Debian: Rezignace Tollefa Fog Heena (diskuse)

[Ovoce]

If you do genuinely disagree with somebody (something which is entirely fine), try not to escalate, even if the stakes are high. Examples from the last year include talking about this as a war and talking about "increasingly bitter rear-guard battles". By using and accepting this terminology, we, as a project, poison ourselves. Sam Hartman puts this better than me:

I'm hoping that we can all take a few minutes to gain empathy for those who disagree with us. Then I'm hoping we can use that understanding to reassure them that they are valued and respected and their concerns considered even when we end up strongly disagreeing with them or valuing different things.

I'd be lying if I said I didn't ever feel the urge to demonise my opponents in discussions. That they're worse, as people, than I am. However, it is imperative to never give in to this, since doing that will diminish us as humans and make the entire project poorer. Civil disagreements with reasonable discussions lead to better technical outcomes, happier humans and a healthier projects.

Tohle se mi v tom textu líbilo.

[Ovoce]

Sakra, zapomněl jsem na ten (podstatnej) předchozí odstavec:

Our code of conduct says, "assume good faith". If you ever find yourself not doing that, step back, breathe. See if there's a reasonable explanation for why somebody is saying something or behaving in a way that doesn't make sense to you. It might be as simple as your native tongue being English and their being something else.

[little.owl]

Je toho vice: rezignoval i Russ Allbery na svou funkci v Debian TC, viz zde.

[Ladislav Hagara]

Dík, doplněno do zprávičky.

[ewew]

Vyzerá to tak,že loď sa začala potápať. A ako bonus dostala závažie vo forme systemd.

Potom ako sa loď potopí, začnú určité osoby oslavovať, že padol ďalší zastaralý projekt.

[egg]

Potápí == nabírá jiný směr, než by se mi líbilo?

[qorin]

Konečně nastane éra Ubuntu nezkažená Debianem

[pavele]

Že by Ubuntu založili v budoucnu na Gentoo?

[mankind_boost]

Cože?

[qorin]

Tak to snad není tajemství, že se Debian přiživuje na slávě Ubuntu. Už mu zbyl jen server, kam se Ubuntu ještě moc nesnažilo dostat, ale to přijde

[Šangala]

Obráceně to mělo bejt…

[qorin]

To bylo zpočátku, to mu nikdo neupírá

[Šangala]

Aha, nevěděl jsem, že se Debian začal dělat z Bubuntu.

[qorin]

To jsi nevěděl dobře, tak to nebylo.

[Šangala]

Takže jsi si to ujasnil - bezva.

[qorin]

Jasně, aniž bych na cokoliv změnil názor, to je nějaký zázrak asi Prostě jsi to napoprvé nepochopil, nic se neděje.

[mankind_boost]

Máš v tom nějakej zmatek... Opravdu víš, co je to Debian a Ubuntu?

[Andrej]

Jako by snad Ubuntu nebylo mnohem zkaženější než Debian…

[languageless]

pro ty kdo to jeste nezna:

xlennart - save your computers from SystenD [TM] virus

http://www.bloodbathsoftworks.com/xylemon/xlennart.php

[quā quā]

Chtělo by to xlennart procpat do repositářů Debianu

[pavlix]

Nechtěl by mi někdo vysvětlit, co se v tom Debianu děje?

[Šangala]

U mě zatím dobrý.

[Lol Phirae]

Asi mají Borgové drobný problém s asimilací...

[pavlix]

Asi jsi nepochopil otázku, ptal jsem se na Debian.

[jirka]

proste rozmrdavka pomoci systemd ne a ne projit, hladce...

[pavlix]

Už jednou jsem psal, že jsem se ptal na Debian.

[Lol Phirae]

Asi jsi nepochopil otázku

... asi jsi nepochopil odpověď

[Petr Ježek]

Odpovědět způsobem, který dává vinu za všechny problémy organismu externí vakcíně, znamená shledat organismus slabý a neživotaschopný s poškozenou imunitou a autoreparací. Debianí vývojáři se musí zamyslet, zda jim jde o Debian jako takový nebo o moderní systémovou (system-wide) optimalizaci init subystému. Takže nepochopení otázky plodí absurdní a sebedestruktivní odpovědi...

[Lol Phirae]

Kristepane, další výplach mozku systemd propagandou. Hele, vy máte s Kufnerem (Java) nějaký watchdog na klíčová slova (systemd, java) v diskusích?

[mankind_boost]

"moderní systémovou (system-wide) optimalizaci init subystému."
Úplně stejný styl vyjadřování jako Lennart.

[Pev]

"moderní systémovou (system-wide) optimalizaci init subystému."
Úplně stejný styl vyjadřování jako Lennart.

Můj první komentář k systemd flame. Považoval jsem systemd za nutné zlo ve světě desktopu; pokrok, kterému se prostě nevyhneme (jako u spousty jiných technologií typu PulseAudio). Minulý týden jsem byl na konferenci elektronica. Jaké překvapení, když mi borci z Pengutronixu popisovali výhody nasazení systemd na embedded Linuxu (a rozhodně nebyla největší výhodou rychlost bootu). Považovali systemd za suvereně nejlepší init system (pro desktop, server i embedded). Třešničkou na dortu bylo fungující cryptsetup (viz. bug #618862).

[pavlix]

On ten celý flame je v první řadě o lidech, software v něm hraje druhotnou roli.

[trekker.dk]

Hm, nutné zlo ve světě desktopu a úplně nejlepčejší init systém pro hračky embedded zařízení... uvědomujete si, že Debian vždy byla distribuce pro servery?

[mankind_boost]

Trefné.

[JoHnY3]

Mam z toho takovej dojem, ze (stupidni) nevrazivost zastancu obou stran reseni init systemu dostala celou radu lidi v komunite do stavu kdy se zeptali sami sebe proc delaji co delaji a jestli je to jeste bavi. Odpoved je zjevna.

Vnitrni taje Debian komunity neznam a taky by me zajimalo co se vlastne stalo.

[pavlix]

První netroll, máš u mě pivo. Osobně nechápu, že se taková věc děje u takového dlouhodobě stabilního a řekl bych váženého projektu jako je Debian.

[jirka]

vec se deje, protoze se, celkem pravem, nekteri z debianu ptaji, kde je volba ? Debian neni military-industrial-corp ala RH. Zatimco odpurci systemd trvaji na zachovani volby - vcetne moznosti tu sragoru provozovat, zastanci se jim volbu snazi vzit.

A celkem logicky, vyvojari a jini se ptaji, mam to zapotrebi ? Bohuzel se tak v posledni dobe pta i spousta kdysi skalnich priznivcu linuxu...

[little.owl]

Ne, to neni pravda, oni neodmitaji podporu dalsich initu. Pokud ale nekdo chce podporu jinych init systemu, musi na teto podpore sam pracovat a ne operovat s predstavou, ze k tomu muze primo i neprimo nutit neplacene maintainery systemd.

[Bubak]

No to je mi nejaka divna logika - chtit po maintainerovi nejakeho baliku, kdyz neco cpe do systemu, aby nerozbijel zbytek systemu pro ostatni, je spatne?

[Rezza]

a) obcas je ta zmena tak velka, ze je potreba trosku tou sekerou utnout neco jineho... b) ale to neznamena, ze nekdo nemuze pak vstoupit a udrzovat alternativu, ale uz s jistyma omezenima

[Ovoce]

S touhle logikou by musel kdokoli, kdo nahradí nějakou komponentu nebo blík jinou alternativou, pak navěky udržovat tu starou. N2kdy to možná dává smysl, ale automaticky bych to nevyžadoval, pokud už bylo "vějš" rozhodnuto, že ta komponenta bude nahrazena.

[little.owl]

Zajistit rozumny prechod pro uzivatele ano, trvale udrzovat predchozi verzi ne - to pak musi delat nekdo jiny - kdo ji chce. Maintaineri jsou vesmes dobrovolnici a tezko jim nekdo bude diktovat, co maji delat ve svem volnem case - a to vcetne TC.

[Grunt]

Maintaineri jsou vesmes dobrovolnici a tezko jim nekdo bude diktovat, co maji delat ve svem volnem case - a to vcetne TC.

Popravdě by zajímalo co to vlastně v té Debianí TC dělají. Protože podle popisu to zní jako že tam przní malé koťátka. Obě rezignace jsem si pečlivě pročetl a takhle nějak píše rezignaci voják co přežil termonukleární konflikt (samozřejmě jde o nadsázku). Docela drsné na to že jde o dobrovolnický projekt.

[Lol Phirae]

Obě rezignace jsem si pečlivě pročetl a takhle nějak píše rezignaci voják co přežil termonukleární konflikt

No, já se nedivím. Viz např. kruciální diskuse o tom, které menu je to správné (467 komentářů) a následný TC sequel (450 komentářů), přičemž se ve finále rozhodlo hovno.

[Grunt]

