Debian bude hlasovat o zachování možnosti volby init systému (diskuse)

[LLeoš]

A jéje, to zas bude nářku až to podle očekávání projde s podporou lidí, kteří tomu rozumí

[Rejpal]

Jeden prsten vládne všem, jeden jim všem káže, jeden všechny přivede, do temnoty sváže.

[hmm]

nastesti jsou ty dalsi 3 prsteny, ktere drzi elfove...

[Tonda]

A co sedmička, jo, ta se vlastně časem různě poztrácela a zbývá už jen jednomu loajální devítka :D

[omg]

to je sice hezke, ze tomu rozumi desktopari, ale systemd prinasi do klasickeho server admin workflow "efekt forkbomby". slozitost nekterych pomerne castych operaci se meni z: c=2, na (v lepsim pripade) c*n. v pripade, ze neznate detailne systemd a teprve se to ucite, tak to workflow snadno sklouzne az k exponencialni ci dokonce rekurzivne cyklicke slozitosti.

[omg]

a pokud se bavime o customizaci serveru a verifikaci pred udelenim "zaruky" na spravnost nastaveni se meni slozitost z:

krok 0 = n

krok >0 = c = 1

krok upgrade = c = 0, 1 az n

na

krok 0 = exp

krok 1 = c = 1

krok upgrade = c = 0 nebo exp

a stavi to spravce customizovaneho serveru na uroven kvalitniho programatora paralelnich aplikaci, ktery je debuguje ve strojovem kodu. napric oborem kam se podivam neznam dostatecne kvalitni OSS nastroje co usnadni debugovani/reprodukovani/opravu asynchronnich paralelnich aplikaci s latkou tak nizko, aby je dokazal pouzit i neprogramator.

[omg]

systemd je proste navrzena pro kliktko a ne pro lidi s konzoli.

kratkodoba pamet pojme v prumeru 7 +/-2 polozek.

minimalni instalace 122 unitu

pocet adresaru relevantnich pro konfiguraci >10 a to jeste pozadavky na jedine spravne formatovani unitu souboru, aby slo pouzit trivialni grep a z *c(=1) se nestalo *log(p) az *p ...

[Jiří J.]

Jakkoli jsem pro alternativy k čemukoli a třeba i útočení na systemd, aby se rozpadl na shluk knihoven (a nebyl tedy unifikovanou platformou pro Lennartovy nápady), nutit maintainery, aby dělali práci upstreamu, je opravdu mimo. Pěkně to bylo shrnuto už u původního návrhu. Souhlasím s "duchem" návrhu, ale nevěřím, že by se taková politika dodržovala. Taky to otevírá další otázky toho, co tedy balíček musí podporovat - stejně jako na "init systém" se podobná podmínka může do budoucna vztáhnout na kernel (Linux/BSD) nebo display server (X/Wayland/TaUbuntuVěc).

A to mě před dvěma lety nehorázně štvaly balíky, které závisely (Depends) na dbusu, přestože jely bez něj.

Podle mě projde Lucasova verze, protože prostě dává smysl a je více "sane", což by taky ale znamenalo, že se prakticky nic nezmění.

Kromě odkazů na mailing list se sluší uvést https://www.debian.org/vote/2014/vote_003.

[chrono]

Možno by stačilo, ak by povedali, že odteraz Debian bude podporovať len Systemd a Linux (a prestali sa tváriť, že sa nič nezmení).

[little.owl]

nutit maintainery, aby dělali práci upstreamu, je opravdu mimo.

To je asi ten hlavni nesmysl.

Dalsi kolo grotesky zacina .

[tacoberu]

Představ si to, že by sis v balíčkovači změnil jádro z LINUX na BSD, nebo na MACH... Mě by se to třeba líbilo.

[Dreit]

+1

[pavlix]

Takto to pokud vím ani nikdy nefungovalo.

[Jiří J.]

Mě taky, ale kdo udělá tu práci, aby to fungovalo? Ty? Maintaineři balíčků? Debian má tak rozsáhlé repozitáře *právě* kvůli tomu, že nemá taková omezení. Pokud by byl nějaký požadavek "musí běžet na Linux, Hurd a BSD kernelu" a nějaký upstream projekt by měl silně Linux-specific rozhraní, tak se do Debianu nejspíš ani nedostane, protože se nikomu (jako maintainerovi) nebude chtít přepisovat ten projekt.

Už ze samotné podstaty - maintainer je někdo, kdo jen "balí" upstream do .deb, nemusí to být nutně vývojář.

Co třeba dopředné inovace? Pokud někdo udělá pěkně odlehčený nativní WM (jako blackbox) nad Waylandem a nebude chtít psát tunu ošklivého kódu pro vrstvu X serveru, proč by neměl mít právo takový WM mít v Debianu?

Taková omezení opravdu mají smysl snad jen pro silně ideologické distribuce, ne pro tak univerzální projekt, jako Debian.

[Grunt]

Co třeba dopředné inovace? Pokud někdo udělá pěkně odlehčený nativní WM (jako blackbox) nad Waylandem a nebude chtít psát tunu ošklivého kódu pro vrstvu X serveru, proč by neměl mít právo takový WM mít v Debianu?

Jen tak pro zajímavost: Zde se nacházíme u stejného problému akorát ne u initsystému ale u grafického subsystému. Sám jsem zvědavý, které řešení ukáže čas jako to nejlepší.

[Grunt]

To se mi líbí. Nechcete někdo sepsat požadavek?

[hermelin]

No ac systemd nemusim tak pokud se jednou Debian rozhodl pro tuhle obludu tak by se ji mel drzet. Vybery a alternativy takove dulezite veci jako je init system muzou pak vest jenom k problemum.

Uz vidim jak pak clovek nainstaluje Debian s urcitym systemem a pak napr casem doinstaluje nejaky 3rd party balicek nebo neco z backports a system mu rekne - tento program nepodporuje vas init system. Nebo se bude neco resit v bugzille a vzniknou dotazy - a s timto init systemem sluzba startuje spravne ? apod.

Rozhodnutim pro systemd sli proti nemalemu poctu vyvojaru - meli tedy k tomu prihlizet driv. Ted uz delat podobne alibisticke kroky je jenom ke skode.

[SPM]

Stejně tak by se dalo argumentovat, že by měl být jenom jeden desktop environment / window manager, jenom jeden MTA a tak podobně... Jediný rozdíl je, že ten init systém se dotkne většího počtu lidí. Naproti tomu zase většina těch uživatelů bude stejně používat ten výchozí, takže se dá očekávat, že s ním to fungovat bude a ty problémy s alternativními inity holt budou mít na bedrech ti, co je budou používat...

[Neel]

To preci neni moc porovnatelne. Maintaineri napr. gnome balicku v debianu preci nemaji duvod starat se o nedostatky KDE softwaru a stejne je to i naopak nebo se mylim? Kdezto predstava, ze se po maintainerovi bude pozadovat, aby psal init skripty v tehle chvili, kdy se jeho distribuce a vetsina upstreamu posunula nekam dal, mi prijde jako hloupe bremeno.

[pavlix]

Možná by bylo lepší nepožadovat, aby psal initskripty, ale vyrobit nějaký generátor initskriptů z unit souborů, který by řešil 90% problému a zbytek by holt maintainer nebo uživatel musel dořešit ručně. Ale to úplně neodpovídá nátuře Debianu jakožto distribuce, která vždy směřovala k principu just works. Na Gentoo jsou takovéhle hrátky daleko přirozenější.

[Josef Kufner]

Tohle není vůbec blbý nápad. Vygenerovat initscript pro těch pár jednoduchých a častých případů by nemělo být nijak těžké.

Už jsi poslal feature request?

[pavlix]

Tohle není vůbec blbý nápad. Vygenerovat initscript pro těch pár jednoduchých a častých případů by nemělo být nijak těžké.

Bude k tomu potřeba init, který je schopný pracovat rozumně se závislostmi.

Už jsi poslal feature request?

Na Debian? Proč bych to dělal? Osobně nevidím jiný důvod používat Debian než jeho relativní stabilitu a odladěnost, tudíž používám výhradně stable a za žádných okolností nenahrazuju výchozí init. Určitě nebudu provozovat Debian/systemd bez systemd.

