Spotify preferuje systemd jako defaultní init systém v Debian Jessie

Noa Resare, zástupce Spotify, provozující Debian na tisících serverech, prezentoval v rámci pokračující diskuze o defaultním init systému stanovisko firmy. Spotify by preferovala užití systemd v Debian Jessie, a jako důvody uvádí: (a) systemd je snadnější pochopit, vysvětlit a použít, (b) nabízí více funkcí, například pro správu zdrojů, (c) bude mít větší podporu komunity a upstreamu.

26.1.2014 21:58 | little.owl | Komunita

Komentáře

[SPM]

To jsou zase argumenty jak stehno... ještě mohli připsat, že ten projekt má hezčí webové stránky.

[David Heidelberg]

jenomže tyhle věci jsou zatraceně důležité (a tím myslím i ty webové stránky). Software není jen kód, je to i komunita, přístup vývojářů, prezentace a dokumentace. I ten web může hrát důležitou roli.

[pavlix]

Ty jsi zase přišel jenom provokovat, co ;).

[potato]

Nebudu posuzovat stránky, ale ano, reálně se projekty prosazují na základě toho, jak se snaží, aby je lidi používali. Takže (a) a (c) jsou relevantnější než ‚technické‘ diskuse mezi blouznícimi vizionáři a rozvášněnými luddity...

[lertimir]

Mimo jiné to jak se programy/protokoly používají patří mezi čtyři základní principy internetu (Rough Consensus and Running Code). Poprvé jsem principy četl v knižce Huitemy Routing in Internet koncem 90 viz např Russell.

[Foo Bar]

A Google zase preferuje klasický sysvinit (dokonce bez paralelniho startu)...

Mozna bych to nechal ulezet do doby, nez ctte vyda nejake rozhodnuti.

[David Heidelberg]

nic o tom nevím, ale hádám, že těm je to spíš jedno, protože už asi používají nad tím nějaké svoje řešení

[pavlix]

Spíš nepovažují paralelní start za hodnotu.

[David Heidelberg]

tomu klidně věřím, on pomalejší náběh nějakého toho vyměněného kompu z těch tisíců s nima asi nepohne :D

I když přijde mi, že Spotify s 5000 stroji na tom může být asi obdobně, ale asi rádi dělají update jader a potřebují mít ty stroje rychle zpátky.

Zajímalo by mě, porovnání přístupu těch dvou firem. Hádám, že kdyby byl systemd default, by (zřejmě? *) lidi od Googlu taky byli pro.

* (pokud nemají nějaké svoje historicky opatchované jádro na kterém systemd nepojede)

[pavlix]

I když přijde mi, že Spotify s 5000 stroji na tom může být asi obdobně, ale asi rádi dělají update jader a potřebují mít ty stroje rychle zpátky.

Ono dost záleží, jak jsou ty stroje organizované.

[SPM]

Já si nejsem jistej tím, jestli rychlost bootu samotného OS u serveru je vůbec něco zajímavého. Přináší paralelní spouštění vůbec zrychlení (tj. jestli je to jen efekt, že vidím dříve login prompt nebo jestli všechny služby naběhnou doopravdy rychleji)? Navíc když si vemu do ruky nějaké serverové železo, tak uplynou minuty jenom než proběhne veškerá inicializace hardwaru a všeho možného. Mám tu servery, kde reboot trvá asi 15 minut. Jestli samotný systém potom naběhne za 10s nebo 15s je úplně jedno...

[David Jaša]

Navíc když si vemu do ruky nějaké serverové železo, tak uplynou minuty jenom než proběhne veškerá inicializace hardwaru a všeho možného.

Ano, reboot hypervizoru trvá dlouho. Ale nevidím důvod, proč by měl trvat dlouho reboot serveru, který dělá i nějakou užitečnou činnost.

[Sešívaný]

Na Flocku říkal Greg Koenigsberg z Rackspace, že průměrná životnost virtuální mašiny v jejich IAAS je < 1 minutu. Tam rychlost startu systému bude hrát sakra roli. A cloud bude čím dál častější serverovou architekturou.

[Jakub Lucký]

IAAS je < 1 minutu

To číslo je nějaké divné... Buď to znamená, že jim spousta VM vůbec nenastartuje, nebo, že jim kolabují už při startu. Nebo se spouští na jeden request.

A všechny tři parametry mi přidou jako něco mezi nesmyslem a nepochopitelným use-case

[dustin]

Taky mi to přijde divné, k čemu by ty stroje sloužily?

[kavol]

+1, další nechápavec se hlásí - proč je výhodnější virtuálky startovat od nuly než jen uspávat a probouzet?

[David Jaša]

