Výchozím init systémem Debianu bude systemd (diskuse)

[Hans1024]

Rekl bych, ze ten vysledek jeste vubec neni jisty. Ian se "EXTREMNE" nastval, protoze Bdale nedal o hlasovani vedet predem, a neumoznil tim pripominky. Ian si vzal par dni volno, aby se uklidnil. Navic sve hlasy muzou menit, myslim ze do tydne po zacatku hlasovani.

Nevim, proc to povazujete za uzavrenou vec.

[pavlix]

Zase na druhou stranu je to uzavřená věc už docela dlouho ;).

[Hans1024]

No systemd je vec celkem uzavrena, vedena tvrdou rukou Lennartovou, to mate pravdu

[dustin]

Je otázkou, jak dlouho se bude Lennart systemd věnovat. Pulseaudio rozjel do nějaké více či spíše méně použitelné formy a pak jej nechal ostatním, aby na něm dělali. Po pár letech už je docela rozumné a stalo se standardní součástí linuxového desktopu (ne, libalsa jej opravdu neumí plně nahradit, navíc se už některé její pluginy, např. dmix, víceméně nevyvíjí, s odkazem na roli PA). Systemd už je docela daleko, dovedu si představit, že se Lennart v dohledné době pustí do jiného projektu. Pak by impulzy (i) z debianu mohly systemd posunovat dopředu.

Pevně věřím, že až se systemd dostane do stablu, bude už zase trochu jinde.

[Hans1024]

No pulseaudio me nikdo nenuti pouzivat a vystacim si s dmixem. Jestli se ale zacnou mnozit balicky zavisejici na systemd, tak to se teprve nastvu :-/

[Hans1024]

Coz je mimochodem presne to, co chce Ian osetrit (jestli muze byt zaislosti konkretni init).

[Foo Bar]

No já nevím, Ian tam tlačil svoji extrémní ideu, se kterou nakonec nesouhlasil ani Steve. Přečtěte si poslední diskuzi mezi Ianem a Stevem.

Podmínka, kdy by balíčky měly zakázáno záviset na konkrétní implementaci rozhraní, pokud nebude existovat alternativní implementace, mi osobně přijde už mimo mísu.

[Hans1024]

No kazdopadne si myslim, ze nejde vyresit jednu vec (init) bez druhe (zavislost na initu). Oni chteji porad hlasovat co bude default, ale predtim by bylo dobre rozhodnout co z toho vypliva, ze neco bude default. Jestli mi zadne klicove balicky nebudou systemd nutit, tak prosim, at si je defaultem. Jestli me ale nutit budou, mam s tim docela problem.

[little.owl]

Jestli me ale nutit budou, mam s tim docela problem.

Tohle neni zalezitost tvurcu balicku ci distribuce, ale tvurcu baleneho SW. Pokud programatori zacnou vyuzivat systemd a vytvori nejake zavislosti, packager s vyjimkou trivialnich pripadu nema moc moznosti s tim neco delat.

[marvn]

nikdo ti nic nutit nebude. nejhorsi co se muze stat je, ze budes mit pocit, ze ti neco nuti a budes to psat na internety...

[wtf]

So, far, the oldest Linux Distro Slackware has avoided the issue and the most recent version, Slackware 14.0 released last fall by its Founder +Patrick Volkerding, is doing just fine without it.

[potato]

Slackware je takové naše malé linuxové muzeum. Mentálně zůstává někde v době kontroverze mezi libc5 a glibc nebo přechodem z a.out na ELF...

[wtf]

Tak to me tesi, ze ma takovou image. Aspon nehrozi HiJack od JackAss Inc.

[luky]

ne, libalsa jej opravdu neumí plně nahradit, navíc se už některé její pluginy, např. dmix, víceméně nevyvíjí, s odkazem na roli PA

U alsy si alespon muzu vybrat, jestli chci mixovat softwareove nebo hardwareove. IMO to je zakladni funkce zvukoveho systemu.

[dustin]

Poslední zvukovky s HW mixem podporovaným alsími drivery byly staré soundblastery před 10+ lety.

[Josef Kufner]

Mám zvukovku s HW mixováním na desce s Intel i3. Umí sice jen 4 kanály současně, ale stačí to k tomu, aby mi MPD neběželo skrz PulseAudio.

[dustin]

OT: Deska s i3 má zvukovku Intel HDA, které žádný HW mix streamů nemá. Možná mluvíš o nějakém mixování kanálů čtyřkanálové zvukovky (což není HW mix streamů, o kterém byla diskuse, a s dmixem vůbec nesouvisí). Pokud zvukovka takové čudlíky nabízí a alsa je umí, pak jimi můžeš alsamixerem kroutit bez ohledu na to, zda data do výstupního alsího zařízení pouští PA nebo MPD.

Spíše bych řekl, že to máš jenom špatně nastavené.

[luky]

Poslední zvukovky s HW mixem podporovaným alsími drivery byly staré soundblastery před 10+ lety.

Na to jste prisel jak? Co treba Sound Blaster Audigy Fx, coz je Sound Blaster Audigy 4 s PCIE rozhranim ze zari minuleho roku.

[David Heidelberg]

No, pokud to tvoje zvukovka umí, tak můžeš používat HW mixování. Pokud ne - hodně štěstí třeba s 5.1 + více aplikací + dmix. S dmixem jsem nad tímhle zlomil hůl, nainstaloval PA a ani jsem nemusel hrábnout na konfiguraci, vše plynulé a funkční + nezávislá regulace hlasitosti.

I přesto, že nejsem BFU, tak mi vyhovuje, když všechno funguje out-of-box. To samé např. Nokia N900.

[dustin]

Hm, zrovna s multikanálovým dmixem nemám na HTPC žádný problém. Ale to už je OT.

[Heron]

Je jistě hezké, že PA umí mixovat 5.1, ale já bych třeba rád, kdyby to umělo třeba jen kvalitní stereo.

PA funguje na defaultních 44.1 (48kHz) 16b. Toť vše. Jakmile se zvedne samplerate na 96kHz, 24b, nebo se změní resample alg na cokoliv lepšího než je ten odporný default. tak to jde do kytek. Jeden stream zvládne, dva a víc už ne. Když tak můžu poslat screeny z osc (což stejně plánuji na nějaký dlouhý víkend), ale ono to jde samozřejmně normálně slyšet.

Po pár dnech měření jsem tak dospěl do stavu, kdy mám pouze alsu, 96kHz / 24b (S32_LE), pro více zdrojů mám dmix a funguje to.

Mimochodem, prodávají se docela kvalitní dac do usb, ale všechno je jen max. 48kHz. Dlouho jsem si lámal hlavu proč, když ve studiu se používá 192kHz / 24b. Myslím si, že je to právě proto, že většina software s ničím jiným ani nepočítá, a tak ti výrobci (třeba TI), alespoň vyždímali z 48kHz maximum. Což je sice fajn, ale je to taková z nouze cnost.

[dustin]

OT: PA jede na takové frekvenci, jakou si nastavíš. Interně jede v int32, takže žádných 16 bitů. Algoritmus si volíš úplně stejně jako v dmixu, obojí používá úplně stejné sady resamplovacích knihoven. Když PA nastavíš na 96kHz a pustíš do něj 96kHz track, nic se resamplovat nebude. Stejně jako v dmixu. Jen dmix ti to narozdíl od PA všechno před samplerate konverzí shodí na 16 bitů.

Chceš-li PA/dmix s kvalitní konverzí a minimální spotřebou CPU, nakonfiguruj si libsoxr - http://blog.ivitera.com/pavel/linux-audio/simple-use-of-libsoxr-lsr-in-alsa-using-ld_preload , http://blog.ivitera.com/pavel/linux-audio/pulseaudio-with-ld_preloading-libsoxr-lsr

Co "vše" umí jen 48kHz? V linuxu tedy určitě ne, tam SW jede na samplerate, který si nastavíš. A zvukovky (kromě nepodporovaných, kterých je dnes naprosté minimum) umí plný rozsah frekvencí, které hardwarově umí.

[Heron]

Interně jede v int32, takže žádných 16 bitů.

No ještě aby nejel. Jde o výstupní formát.

Algoritmus si volíš úplně stejně jako v dmixu

Vzhledem k tomu, že jsem je měnil, tak tohle tak nějak vím.

Když PA nastavíš na 96kHz a pustíš do něj 96kHz track, nic se resamplovat nebude.

Ano. Ale když se k tomu přidá další stream, tak už to výkonově nezvládá.

Blogy si přečtu. Nejde o minimální spotřebu, ale o maximální kvalitu.

[David Heidelberg]

výkonově nezvládá? na jakém HW?

určitě to nevylučuji, ale spíš to vypadá na nějakou chybu, než špatný design. Když vezmu, že PA může běžet bez problému na N900 (OMAP3, 600Mhz ARM, samozřejmě asi max. 48kHz)

[Heron]

AMD FX8350

[David Heidelberg]

hehe, tak to vypadá na bug

[dustin]

Prostě jen CPU nestihne resamplovat tím přenastaveným algoritmem.

[dustin]

No ještě aby nejel. Jde o výstupní formát.

?? PA jede přímo nad alsím zařízením hw:X (protože z principu své funkce zapisuje přímo do DMA RAM bufferu zvukovky, aby mohl mixovat streamy s různou latencí). Takže na výstupu použije velikost samplu vyžádaný přímo driverem zvukovky. Nic jiného mu ani alsa-lib nedovolí.

Vzhledem k tomu, že jsem je měnil, tak tohle tak nějak vím.

To je dobře. Tak jak se tedy liší?

Ale když se k tomu přidá další stream, tak už to výkonově nezvládá.

Stream o stejné fs nebude taky resamplovat, není proč. Samozřejmě když musí resamplovat, dojede na žravost použitých resamplovacích knihoven, úplně stejně jako dmix. Ani moderní CPU neutáhne dmix se samplerate_best na 96kHz, stejně jako u PA.

O minimální spotřebu CPU jde, protože vyšší kvalita libsamplerate spolehlivě zahltí CPU a způsobí xruny. Proto nemůžeš nakonfigurovat PA/dmix s touto volbou.

[Heron]

??

Asi si nerozumíme. PA, ve defaultu, má nastavenou samplerate 44.1kHz/16b. A toto opravdu jde do zvukovky. Při nastavení na 96kHz, jde do zvukovky opravdu 96kHz. Tohle nastavení, pokud bychom nevěřili informacím od PA nebo Alsy (kam PA hraje), lze poměrně jednoduše potvrdit měřením (samplerate 44.1 frekvenci například 40kHz nepřehraje, 96kHz už ano, a u 192kHz jsem celkem pohodlně mohl generovat 70kHz.) Takže ano, PA jede na frekvenci, kterou si nastavím, ale cokoliv nad 48kHz u mě nestíhá. U alsi mám dmix nastaven na 96kHz, protože primární využití této zvukovky je právě přehrávání samplů 96kHz/2, takže logicky chci, aby se jakékoliv jiné sekundární samply (typicky na 44100) resamplovali sem. S alsou mi to funguje.

To je dobře. Tak jak se tedy liší?

U speex-float-0 jdou celkem jasně slyšet artefakty při přehrávání samplu 96kHz do standardních 44100. Při samplerate_best, což třeba alsa, nebo i například deadbeef stíhá, nikoliv.

O minimální spotřebu CPU jde, protože vyšší kvalita libsamplerate spolehlivě zahltí CPU a způsobí xruny. Proto nemůžeš nakonfigurovat PA/dmix s touto volbou.

Ano, ale není úplně nezbytně nutné používat pouze a jen tu nejnižší.

Jestli je to celé jen bug PA nevím. Vzhledem k nemilosrdně pokračující penetraci PA bych byl celkem rád, kdybych požadovaného nastavení mohl bezproblémově dosáhnout i s PA, protože se tomu v budoucnu stejně nevyhnu. Zatím ale bohužel vidím priority vývoje (pokračuje vůbec nějak?) jinde a to v podpoře všech těch BT zařízení.

[dustin]

speex-float-0 je samozřejmě velice nekvalitní, není divu, že slyšíš artefakty. Proč používáš tak špatné nastavení?

Na Atomu, co teď píšu, žere aplay při resamplování přes alsu s kvalitou samplerate_best téměř 100%, tj. permanentní xrun. Na výsledné frekvenci nezáleží, dělá to i pro 44100 výstupní samplerate. Celé jádro žere i na výkonnějších strojích (nějaké P dual core)

Samozřejmě úplně stejně na nejvyšší kvalitu žere PA.

Samplerate-medium na 96kHz žere podobně jako defaultní speex-3 u PA okolo 40% CPU. Zatímco na nezatíženém stroji to jeden přehrávací proces alsy ustojí, přes PA zvuk vypadává. Je to logické, protože aplay hraje přímo do zvukovky v rámci jednoho procesu, zatímco přes PA to jde přes aplay (přehrávač) do PA (zvukový server). Dva procesy jsou samozřejmě náročnější. Když v prvním případě čisté alsy stroj trochu zatížím, přijdou xruny také. Prostě při 40% na playback proces zbývá příliš malá rezerva. PA speex-1 žere pár procent.

Podotýkám, že mám ubuntu 10.04, tedy letité PA. To dnešní už je zase o trochu jinde.

Prostě pokud chceš spolehlivý kvalitní resampling, potřebuješ ten libsoxr, s ostatními žravými knihovnami budeš vždycky na hraně. A pak je jedno, zda PA nebo čistou alsu.

Výstupní formát v PA je jen defaultní, tj. první pokus. Pokud zvukovka umí třeba jen 32bit (většina PCI zvukovek, kromě IntelHDA), stejně se použije 32bit. Jinak překonfigurovat PA na nejvyšší podporovaný formát zvukovky je triviální.

[Heron]

Proč používáš tak špatné nastavení?

Nepoužívám.

Na Atomu, co teď píšu, žere aplay při resamplování přes alsu s kvalitou samplerate_best téměř 100%,

U mě cca 40%. 1/16 cpu klidně věnuji na zvuk.

Zatímco na nezatíženém stroji to jeden přehrávací proces alsy ustojí, přes PA zvuk vypadává.

Ano. Děkuji za potvrzení.

[dustin]

Pokud ti PA žere cca 1/16 výkonu tvého stroje (bude to podobné jako u alsy, knihovny jsou stejné), pak jsem přesvědčený, že kdybys nastavil trochu realtimových parametrů, budeš mít přehrávání s resamplováním stabilní. Se podobnou situací se potýká jack (tam nejde o spotřebu CPU, ale latenci - podobný problém, je to taky další proces v cestě) a řeší to rt prioritami.

Na druhou stranu, pokud jsi spokojen s alsou a nepotřebuješ funkce, které nabízí PA, nemáš důvod jej používat. Já je taky na některých strojích nemám, když mi záleží na jednoduchosti (např. HTPC). Čistá alsa bude pořád fungovat.

[LKG]

Ty USB DAC maji jeden zasadni nedostatek - jsou pouze USB 2.0 Full Speed a Audio Class 1.0 - 24b/192kHz nezvladaji ani rychlosti, ani firmwarem.

Ted zacinaji byt dostupne USB Audio Class 2.0 USB 2.0 HiSpeed cipy, napr. CM6631A od C-Media. Casem se zacnou osazovat DACy timhle misto obyc 1.0... Ted jsem si jednu desticku CM6631A/PCM1792/TPA6120 delal....

[Pavel Ruzicka]

