Názory k článku
Systemd v roce 2022 povyrostlo na 1,7 miliónu řádků kódu

Pointa bola, že na čase nezáleží, ale na dátume - náležitosť faktúry nie je čas vystavenia, ale dátum vystavenia. A aby sa takýto problém vyskytol s dátumom, to už treba trošinku väčšie skoky.

Okrem toho každý normálny systém neprideľuje číslo faktúre pri generovaní, ale pri zaúčtovaní. Keď sa vygeneruje/vyt­vorí/čokoľvek, tak je to draft, ktorý je možné opravovať alebo zmazať až kým ju účtovník (alebo áno, aj automat) nezaúčtuje. Až potom dostane číslo z číselného radu a až potom sa posiela zákazníkovi.

Zakon o ucetnictvi (alespon v CR) vyzaduje okamzik vyhotoveni dokladu a pokud neni shodny tak i okamzik uskutecneni ucetniho pripadu. Firme, ktera vydava 1 fakturu denne muze stacit jenom datum, firma ktera vydava 10 faktur denne pro stejneho odberatele a kde castka muze byt stejna bude potrebovat vyssi presnost identifikace okamziku.

29. 12. 2022, 11:50 editováno autorem komentáře

Za prvé, pokud se čísla faktur přidělují chronologicky, záleží na tom, s jakou přesností datum a čas ukládáte – když to ukládáte s přesností na sekundy, musí ta chronologie sedět na sekundy.

Za druhé, když se jedna faktura vystaví 29. 12. 2022 v 0:00:00,370 a následující faktura se vystaví 28. 12. 2022 ve 23:59:59,976, je to rozdíl méně než půl sekundy, takže žádný „trochu větší skok“, a přesto vám nebude sedět chronologie ani při počítání ve dnech.

To, že vy byste udělal přidělování čísel nějakým způsobem, neznamená, že jiné jsou špatné. V původním komentáři nebyla řeč o čísle faktury, ale objednávky – a klidně to může být udělané tak, že už čísla objednávek jsou generovaná chronologicky, a číslo faktury je pak číslo objednávky. Navíc v tom vašem způsobu byste si nijak nepomohl, pořád je tam okamžik, kdy se automaticky přiděluje číslo a pokud dojde ke skokové změně času, může dojít k porušení chronologie.

Cislo faktury ale vubec nemusi byt chronologicke. Klidne muzu mit v lednu fakturu cislo 100 a v unoru cislo 5, stat po me chce aby byli faktury jedinecne. Dokonce na fakture nemusi byt ani cislo faktury, zakon zadnou takovou povinnost neuklada. Naopak tam musi byt okamzik vyhotoveni ucetniho dokladu a pokud neni shodny tak i okamzik ucetniho pripadu (tohle spolu s dalsimi udaji zajistuje jedinecnost).

ale ukládá, je požadováno v Zákonu o DPH, každá faktura musí mít své číslo a to je součástí kontrolního hlášení, nedokážu si představit firmu, která není plátcem. Zákon o Účetnictví ale číslování dokladů nechává na účetní jednotce, která se si to účtové směrnici stanovuje sama.

Ratbatcat: Zákon o DPH vyžaduje, aby faktura měla jednoznačný identifikátor. Zákon o účetnictví obecně vyžaduje, aby vedení účetnictví bylo průkazné. Což se v době papírových knih nejsnáze vyřešilo chronologickým číslováním. No a dodnes se v administrativě spousta věcí dělá stejně, jako za císaře pána, akorát se ty výstupy generují na počítači^*). Účetní i kontroloři jsou na to chronologické číslování zvyklí a bylo by marné pokoušet se jim vysvětlit, že jednou zapsaný záznam v databázi se opravdu sám od sebe jen tak neztratí, a že naopak zajistit nepřetržité číslování je dost komplikované a výrazně to celý systém zpomaluje.

*) Například obálky s doručenkou mají stále předtištěné kolonky, aby se to dobře vyplňovalo rukou nebo na psacím stroji. Takže se do toho dneska musíte trefovat tiskem a musíte uživateli umožnit milimetrové posuny tisku, protože různé tiskárny tisknou různě. To samé třeba blankety na vysvědčení. V obou případech by bylo daleko jednodušší (a výsledek by vypadal lépe) tisknout to vše, včetně šablony – jenže v praxi se jen psaní rukou nahradilo tiskem na počítači a už nikdo neřešil, jestli by se to s počítačem nedalo dělat celkově lépe.

U těch vysvědčení je to komplikovanější. Jsou na speciálním papíře s vodoznaky a jinými ochranými prvky. Proto tisk do kolonek. Papír dodá stát.

U těch vysvědčení je to komplikovanější. Jsou na speciálním papíře s vodoznaky a jinými ochranými prvky. Proto tisk do kolonek. Papír dodá stát.
Ne, u vysvědčení je to jednoduché. Vysvědčení je na speciálním papíře s vodoznaky a ochrannými prvky. Pak se na ten papír zbytečně vytisknou kolonky, do kterých se pak musí na školách tiskem trefovat. Kdyby tam ty kolonky předtištěné nebyly a tiskly se až současně s údaji, bylo by to mnohem jednodušší – a ničemu by to nevadilo, protože ty předtištěné kolonky nemají žádný vztah k tomu podkladovému papíru.

Vysvedceni je hlavne cislovany tiskopis. Ale delaji se i "bianco" tiskopisy splnujici potrebne nalezitosti, kde zadne kolonky nejsou (SEVT 49 999 9).

Ten papir na vysvedceni jde koupit i bez sablony/kolonek, tedy ciste jen s vodoznakem na pozadi.

Ten papir na vysvedceni jde koupit i bez sablony/kolonek, tedy ciste jen s vodoznakem na pozadi.
Tak to je pokrok.

Ono to ale uz slo takto koupit minimalne v roce 2014. Aspon tehdy jsem to resil a nebyl to vubec zadny problem.

Já jsem to řešil koncem minulého století, je fajn, že se to od té doby posunulo alespoň někde.

Jenze timesyncd je samostatny daemon. Stejne tak jako dalsi komponenty systemd. Zousel jste si nekdy vylistovat bezici procesy? ;-) Skoro to vypada... ze ne :D

Však to je samostatný daemon a robí jednu vec.

To je ako nadávať na coreutils, pretože ich súčasťou je sha256sum.

ja.
Však to je [timesyncd] samostatný daemon a robí jednu vec.
To je ako nadávať na coreutils, pretože ich súčasťou je sha256sum

to je trochu zavadejici ;-)

jmeno timesyncd binarky je systemd-timesyncd, jeji velikost je pouhych 55kB,
a vyuziva sdilenou knihovnu libsystemd-shared-XYZ.so, jeji velikost je 2.7MB (ubuntu, v249)

k3dAR: Ostatní jednoúčelové aplikace v unixovém stylu snad nepoužívají sdílené knihovny? Naopak by to byla chyba, kdyby sdílené knihovny nepoužívaly, protože by to bylo porušení právě toho principu, že aplikace má dělat jenom jednu věc. Protože by musela implementovat i ty věci, které jsou implementované v té sdílené knihovně.