Na druhou stranu jsem si napsal v Pythonu primitivní konvertor do OpenRC initskriptů v době, kdy jsem si ještě myslel, že budu Gentoo používat s OpenRC.

Jenže jsem zjistil, že má OpenRC dost neohrabaný a neschopný systém závislostí, takže by s tím bylo pořád ještě pro maintainery moc práce s tím vymyslet jak tu neschopnost obejít, protože tohle skriptem rozumně řešit nelze. Až bude mít OpenRC závislosti aspoň tak schopné jako systemd, můžu to zkusit doladit, do té doby jsem víceméně vázaný na systemd.

[Josef Kufner]

Pracovat se závislostmi? Není potřeba. Aktuální SysV init v Debianu si závislosti předpočítá a pak jede tradičně podle čísílek. Ono ty závislosti jsou docela přeceňované.

Pokud z párřádkového service souboru to zvládne vygenerovat ten ošklivý init script, tak to umožní snadno udržovat stávající init i systemd, aniž by to znamenalo více práce s údržbou balíčků. Vlastně by ji to mohlo i ušetřit.

[pavlix]

Pracovat se závislostmi? Není potřeba. Aktuální SysV init v Debianu si závislosti předpočítá a pak jede tradičně podle čísílek.

Zde si docela protiřečíš. Pokud ty závislosti předpočítá, tak zjevně nějaký význam mají. Navíc závislosti vstupují do hry několika různýmy způsoby a služby napsané pro systemd s tím už jaksi počítají. Závislosti neurčují jenom pořadí a navíc se neuplatňují jenom při bootu.

Ono ty závislosti jsou docela přeceňované.

Zjevně jak přeceňované, tak i podceňované.

Pokud z párřádkového service souboru to zvládne vygenerovat ten ošklivý init script, tak to umožní snadno udržovat stávající init i systemd, aniž by to znamenalo více práce s údržbou balíčků. Vlastně by ji to mohlo i ušetřit.

Ano, to přesně jsem si myslel, než jsem se to pokusil pro Gentoo reálně implementovat. Jenže pak jsem se zasek na tom, že Gentoo initskripty prostě nemají ekvivalenty pro systemd direktivy, tudíž je problém i s relativně triviálními službami, což jaksi zabíjí hlavní motivaci, kterou bylo ušetřit maintainerům práci.

[Josef Kufner]

Tím, že se předpočítají, tak se o to už samotný init nemusí starat a o to jednodušší může být.

Představa, že by SysV initscript zvládl vše, co Systemd je značně nerealistická, ale pokud by to zvládlo ty nejpoužívanější věci, se kterými si vystačí většina tradičních démonů, tak by to ušetřilo celkem dost práce. A pokud narazí na něco, co nepůjde převést, stačí, když to oznámí.

[pavlix]

Já o voze, ty o koze. Smyslem projektu a předmětem mých úvah samozřejmě byly nejběžnější konstrukce a počítal jsem s tím, že by maintainer v případě potřeby příkaz doplnil parametry. Nehledě na to, že se jednalo o převod to Gentoo initskriptů, které závislosti už používají.

Navíc není pravda, že by skriptové řešení nemohlo podporovat běžnou funkcionalitu systemd služeb. Je potřeba jen sestavit strom závislosti pro danou externí akci (boot, shutdown, příkaz od administrátora) a postupovat na základě něj. Socketem aktivované služby by samozřejmě vyžadovaly spuštění dlouhodobě běžícího procesu. Časovačem aktivované služby by rovněž bylo nutné obsloužit běžícím procesem, ale v případě zájmu by jím mohl být třeba i cron.

Nelze ale sestavit lineární seznam služeb a spouštět je jednu podruhé, pokud člověk neobětuje funkcionalitu jako třeba Required, která může v případě selhání služby vést na zcela odlišnou posloupnost akcí než by vedl úspěšný start všech služeb.

[Josef Kufner]

Myslím, že myslíme oba totéž

Jen s tím posledním odstavcem nesouhlasím. Lineární seznam můžeš sestavit velmi snadno, neboť "required" stejnak v současném SysV initu není, takže by nikomu neměl chybět.

[pavlix]

Jen s tím posledním odstavcem nesouhlasím. Lineární seznam můžeš sestavit velmi snadno, neboť "required" stejnak v současném SysV initu není, takže by nikomu neměl chybět.

Jak bych to jen... Vždyť v tom odstavci je explicitně:

pokud člověk neobětuje funkcionalitu jako třeba Required

Tudíž i kdybys s ním opravdu nesouhlasil, nemá smysl argumentovat tím, že nepotřebuješ Requred, vzhledem k tomu, že odstavec o takové situaci vůbec nemluví.

Psal jsem to právě proto, že mě napadlo, že bys mohl zkusit obětovat Requires a interpretovat ho jako Wants. Pak by mohlo jít teoreticky sestavit pořadí i pro úplně všechny služby a při spouštění řešit jen závislosti a nikoliv pořadí. Pro boot, shutdown apod by bylo možné i nějak cachovat uzávěr (v matematickém smyslu) těch závislostí.

Nicméně pořád bych potřeboval aby ty systémy alespoň striktně rozlišovaly závislosti a pořadí a v lepším případě bych potřeboval aby podporovaly i trochu pokročilejší typy závislostí systemd, které třeba zajišťují správný postup při restartu některé služby.

[Josef Kufner]

Nemůžeš obětovat něco, co nemáš. Pokud chci ze service souboru generovat SysV init script, je na místě se bavit o graceful degradation a nemá smysl řešit pokročilé závislosti.

[pavlix]

Teď už ale vaříš z vody.

[Foo Bar]

Jako třeba toto?

https://github.com/oerdnj/systemd2init

V Debianu je to v balíku dh-systemd; V RH/Fedoře to používá minimálně lzap.

[little.owl]

To vypada velmi dobre, snad jeste nejake README.

[Foo Bar]

Napsat README už je moc práce :)

[little.owl]

Vetsina vyvojaru trpi jako zvire, pokud maji neco dokumentovat .

[pavlix]

Zvláště pokud se tím o krok přiblíží tomu, že někdo ten software začne zkoušet používat.

[Foo Bar]

Rozhodně to nebudu rozporovat, ale pokud by ten systemd2init.1 někde aspoň trochu napsal, tak slibuji, že ho budu udržovat.

P.S.: Psal jsem to hlavně kvůli sobě a kvůli tomu, že mi to přišlo lepší než tlachání v mailing listu o tom, jak je svět zlý...

[pavlix]

Mně by se líbilo mít jeden tool pro Debian/Fedoru i pro Gentoo, pak bych měl nějakou motivaci se angažovat, viz.

[pavlix]

Aha, do toho by se dal teoreticky mergenout ten můj systemd2openrc, ale nevím, jestli se mi úplně líbí to dělat v shellu a takhle pomocí primitivních šablon. Já popravdě řečeno generuju docela odlišné výsledky podle typu služby.

[Foo Bar]

Osobně bych to teda nemergoval, protože je to úplně jiný typ úlohy... a merge by už trochu byl bikeshedding.

[pavlix]

Nezdá se mi, že by generování initskriptu byl jiný typ úlohy než generování initskriptu.

[Foo Bar]

"Cesta z bodu A do bodu B" a "cesta z bodu A do bodu B" je taky stejný typ úlohy a přesto nemáme autovlakletadkolo :).

Generovat OpenRC skript, který je více méně taky deklarativní jako systemd, vs shell špagetový initscript mi pořád připadá jako jiný typ úlohy.

[pavlix]

Prosím, jenom ne další nepovedená přirovnání k dopravním prostředkům. OpenRC je podle mě dost podobnou směcicí špaget a deklarací jako třeba LSB initskript, nehledě na to, že i dost podobně vypadá. Osobně mi přijde, že by upstreamový projekt schopný generovat kvalitní initskripty pro několik systémů byl příjemným zlepšením současné situace. Nabídl jsem, že se na tom budu účastnit. Byl jsem odmítnut. To je vše, co k tomu má smysl říkat.

[...]

zato mame skupinu inovatoru, kterym nevyhovuje status quo v doprave. zbrojni prumyslniky.

a uz vynalezli tank. ted zapracovat na marketingu a protlacit ten tank silou, aby si ho kazdy chtel koupit misto auta, listku na vlak, letenky, ... kdyz tank, tak do kazde rodiny. bezpecny dopravni prostredek. natolik bezpecny, ze ani nebudete potrebovat ridicsky prukaz.

