Projekt eudev, fork udev, oficiálně představen

V listopadu vývojáři Gentoo zvažovali fork udev. V sobotu byl projekt eudev, fork udev, oficiálně představen. Jedním z důvodů vzniku eudev je začlenění udev do systemd. Dle oznámení se vývojáři systemd o problémy udev s jinými inity nezajímají (LWN.net).

17.12.2012 06:06 | Ladislav Hagara | Komunita

Komentáře

[BoB]

<ot>Mně to prostě nedá: eudev je speciální fork pro EU?</ot>

[mirec]

Gentooisti - vy ste praví hrdinovia linuxového sveta. Ďakujeme.

[rastos]

Priznám sa, že o systemd viem pramálo a som mierne skeptický. Ako človeku, ktorý občas potrebuje zasiahnuť do boot-skriptov (vložiť vlastný výpis aby som videl čo a prečo sa deje, vložiť "set -x", spustiť vlastného démona, upraviť poradie akcií, prepísať nejakú časť podľa vlastných predstáv, ... ) čo mi systemd prinesie? Bude mať chápanie bootovania systému či spúšťania/zastavovania démonov rovnakú alebo menšiu zložitosť, ako čítanie shell-ových skriptov?

[l4m4]

Chceš-li, aby byl boot řízen skripty, tak otázka nemá smysl, protože systemd v takovém případě nebudeš používat. Typická systemd unita není komplikovaný shellový skript, ale má tak 10 řádků, které říkají, jak se ta věc jmenuje, co to je za typ služby (jen něco nastavuje, forkující démon, ...) a co se má execnout.

[Michal Kubeček]

To je přesně ta filosofie "90 procent běžných situací se bude řešit pohodlněji a zbylých 10 procent nás prostě nezajímá", se kterou mám problém.

[Michal Vyskočil]

Však systemd podporuje LSB init skripty. Tak v čem je pro oněch zbylých 10% (což mi přijde, jako přehnaně vysoké číslo) ten problém?

[Michal Kubeček]

Dobře to ilustruje třeba historie kolem ExecStatus, který se sice AFAIK nakonec prosadit podařilo, ale dost dlouho vývojáři systemd jen opakovali, že služba, která by něco takového potřebovala, je špatně navržená a nezapadá do koncepce. Z aktuálních problémů jsou to třeba pm-utils, které má také systemd nahradit jako přežitek - implementuje ovšem zase jen část funkcionality.

[mrv]

coz vubec neodpovida na otazku co je tech 10%

[Michal Kubeček]

Kdybych si nemyslel, že odpovídá, nepsal bych to jako odpověď. Těch 10 procent (obrazných, nedělám si přesnou statistiku) jsou ty use cases, které mají tu smůlu, že panu Poetteringovi a spol. nazapadají do jeho koncepce a představy, co má právo existovat.

[blami]

Nikoliv. Systemd opet pokryje jen 90% bezne potrebneho a v pripade, ze se v tom nekdo bude chtit vrtat muze ty eventy systemd nechat byt (jednoduchym nastavenim) pro utility jako pm-utils, pripadne jen pozdrzet eventy na ne vazane (tzv. inhibit session) jak to pouziva treba gnome-settings-daemon. Jinak pm-utlis se systemd pouzivam a nemam nejmensi problem.

[Michal Vyskočil]

Žádný ExecStatus podle man systemd.service neexistuje. A ono volání userspace kódu pro zjišťování, v jakém se služba stavu do koncepce systemd vážně nezapadá. I když mi to nepřijde nijak složité tu podporu do něj dodat ...

[Michal Kubeček]

Pak je ta koncepce špatná, protože služby nespočívající ve spuštění démona prostě existují.

[pavlix]

+1

Na druhou stranu lze pochopit, že když si někdo o sobě myslí, že je bůh, že ho napadne požadovat, aby se všechny služby předělaly na démony.

[Ash]

+1

[l4m4]

Zatím jsem neměl problém napsat unitu na cokoli, na co jsem ji potřeboval. Vždy to bylo jednodušší než SysV skript. Když je zle, s oneshot typem lze provést v podstatě libovolnou zvrácenost, IMO včetně těch 10%.

Bojím se, že pro většinu diskutujících systemd a Lennart Poettering jedno jsou, takže kvůli osobnosti hlavního výojáře, který se ovšem po čase přesnue rozvrtat zase něco jiného, zavrhují jinak užitečný projekt.

[Michal Kubeček]

To vůbec není o osobě, to je o přístupu, který dělí ostatní projekty na ty, které je třeba asimilovat, a ty, které je třeba zničit. Dokud se takhle bude vývojový tým systemd chovat, budu proti, i kdyby ho vedl třeba Linus.

[Ash]

+1

[pavlix]

