Hlasování o systemd v Debianu

Michael Stapelberg ve svém blogu informuje o proběhlém výzkumu ohledně systemd. Podle něj 62 % lidí vítá zavedení systemd do Debianu a 44 % si přeje, aby byl systemd defaultním init-systémem. Uvádí také seznam nejvážnějších důvodů, které respondenti uvedli proti systemd.

28.5.2013 11:37 | Jakub Lucký | Komunita

Komentáře

[Martix.]

1. systemd is too complex, or bloated, or it does too many things, or has too many dependencies (weight: 217)

2. systemd is not portable to non-linux systems, e.g. Debian/kFreeBSD or HURD (weight: 199)

+1

Jinak ostatní důvody jsou přinejmenším diskutabilní nebo dokonce sporné.

[Mrkva]

Co trojka?

[adsfds]

No treba binarni logy rozhodne nejsou diskutabilni. Je to zlo.

[Robert Smol]

Proc je to zlo?

Tim ze je to strukturovane, lze delat lepsi/automaticke parsovani, je to rychlejsi i na vyhledavani.

Vite, ze kernel log (kmsg) je take binary a to Vam nevadi?

Co Vam brani si nad systemd pustit normalni logger (dle vasi preference) a normalni si nakonfigurovat loggin tak jak vam to ted vyhovuje (vetsina distribuci to stejne dela za Vas).

Zkousel jste journal?

K tomu bodu 1) bloated to rozhodne neni, kouknete do repozitare, uvidite, ze to je spousta malych citelnych a spravovatelnych submodulu.

bod 2) Ano, nelze to portovat. Duvod je ten, ze ostatni systemy neposkytuji v kernel potrebne API. Chapu, ze pro lidi z BSD to je problem, ale uz jsem takovy system nepotkal ani nepamatuji.

Krome bodu 2 mi to vse prijdou jako liche duvodu. SystemD je stabilni, rychly a moderni spravce procesu, jsem s nim velmi spokojen.

[chrono]

Keď nájdem niekoho, komu SystemD nefunguje stabilne, bude SystemD dobrý len na 50%?

[Robert Smol]

Nerozumim, co se snazite rici. Ty dve posledni vety meho prispevku byly muj osobni nazor.

[Luboš Doležel (Doli)]

Je to jen otázka zvyku. Jinak na OS X/Darwin už něco takového je - ASL - a je to docela praktické.

Jen je škoda, že je to zase další duplicitní unixové API.

[adsfds]

Ne, neni to otazka zvyku. Je to otazka moznosti zjisteni co se sakra stalo kdyz se neco vy5ere.

[lyon]

Hm skoda, ze mi survey uniklo. Hlasoval bych proti. :-/

[tomasgn]

+1

je jeste nejake distro, ktere tim svinstvem neni zavsivene, a ani o tom v neuvazuje? nebo uz zbyva pouze utek k *bsd a doufat, ze se tim morem taky nenakazi?

[Luboš Doležel (Doli)]

Gentoo?

[tomasgn]

zatime me debian jeste bez systemd bezi, ale je videt, ze se jim uz podarilo propasovat zavislosti na jakychsi jeho knihovnach do znacne casti systemu to je zajimavy, ze po cem nic, to se rozsiri jak stepni pozar.

[David Heidelberg]

sice zatím OpenRC, taky se o tom uvažuje a postupně začleňuje. Už jsem na něj přešel na jednom Gentoo stoji a předčilo to očekávání, z pohledu admina/usera, samé výhody.

Například Sabayon co vychází z Gentoo nabízí už možnost v posledím vydání přepnout se na systemd a přene na systemd co nevidět.

[chrono]

Na čo presne sa ten počítač so SystemD používa? (pretože na mojom počítači si momentálne žiadne výhody neviem predstaviť)

[rastos]

Slackware

[R]

Tam su init skripty neudrzovatelny bordel.

[Martin Matějek]

Vzhledem k tomu, že už jsou dávno odladěné a ve Slackware se zas tak moc věcí nemění - spíš se aktualizuje software na novější verze než že se přidává něco nového - tak si myslím, že jsou v pohodě udržovatelné.

Škoda, že z eudevu asi nic nebude (jestli ano, tak za dlouho). Na druhou stranu, pokud systemd nezatáhne do udevu nějaké zpětně nekompatibilní API, které bude vyžívat nový software (třeba GNOME), tak v klidu můžeme zůstat u udev-182 a BSD init skriptů.

[R]

Ano, su odladene tak vyborne, ze ked mas 32MB RAM, tak devtmpfs ma tak malo inodov, ze to nestaci na normalny beh udevu. Na povolenie smartd treba skripty editovat. Instalacia apcupsd je problem, pretoze nie je v distribucii a treba editovat skripty (konkretne v Debiane je instalacia trivialna). Cim viac veci tam je nainstalovanycvh mimo distribucie, tym vacsi bordel v tych skriptoch vznika. A kedze je tam dodnes ako SMTP server iba sendmail, tak prakticky nie je mozne pouzivat system bez externych balikov.

Nehovoriac o tom, ze v tych skriptoch je milion zbytocnosti okolo desktopu (regenerovat vselijake cache a pod.), ktore zbytocne spomaluju boot a treba ich zrusit (pouzival som Slackware x rokov, vzdy som to mal zakomentovane a nikdy mi to nechybalo).

[pc2005]

Na povolenie smartd treba skripty editovat.

A ona je nějaká jiná, lepší možnost?

[R]

Ano, editovat konfiguracny subor (napr. /etc/default/smartmontools v Debiane) a nie priamo init skript, kde je vsetko nadrbane dokopy.

[Martin Matějek]

Na povolenie smartd treba skripty editovat. Instalacia apcupsd je problem, pretoze nie je v distribucii a treba editovat skripty (konkretne v Debiane je instalacia trivialna).

Zrovna s smartd je to takové podivné (nejsem jediný, kdo ve Slacku našel spuštění smartd čirou náhodou), mdadm a třeba dhcpd nemají vlastní init skript. To zrovna moc odladěné není.

Cim viac veci tam je nainstalovanycvh mimo distribucie, tym vacsi bordel v tych skriptoch vznika.

To je otázka. Důležitý software (databáze, dhcp, apod.), i mimo oficiální balíky, obsahuje init skripty a funguje sám od sebe, takže není co řešit. Sem tam člověk musí init skripty upravit, ale asi jsem si na to už zvykl, tak mi to nevadí.

Spíš mám občas pak mám opačný problém. Na init systémech s vlastní správou spouštění obvykle zapomenu aktivovat danou službu a pak se divím proč se nespouští (obzvlášť u sítě to naštve).

Prostě otázka zvyku. Kromě Slackware používám ještě Gentoo a tam mi trvalo asi půl hodiny než jsem pochopil (z příručky a zdrojů na internetu) jak fungují OpenRC init skripty. Proti tomu jsou čistě bashové skripty (základní proměnné, fce start, stop a restart) krásně jednoduché a přehledné. Ok, když člověk pochopí jak OpenRC funguje, tak je to jednoduché, ale na první pohled to nedává vůbec smysl.

[pc2005]

Ujdou, zbytek systému je horší. Zvlášť pokud chce člověk nějaký podivnosti jako podporu 32 bit ELF na 64 bit gcc nebo okrajový software a zároveň to zase nechce natolik, aby si nainstaloval gentoo (samozřejmě).

[kavol]

Hm skoda, ze mi survey uniklo. Hlasoval bych proti. :-/

no, proč mi to jen připadá jako "zorganizujme anketu ... pojďte si všichni příznivci zahlasovat za systemd!"

[pc2005]

Průzkum:

Otázka: Myslíte, že je v Británii příliš mnoho imigrantů?

Odpověď: 17% - ano, 11% - ne, 72% - nerozumět otázka.

[Foo Bar]

Zvláštní, že je Vám blaho Debianu leží na srdci pouze ve chvíli, kdy se řeší systemd. To nebyla uživatelská anketa, ale anketa pro vývojáře, kteří pak dopady změny init systému budou muset řešit.

A jen se proboha do d-d nepřihlašujte. Trollů tam máme dost i bez Vás.

[chrono]

Väčšina hlasujúcich, podľa informácií na tej odkazovanej stránke, neboli vývojári.

[kavol]

To nebyla uživatelská anketa, ale anketa pro vývojáře, kteří pak dopady změny init systému budou muset řešit.

to je velmi zvláštní argument ... a uživatelů se to jako nedotkne? ti nebudou muset nic řešit?

[Foo Bar]

Většina uživatelů to opravdu řešit nebude. Ale na vývojářích leží zodpovědnost (a taky je to stojí čas). Čímž neříkám, že se na názor uživatelů nemá dbát, ale rozhodně nelze dělat rozhodnutí na základě těch nejhlasitějších. Nevolíme Krále majálesu, ale init system.

[kavol]

Většina uživatelů to opravdu řešit nebude.

tady bych viděl jedno velké [Citation needed]

tuším, že vpodstatě všechny lamy, co jim je jedno, co maj za systém, jestli Wokna nebo co, hlavně když jim to browsí a jedou ty fejsbůky a skájpy, jsou u Ubuntu

u Debianu pak zůstává "skalní jádro", tvořené především sysadminy - a ti to teda sakra budou řešit