[hermelin]

Vybery a alternativy takove dulezite veci jako je init system...

samozrejme grafiky desktop, webove prohlizece atd - to je uplne neco jineho - tam je pravo volby dulezite a s tim nemam nejmensi problem

[zofrey]

on ten init zas tak dulezity neni a da se docela jednoduse vymenit treba za bash nebo python. problemem je hlavne prohlizec by v nem vsechny ty web aplikace vubec jely

[j]

Jiste, takove logovani, to je zcela nepodstatna vec ... start dhcp serveru na klientech, to je taky detail ... a muzem pokracovat jmenovanim tisicu a jedne veci, ze kterych systemd dela jednoho velkyho molocha, pricemz aktualni stav je takovej, ze pro kazdou jednu vec existuje nikolik (casto i desitek) ruznych implementaci, kde kazda je dobra na konkretni ucel.

Ostatne, proc by mel tux podporovat 30+ ruznych FS. Staci jeden, vzdyt je to nepodstatny. User vlastne ani nevi, k cemu to je ... a proc by vubec mel behat na necem jinym, nez x86 (coz je mimo jiny stim primo souvisejici - pokud se debian stane systemd only, tak se ZAROVEN stane x86 only).

[pavlix]

start dhcp serveru na klientech

V čem je problém?

[j]

Vubec v nicem, na widlich taky startuje hromada sluzeb otevrenych do netu a nabouravajicich site ... to bude radosti na starym belidle az se zase objevi nejaka ta dirka.

Ale to ty samo nemuzes chapat.

[pavlix]

Máš pravdu, nemůžu chápat vyblití se do klávesnice, které nemá hlavu ani patu a nejspíš ani nic moc společného s realitou.

[Jirka]

Vypálit si Wheezyho na zlatý DVD byl evidentně dobrej nápad.

[port]

g-e-n-i-a-l-n-i

[little.owl]

... na zlatý DVD ...

A povesit si ho na snurce na krk ... od jednoduche verze po slozitejsi ...

[Šangala]

Jestli chceš i Gnome, tak spíše Squeeze .

[odin]

Proc je vlastne kolem toho takova vlna nevole? Ja jsem se osobne se systemctl celkem szil. Na druhou stranu, kdybych mel moznost volby, zustal bych u stareho zpusobu

[Pavel Kozisek]

takze jeste jednou pro takove pitomce, jako ses ty.

Pan Poettering je vyvojarem v desktopovem tymu. Vsechny ty ficurky, ktere se nyni pod jeho vedenim tlaci do distribuci maji pouze smysl pro desktop. Demoni kteri prichazeji se systemd meni locales a casove zony, NTPd neni servrovy.

Zrovna tak automaticky restart services je tak akoroat neco pro desktopy, aby se zakamuflovalo, ze padaj programy. U bezneho servru je automaticky restart services mnohdy harakiri. Pres cgroups se zabijou child procesy spolecne s parents - opet nepripustne.

Nejakou dobu jsem se nechal zmast tim, ze RH dodava uhlazenou servrovou distribuci a myslel jsem si , ze za tim stoji kvalitnio vyvojari. Dnes jsem presvedcen, ze vyvojari u RH nemaji o provozovani servru nejmensi poneti. Kdby meli u RH koule, tak by si priznali, ze delat ze servroveho systemu desktop s tou samou kodobou zakladnou je nesmysl. Uz se o to pokouselo nekolik firem - vysledky jsou zname.

[odin]

takze jeste jednou pro takove pitomce, jako ses ty.

Dej si facku a zkus to znovu

Nadavky si setri pro sve rodice. Muzes jim nadavat za to, jak spatne te vychovali.

[pavlix]

+1

Po těch nadávkách jsem alespoň čekal smysluplnou a věcnou argumentaci, ne vyblití pár okoukaných klišé.

[ragnarok]

+1 Hezky =)

[little.owl]

... , aby se zakamuflovalo, ze padaj programy. ...

Vetsina techto konfiguraci je optional a vy je nemusite timto zpusobem pouzivat. Vzhledem k tomu ze firmy jako jako Spotify, provozujici desititisice serveru po cele zemekouli, vyjadrovaly ve sporu systemd podporu, nabizite nejspise pohled pouze z jedne strany.

ze delat ze servroveho systemu desktop s tou samou kodobou zakladnou je nesmysl.

To by se dalo rici i kernelu - a ze stejne codebase to beha od mobilu po TOP500 stroje.

[michich]

Pres cgroups se zabijou child procesy spolecne s parents

Způsob zabíjení služby jde nastavit v unit souboru. Viz KillMode= v systemd.kill(5).

[pavlix]

+1

[Pavel Kozisek]

ty ses u tech sitovych nastroju:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739190

taky je to za +1 ??

kde je moje moznost volby?

[pavlix]

Na co přesně se ptáš?

[little.owl]

Zrejme ma vyhrady k tomu, ze debianni maintaineri maji problemy integrovat interaktivni chovani puvodnich sitovych init skriptu postavenych na jejich vlastnich specifickych LSB extensions do systemd unit, nebot systemd interaktivitu s vyjimkou bezpecneho zadavani hesel nepodporuje a vstupy jsou pripojeny k /dev/null.

Klasicky problem kdy systemd je kompatibilni s 99% LSB kompatibilnich skriptu, ale ne s distro specifickymi rozsirenimi.

[Pavel Kozisek]

v unit souboru

kde se to nastavuje v init-scriptech?

[pavlix]

Je takový problém napsat několikařádkový unit soubor v případě potřeby? Stoprocentní kompatibilita s původními initskripty bez další konfigurace je podle mě utopie, vzhledem k povaze obou řešení. Ale jestli bude potřeba upravit initskript nebo unit soubor je podle mě jen nepodstatný detail.

[michich]

SysV služby mají implicitně nastaveno KillMode=process, nikoliv cgroup.

Ale nastavit jinou hodnotu jde i pro SysV službu. Stačí pro ni vytvořit drop-in soubor, např. /etc/systemd/system/sluzba.service.d/killmode.conf:

[Service]
KillMode=mixed

[Rezza]

Lennart je v týmu Server Experience .

[little.owl]

No toz tak. Uz jsem se lekl, ze by mi prznil Gnome!

[kralyk z abclinuxu]

No toz tak. Uz jsem se lekl, ze by mi prznil Gnome!

No to by si snad nedovolil. To je přece práce Gnome developerů :p

[Pavel Kozisek]

https://archive.fosdem.org/2011/interview/lennart-poettering.html

[pavlix]

A?

[Rezza]

Rok 2011 :).

[JS1]

Vyhodili ho kvuli PulseAudio?

[Heron]

Dnes jsem presvedcen, ze vyvojari u RH nemaji o provozovani servru nejmensi poneti.

Asi tak. Je velice smutné poslouchat, jak vývojáři RH dostávají nové notebooky, jak na tom testují serverový program a jak vůbec nic neví o potřebách správců serverů. Je to pořád stejná písnička. Když přišly 64b CPU, testovalo se pochopitelně na 32b OS. Když přišly mutlicore x86 CPU, testovalo se pochopitelně na jedné singlethreaded appce, když přišly multidevice FS jako ZFS a později BTRFS, testovalo se na notebooku (kde jinde) a samozřejmě na jednom disku. Nepřekvapuje mě to. Znalosti čehokoliv za mimo notebook jsou dnes zcela mizivé. Jen je to ... smutné.

[little.owl]

To by me zajimalo na jakych noteboocich testuji pro ppc64 ci s390x.

[Heron]

Mě taky. Nebo možná ne. Úplně mi stačilo, když jsem slyšel, jak se testují různé UEFI appky.

[pavlix]

Je velice smutné poslouchat, jak vývojáři RH dostávají nové notebooky

Ano, to musí být velice smutné ;).

[R]

Problem s testovanim nema len RedHat. Napriklad vyvojari drivera pre grafiky Intel netestuju zmeny na starsom HW. Ocakaval by som, ze v takej firme maju od kazdeho vlastneho HW, ktory vo svojom driveri podporuju, aspon jeden kus, na ktorom sa robia automatizovane testy. A nie, ze sa NULL-pointer dereference dostane az do mainline kernelu. Ale aspon to po nahlaseni bugu hned opravili...

