Rozhodnutí o výchozím init systému v Debianu se (ne)blíží

Debian by ke konci měsíce "měl dospět" k volbě výchozího init systému. Podle jednotlivých vyjádření členů (link na seznam) technické komise (ctte) je stav systemd: 4, upstart: 4, openrc: 0 (k finálnímu hlasování ještě nedošlo).

LWN.net dále rozebírá (subscriber link) možná řešení patové situace: předseda komise (Bdale Garbee, pro systemd) má formálně 1 extra hlas pro řešení patu, ale v tomto případě není pravděpodobné, že by takové řešení bylo přijato. To by mohlo vést např. k referendu, které ale na přehlasování komise potřebuje výsledek alespoň 2:1 ...

22.1.2014 07:27 | marbu | Komunita

Komentáře

[Max]

Používá a vyvíjí někdo upstart kromě Canonicalu?
Na wikině je, že Fedora nasadila upstart, ale pak přešli na systemd. To samé v případě OpenSuse. RedHat 7 bude mít také systemd.
Zdar Max

[marbu]

Fedora sice na upstart přešla, ale nedostala se do fáze, že by se přestal používat SysV kompatibilní režim, nativní upstart initfile (v /etc/init/) mělo jen pár věcí (tty, plymouth, sysv runlevely a pod.).

[Ján Dráb]

s tym redhatom to bude zaujimave, ak si spravne pamatam, tak RH6 ma podporu 10rokov :)

[marbu]

Tohle imho nebude zas az tak velky problem, protoze vsichni daemoni v RHElu 6 maji pouze klasicke SysV initskripty, nove vlastnosti upstartu se vyuzivaji velmi malo. Viz muj predchozi prispevek o Fedore (do verze 14), pro RHEL6 plati to same.

[David Jaša]

Jediné nativní využití upstartu, které jsem v RHEL6 viděl, používá vdsm pro řízení libvirtu na RHEVích hostitelích. Tam se libvirt musí ovládat pomocí initctl pokud se už na něco musí sahat.

[SYSMAN]

A není to ve finále v podstatě jedno?

[Karry]

Co se Linuxového Debianu týče tak je to opravdu celkem jedno. Ale Debian se vydává i s jinými jádry, jako (k)FreeBSD a jako neoficiální build s Hurd kernelem. Systemd může fungovat pouze na Linuxu, jeho výběr by tedy tyto ne-Linuxové porty značně ztížil.

Osobně mám zkušenosti pouze s Upstartem, takže nemohu moc porovnávat. Na úrovni init systému stojí na stejných myšlenkách. Systemd ale krom init systému plní i funkci udev a logování...

[Rezza]

Jak pises - systemd uz davno neni jen init, ten je tam jen takovy maly zlomek. Ale proste systemovy daemon. Ve chvili, kdy tu systemovou cast zacnou pouzivat a vynucovat upstreamy, musis na systemd stejne prejit nebo mit kompatibilni vrstvu nebo se trebas rozloucit s GNOME.

[ikar]

nebo se trebas rozloucit s GNOME

Nejlepší řešení navrhne odborník vždy jako poslední!

[Michal Kubeček]

Nevím, nakolik to funguje i u psaného projevu, ale při živém rozhovoru je podle psychologů vhodné nabízet námi preferovanou možnost jako poslední, protože člověk, kterému je to víceméně jedno, nejčastěji zvolí právě poslední nabízenou variantu (zejména je-li jich hodně nebo pokud problematice vůbec nerozumí), prostě proto, že ji má nejčerstvější v paměti.

[Xerces]

Otázka je, zda navrhovat něco člověku, kterému to je v zásadě jedno, nebo problematice nerozumí.

[Mti.]

Bohuzel i takovi maji casto moznost rozhodovat a je jich dost na to, aby mohli (byt nevedome) skodit. :-/

[Já]

Zajděte si třeba do čajovny, kde zrovna obsluhuje nějaký aktivista, který má pocit, že i když jste si vybrali čaj, pořád se vás ještě musí zeptat na deset dalších doplňujících otázek k relativně bezvýznamným detailům. To strašně škodí, že?

[marvn]

(ftr) na ck uz se skoro 2 roky nesahlo, takze v dohledne dobe to nebude jen gnome, protoze k logind neni v soucasnosti alternativa...

[Ondra]

nebo se trebas rozloucit s GNOME

a nejsou tohle jen klepy?

co jsem ja slysel, tak jadro GNOME systemd nepotrebuje. ten se pouziva/bude pouzivat jen na technicky veci jako spravu napajeni nebo neco okolo prihlasovani... ale gnome-shell, nautilus, nebo gnome-control-center si pustim systemd nesystemd

jestli do toho nekdo opravdu vidite, uvedte to prosim na pravou miru, diky

[marvn]

afaik, tak nektery funkce jsou vazany na logind. ktery teoreticky nepotrebuje systemd jako init, ale atm s nicim jinym nefunguje...

bez logind pak gnome bude postradat nektere funkce (ale konkretnejsi info neznam)

[Michal Kubeček]