Virtualizace != cloud. Co jsem pochopil*, tak cloudové programy musí být navržené tak, aby škálovaly přidáváním dalších instancí (VMek) a aby si poradily s výpadkem kterékoliv instance (VMky) - takže tyhle jepičí virtuálky jsou buď na pokrytí krátkodobých špiček, nebo na testy. Tipuju, že většinu VM-hodin odkroutí VMky, co pojedou podstatně déle.

* stránky 25-33, případně až 36 :)

[little.owl]

Ta analogie Pets vs Cattle se mi libi, nicmene prumerna zivotnost VM < 1 min mi prijde na hlavu. Lze ilustrovat smysluplnost takoveho reseni na nejakem selsky pochopitelnem priklade?

[David Jaša]

Ta analogie Pets vs Cattle se mi libi, nicmene prumerna zivotnost VM < 1 min mi prijde na hlavu.

Mě taky. Proto tipuju to, že zrovna průměr přes počet VMek není vypovídající.

[Foo Bar]

Medián by byl asi o dost zajímavější, ale ten tam asi nikde není, co?

[Bedňa]

že průměrná životnost virtuální mašiny v jejich IAAS je < 1 minutu

A nielen túto funkcionalitu prináša systemd.

[little.owl]

A Google zase preferuje klasický sysvinit (dokonce bez paralelniho startu)...

To je pravda - jsou dost velka firma na to aby postavili vlastni specificke reseni, vcetne rekompilace systemu z reviewovanych balicku, vedle vyvoje vlastni HW a treba FW pro disky na zakazku. Google, Amazon ci i Facebook jsou jina liga, kterym to co udela Debian je v podstate jedno.

Mozna bych to nechal ulezet do doby, nez ctte vyda nejake rozhodnuti.

Tohle je soucasti hledani reseni a lze ocekavat, ze velci uzivatele Debianu se zacnou vyjadrovat a chranit sve zajmy a nejsem si jist jestli by bylo moudre je ignorovat.

Spotify, velky uzivatel Debianu, vyjadrila svuj nazor a nevidim duvod to tu neprezentovat.

[Foo Bar]

Narážel jsem na tohle:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3155

resp. tady je k tomu paper:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3170

When you have so many machines, you want to keepthe init system simple and dependable. Whenever possible we want all our machines to behave the same. As a result, we stuck with normal init, and looked at Debian's insserv and startpar for simple dependency boot ing that we can set in stone and review at image creation time. Both upstart and systemd require way too many moving pieces and introduce boot complexity and unpredictability that was not worth the extra boot time they could save.

[little.owl]

Ten talk jsem videl/slysel, stejne jako vetsinu z linux.conf.au 2014. Jiste, v urcitych situacich muze byt jednoduchy init lepsi reseni, mne by vyhovoval systemd a nejaky jednoduchy bsd init. Jinak s tim determinismem bych byl opatrnejsi, jedna vec je spustit proces v nejakem poradi, druha vec je, kdy je proces fakticky ready a pokud na tom zavisite to bez nejakeho protokolu nelze uplne trivialne resit.

[Foo Bar]

Já s Vámi naprosto souhlasím. Jen mi přijde, že omílat a omílat další informace z toho bugu už nic dalšího nepřináší.

Snad možná výsledek tohodle hlasování: https://lists.debian.org/debian-ctte/2014/01/msg00425.html

Ballot:

  The default init system for Linux architectures in jessie should be

  1.  systemd
  2.  upstart
  3.  openrc
  4.  sysvinit (no change)
  5.  requires further discussion.

Bdale: 12345
Russ:  12534
Ian:   54231
Keith: 12435

Don, ABA, Steve a Colin ještě nehlasovali a Ian je pěkně nasraný :).

[little.owl]

Nedivim se mu, tohle nikam nevede. Hezke je, ze se uvazuje jen o initu pro Linux, to mi prijde nove.

[Foo Bar]

Pokud jsem Bdaleho pochopil dobře, tak to chce dělat salámovou metodou a chce, aby už se to začalo někam hýbat dopředu.

[little.owl]

Nevim, to je politika, ale vypada to tak. Tim, ze se hleda reseni jen pro Linux, pada pozadavek portovatelnosti na jina jadra a nejvetsi slabina systemd. Technicky priklon k Upstartu uz nelze zduvodnit, zejmena kdyz sam jeho tvurce ukazuje, ze je fundamentalne rozbity a dalsi lide vyhledali, ze Canonical ma v bugzille zasadni bugy snad v kazde casti systemu, ktere uz nekolik let neresi. Takze je na proponentech Upstartu s cim prijdou, zatim mi prijde ze hrajou mrtveho brouka a Bdale se to pokousi proste rozhybat. Kazdopadne je to dosti zoufaly krok a Ian pekne vypenil. Stale stejny stejny Debian, jak jsem ho znal pred 12+ lety .