No o to mi až tak nejde. Jde o to že v tomhle případě nikdo nikoho do ničeho nenutí (žádná vyšší hodnost, nadřízený, peníze, prostě cokoliv) a v první řadě jde opravdu o to že člověk v této pozici dělá to co dělá, protože ho to baví. Výsledek dopadu na jedince? Snad ještě horší Minimálně podle toho jak čtu finální slova, mi to tak připadá.

[Lol Phirae]

"Researchers estimate that 5-10 percent of the U.S. population engages in sadomasochism for sexual pleasure on at least an occasional basis" (June M. Reinisch, Ph.D. with Ruth Beasley, M.L.S (1990). Kinsey Institute New Report on Sex, St. Martin's Press: pg. 162-163.)

[Grunt]

Asi jo. Jinak si to vysvětlit nedovedu…

[pavlix]

vec se deje, protoze se, celkem pravem, nekteri z debianu ptaji, kde je volba

To je jistě vcelku logické, ale neříká to nic o tom, kam se ztratila tradice Debianu a proč všem z ničeho nic hrabe.

[Petr Ježek]

Debian je "geneticky" tradicionalistické a konervativně vyvíjené distro, tak jej profiloval dosavadní vývoj a lidé, kteří jej táhli. Kdyby se situace s rozvojem HW i SW Debianu nedotkla, rychle by zastaral a nemohl by fungovat jako podvozek pro řadu nad ním sestavených distribucí. Primitivní init subsystémy historicky nebyly tvořeny pro současné složité systémové podmínky. Pro Debian (nejen pro něj) to znamenalo buď zůstat jednoduchým a současně rezignujícícm na možnost rozsáhlejších provázaných instalací nebo se modernizovat tam, kde je to nejdůležitější - v oblasti init subsystému. LP byl jediný, kdo měl odvahu se pustit do komplexního redesignu init subsystému včetně nezbytných (dnes i v očekávané blíké budoucnosti) systémových návazností. Můžeme na něj nadávat, můžeme kritizovat systemd jako init i jako širší systémovou komponentu, ale dokud nevymyslíme jako náhradu nesystémových historických initů vlastním lepším řešením než je to od LP, musíme se smířit s tím jeho, plně jej pochopit a pokusit se je redesignovat nebo alespoň implementovat námi požadovaným způsobem. Proto i mně je velmi líto debianí komunity, která prokazuje mizernou adaptabilitu a znalosti, jež k ní nezbytně vedou. V komunitě Archu se také hodně debatovalo, ale poměrně rychle převládl názor, že "bleeding edge" distro nelze udržitelně stavět na zastaralém initu. Arch není Debian, ale kultivovanost debat v komunitě Archu je na nesrovnatelně vyšší úrovni. Spory založené na nepochopení situace a lpění na tradičních postupech svědčí o neživotaschopnosti takové komunity.

[Lol Phirae]

Primitivní init subsystémy historicky nebyly tvořeny pro současné složité systémové podmínky

Bože... čo si predstavujete pod takým pojmom "současné složité systémové podmínky", Kefalín? A jistě, normální init nebyl tvořen s tím, že bude dělat DNS resolver, srát se podsvícení displeje, zapínání a vypínání wifi, do šifrování disků, synchronizace systémového času nebo třeba implementovat vlastní konzoli. To nemá nic společného s primitivností, zato mnoho se zdravým rozumem.

[mankind_boost]

Toto systemd fanboys raději ignorují. Předpokládám, že nedostaneš žádnou odpověď.

[pavlix]

Nebuď hned tak zlý, třeba Petr odpoví.

[trekker.dk]

Dva dny a nic... ó, jaké překvapení

[Ovoce]

Ty kráso, kolem SystemD už je snad na fórech hustější řež než mezi jabkařema a androidistama :)

[pavlix]

Mezi jabkaři a androidisty bych si aspoň našel stranu :D.

[little.owl]

Tak systemd neni jiz jen init, je to framework.

[mankind_boost]

*operační systém

[biolog]

Ya dawg, we put an OS into your OS... (sorry, nemohl jsem si to odpustit)

Když GNOME Project před dávnými lety obsahoval jen správce oken a správce souborů a pak přidali kalkulačku, stal se projekt složitějším? Ty funkce, co zmiňuje Petr Ježek, se staly součástí projektu systemd, ne součástí procesu s PID 1.

[little.owl]

Nesmysl.

[Ivan]

Proboha co je to za kecy? (Sry ale tohle se neda napsat jinak). Co jsou to ty slozite systemove podminky? Zatim jsem nezazil situaci kde by nestacil klasicky BSD init. Vzdyt dneska stejne bezi na kazdem Unix serveru jen jedna hlavni aplikace. Kdo dneska provozuje web, dns db popr. ftp na stejnem serveru?

A kdyz opravdu nekdo potrebuje neco sloziteho, tak pouzije HACMP, VCS anebo RAC. Proste neco co ma vlastnosti init systemu, plus to umi neco navic a HLAVNE, bezi to na vice serverech najednou.

[sid]

Povedal by som, ze momentalne kazde rozhodnutie z jednej ci druhej strany ohladom systemd vedie k hysterickym utokom a totalne zbytocnemu sumu. Byt vyvojarom a musiet stale registrovat utoky od ludi ktorych schopnosti koncia a zacinaju u bashu tak tiez si po 20 flame poviem ci to ma vyznam.

[pavele]

Je dobře, že se to děje, že dosud existuje tak silná odezva. Je ovšem možné vyhovět oběma stranám a začalo se na tom pracovat - ovšem nevím, v jakém stavu je to nyní (systemv-shim?).

[biolog]

Bylo by to dobře, pokud by ta silná odezva byla od vývojářů nebo obdobně kvalifikovaných lidí. Jenže uživatel sid říká, že ti hulákající jimi nejsou (samozřejmě jsou výjimky).

Možná říkáte, že je to dobře, ve smyslu "když Technical Committee rozhodla pro systemd, tak aspoň ti hysterici jsou na mé straně". Ale ten názor není univerzálně sdílený.

[little.owl]

V podstate maintaineri systemd celi uz pomerne dlouho utokum nekterych jedincum se sociopatickym chovani, ktere jiz zacaly prerustat od standardniho flamu a zneuzivani bugzilly do roviny vyhrozovani a demonizace, a pro nektere lidi bylo posledni kapkou byrokraticke zneuziti TC.

[x]

Ted to znelo uplne jako od Microsoftu, teda pardon RedHat......nebo sakrys nezni to od obou nejak stejne posledni dobou? :D My jim prece nutime neco tak dokonaleho podle nasich predstav, cpeme to kde se da a delame na tom zavisle kdeco a jim se to nelibi a prudi s nejakou blbou Unix filozofii a podobnyma nesmyslama.

Krasne to pripomina:

This isn’t even the first time I’ve heard about runtime code patching in the Linux kernel. The e1000e bricking bug has that honor. I’m going to check the box next to “we are not smart enough to use features like this correctly”. We do not need to develop software with a we can do this; therefore we must do this mentality.

specialne teda veta - We do not need to develop software with a we can do this; therefore we must do this mentality.

Je dobre, ze vyvojari i uzivatele toho zacinaji mit dost a davaji to cim dal vice najevo, protoze Linux tohle potrebuje aby si uvedomil proc a za jake situace vznikl a proc mel zpocatku takovy uspech.

Debian, Debian fork, Slackware odolavajici, Gentoo preslapujici, Alan Cox a jeho pekny prvni odstavec , proc se vyhybat cemukoliv z US (odkud ze to je RH?, systemd je presne takovy uzasny moloch do ktereho pujde nacpat kdejaka zhovadilost tak jako do OpenSSL, protoze to je tak otresne, ze to nikdo nechce do detailu ani zkoumat )nebo tady posledni odstavec , dalsi dobry duvod proc se vyhybat vecem z US, opet na lwn.net nebo kam to az Linux dopracoval nebo lepe receno zarizl s podporou RealTime prave diky komercnim firmam, opet z lwn.net , Andrew S. Tanenbaum a jeho aktualni pohled atd. atd. atd. Deje se toho hodne a je to jen dobre. Cistka poradna je potrebna v mnoha oblastech, protoze uz to hnilo a smrdelo dostatecne dlouho a Linux nevznikl proto aby zahnival nekde pod diktatem jakekoliv firmy (i takove, ktera se tvari jako open source zachrance).

[Ovoce]

Teda, ne že bych si myslel, že chápu, o co v tom postu šlo. Ale fakt myslíte, že ten Fuzix k něčemu je? *Zilog Z80*

Jinak IMHO bla-bla, škaredý klerofašistožidobolševikozednáři z USA bla bla.

[xzz]

v tom svym nicku sis asi omylem napsal o jedno 'o' vic, co?

[sid]

uzasne na tom je hlavne to, co si Linus mysli obecne o Unix filozofi co je pre miestnych znalcov nieco ako nabozenstvo ktore vytahuju pri kazdej druhej diskuzii. There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at *some* level, but I think it's also clear that it doesn't really describe most of reality.