Pokud mohu soudit podle zkušeností s KDE, půjde o všechno, co bude potřebovat (typicky kvůli oprávněním) vědět, kdo je aktuálně přihlášený uživatel - např. mountování výměnných diskových zařízení, povolení uspání/vypnutí/rebootu apod.

[Já]

Toho je víc. Ale dá se celkem čekat, že kolem 3.14, nejpozději 3.16, nahradí systemd (v uživatelské instanci) gnome-session tak moc, že Gnome jako celek asi používat moc nepůjde.

(Má-li kdo intimnější zážitky s gnome-session, spíš se na to těší.)

[Ján Dráb]

Len doplním tvoje tvrdenie, že systemd môže fungovať len na linuxe. AFAIK Lennart povedal, že nepočíta s ničím iným ako s linuxom, čiže na BSD/hurd nebude brať pri vývoji ohľad. Naproti tomu upstart ani dnes ešte nie je portovaný na nič iné ako linux. Rozdiel je v tom,že Canonical potvrdil, že prekážky portovaniu na inú platformu robiť nebude a možno neskôr niekoho k tomu vyčlení. Ďalší problém vidím vo vývojároch debianu, kde podľa môjho názoru má veľká časť z nich problém s CLA, ktorú Canonical od nich k upstartu bude určite vyžadovať.

[Foo Bar]

Škoda, že se i tato diskuze plní nepodloženými fakty: https://lists.ubuntu.com/archives/upstart-devel/2014-January/003010.html

Stejně tak ten žblept o tom, že by Canonical od Debian vývojářů bude vyžadovat CLA. Debian má dlouhou tradici v udržování externích patchů, a není zásadní problém v tom dál pokračovat i v případě upstartu.

Pokud by se stal upstart stardarním init systémem, tak by naopak musel nějak zareagovat Canonical, protože v jeho zájmu rozhodně není, aby Debian forknul upstart. Byl by to pro ně byl snad větší problém, než když Debian přejde na systemd, protože situace, kdy existují dvě vzájemně nekompatibilní verze upstartu, je pro import source balíků z Debianu nejhorší možná situace.

P.S.: Osobně bych byl pro kombo systemd(Linux)+openrc(!Linux)

[Honza Jaroš]

Tohle mě zajímá - když už OpenRC, proč ještě systemd? Kvůli Gnome?

[little.owl]

když už OpenRC, proč ještě systemd?

Otazka by spise mela znit: "Kdyz systemd, tak proc OpenRC?", zejmena kdyz mam pocit ze i v jeho baste Gentoo ztraci postupne pozice a i treba odvozeny Sabayon presel z OpenRC na systemd.

[Honza Jaroš]

Což si takhle přečíst, na co jsem reagoval? Nebo to má chápat jako dotaz, proč mít Debian založený na nelinuxových jádrech? V tom případě se ptejte spíš předřečníka, já vám na to odpověď nedám (i když ta možnost se mi líbí, byť ji nevyužívám)

[little.owl]

Což si takhle přečíst, na co jsem reagoval?

V podstate ano, sorry.

Nebo to má chápat jako dotaz, proč mít Debian založený na nelinuxových jádrech?

To je dobra otazka, podle je uzivatelu jinych architektur smesne zanedbatelny pocet.

[Foo Bar]

Odpovídám tady za sebe - moderní init kvůli integrované supervizi, kterou OpenRC nemá a ta navrhovaná integrace s monitem ve mne vyvolává dávící reflex.

OpenRC je tam jenom proto, aby non-Linux porty fungovaly, a zároveň se dalo zbavit těch příšerných shell init skriptů. Mnohem radši budu psát konfigurace pro systemd+upstart+openrc než jeden shell init skript.

[David Jaša]

moderní init kvůli integrované supervizi, kterou OpenRC nemá

Proč se jejich implementace cgroups nedá počítat jako integrovaná supervize?

[Foo Bar]

Já do toho zas tolik nevidím (resp. mne to nezajímá natolik, abych to studoval hlouběji, nesedím v CTTE :)), ale tak jsem to pochopil z Thomasovy reakce v https://lists.debian.org/debian-ctte/2014/01/msg00390.html

[...]

On 01/19/2014 08:15 PM, Ian Jackson wrote: > * The daemon does not double-fork; it runs in the foreground of > of its initial process.

Something like start-stop-daemon then? :)

See also the command_background directive (in the man openrc-run).

On 01/19/2014 08:15 PM, Ian Jackson wrote: > * The daemon's parent process (part of the init system) keeps > track of it, so the init system knows whether the process > is still running.

First, OpenRC isn't stateless like sysv-rc to begin with (try "rc-status" to see what daemon is running). Status are kept in /run/openrc/started using symlinks to /etc/init.d, and OpenRC uses (optionally) cgroups to shutdown daemons, if that's what you ask.

Then, the answer to this question is even more definitively "yes", if you use this patch: https://github.com/qnikst/openrc/compare/s-vision

which uses monit for the process supervision. [...]

Radši to přečtěte v originále včetně další diskuze, mohl jsem vytípat něco moc z kontextu... a třeba jsem špatně pochopil to, že OpenRC používá cgroups jenom na hlídání toho, že se mu při shutdownu nerozutečou všechny child procesy.

