Názory k článku
TrueOS přechází na OpenRC

Vazne?

Binarni logy, na ktere ve skutecnosti nemusim spolehat, a pak co? Bud politikia nebo neprectena dokumentace (kde si do dokumentace dovolim zapocitat i SystemD Myths).

Binarni logy, na ktere ve skutecnosti nemusim spolehat, a pak co? Bud politikia nebo neprectena dokumentace (kde si do dokumentace dovolim zapocitat i SystemD Myths).

Binarni logy, casto nefunkcni, jsou vyzivne, ale neni to zdaleka jediny duvod. Ten, ktery bych oznacil za hlavni, je to, ze systemd jde proti nixove filosofii. Syatemd neni kostka ve stavebnici, kterou muzu vymenit za jinou, ktera se mi libi vic. Je to prujem, ktery znecistuje cim dal silneji ostatni casti systemu nebo je dokonce pohlcuje a stava se nenahraditelnym a neodstranitenym. Cim dal vice SW ma nove vzniklou zavistlost na systemd, ktera eventuelne vznikla jen proto, aby byla obejita nejaka systemd picovina nebo proto, ze systemd neco rozbil. Za chvili bude portovani SW odjinud na Linux mnohem obtiznejsi kvuli systemd a opacnym smerem pak (skoro) nemozne. Z Linuxu tak budou dalsi Widle, kde lze provozovat SW z Linuxu a nic jineho a SW z Linuxu vubec nikde jinde nepobezi. Bodejt ne, kdyz budouci linux se bude skladat akorat z jadra, systemd a graficke nadstavny. Pricemz nahrada jadra systemd se pripravuje a bude se tomu pak rikat Poetteringux.

Tak nás pouč. Argumentů proti systemd jsem slyšel mračna ale DOBRÝ dosud ani jeden.

Ja mam podobny problem. Zase jsem neslysel dobry argument pro systemd. Stejna situace, donekonecna muzeme resit co je to "dobry"... Vzhledem k tomu, ze to prislo jako novinka, tak tam bych to ocekaval.

Netreba psat/udrzovat slozite bash skripty pro spravu sluzby...Uz vidim, jak to nasi vyvojari pisou misto nekolikaradkove definice systemd service unity.

Ano, systemd je naprosto unikatni init, ktery jako jediny funguje bez dlouhych bashovych skriptu. Pockejte, vlastne ne. I jine inity misto nich maji jednoduche konfiguraky o par radcich a to i presto, ze se do nich nepromitly paprsky Poetteringova genia. Tak mi znovu unika, proc misto SysV zavadet zrovna systemd, kde se nektere veci serou, jine se meni adminum pod rukama, protoze soudruzi neco nedomysleli a dneska to proste funguje jinak a jeste to pozira okolni system jak zelena smrt.

Argumenty pro systemd byly probírány do omrzení, takže jenom krátce a v kostce:

1. Logy. Sice binární, ale v jasně definovaném formátu. Kdo někdy psal parser syslogu tohle ocení.

2. Integrace všech typů systémových událostí se závislostmi. V klasickém Unixu například cron a síť o sobě vůbec nevědí a žádná vzájemná závislost tudíž není tudíž není možná, přihlášení a odhlášení uživatele nejsou zaznamenané nijak apod.

3. Všechno má API, což je jeden z největších problémů klasického Unixu, kde ovládat a konfigurovat systém programově v podstatě nejde. Víc než cokoli jiného je tohle důvodem, proč se Unix ani Linux není schopný doopravdy dostat na desktop.

Někdo tady použil přirovnání ke stavebnici. Ano, Unix je stavebnice, ale taková, ve které má každá kostka jiný tvar, jiný rozměr, je z jiného materiálu a každá je nějak vadná, jenom každá jinak. Jistě, i z takové stavebnice se při troše dobré vůle dá něco postavit, ale to že to jde neznamená, že by člověk nemohl chtít lepší stavebnici. No a když ji dostane, tak ho nijak moc nemrzí, když ty staré kostky do ní už nezapadají.