Netvrdil bych, že výtky vůči systemd a především přidružení udev pramení z nějaké nechuti vůči osobě. Spíše naopak.

[Grunt]

Lennart Poettering jedno jsou, takže kvůli osobnosti hlavního výojáře

Já když se dívám na jeho stránky, tak by mě spíš zajímalo kdy on má vůbec čas se tomu vývoji věnovat…

[pavlix]

No... to je velice jednoduché, on projekty pouze začíná, popřípadě „vylepšuje“. Dodělávají a opravují je už jiní. A jak známo, prvotní naprogramování a předvedení nápadu je jen zlomek toho, co je potřeba udělat.

[Majkls]

zas na druhou stranu je potřeba říct, že prvotní návrh je velice důležitý. Když se udělá špatně, tak je kolikrát lepší celou věc zahodit a napsat znova...

[kavol]

kéž by tohle věděli i ti jeho nohsledi ...

[kavol]

To je přesně ta filosofie "90 procent běžných situací se bude řešit pohodlněji a zbylých 10 procent nás prostě nezajímá", se kterou mám problém.

hm, mohu si dovolit toto zkonfrontovat s tvrzením:

"Ne, opravdu si nemyslím, že by bylo žádoucí v roce 2012 zamítat změny prospěšné pro drtivou většinu uživatelů, pokud jediným argumentem proti bude to, že kvůli nim nepůjde nabootovat na systému s 8 MB paměti."

zdá se mi to trošku protichůdné ... v čempak je rozdíl? v tom, že tentokrát jste v těch "10%" (je to vůbec 10%?), zatímco mezi tu minoritu, co se potýká s problémy s pamětí na omezeném hardware, nepatříte?

[Michal Kubeček]

v čempak je rozdíl?

Třeba v tom, že řada z těch projektů, které systemd nezapadají do koncepce, jsou živé, aktivně vyvíjené a velmi užitečné a nemohou za to, že přišel nějaký pan Poettering a prohlásil, že takhle služba vypadat nemá a že na všechno musí permanentně běžet nějaký proces, i kdyby neměl nic dělat. Oproti tomu zařízení s 8 MB RAM jsou (a) stará a už nevyvíjená (b) sice nová, ale výsledkem nesmyslného designového rozhodnutí, protože dát tam víc by mělo na výrobní náklady jen zanedbatelný vliv (a dokážu si představit, že by to mohlo paradoxně vyjít i levněji).

[kavol]

v čempak je rozdíl?

Třeba v tom, že řada z těch projektů, které systemd nezapadají do koncepce, jsou živé, aktivně vyvíjené a velmi užitečné a nemohou za to, že přišel nějaký pan Poettering a prohlásil, že takhle služba vypadat nemá a že na všechno musí permanentně běžet nějaký proces, i kdyby neměl nic dělat.

nejsem si jist, zda "živost" a "aktivní vývoj" jsou podmínkou té užitečnosti a toho, že opravdu není nutné přijít a říct, že se to má dělat jinak

momentálně máme k RHELu podporu nasmlouvanou (resp. standardně nabízíme, co všecko je nasmlouvané ani srnka netuší) na 13 let - v druhé polovině tohoto cyklu už se v distru nicmoc neděje, přesto někdo považuje za velmi užitečné to používat

samozřejmě těžko chtít po všech upstreamech zpětnou kompatibilitu po takovou dobu; v mnoha případech by to bylo opravdu brzdou vývoje ... nicméně nějaké ohledy by se brát mohly, nelze to smést s argumentem "je to opensource, nic nebrání zakonzervovat si fork a backportovat jen bezpečnostní opravy", neb tomu brání právě nedostatek prostředků - Red Hat je "billion dollar company" a stejně se nám ta zpětná kompatibilita nedaří na 100%, natožpak když je to pak záležitost jednotlivce ... takže se divím, že není vůle takovéto pány Poeterringy nakopat někam a jejich nadšené ideály tiše ignorovat, pokud tyto znamenají hafo zbytečné práce navrch v ostatních projektech

Oproti tomu zařízení s 8 MB RAM jsou (a) stará

to je nefér argument ve srovnání hardwaru se softwarem; zatímco software se dá měnit dle libosti zdarma (resp. za náklady typu zanedbatelný díl paušálu na připojení k Internetu), hardware se zdarma nerozdává (ba dokonce něco stojí i likvidace starého ...)

kriteriem by tedy mělo být, zda je něco nadále schopno plnit svůj účel či nikoliv (ostatně to by mělo platit u software)

a už nevyvíjená

a není toto tak trošku argumentace kruhem? - nebudeme to podporovat, tak to nebude vyvíjené, a když to není vyvíjené, tak to nemá smysl podporovat?

(b) sice nová, ale výsledkem nesmyslného designového rozhodnutí, protože dát tam víc by mělo na výrobní náklady jen zanedbatelný vliv (a dokážu si představit, že by to mohlo paradoxně vyjít i levněji).

bohužel i s takovými zařízeními musí uživatelé žít; tady opravdu nevidím rozdíl, házíte přes palubu to, co nezapadá do vaší představy zařízení, které chcete podporovat, stejně tak jako Lennart hází přes palubu vše, co nezapadá do jeho představy jak má vypadat služba - jiní lidé měli jiný názor, na to jak to má vypadat, oni nemohou za to, že přišel nějaký pan Linus a prohlásil že zahodí kus zpětné kompatibility, ale vy ten jejich názor, stejně jako Lennart, označíte za "nesmyslné designové rozhodnutí" ...

jakkoli se shodneme na tom, že by bylo krásné, kdyby se hardware nedělal poddimenzovaný, tedy i s nějakým "větším než malým" (dle aplikace) množstvím paměti, tak v tomto případě mi vaše argumentace přijde schizofrenní, jestliže brojíte proti "filosofii 90 a 10 %" a přitom ji sám uplatňujete

[Michal Kubeček]

Holt nezbývá než to uzavřít s tím, že já tam ten rozdíl vidím a vy ne. Obávám se, že sebedelší diskuse by na tom nic nezměnila.

[rastos]

Ja netrvám silou mocou na tom, aby boot bol riadený skriptami (hoci priznám, že mi to vyhovuje). Pýtam sa do akej miery je zložité rozumieť tomu, kedy sa čo stane a prípadne to preskúmať alebo ovplyvniť.

A "nebudeš používať" by mi vôbec nevadilo, pokiaľ sa budovanie blbuvzdornosti systému nezačne preháňať a nepretlačí sa ako tá jediná správna cesta úplne všade. Lebo teoreticky môžem fungovať aj s KDE 2.0, ale backportovať všetko o 10 rokov dozadu ma nenapĺňa nadšením.

Ono je to fajn, pokiaľ je to komplikované a funguje to samo. Ak to funguje. Keď to prestane fungovať, tak je to prúser. A definícia toho, kedy to "prestane fungovať" je na Linuxe občas veľmi veľmi blízko definícii "takto sa mi to nepáči a chcel by som to troška inak".

[mrv]

http://0pointer.de/public/systemd-man/systemd.unit.html (Before=, After=)

[l4m4]

Pýtam sa do akej miery je zložité rozumieť tomu, kedy sa čo stane...

No, asi jako u čehokoli jiného umožňujícího paralelismus a definujícího pořadí pouze implicitě, vazbami -- jako třeba Makefile.

[Člověk z Horní Dolní]

Tady je porovnani systemd, sysvinit a upstartu: http://0pointer.de/blog/projects/why.html

[Michal Kubeček]

Pokud by to někomu z té stránky nebylo jasné na první pohled: autorem "porovnání" je autor systemd a míra objektivity tomu odpovídá.

[Grunt]

Tak nějak mě napadá „Kdo nevěří, ať tam běží“ a pak ať plká po zprávičkou na ABC. Soudit ještě před prvním spuštěním je špatné.

[Michal Kubeček]

Co prosím? Kam mám běžet? Tu stránku jsem samozřejmě četl, jinak bych se těžko vyjadřoval k jejímu obsahu. Viděl jsem i konfiguraci systemd a viděl jsem ho i v chodu. Viděl jsem, jak systemd lobby přistupuje k těm, kdo "neprozřeli". Tak kam mám ještě běžet?

[Grunt]

• stránku jsem samozřejmě četl
• Viděl jsem i konfiguraci
• Viděl jsem

Work complete, že? V takovém případě už je jediné místo kam se dá běžet.

[Michal Kubeček]

Work complete… to určitě ne. Ale na to, abych věděl, že systemd nechci, pokud nedojde k zásadním změnám v pojetí projektu a chování ke zbytku světa, a abych si udělal obrázek o té propagandistické stránce a objektivitě toho "porovnání", to stačí.

[pavlix]

Tak hlavně když někdo srovnává init systémy a úmyslně zahrne pouze svůj a takové ty staré dřevorubecké. To je jak kdybych srovnával Windows s DOSem a OS/2 a dělal ramena, jak jsou Windows skvělé a moderní.

[Ovocníček]

Šak i sou. :P

[pavlix]

Právě. A přesně stejně je to se systemd.

[j]

Sak jo, i windowsaci milujou svoje registry (kdyz se neco posere, tak spravovat jakejsi binarni blob ...), nemoznost upravit boot menu v jednoduchym textaku (slo v XP) ... mam pokracovat?

[pavlix]

Nevidím souvislost.

[blami]

Protoze kdyby systemd srovnaval se SMF odkud je 90% myslenek minus hnusna konfigurace v XML, tak by to jeste nekomu prislo podezrele. *wink*

[Vskutečnosti Saýc]

Ono SMF je taky bliz windows registrum nez sysVinitu.

[Grunt]

to stačí.

V tom případě blahopřeji.

[michi]

Nějakou takovouhle tabulku jsem úplně čekal

[Tomáš Bžatek]

Wow, drsna tabulka, jak si muze vubec neco takoveho dovolit vystavit?

[Zopper]

Připomíná mi to jakési srovnání od MS "Windows vs Linux" :D

[pavlix]

No to teda. Jako já chápu, že tu tabulku napsal. Ale nechápu, jak se na ni může soudný člověk odkazovat.

[pavlix]

Tady je porovnani systemd, sysvinit a upstartu: http://0pointer.de/blog/projects/why.html

Předpokládám, že OpenRC je vynecháno úmyslně :D.

[mrv]

no jasne, protoze z nej ma strach :nesmyslny smajlik:

i mean, http://goo.gl/CyiGy

[pavlix]

Jsem o tom přesvědčen.

[mankind_boost]

+1

[kavol]

no, já tam spíš postrádám porovnání s launchd a důvod, proč bylo nutno napsat systemd ...

[blami]

IMHO stejny duvod jako proc nebylo uvedeno SMF. Ackoliv se o launchd opira hlavne upstart, rekl bych ze drobet chytrych napadu soudruhu z nekonecne ulice v systemd pristalo tez.

[Michal Vyskočil]

Lennart tě nejspíš chtěl připravit o munici v podobě odporné XML konfigurace. Navíc launchd neumí (viz odkazovaná dokumentace) spouštět démony a z podstaty věci nikdy neslyšel o cgroups, což je dost integrální součást systemd. A taky by v upstreamu chyběla cedule - tady je to Lennartovo.

[Grunt]

tady je to Lennartovo

He, he… ten Lennart podle všeho musí být pořádné lečo.

[kavol]

Navíc launchd neumí (viz odkazovaná dokumentace) spouštět démony

tomuto vtipu asi nerozumím ...

a z podstaty věci nikdy neslyšel o cgroups, což je dost integrální součást systemd.

vzhledem k tomu, že asi slyšel někdy o nějakém jail nebo co že to mají na BSDčku, tak by jeho přeučení na cgroups nemuselo být tak složité

A taky by v upstreamu chyběla cedule - tady je to Lennartovo.

no to asi hlavně ...

já ale jen nechápu ty spousty bojovníků pod touto cedulí povstávajících, proč najednou nejsou ochotni dělat něco pod cedulí "tady je Mekintošovo", zatímco pár let zpátky za tuto ceduli hodlali položit život, a prgat pod cedulí "tady je Bastianovo" prudce odmítali s tím, jak je WebKit huj a KHTML fuj

[Michal Vyskočil]

Navíc launchd neumí (viz odkazovaná dokumentace) spouštět démony

tomuto vtipu asi nerozumím ...

No tak si přečti dokumentaci - cokoli co dělá daemonizaci - čili drtivá většina unixových věcí, nejde pod launchd spustit. Prostě přiohnout launchd směrem k systemd by bylo imnho více práce, než to napsat od začátku.

vzhledem k tomu, že asi slyšel někdy o nějakém jail nebo co že to mají na BSDčku, tak by jeho přeučení na cgroups nemuselo být tak složité

Až na to, že jail a cgroups jsou dvě naprosto odlišné věci, tak dobré ...

A taky by v upstreamu chyběla cedule - tady je to Lennartovo.

no to asi hlavně ...

Jsem rád, že se aspoň na nečem shodneme

[pavlix]

Až na to, že jail a cgroups jsou dvě naprosto odlišné věci, tak dobré

Podle mě se dají cgroups co do schopností alespoň zhruba považovat za podmnožinu jails.

[kavol]

Navíc launchd neumí (viz odkazovaná dokumentace) spouštět démony

tomuto vtipu asi nerozumím ...

No tak si přečti dokumentaci - cokoli co dělá daemonizaci - čili drtivá většina unixových věcí, nejde pod launchd spustit.

stále tomu nerozumím ... o "démonizaci" se snad launchd stará sám, absolutně nechápu, proč by ty věci pod launchd neměly jít spustit

nebo on se na masoxu nedá pustit třebas apache?

Prostě přiohnout launchd směrem k systemd by bylo imnho více práce, než to napsat od začátku.

tady je ovšem špatně již předpoklad, že je třeba něco "přiohýbat směrem k systemd"

vzhledem k tomu, že asi slyšel někdy o nějakém jail nebo co že to mají na BSDčku, tak by jeho přeučení na cgroups nemuselo být tak složité

Až na to, že jail a cgroups jsou dvě naprosto odlišné věci, tak dobré ...

