Dokonalé není to, kam nelze nic přidat,

… ale to, odkud nelze nic odebrat. (Antoine de Saint-Exupéry)

O systemd toho bylo za poslední roky napsáno mnoho, jak po technické stránce, tak po emocionální. Původně jsem chtěl popsat jednotlivé technické důvody, proč si myslím, že systemd je špatná cesta, ale nemá smysl psát to, co mnohokrát a lépe napsali jiní. Dneska chci psát o důvodech principiálních, nebo chcete-li filozofických.

Unix

Unix je postaven na několika málo jednoduchých principech. Jednoduchých na napsání, ale velmi, velmi složitých na pochopení. Některé věci se musejí zažít. Odtud také citát:

Unix je velmi přátelský, ale své přátele si vybírá.

Jedním ze zásadních principů je princip minimalizace. Dělej jednu věc a dělej ji pořádně. Tento princip nepřišel s Unixem. Tento princip používá věda v mnoha různých podobách. Occamova břitva například.

Pokud má jistý jev více vysvětlení, to správné bude právě to nejjednodušší.

Chemie

Určitá vědecká odvětví se s tímto pasují různě. Chemie, například, se smířila s existencí 118 prvků (z toho reálně použitelných něco kolem 90). S tím pracuje. Samozřejmě, chemie zkoumá vlastnosti oněch prvků, hledá zákonitosti v elektronových obalech a řadí je do skupin. Odtud má periodická tabulka prvků svůj nezaměnitelný tvar. Ale chemie se nesnaží (a z principu věci ani příliš nemůže), o minimalizaci počtu prvků (chemie je prostě založená na různorodosti elektronových obalů a té lze dostáhnout pouze různým atomovým číslem).

Fyzika

Fyzika (na rozdíl od chemie) naopak využívá principu minimalismu. Někdy až ad absurdum. Fyzikové se s větším než malým počtem (čehokoliv) nikdy nesmíří. Kupříkladu částicová fyzika. V knížkách ještě z 80 let dvacátého století (je skutečně poučné si i dnes přečíst například Weinbergovy První tři minuty — když tak půjčím — svět z pohledu fyziky tehdy před 37 lety vypadal diametrálně odlišně od dnešního) nalezeme tabulky se stovkami elementárních částic. Situace vypadala katastrofálně, zatímco chemie pracovala s 90 prvky, fyzika měla stále rostoucí seznamy nových a nových elementárních částic. Jenže se s tím nesmířila. Zjistilo se, že ony částice nejsou elementární, že každá z nich se sestává z jisté kombinace pouhých dvou částic. Princip minimalizace ve své nejlepší formě. Usilovnou prací se přišlo na ucelenou množinu elementárních částic, kterým říkáme standardní model. Je jich, částic hmoty, fermionů, 12. Z toho nám známá hmota potřebuje pouze 3 (u, d, e)). Plus příslušné intermediální bosony. Z pouhých 3 částic lze postavit kompletně cokoliv, co běžně vidíme kolem sebe (no dobře no, aby fungovalo Slunce a jaderné elektrárny, tak si tam připište ještě elektronové neutrino). Takže 4.

Superstruny

A fyzikům ani tohle nestačí. Jednak se ví, že standardní model nepostihuje všechno (když nic jiného, tak tam chybí gravitace), ale hlavně, vědcům i těch 12 částic + 5 bosonů přijde jako příliš mnoho. Hledá se řešení, které by obsahovalo pouze jeden stavební prvek.

Elektronika

Že je to nesmysl? Není. Veškerou digitální elektroniku na světě můžeme postavit pouze pomocí jednoho hradla. NAND (nebo i NOR, používá se ale NAND). Toť vše. Pomocí vhodné kombinace NANDů postavíte jakýkoliv kombinační obvod, pomocí vhodné kombinace kombinačních obvodů postavíte jakýkoliv sekvenční obvod. A z toho potom postavíte jakýkoliv procesor, jakoukoliv paměť, zkrátka vše, co se dneska používá. Stačí k tomu jeden základní stavební kámen a dvě úrovně signálu. Princip minimalismu na svém maximu :-D.