je rozdil kdyz aplikace pouzije 3rd knihovnu, nebo vlastni, v tom druhem pripade totiz je pak jak sem psal zavadejici psat o "timesyncd" ze [v podstate] se systemd nema nic spolecneho ;-)

V čem je ten rozdíl? Navíc nikdo netvrdil, že systemd-timesincd nemá nic společného se systemd. Důležité je, že to je samostatná aplikace, kterou můžete a nemusíte používat. Klidně můžete používat na synchronizaci času cokoli jiného a systemd vám v tom nebude nijak bránit. To je to podstatné.

Prosim vas, a kolik veci pouziva treba takovou libwireshark.so ;-) Ja jen ze ta ma 110M...

Kdyz uz teda delate takovy nesmysl a pomerujete velikosti knihoven, kolik veci zavisi na libc6? :D Mimoto v lib najdete i mnohem vetsi knihovny, kdyz se podivate pozorne :P

goto 1108953

goto 1108955. Ano, najdete hafo knihoven, kterou v realu pouziva jen jedna vec. Ale co to ma byt za argument? ;-)

> Ano, najdete hafo knihoven, kterou v realu pouziva jen jedna vec.

A tipnul bych že libsystemd-<sstrong>shared používá víc než jedna věc. Nevím co tím chce k3dAR říct -- i kdyby to bylo jenom pro timesyncd, tak 2.7 MB mi přijde pro program který implementuje síťový protokol a různé funkce pro nastavování hodin docela v pohodě.

Jenže to musí ten binární log mít specifikovaný přesný formát, který bude implementovaný i v tom parseru. A nesmí ho zkoušet interpretovat někdo způsobem „to je textový formát, vidím, co tam je, nepotřebuju číst specifikaci“. Ta „výhoda“ textového logu, že je možné jej číst čímkoli/kdykoli je dost pochybná. Zejména, když si uvědomíte, že se textové logy často komprimují, takže ta výhoda padá.

ano i ten binarni log musi mit specifikovany presny format ;-)

pokud vystup co leze do binarniho logu lze nasledne z binarniho logu dostat v pozadovanych formatech/castech, stejny vstup ukladany do textoveho logu by to umel logicky take, jen by misto parser na vstupu byl parser na vystupu...

midnight commander otevre gz rovnou, pripadne: zcat tvuj.log.gz | cokoliv

pokud budes chtit psat ze cokoliv nemuze byt treba gui textovy editor, tak ano pred otevrenim v nem se proste log kdekoliv dekomprimuje ;-)

A to je velmi efektivni, ze? :-) Zvlast u velkych logfiles...

ano i ten binarni log musi mit specifikovany presny format ;-)
Nikoli. Binární log musí mít přesně specifikovaný formát. Textový ho právě přesně specifikovaný mít nemusí (což je u textových logů většina případů), což pak právě způsobuje problémy při jejich parsování.

midnight commander otevre gz rovnou, pripadne: zcat tvuj.log.gz | cokoliv
journalctl zase otevře rovnou binární formát journald… Nějak nevidím rozdíl mezi dekompresí a exportem z journald.

textovej log je komprimovanej az po rotacich >2 v poradi, aktualni a predchozi neni komprimovan...

ten textovy log ktery by nesel z textu parsovat, se do journallogu tedy nedostane? protoze pokud dostane, tak se musi parsovat pred ulozenim do binarniho formatu, takze stejne tak by sel ukladat upravenej do textoveho formatu...

textovej log je komprimovanej az po rotacich >2 v poradi, aktualni a predchozi neni komprimovan...
To, že vy to tak máte nastavené, neznamená, že je to tak všude.

ten textovy log ktery by nesel z textu parsovat, se do journallogu tedy nedostane? protoze pokud dostane, tak se musi parsovat pred ulozenim do binarniho formatu, takze stejne tak by sel ukladat upravenej do textoveho formatu...
Vy do journald ukládáte něco tak, že to zapisujete do textového logu a z něj to parsujete?

Problém textových logů je v tom, že obvykle nemají pevně definovaný formát, takže při jejich parsování o některé záznamy přijdete nebo budou chybně rozparsované. Textový log často rozbijete jenom tím, že zalogujete konec řádku.

To zalezi na nastaveni (externiho nastroje). Aneb komprimovany muze (nemusi) byt uz pri prvni rotaci. A taky nemusi byt komprimovany vubec (treba na CentOSu ve vychozim stavu). Proste si to dela kazdej jak chce ;-) Neexistuje unifikovane reseni.

Filip Jirsák: Ano, takto na papíře vypadají binární logy skvěle. Osobně by se mi taky líbila možnost textové, ale s určeným formátem prvních několika sloupců a escapovanými \n ve zprávách - já konkrétně teču z toho defaultního formátu času "Dec 29 19:08:51" - bez timezone, neseřaditelné… Ono tohle se dá v podstatě udělat pomocí pár řádků konfigurace rsyslogu a logrotate, jen to není default.

Nicméně v realitě jsme do rukou dostali journal, který je desetkrát pomalejší, ale za to zabírá třikrát víc místa na disku i v paměti, neumí základní věci typu nastavit pro různé unity různé retentions nebo přetékající log promazat, téměř neexistuje tooling pro věci jako "vyexportuj journal pro unity X, Y, Z mezi časy A a B pro pozdější analýzu", a ještě je tu pachuť ohledně recovery logů při selhání hardwaru a nutnost řešení konzistence při zálohování.

Naopak, z pohledu konzistence je journald lepsi - zvlaste pokud si clovek zapne sealing. S textakem jen tezko nekdo uhlida, ze logy nekdo v ramci zametani stop po svych preslapech treba nepoeditoval... ale mozna prave to "potrebujete"? :D

Ono tam tech informaci je podstatne vic, defaultne journalctl emuluje vystup klasickeho logu (aka short), ktery je ocesany... ale parametrem -o z nej jde vymamit extenzivnejsi vystupy ( verbose), nebo klidne treba v json formatu, nebo vystup s jinym formatem data/casu, nativne prepnout z lokalni timezone do utc... as-build to umi to i reverse sort - tzn. nejnovejsi udalosti nahore, snadno se da dostat k logu z predhoziho bootu ( -b -1), kdyz se neco zvrtne... samo/nativne si to umi resit rotaci/data retention po definovany cas a nemusim spolehat na nejaky externi tool a cron, co ho pusti (nebo taky ne).

Cim vic clovek cte tuhle diskuzi, tim vic se utvrzuje v nazoru, ze lidi dokumentaci fakt moc nectou... ale hlavne ze maji nazor, ze je vsecho spatne :-)

> Naopak, z pohledu konzistence je journald lepsi

Z pohledu detekce poškození ano, z pohledu čitelnosti logů těsně před selháním systému (kdy logy potřebuju nejvíc) mi nezbývá než doufat, a když vidím „kvalitu“ zbytku journald tak nejsem moc přesvědčen…

> Cim vic clovek cte tuhle diskuzi, tim vic se utvrzuje v nazoru, ze lidi dokumentaci fakt moc nectou...

To je pravda, ale když to neumí základní funkčnost, tak k čemu mi je že to umí json a nastavovat formát času?