Argumentů proti systemd je, pokud vím, primárně pět:

1. Rozbije to kompatibilitu s FreeBSD/NetBSD apod... Budiž. V tom je snad jakás logika, ale v zásadě je to stejné, jako odmítat TCP/IP, protože není kompatibilní s UUCP.

2. Binární logy. Viz výše: jsou v každém případě mnohem lepší. Textové by třeba byly ještě lepší, to je možné, ale rozhodně je to dle mého názoru krok kupředu. Operační systém má být navržen primárně pro potřeby vývojářů, ne sysadminů.

3. Návrh systemd není optimální. Nikdo netvrdí, že je dokonalý. Žádný lepší ale prostě k mání není a nikdo žádný takový ani nevyvíjí, takže v praxi je to buď systemd, nebo status quo. Většina zjevně volí tedy systemd.

4. Do teďka jsme se bez systemd obešli. Aneb k čemu mikroprocesor, zbytečně integruje moc funkcí a sálové elektronkové počítače se bez něj do teďka taky obešly.

5. Není to Unix. Na tohle je dle mého názoru přiměřená odpověď: "no a co má být?"

Pricemz ty protiargumenty 1. 3. 4. a 5. jsou primarne politicke...

1. Logy. Sice binární, ale v jasně definovaném formátu. Kdo někdy psal parser syslogu tohle ocení.

Hm, tak zrovna ty binani logy a jejich parsovani tu jednou nekdo rozpatlavat a jestli se pamatuju, tak s tim parsovanim je to jeste horsi, nez u textovych logu. A to dokonce i v pripade, kdy se clceku podari se k tem binanim logum dostat, protoze zrovna nespadly.

Operační systém má být navržen primárně pro potřeby vývojářů, ne sysadminů.

Vazne? Ja si vzdyzky myslel, ze pocitace jsou navrhovany pro uzivatele. S vasim pristupem bychom dnes meli treba vysavace takove, ze by lidi radsi klepali koberce na klepadle na dvore.

Vyvojar vyviji pro uzivatele a tim je v pripade spravy systemu admin, ne vyvojar.

Vazne? Ja si vzdyzky myslel, ze pocitace jsou navrhovany pro uzivatele.

Pro uživatele jsou navrhovány aplikace. Operační systémy jsou (respektive měly by být) navrhovány pro vývojáře aplikací. Tak je to u Apple, Google i Microsoftu, jenom unixáci s tím mají pořád problém.

S vasim pristupem bychom dnes meli treba vysavace takove, ze by lidi radsi klepali koberce na klepadle na dvore.

A to jako proč? S vaším, tj. unixáckým přístupem, bychom měli vysavače, které by byly dělané každý na jinou elektrickou síť, hadici by mohl ohýbat jenom oprávněný technik v servisu, hubici by si člověk musel dodělat doma sám a nic by se na tom nesmělo vylepšit, protože by to už nebyla "filozofie" původního modelu od Electroluxu.

Vyvojar vyviji pro uzivatele a tim je v pripade spravy systemu admin, ne vyvojar

U operačního systému je uživatelem vývojář aplikací pro koncové uživatele.

Operační systémy jsou (respektive měly by být) navrhovány pro vývojáře aplikací. Tak je to u Apple, Google i Microsoftu, jenom unixáci s tím mají pořád problém.

Zrejme proto zastoupeni Widli, Masoxu a Androidu na serverech nikoho neohromi. Uzivatele serveru jsou totiz admini a ti si system predstavuji urcitym zpusobem, ktery je s uvedenymi OS nekompaibilni.