Mam pocit, ze mainline kernel netestuje nikto. Okrem par vyvojarov, ktori to testuju na par kusoch vlastneho HW.

[omg]

problem neni u: "jak na tom testují serverový program"

to by vypadalo jako problem testeru. tohle je problem vyvojaru. testeri prijdou uz k hotovemu a jeste idealne s sibenicnim terminem na krku. ti uz toho moc nezmuzou.

[fklaud]

redhat tlaci cloud kde to jde. takze pokud spravne chapu kam tohle smeruje, tak k tomu, aby se malym firmam nevyplatily naklady na spravce systemu a misto toho zaplatili jednorazove konzultanta/integratora a pak provoz v cloudu.

systemaci pak budou mit zhruba jen nasledujici moznosti. jit mimo obor. jit mimo korporatni linux, prosadit se jako integrator nebo konzultant. nastoupit jako podpora k provozovateli cloudu. tech par neschopnejsich pak budou delat to co doted akorat to budou psat jako automatizaci pro spravu v cloudu u toho uzasneho enterprise.

[fklaud]

no a skonci to nejspis spatne. protoze sice nejaky cas prodaji vic licenci, ale v podstate to bude mit komorni uzivatelskou zakladnu. takze ubyde moznosti jak se samovzdelat...

[JS1]

Ano, nejspis to tak skonci, ale nevidim duvod, proc je to spatne. Takhle konci vsechny technologie - stanou se z nich komodity.

[Pavel Kozisek]

casto s tim souhlasim, co pises, ale to tvoje "bejt nad veci" me fakt leze na nervy

[JS1]

Ja nejsem nad veci. Automatizace se ale tyka velkeho mnozstvi povolani, nejen adminu. Jsem ochoten s takovym clovekem sympatizovat jen za podminky, ze je on ochoten sympatizovat s nekym jinym. Luddismus nepovazuji za rozumne reseni.

[/.]

http://phys.org/news/2014-10-lufthansa-outsources-infrastructure-ops-ibm.html

[frm]

aby se malym firmam nevyplatily naklady na spravce systemu

to si nejsem tak jisty. Cloud zatim jakz takz funguje u veci, keter jsou standardizovane (office, mozna ucetnictvi, SAP) ale jakmile ma software zohlednit nejake zvlastni prani maleho zakaznika, tak je konec s jednorazovym konzultantem/integratorem.

[little.owl]

Ano. Jen si nemyslim, ze Red Hat tady urcuje trend. Googlu, Amazonu, Microsoftu, ale i dalsim mensim hracum, je v podstate jedno, co Red Hat dela a jsou si schopni pripravit vlastni reseni i bez ohledu na nej. Red Hat se prizpusobuje situaci, snazi se urvat co jde a nemam pocit, ze zrovna komodizace distribuci je uplne v jeho prospech.

[LKG]

Zcela upřímně doufám, že se dočkáme variability ve výběru initu. Debian byl vždy poměrně konzervativní distribuce. Poměrně přesně vystihl v odkazované diskusi moje pocity Florian Lohoff:

I am not saying its a conspiracy. I dont understand the hurry - For me systemd came from behind the couch 24 months ago and suddenly its the best invention since sliced bread. I am just courious about any integral part of my system beeing rewritten in a revolutionary way and people beeing very loud about it beeing the best thing ever happened.

--

I dont like this trend - systemd already mixes beeing pid 1 and beeing an aglomerated blob of nearly ANY low level functionality any unix system needs like syslog, timekeeping etc.

Lennart je zcela jistě génius, který je schopen produkovat funkční kód v rekordním čase. Ale ten hype, který vyvolal, ten prostě nechápu a neodpovídá (ne)zralosti kódové základny systemd. Diskusi doporučuji přečíst - velmi poučné.

[TM]

Mně jeho činnost připomíná spíš grafomana. Opravdu produkuje spoustu kódu(což bych já třeba tak rychle asi neuměl), který - z jeho pohledu - funguje, ale celé je to celkem k ničemu. Nejsou za tím žádné geniální myšlenky, jen spousta hypertrofovaného ega a možná, vzhledem k tomu, jak jedná a projevuje se na veřejnosti, Aspergerův syndrom jak vrata.

[Sid]

"ale celé je to celkem k ničemu." - celkom silne tvrdenie, chcelo by zdovodnit. btw skoro za naprostou vacsinou SW nie su ziadne genialne myslienk. Kazdopadne aspon sa ten clovek o nieco snazi, kecat dokaze kazdy. Povedal by som, ze obecne tieto diskuzie mi pridu, ze vacsina ludi tu sa citi ako genius v oblasti initu.

[TM]

Na init ale nemusíte být žádný génius. Je to relativně jednoduchá záležitost a když půjdu do extrému a vyrobím si vlastní malou distribuci - aby to šlo rychle, tak s Busyboxem - budu mít první verzi initu za jeden večer ve formě několika scriptů.

Ta debata, sakra, není o initu!

Pokud by systemd byl jen init systém, dalo by se to asi akceptovat podobně jako upstart. Jenže šílený Poettering s RedHatem za zády, požírá spoustu dalších věcí a snaží se v userspacu linuxových distribucí vytvořit další, podle mě úchylný, (s trochou nadsázky)operační systém, kde všechno souvisí se vším.. Díky, ale jedny Windows už tu máme. O tom je ta debata, pochopte to už konečně.

[Petr]

Dokonce by to šlo ještě snadněji - udělat si jeden script (a'la autoexec.bat), který prostě postupně spouští služby. (Např. že volá postupně scripty z /etc/init.d). Toť vše.

[Sid]

Ono asi je problem s tym, ze pre vas je init jeden script ktory zbastlite za vecer. Pre niekoho to bude dostacujuce, pre niekoho zase nie. V momente ked zacnete riesit dalsie poziadavky (poradie spustania sluzieb, zavislosti, ukoncovanie, testovanie procesov,...) tak uz asi vas init nebude jednoduchy scriptik zbuchany za jeden vecer. Som si uplne isty, ze vasa "relativně jednoduchá záležitost" by sa vam v momente nasadenia do velkych distribucii rozletela na kusy.

PS: Podobnych rieseni zbuchanych za den/dva je plny github. Maju tak ~ do 50 commitov a potom ticho...

[TM]

To je těžké, když vy vůbec nechápete, co se snažím sdělit.

[Šangala]

Zbytečné - kdo nechce slyšet neuslyší, kdo nechce vidět neuvidí ;)

[omg]

tak jeste porad je moznost ze dojde na rozsireni na http://en.wikipedia.org/wiki/List_of_inventors_killed_by_their_own_inventions jen je otazka co se tam bude pripisovat, jestli znacka, korporace, ...

[Pavel Kozisek]

poradie spustania sluzieb, zavislosti, ukoncovanie, testovanie procesov,...

ja se priznam, ze se mam fakt co drzet, protoze to co se porad omila je proste bohapusta lez. Ja spravuju jiz desetileti unixovske a linuxovske servry a to u koncovych zakazniku, kteri se bez IT neobejdou jeden jediny den. A skutecne si nepamatuji, ze bych za ta leta resil poradi spousteni sluzeb, jejich zavislosti a nebo dokonce ukoncovani. Na servrech, ktere jsem zatim spravoval se sluzby ukoncuji se shutdownem.

Poradi vsech tech sluzeb je jiz predem dano a a za ta leta se samozrejme k tem standardnim sluzbam obcas neco prida, co je pro nejakeho zakaznika specificke. To jsou absolutni vyjimky, vzpominam si, jak jsem musel pro Slackware udelat init script pro Kerio, protoze Kerio dodavalo jen rpm balicek. Pro nejaklpu takovou akci je pak init-script to posledni, co pusobi bolesti hlavy.

Skutecnost je takova, ze unixovske a linuxovske servry maji bezne uptime radove v letech. A kdyby mely ty sluzby neustale padat, znova se musely stratovat a furt byly problemy se zavislostma, tak uz by byly davno vsechny servry tohodle sveta Windows. Ale tomu tak neni a to je take ten dukaz, ze soucasna technologie fantasticky funguje.