[Kvakor]

U Googlu bych se tomu nedivil, protože pokud máte milion serverů, mezi které je automaticky rozkládaná zátěž, tak je doba startu jednoho z nich relativně nepodstatná, naopak spíš záleží na jednoduchopsti, robustnosti a spolehlivosti (proto nejspíš nepoužívají ani paralelní start).

[pavel]

Zatímco "obyčejní"linuxoví uživatelé jednoduchost, robustnost a spolehlivost nechtějí...

[lkajlkj]

+1000 a proto pouzivaji systemd

[Michal Vyskočil]

A Google zase preferuje klasický sysvinit (dokonce bez paralelniho startu)...

A vlastně prakticky všechno je The Google Way ™. Není to zase tolik let, co nemohli přejít na kernel 2.6 kvůlivá hromadě patchů nad 2.4, že? Takže nic proti Google, ale argument Google to dělá tak a tak, je argument dobrý akorát tak pro Google.

BTW: systemd v Google Cloudu nakonec stejně nějak poběží

[kavol]

Takže nic proti Spotify, ale argument Spotify to dělá tak a tak, je argument dobrý akorát tak pro Spotify.

[Michal Vyskočil]

No, kdyby nepoužívali Debian, tak možná ...

[trekker.dk]

Takže přestože Google i Spotify používají Debian, tak názor Googlu je dobrý akorát pro Google, kdežto názor Spotify je relevantní pro všechny ostatní...

[David Jaša]

Ano, za předpokladu, že v Debianu bude sysvinit i nadále dostupný. Jestli dobře čtu (poměrně kusá) vyjádření obou firem k init systému, tak spotify by rádo využívalo systemd podporované v rámci Debianu, zatímco gůgl si vezme sysvinit a ohne ho pro potřeby svého ProdNG.

[lertimir]

Navíc nemám dojem z příspěvku Ondřeje Surého, že by se Google k tomuto rozhodování vyjádřil. Pouze používá, co je, a díky tomu, jak je obrovský, tak je velmi konzervativní, viz poznámka o zpoždění přechodu na jádro 2.6. A to, že se firemní uživatelé Debianu vyjadřují, co by preferovali je jen dobře, protože vývojářská komunita, dostává zpětnou vazbu, co uživatelé by chtěli. Samozřejmě teď by bylo záhodno, aby se i další velcí uživatelé vyjádřili, aby zpětná vazba nebyla na jedné firmě.

[little.owl]

Par velkych firem jako Google jsou jina liga, schopne nasadit stovky lidi a napsat si vlastni reseni; vzdyt oni vyviji vlastni HW a vedle toho dva OS. Spotify je reprezentativnejsi vzorek stredne velke firmy nasazujici Debian ve velkem.

[Sešívaný]

Asi tak nějak. Spotify je IMHO mnohem typičtějším uživatelem Debianu než Google. Ten je uživatelem Debianu asi jako byl doteď uživatelem Red Hatu. Když jsem viděl tu jejich prezentaci, tak jsem zíral bulvy. Někdy v dřevních dobách, začátcích Googlu, nasadili Red Hat Linux a už u něj zůstali. Nevím, která verze to byla, ale RHL už tu s námi není víc než 10 let a oni si to celou tu dobu udržovali sami až do podoby, kdy to s původním RHL už nemělo skoro nic společného. Takovým stylem je téměř jedno, jaké distro si vyberou, a příliš je nebude trápit, jestli tam je initV nebo systemd.

[little.owl]

Spotify je IMHO mnohem typičtějším uživatelem Debianu než Google.

Takovych firem budou stovky ci tisice, ale Google je jen jeden.

Nevím, která verze to byla,

Tusim RHL 6.2-7.1, odhadem 2000-2001. Z toho skutecne nemohl zustat kamen na kameni.

[Aleš Kapica]

Velké firmy nemají zájem na vývoji nových věcí, ale na údržbě starých. Proto je zcela zásadní omyl se v tomto směru orientovat na velké firmy.

[vencas]

Zajímavější by bylo, kdyby se k tomu vyjádřili i další masoví uživatelé Debianu. Takhle je to plácnutí do vody, co zrovna jedna firma. Podpora upstreamu: ve všech diskusích na ML debianu zaznělo, že přístup upstreamu systemd (víme kdo) k jakýmkoliv návrhům je hrozný.

[Michal Vyskočil]