[Petr Ježek]

A proto je poměrně náročné nahradit Linuse někým jiným. Přeci jen je znalých, tvořivých a neomezených lidí omezené množství... Kdyby všechna energie věnovaná ostřelování systemd pod falešnou vlajkou byla soustředěna na vylepšení systemd nebo na vývoj lepšího alternativního "komplexního initu", neměl bych o Debian, natož o GNU/Linux žádné obavy...

[pavlix]

neměl bych o Debian, natož o GNU/Linux žádné obavy...

Máš namysli systemd/linux, ne?

[kolcon]

...zatimco jini by to nejradsi rozm*dali a pritom nemaji zivotaschopnou alternativu...

[pavlix]

Deje se toho hodne a je to jen dobre.

S tím naprosto souhlasím.

[Aleš Kapica]

Debian fork

Hm. Prima. Ale alternativní pool by do toho vnesl trochu víc než pouhý manifest hodný Karla Marxe.

[Petr Ježek]

Přesně tak. Zdá se pouze mně, že příliš mnoho "profesionálů" a "administrátorů" prokazuje nule blízkou adaptabilitu na změnu vnějších podmínek (ostatně co jiného než změnu podmínek čekat za období 40 let UNIXu) a neschopnost přizpůsobit paradigma realitě? Vypadá to, že koromě Linuse to chápe jen málo tahounů vývoje GNU/Linuxu a distribucí.

[Lol Phirae]

nule blízkou adaptabilitu ... neschopnost přizpůsobit paradigma realitě

"Vybral jsem namátkou jednu větu a velice pozorně ji čtu. Nepamatuju si ji doslova, ale víceméně zněla takhle: „Individuální člen sociální komunity často získává informace prostřednictvím vizuálních symbolických kanálů." Četl jsem si to pořád dokola a přeložil to. Víte, co to znamená? „Lidi čtou." Pak jsem přešel k další větě a zjistil, že ji dokážu přeložit taky. Pak už to bylo jako mlácení prázdné slámy: „Občas lidi čtou; občas poslouchají rádio," a tak dále, ale bylo to napsáno tak komplikovaně, že jsem tomu zpočátku nemohl porozumět; a když jsem to konečně dešifroval, nic v tom nebylo." (Richard P. Feynman, To nemyslíte vážně, pane Feynmane!)

[pavel]

+1

[Jindřich Makovička]

Holt nechtěl na plné pecky napsat "někteří administrátoři jsou tvrdohlaví pitomci."

[trekker.dk]

Kde definice tvrdohlavého pitomce je "nelíbí se mu, že se zbytečně a bez možnosti volby rozesírají věci"

[2012]

[Rezza]

Po ranu se ma clovek zasmat :).

[little.owl]

To je vsechno neco jineho, nez se navazet do vyvojaru. Jeden z lidi, ktery stoural do Heena, byl Thorsten Glaser. Mohl byste ho znat, nebot ho de Raadt dostal z OpenBSD a on to potom forknul a zalozil MirOS BSD.

[x]

Ale ja nepsal nic o xBSD, ktere je v teto situaci pomerne bezpredmetne. Ja poukazuju na to co se na ruznych frontach Linuxu deje, ze za tim jsou realne duvody/problemy a ze zasadni zmena je nutna, ale bude tezko zkousnutelna pro spousti lidi.

Vyhrozovani vyvojarum nepatri do zadneho OS a nesouhlasim s tim a maji tak plne pravo rict "polibte mi sos a vyvijejte si to sami". O tom tady nedebatujeme prece. To co se deje okolo systemd a dalsich veci je systemova chyba, kterou; i kdyby se systemd prepsalo do cisteho ASCII a zacalo pouzivat Unix filozii; to nevyresi.

[Foo Bar]

Lidi stárnou, zakládají rodinu, mají děti, a prostě vidí, že jim to prostě za to nestojí věnovat tolik úsilí do práce, kterou pak ostatní podkopávají (můj osobní pocit je, že Russ nevydýchal Ianovo GR, což mimo jiné spustilo nový flame, který je ještě o něco žhavější než ten posledně). Nic nenormálního, ono se to zase uklepe až vyjde jessie a lidi začnou upgradovat.

S Tollefem jsem se teď dva týdny zpátky viděl na večeři a připadal mi, že je docela v pohodě. DSA funkci nesložil.

[Petr Ježek]

Co se těchto lidí týče, tak nepochybně ano. Problém ale působízdánlivě "ideový" střet tradicionalistů s mladými progresivisty nastupujícími na místa po Vámi zmíněných.

[pavlix]

Obávám se, že právě lidi, kteří ze všeho dělají fatální ideový střed, projektům nejvíce ubližují.

[sid]

suhlas, navyse casto mam dojem, ze najvacsi "bojovnici" v tychto vojnach povacsine zostanu iba pri tom pisani do mailing listu.

[pavlix]

*střet

[Foo Bar]

Řeknu Vám to takto - největší prudiči v d-private listu jsou lidi, o kterých jsem v životě neslyšel (tj. buď nemají žádný zajímavý balík, nebo jsou již několik let MIA).

[pavel]

Před 3 měsíci:

Takže po mohutných deklaracích o tom, jak bude GR, se nic nestalo, protože to nikomu nestálo ani za to, aby sepsal návrh "general resolution", natož aby ta GR měla nějaké podporovatele (seconders). Tak nějak hádám, že se Ian uklidnil a reflektoval, že jeho reakce byla více založená na aktuálních emocích než na racionální proceduře.

Hmm...

Dnes:

můj osobní pocit je, že Russ nevydýchal Ianovo GR, což mimo jiné spustilo nový flame, který je ještě o něco žhavější než ten posledně). Nic nenormálního, ono se to zase uklepe až vyjde jessie a lidi začnou upgradovat.

Hmm...
Jinak zajímavý obrat "uklepe", který leccos vypovídá.

[pavel]

s/Před 3 měsíci/Před dvěma měsíci/
link

[Foo Bar]

Tak jsem se s Ianem pletl, jsem pořád ještě idealista.

Jinak nerozumím tomu, co se ve zbytku příspěvku snažíte říct.

[Foo Bar]

Výsledek GR odpovídá tak nějak tomu, co jsem říkal. Ono se to uklepe...

[Šangala]

Tak znovu a lépe, moje hodnocení situace je:

Někteří lidi jsou unavení a chtějí dělat svou práci, místo dohadů s mladšími a chytřejšími (trocha zjednodušení), co chtějí objevovat objevené nebo řešit jednoduché věci složitě (prostě něco víc než postupný vývoj). A holt pouštět do kolejí Debian-u, „nový vítr“ musí způsobit tam, nebo tam reakci…

Mám z toho jen smutný pocit, že rozhasit něco je velice snadné a stačí pár procent jedinců a nemusí to dělat ani záměrně…

PS: Osobně už jsem několik let nikam nic oficiálně neposlal, když opravdu už velmi ojediněle „něco“, tak se raději spojím s konkrétním vývojářem a pošlu mu to, s žádostí „vynech mě“ ... je to tak 50:50, což považuji za velký úspěch a jsem spokojený.

[little.owl]

Nemam pocit, ze je to az tak vekove profilovane, tento konflikt jde napric vsemi generacemi.

Nakonec stejne rozhodne jen to, jestli zastanci te ci one cesty jsou schopni dlouhodobe prakticky podporovat sve reseni a produkovat nutny souvisejici kod. Prenesene, u Debianu tedy rozhodne jestli maji dosti lidi ochotnych podporovat neco jineho nez systemd a pokud tam nejsou nebo jich treba jen neni dost, zadna Jacksonova konstitucni alchemie ci hony na systemd maintainery nic nezmeni.

[Šangala]

Nemam pocit, ze je to az tak vekove profilovane, tento konflikt jde napric vsemi generacemi.

Napsal jsem „trocha zjednodušení“, mladým jsem chtěl označit spíše „novou myšlenku/postoj/směr“.

Prenesene, u Debianu tedy rozhodne jestli maji dosti lidi ochotnych…

Mají a budou mít, spíš to bude otázka kvality…

[chrono]

Možno si až teraz všimol kvalitu ľudí stojacich za systemd (CVE-request: systemd-resolved DNS cache poisoning) a povedal si, že s tým bude viac práce, ako si myslel. :)

[pavlix]

Jakože by řešitelný problém ve volitelné komponentě měl na věci něco měnit? Teď nemluvím o jeho závažnosti.

[Petr Ježek]

Do hlav lidí těžko nahlížet. Možná řešitelné pro jednoho je neřešitelné nebo řešení nehodné pro jiného...

[x]