Já si pod supervizí představuju něco jako daemontools/runit, a systemd (i upstart) to (alespoň pro mne) splňuje.

[little.owl]

No a jaka je tedy situace v Debianu?

Podle pravidelneho scanovani Debian mailing listu mam pocit, ze vetsine vyvojaru je to fuk, a vetsina z tech kterych se to tyka nebo maji nazor se kloni spise k systemd, s tim ze na obou stranach jsou hlucni zastanci/odpurci, a ze OpenRC je mimo hru, nebot ho nikdo prakticky neni ochoten udrzovat v odpovidajicim stavu.

[Ján Dráb]

Dik Ondrej, zrejme som mal stare informacie, vid mailinglist. A tiež máš pravdu v tej ďalšej časti o upstarte ako štandardnom init systéme. Osobne mi ale príde veľmi divné aby si debian udržiaval všetky svoje príspevky do upstartu ako patche, pretože to podpísanie CLA platí pre všetky projekty Canonicalu. Ale naozaj by bolo pre Canonical a upstart vhodnejšie aby sa s tým CLA umravnili a celé ho zahodili. Pre ich vlastné prospech. Ešte raz ďakujem za ten link na mailinglist.

[Max]

Rozhodně ne, musíš překopat hodně věcí, hodně scriptů a všeho. Změna init systému není záležitost na týden.
Je třeba myslet na budoucnost, aby se to pak zase nemuselo překopávat (zbytečná práce navíc, dále uživatelé jsou na něco zvyklí a musí měnit atd.).
Zdar Max

[Jiří J.]

Docela mě zklamal openrc:0. ... Doufal jsem, že se alespoň někdo bude řídit rčením "pokud se nemůžeš rozhodnout mezi A nebo B, zvol C". Konec konců openrc je pěknou "evolucí" sysv init skriptů.

Ono to možná dopadne tak, jak předpovídaly spousty komentářů pod oznámením o hlasování na LWN - Debian prostě půjde přes veškerou bolest všech zúčastněných, jen aby podporoval všechny init systémy.

Stejně nechápu, proč se při stavu 4:4:0 nemůže hlasování prostě o release nebo dva odložit. Kdo na to tlačí? Systemd?

[David Jaša]

Kdo na to tlačí? Systemd

Afaik stav debianích initskriptů.

[paul]

Nejhorsi na tom je, ze psat prehledne a jednoduse initskripty jde ala styl BSD v Archu(pred systemd) nebo Slackware. Ty SysV init rc postradaly v zakladu tu jednoduchost a podle me to muselo driv nebo pozdejc skoncit bordelem. S tou komplexnosti systemd to analogicky vidim taky jako cestu do pekel.

Mimochodem, uvazuje Debian taky o prechodu na jiny zpusob tvorby balicku ? Ty jejich automagicke devhelpery, devscripty, dh-makery, dpkg-buildery a stokrat prekopavane rules jsou taky sila.

[Robert Smol]

Tak prave systemd ma vyhodu v tom, ze napises init script (a ten muze byt opravdu trivialni) jen jendou a bezi ti na vsech dsitribuci.

[paul]

Ten initscript muze byt sam o sobe trvialni, ale to je uplne jedno. Na komplexnosti systemd to nic neubere. Jen obsluha zurnalu je rozsahlejsi nez cely sysvinit a to ma systemd tech modulu desitky.

[little.owl]

To je ale jina vec - moduly systemd kanibalizovaly funkce jinych casti systemu - a pak to musite srovnavat nejen s init ale treba i syslog a dalsimi vecmi, vcetne cele kupy veci ktere potrebovaly init scripty..

[Gilhad]

Srovnám tedy srovnatelné - jak systemd, tak Windows kanibalizují zbytek systému a jak systemd, tak Windows mi nesmí na počítač.

[little.owl]

systemd (komponenta) a Windows (OS) jsou podle vas srovnatelne veci?

[David Jaša]

dej tomu pár let, a budou. :-]

[little.owl]

[little.owl]

Co je to za party, kdyz tam vsichni chodi rovne?

Konecne neco k ARMu portu, Martix, thumbs up.

[little.owl]

Ja jsem ale vul, spatna diskuze, cas jit spat.

[foobar]

Pro OpenRC chteli hlasovat vsichni, ale byli ovlivneni klasickym dilematen volice 'nebudu hlasovat pro malou stranu, je to vyhozeny hlas' :)

Jsem prekvapeny, ze je to remiza - nebyla nedavno mezi vyvojari Debianu nejaka anketa, ze ktere vzesel vysledek, ze uplne vsichni (nebo aspon velka vetsina) chteji systemd?

[Jiří J.]

ale byli ovlivneni klasickym dilematen volice 'nebudu hlasovat pro malou stranu, je to vyhozeny hlas' :)

Taky mě to dodatečně napadlo, to je pravda.

Asi to v IT vzdám a půjdu někam do jižní Ameriky pěstovat jablka, protože současnou situaci kolem systemd snad ani nejde brát vážně.

[marvn]

pokud by pro nej chteli hlasovat vsichni, tak by byl prece velkou stranou, dokonce tou nejvetsi! zbytek tve uvahy pak nedava smysl...

