Útek od Archlinuxu - systemd - kam?

14.10.2019 14:00 | Přečteno: 4825× | poslední úprava: 13.10.2019 20:29

Po rokoch strávených pri Archlinuxe uvažujem o odchode. Dôvod - systemd. Nikdy som sa nepovažoval za nejakého zarytého odporcu - koniec-koncov, som s ním na Archu už riadne dlhý čas. Ani nejak extra tento kus SW nesledujem - len občas narazím na správičku, ktorá ma ale v podstate nikdy veľmi nepoteší - došlo to však až do štádia, keď mi systemd začína liezť na nervy.

Aj keď snaha koncentrovať do systemd rôznu funkcionalitu navyše (mimo funkcie init démona) mi nikdy nebola veľmi sympatická, z počiatku mi to až tak veľmi nevadilo. V poslednej dobe je toho však akosi veľa - zavŕšila to správička o ambicióznom projekte prekopať komplet správu používateľov. Ako inak - v rámci systemd. Len tak som mrkol, čože to už ten systemd všetko vie - a je toho dosť. Logovanie, správa sietí, zavádzač, synchronizácia času - a to iste nie je koniec zoznamu (a koniec snáh o začleňovanie rôznych funkcionalít do init démona).

Voľakedy sa myslím hovorilo o systemd ako o modulárnom - ale ak aj to je pravda, praktické dopady tejto modulárnosti akosi nie je veľmi cítiť. Skrátka, keď si predstavím, ako asi vyzerá taká dnešná distribúcia (zo systemd) a ako asi bude vyzerať za pár rokov... Je to riadne vzdialené od unixovej filozofie - toho, čo som dakedy začal používať a toho, čo sa mi páčilo. Nemám z toho dobrý pocit - taký ten DIY pocit, keď som si nainštaloval Archlinux pred... 8 rokmi? Tak nejako - ešte z pred čias systemd, v čase, keď existoval ten dialógový inštalačný skript a neboli digitálne podpísané balíky. (Len tak na okraj - dá sa nejako zistiť kedy presne bola urobená inštalácia?)

Našťastie máme stále dosť non-systemd distribúcií - stačí si vybrať. Možno to nebude taký mainstream ako Archlinux, ale... vadí to vlastne? Mne nie. Otázka je však - kam ujsť? Mám rád koncept rolling release a KISS prístup k veciam. Pacman ako správca balíkov mi tiež vyhovuje. V podstate mi ide o to mať čo možno najčistejší Arch bez systemd. Keď si to zrátam, vychádzajú mi dve možnosti: Artix Linux a Parabola GNU/Linux-libre.

Parabola patrí k tým "dogmatickým" distrám poskytujúcim výlučne slobodný SW. Osobne si na tom až tak veľmi nezakladám, ale svojim spôsobom by to mohla byť výhoda. Nemyslím si tiež, že narazím na problémy - HW sa snažím kupovať tak, aby som sa týmto problémom vyhol a SW uprednostňujem slobodný - čiže sa aspoň ukáže, v akej miere je to u mňa v skutočnosti. Parabola síce používa systemd, ale dá sa fungovať aj na alternatíve (OpenRC).

Artix je zase taký ten anti-systemd punk. Podľa všetkého za ním stoja zarytý fanúšikovia Hviezdnych vojen - nič proti nim (sám mám Hviezdne vojny rád), ale trocha ma to od Artixu odrádza - asi najprv mám taký ten pocit, že to neberú celkom vážne. Ale zase si racionálne hovorím - no a? Aspoň bude sranda - veď sa jedná len o domácu mašinu. Artix má v otázke výberu init systému dve možnosti (OpenRC a runit).

Používate niečo z tých dvoch niekto? Aké je to v porovnaní s Archom? Aká je komunita? Ste spokojní s prechodom / výberom? Prípadne plánuje niekto tiež utiecť od Archu? Kam? A prečo?

       

Komentáře

[M. Ponkrác]

Pro mě systemd znamenal totální konec aktivního zájmu o Linux.

Plus to, že linux začíná řešit moderní neomarxistické progresivní věci natolik, že to nehodlám akceptovat. Feminismus, urážení se sněhových vloček, diverzitu, politickou korektnost. Kdybych to věděl na začátku, tak s Linuxem nikdy nezačnu.

[Krafft]

To je fakt. V astrologii nám to naštěstí nehrozí. Moderní progresivní věci. Fuj.

[regine2]

Registr nahradil konfigurační soubory aplikací z Windows 3 a tím to Microsoft poSZral. Ukládal do něho kdy, jaký soubor se otevřel... a jiné 'důležité' kraviny. Nevím, jak to dnes ve Windows řeší, ale tehdá často bobtnal, a bobtnal, až se systém zadrhával.

No, jen jsem tak odbočil do prahistorie konkurenčního systému.

[stepan]

Systemd rozbiji filosofii puvodniho Unixu, ale nijak zvlast mi nevadi.

S tim dalsim s Vami 100% souhlasim.

[AsciiWolf]

Pro mě systemd znamenal totální konec aktivního zájmu o Linux.

Takže jsi přešel na Windows. To je vážně z deště pod okap.

Plus to, že linux začíná řešit moderní neomarxistické progresivní věci natolik, že to nehodlám akceptovat.

Tohle taky nijak zvlášť nemusím, ale není to jen doménou svobodného softwaru. Podobný přístup a názory dnes najdeš i v téměř každé větší západní firmě.

[figliar0]

Ja to až tak tragicky nevidím. Linux je len jadro - slobodné jadro. Systemd sa stále dá vyhnúť - je to dokonca tak jednoduché, že stačí prejsť na iné distro. Tie neomarxistické drísty sú síce nahovno, ale to je len o ľuďoch - keď to prejde za nejakú únosnú medzu, vznikne fork.

[V.]

V gentoo lze toto změnit v principu za chodu, "eselect profile list", "eselect profile set (hardened | multilib | systemd | etc. ...)"

[snajpa]

Ve vpsAdminOS pouzivame tvrdohlave runit, i kdyz NixOS je primarne systemd basta. Na produkcni masiny, na kterych visi dalsi stovky lidi, mi to proste nesmi, nervy mam jenom jedny. Ale pravdaze si tim padem musime udrzovat init skripty pro sluzby, co pouzivame.

Dobrou radu, co pouzivat, uplne nemam. q66 tu docela schopne vali na Void linuxu, mozna bych zkusil ten... tez runit-based.

[trekker.dk]

A to bylo povídaček, že systemd je úžasný svěží vítr

[snajpa]

No a neni? Jen myslim, ze jsem nikdy nerekl, ze je uzasny. A zas tak uzasny, abych si pridelaval starosti pro spusteni 5ti sluzeb, to neni urcite. Obzvlast, kdyz na tech 5ti sluzbach visi dalsi stovky sluzeb...

Na laptopu, koncovych aplikacnich kontejnerech/serverech a podobne ale systemd normalne bezim. Dokonce z casu na cas ocenim veci, co systemd jdou jednoduseji (multiinstance services, socket activation).

Do uzasnosti tomu chybi spousta veci... modularita (s alternativnimi implementacemi jednotlivych komponent), rozsahla test suite a LTS releasy. To by myslim vyresilo dost z toho treni, co je okolo systemd ted.

[M. Ponkrác]

Zjevně se systemd většině lidí líbí, když se tak šíří. Demokraticky bylo rozhodnuto většinou, že systemd je nový směr.

Já jsem začal mít zase po dlouhé době extrémně raději Windows než Linux.

[V.]

Ano taky vyhrává volby. A taky se nad tím soudný člověk pozastavuje.

[AsciiWolf]

Já jsem začal mít zase po dlouhé době extrémně raději Windows než Linux.

Je zvláštní, že Windowsí "init" Ti nevadí, přítom je to podstatně větší šílenost, než systemd.

[Paranoik]

Presne tak.

[k3dAR]

tohle posledni dobou vidavam, nekdo kvuli veci XY v GNU/Linuxu pise ze radeji prejde/presel na Windows, pritom ta XY je ve Windows resena jeste hure a k tomu "tisice" dalsich veci co tam jsou reseny hure, svobodne ci otevrene to neni vubec, atd...

pritom racionalni zmenou by byl prechod na jiny init nebo jine distro nebo jiny sw z toho ktere dotycnemu nesedi... kdyz vynecham osobnostni poruchy, zbyva pouze vysvetleni ze takovej clovej lze a/nebo tro(t)luje

samozrejme bych bral duvody jako "chci/potrebuju hru/program co je pouze na Windows a nejde/nebo_nechci_zkouset wine/virtual"...

[...]

Je to prostě znechucení a zklamání z linuxové komunity, to jsou emoce, pak útěk k Mac nebo win dává smysl, i když to není k lepšímu.

[Gilhad]

Proc mi to jen pripomina hlasku "Ruku nelecit, uriznout!" smerem k uciteli, ktery pri probirani praveku nadsene ukazoval rozdelavani ohne kresanim kameny a samozrejme se prastil do palce :)

[debian+]

Co viem, tak Apple ma limit na pocet uzivatel na kompe, max 5. Preto GNU veci nemozu byt apple store. Bolo by porusenim GPL licencie, ze program mozem pouzivat ako chcem.

[figliar0]

Demokraticky bylo rozhodnuto většinou, že systemd je nový směr.

Demokraticky sa dá rozhodnúť pri jednom konkrétnom distre. Ťažko budeš demokraticky rozhodovať, akým smerom sa majú uberať iní - obzvlášť pri slobodnom SW.

[xkucf03]

Je chyba si spojovat Linux nebo GNU/Linux se systemd. Řada uživatelů a vývojářů s tím má problém a používají nebo chtějí používat něco jiného. Rozhodně ale existence systemd není důvod k opouštění GNU/Linuxu. Aktuálně se to řeší třeba tady: gnu-system-discuss

[vencour]

Nic ve zlym, v korporaci se mu člověk spíše nevyhne, systemd.

[xkucf03]

Zase když ti systemd někdo naordinuje jako požadavek, tak případné problémy nejsou tvoje starost – buď má konkrétní verze otestované, že budou fungovat, nebo jsou ty chyby jeho odpovědnost.

[vencour]

Nebo je budeš pro RH testovat

[xkucf03]

Když si zákazník objedná a zaplatí Red Hat, tak to bude mít na Red Hatu. Nemám s tím zásadní problém. A byť můžu mít výhrady ke kvalitě nebo přehnané komplexitě, pořád je to svobodný software.

[figliar0]

Na ten Void som tiež troška pokukoval - dokonca sa dostal do užšieho výberu. Ale nakoniec som ho vyškrtol - asi hlavne z lenivosti - vyzerá to totiž tak, že pri prechode na jedno z dvoch vymenovaných nebudem musieť robiť reinstall... A takisto pacman mam tak akosi "v ruke".

Čo sa týka výberu init systému - pomýšľal som skôr nad OpenRC - mám akosi pocit, že to je viac "in". Ale v princípe to je asi jedno.

[V.]

Gentoo nebo *BSD?

[figliar0]

Na Gentoo sa necítim (kompilácie ma veľmi nelákajú). Chvíľami som premýšľal o nejakom BSD, ale nemyslím, že je tam až taký výber rolling release systémov (čo namátkovo pozerám na distrowatch, nejaké sú, ale skôr user-friendly orientované).

[vencour]

Jestli máš vpsfree, tak tam taky je. Když tak se pokusim ověřit aktuálnost šablony.
Za mne je supr, stable základ i testing jednotlivý balíček lze mít. Celkem velký výběr balíčků. A v principu jednoduché.
Jestli se bojíš kompilace, tak ji ber jako věc danou a teprve po rozkoukání se v ní můžeš šťourat.

[figliar0]

Nejde o to, že sa bojím kompilácie - skôr sa mi to zdá... otravné? Zbytočné? Ťažko nájsť to správne slovo - ide o to, že Gentoo by pri rutinnej údržbe zožralo určite viac času ako Archlinux, čo nie som ochotný do toho investovať - alebo nie? Vieš to posúdiť?

[vencour]

Se mi nezdá, kompilaci nemusíš v principu řešit, pustíš ji, zkontroluješ flagy, jestli je tak chceš a počkáš na výsledek.
Navíc chceš to na server nebo klienta? Méně balíčků, méně aktualizací.
Řekni si, proč to vlastně chceš provozovat? Je to nutnost nebo hobby?

[figliar0]

V tom blogu som to naznačoval - je to domáca mašina, čiže jasné hobby. A je to na klienta (aj keď toho veľa nainštalovaného nemám, no...).

A to

zkontroluješ flagy

- to taký gentooista musí pri update robiť osobitne pre každý balík? Alebo sa to urobí raz pri inštalácii balíka?

[vencour]

Když zadáš příkaz ke kompilaci, tak si můžeš vypsat, jak to chceš a flagy uvidíš. Třeba mplayera s podporou skoro všeho, nebo iproute2 bez ipv6. Je to vidět. Můžeš to nechat plavat nebo změnit. V globálu i konkrétně pro jeden balík.

[figliar0]

No - vrela vďaka viacerým - prečo sa potom hovorí o gentooistoch ako o masochistoch? Keď to takto viacerí ospevujete, naozaj sa to nezdá až také zlé.

V každom prípade migráciu na spomínanú Parabolu (resp. Artix) mám úplne easy - netreba robiť čistú inštaláciu (je to skoro zadarmo). A keby to nebolo ono, potom sa poobzerám viac na Gentoo (alebo ten Void - aby som ho teda hneď nezatratil).

[Gilhad]

No, gentoo ti dava moznost nastavit skoro cokoliv jakkoli, ale pak samozrejme neses nasledky - spousta uzivatelu dava prednost tomu zakliknout par veci z kratkeho vyberu a aby to pak ten zbytek vsechno nejak samo se a hlavne to po nich nic nechtelo, natoz znalosti. Navic se programy kompiluji coz rada lidi povazuje za sproste slovo. No a instalace neni o rozsypani zrni okolo Enter a pripojeni slepice, ale zacina rozhodovanim, jak vlastne rozdelit disk ((a proc), jake tam dat filesystemy (a jake maji vyhody a nevyhody), jaky bootloader a proc, vyberem cronu, systemoveho editoru ... a asi tak na strance 50 to konci vytvorenim uzivatele, s tim, ze graficke rozhrani a podobne nastavby jsou volitelne a maji sve vlastni manualy a v tu chvili jeste instalovany nejsou, protoze kdovi, zda je tam vubec budete chtit.

"Typicka distribuce (tm)" zacne tim, ze se uzivatele zepta na jmeno, mozna jeste tak na casove pasmo a pak mu tam naflaka vsechno, co si mysli, ze by mohl chtit, vcetne weboveho prohlizece, officu a par gamesek, nacez to rovnou muze zacit pouzivat, nic neresit a treba mu to par let bude stacit i v tomto defaultu. (coz me na Windows vzdycky sralo, co tam vsechno nacpaly bez ptani a jak samy vedely lip nez ja, co chci a potrebuju a nedaly si to vymluvit)

[m.]

Ja beru Gentoo jako fajn ucebni pomucku pro zacatecniky, v zacatcich tato distribuce poslouzila opravdu skvele. Ale v praxi, kdyz chci byt produktivni, tak na desktopu detaily jako filesystem, jaky cron atp resit nechci. Nakonec na vysledky me prace takove rozhodnuti pri instalaci kterou jsem delal nekdy davno v minulosti, kdy jsem stejne netusil jak ten pocitac budu pouzivat dneska maji tak jako tak minimalni dopad.

A servery po jednom stejne instalovat nehodlam a rozhodne ne nejak moc customizovat nejakej zakladni system, co na nich bezi. A uz vubec ne, kdyz jsou jich desetitisice. Pak kazda vyjimka z bezneho stavu boli a stoji cas, ktery bych moh venovat vecem na kterych opravdu zalezi.

[vencour]

Ty někoho takového znáš z vlastní zkušenosti, kdo takhle o gentooistech mluví?
Fakt nevěř všemu, co kde na obědě nebo na cigáru slyšíš. Tam se pindá věcí.

[figliar0]

Jasne, ze nepoznám - trošku som preháňal .

[j]

Flagy nemusis vubec resit, pokud ti nevadi ze nekdo za tebe rozhod, jaky budou vychozi zavislosti = ta vec bud sebou dotahne (presne jako v libovolnym binarnim distru) tuny sracek, ktery na nic nepotrebujes, nebo naopak, nejakou ficuru kterou bys zrovna ocenil, v defaultu nekompiluje.

Kupodivu se pred aktualizaci vetsinou kazdy normalni clovek podiva, co se bude aktualizovat, a tam i zjistis, jestli se od minule flagy nezmenily = muze se zmenit ten default, nebo muzou nejaky flagy pridat/odebrat.

Pokud je treba neco extrea udelat po aktualizaci, tak te ne to system taky upozorni (veci jako ze kdyz mas novou mysql, tak ze mas spustit mysql-upgrade a pod)

[j]

Navic to kompilovat vubec nemusis, pokud se smiris s nastavenim zavislosti (stejne jako v libovolnym binarnim distru) muzes si nainstalovat binarni balicky.

Jinak vazne nechapu, co ma kdo za problem s kompilaci ... neni totiz zadnej rozdil mezi apt upgrade vs emerge -u ... pustim, necham bezet nekde na pozadi s nejnizsi prioritou (= na behu systemu se to prakticky nijak neprojevi) a zkontroluju vysledek.

Narozdil od tech "uzasne" stabilnich distribuci jako trebas deb, se mi jeste nestalo, ze by system aktualizovat neslo. Byt to v pripade ze ten system nekdo par let nechal byt, muze byt trochu vopruz, ale to vsude.

[~]

Jo, není v tom žádnej rozdíl, příkaz jako příkaz, snad jen ta spotřeba energie, délka běhu, nemožnost shutdown/reboot bez ztráty progressu a další detaily

[Gilhad]

Bez ztraty progressu? Samozrejme kdyz to shodis v pulce kompilace balicku, tak se priste ten balicek kompiluje od zacatku, ale kdyz dam kompilovat treba 5 balicku, kazdy 20 zavislosti, po case, kdy je jeden zkompilovan a ostatni maji poresenu cast zavislosti to restartnu, tak se se pokracuje tam, kde se skoncilo

emerge -n A B C D E

>emerging 1 from 105

>installing 1 from 105

...

>emerging 25 from 105

>installing 25 from 105

>emerging 26 from 105

reboot

emerge -n A B C D E

>emerging 1 from 80

>installing 1 from 80

(a tech 25 uz je hotovych, kuprikladu B i se zavislostmi a par zavislosti z A a D, tak uz se neprekladaji znovu, jen to, co bylo preruseno tim restartem)

[~]

Gratulki!

[j]

Ani to ne, kdyz mas cache, tak se kompiluje jen to, co uz neni, takze prijdes maximalne o poslednich par minut. A doporucuju vyzkouset, co se stane, kdyz uprostred aktualizace strelis deb, blbuntu nebo cokoli jinyho ... Me vzdycky fascinujou lidi, ktery zvanej o tom co se stane kdyz, a pritom se totez, ne-li jeste hur, stane na cemkoli.

[k3dAR]

[...] doporucuju vyzkouset, co se stane, kdyz uprostred aktualizace strelis deb, blbuntu nebo cokoli jinyho[...]

nestane se "nic", pokud by slo o jadro/initrd, bude dostupne predchozi, pokud by slo o (treba)xorg, v nejhorsim to po rebootu najede do konzole, kde pustit aktulizaci totozne znovu a pojede od pocatku mista kde zkoncila/byla_strelena, "kupodivu" se pri aktualizaci balicku totiz zaznamenava, zda byl uspesne rozbalen, nainsalovan, zkonfigurovan a podle toho se pozna kde to zkoncilo...

[Josef Kufner]

No... zas tak úplně "nic" se nestane. Občas se stane, že se to dostane do nějakého nekonzistentního stavu a chce to trochu popošťouchnout. Ručně vyvolat dokonfigurování balíčků a podobně. Občas nějaký balíček má trochu blbě závislosti a přerušený upgrade už nechce doběhnout.

[V.]

Proč shutdown? s2ram nestačí?
Tohle je linux, tam je reboot zpravidla jen pro změnu kernelu.

[~]

Předřečník tvrdil, že v tom není rozdíl. Takže jak to je?

a) jsi na ntb, ždímeš baterku

b) vadí ti zbytečně plýtvat energií - plná kompilace systému do KDE si pár hodin na max výkon a tedy i spotřebu vezme a děláš to znovu při každém upgradu

c) potřebuješ program/balík/tool ASAP a nenaplánoval sis jeho kompilaci předem

d) dual-boot na malém/pomalém/SSD disku (nechceš hibernovat); hw upgrade; kernel panic; výpadek proudu

[V.]

KDE je prostředí, že? LXDE je také prostředí a může stačit.
Notebook mívá by default upsávání, na desktopu to až tak časté není.

[~]

Počki, ale já myslel, že v tom není rozdíl. Prostě apt nebo emerge, příkaz jako příkaz, a teď slyším, že místo KDE mám používat nějaké LXDE?

[V.]

Linux je přece o volbě a svobodě?

[~]

Nepovídejte. O volbě mezi variantami a jejich výhodami a nevýhodami je celý život. A pokud vám někdo entusiasticky nakuká, že si máte nainstalovat Gentoo, protože kompilace se netřeba bát a není v tom rozdíl oproti Apt, tak ta volba může být objektivně špatná. Nutnost kompilace, když nepočítám to sto binárních balíků, je zásadní nevýhoda, která Gentoo pro některá použití zcela eliminuje. Když náhodou potřebuji Gentoo, dotáhnu si z něj to potřebné do Linuxu. Určitě kvůli tomu nebudu kompilovat celý kellner.

Ale těžko to vysvětlovat někomu, komu ještě teče mléko po bradě. Na čem kompilujete? Asi máte moderní procesor vyrobený 14nm technologií. Gratuluji. Patrně také máte Meltdown, Specter a další dosud neobjevené a neopravené choroby, které jsem předvídal už před 5 lety. Patrně máte porušený pud sebezáchovy, jak říká můj dobrý přítel Vlasta, a brzo vás bude svědět i prdel.

PPF: Vše nejlepší do nového roku a depilaci kellneru zduř.

[V.]

Co máte u sebe, to už je váš problém.
Gentoo mívá verzi kompilovanou i binární, například firefox, thunderbird, libreoffice, icedtea. Ano to má, u kompilované je možnost většího množství flagů.

[k3dAR]

sice to neni zarucenej test, jestli ti take tece mleko po brade... ten gentoo filemanager co davas link, jakej fm, v jake verzi, z ktere platformy to pripomina?

[Gilhad]

Nevim, jakou technologii je vyrobene Rapsberry Pi, ale Gentoo mi na nem funguje a je schopne se tam prelozit treba i cele. 486 urcite Meltdownem netrpelo, ani Spectre a gentoo tam taky chodilo (no uz je to par let, co ta 486 sla k nadsenci, co sbira stare pocitace - plne funkcni).

[kolcon]

jo, akorat u nekterych flagu fakt nevis, jestli je chces, nebo ne... a dalsi ti vynuti upravy package.use, protoze "package XY to vyzaduje"... takze muj package.use je plny historickeho plevele.

[Gilhad]

Muj package.use je adresar, ve kterem jsou soubory nazvane podle veci, ktere resi, takze vim grbl inkscape fritzing .... a v kazdem tom souboru jsou veci, ktere si dana vec "vynutila" - takze kdyz ji pak vyhodim, tak smaznu tento soubor a pokud nahodou to vyzadovaly i jine package z dobrych duvodu, tak to hodim do toho onoho jineho souboru (samozrejme je to vse verzovane v gitu, takze neni problem to vratit)

[vencour]

To souhlasí. Takže proto nenesu na úplně všech instalacích stejnou historii/stav /etc/portage.

[Gilhad]

No Gentoo pouzivam uz radu let a neprijde mi to az tak slozite (jasne, protoze vim jak na to).

Kdyz chci celkovy update, tak se synchronizuju se zdrojovymi servery distribuce (emerge --sync) a stahnu si aktualni stav. Kdyz jen potrebuju pridat balik, ale nechci se zabyvat tim, co se kde vsude noveho vylihlo, tak tento krok preskocim a jsem porad ve stejnem praveku :)

Prehozeni celeho systemu na novy stav (po updatu, nebo po zmene nastaveni - viz nize) (emerge -DuN world) (Deep, update, New flags) (pokud pridam -e, zacne se z empty tree a povinne se prekompiluje vsechno, i to co si mysli, ze nemusi)

Pridani baliku nekolik naraz (emerge nano vim hexedit) ci v konkretni verzi (emerge =app-editors/nano-2.5.3) - zavislosti si resi samo. Bezne pridavam -avq (Ask vypise co bude delat a ceka na potvrzeni, Verbose vypise i priznaky a Quiet nevypisuje kompilovane soubory, pokud neni chyba) pripadne --jobs=5 --load-average=10 (delej az 5 veci naraz ale nespoustej dalsi veci, pokud by se mel prekrocit dany load - no on se obcas o neco prekroci, neni to v systemu samo, ale priblizne)

Odebrani baliku (emerge -C wine games-roguelike/nethack =games-roguelike/rogue-5.4.4) odebere jen dany balik(y), muse se tim ale neco rozbit, nebo zustat sirotci

Odebrani sirotku (emerge --depclean) - no a jeste pak (emerge -avq --jobs=5 --load-average=10 -DuN world) pokud si chci byt jisty, ze jsem rucne nekomu nesebral zavislosti (nebo revdep-rebuild ktery projde zavislosti na knihovnach)

test nasucho (emerge -pv mplayer) jen vypise a skonci (Pretend Verbose) a pak si clovek muze hrat s flagama a zkouset what-if (USE="aalib dvdnav -pulseaudio" emerge -pv mplayer) dokud se mu nezda, ze to bude delat to, co chce a netahat zbytecne kraviny - pokud si je celkem jisty tak -avq je lepsi, kdyz to sedi, tak to rovnou muzes nechat provest

ty USE a podobne bud zadas z prikazove radky (nebo v prostredi), nebo centralne pro vsechny v /etc/portage/make.conf nebo jen pro jednotlive baliky, ci dokonce jejich verze (v podadresarich /etc/portage), stejne jako tam muzes zakazat, ci povolit instalaci nejakych baliku/verzi, ze neco muze jit i v non-stable verzi, ze neco ma mit konkretni USE flagy a tak - cili po case se ti tam nahromadi "zkusenosti", jak chces mit system ponastavovany a emerge to bere automaticky v uvahu - je to velike dobro (ale samozrejme to nemusis pouzivat)

Pokud jsou problemy s pripojenim, nebo tahas archivalie, tak (emerge -f cosi kdesi) pouze Fetchne zdrojaky, ale nepreklada, kdyz projde, vis, ze mas vse potrebne a ze kdyz prebudovavas system od zacatku na Rapsberry Pi (a bude to trvat cely vikend), tak ze se to nesekne na nenalezeni souboru jen co od toho odejdes

Co vsechno sis takhle navolil je ve /var/lib/portage/world (a kdyz to rucne upravis, tak to dalsi emerge world proste schrousta - cili si udelas i snadno zalohu), zavislosti dotazene automatisky tam samozrejme nejsou

Neni problem si udelat vlastni balicky, ktere bud neco delaji, nebo proste jen zavisi na tvych oblibenych vecech a pak to nainstalujes jednim prikazem (a zavislosti si to dotaha samo)

----

Jako casu to sice zabere vic (protoze to kompiluje), ale ty u toho pritom byt nemusis (pustis to prez noc, rano je vse hotovo).

Defaultni nastaveni je povetsinou pricetne a netreba ho menit, ale jde to, at jednorazove (jo, je psina v mplayeru mit moznost koukat na filmy i v ASCII artu, ale po case si clovek rekne, ze to vlastne mit nemusi) tak trvale (zeroconf je proste zhuverilost - kdyz neni sit, tak NENI, ne ze se vymysli nejaka falesna, ktera nefunguje, ale tvari se, ze tam je).

Takze na tvou dalsi otazku - ty flagy povetsinou nastavis poprve, kdy se ti neco znelibi, nebo chybi, a nechas je tak uz naporad, nebo dokud si to nerozmyslis. Nebo se na to vybodnes a ono to nejak samo v pricetnem defaultu. Proste podle toho, jak moc si s tim chces hrat a kdy si s tim chces hrat.