To mne docela zajima. Mate k dispozici schema vaseho USB-I2S prevodniku? V soucasne chvili nevyrabi zadny vyrobce jednoduchy USB codec Audio Class 2.0, ktery by nepotreboval programovat a mel malo vyvodu. USB zvukovek jsem postavil nekolik s cipy od Texas Instruments, ale jsou bohuzel pouze do 48kHz. Rad bych si postavil USB-I2S prijimac s podporou 192kHz a k nemu pripojil D/A prevodnik.

[little.owl]

V soucasne chvili nevyrabi zadny vyrobce jednoduchy USB codec Audio Class 2.0, ktery by nepotreboval programovat a mel malo vyvodu.

Mame kit od XMOSu, ktery to umi, ale je to drahe programovatelne monstrum.

USB zvukovek jsem postavil nekolik s cipy od Texas Instruments, ale jsou bohuzel pouze do 48kHz.

PCM2902E?

[Bedňa]

Si nám pokazil radosť

Fuck systemd from the bottom of my heart.
Fuck it.
Fuck it.

FUCK SYSTEMD.

I do not want to learn systemd.
I do not want to deal with systemd.
I hate the way it does things.
I hate the way their community works.

I hate that it does so much.
I hate that it changes the system.
I hate what it is: system Daemon.

Dať tomu punkový podmaz a môže to byť hit, nenachádza sa tu nejaký umelec čo by to naspieval? Rád by som si to dal ako zvonenie.

[s0]

ale mlho...

[merlyn]

RIP Debian. Budu muset hledat nejakou jinou jednoduse pouzitelnou, nenarocnou a obsahlou distribuci.

[wtf]

Taky to tak vidim. Po tomhle fiasku s hlasovanim se da ocekavat odliv vyvojaru. Pokud teda nedojde k narovnani.

[frdrx]

Zabedněnci odejdou. Good riddance.

[wtf]

bohuzel to znamena dvakrat vice prace pro aktivni idioty a tedy dvakrat vice moznosti neco zkazit.

[frdrx]

Znamená to víc prostoru pro schopné a aktivní vývojáře toužících věci vylepšovat a míň závistivého fňukání druholigových leč hlasitých zabedněnců, kteří neumí nic vylepšovat a hledají jiné způsoby jak vypadat důležitě.

[wtf]

coz v pripade Debianu znamena jedine odliv uzivatelu. uz i zrychleni release cyklu byl pro znacnou cast uzivatelu neprimereny infarktovy sok.

[frdrx]

Nevidím důvody si tohle myslet.

[wtf]

no vidis. ja v to doufam. debian upadne v nelibost, casem skonci ubuntu a treba bude zas nasaditelny jak pred deseti lety.

[frdrx]

To hrozí asi stejně jako to že pozici Linuxu nebo GNU ohrozí HURD nebo Plan 9.

[wtf]

predsevzeti pro tuto diskuzi. na tebe nereaguji. nechci si zkazit nazor na to, ze jsou tu inteligentni lide. nechci si te zaskatulkovat jako dalsiho "greater good doera", kteri z linuxu odhani uzivatele. typicky osobu, co je hyper-super-ultra-cool inovativni a pokrokova. ma v hlave svych 10 use-case co pouziva 90% uzivatelu a silou je vsem narve do chratnu i kdyby se meli zardousit driv nez implementuje tech dalsich 90 use-case co pouziva 10% uzivatelu co se leda tak nastvou co ze se to zase kde kvuli komu vykurvilo. udelej to tak krat pocet balicku v debianu a zjistis, ze ti zustala prazdna mnozina uzivatelu debianu.

[wtf]

pro poradek: systemd do te skupiny nepatri, ale argumentace frdrx tak trosku misty ve vlaknech vic dole tak na 50% mozna i vic jo.

[frdrx]

Vždycky mě baví sledovat jak si spousta lidí svoje nepochopení ostatními vysvětluje tak, že ostatní jsou blbci, jinak by přece museli souhlasit.

[wtf]

me zas bavi videt nadsence, co si projde vyhorenim, aby pak pochopil, ze se placa porad na miste se stejnym hovnem. misto toho aby zamakal na dotazeni toho co uz existuje.

[wtf]

ale kdyz je za to nekdo plati, tak to neni moje starost...

ale osobne by mi asi jako investorovi vadilo objednat si barak a mit kazdejch pet let novy zaklady a strecha ani za 40 let nikde.

[wtf]

u systemd tu strechu postavili, ale rovnou na zakaldy, takze se bude chodit asi stresnim oknem.

[kolcon]

myslis treba Lennarta?

[frdrx]

Ne.

[wtf]

pro poradek... me je systemd uplne u zadele. je to jen v soucasnosti asi nejlepsi spravce sluzeb nicmene stale zalostne neuplny z pohledu kernel api. jen dalsi meziclanek co bude za 10,20 nebo 40 let zahozen a nahrazen snad uz konecne necim co umi i runlimity boha jeho to api je stary jak metuzalem a nikdo se ho nechysta z kernelu odstranit.

[hermelin]

Systemd a jemu podobny je bordel - a jde presne proti filozofii unixu/linuxu = delat jednu vec a delat ji poradne. Mozna ze na desktopu to nejake plus ma - na serveru bych se s tim potkaval opravdu nerad. Klasicky rc scripty jsou podle me na serveru nejlepsi.

[MarSik]

Ač má způsob jakým to Lennart vede mouchy (no.. masařky :), tak systemd řeší jednu či dvě věci, které rc skripty neumí a přitom jsou na moderním serveru potřeba:

1) správný selinux kontext nezávisle na tom, kdo službu spustí (init vs. service start)

2) to samé pro cgroups

3) jako bonus předotevření serverových socketů (tohle je občas užitečné pro HA služby)

[trekker.dk]

správný selinux kontext nezávisle na tom, kdo službu spustí

Selinux je další příklad molochu, který se snaží dělat všechno.

to samé pro cgroups

Děkuji, ošetřím si sám tak, jak potřebuju. Jenže systemd mě nenechá.

[chrono]

Akú reálny výhodu prináša používanie cgroups (pretože pri mojich testoch som si nevšimol, že by systém bežal lepšie)?

[pavlix]

Popravdě, cgroups je nástroj na seskupování/rozdělování procesů. Dokud s těmi skupinami nic dalšího neděláš, tak to asi těžko může na běhu něco měnit. Nicméně jedna věc mi na service managerech nad cgroups vyhovuje, a to je schopnost udržet si přehled o tom, které procesy do služby patří a případně je zlikvidovat. Pro limit prostředků pro specifické služby bych měl taky použití.

[chrono]

Myslel som si, že systemd nejako tie cgroups využíva (keď ich potrebuje).

[pavlix]

Pokud vím, tak je používá tak, jak jsem psal výše (což mimochodem umí i OpenRC), a dále dle specifikace v .service souborech. Další vlastnosti postavené nad cgroups jsou pokud vím volitelné (nemusíš je mít vůbec zapnuté v jádře a systemd naběhne) a nastavují se v .service souborech.

Očekávat, že naházím procesy do skupin podle služeb a systém zázračně poběží nějak jinak, je pitomost.

[kavol]

Další vlastnosti postavené nad cgroups jsou pokud vím volitelné (nemusíš je mít vůbec zapnuté v jádře a systemd naběhne)

hm, nevím, co myslíš "zapnuté", ale řekl bych, že tvé informace se poněkud rozchází s tím, co mi posledně říkal Seki -

a) jádro musí být zkompilované s podporou cgroups

b) jsou dva levely použití cgroups, systemd se obejde bez druhého - tady si nejsem jistej, už je to nějakej pátek, moje paměť je chabá a nejsem jadernej expert, ale v principu jsem to pochopil tak, že ty pravidla musí jít nadefinovat, ale už se za běhu nemusí používat (aby se vlk nažral a koza zůstala celá)

[pavlix]

a) jádro musí být zkompilované s podporou cgroups

To je naprosto v souladu s tím, co jsem psal.

[kavol]

to bylo pouze upřesnění, neb "zapnuté" se v kontextu konfigurace jádra používá i pro povolené konfigurační volby; podstatný je ovšem ten druhý bod

[pavlix]

Ten druhý bod je úplně o tom samém, co jsem psal.

[kavol]

pak máš ovšem nějakou zvláštní definici "zapnuté" ...

[wtf]

je na balickari, aby v unitfajlu nastavil sluzbe cgroupu. pripadne pokud sysadmin uzna za vhodne neco zmenit, protoze balickar je skoro jako rozhodci, tak ma systemd jeste override strom kam se da vrazit nahrada.

[chrono]

Čiže je chyba správcov balíčkov, že používanie cgroups v systemd nemá žiadny dopad na výkon?

[wtf]

je chyba spravce, ze pouziva balicky, ktere cgroups nepodporuji.

[wtf]

no ale dost vtipne kase... dopad na vykon, co si pod tim kefalin predstavujete? cgroups nejsou tlacitko "turbo" jak z dob XT, ci 286. v systemd se to pouziva treba na garanci kvality, kdyz se vsechno zatizi a v dusledku pretizeni zpomali do dob 286 nebo XT, tak aby nekdo kdo musi jeste bezel v kvalite soucasnosti.

[dustin]

Třeba MongoDB jsem musel zavřít do memory cgroup, jinak zaplnila všechny diskové buffery v paměti a systém se takřka zastavil. Po omezení celkové využité paměti tím procesem běží mongo i systém OK. Předpokládám, že v systemd jen zadám do spouštěcí konfigurace mongodb velikost paměti pro cgroups. Samozřejmě to lze vyřešit i ve skriptech, ale chvíli to zabere.

[Robert Smol]

Dalsi vyhodou je i spolehlive ukonceni opravdu vsech procesu. Tusim, ze pokud bezela nejaka konfigurace typu Apache+forkovane procesy, nebylo snadne dohledat, komu vsemu poslat KILL. Vyhodou cgroups je i to, ze jakykoliv potomek je stejne zonackovan a dohledat je pak trivialni.

[Filip Jirsák]

Systemd a jemu podobny je bordel - a jde presne proti filozofii unixu/linuxu = delat jednu vec a delat ji poradne. … Klasicky rc scripty jsou podle me na serveru nejlepsi.

Shell je možná navržen, aby dělal jednu věc a dělal ji pořádně, ale spouštění systémových služeb to není. Klasické RC skripty jsou spíš ukázka toho, k čemu všemu se dá shell zneužít – celkem úspěšně zneužít, vzhledem k době, po kterou se toto řešení používá.

[little.owl]

a jde presne proti filozofii unixu/linuxu = delat jednu vec a delat ji poradne.

Jako treba Linux kernel?

[trekker.dk]

Pominu většinu aspektů, ve kterých je tohle srovnání se systemd nesmyslné, a zmíním jednom jeden: při přechodu na novější jádra - narozdíl od přechodu na tenhle novější init systém - nepřestanou fungovat staré konfigurace.

[Foo Bar]

Mám pocit, že jste vynechal ten jeden důležitý aspekt, na který little.owl narážel a to, že Linuxové jádro není mikrokernel.

[little.owl]

Argumentacni straw man jak vysity.

Pokud si to prectete znovu trikrat, pomalu, snad pochopite, ze nesrovnavam kernel se systemd, ani neresim zpetnou kompatibilitu cehokoliv, ale zajimam se jestli tedy samotny monoliticky Linux kernel naplnuje tu opevovanou "filozofii unixu".

[trekker.dk]

nesrovnavam kernel se systemd

...ve vlákně, které se zabývá systemd.

jestli tedy samotny monoliticky Linux kernel

On ten "monolitický" kernel má docela dost modulů. A taky má členění na jednotlivé subsystémy, které fungují dost nezávisle na sobě (a dají se - minimálně při překladu - vypnout, když něco nepotřebujete.)

[little.owl]

...ve vlákně, které se zabývá systemd.

Nahore borci resi zvukovky ... co takhle zacit srovnavat zvukovy mixer a systemd ....

On ten "monolitický" kernel má docela dost modulů. A taky má členění na jednotlivé subsystémy, které fungují dost nezávisle na sobě (a dají se - minimálně při překladu - vypnout, když něco nepotřebujete.)

Videl jste zdrojove kody systemd? Modularni architektura, vystupem je 70+ binarek, cast nemusi byt vyuzivana a instalovana. Namatkou:

/usr/bin/bootctl
/usr/bin/hostnamectl
/usr/bin/journalctl
/usr/bin/kernel-install
/usr/bin/localectl
/usr/bin/loginctl
/usr/bin/machinectl
/usr/bin/systemctl
/usr/bin/systemd-analyze
/usr/bin/systemd-ask-password
/usr/bin/systemd-cat
/usr/bin/systemd-cgls
/usr/bin/systemd-cgtop
/usr/bin/systemd-coredumpctl
/usr/bin/systemd-delta
/usr/bin/systemd-detect-virt
/usr/bin/systemd-inhibit
/usr/bin/systemd-machine-id-setup
/usr/bin/systemd-notify
/usr/bin/systemd-nspawn
/usr/bin/systemd-run
/usr/bin/systemd-stdio-bridge
/usr/bin/systemd-tmpfiles
/usr/bin/systemd-tty-ask-password-agent
/usr/bin/timedatectl
....

To pro vas monolit horsi nez kernel?

Jeden z nejpopularnejsich programu je BusyBox, ktery jde take proti te "filozofii unixu". Proc? Neni to spatny pristup, ale neni to ani dogma a v rade pripadu je to rozumna volba.

[wtf]

proc? protoze nekdo od stolu rozhodl ze staticke linkovani je spatne a silou protlacil do upstreamu.

[little.owl]

To myslite silou vyvojare sveho projektu?

[wtf]

ne. to myslim silou korporatniho security greater good doera.

[wtf]

a je potreba si pripomenout, ze mezitim byt adminem byly krusne doby nez busybox zacal byt dostatecne uplny...

[Sešívaný]

Videl jste zdrojove kody systemd? Modularni architektura, vystupem je 70+ binarek, cast nemusi byt vyuzivana a instalovana.

Asi tak nějak. Někdy mi přijde, že někteří kritici systemd nikdy nevyzkoušeli a neviděli. Na netu se všude píše, že je to monolitický moloch, tak je potřeba to opakovat. systemd rozhodně není méně modulární než Linux.

[Pavel]

Skvele. Prosim o vysvetleni jak zkompilovat systemd bez journalu. Hledal jsem v dokumentaci, na webu, psal jsem vyvojarum. Ani jedno nevedlo k vysledku.

[marvn]

mozna proto, ze to nejde. journal je jednou ze 3 povinych soucasti a chvile googlovani by tobe i vyvojarum usetrila dost casu ;)

[Pavel]

Jo, coz presne podporuje tvrzeni, ze systemd je monolit.

[David Jaša]

Když ty démonické (tedy nepříkazové a neknihovní ) binárky mezi sebou mají tvrdé závislosti, tak o jaké že modularitě je řeč? Jó kdyby měly mezi sebou nějaké rozhraní, to by byla jiná, ale tím pádem by taky spousta z těch binárek přestala být ospravedlnitelná, protože jejich staré alternativy by se ukázaly jako vhodnější, nebo by se ukázalo, že systemd-init vlastně nepotřebují.

[little.owl]

Posledni reakce - ze jste to vy a ze jsem vas prispevek minul - uz to nectu vse - nestabilni interfacy mezi moduly nevylucuji modularitu, i kdyz castecne popiraji jeji smysl.

[pasky]

Samozřejmě si mezi sebou jednotlivé komponenty systemd povídají skrze dokumentovaná a stabilní rozhraní:

http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/