[Hans1024]

Me to taky stve, uz se kvuli tomu i nekdo poradne vztekal na mailing listu. Argumentuje se vetsinou tim, ze rovnou muzou pouzit upstart, ktery taky pujde na jinych jadrech a umi toho vic. Coz je podle me hodne blby napad, protoze budou muset kvuli skvelemu Canonicalu udrzovat vlastni patchset (pokud to neforknou).

[AsciiWolf]

Docela mě zklamal openrc:0. ... Doufal jsem, že se alespoň někdo bude řídit rčením "pokud se nemůžeš rozhodnout mezi A nebo B, zvol C". Konec konců openrc je pěknou "evolucí" sysv init skriptů.

+1

[Sešívaný]

Stejně nechápu, proč se při stavu 4:4:0 nemůže hlasování prostě o release nebo dva odložit. Kdo na to tlačí? Systemd?

Patová situace to není. Předseda komise má v případě remízy právo rozhodnout a předseda zrovna v tomto případě stojí za systemd. Jenže, aby to nebylo tak jednoduché, tak zvolení systemd může odporovat jednomu z článků ústavy Debianu (počítám, že to souvisí s nepodporou ostatních jader) a na změnu ústavy potřebují nadpoloviční většinu. Prostě velká politika. A já jsem si myslel, že ve Fedoře děláme rozhodnutí s velkými porodními bolestmi

[lyon]

A já jsem si myslel, že ve Fedoře děláme rozhodnutí s velkými porodními bolestmi

Nekdo musel tu slepou ulicku lidskeho poznani ohledat a ohlasit svetu: Tudy ne, pratele!

[Bedňa]

Keď chceš vybudovať komunitu, musíš sa riadiť pravidlami čo vyhovujú väčšine. To by som s nejakým detským vydupkávaním manažéra s Red Hat neporovnával.

[Sešívaný]

Jako vtip dobré. Jde vidět, že nemáš moc tucha, jak to ve Fedoře chodí. Někdy si až říkám, že by bylo možná lepší, kdyby o věcech ve Fedoře rozhodoval někdo autoritativně z Red Hatu.

Jinak k těm pravidlům, které vyhovují většině: mezi systemd a Upstartem je to momentálně remíza a dávám šance spíše Upstartu, ale i někteří hlasující pro Upstart přiznávají, že pro čistě linuxový Debian by byl systemd výhodnější. Prosazení systemd tedy zastavila hlavně ta nepodpora ostatních kernelů. Věc je ta, že ~99 % uživatelů Debianu používá primárně linuxový kernel, takže v tomto případě se díky těmto pravidlům musí přizpůsobovat naopak většina hodně malé menšině. Neříkám, že je to nutně špatně, ale je to tak.

[Bedňa]

Začnem od konca, Všetko sa samozrejme môže zmeniť hlasovaním (Debian).

Upstart je relatívne malý projekt a dá sa ľahko udržiavať, ja viem že mi každý nedá za pravdu, ale tá unixová filozofia ma oslovila, keď som s Linuxom začínal. Pokiaľ systemd čoskoro neumrie požerie aj kernel, tak to vidím ja. Je to rozhodne prvý init kde sa vie viac o autorovi ako fjučúrach.

Som rád že slobodné myslenie vo Fedore stále existuje. Tak máš pravdu poznám len tie zákulisné kecy :)

[Michal Kubeček]

Jestli jsem to dobře pochopil, Debian zatím neplánuje model "one init to bind them all", ale hlasuje se o defaultním init systému. Takže bych si dokázal představit i takový výsledek, že na Linuxu bude defaultem systemd a nad ostatními jádry třeba upstart.

[Mti.]

Zeptam se mimo misu... kdyz sem potreboval vedet na ne zcela znamem stroji, co mam k dispozici, stacilo neco jako "ls /etc/init.d". Jak se to dela "usporne" se systemd? Nasel sem "systemctl list-unit-files --type=service" ... to aby si jeden teda pamatoval novoty... :-/ Jde i o to, jak se ta sluzba jmenuje. Typicke je "httpd" na redhatech a "apache2" na debianu... No nic, zvyknu si, treba.

[Michal Kubeček]

Člověk si zvykne i na šibenici…

[PetrHL]

To asi ano, ale maji vyvojari systemd kolem sebe i lidi, kteri to budou muset kazdy den nejak pouzivat? Nekoho, kdo by jim rekl "Tak takhle ne panove, to je totalni kravina protoze ....". Ja jen aby neresili nejaky problem, ktery predtim vlastne problem nebyl.

[Michal Kubeček]

To asi ano, ale maji vyvojari systemd kolem sebe i lidi, kteri to budou muset kazdy den nejak pouzivat?

Přinejmenším někteří by měli mít kolem sebe lidi, kteří budou muset záhy řešit reporty od zákazníků RHEL7. Jestli to aspoň trochu pomůže, to se uvidí.

Ja jen aby neresili nejaky problem, ktery predtim vlastne problem nebyl.

To je ale samotná podstata, systemd, ne? :-)

[Mti.]