To rotování je taky takové sporné -- když se něco zblázní a začne logovat (máme teda ratelimit, jak v journald, tak v rsyslogu), tak u journald všechny logy odrotují, u rsyslogu dojde místo a předchozí logy jsou zachovány… Já bych preferoval to druhé, ale samozřejmě se musí nějak zařídit, aby místo došlo tak, aby nehavarovaly služby protože není místo ve /var/spool atd.

Kdyz dojde k padu systemu, tak i textove logy byvaji vesmes nakopnute. A fakt pomerne casto je to tak, ze v textaku je pasaz, kde je spousta znaku 0x00 :D Ve finale to jako bonus rozhodi mnohe ty "parsery textu", kdyz na tohle narazi...
A pomoci journalctl --verify muzu instantne overit, jestli je v logach nejaky vami popsany problem....
Rotace je nastavitelna podle toho, co kazdemu vyhovuje. Jinak viz man journald.conf a informace u parametru SyncIntervalSec (vc. toho co to dela u zprav s kritictejsi prioritou).

No vždyť jsem to psal, že pasáže nul vídám. A co se zvládlo zapsat předtím, to normálně vidím. Řekne mi journal „sorry poslední zápisová transakce se nedokončila, nezobrazím, bye“?

Sync podle priorit je pěkná myšlenka.

Nikoliv, vysledny stav bude stejny - neco v tom logu bude, neco ne. Nevim, z ceho jste (asi) dovodil, ze nepujde precist cely log jen proto, ze je binarni... proste tam jen budou chybet ty informace, co uz se nestihly korektne zapsat. A jako bonus mam nastroj, co mi to poskozeni logu primo indikuje - nemusim na to prichazet metodou pokus-omyl.

> Nevim, z ceho jste (asi) dovodil, ze nepujde precist cely log jen proto, ze je binarni...

Nemyslel jsem že nepůjde přečíst celý log, to už se snad umí řešit (žurnálování jako v databázi), ale že pro přečtení posledních položek asi nestačí když se zapíšou, ale musí se zapsat a pak se ještě musí někde nastavit nějaká struktura, že jsou tam zapsané. Ale třeba je ten formát opravdu nějaký mazaný a bude to fungovat.

No mimo jine to resi i to, ze kdyz se nejake naruseni detekuje, tak se okamzite stavajici soubor odrotuje a zacne se s cistym souborem.

Nicméně v realitě jsme do rukou dostali journal, který je desetkrát pomalejší
Za prvé jste při tom porovnání rychlosti porovnával jablka s hruškama, za druhé je při čtení logů rozdíl v rychlosti v řádech desítek milisekund absolutně nezajímavý.

Formát journald je podle mne určený pro sběr logů, ne pro jejich archivaci. To, co vám chybí, podle má být vlastností nástrojů pro zpracování a archivaci logů. A znáte to – každý nástroj by měl dělat jednu věc, a tu má dělat dobře.

> Za prvé jste při tom porovnání rychlosti porovnával jablka s hruškama

Otevřu log, zmáčknu End, čekám. (inb4 "tak používejte journalctl -n 500 a když pak zjistíte že chcete víc historie tak si to pusťte znova" -- ve skutečnosti jsem se z diskuze dozvěděl že mám dávat journalctl -r, uvidím v praxi, jestli mě bude mást že je nejnovější nahoře)

> za druhé je při čtení logů rozdíl v rychlosti v řádech desítek milisekund absolutně nezajímavý

Sekund.

> Formát journald je podle mne určený pro sběr logů, ne pro jejich archivaci. To, co vám chybí, podle má být vlastností nástrojů pro zpracování a archivaci logů.

OK, ale než bude, tak prostě nemůžu journal rozumně používat.

Jinak popíšu k čemu jsme aktuálně dokonvergovali: máme aplikace v Pythonu. Používáme nějaký logger (nevím jaký, řeší kolega, já jenom vím že se to naimportuje a pak můžu dělat logger.warnin­g("bleble")), který to posílá na (lokálně běžící) logovací server, který to zapisuje do texťáků pojmenovaných podle služeb a sám si je rotuje. A současně zprávy s nejvyšší důležitostí přeposílá na centrální server, který nám pak píše maily a na Slacku. Logů je řádově 10 MB za hodinu (například logujeme veškerou komunikaci s hardwarem po sériáku, aby to pak šlo debugovat), to jsme usoudili že journal nezvládne + popsané problémy s exportem a archivací (například jsme jedno zařízení zničili, poslali na opravu, a oni se za dva měsíce ptají co přesně jsme tomu dělali potřebujeme umět vyexportovat několik hodin logů a uchovat; samozřejmě z journalu bych si je mohl vypsat textově, ale to je můžu mít textově rovnou).

Do journalu jsou přesměrované stderry těch pythoních programů, takže se tam logují jednak stavy unit (restart, exit code) a jednak když to udělá něco co ten logging nezaloguje (ten logger chytá i neošetřené výjimky, ale pokud to umře nějak kreativně tak se to vypíše na stderr + na stderr píšou Cčkové knihovny co ten Python používá). A pak je tam nějaké hlídátko journalu které z toho taky dělá zprávy které se nám pak posílají (přečte z journalu řádek, podle regexpů a kolikrát se to za poslední hodinu opakovalo zjistí důležitost a zahodí/pošle/pošle urgentně).

Tím jsme dost vyřešili ten problém že se do journalu nesmí moc logovat protože pak je velkej a pomalej. Jediné co se mi teď stalo je že se jedna z těch služeb každých 5 sekund restartovala (jak má nastaveno) protože nebylo připojené HW zařízení co bylo potřeba a tak to vždycky hned skončilo, a tohle přes noc udělalo desetitisíce řádek (systemd hlášky o restartování + stderr hlášky při startu) a pak to zase bylo pomalý. Tohle se samozřejmě musí vyřešit tím že se víc poladí takové ty "restart timeout" a "burst" aby to třeba zkusilo 3x a pak až za 5 minut. Škoda že to tam teď furt je (nechci odrotovat celý journal kdybychom potřebovali něco ještě ladit a selektivně tu jednu unitu smazat nejde) a ještě nějaký ten týden bude…

Otevřu log, zmáčknu End, čekám. (inb4 "tak používejte journalctl -n 500 a když pak zjistíte že chcete víc historie tak si to pusťte znova" -- ve skutečnosti jsem se z diskuze dozvěděl že mám dávat journalctl -r, uvidím v praxi, jestli mě bude mást že je nejnovější nahoře)
Tak si to zkuste srovnat třeba s případem, kdy budete muset mezi textovými logy nejprve najít nějaký starší soubor. Nebo budete potřebovat data z více souborů. Nebo z více služeb.

Sekund.
OK, tu jedničku jsem přehlédl, rozdíl je tedy jedna sekunda. Když ovšem nebudeme počítat dobu, jak dlouho jste hledal ten správný soubor s textovým logem…

OK, ale než bude, tak prostě nemůžu journal rozumně používat.
Vždyť můžete používat to, co používáte doteď. Data z journald přece můžete vyexportovat i v textovém formátu.