Řada z nich je i postupně reimplementována, třeba logind (který lze brát jako nástupce consolekitu).

[wtf]

"Those who do not understand Unix are condemned to reinvent it, poorly."

-- Henry Spencer

... LINUX Linux Is Not UniX

[frdrx]

Nesmysl. Systemd do Unixu filozoficky zapadá velmi dobře.

[coques]

Zapadá asi tak ako Pamela Anderson do čínskej štvrti.

[frdrx]

Důvod?

[wtf]

uz mu z toho asi je.e jak kdyz cinan zapadne do pamely

[Pavel]

Protoze je to monolit. Nebo snad muzu z neho odstranit journal? Ne? A jak vubec souvisi init system a logovani? Nijak. Proto je systemd monoliticka sracka.

[martin]

ty jsi vskutku diskuzni gigant! ta argumentace! ta logika! :D

btw. pokud chces vedet, jak spolu souvisi management demonu a logovani, tak na internetu o tom pisou. hledani uz necham na tobe ;)

[pasky]

Tu diskuzi na ctte celkem zvědavě sleduji již nějakou dobu (spíše kvůli pozorování toho procesu; sám jsem došel k názoru, že žádná z voleb není zásadně špatná a vůbec nejméně sympatičtí jsou mi zapřisáhlí ideologičtí odpůrci ať už systemd nebo upstartu; naopak mne potěšily poměrně detailní technické analýzy členů ctte, kteří to vzali celkem zodpovědně - asi ten systemd nakonec sám vyzkouším, až budu příště rebootovat notebook :).

Tahle zpráva mi přijde poněkud předčasná:

- Hlasování stále není uzavřeno (i když změny hlasů mi už přijdou nepravděpodobné) - Důležitější: Mnoho lidí již řeklo, že hodlají iniciovat na toto téma tzv. General Resolution (GR), neboli v zásadě referendum v rámci projektu. To pak bude mít před tímto rozhodnutím prioritu. Jak dopadne mi není vůbec jasné.

K předchozímu: Ian Jackson se skutečně extrémně naštval, protože předseda komise Bdale Garbee vyvolal "bez diskuse" hlasování. Na druhou stranu to od Bdaleho nebylo zcela nerozumné, Ian se totiž už předtím nechal slyšet, že do každého hlasování o init systému zamíchá i otázku o tom, jak které balíky mohou záviset na init systému - tahle iniciativa doteď každé hlasování a diskuzi výrazně komplikovala a již neúnosně prodlužovala, navíc mnoho lidí (i členů CTTE) si myslí, že by o tomhle ctte z různých důvodů vůbec rozhodovat neměla, nebo nezávisle na volbě init systému.

Ian tedy svým způsobem zneužíval ten proces jedním směrem, a mělo-li se v konečném čase dojít k rozumnému výsledku, musel ho Bdale zneužít opačným směrem. Pokud by to ostatním vadili, mohli Bdaleho hlasování odmítnout, to však z osmi členů komise udělali pouze dva.

[David Heidelberg]

moc pěkně popsáno :)

Co se týká hlasování bez diskuze:

a) aspoň mě přišlo, že informace že se ta volba blíží byla k dispozici už hodně dávno (tak 2 měsíce dopředu? nevím jistě)

b) ono je někdy potřeba trochu zatlačit, aby se něco rozhodlo. Někteří lidi mají prostě takovou tu sabotovací taktiku, nedělat nic a protahovat celý postup, dokud se na ně nezatlačí (aneb podobný příběh řešení některých bugů)

[Hans1024]

a) tohle bylo totiz uz treti hlasovani, a oznameno nebylo

b) to mi nebezpecne zavani diktaturou, ale debian je demokracie, se vsemi vyhodami a nevyhodami

[wtf]

demokracie jako v irsku... hlasovat se bude tolikrat, dokud vysledek nevyjde podle ocekavani.

[pasky]

(Aby to bylo cteno ve spravne perspektive - predchozi hlasovani byla zrusena vicemene na popud priznivcu upstartu; rozlozeni hlasu bylo jasne uz na zacatku.)

[Foo Bar]

Nevím, proč se tak řeší hlasování bez diskuze... Jednak už se diskutovalo tolik, že další diskuze nad hlasovacím lístkem by nic nepřinesla (tady stojím za Bdalem) a jednak to Constitution povoluje:

6.3.1:

A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two.

[Pali]

a) tych navrhov na hlasovanie bolo za posledny mesiac niekolko, ale hlasovania skoncili tak, ze o tom budu este diskutovat. a v zasade bdale nezahrnul do posledneho hlasovania moznost ci baliky mozu zavisiet na konkretnom init alebo nie. takze svojim sposobom toto hlasovanie nebolo dopredu ohlasene.

[Foo Bar]

Opět ... proč by mělo být?

[Pali]

Minimalne pre to ak to nejakym clenom ctte vadi ci chyba. Takto sa ti ludia rozumne nedohodnutu... Ale to uz je asi ich problem.

[Foo Bar]

Osobně bych byl taky radši, aby se podobně definitivní zprávičky psaly až ve chvíli, kdy se špinavé prádlo vypere.

A odkazovat na nějaké kecy lidí, co s Debianem nemají nic společného, není přiliš produktivní. Bohužel poslat email dneska dokáže každý idiot.

[Foo Bar]

Já bych naopak dodal, že Debian Constitution v 6.3.5 říká:

No detailed design work.

The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums.

The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere.

A můj pocit je, že ten Ianův návrh byla vlastně nová policy, což je mimo jurisdikci tech-ctte. A osobně doufám, že jeho úlet s ultimátem (buď budete hlasovat pro moje návrhy nebo jdu okamžitě podpořit libovolnou GR) byl jenom výsledek aktuální emoce a nikoli něco, co by doopravdy šel udělat.

[little.owl]

Ian me prekvapil a zklamal, chova se jak maly fracek. Uz byl cas ten cirkus ukoncit, byt fakt ze se veci resi verejne ocenuji.

[trekker.dk]

Čtěte: je proti rozhodnutí, se kterým já (tj. předřečník) souhlasím.

[little.owl]

Vubec ne, v tom ze se systemd nesouhlasi nevidim zadny problem.

Náš administrátor shledal tento komentář závadným.

Vulgarity

Zobrazit komentář

[pavlix]

--> www.novinky.cz

[little.owl]

zalez, pokrytecka spino.

Klid.

debian nepouzivas,

A to vite jak?

pracujes pro RH

Ne.

takze tvoje postoje jsou trochu biased :/

Subjektivni,jako kazdeho.

[Jiří J.]

Asi se jen snaží zabránit monopolu systemd, jak jen může. Koneckonců systemd/upstart/openrc/etc. není technická volba, ale politická. Jen si to nikdo nechce přiznat. Pokud by to byla jen technická záležitost, nebylo by kolem toho tolik povyku.

[little.owl]

Asi se jen snaží zabránit monopolu systemd, jak jen může.

Tak mel zacit pracovat pred lety na podobne pouzitelne alternative. I kdyz on spise ne, viz. jeho napady jak "vylepsit" systemd - koulel jsem ocima - jak znasilnit SIGSTOP (LP mu slusne vysvetlil proc rozhodne ne) ci aplikovat pozadavky na maintainer scripts na systemd unity (odmitli debianni maintaineri systemd).

není technická volba, ale politická

To je sakra z podstatne casti technicka volba.

[wtf]

Me Ian jen utvrdil v tom, ze Debian Stable ma jeste sanci... pokud teda on vyrdzi dyl nez ... -dlouhy seznam-

[sid]

Ked tak citam ten mailing list, je tam celkom dobra zbierka magorov... A zjavne im tam chyba nejaky diktator ala Linus ktory by celu ich debatu z ktorej 99.9% je absolutne sa opakujuci sum bez nejakej pridanej hodntoy utal uz tak po 20 sprave. Dost dobre nechapem, ze to niekto z vedenia nechal zajst takto daleko. (cisto moj pocit, ze Ian Jackson tomu momentalne tiez momentalne nepridava, chova sa ako 5 rocne decko ktoremu zobrali hracku)

[David Heidelberg]

který init systém asi používá Linus? :D (aneb jak nenechat flame umřít)

[sid]

kedze pouziva Fedora tak asi systemd. Ak teda este nepresie zase inde.

[little.owl]

Tak Linus, s ohledem na to, ze vi co spravuje, pouziva OpenBSD provozovane ve VirtualBox na Windows.

[Hans1024]

Jestli se vam tolik libi diktatura, je spousta jinych distribuci, ktere vam jiste budou vyhovovat.

[Hans1024]

(To mela byt odpoved na prispevek nade mnou)

[sid]

nejedna sa o diktaturu ale o to, ze comu pomoze to ked sa k nejakej technickej veci bude vyjadrovat hocikto? Napada ma taky dobry primer z jednej knihy, ktory ilustroval, ze aj velka vzorka je na nic ked sa jedna o konretnu velicinu. Takze tu je : cinania chceli zistit velkost cisarovho nosa tak nechali sa k tomu vyjadrit vsetkych ludi v cine a urobili priemer. Krasny priklad zapojenia vsetkych ale ma nieco vysledok spolocne s realitou? Takisto ked zo 100 ludi realne 10 chape vsetky zakutia init a na zaklade toho sa snazia najst najlepsie riesenie (nech je ake chce) ma to byt prehlusene 90 ostatnymi ktori o tom vedia hovno a rozhoduju sa akurat na zaklade osobnych preferencii?. Co to ma spolocne s demokraciou? Sledujem, ze okrem skveleho OS debian vyvinul aj celkom kvalitny byrokraciu:)

[Hans1024]

Ale to je podstata demokracie, ze lidi muzou kecat do vseho a je jenom na jejich svedomi, jak dukladne si to nastuduji. Ze to muze byt nevyhodou vidime treba na nasem statu. Ale to, ze si myslim, ze bych se v 99% pripadu rozhodnul lepe nez drtiva vetsina spoluobcanu, jeste neznamena ze ze sebe udelam diktatora a budu rozhodoat za ne.

[sid]

demokracia predsa neznamena, ze kazdy sa ma vzdy vyjadrovak k vsetkemu (prakticky vzate). Ked poletite lietadlom tak si vyberiete. a) to ktore zostavil tym inzinierov ktory mal nejakych sefov b) to u ktoreho sa pri kazdej suciastke urobilo hlasovanie vsetkych ludi

a vas primer o nastudovani je uplne mimo pretoze predpokladate, ze kazdy je schopny pochopit vsetko. Takze dam vam dve nejake teorie napr. z teoretickej fyziky vedla seba a vy budete hlasovat ktora je asi spravna, urcite si to nastudujute... Ak nie ste matematicky genius tak dost dobre si to neviem predstavit, o com potom budete hlasovat?

[Hans1024]

Letadlo neni demokracie, stejne jako ruzne komercni distribuce, narozdil od Debianu, ktery je komunitnim projektem.

Demokracie, ktera je dnes obvykle praktikovana, je neprima - lidi si danou vec nenastuduji, ale zvoli jako sveho zastupce nekoho, o kom veri, ze si danou vec nastuduje. Je otazka nazoru, jestli je to spravne. Ja si napriklad myslim, ze by obcane meli mit moznost vyvolat referendum.

Primer k vedecke teorii neni zrovna idealni, protoze v pripade initu ma kazdy nejake vyhody a nevyhody, a neexistuje "ten jedinny spravny". Navic vedecke teorie se obvykle daji overit opakovatelnym experimentem.

[sid]

Mate v tom chaos a nekonzistenciu. Najprv pisete, ze ludia sa mozu k hocicomu vyjadrovat. Potom nemozu. Aj ked to vztiahnem na debian (ak ste mysleli iba ten)tak ste vy osobne schopny sa yjadrit k hocikakej technickej otazke? Od kernelu, cez init po akceleraciu grafiky? A mysliet si nieco si nastudujete ked vam to niekto znaly predzvyka o ocese je cisto romanticka predstava bohuzial vzdialena realite.

[Hans1024]

Jaka nekonzistence? V prime demokracii lide mohou hlasovat o vsem, v neprime nemohou. Ja sem spise pro tu primou. Vy asi ne.

Debiani vyvojari kombinuji neprimou demokracii (CTTE) s primou (muzou prehlasovat CTTE). Muzou hlasovat o vsem, o cem je v Debianu treba rozhodnout a nemuze to vyresit jeden konkretni maintainer.

Tedy "Od kernelu, cez init po akceleraciu grafiky" to sice ano, ale predpokladam jenom v mire "jake kernely budeme podporovat", "jaky init bude default" a "bude default Xorg, nebo Wayland".

[Foo Bar]

Možná byste mohl začít tím, že si alespoň přečtete Debian Constitution než budete pokračovat v radách, jak bychom to v tom Debianu měli dělat.

[Hans1024]

Ja se vam rozhodne nesnazim radit, jestli jste to tak pochopil, tak se omlouvam. Snazil jsem se jenom vysvetlit co povazuju za demokracii.

[sid]

Ja vam nechcem ak to tak chapete tak to chapete zle. Co si debian zvoli je jeho vec. Narazal som iba ten proces plus kopec osobnych utok, jesitnosti a urazenosti. Ak sa vam to zda konstruktivny sposob riesenia problemu nic proti tomu nemam. To ze mne nie dufam v ziadnom debian constituion nie je. Takze za mna menej paragrafouv a viac rozumu.

[sid]

Tusim co slovo to chyba. Takze nabuduce uz zasadne neodpisovat z tabletu

[Hans1024]

No jakym zpusobem se mezi sebou bavi, to je vec druha. Ja vas ale pochopil tak, ze by podle vas bylo nejlepsi tento problem vyresit tak, ze by byla jedna osoba, ktera by o vsem rozhodla (jako Linus), s cimz nesouhlasim.

[Foo Bar]

Ještě jedna poznámka - to, že je Debian komunitní, neznamená, že o něm může rozhodovat každý, kdo má díru na přední straně a umí s ní vydávat hlasité zvuky. Čímž na druhou stranu neříkám, že by vývojáři měli na uživatele kašlat, ale jsou to především Debian vývojáři (a DM), kteří do projektu investují svůj čas (a mnohdy i peníze), a proto jsou to především oni, kdo by měli určovat směřování projektu. Mechanismy k tomu, jak to dělat jsou nastavené poměrně dobře, ale nikterak nesouvisí s demokracii pojmutou jako: "ať do toho kecají úplně všichni".

[Hans1024]

Ja jsem rozhodne nechtel, aby o debianu mohl rozhodovat kazdy, ja jsem jen obhajoval, ze vyvojari muzou prehlasovat CTTE. (Ve svem primeru jsem "obcany" myslel prave vyvojare)

[Heron]

Mě by zajímalo, jak Debian zajistí běh na jiných jádrech než jen Linux.

[Hans1024]

Pouzitim jinych initu... Samozrejme, kdyby pouzili cokoli jineho nez systemd, tak dany problem vubec nemusi resit.

[David Heidelberg]

On to někdo používá? Sice vím, že to debian nabízí, ale zajímalo by mě, kolik lidí to seriózně využívá :)

K tématu - buď pro ne-linuxy nechají klasický init nebo hádám že upstart.

[Honza Jaroš]

On upstart běží na něčem jiném než na Linuxu? Pokud se nepletu, z hodnocených variant je možno zvolit buď ponechání stávajícího initu, nebo OpenRC. Upstart je stejně jako systemd čistě linuxová záležitost.

[David Heidelberg]