Ja jen aby neresili nejaky problem, ktery predtim vlastne problem nebyl.

To je ale samotná podstata, systemd, ne? :-)

[paul]

+1

[Mti.]

Dik. O to ( jen zvykat si, ne na provaz :-/ ) se uz chvilu snazim a porad to musim na fedore hledat. Preci jen apache/ssh/sambu povoluji na stroji tak 1x za rok... a na debianech mi zatim prochazi puvodni konstrukce. A totez ifconfig a za chvilu aj iptables

[xvasek]

Člověk si zvykne i na šibenici…

Ale tak přežili jsme devfs, přežijeme i systemd / upstart. Co mě štve je, že padesát let jely UNIXy na rc skriptech a staticky vytvořeném /dev (a vysvětlit / ukázat to nekomu trvalo asi 5 minut) a najdenou se to za posledních 10 let musí nutně čtyřikrát přepsat. Dobře už bylo...

Na druhou stranu vznikají zase jiné dobré věci - když mám tento splín, tak si jdu někam spustit "git pull" a ještě mu předtím nějak upravím zdroják, ať se u toho tak nenudíme.

[Michal Kubeček]

To je IMHO docela rozdíl. Důvody, proč nešlo zůstat u staticky vytvořeného /dev, byly docela jasné a srozumitelné. Že devfs nebyl správný způsob, jak ten problém řešit, to je věc jiná - a proto nakonec vznikl udev. Oproti tomu systemd "řeší" problémy, které byly uměle vymyšleny, aby bylo jak zdůvodnit jeho existenci. Viz třeba "socket based activation" - naprostý nesmysl, který nadělá víc škody než užitku, ale najednou se budeme tvářit, že bez toho nemůžeme žít.

[xvasek]

Jo, uznávám že je to jiná káva, ale já si i život se staticky vytvořeným /dev umím představit. Člověku stačil mknod, dvě čísla a ovládnul svět.

[Michal Kubeček]

Problém byl právě v tom, že těch, kterým to nestačilo, bylo čím dál víc.

[Gilhad]

Ja právě přemýšlím, není-li čas od udev udělat krok dál právě k tomuto statickému vytváření. Poslední dobou kdykoli se mi něco chová divně, tak je za tím udev.

[R]

Takze pripojim USB klavesnicu, idem do konzoly a pisem (bez klavesnice):

mknod /dev/input/event0 c 13 64

A nasledne restartujem X11?

Ja si radsej necham ten udev.

[potato]

Typicke je "httpd" na redhatech a "apache2" na debianu...

To se tak jmenovalo, co pamatuji, a se systemd to nesouvisí...