no ale jestli existuje nějaký věrohodný rozbor, že se pletu, že Debian používaj samý lamy, kterejm je u prdele nějakej initsystém, a že navíc tyto lamy ten initsystém nebudou (muset nechat svými zkušenějšími kamarády) řešit, protože se jich nebude týkat žádný z bugů zde porůznu zmíněných i dalších život uživatele dosti znepříjemňujících, tak sem s ním

... na druhou stranu je pak otázka, když si toho většina uživatelů ani nevšimne, tak proč to vůbec měnit, že

[Jiří J.]

Já třeba jako jeden z bodů právě uvedl tu "monstrozitu" - ano, je to skupina menších modulů, ale ty moduly zásadně mění základy celého systému a trendem je přidávat takových modulů a překopávek víc. Systemd už dávno není jen init systém - nevolil se tedy init systém, ale v podstatě základ userspace. (!)

Ano, většina modulů je "optional", ale kdo/co zaručí, že to tak zůstane i v budoucnu, zvlášť s Lennartovou vidinou budoucnosti?

Osobně nejsem striktně proti systemd nebo jinému init systému, ale jsem spíše skeptický k těmto "hurá" akcím, zvlášť pokud tak zásadně zasahují do systému. Silně jsem byl taky proti Waylandu, dokud jsem nezjistil, že jejich oficiální idea není kompletní nahrazení X s nějakou pomalou vrstvou kompatibility.

Wayland is a graphics multiplexer for a number of X servers. Linux today typically only uses one X server for GDM and the user session, but we'll probably see that move to a dedicated GDM X server, an X server for user sessions (spawning more on the fly as more users log in) and maybe a dedicated screensaver/unlock X server.

Má to co dělat se zvykem, ale taky se zkušenostmi - ať už jde o Gnome 3, Pulseaudio nebo každodenní používání a lazení (současného) systemd na Fedoře a Fedora-based distrech.

[Jirka]

Ale nééé!

[Fantomas]

A sakra, uz je to tady

[Radek Podgorny]

vsem (zvlaste pak tem s negativnimi nazory) bych doporucovat systemd nejdrive vyzkouset a nespolehat na informace typu "jedna pani povidala". on pak clovek totiz treba zjisti, ze systemd ma svou mnozinu spatnych veci, ale vysledne je mnohem lepsi nez veskere ty init+miliarda_krehkych_bashovych_obludnosti zvracenosti v beznych distribucich...

[chrono]

Tie krehké bashové obludnosti mi bez problémov fungujú viac ako 10 rokov. ;)

Každopádne pred pár dňami som sa rozhodol, že si SystemD nainštalujem a po prečítaní dostupnej dokumentácie som zistil, že čas pre SystemD na mojom počítači ešte nenastal (pretože nie pre všetky služby existuje SystemD náhrada a emulácia SysVInit funguje len v tých najjednoduchších prípadoch a navyše aj tak by som v takom prípade musel používať tie bashové obludnosti, takže to nemá žiadny význam).

[dumblob]

Mel jsem k systemd skepticky postoj a jisty odstup mam doposud. Ale jednu vec mohu smele prohlasit - napsat si nejaky prumerne slozity service je docela jednoduche a jejich nedostupnost tedy nepovazuji za argument.

[chrono]

Skript, ktorý robí to isté ale písať nemusím (a ak by som aj musel, nemusím kvôli tomu čítať ďalšiu dokumentáciu).

[dumblob]

Kdyz se rozhodnu si koupit nove auto, tak take predpokladam, ze si do neho budu muset koupit stejne potahy (avsak delane na miru tomuto modelu), aby zevnitr vypadalo obdobne (pochopitelne nelze docilit uplne stejneho vzhledu/chovani) jako moje stavajici auticko .

[ET]

nj, jenze tedka ti kupuje auto nekdo jinej... :(

[dumblob]

Smim se zeptat co je na vete

Každopádne pred pár dňami som sa rozhodol, že si SystemD nainštalujem...

v odkazovanem prispevku nejasne?

[chrono]

Rozhodol som sa preto, lebo aj tak o chvíľu už inú možnosť mať nebudem. ;)

[tomasgn]

zajimave, ze me ty _krehke_ shellove (nejan bashove) zalezistosti chodi podstatne lepe a spolehliveji, nez vselijake nahrazky, vcetne systemd.

[mrv]

az na to, ze nedokazi spolehlive zastavit/restartovat daemony, protoze nad nimi nemaji spolehlivou kontrolu. ale jasne, jde o nepodstatny detail ;)

[tomasgn]

ano, to je ohromny problem. az tak velky, ze si vubec nevzpominam, kdy jsem neco takoveho naposledy resil. a proto tento pseudoproblem - a oblibeny argument zastancu systemd - vyresime zavlecenim dalsiho pochybneho systemu.

[adsfds]

Asi tak. A pripada mi opravdu trapne pri problemu demona proste restartovat a nestarat se o duvod problemu. Muze to byt take vazne bezpecnostni riziko => systemd prokazatelne snizuje bezpecnost vaseho systemu.

[Radek Podgorny]

btw: supervision neni (jen) o tom, jak automaticky hlidat, jestli daemon nespadnul. je to dost treba o moznosti posilat daemonum primo signaly.

[Foo Bar]

Nedá mi to...

Je docela vidět, že jste nikdy nic pořádného neřešil...

Ve chvíli, kdy provozujete trochu náročnější systém, který musí běžet stále, tak dříve či později skončíte s nějakým supervizorem. A /etc/inittab je supervizor na dvě věci.

A popravdě řečeno jestli to mají být daemontools, upstart nebo systemd je mi fakt jedno.

Aneb největší emoce vzbuzují věci, o kterých lidé ví zbla, ale hlavně že mají názor...

[kavol]

Je docela vidět, že jste nikdy nic pořádného neřešil...

je docela vidět, že někteří mají problém vystoupit ze své bubliny a myslí si, že jen to jejich milované je to nejdůležitější a pravé

A popravdě řečeno jestli to mají být daemontools, upstart nebo systemd je mi fakt jedno.

hm, v tom případě ale proč znovu vynalézat kolo, když řešení existují?

[Solitary]

Protoze bychom dodnes jezdili na kamenych valcich jako Flintstonovi nebo by nase auta mely drevena kola jako u kocaru... tahle analogie se znovu vylezanim kola je u software dost ohrana a nepouzitelna.

[kavol]

opravdu nechápu, proč kamenný válec nahrazovat ... kamenným válcem?

[Foo Bar]

To by mne zajímalo, co je to moje milované. Požadavek na nepřetržitou funkci různých daemonů je tak nějak základ provozu nějaké produkční služby, na tom bychom se mohli shodnout, ne? A pokud výsledné rešení přinese tuto funkcionalitu i do neprodukčního prostředí, tak se tím minimálně nic nezkazí.

Protože integrace daemontools (nebo runitu) do systému není příliš snadná, a navíc to umí jen základní funkcionalitu (tj. udržet službu v chodu a logovat stdout/err do souboru).

Domnívám se, že inovace init systému i se změnou paradigmatu je nutná.

[kavol]

To by mne zajímalo, co je to moje milované. Požadavek na nepřetržitou funkci různých daemonů je tak nějak základ provozu nějaké produkční služby, na tom bychom se mohli shodnout, ne?

no, teď ještě nadefinovat, co je to ta "produkční služba" ...

máme zákazníky, kteří mají priority naprosto odlišné

Protože integrace daemontools (nebo runitu) do systému není příliš snadná, a navíc to umí jen základní funkcionalitu (tj. udržet službu v chodu a logovat stdout/err do souboru).

aha, daemontools (nebo runit) je jediné možné řešení, jasně, no tak to se pak nedivím, že si někdo na to potřebuje napsat systemd ...

Domnívám se, že inovace init systému i se změnou paradigmatu je nutná.

dejme tomu, že bychom na tuto domněnku přistoupili - ale já se ptám, proč kvůli tomu znovu vynalézat kolo?

[mrv]

ty mas zakazniky, jejihz prioritou je, aby sluzbe nebezela? nebo aby aspon nevedeli, jestli skutecne bezi a nesla spolehlive vypnout?

kdo ti zakaznici jsou? lide z bohnic?

[kavol]

řekl jsem něco takového? - začínám pozorovat trend, že příznivci systemd mají podstatně větší potíže s logikou (non [nepřetržitá funkce] != neběží vůbec) a obecně argumentačními fauly, nežli odpůrci ...

ale že jsem zrovna v dobrém rozmaru, tak osvětlím, že pro někoho je důležitější například bezpečnost systému (splnění nějakých formálních kriterií a na tom založená certifikace) nežli Lennartovy vlhké sny o kontrole démonů

[tomasgn]

Nedá mi to...

Je docela vidět, že jste nikdy nic pořádného neřešil...

to vidis docela blbe.

resim toho dost a denne, a zatim videl _mnohem_ vice problemu se vselijakymi prerostlymi a vsechnomozne zvladajicimi (papirove) supervisory, nez s jednoduchymi initscripty nebo inittabem.

[Robert Smol]

Mozna Vam neco bezi 10 let v bashi fajn, ale to mate asi jen jeden system. Kazda distribuce ma vlastni podpurne init skripty. Nelze pouzit jeden bash skript pro start a integraci s initd procesem vasi aplikace (kazda distirbuce dodava vlastni).

Pro kazdou sluzbu exitsuji jine konfiguracni soubry ( conf.d / sys-config a debian ma urcite take vlastni 'default' mista).