Jinak popíšu k čemu jsme aktuálně dokonvergovali: máme aplikace v Pythonu.
Podle mne na tohle je lepší ELK nebo něco podobného (dají se do toho sbírat i logy z journald). journald vnímám jako základní jednoduché logování v systému, na aplikační logy vlastní aplikace bych to nepoužil.

No ehm... pokud to mate tak, ze to restartujete kazdych 5 sekund i kdyz tam ten device pripojeny ani neni (a instantne to spadne), tak to mate spis sami blbe vymyslene. A to ale neni chyba systemd...

journald je hlavně sběr logů a nikoliv jejich archivace, ač tu také nějak umí.

Tvůj popis ukazuje, že vlastně nemáš problém s journald, ale s návrhem aplikace, zkus se zaměřit spíše na tohle, ušetříš si spousty energie běháním proti zdi. To nemyslím nijak zle, ale občas je dobré se zastavit a podívat se, jestli ty problémy neřešíš zbytečně.

Souhlasím že logovat systémově provoz po sériáku je blbost, na druhou stranu různé SOHO mailservery co jsem viděl a adminoval (ne že jsem to tak nastavil, ale už to tak bylo i od jiných) strkaly skrze syslog do mail.log pro každý mail třeba 15 řádků, takže ty objemy nejsou zas _tak_ astronomické. (na druhou stranu webservery už si typicky řeší access.log po vlastní ose a netlačí to přes syslog)

A jak to mám teda archivovat? Koketoval jsem s tím že to budu forwardovat do rsyslogu, v unitě nastavím SyslogIdentifier a podle toho to budu rozhazovat do normálních texťáků, ale nakonec mi to přišlo jako moc velký opruz na to abych to řešil (a raději jsem se věnoval omezení aby se do journalu nelogovaly zbytečné věci).

máme servery, kde journald ukládá 100MB/s logů.

Obecně udržovat a archivovat logy na stanici nebývá z dnešního pohledu útoků a rizik nejlepší volba. Rejpání se v logách přímo přes journald je opět takové spíše na ruční debugování v UAT než pro produkce.

Na standalone stanicí, které někde u klientů něco dělají, používáme třeba exporter do sqlite, nad logy je pak nějaká analytika a alerting, přímo na stanici. Dobře dnes může sloužit třeba i loki.

Journald je pro čtení a vyhledávání logů takový dost hloupý, nemá indexy a čte to sekvenčně ze společných datových souborů. Chceš-li ho optimalizovat pro rychlost dotazování, tak oddělit služby do vlastních souborů je dobrý začátek. To, že ale umí prokázat úplnost logů a při jejich exportu je možné pokračovat od poslední exportované zprávy je velká výhoda proti rsyslogu.

proc by ta vyhoda odpadala? uz jste nekdy pouzil pipe v linuxu? bezne pracuju s komprimovanymi textovymi logy a zadny problem jsem s tim nikdy nemel. naopak to shledavam jako velikou vyhodu mit je v textove podobe a presun k logum binarnim je dle meho veliky fail.

(btw. @Danny to nebyl "hejt", ale normalni otazka, na kterou jsem cekal normalni odpoved - ta vase me nepresvedcila).

predstavte si situaci, kdy vam "crashne" disk/ssd prave s logy. je jednodussi dolovat textova data nebo binarni?

Textovy format vam velmi snadno rozhodim proste tim, ze poslu oddelovac tam, kde ho ten vas parser nebude cekat.

To je podle „neviditelného odkazu“ (vlevo od nicku) reakce na váš vlastní komentář? Pokud to mělo být na mě, tak říkám, že rsyslog by měl \n, \r a spol. escapovat. (mezery/taby oddělovače nejsou, protože důležité jsou první dva sloupce - čas a jméno zdroje - pak je mezera a pak už může být mezer kolik chce).

Tak to asi neco delate blbe ;-)

danny@enterprise:~$ du -s /var/log/journal
351864  /var/log/journal
danny@enterprise:~$ journalctl | wc -c
2828168

Čili 352 MB logů na disku obsahuje 2.8 MB textového výstupu? Tak to máte výrazně horší skóre než já, mně 64 MB logů na disku obsahuje 20 MB textového výstupu.

Mimochodem:

# time journalctl -u transmit_api.service | wc -l
119667

real    0m1.183s
user    0m0.877s
sys 0m0.150s

# time zcat /var/log/syslog.2.gz | wc -l
299219

real    0m0.143s
user    0m0.133s
sys 0m0.020s

🤡🤡🤡

Mimochodem2 (náhodou jsem na to narazil při ověřování argumentů v jiném komentáři):

/var/log/journal/915b7493f84f42eabb5d51eba95f2985 # cat system.journal | wc -c
58720256
/var/log/journal/915b7493f84f42eabb5d51eba95f2985 # cat system.journal | xz -9 | wc -c
4217472

Tak tolik asi k té komprimovanosti. Analýza pomocí

hexdump -ve '1/1 "%02X " "\n"' system.journal | sort | uniq -c | sort -rn

ukáže, že 58% bajtů v tom souboru jsou binární nuly. Velmi letmé prolistování hexdumpem pak ukáže, že bohužel jsou ty nuly rozprostřené v menších blocích přes celý soubor, takže udělat soubor sparse (cp --sparse=always) ho zmenší jenom o čtvrtinu.

Kdyz on si nejake misto pre-alokuje dopredu. Ono se to muze hodit... treba k tomu, ze vam to zaloguje udalosti, i kdyz neco "okolo" zaplacne cely filesystem.

To mě taky napadlo, a proto jsem to pak ještě zkusil i na „odrotované“ soubory. A… ne. Jako ten poměr je trochu lepší, ale furt je >10x. Což mi přijde úplně bizarní, čekal bych, že to archivní soubory během odrotování zkomprimuje (jako to dělá logrotate). Prej to jde zapnout, jenom to není default, tak to zkusím.

ad 1) escapování má vždy dvě strany, při uložení nechceme rozbít formát dat, při čtení nechceme interpretovat něco, co nám může udělat paseku. A jak prosímtě escapuješ do textového logu? Vždyť to nemá žádná pravidla. journald umí vracet strukturovaný výstup (json např.), kde již je vše řádně escapované.

ad 2) ty nuly tam jsou uloženy dopředu jako prostor, kam se zapisují další logy. Hard reset je tvůj častý případ? Journald primárně data drží v paměti a v pravidelných intervalech syncuje na disk. Pokud chceš dobře fungovat s hard resety, asi bych zvolil úplně jinou technologii na zápis logů. Ano, můžeš si počítat vlastní checksum, ale tady se bavíme o univerzální logovací službě.

ad 3) v jaké konfiguraci? Výchozí nastavení v distribucích je tak trochu hodně univerzální a o nic moc se nesnaží, výhoda journald je jeho dokumentace a možnost přízpůsobení.

Zkoumat logy přímo na serveru je něco, co se spusty let v mém vesmíru nedělá, logy sbíráme a replikujeme na centrální server, snažíme se prokazatelně sesbírat a přenést všechny (to journald umí pěkně), poté se indexují a dělají nad tím další operace. Jde o to, že přístup na produkční servery pod rootem má málokdo, dělat si tam nějaký streaming logů do konzole je pro mě tak trochu mimo.