Máš pravdu. Já si myslel, že je to kompatibilní. Tak potom už jen to OpenRC. To je ještě něco přijatelného.

[Foo Bar]

Bylo by fajn, kdybyste nešířil bludy, když nevíte... Už jsem to tady jednou vyvracel v poslední diskuzi.

[Honza Jaroš]

Bylo by fajn, kdybyste se vyjadřoval méně útočně a radši dal odkaz na tu diskusi. Svoje dřívější informace jsem si před odesláním příspěvku ověřoval a nenarazil jsem na nic, co by s tím bylo v rozporu.

[Foo Bar]

Upstart booting on kFreeBSD

[Foo Bar]

Abych byl přesný, je to asi šestý odkaz v Google, když zadáte "upstart kfreebsd"...

[Honza Jaroš]

Problém je v tom, že tento dotaz jsem nezadal, hledal jsem seznam podporovaných systémů. Všude byl jen linux, včetně oficiálních stránek (viz níže).

[David Heidelberg]

úspěch, tak před cca 24 dny se to někomu povedlo nabootovat. Aspoň že getty jim naskočí

[Honza Jaroš]

Děkuji, to je lepší. V mailistech jsem opravdu nehledal a i na oficiálních stránkách je jako vyžadovaná závislost Linux 2.6.24 nebo novější. Pokud se pracuje na portování jinam, tím lépe.

V každém případě stále platí to, co jsem psal výše: doporučuji v diskusích méně obviňování z šíření bludů, lhaní a podobně a více konstruktivního tónu. Působí to lépe a dělá to méně zlé krve.

[Foo Bar]

Možná už jsem trochu jumpy, sleduju tu tech-ctte diskuzi už trochu moc dlouho, tak se Vám omlouvám za příkrý tón. A to zrovna v tomhle případě ani upstart vůbec neprosazuju.

Slibuju, že jestli někdo napíše něco o tom, že Steve by neměl hlasovat nebo by Ian nebo Bdale měli být zbaveni funkce, tak si něco o debilech budu jenom myslet a zdržím se komentáře...

[Honza Jaroš]

[Heron]

Nevím, kdo to používá, ale když jsem přecházel na Debian, jako pro mě relativně neznámý systém, tak přímo na webu měli napsáno, že pro běh na serveru doporučují právě kFreeBSD.

K tématu - buď pro ne-linuxy nechají klasický init nebo hádám že upstart.

Ano, proč dělat věci jednoduše, když to jde složitě.

[David Heidelberg]

bože proč? aspoň dle letmého pohledu na něco jako "benchmark" to nedává moc smysl

[Heron]

Tak mě třeba zlákalo ZFS. Nakonec jsem se našel v BTRFS, ale byl to jeden z důvodů. Potom je to firewall (takový Juniper je uvnitř bsd). A taky jako usnadnění přechodu na FreeBSD samotné.

Benchmarky, a už vůbec ne "benchmarky" nejsou to nejdůležitější.

[Foo Bar]

Potom je to firewall (takový Juniper je uvnitř bsd).

A máte opravdu pocit, že klasické pf je to, co je v Juniperu?

[David Heidelberg]

ZFSonLinux by mělo být v dnešních dnech v pohodě, ale BTRFS mi taky momentálně přijde přívětivější. Firewall určitě (ale ten SW Juniperu mi zrovna moc super nepřipadá, sice mají pěkné stroje).

Ohledně usnadnění přechodu - nevím jestli bych to upřednostňoval oproti full-experience na linuxu.

Co se týká benchmarků na Phoronixu, ty jsou samozřejmě diskutabilní, ale zrovna tenhle konkrétní mluví jasně.

[Heron]

Co se týká benchmarků na Phoronixu, ty jsou samozřejmě diskutabilní, ale zrovna tenhle konkrétní mluví jasně.

Hovoří jasně ale o čem. Když budu mít dvě disková pole, je lepší to co má 500MB/s, nebo to, co má 250MB/s? Dá se o tom rozhodnout? Podle účelu, že jo. Pokud bude mít první pole 100IOPSů a druhé 10 tisíc, tak dám DB na to druhé. Bude to mnohem rychlejí. Pokud by to bylo diskové pole na image dvd disků, tak se hodí to první. A co když najednou zjistím, že to druhé pole je sestaveno jako 20 disků v RAID0? Sice vyhrálo, ale data se tam moc dlouho neohřejou.

Udělat vypovídající benchmark především vyžaduje znalost situace, kterou měřím. A porovnat dva systémy podle benchmarků vyžaduje znalost nasazení toho systému. Systém, který bude sice pomalejší, ale bude reagovat v každém okamžiku stále stejně rychle, bude pro některá nasazení výhodnější, než celkově rychlejší systém, který má ale "sezoní" výkyvy.

Phoronix měří sice dobře, ale celkem nesmyslné veličiny.

[Foo Bar]

Nevím, kdo to používá, ale když jsem přecházel na Debian, jako pro mě relativně neznámý systém, tak přímo na webu měli napsáno, že pro běh na serveru doporučují právě kFreeBSD.

Tak to vidím spíš na nějaké nepochopení, než na oficiální doporučení na straně Debianu.

[Sešívaný]

Někdo napíše kompatibilní knihovnu stejně jako v případě sysinit, který taky není sám od sebe multiplatformní? Asi to nebude v tomto případě jednoduché, ale kde je vůle...

[Punny]

Tohle dopadne tak, ze se vytvori forky s upstartem, initem a openrc :D
Osobne systemd na debianu vidim nerad, ale me stve i grub2 :D
Punny

[pta]

Jenze Grub2 muzes ve vetsine pripadu vymenit za jiny bootloader jako Lilo nebo puvodni Grub aniz by se ti neco rozsypalo. To u systemd nelze a imho to byl od zacatku i umysl (nekompatibilita, zavislosti).

[Josef Kufner]

Debian má ještě stále balíčky s Grub verze 1 – grub-legacy.

[marvn]

proc by to neslo? ted muzes mit debian s (aspon) 4ma ruznyma initama, co se zmeni tim, ze/pokud bude systemd default?

[j]

Tak si predstav (trebas) ze soucasti tyhle srajdy je... trebas ... udev. A prave kvuli integraci do systemd bylo rozbito to, co leta sice "politicky nekorektne" ale fungovalo. Je otazkou par tydnu, nez udev nebude schopen bez systemd fungovat vubec. Pokud z toho debian udela default, jen se to zhorsi => spousta systemove kritickych veci ti bez toho proste nebude fungovat => v realu nebudes mit na vyber vubec nic.

[marvn]

Je otazkou par tydnu, nez udev nebude schopen bez systemd fungovat vubec

citation needed

[kralyk z abclinuxu]

Jenze Grub2 muzes ve vetsine pripadu vymenit za jiny bootloader jako Lilo nebo puvodni Grub aniz by se ti neco rozsypalo.

Syslinux.

Používám všude a naprostá spokojenost.

[Vantomas]

Já nechápu proč je proti systemd takový odpor.

Myslím, že úplně původní záměr pro vznik systemd bylo sjednocení init systémů napříč distribucemi, aby vývoj nástrojů pro konfiguraci init systémů byl jednodušší a aby pro aplikace existovalo nějaké sjednocené rozhraní pro zjišťování zda nějaká služba běží apod.

To, že se to celé zvrtlo a vznikl celkem velký "moloch", který ale opět řeší problémy, které se dříve nikdy neřešily je možná dobře, protože se ty problémy před kterými dříve každý zavíral oči konečně vyřeší.

Příkladem uvedu třeba takový Webmin který při konfiguraci initu (zakázání nebo povolení nějaké služby) musel řešit tu něco jinak pro Redhat, tu něco úplně jinak pro Debian, tu zase něco jinak pro Suse. Jako další příklad uvedu spouštění daemonů routovacích protokolů z balíku Quagga, jsou tam nějaké deamony zebra a ospfd, na Debianu se buď všechny tyto protokoly, které jsou uvedené v /etc/default/quagga spouští buď hromadně přes "/etc/init.d/quagga start" nebo ručně a jednotlivě přes "/etc/init.d/quagga start zebra" a "/etc/init.d/quagga start ospfd", ale v RH-like mají pro jednotlivé protokoly samotné init skripty /etc/rc.d/zebra a /etc/rc.d/ospfd.

Samozřejmě onen problém s "jeden init skript" vs. "několik init skriptů" by mohl klidně nastat i ve světě systemd, ale možná to bude na všech distribucích stejné, protože takový .service soubor by měl dodávat samotný vývojář a ne až distributor (ten by ho měl maximálně patchovat kvůli odlišným cestám třeba).

Co mě se týče, je mi úplně jedno jestli init systém bude takový moloch, že bude záviset na dbus, je mi úplně jedno jestli se služby budou řídit pomocí spouštění skriptu "/etc/init.d/apache stop" nebo pomocí "systemctl stop apache.service", které ve skutečnosti akorát pošle event na dbus... On totiž na ten dbus může poslat event sám samotný apache, že chce spustit nějaký fastcgi server a nemusí se to řešit ručně v init skriptu Apache, na každé distribuci jinak.

Stejně tak je dobře to, že se taky konečně bude jednat o nástroj kterému není ukraden stav procesu. Třeba z takového Gentoo si moc dobře pamatuji jak skvěle funguje "/etc/init.d/apache2 status". Asi tak, že když existuje pid soubor, tak běží! Stejně tak moc dobře znám jak funguje hlídání procesu když z nějakého důvodu havaruje, prostě zhebne a dokud nepřijde admin, tak neběží! Přitom proč proces nezkusit spustit znova, beztak první věc co admin dělá je to, že proces spustí, aby nebyly omezeny jím nabízené služby a pak teprve ladí co a proč se to stalo.

Když se na to člověk podívá kolem a kolem, není problém v samotném systemd, ale v onom sjednocení, které automaticky znamená sebrání svobody nad způsobem initu, protože jinak by k žádnému sjednocení nikdy nedošlo.

[Honza Jaroš]

Myslím, že úplně původní záměr pro vznik systemd bylo sjednocení init systémů napříč distribucemi, aby vývoj nástrojů pro konfiguraci init systémů byl jednodušší a aby pro aplikace existovalo nějaké sjednocené rozhraní pro zjišťování zda nějaká služba běží apod.

Ehm...

[chrono]

Problém je, že systemd funguje len na Linuxe, takže Debian aj bude musieť udržiavať aj iný init systém (a je otázne, čo sa má stať s programami, ktoré bez systemd nebudú fungovať).

[Bedňa]

To sa dá riešiť medzivrstvou, alebo sa len napíše fake-systemd čo bude smerovať do /dev/null, ono aj taká závislosť Gnome na systemd je nepotrebná.

[frdrx]

Šmarjá, zaprvé, proč by kdokoli chtěl používat cokoli jiného než Linux, a zadruhé, stejně nikdo nic jiného než Linux nepoužívá.

[Pavel]

Trololo . Proc by kdokoli chtel pouzivat cokoli jineho nez Windows. Ty svoje Linuxy muzete zrovna zahodit

[frdrx]

Bavíme se o Debianu a jeho jádrech!

[trekker.dk]

Bavíme se o počítačích a jejich operačních systémech!

Stejná logika.

[frdrx]

Ne. Kdybys uměl číst, viděl bys, že řeč byla o Debianu a jeho jádrech.

[pavlix]

Byla by přece chyba si myslet, že k open source patří i možnost volby. Trochu mi přijde, že někteří zapomínají na to, že linux byl takřka neznámým minoritním systémem a jak se nadávalo na cokoli nestandardního a nekompatibilního.

[frdrx]

Střílíš do prázdna. Řekni mi prosímtě pro koho je dobrá možnost volby jádra v Debianu a kdo jí využívá.

[j]

Kdo by pouzival linux, kdyz tu sou widle ... ze ...

[frdrx]

Widle jsou nejlepší jádro pro Debian, jasně...

[pavlix]

Řekni mi prosímtě pro koho je dobrá možnost volby jádra v Debianu a kdo jí využívá.

Máš pravdu, že Debian je vhodnější jako komoditní systém než na nějaké open source hrátky a pro komoditní systém je už v tuhle chvíli systemd nejlepší možnou volbou díky jeho nasazení v komerčních distribucích.

Pak ovšem nastává otázka, proč tam ta možnost volby vůbec vznikla.

[frdrx]

Systemd je nejlepší volbou, protože má nejlepší návrh, užitečný featury a protože ho využívají důležité aplikace, což je důvod proč se tak prosazuje. Jeho přijetí za default v Debianu sice přináší nějaké komplikace pro udržování alternativních jader v Debianu, která stejně nikdo nepoužívá, ale žádnou "možnost volby" to nijak neomezuje.

[Vantomas]

Trochu naivně doufám v to, že až se tady systemd trochu zabydlí, že se z něj stane trochu standard právě v tom smyslu jak aplikace k němu přistupují (hlášení stavu), jak k němu přistupují systémové nástroje, vývojáři aplikací apod. a že začnou vznikat vzájemně kompatibilní alternativy, kdy si každý zase začne dělat něco jinak, ale v základu to bude stále stejně funkční: syntax .service filů, ovládání procesů přes dbus, skutečné hlídání stavu procesu...

[frdrx]

Pokud bude mít někdo důvod takové alternativy vytvářet, tak jistě vzniknou, možná i pro FreeBSD aj.

[pavlix]

Systemd je nejlepší volbou, protože má nejlepší návrh, užitečný featury a protože ho využívají důležité aplikace, což je důvod proč se tak prosazuje.

Podle mě je pro Debian nejdůležitější mít service manager, na kterém budou hákovat jiní a který bude podporován upstreamem aplikací. Jak se k tomu ten service manager dostane, je zajímavé leda do hospodských diskuzí.

[frdrx]

To je systemd, ne?

[pavlix]

A o čem se tu asi bavíme?

[frdrx]

To já jen tak pro jistotu...

[Drom]

Pro mě!

[kavol]

Stejně tak je dobře to, že se taky konečně bude jednat o nástroj kterému není ukraden stav procesu. Třeba z takového Gentoo si moc dobře pamatuji jak skvěle funguje "/etc/init.d/apache2 status". Asi tak, že když existuje pid soubor, tak běží!

a jak myslíš, že funguje v systemd? - jakože když ti systemctl status řekne, že je active, tak to zaručuje, že je schopen vyřídit http request? - ha ha ...

Stejně tak moc dobře znám jak funguje hlídání procesu když z nějakého důvodu havaruje, prostě zhebne a dokud nepřijde admin, tak neběží! Přitom proč proces nezkusit spustit znova, beztak první věc co admin dělá je to, že proces spustí, aby nebyly omezeny jím nabízené služby a pak teprve ladí co a proč se to stalo.

a protože je admin debil a neumí si nainstalovat něco na monitoring, tak to musíme narvat do initsystému a všem, i těm, co žádného apache nepouští ...

[David Heidelberg]

Stejně tak je dobře to, že se taky konečně bude jednat o nástroj kterému není ukraden stav procesu. Třeba z takového Gentoo si moc dobře pamatuji jak skvěle funguje "/etc/init.d/apache2 status". Asi tak, že když existuje pid soubor, tak běží!

a jak myslíš, že funguje v systemd? - jakože když ti systemctl status řekne, že je active, tak to zaručuje, že je schopen vyřídit http request? - ha ha ...