Podpora upstreamu: ve všech diskusích na ML debianu zaznělo, že přístup upstreamu systemd (víme kdo) k jakýmkoliv návrhům je hrozný.

Zatímco druhá strana je dle Iana přátelská, leč drobet nekompetentní ...

[kavol]

a) opět oblíbené falešné dilema - těch alternativních init systémů existuje jaksi poněkud více, než na kterých Lennart ukazuje, jak je zrovna ten jeho v porovnání skvělý

b) stejně tak lze sepsat seznam fuckupů v systemd ... nedávno jsem tu několikrát zmiňoval, takže sorry za opakování, můj oblíbený, kdy pomalost zpracování logů (což je sám o sobě fuckup, jakým způsobem se to dělá) dokáže úplně zablokovat start systému (takže se tam člověk ani nepřihlásí, aby to nějak opravil), což je IMO megafuckup (notabene když se systemd neustále chlubí zrychlováním startu, a sám zavede věc, na kterou se při startu čeká)

[Sid]

Cisto zo zaujimavosti, Lennart ti zo svojim systemd rozbil tvoje oblubene PC? Dlhodobejsie badam na tebe fobiu z toho mena . Aby si raz detom necital rozpravku "A potom prisiel zly Lennart..."

[little.owl]

To bych mu nezazlival; jako zamestnanec linuxove firmy v Brne se musi potykat s bugy a rozbijenim systemu v prvni linii (my to uz dostanem ucesane), a Lennart mi pripada jako clovek vice tvari se kterym se nespolupracuje snadno.

[Sid]

viem, ze pracuje pre RedHat akurat u neho mi pride miera znechutenia dost velka, az by som to nazval osobnou zaujatostou.

[little.owl]

Kavol jen udrzuje rovnovahu veci ... .

[TM]

Vůbec se mu nedivím.
Já si taky myslím, že Lennartovy vynálezy jsou tím nejhorším, co mohlo distribuce Linuxu potkat.
Stejně je zajímavé, co dokáže malá skupinka dostatečně agresivních jedinců způsobit...

[pavlix]

Já bych řekl, že jeho příspěvky jsou tak trochu karikaturou pohledu lidí, kteří usilovně pracují na tom, aby celý ten systém nějak fungoval.

[Michal Vyskočil]

a Lennart mi pripada jako clovek vice tvari se kterym se nespolupracuje snadno.

Co jsem proletěl pár kavolem odkazovaných věcí, tak tu jeho averzi k osobě LP chápu.

[kavol]

díky

[kavol]

Cisto zo zaujimavosti, Lennart ti zo svojim systemd rozbil tvoje oblubene PC?

mé oblíbené PC zatím ne, neb na něm běží Gentoo :-p

nicméně rozbil mi pracovní notebook, a rovněž notebooky mojí ženský a tchýně - přičemž s tím je to o to vtipnější, že k němu mám přístup jen když jedeme na návštěvu, tj. tak max jednou do měsíce

Dlhodobejsie badam na tebe fobiu z toho mena

v tom případě nevím, co se tak blbě ptáš, neb dlouhodobě podkládám své příspěvky odkazy na konkrétní problémy (výše uvedený jsem tu zmiňoval snaď aspoň desetkrát a za chviličku odpovím kolegovi níže se správným číslem bugu, tak se snad nemusím opakovat v každém ...)

[little.owl]

stejně tak lze sepsat seznam fuckupů v systemd ... nedávno jsem tu několikrát zmiňoval, takže sorry za opakování, můj oblíbený, kdy pomalost zpracování logů

A ten bug, kdy se to pri bootu kouslo a muselo se promazat journald souboru, byl uz konecne vyresen, nebo to bylo jen "pomale"?

[marbu]

Myšlíš tohle: BZ 967521?

[little.owl]

Ano, to by mohlo byt ono. Ja to chtel reportovat jako tohle. U F20 se mi to uz nestava, bylo to tedy vyreseno?

[kavol]

našly se tam díky tomu i nějaké jiné drobnosti, které se fixly v rámci dalších bugreportů, ale hlavní problém byl nakonec řešen jako bug #1006386

U F20 se mi to uz nestava, bylo to tedy vyreseno?

tuším, že to bylo obejito nějakým limitem na velikost logů - zajímavý je asi #84, ale nijak konkrétně mi to z toho neplyne, jestli se udělalo to navrhované výše, a v srpm (patche, spec) o tom bugu nevidím nic kromě konstatování v changelogu, žádný patch na journald, který by vypadal relevantně ...

[little.owl]

Aha, diky, to jsem videl, tu zaplavu mmap-u; tusim ze jsem se tu pak divil IRC komunikaci v bugzille; pak uz jsem to nesledoval.