Jednou mate /var/log/messages jednou /var/log/syslog.

systemD ma prehlednou konfiguraci a unifikuje distribuce na urovni kontroly procesu, to je preci jasne plus.

Jasne ze to neni bez chyby, ale dle mne to je jasny krok vpred.

[Honza Jaroš]

systemD ma prehlednou konfiguraci a unifikuje distribuce na urovni kontroly procesu, to je preci jasne plus.

Mám pocit, že právě ta unifikace je jádrem sporu: ne každému vyhovuje ten "jeden správný" způsob. Je vhodné na to nezapomínat - nejen u systemd, i obecně v životě...

[kavol]

+1

[citanus]

+∞

[tomasgn]

+1

[tomasgn]

a vy zase vidite jen linux. aix, hp-ux, solaris a dalsi, taky pouzivaji sve skripty nebo jina reseni. hodlate ty lennartoviny protlacit i tam?

prave stav, kdy se veskere linuxove distribuce nechavaji dotlacit do stejnych nesmyslu, takze nakonec mozna dojdeme do stavu, kdy se budou lisit jen logem a jmeny vyvojaru, mozna jeste rozsahem repozitaru, mne moc netesi.

[Michal Vyskočil]

a vy zase vidite jen linux. aix, hp-ux, solaris a dalsi, taky pouzivaji sve skripty nebo jina reseni. hodlate ty lennartoviny protlacit i tam?

Ehm, zrovna Solaris už nějaký čas běhá na SMF.

[kavol]

a vy zase vidite jen linux. aix, hp-ux, solaris a dalsi, taky pouzivaji sve skripty nebo jina reseni. hodlate ty lennartoviny protlacit i tam?

Ehm, zrovna Solaris už nějaký čas běhá na SMF.

čemu nerozumíš na "nebo jiná řešení"?

[Michal Vyskočil]

čemu nerozumíš na "nebo jiná řešení"?

Prosté přehlédnutí - pokud bych jiná řešení viděl, pochopitelně bych napsal, že ten výrok postrádá smysl.

[mrv]

ano, to je ohromny problem. az tak velky, ze si vubec nevzpominam, kdy jsem neco takoveho naposledy resil. a proto tento pseudoproblem - a oblibeny argument zastancu systemd - vyresime zavlecenim dalsiho pochybneho systemu.

ja jsem nikdy neresel problem s tim, ze by mi dosel benzin. znamena to, ze nedostatek benzinu je pseudoproblem? a ze vsechny benzinky by tedy mohli zavrit? a to jen proto, ze ja sam nejezdim autem? tak asi jo, ze?

cool logic, bro ;)

btw. zkus to co pises priste podlozit argumentem, pak to treba nebude vypadat jako uplna kravina. nebo ti dojde, ze to kravina je a pak to nebudes muset psat a nebudes ze sebe delat hovadko -> profit!

[mankind_boost]

Ta logika je možná stejná, ale pravděpodobnost - to je oč tu běží.
Kdo někdy musel řešit takový problém? Je to spíše urban legend Kdežto zavedení systemd rozbije tolik věcí v systému, že se to bude opravovat roky...

Systemd bych možná i překous, kdyby to byl jen init. Ale on je to v podstatě systém v systému Netrpělivě čekám na plugin pro systemd, který mi umožní ovládat klimatizaci, přehrávat gramofonový desky a odpalovat ICBM.

PS: Mohl bys trochu ubrat s urážkama, snižuje to úroveň tvou i tvých komentářů.

[kavol]

az na to, ze nedokazi spolehlive zastavit/restartovat daemony, protoze nad nimi nemaji spolehlivou kontrolu. ale jasne, jde o nepodstatny detail ;)

ach ano, to je tak důležitá featura, že systemd restartuje démony, které restartovat nemá, jen aby ukázali, že to umí

[iik]

Naopak zase ty, která restartovat má nerestartuje. Dokonce se tváří, že chcíplí démoní běží. Za posledních dvacet let jsem měl méně problémů s "bashovými obludami" initskripty než s geniálním systemd za minulé dva roky. A navíc problémy s init scripty šly snadno vyřešit.

Hlavně, že nás magoři zunifikují pod jedním správným magorským systemd.

[trekker.dk]

Hm, jedna sra.ka startuje druhou...

[mrv]

vazne? takze ty mi tu argumentujes PEBKACem? lol, ty by ses fakt mel jit lecit ;)

[mrv]

pokud chces daemona zastavit tak ten prikaz je "disable". ale jasne, debilite se meze nekladou. lepsi nahlasit bug a pak si honit nad tim, jak to nefunguje nez si precist navod...

OMFG, clovek by cekal aspon tady nejaky zakladni level kompetence. to i na ubuntu forech jsou schopnejsi lidi :P

[kavol]

pokud chces daemona zastavit tak ten prikaz je "disable".

vskutku?

https://bugzilla.redhat.com/show_bug.cgi?id=815243#c8

"Your two options are 'disable' and 'mask', where disable makes the service a manually-started one, including at boot time."

to ale jaksi není to, po čem bychom toužili, ba naopak, ta služba by se po bootu spustit měla

ale jasne, debilite se meze nekladou

také jsem si říkal, ale nechtěl jsem být tak drsný, pořád jsem ochoten věřit, že seš už takhle ve dvě odpoledne totálně zkalenej na šrot nebo sis zatemnil mozek jiným způsobem, a nikoli že to máš od přírody ...

[kavol]

vsem (zvlaste pak tem s negativnimi nazory) bych doporucovat systemd nejdrive vyzkouset a nespolehat na informace typu "jedna pani povidala". on pak clovek totiz treba zjisti, ze systemd ma svou mnozinu spatnych veci, ale vysledne je mnohem lepsi nez veskere ty init+miliarda_krehkych_bashovych_obludnosti zvracenosti v beznych distribucich...

a třeba taky nezjistí, že?