Neimplementovat cache resolver a dalsi veci podle RFC rika vse o tom co za lidi tyhle komponenty vyviji a proc je proti tomu takova boure. Presne tyhle problemy ukazuji, ze opravnena. Kdyz neco takoveho chci, tak to delam poradne a ne jako kdyz pejsek s kocickou vari dort, obzvlaste pokud se jedna o velkou firmu. Kdyz je neco na h..... od zacatku, tak uz to pak v korporaci tezko nekdo spravi. Tech prikladu je za poslednich cca 20 let az az jak takovy pristup dopada.

[Lol Phirae]

Neimplementovat cache resolver a dalsi veci podle RFC rika vse o tom co za lidi tyhle komponenty vyviji a proc je proti tomu takova boure.

Takhle to v systemd vypadá všude. Např. implementace "synchronizace" času: Bug 86292 - systemd-timesyncd: Do not save clock to disk on every NTP fix. No to nemoh vymyslet zdravej mozek. A to zdůvodnění celého nápadu:

This is particularly helpful on systems lacking a battery backed RTC.

Ano, několik takových tady mám - Alixy s CF kartami. Když se nějaký debil rozhodne zapisovat mi co pár minut na tu kartu a likvidovat HW, protože "co kdyby systém spadnul, tak asi potřebuje kladivem přes palici!

[pavlix]

:D

[Michal Kubeček]

Před časem jsem čirou náhodou (hledal jsem něco úplně jiného) narazil na projekt implementující šifrování a dešifrování paketů formou targetu do netfilteru. Pokrčil jsem rameny a pomyslel si, že lidé občas dělají hodně podivné věci. Pak jsem si ale všiml jména autora a tak nějak to začalo dávat smysl…

[Delaunay]

A tehdy v tom roce 2002 to vlastně začalo. LP tehdy napsal:

Please check it out and send me bug reports and improvement suggestions.

A protože se mu nikdo neozval a nikoho to vůbec nezajímalo, tak si sám pro sebe řekl:

Však já se ještě vrátím, a se mnou přijde...

A co přišlo vlastně už moc dobře víme

[pavlix]

Vždycky mě fascinuje, když někdo udělá interface ke zobrazování zpráv nebo aktuálních článků, kde není vidět datum. Vždycky si říkám, jestli si ze mě prostě jenom nedělají prdel. Ještě víc fascinující je, že ve zdrojáku nějaké datum je a u něj celá jiná zpráva, kterou ale ve stránce ani nevidím. Zlatý Lennart.

[Rezza]

...obzvlaste pokud se jedna o velkou firmu

Lennart uz na systemd zalozil i firmu?

[little.owl]

Dodela se hardening.

[Petr Ježek]

Nejen Debianu by prospěly častější kontakty tvůrců s realitou. Někde skřípe zpětná vazba komunikace vývojářů s uživateli, jinde se naráží na vlastní znalostní omezení, onde pak na prostou pohodlnost... To, co musely za těžké peníze zvládat dřevní UNIXy obsahovalo řádově méně nejistoty, s níž je nutné vyvíjet moderní komplexní systémy. Proto i tehdejší optimální "suckless" paradigma musí ustoupit tomu, co ponechá "suckless" prvky a doplní je rozšířením schopným je i nahradit, je-li to nutné pro optimalizaci při vyšší komplexitě. Tím neříkám, že na desktopech nemůže zůstat "suckless" OS, pokud nemá uživatel vyšší ambice nebo k nim není nucen dodavatelem HW...

[Lol Phirae]

moderní komplexní systémy. ... tehdejší optimální "suckless" paradigma ... pro optimalizaci při vyšší komplexitě.

Viz...

[pavel]

Heen událost ještě komentoval na /., tady to shrnuje. Osobně mi ty argumenty přijdou slabé, ale možná neřekl to hlavní.

To samé Allbery, zvlášť v kontextu k jeho dosavadním aktivitám v TC. Bylo to spíš o politikaření než o technické a logické argumentaci k systémovému designu. Házet vinu na vyvolané GR je neopodstatněné. Jednak nevidím na něm nic fatálního, neodpovídá časová souslednost a ani to v rezignačním mailu nezmiňuje.

Na pravé důvody si budeme muset asi ještě počkat.

[pavel]

OT: Když jsem hledal další info k výše uvedené události, narazil jsem na bug #765870, se kterým si neví rady ani sám John Goerzen ! Leakuje mu systemd-logind až na 4 GiB. Teď ani nejde o to, jestli je chyba v systemd-shim nebo přímo v systemd, ale že se musí hledat příčina přes strace a valgrind, jak jehla v kupce sena. Třeba to časem dojde i víc lidem, jak draho budou vykoupeny lákadla systemd subsystému.

[pavlix]

Třeba to časem dojde i víc lidem, jak draho budou vykoupeny lákadla systemd subsystému.

Tak ono se to hlavně v začátku neví, jak draho, a ani později se asi všichni v hodnocení neshodnou :).

[pavel]

Tak určitě Těm co mají Linux jako černou skříňku a nevadí jim platit za support/pronájem, i když ho měli a mohli mít grátis to asi ne(d)ocení.

[pavlix]

Jestli je tvým oblíbeným diskuzním stylem předem onálepkovat každého, kdo by mohl nedej bože mít na něco jiný názor, tak si nemáme co říct ani v těch oblastech, se kterých s tebou souhlasím ;).

[little.owl]

Spise lakadla bastlu systemd-shim, ktery nema s vyvojem systemd nic spolecneho.

[pavel]

A jak jinak by se hledala chyba v pravém systemd ?

[little.owl]

Jako pri vyvoji kazdeho jineho programu. Samozrejme pouziti systemd-shim muze odhalit nektere jinak nedetekovane chyby v systemd-logind a z tohoto pohledu to muze byt uzitecne, ale nejedna se o komponentu, ktera byla/je/bude vyvojari systemd podporovana ci testovana. Muze to prinest "chyby", ktere z pohledu systemd chyby nejsou a provoz systemd-shim vzdy bude "na vlastni riziko".

[pavel]

Pointa mého příspěvku zřejmě zůstala nepochopena. Pro oba případy je nutné nasadit nástroje typu strace a valgrind k hledání příčiny chyby. Systemd přináší rozsáhlou mezivrstvu mezi jádrem a userlandem v nativních binárkách, kde se budou muset řešit obdobné problémy právě takhle komplikovaně. Aspoň v těch případech, kde se doteď vystačilo s editací init skriptů a inittabu (zakomentování, vložení assertů, úprava podmínek apod.).

[Jindřich Makovička]

Až na to, že práci systemd-logind předtím zastával ConsoleKit, u kterého si asi editací skriptů nevystačíte.

Skoro si myslím, že největší chyba systemd je v pojmenování. Kdyby ty ostatní démony nepojmenovali systemd-něco a pro jistotu je umístili v oddělených repozitářích, byl by klid.

[pavlix]

Ještě by nesměly být na systemd závislé. Jenže to už by jaksi kazilo celou pointu, že.

[Jindřich Makovička]

Na tom až tak nezáleží. Napište http server, který bude k běhu potřebovat systemd a neštěkne po tom IMHO ani pes. Ale zkuste ho pojmenovat systemd-httpd :)

[Slavko]

Ono to síce nie je HTTP server, ale IMO to má blízko - v súčasnom testingu Debianu nájdete:

• fcgiwrap závisí na libsystemd0
• php5-fpm závisí na libsystemd0

Ibaže budem PHP a CGI púšťať cez UWSGI...

[Foo Bar]

Vaše reakce je naprosto ukázkovým příkladem toho, proč lidi jako rra anebo tolef hází ručníky do ringu. Aniž byste věděl zbla o tom, co libsystemd0 dělá, tak to šmahem odsoudíte. PHP (a extensions) závisí na další hromadě jiných knihoven, o kterých víte zbla co dělají, a to je jedno. Hlavně že můžete trollovat o tom, že něco závisí na libsystemd0...

[Honza Jaroš]

Protože o tom také nevím ani zbla, zeptám se: jde v nové verzi Debianu tyto balíky provozovat na systému bez spuštěného systemd, či nikoli?

[pavlix]

Já teda na tohle nemám odpověď, ale je nějaký důvod, proč by závislost na knihovně měla implikovat závislost na běhu démona? Pokud by tyhle služby bez systemd nefungovaly, tak to buď musí mít zásadní důvod, nebo to musí jít triviálně opravit. Z názvu těch balíků mi nepřipadá, že by nutně systemd k něčemu potřebovaly.

[Honza Jaroš]

No já nevím, prostě Slavko naznačuje, že by to bez systemd nejelo, z odpovědi Petra Surého úplně moudrý nejsem, tak jsem se jednoduše zeptal. Přišlo mi to jako nejjednodušší řešení.

Pak mě teda napadlo podívat se ještě na závislosti balíku a řekl bych, že nepotřebují, ale co já vím, co kde bez čeho nejede...

[pavlix]