Instalace je pomala a je tam probirany kazdy krok, co a jak a proc a co se da zvolit, je to poprve poucne a pri dalsich instalacich uz tim jen listujes a hazes tam osvedcene veci, nebo tam mrsknes vlastni balicek, co vetsinu z toho nataha sam.

Sprava podobne - ze zacatku si zkousis, jak vlastne ma tvuj system vypadat, co se ti libi nahazes do konfiguraku a ono to tam zustane a kazdy update je o to jednosdussi, stejne jako to snadno zkopirujes do dalsi instalace. (Jo a samozrejme to mam verzovane v gitu, takze sam vidim co jsem kdy a proc menil, po letech bezchybne funkce to clovek oceni, kdyz stavi novou masinu)

Gentoo neni jednoduchy oklikator pro konvertisty z Windows, ale skutecne system, ktery si muzes detailne vyladit k obrazu svemu, pokud si das tu praci. A prubezna udrzba je po case trivialni, protoze uz sis davno vsechno nastavil.

[vencour]

Mimochodem napiš, co chceš na FreeBSD rozchodit, návody jsou, aby ses měl na čem učit. Pak když už víš, kde co a jak ladit, tak dáš i další programy/services.
Pro mne bylo asi největším zádrhelem zjistit/zajistit, jak sladit existenci balíčkových předpřipravených i ručně volených a kompilovaných programů po updatu.

[figliar0]

Ako píšem, na BSD ma odrádza to, že nie je nič ako rolling release KISS distribúcia pre pokročilých - aspoň na distrowatch som nič nenašiel. Ale BSD si odkladám ako takú rezervu, keď to s Linuxom dopadne zle (v akomkoľvek smere).

[vencour]

Pusť si to do virtuálu a ptej se, co potřebuješ. Já potřeboval nahradit Centos 6 a povedlo se.

[GeorgeWH]

FreeBSD v podstate je RR "distro" - kazdu chvilu nove verzie balikov a novy release systemu. A myslim, ze aj OpenBSD funguje podobne.

NetBSD je naopak stable, len so security opravami.

[figliar0]

Čo znamená "v podstate je RR distro"? Chvíľu som používal v práci Debian Testing (čo je tiež "v podstate je RR distro") a zdalo sa mi to v porovnaní s Archom také neohrabané - pacman má prehľadný výpis, kde hneď s fleku vidím, čo treba robiť - vo výpise apt-u som sa pravdu povediac strácal - vyhrabať z tade, čo skončilo chybou a čo treba vyriešiť mi prišlo strašne komplikované. Nehovoriac, že sa toho každú chvíľu updatovalo tony...

Mám zato, že skutočné rolling distrá myslia aj na to a majú vyriešené aj upozornenia na prípadné zmeny - alebo som len robil dačo zle, resp. som rozosratý z Archu?

[GeorgeWH]

Čo znamená "v podstate je RR distro"?

No ze tam mas v podstate najaktualnejsie verzie.

Chvíľu som používal v práci Debian Testing (čo je tiež "v podstate je RR distro") a zdalo sa mi to v porovnaní s Archom také neohrabané

debian testing som nikdy nepouzival, pretoze testing

pacman má prehľadný výpis, kde hneď s fleku vidím, čo treba robiť - vo výpise apt-u som sa pravdu povediac strácal - vyhrabať z tade, čo skončilo chybou a čo treba vyriešiť mi prišlo strašne komplikované.

ako neviem, co myslis pod prehladnym vypisom pri upgrade, ale pri upgrade freebsd portov, ti vypise, co sa bude upgradovat, co sa bude reinstalovat, co bude odinstalovane a co je v konflikte. po upgrade ti to k jednotlivemu balicku hodi info, co a ako nastavit (nie je to nevyhnutne). pri upgrade systemu ti tiez vypise, ktore subory sa budu upgradovat. v pripade upgradu na vyssi release sa robi merge konfiguracie.

Nehovoriac, že sa toho každú chvíľu updatovalo tony

pri RR je to hadam ok, nie?

Mám zato, že skutočné rolling distrá myslia aj na to a majú vyriešené aj upozornenia na prípadné zmeny

mam zato, ze zmeny si hlavne musis strazit ty sam sledovanim changelogov.

[figliar0]

v pripade upgradu na vyssi release sa robi merge konfiguracie

Automaticky?

pri RR je to hadam ok, nie?

Subjektívne sa mi to zdalo horšie, ako pri Archu (ale to môže byť tým, že Debian má programy rozdelené do viacerých balíkov).

mam zato, ze zmeny si hlavne musis strazit ty sam sledovanim changelogov

Za roky pri Archu som nič také nerobil. Pred updatom mrknem na web, kde sa môže vyskytnúť info o nejakých závažnejších zmenách. Po update mrknem výpis, kde vidím prípadné upozornenia, hlavne ohľadom potreby ručných mergov konfigurákov. Ak sa aj napriek tomu niečo poserie, mrknem na nejaký mailing list (čo treba tak raz za rok, ale závisí, čo všetko človek s tým distrom robí).

[GeorgeWH]

v pripade upgradu na vyssi release sa robi merge konfiguracie

Automaticky?

merge ponuka automaticky, ale rucne treba vybrat moznost. ale mozno to ide urobit nejakym nastavenim, neviem, neriesil som to este

pri RR je to hadam ok, nie?

Subjektívne sa mi to zdalo horšie, ako pri Archu (ale to môže byť tým, že Debian má programy rozdelené do viacerých balíkov).

ako neviem, v com je problem, updatne sa to, co sa ma a je to

mam zato, ze zmeny si hlavne musis strazit ty sam sledovanim changelogov

Za roky pri Archu som nič také nerobil. Pred updatom mrknem na web, kde sa môže vyskytnúť info o nejakých závažnejších zmenách. Po update mrknem výpis, kde vidím prípadné upozornenia, hlavne ohľadom potreby ručných mergov konfigurákov. Ak sa aj napriek tomu niečo poserie, mrknem na nejaký mailing list (čo treba tak raz za rok, ale závisí, čo všetko človek s tým distrom robí).

no ved to som mal na mysli. ale tu to treba rozdelit na system a porty. pri upgrade portov som fakt nic neriesil

[jiwopene]

Prý by mohl být zajímavý runit. Podle toho, co jsem slyšel to nevypadá špatně, ale zatím o něm moc nevím.

---

V současnosti používám Gentoo. Pokud máte nějaký novější/„výkonnější“ hardware (a ne Intel Atom jako já), kompilace balíčků není moc velký problém. Jako init používám OpenRC. Není to doslova init, ale prakticky všechno z sysvinitu řeší sám (vč. runlevelů).

• OpenRC má uživatelem definované pomenované runlevely — Zvolíte je volbou jádra softlevel= nebo za běhu
• Možnost, ale ne nutnost psaní skriptů à la SystemD:

  #!/sbin/openrc-run
  # Copyright 1999-2012 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
  
  #NB: Config is in /etc/conf.d/gpm
  
  command=/usr/sbin/gpm
  command_args="
          -m ${MOUSEDEV}
          -t ${MOUSE}
          ${RESPONSIVENESS:+ -r ${RESPONSIVENESS}}
          ${REPEAT_TYPE:+ -R${REPEAT_TYPE}}
          ${APPEND}
  "
  
  pidfile=/var/run/gpm.pid
  
  depend() {
          need localmount
          use hotplug logger
  }
  
  start_pre() {
          if [ -z "${MOUSEDEV}" ] || [ -z "${MOUSE}" ] ; then
                  eerror "You need to setup MOUSEDEV and MOUSE in /etc/conf.d/gpm first"
                  return 1
          fi
  }
  

• Vlastní příkazy (kromě start, stop, restart, zap, status, describe) — např. /etc/init.d/demon prikaz

Pokud chcete používat nějaké DE, asi budete muset nainstalovat elogind (jako LoginD). Musíte si dát pozor na to, že má snahu (stejně jako LoginD) uspávat při zavření víka a dělat další věci. Zkoušel jsem KDE, ale pořád zůstávám u i3-wm.

[figliar0]

Možnost, ale ne nutnost psaní skriptů à la SystemD

Nemyslel si náhodou a la sysvinit?

[Grunt]

Já pouze dodám, že Gentoo jako jediný systém, který znám (třeba to umí i některé binární distribuce, ale myslím si že je to fičura přímo závislá právě na kompilaci) je systém který ne že nabízí SystemD, ale nabízí ve výchozím stavu na výběr z několika Init systémů a ještě má na každý napsaný svůj manuál. Takhle jsem si to představoval soudruzi.

[luky]

V debianu si muzu vybrat mezi systemd, sysvinit a runit.

[Grunt]

Jako jo. Ne že ne. Ale je to spíš takové že systemd má by default a nebo se dá odinstalovat. Já bych z toho podobně jak v Gentoo udělal volbu (pamatuje si ještě někdo výběr výchozího prohlížeče ve Windowsech po kauze s Operou?) a nebylo by co řešit.

[figliar0]

Tak osobne si nemyslím, že je to fičúra závislá na kompilácii. Podľa mňa je to možné aj pri binárnych distrách, len na to treba dbať pri zostavovaní balíkov. Aj keď mám pocit, že sa všetci tvária, aké je to ťažké. IMHO stačí, aby balík z démonom obsahoval skripty / service súbory pre všetky podporované inity.

[jiwopene]

Určitě by se to dalo udělat prakticky stejně u jiných systémů, ale např. Devuan i přes zvolení OpenRC používá init skripty, které jsou psány „postaru“ (čistý shell, ne openrc-run). Pod binárním systémem by muselo být obrovské množství různých variant jednoho balíčku (s PulseAudiem, bez něj, pro SystemD, pro OpenRC, pro jiné, s X, bez X, …). Když vezmu třeba ffmpeg, tak tam je obrovské množství flagů a v binární distribuci by každý flag znamenal vynásobení počtu variant této verze tohoto balíčku číslem blížícím se 2 (2 to nemusí být, protože některé flagy spolu nemohou být nebo nedávají smysl). Pro binární distribuce je tento model víceméně nepoužitelný.

[figliar0]

Keby sme to obmedzili iba na problém rôznych initov, IMHO nebude potrebné viac variant jedného balíka. Skrátka bude balík s nejakou službou okrem binárky obsahovať rc skript aj systemd service file (prípadne ďalšie). Správca balíka sa postará o to, aby bolo v balíku všetko - podľa toho, ktoré inity daná distribúcia obsahuje (resp. podporuje).

[Josef Kufner]

V Debianu to takto je. Prostě je tam obojí. V /etc straší jeden zbytečný adresář, tj. buď /etc/init.d, nebo /etc/systemd , ale jinak to není nijak na škodu.

[figliar0]

No... nie vždy. Napríklad balík lighttpd to tak má, ale balík tftpd-hpa nie. Asi sa jasne neurčili pravidlá a každý správca si to robí po svojom...

[Fluttershy, yay!]

s6

[figliar0]

Len s týmto tu asi nie je veľmi veľký výber distier, či?

[Fluttershy, yay!]

Ten Obarun odkazovaný níže. Je to mírně upravený Arch Linux.

[figliar0]

Ale asi jediný... Ty ho používaš? Resp. aspoň s6?

[Věštec]

Len tak na okraj - dá sa nejako zistiť kedy presne bola urobená inštalácia?

12. listopadu 2011. You're welcome.

[Thyrst']

Obarun?

[figliar0]

Neviem - to ma nijako neupútalo - veď to nemá ani len stránku na wikipedii... Používaš?

[jiwopene]

dá sa nejako zistiť kedy presne bola urobená inštalácia?

Stačí najít soubor, který nebyl změněn od instalace. Může (ale nemusí) to být např. adresář /bin.

[figliar0]

Veď práve to je ten problém. Ako viem, ktorý nebol zmenený "od inštalácie"? /bin bol pred nejakým časom zmenený na symlink. Do úvahy prichádza /opt, kde som nikdy nič nemal, ale aj tam je mtime niekedy z 2013 (ťažko povedať prečo). Ja som si istý, že som inštaloval v 2011 (teda skoro istý).

Príkaz find / ! -newer /opt/ -printf "%Ty-%Tm-%Td %p\n" ukazuje aj staršie systémové súbory ako z r. 2011 (vrátane adresárov). Ten mtime bol uložený v tar archívoch pri zostavovaní balíkov...

[k3dAR]

pokud mas na rootfs ext4 a nepreformatoval/obnovoval_ze_zalohy od instalace, tak by to melo jit poznat z:

dumpe2fs /dev/tveho_rootfs | grep created

[Gilhad]

Tak ano, ale ja, se svym zvykem mit nekolik verzi systemu, vyladenych pro dana pouziti a rebootovat do nich podle potreby (da se pouzit slovo dualboot, kdyz jich mam na disku deset?) a nepotrebne casem likvidovat a menit partisny podle potreby i u aktualne pouzivanych, nemluve o tom, ze vetsinou i na novy stroj (o detailech jako vymemene CPU, grafarny, disku, zakladni desky a tak ani nemluve) pretahnu kdyz uz ne system, tak aspon vetsinu konfigurace ... no nektere systemy byly instalovane o nekolik stroju driv, nez ten, na kterem aktualne bezi a pravdepodobne z puvodni instalace tam postupne nezustal ani jediny nedotceny soubor (stejne jako se obmenuji bunky v tele - pry asi tak kazdych 7 let - a tak identita v podstate spociva v kontinualite, protoze z puvodniho zakladu nezustalo uz vlastne nic) - cimz uspesne prechazime od ciste techniky k ciste filosofii :)

[figliar0]

Podobne, ako píše Gilhad - systém prežil už výmenu disku, aj celého stroja. Čiže toto tiež nie je riešením.

[vencour]

Přidat do výběru? Nepřidat do výběru?

[vencour]

Tak přidáno. Vivat !SystemD.

[Bedňa]

Používam už niekoľko rokov antiX a trochu si ho tuním na obraz svoj. Nájdeš to na GitHube.

Som neskutočne spokojný a sráčov z RedHell sa môžem len smiať. Koľko už stál vývoj nepoužiteľného Waylandu a samosa rozjebávajúceho systemd? Ježiš kurwa jak ma tí čuráci serú, páč to človek občas niekde na skúšku nasadí, či to fakt náhodou nebude fungovať (v súvislosti z nejakým projektom kde konkrétne sa doporučuje nejaké distro), a ono nie, fakt sa to zas rozjebe samo od seba aby som na niečo šiahol.

Never čurákom to platí v IT, aj v živote, vždy sa spáliš.

[bigBRAMBOR]

zanadavej si, ulevi se ti, odhalis vsem pravdu...

[figliar0]

Z toho Antixu som trocha zmätený - je to alebo nie je RR? Píše sa o ňom ako o RR ale zároveň vychádzajú vydania s číslami verzií.

Píše sa tiež o ňom, že je založený priamo na Debian Stable, ale obsahuje nové verzie kernelu a aplikácií - čo teda preberá z Debianu?

[Bedňa]

Keď používaš stabilnú vetvu, tak tá vychádza vo verziách.

Ja osobne idem na desktopoch unstable a testing a tam je to rolling release. Momentálna situácia je taká, že Arch už oproti testing/unstable zaostáva vo väčšine balíčkov.

[figliar0]

Ako v aktuálnosti? Porovnávaš dúfam s Arch testing repozitárom...

[Atrament]

dá sa nejako zistiť kedy presne bola urobená inštalácia?

pacman tuhle informaci ukládá do logu:

head -n1 /var/log/pacman.log

[kralyk z abclinuxu]

$ head -n1 /var/log/pacman.log
[2009-05-25 20:50] installed filesystem (2009.01-1)

... koukám, že už mam ten systém taky nějakej pátek

[figliar0]

To bude ono! 25.12.2011 - trocha neskôr, ako by si pamätám, ale to musí byť skutočný údaj, pretože balík filesystem musel byť nainštalovaný (nie aktualizovaný) iba pri inštalácií celého systému.

[Franta]

Stále je tu taky Slackware. Jednoduchost: check. No a current v podstatě rolling release: check.

[figliar0]

No dobre! Až takú jednoduchosť som nemyslel! (To už sa radšej rovno vrhnem do toho Gentoo.)

[Migi]

Používám Debian, a ačkoli jsem fanda systemd (ulehčuje mi život, deal with it), právě v debianu ho používám jen a pouze jako init, protože na vše ostatní má debian své utility namísto ostatních modulů systemd.

[Tomáš Pelc]

Zeptám se takto: v čem je systemd tak špatné z praktického pohledu? Jsem spokojený uživatel mainstreamového distra a při každodenní práci nenarážím na žádné problémy.

Jak bych na první pohled - jako běžný uživatel - poznal, že používám distribuci s nebo bez systemd?

Jde mi o objektivní pohled, bez emocí.

Dík.

[j]

Uplne ve vsem?

Vezmemez jednu pidicast - logovani. Kupodivu od toho vetsina adminu ocekava predevsim to, ze ty logy jaksi budou (a pak samo jeste bambiliardy dalsi veci - to uz kazdy soudruh dle svych preferenci). Se systemd nejen ze nebudou ty dalsi veci, ale ony predevsim nebudou ty logy.

I kdyz vemes samotnej init, tak opet, kazdej admin cas od casu narazi na nejakou nestandardni vec, ktera nema zadny svuj script/konfigurak pro danej init, ale spusti se proste bashovym scriptem. Teda spoustela. Takovej script muze mit klidne i desitky tisic radku, a nikdy to nebyl problem. Uz je, protoze u systemd nikdy nevis, kdy ti do toho zacne hrabat.

Muzem pokracovat, screen je snami uz peknych par desetileti, a kazdej prece vi, ze kdyz potrebuje ... mno a se systemd to opet je rozbity.

A ted se rozhodli rozbit i desitky let pouzivanej system uzivatelu, a kvuli nim maji svy aplikace prepsat mililony vyvojaru?

----

Jo, muzes jit k windows ... tam je to jeste horsi, respektive ono vlastne uz moc ne. Logy to nikdy zadny nemelo, nastavit jakkoli spousteni cehokoli je naprosto nemozny a vubec si to cely dela vsechno tak nejak samo aniz bys to moh ovlivnit.

Takze jako user bud drzis hubu a spokojis se s tim jak to je, nebo mas smulu. A to je presne ten problem systemd = mas smulu.

---

Predpokladam, ze v brzky dobe nekoho napadne, ze by se systemd melo samo (mimo distribucni repo) aktualizovat, pak ze by to samo melo instalovat servisy, o kterych si to bude myslet ze by se userovi mohly hodit, pripadne odstranovat veci, o kterych ten kokot rozhodne, ze jsou nepodporovany .... jo a pak taky zavist nejakou tu samoserozesiraci registry databazi, to aby na vsechno mohlo bejt hento api.

A konecne v tom uz proti widlim nebude zadnej rozdil, protoze presne tohle delaj.

[Heron]

Vezmemez jednu pidicast - logovani. Kupodivu od toho vetsina adminu ocekava predevsim to, ze ty logy jaksi budou (a pak samo jeste bambiliardy dalsi veci - to uz kazdy soudruh dle svych preferenci). Se systemd nejen ze nebudou ty dalsi veci, ale ony predevsim nebudou ty logy.

Ano, journald měl na počátku hromadu problémů, ale asi většina je vyřešena. Stále si logy můžeš přeposílat jinam, v tomto se nic nemění. Co mi vadí je poměrně málo možností journalctl pro filtrování. Umí to jen OR nebo AND (a to ještě omezeně). Ale třeba to neumí vypsat logy od všech unit kromě těchto. (Tj vypnout si zobrazení logů od nějaké ukecané služby a nechat tam vše ostatní. Jasně, dá se to filtrovat v jiných programech.)

Takovej script muze mit klidne i desitky tisic radku, a nikdy to nebyl problem.

Což je přesně ten problém. Pokud nějaká služba potřebuje tisíci řádkový rc skript, tak asi nebude úplně v pořádku. Normální služba se jednoduše spustí jako binárka a vypne se po poslání signálu sigint.

Muzem pokracovat, screen je snami uz peknych par desetileti, a kazdej prece vi, ze kdyz potrebuje ... mno a se systemd to opet je rozbity.

screen obcházel problém, který ani nemusel existovat. Asi každý zná kombinaci nohup program &. Mnozí to dokonce doporučují dávat i do rc.local. Jen proto, aby nějaký proces přežil odhlášení uživatele (ignorovat signál hup). Pokud ten proces má běžet, má to být řádně zapsáno do init systému jako service. screen toho řešil pochopitelně mnohem víc, ale v zásadě stejnou věc. Jak spustit program (a uchovat jeho výstupy) a přežít odhlášení od terminálu. systemd nabízí řešení, jak tohoto docílit. Toto je systemd way, kterou používám pro start tmuxu. Je to moje user unita, takže si ji mohu upravovat. A díky tomu, že mi admin nastavil linger, tak to přežije i odhlášení. Tj. místo toho, aby tam běžely uživatelské procesy, které možná mají a možná nemají běžet, tak je to jasně definováno unitou. A všechno ostatní je zabito (KillUserProcesses=yes).

A ted se rozhodli rozbit i desitky let pouzivanej system uzivatelu, a kvuli nim maji svy aplikace prepsat mililony vyvojaru?

To byl jen návrh a proof of concept. Je jasné, že takto to nemůže fungovat obecně a v serverovém prostředí už vůbec ne, ani ten PoC nijak neřešil systémové uživatele, jen se zkoušel podívat na určitý problém uživatelských účtů z jiného úhlu pohledu. LDAP ti fakt nikdo nebere.

[Bedňa]

A už sa skurvené logovanie do blobov dá vypnúť?

Bohužiaľ s tou sračou občas prídem do styku a kľudne to jebne bez zistiteľnej príčiny, kdeje kurwa ten pokrok, toto som nevidel ani pred 15+ rokmi.

Skús si logind hodiť do svojho obľúbeného vyhladávača, ale neviem či im požiadavkou nejebneš servery dole.

Na to aby ti fungoval Tmux si musíš otvoriť Lennartovu modlitebnú knížku to je fakt paráda.

Jako neviem čo by som vypichol ako najväčší pokrok, to sú samé klenoty.

Si kámoš a chápem, že ty si admin v biznis sfére, kde proste človek nechce riešiť to a to pretože toto je in ... Ja to mám jednoduchšie, že si proste nasadím to čo chcem a aj túto kariéru čoskoro opustím úplne, páč ma bavia iné veci a konkrétne sa hrám s umelou inteligenciou. Nikto sa nepýta na čom to beží a ako, proste nevidím dôvod prečo tam zajebať nejaký moloch aby to neprežilo aj tisíc rebootov bez ľudského zásahu.

Boha jeho, kto nevie nastaviť sieť, ošetriť si proces, či z neho nelezú sračky by podľa mňa za svoju prácu nemal pýtať peniaze.

Áno systemd pokiaľ beží OK, vie skontrolovať, či niečo beží. Mno nijak neskontroluje, že ten démon produkuje hovná. Takže si to ošéfujem sám a to či vôbec beží je ten najmenší problém.

[Josef Kufner]

A už sa skurvené logovanie do blobov dá vypnúť?

Snad odjakživa šlo logy přesměrovat do rsyslogu a tím zachovat původní chování (na Debianu to byl dlouho default, nebo aspoň to tak zůstávalo po aktualizacích). Také jde v journald přepnout logy jen do paměti nebo i úplně vypnout (Storage=none).

[Heron]

A už sa skurvené logovanie do blobov dá vypnúť?

Pokud vím, tak ne. Ale dá se to přesměrovat.

Na to aby ti fungoval Tmux si musíš otvoriť Lennartovu modlitebnú knížku to je fakt paráda.

Nemusíš. Některá distra mají default KillUserProcesses=no (zkompilováno), u jiných si to můžeš nastavit v /etc/systemd/logind.conf. Potom ti bude fungovat vše jako dřív.

To, co jsem psal, je najít správnou systemd cestu. Používat to nemusíš. A důvod, proč jsem napsal: "nohup" řešení jsou ve skutečnosti jen workaround. To, že se tento workaround používal tak dlouho, že to někdo bere jako správné, je chybou. To, že něco funguje, ještě neznamená, že je to uděláno správně. A mít v systému jen tak naspawnované procesy, o kterých nevíš ani to, jestli mají vůbec běžet (protože jejich user se před měsícem odhlásil) nepovažuji za správné. Když se to uzavře do unity (resp do čehokoliv, co má nějaká metadata), tak je naprosto jasný kontext těch procesů a ty jako admin víš, co to je a proč to tam je. To, že je to zrovna dneska v systemd unitě pomocí system groups je čistě implementační detail. Klidně to mohl napsat někdo dřív nějak jinak.

Si kámoš

Dík.

si admin v biznis sfére, kde proste človek nechce riešiť to a to pretože toto je in

Já vůbec neřeším co je in a co je out. Vůbec. Pokud mám server, kde je systemd, tak to nastavím přes systemd. A funguje to. Když se budu tvářit, že tam systemd vůbec není (protože se mi nelíbí), a nastavím to jinak, zpravidla to nebude fungovat. Vidím to dnes a denně. Admin, který se tváří, že ho nějaký systemd nezajímá a nastavuje to jako před 15 lety, má neustálé problémy. Takže to vůbec není o tom co je in nebo není, je to zcela pragmatický přístup, abych si ušetřil co nejvíc práce.

Boha jeho, kto nevie nastaviť sieť

Někdy si udělej reality check. Stále ještě spousta adminů nedá dopustit na ifconfig a route. U některých nepomůže ani ukázka toho, že jejich nástroj nefunguje (stačí jedné iface přiřadit více adres, ifconfig vidí jen jednu, ip addr show vidí všechny). Někteří to dál ignorují a vesele používají to, co bylo obsolete už v době, kdy to vyzkoušeli poprvé.

Nehledě na to, že různé nástroje buď nefungují (NM), nebo nefungují v moderním prostředí (zkuste si do network-scripts dát hromadu rout, ipv6 apod.) To, že ty network skripty fungovaly v době, kdy tam byla jedna ip a jedna brána je moc hezké, ale dneska už to nestačí.

Mno nijak neskontroluje, že ten démon produkuje hovná. Takže si to ošéfujem sám a to či vôbec beží je ten najmenší problém.

Tohle se týká monitoringu a ano, ten je potřeba samozřejmě také.

[Bedňa]

Za toto ťa mám rád, že aj keď sa niekto vytočí, ty reaguješ rozumnými argumentami.

Nemusíme riešiť ani polopravdu:

Systemd is compatible with SysV and LSB init scripts.

Proste fajn nový init, nové pravidlá a ten zápis unit fakt nevyzerá zle.

Čo sa týka ifconfig, to je deprecated 10+ rokov a stále vznikajú návody kde sa spomína, prv som nadával, dnes už na to ani nereagujem

Pretože som tak trochu autista, tak ma štve že logovanie blobu dokáže na serveri spraviť väčší tórčr ako posielanie Xiek klientovi kde ide o skutočne požadovanú funkcionalitu, ale dobre zabudneme na to.

Čo je ale hlavný problém, že sa z Linux enviromnt v main streame stáva monolit, bez možnosti vymeniť hocijakú komponentu. Dnes si závažnosť tejto odobranej funkcionality málo kto uvedomuje.

Či už z technického, alebo filozofického hladiska boli tieto problémy tisíc krát rozobrané, tak to ani moc nechcem riešiť.

Prepáč, proste zbadám systemd a búcham ako atomofka. Proste samé zlé skúsenosti. Napr. aj v embedded systémoch máme systemd a neskutočne ma sere, že to neposiela čo má, pretože systemd začne jebať a tam ide o závažnejší problém, pretože, keď to nehackneš, tak to neupgradneš a upgrade od výrobcu raz za rok je k hovnu a po dvoch, troch rokoch už žiadny upgrade ani nepríde. V tých embedded systémoch beží úplne hovno bez možnosti vymeniť hocijaký HW komponent, načo tam vôbec nejaký univerzálny init vôbec je? Ževraj kvôli jednoduchému deploymentu, to čo je dnes za vývojárov? Systém ktorý je jednoúčelový, si nevie vývojár nastaviť na tých pár knižníc, na ten jeden procesor, na jednu zbernicu a vie že to proste nikto nemá šancu nič vymeniť. Ja tým maldým fandím, nech si všetko skurvia po svojom, našťastie Linux riadi pragmatický Linus a vydrží aspoň toľko čo ja a Linux enviroment si každý môže kutiť sám.