systemd "zkouším" už několik verzí Fedory, a zatím nepozoruju [!= nemůže existovat] žádný přínos, zato pozoruju problémy, které jsem dříve neměl (zmíněný bug #815243; nutnost vykopat tmp z tmpfs; několik desítek mega sežrané paměti; akce, které se dříve dělaly v initskriptech/dělal si je démon sám, jsou nyní v samostatných utilitách popř. si to musí uživatel vyřešit ručně; a na kolik jsem toho přišel v rámci našich interních testů darmo mluvit ...)

[Radek Podgorny]

...no tak znova: vyzkousejte to a AZ PAK nadavejte!

p.s.: za posledni roky jsem provozoval initu nekolik (openrc z gentoo, daemontools, runit, ...) a muzu ZA SEBE rict, ze systemd je zatim idealni kompromis.

kdykoliv se objevil problem se shell-based initem, debugovani bylo peklo (spousty skriptu, ktere se sourcuji mezi sebou, navzajem se prepisujici stavove promenne, ...).

supervise-based inity jsou zase spolehlive, ale chybi jim jista flexibilita. a kdyz si nedate pozor, nejaky zblazneny demon vam taky muze se systemem pekne zacvicit.

v systemd mam supervision, kdyz chci a nemam, kdyz nechci. a ta rychlost...! to se proste musi zazit.

ad. binarni logy: taky je zatim nemam moc rad a resim s tim par problemu. na druhou stranu, kdyz vam 'systemctl status nejaka_sluzba' presne vypise stav, pid, casy, a kdo vi co jeste o spustenem procesu a jeste k tomu prida kus logu, velmi brzo zjistite, ze rucne grepovat nejaky log, ktery je predtim jeste nutne kdesi najit, je ponekud zastarala metoda...

nikomu nic necpu, ale za sebe jsem rad, ze arch na systemd presel.

[adsfds]

zvlast ta "rychlost" pri systemctl status, to je fakt na posrani...

[Radek Podgorny]

s cim konkretne mate problem? jestli jde o tu nekonecnou dobu pri prvni parsovani logu (tyka se i journalctl, je to bug, ktery se prave resi - mozna to souvisi s btrfs). pak doporucuji 'systemctl status -n0 nejaka_sluzba' a nemel by byt problem...

[mankind_boost]

"velmi brzo zjistite, ze rucne grepovat nejaky log, ktery je predtim jeste nutne kdesi najit, je ponekud zastarala metoda" V tuto chvíli mi to docvaklo - vy z Linuxu nechcete mít Unix, vy chcete Windows!

[Radek Podgorny]

...zjevne netusite, co jsem mel na mysli.

[mankind_boost]

Grepování funguje už desítky let a dosud nebylo překonáno. Funguje u jakkýchkoliv logů se 100% úspěšností, kdežto pokud bude mít každý program svůj vlastní příkaz pro čtení svých logů, tak z toho adminům asi hrábne. Jakou *využitelnou* výhodu mají binární logy, proboha?

[Radek Podgorny]

odpovedel bych, ale, nezlobte se prosim, je videt, ze jste systemd nikdy nepouzival. je tedy bezpredmetne to vysvetlovat, kdyz si to muzete zkusit sam...

[mankind_boost]

Stále jsem se nedozvěděl, v čem že je ten binární log lepší. Mohl byste mi to podrobně vysvětlit? Děkuji.

[Radek Podgorny]

...vazne si to nedokazete najit sam?

http://0pointer.de/blog/projects/journalctl.html

...nekde existuje i nejaka video-prednaska primo od lennarta (zhruba o tom samem).

[mankind_boost]

To je jen nějakej tutorial k příkazu. Vůbec neodpovídá na mou otázku.

[adsfds]

+1. A podle me neexistuje jedinej rozumnej duvod _pro_ binarni logy.

[jadd]

Vypadá to na důvody kompatibility s Windows

[jadd]

Bezpečnost u přihlašovacích logů, asi taky bude hrát roli.

[bugme]

To si delas prdel, ne?

[jadd]

pršelo

[mankind_boost]

Jo a ještě chci dodat, že systemd jsem POUŽÍVAL. Ale jen na desktopu. A popravdě - stojí to zrychlení startu o 2 sekundy za totálně překopanej systém? Problémy se s tím budou táhnout ještě dlouhá léta a bez výraznějšího prospěchu.

[biolog]

Grepování funguje akorát na nestrukturovaných textových souborech, možná ještě na CSV souborech. Cokoliv co je dost složité aby to mělo gramatiku, grep nezvládne - neříkám že spadne, ale obsahu nerozumí a tedy je užitečný méně než by bylo na místě.

Tedy když mají být v logu nějaké strukturovanější informace, třeba jen hloupé datum a hledat podle rozsahu datumů, tak grep neuspěje. A jestli jsem to dobře pochopil, tak každý program bude mít stejný příkaz. Programátoři nebudou psát každý svůj nástroj, to je snad jasné.

[Foo Bar]

Trololol...

Podobnou funcionalitu (zjistit jednoduše aktuální stav procesu) lze nalézt například i v daemontools (nebo alternativně v runit), ale integrace se zbytkem systému byla vždycky tak trochu na hlavu.

Stav, kdy si každý maintainer balíku musí zmastit vlastní shellový skript je prostě na hlavu a spousta duplicitní práce, a uvítám libovolný pokrok vpřed. A klidně ve svých balících budu podporovat i dva init systémy.

Supervizované procesy, které se jednotně a snadno spravují je správná cesta vpřed. Možná to bude chvíli bolet jako bolí každá změna paradigmatu, ale to bolel i přechod na ELF formát nebo třeba přechod z libc5 na lib6. (Pak ještě dselect, ten bolel dost sám o sobě i bez nějakého předchodu někam...)

Mimochodem nechápu proč je to v Linuxu takový problém, když třeba Solaris má už dávno SMF (a to jsou většinou stroje, na kterých běhají mission-critical aplikace), nebo Mac OS X má launchd.

[Rejpal]

Tahat do debianu, což je podle mě stabilní systém, správce balíků, kteří mají problém psát v bashi nebo problém pochopit balík natolik, aby zvládli napsat jeho startovací skripty je cesta do pekel.

[tomasgn]

Mimochodem nechápu proč je to v Linuxu takový problém, když třeba Solaris má už dávno SMF (a to jsou většinou stroje, na kterých běhají mission-critical aplikace), nebo Mac OS X má launchd.

zrovna se SMF jsem mel uzasne zazitky. zatimco pri chybe v nejakem klasickem initscriptu nenabehla jedna sluzba, SMF se dokazal pri updatu systemu dodrbat tak, ze kvuli chybe v nejake postradatelne sluzbe po rebootu zustal polomrtvy system, kam se dalo prihlasit jen pres konzoli. jakakoliv dalsi prace se SMF je des bes, zlaty initscripty a jejich obvykle prislusenstvi.

nezlobte se, ale me skutecne tyto "dokonale" systemy zatim presvedcily jen o tom, ze dokazi vyrobit problemy, ktere by bez nich nebyly, a ze initscripty jsou lepsim resenim.

[Chytrex]

+1

[iik]

Velmi trefné. Systemd je jako obšlehnutý z Windows - třeba tou veselou vlastností, že někdy nezvládne shutdown; vypnout komp lze pak jen pomocí kolíbky ON/OFF na zdroji. Takhle se chovaly Widle, když se s nimi nechtěl bavit Novel.

[Foo Bar]

Ach jo. Byly časy, kdy nebylo možné díky kombinaci Linuxového jádra a BIOSu vypnout systém jinak než "kolíbkou". Taky se podle Vás tenkrát Linus inspiroval ve Windows?

[mankind_boost]

Ono je to docela rozdíl - jestli chybí jadernej ovladač nebo je ta aplikace totálně zbastlená by design.

[Foo Bar]

Opět můžete to podložit konkrétními argumenty, jaké jsou chyby v designu návrhu systemd, nebo jste jen další troll?

[mankind_boost]

Reagoval jsem na vaši logickou chybu při přirovnání ke kernelu. Ale když to chcete...

Chyby v návrhu systemd:
-binární logy
-více než 25 (!) binárek
-snaží se dělat úplně všechno, což je v rozporu s unixovou filosofií
-podporuje pouze Linux (!!!)
-táhne za sebou spoustu závislostí (což je u initu opravdu smutné)
-na relativně mladý projekt obrovské množství bugů
-Lennart

[citanus]

me vadi zavislost na cgroups a dbus

[Foo Bar]

To jsou názory a nikoli chyby v designu.

[kavol]

myslímže například současné rozšíření a vůbec stav emacsu dosti vypovídá o tom, jestli je třetí bod "jen" názor, a zpochybňovat takový pátý bod, že to není chyba, se mi též zdá dosti, ehm, řekněme "odvážné"

hm, k třetímu bodu mě též napadá, pročpak se Mozilla Suite rozpadla na jednotlivé komponenty, nebo naopak proč ještě v jádře není X server, apod.

[Sešívaný]

nebo naopak proč ještě v jádře není X server

No, tak zrovna v případě Xsek už bylo prakticky všechno, co se dá, přesunuté do jádra. Po nástupu Waylandu pak mezi jádrem a kompozitorem prostředí už nebude vůbec nic.

[kavol]

nebo naopak proč ještě v jádře není X server

No, tak zrovna v případě Xsek už bylo prakticky všechno, co se dá, přesunuté do jádra.

"co se dá" ... ano, ovladače do jádra patří, a co jiného je tam přesunuto? snaží se jádro pohltit věci typu xauth, například?

Po nástupu Waylandu pak mezi jádrem a kompozitorem prostředí už nebude vůbec nic.

a proč v jádře nebude ten kompozitor? - vždyť to se taky "dá" ...

[mankind_boost]

+1

[citanus]

To jsou názory a nikoli chyby v designu.

to jste s tim ale rychle hotov.

[mankind_boost]

It's not a bug, it's a feature! - typický přístup microsoftu

Jsou to prostě VÝRAZNÉ (ne-li přímo klíčové) nedostatky. A co za to dostaneme?! Rychlejší boot? Ale prosim vás, to se Lennartovi podařilo někde v laboratorních podmínkách zrychlit boot o pár procent. Ochrana před double-forkingem? Kterej blázen by takovýho démona předevšim vymejšlel?

Jde o to, že nevýhody o dost převyšují výhody.

[mrv]

no pokud je to tak a systemd je tak spatny, tak je docela smutne, ze nedokazes zadnou z tech chyb v designu navrhu systemd pojmenovat. takze bud si dost hloupny/neschopny, a nebo to se systemd nebude tak spatne ;)

[mankind_boost]

1) Ty jsi nečetl můj příspěvek výše? Vyjmenoval jsem jich několik.
2) Nemáš argument, ale nadáváš mi? To si docela fandíš, frajere

[ee]

me vadi dbus a cgroup. Hlavne protoze to ze cgroup vnucuje spustu kodu v jadru a zavadi dalsi komplexni layer, ktery by mel spravce znat. chystam se na testing na poradnym hw(>250cpu a 1tbram) uvidime jestli se bude se systemd dat definovat affinity a mem place tak jak s initem. ale trosku pochybuji ze s timto pocita. Hlavne me ale trosku desi rhel7, ikdyz zase s rhel6 prisel selinux a taky se nak vstrebal... : )

no uvidime.o vysledek se mejak skrome podelim..

[kavol]

Hlavne me ale trosku desi rhel7,

no tak testuj, testuj ... potřebujem zákazníky, kteří řeknou, v čem vidí problémy, protože když něco reportujeme interně, tak se na to sere, jako např. bug #916168

ikdyz zase s rhel6 prisel selinux a taky se nak vstrebal... : )

ano, zákazníci se naučili setenforce 0

[nyan]

vsem (zvlaste pak tem s negativnimi nazory) bych doporucovat systemd nejdrive vyzkouset

Vzhledem k tomu, ze se (ne)davno objevil v Archu, sem ho "dobrovolne" vyzkousel.

Co jsem zatim zjistil:

The good:

1. boot & shutdown jsou rychlejsi. Ne o moc - SSD uz mam naky ten patek a navic zadavam heslo dvakrat (luks a dm). Tot asi vse. (Ne, kolik milisekund bezel kterej proces pri bootu me opravdu nezajima)

The rest:

1. Prvni vec co jsem zjistil ze nefunguje lvm nad luks. Todle mohlo byt ciste tim hurapristupem develu Archu... Takze hledat po forech unit pro lvm+crypto...pak (nekdy v pozdejsich verzich) to zazracne zacalo fungovat samo.
2. Dalsi vec me teda naprosto vytocila. Kdyz nahodou nemate pripojen disk uveden ve fstab (nebo z jakehokoliv duvodu neslo namountovat tu partition), pak misto okamziteho zobrazeni chyby systemd ceka az se ten disk objevi (mozna ho donese vila zubnicka). Timeout byl/je kolem 3 minut; v te verzi (tusim 197) jeste autori nepovazovali za potrebne vypisovat errory nebo vubec informovat uzivatele, ze se na neco ceka, takze sem cumel jako puk proc mi komp zamrznul (teda ja si myslel ze zamrznul). Je pravda ze novejsi verze systemd uz neco vypisuji.
3. Timeout na zadavani hesla pro luks je tak minuta mozna mene; pote vam systemd zahlasi fail a pomuze jedine reset. Takze na "stisknu power-on tlacitko kompu a na chvili odejdu nez nabehne po password-prompt" muzete zapomenout. Asi new programming paradigm, vsechno lze resit pridanim dalsiho timeoutu...

Nejnoveji se prestal aplikovat sysctl.conf, i kdyz systemctl hlasi ze byl spusten. Obecne to jsou spis annoyance nez opravdove problemy, ale zatim jedinej "prinos" systemctl byl, ze travim debugovanim Archu vic casu nez predtim.

[Foo Bar]

Arch je rolling, že?

[dumblob]

Ano.

[Foo Bar]

Tak to si dokážu představit, že přechod u rolling distribuce může být trochu náročnější než se odladí. Ale díky za konkrétní věci, které jste uvedl.

[dumblob]

Ale díky za konkrétní věci, které jste uvedl.

Ackoliv nejsem nyan, tak musim rict, ze kupodivu tech zavaznych problemu pri prechodu Archu na systemd nebylo tolik jak se z diskuzi muze zdat. Viz. bugzilla Archu.

[Kvakor]

Ad bod 2: dělá to i u volby noauto?

Jinak nechápu, proč dělat timeout u všech chyb při pokusu o mount(), když to má jediný smysl v případě (dočasné) neexistence příslušného zařízení/partition (dá se snadno zjistit z /proc/partitions), protože tam je možné, že se zařízení po nějaké době objeví, např. pokud je připojené přes postupně enumerované sběrnice jako USB, přes síť, nebo u disků, které řadič nahazuje/probouzí až při své inicializace a ne už při bootu.

V opačném případě je timeout zbytečnost, protože pokud se běžící a fungující zařízení nepovede namountovat napoprvé, tak to znamená nějakou chybu v souborovém systému a tam timeouty nepomůžou.

PS: Víla zubnička nepřináší, ta naopak odnáší

[Jezekus]

Tak odtud vitr vane, ten timeout v password-promt u LUKSu me zacal vytacet a nevedel jsem cim to a co to. Uz vim
Musim jak trotl sedet u PC a procumet cely POST, pak nacitani GRUBu2, GRUB2 a pak honem s heslem jinak budu cumet zas Thank you, thank you very much systemD...

[Michal Vyskočil]

Výchozí timeout byl změněn na 0. Pokud se nepletu, tak tohle by mělo fungovat od verze 202.

[hermelin]

Abych pravdu rek tak systemd mam na notebooku a vubec s nim nejsem kamarad. Ale nebudu popirat ze jsem lenivy se cokoliv z nej ucit - vsechno mi prijde takove tezkopadne, krkolomne. Uplne se mi v nem ztraci klasika linuxu/unixu "program dela jednu vec a dela ji co nejlip".

Nerikam ze systemd je spatny, ale me proste nevyhovuje a prakticky ho napr. na nasazeni na server vubec nepotrebuji/nechci. Tady zase plati stare pravidlo "pokud neco funguje a funguje dobre tak na to nesahej".

Jinak mockrat diky Michalovi Vyskocilovi za super serial o systemd http://www.abclinuxu.cz/serialy/systemd

[Petr Ježek]

Mám standardní desktopový Arch. Přešel k systemd, byla kolem toho dost debata (hlavně pověstný rychlý BSD-like init). Kupodivu, ten pověstný rychlý init se ukázal pomalejší než nový systemd, o čemž se ostatně již dříve hovořilo jako o metodě zrychlení startu systému. Konfigurace pomocí systemcfg je přehledná a plně funkční, nenarazil jsem na jediný problém (pominu-li uzanci NetworkManager místo vše v malém). Výsledek? Mám rychlejší start systému, přesnou analýzu časové struktury náběhu komponent s možností uživatelského přeřazení, spolehlivé zavedení všeho, co potřebuji a nezavedení ničeho, co nepotřebuji. Takže ač také preferuji tezi o neměnném funkčním systému, tady vidím pozitivní posun vpřed. Nevím, zda za to poděkovat více Lennartovi (za kvalitní matroš) nebo maintainerům Archu (za skvělou integraci)... Připomínám, že u Archu je zvykem před většími změnami vždy varovat současně s podrobnou wiki či rychlou komunitní zpětnou vazbou... Debianisté se podle mne nemají čeho obávat, ostatně Mint pracuje se systemd již dávno. Specifické instalace ale mohou znamenat specifické problémy...

[chrono]

Připomínám, že u Archu je zvykem před většími změnami vždy varovat současně s podrobnou wiki či rychlou komunitní zpětnou vazbou...

Na tej ich podrobnej wiki akosi chýba zoznam balíčkov, ktoré SystemD podporujú a ktoré nie (aby si používateľ mohol overiť, či služby, ktoré používa, sú už na SystemD pripravené).

[Radek Podgorny]

sluzby, ktere jsou v ofic. repozitarich by mely byt uz davno prevedeny, pokud to tak neni, je to bug a zaslouzi si byt zaznamenan. co se tyce auru, ano, tam to obcas pokulhava (za coz nemuze systemd jako takovy)... ...presto i tam si stezujte a buzerujte spravce.

[martin.k]

nejvetsi vyhoda archu je, ze i kdyz presel k systemd, jde pouzivat i jine inity - byt se systemd & spol snazi ostatnim initum hazet klacky pod nohy co se da (pro ilustraci treba pohadka o tom, jak otesanek sezral consolekit). takze muzu srovnavat - mam nainstalovany arch init, openrc, runit i systemd, vybirat si muzu z grubu a bootuje to - tramtadadaaaa - vsechno +- stejne rychle (sekundu sem nebo tam fakt neresim, stejne valnou cast boot time trva, nez se ta ma herka dohrabe do grubu). takze zustavam u staryho dobryho initu, protoze /etc/rc.conf je ultimatni, pro me jeden z nejvetsich benefitu arch linuxu, tudiz se ho vzdat nehodlam. runit mi prisel taky super, jednoduchy, rychly, elegantni, KISS. btw. fakt ze ma systemd (pid 1) rss >8MB me docela desi. ale mozna jsem jedinej, kdo si nemysli, z ve sw chyby nejsou, ze... nejkouzelnejsi je, ze init + supervizi demonu takovy runit zvladne s rss 4+4KB a logovaciho demona v nem mit muzete ale taky nemusite. a typicka service v runitu je shell skript o dvou radkach (prvni radka je shebang).

[Tomáš Bžatek]

ConsoleKit je opravdu uz mrtvej a zavsivenej, mel by se pouzivat logind. Ale diky tomu, ze se jedna o komunikaci pres d-bus, nemusi nutne bezet demon ze systemd, ale jina implementace.

[martin.k]

Problem je, ze duvod proc je CK mrtvej (a kvuli tomu i zavsivenej) se jmenuje systemd-logind. Jde systemd-logind pustit s jinym pid 1 nez systemd? Pochybuju... A tohle je vec, ktera me na systemd stve ze vseho nejvic. Ze na sebe nabaluje dalsi a dalsi funkcionalitu zpusobem, ktery primo rozbiji funcionalitu jeho "konkurentu." Jeste nedavno by me nenapadlo, ze se bude jednou na linuxu resit de-facto vendor lock-in.

[Tomáš Bžatek]

Proc by nesel? Je to d-bus activated service, takze PID ma ruzny. Pousti se jen kdyz je potreba a po chvili necinnosti se sam ukonci. Ono jde snad pustit vic procesu zaraz se stejnym PID?

CK je mrtvej, protoze ho uz dlouho nikdo nechtel udrzovat a mel sve nedostatky, takze by jej po case stejne nekdo prepsal a nahradil necim jinym. Seating a session management je navic docela optional vec, bez ktere se da zit, ale clovek pak nema ruzne vymozenosti (treba polkit na nem hodne zavisi).

[Tomáš Bžatek]

Hmm, ted si to mozna pletu s jinyma soucastma systemd, ale princip je vesmes stejny.

[Radek Podgorny]

...a muzu se zeptat, jak jste v runitu vyresil treba zavislosti? na device-activation se ani neptam. (neni to rejpani, runit se mi fakt libil, ale proste je simple az moc)

[Martin Matějek]

...a muzu se zeptat, jak jste v runitu vyresil treba zavislosti?

Občas mi závislosti přijdou přeceňované. Zrovna jsem na ně nadával u OpenRC, když mi na stroji s třemi síťovkami kvůli chybné konfiguraci jedné z nich nenaskočila síť (funkční dvě ze tří nestačily) a tím pádem ani sshd a další věci, abych to mohl opravit přes síť. Ještě, že ten server má IPMI, takže jsem to mohl opravit jinak.

Jak tohle řeší systemd/systemd services?

[Radek Podgorny]

...resi to pomoci .wants a .requires.

[Radek Podgorny]