Bohuzel to musim videt tak, ze se nejaky mladicek z Hamburgske univerzity vydal spasit linuxovsky svet aniz by jednou jedinkrat musel stat tvari v tvar zakaznikovi, ktery s tresouci se rukou vsunuje zalozni tape a dela restore a pritom se modli, ze se podari zachranit aspon data z minuleho tydne. A samozrejme na hranici infarktu hrozi advokatem. Ale v RedHatu neco takoveho nehrozi - tam je mozno si zaprogramovat.

Takze jeste jednou - proc lzete?

[little.owl]

Ve vasem scenari pouziti neresite poradi spousteni sluzeb, zavislosti a ukoncovani, a netrapi vas ani rychlost bootu a shutdownu, a nepotrebujete ani monitoring sluzeb a pripadne volitelnou moznost jejich restartu. To vsak nevysvetluje proc by systemd ktery v teto oblasti neco resi mel byt hrozne zlo.

Tvrzeni, ze bezny uptime linuxovskych serveru se pochybuje radove v letech, mi prijde silne nadnesene, tipoval bych ze planovany restart nekolikrat do roka kvuli udrzbe je pravdepodobnejsi - pokud se pletu, rad se necham uvest od mistnich borcu do reality.

Pokud je treba boot up time tak absolutne nezajimava vec, proc se potom sluzby jako Amazon EC2 nebo Google GCE ci distribuce jako CoreOS optimalizuji pro rychly start? Nema to cosi spolecneho treba s autoscalingem?

Takze jeste jednou - proc lzete?

Nelze, ma jen jiny nazor nez vy.

Jinak diky za tento prispevek.

[Jiří J.]

Tvrzeni, ze bezny uptime linuxovskych serveru se pochybuje radove v letech, mi prijde silne nadnesene, tipoval bych ze planovany restart nekolikrat do roka kvuli udrzbe je pravdepodobnejsi - pokud se pletu, rad se necham uvest od mistnich borcu do reality.

(Z mé zkušenosti) je tomu tak. Ne zrovna kvůli "údržbě", ale spíš bezpečnostní aktualizaci kernelu (ksplice a podobné věci pořád nefungují zrovna nejlépe). Na druhou stranu - embedded věcičky se na ty roky dostanou bez problému. Pro "nepřerušitelné" služby nějakou formu HA proxy nebo dočasné přepnutí na záložní stroj (často přes DNS).

Pokud je treba boot up time tak absolutne nezajimava vec, proc se potom sluzby jako Amazon EC2 nebo Google GCE ci distribuce jako CoreOS optimalizuji pro rychly start? Nema to cosi spolecneho treba s autoscalingem?

Pokud je boot time tak důležitá věc, proč na něj všichni výrobci (x86) serverů tak z vysoka, s prominutím, serou? .. OS mi bootuje 10-30 sekund, ale HW se inicializuje 5 (HP) až 20 (Dell) minut. Nedělám si srandu, zlaté desktopy.

[Josef Kufner]

Virtuální cloudové servery je vhodné umět rychle nahodit a shodit. To s hardware nemá nic společného. Pokud přijde nečekaná špička, je potřeba nahodit další servery co nejdřív. Pokud ale jde o server, který poskytuje roky nějakou službu a výkonově má dostatečné rezervy, tak je samozřejmě nějaké bootování zcela nezajímavé.

[TM]

Legrace je, že systém se systemd velmi často nenabíhá o moc rychleji než ten s klasickým initem, někdy tam nějaký rozdíl ani není vidět

Ale init jako takový je v těch debatách málo podstatný. Jde hlavně o to, co se kolem něj v systemd nabalilo a to je ten problém. Poettering může být jen "užitečným idiotem" pro společnost, která na Linuxu vyrostla, stává se z ní klasická korporace, řízená kravatami a snaží se - z komerčních důvodů - Linuxu jako takového zmocnit. Dá se to považovat za přirozený vývoj a je s podivem, že to dřív nikoho nenapadlo. Teď se spousta lidí diví. Ukazuje se, že systémy pod BSD licencí jsou, z nějakého důvodu, proti těmto snahám daleko odolnější.

[j]

Plky ... pokud provozuju vykonovej cluster, tak mi bezi hot stoj, kterej muze zatez prevzit okamzite, a prave v tom okamziku zacne startovat dalsi. Je mi uplne jedno, jestli bude startovat o 10ms dyl, protoze to je tak maximalni rozdil ...

[Heron]

Pokud je boot time tak důležitá věc, proč na něj všichni výrobci (x86) serverů tak z vysoka, s prominutím, serou? .. OS mi bootuje 10-30 sekund, ale HW se inicializuje 5 (HP) až 20 (Dell) minut. Nedělám si srandu, zlaté desktopy.

Asi tak.

Ještě by se mi chtělo napsat: oni maji notebooky s uefi, tam je start hw do 1s. Ale nebudu prudit, tak to nenapíšu.

[little.owl]

Ne zrovna kvůli "údržbě", ale spíš bezpečnostní aktualizaci kernelu (ksplice a podobné věci pořád nefungují zrovna nejlépe).

Jasne, udrzbou (maintenance) jsem myslel veci od aplikace updatu po treba vyhnani pavouku.

ksplice a podobné věci pořád nefungují zrovna nejlépe

A i kdyby byly pouzitelne - pouzil byste to mimo kriticky security fix v dobe kdy to nemuzete schodit? Koukal jsem do kodu kGraft kdyz byl uvolnen a tohle implementovat bez race conditions v interakci s HW neni zadna sranda.

Pokud je boot time tak důležitá věc, proč na něj všichni výrobci (x86) serverů tak z vysoka, s prominutím, serou?

Zalezi na scenari pouziti. U techto serveru je to skutecne fuk, ale jinde, treba u VM, to asi hraje roli.

[Heron]

Tvrzeni, ze bezny uptime linuxovskych serveru se pochybuje radove v letech, mi prijde silne nadnesene, tipoval bych ze planovany restart nekolikrat do roka kvuli udrzbe je pravdepodobnejsi - pokud se pletu, rad se necham uvest od mistnich borcu do reality.

Vzhledem k časům startů v řádu minut mi přijde celkem jedno, zda je uptime roky nebo měsíce. Restarty se provádějí tak často, jak je potřeba, většinou tak často, jak vychází kernel. U stable dister je pro v intervalech několika měsíců, takže se restartuje 2-3x do roka a pokud si dáte tu práci (což se mě osobně nechce, já updatuju tak často jak to jde) a vyzobete si jen updaty platné pro vaše nasazení, tak ty chyby v jádře nejsou tak časté, takže můžete restartovat klidně jedou za 3 roky. I takové stroje máme.

Apropos. Když jsme nasazovali servery pro jednoho zákazníka, zcela vážně se nás ptal, jak často se to musí restartovat. Po několika minutách nechápavých pohledů jsme mu sdělili, že uptime některých serverů a tedy i služeb (zrovna těch, co jsme mu dodávali) máme běžně přes 600 dnů. Na to odpověděl, že když mu dodávala servery jedna třípísmenková společnost (něco jako HAL, ale o jedno písmenko vedle), tak jim doporučovala restartovat každý týden.

Pokud je treba boot up time tak absolutne nezajimava vec, proc se potom sluzby jako Amazon EC2 nebo Google GCE ci distribuce jako CoreOS optimalizuji pro rychly start?

Protože to mají debilně navržené. Službu na serveru také neustále nestartujete a nevypínáte. Tedy ano, pokud se ta služba používá jednou za x dnů tak si ji můžete nechat spouštět přes (x)inetd (pro systemd dementy něco jako socket activation, akorát je to už 28 let staré). Pokud je vyžadována častěji, tak se služba nechá zapnutá trvale. Jak prosté.

[little.owl]

Protože to mají debilně navržené.

Takze fakt, ze si muzete treba vytvaret ve vasi aplikaci instance EC2 podle potreby je principialne spatny design?

[j]

Ses mimo realitu, nevim proc bych mel restartovat server. Natoz server, na kterym bezi nejaky produkcni prostredi. Takovej stroj se velmi casto vubec nijak "neudrzuje", protoze proste funguje a dela co ma. bezpecnost se resi jinde a jinak a patchnou pripadne sshcko je otazkou 10 vterin a reloadu sshcka. A to se tyka i widli, kde patch = 80% sance ze nastanou potize.