Nebaví ma a ani nechcem v živote riešiť veci ktoré sú mi proti srsti.

[Heron]

Za toto ťa mám rád, že aj keď sa niekto vytočí, ty reaguješ rozumnými argumentami.

Dík. No mě to nevytáčí. Já to spíš beru tak, že každý má svoji formu komunikace, kterou používá. Proto mi třeba ani nevadí poněkud necenzurovaný slovník diskutéra 'j'. Prostě je to jeho signatura.

Čo je ale hlavný problém, že sa z Linux enviromnt v main streame stáva monolit, bez možnosti vymeniť hocijakú komponentu.

To mě vadí taky. Osobně si nemyslím, že by byl nějaký větší problém přepsat libovolnou systemd komponentu, přece jen je to OSS, ale současně mi vadí to, že neexistuje (nebo se o tom nemluví) popis komunikace a propojení jednotlivých systemd komponent. Možná to používá nějakou interní sběrnici, možná rovnou dbus. Nevím. Pokud by to tak bylo a bylo by to dobře zdokumentované, tak by si každý mohl napsat vlastní implementaci něčeho. Spíš mě vlastně překvapuje, že se to neděje už dnes. Zdrojáky jsou dostupné.

Napr. aj v embedded systémoch máme systemd a neskutočne ma sere, že to neposiela čo má, pretože systemd začne jebať a tam ide o závažnejší problém, pretože, keď to nehackneš, tak to neupgradneš a upgrade od výrobcu raz za rok je k hovnu a po dvoch, troch rokoch už žiadny upgrade ani nepríde.

Dalo by se to více specifikovat? Co to přesně neposílá a jak to souvisí se systemd? Systemd tam padá (segfault nebo nějak jinak?) Celkově z toho popisu mám pocit, že jde o nějaké specifické zařízení, které navíc není výrobcem dobře podporováno (update jednou za rok?).

V tých embedded systémoch beží úplne hovno bez možnosti vymeniť hocijaký HW komponent, načo tam vôbec nejaký univerzálny init vôbec je?

No to se musíš zeptat těch vývojářů. Mě to taky, podle popisu, nedává smysl.

Ževraj kvôli jednoduchému deploymentu, to čo je dnes za vývojárov?

S deploymentem na, ještě k tomu vlastní, systém nemá systemd nic společného. Tohle jsou všechno výmluvy na vlastní neschopnost. Vidím to zcela jasně: "Nějaký nadšenec, zaměstnanec, kdysi dávno napsal systemd unity pro ten bastl. Tento borec odešel a nikdo další už to neumí napsat. Proto se to ani nezmění. 'Deployment' funguje, takže to budeme dělat na systemd, protože nic jiného neumíme." (Podobnost s realitou mnohých firem je čistě náhodná. )

Systém ktorý je jednoúčelový, si nevie vývojár nastaviť na tých pár knižníc, na ten jeden procesor, na jednu zbernicu a vie že to proste nikto nemá šancu nič vymeniť. Ja tým maldým fandím, nech si všetko skurvia po svojom...

Tohle mě neskutečně štve na hype kolem dockeru. Místo toho, aby se vývojář zamyslel nad tím, jaký bude výsledek jeho práce a cílil to na nějaký balíček nebo jednu binárku (v tomto fandím GoLangu), tak si zmastí docker image a je to. Bordel je schovaný uvnitř a nikdo tam nevidí. Ale zase, za tohle docker nemůže, tohle se dělo dřív i kolem javy. "Program" byla skrumáž jarů, nějaký startovací sh skript, miliarda libs ale hlavně, přibalený zcela konkrétní a roky zastaralý JRE, protože na systémovém to prostě nejede a nikdo nebude řešit kompatibilitu. Hrůza.

[Bedňa]

Dík. No mě to nevytáčí. Já to spíš beru tak, že každý má svoji formu komunikace, kterou používá. Proto mi třeba ani nevadí poněkud necenzurovaný slovník diskutéra 'j'. Prostě je to jeho signatura.

Ako to cítim, tak to zo mňa ide. Nejaký čas som sa krotil, pretože sme všade boli za trollov, ktorí všetko len kritizujú, teraz to vidím ako chybu, že sme sa dali zahnať do kúta. (Jasne, ja proste mám svoju signatúru :) )

To mě vadí taky. Osobně si nemyslím, že by byl nějaký větší problém přepsat libovolnou systemd komponentu, přece jen je to OSS, ale současně mi vadí to, že neexistuje (nebo se o tom nemluví) popis komunikace a propojení jednotlivých systemd komponent.

Ja by som to otočil, prečo keď niekde bol nejaký nepísaný štandard, tak sa systemd komponenta nesnažila včleniť do Linux enviroment? Používam všade antiX Linux a dosť vecí sa prebralo z Gentoo vrátane eudev a nie defaultného, ale predpripraveného OpenRC. Systemd vývojárov zaujíma len to ako pohltiť celý Linux enviroment a nie, že by snažili na niečo nadviazať, alebo s niekym spolupracovať. Načo, však RedHat to všetko zaplatí.

Dalo by se to více specifikovat? Co to přesně neposílá a jak to souvisí se systemd? Systemd tam padá (segfault nebo nějak jinak?) Celkově z toho popisu mám pocit, že jde o nějaké specifické zařízení, které navíc není výrobcem dobře podporováno (update jednou za rok?).

Proste zlyhá služba a systemd sa ju snaží znova nakopnúť a nenakopne. V logoch vidím ten problém, ale neviem prečo to nedokáže. Lennart by by určite vedel vysvetliť, kde všade okolo sú chyby s ktorými musí bojovať.

Načo je tam vôbec zložitý init je záhadou aj mne, keď by to všetko obslúžil jeden skript v Bashi a pracoval ako chcem.

hype

Toto je asi najväčší problém, na každej linuxovej konfe sú narvaní RH rečníci o tam aký je vynikajúci deployment v kontajneroch a všetko okolo zabezpeči systemd.

Falošný pocit bezpečia, odjebaná práca, proste "keď to nejede" tak jej dáme všetky práva. Ja som pred rokmi od Widiel utiekol k Linuxu kvoli tomu aký je a milujem ho. Nikto ma zatiaľ nepresvedčil, že Linux enviroment stojí roky za hovno a treba ho prekopať. To by skôr neschopní RedHat zamestnanci zaslúžili nakopať. Je tam aj veľa skvelých ľudí ktorí s tou ich politikou nesúhlasia, ale po tých je vidieť len kopec skvelej práce a moc sa o nich nehovorí.

[Heron]

Ja by som to otočil, prečo keď niekde bol nejaký nepísaný štandard, tak sa systemd komponenta nesnažila včleniť do Linux enviroment? Používam všade antiX Linux a dosť vecí sa prebralo z Gentoo vrátane eudev a nie defaultného, ale predpripraveného OpenRC. Systemd vývojárov zaujíma len to ako pohltiť celý Linux enviroment a nie, že by snažili na niečo nadviazať, alebo s niekym spolupracovať. Načo, však RedHat to všetko zaplatí.

To je podle mě trochu širší problém. systemd nikam nepřišel, nezačal nikoho vydírat "jestli nás nedáte do distra, tak vám utopíme koťátka". Jak už jsem to psal v jiném komentáři. systemd je velmi často "jednooký mezi slepými". Ale místo toho, aby přišla lepší implementace toho něčeho, tak se nasadil systemd. Velmi často salámovou metodou.

Ano, toto mi vadí taky, osobně mám raději otevřený přístup typu: nás systém nabízí toto a je jen na vás, zda to nasadíte, karty máme otevřené. Takhle lze přistupovat ke všem programům splňující nějaké API. Klidně si každý den používej jiný FS, nic se nezmění, protože všechny používají stejný VFS. Nebo DB splňující standard. Takže kdyby systemd byl jen další balíček v repu, který můžeš nebo nemusíš použít, bylo by to, za mě, čistější řešení.

Proste zlyhá služba a systemd sa ju snaží znova nakopnúť a nenakopne.

Osobně autorestart (restart-on-failure) nepožívám. Zdravé služby nepadají a pokud to spadne, tak chci vědět proč. Ale nemám problém ani s unitami, který restart-on-něco využívají. Prostě pokud to spadne, systemd to zaloguje a opět spustí. Pokud se ta service nespustí, tam tam má nastaven určitý počet opakovaní za určitý čas. Tj vadná služba může skončit vypnutá. Ale to není chyba systemd. Ta služba by především neměla padat.

V logoch vidím ten problém, ale neviem prečo to nedokáže.

No a ten problém (chybová hláška) je ze strany systemd? Asi by to chtělo více podrobností, pokud je možné jej zveřejnit.

Nikto ma zatiaľ nepresvedčil, že Linux enviroment stojí roky za hovno a treba ho prekopať.

To záleží, co konkrétně myslíš tím Linux enviroment. Sám za sebe můžu říct, že věci jako nastavení sítě (zrovna konkrétně sítě!!!) stálo vždy za prd a to i u serverových distribucí (vlastně nic jiného ani nedělám), kde by se dala automaticky očekávat velmi zvládnutá podpora mnoha ip, rout, bridgů, iface apod. Jako network-scripts v RHELu nebo interfaces v Debu snad ani nikdo nemohl myslet vážně. Serverový operační systém, který na síti vyrostl, neměl ani pořádné nastavení. Mimochodem, třeba u iptables už několik desetiletí (2 ) možnost si nastavit fw pomocí série příkazů a potom si to alespoň nechat uložit do startup skriptu. Tato možnost u sítě nikdy nebyla (tj nastavit si ip addr, ip route, ip link a potom dát něco jako ip save a uložit do na disk).

Opět, neříkám, že systemd to řeší nějak geniálně, ale sakra, stačilo by, kdyby někdo přišel s lepším řešením ve více takových různých oblastech a systemd by měl o hodně víc oslabenou pozici a jeho přijetí v různých distrech by vůbec nebylo tak automatické.

Ale jak jsem psal, mě se směr systemd taky nelíbí, zjistil jsem, že na FreeBSD je svět ještě normální a to včetně všech těch věcí, o kterých propagátoři systemd na počátku tvrdili, že ve starém initu "prostě nejdou". Ony "prostě jdou", akorát se o ně na Linuxu nikdo ani nepokusil. Ty zmiňované network-scripts nebyly udržovány dlouho před tím, než se vůbec o nějakém systemd-networkd začalo uvažovat.

[k3dAR]

Některá distra mají default KillUserProcesses=no (zkompilováno), u jiných si to můžeš nastavit v /etc/systemd/logind.conf. Potom ti bude fungovat vše jako dřív.

aby to bylo jako driv, je potreba vice, vim ze si na to reagoval ze u tebe ne, u me na xubuntu 18.04 nekde jo, nekde take ne, nezkoumal sem proc

[Heron]

vim ze si na to reagoval ze u tebe ne

Jak je vidět, reagoval jsem více obšírněji, včetně odkazu na návod.

[k3dAR]

jiste to je videt, ale v navodu neni videt potreba pouzit cmdline "systemd.legacy_systemd_cgroup_controller=true" ktere sem zminoval ze od jiste doby (nekde/nekdy) je potreba, aby tmux fungoval "jako driv"(=bez systemd nebo se starsi verzi systemd)

[Heron]

Ano, protože ten návod není o předstírání, že systemd neexistuje, ale o tom, jak to udělat v systemd správně (přičemž si nenárokuju, že toto je jediné a dokonce ani nejsprávnější řešení a trochu mě štve, že jako systemd hater tady musím obhajovat správnou konfiguraci; nechce to už konečně nějaký systemd lover vzít za mě?).

Jinak sám přece musíš vidět, že tvoje řešení není funkční. Sám jsi napsal asi 4 způsoby, jak se tvářit, že systemd neexistuje a potom ještě napíšeš "ze od jiste doby (nekde/nekdy)" to ne-funguje. Já chápu (skutečně), že tě nebo kohokoliv může štvát, že je potřeba dělat věci jinak, ale řešením skutečně není to je dělat špatně a navrhovat 4 různá řešení, které možná někdy fungují. Tak se buď na systemd vyprdněte jako Bedňa a používejte systém bez něj a nebo se to naučte dělat podle systemd. To neznamá, že ho musíte mít rádi. Já systemd rád nemám (což je složitější), ale to neznamená, že budu spravovat systémy horším způsobem. Jak už jsem psal jinde, server s distrem používající systemd nastavím pokud možno the systemd way, protože je to pragmatické a funkční a v soukromí používám FreeBSD (nejen) a nemusím nic předstírat.

[kralyk z abclinuxu]

nechce to už konečně nějaký systemd lover vzít za mě?

Je otázka, jestli někdo takový vůbec existuje...

[Heron]

Určitě jo, když jsem psal systemd hate komentáře (na root.cz), tak mě tam lidi běžně psali, v čem je systemd super a co všechno v předchozím initu nešlo a jak se strašně pletu. Takže bych čekal, že se někdo z těch stovek lidí najde a začne o systemd psát s chutí. (Toto je ironie.)

Ale vážně, někdo to fakt vemte. Rád se dozvím něco nového.

[kralyk z abclinuxu]

No, já osobně jsem "systemd lover" v tom omezeném smyslu, že mi dost vyhovuje ten základ systemd (tzn. init samotný) a jeho použití na desktopu a ve velmi malém mšřítku na serveru (čti: moje vps a podobné stroje). Nepracuju jako admin, takže v tomto ohledu ze mě nic moc nevypadne, a nemam kdovíjak v oblibě některé systemd věci mimo init, zejména journald se mi moc nelíbí. Tož asi tak

[figliar0]

Presne toto je racionálny a pragmatický prístup k terajšej otázke init systémov, s ktorým sa stotožňujem.

[k3dAR]

[...]Stále ještě spousta adminů nedá dopustit na ifconfig a route. U některých nepomůže ani ukázka toho, že jejich nástroj nefunguje (stačí jedné iface přiřadit více adres, ifconfig vidí jen jednu, ip addr show vidí všechny). Někteří to dál ignorují a vesele používají to, co bylo obsolete už v době, kdy to vyzkoušeli poprvé.

myslim ze 99% tech co pouzijou ifconfig bud nevedi/nepotrebuji ze vice ip priradit lze, nebo vedi ale i vedi ze maji k rozhrani prirazenu jen 1
osobne pouzivam ifconfig nejcaseji na zjisteni prirazene ip z dhcp, ten vystup je mnohem prehlednejsi nez z "ip a" kde to musim 10x dle hledat btw: prvne sem ifconfig vyzkousel ~5let pred tim nez ip/iproute2 vyslo v prvotni verzi, natoz aby byl obsolete

[Heron]

vedi ze maji k rozhrani prirazenu jen 1

Tj taková kladná zpětná vazba:

"Používám ifconfig, protože mám jen jednu ip." "Jak víš, že máš jen jednu?" "Protože to vidím v ifconfigu." (Jen rejpnutí.)

osobne pouzivam ifconfig nejcaseji na zjisteni prirazene ip z dhcp, ten vystup je mnohem prehlednejsi nez z "ip a" kde to musim 10x dle hledat

To už jsem slyšel několikrát. Asi je to o zvyku. Mě chybí adekvátní nástroj jako byl brctl. Ten výstup byl krásně přehledný. Dneska se bridge nastavuje pomocí ip link a pro zobrazení se dá použít nástroj bridge, ale ten výstup moc pěkný a hlavně názorný není. brctl jasně ukazoval tu hierarchii a bylo vidět, co je kam přiřazené. (Jasně, ale jen zjednodušený stav.)

[vencour]

Co má být s brctl? V gentoo pořád je, ono to koliduje s něčím od systemd?

[Heron]

brctl is obsolete.

Se systemd to vůbec nesouvisí.

[vencour]

No tak jo, tohle v aktuálním manu na lokále nevidim.
Děkuji za upřesnění. To skoro vypadá, že to bude stejně dlouho obsolete jako ifconfig?

[Heron]

No hele, na wiki máš přímo návod. (Gentoo neznám, takže nevím, jestli jejich brctl je ten brctl o kterém se bavíme, nebo nějaký workaround skript. Každopádně návod na převod brctl na moderní způsob je k disposici.)

[vencour]

No vidíš, a v instalační příručce je pořár brctl.
Takže dík za info, věřim, že se bude něco "vznášet ve vzduchu", nějaké změny, že i tady v Handbooku to bude aktualizované.

[xxx]

Pricina iproute2 a jeho nepouzivani je to, ze je spis referencni implementace Netlink rozhrani sitovani v jadre, nez uzivatelsky nastroj. Nad ip -h mozna zaplesa milovnik gramatik, ale rozhodne ne uzivatel, ktery potrebuje zjistit jake vlany ma na nejakem rozhrani.

[j]

"Áno systemd pokiaľ beží OK, vie skontrolovať, či niečo beží"

Az na to, ze nevie ... tak maximalne muzes zjistovat stav servisy (coz ostatne jiny inity umej taky), ale neumi (jak by moh) zjistit, jestli to vazne bezi. Jinak receno, mas informaci uplne knicemu. Co hur, ono ti to na zaklade ty informace knicemu jeste navic zasahuje do behu.

Pokud potrebujes zjistovat jestli neco bezi, tak na to stejne potrebujes dalsi servisu, ktera to bude umet.

[Heron]

No jenže tohle platí pro každý init systém. Neznám init, který by měl funkcionalitu ověřování třeba i jen nějakého výstupu, zda je to ok. Od toho jsou monitorovací systémy, kde si můžeš definovat akci, která se má provést, pokud nějaký check selže. Třeba monit (kdyby to nebyl výkal a kdyby fungoval).

Stejně tak si můžeš definovat novou unitu (třeba timer), která ti bude testovat něco v té tvé službě a v případě chybového stavu tu službu třeba zrestartuje. Vlastně si psát takový monitorovací systém skládající se z jednotlivých checků v jednotlivých unitách. Asi je to kravina, ale někdy bych chtěl vidět systém, kde někdo vzal systemd vážně "ad absurdum" a udělal tam desetitisíce závislých malinkatých unit. Taky by se tomu dalo říkat microservices .

[Cabrón]

Systemd to umí nativně

V [Service] můžete definovat watchdog interval, ve kterém musí spuštěná služba hladit pejska (voláním sd_notify), aby nezaštěkal. Když se to kousne, systemd celou cgroupu vymete a pokračuje dál podle předpisu (cooldown, restart).

V samotné aplikaci pak stačí zavolání sd_notify podmínit úspěchem selftestu, úplně stejně jako to dělá klasický watchdog(1), a máte vestavěný monitoring na světě.

[kolcon]

umi systemd poslat automaticky notifikaci (emailem), kdyz spadne nejaka sluzba, aniz bych to musel vsem pridavat do OnFailure?

[j]

"Což je přesně ten problém."

Ne, problem to neni vubec zadnej, existujou aplikace, ktery potrebujou pred vlastnim spustenim overit dostupnost a konfigurace desitek nebo i stovek jinych veci, stroju, jejich dostupnost atd atd. Jak bys to asi tak chtel delat? Ted se ti do toho nasere systemd, kterej to nekde v pulce utne protoze neco ...

Ad screen, zjevne meles o vecech o kterych nic nevis. Screen resi predevsim to, ze uzivatel CHCE spustit appku, ktera jako servisa NEBEZI, ale NECHCE(nebo nemuze) byt prihlasen hodiny, dny nebo tydny, nez to dobehne a kam jinam nez na fronend terminalu, vypise vysledek.

Joooo jasne, mame tu prece windows way ... nastavit autologin (jak jinak nez admina), a ono to prece pobezi.

Mimochodem, sem zvedav, jak si nonroot user bude nastavovat nejaky unity v ty sracce ...

"To byl jen návrh"

lol ... to urcite ...

[xxx]

To uz fakt nefunguje:

ssh server
screen
scp neco_velkyho.tgz jinej_server:/kamsi
CTRL-A CTRL-D
exit

a jestli fakt ne, co to dneska nahradilo?

[Heron]

Funguje.

[j]

Se systemd bez dalsiho nefunguje ... protoze kokot lennart usoudil, ze kdyz se user odpoji, je treba sestrelit vse co spustil.

https://duckduckgo.com/?q=systemd+kill+screen

A navic prohlasil, ze to samozrejme delaj blbe autori (nejen) screenu ... jak jinak.

[k3dAR]

btw: viz

[Heron]

Jak bys to asi tak chtel delat?

Rozdělit to na jednotlivé komponenty a definovat mezi nimi závislosti. Aby bylo zcela jasné, co spadlo. A definovat reakce na dané události. Už jen ten popis toho tvého systému volá na všechny strany, že je to špatně navržené. Protože to, že stroj, na kterém ti to závisí, běžel před 1s neznamená, že běží teď. Tj ta appka stejně musí počítat s tím, že nějaký závislý server bude nedostupný. Tedy ani když ten předstartovní skript zkontroluje milion věcí, tak to neznamená, že po jeho doběhnutí jsou stále ok. Atd.

Ad screen, zjevne meles o vecech o kterych nic nevis.

Jistě, protože mi vůbec neběží na několika stovkách serverů.

Screen resi predevsim to, ze uzivatel CHCE spustit appku, ktera jako servisa NEBEZI, ale NECHCE(nebo nemuze) byt prihlasen hodiny, dny nebo tydny, nez to dobehne a kam jinam nez na fronend terminalu, vypise vysledek.

V tom případě to může pustit jako unitu (systemd-run) a výsledek si přečíst v logu. Protože toto popsané řešení (které jsem několikrát v praxi taky viděl) je velmi křehké. Např. když se ten server někdy po vykonání té úlohy restartuje, tak user nevidí výsledek, protože ten jeho screen neběží. Kdyby to udělal pořádně, pustil na pozadí a logoval do nějakého logu, tak má výsledek vždy. A nemusí si jej jít přečíst na terminál, může jej najít v nějakém systému pro zobrazování logů nebo třeba v emailu.

[xxx]

V tom případě to může pustit jako unitu (systemd-run) a výsledek si přečíst v logu.

Coz je absolutne kokotskej pristup. Nutis uzivatele pouzivat slozitejsi reseni, jen kvuli tomu, ze resi problemy, ktere uzivatel nema.

[Heron]

Sám jsem byl svědkem toho, jak se někdo divil, kam mu zmizel "superdůležitý výstup" z něčeho, co měl puštěné ve screenu. V noci vypadla elektřina, server na ups se vypnul, potom zase zapnul a hle, screen nebyl. Takže si nejsem jist, zda tyto problémy uživatel nemá.

Jako já screen, dneska raději tmux, používám taky a rád a všude. Ale mám to pro interaktivní prostředí, 10 oken, dokončení rozdělané práce apod. Ale když se to vypne, tak se nic nestane. Fakt to nepoužívám pro úlohy, které běží přes noc s tím, že jejich výsledek je fakt nutný. Takové věci vždy nějak loguju. Alespoň program | tee output

Jinak já nikoho nenutím. Psal jsem může.

[Semo]

Sám jsem byl svědkem toho, jak se někdo divil, kam mu zmizel "superdůležitý výstup" z něčeho, co měl puštěné ve screenu. V noci vypadla elektřina, server na ups se vypnul, potom zase zapnul a hle, screen nebyl. Takže si nejsem jist, zda tyto problémy uživatel nemá.

Uzivatel, ktory pozna prikaz tee tieto problemy fakt nema. A sranie sa so systemd-unitou a tee pre jednorazove pouzitie je neporovnatelne.

screen obcházel problém, který ani nemusel existovat. Asi každý zná kombinaci nohup program &. Mnozí to dokonce doporučují dávat i do rc.local. Jen proto, aby nějaký proces přežil odhlášení uživatele (ignorovat signál hup). Pokud ten proces má běžet, má to být řádně zapsáno do init systému jako service. screen toho řešil pochopitelně mnohem víc, ale v zásadě stejnou věc.

...

to může pustit jako unitu (systemd-run) a výsledek si přečíst v logu.

...

Ale mám to pro interaktivní prostředí

Nejak si vzajomne odporujes. Najprv tu vsekym podsuvas, ze scren je dobry ta na krajsi "nohup" a ludia su blbci a maju na to pouzivat systemd a potom tomu priznas interaktivne pouzitie. Pretoze screen je dolezity pravepretu prerusenu interaktiviu - pre pokracovanie v interaktivnej praci v iny cas a z ineho pripojenia.

Ze sijes zabetovnovany v davkovom server svete je tvoja vec, ale tvrdit, zeto kazdmeu musi stacit, je zabednenost.

[Heron]

Najprv tu vsekym podsuvas, ze scren je dobry ta na krajsi "nohup"

Já jsem nikde nepsal, že screen je dobrý jen na kratší nohup! Já jsem jen popisoval, jak tento problém historicky vznikl. Potřebovalo se vyřešit běh programu na pozadí po odhlášení z terminálu. Program běžně reaguje na signál hup tím, že se ukončí. Potom někoho napadlo, že budeme hup ignorovat a odpojíme se od řídícího terminálu. Tím získáme proces, který měl původ v terminálu, ale dokázat se od něj odpoutat. Takže teď máme v systému proces, který nemá žádný kontext, nikdo neví jak a proč vznikl a zda má vůbec běžet. A toto jsem nazval workaroundem. A systemd čisté řešení je zabalit si screen / tmux do unity, aby byl znám kontext (kdo, kdy, ano má to běžet atd.).

Takže screen / tmux je v pohodě, proti tomu jsem nic nepsal. Jen jsem upřesnil, jak by měl startovat, aby to nebyl volně plující proces prostorem.

Takže mi nepodsouvej něco, co jsem nenapsal.

A ano, screen nijak nezajistí, že člověk uvidí výsledek nějakého procesu, takže proto je dobré u dlouho běžících procesů s důležitým výstupem zajistit, aby se ten výstup neztratil. Možností je víc, systemd-run to napíše do logu, výsledek si lze uložit do souboru, poslat emailem apod. To byla jen připomínka, že i ve screenu se ten výstup může ztratit.

Jinak pro interaktivní práci, si to vesel používejte, je to skvělý nástroj.

[j]

A v logu, specielne tom v systemd, se vubec ztratit nemuze ... zapisovat neco timhle zpusobem do logu funguje asi tak stejne jako > /dev/null (ale vubec bych se nedivil, kdyby kokot lennart prisel s tim, ze zapisy do /dev/null bude logovat)

"nikdo neví jak a proč vznikl a zda má vůbec běžet"

lol, tohle myslis vazne ty admine? OK, ps mi prave vypsal nejakych par set procesu spustenych par desitkama useru, du je postrilet, proc by vlastne mely bezet, kdyz nikdo nevi ... kupodivu, nejakym zazrakem, u kazdyho jednoho procesu vidim uzivatele, pod kterym bezi. A je mi lautr uprdele, jestli ten uzivatel je zrovna pripojenej nebo neni. Az bude jeho proces delat neco co se mi jako adminovi nebude pozdavat, tak mu mozna zavolam, a mozna mu ho i strelim (a jak sem uz rek, je mi sumak jestli je dotycnej pripojenej nebo ne). Ale je to moje rozhodnuti, do toho nema zadnej system(d) co kecat, protoze vi lautr hovno jestli neco bezet ma nebo nema.

BTW: Mel bys jit do M$ vysvetlit, ze sou vlastne uplni kreteni, protoze nechavaji bezet uzivatelem spusteny aplikace i v pripade, ze se uzivatel odpoji (tvle, zrovna na to koukam, moje rdp session uz zije 3ti mesic). Teda pokud administrator nerozhodne jinak. Jo a nejakym zazrakem je to bydefault chovani ... zjevne je treba to honem zmenit, a okamzite po odpojeni od rdp strelit vse, co tam user mel.

[j]

"Rozdělit to na jednotlivé komponenty a definovat mezi nimi závislosti"

lol ... tak to urcite ... japak trebas takhle zjistis, ze rekneme SQL bezi a ze je prislusna databaze dostupna. Celkem jedno jestli lokalni nebo vzdalenej ... uz se tesim. Pochopitelne prostredky systemd, jak jinak ... a podle toho provedes konkretni akci.

