ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Byla založena nadace Open Home Foundation zastřešující více než 240 projektů, standardů, ovladačů a knihoven (Home Assistant, ESPHome, Zigpy, Piper, Improv Wi-Fi, Wyoming, …) pro otevřenou chytrou domácnost s důrazem na soukromí, možnost výběru a udržitelnost.
Společnost Meta otevírá svůj operační systém Meta Horizon OS pro headsety pro virtuální a rozšířenou realitu. Vedle Meta Quest se bude používat i v připravovaných headsetech od Asusu a Lenova.
Společnost Espressif (ESP8266, ESP32, …) získala většinový podíl ve společnosti M5Stack, čímž posiluje ekosystém AIoT.
Byla vydána nová stabilní verze 3.5 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). Přehled novinek také na YouTube. Nově lze využívat cloud (audio.com). Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
50 let operačního systému CP/M, článek na webu Computer History Museum věnovaný operačnímu systému CP/M. Gary Kildall z Digital Research jej vytvořil v roce 1974.
Byl zveřejněn program a spuštěna registrace na letošní konferenci Prague PostgreSQL Developer Day, která se koná 4. a 5. června. Na programu jsou 4 workshopy a 8 přednášek na různá témata o PostgreSQL, od konfigurace a zálohování po využití pro AI a vector search. Stejně jako v předchozích letech se konference koná v prostorách FIT ČVUT v Praze.
Po 48 letech Zilog končí s výrobou 8bitového mikroprocesoru Zilog Z80 (Z84C00 Z80). Mikroprocesor byl uveden na trh v červenci 1976. Poslední objednávky jsou přijímány do 14. června [pdf].
Ještě letos vyjde Kingdom Come: Deliverance II (YouTube), pokračování počítačové hry Kingdom Come: Deliverance (Wikipedie, ProtonDB Gold).
Thunderbird 128, příští major verze naplánovaná na červenec, přijde s nativní podporou Exchange napsanou v Rustu.
Jádro 4.15 bylo vydáno 28. ledna. V oznámení Linus poznamenal: „Po vývojovém cyklu, který byl neobvyklý na tolik (špatných) způsobů, byl poslední týden opravdu příjemný. Klidný a tichý, žádná panika na poslední chvíli, jen malé opravy různých problémů. Už jsem neměl pocit, že bych musel vydání odložit o další týden, a podle mě už 4.15 vypadá dobře.“
Některé z nejvýznamnějších změn v tomto vydání zahrnují: dlouho očekávané řízení CPU v druhé verzi rozhraní řídících skupin, významná vylepšení patchování systému za běhu, základní podporu architektury RISC-V, podporu AMD Secure Encrypted Virtualization, mechanimus MAP_SYNC pro práci s perzistentní pamětí. Detailnější shrnutí najdete na stránce KernelNewbies o vydání 4.15.
Toto vydání také samozřejmě obsahuje zmírňování zranitelností Meltdown a druhé varianty Spectre,, ačkoliv jak poznamenal Linus v oznámení, práce týkající se těchto problémů nejsou zdaleka u konce.
Stabilní aktualizace: 4.14.16, 4.9.79, 4.4.114 a 3.18.93 byly vydány 31. ledna.
Myslím si, že jsme tenhle problém všem lidem od bezpečnosti, nejen IMA (Integrity Measurement Architecture), vyrobili do jisté míry sami: Myslíme si, že jsou šílení, takže neposloucháme, co chtějí. Aby dostali, co chtějí, sami implementují komplikovaný systém vrstev a my se poplácáváme po ramenou, jak jsou šílení, protože se zrovna dopustili nechutných prohřešků ve vrstvení. Průměrný člověk od bezpečnosti, jak jsme ho sami umně stvořili, má mozek, který automaticky přemýšlí o komplikovaném vnějším vrstvení, kvůli němuž je jen odháníme dál od sebe.
Takže bez ohledu na mediální zpravodajství je většina výsledků práce na jádře 4.15 obyčejná, úmorná a „nudná“. A myslím to tím nejlepším možným způsobem. Nemusí být zářivá a okupovat titulky, ale je chlebem a solí vývoje jádra a je v mnoha ohledech opravdu důležitá.
Too many lords, not enough stewards. Jake Edge. 31. ledna 2018
Každému, kdo poslední rok nebo dva vnímal jeho přednášky, musí být jasné, že Daniel Vetter není spokojen s procesem vývoje jádra a rolí, kterou v něm hrají správci. V přednášce nazvané „Vypálení hradu“ (Burning down the castle) na linux.conf.au 2018 (LCA) v Sydney si znovu vzal na paškál toto téma, se kterým přišel i na loňské LCA 2017. Podle něj je vývoj jádra rozbitý a je nepravděpodobné, že by se v dohledné době zlepšil.
Začal poznamenáním, že jeho přednáška bude „o něco osobnější než jindy.“ Jde o jeho cestu od prvního pohledu na jádro na střední škole, aby se dozvěděl, jak fungují operační systémy. Jaderní vývojáři byli jeho hrdinové, kteří vytvořili tento úžasný operační systém tím, že spolu veřejně diskutovali.
Časem začal řešit své problémy v grafickém subsystému, díky čemuž byl najat k práci na linuxové grafice – profesionálně, v malém týmu. Dobrovolně se stal jaderným správcem onoho týmu, který se za rok za dva rozrostl ze tří na dvacet lidí. V té době dostal tvrdou lekci o tom, že „vést týmy znamená vést lidi.“ Ale zjistil, že způsob, jakým pracují správci jádra, činí vývojáře, včetně něj, nešťastnými. Přednáška měla být pohledem na to, jak zjistil, jak rozbité to všechno je.
První věc, která se obecně objevuje v diskuzi o tom, co je v komunitě kolem jádra rozbité, je kultura diskuzí, například Linus Torvalds, který někomu nadává. Tato kultura je zakotvena v jaderném Kodexu konfliktu, který vlastně podle Vettera říká, že pokud chcete přispět do linuxového jádra, „budete semleti pro větší úspěch projektu.“ Následuje odstavec, který říká, že pokud je vám něco opravdu nepříjemné, můžete to nahlásit poradní komisi (Technical Advisory Board, TAB) a podle Vettera „ona s tím možná nebude moct nic moc dělat.“
Ale když se bavíte s jadernými vývojáři na konferencích, často říkají, že se kultura za posledních několik let hodně zlepšila. Obecně tím myslí, řekl Vetter, že se omezilo nebo zmizelo „hrubé vyjadřování a diskuze“ v jaderné komunitě. Podle něj to však není ten skutečný problém, pouze jeden jeho aspekt.
To vedlo k jeho první odbočce, která se týkala knihy, kterou četl v rámci přemýšlení o kultuře kolem jádra Linux. Jmenovala se Proč to dělá? Uvnitř mysli rozzlobených a ovládajících mužů od Lundyho Bancrofta. Zajímavou částí knihy jsou archetypy zneužívajících, které Bancroft dal dohromady, a vzory chování, které používají, aby mohli zůstat u moci. Hlavní poučení, které si z knihy Vetter odnesl, je skutečnost, že zneužívání se skládá ze dvou prvků.
Za prvé, zneužívající musí mít nad obětí moc. V případě jádra mají správci velkou moc na přispěvateli, protože jejich právo odmítnout kód je absolutní. Aby se kód dostal do upstreamu, musí se vývojáři potýkat se správci daného subsystému.
Dalším prvkem je ovládající chování, které není nutně násilím. Je zřejmé, že násilí může být naprosto ovládajícím chováním, které ohrožuje bezpečnost oběti, ale existují protipříklady, jako jsou bojová umění. Ta jsou násilná, ale pokud se k nim přistupuje správně, „uctivá.“ Existuje ale různé nenásilné ovládající chování, například určování, s kým smí oběť mluvit nebo chodit ven.
Vetter chtěl zdůraznit, jaký typ ovládacího chování správci používají, aby přispěvatelům diktovali, co smějí a co ne. Seznam začíná tvrzením, že pro jadernou komunitu jsou „důležitá pouze technická témata.“ Podle Vettera to je nesmysl. Možná to platí pro vývojáře, ale nemusí to platit pro správce.
Pro některé správce to znamená hněv, křik a hulákání, ale jiní očekávají emoční podporu, protože jsou přehlcení. Emocionální stav vývojářů je zcela irelevantní. Vyskytuje se také hodně mikroagresí, obtěžování a bikeshedding správců v prostředí, které je zdánlivě pouze technické. Správci mohou přenášet svůj emocionální stav na své přispěvatele v e-mailové konferenci, avšak záleží pouze na emocionálním stavu správců, nikoli přispěvatelů. Toto je klasický příklad ovládajícího chování, řekl Vetter.
Kromě toho jsou diskuze o správě a řešení těchto problémů také mimo téma. Takže je těžké o problémech diskutovat s ostatními.
Vedení týmu lidí se nebere jako cenný příspěvek jaderné komunitě, což vytváří negativní prostor pro vedení, pokračoval Vetter. Vzhledem k tomu, že správci jsou osobně zodpovědní za selhání všech testů, regrese v subsystému a tak dále, činí to věci osobními a také to dělá ze správcování hru s vysokými sázkami. Takže správci se cenzurují a přenášejí to na podřízené správce a přispěvatele. To, že je to osobní, myslí si Vetter, je významnou silou, která udržuje cyklus hrubého a ovládajícího chování v jaderné komunitě.
To vede v některých subsystémech až téměř ke kultu osobnosti. Jsou zde lidé, kteří v subsystému pracují mnoho let a nahromadilo se u nich velké množství znalostí a historie. Tyto lidi je „velmi těžké odstranit.“ Téměř každý subsystém má „své jedovaté osoby,“ které nemohou být odstraněny kvůli nahromaděnému objemu znalostí.
Správcovské pravomoci ve většině subsystémů nejsou sdíleny. Model skupinového správcovství byl tlačen na Jaderných summitech, ale přijat pouze na několika místech: v subsystému x86, na nejvyšší úrovni správy architektury ARM a v polovině grafického subsystému. Správci navíc nedokumentují své nevyřčené předpoklady a pravidla. Ani po letech psaní, revidování a aplikování tisíců patchů si Vetter stále není jistý, jak například formátovat patche pro jiné subsystémy. Nevyhnutelně se objeví drobné problémy třeba s formátováním, když bude posílat patche jinam, ale tato pravidla jsou „naprosto nezdokumentovaná.“
Nástroje a testy, které správci používají ke kontrole patchů, nejsou dostupné přispěvatelům, určitě ne snadno. To se pomalu zlepšuje, řekl Vetter. Ale pro vývojáře by bylo jednodušší najít a opravit problémy předtím, než se dostanou do správcovského stromu, stačilo by, aby kontrolní a testovací nástroje byly dostupné.
Většina recenzí probíhá mezi správci a přispěvateli. Vetter před rokem přelouskal nějaká čísla a zjistil, že pouze 25 % recenzí provádí kolegové, zbytek dělají správci. Pro přispěvatele se z toho stává jakési cvičení, jak se vyhnout konfliktu, protože patch je na cestě k přijetí. Přispěvatel musí pouze „projít procesem, protočit řadu patchů desetkrát,“ aby ukázal, že je „dostatečně podřízen správci,“ potom dojde k začlenění.
Vetter doporučil dvě přednášky s návrhy, jak situaci zlepšit. Jedna se jmenuje „Život je lepší s komunitní automatizací Rustu“ (video na Youtube), kterou přednesla na LCA 2016 Emily Dunham. Druhá, „Ať je po tvém: maximalizace příspěvků od kolemjdoucích“ (video na Youtube) od VM Brasseur, se zaměřuje na jednorázové příspěvky, ale tím, že se proces ulehčuje jednorázovým přispěvatelům, se věci zlepší i těm pravidelným. Vetter si z toho odnesl, že na příspěvky by se měl dívat bot, který poukáže na jakékoli stylistické problémy, možná dokonce poskytne opravenou verzi kódu a upozorní přispěvatele na příslušnou část dokumentace. Takže tato pravidla jsou nejen zdokumentována, ale také snadno odkazatelná, když vzniknou problémy.
Subsystém, který Vetter spravoval, začal divoce růst a on začal mít „pokleslý pocit, že tohle není způsob, jakým se má vést tým.“ Přibližně ve stejnou dobu byl pozván na svůj první Jaderný summit. Chtěl se pokusit mluvit s některými potenciálními spojenci, ale protože grafika je tak nějak oddělená od zbytku jádra, neznal více než dva nebo tři lidi ze stovek správců na summitu. Hledal některé z těch, kdo měli veřejnou přednášku, která by na něj působila tak, že by možná chtěli „bojovat správný boj“, aby změnili způsob vývoje jádra.
Ale zjistil, že na summitu se těžko získává pomoc a spojenci. Někteří z od pohledu „hodných správců“ se ukázali být vůči změnám odolní. Panuje riziko v tom, v jaderné komunitě se ozvat, řekl Vetter. Takže se ukázalo, že je málo správců, kteří jsou ochotní tak učinit. Když se bavíte s mnoha lidmi, kteří se kolem vývoje jádra pohybují dlouhou dobu, a konfrontujete je s otázkou problematických lidí a nezdravého chování nebo toho, že „bychom možná měli věci dělat lépe,“ odpovědí je často, že „to je, jaké to je, a ty se s tím smiř.“ Podle jeho názoru je to činí spoluviníky.
Lidé, s nimiž mluvit můžete, řekl Vetter, komunitu opustili. To je skvělé, protože si můžete porovnávat poznámky. Když tak učiníte, často se objeví stejná jména správců, kteří jsou trochu zklamáním, protože nedělají více, aby pomohli vyřešit problémy. Dochází ke spoustě „hlasitých odchodů,“ ale ještě více přispěvatelů odchází v tichosti. To poskytuje značnou skupinu lidí, se kterými můžete mluvit.
Podobně jsou na tom – v některých ohledech – vyhořelí správci. Problémy si uvědomují, ale komunitu nechtějí opustit, takže odstoupí ze správcovských pozic. S nimi se dá „opravdu dobře promluvit,“ ale protože jsou vyhořelí, postrádají energii, aby pomohli bojovat další bitvu.
Účastníci e-mailové konference dri-devel a grafického subsystému obecně se snaží věci dělat trochu jinak, aby „udělali svůj koutek jádra trochu užitečnějším.“ Tento subsystém vedl přepsání systému jaderné dokumentace a je jediný, který rozdává oprávnění ke commitování. To druhé dělá z grafického subsystému „něco jako standardní projekt.“
V loňském roce byl přijat kodex chování, který je také vyžadován/prosazován, řekl Vetter. „Překvapivě se zdá, že to funguje.“ Bylo zapotřebí uklidnit řadu jaderný vývojářů – Vetter se domnívá, že někteří budou muset být zcela vykázáni. Pokud dáte najevo, že to myslíte vážně, někteří nerozumní lidé se stanou mnohem rozumnějšími, řekl Vetter.
Jedna skupina, která by měla mít silnou motivaci k opravě jaderných procesů, jsou správci na střední úrovni. „Obtěžují je shora a pod sebou mají nešťastné přispěvatele.“ Vetter mluvil s lidmi z jiných subsystémů, kteří by si přáli, aby se věci dělaly jinak, ale vypadá to, že jakmile lidé začnou mluvit o nápravě, nakonec vše jen tak vyšumí a „nic se nestane.“
Předtím, než se Vetter dostal k silám, které mají tendenci stmelit vývoj jádra, nabídl několik míst, kde je možné se o správcovství dozvědět. Community Leadership Summit a přidružená akce CLSx, které se konají během OSCONu, LCA a jinde, stejně jako třeba akce Maintainerati, jsou skvělé příležitosti, kdy se dá mluvit s dalšími správci open-source softwaru. Komunitní sekce mnoha různých konferencí jsou také dobré. Jeden autor, kterého chtěl vyzdvihnout, je John Kotter, jehož knihy o změnách řízení Vetterovi pomohly s úvahami o tom, jak proměnit stávající komunitu s velkou setrvačností.
Existují jisté síly, které v jádře udržují status quo, řekl Vetter. Jednou z nich je povaha jaderné e-mailové konference blízká diváckému sportu. Jakmile Torvalds vybuchne veřejně, přeberou to Reddit, Hacker News a další. Je to něco jako „hrubý performance art,“ který posiluje kulty osobnosti a ukazuje sílu, kterou správci disponují. Také to ukazuje velké riziko vyjadřování na veřejnosti, protože jakmile je medializován jeden Torvaldsův výbuch, vykopou se také všechny z let dávno minulých.
Někteří správci se dalšího takového výbuchu obávají a jsou těmi předchozími poznamenáni natolik, že nejsou ochotní nic změnit, protože je to nejbezpečnější volba. Takže když začnou subsystémy debatovat skupinové správcovství nebo předávání práv ke commitování, dojde nakonec k tomu, že správce řekne „ne.“ Mají obavy, že když dojde k regresi nebo nějakému jinému problému, který se kvůli změně vynoří, budou (opět) podrobeni veřejné kritice. Snaží se zvládnout svůj strach tím, že si zachovají co možná nejvíce vlivu, což jen udržuje věci tak, jak jsou.
Spousta správců jsou zaměstnanci, protože představují úzké hrdlo procesu. Jejich manažeři by je měli tlačit k tomu, aby přestali být úzkým hrdlem s právy ke commitování a tím, kdo to slízne, když Linus vybuchne, ale to se neděje. Správce jako úzké hrdlo má jistotu práce a manažeři se jeví být s tímto přístupem spokojeni.
Linux Foundation (LF) je také součástí problému, řekl Vetter. Byla založena částečně proto, že se někteří obávali koncentrace Torvaldsovy moci, takže chtěli neutrální nadaci, která by ho zaměstnávala. Strmá hierarchie ve světě vývoje jádra představuje výhodu pro nadaci, protože může zaměstnat špičkové správce, a tím k ní poskytnout svým členům i ostatním exkluzivní přístup. Nedávno se LF přesunula do světa cloudu, takže už to není takový problém, ale LF stále představuje faktor v udržování hierarchie.
Jako tajemník nadace X.Org Foundation slyšel Vetter některé staré příběhy o tom, jak tato nadace narazila na různé problémy, takže považuje konflikt zájmů za nevyhnutelný. Pokud jsou řízení projektu a obchod propleteny, věci se mohou zkomplikovat. Po deseti letech se komunita možná posunula kupředu, ale podnikání zůstalo zaseknuté při starém myšlení. Takže namísto toho, aby nadace lépe sloužila komunitě, stalo se jejím cílem udržet lidi zaměstnané, ačkoli tyto pozice již nejsou zapotřebí.
Názor Vettera je takový, že by řízení projektu a zaměstnávání lidí měly být přísně odděleny. Nadace by tedy projektu poskytovala služby a infrastrukturu, ale nezaměstnávala by lidi přímo pracující na projektu. Protože v určitém okamžiku tito lidé už nemusí dělat práci, která je v zájmu projektu a komunity. Stejně tak si Vetter myslí, že by hlasovací práva měla být rozšířena, aby když dojde ke změnám v komunitě, noví lidí nebyli ignorováni jen proto, že nemají hlasovací právo.
Svou přednášku ukončil poznámkou, že správci ze současného statutu quo těží, takže je nepravděpodobné, že by se ho pokusili změnit. Nedoporučil by přispěvatelům, aby na jádře nepracovali, protože se jedná o dobrý kariérní růst, ale navrhl, aby měli záložní plán. „Pokud vystrčíte hlavu a dříve nebo později ji vystrčíte, useknou vám ji.“
Vetterova přednáška by se dala chápat několika různými způsoby. Mohli bychom ji brát jako odkaz na to všechno spálit a začít znovu. Vetter však vidí věci jinak, je to prosba správcům, aby věci dali do pořádku dřív, než přijde revoluce. Tato revoluce by pro Linux byla hrozná. Současné vedení odmítá vidět problémy, řekl Vetter, a když je někdo zmíní, staví se k nim defenzivně.
Takže navrhl, aby správci sdíleli moc, odhodili privilegia a nevyzdvihovali svou pozici při revidování nad ostatní. Také by měli dokumentovat vše, co mohou, a také automatizovat, co jde. Je důležité „starat se o ostatní,“ protože bez ostatních lidí projekt neexistuje. Svou řeč zakončil slovy „buďte sluhou, ne panovníkem.“
Potom odpověděl na několik otázek z publika. Není mu jasné, jak a proč se přihodilo, co se přihodilo. Je možné, že už dávno, když Linux začínal, se ještě nevědělo, jak vybudovat fungující komunitu, jako to umíme dnes. V době, kdy se lidé začali ozývat, byly silové struktury již příliš zakořeněné, než aby je bylo možné změnit.
Vetter řekl, že se mu těžko doporučuje, aby se lidé zapojili do jaderné komunity nebo se do ní vrátili. Mimo grafický subsystém obecně pochopení problémů chybí tak moc, že se ani nedá mluvit o řešeních. Jedním z kroků by mohlo být dostat lidi do stavu, kdy se shodnou, že pouze se omlouvat za současnou situaci nestačí. Možná existuje další subsystém, který by mohl začít propagovat pozitivní změny. Pokud by se tak stalo, byla by jeho přednáška „obrovský úspěch,“ ale časový rámec pro takové změny, pokračoval Vetter, je někde za pět let.
Ve Vetterově přednášce jsou určité části, se kterými by jistě téměř každý účastník nebo pozorovatel (přinejmenším) polemizoval, ale zdá se docela pravděpodobné, že by se neshodli, které části to jsou. Reakce na přednášku byly v mnoha kruzích pochvalné a Vetter jasně vyjádřil obavy, které dosud zůstávaly nevyřčeny. Pojmenoval řadu skutečných problémů jaderné komunity, nyní zbývá jen zjistit, co bude dál.
K dispozici je také záznam přednášky na YouTube.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
5.3.2018 09:19
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Je totiž obecně velice problematické, transformovat projekt který vzniknul jako akce "silných jedinců" tak aby začal fungovat na skutečně demokratických a spravedlivých principech. Ostatně, můžete to vidět všude kolem sebe. S určitým odstupem si troufám říct že vím pouze o jediné organizované skupině, která kontinuálně funguje víc jak 1000 let a to je katolická církev. Ovšem jak jistě víte, ani té se nevyhnuly nejrůznější kopance a přešlapy.No, ale proč by měl? Současnému systému naprosto nikdo nemůže upřít výsledky. Demokratický a spravedlivý princip je asi žádaný v případě vlády, ale proč by to mělo být žádané i v případě vedení projektu? Nepřijde mi vůbec očividné, že to vede na nějakou vyšší efektivitu, naopak. Zkus si představit, jak by fungovala třeba armáda, kde by se všechno řešilo demokraticky a spravedlivě.
No, ale proč by měl? Současnému systému naprosto nikdo nemůže upřít výsledky. Demokratický a spravedlivý princip je asi žádaný v případě vlády, ale proč by to mělo být žádané i v případě vedení projektu?Protože teď to funguje, ale pokud si silný vládce nepřipravý nástupnický plán, tak po jeho smrti/odchodu se všechno sesype. A to se nedá udělat jen papírem v šuplíku, lidi musí vědět, co bude pak, být připravení, naučení - i diktátoři obvykle ukazují svého nástupce po svém boku, když začnou cítit, že přichází jejich čas. Jenže Linus není Vůdce, který by měl silnou ochranku a osobní lékaře a šance, že skončí nečekaně pod autobusem je o dost větší, než třeba v rodině Castrů. A omezit to riziko se dá vytvořením dostatečně silné základny, ať už na demokratickém princpu, nebo třeba v podobě byrokracie, což ale nutně omezuje vliv toho vládce. (A já rozhodně nechci, aby se vývoj jádra utopil v papírových válkách úředníků, takže ta demokratická varianta je z mojí strany preferovaná.)
Nepřijde mi vůbec očividné, že to vede na nějakou vyšší efektivitu, naopak. Zkus si představit, jak by fungovala třeba armáda, kde by se všechno řešilo demokraticky a spravedlivě.Proč všechno? Jednak ta armáda je u nás nakonec stejně řízená demokraticky zvolenými politiky, a pak, pokud máš rozumné lidi, co jsou toho schopní, tak klidně můžeš mít hybridní režim, kdy normálně fungujeme demokraticky, ale když má kapitán důvod, tak zařve a posádka poslechne na slovo (empiricky ověřeno).
5.3.2018 10:45
Fluttershy, yay! | skóre: 92
| blog:
5.3.2018 10:40
Fluttershy, yay! | skóre: 92
| blog:
To má být argument pro katedrálu namísto tržiště?
Vojenské struktury… ty jsou nastaveny na (a) regulaci přístupu k informacím (to asi nebude cílem v komunitně vyvíjeném softwaru) a (b) standardizaci procesů (čehož absenci v Linuxu právě přednášející v článku kritizuje).
5.3.2018 12:31
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
V loňském roce byl přijat kodex chování, který je také vyžadován/prosazován, řekl Vetter. „Překvapivě se zdá, že to funguje.“ Bylo zapotřebí uklidnit řadu jaderný vývojářů – Vetter se domnívá, že někteří budou muset být zcela vykázáni. Pokud dáte najevo, že to myslíte vážně, někteří nerozumní lidé se stanou mnohem rozumnějšími, řekl Vetter.nebo
Ale zjistil, že na summitu se těžko získává pomoc a spojenci. Někteří z od pohledu „hodných správců“ se ukázali být vůči změnám odolní.nebo
Když se bavíte s mnoha lidmi, kteří se kolem vývoje jádra pohybují dlouhou dobu, a konfrontujete je s otázkou problematických lidí a nezdravého chování nebo toho, že „bychom možná měli věci dělat lépe,“ odpovědí je často, že „to je, jaké to je, a ty se s tím smiř.“ Podle jeho názoru je to činí spoluviníky.Líbí se mi, jak rozdělil lidi na "hodné" a "zlé" a pak stihl pokárat i ty hodné, že jsou "odolní"" vůči (jeho) změnám a kdo nesouhlasí, že se všechno bude dělat lépe (= po jeho), je "spoluviník" na útlaku. Tohle působí jako úplně ukázková snaha o převzetí moci. Rozděl a panuj, najdi si drama a body nátlaku, které můžeš použít pro svojí kampaň, vyhrožuj a vyhoď lidi, kteří jsou ti nepohodlní, veď nátlak na lidi, kteří s tebou nesouhlasí a ideálně se ještě nezapomeň postavit do role oběti. Samozřejmě je slušná šance, že se pletu. Ale když vidím podobné řeči psané takhle otevřeně, tak to ve mě rozhodně nevzbuzuje dobrý pocit.
5.3.2018 13:17
Fluttershy, yay! | skóre: 92
| blog:
Linux je fungující projekt. To je asi nepopiratelné.
Jak je tedy možné, že se dlouhodobě řeší neudržitelnost modelu komunity, škálovatelnost Linuse,…?
Tohle působí jako úplně ukázková snaha o převzetí moci.
No a teď zkus na moment vystoupit z petersonovské fanfic a poděl se s námi o svou představu o „převzetí moci“ v podobě kolektivního správcovství nebo dokumentace procesů. Jo, převzetí moci možná jo, ale v duchu miltonovském. Proti tomu ale nemám velkých námitek.
Jak je tedy možné, že se dlouhodobě řeší neudržitelnost modelu komunity, škálovatelnost Linuse,…?
Právě proto. Kdyby kvůli tomu projekt nefungoval, neřešilo by se to dlouhodobě, ale muselo by se to vyřešit, a to pokud možno rychle. :-)
5.3.2018 13:49
Fluttershy, yay! | skóre: 92
| blog:
5.3.2018 13:42
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
No a teď zkus na moment vystoupit z petersonovské fanfic a poděl se s námi o svou představu o „převzetí moci“ v podobě kolektivního správcovství nebo dokumentace procesů. Jo, převzetí moci možná jo, ale v duchu miltonovském. Proti tomu ale nemám velkých námitek.Ale proč by mělo být dobře, že to bude kolektivně spravovat někdo jiný, než současní správci, kteří se dlouhodobě osvědčili? Mělo by snad být na nich a na komunitě kolem nich, aby se snažili najít náhrady, až budou potřeba, ne? Přijde mi divné, když někdo přijde do očividně fungující komunity a snaží se všem vnutit svoje pořádky a ještě k tomu používá uvedenou rétoriku.
Zatím co jedni koukají po záchraných člunech, druzí naslouchají skvělé hře lodního orchestru.
Povšimněte si, prosím, že vámi popsaná situace neříká naprosto nic o tom, jestli se loď opravdu začíná potápět nebo jestli je všechno v nejlepším pořádku.
Je to sice poněkud expresivní příklad, protože tak daleko ta věc ještě není, nicméně jak vidno některým už začíná být jasné, že do budoucna to bude muset fungovat trochu jinak.Jinými slovy. Někdo problémy už vidí a jiní ještě ne.
tanečky kolem Reiser4
Jaké "tanečky"? ReiserFS 4 měl objektivně zcela konkrétní zásadní chyby, které Hans Reiser bagatelizoval a odmítal opravit.
jak probíhal (a řadu let vlekl) proces začlenění overlayfs
V tomto případě ale AFAIK nebyl vůbec problém v tom, že by maintainer VFS zneužíval svou moc, ale právě naopak (zbytečně dlouho) zcela "demokraticky" nechával průběh tomu, aby si to "kluci vyříkali mezi sebou".
V podstatě se dá říct, že filosofie je taková, že je lepší přijít o zajímavou featuru než si do jádra zavléct velký kus kódu pochybné kvality, který nebude nikdo udržovat. Jakožto člověk, jehož podstatnou částí pracovní náplně je support, to naprosto chápu. Tím spíš, že dostat něco z jádra je zatraceně těžká věc (UFO anyone?), a to i když panuje všeobecná shoda, že jde o hnijící mrtvolu.
Nic pochopitelně není černobílé, takže se občas stane, že dříve udržovaná část jádra časem začne z nějakých důvodů zahnívat nebo že někdo špatně odhadne situaci a akceptuje něco, co vypadá nevinně, ale vyklube se z toho pořádný bolehlav (napadá mne třeba net/smc). Ale tam, kde je už dopředu dostatek varovných signálů, je ostražitost na místě - a ReiserFS 4 byl ukázkovým příkladem. Také je rozdíl mezi neudržovaným izolovaným driverem, který používá, pár lidí, a významným filesystémem.
Není samozřejmě nutné, aby kód navěky udržoval původní autor nebo ten, kdo ho submitnul. Tady bylo ale AFAIK dost zjevné, že za Hanse Reisera ty problémy nikdo opravovat nechce. Vzhledem k tomu, že se místo řešení problémů zaměřil spíš na PR a očerňování "nepřátel", vůbec se tomu nedivím (a stejně tak se nedivím, že se dodnes najdou lidé, kteří nekriticky přejímají jeho výklad). Viz třeba Theodore T'so:
As far as I know not all of the problems were fixed. And it has been observed that given the abuse and accusations that were directed at the people who did decide to review it, that it would not at all surprising if some (all?) of reviewers may have decided they had better things to do. Getting things merged into mainline is not a right, and the reviewers are volunteers.....
Speaking for myself, since I don't enjoy being accused of partisanship and being ascribed of having a desire to backstab reiserfs, I have a personal policy to avoid reiserfs review, and recuse myself from any votes within program committee discussions regarding Hans Reiser. Being accused of taking unfair advantage of my volunteer activities is something I allow myself to get into once.
U filesystému mi prostě přijde logické, že spolehlivost a udržovatelnost mám přednost před geniálními myšlenkami.
Chytáte se dílčích problémů.
Myslíte? Já na rozdíl od vás nemám tolik sebevědomí, abych tváří v tvář tomu, že Christoph Hellwig, Al Viro a Theodore T'so svorně tvrdí, že filesystém má zásadní designové chyby, trval na tom, že oni tomu nerozumějí a já vím, že byl určitě v nejlepším pořádku (protože "mně to funguje").
Nejsem vývojář, tak mi je to nakonec jedno
Stejný problém. Nejste vývojář, natož vývojář filesystémů, ale přesto máte naprosto jasno, že to řešení bylo naprosto v pořádku a veškeré připomínky byly jen podružným bazírováním na formalitách, protože "nám to fungovalo".
Vy teď ten problém možná ještě nevidíte, ale dříve či později si ho rovněž všimnete.
Tenhle přezíravý postoj "no jo, vy jste to ještě nepochopil, ale vy na to jednou (nevyhnutelně) přijdete" mne trochu irituje, abych pravdu řekl. Ne, vůbec si nemyslím, že všechno funguje ideálně (a už jsem to tu i napsal). Ale zjednodušit to na jeden specifický problém, který sice nepochybně někde opravdu existuje, ale rozhodně není obecný, a namlouvat si, že je nezbytně nutné ho řešit jedním konkrétním způsobem - a že to automaticky pomůže, to prostě neberu.
Vy jste uvedl dva konkrétní příklady, kterými se to snažíte dokládat. Jeden je podle mne úplně mimo, protože chcete-li někomu konkrétnímu dát vinu za to, že Reiser4 se nedostal do upstreamu, pak pro mne je jednoznačný kandidát jen jeden, a to Hans Reiser. Druhý příklad podle mne ilustruje problém přesně opačný, tedy ne zneužívání autority maintainerem, ale naopak to, že se do věci nevložil podstatně dříve.
Chápu, že z pohledu člověka, který chce v jádře nějakou cool featuru, je frustrující sledovat, jak se proces vleče a přibývají další revize, zvlášť když podstatě připomínek často ani neozumí. Nechápu ovšem tu zpupnost, když na základě toho začne vyprávět, jak ten proces nefunguje a to ti maintaineři zbytečně zdržují kvůli malichernostem, když on ví, že to "prostě funguje". Já si třeba často netroufnu posoudit, kdo "má pravdu", ani u networkingu, natož pak u oblastí, kterými se nezabývám.
tam kde vy žádný problém zatím nevidíte už jiní problém vidí
A já několikrát upozornil, že to, že někteří vidí problém a jiní s nimi nesouhlasí, neznamená automaticky, že musejí mít pravdu zrovna ti, kteří "už" ho vidí, a že je jen otázka času, kdy ostatní "prohlédnou".
Připomeňte si prosím, že s tím příspěvkem přišel Daniel Vetter
Ano, to je jedenmaintainer. Přímo do diskuse na LWN několik dalších napsalo, že oni to vidí jinak. Několik dalších přispěvatelů navíc upozornilo, že to převyprávění vyznívá mnohem víc konfrontačně než samotný talk.
Mě nepálil Reiser4, ten v jádře byl.
Teď jsem si toho teprve všiml… jak tomu mám rozumět? Zkusil jsem pro jistotu i trochu googlit (paměť může klamat), ale nenašel jsem nic, co by dokládalo, že by se reiser4 někdy opravdu dostal do mainline.
5.3.2018 13:56
Fluttershy, yay! | skóre: 92
| blog:
kteří se dlouhodobě osvědčili
Jestli to není právě iluze meritokracie.
to bude kolektivně spravovat
Protože když stávající správce vyhoří nebo ho přejede autobus, tak to paralyzuje subsystém?
Co když stávajícímu správci status quo – nenahraditelnost a autorita – vyhovuje?
5.3.2018 14:14
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Jestli to není právě iluze meritokracie.Jo, hrozná iluze, která vedla jenom k nejúspěšnějšímu opensource projektu v dějinách lidstva, jinak je ale úplně nepodložená.
Protože když stávající správce vyhoří nebo ho přejede autobus, tak to paralyzuje subsystém?A to se jako po změnách nestane, jo?
Co když stávajícímu správci status quo – nenahraditelnost a autorita – vyhovuje?No a? To automaticky neznamená, že je na tom něco špatně.
5.3.2018 15:01
Fluttershy, yay! | skóre: 92
| blog:
To je nejspíš právě Alešova pointa, že nestačí se navěky poplácávat po ramenou.
Protože když stávající správce vyhoří nebo ho přejede autobus, tak to paralyzuje subsystém?A to se jako po změnách nestane, jo?
Pokud je cílem mít správců víc, tak to znamená bus factor >1.
Protože když stávající správce vyhoří nebo ho přejede autobus, tak to paralyzuje subsystém?
Jakkoli to zní paradoxně, to vyhoření je větší problém. Pokud by maintainer ze dne na den "zmizel", bylo by všem jasné, že takovou situaci je třeba vyřešit hned a bez prodlení - a praxe ukazuje, že se také obvykle rychle vyřeší. Na druhou stranu, vyhoření není jednorázový střih, ale pozvolné zhoršování situace, to se z principu vždy řeší hůř.
Co když stávajícímu správci status quo – nenahraditelnost a autorita – vyhovuje?
Co když vyhovuje i ostatním?
6.3.2018 11:25
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Asi máme hodně rozdílnou představu o významu slova důkaz.
Především je potřeba mít na paměti, že i kdyby to jim opravdu tak skvěle fungovalo, vůbec to neznamená, že to bude zlepšení i v jiných subsystémech, natož kdyby se to aplikovalo na celý strom. Já mám třeba zkušenosti se změnou přesně opačnou, tj. z modelu, kde může přímo commitovat každý, kdo je dostatečně způsobilý, na model, kde má každá větev svého maintainera, který dostává pull requesty. A jednoznačně to byla změna k lepšímu.
Co se týká toho, jak to funguje u i915, tak i tam mám své pochybnosti. První věc, která se mi vybaví, když se řekne i915, je b^Hchaos, který tento driver zanáší do gitu svými duplicitními commity, protože si jednotliví vývojáři neustále cherry-pickují opravy mezi sebou, takže se pak stejný patch dostane do stromu pod několika různými commit id. Ne že by se to občas nestalo i jinde, ale frekvence, s jakou se to děje u i915 (a to zejména u oprav, které končí ve stable větvích a distribučních jádrech, tj. tam, kde to vadí nejvíc) - je alarmující. Dokonce i Greg KH, který obecně rozhodně neplní úlohu "zlého muže", už se kvůli tomu nedávno ozval. Nevím, do jaké míry je to důsledek toho jejich workflow a do jaké míry jen nedostatek disciplíny a ohleduplnosti, ale podle toho popisu v článku bych řekl, že to přinejmenším částečně souviset bude.
kde také přešli ke skupinovému správcovství
Jenže on nenavrhuje skupinové správcovství. Model, kdy nemá subsystém jednoho maintainera, ale třeba dva nebo tři, kteří se o tu práci dělí, už leckde dávno funguje i bez Daniela Vettera. To, co navrhuje on, jde o dost dál. Nemám samozřejmě nic proti tomu, že si to nasadili v i915, pokud jim to tak vyhovuje a nezpůsobuje to problémy jinde. Nevidím ale důvod, proč automaticky předpokládat, že by takový model byl přínosem i jinde. Jak už jsem napsal, každý subsystém má své specifické problémy a moje obecná zkušenost je, že univerzální kouzelné proutky málokdy fungují tak univerzálně, jak jejich propagátoři tvrdí.
8.3.2018 10:55
Fluttershy, yay! | skóre: 92
| blog:
6.3.2018 10:01
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
6.3.2018 11:48
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
A to, že největší kápo je demokraticky volený prezident nestačí?To na věci vůbec nic nemění. Myslím, že jsi úplně ztratil původní thread diskuze. Pokud se ti nelíbí armáda, tak si vem v podstatě libovolnou firmu, nebo složitější projekt a zamysli se, jak moc se tam uplatňuje demokracie a na kterých úrovních řízení lidí a proč.
6.3.2018 10:00
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Zkus si představit, jak by fungovala třeba armáda, kde by se všechno řešilo demokraticky a spravedlivě.vs
Asi by mě nemělo překvapovat, že humří skvadra si fetišizuje armádu...Ono celkově, tvoje povědomí se mi zdá poněkud naivní.
a ze to neni potreba brat osobne
(nic me neurazilo, proc by me ten kolousek mel urazet)
6.3.2018 13:23
Fluttershy, yay! | skóre: 92
| blog:
Pokud si chcete přeměřovat jaderné pindíky
Ale houby, o to tady vůbec nejde, se svou zhruba padesátkou commitů v mainline se těžko můžu vydávat za nějakého guru. Jde o to, že mám temné podezření, že většina zúčastněných ve skutečnosti nedebatuje o vývoji jádra, ale o českém překladu článku z LWN, jehož obsahem je převyprávění jistého talku Daniela Vettera, kde prezentoval svůj pohled, tj. oni sami mají informace z třetí ruky. A to je podstata problému, protože už ten talk je sám o sobě jednostranným pohledem na věc a když se podíváte do diskuse pod původním článkem na LWN, hned několik lidí tam upozorňuje, že ten článek vyznívá poněkud jinak než ten původní talk (a nevšiml jsem si, že by to tam někdo zpochybňoval).
Nechci tvrdit, že ohledně vývoje jádra všechno funguje hladce a sluníčkově a není si na něco stěžovat. Ale ta generalizace, kterou předvedl Daniel Vetter, s tím prostě nemůžu souhlasit. Dal by se třeba uvést příklad jednoho klíčového subsystému, který dodnes nemá vlastní git. Nebo jiný, kde se nečinnost maintainera probírala i na Kernel Summitu. Ale stejně tak by se dalo mluvit o subsystému, kterým proteče zhruba čtvrtina patchů a z procesního hlediska tam žádné zásadní problémy nejsou. Takže ano, problémy rozhodně existují, ale vůbec nemám pocit, že by to šlo zjednodušit tak, jak to udělal Daniel Vetter. Někde jsou problémy větší, někde menší, ale ani tam, kde to moc dobře nefunguje, není zdaleka vždy (hlavním) problémem to, že by se maintainer choval jako nějaký arogantní polobůh.
Já mám s jadernými procesy zkušenost skrze medializované Linusovy výstupy. Ale i těch pár jeho emailů mi bohatě stačí na to, abych konstatoval, že se chová jako idiot a toto rozhodně není způsob, jak pracovat s týmem lidí.
Nemám chuť to tu sáhodlouze rozebírat, kdyby nic jiného, tak i proto, že i přímo tady už jsem se o to několikrát pokoušel. Takže jen stručně: takový závěr je asi tak stejně fundovaný, jako kdybyste si někde přečetl citaci posledních tří slov Písně neznámého vojína a na tomto základě usoudil, že Karel Kryl byl hulvát a sprosťák a že nic víc už vás nezajímá, protože už o něm víte vše podstatné.
a tohle se neustála opakuje
A tohle přesně ukazuje, proč to přirovnání tak dobře sedí. Máte vůbec představu, na kolik let práce a kolik pull requestů těch pár medializovaných reakcí připadá? Obtěžoval jste se aspoň podívat, na co ty reakce byly, co jim předcházelo a co je vyvolalo? Očividně ne, vám prostě stačí "vědět", že "tohle se neustále opakuje".
Ano, obtěžoval.
Abych pravdu řekl, moc tomu nevěřím. Kdybyste to totiž udělal, těžko byste mohl napsat takový nesmysl jako
ale každý zúčastněný ví, že kdykoliv může ke komukoliv přiletět nečekaná pumelice
Zúčastnění totiž vědí, že to není ani ke komukoli (ukažte mi příklad, kdy Linus takhle vyjel na nějakého nešťastníka, který poslal patch a podařilo se mu nechtěně něco rozbít - i kdyby to měla být pověstná wi-fi na Linusově notebooku), ani kdykoli (ani pověstné "rozbít userspace" nestačí, musíte navíc zarputile obhajovat, že tak je to vlastně správně). A asi právě proto mají největší péči o "domrvenou atmosféru" ti, kdo o té atmosféře v podstatě nic nevědí.
Každé prostředí má svou kulturu. České úsloví říká "co se snese v lese, nesnese se na plese", ale je dobré si uvědomit, že to platí i naopak. Před pár dny jsem třeba četl rozhovor s fotbalistou Krmenčíkem, kde popisoval, jak ještě jako dorostenec přišel poprvé do kabiny plzeňského áčka a tam seděla tehdejší hvězda Pavel Horváth. Pozdravil ho "dobrý den" a dostalo se mu odpovědi "No, to si snad děláš p...l, mladej." Ladislav Špaček by z toho asi dostal vyrážku, ale těžko očekávat, že ve sportovním týmu bude "bažant" vykat starším hráčům a oslovovat je "pane Horváth".
Sportovní prostředí je samozřejmě v tomto ohledu trochu extrémní a nechci tvrdit, že si z něj open source projekty mají brát příklad. Ale i samotný svět open source se dost vymyká běžným zvyklostem. Před časem jsem byl na školení prezentačních dovedností a školitel nám o přestávce vyprávěl, jaký kulturní šok utrpěl, když v naší firmě školil poprvé. Součástí je blok, kdy účastník něco krátkého odprezentuje a ostatní ho mají hodnotit, což v "normálních" firmách probíhá tak, že se všichni úzkostlivě snaží neurazit, takže se soustředí na pozitiva a pokud vůbec zmíní chyby, snaží se to co nejvíc zaobalit a zjemnit. A pak přišel sem a jen zíral, jak všichni bez servítků a bez zábran vyjmenovávají nedostatky - a na druhé straně s tím nikdo nemá problém a nikdo to nebere jako útok na svou osobu.
Takže jakkoli si myslím, že by to klidně šlo i bez těch vulgarit (aniž by se to odrazilo na efektivitě), jsem si moc dobře vědom, jak řídký je ve skutečnosti jejich výskyt a iritují mne mudrcové, kteří na základě pár e-mailů ocitovaných bez kontextu dělají dalekosáhlé závěry o "domrvené atmosféře" v projektu. V tom to totiž vůbec nespočívá; šéf může být nesnesitelný a otrávit atmosféru, aniž by k tomu potřeboval jediný ostřejší výraz, a stejně tak to platí i naopak. Znám dost vývojářů jádra a i nějaké maintainery. Nevšiml jsem si, že by žili v permanentní hrůze, že je Linus znectí (a objeví se to na Slashdotu). Ne že by si občas (a někteří i často) nestěžovali na to, jak určité věci kolem vývoje a jeho managementu fungují, ale vesměs řeší úplně jiného problémy, než se probírají v této diskusi.
.
Kdo dnes učí komplexnímu multidisciplinárnímu přístupu ke vzdělání, a preferuje pochopení před "nastudováním"?Do kamene tesat.
… Jedině tak má GNU/SystemD nějakou budoucnost, která nebude světlá ale černá, jako kůže po staletí utlačovaných vývojářůHm. Přiznám se, že jsem mezi vývojáři kernelu moc černoušků neviděl.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz