Poettering: Největší mýty o systemd (diskuse)

[Jim Hacker]

Pravdivy mytus c.1: systemd je o velkom hnedom tocenom...

[mrv]

"pravdivy mytus" :) ty vypadas jako typicky systemdfob, blbej jak klika vod dveri :)

[Tom Hacker]

Hele, lidi, kdyz vam tak strasne vadi systemd, nikdo vas nenuti ho pouzivat. Predstavte si, ze ani vase distribuce - nikdo vam nebrani vstoupit do jeji ridici struktury a prosadit zachovani status quo, pripadne jeho navraceni, pokud uz k te "tragedii" doslo. :)

Tenhle slepy hate na forech nezmeni nic krom toho, ze si o vas budou ostatni myslet, ze jste zpatecnicti tupci. :)

[pavlix]

Já ti tvůj obdiv k systemd neberu, ale je nutné si kvůli tomu lhát do vlastní kapsy?

[chrono]

Tým bodom 9 chcel naznačiť, že systemd je projekt RedHat a nikým si do neho nenechajú hovoriť?

[little.owl]

Tak to nevyzniva, navic v bode 27 se to pokousi vyvratit.

[joejoe]

uz body 2 a 3 si odporuji (-; jde o rychlost nebo ne?

[little.owl]

Neodporuji. V bode 2 rika, ze rychlost neni primarni kriterium, kteremu je vse podrizeno. V bode 3 rika, ze rychly boot je uzitecny pro servery. V tom neni rozpor.

[R]

Mne vzdy na serveroch najdlhsie trva POST. Teda na serverovom HW (podla hesla - cim viac enterprise, tym dlhsie trva POST). Debian bootuje rychlo aj bez systemd.

[Kaacz]

Presne tak. Boot OS trva zlomek casu POSTu..

[Ondrej 'SanTiago' Zajicek]

Ono nejen na serverech. Na routeru z bezneho hardware mi boot OS puvodne (pred predchodem na 1 Gbps) trval ne o moc dele nez POST (resp. kompletni boot firmware), ale vyrobci 1 Gbps sitovek zrejme nevyrabi verze bez bootovaciho firmware a i pri vypnuti bootovani na kazde sitovce pak boot firmware s postupnou inicializaci kazde sitovky (pri 6 sitovkach) trva podstatne dele nez boot OS. A to ani nemluvim o tom, ze i boot mnou pouzivanych managovatelnych switchu trva podstatne dele nez boot OS.

[j]

I jen na zaklade tohoto bodu muzu tvrdit, ze dotycny je blb, a vzivote zadnej server nevidel. Videls nekdy jak staruje server? Mnohem dyl, nez samotnej OS, probiha hledani HW, poli, ... samotnej start systemu je tak maximalne 1/5 ty doby.

Takze "ryhly" boot pro stervery je naprosto nepodstatnej.

[asfethan]

I na zaklade tohto prispevku mozem tvrdit ze si blb kedze on argumentuje bootovanim virtualnych strojov vo velkom pocte kde POST trva kratko.

[j]

Na zaklade tohodle postu tvrdim, ze blb ses predevsim ty. On systemd zrychli start databaze? Vazne? A jak? On zrychli start nejakyho aplikacniho serveru? Vazne? A jak? Nejspis tim, ze provozuje nejaky voodoo, ze? Nejaka milisekunda mezi scriptem a blackboxem v podobe binarky to fakt vytrhne ...

[Ščuka]

A to musí startovat všechny servery současně? Ty když přidáváš nový server, tak honem rychle vypneš ostatní, že na sebe musí čekat? To jsi teda dobrý vemeno :D

[j]

Vemeno ses ty, start OS je proti startu aplikace (byt jedine) naprosto zanedbatelny, ale to by nekdo musel aspon tusit o cem plka, ze ...

[stativ]

Nejspis tim, ze provozuje nejaky voodoo, ze?

Jo, třeba odložený start – navenek se to bude tvářit, že DB nastartovala hned, ale až přijde první zákazník, bude čekat pět minut než se DB opravdu spustí. Nebo spíš nebude čekat a půjde jinam.

[little.owl]

Kdyz vam nevyhovuje socket-based activation, tak ji proste nemusite pouzit.

[chrono]

V takom prípade ale ten štart rýchlejší nebude. (prípadne bude, ale o zanedbateľný čas)

[little.owl]

Pointa je v tom, ze systemd ho tady neomezuje a pokud delayed start nechce, nemusi ho mit.

[Michal Kubeček]

Proč mám pocit, že u většiny bodů "vyvrácení mýtu" vypadá tak, že se napíše "To vůbec není pravda" nebo "To je naprostý nesmysl" a přidá se negace původního tvrzení? :-)

[Solitary]

Protoze vetsina tech mytu pravda neni?

[Michal Kubeček]

I kdyby opravdu nebyly, pořád je úsměvné prohlašovat za vyvrácení to, že prostě napíšete "to není pravda".

[Rupt]

Tak alespoň, že ty mýty jsou pevné jako skála, viď?

[Solitary]

Ale on nikde prece nevyvraci tvrzeni pouze hlaskou "to neni pravda". Vzdy vypise duvody, proc to neni pravda (resp. proc si mysli, ze to neni pravda) ... coz samozrejme typicky musi byt opak toho tvrzeni, protoze kdyz nekdo tvrdi, ze "ta barva je cerna", tak vyvraceni tohoto tvrzeni bude hlaska "to neni pravda, ta barva je bila". Myty maji casto nesmyslne a nezname zaklady (typicky vznikaji z nedostatecne znalosti nebo zloby a nenavisti) a casto tvrdi primy opak reality.

[Michal Kubeček]

:-)

[kavol]

ze "ta barva je cerna", tak vyvraceni tohoto tvrzeni bude hlaska "to neni pravda, ta barva je bila".

nikoli, to není vyvrácením tohoto tvrzení, to je pouze protitvrzení

vyvrácením by bylo něco ve smyslu "za ideály bílé barvy považujeme síran barnatý nebo oxid hořečnatý (viz literatura); laboratoř ta a ta provedla měření našeho vzorku, při kterém vyšlo, že dosahuje 96% bělosti BaSO₄, pročež jej můžeme považovat za bílý"

[j]

Ani to neni pravda, za ideal cerne povazujeme stav, kdy je veskere vlneni (rekneme v alespon viditelne casti spektra) dokonale pohlcovano => nic se nevraci/neodrazi .... a na zaklade toho lze dokazat, zda je nebo neni neco cerne (pripadne zmerit, co je cernejsi ;D ).

[kavol]

z hlediska pointy je to víceméně ekvivalentní, kolega si tam přidal navíc tvrzení o bílé, takže by ho měl doložit, čímž automaticky popře, že by to bylo černé - pokud by říkal pouze "to není pravda, ta barva není černá", tak samozřejmě stačí doložit, že nepohlcuje viditelné světlo

[j]

Ono slo predevsim o to, ze ty plky ve zminovanem clanecku absolutne nic nedokazuji, jsou to jenom plky typu "to neni pravda", bez jakehokoli argumentu.

[kavol]

ano, samozřejmě

přijde mi poněkud smutné, že to někdo vidí tak, že když Lennartův odpůrce napíše, že něco je černé, tak je to mýtus, zatímco když Lennart napíše "to je bílá", tak je to "důvod", proč není pravda, že je to černé

[little.owl]

jsou to jenom plky typu "to neni pravda", bez jakehokoli argumentu.

Argumenty tam jsou, nektere mohou byt sporne, ale jsou.

Problem je v tom, ze fakticka argumentace odpurcu systemd nedosahuje zdaleka anit teto jeho urovne, tahle diskuze je toho ostatne ukazkou.

[little.owl]

Je to trochu manipulativni, kazda liska si chvali svuj ocas, ale v podstate celkem korektni.

Bod 27 je nepresvedcivy, statistika z logu repository je celkem jasna, kdo hraje prim, par commitu odjinud, z jinych distribuci a nekolik fanboys na G+ to presvedcive nevyvraci.

[Michal Vyskočil]

Lennart Poettering 4086
Kay Sievers 3177
Greg KH 679
Michal Schmidt 232
Zbigniew Jędrzejewski-Szmek 222
Martin Pitt 181
Harald Hoyer 86
Marco d'Itri 65
Dave Reisner 63
Tom Gundersen 58

Toto jsou aktuální čísla, ovšem silně zkreslená faktem, že byla importována kompletní historie udevu, proto je tam Greg a Kay tolik neudev commitů afaik mít nebude. Každopádně faktem je, že systemd == Lennart, potažmo RedHat a až potom zbytek.

[little.owl]

Ano a pokud by se to posuzovalo treba podle poctu zmenenych radku kodu, bylo by to jeste vyraznejsi.

[lm]

po precteni prvnich asi 15 bodu jsem to vzdal. ten clovek je neskutecnej demagog a kreten. kompatibilitou s shell scripty rozumi, ze je systemd umi spoustet (wtf) ?! systemd je jednodussi nez initscripty kvuli unifikaci rozhrani ? a co ta dalsi neprima vrstva, kterou mezi konfiguracnimy soubory a samotnym spoustenim sluzby zavadi ? navic znalost shellu je univerzalne pouzitelna, lze v nem psat cokoliv od administratorskych skriptiku po hromadne zpracovani fotografii. systemd s jeho nastroji a konfiguraky se da pouzit ... jen pro systemd. nema cenu se dal rozepisovat, to je ztrata casu.
s/Linuxes/Lunexes/ig

[l4m4]

Proč bychom si nechali kazit spravedlivý hněv, nějakými fakty...

Ve skutečnosti mezi initem a spouštěným programem ubyl shell (ve většině případů), což je jedna vrstva, a navíc ubyly smatlaniny typu /lib/lsb/init-functions nebo /etc/init.d/functions, které nikdy nebyly pořádně specifikovány, nicméně tvořily další vrstvu, protože se pomocí nich init skipty implementovaly. Z druhé strany ubyly kutilské nadstavby nad initem typu různých chkconfigů a service.

[Mrkva]

find ~/systemd/tgt|wc -l 795

A doporučuju podívat se do /usr/lib/systemd :)

[pc2005]

bash-4.2# ls /usr/lib/systemd/
ls: nelze přistoupit k /usr/lib/systemd/: Adresář nebo soubor neexistuje

YES!

[l4m4]

V /usr/lib/systemd žádné zbastlené mezivrstvy nemám (díval jsem se tam mnohokrát, a skutečně to doporučuji). Co dělám špatně?

[Michal Vyskočil]

Nedobře se na to díváte - fakt, že je tam spousta zbastlených mezivrstev je přeci očividný - a) tam vůbec něco je, b) Lennart.

[Michal Vyskočil]

Ve skutečnosti mezi initem a spouštěným programem ubyl shell (ve většině případů), což je jedna vrstva

On taky shell (nebo třeba bash) není ani nijak hezká vrstva - jako programovací jazyk stojí za houby a pro ovládání běžících procesů je docela nepraktický, když prakticky jediné, co umí, je pustit nový proces.

[deda.jabko]

prakticky jediné, co umí, je pustit nový proces

ale umi to udelat poradne

[Michal Vyskočil]

ale umi to udelat poradne

V porovnání s čím? Shell tak akorát abstrahuje od pár volání jako pipe, fork/exec a getenv/setenv a přidává celé to harampádí ohledně úloh běžící na popředí a pozadí (což je pro init systém stejně irelevantní). Cokoli, co umí zavolat příslušná volání spouští procesy stejně dobře, jako shell.

[Já]

Já bych klidně shellový kód delší 10 řádek zákonem zakázal.

[Jiří J.]

Bohužel tohle jsou body, které snad všichni označí za "nesmysly" a doloží spousty případů, kde shell skripty neměly/nemají výhody oproti systemd-based konfiguraci.

Ale ani já bych nedokázal přijít na žádný "systemd killer", jen tak nějak cítím, že je to špatně. Kdyby to byl jednoduchý C process s jasně definovanou množinou souborů, do kterých zasahuje, kdyby se nesnažil pohltit snad vše kolem, kdyby ..., tak by možná dle mé osobní definice "jeden program dělá jednu věc a dělá ji dobře" uspěl spíše. A nikdo netvrdí, že by nemohl mít (třeba v další verzi) featuru trackování procesů přes cgroups.

Takhle mi (osobně) připadne jak zaváděcí proces Windowsu - ne že by se jej nešlo z dokumentace naučit, ale je na můj vkus málo intuitivní a dokud se do něj člověk vyloženě neponoří celým tělem, zůstává systemd takovým blackboxem. Třeba evoluce BSD initu mi přijde docela přirozená - od "rc", přes zavedení "rc.local" až k "rc.d" s integrovanými závislostmi.

Poznám "geniálně elegantní" řešení, když jej vidím, ale taky poznám opak. Neřeší systemd náhodou problémy jen proto, aby se řešily problémy? Připomíná mi tu iniciativu přepsání kernelu do C++ s objekty, protože "C je přece staré a pro dnešní dobu nevhodné". Vždy u každého systému budou chybějící featury, pointa je ta, zda nám stojí za to systém zesložiťovat jen pro implementaci těch, které v současnosti považujeme za klíčové.

[Solitary]

Připomíná mi tu iniciativu přepsání kernelu do C++ s objekty, protože "C je přece staré a pro dnešní dobu nevhodné".

Vetsinou maji tyto iniciativy prepisovani sve opodstatneni (sam jednu v zavorce zminujes). Ono se to zvenci muze zdat byt jako malicherne a zbytecne rypani se ve fungujici veci, ale ono je obcas zkratka vyhodnejsi vec prepsat nez se pokouset spravovat stavajici reseni postavene nad technologii, ktera nanabizi vse, co chces a je navic napsana tak, ze se v tom prakticky nikdo nevyzna.

[R]

Prepisovanie skonci takmer vzdy zle. Mnohokrat na tom projekt skonci.

[j]

Ono v Cecku neco napsat nejde? lol ...

[biolog]

Ono v Cecku něco napsat nejde? Vždyť je to Turingovsky-úplný jazyk, že jo? Vždyť lidi mohou psát i v Brainfucku, a vyjde to nastejno. Nebo ne?

Až na to, že C je pohodlnější než jazyk Brainfuck. A Python je obvykle pohodlnější než C. Není podstatné jestli něco jde, ale jak je to přívětivé/srozumitelné atd.

[Já]

Je spousta věcí, který v céčku nejdou napsat tak, aby se z toho člověk nepomátl.

[Michal Vyskočil]

Je spousta věcí, který v céčku nejdou napsat tak, aby se z toho člověk nepomátl.

Napadá mě třeba překladač C++

[Franta Hanzlík]

Takhle nějak to cítím taky. Když uvážím (na to že v distribucích /Fedoře/ je tři roky) ten neskutečný počet problémů okolo systemd, tak s ním asi něco v pořádku není. A jestli jej po těch třech létech musí LP (celkem nepřesvědčivě, on je naprosto nekritický) obhajovat, tím spíš.
Osobně mi init.d scripty vyhovovaly, nebyl problém cokoliv přiohnout/rozšířit/poladit a bylo to naprosto jednoduché a transparentní.
Nejvíc mne na něm štve že zabíjí (už dlouho) bash předtím, než stačí zapsat .bash_history, takže se o ni co chvíli přijde. A také myslím pořád není schopen pracovat na NFS/NBD kořenovém FS, takže můj oblíbený K12LTSP/K12Linux pohřbil (ten skončil s Fedorou 14).

[dustin]

Souhlasím. IMO je to zbytečně velké sousto. Místo aby nejprve do finále (tedy i do prosazení do distribucí) pořešili to, co při bootu pálí nejvíc (ano, initscripty nejsou zdaleka ideální), rozpracovaný projekt roztahují ještě před jeho akceptací uživateli do šířky.

[Ivan]

Mam z toho uplne stejny pocit. Cely ten systemd se snazi spasit svet tim, ze vyresi spoustu neexistujich problemu. Stavajici init neni kdovijak genialni, ale rozhodne nestoji za tom, aby se cely zahodil a nahradil uplne necim jinym - mnohem komplikovanejsim. Pred 17ti lety jsem zacal s Linuxem, BSDckem a AIXem.
Za tu dobu jsem se na Linuxu naucil spoustu veci, ktere jsou uz dneska mrtve anebo mrtve budou(napr. LVM -> EVMS -> LVM2, plus device mapper, multipath). Za tu dobu se zmenil bootovaci system Linuxu nekolikrat, a nikdy to neprineslo nejaky zasadni uzitek(me jako adminovi). Na druhou stranu se v AIXu nic zasadniho nestalo (kdyz pominu virtualizaci). Ten system byl uz v te dobe byl kompletni a veskery cas, ktery jsem do nej "investoval" se mi 100x vratil. Diky tomu, ze nikdo nema chut ten system porad dokola prekopavat, tak maji admini cas i na dulezitejsi veci nez je bootovaci sekvence.
Bootovaci system ma bejt prostej jak bulharska stripterka a admini by meli resit jiny veci nez je bootovani.

[dustin]

Na desktop to asi má smysl, ale u serverů potřebuji maximální spolehlivost bootu, protože obvykle není příležitost bootovací sekvenci jakkoliv ladit. Doba bootu mě téměř nepálí, přesně jak tu už bylo řečeno - nejdéle stejně trvá POST. Naopak opakovaný reboot kvůli ladění a ověřování sekvence krutě zdržuje právě kvůli délce POSTu.

Argument Lennarta o virtuálech je sice pravda, ale přijde mi, že to prostě nějak obhájit musel. Navíc virtuály bývají jedno/máloúčelové, takže se v jednotlivých instancích toho moc nestartuje. A navíc se jim nemění hw, což byl jeden z cílů systemd.

[Bedňa]

Bootovaci system ma bejt prostej jak bulharska stripterka a admini by meli resit jiny veci nez je bootovani.

Podľa toho čo som videl, práve snaha zrýchliť proces bootu to skomplikovala, pritom ako vidím z diskusie, tak je to pre každého neprínosné a stráca sa jednoduchosť konfiguráku, one line.

[Ivan]

No a to je jeden z duvodu, proc to lidi odmitaji. Rychly bootovani => Paralelni bootovani => Nedeterministicky chovani (alespon nekdy).

Navic ani to paralelni bootovani neni kdovijak super. Kdyz mate v serveru vetsi pocet disku, tak vam paralelni udev spolecne s multipath-em zabijou server a ani to nenabootuje.

[Ondrej 'SanTiago' Zajicek]

systemd je jednodussi nez initscripty kvuli unifikaci rozhrani ?

Tady, ac s nim nesouhlasim, bych se ho zastal. Existuji dva pohledy na jednoduchost, ktere jdou casto proti sobe - 'jednoduchost uziti', kdy vnejsi chovani je prizpusobene obvyklym use cases, a proto se jich da snadno dosahnout i za cenu komplikovaneho chovani software, a 'jednoduchost chovani', kdy je jednoduche (ci rekneme transparentni) to, co dany software dela, i kdyz to muze znamenat, ze obvykle use cases vyzaduji netrivialni zachazeni.

Oba tyhle pohledy jsou svym zpusobem regulerni, takze Poetteringa nelze oznacovat v tomto bode za demagoga. Ale slusi se zminit, ze 'jednoduchost chovani' je dalko vic v souladu s 'the unix way'.

[Sešívaný]

Bavil jsem se s člověkem, který prošel asi 2500 init skriptů a zhruba 250 přepsal pro systemd. Říkal, že zatímco u init skriptů narážel i na takové, které měly 900 řádků, žádný z těch, které přepsal, nebyl delší než 15 řádků. To je docela silný argument pro jednoduchost, v tomto případě jednoduchost užití.

[lyon]

Jinými slovy lze se systemd jednoduše vyřešit něco, co by bez něj nebylo vůbec potřeba dělat. Chápu to dobře?

[Sešívaný]

Spíš systemd dělá za člověk věci, které si se sys-v musí člověk udělat sám. Zatímco se systemd stačí řádek "Restart=on-failure", se sys-v si musí napsat vlastní skript a nastavit úlohu v cronu.

[Jinan Dvoulaločný]

se sys-v si musí napsat vlastní skript a nastavit úlohu v cronu.

Nebo použít nástroj k tomu určený, jako například Monit.

[Michal Vyskočil]

Případně systemd, kterým odstaníme těch předchozích tisíc řádků shellu a nutnost startovat extra proces na něco, co lepší init systémy umí sami o sobě.

[j]

Coz je mu uplne naprd, protoze to ze sluzba zbuchne tak, ze to pozna systemd je spis vyjimka. Beznejsi je spis to, ze se tvari jako ze bezi, ale ve skutecnosti nebezi => dotycny si stejne musi napsat tech 1000 radku aby otestoval zda bezi nebo ne ...

[little.owl]

protoze to ze sluzba zbuchne tak, ze to pozna systemd je spis vyjimka.

To zalezi treba na tom, zdali sluzba podporuje treba sd_notify a sluzby to ted zacinaji podporovat, od apache po mysql.

[Ivan]

WTF?

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1

Tohle prece umi klasicky BSD init uz minimalne 30 let. Dokonce je tak inteligentni, ze po nekolika selhanich pocka 5 minut nez, to zkusi znovu. Takhle to dopada, kdyz kazdyho bavi programovat, ale nikdo nechce cist dokumentaci.

[Michal Vyskočil]

Nojo, když oni jsou lidi věčně nespokojení a fakt, že jejich init systém umí udělat respawn getty (a prakticky k ničemu jinému se inittab nehodí), jim zase tak ohromující nepřijde. Systemd umí udělat respawn čehokoli, můžete si nastavit, při kterých exit hodnotách se to udělat nemá, nebo kolik času se má mezi restarty počkat.

Takže co to ten BSD init vlastně už 30 let umí?

[Radek Hladik]

Tady by mě docela zajímal nějaký konkrétní příklad... Protože bych řekl, že jediný případ, kdy dobře napsaný init skript s několika sty řádků jde přepsat do pár řádek čehokoliv jiného, je , že si ten skript programuje něco, co to cokoliv už má implementované. A to nemluvě o tom, že systemd unity nejsou skripty, resp. používají deklarativní paradigma, takže mají úplně jinou vyjadřovací sílu...

A nebo je to ten případ, kdy init skript dělá něco víc (třeba initdb u postgresu) a protože to systemd neumí, takže je to vytažené do jiného skriptu? :)

P.S. Pochopil jsem to správně, že nějaký takový 900 řádkový init skript přepsal do 15 řádkového unit souboru, nebo je správně interpretace, že z těch 2500 init skriptů přepsal pouze ty trivální? :)

[Sešívaný]

No, předpokládám, že je to především o tom, že už se v těch skriptech nemusí řešit to, co má systemd implementované. Jeden konkrétní drobný příklad mám uvedený o komentář výše. On konkrétní nebyl. Nepředpokládám, že zrovna 900 řádkový skript dokázal stáhnout do 15 řádků, ale obecně tam podle něj byla docela velká úspora. Michochodem bude v Brně na DevConfu, tak není problém se ho zeptat na konkrétní příklady a zkušenosti osobně Taky tam budou i všichni vývojáři systemd včetně Lennarta, takže pokud má někdo věcné připomínky (něco ve stylu "systemd je sračka a měl by shořet v pekle" asi nepadne na úrodnou půdu), tak to může dojít Lennartovi a spol. vytmavit