# systemctl status nginx
nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib64/systemd/system/nginx.service; enabled)
   Active: active (running) since Tue 2014-02-11 00:35:30 CET; 1s ago
  Process: 2493 ExecStop=/bin/kill -QUIT $MAINPID (code=exited, status=0/SUCCESS)
  Process: 2500 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
  Process: 2497 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
 Main PID: 2501 (nginx)
   CGroup: /system.slice/nginx.service
           ├─2501 nginx: master process /usr/sbin/nginx
           ├─2502 nginx: worker process
           └─2503 nginx: worker process

Feb 11 00:35:30 hostname nginx[2497]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Feb 11 00:35:30 hostname nginx[2497]: nginx: configuration file /etc/nginx/nginx.conf test is successful
Feb 11 00:35:30 hostname systemd[1]: Started The nginx HTTP and reverse proxy server.

že by byla odpověď ano?

[dustin]

OK, je to trochu víc než existence pid souboru, nicméně jediná informace o aktuálním stavu o aktuálním stavu nginxu je to active "running", vše ostatní jsou informace o průběhu startování, snímané zvenku nginxu. Nějaký status poskytnutý přímo nginxem tam nevidím.

[little.owl]

Systemd nabizi pro tyto ucely sd_notify() a nevim jak nginx, ale treba Apache to podporuje, viz zde a to je vice nez PID soubor.

[kavol]

uff, nezlob se, ale na čtení zdrojáků apache teď opravdu nemám, můžeš nám to přetlumočit, umí to něco víc oproti tomu, co bych pochopil z té man stránky?

- pokud ne, tak bych řekl, že mi to o skutečné funkčnosti serveru taky nicmoc navíc neřekne ...

[little.owl]

Slo mi o to, ze systemd nabizi nastroje, aby tvrzeni

nicméně jediná informace o aktuálním stavu o aktuálním stavu nginxu je to active "running", vše ostatní jsou informace o průběhu startování,

nebyla pravda a je to celkem jednoduse implementovatelne. Onen Apache vraci pres systemctrl obsah promenne STATUS, ktera zobrazuje vnitrni data ziskana pres ap_get_sload(). Tusim, ze to implementovali lide dokonce od vas z Brna.

[kavol]

ok, takže to jsou jen informace, které lze triviálně získat jinak, a nijak to nesouvisí s tím problémem, kterým jsem to načal, tedy že to nevypovídá nic o skutečné funkčnosti démona ...

[little.owl]

Jenze to je jina otazka, ktera az tolik nesouvisi se systemd. Systemd jen umoznuje naintegrovat monitoring lepe, dat uzivateli urcity stupen kontroly a to generickym zpusobem, coz je zasadni a od systemd bych necekal zatim vice.

Detekce musi byt soucasti designu aplikace. Ja pouzivam, odhlednuli od HW monitoringu, napr. (a) pasivni sledovani - ruzne countery a timery - vim, treba ze zpracovavam v prumeru X framu ci packetu za sekundu, doba dekodovani ci rendereringu je X ms, zpozdeni na vystupu Y ms, thread Z je spusten minimalne kazdych 200ms, jak casto se posilaji zpravy z jadra A do B etc. Kazda promenna ma min/max/avg hodnotu a pokud se zacne nejak lisit, asi se neco deje. (b) aktivni testovani funkcnosti - treba periodicky vkladany synteticky frame, packet (ci treba http request) a analyza cele cesty zpracovani.

[kavol]

Jenze to je jina otazka,

ano, ale s tou jsme začali, tak jsem se jen ujišťoval, že objížďka, kterou jste to s kolegou vzali, nemění nic na tom, co jsem výše říkal já

ktera az tolik nesouvisi se systemd.

zatím

jinak dovoluju si připomenout, že jsem výše reagoval na "aby nebyly omezeny jím nabízené služby", tedy právě tu "skutečnou funkčnost démona"

Systemd jen umoznuje naintegrovat monitoring lepe,

lépe než co?

dat uzivateli urcity stupen kontroly a to generickym zpusobem,

výše uvedený příklad, jestli ho správně chápu, tedy vůbec není generický

zbytečně jsem se prve zaleknul, nepodíval jsem se, že ten soubor má jen pár řádků a to podstatné je vlastně jen:

rv = sd_notifyf(0, "READY=1\n"
                   "STATUS=Total requests: %lu; Idle/Busy workers %d/%d;"
                   "Requests/sec: %.3g; Bytes served/sec: %sB/sec\n",
                   sload.access_count, sload.idle, sload.busy,
                   ((float) sload.access_count) / (float) up_time, bps);

hm, no tak sorry, ale to dává nulovou informaci o zdraví démona, a ještě navrch to dává smysl jen pro Apache

[little.owl]

lépe než co?

Lepe nez soucasne inity s kdysi vyznamou pozici v Linuxu*.

---------
*) Musim stanovit podminky tak abych vyradil OpenRC, ktere sice plno veci "ma", ale nic poradne .

výše uvedený příklad, jestli ho správně chápu, tedy vůbec není generický

Genericky je stabilni interface.

hm, no tak sorry, ale to dává nulovou informaci o zdraví démona

Nulovou - urcite ne. Dobre udelany monitovaci framework mi neselhal za posledni roky snad nikdy (pokud neslo do kytek cele CPU - treba nestabilni napajeni - ci cele jadro OS - a pak to resil HW watchdog ci host controller).

, a ještě navrch to dává smysl jen pro Apache

Ano, ale take se vam to zobrazi jenom u statusu Apache . Jiste, tohle je server specific, jiny server vam bude zobrazovat jiny status - jak to jeho autori implementuji.

[kavol]

lépe než co?

Lepe nez soucasne inity s kdysi vyznamou pozici v Linuxu*.

aha; no ale ty si toto za cíl nekladou

myslel jsem to spíše tak, že má-li se něco takového zavádět, nemusí to být nutně součástí systemd (ehm, tedy: naopak by to součástí systemd být nemělo)

když se teď pracuje na kdbus, co takhle nad tím nadefinovat, jak by měli démoni informovat o svém stavu, přičemž to bude moci poslouchat kdokoli? - proč tady máme mít zase jenom bazmek specifický pro systemd?

*) Musim stanovit podminky tak abych vyradil OpenRC, ktere sice plno veci "ma", ale nic poradne .

Genericky je stabilni interface.

který je ovšem z hlediska monitoringu k ničemu, viz níže ...

hm, no tak sorry, ale to dává nulovou informaci o zdraví démona

Nulovou - urcite ne. Dobre udelany monitovaci framework mi neselhal za posledni roky snad nikdy (pokud neslo do kytek cele CPU - treba nestabilni napajeni - ci cele jadro OS - a pak to resil HW watchdog ci host controller).

nerozumím, jak z toho, že ti něco léta funguje, vyvozuješ, že výše uvedené dává nenulovou informaci o zdraví démona (pomineme-li to, že to dává informaci, že část posílající tyto zprávy žije, což je uživateli, který se nemůže dobouchat na svůj oblíbený web, k ničemu)

Ano, ale take se vam to zobrazi jenom u statusu Apache . Jiste, tohle je server specific, jiny server vam bude zobrazovat jiny status - jak to jeho autori implementuji.

no, takže jinými slovy říkáš, že to není univerzálně (tedy "genericky") použitelné - na druhém konci musí sedět opice s křišťálovou koulí, která vyčte, co tím chtěl Apache říci a jestli je potřeba ho restartovat nebo něco, a vedle toho jiná opice, která to samé bude dělat pro sshd, a vedle jiná opice pro xdm, atd. atd., namísto aby stačila jedna opice bez křišťálové koule, která bude reagovat na zprávy z nějakého setu sjednoceného přes všechny služby (které se mají monitorovat)

hmpf ...

[little.owl]

Za prve, nahore si stezuji, ze u statusu je jen "running" a nic co by indikovalo cinnost od vlastni sluzby. Ja k tomu dodavam, ze systemd umoznuje pres genericky stabilni interface nastavit promennou STATUS, ktera preda dalsi uzitecne udaje, ktere se pak zobrazi. Je na programatorech aplikace vratit neco, co umoznuje adminovi posoudit v jakem stavu sluzba je a naivne predpokladam, ze programatori postupne vyjdou adminum vstric.

Za druhe, rikam, ze systemd nema moc moznosti posoudit, jak na tom aplikace je - tady se shodnem, krome zakladnich primitiv jako je SW watchdog (promenna WATCHDOG) a resenim je, ze aplikace sebe sama bude kontrolovat a pri pripadnem selhani nastavi nejaky error kod (promenna ERRNO), pripadne se ukonci. Na adminovi bude zalezet, jestli watchdog ci kod v systemd unite nejak vyuzije, moznosti tam jsou.

Interface, vcetne zminenych promennych, je genericky, lze ho implementovat u vsech sluzeb, a bude bez vetsich uprav chodit ve vsech distribucich pouzivajicich systemd, coz krome Ubuntu jsou dnes vsechny vyznamne distribuce. Vidim v tom pokrok.

Konec, diskuze o systemd me uz *********.

[kavol]

Za prve, nahore si stezuji, ze u statusu je jen "running" a nic co by indikovalo cinnost od vlastni sluzby.

pardon, trošku jsem se v tomto vlákně ztratil, mělo se to rozdělit do dvou větví, pak bych hned viděl, kde se bavíme o dostupnosti služby, a kde o poníkách

- ano, beru, pokud má někdo takový požadavek, budiž mu přáno jeho naplnění

Ja k tomu dodavam, ze systemd umoznuje pres genericky stabilni interface nastavit promennou STATUS, ktera preda dalsi uzitecne udaje, ktere se pak zobrazi. Je na programatorech aplikace vratit neco, co umoznuje adminovi posoudit v jakem stavu sluzba je a naivne predpokladam, ze programatori postupne vyjdou adminum vstric.

trošinku offtopic, ale nad tímto odstavečkem jsem se musel zasmát - argumentem Billa Nothinghama proti zachování kompatibility výstupu service blabla status bylo, že si stejně každá služba vypisuje co chce[*], a že takhle po novu je to krásně přehledné a jednotné ... načež je obhajována možnost, aby si každá služba psala co chce, príma

[*] skutečnost je taková, že na RHEL6 devět služeb z deseti používá stejný formát, a značná část z toho zbytku jsou speciality, kde třeba žádný démon neběží

Interface, vcetne zminenych promennych, je genericky, lze ho implementovat u vsech sluzeb, a bude bez vetsich uprav chodit ve vsech distribucich pouzivajicich systemd, coz krome Ubuntu jsou dnes vsechny vyznamne distribuce. Vidim v tom pokrok.

já v tom vidím krok do prdele, jak jsem již naznačil výše

pokud "ho lze implementovat", tzn. zatím implementován není (až na ten Apache? ), stále platí otázka, proč by měli autoři do programů drátovat natvrdo něco takového pro systemd, a nikoli například výše navržené poslání zprávy, kterou si systemd může odchytit?

Konec, diskuze o systemd me uz *********.

tohle bych si měl zabookmarkovat a při nejbližší příležitosti (hádám max tři dny) použít

[Honza Jaroš]

Kavol ale nepsal o kontrole běhu procesu, nýbrž o schopnosti vyřídit HTTP request. Tipuju, že dobře ví, proč to formuloval zrovna takto...

(např.)

[sid]

Ano. Ma uzasnu schopnost argumentacie. Zapliest tam vec co s tym vobec nesuvisi. Je to o kontrole processu a nie kompletom monitoringu aplikacie. Urcite ten rozdiel chape ale ked sa jedna o systemd tak racionalita ide stranou.

[Honza Jaroš]

No tak zaseknutý program osobně považuju za stejný problém jako program spadlý. V obou případech nedělá to, co má.

[Honza Jaroš]

(on jeho předřečník si taky vybral dost blbý příklad, jednak zrovna Apache s tímhle měl problémy, jednak se to v Gentoo chová jinak, než dotyčný tvrdí)

[sid]

Suhlasim. Ale stale je to miesanie hrusiek a jablk dokopy. Ak test na to ci nieco je stale aktivne v zmysle existencie procesu spociva v nejakom vytvarani a mazani suboru s pid a realnej kontrole ci naozaj process je ready tak neviem ci tam vidim zlepsenie len ja. Preto najpriek zaveru ktory je pravdivy tam vidim cisto manipulativne narabanie s faktami.

[Honza Jaroš]

V kontextu toho, co psal jeho předřečník, nesouhlasím. Ale to už je věc osobního názoru.

[Vantomas]

Není to tak jednoduché, do doby systemd totiž nešlo stav procesu zjišťovat jinak než existencí pid souboru, maximálně existencí procesu s daným PID a to protože to vlastně nikdo neřešil, že by to taky šlo nějak jinak. Ano, některé procesy mají vlastní nástroj co se připojí na nějaký jejich socket a je schopný zjistit zda to pracuje tak jak má, to šlo do init skriptů implementovat a mohlo se s tím nějak pracovat, jenže kolik distribucí ve svých init skriptech toto používalo? Debian u MySQL má po mysqld hned mysqlcheck, jenže v Redhatu je to taky tak? Přitom by stačilo mít už od vývojáře MySQL připravený .service file, kde bude, že po spuštění se má zkontrolovat integrita tabulek....

Systemd právě řeší ty problémy co nikdy nikdo neřešil. Díky tomu totiž bude možné aby proces sám od sebe notifikoval svůj stav směrem k init systému, který to má pak připravené pro vyřvání do zbytku světa - třeba že monitorovací systém může na tyto eventy nějak reagovat.

[pavlix]

Není to tak jednoduché, do doby systemd totiž nešlo stav procesu zjišťovat jinak než existencí pid souboru

Snad nechceš tvrdit, že byl systemd prvním správcem služeb? Pokud vím, tak nebyl ani prvním, který byl schopný sledovat forkované procesy.

Systemd právě řeší ty problémy co nikdy nikdo neřešil.

Takhle nějak se to bude učit ve školách, stejně jako že Edison vynalezl žárovku.

Díky tomu totiž bude možné aby proces sám od sebe notifikoval svůj stav směrem k init systému

Ve skutečnosti je to směrem ke správci služeb. Že je v systemd správce totožný s initem, je jen implementační detail. Jsi si jistý, že před systemd nikdo nikdy nepoužíval komunikaci mezi službou a správcem služby? Jak to funguje v Upstartu? Jak to funguje v launchd? Jak ve Windows?

Zásluha systemd je především v některých v popularizaci (aka vnucení) a v některých technických detailech. Ale hádám, že už moje děti se budou ve škole učit, že Linus Torvalds napsal jádro a Lennart Poettering k němu dodal zbytek operačního systému :D.

[Vantomas]

Asi tak, není to ani první ani poslední init systém, který takové věci řeší. Ale nemíchejme to s launchd nebo s Windows, protože tam se jim alespoň trochu otevřeli oči a přiznali si, že něco takového je potřeba. Na Linuxu máme upstart, který používá akorát Ubuntu, měli jsme tu nějaké daemon-tools, které používá jenom djbdns. V tomto případě je systemd opravdu první, protože se dokázal natlačit do více jak jedné distribuce.

[kavol]

již odpověděl pavlix, jen doplním ...

Debian u MySQL má po mysqld hned mysqlcheck, jenže v Redhatu je to taky tak?

testuje se to pomocí mysqladmin

[kavol]

Ano. Ma uzasnu schopnost argumentacie. Zapliest tam vec co s tym vobec nesuvisi. Je to o kontrole processu a nie kompletom monitoringu aplikacie.

souvisí, jak již je diskutováno okolo, a jak ještě rozeberu níže

Urcite ten rozdiel chape ale ked sa jedna o systemd tak racionalita ide stranou.

já to vidím naopak, snažil jsem se vnést trošku racionality do toho blábolu od zakladatele threadu