mimochodem, tohle, pamatuji-li si to spravne, openrc taky ma. neco jako "need" a "want" nebo tak nejak... ale je pravde, ze co si pamatuji, tak s temi "sluzbami" typu sitovy interface to bylo vzdycky nejake podivne... ...na tohle je prave v systemd super ta device-activation.

[Bedňa]

Tak pridám posledný bug čo si pamätám, Systemd+Samba+CUPs systemd vyťažoval jedno jadro na 50%, pomohlo len vypnúť zdieľanie tlačiarne. Bola to chvíľková pomoc čo som riešil, neviem či problém ešte pretrváva a kde bola presne chyba.

[Martin Matějek]

mimochodem, tohle, pamatuji-li si to spravne, openrc taky ma. neco jako "need" a "want" nebo tak nejak... ale je pravde, ze co si pamatuji, tak s temi "sluzbami" typu sitovy interface to bylo vzdycky nejake podivne... ...na tohle je prave v systemd super ta device-activation.

O "need" a "want" vím, ale v tomhle případě jde o kompromis mezi detailními závislostmi a jednoduchostí používání. Problém je myslím v tom, že různé služby vázané na síť požadují běžící službu "net". A ta se úspěšně nespustí, dokud neběží všechny definované síťové karty, takže stačí, aby jedna z nich nenaskočila a systém si myslí, že síť neběží.

[Tomáš Bžatek]

Smutne... :(

(a to jsem se zase vcera rozcilil kvuli nedodelanosti jejich d-bus interface).

[Jakub Lucký]

Jediné, co mě uklidňuje, je fakt, že Debian bude muset kvůli kFreeBSD a HURD udržovat i nějaký další, kompatibilní, init, takže se mi snad podaří svobodně si vybrat něco horšího s méně geniálním maintainerem...

[R]

Nech to tam ako balik kludne daju. Pokial to nebude ako default.

[mankind_boost]

Anebo je dropnou

[Jakub Lucký]

To se mi moc nezdá. Kdyby ale k něčemu takovému došlo, tak si myslím, že bude v komunitě Debianu více problémů, než jen systemd...

[Foo Bar]

Politika je jasná, buď se porty chytají a stíhají nebo jsou přesunuty z officiálního archívu do portů. Nebyl by to první ani poslední přesun jedním nebo druhým směrem.

Co si budeme povídat tak Debian s jiným jádrem je sice hezká hračka (a občas to pomáhá odhalit portability chyby), ale reálná použitelnost a používanost těchto variant se limitně blíží k nule.

[Kvakor]

Debian dodnes udržuje pro x86 dva bootloadery (GRUB a LILO), tak by klidně mohl udržovat dva inity. Na druhou stranu, zajišťování kompatibility by nejspíš nebylo nic jednoduchého, leda že by každý balíček měl jak sadu skriptů pro klasický (paralelizovaný) init, tak konfiguraci pro systemd.

[ZiGi]

vo weezim pribudol treti bootloader - extlinux a da sa cakat, ze pribudne aj nieco pre UEFI...

neverim, ze sa najblizsich 5 rokov vobec pokusia zbavit sysvinitu.

[coques]

Pred rokom, po hodinách strávených prechodom na systemd som zhnusene prehlásil, že SystemD je grc na entú a doteraz ma nepresvedčil o opaku. Debian nedaj sa.

Pre mňa osobne je systemd jedna zo zásadných vecí, ktore v mojich očiach v poslednej dobe hlboko degradovali Linux v porovnaní s konkurenciou. Vlastne som kôli tomu prestal používať po niekoľkých rokoch Arch.

Na(ne)šťastie vždy môže byť horšie.

[Foo Bar]

Před rokem byla na chodníku napadaná hromada listí, a zhuseně jsem prohlásil, že chodník "je grc na entú", a od té doby zásadně chodím jen po silnici...

Máte i nějaké aktuální technické argumenty nebo je to jenom o tom, že ze systemd nemáte sluníčkový pocit?

[kavol]

a ta hromada listí je tam pořád?

[Foo Bar]

Já nevím, ale stejně tak to neví ani předchozí pisatel. Narozdíl od Vás, který jste jako jediný vznesl technický argument odkazem na konkrétní chybu v systemd a kde se můžeme bavit o tom, co se s tím dá dělat.

[adsfds]

Promin, ale to asi neumis cist (nebo si precti celej thread) - tech problemu a chyb u systemd je tady zminovano vyrazne vic nez 1.

[kavol]

nojo, ale já jedinej jsem dal link do bugzilly, vše ostatní je jen slovní popis, takže vpodstatě nekecá

[bugme]

Jo, mas pravdu, tak abych taky neco pridal - https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=systemd&list_id=1404093&product=Fedora&query_format=advanced

[kavol]

Já nevím, ale stejně tak to neví ani předchozí pisatel.

no, já jsem ho pochopil tak, že tam tu hromadu stále vidí - píše o přechodu na systemd, nic o přechodu zpátky

Narozdíl od Vás, který jste jako jediný vznesl technický argument odkazem na konkrétní chybu v systemd a kde se můžeme bavit o tom, co se s tím dá dělat.

hm, v první řadě asi profackovat obě skupiny dohadujících se vývojářů, aby si to nepřehazovali mezi sebou

[coques]

Riešil som niekoľko technických vecí, už to tu nebudem rozoberať. Môj problém so systemd je po vcelku dobrom zoznámení sa skôr principiálny, asi ako pre väčšinu. Mne systemd primpomína cudzopasníka, ktorý nemá so základnými Linuxovými princípmi nič spoločné. Nakoniec, aj sa s tým tak pracuje...

U nás v práci funguje v podstate každý druhý na Linuxovom desktope. V rámci slušnosti ani nebudem opakovať čo za nadávky tam každú chvíľu lietali. Ano, taká je realita. Ako zástancovi systemd viem, že sa ti páčiť nebude, ale pre väčšinu známych bolo začlenenie systemd do systému ako veľmi zlý vtip.

Ale už je to aj tak jedno, systemd sa votrel všade ako mor, takže nám nezostane nič iné, len sa s ním spokojiť.

A posledná vec, ktorej sa veľmi obávam. NEVIEM si predstaviť, že sa systemd začne intergrovať do RHEL a na produkčné mašiny. Na druhú stranu, aspon budeme mať ako admini na dlhú dobu o prácu postarané.

[Bedňa]

ktorý nemá so základnými Linuxovými princípmi nič spoločné.

Toto je vec, ktorá mi na ňom najviac vadí, inak by človek prekúsol aj nejaký ten bug. Je to systém v sytéme čo hovorí že to spraví lepšie ako ja. Rovnako to tvrdia user friendly distrá, ďakujem, zatiaľ viem čo robím a čo chcem.

[Chytrex]

+1!!

[Bedňa]

Keď som začal s Linuxom ma uchvátila Unixová filozofia, jeden program robí jednu vec a robí ju dobre. Je škoda že namiesto jedného skriptu v Bashi, Pythone ... ktorá by napríklad zjednotila logovanie a správu démonov tu vznikol moloch čo chce robiť všetko za všetkých. Manažéri hovoria všetko pôjde samo všade rovnako dobre, ja hovorím rovnako dobre zle :)

Ak si niekto myslí, že existuje univerzálnosť, nech sa zamestná v MS.

[biolog]

Však to taky systém ví lépe, než vy. Protože ten systém dělají lidé, kteří se danému problému věnují na full-time, Canonical zaměstnává cca 4 kernelové vývojáře, Red Had odhaduji nějakou desítku. Filesystémy dělají specializovaní lidé, síťování taky, audio taky, video, telefonii, C runtime a toolchain, grafiku.

Teda pokud člověk používá systém, kde autoři své vědomosti vdechnuli do softwaru a kde jsou defaultní hodnoty praktické, tj. nějaké user-friendly distra, a ne distra kde si věci musí zařizovat uživatelé sami.

Kdo z místních zná všechny/většinu výhod a nevýhod různých mount-opšnů pro třeba btrfs? Nikdo.

[Bedňa]

Súhlasím v Ubuntu tu bude prínos, ale prečo v Debiane? Používame tento systém, pretože tam si treba všetko nastaviť podľa svojich potrieb a uznávame Unixovú filozofiu jednoduchosti texťákov a jeden program robí jednu vec a robí ju dobre. Bez nejakej nenávisti, sám som nad tým rozmýšľal ako je možné robiť veci univerzálne a po pár rokoch som zistil že to nieje možné. Nechcem aby systém robil to čo uzná za vhodné, vždy musí robiť to ča ja chcem a iný to zas chce inak, rozumieme sa?

[biolog]

Debian je právě ten případ, kdy si člověk musí vše konfigurovat sám a kdy defaultní hodnoty jsou tak nepraktické (a kolikrát i nesmyslné), že to ajťák nastaví sám lépe.

Ale máte běžné potřeby. Skládáte programy, které umí polovinu toho, co se po nich obvykle chce, takže je těžké říct zda tu polovinu dělají dobře. Taky jsem rozmýšlel o tom, jak dělat věci univerzálně a po ~4 letech dospěl k tomu, že to nejde zcela. Ale jde vytvořit nástroj, který vyhovuje 90% uživatelů. A jde vytvořit nástroj který pokryje zbylých 9% uživatelů, přičemž se nejspíše využije většina vnitřností či podnástrojů v tom většinovém nástroji. A zbylé 1% se vyřeší podobně - nebo ti uživatelé budou muset pročíst dokumentaci, ale až tahle minorita.