[Radek Hladik]

Ono je jasné, že se nemusí řešit x-krát to, co už systemd umí, ale mně by docela zajímalo, co konkrétně to je. Jedna z věcí je démonizace něčeho, co démon není, respektive to, že se hlídá, zda to běží a případně se to pustí znova. Ale přijde mi, že takových problémů je opravdu jen pár a rozumně napsaná "knihovna" jako měla Fedora/RH rc.functions (nebo jak se to jmenovalo) udělá poměrně hodně.

A naopak příklad s initdb je naprosto zřejmým dokladem toho, jak je funkcionalita systemd omezená. Určitě je možné argumentovat, že taková věc do init démona nepatří a určitě je to validní argument, ale na druhé straně je fajn, když první start služby připraví prostředí...

A co se týče osobní konfrontace s LP, obávám se, že bych se nedokázel udržet ve věcné a technické rovině, už před léty na Fosdemu jsem měl pocit, že jeho názory a charakterové vlasntosti mi naprosto nesedí a to jsem systemd ještě ani nepoužíval a nečetl jeho blogy

[dumblob]

+1

[TM]

A čekal snad někdo od toho agresivního fracka, že nebude zdůvodňovat prznění Linuxových distribucí, které vyvolal?

[Franta Hanzlík]

systemd mi zabírá 20MB/16MB VIRT/RES, na Fedoře 5 cca 6 roků staré mi SYSV init zabírá 2M/600kB. Kdyby tady platila nepřímá úměrnost, tj. 'Když je NĚCO Nx větší, tak toho umí Nx míň', tak by toho systemd musel umět 25x méně než ten SYSV init - ale to se mi zase až tak úplně špatný nezdá. Spíš je jenom o 25 horší ;)

[Franta Hanzlík]

Kde jsou ty doby, kdy si jeden mohl na pecku s 8MB RAM jakžtakž a s 16MB pohodkně spustit Xka.
Dneska nespustí ani samotný init. Taky pecka.

[Ovocníček]

Což je vpoho, protože většina distribucí se skoro nebo úplně nedá nainstalovat na stroj s 128 MB RAM :D

[Franta Hanzlík]

128MB? Nový geni[t]ální instalátor Fedory 18 potřebuje 1GB pro základní instalaci, a pokud jsem instaloval z kickstart souboru (předdefinovaná instalace) něco maličko většího, tak to spadlo i s 1.25GB RAM (na 32 bit distru). Ať se jdou vycpat.

[nyan]

pak to bude zajimave na virtualkach s 512m ram..

[Michal Kubeček]

Ani ne, virtuál má tu výhodu, že mu lze celkem snadno dát na instalaci paměti víc a pak to snížit. Mám takhle sadu virtuálů na testy síťování, které spokojeně běží se 128 MB, přestože instalátor (OpenSuSE) potřebuje 512 MB.

[j]

Nevim jak vetsina ... gentoo mam (stale) funkcni na P100 s 8MB ... ;D

[pc2005]

Jakej kernel?

[nyan]

Ale on toho mozna i umi 25x vice. A taky ma 25x vice kodu a 25x vice bugu

[dustin]

A navíc je otázkou, zda z toho 25násobku funkčnosti už třeba 2/3 neřeší nějaké stávající legacy projekty (udev v systemd?)

[Michal Vyskočil]

systemd mi zabírá 20MB/16MB VIRT/RES

$ ps -p 1 -o comm,rss,vsz,size
COMMAND           RSS    VSZ  SIZE
systemd          2100  43880  3032

Pokud máte zapnutý SELinux, tak většina toho bude právě on.

[Franta Hanzlík]

To si děláte srandu, ne? Na co by v initu byla tuna kódu SELinuxu? To je přece záležitost jádra, ne userspace.

[Michal Vyskočil]