jednak, jak už jsem odpovídal kolegovi, jde v tomto konkrétním případě o bug, a nikoli vlastnost initsystému

a jednak je toto uměle vykonstruovaný příklad, jako admina mě uživatelé bombardují nadávkami "nejde ti web!" a nikoli "neběží ti proces `cat /var/run/httpd/pid`!"

takže pokud bych řešil monitoring, tak ho postavím nad dostupností služby, a nikoli nad výstupem "service httpd status"

[sid]

plne rozumiem tomu co sa znazite povedat a z pohladu uzivatela mate 100% pravdu. Stale ale mi pride, ze riesenie pre vylepsenie sledovania sluzieb (ci cez systemd alebo hocico ine) ma svoje miesto. Ok, pre embedded veci sa da pouzit uspesne watchdog priamo napr cez aplikaciu, pre vami spominany web dajme tomu Zenoss ale myslim si, ze je tu dost priestoru kde netreba nejaku extra logicku pre monitoring a staci hocico robusnejsie ako pid. Cisto prakticky je toto riesenie (pid) naozaj tak debilne, ze ma fascinuje ta miera iracionality s ktorou sa obhajuje ako cosi naozaj uzasne tj. myslim spojenie shell + pid.

[kavol]

spojení shell+pid za nijak úžasné nepovažuju, jsou dokonce případy, kdy nemá smysl vůbec (a se kterými má/měl systemd velký problém, jak se tu také diskutovalo již před delší dobou, např.), pouze chladím nadšení věrozvěstů systemd a pokouším se některé věci uvést na pravou míru (zcela jistě není designovou vlastností initskriptů vracet špatný status)

[Honza Jaroš]

Jak už tady bylo řečeno vícekrát, i jiné inity než systemd jsou schopné využít cgroups pro kontrolu běhu. Mě pro změnu fascinuje, jak to někteří ignorují...

[little.owl]

Ale zadny jiny init je nema usite na miru svym potrebam od kernel vyvojaru, jako systemd!

[Honza Jaroš]

No a? Což si (opět!) přečíst, na co reaguju?

[trekker.dk]

K čemu přesně je dobrá kontrola procesu, když ten proces nedělá to, co má?

[kavol]

Kavol ale nepsal o kontrole běhu procesu, nýbrž o schopnosti vyřídit HTTP request. Tipuju, že dobře ví, proč to formuloval zrovna takto...

ano, děkuji ti náčelníku ...

zrovna slowloris jsem na mysli neměl, nicméně řekl bych, že většina CVEček, co mi v poslední době prošlo rukama, byly nějaký denial-of-service, takže si dovedu představit, že zákazníka zajímá spíše jestli služba funguje, a ne jestli to adminovi hlásí, že běží (kromě toho příklad výše je jasným porušením standardu, případ mrtvého démona a existujícího PIDfile má dokonce nadefinovaný zvláštní chybový kód ve statusu, tzn. šlo o bug a ne o featuru, tedy je nefér používat to pro tvrzení, že initskripty jsou konkrétně v tomto oproti systemd principiálně špatné)

[Honza Jaroš]

Třeba z takového Gentoo si moc dobře pamatuji jak skvěle funguje "/etc/init.d/apache2 status". Asi tak, že když existuje pid soubor, tak běží!

Nedalo mi to a vyzkoušel jsem:

# /etc/init.d/apache2 status
 * status: started
# killall apache2
# /etc/init.d/apache2 status
 * status: crashed

Dělám něco špatně?

[Vantomas]

Taky jsem psal "jak si pamatuji", dnes již Gentoo nepoužívám a nejspíš už celý problém vyřešily, tudíž si to s dnešní dobou nezaslouží srovnání.

Ale mám tedy stále jednu starou instalaci živou, tak ukáži jak to fungovalo:

Goliath ~ # /etc/init.d/apache2 status
 * status:  started
Goliath ~ # ps ax|grep -i apache
 5222 pts/0    S+     0:00 grep --colour=auto -i apache
 6642 ?        Ss     0:00 /usr/sbin/apache2 -D DEFAULT_VHOST -D PHP4CGI -D DAV -D DAV_FS -D SVN -D SVN_AUTHZ -D SSL -D NAGIOS -D PERL -D PHP5 -D SSL_DEFAULT_VHOST -D PROXY -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -k start
 6644 ?        S      0:00 /usr/sbin/apache2 -D DEFAULT_VHOST -D PHP4CGI -D DAV -D DAV_FS -D SVN -D SVN_AUTHZ -D SSL -D NAGIOS -D PERL -D PHP5 -D SSL_DEFAULT_VHOST -D PROXY -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -k start
24978 ?        Sl     0:48 /usr/sbin/apache2 -D DEFAULT_VHOST -D PHP4CGI -D DAV -D DAV_FS -D SVN -D SVN_AUTHZ -D SSL -D NAGIOS -D PERL -D PHP5 -D SSL_DEFAULT_VHOST -D PROXY -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -k start
25020 ?        Sl     0:47 /usr/sbin/apache2 -D DEFAULT_VHOST -D PHP4CGI -D DAV -D DAV_FS -D SVN -D SVN_AUTHZ -D SSL -D NAGIOS -D PERL -D PHP5 -D SSL_DEFAULT_VHOST -D PROXY -d /usr/lib/apache2 -f /etc/apache2/httpd.conf -k start
Goliath ~ # killall -9 apache2
Goliath ~ # /etc/init.d/apache2 status
 * status:  started
Goliath ~ # ps ax|grep -i apache
 5253 pts/0    S+     0:00 grep --colour=auto -i apache
Goliath ~ # /etc/init.d/apache2 start
 * WARNING:  apache2 has already been started.
Goliath ~ # /etc/init.d/apache2 stop
 * Stopping apache2 ...
httpd (pid 6642?) not running                                                                                                                                              [ ok ]
Goliath ~ # /etc/init.d/apache2 start
 * Starting apache2 ...                                                                                                                                                    [ ok ]
Goliath ~ #

[pavlix]

Jako pravdou je, že v tomto ohledu systemd částečně neschopnost maintainerů a vývojářů řeší. Nicméně pokud by se problém týkal jen jednoho balíku, je to trochu kanón na vrabce.

[Honza Jaroš]

Jen pro představu - jakou verzi OpenRC a Apache tam máte? Popř. co máte v /usr/portage/metadata/timestamp? Docela by mě zajímalo, kdy se to změnilo, koukám do GITového repozitáře OpenRC a v posledních letech změny kolem detekce spadlých služeb nějak nemůžu najít...

[Vantomas]

Hmm, je to starší než jsem doufal, hlavně jsem myslel, že už tam bude OpenRC, ale není...

www-servers/apache-2.2.14-r1

Goliath ~ # cat /usr/portage/metadata/timestamp Tue May 17 11:36:39 UTC 2011

[Honza Jaroš]

hlavně jsem myslel, že už tam bude OpenRC, ale není...

Což ovšem, vzhledem k známé vazbě OpenRC a Gentoo, docela dost mění původní vyznění. Inu inu...

[Vantomas]

Jak jsem psal, "tak jak si pamatuji", pokud si to dnes dokáže poradit jinak než za pomocí pid souboru, tak všechna čest, skripty v Debianu ani v roce 2014 toto nedokáží!

[pavlix]

V kontextu toho, že Gentoo používá service manager nad cgroups, jsou tvé pokusy o srovnání systemd a bash skriptů více než komické. Navíc bys měl srovnávat vlastnosti, nikoliv implementační detaily. Pokud vím, tak ten problém s Apache je vcelku triviálně řešitelný i za pomocí pouhého pidfile.

[SPM]

Na monitorování procesů slouží monitorovací nástroj (stejně jako na další řadu věcí na tom serveru) a ne init systém. Pokud proces spadne, notifikuje to admina a ten to vyřeší třeba tak, aby to nepadalo vůbec. Pokud bude init systém jak blbec dokola restartovat proces po každých 5 minutách co spadne, tak si toho monitorovací nástroj pravděpodobně nevšimne a na serveru zůstane padající služba.

[little.owl]

Ten blbec systemd vam umoznuje pocet restartu nastavit a a v pripade selhani vam to umi hezky nareportovat.

[SPM]

Ten počet restartů se nastavuje v nějakém čase? Resp. když proces nastartuje, pár minut poběží a pak spadne, tak to udělá co? Jinak report je zase něco, co nechci, aby dělal init systém. Prostředí, kde každá věc na serveru (init, mdadm, ...) reportuje problémy separátně na vlastní triko je při větším počtu systéů neudržitelná...

[pavlix]

Prostředí, kde každá věc na serveru (init, mdadm, ...) reportuje problémy separátně na vlastní triko je při větším počtu systéů neudržitelná...

Jako bych slyšel Lennarta při návrhu journald ;).

[Heron]

, ehm

[little.owl]

Myslim, ze jsem vas mistifikoval, pocet restartu asi nelze nastavit, omluva. Tam byla o tom diskuze a myslel jsem ze to imlementovali. Mam fixne nastaven casovy interval a restartuji jen podle navratoveho kodu/signalu (RestartPreventExitStatus, SuccessExitStatus). Pak cast vasi vytky dava smysl, i kdyz to jde rozumne osetrit ve vetsine pripadech.

[Vantomas]

Tedy osobně bych si monitorovací nástroj pořídil na to, že to zkouší ten Apache na HTTP odezvy, případně zkouší i přímo nějaké URL a hlídá jestli je problém, ale to když sám od sebe padne proces a že se znovu spustí očekávám od init systému a nikoliv od admina s ručním zásahem (klidně třeba až po několika hodinách). Koneckonců init systém taky znova spustí killnutý getty

Mě v produkci v 99% případů proces lehl kvůli nějakému specifickému požadavku nebo shodě náhod a v takových případech když se proces znovu spustí, tak vše bez problémů funguje dál - dokud nenastanou opět dané podmínky. Je mi milejší aby se proces zkusil znovu spustit a v případě, že bude stále havarovat, tak mu dát tři pokusy a dost, než aby hned po prvním problémů byl proces mrtvý a čekal na admina a pro uživatele se to tvářilo nedostupné po delší dobu.

[SPM]

Já mám v monitorovacích nástrojích obojí :) Ono není na škodu mít těch informací co nejvíc (už i kvůli tomu, že pak s ohledem na čas zpět se dá zjistit kdy, co, jak zlobilo).

[lima]

Mě v produkci v 99% případů proces lehl kvůli nějakému specifickému požadavku nebo shodě náhod a v takových případech když se proces znovu spustí, tak vše bez problémů funguje dál - dokud nenastanou opět dané podmínky. Je mi milejší aby se proces zkusil znovu spustit a v případě, že bude stále havarovat, tak mu dát tři pokusy a dost, než aby hned po prvním problémů byl proces mrtvý a čekal na admina a pro uživatele se to tvářilo nedostupné po delší dobu.

Jenze pad procesu muze mit i vazne priciny a restartovanim se tvarit, ze je vlastne vsechno ok je zametani pod koberec a koledovani si o pruser. Tohle je mozna jeste ok u desktopu v kiosk modu, ale jinde je to spis projev ignoranstvi.

[little.owl]

Celkem souhlas, ja proto restartuji jen u nekterych navratovych kodu, treba u segfaultu nikoliv.

[pavlix]

Tvému komentáři rozumím, ale má zkušenost mi říká, že něco není úplně v pořádku a že možnosti v tomto případě nebudou jenom dvě a nevypadají tak, jak je popisuješ. Podle mě je potřeba reagovat nejen na pády, ale i na ošklivé věci v logu a dá se předpokládat, že systemd pády zaloguje. Na druhou stranu existuje software, který padá notoricky a administrátor s tím nic neudělá, jako třeba squid, jehož geniální vývojáři se rozhodli používat vlastní restartující supervizor, který neloguje vůbec nic.

V tomto ohledu je systemd mnohem lepší volbou, kde lze nejen sledovat logy, ale restarty je možné triviálně vypnout a zapnout, což třeba u squidu sice lze zařídit, ale ne bez vedlejších efektů.

[Foo Bar]

Zrovna nedávno jsem přemýšlel nad tím, kolik vlastních supervizorů se mohlo ušetřit, kdyby s námi byl systemd už před lety.

Jen namátkou přidám ještě: postfix (postmaster) a cyrus-imapd ({cyr_}master).

[pavlix]

Zrovna nedávno jsem přemýšlel nad tím, kolik vlastních supervizorů se mohlo ušetřit, kdyby s námi byl systemd už před lety.

Na to ti rád odpovím, bylo by jich úplně stejně. Zato kdyby se uchytil multiplatformní service manager nebo ještě lépe obecné service manager API třeba i s více implementacemi, byla by situace značně odlišná. V ideálním případě by šlo používat takový service manager bez závislosti na zadrátování do základu systému, jako tomu bylo u předchozích pokusů.

[Foo Bar]

Možná. Ale možná taky ne.

Každopádně oceňuji na systemd to, že místo tanečků okolo a přidávání supervizorů (sysvinit) nad supervizory (daemontools) do toho konečně někdo šlápnul, a pokusil se změnit zrezivělé paradigma. Kdyby djb nebyl takový svéráz a nemyslel si, že všichni ostatní jsou idioti, tak by možná už více lidí už na začátku uznalo, že měl v mnoha věcech pravdu.

[pavlix]

Na toho djb už jsem myslel několikrát, když on měl vždy tendenci věci hrozně prasit a vymykat se za každou cenu. Nebýt toho, tak se jeho myšlenky dávno do fungování linuxových distribucí propsaly. Na druhou stranu, když už ho zmiňuješ, ani on pokud vím neměl zapotřebí sloučit init a service manager.

[lertimir]

djb je Daniel J. Bernstein?

[Foo Bar]

Nebo D.J.Bem, poměrně významný sociální psycholog. Vyberte si :)

[Bedňa]

Zato kdyby se uchytil multiplatformní service manager nebo ještě lépe obecné service manager API třeba i s více implementacemi, byla by situace značně odlišná. V ideálním případě by šlo používat takový service manager bez závislosti na zadrátování do základu systému, jako tomu bylo u předchozích pokusů.

Tohoto keby sa niekto s RH chytil a vedel o tom pekne pútavo porozprávať, ale to sa asi nestane. Osobne tieto dva riadky pokladám za väčší prínos ako tisíce riadkov kódu dnešných implementácií.

[pavlix]

Otázkou je, proč by se toho měl chytat někdo z firmy, která zájem o *BSD a podobné nijak veřejně nedeklaruje. Samozřejmě se toho může chytit někdo z RH, nejspíše z vlastního zájmu, ale stejnětak se toho může chytit někdo z kterékoli jiné organizace.

[Bedňa]

Pretože je tu záujem RH niečo s tým spraviť a rozhodnutie padlo hneď na prvý návrh čo bol po ruke. Lennart to vie veľmi pekne zdôvodniť, vie o tom spraviť prednášku, napíše pekný článok o všetkých plusoch čo to prinesie. Má výhodu v tom že ako jediný rieši veci ktoré pália RH, podľa mňa ale úplne zle. Preto som položil túto otázku, či sa nenájde nikto kto by sa snažil pretlačiť riešenia bez zbytočného drátovania do základov systému, to si my napísal z duše. A pridám že drátovania aj do aplikácií.

[pavlix]

Vlak už je rozjetý, kdo chce teď nastoupit, musí dělat na systemd.

[Bedňa]

Ešte to nikto neskúsil a ty už hádžeš flintu do žita :) Čo kdbus, to by hádam ešte išlo.