[kavol]

Aha, diky, to jsem videl, tu zaplavu mmap-u

jo, to byla další věc, co se udělala, že to myslím michich lehce zoptimalizoval, an to jsem zapomněl, nehynoucí sláva mu

[kavol]

U F20 se mi to uz nestava, bylo to tedy vyreseno?

ještě doplnění, tak si čtu bugzillí backlog, a narazil jsem na seznam relevantních commitů:

fbb6341    journald: mention how long we needed to flush to /var in the logs
eda4b58    journal: simplify pre-allocation logic
248c78c    journal: allow journal_file_copy_entry() to work on non-local files
e5462cd    journal: fix iteration when we go backwards from the beginning of an array chain element
f268980    journal: optimize bisection logic a bit by caching the last position
a676e66    journal: when appending to journal file, allocate larger blocks at once

[little.owl]

Diky, prave koukam do git logu a dohledat, kde/co to vlastne resi neni jednoduche.

[Michal Vyskočil]

a) opět oblíbené falešné dilema - těch alternativních init systémů existuje jaksi poněkud více, než na kterých Lennart ukazuje, jak je zrovna ten jeho v porovnání skvělý

No a tady o tom zrovna píše Russ Albery, což se zdá je afaik jeden z tak čtyř lidí na světě, který trochu víc vidí do všech tří (čtyř, počítáme-li i sysvinit) init systémů.

b) stejně tak lze sepsat seznam fuckupů v systemd

No, pokud to budou dlouho známé desingové nedostaky, tak sem s ním. Pokud vím, tak hlavním (a jediným velkým) průserem Lennart-ware je journald a jeho excelentní rychlost nad rotačním diskem.

[little.owl]

Tech bugu je mnohem vice, treba nedavno tenhle, ale pomalu se resi; ostatni systemy na tom nejsou s bugy lepe, progress na opravach je pomalejsi.

[kavol]

Tech bugu je mnohem vice, treba nedavno tenhle

dík za link, skoro mám takový pocit, že #c10 docela vysvětluje první polovinu problému, proč nám v neděli padnul webserver, čehož jsme se zatím nemohli dopátrat

[R]

Pekny bug...teda vlastne 3 bugy. Nestacim sa divit nad demenciou systemd a gnome 3.

[kavol]

No a tady o tom zrovna píše Russ Albery, což se zdá je afaik jeden z tak čtyř lidí na světě, který trochu víc vidí do všech tří (čtyř, počítáme-li i sysvinit) init systémů.

promiň, ale nemám pro to jiných slov než bullshit

ani jsem nebyl schopen ty sračky dočíst do konce

ale abys neřekl, že to shazuju bez argumentu, tak třeba:

* No mechanism for process monitoring and restarting beyond inittab.

no a? proč by to měl řešit init? - viz níže Aleš používá třeba Pacemaker, proč by na to měl mít monopol initsystém?

není to jaksi spíše argument pro argument, nežli reálný požadavek? kde je nějaké vypořádání se s oponentním názorem, že init by měl naopak být co nejjednodušší (tedy nejrobustnější) a neřešit věci, které mohou být řešeny mimo něj?

No, pokud to budou dlouho známé desingové nedostaky, tak sem s ním. Pokud vím, tak hlavním (a jediným velkým) průserem Lennart-ware je journald a jeho excelentní rychlost nad rotačním diskem.

jestliže si někdo stěžuje na "Lack of integration with kernel-level events to properly order startup.", tak pro mě je velkým nedostatkem naopak příliš velká integrace s kernelem, že to není schopno běžet nad jiným (resp. byť jen jinak zkompilovaným!)

tím pak padá proklamovaná jednoduchost pro ostatní, že ke svým démonům mohou dodávat jenom systemd unitu a bude to fungovat všude - nebude, jak si přes systemd unitu pustím Apache nad *BSD?

například ...

[Aleš Kapica]

Jako jeden z masových uživatelů konstatuji, že mi je to vcelku jedno, ale osobně mám silnou nedůvěru ke všemu co pochází od Canonicalu, takže bych volil mezi systemd nebo openrc. Stejně jde v mém případě pouze o nahození základních služeb o zbytek se už tak jako tak musí postarat pacemaker.

[kavol]

neboj, systemd se postará, aby jsi s ním nemohl Pacemaker používat, protože jediné správně řešení je ovládat vše přes systemd :-p

[Aleš Kapica]

Zabít se dá všechno.

[little.owl]

Devel mailing listy Debianu scanuji a zaznelo tam vselicos, na obou stranach. Realitou je, ze podle zaznamu v git-u pocet prispevku od jinych prispevatelu mimo LP a KS, z jinych distribuci, setrvale roste, takze tyhle argumenty jsou mene a mene platne.