ano jistě, jedna je na BSD a druhá na linuxu ... což se dá řešit mezivrstvou sjednocující rozhraní

anebo jsi chtěl říci, že jail a cgroups řeší principielně něco úplně jiného? - no, nejsem sběhlý ani v jednom z diskutovaných jader, ale dle popisu pro lamy je to +- o tom samém, jak by ostatně naznačoval i pavlixův příspěvek výše ...

[pavlix]

Můžu jenom potvrdit. Jako takové, cgroups nabízejí pojmenované skupiny procesů. K tomu nějaká správá prostředků. V ideálním případě se na tom dá postavit mimo jiné i kontejnerová virtualizace (nevím jak je na tom LXC, ale znám OpenVZ, které akorát ještě potřebuje v kernelu hromadu věcí patchnout). FreeBSD jails mají jako jednu z funkcí kontejnerovou virtualizaci.

Takže když vynecháš přesné hranice, kde začíná grupování procesů, kde správa systémových prostředků, apod, tak je to principiálně úplně to samé.

[David Jaša]

stále tomu nerozumím ... o "démonizaci" se snad launchd stará sám, absolutně nechápu, proč by ty věci pod launchd neměly jít spustit

RTFA:

     A daemon or agent launched by launchd MUST NOT do the following in the process directly launched by
     launchd:

           •   Call daemon(3).
           •   Do the moral equivalent of daemon(3) by calling fork(2) and have the parent process exit(3)
               or _exit(2).

Tedy každý démon pod launchd se musí pouštět s --foreground nebo ekvivalenty - pokud je má. Má je každý z démonů, co jsou k nalezení v linuxových distribucích?

[pavlix]

Nebyl by zase takový problém je opravit. Vždycky jsem měl pocit, že tyhle fork+exit triky jsou debilita.

[kavol]

Tedy každý démon pod launchd se musí pouštět s --foreground nebo ekvivalenty - pokud je má.

což je ovšem trošku jiné tvrzení, než že "to nejde spustit", že?

Má je každý z démonů, co jsou k nalezení v linuxových distribucích?

to nevím, zato vím, že v praxi jsem musel řešit spíše opačný problém, jak některé věci donutit běžet na pozadí, nežli že bych si třeba zmiňovaného Apache nemohl pustit z příkazové řádky bez toho, aby se mi "zdémonizoval" sám

nicméně k počátku diskuse, nezdá se mi, že by vyřešit tuto věc (pokud je ji nutno řešit) mělo být složitější, nežli napsat obdobu launchd from scratch ...

[Michal Kubeček]

Tedy každý démon pod launchd se musí pouštět s --foreground nebo ekvivalenty - pokud je má.

což je ovšem trošku jiné tvrzení, než že "to nejde spustit", že?

Akorát už to pak vlastně není démon. :-) Problém je ale spíš s těmi "čistými démony", kteří takovou volbu nemají. Na druhou stranu, o těch i systemd (tedy jeho vývojáři) tvrdí, že takhle se to dělat nemá.

[pavlix]

Akorát už to pak vlastně není démon.

Ten software? Nebo ten proces?

Na druhou stranu, o těch i systemd (tedy jeho vývojáři) tvrdí, že takhle se to dělat nemá.

A já s nimi naprosto souhlasím.

[Michal Kubeček]

Akorát už to pak vlastně není démon.

Ten software? Nebo ten proces?

Proces, pochopitelně.

[pavlix]

Podle mě kernel nijak nerozlišuje, který proces je proces démona a který není, nebo se pletu?

[Michal Kubeček]

Jádru je to samozřejmě jedno, to je jen terminologie.

[pavlix]

Zjevně se v tomto případě neshodujeme ani v terminologii.

[kavol]

Akorát už to pak vlastně není démon. :-)

aha

pak si to ale chtělo vyjasnit na začátku, co se tím "démonem" myslí, vzhledem k tomu, že i stejná binárka může vystupovat v různých rolích ... nadhodil jsem jako příklad toho Apache, hm, httpd, a ejhle, on to "vlastně není démon", aby to pasovalo do toho, co kolega na začátku chtěl říct ...

[Michal Kubeček]

To je celkem běžné, že se dá stejný spustitelný soubor podle parametrů nebo podle konfigurace spouštět buď jako démon nebo (např.) prostřednictvím (x)inetd.

[kavol]

právě protože toto je běžné, nepochopil jsem, co tím kolega chce říct

[kavol]

Tady je porovnani systemd, sysvinit a upstartu: http://0pointer.de/blog/projects/why.html

                                                                         sysvinit  Upstart  systemd
Specialized professional consulting and engineering services available   no        no       yes

ROFL

[pavlix]

Prostě čurák, to se jinak nedá říct.

[vencas]

V diskusi k té stránce taky bylo:

It would be like comparing VIM and MS Office based on the later point of view : they are different products with different goals, different design philosophy and they target very different markets.

A odkaz na tuto skvělou tabulku: VIM / MS Office comparison chart

[l4m4]

Tabulka je pěkná, nicméně výmluvné je, že i v takové tabulce by měla po pravdě být u vimu skoro polovina chlívečků zelených...

[tydýt]

Škoda že MS Office nesrovnával s Emacs. To by totiž Emacs natrh p*del MS Office.

[cuiviemen]

Srovnavat OS s textovym editorem? :P

[tydýt]

Samozřejmě, Emacs přeci vládne světu.

[Tomáš Bžatek]

Tak ta tabulka me dostala, trefne!

[w4rr10r]

Z pohledu admina.

[pavlix]

Jo, s tím se dá naprosto souhlasit. A u administrátora lze i pochopit, že si nezjišťuje informace o dalších alternativách než těch, které běžně potkává.

[Luboš Doležel (Doli)]

Nezdá se mi tam to o rychlejším načítání modulů, když se to dělá paralelně. Měl jsem za to, že načítání je synchronní a vede k pozastavení všech CPU jader.

To byl ostatně problém na systémech s 4096 CPU, kdy se vyčerpal prostor pid jen na zastavení CPU.

[Michal Vyskočil]

viz tento komentář

Osobně si myslím, že zajímavé důvody pro fokr jsou pouze dva. Jednak samotné sloučení systemd a udev je prostě podivné. A za druhé nemusí uživatelé Gentoo sestavovat systemd, pokud chtějí jenom udev. To je něco, co po sloučení nešlo a Lennart podobné nápady zavrhoval. A je to něco, co trápí především uživatele source-based distribucí.

Na straně druhé, je zajímavé číst podobná prohlášení

In particular, we want better compatibility with existing software such as OpenRC and Upstart

když vím, že současný maintainer udev z Cannonicalu má commit přístup do systemd stromu. To a komentáře o kmod/module-init-tools nevzbuzují zrovna důvěru, že vývojáři eudev vědí, co dělají.

[l4m4]

A je to něco, co trápí především uživatele source-based distribucí.

Co je konkrétně trápí? Těch 20s build time každých několik měsíců, když vyjde nová verze?

[j]

Trebas nechceme mit na svym stroji sracky, ktery nepouzivame a jsou potencialnim zdrojem pruseru.

[l4m4]

Dostáváš 10 bodů z deseti za porozumění psanému textu.

Takže jen kontrolní otázka: O čem je toto vlákno?

[Tomáš Bžatek]

když vím, že současný maintainer udev z Cannonicalu má commit přístup do systemd stromu.

Tak zrovna Martin je take clenem Lennartova gangu, sice je zrejme ze strany Canonicalu docela svazan, ale verim, ze je to jen otazka casu, kdy se do Ubuntu protlaci systemd primarne (neni-li jiz tam nahodou - nesleduju).

[mrv]

tak jasne. stejne jako je kazdej spiknutej proti Okamurovi, to da preci rozum!

[blami]

Nerekl bych ze Martin ma nejak svazane ruce.

[nyan]

Jednak samotné sloučení systemd a udev je prostě podivné.

Kdepak, to jste asi nepochopil, ze cilem systemd je integrace uplne vseho.

[Mordae]

Ano a s trochou štěstí se jednoho dne podaří tam přehodit i konfiguraci síťí a firewallu a Linuxový userspace se zbaví toho posledního humusu, který všichni tak srdnatě brání.

[lyon]

S trochou stesti Lennartovi praskne zilka v hlave a bude od systemd humusu klid...

[pavlix]

Tenhle nápad už tu byl, ale nemyslím si, že by na něco takového mezi systemd vůbec existovalo know-how, takže by buď museli požádat někoho, ať to udělá za ně, nebo by se museli začít učit o sítích, a to zabere dost času.

Ale na druhou stranu to vytvořilo tlak na to, abychom některé věci vyřešili v NetworkManageru, jehož „oblíbenost“ naštěstí nedosáhla takové, jaké systemd.

[nyan]

se zbaví

Ehm... jakoze tim ze neco presunem^Wprepisem jinam se toho "zbavime" ? Skvele promysleno, mily Watsone.

[David Jaša]

netfilter zoufale potřebuje lepší rozhraní, než (programově) nepoužitelné *tables, a oddělit od sebe konfigurace filtrování a routování by taky nebylo od věci. Kdo nevěří, ať si zkusí používat na jednom stroji dva softy, které musí mít každý svá dynamická pravidla.

[Jozef Mak]

Rad by som poprosil o vysvetlenie/linky na to, co mi prinesie systemd.

MOJE bezne pouzitie Linuxu:

Debian server(!)