systemd-devel

[Franta Hanzlík]

Hm, pochopil jsem z toho jen to že si systemd natahuje obsah SELinux politik. Ale proč to potřebuje natáhnout tam zmiňováno není. A jak to dělaly předchozí init-y? Ve Fedoře 2 se objevil SELinux (v dobách SYSV initu), upstart ve Fedoře 9 (upstart mi ve F14 zabírá 2.88/1.18 MB VIRT/RES - o něco víc než SYSV init, ale tak tragické jako u systemd to není). Neinspiroval se LP u Mozilly a nesměřuje to k systemd OS? :)

[kavol]

Ale proč to potřebuje natáhnout tam zmiňováno není.

+1, taky jsem to z toho nepochopil ...?

[pavlix]

Taky bych to z toho nepochopil. Ale systemd některé politiky přímo provádí. Ne všechno selinuxování se děje v kernelu.

[little.owl]

+1

Pridavam se. Proc by si selinux mel alokovat memory v memory space systemd, aniz by LP integroval selinux do systemd?

[pavlix]

Já měl za to, že integrován je.

[little.owl]

To mi uslo. Hlasim se do teamu vesicu za koule ...

[pavlix]

systemd dělá spooooustu věcí. U některých z nich stojí za to implementovat nějakou bezpečnostní politiku a jediná, která je z hlediska Fedory a Red Hatu zajímavá, je politika postavená nad selinuxem.

Proti věšení nic nemám, ale samotný fakt, že se integruje selinux, bych jim odpustil.

[little.owl]

ale samotný fakt, že se integruje selinux, bych jim odpustil.

Proti integraci ve smyslu, ze systemd spousti a aktivuje veci pro selinux vubec nic nemam, o tom jsem vedel. Ale fakt, ze systemd naloaduje cosi z selinuxu do sveho pametoveho prostoru a pak jeho proces zabira v pameti 20M, jak se pise nahore, je silene, to by fakticky znamenalo primou integraci selinuxu do systemd.

Nevim, casem se na to kouknu, ted varim z vody, ale prijde mi to divne.

[pavlix]

Nevim, casem se na to kouknu, ted varim z vody, ale prijde mi to divne.

Taky vařím z vody, četl jsem o tom někde před delší dobou…

Jenže pokud chceš v nějaké službě dělat policy decisions, tak potřebuješ buď natáhnout politiku do paměti, nebo dělat policy decisions dotazem na službu, která tu politiku nataženou má (třeba kernel).

[little.owl]

nebo dělat policy decisions dotazem na službu, která tu politiku nataženou má

Tohle se cesta, ne narvat selinux do systemd.

[pavlix]

Odkaz na bug report? :)

[little.owl]

Ja hlavne potrebuji vedet, jestli je to vubec pravda. Nechci byt dalsi verejny zarez na Lennartove pazbe, a navic levny .

[pavlix]

Dá se to formulovat i jako otázka.

[little.owl]

Tak jsem koukal chvili do kodu a prijde mi to jako plany poplach. systemd loaduje selinux policy, integruje labeling a podobne, ale zasadni integrace tam neni. Pokud si docasne pri loadovani policy alokuje velke mnozstvi pameti, problem je asi na strane libselinux, nikoliv na strane systemd. Vysvetleni pro to, ze nekomu systemd zabira 20M to asi neni.

[pavlix]

OK.

[pavlix]

8. Myth: systemd was created as result of the NIH syndrome.

Zajímavé, že si vždy ke srovnávání úmyslně vybírá jen některé z dlouho existujících alternativ :).

[Michal Vyskočil]

Prostě a jednoduše si srovnání s openrc musíš napsat sám ...

[j]

To bude jednoduchy ... je to trivialni, funguje to, snadno se to uzivatelsky modifikuje, je to snadno citelny, logicky = i blbec pochopi co tim autor myslel ...

[pavlix]

To si mě asi s někým pleteš. Já na systemd nepracuju a u NetworkManageru se takhle alibisticky nechovám.