[Jakub Lucký]

Tak ještě aby to byly vesměs mazací (nebo modularizační) commity, co odebírají to, co tam ten Lennart nafrkal...

[little.owl]

Nejsou.

[Jakub Lucký]

v tom případě bych argument jen trochu upravil a zanechal ho platným...

[Duff]

Je vůbec nutné měnit součastný init v Debianu, který funguje spolehlivě, umí dependency a start je dost svižný na to, že startuju počítač tak jednou týdně.

Podle toho co čtu a systemd tak z něho nemám dobrý pocit a závislost na Canonicalu se mi taky moc nelíbí.

[trekker.dk]

Jenže vývojáři mají osypky z těch (údajně) strašlivých skriptů.

[Petr Tomášek]

Rozhodně lepší, než se vrtat ve zdrojácích systemd

[Foo Bar]

Eh, když dneska selže sysvinit, insserv nebo startpar, tak se tady jdete hrabat ve zdrojácích initu, nebo napíšete bug a maintainer (nebo upstream) se o to postará...?

[Ivan]

Nedelam ani jedno. Kdyz selze init, tak bohuzel po sobe moc stop nezanecha - proto se problemy tohoto typu spatne reportuji. A taky proto spousta lidi reaguje podrazdene, kdyz se ma init menit.

Nastesti samotny init process toho umi tak malo a je tak stabilni, ze s nim nejsou problemy. A do init scriptu vetsinou staci pridat "-x" a pri pristim bootu clovek vi na cem je.

[pavlix]

+1

[little.owl]

Tenhle smer argumentace je postaven na hlavu.

Pokud se vam podela init, systemd, kernel ci neco jineho, jste v prdeli, a nema moc smysl resit, jestli mensi nebo vetsi. Pro vas, jako admina, prisel spravny cast pozadat Red Hat ci SUSE o support, a nechat to resit vyvojare, vy muzete maximalne upichnout nejaky docasny workaround. Dale, nikdo nebude nasazovat systemd do produkce, dokud nebude pro jeho potreby dostatecne stabilni, a treba do RHEL 7.1 je jeste dlouha doba.

Co se tyka me, systemd mi velmi zjednodusil skripty, nekdy na uroven kdy uz v podstate nejsou, tudiz se nema co podelat. Daleko vetsi problemy mam s daemony/sluzbami a jejich chovanim za behu a tam mi systemd nabizi lepsi moznosti, od uklidu, monitoringu, po analyzu toho, co se vlastne stalo. K pre systemd stavu bych se uz rozhodne vracet nechtel.

[Heron]

Pokud se vam podela init ... ste v prdeli

COŽE??? Sorry, ale server se dá nabootovat i s kernel parametrem init=/bin/bash a zbytek pěkně ručně. Není to těžké. Ne že bych to dělal rád, ale pár takových případů mám za sebou. Když se podělá init, tak support určitě nepotřebuju. Otázkou tedy zůstává, zda by měl dělat admina někdo, kdo neví co dělá.

[little.owl]

Sorry, ale server se dá nabootovat i s kernel parametrem init=/bin/bash

Jiste, ale o tom nebyla rec.

Když se podělá init, tak support určitě nepotřebuju.

Takze pokud budete mit bug v init (mel jsem segfault v initng), tak si ho sam opatchujete a jedete dal?

[Heron]

Jiste, ale o tom nebyla rec.

Jakto že ne? Já tvrdím, že pokud se rozbije init, tak v prd... nejsem a neměl bych být.

Takze pokud budete mit bug v init (mel jsem segfault v initng), tak si ho sam opatchujete a jedete dal?

Ten bug se tam pravděpodobně dostal s nějakou novou verzí balíčku takže lze nainstalovat starší, která fungovala. Každý update se zkouší na méně významných strojích a pokud něco rozbíjí, tak se na důležitější prostě neinstaluje. Co bych dělal v konkrétním případě ale říct nelze, záleží na tom konkrétním případu.

[little.owl]

Jakto že ne? Já tvrdím, že pokud se rozbije init, tak v prd... nejsem a neměl bych být.

Zaradte si tedy to reseni do kategorie 'docasny workaround', ktery jsem zminil, nic jineho to totiz neni.

Ten bug se tam pravděpodobně dostal s nějakou novou verzí balíčku

Varite z vody. Chyba tam byla od pocatku, tusim v parseru konfiguracnich parametru a projevovalo se to na nekterych prvnich amd64 strojich (zpracovani stringu); uvadel jsem to jen proto, ze to byl snad muj jediny pripad, kdy mi takhle nejaky init tvrde klekl.