Normalne se toho resi mnohem vic, ale necham ti to jednoduchy.

"V tom případě to může pustit jako unitu"

Ty ze neco adminujes? Fakt? V tom pripade bych te nechal zastrelit driv, nez reknes dobry den.

[trekker.dk]

V tom případě to může pustit jako unitu (systemd-run) a výsledek si přečíst v logu.

A vstup do toho programu mám taky zapsat do toho logu, že si ho odtud aplikace přečte?

[m.]

Mimochodem, sem zvedav, jak si nonroot user bude nastavovat nejaky unity v ty sracce ...

systemd/User

[trekker.dk]

screen obcházel problém, který ani nemusel existovat. Asi každý zná kombinaci nohup program

To vážně považujete screen a nohup za ekvivalentní?

systemd nabízí řešení, jak tohoto docílit. Toto je systemd way, kterou používám pro start tmuxu

Jak už tady bylo mnohokrát zmíněno, kdysi bylo považováno za standard nabízet nové věci, ale nerozbíjet ty stávající.

[Heron]

To vážně považujete screen a nohup za ekvivalentní?

Z dalších komentářů je snad dostatečně patrné, že nikoliv.

Jak už tady bylo mnohokrát zmíněno, kdysi bylo považováno za standard nabízet nové věci, ale nerozbíjet ty stávající.

No jednak je to věc nastavení distribuce a existují distribuce, které mají nebo měly zkompilováno (tj ani ne v konfiguráku) KillUserProcesses=no. Tedy pro uživatele dané distribuce se nezměnilo vůbec nic. Pokud to ta distribuce neměla takto zkompilováno ani explicitně nastavené v konfigu, tak si to admin mohl nastavit. Tedy buď se nic nerozbilo, nebo se to velmi snadno přivedlo do předchozího stavu.

Jinak přístup nic nerozbít taky znamená být zabetonovaný v minulosti. Tento mindset předpokládá, že, tak jak se to udělalo napoprvé, je prostě správně a nikdo další v budoucnu už to nesmí rozbít. Málo co je uděláno dobře hned na poprvé. Proto je dobré to změnit.

Ale uznávám, oba přístupu jsou legitimní. Osobně na nějakou dlouhodobou kompatibilitu kašlu (pochopitelně s podmínkami, že přechod na novou verzi bude mít minimální náklady, bude zajištěno přechodové opatření a bude to ohlášeno transparentně a dlouho dopředu) a nevidím moc výhod na tom si v jistém nejmenovaném OS pustit 20 let starý exáč a on fakt funguje, jenže s tím, že si ten OS táhne s sebou všechny možné quirky, aby to fungovalo.

[kralyk z abclinuxu]

Jinak přístup nic nerozbít taky znamená být zabetonovaný v minulosti. Tento mindset předpokládá, že tak jak se to udělalo napoprvé, je prostě správně a nikdo další v budoucnu už to nesmí rozbít. Málo co je uděláno dobře hned na poprvé. Proto je dobré to změnit.

Oj, tak teď sis dovolil hodně.

[trekker.dk]

Jinak přístup nic nerozbít taky znamená být zabetonovaný v minulosti.

Tohle je prostě a jednoduše lež. Srovnejte si třeba vývoj systemd s vývojem kernelu.

[Heron]

No jeden projekt ke změnám přistupuje s větší odpovědností a důkladnějším zamyšlením a jiný s poněkud ukvapenějším přístupem. Ale to na tom nic nemění. I ten nejodpovědnější návrh nemůže vyřešit v první verzi všechny problémy světa, takže nutně přicházejí změny. A pokud nechceme nic rozbít, tak to znamená podporovat předchozí řešení a vedle něj postavit nové. To znamená, že do budoucna je potřeba podporovat oba způsoby, starý i nový. Takto to přibývá s časem a je nutné udržovat stále víc a víc "legacy" věcí. To, že některé projekty toho na sebe nabalují méně (nebo to spíše nějak zvládají udržovat všechno), je moc hezké, ale to na věci nic nemění. Proto si myslím, že je zdravé jednou za čas udělat pořádek, označit věci, které v další verzi už nebudou a nechat čas na přechod.

[trekker.dk]

Takže nic nerozbít znamená být zabetonovaný v minulosti, ale vlastně to neznamená být zabetonovaný v minulosti. Hm.

[kralyk z abclinuxu]

IMO je to do značný míry otázka zdrojů. Čím je projekt slavnější / čím víc peněz se do něj leje, tím víc si může dovolit zachovávat zpětnou kompatibilitu, platit vývojáře za údržbu stávajícího a legacy kódu a testovat.

[j]

"No jednak je to věc nastavení distribuce a existují distribuce, které mají nebo měly"

Az na ten detail, ze o tyhle "drobny" zmene soudruh lennart nikoho neracil informovat (nebylo to uvedeny ani v zadnym changelogu), a vydal to jako novou verzi. Na to jakej je to pruser se prislo az potom, co si to lidi aktualizovali. A nebylo to ani poprvy ani naposled.

A o tom betonovani minulosti bez vypravet Linusovi, ten uz pakrat podobny lidi ktery neco nekde rozbili kopnul mezi pulky. Ostatne poslal doprdele i systemd s jejich pozadavkama na zmeny fungovani kernelu.

Ve widlich si 20 let starej exac nepustis. V linuxu kupodivu jo.

[Heron]

Az na ten detail, ze o tyhle "drobny" zmene soudruh lennart nikoho neracil informovat (nebylo to uvedeny ani v zadnym changelogu)

https://github.com/systemd/systemd/blob/master/NEWS

CHANGES WITH 230, Fairfax, 2016-05-21

A o tom betonovani minulosti bez vypravet Linusovi, ten uz pakrat podobny lidi ktery neco nekde rozbili kopnul mezi pulky.

No však já vím, ale toto přece podporuje argument zabetonování v minulosti. Někdo chtěl změnu a Linus řekl ne. Tj ten dotyčný se na to mohl buď vykašlat úplně a podpořit tím zabetonování, nebo se mohl zamyslet jak tu změnu udělat a nic nerozbít (na tom není nic špatného, jen to vyžaduje více času a prostředků), nebo vytvořit nové volání, kde implementovat tu danou věc (tj přidat víc práce s údržbou do budoucnosti). V praxi se používají asi všechny tři metody, každopádně dvě z nich vyžadují větší prostředky a jedna z nich více práce do budoucnosti.

Ve widlich si 20 let starej exac nepustis.

Vytáhl jsem CD z časopisu CHIP 1999/2 a spustil na nejnovějších W10 nějaký exáč z roku 1998. Bez problémů. Moje programy z Delphi z roku 2000-2001 fungují též.

[sigma]

Ve widlich si 20 let starej exac nepustis. V linuxu kupodivu jo.

Pokud to bude "exac" udělaný správně linux-way, tj. s maximálním využitím sdílených knihoven, a ne statický build, tak si každý snadno může zkusit, jak dopadne. U netriviální aplikace skončí už na libc.

Na posledních Windows pro některé zákazníky provozujeme binárky z dob Windows NT (1997) bez úprav a funguje to.

[johnyK]

sam si odpovidas, NIC SE NEZMENILO. ... tedy ani k lepsimu.

[figliar0]

Objektívne nedokážem povedať, či je systemd zlé. Ako som písal - nie som nijaký systemd-hater. Na pracovnom laptope mám Linux Mint (a systemd), na serveroch mám Debian (a systemd). V dohľadnom čase ani jedno z tých dvoch nehodlám meniť.

Na Linux som prešiel (okrem iného) kvôli filozofii unixového systému. Subjektívne sa mi taký systém páči. Ak to so systemd pôjde takto ďalej, celý systém bude zložený z: kernel, GNU, balíčkovací systém a systemd (ktorý nahradí všetko ostatné). A to sa mi nepáči.

Jasné - ja si môžem doinštalovať kadejaké alternatívy za jednotlivé komponenty systemd a systemd používať iba ako init (ako tu bolo spomenuté). Ako som ale písal, modularita systemd sa v praxi veľmi neuskutočňuje - v Archu konkrétne nemám systemd rozdelený do viacerých balíkov s možnosťou niektoré neinštalovať (je to snáď inde lepšie?). A navyše - čo konkrétne mi systemd prinesie, ak ho budem používať iba ako init (v zmysle - prečo si mám vybrať práve systemd)?

Skrátka sa mi predstava molocha systemd nepáči. Oveľa viac sa mi páči predstava malých utilitiek vykonávajúce samostatné úlohy. Je to síce môj subjektívny názor, ale tento koncept systému je preverený a má viacero racionálnych výhod.

[R]

Nic z GNU tam nebude, systemd to nahradi. Namiesto balickovacieho systemu bude nejaky snap, flatpak alebo nejaka ina sracka, ktora bude do systemd integrovana.

[k3dAR]

v tom budoucim OS sYsTeMd/Linux bych cekal kontejnerovej balickovac zalozenej na systemd-nspawn

[Heron]

V blogu nepíšeš, co ti na systemd konkrétně vadí. Jen obecně to, že toho umí čím dál tím víc. Řeknu ti jedno, ono to prostě funguje. A to jsem mnohými považován za systemd hatera.

Problém je, že na systemd není často návod, jak to dělat "the systemd way". U některých článků laik nepozná, že je to napsané blbě a prostě to tak udělá. Zkušenější admin už vycítí, že článek o něčem v systemd je napsaný blbě (nebo je blbý ten postup), ale už třeba nenajde jak to udělat správně. (Ale tohle se netýká jen systemd. IT je až podivuhodně setrvačné a konzervativní, takže věci před 20 lety označené za obsolete se stále používají.)

Tím neříkám, že v implementaci systemd nejsou občas chyby. Jsou a sám jsem o tom napsal spoustu komentářů. Ale řešení není ohýbat systemd a tvářit se, že tam není (což často radí různí "admini" v komentářích), ale naopak, zkusit jej používat co nejvíce.

Takže z mého osobního admin pohledu: systemd-networkd prostě funguje. systemd-timesyncd (timedatectl) prostě funguje. Kdo potřebuje mít třeba lepší statistiky, jak dobře je čas synchronizovaný, může použít ntpd. Krom speciálních případů napojení na státní etalon času toto není potřeba. Tj ano, u některých serverů máme ntpd s lepšími stats, ale na zbytku je timedatectl set-ntp true a čas je synchronizován.

Místo psaní kravin do rc.local (což mnozí dodnes radí - mimochodem, nedávno jsem narazil na případ, kdy někdo radil dát do rc.local sérií příkazů sysctl pro nastavení čehosi. Přitom sysctl má vlastní nastavovací adresář /etc/sysctl.d/ - takže ta rada byla špatně nejen z pohledu systemd, ale dokonce i z pohledu toho, co chtěl dotyčný docílit) je lepší si napsat několik velmi jednoduchých unit typu oneshot service. A admin má okamžitě přehled, co konkrétně z původního "rc.local" selhalo. Uživatelé si mohou psát své vlastní unity do své vlastní user instance systemd a mít tak vlastní služby po loginu.

Atd. Já neříkám, že systemd je nejúžasnější věc na světě, to rozhodně není, ale musím zcela objektivně uznat, že to co dělá, dělá často líp, než jiné řešení. Velmi často je to "jednooký mezi slepými," ale to spíš ukazuje, jak blbě jsou předchozí programy napsané.

Jinak já osobně jsem na serveru přešel na FreeBSD. Systemd není jediný důvod. Je to jen zástupný problém. Zkusím to ve stručnosti vysvětlit. S příchodem systemd mnozí říkali, že se konečně vyřeší bordel v rc skriptech služeb. Že konečně bude s programem distribuována jedna service unita a díky možnostem (simple, exec, forking) to konečně bude jednoduché a bude v tom pořádek. Samozřejmě, že se tak nestalo. Protože lidi, kteří neuměli psát rc skripty pro své služby, tak stejně tak neumějí psát unity. Problém vůbec není v initu nebo systemd. Takže dneska je v některých unitách podobný bordel, jako dříve v rc skriptech a někteří se vyžívají v ExecStartPre, ExecStartPost a volají tam sáhodlouhé skripty, které "cosi" nastaví pro běh služby. Nic se nevyřešilo, blbě napsaná služba má blbou unitu stejně jako dříve měla blbý rc skript. Ano, někdo může říct, že pro dobře napsanou službu je service unita jednoduchá (výchozí typ simple a jeden řádek s ExecStart), což je pravda, ale rc skript nebyl o moc komplikovanější (jen template a nastavený jeden řádek pro start).

A při používání FreeBSD mám pocit, že u toho fakt někdo přemýšlel. Init system to má napsaný v bashi, ale není v tom bordel. Různé systémové příkazy jsou ve skutečnosti jen různá volání různých Makefile, ale není v tom bordel. Využívají se dávno napsané primitivní programy. Implementace nových funkcí (často uvádím za příklad jaily) jsou implementované i v tom bash init skriptu velmi jednoduše. Zkrátka ten base system je velmi unixový. Pochopitelně s programy "třetích stran" to tak slavné není. Spoustě portů chybí i základní závislosti na knihovnách a pro blbě napsanou službu je blbý rc skript (často jen ohnutý z linuxu). Takže ani tady se zázrak nekoná.

[kralyk z abclinuxu]

Hezky shrnuto. Přijde mi, že tohle vystihuje situaci naprosto přesně a bez zbytečné dramatizace, která je jinak v diskusích okolo systemd všudypřítomná...

[johnyK]

považován za systemd hatera.

to mas pravdu a sam sem posledni dobu prekvapen, jakou promenou si prosel. Moc dobre si ty tvoje komentare jeste pamatuji a fakt me pri cteni tvych soucasnych komentaru k systemd napadlo, jestli nam Herona nevymenili (abychom byli aktualni, tak reknu, ze si myslim, ze jsi podepsal asi nejakou 'pro-systemd chartu' )

S příchodem systemd mnozí říkali, že se konečně vyřeší bordel v rc skriptech služeb. Že konečně bude s programem distribuována jedna service unita a díky možnostem (simple, exec, forking) to konečně bude jednoduché a bude v tom pořádek.

Tak, o to presne jde. Ale inzenyri (ne lide jako Poettering) na tohle maji takove osvedcene reseni- rika se tomu 'normy'.

[Heron]

to mas pravdu a sam sem posledni dobu prekvapen, jakou promenou si prosel

Tak proměnou. Hele, všechno, co jsem psal, byla ve své době pravda (resp asi ne všechno, jistě se mohl najít případ, že jsem měl chybné informace z nějakého článku - proto to teď taky píšu, mnoho článků o systemd (nejen) jsou zavádějící). Jurnal se rozbíjel naprosto pravidelně, verify neprošla většina souborů, bylo to extrémně pomalé (někdo místní tehdy poslal odkaz na opatchovaný journalctl, který byl mnohokrát rychlejší) apod. Sám jsem narazil na chybu, kdy se krátce běžící úlohy do logu nezapisovaly (resp ano, zapisovaly se, ale bez tagů _SYSTEMD_UNIT apod.) jen tato chyba mě stála cca jeden víkend ladění mého programu. Nakonec jsem přišel na to, že to v tom logu je, ale bez tagů. Dodnes to nemají vyřešeno.

Ale snažím se být objektivní. Tj pokud se mě někdo zeptal na to, jak nastavit nějakou systemd věc, tak jsem mu poradil bez ohledu na filozofii. Tj sice nesouhlasím se směrem, kam se systemd v linuxu ubírá, ale to neznamená, že někomu neporadím, jak si nastavit unitu. Protože šířit chybné informace té věci stejně nepomůže. Takže pokud někdo chce, tak si může nastavit síť třeba i s pomocí mého návodu bez ohledu na můj názor.

No a taky mám na uklidnění FreeBSD .

Ale inzenyri (ne lide jako Poettering) na tohle maji takove osvedcene reseni- rika se tomu 'normy'.

Tohle jsem asi nepochopil, podle mě jsou normy skvělá věc. Na tomhle vyrostl celý průmysl.

[Josef Kufner]

Moje zkušenost se Systemd je taková, ze nejvíce problémů bylo právě s init scripty a kompatibilitou se starým SysV initem. Jakmile se zpackaný initscript přepsal do systemd unit, tak to začlo fungovat a problémy přestaly. A hlavně je teď jasné, zda služba běží či nikoliv.

Ze začátku bylo Systemd hodně o nervy a plné bugů. Teď už to je v pohodě a věci fungují tak, jak by to člověk čekal (a nebo jsem si už zvyknul). Občas někde něco chybí nebo je pořešené trochu nečekaně, ale celkově bych řekl, že přesun k systemd byla změna k lepšímu.

Například konfigurace sítě s dvěma WiFi kartami, dvěma instancemi hostapd a jedním bridgem je při čistě systemd + networkd řešení mnohem čistší a spolehlivější, než při použití init scriptů. Neskutečně dlouhou dobu jsem řešil že se občas něco nechytlo, nenastavilo, nebo že se bridge rozpadl, když z ní hostapd vyhodil síťovku. Teprve když jsem všechny rádby uzitečná udělátka (kteréa právě pomáhala s tím, co SysV initscripty nezvládaly) vyházel a povypínal a napsal si čisté unity pro hostapd, firewall, dhcpd i konfigurace sítě, tak to začlo fungovat spolehlivě.

[Heron]

Moje zkušenost se Systemd je taková, ze nejvíce problémů bylo právě s init scripty a kompatibilitou se starým SysV initem. Jakmile se zpackaný initscript přepsal do systemd unit, tak to začlo fungovat a problémy přestaly. A hlavně je teď jasné, zda služba běží či nikoliv.

Moje zkušenost je zcela stejná. Taky jsem pár unit musel napsat sám. Jenže admin tady není od toho, aby opravoval rc skripty nebo psal chybějící unity. Za distribuci nebo autora toho balíčku.

Například konfigurace sítě s dvěma WiFi kartami, dvěma instancemi hostapd a jedním bridgem je při čistě systemd + networkd řešení mnohem čistší a spolehlivější, než při použití init scriptů.

Já sice nemám wifi karty, ale mám několik bridge pro kontejnery a nastavit nový bridge v systemd je hračka. Stejný ini like formát, jako pro všechno ostatní, konfigurace sítě na pár řádků.

teprve když jsem všechny rádby uzitečná udělátka (kteréa právě pomáhala s tím, co SysV initscripty nezvládaly)

Opět stejná zkušenost. Když jsem z debianu vyházel většinu těch jejich "helperů" pro service a ifupdown a update-rc.d apod, tak to najednou začalo hladce fungovat. Ale tj x let zpět. Asi bylo lepší přejít na jiné distro (třeba arch) a nepárat se s debianními skripty na všechno.

[xxx]

Atd. Já neříkám, že systemd je nejúžasnější věc na světě, to rozhodně není, ale musím zcela objektivně uznat, že to co dělá, dělá často líp, než jiné řešení. Velmi často je to "jednooký mezi slepými," ale to spíš ukazuje, jak blbě jsou předchozí programy napsané.

S timhle nesouhlasim. Ostatni inity jsou napsane dobre. Jen proste zastaraly. Nereflektuji nastup desktopu, kde se rozbiji klasicky pristup root vs. user. Stejne tak spousta sluzeb zeslozitelo.

Systemd se s tim jako prvni pokusil neco poradne udelat. Ale logicky musel narazit, protoze spousta problemu ma puvod v jadre (resp. v navrhu OS). Takze misto silenych wrapper skriptu se objeuvuji silene konfiguracni volby unit, atp.

FreeBSD si muze dovolit mit hezky init, protoze nemusi diky svemu nizkemu a vice specifickemu rozsireni resit spoustu problemu.

[figliar0]

Stručne. Ja netvrdím, že systemd nefunguje. Tak ako píšeš nižšie o FreeBSD - potrebujem len niečo na upokojenie. Momentálne to vidím ako odchod od systemd - i keď stále v rámci Linuxu.

[deda.jabko]

Velmi často je to "jednooký mezi slepými," ale to spíš ukazuje, jak blbě jsou předchozí programy napsané.

Systemd umi byt taky hodne kreativni, jak veci udelat spatne.

Existuje uz treba nejaky inteligentni zpusob, jak z journalu odstranit vybrane coredumpy bez toho, aniz bych musel odrolovat i zbytek logu?

[Heron]

Systemd umi byt taky hodne kreativni, jak veci udelat spatne.

To zcela nepochybně.

Existuje uz treba nejaky inteligentni zpusob, jak z journalu odstranit vybrane coredumpy bez toho, aniz bych musel odrolovat i zbytek logu?

Nevím.

[KOLEGA]

journactl --help

-S --since=DATE Show entries not older than the specified date -U --until=DATE Show entries not newer than the specified date

A ma to tu vyhodu, ze to je rychly!

[deda.jabko]

journactl --help

-S --since=DATE Show entries not older than the specified date -U --until=DATE Show entries not newer than the specified date

Jestli je to reakce na muj dotaz:

Existuje uz treba nejaky inteligentni zpusob, jak z journalu odstranit vybrane coredumpy bez toho, aniz bych musel odrolovat i zbytek logu?

Tak to nic neresi.

Problem je, ze pokud mas segfaultujici sluzbu (napr. chyba v PHP) nebo proste jen vyvojarsky stroj, kde segfaulty jsou bezne, tak mas core dumpy ulozene v zurnalu. Z ceho plyne, ze bud ti brutalne narostou logy (gigabyty) nebo ti to vytesni uzitecne informace, pokud tam mas nastaveny limit na velikost zurnalu.

[⧠ A = 0]

Já jsem se minulý týden začal učit OpenBSD. Důvod: (pravděpodobně) kvůli systemd už i debian začíná stát za h*vno.

[_]

devuan

[Leinad]

systemd není init daemon, ale kolekce softwaru podobně jako GNU, obsahující jako jeden z programů init daemona

[Max]

Myslím si, že kdo se chce věnovat Linuxu, tak by před systemd neměl utíkat. Člověk se s ním setká všude. Lepší se tedy vycvičit na sobě, než pak někde v produkci.

Jinak za mně musím říci, že se systemd nemám problém. Možná je to tím, že jedu vše distribučně, nebo prostě mám štěstí, že nenarazím na nějaké problémy jako jiní.
Zdar Max

[V.]

Co to slyším, linux je systemd? Kéž Tě svatý tučňák nepotrestá hned ...

[Max]

Myšleno tak, že nejpoužívanější distribuce jedou systemd.
Zdar Max

[PetebLazar]

Existuje něco jako oficiální Systemd Concepts?

[Max]

Nerozumím, můžeš upřesnit? Všude se systemd používá stejně, jen některé distribuce ho obalují svými tooly, ale standardní ovládání samozřejmě stále zůstává. Nevidím rozdíl, u všech mi to přijde jednotné.
Zdar Max

[PetebLazar]