ziaden RAID, LVM

ziadne extra features

bezny non-server HW (aka PC)

super mi vyhovovalo bootovanie ako mal Potato a Woody (RCx adresare, inittab ...)

bezne vyuzivanie typu apache, squid, firewall

Ozaj tematike velmi nerozumiem a nezaujimam sa (systemd, udev ...) Vo vseobecnosti sa asi o5 budem musiet. Ale to, ako to fungovalo predtym - napr. fstab mi vyhovalo - prislo udev/$nieco - prisposobil som sa, zmenil veci, configs ... Ale PRE MNA a jednoduche servery nevidim nic pozitivne na udev a systemd a pod. "novinkach". Rad sa necham vyviest z omylu.

(detto dash vs. bash) - len musim rucne osetrovat, aby bol vsade default bash a pre istotu ho mam vsede v "automat_install" a este namiesto #!/bin/sh

Proste som za pokrok - ale nie "za kazdu cenu" - a "vsade". Som rad a vdacny, ze mame 4core@4GHz namiesto 1@200MHz a 24" LCD namiesto 15" CRT a este za nizsiu cenu, atd...

Je OK, ak sa update/upgrade nieco, aby sa "to prisposobilo vyvoju" / novym veciam, technologiam ...

Ale mam silny dojem (neviem, ci to plati pre systemd), ze sa vsetko robi pre to, aby "bolo nieco nove" (popr. "ved stare ma uz $X rokov)", popr. "vsetko je desktop".

Dakujem za reakcie z kt. nacerpam.

JM

[Grunt]

Rad by som poprosil o vysvetlenie/linky na to, co mi prinesie systemd.

Vůbec nic.

Ozaj tematike velmi nerozumiem a nezaujimam sa

Však taky tomu nemusí rozumět a mít názor na to úplně všichni co mají mezi půlkama díru.

[mrv]

heh, ted me napadlo, ze podobnym zpusobem by slo trolovat pod kazdou zpravickou o novym softu.

vysla nova verse libpng ...

takze jako ja jsem uzivatel, co pouziva ... a ... . A jako to mi teda vysvetlete, CO MI TA NOVA VERZE PRINESE DOBRYHO?

...

VUBEC NIC? TAK TO STFU, dete s tim nekam, linux windowsovati, a ja jsem proste PROTI!!!!!!!!!

[Grunt]

heh, ted me napadlo, ze podobnym zpusobem by slo trolovat pod kazdou zpravickou o novym softu.

Já netroluju. Já to myslím zcela vážně. Proč by každý soft, který se vyvíjí měl sloužit zrovna tobě? Tobě to nepřinese vůbec nic, což ale ještě vůbec neznamená, že to radši ani nemělo vzniknout. Něco málo to zase přinese třeba někomu jinému.

[Mordae]

Tohle by se nehodilo?

# systemctl status httpd.service | cat
httpd.service - The Apache HTTP Server
	  Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
	  Active: active (running) since Mon, 2012-12-17 15:32:15 CET; 56s ago
	Main PID: 502 (httpd)
	  Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
	  CGroup: name=systemd:/system/httpd.service
		  ├ 502 /usr/sbin/httpd -DFOREGROUND
		  ├ 503 /usr/sbin/httpd -DFOREGROUND
		  ├ 504 /usr/sbin/httpd -DFOREGROUND
		  ├ 505 /usr/sbin/httpd -DFOREGROUND
		  ├ 506 /usr/sbin/httpd -DFOREGROUND
		  └ 507 /usr/sbin/httpd -DFOREGROUND

Dec 17 15:32:13 localhost.localdomain systemd[1]: Starting The Apache HTTP Server...
Dec 17 15:32:13 localhost.localdomain httpd[502]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using localhost.localdomain. Set the 'ServerName' directive globally to suppress this message
Dec 17 15:32:15 localhost.localdomain systemd[1]: Started The Apache HTTP Server.

On totiž systemd skutečně ty procesy sleduje, narozdíl od SysV initu v kombinaci se skripty. Například při přepínání runlevelu pohlídá, že opravdu běží jen to, co běžet má a případné sirotky zabije.

[elenril]

Hlavní problém tady není to, zda je systemd dobrý nebo špatný init systém. Problém je především v tom, že ta sebranka co ho vyvíjí se pokouší o klasický vendor lock-in. Udev používá s Linuxem prakticky každý, takže když bude udev fungovat pouze se systemd tak všechny alternativní init systémy jdou do kytek. A vendor lock-in je zkrátka zlo, at už je systemd jakkoliv úžasný.

Ano slyšel jsem ty prohlášení, že udev bude pořád fungovat i samostatně. Ale po výrocích jako je tenhle už tomu moc nevěřím. Takže forku přeju všechno nejlepší.

[Grunt]

Osobně jsem také rád, že fork vznikl. Teď alespoň každý bude mít na výběr a bude si moc vědomě zvolit. Čímž chci říct, že pokud nevolil pod vlivem, tak není výmluvy na neustále frflání a budu odmítat to tolerovat. Jen mě štve, že to není zařazeno do nějakého oficiálního stromu jako třeba nějaký modul kdy při kompilaci si každý může zvolit jestli udev samostatně nebo společně se systemd.

[Václav HFechs Švirga]

a budu odmítat to tolerovat

To se projeví jak? Budeš zabíjet?

Myslím, že většině lidí, kteří systemd nechcou, je to co ty hodláš a nehodláš tolerovat naprosto u prdele.

Radím se méně opíjet vlastním egem.

[Grunt]

To se projeví jak? Budeš zabíjet?

To bych klidně mohl začat, ne? Ale spíš to prostě a jednoduše nebudu tolerovat, toť vše.

Myslím, že většině lidí, kteří systemd nechcou, je to co ty hodláš a nehodláš tolerovat naprosto u prdele.

A mě jsou zase u prdele oni. Mně systemd funguje dle mých představ, vyhovuje mi a přináší mi něco nového (jediná otázka kterou už si kladu je: To jsem vážně jediný?), já nemám co řešit.

[Tomáš Bžatek]

Hm, to jsem presne cekal, kdyz se mergli. Bohuzel ani ta arogance nebyla nepredvidatelna, zvlaste u nekterych osob. Cim vic se hrabou k moci, tim je to horsi. Naprosto stejna situace panuje i v Gnome. (Temer) tvrda zavislost na systemd, neochota udrzovat kod pro alternativy, samozvana skupinka. ktera urcuje smer a nikdo ji neni ochoten a schopen odporovat. Obcas se revertuji prilis omezujici commity po velkem kriku ostatnich, ale jen pro to, aby se tam dostaly v dalsim cyklu znovu.

[mrv]

OSS vendor lock-in ... cool story, bro :D

[----]

Taky je to http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish vůči ostatním un*xům. Systemd je záměrně vyvíjený pomocí neportabilních extensions a *potřebuje* VOLITELNÉ (!!!) kernel featury (cgroups). Kromě toho kompletně ignoruje unix filozofii a nalepuje dbus čím dál tím hlouběji do systému.

[Tomáš Bžatek]

Pamatuju si doby, kdy release systemd (tudiz i balicek v systemu) potreboval k bootu urcity typ cgroups, ktere byly tehdy v jeste nevydane verzi kernelu. Nektere procesy jdou zkratka velice pomalu.

[l4m4]

Kdežto ostatní alternativy SysV initu všechny ostatní Unixy od HP-UX přes OpenBSD po Darwin nyní nadšeně zařazují do systému. Probuď se.

[pavlix]

Závislost na cgroups chápu.

[----]

opět udržovaný devfs by se mi líbil víc. Ve FreeBSD to funguje bez problému.

[Michal Kubeček]

Tady vidím problém ve slově opět. IIRC jeden z problémů devfs (v linuxovém jádře) byl právě v tom, že udržovaný nebyl.

[----]

Jo, právě že nebyl, ale než to nahrazovat udev, tak by bylo lepší sehnat novýho maintainera. IMO devfs funguje celkově líp (dynamický to je, věci z /dev se nedají kopírovat ven, ne-dev věci se nedají vytvářet vevnitř, což je hodí pro sandboxy, nepotřebuje žádnýho daemona), a devfs rules jsou jednodušší, než udev rules.

[Michal Kubeček]

Jo, právě že nebyl, ale než to nahrazovat udev, tak by bylo lepší sehnat novýho maintainera.

To se zkoušelo - jenže on nikdo nebyl ochoten se toho kódu ujmout a starat se o něj.

[Kvakor]

V nových jádrech je možné zapnout jakousi rudimentální obdobu devfs - devtmpfs. Sice umí jen to nejnutnější, nicméně je přímo v jádře a pro věci jako embedded systémy to většinou stačí. A funguje i s udevem, dokonce se doporučuje ho zapínat i u "normálního" desktopu, protože v okamžiku, kdy nejde nabootovat normálním způsobem (např. nejde spustit /sbin/init), je člověk vděčný, že v /dev jsou alespoň nějaká zařízezní a nemusí se umkdnodovat k smrti

Nicméně ta pokročilejší magie prováděná udevem by se v jádře realizovala špatně, tudíž plnohodnotného devfs2 se nejspíš nikdy nedočkáme, protože by se stejně musel být částečně v uživatelkém protoru a tudíž by dělal zhruba to samé, jako dělá teď udev.

[Luboš Doležel (Doli)]

Nejen, že devtmpfs funguje s udevem, udev jej dokonce vyžaduje.