Podle toho, co tady píšeš, tak máš nějaké malé přenosné linux stanice, ty mají připojený nějaký HW, s kterými komunikují a to logují. To vysvětluje ty časté hard resety, na to journald zrovna není přeborník a klidně použij něco jiného, těžko víme jak to máš, začal jsi univerzální kritikou, tu jsme se snažili mírnit, teď to vypadá, že v tvém konkrétním případě journald není vhodný, skvělé si to uvědomit a najít vhodnější řešení.

1) Omezení, že logovací systém nedokáže uložit newlines a řídící znaky mi přijde jako něco, s čím dokážu v pohodě žít. A pak už není potřeba escapovat při zobrazení. Do textového logu bych escapoval třeba tak, že bych "\" nahradil za "\\" a newline nahradil za "\n" (stejně tak \r a spol.).

Schválně jsem si zkusil do syslogu poslat newline pomocí logger "něco s newline" (doufám že to nedělá escape už na klientovi) a zalogovalo to místo ní "#012". To není úplně optimální, protože když tam pošlu doslova "#012", tak to pak nejde odlišit od newline (správně by to mělo třeba ještě escapovat křížek), ale na druhou stranu myslím že lidi by neměli do logů posílat newlines a tohle zařídí že se to nerozbije, holt za cenu nejednoznačnosti.

2) Jo, tak nějak jsem si to myslel, že to alokuje filesystém třeba po stránkách. Hard reset je můj častý případ v tom, že je to ze způsobů ukončení systému ten běžný (výpadek elektřiny, zátuh (to se mi děje na notebooku občas bohužel)). Ale jen výjimečně potřebuju logy co byly těsně před tím (to pokud by to bylo tím způsobeno - většinou je to ale nesouvisející externí příčinou).

Checksum jsem dával jenom jako příklad že to nevyžaduje binární logy a šlo by to implementovat i nad textovými.

3) Výchozí v Debianu. Tobě to funguje?

Nj, já jsem byl předtím SOHO admin kde to bylo heterogenní a bylo toho málo, a teď jsme v živelné fázi startupu, tak se to dělá takhle (a taky je těch strojů pár). Logy přeposíláme jenom s velkou severity za účelem alertování.

SOHO adminování byly takové ty běžné webservery, mailservery a tak; a teď mám radary :) což je průmyslové PCčko, ke kterému je připojené bladeRF a hromada sériáků přes které se to různě ovládá a měří. Aktuálně to provozujeme tak že se tam nasshčkujeme a čteme logy (případně si soubory odpovídající času kdy se něco rozbilo zkopírujeme). A taky to tak, no, vyvíjím, protože dost věcí se blbě dělá na stole. A pak to má lokální influx+grafanu, do které se sbírají metriky po sekundách, a do globální grafany se posílají minutové agregace - pro bližší zkoumání některých problémů jsou potřeba ta sekundová data. To dělám tak že si protuneluju po SSH port 3000 a připojím se na tu grafanu lokálním prohlížečem :).

TL;DR nejak to bastlime, ale poradne a systemove spravne reseni nevyhovuje tomu nasemu bastleni :-) Tak ho hejtime...

TL;DR journald se nehodí na mnoho use-cases na které byl syslog super, tak ho hejtíme.

TL;DR journald se nehodí na mnoho use-cases na které byl syslog super, tak ho hejtíme.
Přesnější by bylo, že se na to nehodil ani syslog, akorát že jste to neřešil. Například to „escapování“, ze kterého nejde zrekonstruovat, co přesně bylo zalogováno, je podle mne vážný problém. O kvalitách syslogu svědčí i to, kolik aplikací se mu vyhýbalo a řešilo logování po svém.

Z jinych mist teto diskuze je patrne, ze spis mate blbe vymysleny sve "aplikace". Viz treba ty restarty unity co pet sekund, kdyz nema pripojeny zarizeni. A pak fnukate, ze vam to zablesi zurnal.

"Omezení, že logovací systém nedokáže uložit newlines a řídící znaky mi přijde jako něco, s čím dokážu v pohodě žít."

A pak si tam zkus poslat něco, co obsahuje vstup od uživatele.

A pak si tam zkus poslat něco, co obsahuje vstup od uživatele.

Ano, to je totiž většinou nezpracovatelné, neuložitelné a nečitelné.

...a potřebuješ to.

A jak si to pak zobrazuješ? Dokážu si to představit v nějakém GUI, ale v textovém terminálu to stejně budeš muset ukazovat nějak escapovaně. A i v tom GUI bude IMHO dost zásadní ty řídící znaky nějak zobrazit (a neinterpretovat, například když tam je \r, tak nechceš přepsat obsah předchozího řádku), protože na to koukáš asi z důvodu, že vstup od uživatele vyvolal nějakou chybu a v tom budou řídící znaky hrát roli. (jediné co tam může být OK je newline)

Furt si nedokážu představit use-case kdy by mi vadilo že to escapoval už syslog než to zapsal do souboru (a kdybych to jó potřeboval tak to můžu odescapovat).

ad 1) to #012 dělá rsyslog, https://www.rsyslog.com/doc/v7-stable/configuration/input_directives/rsconf1_escapecontrolcharactersonreceive.hm a to je přesně ono, nikde není řečeno jak má probíhat escapování do texťáku a každý si to dělá jinak.

ad 2) a chceš si logy řešit sám nebo řešíš, kterou službu na ně použít? Z těch linuxových vím pouze o journald, který dělá kontrolu integrity, ostatní nikoliv. Pokud chceš psát vlastní logování, klidně, ale pak nemáme o čem diskutovat.

ad 3) journald v debianu potřebuje trochu lásky a konfigurace, jako spousta věcí tam, bohužel, dobře připravené distribuce linuxu začínají být nedostatkové zboží a pokud potřebuješ od journald jiné chování, změn si to, to je na linuxu skvělé, dá se tam upravit cokoliv.

Nj. to vypadá jako celkem šílený návrh systému, ale co občas naděláš, že? To vypadá, že s logy máte zbytečně moc ruční práce, to se nedivím, že vás trápí pomalost journald při čtení.

> Nj. to vypadá jako celkem šílený návrh systému, ale co občas naděláš, že?

Nadělat s tím můžu cokoli, protože to donedávna byla one-man show a teď je nás pár a můžu vymýšlet celkem libovolné změny. Spíš nevím jak to udělat líp. Spíš jde o to že jsem měl plné ruce práce s tím udělat funkční radar způsobem který jsem si vymyslel a zjistit jestli z toho lze odstartovat startup a nebyla kapacita na to zkoumat a vyrábět nějaké „fullstack věci“, a fakt jsem ocenil že „počítače“ („SDRka“, „arduína“, …) „prostě fungujou“ a nemusím to řešit.

> To vypadá, že s logy máte zbytečně moc ruční práce, to se nedivím, že vás trápí pomalost journald při čtení.