Nadto, zcela zjevne si vzivote nevidel server (zelezo), protoze jen to zelezo bude startovat 10, ale klidne taky 60 minut, v zavislosti na tom vocogo. Po tu dobu se vubec nedostane na system. Jestli pak vlastni OS nastartuje za minutu nebo dve je naprosto nezajimavy. Nemluve o tom, ze spousta SW sama o sobe startuje dlouhy minuty a nejaka ms usetrena v initu tomu howno pomuze.

[little.owl]

Ses mimo realitu, nevim proc bych mel restartovat server.

Treba kvuli updatum?

Nadto, zcela zjevne si vzivote nevidel server (zelezo), protoze jen to zelezo bude startovat 10, ale klidne taky 60 minut, v zavislosti na tom vocogo.

Rychlost startu jsem zminoval u VM v souvislosti s autoscalingem. Take si myslite, ze tam to neni problem? Proc treba CoreOS cili na dobu bootu < 1s.

[Heron]

+1

[Heron]

Víte, v jiné diskusi se tady semnou hádali, že admin ani nemusí vědet jaké balíčky má na serveru nainstalované. Tím pádem pravděpodobně ani neví, jaké služby se spouští při startu. Potom se nedivte tomu, že takový člověk ani netuší v jakém pořadí se mají startovat.

[R]

A potom tie jeho "spravovane" servery aj podla toho vyzeraju...

[lima]

Jeste bych dodal, ze je bohuzel moc lidi *zkazeno* metodikou reseni problemu restartem sluzby nebo celeho OS a neco podobnyho chtej i u Linuxu. Vubec je netrapi ze pad, zamrznuti nebo leakovani pameti neni korektni chovani a ma nejakou vaznou pricinu, kterou je potreba identifikovat a odstranit. Zakryvani usi a oci jen kvuli tomu, ze ted mam klid a co bude to bude. Do urcity miry chapu duvod u "hloupych" mobilnich zarizeni nebo cloudovych sluzeb, kde si kazdej Jouda naflaka aplikaci a bez povedomi pokazi konfiguraci a system se pak nechova podle ocekavani. Nebo u proprietarniho software, kde si nemuzete chybu jako u OSS sam odstranit a jsa vystaven na nemilost dodavatele vam nic jineho ani nezbyva. Nevim ale proc by kvuli tomu melo utrpet nasazeni na serverech nebo i desktopu.

Btw. minimalne od Windows 2000 funguje sprava procesu (skupiny, zavislosti, supervize), kterou se systemd snazi prodat jako novinku bez ktere jste nemohli byt. Zkusenosti se spravou obou systemu ale svedci spis o opaku.

[j]

+1000

[Šangala]

* 2^64

[sid]

Ono jedna nemenovana firma co kedysi robila ustredne mala vlastny init system 15 rokov dozadu. Malo to riesenie zavislosti,paralelny startup. Kvoli optimalizacii rychlosti startu sa vsetko vygenerovalo staticky a zabalilo do finalneho suboru. Takze mozno je problem v tom, ze vy chcete vydiet len jeden typ pouzitia a podla vas je to jedine spravne.

[pavlix]

Petr Tomeš se vrátil?

[pita]

Hmm, odebrani moznosti volby, nekompatibilita, nestabilita API, poslapavani standardu. To uz se vsichni zblaznili nebo jen chybi zkusenosti s uzavrenymi systemy jako MS Windows ? To se nikdo nepoucil z negativ monokultur a monopolu ? Historie se bude muset bohuzel (zase) opakovat.

Vzhledem k zatvrzelosti vetsiny clenu vyboru se Jacksonova snaha asi mine ucinkem. Ne ze by na tom neco zasadniho zmenilo, odchyleni kurzu Debianu je patrne uz peknych par let. Kdyz k tomu pridame posledni podpasovku, zariznuti samostatneho vyvoje udevu, tlak na podvoleni se bude asi velky a hodne by me prekvapilo, pokud jeho GR podpori.

Tady nekdo s ostatnimi poradne vyj*bava a jeste mu za to tleskaji. No tragikomedie

[chrono]

Jednu výhodu to začlenenie udev má. Teraz sa systemd môže chváliť, koľko rôznych vývojárov prispelo svojim kódom do systemd. :)

[Jiří J.]

Co se týče udevu - třeba by se dal celkem snadno převzít eudev z Gentoo. Vím, že ten projekt neodstartoval ve 2012 zrovna nejpozitivněji, ale podle githubu se celkem snaží. Nemluvě o tom, že udev vždy byl přece jenom moloch sám o sobě - od správy /dev, hotplug, přes pravidla od disků a síťovek, po nahrávání mixéru zvukovek, ..., až po abstrakci hardwaru (absorbce HAL).

[martin]

odebrani moznosti volby

muzes mi pls ukazat, kde si v instalatoru weezyho muzu vybrat init system? ja to tam nejak nemuzu najit. a byla by skoda si to nevyzkouset, kdyz to v jessie odberou...

[Honza Jaroš]

On někdo mluvil o instalátoru?

[pavel]

fork of Debian

[Grunt]

Kdyby ty písmenka byly tak o číslo nebo dvě větší, tak už se mi asi nevlezou na obrazovku. Jinak:

only few of us have the time and patience to interact with Debian on a voluntary basis.

Tož o čem je řeč? Nemám na to čas, se do toho neseru, ne?

[neklan]

Né každý má čas na nekonečné diskuse a úřednické tanečky okolo. Jsou lidé, kteří posílají pár(až set) euro měsíčně jako příspěvek. Svůj názor mají právo vyjádřit - zvláště na vlastním webu.

Když si někdo stěžuje, tak se sere do čeho nemá a když si nestěžuje, tak vlastně souhlasí. Jediná možnost jak něco ovlivnit je hlasovat nohama a sahnout těm namyšleným blbcům mimo realitu na prachy. Pokud to udělá víc lidí, tak uvidíš ten fičák. To, že existuje velká skupina lidí, kteří se současným vývojem zásadně nesouhlasí je nepopiratelné. A rozhodně to nejsou jen nějací pubescentní haters, jak se snaží druhá strana podsouvat.

Osobně jim fandím a pokud se některá nebo více těchto iniciativ vyprofiluje v solidní fork nebo jiné stable binární distro určitě je finančně podpořím, naúkor debianu samozejmě.

[little.owl]

To, že existuje velká skupina lidí, kteří se současným vývojem zásadně nesouhlasí je nepopiratelné.

Pak je na nich se podle toho zaridit a misto nekonecneho brblani si udrzovat reseni podle svych predstav.

[neklan]

A není to náhodou přesně to, o co se stránka s názvem "Shall we fork Debian?" pokouší? Nebo tedy souhlasíte s tím, že se do toho nemají "srát"? Nechápu kam míříte.

[little.owl]

Dokud se to nezacne realizovat, je to jen dalsi z rady vykriku do tmy.

[pavlix]

To v určitou chvíli platilo i pro všechny projekty, které se realizovaly.

[little.owl]

Tak to ano. Pokud by ale skutecne udelali treba spin Debianu bez systemd, jen bych to uvital, ale ve fork neverim.

[pavlix]

A oni se podle toho nezařizují?

[little.owl]

Je to zatim slovni snaha ovlivnit rozhodnuti Debianu, tohle napises za dve hodiny.

[Grunt]

Přesně tak mi to přijde. Nech radši založí bitcoinový účet na financování podpory alternativního systému a pak jsem zvědavý.

[pita]

Pak je na nich se podle toho zaridit a misto nekonecneho brblani si udrzovat reseni podle svych predstav.

Pri vsi ucte, rady a nazory tve uz zprofanovane malickosti jim budou asi u zadele

[Grunt]

Jsou lidé, kteří posílají pár(až set) euro měsíčně jako příspěvek.

Jo a pak tu máme valnou většinu, která provozuje „core business“ na něčem co vzniklo jako kříženec mezi idealistickou svobodnou náhradou UNIXu (nikoho kdo by provozoval čisté GNU neznám) a komerční proprietární platformou určenou pro business (nicméně proprietárna a bastlu jen tak racionální množství přesně k pohodlnému provozu) – ať jsem přesnější: Vydělává na tom bez toho aby korunu vrátil a ještě se rozčiluje, nadává a zakládá petice pokud přijde někdo a mění směr vývoje (motivovaný komerčními pohnutkami) právě směrem k podpoře jeho biznisu. Kdyby se za každý běžící Debianový server, který vydělává svému majiteli vybralo polovinu toho co za Windows Server, tak ty init systémy mohly být dneska minimálně tak čtyři. Nelíbí se mi? Použiju jiný. Není jiný? Napíšu si. Neumím si napsat? Zaplatím si. Nebudu platit? Neotravuju.