Šlo mi o dokumentaci k systemd (něco v duchu Oracle Database Concepts, kde se na pár desítkách stránek dají pochopit základní principy a fungování.

[V.]

A busybox to není, nejpoužívanější?

[Max]

Myslím, že jsem se vyjádřil srozumitelně a ani jsem neřekl, že je systemd nejpoužívanější, pokud tvá reakce měla podobný myšlenkový základ.
Zdar Max

[Bedňa]

Najpoužívanejšou distribúciou je MS Windows 10 a nehodnotil by som ten systém ako dobrý a ani ako priemerný. Nato že to pustím menej ako raz za mesiac, tak mám samé dobré skúsenosti. Tlačiareň tlačí po nainštalovani a potom už nikdy. Reboot bez opýtania začne sťahovať updaty, to sa mi hodí keď chcem rýchlo niečo spraviť a štvrť hodiny som out. Proxy nastavenia sa stratia, WTF?

Myslíš najpoužívanejšie distribúcie Linuxu ako RedHat a Ubuntu? Nemožnosť sa prihlásiť, pretože logind nejak jebe, bez toho aby som na niečo šiahol. Server sa nerebootne pretože sa zjebe celý systemd. Na rozbitie stačí upgrade systému bez jediného zásuhu do hocičoho. A to s týmito systémami našťastie prichádzam do styku okrajovo, nie je to ani raz za mesiac.

Najpoužívanejšie sa nikdy nebude rovnať dobré.

[Max]

Co ty preferuješ a jaké máš zkušenosti, to je tvoje věc. Z kontextu je myslím jasné, že slovo "distribuce" se vztahuje k Linuxovým distribucím, takže nechápu tu připomínku k Windows.
Taktéž jsem nikde neřekl, že nejpoužívanější jsou nejlepší, takže mi uniká další tvá připomínka. Nicméně z mé osobní zkušenosti hodnotím Debian i CentOS (potažmo OEL) kladně, mám je všude a nemám problémy.
Zdar Max

[Bedňa]

Nemal som zrovna dobrý deň, ale proste vždy keď vidím "najpoužívanejší ..." tak mi to hne žlčou. Jako keby to bolo meradlo kvality.

To by sme aj výsledky volieb mohli vždy hodnotiť ako, že sa nám tam zas dostala kvalitná zostava

Debian somozrejme hodnotím veľmi pozitívne, najbližšie obdobie (hlasovanie) nám ukáže, či to tak bude naďalej.

CentOS hodnotím ... nie nebudem hejtovať. Ale keby som chcel ísť touto cestou, zaplatím si RedHat.

[Gilhad]

Zatim jsem se s nim primo nesetkal a nejak nemam duvod na tom v nejblizsich letech cokoli menit. Jeho filosofie (nahradit vsechno naraz) se mi proste nelibi, pristup vyvojaru taky ne a nemam problem, pro jehoz reseni by byl dulezity.

S tim, jak porad jeste neni vyvinuty a ustaleny, mi prijde jako lepsi pouzivat to co znam a az nepujde jinak, tak se eventualne naucit posledni verzi, nikoli preventivne sledovat vsechny mezikroky a ucit se jak se vubec dostat k logum, kdyz ted uz to pry jde nejak rozumne a kdovi co bude za par let, stejne jako se porad preucovat, co vsechno uz pohltil (a teda by se nemelo pouzivat mimo nej) a co jeste jede v puvodni koncepci a kterak to ohnout, aby to s nim fungovalo.

[Max]

Mno, já ho mám všude. CentOS, Oracle Linux, Debian, ArchLinux.
Zdar Max

[figliar0]

Nepopieram. Človek sa so systemd stretáva a bude stretávať. To, že nie doma, ešte neznamená, že to nebude ovládať.

[Max]

To samozřejmě ne. Na druhou stranu, doma člověk oproti produkci dělá občas pěkný prasárničky, které jsou pak dobrou průpravou.
Zdar Max

[Ondra]

prejdi na freeBSD .....

[luky]

alebo openBSD maju skor synchronizovane ovladace pre inteldrm a radeomdrm

[johnyK]

podle mne nevi u RedHatu leva ruka co dela prava (a podobne to je v cele branzi).

Na jedne strane nechaji delat Poetteringa na tom intergalaktickem systemd, ktery o vsem vi, vsude vidi a od vseho ma klice a na druhe strane tlaci vyvoj microservices, kdy je v uzavrenem biotopu jedna jedina sluzba.

Samozrejme, ze to neni od veci zkouset ruznymi smery, ale mozna by nebylo spatne, kdyby nam ta firma, co ma ty miliardove obraty sdelila, jakym smerem se mame my, obycejni obcane v pristich par letech orientovat.

[Gilhad]

Gentoo bez systemd jsem spokojene pouzival nez prisel Poettering a stejne spokojene ho pouzivam bez systemd i nadale.

Az budu mit miliardove obraty, tak se zacnu zabyvat firmama s miliardovymi obraty, do te doby me stejne nebudou brat vazne a bude to vzajemne.

[johnyK]

to jsem mel zrovna tak se Slackware. Dokud jsem se o infrastruktury ve firme a u zakazniku staral sam.

Ale pak prisli dalsi zamestnanci a tem neni mozne vsechno 'naridit'. I zamestnanec ma pravo na to, aby pracoval v prostredi, ktere je v oboru rozsirene a samozrejme prijdou takovi lide jiz s urcitymi navyky. A museli jsme se rozhodnout, kterou z tech 'main' distribuci vezmeme. Aby se lidi neptali porad me, ale mohli si vetsinu vygooglit. Aby byla podpora hardware atd. atd.

Takze centos a do letoska to nejak slo (10 let). Ted prijde centos7 a services reaguji jinak. Zadny problem prece, informatika je o neustalem uceni, takze si to kazdy vygoogli a jede se dal.

Zadny ze zamestnancu ovsem neprisel, ze si to hodiny toho sebevzdelavani zaplati sam. A Poetteringovi jaksi ucet poslat nemuzu. I kdyz mi ten jeho nesmysl nic neprinesl. Ja dokonce pochybuji, ze to vubec nekomu neco prineslo ve stavajicim stavu, ale budiz.

A nyni, s postupen virtualizace rozhodime sluzby na vice virt. stroju. A na kazdem tom stroji nyni pobezi ten fantasticky systemd, ktery se bude starat o tu jedinou sluzbu.

[vencour]

Interní knowledge base není, nefunguje? Nebo ji považujete za zlo a každý válčí na vlastní pěst?

[Aleš Kapica]

Přesměruj je na Ubuntu a pak je pošli k čertu.

Teda.. On se jich tu s radostí nepochybně ujme K3d4r

[k3dAR]

a pro blbe (ego)kecy je ma nasmerovat na "alese Kapucu"?

[Aleš Kapica]

Opravdu trefné – od osoby co se stydí za své jméno.

[snajpa]

Muzes klesnout jeste niz? Je vsechno v poradku s Tvoji hlavou po zdravotni strance.? Aby se do toho pomalu nemichalo neco, na co Ti chybi diagnoza... a aby se na to neprislo pozde...

[Aleš Kapica]

Od tebe to taky sedí. Chápu, že si K3dar musel kopnout, když jsem tímhle jemným způsobem naznačil, že si trhá kšandu tam, kde chybí snaha. Ovšem tvoje averze, zakořeněná na tom, že jsem se otevřeně kdysi dávno vyjádřil skepticky k tvému plánu, je fakt ubohá.

[snajpa]

Proklikej si svoje posledni prispevky v diskuzich tady... to je furt sklapni, zmiz, a co ja vim co... Ale Mr. Kapica Vi Vsechno Nejlip (tm), pripadne se umi obhajovat az do zblbnuti, ze si totalne poplete co vlastne obhajuje Dyt je to smesny.

[podlesh]

Zřejmě v tom nevidí žádný rozpor - systemd a microservices jsou různé věci pro různé použití, průnik je minimální.

[Tomáš Pelc]

Díky za výživnou a vesměs věcnou diskuzi k mojí otázce - zejména @Heronovi.

U nás v práci jsou kolegové vesměs "systemd lovers" a tak mě zajímá i druhý úhel pohledu, abych neměl klapky na očích jedním směrem.

[Jendа]

Logovanie, správa sietí, zavádzač, synchronizácia času - a to iste nie je koniec zoznamu (a koniec snáh o začleňovanie rôznych funkcionalít do init démona).

Nevím jak na Archu, ale na Debianu z uvedeného ze systemd používám pouze logování, a to ještě dost omezeně (journal vlastně nečtu, všechno se hned přeposílá do rsyslogu). Uvedené věci (networkd, bootněco, timesyncd) jsou na Debianu dokonce defaultně vypnuté. Na Archu nejsou a nelze je jednoduše vypnout?

A co se týče té správy uživatelů, tak pokud je pravda co psali v diskuzi na Rootu (osobně jsem to neověřoval), tak to též bude triviálně vypnutelné, resp. vůbec nezapnutelné.

[figliar0]

Už som to tu písal niekde. Ja beriem, že si jednotlivé systemd služby môžem nahradiť inými, tamtie vypnúť a zo systemd použiť iba init. Vo finále budem mať stále nainštalovaný systemd kompletne zo všetkými vypnutými službami - v systéme bude stále "smrdieť" ten moloch - pretože distribúcie nerozdeľujú systemd na viacero balíkov. A to dokonca ani Debian - u Archu to lepšie nie je.

Mimochodom - prečo? Prečo nemáme balíky ako systemd-core, systemd-journal, systemd-network, systemd-ntp... Jednoducho odinštalovateľné a nahraditeľné inými (bez závislostí jeden na druhom)?

Celé je to potom vo finále také... neelegantné. A potom príde tá otázka - prečo systemd? Čo mi prináša navyše v porovnaní s alternatívami? Prečo nemať radšej niečo iné - niečo, čo človek bude mať rád a bude to rád používať? Niečo, čo viac zapadá do filozofie Unixu, s ktoru sympatizujem? Nie niečo, čo každú chvíľu príde zase s niečím, čo budem musieť "vypínať" a "nahradzovať", resp. musieť to "strpieť"?

Je to podobné ako s web prehliadačmi. Človek len tŕpne, čo v Mozille zase vymyslia v novej verzii, až kým neprejde k alternatíve. Tam si sem-tam všimne zlepšenie, či novú funkciu, ktorá ho poteší a víta ju.

[xkucf03]

Mimochodom - prečo? Prečo nemáme balíky ako systemd-core, systemd-journal, systemd-network, systemd-ntp... Jednoducho odinštalovateľné a nahraditeľné inými (bez závislostí jeden na druhom)?

Přesně tak, systemd chybí modulárnost a standardy. Už jsem se tu o tom rozepisoval několikrát (1, 2, …) Přitom systemd má i pár hezkých vlastností.

[kralyk z abclinuxu]

Rozumim tomu správně, že jakýkoli sw, který je (pouze) na GitHubu, je automaticky diskvalifikován (tj. 'insane')?

[xkucf03]

Je to dost zásadní vada, ale nemusí ho to nutně diskvalifikovat. Pokud umožníš lidem se zapojit, aniž by museli podepsat smlouvu s GitHubem (mít tam účet). Tzn. pokud půjde hlásit chyby, posílat patche, diskutovat atd. i jiným (svobodným) kanálem. Např. můžeš fungovat jako taková proxy a propisovat příspěvky od těchto uživatelů a vývojářů do GitHubu.

Pokud je GitHub jedinou cestou, jak lze přispět do kódu nebo třeba nahlásit chybu, tak ano, není to příčetné.

[kralyk z abclinuxu]

Hm. A existuje vlastně vůbec nějaký sane software?

[xkucf03]

Dost projektů vyvíjených v rámci GNU nebo pod Apache Foundation nebo různé nezávislé projekty…

Přijde mi, že z toho děláte moc velkou vědu – přitom to jsou celkem základní doporučení a dobré praktiky.

V diskusi na Rootu se třeba někdo pohoršoval nad povinností veřejně vystavit verzovací systém (tzn. ukázat historii – kdo, kdy, co, proč) a divil se, že nestačí jen občas zveřejnit zazipované zdrojáky (snapshot). :-)

Tady se zase někteří děsí toho, že by měli elektronicky podepsat vydanou verzi – přitom je to věc, kterou zralé projekty běžně dělají a nic divného jim na tom nepřijde, je to samozřejmost.

[kralyk z abclinuxu]

Ptal jsem se jen ze zvědavosti. Jinak k tomu manifestu jsem se zatim iirc moc nevyjadřoval, hlanvě protože to jde dost mimo mě ('sane software' nepíšu / nebudu psát).

Kdybych se k tomu měl vyjádřit, tak mi přijde mimo už ten název. Sepsat seznam příkazů pro vývoj software víceméně na základě osobního názoru a pak označit veškerý software, který to nesplňuje, za nepřičetný - to je imo cestak k tomu lidi spíš nasrat než jim předat nějakou myšlenku...

[ChronicPain]

§ 1

• (1) Kdo sobě nebo jinému přidělí nick začínající písmenem x, bude označen za
  • a) příčetného s výhradou, je-li písmeno x bezprostředně následováno samohláskou;
  • b) nepříčetného, není-li písmeno x bezprostředně následováno samohláskou;
  • c) zavrženíhodně nepříčetného, spáchal-li daný skutek jako součást organizované skupiny, vyzýval-li k vytvoření takové skupiny, či obhajoval-li tento skutek ve veřejném prostoru
• (2) Odnětím titulu numerické příčetnosti až na dvě babí léta bude potrestán ten,
  • a) jehož nick končí číslicí 1 nebo 2, přičemž tato nenásleduje jinou číslici;
  • b) jehož nick končí dvojčíslím, které vzbuzuje dojem letopočtu;
  • c) kdo si pšoukne při zadávání telefonního čísla
• (3) Deseti až třiceti hodinami logopedie a odnětím titulu artikulační příčetnosti až na věky věků bude potrestán ten, jehož nick nelze srozumitelně vyslovit jako slovo v přirozeném jazyce a na hláskování je příliš dlouhé.
• (4) Tresty za prohřešky uvedené ve článcích 1 až 3 se sčítají.

§ 2

• (1) Kdo hovoří či jinak komunikuje s nepříčetnou osobou, sám pozbyde příčetnosti na jednu časovou jednotku.

§ 3

• (1) Kdo se ohradí proti znění zákona bude bez zbytečného odkladu zesměšněn dvorním principálem a pozbyt příčetnosti, jakožto i schopnosti ji znovu nabýt.
  (2) Zákon, který nemá sudý počet paragrafů, není příčetný.

§ 4

• (1) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam velit mauris, iaculis a lacus vitae, euismod rhoncus lorem. Proin ultricies hendrerit volutpat. Aliquam interdum et ligula non tempor. Suspendisse mi metus, sagittis quis odio vel, fringilla viverra nunc. In ut risus dapibus, dapibus lectus nec, eleifend sem. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Donec vel aliquet tortor. Curabitur diam ex, fermentum a suscipit ac, mollis id tortor. Nunc tempus mi vel lectus accumsan, malesuada accumsan neque venenatis. Suspendisse varius volutpat dapibus. Vestibulum blandit non nibh aliquet elementum. Maecenas maximus eros libero, eget tincidunt nunc porta a. Sed nec urna quis arcu eleifend tincidunt. Aliquam eu pulvinar justo.

[sigma]

modulárnost

Na jaké úrovni si to představuješ? Systemd je projekt obsahující řadu nástrojů (init, networkd, timesyncd, journald, resolvd, ...). Většinu z nich lze nepoužívat a případně ani nekompilovat a neinstalovat. Autoři se rozhodli vše spravovat v jednom git repository, ale to IMHO není proti modulárnosti, má to nějaké nevýhody ale i výhody, a mě jako uživatele systemd na úrovni správce vlastní embedded distribude to nijak nepohoršuje. Modulárnost systemd v tomto ohledu využíváme. Že se mainstream distribuce rozhodly balit vše najednou není problém na straně systemd projektu.

[xkucf03]

Ano, rozdělit to do více repozitářů a mít mezi těmi moduly dobře definované rozhraní. Což následně umožňuje nahrazování jednotlivých modulů vlastní implementací a nebo použití vybraných modulů nebo funkcionalit i s jiným jádrem (jiným init systémem).

Autoři se rozhodli vše spravovat v jednom git repository, ale to IMHO není proti modulárnosti

Je to asi jako když píšeš v Javě a členíš si aplikaci do javovských balíčků¹ a myslíš si, jak to máš modulární – a pak se rozhodneš to přepsat do OSGi nebo do Java Platform Module System nebo to jen rozdělit do více Maveních projektů (více JARů) a najednou zjišťuješ, že jsi to psal vlastně špagetově a že se ti hranice mezi moduly jaksi rozmazaly a různé třídy a metody používáš napříč moduly bez nějakého řádu.

Dá se tedy říct, že pokud přechod na systém vynucující² izolaci modulů je pro tebe obtížný a musíš toho dost přepisovat, tak to znamená, že jsi nebyl dostatečně disciplinovaný a reálně nedělal modulární aplikaci.

_{[1] package, což jsou vlastně jen jmenné prostory (sice existuje package protected, ale pro izolaci modulů je to nedostatečné)
[2] tzn. není to jen nějaké doporučení nebo varování, ale porušení těch pravidel znamená, že to nejde zkompilovat}

[sigma]

Touto argumentací vyžaduješ build-time modularitu. Ta ale nutně negarantuje run-time modularitu. Ale asi tam bude nějaká korelace.

Systemd-haters jde podle mě spíš o tu run-time (případně install-time) modularitu. Ta do jisté míry existuje.

Fascinace standardizací a dobře definovaným rozhraním je fajn, ale v reálu to může mnohonásobně zvýšit náklady na vývoj a údržbu a garance kompatibility. Nejsem si jistý, jak moc to platí u systemd projektu, ale obecně projektů s takovouto úrovní modularity mnoho neznám. Zvlášť u infrastrukturních projektů to přináší značné navýšení komplexity. A autoři se legitimně rozhodli, že tyto náklady s pochybným přínosem nechtějí nést.

[xkucf03]

Fascinace standardizací a dobře definovaným rozhraním je fajn, ale v reálu to může mnohonásobně zvýšit náklady na vývoj a údržbu a garance kompatibility.

Zrovna u softwaru, který má ambice být klíčovou součástí mnoha distribucí, si myslím, že by se z kvality a dobrých zvyků nemělo slevovat. Naopak – takovýto software by měl být to nejlepší, co jsme schopní vyvinout – a ne dělat nějaké kompromisy v zájmu zlevnění vývoje.

V aplikacích ať si lidi prasí a dělají kompromisy, jak chtějí, ale základní systémové komponenty by měly být napsané čistě a minimalisticky.

[sigma]

Platí tyto nároky ve smyslu modularity a stabilních rozhraní i na (linux) kernel? Měl by být každý driver a filesystém v samostatném repozitáři? Aktuální stav linux kernelu je tebou prezentovanou optikou totální hell.

Jinak co jsem několikrát potřeboval sáhnout do zdrojáků systemd, považuji je z pohledu kvality za nadstandardní.

Ty se snažíš prosazovat určitou architekturu, po které zřejmě není až tak reálná poptávka. Reálný svět sebou nese omezení, a takové "neslevování" z požadavků s povětšinou čistě hypotetickým přínosem (někdo by mohl vyměnit/reimplementovat nějakou komponentu, protože to jde) by znamenalo buď zpomalení vývoje nebo potřebu nalít do toho podstatně více peněz.

[xkucf03]

Ty se snažíš prosazovat určitou architekturu, po které zřejmě není až tak reálná poptávka.

A čím si potom vysvětluješ to, že tolik lidí má se systemd problém a snaží se hledat cestu, jak z toho ven? Viz třeba ta diskuse v gnu-system-discuss.

Chybějící specifikace/standard je reálný problém. Kdyby ze systemd vyčlenili to jádro (init systém) a všechno ostatní nechali bokem + stabilizovali a zdokumentovali API, tak si myslím, že by to i lidi celkem rádi používali. A byl by to software řádově s nižšími desítkami tisíc řádků kódu (dokonce i v C).

[xxx]

To jako viz František Kučera, Alexander Vdolainen, marinus.savoritias, Alfred M. Szmidt, Jean Louis. IMHO LOL.

[xxx]

Ale jinak ti unika jadro problemu. To neni nejaky cool initi. Ale spis neco co bych nazval "beyond the Linux kernel". Tedy ta vrstva nad jadrem, do ktere by radi sahali uzivatele, aplikace, sluzby atd. Patri tam krome initu, nastavovani site, sprava disku, opravneni, etc. (Windows na to mely "Ovladaci panely"). Po tom je poptavka. Ne po primitivnim initu co by mel 1000 radku v C.

[Gilhad]

A spousta lidi naopak presne kvuli tomuhle od Windows odesla k linuxu a jejich poptavka je, aby tohle v linuxu nestrasilo (aspon ne povinne).

[xxx]

No otazka je, jestli odchazeli od neceho, nebo k necemu. A pripadne co to bylo. Jestli koncept, nebo funkcnost.

Jen pro priklad. Moc dobre si pamatuju, jak bylo supper mit xsupplicant (pozdeji wpa_supplicant) a jak to na FELu v predchudci Eduroamu dobre fungovalo. A kdyz to nefungovalo, tak bylo videt proc. Narozdil od Windows.

Jenze. Prijit dneska kamkoliv, a tam resit iwlist, editaci configu, restart supplicanta. Na to uz jsem trochu starej. Navic to stejne bylo ohakovany, proze supplicant nenes uplne dobre shozeni/nahozeni ifacu a tudiz ani uspavani.

A takhlen je to se spoustou dalsich veci.

[xkucf03]

Falešná dichotomie… Dobře navržený a transparentní systém nevylučuje dobrou použitelnost.

[xxx]

Ruzovej jednorozec taky existuje...

Stejne tak existuje hromada dobre navrzenych a jednoduchych systemu nevylucujicich dobrou pouzitelnost. Pokud teda za dobrou pouzitelnost oznacujes to, ze ten jednoduchej system obalis hromadou bashovskejch sracek.

[Gilhad]

Za me je odpoved ano - odchazel jsem od Windows, ktery me soustavne sraly a odchazel jsem k linuxu, ktery me nadchnul. Jak koncepci, tak tim, co na nem tehdy fungovalo. Jasne ze nefongovalo zcela vsechno co dnes a zdaleka ne vse fungovalo naprosto perfektne, ale oproti Windows to byl neskutecny pokrok. A clovek si mohl snadno dodelat spoustu veci, ktere potreboval, sam, nebo si je nejak upravit.

Dodnes se mi celkem nezne deje, ze neco v linuxu zkoumam nebo resim a vyslovene me potesi, jak to funguje. Na windows me veci proste pravidelne sraly a nic se s tim nedalo delat. Od te doby se mi po Windows nezastesklo a i kdyz jsem se s nimi jeste nekolikrat profesne musel zabyvat, tak ty veci, co me na nich sraly tam byly furt a pribyly dalsi.

Dnes uz se jim nastesti davno venovat nemusim, ale manzelka ma dva pocitace, jeden s linuxem, druhy s windows (kvuli zamestnani) a pouziva prubezne oba dva. Zajimave je, ze nadava jen u toho jednoho. nejcastejsi vykrik "Proc jen ty windows musi byt tak strasne blby!?!" dava jasne tusit, ktery z nich to je.

[xxx]

Přílohy:

• pic1.png (5763 bytů)
• pic2.png (8916 bytů)

No do tehle debaty zabredavat nebudu. Windows ted pouzivam min, spis jen jak zavadec her, takze men serou min. Ale to neznamena, ze lze prehlizet problemy Linuxu.

Co mne na Linuxu nadchlo bylo, to, ze kdyz se jdnou neco nastavilo, tak se to samo nerozbilo. Coz melo dva neprijemne dusledky. 1) vsechno se muselo nastavit, 2) vsechno co se delalo automaticky stalo za <|>. Dneska uz 1 zdaleka neplati, neplati uz ani vzdycky 2, ale cenou je komplexita.

Pokud bude nastoleny trend pokracovat, pak nas ceka vice dusledku komplexity. Rozumej vice systemd. Pokud ho chces zavratit, pak zacni manzelku ucit, jak se pouziva prikaz mount/umount u USB flashek, a jak nastavit v Xorg.conf monitory.

PS: Tezko muzu prehlizet nedokonalosti Linuxu, kdyz na ne denne koukam. (Velikost kurzoru je defaultni.)

[Gilhad]

Tak ja je neprehlizim (ve smyslu, ze bych tvrdil, ze zadne nejsou), ale pro me jde ve srovnani s problemy Windows o veci radove mene stresujici a obtezujici.

S tim taky souvisi to, ze jsem si system nastavil tak, aby mi vyhovoval a on tak zustava. Vetsinu dulezitejsich nastaveni jsem si zabalil a na dalsi pocitac uz celkem snadno pretahnu, takze 1) me tolik neirituje, nove je toho potreba nastavit celkem malo a u kazdeho pocitace to staci vetsinou jednou (ovladace HW a tak). A 2) zase nepovazuju za tolik dulezitou, aby ospravedlnila navrat k Windows ci jinym molochum (a tudiz taky nepouzivam sytemd a doufam, ze k tomu ani nikdy nebudu donucen).

Nastaveni monitoru problem neni, to jsem udelal pri instalaci a funguje to, mountovani a odmountovavani USB (nebo SD karet z fotaku) ji problemy necini.

Nemenna velikost kurzoru ji vadi daleko, daleko mene, nez stale se menici menu v ruznych MS produktech ( a tim nemluvim jen o zmenach typu XP-vista-7-8-10 (zatimco fluxbox vypada porad tak, jak je zvykla), ale i a hlavne o tom, ze ted se ji meni menu pod rukama klidne nekolikrat denne - na to nadava dost casto).

Me velikost kurzoru vyhovuje, takze necitim potrebu ji menit (ale vim, ze jsem to kdysi nejak delal, ale pak jsem to shledal zbytecnym). BTW: ted jsem naklepal do googlu linux cursor size a hned prvni odkaz naznacuje, ze to jde na Ubuntu https://vitux.com/how-to-change-cursor-size-on-ubuntu-desktop/ o par radku niz, ze i na Archlinuxu https://wiki.archlinux.org/index.php/Cursor_themes (a tam i obecne jako X resources takze pravdepodobne naprosto kdekoliv), dal asi nema cenu pokracovat : Přibližný počet výsledků: 15 000 000

[xkucf03]

Příloha:

• KDE-nastavení-kurzoru.png (417810 bytů)

V KDE to jde naklikat v nastavení. Ale ani si už nevzpomínám, kdy jsem si naposledy nastavoval kurzor – asi někdy v dobách KDE 2.0, kdy jsem si s tím různě hrál (v té době jsem střídavě používal i Gnome).

[xxx]

Přílohy:

• pic3.png (4622 bytů)
• pic4.png (3607 bytů)

Ja nemam problem nastavit si velikost kurzoru. Ja mam problem s tim, ze kdyz pripojim 4K monitor, tak na FHD monitoru se stane kurzor obrim. Stejna tak se muzem bavit dal o tom, proc Windows umi naskalovat kazdy monitor zvlast, tak aby na nem bylo GUI stejne velke, zatimco Plasma ne.

ZAle abych Linuxu nekrivdil, Plasma pridala novou feature. Kurzor s menici se velikosti. (Arch linux)

[kralyk z abclinuxu]

Stejna tak se muzem bavit dal o tom, proc Windows umi naskalovat kazdy monitor zvlast, tak aby na nem bylo GUI stejne velke, zatimco Plasma ne.

IIRC Plasma tohle umí a naopak to neumí Gnome, resp. pouze umí celočíselné násobky.

[xxx]

Neumi. V tom dialogu je jen "global scale". Pokud je na to nejak trik, tak by se mi docela hodil. Teda krome tehle metody.

[kralyk z abclinuxu]

Teď nejsem u externího displaye, tak to nevyzkoušim, ale minimálně v minulosti to šlo...

[Gilhad]

Inu ja se s tim jeste nesetkal (takze pred tim nemuzu zavirat oci ani kdybych chtel), pouzivam vzdy jen jeden monitor na danem pocitaci. Ale pokud to bude vadit dost lidem/nejakemu schopnemu vyvojari, tak verim, ze se to casem taky vyresi.

Na druhou stranu jsem uz strasnou radu let zvykly pouzivat aspon 12 virtualnich ploch, coz na Windows proste neslo. Pred par lety jsem zaslechl, ze uz pry zvladli nejak az 4, ale ze s tim jsou neustale potize. Jak je to ted netusim, tak podrobne je nesleduju. A myslim, ze dodnes neumi naraz spustit nekolik ruznych grafickych rozhrani, kazde pod jinym uzivatelem, coz jsem pouzival na linuxu tak nejak asi pred 10 lety.

Proste se ty systemy v mnohem lisi.

Me linux vyhovuje vyrazne vic a to tak ze dlouhodobe. Ale asi to bude tim, ze davam obecne prednost tomu sedet na vlastnorucne vyrobene drevene zidli, ktera neni treba zcela dokonala a misty trochu tlaci (i kdyz ne natolik, abych ji tam zacal upravovat), ale jinak plne vyhovuje, pred posezenim na plne automatickem, polstrovanem, vyhrivanem, chlazenem a vetranem kresle, ktere ale do me co pul hodiny nahodne vrazi jehlu a obcas mi vykloubi rameno, nebo zlame ruku. Cimz nijak nepopiram, ze ta drevena zidle misty tlaci a polohovat jde jen s pomoci pilky a sroubovaku, ale zato jakkoli si zamanu.

[xxx]

Ach ty prirovnani. Protoze jestli se mi meni tema kurzoru podle toho jestli jsem v okne nebo nad plochou. A nove jako bonus i velikost kurzoru. Tak pak je Linux na desktopu neco jako, zidle ktery nekdo uriz nohu (Protoze KDE 3.5 tento problem rozhodne nemelo).

[k3dAR]

"Linux na desktopu" neni jak jiste vis jedno DE o kterem je rec ani v Xfce 4.14 se mi takto kurzor nemeni, resp. meni se jen kdyz je nad okrajem/rohem okna, nebo nad textem ktery jde oznacit...

[k3dAR]

[...]Rozumej vice systemd. Pokud ho chces zavratit, pak zacni manzelku ucit, jak se pouziva prikaz mount/umount u USB flashek, a jak nastavit v Xorg.conf monitory.

mount/umount USBFlash kliknutim na plose nebo v spravci souboru i automaticke nastaveni xorg.conf fungovalo davno pred systemd...

naopak systemd prineslo problem s automountem v fstab pridanych zarizenich ktere nejsou dostupne a zustane to vyset v emergency rezimu i presto ze jde o datovej oddil kterej pro start systemu neni potreba (ano jde to vyresit pridanim mount parametru nofail)

[Heron]

Kdyby ze systemd vyčlenili to jádro (init systém) a všechno ostatní nechali bokem

Otázkou je, co je zrovna v případě systemd to init jádro. Systemd není jen init, který spustí servicu a jde od toho. Už třeba jen to, že služba může mít závislost na mount unitě znamená, že ještě před spuštěním služby je potřeba namountovat nějaký fs. Nevím, zda je možné mít podobné závislost na nějaké síti (tj nahodit nějaký inface, zapnout tunel apod.), ale bylo by to logické rozšíření. Ta service vůbec nemusí startovat automaticky, může být socket activated, nebo spouštěná přes dbus.

Najednou ti ten core init zasahuje do správy mountů, možná do správy sítě, dejme tomu do kontejnerů, určitě do systémové sběrnice apod. Tj to core je hodně velké.

A ano, jistě by se to dalo rozdělit a propojit nějakým API, ale je otázka, nakolik by to rozdělení bylo umělé. V tomto nelze nezmínit snahy udělat pomocí MD, LVM, XFS něco jako btrfs, ale bez btrfs. Tedy, podle autorů, stačí pouze jen to, kdyby ty vrstvy více a oboustranně komunikovali a dá se dosáhnout téhož. No jenže je otázkou, zda to rozdělení na vrstvy nebude už jen čistě formální, protože pro danou funkci bude potřeba tam mít přítomné všechny "vrstvy" a musí mezi sebou masivně komunikovat.

[kralyk z abclinuxu]

V tomto nelze nezmínit snahy udělat pomocí MD, LVM, XFS něco jako btrfs, ale bez btrfs.

To vypadá velmi cool, díky za odkaz. Mít něco jako btrfs, ale od lidí, kteří umí napsat robustní FS by bylo super.

No jenže je otázkou, zda to rozdělení na vrstvy nebude už jen čistě formální

No tak jistěže by to bylo víceméně pouze formální, ale to takové ty "všechno musí za každou cenu být modulární" nadšence moc nezajímá...

[Heron]

To vypadá velmi cool, díky za odkaz. Mít něco jako btrfs, ale od lidí, kteří umí napsat robustní FS by bylo super.

Není zač. K tomu dalšímu, btrfs můžeš se všemi funkcemi používat od roku 2011. Tento výtvor postavený na fs z roku 1994, lvm z roku 2002 a md taky tak nějak nemůžeš používat ještě ani v roce 2019. Ale to si musí každý vybrat, zda bude používat dostupný fs, nebo si počká a bude roky bez těch funkcí. Ono se to dá zkombinovat, používat to co je a potom přejít na něco lepšího. I to btrfs se časem vylepšuje, takže to je soutěž různých přístupů.

[kralyk z abclinuxu]

Ale to si musí každý vybrat, zda bude používat dostupný fs, nebo si počká a bude roky bez těch funkcí.