Stejně tak nevím jak ten vývoj a především teda debugování dělat jinak - něco se pokazilo, tak čtu logy, snažím se zjistit co se kde stalo, a typicky to odhalím. Resp. tohle je způsob jakým věci dělám (odjakživa, tj. 10+ let) a jsem s tím úspěšný, což samozřejmě neznamená že by to nešlo ještě lépe.

AFAIK je možné mít těch číselných řad paralelně víc. A je to tak konstruované kvůli (o něco) lepší průkaznosti účetnictví. Ale poněkud nepříjemné to je.

S tím podvržením nevím, jak to myslíte? Že bych byl domluvený s dodavatelem, že číslo faktury bude mít nějaký "checksum" a podvodník by nejspíš nevygeneroval validní?

Jinak počty ani čísla faktur nejsou osobní údaje, takže UOOÚ s tím nemá co dělat.

Nikoliv, nic mi nebrani mit v cisle faktury treba i mesic... kdy se zmenou mesice se rada zdanlive "prerusi". Do cisla muzu zakomponovat dalsi veci, treba i to, kdo fakturu vystavil. Dulezite je umet ten system cislovani pripadne kontrole popsat.

Zákon o účetnictví skutečně číselnou řadu mezi povinnými náležitostmi faktury neuvádí. Je to nicméně zavedený mechanismus integrity účetnictví a když ho nebudete při kontrole finančním úřadem mít, můžou pojmout podezření, že krátíte daně a udělat hloubkovou kontrolu, což nechcete. V době papírového účetnictví to asi mělo smysl, nicméně dnes se dá ta integrita účetních záznamů držet a prokázat i jinými způsoby.

U faktury ne, ale u účetního deníku už ano:

https://www.zakonyprolidi.cz/cs/1991-563?text=z%C3%A1kon%20o%20%C3%BA%C4%8Detnictv%C3%AD#p13

Účetní jednotky účtují, pokud tento zákon nestanoví jinak:

a) v deníku (denících), v němž účetní zápisy uspořádají z hlediska časového (chronologicky) a jímž prokazují zaúčtování všech účetních případů v účetním období,

Faktura je jen "formát přenosu dat", ale její číslo evidujete třeba v deníku vydaných faktur. Teoreticky by asi mohlo být náhodné, ale FÚ by se nejspíš zeptal, jak z toho pozná, že jste něco nevyřadil.

Zakon o ucetnictvi vyzaduje jednoznacnou identifikaci dokladu, jak toho dosahnete je na vas. Faktura vubec nemusi mit cislo. A vyrazeni z ucetnictvi muzete mit osetreno formou predpisu. Pokud urednice FU bude namitat ze je to nedostatecne, odkazte se na zakon o ucetnictvi a pani to pochopi. A ano, zazil jsem i hloubkovou kontrolu kdy jsme dostali pokutu 5000 za nejaky smesny prohresek ale dalsi 3 roky byl klid, takze za tech par dne prace a par tisic to stalo.

Chronologický zápis v seznamu ovšem nevyžaduje chronologické číslování, pokud si zvlášť evidujete datum a čas. Akorát se vám pak může stát, že v tom chronologickém výpisu budou čísla faktur prohozená (bude tam zapsaná nejprve faktura s vyšším číslem a pak až s nižším), což bude přitahovat pozornost kontrolorů – proto se tomu i dnes snaží software vyhnout, i když to odpovídá době, kdy se účetnictví psalo perem do skutečných papírových knih, a dnes to vše jenom komplikuje.

Ono by asi šlo to číslo faktury generovat jako hash údajů z faktury (a zkontrolovat jedinečnost) - pak by to bylo nejen jednoznačné, ale taky by šlo snadno zkontrolovat, že s tím dodatečně někdo nehejbal.
Ovšem obávám se, že by to bylo trochu mimo toleranci ouředníků.

Účelem nepřetržitého číslování bylo to, aby se na nějaký doklad nezapomnělo. To hash nezajistí. Také je potřeba počítat s tím, že může docházet k chybám, takže je možné vystavit opravný doklad – to, aby doklad s přiřazeným číslem byl neměnný tedy není nijak zajímavé.

Účetní systémy nedělám, takže možná mi něco uniká, ale proč prostě nepoužít autogenerovaný primární klíč z tabulky invoice?

Dobrý den, mohu poprosit o popis jiného způsobu prokázání, že mnou vystavené faktury za dané období jsou všechny v případě, že nebude použita variace na vzestupnou řadu? Řekněme že mám v systému řádově 1000 různých dokladovych řad a potřebuji peovest kontrolu zda mám všechny. Předem děkuju za popis. S přáním hezkých vánočních svátků

Jenže problém je že to vidíte za sebe -- když to nepřínáší užitek vám (nebo ten užitek za sebe nevidíte), nepřináší to užitek nikomu. Ale to není pravda, třeba takové systemd-resolved např. přináší možnost resolvování tld o specifický ns, což je věc kterou třeba já využiji (vy asi ne).

Mě to připadá že jste se prostě jednou "naučil" v 90kách unix a představujete si že to bude na celý život. Takhle to ale ve světě nefunguje, veškeré věci procházejí evolucí (os, software, programovací jazyky i nakonec takové věci jako (ať se nedržíme výhradně software) vozidla, letadla, řemesla... prostě všechno). A to co platilo před 10, 20 lety opravdu dnes neplatí a popravdě ani většině uživatelů(pro­gramátorů, řemeslníků, řidčů...) by to nevyhovovalo.

Ano, kazdy to mame jinak. Pisu jak to mam ja.

Ano, souhlasim s tim, ze svet prinasi nove problemy, v 90tkach DNSSEC nebyl, a je to vec, ktera resi urcity problem, byt ne zcela dokonale, ale je to myslim good enough reseni.

Ale uz nesouhlasim s tim, ze vetsina novych reseni (ala koncepty v systemd-resolved) skutecne prida takovy uzitek, aby stalo za to domrvit stavajici reseni. To co vlastne popisujete pokud jde o nutne zmeny (cache atd.) tak by do (g)libc zcela urcite slo zapojit vic po vzoru paradigmatu Unixu (sada malych komponent delajicich svoji praci dobre).

Treba nakonec skoncim u OpenBSD :).

> To co vlastne popisujete pokud jde o nutne zmeny (cache atd.) tak by do (g)libc zcela urcite slo zapojit vic po vzoru paradigmatu Unixu (sada malych komponent delajicich svoji praci dobre).

Nechápu co není unixového na přístupu „spustím lokální DNS démon který všechny ty komplikace bude řešit, nechám ho poslouchat na 127.0.0.53, tohle napíšu do resolv.conf a všichni se ho budou ptát stávajícím jednoduchým způsobem a on jim bude vracet jednoduché odpovědi“. Jakmile máš cache, DNSSEC klíče a já nevím co dalšího, tak se všechny programy co dělají resolving budou přetahovat o nějaký soubor ve /var/cache/bleble a nedejbože bude muset být něco SETUID nebo +t aby to tam mohlo zapisovat.

Posílat systémovou poštu přes lokálně běžící postfix/exim4 ti taky přijde neunixové?