[neklan]

Udělat všechno tohle - navíc proti proudu poháněným kapitálem červených čepic není žádná sranda. Možná se to podaří možná, že ne. Každopádně se o to lidé snaží. Opravdu nevím, co na tom může komu vadit. Leda se bojí, že přijde o koryto.

I ty bohaté korporace si moc dobře uvědomují, že bez menších přispěvovatelů, dobrovolných testerů, nadšenců, propagátorů, rádců, blogerů, howto z komunity, universitních programů, ... jsou z dlouhodobého hlediska bezvýznamné. Ono je samožřejmě otázkou úhlu pohledu, kdo komu má co vracet.

Vůbec celá ta rétorika, že kdo nejde s námi je blbec, nula, zbytečný brblal a ještě k tomu socka je značně ambiciózní a křečovitá.

[pavlix]

Udělat všechno tohle - navíc proti proudu poháněným kapitálem červených čepic není žádná sranda.

Hlavně že prosadit se proti proudu určovaným Microsoftem a na něj navázanými výrobci hardware byla procházka růžovým sadem.

[Grunt]

navíc proti proudu poháněným kapitálem červených čepic

Jakože kdokoliv z RedHatu stál za integrací systemd do jakékoliv jiné distribuce než je RHL či Fedora nebo o čem je řeč?

[David]

To je pěkně chabá námitka. A ano stál za tím Red Hat. Hlavně protože Gnome, které distribuce historicky integrují a hle teď _musí_ i systemd. Nasranost části komunity uživatelů i vývojářů stoupá a jestli to někdo odnáší tak je to právě Red Hat za Gnome a systemd. Posun vnímání značky se ale projevuje pomalu, ale dopad Red Hat určitě pozná, o to se nebojím.

[Grunt]

Takže teď za to nemůže RedHat, ale GNOME? Kdo dál? Já taky?

[David]

Neumíš číst nebo neznáš fakta? Pořád za to může Red Hat.

[Grunt]

No já jen že openSUSE, Mageia, Tizen, Arch, to jsou typicky gnomácké distribuce.

[David]

Tak ještě jednou. Jde o to kdo platí vývoj Gnome a tím určuje směr. A kdo pak to teda asi je?

[Grunt]

Jak se mi může někdo smát a nazývat mě konspirativcem když pouze věřím že za útoky z 11.září stojí vláda USA, fakt nechápu.

[martin]

ty mas dneska formu :)

[omg]

Freedesktop ~= Gnome ~= RH desktop ~= schovavacka za Lennartem.

[David]

A ty tvoje distribuce integrují Gnome z historických důvodů. Prostě mají uživatele, kteří na něj bzli zvyklí, proto integrovali i Gnome 3, ale s trojským koňem.

[Grunt]

OK. Plán ovládnutí Středozemě rozkryt. Už nemá cenu zatloukat. Končím.

[otula]

Maličko nepochopils příspěvek, na který reaguješ...

[Václav "Darm" Novák]

Většině uživatelů Archu je GNOME absolutně ukradené, ta distribuce nemá žádný defaultní DM, ale stále za to že nasadili systemd může GNOME? Tak to už chce fantazii

[chrono]

Čiže žiadny projekt, od ktorého má kľúče RedHat, nevyžaduje SystemD? (a teda ostatné distribúcie bez Systemd môžu bez problémov fungovať)

[Grunt]

To, že existuje velká skupina lidí, kteří se současným vývojem zásadně nesouhlasí je nepopiratelné. A rozhodně to nejsou jen nějací pubescentní haters, jak se snaží druhá strana podsouvat.

Jo. Jsou to všelijací podnikavci co na tom žijí a systemd neumí jejich kluci bastlit tak jako init skripty, co?

[neklan]

Chceš tvrdit, že tyto lidi jsou bezvýznamní a nepořební? Proč tedy ta histerická argumentace, to opravdu nechápu.

[Grunt]

Chceš tvrdit, že tyto lidi jsou bezvýznamní a nepořební?

To tvrdit nechci (vlastně ano, chci, ale to je debata do jiného vlákna a na jiný čas), ale tyto lidi mají nejmenší právo brblat a největší právo platit.

[martin]

mno, kdyz jsem mel linux jen na svem pocitaci, tak jsem se hrabal v init sciptech, hrabal jsem se v grubu, kompiloval jadro and all that jazz. ale kdyz jsem zacal pracovat jako linux admin, tak jsem tyhle veci az na par vyjimek nikdy nedelal. proto mam pocit, ze zmena initu bude vetsine takovych podnikavcu dost u prdele, protoze je proste tenhle low-level vubec nezajima.

me prave prijde, ze systemd nejvic vadi "domacim hackerum", protoze se jich nejvic dotyka

[tacoberu]

Když si můžou kompilovat jádro, můžou si kompilovat systemd. V tom bych toho čokla neviděl.

[pita]

Hodne tenka hranice mezi hlouposti a provokaci …

Neprestava me bavit, jak si kdekdo racionalizujete svoje dojmy presvedcovanim okoli

[Foo Bar]

Hmm, můžu se zeptat, jak jste finančně podpořil SPI za posledních pár let?

[Honz]

Mě by jenom zajímalo - je systemd plánován jako nezbytný kámen na dalších 20 let? Pokud ne, nemá už někdo v hlavě vymyšleno něco mnohem lepšího, co by za podpory mnoha nespokojených vývojářů dal během pár let do provozu...?

[R]

systemd je planovany ako kamen, ktory sa uviaze o Linux a nasledne aj s nim hodi do vody.

[David]

Hehe. To až Linus ukáže Red Hatu prostředníček a Kaye s Lennartem přestane bavit udržovat fork

[JS1]

Ja myslim, ze Linus je ve skutecnosti za systemd rad. Aspon nekdo donuti konzervativni adminy pouzivat moderni vlastnosti Linuxu, treba cgroups.

[Pavel Kozisek]

ale ty uz jsi zkusil s cgroups omezit ty zdroje? Ono to ma smysl vlastne jen tehdy, kdyz je mnuzstvi procesu, ktere se daji spojit do skupin - tedy cim vice lidi tim vice prace. Kdyz tak vidim, ze lidi z BSD daj klidne ssh do jednoho jailu a tim maj to omezeni zdoju takrikajic zadarmo, tak si myslim, ze ty cgroups bylo takove placnuti do vody. Pro virtualizaci (zejmena KVM) by to melo smysl, ale jak to tak pozoruji, vsechno smeruje k jailum. Takze asi nic

[pavlix]

Neřeší náhodou linuxové cgroups právě určitou část funkcionality jailů?

[Václav "Darm" Novák]

Mám přes to nastavené CPU kvóty pro některé služby na laptopu, počítá se to?

[R]

Lenze oni to pouzivat nechcu, lebo z toho nemaju ziadny uzitok a je to zbytocne kurvitko.

[Václav "Darm" Novák]

cgroups nemají užitek a jsou zbytečné kurvítko? Hláška týdne To že to nepoužíváš neznamená, že to není zatraceně dobrá vlastnost.

[chrono]

Predpokladám, že nebude trvať príliš dlho kým sa objaví ďalší vizionár, ktorý rozdelí SystemD na kopec častí, potom ďalší čo to všetko pospája dokopy a pridá kopec nových vecí... (podobne, ako dopadol HAL)

[fklaud]

neintegruje systemd nahodou udev? pak je to jen ukazkove pokracovani tehle soap opery. aneb vyhodili nebudu jmenovat oknem, tak jim do baraku najel tankem primo novyou branou co si prave prorazil... pouzit vyhodit dvermi vlezt oknem je na tohle prilis slabe a hlavne nelogicky chronologicky obracene.

[mirec]

Tá integrácia udevu ma inak celkom naštvala. Len tak offtopic nevie niekto o jednoduchom kompozitorovi (to čo je za slovo?) pre wayland ktorý nepotrebuje udev a teda aj systemd? Chcel som vyskúšať wayland, ale na svojom minimalistickom systéme bez glibc nedokážem skompilovať závislosti.