Tak pokud vím Wokna mají na serverech kolem 33%. O to ale nejde. Linux dneska nezaostává na serverech ale na desktopu. A kdyz budu parafrázovat Linuse, tak udělat OS pro servery je snadné. Horší je to na desktopu, protože to musí šlapat na mnohem širší škále konfigurací, kde se hardware, síť apod. mění pod rukama, člověk neustále instaluje a odinstalovává různé aplikace, a to všechno musí spolehlivě fungovat samo od sebe, bez žádného admina. Od toho je systemd. Jestli všechny tyhle požadavky splní se teprve ukáže, ale je to rozhodně nejnadějnější a vlastně jediný vážný pokus, jak je realizovat.

Mimochodem i na serverech je to dneska jinak. Čím dál víc firem chce servery na klíč (a/nebo rovnou v cloudu), které fungují samy a případná (vzácná) administrace se dělá přes webové rozhraní, které tím pádem předpokládá správní API - a jsme opět u systemd. Admini na plný úvazek, kralující nad systémem i nad uživateli, kteří si bastlí vlastní init skripty a kompilují kernel, už z velké části patří do jiné doby. Můžeme o tom vést spory, můžeme s tím i nesouhlasit, ale to je všechno, co proti tomu můžeme dělat ;-)

Linux dneska nezaostává na serverech ale na desktopu. A kdyz budu parafrázovat Linuse, tak udělat OS pro servery je snadné. Horší je to na desktopu, protože to musí šlapat na mnohem širší škále konfigurací, kde se hardware, síť apod. mění pod rukama, člověk neustále instaluje a odinstalovává různé aplikace, a to všechno musí spolehlivě fungovat samo od sebe, bez žádného admina. Od toho je systemd. Jestli všechny tyhle požadavky splní se teprve ukáže, ale je to rozhodně nejnadějnější a vlastně jediný vážný pokus, jak je realizovat.

Tak me to tak nejak uz leta funguje a bez systemd. Udev a tak, ze jo.

Ja ale nechapu, proc kvuli tomu, ze Poetteringovi to nefunguje na desktopu, musime v OS mit v podstate nevykorenitelny init, ktery proto musi byt i na serveru, protoze na nem uz pulka veci zavisi. Pricemz tedy zrovna na serveru je lepsi cokoliv jineho, nez systemd.

@Zero: +1000.

To si robis srandu? Tebe webserver, mail server a cely system spravuje vyvojar? Tak to vela stastia...

Tak předně, jak už bylo mnohokrát řečeno, cílem systemd je primárně zlepšit konkurenceschopnost Linuxu na desktopu a docílit toho, aby Linux už nebyl JENOM pro webservery a mailové serveru. Dále je fakt, že spousta firem dává přednost MS IIS a Exchange na Windows, i přes to, že nevýhody a problémy těchto produktů jsou všeobecně známy (proprietárnost, uzavřenost apod), a proč? Protože to není systém stylu "dodělej doma", kde rozchodit email je práce na týden. Uživatelé si kupují servery ze stejného důvodu, ze kterého si kupují desktopy: aby jim na nich chodily aplikace, které zrovna potřebují. Ne pro to, aby je mohli spravovat. Model centrálního počítače s adminem, do kterého se uživatelé přihlašují přes terminály, už mírně řečeno není typickým scénářem a návrh OS se musí vyvíjet podle toho. Někdo to holt pořád ještě nedokáže pochopit.

Ano a preto chlapci z TrueOS prechadzaju na OpenRC lebo ten nieje vyvyjany a udrzovany ludmi z Gentoo... Vecsina voli systemd aby mohla na distre spustit gnome a dalsie systemd dependency app...

Přesně tak, "vecsina voli systemd aby mohla na distre spustit gnome a dalsie systemd dependency app". TrueOS a Gentoo používají OpenRC, to je samozřejmě pravda a mají na to plné právo, ale při vší úctě to nejsou zrovna většinové distribuce. Neboli silně pochybuju, že by volba OpenRC v TrueOS nějak ovlivnila celkové směřování Linuxu a drtivé většiny komunity. Je samozřejmě dobře, že takové distribuce jsou a jistě dobře poslouží těm, kteří se s existencí systemd stále nemůžou smířit. Od toho je to open source - i když upřímně řečeno nevím, proč tito kverulanti nepoužívají radši rovnou BSD.