Neříkám, že to obecně tak není, ale osobně to vidím tak, že si budu muset počkat tak jako tak - u btrfs na to, až bude důvěryhodný (jestli se to někdy stane) a u XFS, až bude mít ty fíčury (jestli se to někdy stane). Co se týče LVM a MD, IMO to docela dává smysl, protože třeba btrfs a ZFS taky mají v sobě něco jako LVM/MD, žejo (ale tu přednášku jsem, pravda, ještě neskoukl)...

Kdo má s btrfs dobré zkušenosti / věří mu se svými daty, tak to samozřejmě má jinak...

[Heron]

u btrfs na to, až bude důvěryhodný

A to přesně znamená co? Pro mě je btrfs důvěryhodný od 2011, od kdy jej používám. Osobně si myslím, že to je více než cokoliv jiného věcí psychologie a na některé projekty se nabalilo tolik "pověr" (nálepek, předsudků), že se toho jen těžko zbaví.

protože třeba btrfs a ZFS taky mají v sobě něco jako LVM/MD

No to právě nemají. V nejvyšší úrovni abstrakce lze disky chápat jen jako pooly bloků. Každý soubor rozdělíš na bloky a tyto bloky uložíš na disky. Pokud každý blok uložíš na více disků, máš redundanci. Tedy vůbec tam nemusíš mít nic jako MD (do kterého vstupují bloková zařízení a které vytváří další blokové zařízení), prostě máš jen skladiště bloků. Přidáš další disk a začneš na něj ukládat další bloky. Odebereš disk a jeho bloky se naházejí na zbývající disky.

Zatímco při přidání disků do MD musíš čekat, až se ti to celé přepočítá (což může trvat dny), tak přidání disku do btrfs je hned.

S LVM je to v bledě modrém. Do LVM vstupují bloková zařízení (PV) a LVM exportuje bloková zařízení (LV). Ale není potřeba pracovat na úrovni blokových zařízení. Prostě "subvolume" bude jen podmnožinou bloků v daném storage poolu. Pokud máme COW, tak můžeme některé bloky sdílet přes více subvolume (a tím máme snapshoty).

Tím chci říct, že v btrfs fakt nikde není okopírované a dobře schované MD a LVM. Prostě to dělá od počátku jinak. A tento přístup není nový nebo osamocený, začínají se (konečně) prosazovat objektové storage (CEPH apod.) které toto mají na úrovni objektů. Disky jsou jen sklady pro objekty nebo nějaké fragmenty a fs může redundanci řešit třeba tak, že ty fragmenty uloží současně na 5 serverů. Přidat / odebrat disk nebo celý server je hračka. Taky tam nikde není zakuklené LVM a MD.

[kralyk z abclinuxu]

A to přesně znamená co? Pro mě je btrfs důvěryhodný od 2011, od kdy jej používám. Osobně si myslím, že to je více než cokoliv jiného věcí psychologie a na některé projekty se nabalilo tolik "pověr" (nálepek, předsudků), že se toho jen těžko zbaví.

IMO to nejsou jenom pověry. Když jsem btrfs zkoušel, rozsypával se mi. Je pravda, že to už je pár let a že to nekontroluju moc pravidelně, ale lidé mi tu zkušenosti potvrzují. Viz nedávný blog tady na abc a také shodou okolností zrovna dnes mi jeden kolega říkal, že se mu nedávno na laptopu rozsypal btrfs root filesystém.

Mně ty fíčury popravdě (aktálně, pro moje použití) nezajímají natolik, abych to nějak extra řešil a hlavně ne natolik, abych jim dal větší prioritu než spolehlivosti/robustnosti.

No to právě nemají. (...)

Ok, já tím měl na mysli spíš uživatelské rozhraní, než vnitřní fungování, a tam je pravda, že domain specific znalost fs může asi být benefit. Máš v tomhle zřejmě lepší znalosti než já, takže o tohle se nechci hádat

[Heron]

Viz nedávný blog tady na abc a také shodou okolností zrovna dnes mi jeden kolega říkal, že se mu nedávno na laptopu rozsypal btrfs root filesystém.

Nedávno jsem dostal jeden disk na obnovu dat. S BTRFS, asi jsem to dostal za trest, nebo nevím. Uživatel není v IT rozhodně nováčkem. Přesto jsem se několikrát nestačil divit. Dostal jsem rotační disk s tím, že je to dd z toho rozbitého disku. O tom rozbitém disku mi neřekl ani slovo, tak jsem předpokládal (naivně), že je to obyč 3.5 interní rotační disk. Začal jsem to řešit a byla mi hromada věcí podivná, takto se FS nerozbije. Data se mi částečně podařilo obnovit a tak jsem napsal tomu majiteli zprávu o tom, že ten fs je fakt rozbitý strašně divně, že mi to nesedí na rotační disk. Už z labelu mi to mohlo být jasné (NTB-něco), ale v první chvíli mi to nedošlo (protože přestože v NTB mám SSD, tak NTB prakticky nepoužívám). Tak samozřejmě, že disk byl SSD a FS byl poškozený trimem. A jednalo se o disk s vadnou implementací NCQ trim. Prostě trim smazal bloky, které neměl, včetně půlky stromu metadat. Takže je super, že dostanete HDD (kde by jinak byla přirozeně zachována i smazaná data), ale je to bloková kopie SSD.

NCQ Trim Widle nepoužívají, takže se nikdo neráčil to implementovat správně, výrobce disku na to házel bobek, majoritní fs se tomu nějak dokázali vyhnout, ale ne vždy. V Linuxu i ve FreeBSD vidím blacklist těchto Samsung SSD (viz poslední řádek):

ada0: <Samsung SSD 850 EVO 250GB EMT02B6Q> ACS-2 ATA SATA 3.x device
ada0: Serial Number
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 238475MB (488397168 512 byte sectors)
ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>

Takže tolik k některým chybám FS. Neříkám, že za všechno může někdo jiný, ale bohužel u některých výrobců stále platí, že to musí fungovat ve widlích a konec, a zejména u méně používaných voláních nebo příkazech se mohou dít věci. Kámoš takto řešil NVMe od Intelu a v RedHatu potom storage experti zjistili hned několik bugů v tom HW. Už nevím, jaký model to byl, ale bylo to rozbité tak, že pro danou úlohu md-cache mu to padalo prakticky neustále.

[Käyttäjä 11133]

Aneb proc vyrobci diskovych poli pouzivaji vlastni diskovy firmware i z jinych nez obchodnich duvodu...

[kralyk z abclinuxu]

Takže tolik k některým chybám FS. Neříkám, že za všechno může někdo jiný, ale bohužel u některých výrobců stále platí, že to musí fungovat ve widlích a konec, a zejména u méně používaných voláních nebo příkazech se mohou dít věci.

Tenhle člověk je poměrně znalý (píše drivery), takže bych nečekal nějaké špatné použití SSD + Trimu. Ale zaručit to nemůžu.

Jinak ten problém by se projevil i s jiným FS, ne? Nebo je btrfs nějak specifický a škodí mu tohle víc?

[Heron]

Jinak ten problém by se projevil i s jiným FS, ne?

Však se projevoval. Ale tj přece jedno, když je chyba v implementaci něčeho, tak i kdyby to něco používal jen jeden projekt na světě, pořád je to chyba toho něčeho, nikoliv toho jednoho projektu.

Nebo je btrfs nějak specifický a škodí mu tohle víc?

AFAIK btrfs bude volat trim mnohem častěji, protože je to cow fs. Tedy při každé změně libovolného bloku (včetně stromu metadat) se vytvoří kopie daného bloku a do ní se zapíšou změny. Což umožňuje atomicky přepnout mezi starým a novým blokem (tj soubor je buď ve stavu před zápisem nebo po zápisu, ale nikdy mezi, což se může stát u FS, které zapisují přímo do datových bloků). Takže je potřeba uklízet ty staré kopie bloků, tj asi bude volat trim mnohem častěji a možná mimo běžný pattern ostatních fs.

Jako já neříkám, že btrfs nemá cbyby. Má je. Ale většina internetových povídaček jsou naprosto neurčité kecy "prostě se mi to rozbilo, nevím proč" nebo ještě lépe, "znám někoho, komu se to rozbilo". Já to používám kontinuálně od roku 2011 na celkem už desítkách disků a nic se tomu nikdy nestalo, krom případu, kdy zahaproval řadič. Ale to je chyba HW, btrfs fakt nemůže za to, že mu 3 ze 4 disků v R10 zmizelo a řadič na ně zapsal nebo nezapsal něco, co měl. btrfs přesto dokázal přečíst všechna data za hlasitého psaní do dmesgu "error recovered" nebo co tam píše. Data jsem pochopitelně raději vytáhl ze zálohy.

Ale jak jsem psal. To si musí zvolit každý admin. Mě se koncept, na kterém je btrfs postaven, velmi líbí a tak jej používám. Až bude koncept slepení vrstev MD+LVM+FS dotažen do konce, tak mu dám šanci také. Storage systému není nikdy dost.

[Josef Kufner]

AFAIK btrfs bude volat trim mnohem častěji, protože je to cow fs. Tedy při každé změně libovolného bloku (včetně stromu metadat) se vytvoří kopie daného bloku a do ní se zapíšou změny.

Já bych docela očekával, že tam bude nějaký mechanismus na připisování změn metadat do bloku, kdy nebude potřeba kopírovat celý blok, jen se čas od času uklidí staré nepoužívané záznamy a ty používané sesypou k sobě, aby se uvolnilo místo.

[trekker.dk]

Teď nedávno jsem zjistil, že SSD od Intelu o stejné kapacitě jsou levnější než Samsung. Serverové teda. Docela příjemně mě to překvapilo - když si na SM883 zkusíte udělat ext4 se zapnutým discardem, vyrobit tam hromadu adresářů s hromadou souborů a pak to všechno několika paralelními rm smazat, tak uvidíte proč. Ta věc je schopná vytuhnout tak, že se ten server musí vypnout/zapnout.

[Aleš Kapica]

A tento přístup není nový nebo osamocený, začínají se (konečně) prosazovat objektové storage (CEPH apod.) které toto mají na úrovni objektů. Disky jsou jen sklady pro objekty nebo nějaké fragmenty a fs může redundanci řešit třeba tak, že ty fragmenty uloží současně na 5 serverů.

Sheepdog. Je ideální v kombinaci s btrfs. A nevyžaduje nic extra, na rozdíl od Cephu.

[xkucf03]

Tohle všechno lze právě zobecnit a pracovat s abstraktními koncepty jako služba, zdroj, závislost atd. Potom úkolem toho, o čem mluvím jako o jádru nebo init systému, je vyhodnocovat závislosti a spouštět služby ve správnou chvíli, mít přehled, zda běží, a poskytovat jednotné rozhraní pro změny jejich stavu (povolit, zapnout atd.).

I to síťové rozhraní nebo připojený disk je vlastně služba (na které může záviset jiná služba) a jsme schopní u ní sledovat stavy (běží = disk je připojen atd.).

Tzn. init systém sám o sobě nemusí umět připojovat disky nebo nastavovat síť – musí jen vědět, kdy to má udělat, a komu o to má říct.

Ono se pak může zdát, že by z toho init systému nic nezbylo a že by byl triviální, ale není tomu tak – vyřešit precizně ty základní věci je kus pořádné a smysluplné práce. A nad tím se pak dá stavět dál.

Je samozřejmě otázka, kam až s tou abstrakcí jít. Přeci jen se pohybujeme v rámci POSIX kompatibilních systémů, takže se dá předpokládat, že pro spuštění služby budeme volat nějakou tu exec() funkci a že tomu spouštěnému procesu budeme nějak připravovat prostředí (práva, zděděné FD, různé kontejnery, proměnné prostředí atd.). Samozřejmě se dá diskutovat o tom, zda to má být přenositelné i na jiné unixové/posixové systémy/jádra nebo zda to může být specifické pro Linux. Ono i tohle by šlo zobecnit a mít např. spouštění POSIXových procesů (+ práva, proměnné atd.) v tom základu a specifika (jako různé kontejnery, AppArmor, SELinux atd.) mít ve volitelných modulech. Jak říkám, tohle je k diskusi, a nemám ani problém s init systémem, který bude běhat jen nad jedním unixovým jádrem (Linux). Nemusí se ta abstrakce hnát do extrému. Ovšem i tato neextrémní úroveň abstrakce (specifická pro Linux) je stále velmi vzdálená současnému stavu systemd – je tam obrovský prostor pro zjednodušení a zobecnění toho init systému a přesunutí jiných funkcionalit do volitelných modulů.

A mimochodem, taky je potřeba rozlišovat mezi softwarem a jeho konkrétním nasazení (parametrizací). Když např. někdo programuje nástroj typu cat, sed nebo grep, tak píše software a abstrahuje od konkrétních doménově specifických požadavků. A když někdo tento software nasazuje, např. tím, že napíše nějaký skript, který tyto nástroje používá, tak tam už ta doménová specifika patří.

[Heron]

Tzn. init systém sám o sobě nemusí umět připojovat disky nebo nastavovat síť – musí jen vědět, kdy to má udělat, a komu o to má říct.

Tomuhle já rozumím, dokonce bych očekával, že něco takového v systemd je. Vzhledem k tomu, že "vše je unita", tak tam někde bude core, co bude umět jen unity. Ale co potom? Když si někdo systemd zkompiluje bez podpory mount unit, tak to má zařvat chybu v případě, kdy tam někdo umístí .mount? Ano, tady je vadou chybějící specifikace, o které píšeš (ty to asi bereš z pohledu softwarového inženýrství, mě chybí nějaká technická specifikace pro admina a nějaká stránka o filozofii toho projektu - jaký je celkový koncept a kam to má směrovat, což mi vadí od počátku).

je tam obrovský prostor pro zjednodušení a zobecnění toho init systému a přesunutí jiných funkcionalit do volitelných modulů.

Tohle tvrdíš na základě čeho? Ty jsi studoval ty zdrojáky? Mě přijde, že na toto nelze odpovědět, pokud nemáme v ruce kompletní specifikaci. A mě třeba vadí, že se distribuce před x lety rozhodly vyčlenit systemd-nspawn do samostatného balíčku (systemd-container). Toto považuju za chybu, protože snadno dostupné a integrované kontejnery mohly být jednou z killer featur systemd. Dřív mi stačilo někomu říct jen "udělej snapshot systému do nějakého adresáře, nastav si jeden konfig v /etc/systemd/nspawn a pomocí machinectl to ovládej". Po oddělení to ti lidé začali vnímat jako něco externího a moc se jim do toho nechtělo. Já osobně beru nspawn jako neoddělitelnou součást systemd. Nikoliv ze softwarově inženýrského pohledu (nspawn jistě není potřeba na běžnou init-like činnost), ale z pohledu systémového administrátora.

[xkucf03]

Tohle tvrdíš na základě čeho? Ty jsi studoval ty zdrojáky? Mě přijde, že na toto nelze odpovědět, pokud nemáme v ruce kompletní specifikaci.

Ta chybějící specifikace je právě ten problém… ale v té úvaze se dá pokračovat i bez ní, jen na základě pozorování a srovnávání různých implementací. Pro představu:

 ╭───────────────────┬────────────────╮
 │ software (string) │ LOC  (integer) │
 ├───────────────────┼────────────────┤
 │ systemd           │        480 000 │
 │ OpenRC            │         16 000 │
 │ GNU Shepherd      │          5 900 │
 │ Upstart           │         76 000 │
 │ procd             │          7 000 │
 │ initng            │         38 500 │
 │ launchd           │         21 200 │
 │ xinetd            │         31 500 │
 │ Lua               │         32 000 │
 │ GNU Guile         │        272 000 │
 │ Rakudo Perl       │         21 700 │
 ╰───────────────────┴────────────────╯

Vážně toho systemd přináší tolik navíc, aby to opodstatnilo takový nárůst komplexity? A pokud přináší užitečné věci navíc, musí být nutně v jednom repozitáři a těžko použitelné samostatně a těžko vyměnitelné za něco jiného? (tím se opět dostáváme k tomu chybějícímu standardu a API)

Pak je taky otázka, v jakém jazyce by to mělo být napsané. Jasně že na úplném začátku spouštění OS (psaného v céčku) je céčko celkem jasná volba, stejně tak asi i pro volání těch exec() funkcí (i když tam už je to trochu sporné). Ale vážně v něm musí být napsané i všechno okolo? Proč nepoužít raději nějakou minimalistickou VM nebo interpret nebo kompilátor vyššího programovacího jazyka do nativního kódu? Vždyť už i v samotném jádře (Linuxu) určitou VM máme (eBPF).

Když se podíváš na ta čísla výše, tak si lze představit variantu, kde vezmeš nějaký základ psaný v C (nižší desítky tisíc řádků kódu nebo i jen tisíce), přibalíš k tomu VM/interpret/kompilátor a zbytek napíšeš ve vyšším programovacím jazyce… a pořád bude celková komplexita nižší, než u toho systemd.

A neměl by to být problém ani z hlediska výkonu (init nedělá žádnou těžkou práci – jsou to jednorázové operace, kde něco připraví, nastaví, a pak zase dlouho jen čeká) ani z hlediska bezpečnosti/spolehlivosti (je vyšší pravděpodobnost, že uděláš chybu v těch stovkách tisíc řádků céčkového kódu, než v menším množství kódu psaného ve vyšším a bezpečnějším programovacím jazyce).

[xkucf03]

P.S. ještě k té rychlosti: čekat šest vteřin, než to napoví služby, které lze restartovat:

systemctl restart <TAB> <TAB>

je vrchol zoufalství.

[k3dAR]

zkus...

[xkucf03]

Pěkné, koukám, že je to patch z roku 2017 a vyřešené v systemd to asi pořád není.

[Heron]

Vážně toho systemd přináší tolik navíc, aby to opodstatnilo takový nárůst komplexity?

Na toto neumím odpovědět, protože příliš neznám ty ostatní projekty, ale třeba jen xinetd funkcionalita je součástí systemd také (socket activation) a pochybuju, že některé z těch jiných uvedených initů umí třeba kontejnery nebo nastavit síť. Jinými slovy se srovnává nesrovnatelné. Co s tím mají společného ty programovací jazyky už vůbec nechápu. Ty jazyky jsou dost jednoduché (Lua) a asi je to bez knihoven a sám jsem si kdysi napsal interpretr scheme asi a 200 řádek v C. Pochopitelně kompletně bez knihoven, pouze se základními funkcemi a aritmetikou (takže k ničemu).

A pokud přináší užitečné věci navíc, musí být nutně v jednom repozitáři a těžko použitelné samostatně a těžko vyměnitelné za něco jiného? (tím se opět dostáváme k tomu chybějícímu standardu a API)

No já hlavně nevím, jak těžko vyměnitelné to ve skutečnosti je. Nevím o žádném pokusu přepsat nějakou část systemd třeba v jiném jazyku. Jít by to mělo, je to OSS. K té samostatné použitelnosti, myslím si, že kdyby se třeba z systemd-networkd vyjmula jen ta část čtoucí konfigurační soubory a nastavující síť, tak by to mohla být samostatně funkční utilita. (Přičemž nepochybně ten parsing ini-like konfigů bude někde napsán obecně.)

Když se podíváš na ta čísla výše, tak si lze představit variantu, kde vezmeš nějaký základ psaný v C (nižší desítky tisíc řádků kódu nebo i jen tisíce), přibalíš k tomu VM/interpret/kompilátor a zbytek napíšeš ve vyšším programovacím jazyce… a pořád bude celková komplexita nižší, než u toho systemd.

Do výběru jazyka nikomu kecat nebudu. Pokud jim to funguje v C, tak ať to píšou v C. Osobně bych raději viděl nějaké bezpečné jazyky typy rust nebo go, ale nezdá se, že by zrovna C bylo tím kamenem úrazu.

Akorát nevím, co by to mělo přinést navíc. Ok, budeš tam mít init jako binárku napsanou v C, potom tam budeš mít "vše nad tím" napsané v nějakém interpretovaném jazyky. Takže kromě systemxkfc tam budeš mít ještě interpretr. Jak se to liší od stavu, kdy byl init v C a zbytek v shellu?

[Aleš Kapica]

Mně je celkem jedno co se používá, pokud je to dobře zdokumentované. Faktem je, že za drtivou většinu problémů co jsem řešil nebylo systemd jako takové, ale to že se ho někteří maintaineři balíků rozhodli ignorovat, takže chyběly odpovídající unity, nebo byly tupě převzaté z jiných distribucí. Což pochopitelně potom nabouralo závislosti a nastartoval celý řetězec problémů.

Z mého pohledu je tedy úplně jedno, jestli musím editovat blbě udělaný init skript, nebo napsat vlastní unitu, kterou bych přerazil tu z balíku.

[Käyttäjä 11133]

kterou bych přerazil tu z balíku.

To je tak trosku problem te distribuce kterou pouzivas ne?

[Aleš Kapica]

Jak se to vezme. Ale bavíme se o době několik let zpět, kdy se systemd začal do distribucí tlačit a někteří maintaineři to odmítali brát na vědomí. Pak se forknul devuan, tam nalezli svou parketu a je klid.

[figliar0]

Že se mainstream distribuce rozhodly balit vše najednou není problém na straně systemd projektu.

Možno súhlasiť s tým, že by malo byť na rozhodnutí distribútora, ako systemd zabalí. Ale ako je možné, že sa všetky mainstream distrá rozhodli zabaliť to dokopy? Robí to vôbec niekto ináč (hoci aj nie-úplne-mainstream)?

O tom som písal. Ak by aj systemd bol modulárny, používateľom je z toho prd, keď sa to v praxi nedá veľmi použiť.

[JS1]

Co mi neni jasne z puvodniho blogpostu. Ty si predstavujes, ze systemd (nebo neco podobneho) bude nejak "Unixove" modularni. Ale muze byt system, ktery se snazi byt jakymsi spravcem systemovych sluzeb (ridi jejich zivotni cyklus), modularni? Z definice potrebuje prece vedet, co ktera ta sluzba znamena, a potrebuje chapat rozdily v pozadavcich jednotlivych sluzeb.

[xkucf03]

Nevím, jakou má přesně představu figliar0, a budu rád, když ji sem rozepíše, ale za mě:

Z definice potrebuje prece vedet, co ktera ta sluzba znamena, a potrebuje chapat rozdily v pozadavcich jednotlivych sluzeb.

Tohle právě není pravda. Init systém nepotřebuje znát specifika jednotlivých služeb. Viz #228 a zejména poslední odstavec. Konkrétní instance/parametrizace init systému nasazená na nějakém konkrétním stroji (nebo její šablona obsažená v určité distribuci) tato specifika znát musí (např. vědět, že potřebuji síťové rozhraní s IP adresou 192.168.1.4, a až teprve potom můžu startovat Apache, nebo že pro spuštění PostgreSQL je potřeba mít připojený oddíl /var/lib/postgresql/), ale software, na kterém je to postavené, je znát nemusí – ba dokonce by je ani znát neměl a měl by od nich abstrahovat.

A mimochodem: nebyl jsi to ty, kdo tu psal o tom, že by se měl rozlišovat vývoj těch stavebních kamenů a vývoj aplikací z nich postavených a že to jsou odlišné role?

Je samozřejmě dobré mít nějaké návrhové vzory a doporučení pro distribuce, jak z těch základních stavebních kamenů poskládat operační systém a držet tak nějakou úroveň kompatibility/podobnosti napříč distribucemi. A klidně se ta sada doporučení může jmenovat „systemd“. Ale mělo by to být primárně doporučení nebo standard – zatímco softwarová implementace je něco jiného. Implementace by podle mého měla spočívat v malých samostatně použitelných komponentách a malém jádře.

[JS1]

IMHO neco takoveho zkousel upstart.. a Poettering ma nekde tusim na svem blogu vysvetleno, proc to systemd tak nedela. Ja jako chapu, ze maji lidi se systemd prakticke problemy, spis mi neni jasne, jestli to lze vubec udelat jinak.

[xkucf03]

Ja jako chapu, ze maji lidi se systemd prakticke problemy

Abych se přiznal, tak já s ním zase tolik praktických problémů nemám – a jak jsem tu psal, některé věci se mi na něm líbí a dokáži je ocenit. Přistupuji k tomu podobně jako Heron tzn. když používám distribuci se systemd, tak bych se měl naučit ho používat, a ne předstírat, že tam systemd není a bastlit si to nějak bokem.

spis mi neni jasne, jestli to lze vubec udelat jinak.

Můžeš to trochu rozvést?

a) Co od systemd čekáš?

b) Kterou tuto funkcionalitu (nad rámec jiných init systémů) nelze vyčlenit do volitelných modulů?

[kralyk z abclinuxu]

Kterou tuto funkcionalitu (nad rámec jiných init systémů) nelze vyčlenit do volitelných modulů?

Pravděpodobně jakákoli funkcionalita lze vyčlenit do volitelných modulů. Mohl bys klidně dát dokupy brutálně modulární init systém + utility nad brutálně modulárním mikrokernelem a v tom mít samé brutálně modulární programy. Byl by z toho modulární ráj (nebo peklo, záleží na úhlu pohledu).

[xkucf03]

JS1 psal:

spis mi neni jasne, jestli to lze vubec udelat jinak.

Tak jsem se těšil, že se dozvím o něčem, co skutečně nejde – ne jen o něčem, co je obtížné.

Jinak je tedy běžné dělat při vývoji kompromisy a mít na různých projektech různě nastavené priority (což zahrnuje i vzdát se věcí, které jsou moc obtížné, byť proveditelné). Takové kompromisy dělám v podstatě pořád a kdybych např. vyvíjel jednorázový web, který má pár měsíců sloužit nějaké kampani, a pak se zahodí, tak bych tam patrně těch kompromisů a prasáren udělal spoustu, protože investovat do toho víc práce nemá smysl. Ale pak tu je software s podstatně delším životním cyklem¹, kde se naopak těch kompromisů má dělat méně a je na místě investovat více úsilí a přemýšlení. A zrovna init systém podle mého patří spíš do téhle kategorie než do té první.

_{[1] a musím říct, že takový software je mi bližší a zajímá mne víc}

[sigma]

Ale pak tu je software s podstatně delším životním cyklem, kde se naopak těch kompromisů má dělat méně a je na místě investovat více úsilí a přemýšlení.