systemd

Jak celé tohle blábolení souvisí s Unixem, Linuxem a systemd? Unix celkem dobře ctí princip minimalismu. Základních stavebních prvků je skutečně málo. Asi by jich mohlo být ještě méně, o to se snaží jisté, dejme tomu experimentální, systémy. Každopádně, když už nějaké prvky v systému jsou, je snaha je využít do maxima. Kupříkladu příkaz ls (výpis obsahu adresáře). Mohu ho použít na výpis obsahu adresáře, ale když jsem chytrý a navrhnu si správně adresářovou strukturu, mohu tím současně získat například seznam úkolů, seznam projektů, seznam kontaktů, nebo například seznam služeb, které se mají startovat po zapnutí počítače. Nemusím psát 5 různých nástrojů, stačí mi jeden (a případě si nastavit 4 aliasy). Kdykoliv je tento jeden nástroj vylepšen, současně se vylepší i jeho 4 další použití.

SysV Init

Klasický SysV init a rc skripty jsou psány v bashi. Bash každý admin zná. Obsahují několik základních příkazů. Grep, awk, sed, možná ani to ne, typicky ale jen vytvoření souboru (přesměrováním), spuštění nějaké binárky. Není to nic složitého. Grep, například, každý admin zná. Nepoužívá se jen v rc skriptech. Dá se použít na hromadě dalších místech.

Vidíte tu podobnost? V reálném světě mi stačí 4 částice a udělám (kdybych měl tu moc) cokoliv. V digitronice mi stačí dokonce jedna součástka. V linuxu mi stačí pár základních příkazů (nevím, 10, 15, víc ne) a udělám cokoliv. Pokud z těchto základních příkazů postavím mimo jiné init a rc systém, tak admin, který s nimi denně pracuje, si hravě poradí i se změnou nějakého rc skriptu. Rozhodně to neuvidí poprvé v životě.

Stejně tak například less. Less mohu použít na stránkování dlouhého výstupu nějakého příkazu, stejně dobře jej mohu použít i pro čtení logů. Jeden nástroj. Pokud se jej naučím efektivně používat, současně si zlepším mnoho různých činností.

Efektivita

Pokud ale místo toho někdo zavede jiný systém, který bude mít pouze jedno použití, tak se to lidé nikdy nenaučí efektivně používat. Zatímco s příkazy less, grep, find, xargs apod. pracuji takřka denně, tak například do logů chodím 3x do roka. Ono to nevadí, protože na ty logy použiju less, který dobře znám a nezapomenu jej. Pokud ale na přístup k logům potřebuju speciální příkaz (například systemd journalctl), tak se jej pokaždé budu učit znovu. To nikdy nebude efektivní. Pouze efektní. Totéž platí pro systemctl enable apod. Příkaz ln -s používám přece jen častěji a jedním z použití u původního rc.d bylo ln -s init.d/neco rc2.d/neco. Opět, stejně jako u ls, less, tak i tady jeden příkaz na vytváření symlinků může současně sloužit i jako příkaz pro aktivaci služeb při bootu. Dále, co je špatné na obyčejném spuštění /etc/init.d/něco a proč místo obyčejného spuštění programu (což dělám mnohosetkrát za den, takže ani v případě potřeby spustit službu mě to jaksi nezaskočí) bych měl použít systemctl start?

Co dál

Ale jak jsem psal na počátku, nechci zacházet do přílišných technických detailů, o tom to fakt není. Je to o celkovém principu nebo filozofii práce se systémem. Unix vždy stavěl na svých principech a to mu vždy dobře fungovalo. Pokud to někomu nevoní, prosím, existují (už desítky let) jiné operační systémy se zcela jiným přístupem. Kdo chce, může je použít. Nějak mi ale nedochází, proč ti, kterým unixový přístup nevoní se jej snaží změnit způsobem, jakým to dělají (rozuměj: ne moc fajn), a proč místo toho nepoužijí již existující systémy. Měli by to bez práce a bez emocí.