Znova - poita je v tom, ze pokud mate bug v klicove binarce, vy jako admin upichnete maximalne docasny workaround a pozadate o support, veci jako rypat se v kodu, zejmena pro produkcni server, je prace pro vyvojare a nasledne QA team.

[mess]

Já si myslím, že to je hlavně proto, že když se přidají na temnou stranu síly a použijou systemd jako ostatní, tak to znamená že nebudou muset ke každému balíčku psát vlastní init skript, jelikož bude větší pravděpodobnost, že autor programu poskytne konfigurák pro systemd (když ho teda už používají všichni).

Čili méně drbání se s balením programů.

[little.owl]

Tam jde take i technicke aspekty, viz. treba zminena kontrola resources; systemd neni jen zalezitost rychleho startu ci zjednoduseni skryptu.

[mess]

Pravda, na to jsem pozapomněl.

[pavlix]

Na druhou stranu by teoreticky mělo jít správu služeb a podporu service files reimplementovat.

[trekker.dk]

Jenže já tu kontrolu od init systému nechci. Nemám zájem na tom, aby mi systemd sežral cgroups, nestojím o binární logy, které nelze přečíst čímkoliv, a nepotřebuju ani dohled nad službami, protože na to mám runit nebo pacemaker.

Jenže podle vývojářů systemd mám smůlu. A podle vývojářů Debianu zjevně taky, protože mi systemd bude vecpán. (Kecy o tom, že to je jenom změna výchozího init systému a že ty ostatní budou podporovány taky, se můžou nadrobit rybám. Známe salámovou metodu.)

[little.owl]

Pasivni vyzadovani status quo, spolu s neschopnosti prijit s zivotaschopnou alternativou k systemd behem poslednich tri let vedla ke stavajici situaci.
Mate smulu, pokud ocekavate, ze vyvojari a zastanci systemd se kvuli vam vzdaji sve vize a pisteni ja to nechci nazor tech co to naopak chteji nezmeni.

[kavol]

Pasivni vyzadovani status quo, spolu s neschopnosti prijit s zivotaschopnou alternativou k systemd behem poslednich tri let vedla ke stavajici situaci.

nějak stále postrádám vysvětlení, proč by měli přicházet s něčím novým ti, kterým vyhovuje to staré ...

[little.owl]

Nemusi prichazet s necim novym, ale musi si 'to stare', pokud to tedy chteji, sami udrzovat.

[Foo Bar]

Slyšte, slyšte!

...pokud místo klapání pusou o tom, jak mi Debian něco vnutí a nebude udržovat ty ostatní init systémy, raději pojďte ty ostatní init systémy udržovat. dtto platí pro GNOME, pokud chcete, aby tam nebyla taková silná vazba na logind/systemd, tak se to samo nenapíše – výzva šla od vývojářů GNOME už v roce 2012, a nikdo se neozval...

[kavol]

dtto platí pro GNOME, pokud chcete, aby tam nebyla taková silná vazba na logind/systemd, tak se to samo nenapíše

LOL - tak to je dobrá demagogie!

takže ta vazba na systemd se jaksi napsala sama a naopak je potřeba psát kód, aby tam nebyla, hmmm ...

[little.owl]

takže ta vazba na systemd se jaksi napsala sama a naopak je potřeba psát kód, aby tam nebyla,

Zadna demagogie. Kazdy projekt ma fundamentalni svobodu si stanovit sve behove zavislosti, at se jedna o knihovnu libXY ci treba libsystemd-* a tyto zavislosti se normalne meni v prubehu vyvoje. Pokud na nekterem systemu zavislosti nejsou naplneny, ma jeho vyvojar v podstate dve moznosti: (a) opatchuje projekt tak ze eliminuje chybejici zavislost nebo (b) vytvori nejakou compatibility vrstvu.

To ze projekt by mel byt se zavislostmi opatrny a nevytvaret tvrde zavislosti zbytecne, je jina vec.

[trekker.dk]

pokud místo klapání pusou o tom, jak mi Debian něco vnutí a nebude udržovat ty ostatní init systémy, raději pojďte ty ostatní init systémy udržovat

Hezký posun od "já klidně budu dělat podporu pro 3 init systém", který jste tady prezentoval v některé z minulých diskuzí.

A ano, pokud mi Debian vnutí systemd, tak mi nezbyde nic jinýho, než si systém udržovat tak, abych tu sračku nemusel instalovat. Práce navíc a zbytečná, ale dokud někdo Lennarta nezasype vápnem a nezaleje betonem*, tak mám smůlu.