Again - Platí toto i na (linux) kernel? (v reakci na #221 jsi mi neodpověděl) Stabilní API pro moduly by tam jistě technicky šlo udělat, je to software s velice dlouhým životním cyklem, ale nějak to k tomu nesměřuje.

A pak sice existuje velmi stabilní userspace API, ale to je tak implementation-specific, že ho v plné šíři reálně těžko někdo bude reimplementovat. Microsoft to zkoušel s WSL, což je zajímavý výkon, ale nakonec to vzdali a WSL2 využívá nativní linux kernel implementaci.

[figliar0]

Predstavujem si to nejak tak, že systemd (v zmysle init systému alebo povedzme "správcu systémových služieb") nebude obsahovať funkcionalitu nastavovania sietí, správy používateľov, NTP démona a pod. Pretože trebárs ten NTP démon je tiež len systémová služba a správca takej služby ju má spravovať, nie suplovať. Systémové služby by mali byť samostatné a nahraditeľné programy/démony (implementácie). Podobne ako mám v repozitároch niekoľko implementácií napr. cronu, web servera a podobne.

Presne tak ako píše xkucf03:

Implementace by podle mého měla spočívat v malých samostatně použitelných komponentách a malém jádře.

[Käyttäjä 11133]

a malém jádře.

HURD!

[JS1]

No, to by slo.. ale pak by asi muselo existovat API, pod kterym budou ty sluzby komunikovat s tim spravcem sluzeb (neboli, ten spravce sluzeb musi mit prehled, co se deje). Tzn. by to znamenalo takove API vytvorit a tudiz nahraditelnost tak nejak mizi tak ci onak.

To je stejny problem jako ma ten Hurd. Ty muzes vzdycky rict, tenhle kus SW je malo modularni, protoze tady tyhle dve komponenty muzou byt oddelene (asi jako muze kreacionista namitnout, ze nelze najit dalsi evolucni meziclanek). Ale od jiste urovne uz to proste nebude z inzenyrskeho pohledu prakticke. Pokud je to potrebne API natolik detailni, ze nelze vymyslet jinou implementaci, pak uz na tom oddeleni nesejde.

A ja u techto systemovych demonu nevidim, jak by bylo mozne chtit pozadovat jinou implementaci, aniz by se tim nezmenilo pozadovane rozhrani. (Mozna to jde, jen mi to neprijde u tech casti, ktere resi systemd, jako trivialni uloha ukazat.)

[kralyk z abclinuxu]

Tzn. by to znamenalo takove API vytvorit a tudiz nahraditelnost tak nejak mizi tak ci onak.

Nezmizí, protože zasedne komise plná moudrých lidí a ta schválí API standard a bude vydávat jeho sémantické verze. Každý modul se pak bude hlásit k nějaké verzi a vždycky si vyjedná se správcem a s ostatními moduly vzájemné kompatibility, a bude to celé super.

_{(Dělám si srandu, samozřejmě...)}

[ChronicPain]

Bude se verzovat i ta komise?

32ae763 BUG-3815: Removed J. Doe from the project (made a joke about trans people two decades ago)

[xkucf03]

Zajímavé je, že na desktopu se řada specifikací podařila dohodnout: Interoperability specifications. Kromě toho tu máme POSIX, máme standardy programovacích jazyků, datových formátů, máme standardní API pro přístup k souborovým systémům, k síťovým soketům, k hardwaru atd. Interoperabilita a standardizace je běžně součástí našeho oboru. Tak proč by to zrovna v případě init systému měl být problém?

[kralyk z abclinuxu]

To byla nadsázka. Jinak ano, je možné, že se to časem standardizuje, ale spíš bych čekal, že se standardizuje třeba formát unit apod., API mezi moduly bych nečekal.

POSIX ti taky neříká, že máš mít microkernel...

[xkucf03]

Jinak ano, je možné, že se to časem standardizuje, ale spíš bych čekal, že se standardizuje třeba formát unit apod.,

Ale vždyť o tom tu už dva dny mluvíme, Mlho! Viz #213 a ta diskuse v gnu-system-discuss:

Convert – or even load at runtime – the systemd declarative configuration files. This also requires a stable standard.

A když jsem tam psal o standardizaci API, tak jsem explicitně zmiňoval tu socket activation. To rozhraní může být úplně triviální, stačí si např. dohodnout názvy proměnných prostředí, přes které se předá informace o zděděných FD. To může být specifikace na jednu A4. A jde o to, že tohle je velmi užitečná funkcionalita a kdyby byla standardizovaná, mohly by ji implementovat jiné init systémy (nebo i takový xinetd nebo různé zavaděče) a aplikace by ji mohly využívat nejen v systemd.

[kralyk z abclinuxu]

Myslel jsem, že ti jde o rozdrobení systemd do modulů (#269).

[xkucf03]

Jenže modul je v tomhle případě většinou nějaký démon a tam žádné složité rozhraní vymýšlet nemusíš – prostě spouštíš proces. Maximálně by tam bylo nějaké obecné rozhraní na posílání zpráv o dostupnosti těch zdrojů.

[Heron]

Tak příště si nejdřív přečtu všechny nové komentáře a až potom budu reagovat.

+1

[Gilhad]

Spravce sluzeb potrebuje umet sluzbu na pozadani zapnout a vypnout. Pokud sluzba vyzaduje jine sluzby, tak je musi zapnout driv, nez zapne tu danou sluzbu. Pokud sluzbu vypina, ci restartuje, tak by mel nejdriv povypinat vse, co na ni zalezi (a pripadne pak zase pozapinat). A to je asi tak vsechno, co potrebuje vedet a ty sluzby k tomu zadne zvlastni API ani nepotrebujou (krome klasickeho exit kodu, kterym daji najevo, zda se je podarilo nastartovat).

Samozrejme se daji vymyslet dalsi vychytavky, jako ze by si pamatoval, co bylo volano primo a co jen jako zavislost a pokud to je jen zavislost veci, ktere uz skoncily, tak to vypnout taky, ale ani k tomu nic od tech sluzeb vlastne nepotrebuje.

A eventualne pri uklidu systemu pripadne zkusit ty sluzby zabit natvrdo (a dal je mit za mrtve), pokud pri pokynu k vypnuti vrati neuspech. (Pokud si to vypnuti preji nejak osetrovat (treba databaze, ze jeste dumpne data na disk), jinak staci obycejny signal).

[xkucf03]

Spravce sluzeb potrebuje umet sluzbu na pozadani zapnout a vypnout. Pokud sluzba vyzaduje jine sluzby, tak je musi zapnout driv, nez zapne tu danou sluzbu. Pokud sluzbu vypina, ci restartuje, tak by mel nejdriv povypinat vse, co na ni zalezi (a pripadne pak zase pozapinat). A to je asi tak vsechno, co potrebuje vedet a ty sluzby k tomu zadne zvlastni API ani nepotrebujou (krome klasickeho exit kodu, kterym daji najevo, zda se je podarilo nastartovat).

+1

Nicméně i kdyby tam nějaká komunikace nad rámec toho návratového kódu měla být, tak to právě má řešit ten standard/API. Není to nic, nad čím by se nějaká komise musela scházet dva roky. Může se použít např. D-Bus nebo ten proces může zdědit FD, do kterého pak posílá zprávy v nějakém dohodnutém formátu…

[xxx]

Tak zacne to tak nadejne, a pak "A eventualne...". Takze kdyz uz si nakousl stop, tak force-stop by v API byt nemelo? A nemelo by tam byt treba vic moznosti zastaveni? A pak start, takze treba check jestli uz nebezim. Pidfile? Nebo neco lepsiho, aby to neskoncilo na klasickem, init spusti sluzbu, ktera pak cekuje nejakej socket jestli uz je sluzba na ktere zavisi ready? Co treba sit... NTP (thx heron).... a samozrejmne ta socket activation (pise to xfcuk03, tak je asi hodne dulezita).

Jeste chvili chlapci a definice API bude obludnejsi nez cely systemd. Nebo se muzete vydat smerem k jednoduchosti a vzit rovnou procd z OWRT.

[Gilhad]

Tak za me bohate staci, kdyz skript v /etc/init.d ma parametry start|stop|zap (pripadne i restart) a funkci depends() obsahujici need a after - kde prosim najdu pozadavky pro systemd na jednom radku?

[xxx]

Ja netvrdim, ze to systemd vyresil. Ja tvrdim, ze se systemd snazil vyresit ten neskutecny bordel bashovych skriptu, nepsanych zakonu a hacku v programech, diky kterym jsi mohl mit primitivni init.

Takze pokud za start nepovazujes fork() + exec() a za stop killall -9 $PROCNAME., pak proste nevyhnutelne skoncis u neceho jako systemd nebo nebo u primitivniho initu se spoustou balastu okolo.

[xkucf03]

Tak to si opravdu nemyslím. Viz srovnání různých systémů v #234 v té komplexitě je tam obrovské rozpětí a systemd je o řád až o dva složitější než ostatní. Tzn. je nesmysl tvrdit, že to bude buď a) primitivní init s pár řádky v C a hromadou bordelu v různých skriptech nebo b) systemd se 480 000 řádky kódu a celkem hezkými konfiguráky. Mezi těmito extrémy je celá škála dalších možností resp. spíš to ani není jednorozměrná osa.

[Käyttäjä 11133]

Mi se treba dost libi Supervisord, pouzivam ho v Docker kontejnerech, kdyz je to use-case kde nema smysl ty jednotlive aplikacni komponenty separovat do ruznych micro-service; ale rozhodne nejsem kompetentni posuzovat komplexitu kodu,...

[xkucf03]

Dobře napsaný software tohoto typu by měl jít použít rekurzivně tzn. zanořovat víc jeho instancí do sebe – kde jedna instance je třeba ten systémové init a další třeba správce nějaké komplexnější aplikace nebo správce desktopových služeb jednoho konkrétního uživatele…

Resp. mluvím o znovupoužitelnosti – pokud se jednotlivé komponenty/moduly izolují do samostatně funkčních celků (tzn. to klasické: program má dělat jednu věc a má ji dělat pořádně), tak je jde opakovaně používat v různých rolích.

[sigma]

Do těch 480k LOC počítáš celé git repository systemd? To není úplně fér. V tom repository projektu systemd je řada dobře oddělených komponent (namátkou timesyncd, resolved, networkd, journald, nspawn, boot, celý udev ...), které není třeba ani kompilovat ani instalovat a používat pokud je nepotřebuju. Stejně jako jsou v repository linux kernelu veškeré drivery, filesystémy a další věci, které reálně nikdo úplně všechny najednou nekompiluje.

Pokud se bavíme o systemd v kontextu initu, tak to je PID 1, libsystemd, systemctl.

[Heron]

Asi tak, na to už jsem Frantovi reagoval a zůstává to bez reakce.

[xkucf03]

To není úplně fér.

To není můj problém, ale autorů. Celé dohromady je to jeden produkt se společným verzováním, celé dohromady se to jmenuje systemd a je to v jednom repozitáři.

Kdyby autoři chtěli, aby to lidi vnímali jako sadu¹ malých samostatně použitelných nástrojů, tak to měli zřetelně oddělit, vhodně pojmenovat a ukazovat, jak lze jednotlivé části používat samostatně nebo je nahrazovat jiným již existujícím softwarem. Tohle ale zjevně není jejich/jeho záměr.

_{[1] podporující nějaké společné paradigma, filosofii}

[sigma]

To není můj problém, ale autorů.

Tvůj problém je, že z metriky "LOC v repository celého projektu" a porovnání s jinými projekty zcela jiného typu děláš nějaké závěry.

Ale ano, vize autorů je jiná, než desítky modulů s různými verzemi propojené dokonalým sémanticky verzovaným API. Z mé zkušenosti to na use cases, na které se systemd od začátku zaměřuje, funguje velmi dobře, a celý tento projekt, platforma beyond linux kernel, nám přinesl řešení řady dlouhodobých problémů. Systemd projekt je dost flexibilní co se týká způsobu nasazení, ale nikomu to necpe a není to preferovaný způsob použití. Je pravda, že řada věcí je zdokumentována jen povrchně / technicky, a chybí nějaké oficiální best practices. Místo toho se po webu povalují hromady návodů jak co udělat se systemd, velmi často plné nesmyslů a nefunkčních hacků. Ale jakým způsobem to bude zabaleno a integrováno je starost správců distribucí.

[k3dAR]

[...] systemd [...] nám přinesl řešení řady dlouhodobých problémů [...]

asi jak komu, me prijde ze resi problemy ktere sem nemel a prinesl problemy ktere sem taky nemel napr.
1. datovy disk v /etc/fstab, odpojim, rebootnu a system skonci v emergency, bez site, bez ssh i presto ze ten datovy disk neni pro start systemu potreba...
2. bez nekolika dodatecnych kroku, se mi byobu/tmux po odhlaseni killne
3. vice sitovek, pouzival sem udev pravidlo ktere dle MAC vzdy zajistilo jmena+poradi sitovek, nejakou dobu to slo i se systemd, ale nedavno mi je to prestalo pojmenovavat spravne, presel sem na "predictable" nazvy ale nasledne se mi (ne)predvidatelne pojmenovaly sitovky jinak kdyz se vlozil do slotu sata radic...

zjisteni stavu, paralelni spousteni sluzeb vcetne poreseni poradi/zavislosti sem mel uz s upstart...

[xxx]

Jeste by si mel k GNU Shepherd pripocitat radky z GNU Guile, pokud je potreba interpret toho jazyka pri behu.

[xkucf03]

Viz #234:

Když se podíváš na ta čísla výše, tak si lze představit variantu, kde vezmeš nějaký základ psaný v C (nižší desítky tisíc řádků kódu nebo i jen tisíce), přibalíš k tomu VM/interpret/kompilátor a zbytek napíšeš ve vyšším programovacím jazyce… a pořád bude celková komplexita nižší, než u toho systemd.

Kromě toho VM/interpret/kompilátor je znovupoužitelný kus kódu a i když ho používáš opakovaně, jeho komplexitu máš v systému jen jednou (na rozdíl od řádků aplikačního kódu, který je jednoúčelový).

[Gilhad]

No, ja rozhodne davam prednost jednoduchemu initu, kde mam jednoduche bashove skripty

Balast jako ze by to melo mit sekci start|stop|depend|restart a kazda zabere par radku, pokud to ma byt uhledne, prikaz pro spusteni/zastaveni sluzby (ktery nutne musi byt v nejake forme stejne pritomny) a pak uz jen to, co prislusna sluzba vyzaduje naprosto unikatniho - tedy u svych sluzeb to prehlednu snadno a snadno se v tom vyznam a u ostatnich me to nezajima, protoze je staci spravne nakonfigurovat v jejich konfigurakach a dal to proste funguje - tak takovy balast mi fakt nevadi.

Naopak jsem rad, ze mam moznost si snadno nastavit vse potrebne a nemusim to slozite roubovat na nejakou obludnost, co se snazi resit vse a pritom nema silu to udelat poradne, prehledne a jednoduse.

[kralyk z abclinuxu]

No jo, jenže ten problém byl v tom, že ten kód volající ty skripty byl taky v bashi, takže enumerace služeb, dependency resolution atd. všechno v bashi. Sorry, ale to mi přijde jako šílenost. To je IMO něco, co by mělo být napsáno v programovacím jazyku. Mít definice služeb v bashi (s těmi funkcemi, co jsi vyjmenoval), s tím, že by to bylo volané z programu, to už dává větší smysl, ale pak už dává smysl rovnou použít spíš nějaký skutečný skriptovací jazyk...

[Gilhad]

Tak prepsat jednoduchy init aby pouzival na volani tech skriptu neco v prekladanem jazyce misto v bashi by nemela byt az tak rozsahla prace - navic je otazkou, zda se to vyplati optimalizovat takto, kdyz se to pouzije jen velmi zridkakdy. Pouzit v tech definicich "skutecny skriptovaci jazyk" misto bashe by pak mohlo mit smysl, ale asi by se tim spousta veci lehce zeslozitila (pouzivani knihoven misto programu s vyrazne vetsi funkcionalitou, nebo jejich spousteni prez knihovny a tak - ale vhodna volba toho skriptovaciho jazyka by to mohla udelat celkem snadne) - na druhou stranu tady nevidim ten zasadni problem - kdyz jde o veci jednoduche coz vetsinou jde), tak se to v bashi zapise snadno, pokud jde o veci sloitejsi, neni problem z bashe zavolat neco v jinem jazyku, co zrovna tohle poresi (find, grep, sed ... nebo treba skript)

[xkucf03]

Viz GNU Shepherd – ten používá je nejen „skutečný skriptovací jazyk“ ale rovnou „skutečný programovací jazyk“ – je to postavené na Guile (Scheme). Nicméně pro průměrného admina bude stravitelnější ten Bash, se kterým pracuje každý den, než nějaký dialekt Lispu s kopou kulatých závorek.

Výhoda psaní i toho jádra v Bashi je v tom, že z něj přímo můžeš volat jiné Bashové funkce – nevoláš je jako systémové příkazy (nové procesy), ale tvoří to jeden program psaný v jednom jazyce.¹ A Bash je rozšiřitelný, můžeš si do něj dopsat modul (dynamickou knihovnu), která přidá nové příkazy – tento modul píšeš v C, ale přes něj můžeš volat cokoli dalšího, takže klidně i interpret nějakého jiného jazyka. To jádro init systému bys tudíž mohl napsat v čemkoli a integrovat to s Bashem a zároveň z toho přímo volat funkce definované v těch init skriptech.

Neříkám, že tohle považuji za ideální způsob, ale schůdné to je – fakt to nemusí vypadat jako hromada hnoje a být nějak extra složité. Osobně mi přijde lepší mít ty konfiguráky služeb deklarativní, v podobném stylu jako systemd, akorát to jádro init systému implementovat jinak, jednodušeji, abstraktněji a nepřibalovat k němu hromadu nesouvisejících programů.

_{[1] i když tedy jak kde – já znám spíše init skripty, které se volají jako příkazy s parametrem start, stop atd. než že by se jejich zdroják vložil přes . nebo source a volaly se jeho funkce přímo}

[kralyk z abclinuxu]

Nicméně pro průměrného admina bude stravitelnější ten Bash, se kterým pracuje každý den, než nějaký dialekt Lispu s kopou kulatých závorek.

Určitě existují i jiné, familiérnější možnosti než bash a guile.

Výhoda psaní i toho jádra v Bashi je v tom, že z něj přímo můžeš volat jiné Bashové funkce

To považuju za nevýhody - tímhle způsobem vznikají prasárny.

nevoláš je jako systémové příkazy (nové procesy), ale tvoří to jeden program psaný v jednom jazyce.

Meh, bash vytváří subprocesy celkem často, např. když použiješ pajpu apod... A lidi z toho stejně volají různé další věci jako sed, awk, perl, python, ...

[Heron]

No, ja rozhodne davam prednost jednoduchemu initu, kde mam jednoduche bashove skripty

Já taky, proto jsem přešel na FreeBSD.

Jak už jsem psal mnohokrát, nepovažuji za hlavní problém to, v jakém jazyku je to či ono napsané, ale spíš kdo a jak to píše. V rc skriptech v linuxu byl bordel, po přechodu na systemd začíná být bordel v unitách. Evidentně není problém v shellu a ani v systemd.

[Käyttäjä 11133]

Tak to je vzdycky o tom, jake balicky (od koho) vyuzivas...

[xxx]

A mluvis o skutecnem startu a skutecnych dependencich, nebo jen o tupem spusteni sluzeb za sebou? To si nejdriv ujasni. Protoze, kdyz vezmu ten nejtupjejsi priklad B zavisi na A a povidaji si spolu pres shmem nebo socket, tak reseni startu a zavislosti vypoada zpusobem:

- spust A (fork, exec)

- spust B (fork, exec)

Coz vede k takovym komickym workaroundum v onech programech, jako ze B, kdyz nenajde socket, shmem, nebo tak, tak to zkousi tupe znovu. Pokud je B napsany tak, ze exitne, pak se obali bash scriptem. Nekdo pridava magicke delay constanty, atp. Zkratka perfektni ukazka paralelniho programovani. A to jsme jenom u startu. Restart a podoben je jeste vetsai peklo.

Takze jestli nekdo tvrdi, ze v Linuxu existuje spolehlivy a jednoduchy system na mgmt sluzeb, pak vydava hovna za cokoladu. (Ne ze by systemd zrovna tohle resil ale v Upstartu o to snaha byla, jenze ten taky nemel par radek.)

[xkucf03]

Coz vede k takovym komickym workaroundum v onech programech, jako ze B, kdyz nenajde socket, shmem, nebo tak, tak to zkousi tupe znovu. Pokud je B napsany tak, ze exitne, pak se obali bash scriptem. Nekdo pridava magicke delay constanty, atp.

Viz #266. V dobrém init systému by služby mohly informovat ostatní o dostupnosti zdrojů (např. soketu nebo té sdílené paměti) v průběhu svého života. A init systém by na základě těchto událostí a nakonfigurovaných pravidel prováděl různé akce (např. spouštěl jiné služby).

[Heron]

Ano, toto je zcela legitimní požadavek, kterému rozumím a takto se na systém dívám taky.

Dovedu si však představit systém postavený na zcela jiných základech. Uvedu příklad.

Pretože trebárs ten NTP démon je tiež len systémová služba a správca takej služby ju má spravovať, nie suplovať.

Dejme tomu, že provozujeme nějakou službu, u které se nesmí rozjet čas a v podmínkách provozu té služby je uvedeno, že pokud není možné synchronizovat čas (nebo synchronizaci ověřit), tak je nutné službu odstavit. Pokud je to služba systemd-like, dovedu si představit závislost na NTP synchronized. Tj když se správce služeb dozví od timesyncd, že nelze dosáhnout / ověřit sync, tak tu závislou službu vypne. (Upřímně řečeno, nevím, zda tam teď taková možnost je a překvapily by mě vlastně obě možnosti, tj že to tam není i že to tam je. Vlastně bych to tam očekával.)

A ano, stejné funkcionality lze dosáhnout dneska. Nějaký skript může očuchávat statistiky ntpd a když se mu nelíbí, tak tu službu vypnout (voláním systemctl nebo přes dbus). Jenže nebylo by lepší to psát deklarativně? Jako jasnou podmínku pro běh dané služby? Tak jak se píší ostatní podmínky pro systemd .service?

Což se ale nevylučuje s modularitou. Může existovat API, které pro ntp definuje rozhraní pro ověřování stavu a tato služba bude připuštěna jakou součást správce služeb. Opět si dovedu představit ten řev, který by vnikl u zprávičky "všechny NTP démoni musejí definovat api".

[Gilhad]

No ja zadnou takovou sluzbu (tedy sluzbu, kterou by bylo nutno systemem sestrelit kdykoli si nebude ntpd jisty jzda je synchronizovany) neprovozuju, takze nepotrebuju mit soucasti initu ntpd.

Ale samozrejme si muzeme predstavit i sluzbu, kterou je nutno sestrelit, pokud se cas rozejde o vic nez jednu sekundu a tak je nutno preventivne udelat i API pro NTP nearly-synchronised a pro sluzbu, ktera se spokoji s minutama api NTP not-so-nearly-synchronised ...

Nebo sluzbu pro nejakou hru, ktera ma ve smluvnich podmikach, ze hrac musi kazdou hodinu aspon na 5 minut prestat, takze soucasti init systemu pak bude samozrejme i graficky server a screensaver s nastavitelnou dobou, kdy nejde odstranit. Nebo sluzbu, ktera ma v podmikach provozu, ze uzivatel musi mit platnou licenci a tak initsystem bude obsahovat i pripojeni se k serverum prislusne spolecnosti a prubezne overovani licenci ...

Me to teda prijde jako blbina.

[Heron]

No ja zadnou takovou sluzbu (tedy sluzbu, kterou by bylo nutno systemem sestrelit kdykoli si nebude ntpd jisty jzda je synchronizovany) neprovozuju, takze nepotrebuju mit soucasti initu ntpd.

Gratuluji. Třeba my něco takového provozujeme (nikoliv přesně tak jak bylo popsáno výše). O tom ovšem komentář nebyl.

Pokud už máme deklarativní popis, tak je logické do toho deklarativního popisu přidat vše potřebné. A tedy i odchylku od etalonu času.

ktera se spokoji s minutama

Za to by měl být admin automaticky zastřelen. Před lety mi jeden známý řekl, že on má čas správně a to, že se rozcházíme o 3 minuty znamená jen to, že on se synchronizuje s jiným serverem. Netuším, v jakém vesmíru žije, ale ten jeho server musel být patrně někde blízko horizontu černé díry.

[Gilhad]

ktera se spokoji s minutama

Za to by měl být admin automaticky zastřelen.

Tak to ma cron teda blby :)

(aspon v zadnem jsem nevidel presnejsi zadavani udalosti, nez na minuty - a to jeste vetsina z toho byla typu "tady nekde by se to asi tak melo udelat, jen to nechceme nahnacat vsechno naraz" nebo "tak jednou za hodinu ...")

[Heron]

ktera se spokoji s minutama api NTP not-so-nearly-synchronised

Neodváděj pozornost jinam, řeč je o synchronizaci času a nikoliv o tom, jak přesně se musí spouštět daná služba. V předchozím komentáři jsi napsal NTP nearly-synchronised a NTP not-so-nearly-synchronised z čehož to jasně plyne.

Jinak nikomu nebrání si i na stroji s mikrosekundovou přesností času nastavit AccuracySec= klidně na hodiny. Nebo třeba na To get best accuracy, set this option to 1us.

[Gilhad]

Ano, cron je podle me sluzba, ktera nepozaduje, aby NTP bylo zcela synchronizovane, ale bohate mu staci, kdyz neni uplne totalne mimo. Na druhou stranu pokud by se cas nedal rozumne synchronizovat, ani se k tomu nejak vzdalene neblizil, ale naopak by se rozchazel prilis moc, tak uz ma problem. Nepotrebuje aby cas byl synchronizovany na milisekundy, ale pokud se rozchazi o hodiny a neda se synchronizovat, tak uz je to spatne.