To co vlastne popisujete pokud jde o nutne zmeny (cache atd.) tak by do (g)libc zcela urcite slo zapojit vic po vzoru paradigmatu Unixu (sada malych komponent delajicich svoji praci dobre).
Nevím, jak ještě víc unixově byste si službu pro překlad DNS záznamů představoval, než že záznamy překládá, validuje a kešuje. Nenajdete žádnou jinou službu, která by dělala třeba jenom cache pro DNS záznamy a počítala by s tím, že překládat to bude jiná služba.

Naopak tady někdo jako alternativu zmínil DNSmasq, který kromě překladu a cache dělá také autoritativní DNS server a DHCP server.

Tak si vzpomente na init systemy z te doby :-) To byl jeden velky bastl. Clovek si vesmes vystacil s tim, ze sluzby nastartovaly v nejakem poradi... Kdyz chcel hlidat beh sluzeb, musel to nejak zrovnatak bastlit okolo, zrovnatak byly dost velkym bastlem i ruzne pokusy o paralelizaci startu sluzeb... a cela bezpecnost stala a padala s tim, co vytvoril autor init scriptu.
No a Vam to mozna staci dodnes... a tak proc ne. Ale od moderniho init systemu se toho chce ponekud vic. To ze moznosti systemd (treba omezit prava, systemove zdroje, izolovat tmp) vyuzit nedokazate opravdu jen dokazuje neochotu se neco noveho naucit a treba to delat lip nez pred ctvrt stoletim ;-)

Motame se v kruhu, tak uz jen strucne: Nemyslim, ze sysV init byl spravny a nahradit je ho urcite dobre, ale vsechny koncepty, ktere prinasi systemd za to myslim nestoji.

Mam-li si vybrat predvidatelny system se SysV initem, nebo neco co mi prepisuje konfiguraky, tak volim radsi neco na zpusob toho SysV initu, protoze udrzet to funkcni mne myslim bude stat mene casu.

Na druhou stranu to, ze Ubuntu prinasi celkem dobry komfort pokud jde o snadnost instalace a updatovani zatim stale prebiji nevyhody, ktere mi to prinasi, takze ho pouzivam. A tohle pisu z Windows, protoze v Linuxu mi zase nefunguji nejake pracovni veci, takze Win vyhraly na tomto stroji nad Linuxem.

Abych dodal posledni vec, vystupovani Lennarta celkem jasne ukazuje jeho osobnost a zapada to do meho modelu "vim nejlepe jak to maji ostatni delat".

Jenze samotny init (systemd) zadny konfigurak v etc neprepisuje, to je proste FUD... z neznalosti. A flame kolem /etc/resolv.conf - ehm, ten prepisuje treba i network manager, ktery se systemd vubec nic spolecneho nema. A naopak samotny systemd-resolved daemon na /etc/resolv.conf nesaha - to je prace, co udela postinstall script samostatneho balicku (minimalne v pripade Debianu/Ubuntu) - ktery zmineny soubor nahradi symlinkem na soubor umisteny v /run/systemd/re­solve/... ale samotny daemon do /etc/resolv.conf fakt nehrabe. Kdyz nevite a viditelne si ani nedokazete zjistit, jak to doopravdy funguje, tak radsi pomlcte :-)

> A flame kolem /etc/resolv.conf - ehm, ten prepisuje treba i network manager

NetworkManager (s velkými písmeny) je taky „kontroverzní“ technologie. Spíš bych jako příklad dal dhclient - a ten dokonce kašle na symlinky…

Mě by zajímalo jestli mu to fakt přepisovalo soubor v /etc, myslím si že tam měl symlink a nevšiml si toho (a symlink stačilo smazat -- a nebo resolved odinstalovat, když ho nechce - otázka je proč ho vůbec instaloval, například na Debianu se automaticky neinstaluje).

Proc kontroverzni? Jasne, na server si to clovek nestrci, ale proc ne notebook, se kterym clovek porad nekde lita? Nektere use-case to vyresi naopak elegantne (priority LAN/WLAN/WWAN + ev. i VPN) a to vc. spravneho poskladani toho resolv.conf. Dynamicky... jasne, s ifupdown to jde vykouzlit taky, ale je to desnej os*r :D

Protože je potřeba nastudovat jadernou elektrárnu aby to člověk dokázal používat pro všechny své use-casy (připoj se a nenastavuj adresu; nastav statickou; až teď si řekni o DHCP ale nenastavuj z toho default routu; na jedné wifi kartě spusť hostapd a druhou používej pro připojení a NATuj…) a viděl jsem příliš mnoho lidí v tom failovat (populární je třeba zapomenutí ručně nastavené adresy na ethernetovém rozhraní když na chvilku spadne link). Nepochybuji že všechno z toho lze nastavit i s NM, ale pro mě bylo jednodušší si napsat těch pár shellových skriptů co to připojení zařídí. mhi to může mít stejně a odkloní se tím diskuze uvedením nevhodného příkladu.

A tak kdyz notebook pouzivate jako substitut za router :-) Na vetsinu beznych ale i pokrocilych (klientskych) use-case ale zadnou elektrarnu studovat netreba, to clovek proste naklika. A samozrejme kdyz mam na chvili echt specificky pozadavek, nic mi nebrani v tom GUI cely NM vypnout/nenechat klidne i jen jedno rozhrani NM spravovat a udelat to bokem rucne dle libosti. Za posledni tri roky jsem to udelal... mozna jednou?

resolv.conf je obcas prepsanej i dhcp klientem (IIRC)

29. 12. 2022, 18:30 editováno autorem komentáře

Mam-li si vybrat predvidatelny system se SysV initem, nebo neco co mi prepisuje konfiguraky, tak volim radsi neco na zpusob toho SysV initu, protoze udrzet to funkcni mne myslim bude stat mene casu.
systemd je mnohem předvídatelnější, než SysVinit. A přepisování konfiguráků dělají distribuce odjakživa. Třeba když jste uměl nakonfigurovat síť (tehdy ještě) pomocí ifconfig nebo později ip, nakonfigurovat firewall pomocí iptables nebo dříve ipchains, bylo vám to ve většině distribucí k ničemu, protože konfigurovaly síť vlastními skripty z vlastních konfiguračních souborů. Nadával jste tehdy na to, že je to špatně a nerozumíte tomu – nebo jste se prostě naučil používat ty distribuční konfigurační soubory?

To jak distribuce prepisuji/generuji konfiguracni soubory mi prijde jednoduse uplne spatne.

Moje cesta byla tehdy primet nejak distribuci, aby mi moc nekladla prekazky a upravit si to k obrazu svemu v necem *typu* rc.local :). A nenadaval jsem, ani jsem myslim do nikoho neprojikoval odstepene casti sveho JA ;).

Mate ze mne radost, ze?

To jak distribuce prepisuji/generuji konfiguracni soubory mi prijde jednoduse uplne spatne.
Za prvé, když musíte znásilňovat nějaký nástroj k obrazu svému, měl byste přemýšlet o tom, zda používáte správný nástroj a zda ho používáte správně. Případy, kdy opravdu není jiná možnost, jsou výjimečné. Častější je, že si tím přiděláte práci.

