Ja popravde nechapu to saskovani proti systemd.
Systemd velice slusne a ucelene resi hromadu funktionality vcetne konfigurace cgroup slices, timeru services a hromady dalsiho.
Nic jineho rozsahem obdobneho neexistuje a placat to bash sktripty a crontabem muze jedine clovek,.co zamrzl v roce 98
Dnesni moderni linux roubovat SysV initem, to je jak montovat riditka z trojkolky na mercedes.
Tak se podivejte na OpenWRT a jeho odvozeniny... vc. treba TurrisOS :-) A podivejte se treba i na ruzna "profi" reseni typu QNAP ci treba ruzna zarizeni od Ubiquity. A muzeme pokracovat dalsimi priklady - a klidne treba u firem typu Cisco. Nekde a nekomu to smysl proste z nejakeho duvodu dava... no a? Je to prece kazdeho volba... a taky odpovednost.
"Systemd velice slusne a ucelene resi hromadu funktionality vcetne konfigurace cgroup slices, timeru services a hromady dalsiho."
A třeba s tímhle mám já docela problém. Ne takový, abych měnil distro, ale vadí mi to. Systemd míchá dohromady věci, které mají být nezávislé. Proč má být dohromady init systém, task scheduler, logovací daemon a spousta dalších chujovin? Nechť je tam API, ale ať jsou to nezávislé (a nahraditelné) projekty.
Kde je resolved? Já ho vůbec nemám nainstalovaný. V Debianu je to samostatný balíček.
Co se týče Journalu - všichni brblají jak je na prd (včetně mě), ale pořád nikdo nenapsal alternativu (API mezi systemd a journald jistě existuje), která by logovala per-unit do textových souborů a rotovala to jako za starých časů. Takže to asi nikomu zas až tak moc nevadí.
Jestli to nebude spis tvoji lenosti ... pouzivam treba metalog, a co kam se bude logovat si snadno nastavis, pokud to nejak logovat umi a umi se to nejak itentifikovat, tak to muzes libovolne rozdelit. Muzes snadno docilit i toho, ze budes mit jeden log kde bude "vsechno" a zaroven dalsi kde to bude rozdelene, coz se hodi kdyz hledas nejaky casovy souvisloste.
Jup a jsou to textovy soubory na ktery ti vi/cat/... staci.
Pekny, lec ja nyni, ve stoleti ančovičky, vidim vsade prosty journald, coz, pro debug tracing naprosto postacuje a umim si z nej udelat "oddelene logy" prepinacem --unit.
A kde je potreba delat s logama krapet vazneji, cpe se to do vzdaleneho OpenSearch, kde se daj ty data prosivat v ramci cele farmy kooperujicich serveru.
"Pekny, lec ja " ... o logovani nic nevim. To si chtel rict? Logy jsou totiz zajimavy predevsim v situaci, kdy neco crashne, a logovac systemd crashuje jako prvni.
A kupodivu a neprekvapive, kdyz crashne logger, tak se ani do vzdalenyho logovace nic nezapise ... ja vim, divny.
Ju vlastne, ja zapomel, systemd "resi" problemy tak, ze vsechno porad dokola restartuje.
Provokace:
Ve Windows je to všechno jeden projekt a nikdo si nestěžuje. Kromě pár aktivistů je to totiž uživatelům jedno, dokud to funguje. A ti aktivisti si budou stěžovat vždy, i když to funguje.
SysV init byl hromada osmdesátkového zmatečného bordelu. Nevím proč, ale musel jsem tvořit nějaké záhadné konfiguráky na kdovíco, aby alespoň něco fungovalo. Od příchodu systemd to dělat nemusím. Jako uživatel a zároveň správce vlastního serveru jsem spokojen.
No nikdo si nestěžuje do takové míry, že na serverech, pokud to není nutné, Widle nikdo nepoužívá.
Nic méně já jsem nepsal, že systemd je špatný init systém (a nevím, proč se pořád srovnává s SysV příšrností), já jsem psal, že do něj byly naházené věci, co tam prostě nepatří a kdyby Poettering mohl, tak jsme tu asi měli systemd-desktopd, systemd-coffeed, systemd-toiletd a nakonec i systemd-coffind.
Vzdyt je to spousta drobnych utilit presne v duchu unixove filozofie. V cem je systemd coby cisty init system spatny? Resi to zavislosti sluzeb na sobe, jejich izolaci / hardening, limity zdroju, monitoring vc. restartu pri padu sluzby... v zasade vse, co od moderniho initu realne potrebujete. Nic vam nenuti pouzivat vsechno ze zminovaneho souboru, mnohe z tech drobnych utlit jsou jen doplnky, bez kterych jde existovat.
A je hezke si brat do huby Poetteringa, ale ono to spis vychazi z pozadavku, ktere prichazi od enterprise zakazniku. Systemd neni rozhodne zadna one-man show, kde si kopnete do jednoho cloveka. Ta poptavka po poradnem init systemu tu byla, byly ruzne jine pokusy nahradit SysV a ty mely podstatne vic much. Bastly typu pocatek init scriptu je vlastne komentarova konfigurace pro zavislosti, kterou si neco "nejak" prezvejka nemluve. Casto zadratovane natvrdo v kodu... kdy samozrejme to udrzitelne zmenit byl pak problem - ten "patch" vam rozbil kazdy update baliku. Se systemd napisu jeden override file, se kterym se pocita a ve kterem muzu v pohode ty parametry distribucni unity upravovat...
Co je tak těžké pochopit na větě: "Nic méně já jsem nepsal, že systemd je špatný init systém, já jsem psal, že do něj byly naházené věci, co tam prostě nepatří."?
Já jsem nikdy neměl problém se systemd jako init systémem, ale má zůstat init systémem a ne celým userlandem (a to prostě tlačil Poettering). Chápete to, nebo to potřebujete nakreslit?
No vzhledem k tomu, ze jste si vyfabuloval neexistujici komponenty vlastne neni zrejme, co ze povazujete za chybnou soucast. A opet utocite na cloveka, ale ono tady se nebavime o nejake one-man show.
Takže to bude potřeba asi nakreslit. Jinak součástí systemd jsou: journald, libudev, localed, logind, hostnamed, homed, networkd, resolved, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd. A to s různou mírou zadrátovanosti (minimálně závislost na kterékoli komponentě znamená závislost na systemd a z něho závislosti na některých součástech, třeba journald je typický příklad), to jako považujete za čistý init systém, jo?
To jsou ale samostatne pouzitelne nastroje. Samostatne binarky, chcete-li si to namalovat. A ze ty binarky zavisi na nejake knihovne? No to uz tak milej pane chodi... kazda binarka ma svoje zavislosti. Samotny init na nich nezavisi, pouze jej funkcne obohacuji - ale jde fungovat i bez nich.
A zrovna journald je typicky prikad toho, jak pricetne delat logovani v 21. stoleti. Jiste, porad muzete mit marast oddelenych textaku, kde si pak nejaky chytrak usmysli, ze prida svuj vlastni - oddeleny, ale jaksi opomene jej rotovat... a vyrobi vam tikajici bombicku :-) Typicky hate pochazi od lidi, kteri journald vlastne neumi pouzivat...
Ano, chod NTP chcete logovat. Minimalne situace, kdy nefunguje jak ma. Co je na tom divneho? :-) Vy snad (ne)fungovani NTP nelogujete?
A samozrejme, ze logovani pres journalctl se pouziva lepe, nez ruzna "grep" alchymie nad po disku roztahanymi textaky. Uz jen takove malickosti journalctl jako --since, --until, --unit...
To je asi jako vysvětlovat opici teorii relativity. Vy prostě evidentně nic nespravujete a prostě nevíte. Víte, jak se v linuxu loguje? No, evidentně nevíte. `--since`, `--until` atd. to je fakt raketová věda. Co je proti tomu například různá retence logů dle aplikace? Výsledek journald je, že se stejně nepoužívá a přeposílá se to do souborů, nebo rovnou na nějaký stack , ale s journald nikdo přímo nepracuje a je to jen trpěná komponenta, která nejde oddělat.
Ono jsou tam i dalsi veci, jako treba integrita logu. Aneb jak u toho "tradicniho" syslogu zabezpecite, ze se v tom nahodou nekdo nepohrabal? ;-) Ono je tak tezky ten textak zmenit, a tim treba i skryt nejakou nezadouci aktivitu, ze? (jiste, to jde vyresit tim, ze log poslu i jinam - ale bavime se o lokalnim storage) Napriklad instantne komprimovany zapis logu je take praktictejsi, nez textakovy tradicni syslog - kde kdyz se neco necekane zblazni, tak ten diskovy prostor mizi pomerne rychle, ze? :-) Ale zda se, ze to jste pane "zkuseny" nikdy nezazil...
Ale vase tvrzeni, ze nikdo s tim nepracuje je proste blabol. Nepracuji s tim predevsim hateri systemd, kteri se proste odmitaji ucit neco noveho, protoze jsou prece dvacet let zvykli neco delat...
Pan zkušený ví, že na logy je oddělený volume a když se něco zblázní, tak tomu ani komprese nepomůže, jen to oddálí. A taky ví, že lokálně uložené logy se tailují a zpracovávají jinde (zejména pro security). A co se učení nových věcí týče, tak s tím problém absolutně nemám, ale když je něco k ničemu, tak tomu nic nepomůže. Krásný rozdíl je mezi servicema v systemd (dobré) a logováním v systemd (na prd).
Ne nebavime. Jakmile chcete integritu, autenticitu a podobne vlastnosti logu, typicky logujete ihned pryc. Casto neverite ani lokalnimu zdroji dns, ntp apod. Pouze chcete, aby jadro co nejrychleji a hlavne bez zbytecnych prostredniku, informace poslalo pryc. Lokalni zaznamy at uz s souborech, nebo v db pak slouzi maximalne jako honeypot.
Naopak pro bezne stroje napr. pro uzivatele, je podle mne log soubor diky sve jednoduchosti a beznym vlastnostem (napr. offline cteni) rozumnejsi volba.
> Napriklad instantne komprimovany zapis logu je take praktictejsi
Já jsem tady a na AbcL dělal benchmarky velikosti journalu vs. ekvivalentního syslogu (textového) za stejný čas, a journal z toho vždy vyšel mnohonásobně hůře - neuvěřitelně větší. A následně to další uživatelé reprodukovali - v jedné diskuzi dokonce i vy osobně. (příklad takové analýzy) Nerozumím tedy, proč to tu znovu píšete - nebo se s novou verzí systemd/journald něco změnilo a už to komprimuje? Výše uvedený test je na Debianu Trixie (v době psaní komentáře asi měsíc před vydáním), čili dosti nové verze.
Kdyz ono je to tezke - vam prijde jako "problem" ukladani metadat, ktere mj. umoznuji jednoznacnou identifikaci puvodce dane zpravy. A jinak pomoci konfiguracni volby Compress muzete i upravovat parametry/chovani te komprese, pokud se vam nelibi default, obcas to chce juknout do manualu... pripadne u starsich instalaci zrevidovat, jestli se tam z minulosti neprenesl nejaky artefakt, co stav spise zhorsuje.
> Kdyz ono je to tezke - vam prijde jako "problem" ukladani metadat
Ta metadata jsou ale podezřele velká, nebo jich je zbytečně mnoho, nebo jsou nevhodně uložena.
> A jinak pomoci konfiguracni volby Compress muzete i upravovat parametry/chovani te komprese, pokud se vam nelibi default, obcas to chce juknout do manualu...
Tak se pochlubte, jakých výsledků dosahujete vy. Třeba je to opravdu jen mojí/naší neschopností / výrazně neoptimálním defaultním nastavením.
> jestli se tam z minulosti neprenesl nejaky artefakt, co stav spise zhorsuje
Šlo o čerstvou instalaci Debianu Trixie (tehdy verze po prvním zmražení).
Ta metadata jsou ale podezřele velká, nebo jich je zbytečně mnoho, nebo jsou nevhodně uložena.
Můžu se jen zeptat, proč to vlastně řešíš?
Ptám se proto, že disky na serverech jsou tak velké, že řešit kolik má log (typicky 30 dnů) jsem za 20 let nemusel vlastně nikdy. A kdykoliv někdo chtěl nebo potřeboval ukládat logy navždy, tak přinesl tak velké pole, že mi z toho spadla brada.
A ta poznámka o metadatech mi připomněla situaci, kdy se někdo divil, proč ten "můj" postgresql má tak velká data a že se to dá určitě uložit úsporněji. No .... ano, pokud si napíšu vlastní storage, do kterého budu ukládat pouze golang struct v gob, tak to bude skutečně několika násobně menší, ale otázkou je, jestli chci pro každý projekt psát vlastní storage (nechci) a nebo jestli prostě použiju (ano!) univerzální datový typ BYTEA, případně to rozhodím do sloupců. A u mne vyhrává stále to druhé. A pokud vím, že těch logů bude opravdu hodně, tak to naházím do PG prostě ve standardních gobech do bytea a napíšu další program, který to potom postupně rozhodí do dalších tabulek.
Až budu psát simulátor galaxie, tak záznamy o těch 100mld hvězd určitě do PostgreSQL ukládat nebudu, ale na obyčejná data to zatím bohatě stačí.
Spousta serveru zadny disk nema, a loguje treba na nejaky SDcko, ktery je jednak maly, druhak se zbytecne osoupava.
Tohle někdo viděl v praxi? Jednak disky jsou doslova spotřební zboží, takže výměna vadných disků je od určitého počtu práce na plný úvazek a od doby přechodu na DC Intel SSD (od roku 2014 a tehdy P3500) je jejich životnost zatím mnohem lepší, než u rotačních disků.
> Můžu se jen zeptat, proč to vlastně řešíš?
Velikost mě zas tak netrápí, ale když někdo tvrdí, že je journal komprimovaný a menší, tak to uvádím na pravou míru.
Co mi vadí nejvíc je UX:
- rychlost výpisu (journalctl | grep trvá také řádově déle než textový soubor, a to i když je textový soubor zagzipovaný - jo, možná má journal nějaké interní rychlejší vyhledávání, snad)
- otevřu si journal, otevře se v lessu, zmáčknu end, a to nejde, protože to generuje výpis viz výše a to trvá. Takže musím rovnou při otevírání journalu dávat -n 2000, --since nebo něco a doufat že to bude stačit.
- když mám ten otevřený journal v lessu a zmáčknu end, tak se nedonačtou nové věci (protože to journal už vypsal a skončil a už si povídám jenom s pagerem). Oproti tomu když v lessu mám otevřený soubor a dám end, tak ho to přenačte a vidím nové položky. Obdobně lze v lessu zmáčknout "F" a přepne se jakoby do režimu "tail -f". Takže jediná možnost jak vidět nové věci je journalctl -f, ale v tom logicky zase nejde scrollovat
- nejde nastavit různá doba uložení různým věcem jinak než že použiju úplně oddělené journaly
- nejde smazat specificky jednu unitu co se zbláznila a zaplevelila logy a zbytek nechat
- a už vůbec nejde u zblázněné unity smazat zprávy odpovídající regexu a zbytek nechat
Pri mesicni retenci... takovy bezny server (nginx/php/maria/postfix...), na ktery i chodej lidi.
$ du -sh /var/log/journal/ 1.3G /var/log/journal/
neprijde mi to jako cislo, ktere by mi melo nejak zvlast trhat zily :-) Zijeme v 21. stoleti, fakt neprovozuju masiny s 200MB harddisky.
Metadata osobne za dulezita povazuju - vzhledem k fungovani tradicniho syslogu, kdy "pachatel" nemus byt nutne na prvni pohled zrejmy a kdy vzhledem k "primitivnosti" samotneho protokolu se obcas sovy nemusi jevit tim, cim jsou, zeano...
Škoda, že jste jako všichni hujeři opominul fakt, že jednodušší nástroje, které třeba naprosto stačí často není zdaleka tolik třeba umět používat. Když vám dám do ruky bagr, taky ho dost pravděpodobně (minimálně statisticky pravděpodobně) nebudete umět používat narozdíl od lopaty, kterou bravůrně zvládnete (přinejhorším po krátké instruktáži) za pět minut.
A celé to opravdu neznamená, že je horší bagr nebo lopata. Jsou to dva nástroje pro jiné případy užití. Bez kontextu tvrdit, že jedno je lepší než druhé je nesmysl.
A zase ty tvoje demagogie. Mimochodem, ty používáš bagr pokaždé, když potřebuješ přehrabat dětem pískoviště?
Za prvé, není to tak dávno, co jsem se účastnil kopání základů lopatou a krumpáčem, protože bagr v daném místě by byl nesmysl. Zhodnotili jsme, že lopatou to prostě bude rychleji.
Za druhé, nikdo tu neříká, že všude bude používat lopatu a nikde bagr. Píše, že občas se hodí lopata, občas se hodí bagr.
Za třetí, pokud něco lopatou vykopu rychleji, než se naučím s bagrem, má cenu učit se s bagrem?
Za čtvrté, pořizovací náklady - slušný bagr je trošku dražší a náročnější na provoz nez lopata.
Za páté, journald je skutečně trpěná a útrpná komponenta. To, co mám během pár minut hotové nad textovým souborem s logy, to s journald hledám násobně déle. A to už si konečně pamatuji alespoň základní parametry.
A vy pouzivate na detske piskoviste lopatu? :-)
Ano, dava se smysl ucit nove veci - i kdyz tim prvotne treba stravim vic casu. Nabyta zkusenost se typicky hodi vickrat - a nemusim nutne vedet dopredu, kdy ji budu (opet) potrebovat.
Bagr si porizovat nemusite, ono v dnesni dobe neni zas takova magie si jej nekde proste pujcit.
Ze vam veci s journald trvaji dele je spis obraz vasi nesikovnosti :D
> Jinak součástí systemd jsou: journald, libudev, localed, logind, hostnamed, homed, networkd, resolved, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd.
Větší polovinu z uvedeného nepoužívám ani nemám nainstalovánu, u některých věcí dokonce ani nevím, k čemu slouží. Pro věci jako networkd, resolved, timedated jsou naprosto zjevné náhrady ze kterých si můžete vybrat (jakýkoli network manager preferujete, jakýkoli DNS server preferujete, jakýkoli NTP klient preferujete).
Budu tu trochu proti sobě (sám časy před systemd pamatuju a zlatá situace teď), ale výhrady chápu. Respektive chápu, co vidím jakej je problém s X11 a přechodem na Wayland. Jak systemd prorůstá celým ekosystémem okolo Linuxu a jak se na něm stávají závislé i další projekty, bude jednou strašnej problém ho nahradit i kdyby se objevila lepší alternativa. Stejně jako je teď problém nahradit X11 Waylandem + kompozitorama => hromada appek a využití stojí na všemožných funkcionalitách, co poskytuje X11 a je problém to nějak jednotně nahradit, aniž by byl stvořený nově nabobtnalý projekt, nebo naopak totální Babylon napříč kompozitory.
Já teda nejsem žádný velký systemd nadšenec, ale zrovna ty vyjmenované věci dělá celkem dobře a nejsou to zrovna nové nápady. Task scheduler (ať je to cokoliv) postavený na událostech je super nástroj. Hromada služeb může mít socket activation, takže se spustí až po příchodu packetu na jejich port. Potom služby, které jsou závislé na nějakém disku (třeba síťovém) se nemusejí spouštět, když ten disk není dostupný. (Ano, zrovna tady jsem se systemd zažil srandu, když mount unita nadšeně namountovala disk z pole, který jsem opravdu nechtěl namountovat jako RW, resp v této fázi vůbec.) Logovací démon sice nemusí být nutně součástí init služby, ale stav před tím vypadal tak, že se syslog měnil za rsyslog a rovnou se to posílalo někam do ElasticSearch, aby se to dalo používat. Místo toho stačí zavolat journalctl -f -u nginx -u php-fpm a vidím, jak na to obě služby zareagují a vidím to na dvou řádcích po sobě. A právě na tohle (sledování souvisejících služeb) se vždy používaly externí nástroje.
A jestli tím schedulerem byl myšlen třeba timer, tak to je opět velmi výhodné, protože na rozdíl od cronu, kde se 500 úloh zapnulo ve stejný čas (i když to nebylo nutné), tady stačí dát AccuracySec=1h a systemd to spustí podle aktuální zátěže a situace. Navíc ví, co bude spouštět, takže ví, jestli to vlastně může spustit (jestli to takhle reálně dělá nevím, napadlo mě to až při psaní tohoto textu).
Takže jsem po těch letech se systemd spokojen. Když měli všechno od počátku postavené na cgroups, tak se přímo nabízelo udělat kontejnery a od roku 2016 vlastně nic jiného než nspawn na linuxu nepoužívám. Dneska jdou služby kontejnerizovat do jisté míry i přímo v jejich service konfigu a nastavit omezení paměti, cpu apod. A vzhledem k tomu, že je to vlastně strom všech dalších procesů, tak se to nastavuje mnohem lépe, než dřívější ulimit.
Dále to ve své době mělo konečně rozumné nastavení sítě, kdy v jednom konfigu (resp ve více souborech, ale stále je to ini formát) nastavím bridge, vlan, přejmenuju iface apod. Ve starých network scripts to byl doslova porod a stačilo, aby někdo tam dával postaru iface aliasy a někdo ne a potom nástroje (dodnes velmi oblíbeného) jako ifconfig (nešlo by to konečně definitivně zahodit?) tak jeden admin tam viděl 60 IP adres (ip) a druhý třeba jen "svých" 5. V době, kdy si tam každý balíček může přihodit vlastní network konfig podle toho, jaký typ iface zrovna potřebuje tohle odpadá.
A věci jako NTP a DNS resolver se také přímo nabízejí, protože obé je podmínka nutná, nikoliv postačující pro provoz produkčního serveru. Takže nainstaluju minimal debian, je tam automaticky systemd a automaticky všechno, co kromě mého procesu potřebuju. Takže nemusím nastavovat další služby čistě jen pro základní provoz v roli serveru.
Tedy ne, že by to nešlo jinak, ale serverů, kde chyběl NTP jsem taky viděl hodně. Dneska stačí timedatectl set-ntp true a je to.
A ta modularita tam do jisté míry je. Nevím vlastně proč, ale zrovna debian oddělil nspawn a resolved do vlastních balíčků.
Sockety jsou asi v pohodě. Ale třeba vezměme ten cron (například). Ano, ten má opravdu dost nedokonalostí, ale to není důvod, proč jej míchat s init systémem. Už jenom ty konfigurace máte pak naházené mezi servicema, proč? To není o tom, že by ty komponenty systemd (povětšinou teda, ten journald mi pije krev od začátku a asi toho nenechá) fungovaly špatně, to je o tom, že jsou provázané víc, než by bylo zdrávo. Tam se pak otevírají bezpečnostní problémy, kompatibilita, (ne)přizpůsobitelnost atd. Ta filozofie jedna "aplikace"="jedna činnost" má svůj smysl. Systemd to úplně bortí.
Timer je sluzba jako kazda jina. Zrovnatak pri startu mate sluzby, ktere se jen spusti, vykonaji co je potreba a pak svuj beh ukonci. A i tady doslo k ucesani - zatimco cron mate rozesety na mnoha mistech (nekdo to pise naprimo do /etc/crontab, nekdo do /etc/cron.* adresaru, nekdo do /var/spool/cron/crontabs ), timery jsou prehledne na jednom miste. V tomhle smeru systemd nic neborti, spousteni a kontrola behu sluzeb dle definovanych kriterii (ktere muze byt i casove/periodicke) je prace init systemu.
Já s vámi souhlasím. Po přechodu na FreeBSD (na serverech) jsem teprve viděl, co vše jde udělat správně i v prostředí sahající až někam k MULTICSu a vše napsaném v původním sh. Po instalaci FreeBSD core mám v zásadě úplně všechno, všechno nastavené a všechny potřebné služby jsou jednak přímo core, ale také nainstalované, nakonfigurované a spuštěné. Takže nastavím ssh klíč, dám tam vlastní službu a je to. A nebo ani to, fw, nfs, iscsi je přímo v core, takže postavit diskové pole na FreeBSD je jen instalace core, nastavení zfs datasetů a hurá na export přes NFS.
Linuxové prostředí se do tohoto stavu dostává vlastně dodnes. Měli jsme RHEL, ale tam v core vlastně nic není a co appka, to další repositář. Po přechodu na Debian (2012) bylo rázem všechno v základních repositářích, ale zase se nedokázal rozhodnout, jestli je pro desktop nebo pro server (nebo potom pro tablet). A třeba NetworkManager na serveru opravdu nechci (se vším jako wpa-supplicant apod.)
Ta filozofie jedna "aplikace"="jedna činnost" má svůj smysl. Systemd to úplně bortí.
Ač se mi to nechce psát, tak systemd ale je systém jedna appka jedna činnost. Na všechno kromě pid1 je tam další služba. A pomocí API komunikuje se zbytkem. A to, že místo další implementace timesyncd někdo (rhel) přišel s chronyd je mi vlastně dodnes záhadou.
A já vlastně od počátku své kariéry v IT programuju podobně, jak je stavěn systemd. Za jádro považuju data, takže všechno je v PostgreSQL a kolem toho další služby, které se o ta data starají (import, export, analýza, zpracování dat apod.)
A skutečně nevím, co je tak špatného na tom mít konfiguraci .timer unit v /etc/systemd/system. Kde jinde by to mělo být? V crontabech jednotlivých uživatelů? Což jde mimochodem taky, v systemd může mít každý uživatel vlastní systemd --user unity a své vlastní timery.
Co má znamenat v daném kontextu to "core"?
FreeBSD tým řeší kromě samotného kernelu taky vlastní programy (něco jako coreutils). Takže při instalaci lze zvolit kernel, base (core), porty. kernel+base je vlastně nejmenší možná instalace a i bez dalších balíčků (pkg nebo porty) je tam toho vlastně dost, takže na tom lze postavit samostatný server (bez dalších balíčků).
Jenže tady je podstatné to, že o kernel a base systém se stará stejný tým a je to na tom opravdu vidět. Podpora pro jaily je ve všech systémových příkazech, stačí dát parametr -j a už konfigurujete kontejner. A asi nejhezčí případ je soft-updates pro UFS2 v době, kdy ext2 se rozhodovala, jestli bude mít journal, tak UFS2 mělo snapshoty (i když omezený počet) a journal se obešel právě jiným způsobem update kritických struktur ve fs. A tenhle jeden FS jim vydržel vlastně až do nástupu ZFS.
V systemd to funguje podobně, stačí dát některým příkazům parametr -M a už nastavujete nspawn. Ale už vidím, jak někdo "nutí" implementaci -M i do dalších programů v repositáři. ;-) (To jen takové rýpnutí.)
Takže ona "konfigurace" serveru ve FreeBSD se vlastně rovná jen jeho instalace. A pokud je to pro můj program, tak jedna binárka, konfig a služba a je hotovo.
Tohle jsem na linuxu nikdy nezažil. Jasně, u systemd stačí binárka, unita, konfig, ale potom někdo přijde s tím, že chce docker, takže dockerfile, potom někdo LXC a tak dále.
Jako já jsem psal, že cron rozhodně není dokonalý. Ne vlastně je spíš na kopanec. Ale třeba není to tak dávno, co jsem potřeboval dynamicky generované crontaby dostat do k8s a cronjoby na to nebyly vhodné (kvůli té appce, to nebudu rozebírat) a teď mi poraďte s timerem...
Jako fakt bych radši novou reimplementaci cronu, spíš nějaký svébytný anacron, ale timer to není.
Ale musíte tam mít puštěný celý systemd a to, že byste si konfiguraci přimountoval z volume, tak to asi moc nepůjde.
Já nevím, co myslíte tím celý. Systemd v nspawn je typicky jen a pouze pid1, který spouští služby. Nic dalšího tam neběží, protože je to jaksi kontejner. Takže v případě mých nspawn kontejnerů jeho vnitřní systemd spustí jenom ssh a třeba nginx. A tím jeho role končí.
A pokud v kontejneru potřebujete kromě jednoho procesu té služby, pro který je ten kontejner vytvářen i něco jako cron, tak se bez nějakého dalšího managera stejně neobejdete. Tuším, že docker má nějakou možnost správy interních procesů, ale víc o tom nevím. Já provozuju pouze nspawn a jaily (na freebsd).
Však to je u desktopu záležitost vyloženě pár okrajových dister. U specializovaných dister (Alpine např.) to pak smysl dává vzhledem k use-casu (byť i systemd se dá osekat na poměrně minimalistickou implementaci).
Výhoda Linux světa je především ve svobodě výběru. Většina uživatelů benefituje ze systemd a kdo nechce, nemusí. Pokud mu to tak vyhovuje, super pro něj. Byť ji upřímně taky nechápu, ale nikterak mě nepohoršuje.
Windows také velice slušně řeši hromadu balastu a konfigurace. A stejně jsem rád, že jsem z nich už hodně moc let pryč. To opravdu není argument. To, že vám něco vyhovuje je vám přáno. Ale to neznamená, že to, že někomu to nevyhovuje je špatně. A psát, že něco nechápete je jako psát na fórech, že vůbec nechápete, jak někdo může používat Windows. Nebo nedojedená jablka. Nebo cokoliv jiného. Nesmysl.
Tím, že budete dokolečka omílat nepravdu o tom, že někdo něco někam tlačil, se z toho pravda nestane. Budete se muset smířit s tím, žesystemd v Debianu vyhrál po dlouhé debatě, a protože byl technicky nejlepší. O ostatní varianty se nikdo v podstatě nechtěl starat. Jestli si myslíte, že si Debian nechá jednoduše něco natlačit, tak se prostě pletete.
já se ale nebavil o přechodu Debianu, ten se odehrál v době kdy už v podstatě bylo rozhodnuto a příliš alternativ nebylo a stávalo se čím dál složitější je udržovat.
RedHat prostě vytýčil směr, kterým se bude linuxový svět ubírat a ostatní už dřív nebo později tu změnu museli přijmout.
Nicméně na vzniku dister jako Devuan je vidět, že i přes ten tlak a kladené překážky kdy jádro je čím dál více se systemd provázané, je tu stále poptávka po něčem jiném.
SystemD sa stal akýmsi symbolom aktivistov, ktorý si zo SW dokážu spraviť božstvo a každého, kto by si azda dovolil použiť niečo iné pokladajú za hriešnika, na ktorého treba ukazovať.
Rovnako dnes funguje wayland alebo v minulosti PulseAudio. Je to skrátka smer, ktorý Korporácia zadefinovala ako progress a každý, kto nie je s nami je spiatočník, fašista a zamrzol v roku, keď to ešte fungovalo :)
Jenže zrovna PulseAudio je příklad, jak věci nedělat. Stačil přechod na Pulse a původní nastavení 96kHz/24b přestalo fungovat (protože pulse prostě nestíhal) a ještě navíc tam bylo nastaveno 44.1/48kHz, takže aktuální samplerate se měnil podle toho, který zvuk se přehrál jako první, takže konzistence nula a do toho někdy nutnost resample a jindy ne, takže ještě navíc změny latence + nutnost resample ostatních streamů. Takže jsem si pulse nastavil tak, aby na jednu zvukovku nesahal a mixoval jsem si to v mix pultu na stole. (Ale jak jsem se před lety dozvěděl, tak Pulse je super, protože někomu zrovna v něm fungují BT sluchátka, takže každý máme jinou představu o HiFi. :-D)
A už ho nahradilo něco, co funguje bez toho, aby se samplerate snížilo na 1Hz? :-D
Linux na desktopu nemám, ptám se vážně. Mám stále v todo projekt, že do Marantze dám něco jako RPi se zvukovkou AudioQuest DragonFly (super!) a udělám z toho analogu digitál :-D Ale tak nějak automaticky chci nastavit max, tedy 96/24, aby vážka svítila stále stejnou barvou. Svého času jsem k tomu zesáku měl připojenou destičku Asus board (něco jako RPi 1), která měla z tehdy dostupných desek nejkvalitnější audio čip, hrálo to super a měl jsem tam alsu a mpd.
A to ma nejake prakticke uziti a nebo jde jen o vystrelek z kategorie "protoze muzu"
Já teda nevím, na co přesně reaguješ, ale já mám poměrně jednoduchý default. Nastavit maximum, co umí HW. Takže pokud každá integrovaná zvukovka (čip stojí méně než dolar) na desce umí automaticky 192kHz/24b, tak nastavím 192/24 a tak nějak počítám s tím, že to prostě bude fungovat. A s příchodem PulseAudio se vrátily nadávky na netopýry apod. Já si prostě zjednodušuju život nastavením maxima a pokud někdo chce zkoumat, co kde zrovna slyší a vidí a nastavuje si monitor třeba na 6b místo 10b, tak je to jeho boj, ale zase u toho nemusí nadávat lidem, kteří nastaví všude max.
A když už mám doma Marantz a Bowers and Wilkins, tak prostě chci, aby nic, byť třeba jen teoreticky, neomezovalo data po cestě. A jestli těch 80kHz slyším nebo neslyším, tak do toho nikomu nic není.
A tohle je dlouhodobá zkušenost. Ze všech foťáků ukládám raw a někdy jsem moc rád, že tam ta data ze všech těch pixelů jsou (znám lidi, kteří mají i na zrcadlovce rovnou nastaveno ukládat pouze jpeg). Proč bych se měl zbavovat byť třeba zrovna nepotřebné informace jsem vlastně nikdy nepochopil. Pokud ta data nikdy nebudu potřebovat, tak je to vlastně jedno, ale naopak, když je budu potřebovat, tak tam prostě jsou.
No ono to papírově zvládalo i Pulse, ale potom tam nastoupil resampler, který řekl ne (co se týče nároků na CPU). Takže i na prvním Ryzenu nešlo dělat v Pulse to, co uměla levou zadní Soundblaster Audigy (která měla HW audio mixer, takže resampler nebyl potřeba). Takže jsem to vyřešil po svém, na stole mám mix pult, do kterého hraje několik zvukovek podle toho, co zrovna dělám (jedna na hry do sluchátek, druhá na HiFi a integrovaná na desce pro zbytek). Dneska signálové procesory sice umí hromadu vstupů, ale tak na deskách máme obyčejný DA "kodek" (nevím, proč se tomu tak říká, je to prostě simple DA převodník), který chce data v přesné podobě.
Žádný závěr nedělám. Ty ses jenom podíval do dokumentace a tam jsi něco našel, ale nenapsal jsi, že jsi to vyzkoušel. Stačí vytáhnout audacity a osciloskop a otestovat to. Jestli někdy v geologicky dohledné době budu mít linux na desktopu, tak to samozřejmě otestuju. Snad se mezitím ze Slunce nestane červený obr, ale tak to bych ještě stihnout mohl.