Slavko píše o závislostech na knihovně, což neznamená vůbec nic. Z balíkových závislostí taky o běhových závislostech nic nezjistíš. Takže pokud v diskuzi není nikdo, kdo by věděl třeba proto, že ty balíky dobře zná, tak není jiná cesta než to vygooglit nebo vyzkoušet. Každopádně závislost na knihovně o potřebě démona neříká vůbec nic.

[Honza Jaroš]

Slavko na taky něco reagoval, stačí si přečíst příspěvek o patro výš. Ale jinak souhlasím, že explicitně to nenapsal, proto jsem taky předtím použil výraz "Slavko naznačuje" a ne "Slavko tvrdí".

Myslím, že je zbytečné to dál pitvat, ale pokud chcete... *<:o)

[pavlix]

Já nezačal.

[Honza Jaroš]

Ach jo...

[little.owl]

Rychly pohled, fcgiwrap podporuje socket based aktivaci a pak zavislost na systemd je na svete.

[Foo Bar]

Ano. FPM tam tu závislost má kvůli notifikačnímu protokolu, kterým umí říct systemd, že daemon nastartoval a je připraven odpovídat na požadavky. V systemctl status pak uvidíte jednu informaci navíc. Pokud FPM neběží pod systemd, tak všechno funguje jak má.

[Slavko]

A odkiaľ viete, že neviem?

A aby som bol úplný, presne takéto reakcie (ako je Vaša) ma viedli k tomu, že po asi 7 rokoch už nepíšem z Debianu a skončil som všetky svoje aktivity a prispievania do Debianu...

Viete, nie len DD potrebujú mať pocit, že ich to baví...

[pavlix]

Erm, Ondrovu reakci považuju za přehnanou (to není kritika, jen názor), ale tohle mi přijde taky děsivé. Pokud jsi odešel od strašného Debianu, určitě se rád podělíš o informaci o tom, kde je trává zelenější a všichni ti pořád dělají radost.

[Delaunay]

V tomto konkrétním případě máte zbytečné obavy. Pouhá přítomnost souborů balíku libsystemd0 na disku a knihovny libsystemd.so v paměti nezpůsobí, že vám systém okamžitě začne metastazovat

[pavlix]

A něco víc než rádobychytré řeči by nebylo?

[pavel]

viz

[little.owl]

Pro oba případy je nutné nasadit nástroje typu strace a valgrind k hledání příčiny chyby

To jsou standardni vyvojove nastroje.

Aspoň v těch případech, kde se doteď vystačilo s editací init skriptů a inittabu (zakomentování, vložení assertů, úprava podmínek apod.).

Predchudce systemd-logind nebyl napsany v shellu a mel byste podobne problemy.

[pavel]

Nevím jestli jste se začetl do toho bugreportu, ale ani není jasné jestli leakuje sám systemd-logind nebo v souvislosti systemd nebo systemd-shim. Systemd, který ma na starosti spouštění služeb, podobně jako init skripty, ale s tím rozdílem že výše uvedenou ad-hoc editaci a trasování zdroje problému jen tak neuděláte, resp. podstatně složitějším způsobem. A o level to zvedá vzájemná propojenost, voláním knihovních funkcí z jiných modulů.

Nikde nepíšu že strace nebo valgrind jsou nestandardní, ale hledání chyby je s nimi daleko složitější než u přímo interpretovaných zdrojáků jako shell. Přibyde i překompilování s ponecháním ladících informací, které se standardně odstraňují v distribučních binárkách.

[pavlix]

Nějak mi není jasné v čem se tak liší systemd-logind, že nejde debugovat jako by šel jeho předchůdce ConsoleKit. Bez dalších informací bych k debugování obou dvou přistupoval zcela totožně. Jo, pokud se ukáže, že by default neleakuje, ale začne leakovat oproti náhradě nějaké knihovny ze systemd (jenom hádám), pak bych asi hledal problém primárně v té knihovně, která nahrazuje tu upstreamovou. Řeším podobné věci s glibc, kde mám několik glibc funkcí nahrazených vlastními nataženými třeba přes LD_PRELOAD a holt si s tím musím taky poradit, i když to není systemd.

[pavel]

ConsoleKit, aspoň v mojí distribuci spouštěl /etc/rc.d/rc.consolekit, kde si můžu spouštění procesu izolovat a libovolně obalovat a modifikovat podmínky spouštění. Přiznám že nevím do jaké míry lze nezávisle na systemd pouštět systemd-logind, ale předpokládám že už by to někdo v tom bugreportu zmínil.

S debugováním binárek přeložených z C/C++ jsem si už taky párkrát užil a vím jaký je to opruz. O dost složitější než hledat v pythonních nebo bashových zdrojácích, odpadá indirekce mezi původním lidsky-čitelným zdrojákem a nativní binárkou po optimalizacích překladače. Už jen kolik obtížně dohledatelných bugů mělo příčinu právě v optimalizacích gcc.

To co bylo aspoň částečně v silách běžného admina se solidními základy programování, bude se systemd prakticky neřešitelné a bude odkázán na vendora.

[Jindřich Makovička]

V té konfiguraci se systemd-shim se logind snad pořád spouští z initu... takže by minimálně mělo být triviální zjistit, proč se spouští logind stále dokola, ne?

[pavlix]

ConsoleKit, aspoň v mojí distribuci spouštěl /etc/rc.d/rc.consolekit, kde si můžu spouštění procesu izolovat a libovolně obalovat a modifikovat podmínky spouštění. Přiznám že nevím do jaké míry lze nezávisle na systemd pouštět systemd-logind, ale předpokládám že už by to někdo v tom bugreportu zmínil.

Já skutečně pořád nevidím rozdíl ve spouštění těch dvou, a jestli je pravda to, co píšeš, tak ten rozdíl nevidíš ani ty, takže je to jenom mnoho keců pro nic.

S debugováním binárek přeložených z C/C++ jsem si už taky párkrát užil a vím jaký je to opruz.

Debugování binárek přeložených z C je můj denní chleba, používám gdb na příkazové řádce a nemůžu si stěžovat. Nevím o ničem jiném, co by se debugovalo tak dobře.

O dost složitější než hledat v pythonních nebo bashových zdrojácích

Na bash a python povětšinou žádný debugger nepoužívám a snažím se vše pečlivě psát tak, abych ho nepotřeboval, i za cenu toho, že bude software značně neoptimální. Přecijen od pythoního a bashovského kódu žádný výkon neočekávám, to bych to napsal v C. Oproti tomu se v C se debuggeru vůbec nebojím a neseru se tolik s tím, abych se mu za každou cenu vyhnul.

odpadá indirekce mezi původním lidsky-čitelným zdrojákem a nativní binárkou po optimalizacích překladače

Pokud mi optimalizace při debugování vadí, tak je vypnu. Při tvorbě software to většinou dělám. Trochu problém je, když optimalizace nějaký bug odkryje, ale to se mi nestává. Ale to riziko je samozřejmě cena za to, co céčko nabízí.

To co bylo aspoň částečně v silách běžného admina se solidními základy programování, bude se systemd prakticky neřešitelné a bude odkázán na vendora.

To jsou kecy. Je to open source software. Sice to není v silách běžného admina, ale na druhou stranu to je v silách běžného programátora, který umí trochu s céčkem. Takové programátory urážíš, když jim nadáváš do nějakých vendorů, tím spíše že jen do jednoho abstraktního vendora. Nikomu neberu jeho názor, dokonce spoustu názorů sdílím i s lidmi jako jsi ty, ale nebaví mě v diskuzích řešit takovéto lži, kdy jeden člověk něco neumí a proto předpokládá, že to neumí nikdo kromě nějakého pana vendora.

[pavel]

Pokud v tom spouštění podle tebe není rozdíl, tak jim v tom bugreportu poraď ať neztrácí čas se systemd-shim nebo systemd spouštěný jako parametr jádra a testují logind nezávisle.

Ok, debugování binárek je tvůj denní chleba. A jaká je korelace mezi tvým mikrosvětem a správou systému ? Jako že admin by měl řešit problémy tak low-level způsobem ?

Je mi srdečně jedno jak píšeš skripty, při správě systému ale musíš řešit a číst cizí zdrojáky. Nechápeš nebo sebestřednost ?

Je mi srdečně jedno, jestli si vypínáš optimalizace. Řeč není o vývoji software ale používání GNU/Linuxu z pozice uživatele. Pokud nefunguje nastavení konzole přes systemd-consoled, budu muset celý distribuční balík znovu přeložit, protože se instaluje z debug info stripped a obvykle s optimalizací -O2 nebo vyšší.

Jaké lži ? Tobě přijde normální, že správci podnikových systémů by měli řešit věci na tak nízké úrovni jako prohánění binárek přes gdb a strace ? Opravdu ? Nikde netvrdím že narazí už dnes, s chybami jádra nebo sql serverů si zřejmě většina stejně neporadí a musí čekat až to opraví upstream nebo distribuce, ale na vrstvě mezi jádrem a userlandem prostor je a systemd ho stírá.