Výpis pomocí ls je víceméně ls /usr/lib/systemd/system/*.service, ale, pravda, ne tak docela...

[Mti.]

ten apache je "jen" priklad. Napsal sem ho mimo jine proto, ze o nem zrovna "dobre" vim. Jenze takovych je vic a po tech se potrebuju porivat, jak se jmenuji (ssh/sshd/openssh... treba ..kdyz zkousim naslepo, je to vetsinou posledni z nich bez ohledku v jakem poradi to zkusim ).

Variantu s ls /etc/init.d povazuji za o neco kratsi. Uvedena varianta se systemctl mi nevadi kvuli prvnimu prikazu... jen ze je to proste "jinak" a je to "delsi" ... no ale zvykam si pomalu. Minimalne na to, ze si budu muset zvyknout.

[Robert Smol]

nestaci ti prikaz systemctl jako takovy? Me po jeho napsani a spusteni to vypise asi tak 2 stranky sluzeb, coz se nelisi od "ls -l /etc/init.d/". Pripadne systemctl|grep service a mas to i s popiskem....

[Mti.]

JUUU! Funguje to. Dekuji. To se pamatuje mnohem lepe nez ta dlouha verze.

[Adam Pribyl]

Nutno dodat ze samotne "systemctl" nevypise vsechny sluzby.. ze. Viz man.

[little.owl]

A vetsina z tech, co jsou pro upstart jsou nebo byli na vyplatni pasce Canonical.

[Rezza]

A neni to jedno na ci je vyplatni pasce? Tohle bohuzel ve Fedora slysim porad, jak lidi placeni firmou nejsou komunita...

[Hohot]

Není, protože v případě opačné volby, příští měsíc už na té výplatní pásce být nemusí. A hypotéky se platit musí.

[little.owl]

Ale ja nerikam, ze nejsou casti komunity. Jen v rade pripadu tam muze byt konflikt zajmu a do toho na cem delaji a prosazuji se promitaji obchodni zajmy toho kdo je plati, a oni v rade pripadu nemusi mit silu/moznosti se tomu vzeprit.

Fedoru vnimam jako urcitou symbiozu - na jedne strane ji Red Hat tlaci smerem co potrebuje, a jsem pak tak trochu tester veci ktere nepotrebuji, na strane druhe mi ale dava/financuje plno veci/kodu ktere pouzivam, takze s tim nemam problem.

[paul]

Nj, ale vy si zrejme dokazete udrzet odstup/nadhled. Takovej ale bohuzel neni kazdej ;)

[Ján Dráb]

Ja si naopak myslím, že to úlohu nehrá. Keď raz niekto "sedí v debiane tak vysoko", zrejme to nebude pre jeho modré oči a ani preto, že by pre debian nič nerobil. Tiež si myslím, že nik z nich by nemal veľký problém nájsť si prácu a Canonical by si to tiež veľmi rozmyslel nielen kvôli PR. ale kto som ja :B

[Sešívaný]

Zajímavé bylo vyjádření Kaye Sieverse, že před tím, než začali dělat na systemd, tak se snažili přesvědčit právníky Red Hatu, aby mohli dělat na Upstartu i navzdory CLA, a nebylo jim to dovoleno.

Ta CLA bude problém i pro Debian. Pokud systemd nechtějí, protože nepodporuje jiná jádra, tak si myslím, že z dlouhodobého hlediska by bylo lepší jít spíš do OpenRC, i když z těch tří je na tom co se týče funkcionality momentálně nejhůř.

[belisarivs]

Muzu se zeptat co v OpenRC proti Systemd chybi?
http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
http://wiki.gentoo.org/wiki/Comparison_of_init_systems

[Sešívaný]

Takovéto srovnávací tabulky jsou s promínutím na dvě věci. yes/no neříká nic o tom, jak moc je to kompletní, jak dobře implementované, spolehlivé. Nechci OpenRC nijak hodnotit, protože s ním nemám zkušenosti. Jen jsem vycházel z Debianích diskusí, kde se většina lidí shodovala, že systemd a Upstart jsou, co se týče funkcí, momentálně někde jinde než OpenRC. Nicméně když se dá OpenRC šance a bude kolem toho živá komunita, může to být dlouhodobě nejlepší volba pro Debian, protože to nemá dvě pro Debian zásadní nevýhody konkurence: není to Linux-only a nemá to CLA.

[Rezza]

Zajimava verze historie - jsem taky veril, te verzi, co tam pise Adamw. I s tim, ze systemd ani nevznikal jako RH projekt puvodne, ale bokem, aby to pres RH proslo (ci byl donunec k tomu, aby to proslo . Ale Canonical CLA je v tomto fakt hodne limitujici. Ono i Qt CLA pusobi problemy - Marcin se ted snazi podepsat... Ale tam je aspon ta KDE/Qt pojistka.

[little.owl]

A jak resi KDE pojistka mozne patenty v Qt?

[Rezza]

Tak teoreticky by licence na ty patenty mela prejit taky, tim jak je napsane to licencovani v CLA. Ale to je opravdu otazka pro pravniky. Kazdopadne souhlasim s Linusem, kazde CLA je zlo.

[little.owl]

Nevim. Patenty, podle CLA, stale vlastni kontributor kodu, s tim ze je dava k dispozici uzivatelum Qt. Problem je v tom, ze fork, pod hlavickou KDE vcetne, podle vseho nemusi byt z pravniho pohledu Qt SW, tutiz uzivatel forku nemusi mit pravo je uzivat.

[Rezza]

Nad tim jsem prave uvazoval - do jake miry je tady kryti.

[little.owl]

No, Digia obchodne vyuziva toho ze to moc kryte neni.

[ivan]

Co je tak spatnyho na CLA? Myslim, ze neprijimani patchu je jeste vetsi zlo. Napr:
Eclipse se tvari jako "Java only project" a odmita patche, ktere by zlepsily podporu jazyka Scala.
Mono se tvarilo jako "Suse only project" a odmitalo patche od Fedory.

<konspiracni teorie > systemd je "RHEL only project" a odmitlo by patche od Ubuntu a FreeBSD</konspiracni teorie >

[David Jaša]

<konspiracni teorie > systemd je "RHEL only project" a odmitlo by patche od Ubuntu a FreeBSD</konspiracni teorie >

Zjevně má máslo na hlavě v tomto směru každá opensoucová společnost, nicméně u RH tipuješ úplně blbý projekt. ;) Do systemd připívá dost lidí odjinud.

[little.owl]

systemd je "RHEL only project" a odmitlo by patche od Ubuntu a FreeBSD

Tohle tvzeni je v soucasnosti jiz zcela mimo realitu. Do systemd prispiva jiz tolik vyvojaru odjinud, z jinych distribuci, ze to jiz nelze oznacit za "RHEL only project". Treba posledni vetsi zmena, ktera me zaujmula -DHCPv4 support in networkd - je od Tom Gundersen, coz je vyvojar Arch a spolupracoval na tom s vyvojari ConnMan - sdili kod.

[Sešívaný]

No, dále v diskusi to potvrdil i bývalý vývojář Upstartu, že opravdu s Lennartem řešili jejich zapojení do projektu a že to celé lehlo právě na CLA, takže já bych tomu i docela věřil.

[little.owl]

Tak, Remnant:

But I don't need that self-affirmation anyway :) I wrote Upstart, I got paid for it, I moved on to do other things, something else came along and replaced it. If Upstart hadn't been under the CLA, and systemd hadn't've happened, all my code would have long since been rewritten by now anyway.

[little.owl]

Z dlouhodobejsiho hlediska je nejlepsi systemd, cokoliv jineho je bude stat plno zdroju.

[Sešívaný]

Oni chtějí mít svobodu výběru kernelu a svoboda vždycky něco stojí.

[little.owl]

Chtit a moci jsou dve ruzne veci.

[xvasek]

Nemyslím, že zronva v tomto případě. Kdyby chtěli, tak celý funkční init se dá napsat za odpoledne asi tak 1kB dlouhým scriptem, takže tady nikdo nikomu nůž na krku nedrží. Jenom si svobodně vybírají oprátku, nak teré se později oběsí.

[little.owl]

Jde o zavislosti, systemd se bude pomalu a jiste stavat komponentou na ktere bude zaviset plno dalsich klicovych veci, vcetne vazby na kernel. Pokud ho nekdo nepouzije, vlastni init bude ten z nejmensich problemu, ktere bude nucen resit.

[xvasek]

O jaké závislosti jde? (Fakt se ptám, bez ironie. )

[Michal Kubeček]

Např. u desktopových prostředí to může být závislost na logind.

[little.owl]

V podstate cele jadro OS nad kernelem, vcetne Gnome. Gnome sice pouzivat nemusite, ale systemove veci jako udev, login, logovani, spravu sessions, management systemovych prostredku ci power management budete potrebovat. Souvisejici kod bez systemd bud fungovat nebude, nebo bude zmrzacen ci dostatecne neotestovany.

[paul]

Bejt trochu paranoidni, tak zrovna tohle bych videl jako jeden ze skutecnych duvodu prosazovani systemd. Proinvestovany miliardy, vysledky pod ocekavani a svet OS i Linuxu si zije vlastnim zivotem a na LSB kasle. To by ale takhle dal neslo ;)

[Rezza]

Presne tak, psal jsem uz vyse. I Lennart uz zacina slajdy tim, ze systemd neni init a init je tam jen malou casti.

[Sešívaný]

Já myslím, že je na čase změnit korektní název z GNU/Linux na GNU/Lennart/Linux. Všechno k tomu směřuje

[marvn]

mas to blbe, pokud tak "GNU/SystemD/Linux" nebo "RMS/Lennart/Linus"

[rbc]

Salamova metoda. Pritom je to kratce, co se vyvracely obavy pochybovacu, ze systemd je jen volitelna alternativa a ze zadneho umeleho vynucovani zavislosti jinych kritickych aplikaci dochazet nebude. Vzpomnel jsem si na zdejsi zpravicku Michael Stapelberg vyvrací obavy před složitostí a počtem závislostí systemd. Ha, ha. Za skoro osm let co se venuju linuxu jsem takovy znasilneni ekosystemu nezazil.

Btw. chtelo by to aktualizovat obsah hesla na Wikipedii.

[marvn]

a co teda meli vyvojari gnome pouzit, kdyz ne logind?

ja zas za poslednich 8 let nezazil podobne znasilnovani rozumu, jake je kolem init wars...i kdyz vlastne jo, browser wars byly obodobne krute :P

[Rezza]

Hlavni je, ze to davno nejsou init wars, ale spodek systemu wars :D. Az teda na kernel, Linusovi je to uprdele.

[Adam Pribyl]

Otazkou je, kolik z tech prostredi nad jinym kernelem je neschopno fungovat se systemd, resp. jak moc ze systemd muze zbyt pro jine kernely. Treba by prave to, ze na nej prejde debian do nej dotlacilo nejaky rozumny kompromis kompatibility s jinymi jadry a trochu pribrzdilo tu explozi systemdemonu.

[Rezza]

Vem si, ze ultimatni cil jsou LinuxApps - v baliccich dostanes jen zaklad (i kdyz i to je dnes otazkou) a zbytek budou LinuxApps. Ve chvili kdy na to upstreamy prejdou... Nektere budou asi agresivnejsi v podpore, nektere min a vzdycky budou builditelne zdrojaky, ale asi mensi zajem.

[xvasek]

Něco jako CPAN 2.0?

[\/]

Já bych chtěl daemontools nebo runit.

[xm]

Spolupracovat s DJB by muselo být ještě snad horší než s Lennartem

[\/]

Používal jsem to to léta, ale na serverech. Nejprve daemontools, teď runit. Teď v poslední době jsem už nějaký líný starat se při instalaci a upgradech o ty scripty na spouštění různých daemonů. Ale bez logování á la DJB nemůžu být ani teď. Na to používám socklog.

[Stanislav Brabec]

Zajímalo by mne, kolik z těch, kteří tak nadávají na systemd, někdy důkladně prošlo init skripty a skripty na spouštění sítě.

Nevěřili byste, kolik hnoje se tam za desítky let jejich existence nahromadilo. A to jen proto, že sysvinit neumí rozumně vyřešit tak jednoduché věci jako spouštění démonů až po naběhnutí sítě či plné inicializaci jiného démona jinak než sekvenčním spouštěním nebo čekáním ve smyčce.

A to nemluvím o tom, že v každé distribuci je ta kupka hnoje trochu jiná, a trochu jinak smrdí.

Kolik je v sysvinit a ifup skriptech neodhalených race condition, kolik způsobů, jak to může jednou za x startů selhat… Někdy stačí, aby DHCP server odpověděl o pár sekund později než obvykle.

[Michal Kubeček]

Zajímalo by mne, kolik z těch, kteří tak nadávají na systemd, někdy důkladně prošlo init skripty a skripty na spouštění sítě.

Např. já ano.

Kolik je v sysvinit a ifup skriptech neodhalených race condition, kolik způsobů, jak to může jednou za x startů selhat…

…zatímco se systemd to nikdy neselže a race conditions jsou z principu vyloučeny? Nebo co jsi tím chtěl říct?

A to je potřeba navíc vzít v úvahu, že na rozdíl od klasických init skriptů se systemd s těmi opravdu výživnými konfiguracemi (ať už jde o síťování nebo třeba storage) zatím nepotkal. Tahle legrace nás (i RH) teprve čeká.

[R]

A systemd teraz vsetky problemy carovnym prutikom vyriesi? Nevyriesi. Niekolko ano, niektore nie a prida dalsie.

[Ivan]

Ja naprklad ano. Dokonce jsem prochazel i takovy obludnosti jako byl "xinitrc" na IRIXu anebo "bosboot" na AIXu. A se v sim jsem si nakonec poradil. Selhal jsem ale napriklad u binarniho "mkinitrd" na Linuxu, nedokazal jsem to presvedcit aby mi to dalo na RAM disk vsechny FC ovladace vcetne multipath. Po 15ti letech prace s ruznyma Unixama ma spis strach z ruznych hyper-inteligentnich binarek nez z prasackych sh scriptu.

[j]

+1 ... script v nejhorsim vemu a nahradim svym ... binarni blob, kterej bude delat vsechno ... a nahradit nepujde ... si asi jen tak nekdo nespravi.

[Roslav]

Este ze im Valve uvolni hry. Mozy si dat zapas v CSku a ktora strana vyhra, toho init sa bude pouzivat. Len nevim ci sa k teroristom viac hodi systemd ci upstart.

[Michal2]

Hmm ja jen doufam, ze i po te zmene
/etc/init.d/nazevsluzby start/stop/restart
udela to, co potrebuji. Byl by to bez toho jeste Linux?

Proc musi vsechno kmomplikovat. /dev byl ok, dalo se v tom vyznat... a pak to podelali s devfs a udev kde kdyz neco nefunguje, tak aby mel clovek specialistu na udev. Stejne tak alsa bez zbytecnych nadstaveb (zejmena pulseaudio), ted systemd...

[David Jaša]

Hmm ja jen doufam, ze i po te zmene
/etc/init.d/nazevsluzby start/stop/restart
udela to, co potrebuji. Byl by to bez toho jeste Linux?

Byl, protože na některých systémech se sysv(-style) initem ti ani tohle neudělá to, co potřebuješ. Tedy pro stop udělá, ale ten start/restart bys podělal.

[rbi]

?! Start sysv-initskriptu muze selhat, ale pro vetsinu smrtelniku je daleko snazsi se v nem vyznat, najit zdroj problemu a pripadne ho upravit aby fungoval jak ma. To si u systemd, tedy nad urovni konfiguraku, muzu nechat jen zdat.

[David Jaša]

Odpovídáš na něco zcela jiného, než jsem psal.

[Foo Bar]

Sorry, ale to jsou akorát fanaticke pindy bez navaznosti ma realitu. Debugovani spagetoveho sysvinit skriptu je vsechno jen ne jednoduche.

[Foo Bar]

Abych byl konkretni. Presne z duvodu toho, ze sysvinit skript je naprosto nemozny nam nas gitlsb aktualne bezi ve dvou systemd jobech, protoze gitlab sidekiq job padal nekdy az po spusteni gitlabu a nejakem poctu spustenych uloh na pozadi.

Debuggovani (nakonec to byla nejaka kombinace gitlabu a verze ruby) bylo vsechno jen ne jednoduche. Naopak u systemd jobu vidim presne v jakem stavu se proces nachazi a proc zdechnul.

Kecy o tom, ze sprava daemonu pomoci shell skriptu je jednodussi, jsou naprosto odtrzene od reality a spis vypovidaji o tom, ze dotycny nikdy nemusel udrzovat v chodu sluzbu 24/7. Proste djb to mel s daemontools dobre uz pred mnoha lety, ale jeste na to nenastala doba.

[xvasek]

Nesahej mi na Pulseaudio. (Jeho problém je spíš v tom, že jej tlačili všude moc brzy a nutně. Ale myslím, že Debian jej doteď nemá v základní instalaci a když jej člověk chce, tak si jej stáhne zvlášť - což je fajn řešení.)

[rbi]

Asi je to featura, ale PA ma nesnesitelny latence - mam ozvuceny desktop a sampl se ozve po kliku az se sekundovym zpozdenim. Nebo pred spostenim Nexuiz musim pulse audio stopnout a jet jen pres alsu, jinak se animace trha. Obcas chcipne kdyz si hraju s Rosegarden a musim ho rucne startovat.

Asi mam fakt smulu na hardware nebo distro, faktem ale je ze tyhle problemy se samotnou Alsou nemam.