Systemd mal nahradit stary SysVinit a nie nahradit cely system...

Systemd měl nahradit návrh (nebo možná nedostatečně promyšlený návrh) starého Unixu. To logicky obsahuje init, ale zdaleka jenom ne init. Ale váš příspěvek je svým způsobem velmi ilustrativní: lidem, kteří uvažují striktně v Unixových pojmech, jako je init, syslog apod., se systemd pochopitelně asi nikdy líbit nebude. Jenomže o to jeho vývojářům ani zastáncům nejde. Připomíná mi to klasickou hlášku, už nevím od koho: "FreeBSD dělají lidé, kteří milují Unix; Linux dělají lidé, kteří milují operační systémy."

Tak předně, jak už bylo mnohokrát řečeno, cílem systemd je primárně zlepšit konkurenceschopnost Linuxu na desktopu a docílit toho, aby Linux už nebyl JENOM pro webservery a mailové serveru.

Aha. A jakym zpusobem presne diky systemd nastane rok Linuxu na desktopu? Kde presne je v systemd skryta ta wunderwaffe, diky ktere se to prihodi?

Ja mam podobny problem. Zase jsem neslysel dobry argument pro systemd. Stejna situace, donekonecna muzeme resit co je to "dobry"...

Je uplne jedno, jestli systemd je dobry nebo ne, pokud si kazdy bude moci vybrat, jestli to chce pouzit nebo jestli radsi pouzije neco jineho. A to uz bohuzel neni pravda, systemd se stava neodstranitelnym sajrajtem, zakorenenym jak svlacec.

Asi tě to nepotěší, ale realita je taková, že jeden z důvodů pro systemd je právě i to, že není možné si vždycky "vybrat". Systém, kde si každý může donekonečna "vybírat" každou jednotlivou komponentu znamená, že vývojář nemůže absolutně nic předpokládat a každá aplikace je tak vlastně OS sám pro sebe. Výsledek je pak ta nechutná slátanina, jakou známe, kde člověk musí neustále řešit, proč v aplikaci A nejde zvuk, když funguje v aplikace B, proč má aplikace C totálně podělané fonty, proč se služba D nerozběhne pro probuzení z hibernace atd. Opravdu bych byl rád, kdybych mohl věnovat trochu míň času "vybírání" a trochu víc produktivní činnosti.

Systém, kde si každý může donekonečna "vybírat" každou jednotlivou komponentu znamená, že vývojář nemůže absolutně nic předpokládat a každá aplikace je tak vlastně OS sám pro sebe.

Tohle by se dalo rici o nejakych aplikacich, ktere bezi jako daemon v systemu. Jenze situace je takova, ze za chvili bez systemd nepobezi ani piskvorky. Ale tesi me, ze systemd usetri strasne moc prace s psanim par shell skriptu lidem, kteri napriklad napisi databazi s kodem 15 km dlouhym. Tech 100 radky v bashi by uz asi nezvladli.

Výsledek je pak ta nechutná slátanina, jakou známe, kde člověk musí neustále řešit, proč v aplikaci A nejde zvuk, když funguje v aplikace B, proč má aplikace C totálně podělané fonty,

Ano, tohle se diky systemd urcite zlepsi. Jen by me zajimalo, jestli za vase problemy se zvukem nemuze Pulse Audio od tehoz geialniho umelce.

proč se služba D nerozběhne pro probuzení z hibernace atd.

Ano, jiste i na toto je systemd zazracnym lekem. Kdyz se sluzba neprobudi s obycehnym initem v bile krabici s cernym potiskem, tak se urcite probudi se systemd, s duhou na krabici a granulemi Poetteringova genia, ktere odstrani kazdy problem s ospalou sluzbou.