Příspěvek byl publikován v rubrice Linux, Názory, Počítače, UNIX. Můžete si uložit jeho odkaz mezi své oblíbené záložky.

29 komentářů: Dokonalé není to, kam nelze nic přidat,

  1. davkol napsal:

    GNU/Linux: GNU’s not Unix

  2. Michal Hrusecky napsal:

    No ne ze by se mi systemd a pristup lidi kolem nej libil, ale zrovna
    systemctl enable sshd
    je ve skutecnosti jen „alias“ za
    ln -s /usr/lib/systemd/system/sshd.service /etc/systemd/system/runlevel5.target.wants
    Systemd ma nektere fajn veci (xinet nejen na porty ale i d-bus a sockety, watchdog na servicey, zavirani veci do cgroup, logind vypada ze by narozdil od consolekitu moh mit teoreticky i smysl, …) ale souhlasim, ze spousta toho nepatri do init.

  3. lzap napsal:

    Linux nikdy nebyl UNIX, je to UNIX-like systém s rozdíly od první verze (0.0.1) až dodneška. Asi se bavíme o celém balíku GNU, což je stejný případ. Systemd začal jako init-1 proces a další věci se začaly nabalovat, jak více a více lidí začali do projektu přispívat. Obecně se s Tvým článkem dá jen souhlasit, ovšem zrovna například journad, networkd nebo logind dávají velký smysl mít k dispozici v early bootu. Má to praktické výhody. Upřímně nevidím nic, co by v systemd být nemělo. Nic taky nezmiňuješ ve článku, z předchozích reakcí asi tuším třeba journad, což vidím ovšem jako velkou výhodu.

    Sysv init skripty možná stačily před třiceti lety, dneska se IT svět mění. Operační systémy nejsou tak statické, jako byly. Firmy spouštějí miliony virtuálních strojů a kontejnerů denně (resp. každou minutu). Nemyslím si, že zrovna sysv init skripty jsou to, co by z UNIXu mělo zůstat navždy. Příklad z praxe – init skript postgresu na RHELu6: http://pkgs.fedoraproject.org/cgit/postgresql.git/tree/postgresql.init?h=f15#n124 (na tom řádku je fatální chyba vycházející z toho že skripty se programují místo toho aby se nadeklarovaly).

    Spoustu věcí v systemd je vlastně velmi UNIX-like. Samotný balík je soustavou malých programů, které spolupracují. Například integrace s journald (služba automaticky loguje do žurnálu bez zásahu do aplikace, možnost explicitního použití systemd-cat), pokud bych měl jmenovat jednu jedinou věc.

    O historii systemd vyšel právě zajímavý rozhovor s LP: https://www.youtube.com/watch?v=Rm68XYskgH8

    • Heron napsal:

      Upřímně nevidím nic, co by v systemd být nemělo. Nic taky nezmiňuješ ve článku

      Například systemd-backlightd. Nevidím souvislost mezi initem (nebo initem a rc) a regulací podsvícení. Nebo například integrovaný dhcp server. Na co má init dhcp server?

      V tomto vidím do budoucna problém. Nabalování zcela nesouvisejících částí a propojování do jednoho celku. Na tohle dojel jistý jiný OS, který s sebou táhne obrovský balík všeho (pro uživatele reálně ničeho), když se něco pokazí má to zcela neočekávaný vliv na jiném místě a x desítek GB na disku (I když tohle se údajně ve verzích 8 a 8.1 podařilo zredukovat, nevím, nikdy jsem je neviděl.).

      Samotný balík je soustavou malých programů, které spolupracují.

      Souhlasím. Jenže tohle neznamená (alespoň v mém pohledu) unixovost. Kdyby se mi například líbil journald, mohu jej použít i bez systemd? No nemohl. Kdyby se mi líbil systemd, ale nenáviděl bych journald, můžu místo toho použít třeba rsyslog? Nemohl. Zatímco v tradičním pojetí si můžu vzít libovolnou komponentu a tu požít samostatně, případně z jiného balíku (pokud se mi nelíbí implementace z dílny GNU, mohu použít třeba implementaci z busyboxu, nelíbí se mi open-ssh, je tu dropbear). Tohle v systemd nefunguje, žádnou část nemůžu použít samostatně, nebo ji nahradit jinou implementací. Myslím, že oprávněně vzniká dojem molochovitosti.

      Kdyby byl systemd jen náhrada initu a rc, tak by kolem toho nebyly takové emoce.

      O historii systemd vyšel právě zajímavý rozhovor s LP: https://www.youtube.com/watch?v=Rm68XYskgH8

      Mrknu, díky za námět.

      • lzap napsal:

        DHCP je potřeba při early bootu (dracut), je to velmi výhodné pakliže máš root na iSCSI, SANu nebo to mountuješ přes NFS. Příliš nechápu co myslíš tim backlightem, je to jen servisa, která volá binárku pro načtení/uložení podsvícení. Pokud vím, není to daemon.

        Samozřejmě že velký monolitický balík je něco, co nikdo nechce. Systemd se mi jeví jako dostatečně modulární. Byly diskuse ve fedora listu ho rozbít na víc balíků, ale Lennart to prozatím uargumentoval.

        Jourald je opravdu hodně specifický případ a vývojáři se jeho hlubokou integrací se systemd snaží řešit jednu důležitou věc – při early bootu nebyly zprávy logované do syslogu, až když byl spuštený. Díky journald pokud máš nastaveno například logování po síti by měly logy z kernel crashes přijít (pokud tedy dojde k pádu až po načtení síťové karty a inicializace sítě – přes networkd :-)

        Nahradit systemd určitě půjde, jako všechno. Že to bude více práce? Na to si prosím nestěžuj. Nikdo přece neříkal, že všechno půjde snadno. Ono ruku na srdce – jen vyměnit sysvinit byla šílenost, která trvala 3 roky (ve Fedoře) a stále chybí snad jedno procento služeb.

        Ten rozhovor doporučuju, díky tomu že na LP moderátor neútočí, má možnost vysvětlit některá rozhodnutí a popsat trochu historii projektu, o které se hodně spekuluje (hodně lidí si myslí že Red Hat řekl „udělej náhradu za upstart“).

        U mě stále převažují výhody nad nevýhodami. Zejména když vidím, kam se IT ubírá (VM, kontejnery, configuration management, fast-paced provisioning). A chápu, že je to velká změna, která se týká všech. Jsou věci, které mi taky lezou na nervy (httpd start vs start httpd). Taky proto jsem rozjel: https://github.com/lzap/systemd-shortcuts (zatím to jen testuju)

        • Heron napsal:

          DHCP je potřeba při early bootu (dracut), je to velmi výhodné pakliže máš root na iSCSI, SANu nebo to mountuješ přes NFS.

          Klient ano, já mluvil o dhcp serveru.

          Taky proto jsem rozjel: https://github.com/lzap/systemd-shortcuts (zatím to jen testuju)

          Všiml jsem si (na G+). Mě pořadí parametrů celkem vyhovuje (resp. to že je jiné mi nedělá problém), i když tam, kde to jde, mám rád volné pořadí dle kontextu jako například u příkazů z iproute2.

          • lzap napsal:

            Jo server :-) No to už je samozřejmě specialitka která se bude používat pro kontejnery. Zajímavý koncept, normálně to bude vypnuté pochopitelně. Server samotný je aktivován socketově, tzn. spustí se opravdu jen tehdy, když bootuje nový kontejner a potřebuje IP adresu.

            • Heron napsal:

              Schválně co se stane, když se ten dhcp server spustí na všech uzlech sítě ;-) Například po nějakém nepovedeném update.

              Právě v tomto vidím nebezpečí molochovitosti. DHCP server je za určitých okolností dobrá věc. Pokud si to někdo nainstaluje právě pro danou okolnost, je to super.

              Ale jak jsi sám řekl, LP se nemá k tomu to rozdělit do balíčků. Takže všude tam, kde je systemd, je i dhcp server. Může být aktivován jakkoliv. Přímo přes systemctl, nebo přes dbus. Potom nastane v dané síti hrozná sranda.

              • lzap napsal:

                No tak to už je teorie, co se stane když uděláš „kill -9 1“. To prostě nesmí nastat, tak vážných chyb není zas tolik.

                Diskuse o balíčkování se týkala Fedory, ale například v Debianu se o to starají jiní lidé. Pokud se rozhodnou rozbít to do podbalíčků, jejich věc. Je to víc práce, to jo. Jak říkám, ve Fedoře je systemd zatím ve dvou balíčcích.

        • lzap napsal:

          Ad tři roky – myslel jsem tři Fedory, což je 1,5 roku :-)

      • Filip Jirsák napsal:

        Nebo například integrovaný dhcp server. Na co má init dhcp server?

        Opravdu má systemd init integrovaný DHCP server? Nebo je to jen jedna z volitelných komponent?
        Jinak podle mne má ten DHCP server stejný význam, jako DHCP server v DNS resolver serveru (dnsmasq), nebo DNS, FTP a HTTP server v shellu (BudyBox) – občas se tímhle způsobem na méně výkonných zařízeních šetří místo a výkon.
        Myslím, že nic nebrání tomu použít se systemd libovolný jiný ovladač podsvícení nebo libovolný jiný DHCP server. A stejně tak nic nebrání používat systemd-backlight nebo systemd-dhcpd s jiným initem, který poskytuje potřebné služby.

        Tohle v systemd nefunguje, žádnou část nemůžu použít samostatně, nebo ji nahradit jinou implementací.

        Jak jsi na tohle přišel?

        Kdyby byl systemd jen náhrada initu a rc, tak by kolem toho nebyly takové emoce.

        To ale není problém systemd, ale těch lidí, kteří si bůhvíproč myslí, že součástí systemd initu je všechno, co začíná na systemd.

        • Heron napsal:

          Opravdu má systemd init integrovaný DHCP server? Nebo je to jen jedna z volitelných komponent?

          libsystemd-network

          http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd-network/sd-dhcp-server.c

          This file is part of systemd.

          To ale není problém systemd, ale těch lidí, kteří si bůhvíproč myslí, že součástí systemd initu je všechno, co začíná na systemd.

          Součástí initu to není, ale je to součástí stejného balíku jako ten init. (Chápu, že majitelé source based dister si to mohou zkompilovat bez toho, ale většina dister je z binárních balíčků a tam je to v jednom. Jak psal Lukáš, LP na tom zatím nic měnit nehodlá.)

          • Filip Jirsák napsal:

            většina dister je z binárních balíčků a tam je to v jednom

            To je ale věc těch distribucí. Je zvláštní, že jsme se od údajně chybné architektury systemd postupně dostali k tomu, že je to vlastně problém toho, jak je v některých distribucích zabalený. Chápu, že to pro někoho je problém a důvod, proč on nechce na svých počítačích používat systemd, ale nepřipadá mi to jako něco, co by diskvalifikovalo systemd jako takový.

            • Heron napsal:

              od údajně chybné architektury systemd

              Nikdy jsem neřekl, že systemd je chybná architektura. Jasně jsem napsal, že je to můj názor (a napsal jsem také, jak bych si to představoval po svém) a také jsem napsal, že init může být napsán mnoha způsoby a sysv je jen jedním z nich. Prosím tedy o nepodsouvání něčeho, co jsem nikdy neřekl.

              vlastně problém toho, jak je v některých distribucích zabalený

              Není. Kromě věcí, které půjdou řešit balíčkováním, jsou tu věci, se kterými nehneš. Závislost na cgroups, závislost na dbus (a vůbec celý nápad ho strčit pro jistotu do kernelu) neodpáratelnost věcí jako journald apod.

              • Filip Jirsák napsal:

                Je přirozené, že využívání něčeho vytváří závislost. SysVinit+RC je zase závislé na shellu a utilitách. Nevýhoda může být obojí, ať cgroups a dbus, nebo shell a utility.

  4. Filip Jirsák napsal:

    Podle mne „dělej jednu věc, ale dělej jí pořádně“ není kritérium, podle kterého by se dal spor systemd vs. SysVInit a RC skripy rozhodnout. Protože výsledek záleží jenom na tom, jak si nadefinuju jednu věc, jak pořádně, a jak to, co vlastně porovnávám.
    Vždyť systemd také není jednolitý moloch, jediný BLOB, který by měl spoustu funkcí. Naopak, je to také spousta jednoúčelových utilit, které mohu použít, když chci, ale také nemusím. systemd-backlightd nepatří do initu? Nepatří. A stejně tak tam nepatří grep. Existují konfigurace, kde init používá grep, a konfigurace, kde init používá systemd-backlightd. Proč bych měl tvrdit, že grep není součástí initu, ale systemd-backlightd je? Pro to systemd v názvu utility?

    • Heron napsal:

      Asi jsem se měl vyjádřit jasněji a explicitněji. Pokusím se o to tady :-)

      Grep není součást initu. Grep je program, který umožňuje filtraci stdin dle jistých pravidel a výstup do stdout. (Případě umí pracovat i se soubory, to teď není podstatné, co dělá grep všichni víme.)

      Grep lze použít na hromadu věcí, na filtraci výstupů jiných programů spojených rourou, filtraci položek v souboru, soubor může být log apod. Grep má hromadu využití všude tam, kde chceme omezit počet záznamů dle nějakého kritéria.

      Jedním z těch využití může být i to, že pomocí grepu a několika málo podobně jednoduchých programů, mohu vytvořit větší celek. Například init a rc systém.

      Jenže to neznamená, že init je závislý na jednom konkrétním grepu. Grep mohu použít buď z původního unixu, nebo z GNU, nebo si napsat vlastní (například v Perlu by to nemuselo být až tak těžké).

      Každopádně, admin grep využívá; ehm to by mě vlastně zajímalo, jak často ho využíváte vy ostatní, ale já opravdu skoro denně. Proto, když otevřu nějaký sh skript (klidně rc) a uvidím tam použití grepu, nebude to moje první setkání s tímto nástrojem.

      Už si rozumíme? :-)

      Podle mne „dělej jednu věc, ale dělej jí pořádně“ není kritérium, podle kterého by se dal spor systemd vs. SysVInit a RC skripy rozhodnout.

      Souhlasím že není, proto se článek jmenuje „dokonalé není to, kam nelze nic přidat, ale to, odkud nelze nic odebrat“.

      Zcela nepochybně můžeme napsat init + rc pomocí nějakých dalších nástrojů. Zcela nepochybně můžeme napsat init + rc i jako monolit. Proč ne.

      Ale z toho množství variant mě osobně připadá nejlepší ta varianta, která používá již existující nástroje a pokud možno nepřidává žádný další.

      Tohle kritérium podle mě init a rc skripty zvládají na jedničku. Využívají pouze existující nástroje (bash, grep, find, awk atd. — chtěl jsem udělat výtah co se vlastně používá v rc skriptech Debianu, ale z časových důvodů jsem to vzdal) a přidává k němu pouze minimální init, který přímo volá kernel na konci bootu pro vytvoření PID 1.

      A přesně tohle kritérium systemd narušuje. Systemd zavádí další binárky, zavádí nový init (jiný od již existujícího), zavádí další démony (když nic jiného, tak dbus, journald).

      A tyto věci nelze využít nijak jinak. V tom je zde podstatný rozdíl od věcí jako grep, find, xargs, ty totiž neexistují jen pro init + rc, alespoň já na nich mám postavenou hromadu dalších věcí. Systemd nutně navyšuje počet prvků ve Vesmíru :-). Původní init + rc v bash ne.

      Chápeme se?

      • Filip Jirsák napsal:

        Pokud grep není součástí initu, pak ani systemd-backlightd není jeho součástí, ne? Já myslím, že ty „další binárky“ nejsou součástí systemd jako initu, stejně jako není grep součástí SysVinitu+RC. Když budu chtít, použiju ze systemd jenom init.
        Pokud někdo zvládne napsat moderní init s použitím existujících nástrojů, ať to udělá. ale SyVinit+RC pro mne moderní init není. Už jenom z toho pojmenování je vidět, že to s tím jedním initem není tak slavné. Ony jsou to ve skutečnosti inity dva, jeden opravdový init s PID 1, který nastartuje pár služeb, a na závěr spustí init č. 2, což jsou různé RC skripty, které pak spouští zbývající služby. Každý z těch initů se ovládá jinak, každý umí něco jiného. To je pro mne třeba známka toho, že v init+RC je cosi shnilého. A jsem rád, že systemd je skutečně jeden init a jeden správce služeb, že mi pro inicializaci systému stačí opravdu jeden program (systemd samozřejmě není jedinou takovou náhradou init+rc).
        To, že dbus nebo journald nelze použít jinak, podle mne není pravda (myslím, že třeba při použití patřičného protokolu může do journald logovat kdokoli). Ale hlavně to pro mne není podstatné kritérium. Navíc „lze použít jinak“ je podle mne v příkrém rozporu s „dělej jednu věc“ :-)
        Já za klíčovou přednost náhrad SysVinitu považuju to, že umožňují jimi spravovaným službám fungovat na principu „dělej jednu věc, ale dělej ji pořádně“. Třeba takový Apache díky nim může být jen webovým serverem, a nemusí navíc řešit řízení procesů (double-forking, aby se z něj stal daemon) ani správu služeb (apachectl).

        • Heron napsal:

          Ony jsou to ve skutečnosti inity dva, jeden opravdový init s PID 1, který nastartuje pár služeb, a na závěr spustí init č. 2, což jsou různé RC skripty, které pak spouští zbývající služby.

          Což mi přijde v pořádku vzhledem k tomu, jaké nároky jsou na PID 1 kladeny a co se stane, když PID 1 selže.

          Program s pid 1 by měl být co možná nejjednodušší, aby se předešlo chybám.

          Navíc „lze použít jinak“ je podle mne v příkrém rozporu s „dělej jednu věc“ :-)

          Proč? Lopatou taky můžu přehazovat písek, hlínu, cement, nebo prachy (i když ty raději vidlema :-) ) Jeden nástroj, hromada použití a přitom dělá pořád jednu věc.

          • lzap napsal:

            Nebudu se vám chlapci do toho míchat, snad jen že systemd-backlightd neexistuje, je to systemd-backlight a jedná se pouze o „oneshot“ službu. Pro neznalé – zkrátka něco, co se spustí při bootu/probuzení/uspání/vypnutí. Nejedná se o daemon, ale je to napsané v C (pochopitelně autoři systemd nebudou pro takovou trivialitu jako je šáhnutí do kernelu spawnovat /bin/bash :-)

            • Heron napsal:

              systemd-backlightd neexistuje, je to systemd-backlight a jedná se pouze o „oneshot“ službu

              Ok, moje chyba. Jen nechápu, proč to mám na serveru nebo ve virtuálce. Ani jeden z nich nemá co podsvěcovat.

              • Filip Jirsák napsal:

                Pravděpodobně proto, že to tam dotáhl nějaký balíček jako povinnou závislost. To ale není chyba systemd, nýbrž toho, kdo to tak zabalil. Mně se kdysi také na server s instalací vimu málem skrzevá gvim propašovalo celé Gnome – ale nevyvozuju z toho, že je to principiální problém vimu.

                • lzap napsal:

                  Balíčkování a psaní softwaru jsou dvě věci. Někdy to dělají stejní lidé, častěji jiní. Samozřejmě že v ideálním případě by to bylo všechno v podbalíčcích. Ale jak jsem psal výše – systemd ve Fedoře je zatím jeden (resp. dva) balíky. To se může změnit, je to jen otázka úsilí.

                  Ad vim – prozradím malé tajemství. Celý X Window se do Vimu tahá kvůli jedné věci – podpora X clipboardu. Je tam závislost opravdu ve vimu (nikoli gvimu!). Vim totiž umí synchronizovat schránku s Xkama, což je super věc a používám to každý den. Bohužel RPM/YUM umí jen tvrdý závislosti, bylo už několik bugzill na to raději odstranit tu funkcionalitu, ale pro tyto účely existuje speciální build „vim-minimal“… :-)

          • Filip Jirsák napsal:

            Což mi přijde v pořádku vzhledem k tomu, jaké nároky jsou na PID 1 kladeny a co se stane, když PID 1 selže.

            Na tom se neshodneme. Tohle je podle mne přístup „mám ne zrovna dokonalý nástroj, tak snížím požadavky tak, aby jim nástroj vyhověl“. Taky by se dal přístup SysVinitu s jistou licencí popsat jako „moc tomu našemu programu nevěříme, tak ho raději necháme dělat jenom pár činností, na tom snad nic nezkazí“.
            A i kdyby bylo opravdu nepředstavitelně složité napsat správce služeb tak, aby bylo možné mu svěřit PID 1, pořád se to dá udělat tak, že služby bude spravovat jiný proces, a PID 1 se bude starat jen o tenhle proces spravující služby – ale pro uživatele to bude transparentní, bude se všemi službami pracovat stejným způsobem.

            Jeden nástroj, hromada použití a přitom dělá pořád jednu věc.

            Pokud si jednu věc nadefinuju tím správným způsobem. A pokud si ji nadefinuju jinak, dělá ten nástroj najednou spoustu věcí.

  5. Heron napsal:

    Zajisté nebude příznivcům systemd dělat problém vysvětlit, k čemu je dobré tam mít i databázi myší :-D

    http://lists.freedesktop.org/archives/systemd-devel/2014-December/026189.html

    • lzap napsal:

      Provázanost udevu a systemd má své výhody a ano, je to nějakých 6 MB navíc (celkem, ne jen ty myší). Jenže odstraněním udevu nic neřešíš, stejnak se bez něj neobejdeš. Pamatuji se dobře na ten marast co byl před udevem, tohle dobrovolně podstupují jen vývojáři a hackeři embedded zařízení. No spíš wearables, dneska už každý telefon má udev taky. Nějak nechápu, kam směřuješ…

      • Heron napsal:

        Směřuji k úloze udevu (což je taky součást systemd, ale ještě se o tom lze bavit samostatně).

        Proč by udev měl vědět DPI myši? Udev je tady od toho, aby detekoval hw (a třeba jeho přidání a odebrání), zavedl příslušné moduly, vytvoří příslušné uzly v /dev/. Na který krok z uvedených potřebuje znát DPI?

        Btw, mrknul jsem se na ten rozhovor a měl jsem co dělat, abych to během prvních asi 3 minut nevypnul. Protože nejenže zmínil PulseAudio, ale dokonce má v plánu jej přepsat na kdbus. Přehrával jsem si to 3x, protože jsem měl pocit, že špatně slyším.

        Abych předešel otázce „co je špatného na pulse audio“ tak odpovím rovnou že jen taková drobnost, že vůbec nefunguje.

        Tím nefunguje mám na mysli, že nefunguje s běžným HW, který je k disposici v každé základní desce. Podotýkám, že ALSA funguje.

        PA jede jen v jakémsi failsave režimu na 44.1 kHz / 16b. Neumí ani 192 kHz / 24b, což zvládá kdejaký realtek kodek za $1 (ALC xyz).

  6. Pingback: BTRFS v praxi po 5 letech | Heronovo

  7. Pingback: Ohlédnutí za rokem 2015 | Heronovo

Komentáře nejsou povoleny.