Za druhé si tím budete práce přidělávat čím dál víc, protože software je čím dál komplexnější, aby pokryl čím dál víc situací. Na úrovni předem připravené konfigurace se to řeší tak, aby nejčastější případy byly stále stejně jednoduché – ale když si to předěláte po svém, komplikujete si to, a komplikujete si to čím dál víc.

Za třetí, když jste nenadával tenkrát, proč na to samé dnes nadáváte?

No, možná ani sám Lennart by s vámi nesouhlasil, protože sám mluvíl o větší unifikaci a integraci ekosystému.

To, že RedHat protlačil systemd silou není nic jiného, než konspirační teorie

To není pravda. Argumentovalo se Red Hatem jako hlavním příspěvatelem do jádra a "vlakem který ujede" těm, kdo zůstanou bez systemd. Prvním takovým je Gnome (možná navždy jediným), které jednu službu ze systemd prostě vyžaduje.

Velké monolity mají prostě své výhody i nevýhody, názor může mít někdo i nesprávný, ale stavět to do roviny "prostě hloupé nenávisti" (Surý) nebo "konspiračních teorií" (Jirsák) je laciné.

5. 1. 2023, 16:26 editováno autorem komentáře

Gnome vyžaduje login manager, v princípe je mu jedno aký. Pôvodne fungoval s ConsoleKit2, ale ten skončil ako roky neudržiavaný. Kedže desktopové prostredie potrebuje niečo udržiavané a iba systemd sa obťažoval so systemd-login, tak určitú chvíľu bol systemd vyžadovaný. Neskôr vznikol elogind (vypreparovaním systemd-login zo systemd) a ten vyhovuje tiež.

Takže Gnome urobil všetko správne -- podporoval modulárne riešenie. Akurát alternatívy neexistovali, pretože niektorí len kričia, ale ruku k dielu nepriložia.

@ja.

Dát si jako závislost jeden modul z nějakého jednoho správce není modulární řešení. Modulární řešení je nabídnout rozhraní. <example>Asi jako byste si místo Interface vybrali jednu z implementací a řekl, že Interface prostě nebylo. Možná nebylo, ale zaměnitelné už to není.</example>

DISCLAIMER: Jaký je přesně stav nyní nevím, protože jsem Gnome opustil z úplně jiných důvodů.

Gnome roky upozorňoval na to, že ConsoleKit je neudržiavaný. Každý na to zvysoka.

Takže použili jedinú možnosť ktorú mali. Pokiaľ sa vám to nepáči, mali ste prispieť k údržbe ConsoleKitu.

Pokiaľ sa vám to nepáči, mali ste prispieť k údržbe ConsoleKitu.

No jasně, celý internet opravím, škoda že mi nezavolali ...

Asi jste si to spletl. Já nekritizuji to rozhnodnutí. Pouze říkám, že to tak je. To se snad ještě může ne?

Asi jste si to spletl. Já nekritizuji to rozhnodnutí. Pouze říkám, že to tak je. To se snad ještě může ne?
Akorát z toho vyvozujete nesmysly. Neplyne z toho ani že je systemd monolit nebo velký balík. Neplyne z toho ani že je systemd nějak skrytě protlačován. systemd prostě nabídl nějakou službu, která se Gnome hodí, tak ji Gnome využilo. Co je na tom špatně? Pokud se někomu nelíbí systemd, ať naprogramuje alternativu té služby. Ale těžko to můžete chtít po autorech systemd (ti už tu službu jednou naprogramovali) nebo po autorech Gnome (ti se rozhodli použít externí službu, aby to nemuseli programovat sami).

Argumentovalo se Red Hatem jako hlavním příspěvatelem do jádra a "vlakem který ujede" těm, kdo zůstanou bez systemd.
Ne, neargumentovalo. Argumentovalo se maximálně tím, že vlak ujede těm, kteří zůstanou bez moderních řešení.

Prvním takovým je Gnome (možná navždy jediným), které jednu službu ze systemd prostě vyžaduje.
Ne, Gnome vyžaduje určitý typ služby. Že ten typ služby v určitém okamžiku poskytovalo jen systemd, protože starší alternativy se nerozvíjely a nikdo jiný to tenkrát ještě neimplementoval. To ale jaksi není problém systemd.

Velké monolity mají prostě své výhody i nevýhody, názor může mít někdo i nesprávný, ale stavět to do roviny "prostě hloupé nenávisti" (Surý) nebo "konspiračních teorií" (Jirsák) je laciné.
Systemd není monolit. Když to naplňuje znaky konspirační teorie, jak jinak to chcete nazývat?

@Filip Jirsák

Jak? Nemáte to "nazývat" různými posměšnými připodobněními, ale argumentovat.

Argumentovalo se maximálně tím, že vlak ujede těm, kteří zůstanou bez moderních řešení.

Ano, jenom jste z toho vynechal toho největšího přispěvatele o kterém se mluvilo - Red Hat. Já jim to neberu. Prostě se o tom hodně mluvilo.

Že ten typ služby v určitém okamžiku poskytovalo jen systemd, protože starší alternativy se nerozvíjely

Ano - a tím že místo rozhraní požadovali specifickou službu, tak si přitáhli závislost. To se často stává, když vyvýjíte projekt uvnitř nějakého jiného projektu, ne striktně odděleně.

No jo no ... ale dobře, monolit je možná přehnané, v Gentoo to nazývají velký balík (jednotné číslo).

This article contains a (possibly partial) list of packages in Gentoo's repository that unconditionally require systemd, i.e. that unconditionally list sys-apps/systemd in one or more of the corresponding ebuild's xDEPEND variables, thereby making systemd a 'hard dependency'.

https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd

6. 1. 2023, 23:45 editováno autorem komentáře

Nemáte to "nazývat" různými posměšnými připodobněními, ale argumentovat.
Tak si ten komentář přečtěte ještě jednou. Já jsem tam popsal znaky, které to vykazuje, a pak jsem to jen uzavřel tím, že věci, které mají tyhle znaky, nazýváme konspirační teorií.

Prostě se o tom hodně mluvilo.
Akorát že se nemluvilo o tom, že kdo nebude používat systemd, tomu ujede vlak. Mluvilo se o tom, že vlak ujede tomu, kdo bude používat zastaralé a nevhodné nástroje.

Ano - a tím že místo rozhraní požadovali specifickou službu, tak si přitáhli závislost.
Nesmysl. Oni požadovali rozhraní – jenomže to rozhraní v tu dobu reálně implementovala jen komponenta systemd.

No jo no ... ale dobře, monolit je možná přehnané, v Gentoo to nazývají velký balík (jednotné číslo).
To, že mají v Gentoo špatně zabalený systemd jako jeden velký balík, je problém Gentoo, ne systemd.

pak jsem to jen uzavřel tím, že věci, které mají tyhle znaky, nazýváme konspirační teorií

... a to je právě to, co jste si měl odpustit. To do argumentace nepatří.

... a to je právě to, co jste si měl odpustit. To do argumentace nepatří.
Ale samozřejmě že to do argumentace patří. Když napíšu, že je něco pravidelné trojrozměrné těleso, které má šest stěn, které mají podobu stejných čtverců, je správné pak dodat, že takové těleso bývá zvykem nazývat krychlí.