[pavlix]

Pokud v tom spouštění podle tebe není rozdíl, tak jim v tom bugreportu poraď ať neztrácí čas se systemd-shim nebo systemd spouštěný jako parametr jádra a testují logind nezávisle.

Nehodlám někoho obtěžovat při práci jenom protože někdo jiný nepochopil. Zbytek zkus srozumitelně, česky a slušně, pokud chceš dostat nějakou odpověď.

[pavel]

Nehodlám někoho obtěžovat při práci jenom protože někdo jiný nepochopil.

A nebo jen zastíráš vlastní nevědomost, že nemáš páru o příčině leakování a že logind podle všeho nelze spustit bez systemd nebo emulace ABI systemd-shim, tak že chyba může být v obou (logind i systemd(-shim)).

Zbytek zkus srozumitelně, česky a slušně, pokud chceš dostat nějakou odpověď.

Nechci. A než budeš někoho příště poučovat o slušnosti, podívej se nejdřív do zrcadla a odpusť si výrazy typu kecy k názorum které ti nesedí.

[pavlix]

A nebo jen zastíráš vlastní nevědomost, že nemáš páru o příčině leakování

Nemám o páro o příčině leakování a nevidím jediný důvod to zastírat.

a že logind podle všeho nelze spustit bez systemd nebo emulace ABI systemd-shim

Nikde jsem netvrdil, že logind nemá závislosti na API/ABI nějakých knihoven.

odpusť si výrazy typu kecy k názorum které ti nesedí.

Chtělo by to trochu soudnosti a neříkat hned všemu co vypustím z klávesnice názor.

[sid]

Zasnem. Mozno vas to sokuje ale je celkom normalne ze sw obsahuje chyby. Ked budete mat chybu v bashi tak ho prepisete do pythonu alebo napisete interpret bashu v bashi???. Normalne sa chyba nahlasi a fixne. Fakt by bolo lepsie nechat uvahy o inite a servisoch na ludi co tomu rozumeju a nerozpravaju tu bludy o debugovani c.

[little.owl]

Ten priklad byl nestastny a do diskuze s vyvojari se opravdu radsi nepoustejte.

Vas pohled jako admina bych klidne chapal, nicmene si uvedomte, ze jsou i adminove, kteri to budou videt jinak.

Systemd vam umoznuje spoustet standardni LSB/SysV init scripty, takze pokud je u nejake sve specializovane aplikace chcete, muzete je dale pouzivat.

[j]

Kdyz se podela systemd, tak si nespusti zhola nic.

[little.owl]

A treba o techto moznostech jste slysel?

systemd.unit=rescue.target

systemd.unit=emergency.target

init=/bin/sh

[Grunt]

Asi tak jako když sletí jádro. S trochou štěstí fungují aspoň SysRQ klávesy, ale většinou ani to ne. Je fakt, že interpretované jazyky mají cosi do sebe.

[sid]

Clovek co ma problem debugovat v c,c++ by sa snad k chybam na tejto urovni nemal ani vyjadrovat, nieto hrat zbytocneho chytreho.

[pavlix]

Nechtěl jsem být až tak zlý, ale taky si to začínám myslet.

[j]

" bude odkázán na vendora"

A o to presne RH jde, kdo by platil support, kdyz si ho muze delat sam, zeano.

[TM]

Zase je diskuse plná demagogie o neschopných, hloupých lidech, kteří se prý nechtějí naučit nový init systém.
Přitom to spočívá v něčem jiném. Když se objevil upstart v RHEL6 a před tím v Ubuntu, téměř nikomu nevadil. Z jednoduchého důvodu - dělal to, co má init sytém dělat a někdy i trochu lépe než klasika...
Systemd má ale ambice zcela jiné - transformovat celou platformu do podoby jakýchsi nových Windows pod kontrolou jedné firmy, na.rat se doslova všude, pohřbít Unix v Linuxových distrech jen proto, že je příliš přehledný, nezávislý a variabilní a tudíž mnohdy kazí kšefty. Je to tak prosté...

[pavlix]

Vždycky se mi líbí, jak někteří míchají fakta a vlastní hodnocení, což je případ i tvého komentáře. Vznikají z toho pak docela zajímavé diskuze, protože každý může volně pokládat hranici mezi těmito dvěma odlišnými věcmi. Dobře jsi identifikoval, že systemd rozhodně není projekt na vylepšení initu, to je přinejlepším podprojekt. Je to zjevné z každého jednotlivého vydání systemd už hodně dlouhou dobu.

Zajímavější je ale to přirovnání k Windows, což je univerzální způsob, jak vyjádřit, že je něco špatné. Já osobně bych v mnohých ohledech přirovnal spíše k BSD, které se taky snaží mít základní systém tak říkajíc pod jednou střechou. I když je pravda že v systemd k tomu chybí kernel a libc, zase na jejich omluvu musím říct, že se některé části libc snaží reimplementovat v rámci libsystemd a dokonce jim dávají nová API. Asi hlavním rozdílem od BSD je ta dynamičnost, absence konzervativity.

Na tu kontrolu jedné firmy jsem docela zvědavý, zatím spíše vnímám kontrolu osobnostmi, kteřé pokud mi něco neuniklo můžou chlebodárce kdykoli vyměnit.

[Tonda]

Zajímavější je ale to přirovnání k Windows, což je univerzální způsob, jak vyjádřit, že je něco špatné

ohledne systemd je to naproto odpovidajici prirovnani. Windowws maji take svuj systemd = service control manager a programatori, kteri programuji windows services by mohli vypravet, jaka je to radost to programovat. U windows je presne mozno pozorovat, jak je tato filosofie debilni.

[pavlix]

Musel bych vidět konkrétní srovnání napříč systémy, aby se ukázala podobnost s Windows a nepodobnost se všemi ostatními, ne takovéhle plácání prázdné slámy. Jenže na to nikdo z nás nemá čas, že.

[biolog]

V práci mne čeká napsání servisy pro Windows. Na co se mám připravit? Servisy i démoni nemají přístup na desktop, ovládání a zobrazování se děje přes soket v obou případech. Proces běží s právy jiného uživatele, na to se musí myslet při návrhu a vadí to při ladění. Způsob startování/stopování démona a služby je odlišný, ale ne podstatným způsobem; akorát u Windows IT lidi ten mechanizmus obvykle nemusí znát a tedy ho neznají. Programátor musí mít nastudováno stejné množství materiálu. V čem je to tedy horší?

[Tonda]

no, ja porad nechapu, ze to nikdo nechape. Pritom zna uplne kazdy windows jak tam vypada sprava udalosti (to je ten binarni log a prohlizec k tomu ), jak se startujou sluzby apod. Takhle nejak bude vypadat systemd za par let.

Moje uloha byl takovej odlehcenej printer-spooler, na windows mela bezet jedna sluzba, ktera pres socket prijimala tiskove zakazky a druha ktera to pak posilala na tiskarnu. Vpodstate trivialni zalezitost a na linuxu bez systemd se to dodnes dela tak, ze v systemu o tom nikdo nic nevi - nejaky init to po bootu proste nastartuje a pak to bezi a nikdo nic nevi (jak jsme se od Poetteringa dovedeli, je toto zlo a takovy gulas se v budoucnu nebude trpet). Ve windows se to uz netrpi dnes a proto kdyz chce nekdo napsat sluzbu, tak se ponori do tajiu toho service control managera. (to bude u linuxu tedy ten systemd , ktery bude nabizet ty interfejsy).

Samozrejme, ze ty interfejsy nejsou trivialni - protoze tem moloch musi samozrejme myslet na vsechny mozne alternativy a dokumentace je takova jaka je. Takze do internetu a priklady. Pote co clovek tedy zkopiruje co se da a vytvori vlasni kod , tak se to eventuelne i prelozi a ted zacina ten spravnej cirkus - debug. Spustit to samozrejme nejde, protoze o to se stara ten windowssovskej systemd , takze se clovek propoji s debugem k rozbehnutymu procesu nekde uvnitr ty sluzby v nejake te while smycce. No to by jeste slo. Tu startovaci cast sluzby , tedy kdy tem systemd ty sluzbe predava ty parametry se vpodstate neda smysluplne debugovat, ale na netu existuji navody, jak to nejak udelat - neco pro masochisty - to je celkem pochopitelne, ono jaksi nejde ten systemd kvuli debugu na chvilku vypnout a nastartovat pekne od zacatku, aniz by mezitim klekl sytsem ). Samozrejme, ze je pak mozno naklikat ve sprave sluzeb ty ruzne startovni podminky a zavislosti a tohle take ve sluzbe zohlednit a zpetne davat prikazy tomu systemd, co by prave bylo vhodne ucinit. K tomu se prida jeste multithreading, protoze v jednom threadu se sluzba porad pta jestli nekdo nekliknul na ukoncit a v tom jinym zpracovava to co jeji ulohou.