Tohle by se dalo rici o nejakych aplikacich, ktere bezi jako daemon v systemu. Jenze situace je takova, ze za chvili bez systemd nepobezi ani piskvorky.

Tak piškvorky, pokud jsou (jako že asi jsou) založené na frameworku gnome, bez systemd asi opravdu nepoběží, protože bez něj neběží gnome. Na tom ale není vůbec nic nového. Živě si vzpomínám na doby, kdy se řvalo proti GTK, Qt, Gnome a KDE, protože prý to je zbytečný balast, aplikace mají být napsané čistě v Xlib, ti co argumentovali tím, že potřebujeme lepší API, lokalizaci, přístup pro postižené, podporu drag-drop atd. byli posíláni do oněch míst, protože nechápou, že to odporuje "filozofii" unixu atd atd atd. Ještě předtím byli lidé, co trpěli infarkty kvůli samotnému X11, protože to je prý jako Windows, na unixu to nemá co dělat, správný admin dělá všechno ve vi (nebo v emacsu) a nikdo jiný, než admini, zřejmě počítače nepoužívá. Nic nového pod sluncem. Až implementujete piškvorky, které nemají zbytečné závislosti na libc a na kernelu, a nebrání vám tak v té tolik ceněné možnosti výběru, tak mi dejte vědět.

Ale tesi me, ze systemd usetri strasne moc prace s psanim par shell skriptu lidem, kteri napriklad napisi databazi s kodem 15 km dlouhym. Tech 100 radky v bashi by uz asi nezvladli.

Právě, že by je nezvládli, protože oněch 100 řádků v bashi je nejen na každém distru, ale pomalu na každém jednotlivém počítači jiných. A nestydíte se vůbec takhle vnucovat bash? Co možnost výběru? Co když trvám na tcsh?

To je právě příklad toho, co se systemd snaží řešit. Vývojáři databáze k ní přiloží jeden unit soubor a hotovo, uživatel ani oni už nemusí dál nic řešit. Prostě to funguje.

Tak piškvorky, pokud jsou (jako že asi jsou) založené na frameworku gnome, bez systemd asi opravdu nepoběží, protože bez něj neběží gnome. Na tom ale není vůbec nic nového.

Tak Gnome je uz davno docela monstruozita samo o sobe. Pokud Gnome ma byt dovodem, proc vsichni potrebuji systemd, tak vezte, ze spousta lidi Gnome nepouziva.

Tak kdyz uz chces prudit na tohle tema... tak zkus zapocitat naklady na bambilion spousteni shellu v klasickych init resenich.

Co to s lopatou melete za blbosti? Spousteni sluzeb je u systemd uplne stejny jako u klasickyho initu a stejny jako u jakyhokoli jinyho initu v UNIXu. Spusti se shellovej skript kterej spusti danou sluzbu. shellovej script se po startu sluzby ukonci a parrentem procesu se stane init. Tak to funguje u System V init, OpenRC, Runit, Systemd i SMF u Solarisu. Jedinej rozdil u Systemd a SMF je ze je tam navic textak popisujici jak presne se ma ten script (pripadne kontrolni exac treba apachectl) spoustet.

Ja vim presne jak systemd funguje. Uz sem nejen pro nej par servicu delal. Type je jen nastaveni supervisoru. Nijak to neresi, veci jako nastaveni prostredi, zmeny uzivate atd. Sice tam mas ExecStartPre, ale psat do toho naky pre checky ci cleanup to by bylo dost pro masochisty.
Cili pro par service presne navrzenych systemd to neusetri nic, protoze to misto shellovyho scriptu otevre textak. A pro cokoli se slozitejsim spoustenim to veme dvakrat vic file deskriptoru, protoze krome spousteciho scriptu musi nejdriv ten textak, aby ten script vubec nasel.

A to ze se usetri jeden file deskriptor na inetd, kdyz si to otevre 20 dalsich fakt nemuzes myslet vazne...