Zajímalo by mne jaké máte potřeby, že se liší od ostatních lidí. Máte jiné názvy serverů, no jo no. A přebili jste nepraktické defaultné hodnoty. Chtěl bych vidět někoho, kdo originálním způsobem provozuje DNS server. (Takoví jsou, i tak mne zajímá je vidět. Extrémní příklad: mám defaultní wallpaper, přestože ho změnit umím. A to se běžní uživatelé spíše zajímají o wallpaper než o parametry audio subsystému.)

[Bedňa]

Môj odhad je že užívatelia ktorí chcú svoj komp ovládať sa pohybuje až do 5%, pokiaľ ale zoberieme sféru IT tak to bude až 50%, to by korešpondovalo s obľúbenosťou Debianu a ďalších hlavne "server side" systémov. Napríklad proti Ubuntu nič nemám, ale snaží sa riešiť veci čo požaduje väčšina užívateľov. Mňa proste uchvátila jednoduchosť texťákov, spravidla s vyčerpávajúcim popisom, manuálom k príkazom a keď mi niekto povie že je jednoduchšie niečo si naklikať, alebo že to za mňa lepšie spraví démon, ja hovorím, neberte nám Debian!

[Chytrex]

Přesně, vystihl jsi proč mám rád debian.. Protože dělá to co mu řeknu a ne to co si myslí že má dělat. Linux má na slovo poslouchat konfiguráky, tečka. A ne nějaké bastly co dělají všecko za všechny..

[Bedňa]

Nedá sa nič len súhlasiť.

[kavol]

Však to taky systém ví lépe, než vy. Protože ten systém dělají lidé, kteří se danému problému věnují na full-time, ...

hm, ani jsem si nevšiml, že bych měl za prdelí tým lidí, co se věnuje full-time mému hardware a mým potřebám a problémům, takže si tu nevymýšlej nesmysly

[biolog]

(Tohle následující si neber osobně. Neznám tě, ale moje námitka sedí to na skoro všechny lidi na abclinuxu.)

A jak se tvoje potřeby a hardware liší od ostatních lidí? Máš nějakou kartu, chip na desce, nebo periferii která je unikátní, třeba tím že se ho vyrobilo méně než pár tisíc kusů? (Vzít v úvahu, že karty UltraCool XR a UltraCool XBR bývají skoro stejné.) I kdyby ano, tak všechen ostatní HW máš běžný.

Jaké originální potřeby máš? Dovedeš (a běžně používáš) webový prohlížeč jinak než 99% lidí? Nebo ukládání/přistupování k souborům? Přehrávání multimédií? Tipuji že místní lidé nanejvýš přebíjí defaultní hodnoty a chování programů proto, že jsou nepraktické i v běžných situacích.

Já například programuji a vytvářím programy, které jsou v některých ohledech originální. Ale používám zcela běžné programátorské nástroje a to obvyklým způsobem, jak to dělají ostatní. Jako malý jsem změnil např parametry bootování, disku atd protože byly pomalé nebo nesmyslné - podle návodu. Možná někdo zrychlí třeba KDE, ale použije k tomu profiler stejným způsobem jako ostatní.

Ano, jsou lidé kteří mají hardware na míru, nebo celou sestavu, třeba protože PC pro řízení nějakého průmyslového procesu. Jsou lidé, kteří používají počítač originálním způsobem - v jednom či dvou aspektech. Jinak lidé nejsou nějaké unikátní sněhové vločky.

[kavol]

sorry, ale to je totálně mimo

já jsem neřekl ani slůvko o tom, že můj hardware je unikátní (tedy ... zrovna jednu übercool kartu, která není dostatečně "skoro stejná" jako karta uebercool, vlastním), ani že bych měl kdovíjak unikátní potřeby - pouze nesouhlasím s představou, že zrovna to, co a jak používám já (a nevímkolik dalších), někoho zajímá a je v tom vzdělán natolik, aby to nejen věděl lépe než já, ale ještě dokázal naprgat příslušný systém, který ty jeho zázračné znalosti uvede do praxe na mém stroji

[Jirka]

Když bude nejhůř, budem wheezyho, jen s novějším jádrem, instalovat klidně ještě dalších 10let.

[psc]

- cca 46% z hlasujicich byli maintaineri
- manipulativni otazka "spustili jste a pouzili pocitac se systemd ?" misto "pouzivate soustavne systemd a vyhovuje vam lepe nez stavajici initd/whatever ?"
- manipulativni otazka "jaky je vas celkovy postoj k pouzivani systemd v Debianu (ne nutne vychozi) ?" misto "prejete si kompletni prechod Debianu na systemd (neznamena nutne ukonceni podpory osvedceneho sysvinitu) ?"

Jen mi to pripomnelo jeden z dilu "Jiste, pane premiere" a jak delat ankety, aby vysel vysledek ktery si zadavatel preje. Bohuzel ale nejsem tak jazykove obratny :)"

Se systemd jsem se seznamoval na Archu a pokud nenarazite na problem nebo nepotrebujete resit neco nestandardniho, tak si rozdilu ani nevsimnete. Zduraznuji pokud nenarazite. Krome nutnosti nastudovat relativne rozsahlou dokumentaci, ktera je specificka vcetne konfigurace jen a pouze pro systemd, tzn. jinde je vam k h*vnu, stejne narazite spis driv nez pozdeji na blob - modul systemd - a bud cekat az to opravi v upstreamu nebo distribuci nebo se vrhnout na ceckove zdrojaky, coz je pro bezneho admina nesrovnatelne narocnejsi nez uprava shell-skriptu.

To ze se snazi integrovat vsechno mozne, vcetne treba planovace uloh, obsluhy acpi udalosti, systemovych logu nebo i sitoveho superdemona xinetd jde proti principu jednoduchosti, dekompozice a genericnosti, na kterych prezil *nixovy koncept pres ctyri dekady az do dneska. Nemoznost prohlidnout si logy v obycejnem textaku, kdyz se snazim obnovit nefunkcni system ? WTF ?

Vsechno jsou to ale drobnosti proti argumentu, ze nebyly a nejsou dostatecne silne duvody, ktere by ospravedlnily tak drasticke zmeny v jedne z nejzakladnejsich casti systemu.

[Jiří J.]

Funkčnost systemd se ohýbá i důsledkem protiargumentů (narozdíl od např. Gnome 3), takže některé odpovědi v postu na d-d ML jsou nepravdivé - např. možnost spouštět sysv init skripty vedle systemd je AFAIK na dost dobré úrovni. Nebo taky ukládání logů v textovém formátu a (opět AFAIK) jejich duplikace do binárního pro lepší parsování automaty. Systemd jde ale filosofií oproti oběma případům - ve druhém jsou to šifrované (tedy, FSS) logy.

Obecně vzato ale souhlasím - systemd sám o sobě základním nápadem "pojďme něco vylepšit" není špatný, i jeho specifičtější cíle by má programátorská/designerská polovina viděla světle (což je IMHO důvod, proč je tolik lidí za systemd), ale záhy nastupuje sysadminská polovina stojící u konzole v serverovně, snažící si vzpomenout na něco z rozsáhlé systemd dokumentace, protože se v ní nepotřebovala v posledním roce hrabat. Tedy, pokud ji vůbec systemd ke slovu (a shellu) pustí - ze zkušeností se současným systemd tomu tak není. A úplně nejlepší je, když ani oficiální postupy na debugování startu/shutdownu nefungují a nepřidávají žádné užitečné informace o tom, proč každý cca čtvrtý shutdown zamrzne na 6 minut (real story!).

Ale blýská se na horší časy. Hlas sysadminů totiž není důležitý, protože s dalším releasem bude systemd i v RHELu, už teď je v SuSE, hodně distribucí začíná podléhat argumentu "ale většina distribucí používá systemd", takže zřejmě stačí protlačit systemd do Debianu, odkud ho nejspíš přebere Ubuntu a "totalita" je prakticky nastolena. Sysadmini se budou muset adaptovat.

PS: Ano vím o pěkných featurách právě pro sysadminy, jako je agregace a vyhledávání v binárním logu, ale dle mého skromného názoru tyto featury nestojí za překopání základů Linuxového userspace, a v podstatě ani za systemd v roli init systému.

[Chytrex]

tesat do kamene..

[psc]

Celkem souhlas. Byl bych ale opatrny co se tyce udrzovani podpory alternativich soucasti jako sysv initscriptu nebo puvodnich systemovych daemonu i do budoucna, prestoze to v soucasnosti nabizi. Pokud tady budou prakticky vsechny majoritni distribuce nad systemd postavene, vyvojari se budou na nej zamerovat, tak postupem casu zmizi duvody udrzovat kod ktery bude vyuzivat zanedbatelne mnozstvi ortodoxnich.

Osobne se me to snad nedotkne, protoze k zajistovani obzivy vyuzivame prevazne FreeBSD, kteremu se tohle silenstvi snad vyhne. Pocitam ze to bude mit dopad na userspace, kterej financuje Redhat nebo se i primo podili na jeho vyvoji, ale krome Xorgu je mi to u zadnice.

[psc]

to mela byt reakce na http://www.abclinuxu.cz/zpravicky/hlasovani-o-systemd-v-debianu/diskuse#114

[the.max]