Takze stejne jako ty si dokazes predstavit sluzbu, ktera vyzaduje plnou synchronizaci, tak ja si dokazu predstavit sluzbu, u ktere neni na prekazku, pokud neni cas presne synchronizovan, ale uz vadi, kdyz je nesynchronizovan prilis moc (a samozrejme to nemusi byt jen cron, klidne to muze byt neco, co sbira nejaka data v zavislosti na case, ale taky na jinych vecech, takze potrebuje jednak nejakym zpusobem pricetny ((kdyz uz ne zcela presny) cas ale na druhou stranu se neda jen naplanovat na zaklade casu jako na sobe nezavisla mereni.)

---

Ostatne, kdyz uz nemame odbihat od tematu - jak to teda bude s tema licencema? Klidne si dokazu predstavit sluzbu, ktera ma v podminkach jejich overovani, tak proc to neudelat deklarativne, ze by se init sam pripojoval na licencni server a sluzbu pripadne sestrelil, pokud by se licence nedala overit, nebo expirovala? Jenže nebylo by lepší to psát deklarativně? Jako jasnou podmínku pro běh dané služby? Tak jak se píší ostatní podmínky pro systemd .service?

[Heron]

kdyz neni uplne totalne mimo

Problém je, že to se musí vždy určit nějakou konstantou. Čas mezi různými událostmi nelze synchronizovat přesně ani podle STR a podle OTR už záleží i na poloze v gravitačním potenciálu. Takže za "synchronizovaný" čas se musí vždy určit konkrétní odchylka (100us, 1ms, 1s apod.) A to jsem psal už v předchozím komentáři:

A tedy i odchylku od etalonu času.

Tj deklarativní popis něco jako NTPTimeOffsetOK=10min. (Za což by admina opět měli zastřelit.)

kdyz je nesynchronizovan prilis moc

Akorát nevím, jak by se to určovalo, protože bez funkčního autoritativního NTP serveru nelze zjistit, jak moc je ten čas mimo. Takže pokud je ntp sync, tak je to pár us, pokud není, tak to stejně není možno dlouhodobě určit. (HW zdroje času v PC jsou notoricky známé svou výraznou nepřesností.)

Ostatne, kdyz uz nemame odbihat od tematu - jak to teda bude s tema licencema?

Doporučoval bych používat svobodné licence a tento problém neřešit. Jinými slovy mě to vůbec nezajímá. Správný čas je legitimní požadavek v provozu serverů. Proprietární licence nikoliv.

[Gilhad]

Tak init se netyka jen serveru, ale dobre, napriklad databaze, webove servery, VPN, High-availability clusters, RAID a mnohe dalsi jsou na serverech taky v mnoha pripadech legitimnim pozadavkem - mam tedy cekat, ze budou zahrnuty do systemd?

[kralyk z abclinuxu]

systemd snad umí databázi nebo http server nastartovat už teď, ne?

[Heron]

Ano, myslím si, že jistý zcela legitimní koncept initu může být o tom, že init bude úzce spolupracovat s jednotlivými službami. Jinak mě se líbí, jak se tady obhajuje abstraktní koncept čehosi, jako by bylo podřadné skutečně pojmenovat věci tak jak jsou. Součástí serveru je network tak proč nemít v initu přímo ovládání networku? Klidně i databáze. Video k tématu.

[xkucf03]

Navazuji na #262 …ta zpráva (posílaná v průběhu života služby, ne nutně až při jejím ukončení) může obsahovat např. informaci, že zdroj XYZ přestal existovat. Přičemž XYZ bude nějaký globální identifikátor (může to být libovolné URI, prostě textový řetězec) a v tomhle případě tím „zdrojem“ může být synchronizace NTP. Když se nám hodiny rozsynchronizují nad nějakou mez, tak tento zdroj ztratíme, služba o tom dá vědět init systému (skrze jednoduché standardní API) a init systém dá vědět ostatním službám, které tento zdroj zajímá nebo na něm přímo závisí, případně je může ukončit, zapnout, restartovat atd. na základě deklarativní konfigurace. A pointa je v tom, že init systém nemusí vědět, co to XYZ znamená – pro něj je to pouze identifikátor a init systém pracuje pouze s abstraktním konceptem „zdroje“. Tyto zdroje se mohou objevovat a mizet kdykoli v průběhu životního cyklu služeb (přičemž služba je sama implicitně taky zdrojem, na kterém může něco dalšího záviset a odebírat o tom události). Init systém pak jen drží konfiguraci, koordinuje služby a přeposílá zprávy, ale nemusí rozumět tomu, co a proč se děje – pouze plní příkazy a pracuje na základě deklarovaných pravidel. Autor distribuce + správce daného systému jsou ti, kdo by měli vědět (a rozhodovat), proč se co děje a kdy – nikoli init systém.

Výhodou abstraktně navržených systémů je to, že mnohem lépe škálují. Jako jejich autor nemusíš rozumět všemu a nemusíš všechno implementovat¹ – jen vytvoříš prostředí a ostatní ho používají.

_{[1] viz také kapitola The great parts}

[Heron]

ta zpráva (posílaná v průběhu života služby

Posílaná kým?

služba o tom dá vědět init systému

Která služba? To má posílat ta "obalová service", nebo přímo (v tomto případě) ten ntp démon? Tu obalovou funkci řeší systemd o hodně lépe než předchozí inity (Ale fakt už, nechce to nějaký systemd-lover vzít za mě? Už je mi to trapné.) a o tom, že by přímo nějaká konkretní implementace dané služby ochotně implementovala nějaké API si můžeme nechat jen zdát.

skrze jednoduché standardní API

Takže všechny ntp démoni se mají upravit, aby podporovaly toto api? Resp. úplně všechny služby?

A pointa je v tom, že init systém nemusí vědět, co to XYZ znamená – pro něj je to pouze identifikátor a init systém pracuje pouze s abstraktním konceptem „zdroje“.

Tomu já rozumím, ale je to přenášení odpovědnosti na ty zdroje. Tj všichni ntp démoni musejí implementovat api, aby dokázali říct init systému, "pozor, ztratil jsem kontakt s GPS, ale jinak ještě žiju a čas je ok, sleduju frekvenci cpu a ta za posledních 14 dnů nevykazovala žádné mimořádnosti takže se tomu času dá ještě tak hodinu věřit do 100us.".

Výhodou abstraktně navržených systémů je to, že mnohem lépe škálují. Jako jejich autor nemusíš rozumět všemu a nemusíš všechno implementovat.

Ano. Jen ti zbývá naimplementovat ty služby / zdroje. A to ještě v několika různých implementacích, aby bylo na výběr.

Vlastně se to dá otočit. timesyncd nebo networkd a cokolivd jsou vlastně první implementace tohoto standardu. Nevím, za jak dlouho se k nim přidá ntpd nebo chronyd.

Init systém pak jen drží konfiguraci, koordinuje služby a přeposílá zprávy

Init systém nemusí přeposílat zprávy, systémová sběrnice může být zcela nezávislá. Init tam může být připojen a jen reagovat na start / stop zprávy, přičemž se řídí konfigurací.

Autor distribuce + správce daného systému jsou ti, kdo by měli vědět (a rozhodovat), proč se co děje a kdy – nikoli init systém.

Nerozumím, proč jsi zvýraznil ten init systém. Přece i dnes i autor distribuce a jeho admin rozhoduje o tom, co se kdy stane bez ohledu na zvolený init systém. Jedná se o deterministický software, takže si jej stačí řádně nastavit a používat. (Ne, to není ironie.)

Výhodou abstraktně navržených systémů je to, že mnohem lépe škálují. Jako jejich autor nemusíš rozumět všemu a nemusíš všechno implementovat1 – jen vytvoříš prostředí a ostatní ho používají.

V tom se 100% shodneme, jen je otázkou, zda se dožijeme té implementace. Tvůj koncept jde dál než systemd. Systemd alespoň obaluje stávající služby a snaží se hlídat jejich stav (a je toho schopen pouze tak dobře, jak dobře jsou napsané). Tvůj koncept spočívá v tom, že služby budou aktivně informovat o všech důležitých změnách ve svých stavech. Což je super koncept (opravdu), akorát to má drobnou vadu, že je potřeba upravit všechny služby.

Za mě, myslím si, že mnohem dříve přijdou alespoň binární stavy. ntpd-gps se prostě ukončí, když přijde o signál z gps. Nemusí nic posílat na systémovou sběrnici, init systém uvidí, že se mu služba ukončila. Dle deklarace v konfigu jí může zkusit nahodit s určitým počtem pokusů a potom jí prohlásit za mrtvou a podle toho stopnout závislé service. Přičemž se může pokoušet ji nahodit. A tak dále. I toto je hudba velmi vzdálené budoucnosti. Zatím si každá služba žije na svém písečku, pokud má api, tak to není standard a tak dále. Takže teoretický koncept je super, ale rád bych se ho taky dožil.

[xxx]

Ja bych nebyl takovej pesimista. Ony ty implementace reseni ruznych problemu jsou dost podobne i bez existujiciho API. Takze treba se jednou nekdo nastve, a pro nejaky cluster aplikaci udela svuj subinit.

[xkucf03]

Posílaná kým?

Tou službou.

Takže všechny ntp démoni se mají upravit, aby podporovaly toto api? Resp. úplně všechny služby?

Pokud chceš informace o změně stavu nebo dostupnosti zdrojů poskytovat dynamicky v průběhu života služby, tak jde o funkcionalitu navíc, kterou nikdy jiný nenabízí. Je tedy zřejmé, že k tomu nějaké API a zásah do kódu budeš potřebovat. Ale není to samoúčelný zbytečný zásah – získáš díky němu nějakou užitečnou funkcionalitu navíc.

Nicméně to nebrání službám fungovat klasicky postaru a žádné takové API nepoužívat. Pak se pomocí jednoduché deklarativní konfigurace init systému (tzn. bez zásahu do té služby) dá alespoň říct třeba: pokud jsme spustili službu X, je dostupný zdroj Y – a pokud služba X spadla, zdroj Y přestal být dostupný. Případně by init systém mohl kontrolovat, zda služba naslouchá na nějakém portu nebo vytvořila nějaký soubor či adresář a z toho odvodit dostupnost nějakého zdroje, o které informuje ostatní služby. I toto lze řešit deklarativně konfigurací a bez zásahu do existujícího softwaru. Nicméně lepší je použít to API (ale jak říkám, používal bys ho dobrovolně, protože ti to přinese nějaký užitek).

o tom, že by přímo nějaká konkretní implementace dané služby ochotně implementovala nějaké API si můžeme nechat jen zdát

Pokud by to bylo „proprietární“ API nějakého konkrétního init systému, tak ano (i když zrovna v případě systemd se to bohužel děje a vznikají programy/služby se závislostí na systemd).

Já ale mluvím o standardu, otevřeném API. Stejně jako máme standardní API pro přístup k proměnným prostředí nebo k posílání signálů mezi procesy nebo k soketové komunikaci atd. stejně tak bychom mohli mít standardní API pro komunikaci s rodičovským procesem, který dohlíží na službu a chce být informován o nějakých jejích vnitřních stavech.

Autoři softwaru běžně a ochotně implementují standardní protokoly, souborové formáty, API, SPI… je to běžná součást softwarového inženýrství a spolupráce.

Je mi jedno, jestli to vznikne v rámci POSIXu, GNU, FreeDesktopu, Linuxu, nebo jestli to třeba za víkend napíše Lennart Poettering – může to udělat kdokoli – ale jde o to, aby to byl otevřený implementačně nezávislý standard, který deklaruje dlouhodobou stabilitu a rozvoj kompatibilním způsobem.

Tomu já rozumím, ale je to přenášení odpovědnosti na ty zdroje. Tj všichni ntp démoni musejí implementovat api, aby dokázali říct init systému, "pozor, ztratil jsem kontakt s GPS, ale jinak ještě žiju a čas je ok, sleduju frekvenci cpu a ta za posledních 14 dnů nevykazovala žádné mimořádnosti takže se tomu času dá ještě tak hodinu věřit do 100us.".

Jako autor služby bys měl vědět, jaké zdroje poskytuješ a měl bys být schopný ostatním říct (přes to API), zda ten který zdroj je dostupný nebo ne. Pokud toho služba není schopná, tak je potřeba nějaké náhradní řešení, např. v konfiguraci init systému nadeklarovat, že když daná služba běží, předpokládáme, že takové a takové zdroje jsou dostupné. Ale pořád je to lepší než současný stav.

Tzn. místo toho, abys jen napsal novou implementaci démona s proprietárním rozhraním, bys definoval obecné API a dal ostatním šanci ho implementovat taky. Tvůj démon by byl první, který by to API implementoval a přinášel by oproti ostatním něco nového navíc, ale zároveň by autoři těch jiných démonů měli možnost udělat totéž a taky poskytovat informaci o dostupných zdrojích. Chápu, že se tenhle přístup nepoužívá ve světě proprietárního softwaru, kde jsou mezi implementátory nepřátelské vztahy, ale ve světě svobodného softwaru by to snad mělo fungovat jinak, ne? Pak je otázka, do jakého světa systemd patří. V diskusích se setkávám i s názory, že systemd buduje vendor lock-in. S tímto názorem nesouhlasím¹, ale svým způsobem lidi, kteří toto říkají, chápu.

Ano. Jen ti zbývá naimplementovat ty služby / zdroje. A to ještě v několika různých implementacích, aby bylo na výběr. Vlastně se to dá otočit. timesyncd nebo networkd a cokolivd jsou vlastně první implementace tohoto standardu. Nevím, za jak dlouho se k nim přidá ntpd nebo chronyd.

Jakého standardu? Kde je definovaný? Jak je verzovaný? Jak bude vypadat jeho evoluce? Bude zpětně kompatibilní?

Tohle je právě ten problém – standard neexistuje. Pokud by existoval, není vůbec žádný problém, pokud v první fázi bude existovat jen jedna² jeho implementace a ostatní se dobrovolně přidají či nepřidají později.

Init systém nemusí přeposílat zprávy, systémová sběrnice může být zcela nezávislá. Init tam může být připojen a jen reagovat na start / stop zprávy, přičemž se řídí konfigurací.

Ano, tak by to klidně mohlo vypadat, je to implementační detail. Když zde mluvím o init systému, tak nemluvím jen o PID 1.

Tvůj koncept jde dál než systemd. Systemd alespoň obaluje stávající služby a snaží se hlídat jejich stav (a je toho schopen pouze tak dobře, jak dobře jsou napsané). Tvůj koncept spočívá v tom, že služby budou aktivně informovat o všech důležitých změnách ve svých stavech. Což je super koncept (opravdu), akorát to má drobnou vadu, že je potřeba upravit všechny služby.

Viz začátek tohoto komentáře. Použití toho API je volitelné a nic ti nebrání to dělat postaru a nebo na úrovni systemd. To API bys implementoval dobrovolně, protože by ti to přineslo nějaký užitek (a kdybys v tom jako autor služby užitek neviděl, tak bys ho implementovat nemusel).

Je to trochu jako s D-Bus rozhraním – nikdo tě nenutí ho implementovat, ale pokud to uděláš, získá tím tvůj software určitou výhodu a ostatní ho budou moci používat standardním způsobem přes API.³

ntpd-gps se prostě ukončí, když přijde o signál z gps. Nemusí nic posílat na systémovou sběrnici, init systém uvidí, že se mu služba ukončila.

Tohle v tom mnou navrhovaném systému jde udělat taky. Prostě bys v konfiguraci namapoval 1:1, že: služba běží = zdroj je dostupný. Ale byla by tam otevřená cesta k tomu, aby to postupnou evolucí dospělo k něčemu chytřejšímu tzn. postupně by mohly jednotlivé služby začít používat to API a mohly by o dostupnosti zdrojů informovat dynamicky.

A tak dále. I toto je hudba velmi vzdálené budoucnosti. Zatím si každá služba žije na svém písečku, pokud má api, tak to není standard a tak dále. Takže teoretický koncept je super, ale rád bych se ho taky dožil.

Já to snad budu muset implementovat nebo aspoň sepsat jako návrh (ne jen jako komentáře roztroušené po diskusích a e-mailových konferencích) :-) Přijde mi trochu smutné, že máme nějakých dvacet implementací init systémů, nebo že systemd reimplementuje spoustu již existujících služeb a nástrojů, takže práce se již odvedlo obrovské množství, ale dosud si nikdo nenašel čas na tu standardizaci. To mají vážně všichni takový strach z paralýzy analýzou, že místo přemýšlení radši rovnou sednou a začnou něco kódovat?

_{[1] protože systemd je svobodný software, takže už z  definice závislost na jednom konkrétním dodavateli nemůže vzniknout
[2] i když často se při tvorbě standardů vyžaduje, aby existovaly aspoň dvě nezávislé implementace – což se používá jako takový test, že standard je rozumně napsaný a je schůdné ho nezávisle implementovat
[3] např. v hudebním přehrávači přepínat skladby nebo hrát či pozastavit přehrávání; nebo mít upozornění na nové e-maily, odesílat e-maily bez ohledu na použitý program…)}

[Heron]

Pokud chceš informace o změně stavu nebo dostupnosti zdrojů poskytovat dynamicky v průběhu života služby, tak jde o funkcionalitu navíc, kterou nikdy jiný nenabízí. Je tedy zřejmé, že k tomu nějaké API a zásah do kódu budeš potřebovat. Ale není to samoúčelný zbytečný zásah – získáš díky němu nějakou užitečnou funkcionalitu navíc.

Ano.

Já jenom, než budu reagovat na některé další věci, tak malý reality check. Vem si, jaký řev byl kolem toho, když tmux chtěl implementovat nějakou knihovnu, aby mohl fungovat jako před tím. A to je jedna malá drobná změna. Ty navrhuješ systém, ve kterém (jistě že ne všechny) služby budou muset implementovat daleko větší změny. Já si fakt nejsem jistý, jestli bychom se alespoň částečného výsledku dožili.

IT je, nevím proč, strašně konzervativní obor. UNIX má 50let, něco si stále taháme s sebou (nemyslím myšlenky a filozofie, spíše konkrétní implementace), systemd je tu asi 10 let a zatím v praxi vidíme spíše workaroundy, než skutečná systemd řešení a silný odpor ke změnám. (Ano, souvisí to zejména s přístupem těch protagonistů.) (O FS ani nemluvě, někdo si raději počká, než FS z roku 1994 něco naimplementuje, než aby používat aktuální dostupné řešení.)

Skoro si myslím, že by bylo jednodušší napsat nový OS na základě tvých myšlenek a naimplementovat všechno znovu podle tvého konceptu. Toto je, myslím si, i příčina toho, proč systemd implementuje některé věci po svém a nečeká na okolí.

Já ale mluvím o standardu, otevřeném API.

Jo já vím, tobě chybí API, mě u systemd chybí nějaký popis co to vlastně chce být a kam to chce směřovat, což je pro systémového inženýra dost důležité.

Autoři softwaru běžně a ochotně implementují...

... cokoliv, co je potřeba pro jejich business (ne nutně přímo komerční). Před pár lety jsem se jako systemd-hater pravidelně hádal s lidmi, kteří mi argumentovali, "že potom bude stačit dodat jednu unitu a ne psát rc skripty pro 5 initů". Mimochodem úplně stejná argumentace je i proč to není zabalené v nějakém standardním balíčku - prostě "nebudeme to balit pro rpm, deb, zbytečný." Jinými slovy ochota udělat cokoliv nad rámec nutného extrémně rychle klesá. Prostě dost pochybuju o tom, někdo bude implementovat nějaké api, které je pro něj zbytečné, stejně jako dneska je pro něj zbytečné dělat řádné balíčky.

Jako autor služby bys měl vědět, jaké zdroje poskytuješ a měl bys být schopný ostatním říct (přes to API), zda ten který zdroj je dostupný nebo ne.

Viz výše. Jedna věc je to vědět a druhá je to ochota implementovat.

Pokud toho služba není schopná, tak je potřeba nějaké náhradní řešení, např. v konfiguraci init systému nadeklarovat, že když daná služba běží, předpokládáme, že takové a takové zdroje jsou dostupné. Ale pořád je to lepší než současný stav.

Což je právě to, co na dnešní úrovni umožňuje systemd docela dobře. Lepší lepidlo pro horší služby. (Pochopitelně neumí implementovat zdroje ve tvém smyslu slova.)

ale ve světě svobodného softwaru by to snad mělo fungovat jinak, ne?

Mělo. A funguje? (Jenom disclaimer na tu tvou větu před tím, já se zabývám jen oss, proprietární software v rámci této diskuse vůbec neuvažuju.)

Jakého standardu? Kde je definovaný? Jak je verzovaný? Jak bude vypadat jeho evoluce? Bude zpětně kompatibilní?

V tom odstavci jsem se zaměřoval především na to, že pro systemd bylo asi jednodušší si ty věci implementovat znovu, než řešit API a roky čekat na to, až to napíše někdo jinej. Viz první část tohoto komentáře. O chybějící specifikaci už znovu psát netřeba.

Tohle v tom mnou navrhovaném systému jde udělat taky.

No to jsem nerozporoval, jen jsem psal, že tento čistě binární stav některých služeb nebo jejich podčástí přijde IMO dřív, než koncept založený na definici a dostupnosti zdrojů. Protože naimplementovat službu, která se ukončí, když něco nemá, je o mnoho snadnější než službu, která implementuje jakési API a posílá komplenxní zprávy.

Já to snad budu muset implementovat nebo aspoň sepsat jako návrh (ne jen jako komentáře roztroušené po diskusích a e-mailových konferencích) Přijde mi trochu smutné, že máme nějakých dvacet implementací init systémů, nebo že systemd reimplementuje spoustu již existujících služeb a nástrojů, takže práce se již odvedlo obrovské množství, ale dosud si nikdo nenašel čas na tu standardizaci.

To mi trochu připomíná ten vtip (zkrátím): "ok, takže teď máme N+1 standardů"

[xkucf03]

Já jenom, než budu reagovat na některé další věci, tak malý reality check.

Obecně díky za komentář, v lecčems souhlasím.

Ty navrhuješ systém, ve kterém (jistě že ne všechny) služby budou muset implementovat daleko větší změny. Já si fakt nejsem jistý, jestli bychom se alespoň částečného výsledku dožili.

Já si právě myslím, že podobnou změnu lze zavést evolučně. Tzn. nabídnout API, které můžeš volitelně použít a tím získat nějaké výhody a novou funkcionalitu. V podobné roli je ten D-Bus – ten taky nemusíš používat, ale autoři si do svých programů dobrovolně přidávají D-Bus rozhraní, aby umožnili ostatním s tím programem pracovat přes API. Nebo tu máš třeba System Tray Protocol Specification – to mnou navrhované API by mohlo mít podobný rozsah a složitost, není to nic velkého (řádově jednodušší než D-Bus – případně by to šlo nad D-Busem postavit a pak by se ta specifikace smrskla na jeden krátký XML soubor s definicí toho rozhraní; i když samozřejmě D-Bus sám o sobě nějakou netriviální komplexitu představuje).

systemd je tu asi 10 let a zatím v praxi vidíme spíše workaroundy, než skutečná systemd řešení a silný odpor ke změnám. (Ano, souvisí to zejména s přístupem těch protagonistů.)

Tím to asi bude – systemd má dost špatnou pověst a lidi si často stěžují na problémy ve spolupráci, když hlásí chyby nebo chtějí navrhnout nějakou vlastní změnu. Osobní zkušenost s tím nemám, ale už takhle na základě pozorování to nevypadá moc přátelsky. Řada lidí to ani nepovažuje za svobodný software (resp. jen formálně – licencí) a mluví o budování vendor lock-inu.

Úplně chápu neochotu lidí implementovat rozhraní nějakého konkrétního jednoho init systému, ve který navíc nemají velkou důvěru. Kdyby se ale autoři třeba dvou tří init systémů dohodli na společném standardu třeba pro tu socket activation nebo pro informování o dostupných zdrojích, tak si myslím, že by to bylo přijato mnohem lépe, než systemd. Totéž třeba formát deklarativních konfiguráků popisujících služby – klidně by se dalo vyjít z toho, co má systemd, jen by se to muselo dobře popsat a stabilizovat – a pak by se klidně tyhle konfiguráky mohly načítat i v jiných init systémech nebo by mohly existovat nástroje na konverzi do jiných formátů.

Skoro si myslím, že by bylo jednodušší napsat nový OS na základě tvých myšlenek a naimplementovat všechno znovu podle tvého konceptu.

Tak to samozřejmě někdy je – spolupráce s jinými lidmi má nezanedbatelnou režii a někdy je lepší si vše udělat sám. Na druhou stranu, že bych napsal vlastní operační systém, považuji za celkem nereálné – tolik času se mi do toho investovat nechce a nevidím v tom takový smysl. Ale napsat vlastní init systém pro POSIXové OS, to už reálné je – byť i to je velký objem práce.

Jo já vím, tobě chybí API, mě u systemd chybí nějaký popis co to vlastně chce být a kam to chce směřovat…

Souhlas, tohle je taky důležité.

což je pro systémového inženýra dost důležité

Já si myslím, že z pragmatického pohledu člověka v téhle roli je to jednodušší – vybíráš si distribuci jako celek (a tam je mnohem víc kritérií než jen init systém), a když už si ji vybereš, tak pracuješ s tím, co máš, a držíš se doporučených postupů. Nemluvě o případech, kdy za tebe tu distribuci vybral někdo jiný – tam už vůbec není, co řešit.

Prostě dost pochybuju o tom, někdo bude implementovat nějaké api, které je pro něj zbytečné, stejně jako dneska je pro něj zbytečné dělat řádné balíčky.

Tak ho nebude implementovat, jeho škoda. Ten init systém může fungovat i bez toho a jen spouštět procesy, které ani neví, že běží pod nějakým initem. Ale pak takový program může zaostávat za ostatními, které to API používají a díky němu nabízejí nějakou funkcionalitu navíc. Opět je to jako s tím D-Busem – implementovat ho nemusíš, ale když to uděláš (třeba tam přidáš D-Bus modul), tak tím získáš u uživatelů nějaké body navíc a třeba si díky tomu vyberou raději tvůj program než jiný.

Nebo ještě starší příklad – když půjde nějaký síťový prvek monitorovat přes SNMP, tak bude oblíbenější, než prvky, které nejdou monitorovat vůbec nebo které používají nějakou proprietární technologii, nebo které lze monitorovat jen přes nějaké hnusné webové GUI napsané ve Flashi.

Což je právě to, co na dnešní úrovni umožňuje systemd docela dobře. Lepší lepidlo pro horší služby.

S tím souhlasím, systemd představuje určitý pokrok oproti starším initům (alespoň z toho uživatelského hlediska a pokud se zrovna při upgradu něco nerozbilo). Však taky se mi systemd po funkční stránce v lecčems líbí. Ale nelíbí se mi ta architektura a způsob vedení vývoje.

Proto mne mrzí, že jiné init systémy trochu zaspaly a nedotáhli včas náskok systemd. Jak jsem psal do gnu-system-discuss:

It would be a great „selling point“ if we can say: „we can provide same useful features as systemd but with just a fraction of its complexity and in a modular way (so you install only features, you need)“.

Nevím, jestli to jde ještě napravit, ale kdyby se s tím začalo včas, tak by to vytvořilo tlak na autory systemd, aby se nechovali tak samolibě a byli ochotnější k dohodě na nějakém společném standardu.

Mělo. A funguje?

Nějaký „konkurenční boj“ se tu vyskytuje taky – ať už je důvodem ješitnost a touha po slávě, nebo třeba snaha získat sponzory. Nicméně si myslím, že i tak ta spolupráce funguje lépe, a že pokud se lidi neshodnou na společném standardu, není za tím tak často zlý úmysl nebo snaha potopit konkurenci, jako spíš fakt, že ty lidi baví spíš programování, než psaní specifikací, a že se jim nechce předělávat to, co už mají hotové a k čemu mají osobní vztah.

pro systemd bylo asi jednodušší si ty věci implementovat znovu, než řešit API a roky čekat na to, až to napíše někdo jinej

Standard můžeš vytvořit i sám a nemusíš na nikoho čekat a s nikým se domlouvat. Ano, riskuješ, že na něco zapomeneš, nezohledníš potřeby a scénáře, které tě nenapadly atd. Ale pořád je to lepší než nic – pořád je tam šance, že to ostatní přijmou a začnou používat. Jde vlastně jen o to, abys to vhodně pojmenoval, dobře zdokumentoval a zavázal se k tomu, že to budeš rozvíjet zpětně kompatibilním způsobem a ideálně sémanticky verzovat, aby ostatní už z čísla verze viděli, co od toho můžou čekat.

Výše jsi psal: „mě u systemd chybí nějaký popis … kam to chce směřovat“ – a to je vlastně ono. Klidně by se to dalo pojmout stylem: Teď děláme na verzi 0.* a nejsme schopni zaručit zpětnou kompatibilitu, ale máme hrubou představu, že tehdy a tehdy se dopracujeme k 1.0 a od té doby budeme zpětnou kompatibilitu držet a budeme to mít dobře zdokumentované a části té dokumentace budou otevřené standardy, které může implementovat i někdo další. Jenže systemd je teď ve verzi 243 a stále vlastně nikdo neví, co se od toho dá do budoucna čekat.

No to jsem nerozporoval, jen jsem psal, že tento čistě binární stav některých služeb nebo jejich podčástí přijde IMO dřív, než koncept založený na definici a dostupnosti zdrojů. Protože naimplementovat službu, která se ukončí, když něco nemá, je o mnoho snadnější než službu, která implementuje jakési API a posílá komplenxní zprávy.

Jednodušší to je, ale ne o moc. Jestli v nějakém IFu vyhodíš výjimku, zavoláš exit(1) nebo zavoláš jinou funkci, která někam pošle zprávu, je už celkem jedno.

implementuje jakési API a posílá komplenxní zprávy

Nemám to ještě úplně promyšlené, ale ten zdroj by měl být identifikovaný prostým textovým řetězcem, nejspíš URI (tzn. byl by to globálně unikátní identifikátor). A ty zprávy by vlastně obsahovaly jen tento řetězec a typ události (zdroj se objevil, zdroj zmizel). A opačným směrem (z initu k aplikaci) by chodily podobné notifikace.

Dnes běžně používané technologie (D-Bus, SNMP, JMX atd.) jsou výrazně komplexnější. Jedna z možností je implementovat to nad některou z nich nebo použít třeba podmnožinu jejího kódování – pak by stačilo specifikovat sémantiku zpráv a daly by se použít existující knihovny (které jsou tedy ale kanón na vrabce, takže tady je otázka, jestli použít něco většího a hotového, nebo raději menšího a nového).

To mi trochu připomíná ten vtip (zkrátím): "ok, takže teď máme N+1 standardů"

Tak je to vždycky :-)

Ale vážně, tady jde spíš o to, jestli bych si na to našel čas a dal tomu prioritu… jinak si ale myslím, že by to úspěch mít mohlo, protože reálný užitek to přináší a averze spousty lidí k systemd je dost velká.

[alternativni_prudic]

Nemam cas to tady vsechno procist, ale ja uz nejakou dobu jedu na Alpine z flašky s přimontovanou zakriptěnou home partišnou taky z flašky.Na základní věci celkem dostačující minimalistický a přehledný operační systém. Větší instalace jako texlive instaluji mimo apk do /opt adresáře. Jako bonus jsem tím získal dobrou průpravu pro Docker a embeded.Čus!

[alium]

můžeš přejít na artix linux, což je archlinux s openrc (systemd nahrazuje openrc + eudev). Výhoda je, že se nemusíš "učit" nic nového a používat stále oblíbený PKGBUILD

artixlinux.org

používám artix (KDE) několik měsíců bez problému

[Blaazen]

Ano, a aby se to nepletlo, tak existuje i Antix, ten je taky bez systemd, ale je postaven na Debianu.

[figliar0]

Takže predsa niekto, kto to používa, ochotný podeliť sa o skúsenosť!

Aká je komunita? Nenarazil si na nejaké problémy? Vyzerajú trocha ako Star Wars a anti-systemd fanatici - nie sú tak trocha blázni? Niežeby to vadilo, len aby to neovplyvnilo ich úsudok do budúcna. Predsa len - Artix ako taký tu dlho nie je.

Robil si čistú inštaláciu alebo si prechádzal z Archu? Prebehlo všetko čisto? Neboli nejaké problémy?

Ak správne chápem, majú úplne samostatné repo. Synchronizujú to nejak s Archlinuxom alebo idú kompletne svojou cestou?