[kavol]

podívej, pavlix není žádný druhý Mr. Spaceman - přijď s pár miliony dolarů na vývoj, a pak se budeme bavit, jestli má význam (jiný než hobby, viz Slackware) kutit si něco proti tomu, co kutí RH :-p

[Bedňa]

RH ešte nikto neukázal, že to ide robiť aj dobre, preto by sa hodil človek s Lennartovimi schopnosťami prezentovať svoje nápady.

[kavol]

nevím, jestli "svoje", bo co jsem pozoroval, některé typy osobností se prostě (pro společnost bohužel zásadně nevhodně) vylučují, ale v principu ano, potřebovali bychom někoho, kdo by udělal tu špinavou práci politika ...

[Bedňa]

potřebovali bychom někoho, kdo by udělal tu špinavou práci politika

Jj je škoda, že kopu dobrých nápadov zapadne len preto že sa okolo nich nespraví dostatočná propagácia.

[pavlix]

RH ešte nikto neukázal, že to ide robiť aj dobre

We are hiring!

[kralyk z abclinuxu]

Zato kdyby se uchytil multiplatformní service manager nebo ještě lépe obecné service manager API třeba i s více implementacemi, byla by situace značně odlišná. V ideálním případě by šlo používat takový service manager bez závislosti na zadrátování do základu systému, jako tomu bylo u předchozích pokusů.

Pěkný nápad. Takové rozhraní by klidně mohlo být vytesáno do kamene v rámci nějakého standardu.

Imho by to ale klidně mohlo vzniknout nějakou abstrakcí systemd, je možné, že to tak i dopadne. Ono koneckonců historicky tyhle standardy vznikaly afaik právě tímhle způsobem, totiž že se šlo směrem: jedna nebo vícero ne moc přenosných, nekompatibilních implementací → abstrakce rozhraní a standardizace → lepší přenositelnost, nahraditelnost jedné implementace jinou.

Teoreticky je možné začít tím prostředním krokem, v praxi to ale většinou imho nedopadne.

[sid]

Kludne pokracujte este chvilku a vymyslite znova OSGI

[Foo Bar]

Ehm, jde vidět, že nemáte moc zkušeností s tím být na 'on-call duty'. Já bych teda radši problém s padajícím Apache řešil ráno po snídani, a do té doby mi bude úplně jedno, že spadnul jednou ve tři v noci a supervizor jej nahodil...

[SPM]

Ať se klidně restartne. Ale když tohle řeší systemd bez přičinění monitorovacího systému, tak se o tom patrně ani nedozvím (hádám že notifikace systemd dělá něco jako že pošle mail, což mi prostě nepřijde dostatečné). Padající proces mi přijde jako velký problém a ne obvyklý (pomineme-li tedy prasárny jako squid) a tenhle postup mi přijde, že se o tom admin dost pravděpodobně ani nedozví.

[Vantomas]

Tak je to asi o tom, aby monitorovací systém vzal v potaz nějaké logy nebo eventy systemd a na základě toho sám udělal červenou vlaječku "hele admine, tady tohle bylo, tak to vyřeš".

[SPM]

To se dá, ale je to zase další věc, co se musí monitorovat navíc a je u ní velká šance chyby (zapomene se na to, regexp to nematchne). Systemd tímhle imho šahá až do moc věcí, které jinak řeší jiné nástroje a navíc tyhle překvápka dělá v defaultním nastavení - celkem nemám nic proti tomu, aby tam ta funkce byla a šla zapnout. Ale nelíbí se mi, když se mi záhem s updatem se nainstaluje něco, co začne samo od sebe dělat takové věci.

[Vantomas]

Zrovna u systemd se mi líbí právě propojení s dbus, kterým také mnoho lidí opovrhuje, jenže jak jinak se v Linuxu má nějaká informace šířit multicastem napříč procesy? Dostupnými prostředky je to teď nemožné.

No a právě přes ten dbus se pošle strukturovaná informace o tom, že nějaký proces havaroval a byl restartován a monitorovací systém celkem bez obav na to může nějak reagovat, takže bych se nebál špatných regexpů, protože to bude mít daný nějaký formát.

Díky tomu dbusu nemusí ani systemd sám od sebe řešit posílání emailových notifikací, do budoucna to nebude muset řešit ani mdadm, prostě na dbusu na dané eventy bude viset jedna společná věc, která pošle mail, udělá červenou vlaječku ve webovým rozhraní a všechno možný.

[frdrx]

No nevím jak místné je říkat, že "mnoho". Někdo pak může usoudit, že opovrhovat Dbusem je v módě a začne s tím taky.

[tomasgn]

o restart sluzby se ma - v pripade, ze je to vhodne a zadouci - postarat napriklad monitoring, a ne ze se kvuli tomu nahradi jednoduchy init bazmekem jako je systemd.

ted, kdyz se i debian chysta zahrabat do systemd hnoje, existuje jeste nejake distro, ktere tim svinstvem neni nakazene? snad uz jen slackware, a bsd systemy.

[pavlix]

Možnost volby tuším formálně zůstává i u Debianu, reálně bych dával větší Gentoo, ale docela vážně na Gentoo uvažuju o přechodu na systemd kvůli blízkosti k systémům, pro které vyvíjím.

[Foo Bar]

Vám bych doporučil před další diskuzí začít s man inittab.

Až na to, že to naneštěstí v sysvinit nebylo moc dobře použitelné, protože do té definice na jeden řádek (id:runlevels:action:process) se všechno potřebné pro supervizi procesu nevejde. Každopádně i ten jednoduchý init řeší přesně restart služeb.

[tomasgn]

vase doporuceni nepotrebuji.

nicmene stale nevim, proc by se mel system zaplevelit nejakym molochovitym systemd.

[martin]

tak stejne by ses mohl ptat, proc ne? kdyz uz ho mas zapleveleny mnohonasobne vetsim molochem - jadrem

[tomasgn]

toto prirovnani je ponekud mimo. kdyz nebude jadro (ktere lze do jiste miry orezat), nebude system. pak uz systemd nepotrebujem vubec.

[Foo Bar]

Aha, takže podle Vás by init neměl dělat supervizi procesů, ale vlastně Vám vůbec nevadí, že stávající sysvinit ji umí (ale dost blbě)...

Možná byste si měl trochu urovnat, co vlastně chcete.

[pavlix]

Podle mě obojí tak nějak dává smysl. Jak sloučení initu a supervizoru, tak oddělený init s velmi limitovanou supervizí nad plnohodnotným správcem služeb. Popravdě řečeno jsem zatím neslyšel technické argumenty, které by některou z těch možností vyřadily ze hry.

Osobně vidím v samostatném správci služeb tu výhodu, že takových správců může běžět více. A tím myslím jak více instancí totožného správce (například kvůli testování), tak i více různých správců na systémové úrovni (rovněž kvůli testování nebo i kvůli postupnému přechodu). Možná jsem vedle a zahrnutí initu v tomto ohledu nijak nepřekáží, ale k tomu by bylo zapotřebí právě těch technických a nikoliv politických argumentů.

Mně osobně se na flexibilních řešeních umožňujících více stejných i různých správců paralelně i hierarchicky běžících v rámci jednoho systému líbí to, že to přímo vyzývá k vyzkoušení několika řešení a následnému vybrání toho technicky nejvhodnějšího. A nejen to, podle mě by to i více lákalo ke spolupráci a nadefinování nějakého společného standardu.

To, že sysvinit zvládá limitovanou supervizi, nevidím jako překážku. Vadilo by mi až to, kdyby se používala na něco víc než spouštění plnohodnotného supervizoru. Stejně tak bych se vůbec nezlobil, kdyby bylo možné provozovat openrc nad systemd a systemd nad openrc.

[Foo Bar]

A tak s Tebou nediskutuju :), diskutuju s předřečníkem, který si stěžoval, že init nemá (nesmí) dělat supervizi.

Já zase v jednom supervizoru, který je dobře implementovaný v PID 1, vidím tu výhodu, že jej lidi (upstream, distribuce) začne masivněji používat, a poněkud to zlepší stav Linuxových distribucí.

[pavlix]

diskutuju s předřečníkem, který si stěžoval, že init nemá (nesmí) dělat supervizi.

Jde o to, zda to interpretuješ tak, že ji nesmí dělat vůbec, nebo že se o ni má starat v rámci možností co nejméně. Ne vždy se člověk vyjádří úplně tak, jak by chtěl.

Já zase v jednom supervizoru, který je dobře implementovaný v PID 1, vidím tu výhodu, že jej lidi (upstream, distribuce) začne masivněji používat, a poněkud to zlepší stav Linuxových distribucí.

Já jsem spíše zastáncem prosazování projektů na základě technických vlastností než politického sjednocování čistě za účelem sjednocování. Ale jak už jsem psal výše, mně nevadí nutně to sloučení s initem, pokud to není jediná možnost. Spíš bych rád viděl, jak si můžu toho správce služeb samostatně testovat a spouštět nad/pod jiným správcem služeb.

[David Jaša]

no systemd-in-systemd je celkem oblíbená hračka jeho vývojářů (ty jejich pseudokontejnery nebo systemd coby session manager), tudíž by systemd-in-openrc (nebo obráceně) nemuselo být úplně nereálné.

[pavlix]

Vím, že se to za určitých okolností umí poskládat. Ale je velký rozdíl mezi legem a puzzle, že ;).

[Foo Bar]

A je (zatím) vymalováno :)

Bug#727708: call for votes on default Linux init system for jessie:

Per 6.3.2, I use my casting vote to choose D as the winner.

Therefore, the resolution reads:

We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be systemd.

Should the project pass a General Resolution before the release of "jessie" asserting a "position statement about issues of the day" on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision.

Bdale

V následujících dnech očekávám asi tak deset až dvacet návrhů na GR :).

[Stanislav Brabec]

Když openSUSE zavedlo systemd, ještě dlouho podporovalo přepnutí do sysvinit.

Ukázalo se, že řešit dvě nezávislé sady chyb je mnohem horší, než řešit jednu sadu chyb.

A navíc, když se v openSUSE 12.3 podpora sysvinit rozbila, tak si toho, že se systém po přepnutí do sysvinit ani nenabootuje, nikdo nevšiml celého půl roku. Systemd hateři asi měli moc práce na fórech, a na návrat k sysvinitu nenašli čas.

[David Heidelberg]

Tohle mi připomělo přednášku Keitha Packarda o DRI3 a jak se zajišťuje odstranění zastaralého kódu. ;) Rozbije se to a po pár letech se navrhne odstatranění :D a teprve potom lidi začnou řvát......

[kralyk z abclinuxu]

Systemd hateři asi měli moc práce na fórech, a na návrat k sysvinitu nenašli čas.

+1 tím se zhruba dá shrnout pracovní náplň systemd-haterů...

[kavol]

ironií je, že někteří systemd-hateři na systemd odvedli dosti práce, nejspíše mnohem více, než někteří zde přítomní systemd-loveři :-p

(a další se stali systemd-hatery poté, co na něm začali pracovat)

[kralyk z abclinuxu]

No, ať už mají k systemd vztah jakýkoli, diskuse nejspíš netapetují. (Osobně už se do dalšího flejmu na tohle téma taky radši pouštět nebudu.) Někdo by za tím měl udělat čáru, nebo bude "Jaký init systém chcete?" horší téma než Agáta Hanychová...

[little.owl]

Bude jine tema: Wayland.

[little.owl]

A navíc, když se v openSUSE 12.3 podpora sysvinit rozbila, tak si toho, že se systém po přepnutí do sysvinit ani nenabootuje, nikdo nevšiml celého půl roku.

Ale no tak, pozor! Mne je jasne, ze Michal Kubecek to vedel, ale jen si rikal "Dobre vam tak, ted vam to s tim systemd nandam!"

[Bedňa]

To mi pripomenulo, prečo je systemd jediný init čo padá, pretože Lenartovci hejtujú proti hejterom systemd

[Andrej]

Nechápu, jak je možné, že vůbec někdo rozhoduje o „jednom jediném správném“ init systému, na který se má hned povinně přejít. Stačí se podívat do nedávné historie a poučit se z distribucí, které (narozdíl od Debianu) dávají aspoň trochu smysl.

Není důvod mít za každou cenu pouze jeden init systém. Jak nás učí nedávná historie, ArchLinux měl víc než rok dva init systémy. Uživatel mohl mít zároveň nainstalovaný systemd i původní sysvinit skripty. Pro systemd existovaly doplňky, které zajistily bezproblémovou kompatibilitu s původními init skripty — pro starší balíčky, které ještě neměly unit soubory. Při každém startu systému si mohl uživatel jednoduše kernelovým optionem zvolit, zda chce nabootovat pomocí sysvinit nebo systemd. Později mohl (mohl, ale nemusel) zvolit systemd za implicitní init systém.

Pokud vím, nikdo nestanovil předem, že systemd bude nakonec jediným init systémem. Šlo o dlouhodobý proces. Všechno se postupně vyvíjelo. Během cca roku všechny balíčky s démony postupně získaly kromě init skriptů navíc taky unit soubory pro systemd. Jakmile měli všichni démoni init skripty i systemd units, bylo možné (nikoliv povinné) odinstalovat zpětnou kompatibilitu pro init skripty v systemd a používat už výhradně systemd. Teprve když se systemd celkově osvědčil, po nějaké delší době bylo rozhodnuto o trvalejším začlenění systemd, tedy units se staly povinnou součástí balíčků. Teprve několik měsíců poté byla ukončena podpora pro sysvinit a s ní i povinnost poskytovat init skripty v balíčcích.

Pointa: Vše proběhlo hladce, v rámci rolling updates, žádný infarkt se nekonal a každý uživatel měl minimálně rok na přechod na systemd; mohl se sám rozhodnout, kdy přesně na systemd přejde a zda to už má v jeho případě smysl. A co je nejdůležitější — systemd velmi dlouho podporoval původní init skripty a dal se kdykoliv nezávazně vyzkoušet bez přeinstalování systému a bez zásahů nad rámec běžné instalace balíčků. Kdyby se ukázalo, že systemd je špatná volba, pravděpodobně by nakonec k jeho trvalému začlenění nedošlo.

Přechod na systemd nemusí být problém. Jenže pro Debian je všechno problém. Ze zásady.

[Foo Bar]

Jasně, protože nedávná historie systému s rolling updates, je jistě perfektním příkladem toho, jak se to má správně dělat v distribuci, která dělá release. Vy jste nám to teď ukázal!

[Andrej]

Release jsou výborný námět na exponát do Národního technického muzea. Je to takový pozůstatek z dob, kdy se něco posílalo na disketách poštou. Dnes už jsou release absurdní nesmysl, který vede k těm 32768 klíčům v OpenSSL a podobným průšvihům.

[little.owl]

Ze to tak neni zjistite v okamziku, kdy budete muset na nejaky SW davat garance.

[Foo Bar]

Poprosil bych ještě další moudro otce Fury na dnešní den. A pak se běžte seznámit s tou paní, co se jí říká realita. Až budete zodpovědný za nějaké produkční prostředí, tak to časem třeba pochopíte.

Každopádně jste mne pobavil.

[Andrej]

Buzzword „produkční prostředí“ mě pokaždé pobaví naprosto spolehlivě. Každý po něm sáhne v okamžiku, kdy nemá absolutně žádné argumenty pro svá tvrzení. Prostředím, za která jsem zodpovědný, ze zásady neříkám „produkční“, protože nemám rád módní prázdná slova bez významu. (Navíc nemám potřebu se kasat vším možným, za co (ne)zodpovídám.) Ovšem jedno vím jistě: V žádném z prostředí, za která jsem zodpovědný, nechci mít ani 32768 klíčů v OpenSSL, ani Debian, ani jiný škodlivý software, který se z principu nedá aktualizovat.