Me k pouzivani systemd 'donutil' Arch, celkem na 6ti pocitacich. Kdyz jsem prechazel (omylem) na prvnim, 2 dny mi trvalo dostat system do pouzitelneho stavu a dalsich 5 dni do stavu pred aktualizaci. Po nejake dobe sem si rekl, ze zaktualizuju dalsi stroj. Opet porod. Celkove mi to trvalo 'uz jen' ctyri dny. Dalsi system prosel 'relativne' v pohode, sral jsem se s tim jen cele odpoledne, vecer a noc. Dalsi stroj jsem radeji preinstaloval na Debian (a jak vidim, tak jsem si moc nepomohl). Predposledni (notebook HP) se dostal do takoveho stavu ze zacne nabihat, pak se sekne a konec. Ani po hodine nevypise zadnou hlasku. Zkousel nekdo opravovat system se systemd v chrootu??? A na poslednim je arch neaktualizovany uz asi rok a nevim co s nim.

Takze asi tak.

[Sešívaný]

Můžu se zeptat, co na těch počítačích děláte? U serveru s hromadou custom služeb bych ty potíže s přechodem ještě chápal, ale u desktopu? Upgradoval jsem z init na systemd při přechodu z Fedory 14 na Fedoru 15 (a potom i dále) na čtyřech počítačích s dost různorodou hardwarovou sestavou a se systemd jsem nikdy problém neměl. Natož abych nad tím trávil dny a noci.

[Pavel Píša]

Pokud přestane chodit Debian policy-rc.d a nebo nějaký ekvivalent a budou se spravované/instalované služby a programy v chrootu montovat do globální D-bus session tak mi/nám bude opravdu hodně smutno a roky práce a zkušeností a následné pohody budou ty tam.

Stejně tak pokud nepůjde systém nastartovat do shellu prostým init=/bin/sh a pak postupně pouštět jednotlivé služby/řádky ze skriptů.

Stejně tak by to byl konec embedded systémů, kdy člověk piplá jádro, u-boot a další komponenty a když dojde do shellu tak je v podstatě v pohodě. Stačí BusyBox a GLIBC a lze oživit vše, ideálně přes NFS root. Přitom často není RAM a CPU výkonu nazbyt a jedno mdev -s po instalaci a zavedení přesně specifikovaného (otestovaného - jsme v nemocnici) seznamu modulů je zcela dostatečné. V okamžiku kdy začnou různé základní komponenty padat protože nenajdou jiné komponenty přes systemd a systémový D-bus, tak se portování o řád prodraží. I teď přechod ARM na DTS pro naší firmu znamená platit člověkodny pro přechod na novější jádro. Přitom s myšlenkou DTS a přístupem kernel core vývojářů souhlasím (mám k nim důvěru), na rozdíl od systemd, mnohem více.

Takže uznávám důvody proč se snažit o lépe integrované řešení se strojovým rozhraním, atd.

(Nakonec robusní Real-Time logovací systém s frontou binárních záznamů a podrobným nastavením levelů jednotlivým doménám jsem implementoval pro medicínské přístroje s OS RTEMS a běhá solidně i v buildu aplikací pro Linux. Ale stejně na SD kartu z toho data zapisuji v čistém textu. Je důležité, aby "černou skříňku" šlo i po letech přečíst běžnými nástroji a i mimo vlastní zařízení. Na druhou stranu je pravdou, že pro nějaké rychlé prohledávání na přístroji podle logovací domény a čísla chyby by se mohla binární databáze hodit. Ale kdo z ní dostane data, pokud se nějaký sektor ztratí. Takto pro každé datum zakládáme zvlášť adresář a pro každé spuštění zvlášť log a to je již k rozsáhlejší korupci celkem odolné a i když nějaký sektor vypadne tak grep přímo na úrovni média nebo zbytků po FSCK něco najde. Ostatní data jsou pak ukládaná dvakrát (sekvenčně a se sync) na filesystemu nebo v interní FLASH a chráněná SHA).

Uznávám, že jsem zatím systemd netestoval, ale dokumentaci jsem přečet několikrát a jak udělat pro nás mnoho nezbytných věcí jsem z toho nepochopil nebo někde našel že to nejde (není potřeba). A ano, na druhou stranu uznávám že naše řešení, kdy mám pro kritické služby na Linuxu vlastní binární wrapper v C není ideální. Ale nepřetržitě a bezchybě to měsíce chodí na různých verzích jak na OpenWRT tak na Ubuntu a obchází to různé lahůdky jako skoky v Real Time (kde to lze používáme monotonic) atd. Může ssytemd chodit na zařízení s 8MB FLASH, na zařízení které startuje v roce 1971 (bez RTC) atd.? Nedojde jeho adopcí k tomu, že i ostatní věci, co teď chodí, chodit přestanou atd.?

[dumblob]

+1

[Radek Hladik]

To, že nejsem žádný příznivec systemd, to už jsem psal několikrát. Každopádně musím přiznat, že po 2-3 verzích Fedory začíná být systemd použitelný a dokonce mě i jednou mile překvapil.

TLDR: Delší povídání o pár nepřijemnostech a jedné/dvou dobrých věcech současných linuxových základně-systémových novot...

Používám občas docela divoké konfigurace (boot z flashky+iSCSI, lokální SSD+iSCSI, virtualizace...) a musím říct, že od dob Fedory 12-13 se mění hodně různých základních systémových komponent a mám z toho dost smíšené pocity...

Grub: Grub1 byl naprosto geniální nástroj. Dříve dokonce uměl přímo z bootloaderu nainstalovat MBR část. Grub2 je moloch, ale budiž, můžu si konfigurák udržovat sám (jen je asi 3x delší než u Grub1 ) Instalace už ale není tak jednoduchá (nakopírovat soubory někam a pustit příkaz setup). Co mi ale hrozně vadí je, že mi občas při editování položky při bootu začne psát nemysly a celé editování je tak naprosto nepoužitelné. Nejdřív jsem si myslel, že je to problém jednoho stroje, ale pak mi to začal dělat i na virtuálu...

Dracut: Dracut mi přišla jako perfektní myšlenka. Sice jsem si do té doby vystačil s editováním jednoho skriptu na ramdisku, ale faktem je, že dracut to značně zjednodušil. Pak jsem si ovšem všiml malého problémku, a při debugování jsem zjistil, že dracut je od základu špatně navržený. Jen pro představu: běží jakýsi cyklus, který má výstupní podmínky (třeba přítomnost disku s /) a různé moduly, které postupně spouští a které by měly právě zařizovat to, aby se časem ty podmínky splnily. Bohužel takto snadno to fungovat nemůže, protože logika podmínek by byla potřeba složitější. Například RAID1, k rozjetí stačí jeden disk, ale lepší jsou dva. Jak to podmínka u dracutu řeší? Jakmile je device s UUID raidu přítomný, tak se cyklus ukončí a pokračuje se v bootu (podmínka je jeden bashový test na přítomnost device). Jenže device se objeví už při přidání prvního raid memberu... Určitě někdo namítne, že raid1+dracut používá a vše funguje. Ano, ale pouze proto, že oba disky se najdou v rámci jednoho kroku (udev block-device scan nebo jak se to jmenuje), protože jsou (většinou) připojené stejně. Zkuste ale mít SATA disk + iSCSI a zjistíte, že raid jede jen z lokálního SATA disku a iSCSI ani nezkusí nahodit (proč přece, raid už má ). To že to může vést k zásadní ztrátě dat se dá snadno ukázat. Ostatně bugzilla. O tom, že to asi není úplně jednoduchá oprava svědčí i patřičná (ne)aktivita u toho bugu. Na druhou stranu se pracuje na začlenění systemd do dracutu... Ikdyž to je vcelku rozumná myšlenka, mám strach, jak Lennart vyřeší slepicovejčí bootovací problém.

Systemd: U F17 už je vcelku použitelný, pokud člověk chce základní věci. Co mi ale vadí je, že když mu dám, aby spustil službu, tak nenapíše OK nebo Failed, takže každý start musí následovat status, abych viděl, jestli se služba opravdu rozběhla. Navíc ty nejzajímavější věci bývají vytrojtečkované . Co se mi naopak moc líbí jsou instance služeb. Přesně to jsem potřeboval a systemd si tím u mně šplhl. Sice bych uvítal ještě nějaký lepší management (typicky práci se všema instancema najednou), ale i tak je to o řád lepší než dosavadní init. Kromě toho, co už tu psali lidi přede mnou mi chybí jednoduchá curses utilita, kde si zaškrtám služby, které chci/nechci...

U systemd mi vadí i to, že když chci nějaký single režim, tak si musím pamatovat něco jako systemd.target=single-user-emergency, to je opravdu pokrok oproti slovu single . Co je ale horší, tak nevím proč, ale typicky se mi stává, že když si v grubu zedituju init=/bin/bash (protože si nejsem schopný zapamatovat ten systemd single ekvivalent), tak se mi na konzoli nezobrazuje, co píšu. Stty sane nepomáhá. Ale stává se mi to jen někdy, tak jsem po tom zatím víc nepátral.. Ale díky tomu umím už nastavit síťovku a pustit sshd poslepu

[mrv]

http://www.lehman.cuny.edu/cgi-bin/man-cgi?alias+1

[Radek Hladik]

Přiznávám se, že mi nedochází vztah mezi našimi příspěvky, možná i v důsledku strohosti toho vašeho...