Podtrzeno, secteno, jako programator na volny noze nemam na takove kraviny cas, takze se napise jednoducha konzolova aplikace, ktera se nastartuje v autostartu a kdyz je potreba to ukoncit, tak to udela uzivatel v taskmanageru. Service control manager samozrejme o nicem nevi, (jaka hruza) log to ma vlastni, takze v udalostech taky nic (jaka hruza). Proste jako za starych casu v SysV-init

[j]

Hele, vypada to, ze spolu delame cece ... mam tu appku, ktera se puvodne planovala ze pobezi jako widli sluzba. Ve finale to bezi proste jako bezna appka, startuje se to z "po spusteni" a loguje to do databaze. Logovani do widliho logu se zkouselo zprovoznit asi 14 dnu, a jaksi se nepodarilo (gold parner M$ podotykam).

A presne proto na moje tuxi stroje nesmi systemd ani pachnout, to je radsi zmigruju na widle.

[EtDirloth]

Mozete mi, pani j a Tonda, prosim prezradit, ako je vo vasej appke/appkach zabezpecene znovunastartovanie po exite?

Napada ma, ze by to slo spravit watchdogom, ktory restartne windows. :)

[SPM]

Já furt nevim, co maj všichni s tim znovu startovánim... Když to vypnu já, tak to dělám proto, že chci, aby to bylo vypnutý. Ne aby se to samo znova zaplo. Když to spadne samo, tak mi dohledový systém oznámí, že to spadlo a budu primárně řešit to, proč to spadlo a aby se to už nestalo. Když mi to bude init pouštět pořád dokola, tak velice pravděpodobně ani nepřijdu na to, že to padá a poběží to akorát na h****

[pavlix]

Když to spadne samo, tak mi dohledový systém oznámí, že to spadlo a budu primárně řešit to, proč to spadlo a aby se to už nestalo.

To je ale chyba v návrhu celého systému. Buď se služba restartovat nesmí, nebo má být její restart v dohledovém systému zaznamenán. Oba přístupy mají svůj smysl a své příznivce.

[SPM]

Podle mě služba je pokaždé od toho, aby běžela. Když neběží, tak jedna skupina se to snaží řešit a druhá po vzoru IT Crowd to zkusí vypnout a zapnout. Co se týče dohledu, tak neběžící služba je typicky stav, dohleduje se to lehce (obvykle se stačí podívat, jestli ten proces vůbec běží, jestli je otevřený port) a z dohledu to nezmizí, dokud s tím někdo nic neudělá. Zatímco oznámení, že init systém automaticky restartoval službu, je akorát událost. Ta se někde zaznamená. A jo, v ideálním případě by to taky někde mělo svítit a někdo s tím pak něco udělá. Pokud to ovšem nezapadne mezi stovkou dalších událostí nebo pokud se to vůbec objeví tam kde má, protože po upgradu xx ta logovací řádka vypadá jinak a regexp nefunguje. A pak se na to ten admin stejně vykašle, protože to přece teď běží, tak to není potřeba hned řešit.

[pavlix]

no, ja porad nechapu, ze to nikdo nechape. Pritom zna uplne kazdy windows jak tam vypada sprava udalosti (to je ten binarni log a prohlizec k tomu ), jak se startujou sluzby apod. Takhle nejak bude vypadat systemd za par let.

Windows jsem opouštěl jako uživatel, amatérský programátor a webař. Nemám tušení, jak vypadá ve windows logování ani co se schovává za službama, ani co je na tom konkrétně špatně. A vzhledem k zaměření portálu myslím, že tu nebudu sám, pro koho jsou windows španělskou vesnicí, i když nepopírám, že s nimi pořád umím víc než většina rádobyadminů a že jsem si za to po explicitním upozornění na svou neznalost nechal i zaplatit.

Takhle nejak bude vypadat systemd za par let.

Odvážné to tvrzení, ale vzhledem k výše uvedenému těžko můžu oponovat.

Moje uloha byl takovej odlehcenej printer-spooler, na windows mela bezet jedna sluzba, ktera pres socket prijimala tiskove zakazky a druha ktera to pak posilala na tiskarnu. Vpodstate trivialni zalezitost a na linuxu bez systemd se to dodnes dela tak, ze v systemu o tom nikdo nic nevi

Zatímco v systemd se napíše triviální soubor o pár řádcích, který říká, jak se má služba spustit, podobně jako se to dělalo dřív s initskripty.

Spustit to samozrejme nejde, protoze o to se stara ten windowssovskej systemd

A ten program bez systemd spustit jde? Těším se na důvod a především na srovnání s initskripty. Jestli jde jen o to, že člověk zapomněl závislost na síti a program vypsal, že se nemůže nabindovat na IP adresu, protože v systému není, tak to asi nebude vyžadovat debugger, že.

takze se clovek propoji s debugem k rozbehnutymu procesu nekde uvnitr ty sluzby v nejake te while smycce.

A nebo, když člověk není debil, službu zastaví a pustí si debugger s procesem z příkazové řádky jako se to dělalo předchozích třicet let bez ohledu na to, kdo tu službu v systému standardně spouští.

Podtrzeno, secteno, jako programator na volny noze nemam na takove kraviny cas, takze se napise jednoducha konzolova aplikace, ktera se nastartuje v autostartu a kdyz je potreba to ukoncit, tak to udela uzivatel v taskmanageru.

Dělal jsem jednotlivé linuxové projekty na volné noze a napstat initskript mi zabralo víc času než napsat unit file. Každopádně ten čas byl vzhledem k celému (ač velmi malému projektu) zanedbatelný, takže mi byl init systém tak říkajíc u prdele. Napsat to rovnou do inittabu a nechat to ukončovat killem bych si stejně nedovolil, to by mi ruce upadly.

[Rezza]

+1!

Btw. kdysi jsem psal service pro Windows, byl jsem mlady a nezkuseny. Dokonce v Delphi :). A tam to byl skutecne porod, pokud neco bylo spatne. Tak jsem idealy zahodil a byla to proste nakonec obycejna aplikace. Jen tam porad nevidim to srovnani se systemd... Protoze se systemd je to ten druhy pripad - pusti se proste program, ne sluzba psana vuci nejakemu silenemu API.

[pavlix]

Možná dotyčný prosně někde jednou slyšel, že systemd je jako windows, a podle toho se ho snaží posuzovat a proto dochází k chybným závěrům.

[biolog]

no, ja porad nechapu, ze to nikdo nechape.

To je asi tím, že psaní serviců a démonů není běžná činnost.

nejaky init to po bootu proste nastartuje a pak to bezi a nikdo nic nevi (jak jsme se od Poetteringa dovedeli, je toto zlo a takovy gulas se v budoucnu nebude trpet)

Nejenom Lennart, ale i Raymond Chen z MS říká, že není možno nastavit, že se služba má spouštět na konci bootu. Ani v SysV initu to nejde - pokud nastavíte init skriptu největší číslo, stejně někoho napadne přidat skript se stejným číslem.

Když programátor přidává položku do launcheru, rozšíření do prohlížeče, službu do Windows, démona do systemd, tak musí detailně popsat jak se má zobrazovat a spouštět. Ve všech případech je to zdokumentované celkem dobře.

Debugování programu spouštěného jiným programem a ještě k tomu pod jiným uživatelem je vždy těžší, než napřímo. Proto se služby, démoni pro systemd i sysv init hlavně ladí pod programátorovým účtem bez spouštějícího programu. Jen interakce s spouštěcím programem se ladí (pokud je vůbec potřeba tohle ladit) napříč uživatelskými účty - a ve všech 3 případech je ladění stejně obtížné.

Přečetl jsem návod na codeproject.com a skutečně volání StartServiceCtrlDispatcher(), která pak volá programátorovu ServiceMain(), mi připadne zbytečné. Funkce main() by mohla obsahovat kód funkce ServiceMain(). To další vlákno v procesu služby vytváří Service Control Manager a dává v něm příkaz z ukončení, zastavení atd., není to pollování. V SysV initu by se místo vlákna spustil proces, který musí proces svého démona teprve najít. (Jak je to u systemd nevím.) Takže u Windows je to obdobné, ale snazší.

Ano, zapisovat do windowsiho logu je mor.

[pavlix]

V SysV initu by se místo vlákna spustil proces, který musí proces svého démona teprve najít. (Jak je to u systemd nevím.)

Systemd si drží informace o procesech a nakládá s nimi na základě deklarativního jazyka, takže většinou nepotřebuješ samostatný supervisor proces pro službu, ale samozřejmě jsou služby, které ten supervisor proces stále mají, jako třeba squid.

[mankind_boost]

Je to souboj dvou filosofii - unixova (mnoho malych jednotek, ktere delaji jednu vec) a windowsova (jedna obluda, ktera dela vsechno). Ktera je lepsi uz vime davno (a systemd patri k te druhe - od DNS pres jas displeje az po virtualni konzoli)

