Tak já odpovím z pozice seniorského vývojáře v Red Hatu. Zkušenému člověku manažeři dávají volnější ruce, Lennart není žádná výjimka. Sám to mám taky tak. Netvrdím že si děláš celý den co si zamaneš, ale ten prostor může být hodně velký. Denodenní povinnosti má každý, zejména opravovat bugzilly to se někdy musí když se finishuje release, ale jinak to může být pro někoho celkem těžko pochopitelné. Dám příklad.
Do posledních tří major verzí produktu na kterém dělám jdou featury které byly moje invence. Měl jsem prostě pocit, že tohle by projekt potřeboval, navrhl jsem řešení, poslal patche do všech komponent a nyní to používají lidé z komunity i zákazníci. Žádný manažer mi neřekl "budeš dělat to a to", je to spíš tak že odprezentuju nápad a prototyp a manažer řekne "je to ok, hodí se nám to do krámu, dělej na tom dál".
Ne každý senior to tak má, člověk musí mít čuch na to, co se hodí v upstreamu, downstreamu, co manažer dokáže snadno obhájit u svého nadřízeného a tak dále. Nicméně nic světoborného to není.
Takže rozdíl je jenom v tom, že chce řešit problémy tohoto světa a když na nějaký problém narazí, vymyslí řešení?
Tak ať to kritici dělají stejně - najdou problém, najdou řešení a implementují ho. U nás se vždycky, když něco děláme, pokusíme najít víc řešení a vybírá se to lepší podle pro a proti. Pokud Lennart vytasí nějakou "pitomost" za RedHat, proč třeba Suse nebo Canonical nepřijdou s alternativou?
Problém je, že ta Lennartovská "řešení" vždy vyřeší jeden okrajový problém a spoustu dalších přidělají. Při tom to v tomto případě šlo řešit jednoduše - nový "prediktivní" systém dát jako volbu jen těm, kterým to něco přinese. Ostatní by jeli po staru a měli klid.
Canonical alternativy má (pro problémy svých uživatelů), ale syslí si je u sebe a nedává je do upstreamu, za což paradoxně bývá dost často kritizován.
Vysvětluju si to tím, že je to od Redhatu záměr - administraci Linuxu zkomplikovat natolik, aby si na řešení umělých problémů musely zaplatit podporu - a to zase u Redhatu.
Já jsem ve světě bez systemd žádný problém nespatřoval a vše fungovalo dle očekávání tak jak přesně mělo. Že Lennart vidí v něčem problém a hned na něho musí najít řešení neznamená, že stejný problém ve věci vidí jiní, či že vůbec daný problém existuje jinde než v hlavě pana Lennarta.
Připadá mi to jak EU. Ta taky vidí problémy tam kde nejsou a hned nalézá všespásná řešení takto vyskytnuvších se problémů.
Takže rozdíl je jenom v tom, že chce řešit problémy tohoto světa a když na nějaký problém narazí, vymyslí řešení?
Aniž bych se chtěl přidávat k dobře rozjetému flamu, tak nahradit jedno problematické řešení jiným problematických řešením je jako to známé rčení "z bláta do louže". Ano, předchozí řešení jmen síťovek není dokonalé, ale už si na něj tak nějak všichni zvykli. Nové řešení není dokonalé a budou si na něj muset všichni zvyknout.
Tak ať to kritici dělají stejně - najdou problém, najdou řešení a implementují ho.
To je zcela mylný postup. U spousty věcí (nejen ze světa systemd) má člověk pocit, že by stačil rollback na předchozí non systemd řešení. Problém je, že takto se nepostupuje. Kdykoliv systemd s něčím přijde, tak se chce oprava jen toho systemd řešení a o tom, že to třeba před zásahem systemd vlastně fungovalo se nesmí mluvit.
Ale ano, rozumím, taky jsem měl tu čest s managery, pro které bylo nutné všechno každý rok 3x všechno předělat, aby se něco dělalo. To, že se předělávalo něco, s čím vlastně nikdy nebyl problém nechtěli vidět. Pořád chtěli lepší a lepší řešení (neexistujícího problému). To je jako řvát na horolezce na vrcholu Mount Everestu, že to nestačí, že musí šplhat ještě vejš. Od takových debilů je dobrý se co nejdřív vzdálit.
Az na taku malu drobnost, ze ani jedna z tych uzasnych nahrad "v podobe systemu bez systemd" to nedotiahla do enterprise level riesenia. Takze nikto nie je ochotny brat prachy za support tychto bezplatnych bezproblemovych systemov a vsetci velki dodavatelia Linux distribucii su uplni idioti a zbytocne si komplikuju zivot a zvysuju naklady zavadzani systemd...
Odporcovia systemd by sa mali rozhodne spojit a tuto dieru na trhu vykryt, skor, nez im niekto tento napad vyfukne :-)
...teraz koniec srandy - lebo vidim, ze len mavam cervenou handrou s napisom systemd, na ktoru len niektori prehnane a iracionalne reaguju a zbytocne zbieram negativne body :-)
Tak uprime v enterprise levelu at si delaji co chteji, at si plati koho chteji. Ma zkusenost s 800+ servery ve skolach po CR a SR i Polsku a Nemecku, jede se striktne bez systemd a uplne v poho. Jestli se chce nekdo zasekat se systemd, a platit admina za nekonecne googleni s kazdou novou verzi, nizkou produktivitu prace, nasrany klienty, kteri cekaji 14 dni na reseni jindy trivialniho vzdaleneho servisu, ci si chce platit treba primo Lennarta, pac ten jediny se v tom svem systemd snad vyzna, to je jeho boj a jeho prachy. U nas to delame ponekud rutinneji a systemy bezi naprosto stabilne. Ja jsem tedy nadmiru spokojen i bez systemd :) PS: ja za servis systemu bez systemd prachy beru, majitel je spokojen s funkcnosti a plati celkem slusne. Takze asi jsem vyjimka a nepatrim do vami zminene skupiny "nikdo".
Vy ste to to mozno z kontextu nevycitali, ale ja som nemal na mysli nejaky maly e-shop alebo homepage firmicky s 10 zamestnancami, kde si 2-dnovy vypadok nikto nevsimne. Situacia je dnes taka, ze vsade, kde vypadok sluzieb znamena tazke financne straty, sa nasadzuju v pripade GNU/Linux LEN distribucie, ktore splnaju urcite podmienky (stabilita, podpora, ...).
Momentalne neviem o ziadnej takej distribucii, ktora by nenamigrovala na systemd. Ja na rozdiel od Vas si nemyslim, ze by Lennart Poettering bol az taky diabol, ze by politickymi machinaciami alebo zakulisnymi tahmi dokazal zmanipulovat firmy ako RedHat (ok, tam este mozno hej, dajme tomu..), Canonical, alebo SuSE. Skor to vyzera tak, ze systemd ma zrejme nejake kvality, kvoli ktorym sa tymto firmam oplatilo investovat nemale prachy na premigrovanie existujuceho init systemu na systemd.
Mne osobne tiez na systemd niektore veci vadia, ale fascinuje ma, ze drviva vacsina zarytych odporcov systemd pouziva len argumenty v style "mam to nejako nabastlene, tak mi to chodi uz roky a systemd mi to cele rozmrdal" (prip. "roky som zvyknuty to robit takto a systemd je na <> lebo to musim robit inac"). Za cele tie siahodlhe diskusie (teda skor flamy), ktore som mal tu moznost precitat som narazil az na JEDEN RELEVANTNY TECHNICKY ARGUMENT preco systemd nie, inak vsetko same dristy (zhrnute v dvoch vetach vyssie).
Skuste si, mili bojovnici svatej vojny proti systemd, aspon poriadne nastudovat, proti comu to vlastne bojujete a ci by Vam niektora jeho vlastnost napriklad neusetrila dlhe hodiny stravene ladenim skriptov, pretoze ak budete apriori odmietat vsetko nove, tak to zrejme v IT biznise moc daleko nedotiahnete...
@dizzy
Tak systemd byl v podstatě nasazený IMO ve stavu Alfa verze do produkčních verzí dister. Co, jak a proč je otázka, údajně tam měl hrát roli "strach" z další nekompatibility s hlavními hráči - nevím. IMO potřebovali prostě širokou základnu pro laděním jinak by to doteď dělali na koleni a nepotkali ani 1/2 možných konfigurací reálných nasazení. Třeba v Debianu to údajně prošlo o jeden hlas, což mi zas tak super abys tady s tím mohl ostatní fackovat nepřijde. Problémů okolo systemd - faktyckých - byla hromada, uznávám to je všude, ostatně někdo tady vkládal zajímavou reakci od Linuse - nemyslím si že by to byl jenom nějaký trotl který si nenaštudoval nějaké scripty a teď jenom tak pindá. Systemd prostě zasáhl široké pole - už z definice určení - a na to jak budovat a řídit široký systém je více možných názorů a netroufl bych si šmahem jako ty jen tak ostatní spláchnout jako nějaké obyčejné trotly nebo hatery. Třeba mě osobně vadí že se z toho stává komponenta, které místo aby řídila a předávala, tak požírá další a další součásti systému a prostě toto se mi v životě a praxi neosvědčilo. Názor tedy nějaký mám - jak mám prokázat že už je to moc? Jsem bojovník svaté války?
A podobně, přestože je to u těch zlých svatobojovníků přehlíženo, málokdo z nich neuzná že nebylo potřeba zlepšení či vyřešení. Jenomže názory i na celkem takové neurčité věci jako je rozsah, chceš-li zásah, do architektury se různí a nemusí být správný jenom jeden, těžko se prosazují protože mají svá pro i proti a krom vyložených pindačů, byl bych velice opatrný na to paušálně všechny označovat jako nějaké "bojovníky ve svaté válce". Nehledě na to že spousta se jich tak nechová. Ovšem uznávám, nic jednoduššího než označit skupinu s protinázorem za hlupáky není. A to taky zrovna oblibě systemd nepřidá, když se ti třeba ten přístup tak úplně nelíbí a ještě tě někdo fackuje takovýmy nálepkami ...
Vidis Kentan - ty si prave trafil ten jediny relevantny argument, ktory som mal na mysli (a ktory som tam naschval nepisal), preto mas za mna palec hore ;-) Toto je totiz jediny protiargument, ktory beriem - naozaj systemd sa snazi riesit veci, ktore by nemusel (napr. nahrada cron-u). Osobne by som tiez uvital, ak by sa rozbil na viac (podla moznosti volitelnych a idealne vzajomne nezavislych) modulov ale beriem to ako nutnu dan za nesporne vyhody, ktore na druhej strane prinasa...
Ja som narazal skor na ludi (a je ich tu zial strasne vela), ktorych argumentacia stoji na tom, ze im cosi kdesi funguje, su na to zvyknuti a sprosty systemd im to rozbil.
@dizzy
Tak argument ... Nezbývá ti nic jiného než ho zobrat, protože to jestli systemd řeší moc věcí nebo ne je věc názoru a nejsem si vědom toho, že by se někde dala nalézt nějaká přesná odopvěď ve stylu naplnění nějaké věštby nebo definice. Maximálně nalezneš nějako autoritu před jejíž výrokem se skloníš, uznáš nebo ho přijmeš. To je celé.
Kdesi cosi - takže nevíš kde, nevíš co, je ti to jedno, ale označíš to za chabý argument v tom lepším případě, za svatoválečníky ~ zaslepence v tom horším, přestože jsi schopný přijmout argument že toho řeší až moc, tedy zasahuje do moc věcí tedy by mohl někde zbytečně zasáhnout do věcí které těm lidem fungují ... ach jo ...
Zle si ma pochopil Kentan - mne vadi skor to, ze je to jeden velky monolyt, nez to, ze zasahuje do viacero oblasti. Cize kludne nech tieto oblasti pokryva, ale modularne (t.j. oddelene a prip. nahraditelne). Je to taka moja idealizovana predstava ako by to malo vyzerat (a nie som si isty ci je to vobec technicky mozne).
Na margo zasahovania do fungujucich veci - zial nemozes ocakavat, ze skript, ktory si zbastlil pred 10-timi rokmi ti bude fungovat dalsich 100 rokov. Pretoze ked ti ho nerozdrbe systemd, rozdrbe ti ho nova verzia bashu, OpenRC (alebo co presne pouzivas), prip. ineho systemoveho komponentu, ktoreho prinos bude pre teba mozno otazny. Spatna kompatibilita sice vyzera dobre na papieri ale v praxi si so sebou prinasa vela technickych komplikacii. Plakat nad tym, ze sa po 20 rokoch (toto cislo som si typol, takze mozno nebude uplne presne) na Linuxe premenovali zariadenia mi pripada byt v dnesnom svete trocha scestne vzhladom na tempo akym sa technologie vyvijaju.
Ber to ako evoluciu - ja si myslim, ze doteraz pouzivane init systemy boli neudrzatelne a vnimam systemd ako riesenie, ktore zial nie je idealne, ale prinasa IMHO viac vyhod ako nevyhod. V tomto sa mozno nezhodneme, ale to je uplne jedno, pretoze jak ty tak aj ja s tym trt makovy urobime a zrejme nam nezostane nic ineho, nez sa prisposobit...
@dizzy
No je celé takové nedomyšlené. Např. bavili jsme se o tom, proč hned neházet všechny nemilovníky systemd do jednoho "svatoválečného pytle" a ty do toho zatáhneš přejmenovávání zaízení .... Je to sice téma článku ale ne našeho rozhovoru. Jenom do toho zatahuješ další nesouvisející věc - jak můžeš mít situaci kolem našeho tématu promyšlenou když do toho mícháš další věci?
Dále jako jediný protiargument bereš to že zasahuje mnoho, resp. až moc, oblastí okolo, v druhé píspěvku ale zase že ti spíš vadí že je to monolit, což jsou neosouvislé věci a u systemd to ani neplatí, není to monolit, jenom zasáhl jako monolit ... jak říkám, chce to domyslet ...
Kentan, hovoril som o drvivej väčšine, nie o všetkých, ale to nie je to podstatne. Podstatné v tom pôvodnom príspevku bolo to, že dookola sa tu stále opakujú tie isté argumenty o tom ako niekomu niečo roky rokúce fungovalo a ako mu to zlý zlý Lennart so svojim systemd rozbil.
Ja chápem, že je to k vzteku, prerábať niečo, čo funguje, kvôli zmene, o ktorej prínose nie ste zrovna úplne presvedčení, avšak systemd presvedčil väčšinu ľudí, ktorí o tom rozhodujú (a narozdiel od Vás, si nemyslím, že ich všetkých oblafol, ožral, zdrogoval, pretiahol,...).
Z môjho pohľadu robí systemd presne to, čo má (ok, možno trocha viac) a robí to IMHO výrazne lepšie než doteraz používané init systémy, takže ako protiargumenty by som skôr čakal konkrétne príklady toho, čo sa cez systemd nedá urobiť vôbec, alebo sa to robí výrazne horšie ako doteraz.
Ale uznávam, že som to mohol povedať aj menej, expresívne...
Snáď sa mi to podarilo zhrnúť bez zbytočných odbočiek.
@dizzy zatimco lidi co "nadavaji" na systemd uvadi priklady z praxe, ty jako "obhajovac" pises(v principu) "kdyz to vsichni prevzali tak to preci musi byt bezva" to mi rekni kdo je vetsi slepej bojovnik ;-)
ze im cosi kdesi funguje, su na to zvyknuti a sprosty systemd im to rozbil.
tak bylo by seriozni kdyby nemenil urcite chovani co vede ke ztrate, napr co sem uvedl jinde:
https://www.root.cz/clanky/predvidatelne-pojmenovani-sitovych-karet-v-linuxu-kam-se-podelo-eth0/nazory/994017/
radeji nepremyslet co vse systemd sezral, tady (rok 2013) je toho uz tak dost...
https://www.youtube.com/watch?v=bdmv2FQRHWg
@k3dAR
"kdyz to vsichni prevzali tak to preci musi byt bezva" to mi rekni kdo je vetsi slepej bojovnik ;-)
- alebo, žerte hovná, miliardy múch sa predsa nemôžu mýliť ;-) Ale teraz vážne - áno, myslím si, že je to silný argument - to, že to prevzali všetky major distribúcie o niečom svedčí (aj keď uznávam, že tie posledné už asi moc na výber nemali). Ale samozrejme môžem tu začať menovať konkrétne dôvody, prečo si myslím, že je systemd lepší ako "tradičné" riešenia...
- čo sa týka tvojho problému - je to nová vlastnosť, ktorá mala byť riadne zdokumentovaná a mala by byť defaultne zapnutá skôr pri nejakom security profile (myslím ten kill). Systemd to mal zdokumentovať, na úrovni distribúcie sa to malo pri normálnom desktope vypnúť (mať bezpečnejšiu voľbu ako default je momentalne totiž trendy, viď selinux ;-))
- čo sa týka mountovania, pokiaľ sú všetky disky, potrebné na beh systému dostupné, systém by mal určite nabehnúť, o tom žiadna, tu skôr ale mám väčší problém s tým, že nenabehol, než s tým je niekde nejaký default (až sa mi nechce veriť, ale som lenivý to skúšať)
Áno, žiaľ aj v systemd sú bugy, uznávam (dostali ste ma ;-)). Treba žiaľ hľadať také nastavenia, pri ktorých sa buď workaround - ne, prip. začne chovať presne podľa Vašich predstáv a to sa zatiaľ v oboch spomínaných prípadoch dá. Aj keď je to možno vopruz, nie je to showstopper. Holt zakaždým, keď sa migruje na nový systém, je s tým spojená určitá pracnosť a nie je reálne očakávať, že Vaše nastavenia /skripty budú fungovať večne :-(
Tiež nie som nadšený z toho, že už takmer všetko má závislosti na systemd, ale vnímam to ako cenu za vylepšenia, ktoré sú podľa mňa dosť podstatné, či Vy ste si skutočne nič, okrem problémov nevšimli?
@dizzy
čo sa týka mountovania, pokiaľ sú všetky disky, potrebné na beh systému dostupné, systém by mal určite nabehnúť, o tom žiadna, tu skôr ale mám väčší problém s tým, že nenabehol, než s tým je niekde nejaký default (až sa mi nechce veriť, ale som lenivý to skúšať)
mas to treba tady: https://www.freedesktop.org/software/systemd/man/systemd.mount.html
nofail
With nofail, this mount will be only wanted, not required, by local-fs.target or remote-fs.target. This means that the boot will continue even if this mount point is not mounted successfully.
jiste ze kdyz by nekdo cetl dokumentaci, manual nebo mailing list, tak na to narazi, prida nepotrebnym zaznamum v fstab nofail a ma hotovo, nicmene princip problemu je v tom, ze drive bylo nofail vychozi, ted ne, takze spousta lidi na tuto "vlastnost" prisla kdyz restartovala vzdaleny pocitac ktery jiz nenabehl i kdyz systemove oddily se pripojili ok, takze museli sednout do auta, dojet k serveru, dat pokracovat ve startu, pridat nofail...
pro uplnost, k nofail je potreba pridat jeste x-systemd.device-timeout=3, protoze samotne nofail nezajisti aby systemd zbytecne necekal 90vterin pro kazde zarizeni co mu nejde pripojit a zaroven samotne x-systemd.device-timeout=3 nezajisti aby se nezastavilo bootovani skocenim do "zachraneho" (bez SSH) rezimu...
Protoze system kde "0day" user dostane prava roota a zavreme to jako not-a-bug a nebudeme resit je to nejlepsi pro produkci.
Ve velkych firmach se zasadne vybira to za co dostane zjebano NEKDO JINY pokud se to posere, tam systemd nikdo neresi a proto si tam muze lennart lestit svoje ego a pridelavat praci vsem okolo.
Kdyby někdo náhodou netušil, o čem se mluví, tak odkaz na frikulínského blba v akci zde: https://github.com/systemd/systemd/issues/6237
A jak dlouho se tim (davno opravenym) CVE-2017-1000082 budou lidi jeste ohanet? :-) Takovych problemu bylo, je a jeste bude... staci se podivat na takove CVE-2018-10938 v kernelu, ktere sice bylo opravene pres rok, ale nejakym "nedopatrenim" se to jaksi pozapomelo backportovat do stabilnich verzi kernelu. Proste ten patch nekdo chybne klasifikoval :-) Chybuje nejen Poettering... a mnou odkazovane letosni CVE byl ve vysledku ponekud vetsi pruser...
A jak dlouho se tim (davno opravenym) CVE-2017-1000082 budou lidi jeste ohanet? :-)
Asi do té doby, dokud bude LP k chybám ve svém produktu přistupovat jako úplný kokot. Protože přístup "když je něco nevalidní, tak to pustím jako root a nějak to dopadne" hraničí se zbavením svéprávnosti. Nota bene, když si vzpomenu, že na druhou stranu byl ten samý jedinec schopný prostě totálně rozbít boot jen proto, páč se mu např. nelíbilo, že /etc/mtab je soubor a ne symlink. Ten člověk je obecně nebezpečný psychopat.
On je ale jenom programator. Jsou cinnosti, ktere by mel vykonavat nekdo jiny - vyvoj obecne neni jen o jednom cloveku, tech roli je vic a je potreba je oddelovat (bohuzel u opensource se to ne vzdy dari - ale to je chyba systemova, nikoliv chyba toho dotycneho). Nicmene ten argumenty ad reakce kolem CVE-2017-1000082 jde pouzit i obracene - pokud je admin takovy jelito, ze udela ve svym konfigu unity preklep, pusti to a necha bez kontroly (treba i toho, ze mu to bezi pod spravnym UID) bezet, tak jde na dotycneho admina pouzit podobne expresivnich vyrazu... a rootovsky prava mu do rukou nepatri zrovnatak.
Nikdo vas ho pouzivat nenuti. Cest je vzdycky vice... napriklad http://www.linuxfromscratch.org/lfs/ :-)
Tak ono je ve vysledku vcelku fuk, zda se vyvojar vykrucuje... nebo opravu zatluce takovym zpusobem, ze nikdo z toho nepozna, ze jde o opravu bezpecnostni diry (jako v pripade tech CIPSO zneuzitelnych i vzdalene). Rozhodne nejde nadavat jen jednomu clovekovi - chybuje kdekdo.
U toho systemd to "pusteni pod rootem" bylo ve vysledku jen nespravne osetreni chyby v konfiguracnim souboru (ktery ale upravuje zas jen root a reportujici osoba na to prisla asi diky vlastnimu preklepu v unit configu; rozhodne bych to nenazyval nejakym 0day exploitem snadno zneuzitelnym nekym z ulice). Bug byl nahlasen 29.cervna 2017, po velkem humbuku je tomu 6.cervence formalne prirazeno CVE a 12.cervence 2017 vychazi nova verze systemd, kde uz ten problem neni - je opraven. Ale najdou se jedinci, co to budou vytahovat jeste po vic jak roce od incidentu - i kdyz to bylo vyresene behem ani ne 14 dni...
Ale přece ty lidi to nevytahujou proto, že tam byla nějaká chyba (mraky chyb jsou všude), ale jako ilustraci přístupu LP k návrhu softwaru a řešení problémů. Dotyčný si ještě asi za těch mnoho let neuvědomil, že už si nehraje se zvukovým systémem, který, když se rozbije, tak se stane v zásadě velké lejno. :-(
Jenomze takhle reaguje kdejaky softwarovy vyvojar. Jenom kolem LP se dela takovy humbuk. Jak uz jsem psal vyse - navrh softwaru je pomerne komplexni zalezitost, nemuze se to hazet na hlavu jedne jedine osoby - a pokud se tak deje, tak jde v prvni rade o systemove selhani v obecne rovine, protoze se nikdo neobtezoval jednotlive role spojene s vyvojem jakkoliv oddelit. Programator je uz jen ta lopata, ktera ma neco delat na zaklade externich vstupu (aka nejaka analyza, specifikace atd). Jiste, setri se na ruznych mistech a na ruznych mistech, kde se neco vyviji je i analytyk povazovany za zbytecnost, zeano...
Jenom kolem LP se dela takovy humbuk.
Nesmysl. Humbuk se dělá kolem každého na podobné pozici, když se jako začne chovat jako úplný tydýt, namátkou mě napadá např. DJB, Jörg Schilling... a ostatně u RedHatu už by mohli mít s těmito duševně vyšinutými jedinci taky zkušenost a podle toho se zachovat, viz https://bugzilla.redhat.com/show_bug.cgi?id=119185 (s tím rozdílem, že dotyčného onehdá aspoň vyrazili, ale tady tedy žádné řešení v dohledu nevidím.)
Ona je ta debata stejně zbytečná, v RedHatu mají zjevně mnohem důležitější starosti než to, že tady nějaký blázen zcela nekontrolovaně rozbíjí linuxový init... viz zde.
Tak jeste jednou. Jakmile cokoliv stoji na jednom jedinem cloveku, tak je to spatne - systemove. Kdyz se nekdo chova jako tydyt, ma byt v jeho teamu nekdo, kdo to nejak koriguje. A je vtipne, ze vic energie lidi venuji tomu, aby nadavali na cloveka - misto toho, aby se snazili nejak zmenit ten system ;-) U opensource si lidi hodne zvykli na to, ze jeden clovek dela vsechno... ale ono delat pod tlakem spousty lidi kolem, co akorat na vsecko nadavaji taky nebude zadny med - a svoje stopy to zanecha. Hodnoceni dusevniho zdravi prosim prenechme povolanejsim odbornikum - to sem skutecne nepatri ani okrajove, zvlast kdyz tato hodnoceni padaji z ust zjevnych laiku v oboru psychologie. Nejsme v hospode u piva.
Snazit se zmenit system? Kdyz se podivame na priklade v tomhle vlakne, tak za vetsinu pruseru v linuxu ecosystemu vetsinou muze nejaky arogantni kokot v Red Hatu, ktery si muze delat co chce.
Realne to teda znamena informovat kolik Red Hat napachal skody a tlacit na nase zamestnavatele aby Red Hat prestali pouzivat.
A kdyz uz jsme u toho tak si tim i firmy dost pomuze, ze prestanou RHEL pouzivat, napr. ted ve stale podporovanem RHEL6 jsou *zname* code execution vulnerabilities s trivialnim exploity a pristup Red Hatu je *will not fix*.
https://access.redhat.com/security/cve/cve-2018-16509
Skvely, jak si je Red Hat vedom, ze jsou zakaznici totalne v prdeli a kasle na to - viz sekce Mitigation
"Additionally, this issue can be triggered when processing files in order to generate thumbnails, for example when browsing a folder containing a malicious PostScript file in Nautilus. To prevent this, remove or rename the "/usr/bin/evince-thumbnailer" executable."
A ano RHEL6 na desktopu v mnoha korporacich stale bezi.
A co se tyka nadavani na Canonical, tak o to se nam stara jeden znamy troll ucet "alex285" (za kterym imo stoji nekdo z Red Hatu) a nadavky jsou ve stylu "Ubuntu si dovoluje pouzivat vlastni gtk tema a nepouzivaji adwaita, c*raci jedni!".
Nedelam si srandu:
https://medium.com/@alex285/how-ubuntu-damages-gnome-just-with-a-theme-d6fb257e266
Demokraticke hlasovani uvnitr nekterych distribuci nemusi vzdy znamenat dobrovolnost a uz vubec ne to, ze vysledek bude povedeny. V jinem svem prispevku zde v diskuzi pisu o 2 ruznych vecech, ktere (mate pravdu) zaroven prcam. A to obe dve. Jednou z veci je vec jmenem Lennart a druhou veci jsou zblbli tvurci distribuci, kteri bud diky demokracii, nebo vlastnimu rozhodnuti skocili veci jmenem Lennart na spek. Navic s vysledkem obvykle znacne polarizace drive docela v pohode komunity. Nastesti napriklad u debianu existuje reseni, kterym se da systemd celkem schopne odstranit a vse funguje jako drive. Jeste ze tak.
Tak zrovna v pripade debianu to fakt dobrovolne nebylo, nakonec odesel kvuli tomu z vedeni debianu autor noveho dpkg atd.
Maintainer systemd v debianu, ktery ho tezce tlacil, ted dela v Red Hatu.
https://wiki.debian.org/Debate/initsystem/systemd je plny lzi - moje nejoblibenejsi "Using systemd helps mitigating or eliminating other security issues, by bringing new security features to all daemons running on the system. Switching to systemd is a security improvement for the whole system" a pritom stacilo vytvorit uzivatele "0day" a mas roota a to zavreme jako not-a-bug
Btw, koukal jsem se na GitHub, kolik toho Lennart v tom zdrojáku "zprasil" a jak se do toho zapojil. Takže v produkčním kódu udev-builtin-net_id.c je to asi takhle:
852 LOC celkem, 21 LOC (2,46%) od Lennarta, z toho
- 1x prázdný řádek,
- 4x komentář
- 2x include jinýho souboru
- 1x direktiva #pragma
Poslední Lennartův commit se týká znaku pro copyright v hlavičce:
"Let's unify an beautify our remaining copyright statements, with a unicode . This means our copyright statements are now always formatted the same way. Yay."
A jenom tak mimochodem, ten soubor založil Kay Sievers, ne Lennart "Univerzální Viník" Poettering...
O to hůř, např. klasika http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01331.html