* co jiného taky dělat s morovou ranou

[Foo Bar]

Já u většiny svých balíčků mám init skripty v shellu, pro upstart a pro systemd. Netuším však, jak přesně to souvisí s fňukáním nad tím, že Debian nebude podporovat více init systému. Pokud chcete, aby Debian podporoval více init systém, tak se to prostě samo neudělá.

[pavlix]

O to má smysl se bavit, pokud Gnome ztrácí některé nové nebo přepracované vlastnosti při použití na systému, kde pid 1 není systemd, jinak je debata bezpředmětná.

[little.owl]

Rekl bych to jinak - Gnome zacina zaviset na vecech, casto smysluplnych - jako treba fakt, ze init je schopen uklidit po procesech, ktere sam spusti - vecech, ktere je v soucasnosti schopen zajistit vetsinou jen systemd.

[pavlix]

Já jsem se myslím vyjádřil docela přesně a zatím k tomu nikdo nenapsal, jak se věci mají. Plané řeči mě nebaví.

[kavol]

možná by stálo zato rozvést, co tou údržbou myslíš, páč povětšinou jde o kód, který se napíše jednou a pak už se na něj nešahá ...

[little.owl]

Ve statickem svete mozna, OSS neni nastesti staticky ekosystem. Napriklad se bude jednat o udrzbu skryptu a souvisejici QA, treba v pripade kdy maintainer balicku odmitne sam podporovat cokoliv jineho nez defualtni init, pripadne zminene patchovani ci kompatibility vrstvy.

[Sešívaný]

Jak máme volbu nohama, tak toto bych nazval volbou rukama. Různé komise můžou možná tak rozhodnout o tom, co bude výchozí, ale nikdo nebrání nikomu v tom, aby v rámci projektu rozvíjel ty technologie, které považuje za správné. V open source ještě pořád rozhoduje práce.

Např. GNOME se vyčítá, že jeho portabilita na Unixy je čím dál obtížnější. Není to ale tak, že by se projekt nějak oficiálně usnesl na tom, že třeba na BSD kašle. Je to tím, že množství patchů třeba ze strany lidí od BSD je dlouhodobě minimální a 99 % vývoje dělají linuxoví vývojáři, kterým jde samozřejmě o to, aby to běhalo na Linuxu. Komunita rozhoduje o směřování projektu rukama.

Předpokládám, že v Debianu nebudou nikomu brátit v udržování či rozvoji initu a init skriptů, či upstartu nebo openrc. Stejně tak pokud bude někdo chtít, aby systemd fungoval na jiném jádře než Linuxu, tak si to prostě zařídí. Stejně jako lidi od Hurdu si napsali kompatibilní knihovnu, aby nad jejich jádrem mohl běžet init.

[little.owl]

+1

[trekker.dk]

Ano, mám smůlu, že pištění "já to chci" té menšiny, která má víc času na politiku, má větší váhu, než mlčení většiny, která se věnuje své práci a na politiku nemá čas.

[little.owl]

mlčení většiny, která se věnuje své práci a na politiku nemá čas

Vetsine je jedno, co ma za init, pokud to pro ne funguje a systemd pro ne fungovat bude.

'Vaha' se v OSS casto ziskava poskytnutym kodem - rukama, jak bylo receno.

[trekker.dk]

'Vaha' se v OSS casto ziskava poskytnutym kodem - rukama, jak bylo receno.

A když je ten kód zprasený, zavádí problémy tam, kde nebyly, a rozbíjí věci s tím, že tak je to správně, nastoupí politika. Hle, systemd.

[little.owl]

A když je ten kód zprasený, zavádí problémy tam, kde nebyly, a rozbíjí věci s tím, že tak je to správně, nastoupí politika. Hle, systemd.

Na odsuzovace politiky mate slusnou 'politickou' retoriku .

[Heron]

a start je dost svižný na to, že startuju počítač tak jednou týdně.

Dneska jsem restartoval workstation více než 10x (testy nastavení hw) a ty 3s v initu mi přijdou docela snesitelné. Déle trvá už jen POST samotný.

[dustin]

Jak by mohl vypadat seamless přechod ze stávajícího initu na systemd při upgradu stable na jessie, až na něj přijde řada? Zatím byly upgrady stable celkem bezproblémové i na produkčních strojích.

[kverulant]

Já mám debian jessie a na systemd už jsem přešel, protože mi bez něj nefunguje uspávání. Zatím si nemůžu stěžovat. Start je subjektivně rychlejší, do konzole se při startu vypisuje méně textu a to je asi tak všechno, čeho jsem si všiml. Instalace bez problémů. Za mě na desktopu jsem pro.