[little.owl]

Asi me ve Fedore obludne podvedli a podstrcili mi misto jedne obludy nejaky jiny systemd rozsekany do spousty malych binarnich komponent, z nichz cast je volitelna.

unixova (mnoho malych jednotek, ktere delaji jednu vec)

Jako monoliticke kernely, X-ka ci oblibeny busybox?

Mate nejaky zarny priklad teto ideologie?

[mankind_boost]

"rozsekany do spousty malych binarnich komponent, z nichz cast je volitelna. "
Proč to tedy není několik samostatných projektů?!

"Jako monoliticke kernely"
Ano, typickou ukázkou obludy je linux (jako monolitický kernel) - na hranici maintainability. Proto máme mikrokernely (koukněte třeba na QNX, moc pěkná architektura kernelu).

"X-ka"
Proto se je snažíme nahradit

"busybox"
Busybox je něco jako systemd co se týče modularity. Ale používá se jen na embedded, proto je to jedna "obludka" (to je víceméně jediný důvod). Vy snad používáte busybox v hlavním systému na desktopu? Na to byste si asi netroufnul, že.... Proto máme samostatné coreutils, sed, awk, grep, file atd.

[little.owl]

Proč to tedy není několik samostatných projektů?!

A proc by mel, kdyz cilem je unifikovany framework?

koukněte třeba na QNX, moc pěkná architektura kernelu

QNX jsem pouzival v nekolika projektech a duvodem byla predevsim SIL certifikace, nikoliv mikrokernel.

Vy snad používáte busybox v hlavním systému na desktopu? Na to byste si asi netroufnul, že.... Proto máme samostatné coreutils, sed, awk, grep, file atd.

Nepouzivam a klidne troufnul, commandlinove tooly jsou pro me spise dukazem nekoherentniho evolucniho zmatku, nez unixove filozofie.

Takze jestli tomu rozumim, podle vas je zarnym prikladem teto ideologie neunixovy QNX kernel nebo mate jeste neco jineho?

[Ovoce]

jedna obluda, ktera dela vsechno

A takovým věcem se pak někdy říká "operační systém" :)

mnoho malych jednotek, ktere delaji jednu vec

A tomuhle zase bastl :P

Význam konceptů jako "filosofie Unixu" se IMHO hoooodně přeceňuje, v podstatě je to hlavně fráze a jako fráze se to taky používá (tedy coby náhražka za skutečný argument). Tady v podstatě neargumentujete nějak logicky a fakticky, ale snažíte se vytvořit pojmovou konstrukci, která by spojila systemd s Windows a tím vytvořila negativní *dojem*.

Realita je složitější než takovéhle diskusní zkratky, ostatně někdo výš už v tomto duchu citoval Linuse... "Grau, teurer Freund, ist alle Theorie, und grün des Lebens goldner Baum."

[pavlix]

První německá věta o víc než třech slovech, které jsem v životě rozuměl! Možná to bude tím, že význam toho, co se za ní skrývá už znám a od Linuse to není, mimochodem, Linus nějak běžně mluví německy?

[Ovoce]

To je Goethe, ne Linus samozřejmě. Linuse tu citoval někdo jiný vejš a mě se to nechce hledat. Ale napadlo mě pak tohle moudro.

[mankind_boost]

"A tomuhle zase bastl"
Pokud je pro vás "několik samostatných specializovaných programů" bastl, pak se asi nemáme o čem bavit.

[pavel]

Jak ale vysvětlíš že 45 let starý koncept Unixu a GNU/Linuxu postavený na SysV-initu byl a je stále zelený a už dávno neuhnil ? Co bylo na něm tak neúnosného, že překopat ho na systémové úrovni je nevyhnutelné ?

Pokud bych použil tvoji (para)frázi, tak systemd je v praxi tak krátce, že zatím bilancovat o jeho přínosech je spíš v oblasti šedé teorie.

[JoHnY3]

Linux rozhodne neni ideove cisty Unix, HP-UX i AIX a jine velke Unixy jsou na vymreni, Solarko nepouziva SysVinit, MacOS X je MacOS X.

Unix koncepce je dneska v Linuxu jen o trochu relevantnejsi nez VMS koncepce u Windows ... zatracene malo.

[jirka]

nestras :) zrovna s AIXem bych to tak cerne nevidel. Naopak, spousta firem se k nemu vraci a zrovna po eskapadach s RHEL a zejmenena jeho virtualizaci objevuji opet kouzlo PowerVM.

A co se tyce MacOS X ? no ten je super. Z meho pohledu je spis Linux na vymreni :) Linux jsem doma kompletne vyhazel, Desktopy, tablety, telefony Mac OSX/iOS a na domacim "CML" = p520 zpet AIX. ...stejne od FC12 to slo do .... :)

[TM]

BSD systémy vám nic neříkají? Mají se čile k světu.
Kromě toho, unixová ideologie zdaleka není jen o tom, že se vše rozseká na malé specializované programy - právě toto se občas v historii porušovalo, protože jen na tom to nestojí. Je tam toho _mnohem_ víc a systemd ignoruje téměř vše - je prostě z jiného světa, je násilně vnucován tam, kam nepatří.
Zajímavé je i to, že Dennis Ritchie považoval právě Linux za nejživotaschopnějšího novodobého pokračovatele toho, co kdysi u Bellů vytvořili. A s tím, jestli jde o mikrokernel nebo jádro-monolit to nesouvisí. Jádro je prostě jádro.

[jirka]

ale jo, ale to bych detem neudelal :) Donedavna si stacili se supertuxem, tuxkartem apod, ale ted "frci" Lego apod. a Lego StarWars ve wine na FreeBSD bych as pytlikoval dost dlouho :) a co teprve sync iphonu ? S manzelkou oba dost behame takze ruzne app a sync muziky je taky o dost lepsi. Proste uz jsem dost marne hledal duvod proc se Linuxu na desktopu drzet. Pred 15 lety bych ale skalopevne tvrdil, ze tohle nikdy nereknu :)

Na p520 jsem BSD nezkousel, ale kdo vi. Pokud neklesne cena za Power8, tak asi budu dost vahat, preci jen za ty penize by misto power serveru byl pekny dalsi mac, napr. pro.

Uvidime, co udela OEM licencovani IBM Power CPU, treba se AIX dostane i do nizsich segmentu, kde firmy bojuji s KVM na RHEL a do VMware se jim nechce.

[TM]

To je věc preferencí. Iphone mě třeba nezajímá a nějací fanatičtí hráči jsme doma nikdy nebyli. Takže nemám žádný rozumný důvod, proč bych dlouhá léta používané OpenSUSE měnil za cokoliv jiného, když dělá přesně to co má. Poměrně často jej - zcela úmyslně - kupuju v krabici...
Jediná věc mě vždy trochu štvala - příliš časté vydávání nových verzí podobných desktopových dister. Ocenil bych nějaké LTS jako má třeba Ubuntu(to ale nechci).

[jirka]

docela dlouho me iphone taky nezajimal, ale vecne problemy s androidem syncem do linuxu a nestability prostredi me privedli k iphone.

pak uz to celkem byla jasna volba pro Mac OSX a dalsi iOS veci.

Fanaticti hraci take nejsme, ale kdyz uz deti chteji novu hru tak proc jim neudelat radost :) A hlavne je to zalezitos X eur na appstore, ne hodin u wine console.

Nedelalo mi problem delat leta "betatestera" ruznych dister. Nicmene preference se meni. Uz me nebavi smer kam se userspace ubira, nic mi to neprinasi spise naopak.

LTS u FC nebo jinych by bylo fajn. V posledni dobe jsem pouzival Xubuntu LTS ale misto upgrade na 14.04 se slo na Yosemite :)

V serverove oblasti je to jeste horsi. InitWars jsou toho peknou ukazkou. Neni problem samotny systemd, ale to jak jsou nekteri naprosto neochotni akceptovat cokoliv mimo systemd a systemd protlacuji bez ohledu na to, ze v nekterych oblastech je dle meho nazoru opravdu faulty by design. Ono napr. pouzivat OS X launchd na serveru by asi taky nebylo to prave ale OS X a iOS maji pouze destopove ambice ( vyjma OSX serveru, ktery je docela pekna sbirka serverovych utilit, ale pouzitelne vice mene jen na smb sharing a deploy iOS zarizeni a rizeni parental politik )

Uvidime kam se to v serverove oblasti posune. Dneska ze zakazniku kdo "ma", kupuje unixy, kdo "nema" nebo "ma malo" kupuje vmware s windows a "centosy". No a pak jsou tu specifika tech co "maji ale fandi", napr debianu viz seznam. Jsem zvedav jak jim to dlouho vydrzi se systemd...

[quā quā]

Zase je diskuse plná demagogie o neschopných, hloupých lidech, kteří se prý nechtějí naučit nový init systém.

Věta jak vystřižená z učebnice demagogie