Nesirim FUD jen rikam jak to je. Tech servicu kterych start up script potrebuje je porad hodne a to cislo se nikdy blizit nule nebude.
Mas pravdu, ze pokud ten textak parsuje primo systemd pri startu, tak na ukor permanentniho naroku na pamet teoreticky v idealnim pripade nemusi spoustet dalsi interpret (shell) pokud to sluzba nevyzaduje.
To uz ale neplati pri manualnim spousteni sluzeb, kdy je narok vzdy minimalne stejny ci vyssi nez u klasickyho initu.

systemctl + .service (+ shell + script) + samotnej service

vs.

shell + script + service

Kazdopadne vsechno pohle je naprosto bezpredmetny, protoze ten script bezi vzdy par sekund, takze v realu systemd nenabizi vubec zadnou vyhodu na ukor pameti a slozitosti...

To mas jednoduche: Vezmi si dva podobne systemy - se systemd a s nejakym prainitem a nastartuj je. Podivej se na PID sveho login shellu.

" Ondra Satai Nekola 81 Zlatý podporovatel

To mas jednoduche: Vezmi si dva podobne systemy - se systemd a s nejakym prainitem a nastartuj je. Podivej se na PID sveho login shellu.
"
Vazne by me zajmalo na co je tohle reakce...

@BR

Na to, kolik doopravdy systemd spousti shell scriptu resp kolik je potreba procesu na nastartovani systemu.

OK, muzu porovnavat debian se systemd, kde bezi ssh, httpd a proxy oproti openwrt s busyboxem, kde bezi ssh, httpd, pppd, hostapd a dnsmasq
Debian ukazuje po startu posledni PID 1647
openwrt ukazuje PID 1676.

Kde ze je tech "bambilion spousteni shellu v klasickych init resenich", ktery systemd usetri?

systemd navíc umí socket activation, který ještě více šetří zdroje pokud chceš, tohle shell based inity neumí vůbec a musíš na to vzít další komponentu (inetd).

Cim presne je lepsi pouziti komponenty systemd namisto jine komponenty (inetd)? Ten systemd to jaksi nedela zazracne zadarmo, ale ma na to zase nejaky ten necod, ktery tam musi bezet misto initd a otazka je, jestli to dela nejak lepe nebo usporneji.

Naivko. Co chteji uzivatele a co chteji vyvojari je dost casto v primym rozporu... Tim myslim uzivatele, kteri sou schopny pochopit jak to funguje.
Samozrejme BFU je uplne jedno jak to funguje, takze jim muzou vyvojari klidne vnutit i takovou obludku jako je systemd...

A co jako? Jakoze kdyz muzes limit menit, tak limit neexistuje? Porad to nemeni nic na tom co sem napsal. Jadro dokaze zpracovat jen omezeny mnozstvi file deskriptoru. Proto tam ten limit je...

Soft limit je uplne neco jinyho. Soft limit a hard limit se uplatnuje na uzivatele (ulimit) a s nastavenim jadra nema nic spolecnyho.
Limit v jadre je prave to na co si odkazoval a ma zabezpecit stabilitu jadra. Samozrejme muzes si to menit, ale jako u spousty dalsich nastaveni jadra se pak nesmis divit az ti zacne padat...

Koukam, logicky mysleni neni tvoje silna stranka co?
Proc myslis, ze to nastaveni vubec v jadre je? Pro strandu kralikum?
Maximalni pocet file deskriptoru muzes menit, ale ne nijak dramaticky, protoze moc vysokym pocem ohrozujes stabilitu pocitace (resp. muze vycerpat volnou pamet).
Linux Dokumentation project doporucuje 256 filedeskkriptoru na 4MB pameti.
http://tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec72.html
Cili je to omezeny resource a ne ze ne. To ze ten limit je bezne ve stovkach tisic sem nikde nerozporoval...