[pita]

Chcel som vyskúšať wayland, ale na svojom minimalistickom systéme bez glibc nedokážem skompilovať závislosti.

Rekni si nekomu z mistnich, prej staci par patchu. Mozna ti je budou i aktualizovat

[David]

Mainstream budoucnost linuxu je stejně v systemd a Gnome. Peníze Red Hatu vládnou. Jsem rád za to jejich pořádný rozmrdání userspacu, protože nasranost zbytku roste a z té se zrodí budoucnost alternativní.

[Pavel Kozisek]

http://debianfork.org/

[pita]

pozde

[Pavel Kozisek]

to neskodi, kdyz se to zopakuje vicekrat.

[Pavel Kozisek]

a jeste pro uplnost

http://upload.wikimedia.org/wikipedia/commons/3/35/Systemd_components.svg

[martin]

pro uplnost bys spis mel poslat tenhle link

forkfedora.org

[little.owl]

[kralyk z abclinuxu]

Maybe we're not veteran enough?

[R]

Niekto este pouziva Sendmail?

[lima]

A pointa ? Jako ze ve Fedore pisou init skripty jak dobytkove ? Misto snadne opravy preplacnout nekompatibilnim bumbrlickem s vlastnimi .ini files ? To je logika.

Napr. rc.sendmail ze Slackware nebo se rc skripty na BSD systemech. Arch Linux svyho casu mel taky ciste psane init skripty.

Btw. pokud nekdo neovlada programovaci jazyk, tak mu bude pripadat vetsina zdrojaku taky jako nepochopitelna zmet cehosi.

[Heron]

Jako ze ve Fedore pisou init skripty jak dobytkove ?

Asi tak.

Navíc ty Slackware skripty by šly velmi snadno zjednodušit, protože část restart a case se nemusí v každém z nich opakovat. Stačí tak snadno nadefinovat co se má stát pro start a stop. Což je "kupodivu" totéž, jako je definováno v tom service file. Takže by stačilo celkem 7 řádků validního bash skriptu.

[little.owl]

Jako experti v oblasti shellovskych skriptu jste si urcite vsimli, ze srovnavate hrusky a jabka, nebot slackwari verze implementuje podstatne mene funkcionality nez fedori verze. Pokud by se omezovala, sla by fedori verze zjednodusit mnohem vice a treba na testovani vstupnich podminek ci navratovych kodech nevidim nic spatneho, spise naopak. Co je na fedori verzi konkretne tak dobytkovskeho?

[lima]

Fedori verze krome spousteni/zastavovani/reloadovani konfigurace, coz je ukol init skriptu, navic:
- sourcuje a pouziva vlastni udelatka misto explicitniho pouziti standardnich (funkce, pomocne promenne prostredi)
- resi sitovou konfiguraci, ktera by mela byt nezavisla na sluzbe MTA
- resi vlastni konfiguraci sendmailu mimo ramec jeho vlastni
- sestavuje konfiguraci pri startu
- pomoci vlastnich promennych nastavuje parametry pro spusteni
- spousteni nestandardniho in-house messagera vcetne nastavovani prav behoveho souboru a zamku
- nedodrzovani odsazovani u bloku

[little.owl]

- sourcuje a pouziva vlastni udelatka misto explicitniho pouziti standardnich (funkce, pomocne promenne prostredi)

Co je spatneho na sourcovani funkci (/etc/rc.d/init.d/functions) a konfiguracnich souboru (/etc/sysconfig/*)?

- resi sitovou konfiguraci, ktera by mela byt nezavisla na sluzbe MTA

Neresi se sitova konfigurace; pouze se reflektuje hodnota globalni promenna nastavene v konfiguraci administratorem.

- resi vlastni konfiguraci sendmailu mimo ramec jeho vlastni

Nerozumim.

- sestavuje konfiguraci pri startu - pomoci vlastnich promennych nastavuje parametry pro spusteni

A co je na tom spatne? Pokud neodelite kod a konfiguraci, zkoncite pri upgradu mergovanim init souboru.

- spousteni nestandardniho in-house messagera vcetne nastavovani prav behoveho souboru a zamku

To byla jedna ze soucasti zabezpeceni s ohledem na deravost sendmail - jeden cas byl jak cednik. Opet nevidim problem.

- nedodrzovani odsazovani u bloku

OK, to bych vam uznal, parkrat jim to ujelo.

Cekal jsem po tom prsateni predrecniku vice.

[FrostyX]

+1 viz /etc/init.d/sendmail na Gentoo

[little.owl]

To uz je srovnani jablek a brambor, OpenRC skripty nejsou SysV skripty.

[kralyk z abclinuxu]

Aha, tak proto ten skript není úplnej humus. Já si říkal...

[pavlix]

To, co vidíš jde úplně stejně dobře udělat s klasickými sysvinit skripty.

[little.owl]

Tak se sysvinit skripty jde udelat ledascos.

[pavlix]

Tedy to nepovažuju za srovnání hrušek a jablek.

[Grunt]

LOL, jeden den a flame jak noha zas. Tím padá teorie o tom, že systemd nemusí jen na českém Ábíčku.

Maybe we're not veteran enough?

A tohle nemá chybu

[Grunt]

A jinak asi tak:

Well that's usually how it works, isn't it? People bitch and complain a bit about the direction a project is taking, and then they decide to fork it.

But not with systemd.

Instead, people bitch and complain, and bitch and complain, and bitch and complain.... but they never fork it. They just bitch and complain. And tell everyone to switch to Slackware. Thanks, but I'm not switching to a distro that doesn't use a real package manager.

[pavlix]

Instead, people bitch and complain, and bitch and complain, and bitch and complain.... but they never fork it.

I ty brepto.

[/.]

koukam je tu vybrana spolecnost... asi tolik k tehle sikane lidi co nesouhlasi.

[–]chinnybob 6 points 1 day ago*

systemd was forked. udev was forked. logind was forked. Your claim contradicts reality, and is nothing but a baseless attack on systemd critics, claiming that they are not technically able to create an alternative.

Edit: I just found out consolekit has now been forked too.

[pavlix]

Proč je to pod mým komentářem?

[/.]

protoze pouzit "brepto" na to co predvadi systemd nabozensti fanatici je opravdu slabe slovo.

[pavlix]

Takže šlo o doplnění. Mně se moc líbí použití argumentu o absenci forků v době, kdy existují nejméně tři a navíc existuje netriviální množství alternativ. Hlavně dnes už se dá za alternativu k (části) systemd považovat NetworkManager, Consolekit, cron, ale třeba i ISC DHCP. Na druhou stranu systemd používám a i občas koukám do kódu.

[...]

Tak Debian by se mel v prve rade poucit z "uspechu" mozilly... tam tlacili pokrok takovou dobu smerem k mandatorni IPv6, ze maji ted polovinu uzivatelu oproti stavu, kdy se jim to snazili narvat hrubou silou i presto, ze jim to nefungovalo ani s miredem. Dodnes je takovych siti vetsina. Ale protoze POKROK pyco!

[...]

funkcni multihome system pak zahrnoval povinny reboot a vyber jine boot commandlajny... nebo si proste koupit apple.

[kralyk z abclinuxu]

ze maji ted polovinu uzivatelu oproti stavu

FF má imho teď polovinu uživatelů ne kvůli nějakému problému s IPv6, ale hlavně kvůli úspěchu Chromu/Chromia.

(Čemuž se moc nedivím, protože už jen např. adresní řádek je ve FF stále ještě skoro stejně nepoužitelný jako ve verzi 2 etc.)

[pavlix]

Asi tak nějak.

[/.]

no jo, ale zrovna chrome to ma vychytane.

[pavlix]

Kdyby všichni nesoukromničili a místo toho se opravilo a rozšířilo systémové API a jeho implementace, tak by ten problém na úrovni aplikací vůbec neexistoval. Aby si každá aplikace jednotlivě workaroundovala systémové chyby mi nepřijde jako dobrý postup.

[JS1]

V diskusi na HN byl odkaz na zajimavy clanek - myslim, ze by si ho odpurci systemd meli precist.

[pavlix]

Nevím, jestli jsem ten správný odpůrce systemd, ale jednostranné články nemám rád.

[Šangala]

Já v tomto duchu taky ne ;).