[Foo Bar]

Číslovku 32768 můžete opakovat kolikrát chcete, ale nic na tom nezmění, že distribuce s rolling updates není vhodné do prostředí, kde nechcete, aby docházelo k neřízeným regresím každý druhý týden. Nová verze software neznamená nutně méně chybová verze software.

Rolling updates jsou prima na vlastní desktop/server, kde Vám nevadí, že se věci mění pod rukama. Stable update policy, kde se do stabilních[*] verzí nehrnou automaticky nové verze, ale jen bezpečnostní a kritické opravy, má svůj smysl. Ale třeba jste jenom na takovou situaci ještě nenarazil.

P.S.: Pokud na těch prostředích, za která jste zodpovědný, máte distribuci s rolling updates, tak se jim ani "produkční" prostředí moc říkat nedá, že?

* – kde stabilní neznamená, že je to bez chyb, ale že se to chová tak nějak stejně.

[ebik]

Produkční prostředí je tady nepřesné označení pro servery, kde hodinový výpadek služby stojí víc než denní plat správce. Na takových serverech běží jen nezbytné minimum software pro zajištění příslušné služby a správy takového serveru. V takovém prostředí může platit to co v letectví: dobře zdokumentovaná velká chyba, včetně situace kdy nastává a způsobu jak ji řešit, je menší zlo, než neznámá drobná chybička.

V takovém prostředí občas potřebujete deploynout další server, a nemáte čas řešit změny v software oproti serveru který vám již běží. Zkuste si spravovat 200+ serverů a uvidíte, že naučit se jednou za 3 roky novou release (debianu) a tu postupně dávat na nové stroje, může být právě tak akorát, kolik jste ochoten za provozu řešit.

[dustin]

Úplně stejně by to mohlo být i v debianu a tipuji si, že to přesně tak dopadne. Nedovedu si představit, že po upgradu všech serverů na nový stable se jednorázově kompletně změní init proces a upravené či nedistribuční init skripty přestanou správcům fungovat.

[kavol]

Nedovedu si představit, že po upgradu všech serverů na nový stable se jednorázově kompletně změní init proces a upravené či nedistribuční init skripty přestanou správcům fungovat.

máš dosti chabou představivost, protože tak to nejspíše bude - jak jsme již viděli mnohokrát, proč mrhat třemi dny času vývojáře na nějaké pokusy o kompatibilitu a usnadnění, když si to může přeci každý admin/uživatel spravit/obejít sám; co na tom, že v důsledku to bude stát mnoho člověkolet času, z toho netriviální část bude investovat ta samá firma, ale hlavněže ušetřila čas toho vývojáře, resp. hlavněže on ušetřil čas

[dustin]

No nevím, debian používám na produkci od verze potato (2001) a takové zkušenosti s ním nemám.

[kavol]

no však taky zatím na systemd neběží

[David Jaša]

kavol asi naráží na přechod z fedory 15 na fedoru 16 (IIRC), kdy se vyhlásilo, že mapovat spouštěné sysv služeb na zapnutí systemd unit je moc složitý, tak že si mají admini projít služby a uvést jejich zapínání/vypínání sami.

[kavol]

ano, to je jeden z příkladů, děkuji za doplnění

[dustin]

Proto celou dobu mluvím o přechody mezi stable verzemi debianu. Fedora je přece úplně jiný svět s naprosto odlišnými cíly, jaký má smysl to s ní srovnávat?

[kavol]

Proto celou dobu mluvím o přechody mezi stable verzemi debianu.

nevidím podrobně do vývoje Debianu, ale pochybuju, že má sílu jít proti upstreamu

Fedora je přece úplně jiný svět s naprosto odlišnými cíly, jaký má smysl to s ní srovnávat?

nevím, o jaké konkrétní odlišnosti cílů je zde řeč, ale hlavním cílem je dělat linuxové distro, což znamená, že to má mnoho softwaru společného, a ten software se bere ve stejných upstreamech a jenom se přebaluje (byť tam může být nějaký průnik mezi množinami vývojářů)

pochopitelně, software se dá různě patchovat, nicméně jaksi není prací balíčkáře, aby vlastními patchi polovinu funkcionality dodal a druhou polovinu přepsal

v konkrétním Dejvově příkladu tedy chyběl modul systemd, který by uměl načíst/zkonvertovat starou konfiguraci - dobrá, Debian si jej může dopsat, ale není to jediná věc; uváděl jsem třeba příklad se změnou výstupu service(*), která nám rozbila skripty, a pochybuju, že si Debian bude udržovat vlastní fork, který se bude chovat konzistentně se starou verzí, už třeba jen proto, že by byl z druhé strany bit, že se to chová jinak než u ostatních

(*) pozn. nevím (a nehodlám zjišťovat, je to jen na ilustraci principu), jestli zrovna service v Debianu vůbec je

[dustin]

Zásadní rozdíl je v tom, že fedora je platforma pro testování nových technologií, kdežto debian stable je platforma pro provoz produkčních prostředí. Správci prvního testují na nové věci, kdežto správci druhého testují na co možno nejméně problémů při upgradu na další verzi. Proto taky trvá roky, než vyjde nová verze. Nedovedu si představit, že by mezi verzemi udělali tlustou čáru a řekli "vaše init skripty od další verze přestanou fungovat, předělejte si je dopředu na systemd a až po upgradu si je budete moci otestovat, zda jste se trefili". To by si zadělali na problémy hlavně sami sobě. Takže jsem přesvědčený, že přechod bude pozvolný (i třeba tak, že nové řešení bude nasazené, ale bude zpětně podporovat staré věci) a bude trvat pár let.

[kavol]

připadá mi, že se absolutně míjíme ...

Nedovedu si představit, že by mezi verzemi udělali tlustou čáru a řekli "vaše init skripty od další verze přestanou fungovat, předělejte si je dopředu na systemd a až po upgradu si je budete moci otestovat, zda jste se trefili".

ehm, Debian nelze nainstalovat v jiné verzi než stable?

To by si zadělali na problémy hlavně sami sobě. Takže jsem přesvědčený, že přechod bude pozvolný (i třeba tak, že nové řešení bude nasazené, ale bude zpětně podporovat staré věci) a bude trvat pár let.

v některých případech je ta podpora složitá až "nemožná"[*], opravdu má Debian tolik lidí/času?

[*] technicky jde ledacos, ale prakticky - viz příklad výše, opravdu by Debian chtěl, aby se věci po opatchování chovaly zásadně jinak než v ostatních distrech?

[dustin]

Jistěže se tu bavíme o (některé z budoucích) stable, která je klíčový produkt debianu. Na produkčním serveru se testing ani unstable standardně neprovozují, protože nikdy nevíš, zda se ti po apt-get upgrade nerozsypou.

[kavol]

Na produkčním serveru se testing ani unstable standardně neprovozují, protože nikdy nevíš, zda se ti po apt-get upgrade nerozsypou.

stejně tak se na produkčním serveru neupgraduje mezi releasy, protože nikdy nevíš, zda se ti to nerozsype; pokud životnost serveru přesahuje životnost distribuce, tak se upgrade nejprve otestuje mimo produkci

[dustin]

Upgrade mezi releasy se běžně dělá, samozřejmě se otestuje na jiném stroji dopředu. Ale proto je to stable, aby se nemuselo testovat každý týden a testy (a následný upgrade produkce) proběhly s minimálními problémy.

Prostě závěr je ten, že brát problémy při přechodu mezi verzemi testovací fedory jako měřítko pro problémy při přechodu mezi verzemi produkčního debianu stable je poněkud nestandardní. Víc o tom nemá smysl debatovat.

[kavol]

takovejch už tady bylo, co si mysleli, že jich se něco netýká ... já neříkám, že v Debianu to proběhne úplně stejně jako ve Fedoře, já říkám, že myslet si, že nenastanou podobné problémy vůbec, je bezbřehá naivita

[Foo Bar]

Obecně platí pravidlo, že je možné rozbít až upgrade na stable+2. Takže rozbití v tomto duchu je myslitelné až pro jessie+1, a kdo ví, co bude tou dobou.

[dustin]

Souhlas

[kavol]

ve Fedoře platí taky spousta pravidel ...

jinak takovéto pravidlo by vylučovalo (no, řekněme "nemístně komplikovalo") některé změny -

mějme konfigurák (initskript, whatever) ve verzi 1

protože verze 2 mění formát, ale funkčnost ve verzi 1+1 nesmíme rozbít, dejme do verze 2 nějaký wrapper

=> ve verzi 2 funguje konfigurák verze 1

verze 3 používá formát verze 2, ale protože ve verzi 2 funguje i verze 1, ve verzi 2+1 nesmíme tuto funkčnost rozbít, ponechme wrapper

=> ve verzi 3 funguje konfigurák verze 1

... a tak dále indukcí

[sid]

tato vasa nekonecna rada ma jednu vadu, ze ignoruje prvotny predpoklad, ze sa nieco moze zrusit/rozbit vo verzii n + 2. Tj konfigurak vo verzi 1 oznacite deprecated. Nasledne wraper bude fungovat pre verziu 2 a 3 ale nie vo verzii 4. Vy ste proste zobrali predpoklad, ze ked nieco je vo verzi 2 tak to ma byt podporovane aj v 4 atd nekonecnou radou. Ale nejako ste odignorovali prvotnu podmienku tj. konfigurak 1 musi byt podporovany minimalne do verzie 3, vy si to automaticky zvysujete a kaslete na prvotne obmedzenie.

[kavol]

ale já neupgraduju z verze 2 na verzi +2 = 4 ... já upgraduju z verze 3 na verzi +1 = 4, na 3 mi to chodilo, pokud to na 4 nechodí, není pravidlo dodrženo

kolega tvrdil, že je možné rozbít upgrade, nikoli funkcionalitu

- čemuž rozumím tak, že vývojáři nemusí zajistit, abych mohl hladce (= bez ručních oprav) upgradovat verzi 1 na verzi +2 = 3, ale musí zajistit, abych mohl hladce upgradovat z 1 na +1= 2, a potom ze 2 na +1 = 3

takovéto pravidlo pro upgrade pak může (resp. bude) mít dopad na funkcionalitu

[sid]

Aha, uz chapem co ste myslel.

[pta]

No nevím, debian používám na produkci od verze potato (2001) a takové zkušenosti s ním nemám.

To není možné, takhle dlouho bez systemd nelze fungovat ..

[Foo Bar]

systemd dnes podporuje zpětně /etc/init.d/ skripty, takže asi nějak není důvod, proč by to někdo při Debian balíčkování vypínal.

[pta]

systemd dnes podporuje zpětně /etc/init.d/ skripty

[David Jaša]

Od začátku. IIRC ve Fedoře 15 - prvním ostrém vydání distribuce se systemd - nebyl jediný démon spouštěn přes systemd nativně.

[kavol]

otázka nezní, co podporoval v minulosti, ale co bude podporovat do budoucna ...

[dustin]

Je mi celkem fuk, co nepodporoval dřív. Pro mě je důležité, aby v době nasazení do debianu stable podporoval stávající init skripty. A věřím, že si to v debianu pořádně otestují, než stable se systemd vydají. Určitě to nebude dříve, než za pár let a do té doby se může systemd docela hodně změnit.

[little.owl]

Init systemu muzete mit kolik chcete, jen to nekdo musi udrzovat.

Navic, nedejte se zmatnout medialnim obrazem - i kdyz tentokrat to bylo jak z telenovely - muj dojem byl, ze vetsina vyvojaru cekala relativne celkem v klidu a pro vetsinu z nich by se stejne nic nezmenilo, protoze jak systemd, tak upstart vetsinou podporovali - soude podle Testing.

[Foo Bar]

Trochu mi to komplikuje moje backporty, protože u věcí, které udržuju, je nedělám jen pro Debian, ale i (resp. hlavně) pro Ubuntu a dh-systemd se mi na Ubuntu precise fakt portovat nechce. Ale už jsem se s tím nějak popral - git je mocný, prostě mám bokem branch, kde jsem to vypnul.

Trochu jsou komplikovanější skripty, kde se dělala nějaká inicializace, protože se musí ten kus vyčlenit někam bokem[1]. Ale to je spíš o lenosti, a ono se to časem nějak samo uklepe (uživatelé to otestují :)).

1. Zrovna teď jsem to dělal pro cyrus-imapd-2.4.

[kavol]

Init systemu muzete mit kolik chcete, jen to nekdo musi udrzovat.

ale no tak, o tom už jsme se taky bavili asi stokrát - ono by nebylo potřeba to příliš udržovat, kdyby tomu někdo neházel klacky pod nohy, že ...

[juraj]

Já nevím co tady zase všichni fňukáte. Systemd bude výchozí, ale rozhodně to neznamená, že by debian nešel používat bez něj. Aktuálně mám debian jessie na 2 počítačích, na jednom se systemd a na druhém s init skripty. Na obou funguje bez problémů. Mě to připadá podobně hloupé, jako když se tady lidi čílí jestli má být v debianu výchozí gnome 3 nebo xfce.

[pavlix]

Já nevím co tady zase všichni fňukáte. Systemd bude výchozí, ale rozhodně to neznamená, že by debian nešel používat bez něj.

To bych poprosil písemně a podepsané pravým jménem, ať si nad to můžem za nějakou dobu sednout a zasmát se tomu.

[kavol]

taky bych se o jednu kopii přihlásil

[Foo Bar]

Otázkou je, co znamená Debian... GNOME 3 bez nějakého logind (ale např. už existuje systemd-shim) fungovat nebude.

Ale minimálně jessie se ještě sysvinit skriptů hromadně zbavovat nebude.

[pasky]

Pro upřesnění - nejen že se Debian nebude hromadně zbavovat sysvinit skriptů (to asi bude hodně pozvolný poces), ale naopak nejspíš sysvinit skripty budou pro jessie stále povinné - hlavně kvůli tomu upgrade.

Osobně si myslím, že nejschůdnější cesta bude pro maintainery alternativních init systémů v dlouhodobém měřítku prostě přidat podporu pro parsování systemd service souborů, budou-li chtít přežít v systemd based ekosystému. Jistě se najdou okrajové případy, kdy bude s podporou service souborů problém, ale nevidím důvod, proč by to nešlo technicky udělat aspoň pro 80%-90% service souborů a náklady na podporu alternativních initů tím dramaticky klesnou.

(Nevidím to ani jako kdovíjakou katastrofu, alternativy se vždy musely kompatibilitou přizpůsobit mainstreamovému řešení a čára toho mainstreamu se teď prostě překresluje, for better or worse.)

[juraj]

On existuje systemd pro bsd? Tak se debian bez něj na některých instalacích bude muset obejít. To už je jenom krok k tomu to podporovat všude.

[pavlix]

Spíš mám pocit, že se Debian velmi brzy obejde bez BSD.

[noo]

Debian je na hovno, Ubuntu je pro uživatele, Arch je nestabilní, Fedora taky a s Gentoo se nikdo srat nechce.

Člověk by z týhle diskuze skoro vydedukoval, že se na serverech začnou používat Windows.

[pavlix]

Každému, co jeho jest.

[frdrx]

Debian je sice na hovno, ale to hovno je aspoň pevný. Všechno ostatní způsobuje průjem.