systemd 216 (diskuse)

[Hans1024]

Tak uzavirame sazky... hodi to aspon 100 komentaru?

[lucky]

Tak to, ze to je prerostla chobotnice (daleko nad svoji puvodni myslenku), snad kazdy vi a netreba se o tom hadat.

[mankind_boost]

Toto je stý komentář

[ES]

260 to neni zly, systemd nikdy nesklame

[skunkOS]

Jaký je vlastně rekord v systemd-related článku?

[Ruža Becelin]

Ono by to sto komentaru nehodilo, kdyby lidi reagovali primarne obsah zpravicky (vysel systemd 216) misto obecneho napadani systemd jako celku.

[mankind_boost]

No asi k tomu mají důvod. Kdyby byl tak super, tak nikdo ani necekne...

[Petr Ježek]

V Archu start rychý jako blesk.

[lnykryn]

No zase kdo tu na systemd nadava :D Na jinych urovnich to vypada jinak, bavil jsem se s architektem z automotive prumyslu a tam je systemd must polozka a dal se o tom nediskutuje.

[lucky]

Koukam, ze systemd chybi vzdy N+1 functionalita. Pockam az to bude umet varit kavu a zacnu premyslet o prechodu...

[j]

Cekam kdy to integruje GUI. Video uz to tusim prehravat umi ...

[Grunt]

• A new component "systemd-firstboot" has been added that queries the most basic systemd information (timezone, hostname, root password) interactively on first boot. Alternatively it may also be used to provision these things offline on OS images installed into directories.

Hmmm…zajímavé.

[R]

Naco to ma byt akoze dobre? Tieto veci predsa urobi instalacny program a nikdy ich netreba pytat od pouzivatela pri boote.

[mankind_boost]

Systemd bude asi nova distribuce. V pristich verzich urcite pridaji instalator a balickovaci system.

[R]

Balickovaci system nebude, vsetko bude nainstalovane.

[mankind_boost]

Jakože začleněné do systemd?

[R]

Ano. Zle som sa vyjadril :D

[zzz]

A nepujde to odinstalovat. A kdyz se o to rucne pokusite, posle to systemd-journal-uploadem avizo do NSA ze na vas ma poslat likvidacni komando.

[lnykryn]

Tohle není pravda, občas uživatel chce reconfigurovat existující systém: http://www.cyberciti.biz/faq/redhat-rhel-centos-fedora-linux-sys-unconfig-command/

[kavol]

co konkrétně není pravda?

- pokud se ohrazuješ proti tomu "nikdy", pak samozřejmě máš pravdu, nicméně pointa myslím byla spíše v tom, že to už umí instalátor (i dodatečně), tedy netřeba další udělátor ... nebo už nahrazujete i anacondu?

[R]

Mnoho distribucii taketo nic nema a nikomu to nechyba.

[----]

to na jeho tvrzení nic nemění; třeba na FreeBSD se dá instalační/konfigurační program pustit i v už nainstalovaném systému.

[Ivan]

I na AIXu je to tak. Dokonce zalohovaci SW vytvari bootovatelne image, ktere spousi ten samy instalator, ktery po bootu "nainstaluje" OS ze zalohy.

PS: po instalaci vlozi AIX jednu radku do /etc/inittab, ta spusti "wizarda" hned pri prvnim bootu. Kdyz tim wizardem projdete, tak on sam sebe vyhodi z inittabu pomoci prikazu rmitab. Takhle si predstavuju, ze by mel Unix fungovat. Mam privialni problem, tak pro nej pouziju uplne primitivni reseni.

[MarSik]

Třeba na OEM instalace nebo šablony. Naklonuje se šablona a první boot se zeptá na základní nastvení.

Trošku problém vidím v tom, že na tohle má Fedora už dva projekty - legacy firstboot a initial-setup, který je součástí instalátoru (sdílí kód a vypadá stejně).

[Václav "Darm" Novák]

Ovšem situace kdy si vytvořím šablonu nastavení a budu ji schopen použít i při přechodu na jiné distro nezní vůbec zle

[Mrkva]

Pokud to distro bude používat stejný init systém...

[PM]

Je tam také systemd-network-manager?

[pavlix]

systemd-networkd

[Jardík]

Nevíte, jak v systemd nastavím povolené množství vody k zalévání zahrádky?

[..]

man systemd-gardening

[kavol]

s/gardening/gardend/

[PM]

Díky.

A jak to koexistuje s network-managerem? Kdo má lepší list?

Napřed se systemd rozleze po linuxu, vyhodí se staré řešení a stane se nepoužitelným pro neudržovanost. Pak se hoši ze systemd rozhodnou, že už mohou udělat vlastní SystemD distribuci resp. SystemD OS. A ostatní linuxové distribuce, které přešly na systemd, půjdou do kytek.

[pavlix]

A jak to koexistuje s network-managerem?

Bavil jsem se o tom s nimi na flocku a jejich představa je taková, že si uživatel mezi systemd-networkd a NetworkManagerem vybere, co mu vyhovuje a nebude mít spuštěné obojí zároveň. Pokud se toto dodrží, tak NetworkManager a systemd koexistují vcelku dobře.

[Bedňa]

Takže ťa platia zbytočne za niečo čo už v systemd je :)

Tak a vážne, sieťarina na low level mi príde ako veľmi zložitá vec a ľudí čo do toho skutočne vidia je ako šafránu. Takéto trieštenie síl v rámci jednej firmy beriem ako zlé rozhodnutie. Je to len o tom že nechcete prijať ako sufix systemd? Nevidím v tom zmysel.

[pavlix]

Takže ťa platia zbytočne za niečo čo už v systemd je :)

Nikoliv.

Takéto trieštenie síl v rámci jednej firmy beriem ako zlé rozhodnutie.

Bez komentáře :).

Je to len o tom že nechcete prijať ako sufix systemd?

Otázka nedává smysl.

[Bedňa]

Len sa čudujem, že pokiaľ niečo nechce splynúť so systemd, tak si napíšu svoje vlastné zbytočné riešenie. Je otázkou času kedy zmizne možnosť užívateľovi nejakej voľby.

[Václav "Darm" Novák]

Co jsem koukal naposledy, byl networkd doporučený spíš pro řešení statické konfigurace třeba na serveru, na dynamickou interaktivní konfiguraci třeba při častém přecházení třeba s laptopem doporučovali networkmanager.

[SPM]

... na statickou konfiguraci, na kterou mi teď stačí jeden konfigurák podle kterýho se to po startu nastaví a nemusí na to běžet extra démon? :)

[Václav "Darm" Novák]

Ten démon je dost lightweight a co jsem koukal, docela mocný s přehlednou konfigurací Navíc aspoň sjednotí konfiguraci sítě.

[j]

Jiste, dalsi vec co se rozjebne a nenastartuje kvuli ni system.

[pavlix]

Spíš naopak. Teď už nehrozí, že se kvůli rozjebané síti nenastartuje systém. Ale to platí i pro network démony v kombinaci se systemd obecně.

[xxl]

Jak tady píše kolega, na statickou konfiguraci mi stačí jeden soubor a případně si umím napsat vlastní script, který nastavení provede. Každopádně po nastavení už nechci, aby se na to sahalo, ale aby to zůstalo tak, jak je. Když mi tam poběží démon, který může potenciálně nastavení měnit, budu poněkud nervózní.

[Václav "Darm" Novák]

Proč by měl nastavení měnit? Šance je asi stejná, jako když ti update systému přepíše konfigurák. Navíc by si, vzhledem k tomu že je to démon, mohl poradit i s pádem wifi AP a tak…

[pta]

Šance je asi stejná, jako když ti update systému přepíše konfigurák.

To neni. Nektere balickovaci systemy to nedovoli a zalohu souboru ulozi pod jinym volnym nazvem (napr. priponou pacsave).

Zere navic systemove zdroje, anz to je potreba. Jestli malo nebo hodne je relativni, jde o pristup. S takovym mas ze systemu jeden velky zapleveleny bordel.

Obnovu wifi pripojeni zvlada wpa_supplicant, nevim proc suplovat jeho funkcionalitu v jinem demonu, zvlast u pocitacu pripojenych kabelem

[j]

Proc by proboha melo jinak bezet v pameti neco, co nic nedela? Jinak sit nakonfiguruju asi tak na 3 radky, vazne nevim proc by mi kvuli tomu melo neco zrat par MB ram.

[Václav "Darm" Novák]

Může někdo používající networkd potvrdit těch pár MB RAM?

[SPM]

Ono je jedno, jestli je to pár MB nebo pár kB. Prostě tam běží pro server naprosto zbytečný proces...

[pavlix]

Zbytečné věci je nejlepší mít v kernelu, pak to není vidět mezi userspace procesy.

[j]

Pokud dobre koukam, tak celej init na gentoo mi papka neco kolem 2-4MB ... systemd vedle neco kolem 30ti a vic. Jop, ja vim, poridim si dalsi gigo ramky ... abych moh provozovat systemd.

[Václav "Darm" Novák]

Byl by výpis? Já se dopočítal cca 4MB systemd procesů.

[marbu]

Treba u mne systemd zabira zhruba 7MB (x86_64 fedora 20) - ale pocitam jen samotny systemd proces (pid 1).

[kavol]

pomineme-li, že tato metodika je tak trochu na pytel, neboť nepočítá to, co systemd k běhu potřebuje (a co by jinak v paměti nemuselo být, takže argument z minulé diskuse, že to stejně na systému mám, je nesmysl, to se týká nanejvýše pár mega glibc, ale který jiný program například potřebuje načíst libsystemd-daemon.so.0.0.10?), tak aktuální data u mě:

# rpm -q systemd
systemd-208-21.fc20.x86_64
# ps -p 1 -o vsz,size,rss
   VSZ  SIZE   RSS
 51028  3724  8352
# pmap 1
1:   /usr/lib/systemd/systemd --switched-root --system --deserialize 23
...
 total            51028K

# equery l openrc
 * Searching for openrc ...
[IP-] [  ] sys-apps/openrc-0.12.4:0
# ps -p 1 -o vsz,size,rss
   VSZ  SIZE   RSS
  4216   308   560
# pmap 1
1:   init [3]
...
 total             4216K

(a to je ještě OpenRC umí hezky odswapovat, při minulém pokusu mi vyšlo RSS jen 80 KB)

p.s. prodám Freerunner ... má krásných 128 MB paměti, nabootuje-li se systemd, půjde tam spustit ještě jeden stejně velký program

[pavlix]

p.s. prodám Freerunner ... má krásných 128 MB paměti, nabootuje-li se systemd, půjde tam spustit ještě jeden stejně velký program

Prodám dva.

[..]

# ps -p 1 -o vsz,size,rss
   VSZ  SIZE   RSS
   108    92    20
# pmap 1
1:   runit
...
 total      104K

Už se těším na systemd.

[pavlix]

Co jsem koukal naposledy, byl networkd doporučený spíš pro řešení statické konfigurace třeba na serveru

V té době nejspíš nic jiného ani neuměl, tak nemohl být k ničemu jinému doporučován. Ani teď toho neumí o moc víc, je to prostě projekt v úplných začátcích. Je potřeba rozlišovat, zda se bavíš o současném stavu nebo o dlouhodobém plánu.

[Václav "Darm" Novák]

Máš k tomu nějaké tl;dr info? Jestli přidají funkce a bude to pořád tak krásně přehledné, budu rád

[pavlix]

Tak předpovídat budoucnost neumím vím jenom to, co na sebe sami prásknou na akcích. Ale rád bych o tom trochu popovídal na LinuxDays.

[skunkOS]

Přesně tak, na nějaké to získání síťových nastavení pro klienta z DHCP je to ideální. Zapnul jsem si u toho i ten jejich timesyncd a běží to moc pěkně. NTPD a DHCPD odinstalovano.

[Petr Ježek]

Nikoli Arch.

[Ruža Becelin]

* A new tool systemd-journal-upload has been added to push journal data to a remote system running systemd-journal-remote.

Ma to nejaky vyznam oproti reseni rsyslog si vezme info z journald a posle je evt. dal pres tcp/udp 514?

[rADOn]

Divas se na to spatne. K cemu je ted syslog? Samozrejme ze k nicemu, takze v dalsi verzi systemd bude vytahovani zprav mimo journald zruseno.

[Ruža Becelin]

Zrusit to technicky nejde, vzdycky tam bude byt parser/proxy, co to bude zachytavat a preposilat...

[pta]

No jo, ale kdo to napise a bude se s tim udrzovat ? Technicky neni problem spousta veci, ale ta praxe ..

[Václav "Darm" Novák]

V situaci kdy spousta distribucí přechází na systemd a příznivců syslogu je stále hodně? Fakt se nebojím, že se toho někdo neujme.

[Ruža Becelin]

Napr. autori rsyslogu udelali parser na journald a i kdyby ne - systemd/journald je OSS, tak se staci podivat, co z toho leze a napsat kod, co to prezvyka a nekam ulozi/posle...

[michich]

Zbyszek k tomu má relevantní Fedora feature page: http://fedoraproject.org/wiki/Changes/Remote_Journal_Logging

[Ruža Becelin]

Jo, vidim, berou to jako alternativni cestu pro ty, co nechteji syslog. Fajn, proc ne.

Informace se neztrati tak jako tak, posledni rsyslog umi parsovat journald

[j]

jj, takze kdyz si na ponicenym systemu budes chtit precist logy, budes muset nejdriv nekde vedle naisntalovat jinej system, abys ty logy byl schopej vubec prekonvertovat do citelny podoby ... tomu se rika pokrok ... mno proste jako na widlich, jejich logy bez bezicich widli taky neprectes.

[JS1]

Ve sve zaslepenosti proti systemd resis hlouposti. Pokud uz mas na systemu systemd, da se predpokladat, ze ho mas i na flashce. Jinak zadne logy si neprectes bez operacniho systemu.

[mankind_boost]

Jenze plaintext si prectu na jakemkoliv systemu, proste naprosto kdekoliv. Treba i na windows. Se systemd ma clovek smulu, je to takovej malej vendor lock-in

[kavol]

no, co když mám právě jednu flashku s tím systémem, kterej se sesypal, zatímco na počítači mám něco jinýho? - mám si běžet koupit další flashku?

kde jsi vůbec ten předpoklad vzal, že to tak máš ty, tak to tak musí mít každej?

[JS1]

Pak jsi hlupak, pokud tam mas neco mission critical. Je to teoreticky argument, ktery nema v praxi zadnou vahu. Ext4 (kde jsou ty logy, trebas v plaintextu) si taky neprectu ve Windows..

Nejsem admin, ale predpokladam, ze kazdy admin ma alespon jeden zalozni system (treba na flashce), kde jsou vsechny potrebne nastroje pro obnovu systemu.

[mankind_boost]

"Ext4 (kde jsou ty logy, trebas v plaintextu) si taky neprectu ve Windows.. "
Proč?

[kavol]

Pak jsi hlupak, pokud tam mas neco mission critical.

hm, a předpoklad, že je tam něco "mission critical", se vzal kde?

a pokud to mission critical není, proč o tom vůbec mluvíš, a proč hned vytahuješ nadávky?

Je to teoreticky argument, ktery nema v praxi zadnou vahu.

nejsi-li admin a jen "předpokládáš", jak můžeš takto hodnotit nějakou praxi?

Ext4 (kde jsou ty logy, trebas v plaintextu) si taky neprectu ve Windows..

měl bych stejný dotaz jako kolega ...

Nejsem admin, ale predpokladam, ze kazdy admin ma alespon jeden zalozni system (treba na flashce), kde jsou vsechny potrebne nastroje pro obnovu systemu.

to je něco jako "nejsem řidič, ale předpokládám, že každý řidič má u sebe vždy alespoň jedno záložní auto, kterým to porouchané odveze do servisu"?

[pavlix]

Zajímavé ale je, že ač sám píše, že není admin, tak má naprostou pravdu. Live systém člověka nic nestojí a ve chvíli, kdy se něco posere, šetří čas i práci. Nehledě na to, že každý admin live systém k dispozici má, za předpokladu že má bootovatelné medium a přístup k internetu.

[Honza Jaroš]

...a fyzický přístup k mašině. Přes síťové KVM nebo přes iLo to je horší (ano, někde jde použít virtuální médium po síti, ale třeba u iLo na to je potřeba plná licence), zrovna nedávno jsem takhle jeden počítač v zamčeném baráku na druhém konci města oživoval přes busybox spuštěný přes parametr init=...

[pavlix]

Oživovat stroje bez fyzického přístupu mě nebaví.

[Honza Jaroš]

No a...?

[pavlix]

No a tak to nedělám a nechám ten stroj mrtvý, dokud mi není fyzický přístup umožněn. Pokud je motivace ten stroj oživit, je mi to umožněno velmi rychle.

[Honza Jaroš]

Tak to holt nedělejte, je to váš boj.

Ale na to jsem se neptal. Jestli to chcete formulovat srozumitelněji, zajímá mě, jakou to má souvislost s předchozí diskusí, konkrétně s kavolovým #88 a vaším #98.

[pavlix]

Popravdě se v tomhle vlákně už ztrácím a nechytám souvislost, proč hledáš ty souvislosti :).

[Honza Jaroš]

Vždyť je tu takový hezký stromeček od #88 až tomuhle příspěvku.

Vy jste napsal, že (obecně) admin může kdykoli nastartovat z live CD/USB. Já poukázal na celkem standardní příklad užití, kdy to neplatí. Vy jste na to kontroval stylem

Oživovat stroje bez fyzického přístupu mě nebaví. ... No a tak to nedělám a nechám ten stroj mrtvý, dokud mi není fyzický přístup umožněn. Pokud je motivace ten stroj oživit, je mi to umožněno velmi rychle.

Ale to že vy nemáte rád DRAC & spol. přece neznamená, že ho nepoužívají i jiný (kupříkladu já nebo kavol nebo j). A kupodivu můj čas jsou i moje peníze. Jestli váš #102 a #107 neměl být vyjádřením postoje já to nepoužívám a vy si trhněte nohou, tak se omlouvám za nepochopení. Ale v tom případě mi fakt uniká, co jste tím chtěl říct, protože na mou a kavolovu obecnou připomínku jste odpověděl něčím, co mi připadalo spíš jak trolování (slovo připadalo zdůrazňuji)...

[mankind_boost]

Takže zábava je důležitější než robustnost a odolnost?

[pavlix]

Vzhledem k tomu, že zajištění prostředků pro obnovení komponenty lze brát jakou nutnou podmínku pro robustnost a odolnost celého systému, si dokáže každý odpovědět sám. Když je majitel debil, tak si prostě připlatí, tak to chodí.

[mankind_boost]

Abych si to ujasnil. Mám dvě situace:
A) Mám syslog, což je robustnější logger (protože plaintext). Pravděpodobnost nutnosti použití těch tvých "prostředků pro obnovení" je menší (ale nenulová).
B) Mám journald, což je méně robustní logger (protože má spoustu bugů rozbíjející logy, který vývojáři explicitně odmítají řešit; už z principu je binární log náchylnější). Pravděpodobnost nutnosti použití těch tvých "prostředků pro obnovení" je vyšší.

Proč bych si proboha volil možnost B?!

[Jendа]

Protože neposuzuješ jenom robustnost.

[mankind_boost]

Třeba máte jiné priority, beru. Pro mě je spolehlivost velmi důležitá. Pro někoho možná ne.

[Václav "Darm" Novák]

Ono je to nějak nespolehlivé?

[mankind_boost]

Musím sem znovu postovat ty odkazy na dva z bambilionu bugů journald náhodně rozbíjejících celé nebo alespoň velké části logů (které mimochodem Lennart odmítl řešit s tím, že "to není třeba")? Opravdu znovu?

[Václav "Darm" Novák]

Nezálohovat logy, ideálně na nějaký centrální server, považuji za chybu. Čekal jsem spíš něco o rozbitém initu.

[mankind_boost]

"Čekal jsem spíš něco o rozbitém initu. "
O initu se tu nikdo (alespoň v tomhle podvlákně) nebaví. Řešíme syslog vs. journald. Člověk by čekal, že když už se angažuješ v nějaké diskuzi, tak že si jí aspoň přečteš. Pokud tedy není tvým cílem jen trollovat.

"Nezálohovat logy, ideálně na nějaký centrální server,"
No tak si u toho můžeš projít ten další bambilion bugů. To si teda pomůžeš.

[Václav "Darm" Novák]

Četl, ale zbloudil z vláken „k čemu je vlastně systemd dobrý.“ Mea culpa.

[Václav "Darm" Novák]

Přehlednější správa služeb a psaní nových, cgroups…

[mankind_boost]

A to by u plaintextu nešlo?

[Václav "Darm" Novák]

Existuje nějaký init systém ve kterém by to bylo tak snadné, přehledné a efektivní?

[Václav "Darm" Novák]

Nebo mluvíš o plaintext logu? No, tak systemd nemá plaintext logy. Pro mě má hodně výhod, které tu spekulativní nevýhodu poráží.

[Honza Jaroš]

Bavíte se o initu, nebo o loggeru. Já stále tyto dvě věci odděluji, i když jsem si všiml, že zastáncům systemd to začíná splývat. Což nechápu...

[Václav "Darm" Novák]

Protože volbou A zavrhl i zbytek řešení B. Stejně počítám s tím, že někdo dřív či později napíše textový logger pro systemd.

[mankind_boost]

"Protože volbou A zavrhl i zbytek řešení B."

Nezavrhl. Syslog můžeš používat i v systemd.

[Václav "Darm" Novák]

Trochu jsem se ztratil v diskuzi, vláknech kde Kavol řešil že systém se systemd neopraví, protože se nedostane k logu (a tak trochu jsem zvyklý na kompletní hate systemd na základě jedné komponenty). Sorry.

Jinak osobně použití syslogu už beru jako nouzovku

[pavlix]

V tom se zastánci a odpůrci asi moc neliší.

[Honza Jaroš]

Pokud vím, odpůrce štve, že jim systemd nutí i journald a proto proti němu prskají. Pokud by se systemd nesnažil sežrat půlku linuxového ekosystemu a učinit ho nekompatibilním s dosavadními nástroji, byl by jim systemd u řiti, protože by to byl jen další z řady initů.

Naproti tomu jejich loggery provázané s initem nejsou.

[mankind_boost]

+1

[pavlix]

Pokud vím, odpůrce štve, že jim systemd nutí i journald a proto proti němu prskají.

Nejsem si vědom toho, že by existoval nějaký jednotný myšlenkový proud. Donedávna se dokonce místo slova odpůrci často objevovalo slovo kritici. Sám se za odpůrce nepovažuju, protože mi přijde debilní odporovat kusu software, zato za kritika se považuju, vzhledem k tomu, že daný software často kritizuju.

Jinak mi přijde, že journald je značně odlišná příšera od systemd samotného a na to ukazuje i to, že mnoho lidí vyhovuje systemd a nelíbí se jim journald a stejně tak mnoho lidí nemá rádo systemd a přitom je journald svým způsobem okouzlilo.

Pokud by se systemd nesnažil sežrat půlku linuxového ekosystemu a učinit ho nekompatibilním s dosavadními nástroji, byl by jim systemd u řiti, protože by to byl jen další z řady initů.

Především by jim byl u řiti, pokud by se neujal.

[Honza Jaroš]

Nejsem si vědom toho, že by existoval nějaký jednotný myšlenkový proud. Donedávna se dokonce místo slova odpůrci často objevovalo slovo kritici.

Kritici je určitě lepší slovo, než které jsem použil já. Každopádně v diskusích sleduju ne jednotný myšlenkový proud, jako spíš grupu lidí nasraných z toho, že je jim nuceno něco co nechtějí - a že bez toho něčeho přestávají fungovat i věci, které do té doby fungovaly (viz. např. Gnome). Jak jsem na Ábíčku psal už několikrát, podle mého názoru spoustě lidí vyhovoval Linux i proto, že to byla skládačka, ve které byly jednotlivé komponenty zaměnitelné podle okamžité potřeby. Systemd a na něj navázané projekty tohle boří.

Jinak mi přijde, že journald je značně odlišná příšera od systemd samotného

Myslím, že kdyby jedno bylo schopné fungovat bez druhého a opačně, bylo by mnohem méně zlé krve. A netýká se to jen journald.

Především by jim byl u řiti, pokud by se neujal.

Tak to jde jedno s druhým, ne?

Já nepopírám, že je spousta lidí, kterým systemd & spol. vyhovuje. Mně vadí, že ostatní najednou zjistili, že jsou postaveni před hotovou věc a ovlivňuje to čím dál víc systémových komponent. Ale jak jsem tu už někde psal, jsem si vědom, že jak to tak vypadá, taháme za kratší konec lana. Na druhou stranu se nedivím, že v takové situaci někteří alespoň ječí.

[pavlix]

jako spíš grupu lidí nasraných z toho, že je jim nuceno něco co nechtějí

V tomhle smyslu jsem taky nasraný, ale na druhou stranu život jde dál a člověk se chce taky někam posunout, ne se jenom topit v problému, se kterým stejně nemůže nic moc dělat.

které do té doby fungovaly (viz. např. Gnome).

Od dob Gnome 3 považuju vyjádření, která obsahují fungovat a Gnome za oxymorón.

Jak jsem na Ábíčku psal už několikrát, podle mého názoru spoustě lidí vyhovoval Linux i proto, že to byla skládačka, ve které byly jednotlivé komponenty zaměnitelné podle okamžité potřeby.

Patřím mezi ně.

Systemd a na něj navázané projekty tohle boří.

Narušovaly to i jiné projekty. Ta skládačka je takový ideál, který nikdy není stoprocentní, ale je fakt, že systemd ho kazí v relativně zbytečných případech a dělá z Linuxu spíše něco jako BSD, tedy základní společně spravovaný systém.

Myslím, že kdyby jedno bylo schopné fungovat bez druhého a opačně, bylo by mnohem méně zlé krve.

Osobně chápu, že je to pro vývojáře systemd značně nepraktické a neexistuje nic, co by je k takovému přístupu motivovalo. Neříkám, že mě to těší, ale jinak to nebude.

Mně vadí, že ostatní najednou zjistili, že jsou postaveni před hotovou věc

Pokud byl v posledních dvou letech někdo postaven před hotovou věc, tak si za to může sám.

Ale jak jsem tu už někde psal, jsem si vědom, že jak to tak vypadá, taháme za kratší konec lana.

Začínám teprve rozumět významu toho, co jsi napsal. Ale nejenom, že taháme za kratší konec lana, ale ještě ho rveme každý trochu jiným směrem.

Na druhou stranu se nedivím, že v takové situaci někteří alespoň ječí.

Možná se taky nedivím, ale je to úplně zbytečné a dokonce bych řekl že je to kontraproduktivní.

[Honza Jaroš]

Pokud byl v posledních dvou letech někdo postaven před hotovou věc, tak si za to může sám.

Tohle mě zajímá - jak jsem to mohl jako nevývojář využívající distribuce, které systemd nepoužívají nebo ještě donedávna nepoužívaly (Gentoo, CentOS, Debian) ovlivnit?

Možná se taky nedivím, ale je to úplně zbytečné a dokonce bych řekl že je to kontraproduktivní.

Jestli je to úplně zbytečné si jistý nejsem. Alespoň pokud nemám úplně zavrhnout koncept veřejného mínění.

[pavlix]

Gentoo

Gentoo se snažilo o nějaký slušný startup systém už předtím a vyvíjel se vcelku pomalu, takže riziko nahrazení něčím progresivnějším tu bylo a poslední dva roky se o tom minimálně vtipkovalo.

CentOS

CentOS vychází z RHELu, který vychází z Fedory. Není třeba více dodávat.

Debian

Debian/Ubuntu s vlastním řešením od Canonicalu taky nebylo bez rizika.

Snad jediné, co člověk nemohl hned čekat je, že se z původního initu, service manageru a náhrady cronu postupem času stane repozitář pro další desítku systémových služeb. V tomhle si možná hraju na pobitevního generála.

Jestli je to úplně zbytečné si jistý nejsem. Alespoň pokud nemám úplně zavrhnout koncept veřejného mínění.

Tak pokud vás (tebe zahrnuju proto, že to zjevně podporuješ) baví pomáhat lennartovi prosadit svou tím, že používáte nadávky a debilní argumenty a on pak může díky vám smést ze stolu i technickou kritiku a nikdo si toho ani nevšimne, tak dělejte jak myslíte. Myslím, že by měl všechny tyhle lidi obejít a osobně jim poděkovat.

[pavlix]

jako nevývojář

Informace jsou dostupné víceméně pro všechny stejně.

[Honza Jaroš]

Pardon, ale stále mi není jasné, co jsem měl jako dělat? Nainstalovat systemd a hlásit bugy? Proč když systemd nechci? Nebo se začít rozšiřovat svoje chabé znalosti céčka a naprogramovat alternativu? Nebo co jako? Pokud vyjádření názoru je k ničemu (ano, souhlasím, že čisté nadávání v diskusích bez relevantních technických argumentů je často kontraproduktivní a sám se tomu snažím vyhýbat), tak co ještě zbývá? Možná pro vás v RedHatu je to jasné, máte to tam z první ruky, ale já jsem jen blbej admin...

[Honza Jaroš]

PS: pokud je odpověďí "uč se systemd", tak na to jsem se neptal. Je mi jasné, že pokud se nestane zázrak, nemine mě to, počítám s tím a jsem s tím smířený, byť mě to sere - ne kvůli tomu, že mi seberou oblíbené hračky a dají mi jiné, ale proto, že to jde proti filozofii, která se mi na Linuxu líbila.

Já ten předchozí příspěvek pochopil tak, že jsem (a další podobně smýšlející) měl možnost nástupu systemd zabránit a ptal jsem se jak.

[pavlix]

PS: pokud je odpověďí "uč se systemd", tak na to jsem se neptal.

Na otázku co mám dělat není pro dospělého a svéprávného člověka v diskuzi odpověď ;).

Já ten předchozí příspěvek pochopil tak, že jsem (a další podobně smýšlející) měl možnost nástupu systemd zabránit a ptal jsem se jak.

Já nevím, jestli jsi měl možnost s dalšími tomu zabránit. Ale jsem si jistý, že jsi měl možnost se o to pokusit a nejsem si jistý, zda jsi ji vůbec využil.

[Honza Jaroš]

Na otázku co mám dělat není pro dospělého a svéprávného člověka v diskuzi odpověď ;).

Aha. Tak to jo. Takže to předtím bylo jen plácání prázdné slámy, protože jinak bych se nezeptal. Dobrá, hlavně že to víme, jak říkával taťka Larkin...

[pavlix]

Nestěžuj si. Většina téhle diskuze je plácání prázdné slámy. Zkus se nad tím trochu zamyslet, a dojde ti, že ptát se mě, co máš dělat, když přišlo systemd, je trochu debilita.

[pavlix]

Pardon, ale stále mi není jasné, co jsem měl jako dělat?

To není můj problém. Já jsem jen reagoval na to, že byl člověk údajně z ničeho nic postaven před hotovou věc.

ano, souhlasím, že čisté nadávání v diskusích bez relevantních technických argumentů je často kontraproduktivní

O ničem jiném jsem ani nepsal.

Možná pro vás v RedHatu je to jasné, máte to tam z první ruky, ale já jsem jen blbej admin...

Máme to úplně stejně z první ruky jako kdokoli jiný, ale to už se tu v diskuzích omílalo milionkrát. Pokud chce člověk z RH vědět něco o aktuálním dění v systemd, zajede si na systemd hackfest, naposledy byl tenhle měsíc v Praze. Pokud chce člověk mimo RH vědět něco o aktuálním dění, kupodivu si zajede na ten stejný systemd hackfest.

ale já jsem jen blbej admin...

Jestli jsi jen blbej admin je jenom tvoje věc. Spousta lidí jsou jen blbí uživatelé, vědí to o sobě, a zcela jim to vyhovuje. Co si pamatuju na microsoftí svět, tak tam se člověk o moc dál než na jen blbýho admina nedostal, v open source kupodivu včetně systemd a podobných věcí je vstupní bariéra natolik nízká, že máš na výběr celou škálu možností od konzumace, přes sledování novinek, hlášení bugů až po aktivní vývoj.

A to nemluvím ani tak o jednotlivých softwarových projektech jako o distribucích, tedy především integračních projektech.

[Honza Jaroš]

To není můj problém. Já jsem jen reagoval na to, že byl člověk údajně z ničeho nic postaven před hotovou věc.

Hmm, v tom případě se asi někde míjíme v chápání toho, co ten druhý napsal. Nechme to být.

[pavlix]

Možná by bylo lepší víc číst a míň předpokládat.

[Honza Jaroš]

Nehledej třísku v oku svého bratra, abys nepřehlédl trám ve svém vlastním...

[j]

Jestli je to úplně zbytečné si jistý nejsem. Alespoň pokud nemám úplně zavrhnout koncept veřejného mínění.

Verejne mineni se projevi, az to nasadej do ostrych dister. Pak nezbyva nez doufat, ze je aspon par velkych (a predevsim platicich) zakazniku posle se sytemd do <>.

Ostatne, ze hlasovani hohama funguje, je videt u M$, tem se taky uz sviraj pulky.

[j]

Především by jim byl u řiti, pokud by se neujal.

Jenze on se neujal, on je vnucovan a to prave metodami "vsechno rozbijem tak, aby to bez toho nefungovalo".

[pavlix]

Nemám důvěru v tvou analýzu situace, především mylnou představu, že je implementace logování hlavním činitelem selhání systému, ale to teď nechme stranou.

Zvolil jsem možnost B z následujících důvodů (podle důležitosti).

1) Je to výchozí volba na systémech, za jejichž vývoj jsem placený.

2) Šetří netriviální množství času. I ten debilní journalctl mi zvládá dodat požadovaná data rychleji, lépe filtrovaná a lépe seřazená než obecné nástroje nad textovými logy.

3) Nesnáším nekonzistentní nesmyslné formáty data a času, jaké je běžné vidět v souborech produkovaných syslogem. Nejvíc mi vyhovuje ISO s jednotkami od největší po nejmenší, ale vyžaduju alespoň jednotný formát, který vždy obsahuje všechny jednotky včetně roku.

4) Vadí mi, když je čas vyjádřený jiným způsobem než zrovna potřebuju. Do toho patří neschopnost vypsat logy v konkrétní časové zóně a v případě logů kernelu neschopnost vypsat logy v lidském čase vůbec.

5) Jsem přesvědčen o tom, že strukturované logy mají smysl.

V celkové bilanci journald řeší věci, které mi na syslogu v každodenním použití vadilo. To jsou holá fakta, tím samozřejmě nepopírám, že může mít své nevýhody.

[mankind_boost]

1) Já to bral spíš jako hypotetickou možnost svobodného výběru bez dalších okolností (jako třeba to zaměstnání)
2) Dobře, to beru. Ale opravdu to řeší až takové množství času, že to vyváží ty nevýhody (jako třeba nespolehlivé logování)?
3) Tohle by šlo vyřešit i u plaintextu.
4) Tohle by šlo vyřešit i u plaintextu.
5) Subjektivní.

Tak asi máme každý jiné priority. Takže bych to asi zabalil, dál se nedostanem. Já mám prostě rád jednoduchost a spolehlivost.

PS:
"především mylnou představu, že je implementace logování hlavním činitelem selhání systému, ale to teď nechme stranou."
? Kdes na to přišel? Nic takového jsem nenapsal a ani zdaleka nenaznačil.

[Václav "Darm" Novák]

No, skoro to u tvých příspěvků zní, že kvůli journald je celý init nespolehlivý

[mankind_boost]

Už asi počtvrté - init tu neřešíme!

[pavlix]

1) Já to bral spíš jako hypotetickou možnost svobodného výběru bez dalších okolností (jako třeba to zaměstnání)

Pak stačí vynechat první bod.

2) Dobře, to beru. Ale opravdu to řeší až takové množství času, že to vyváží ty nevýhody (jako třeba nespolehlivé logování)?

Vzhledem k tomu, že na ty nevýhody vůbec nenarážím a vzhledem k tomu, že mě pomalost přístupu k logům vždy doháněla k šílenství, tak bych řekl, že v mém případě ano.

Navíc zatím journald nepoužívám na žádných kritických systémech. A ve chvíli, kdy budu narážet na problémy, budu je řešit přímo s maintainery dané distribuce a nikoli s divokým upstreamem.

3) Tohle by šlo vyřešit i u plaintextu.

Ano, ale nikdo to u plaintextu řešit nebude, zatímco u binárních logů tento problém z principu neočekávám.

4) Tohle by šlo vyřešit i u plaintextu.

Jen teoreticky. Ve skutečnosti považuju za hlavní výhodu plaintextu to, že člověk logy zobrazuje ve stejném formátu v jakém jsou uložené. Jestliže budu tak jako tak potřebovat nástroj na čtení logů z konverzí data a času do mnou preferovaného formátu a časové zóny, přestávám vnímat rozdíl mezi tím, zda ten nástroj čte logy v textovém nebo binárním formátu. A osobně si nemyslím, že je zápis binárního logu kdovíjak nebezpečný.

5) Subjektivní.

Důvody uvádím především ze subjektivního pohledu, ale věřím, že se v nich mnozí taky najdou.

Kdes na to přišel? Nic takového jsem nenapsal a ani zdaleka nenaznačil.

Měl jsem za to, že dokola opakuješ, že nebude potřeba systém obnovovat, pokud bude mít textové logy.

[mankind_boost]

To beru.

"že nebude potřeba systém obnovovat, pokud bude mít textové logy. "
To jsem nikde nepsal.

[pavlix]

Já mám prostě rád jednoduchost a spolehlivost.

V tom se zcela shodnem, i když já si k tomu ještě přidávám rychlost. Jenom každý tyto vlastnosti požadujeme v trochu jiné podobě.

[Václav "Darm" Novák]

Osobně jsem spíš používal vlastní recovery instalaci debianu přes PXE, ale ve výsledku to vyjde nastejno

[pavlix]

Taky mi nejvíc vyhovuje PXE, ale jednak mi některé servery neuměly gPXE a musel jsem použít přímo pxelinux, což mě vzhledem k různým instalátorům apod úplně nebavilo. Na druhou stranu mi zase jeden cizí stroj odmítal bootovat z USB a vypadalo to, že mu budu muset systém nasmažit na disky přímo.

[kavol]

Zajímavé ale je, že ač sám píše, že není admin, tak má naprostou pravdu.

nemá

admin jsem třeba i já

já žádný záložní systém nemám

ergo "kazdy admin ma alespon jeden zalozni system" neplatí

Q.E.D.

Live systém člověka nic nestojí

médium = nic?

a ve chvíli, kdy se něco posere, šetří čas i práci.

šetří oproti čemu?

- ano, v případě průšvihu je čas na boot rescue určitě kratší než čas na přípravu rescue + boot rescue

ale z dlouhodobého hlediska? ... doma jsem nepotřeboval nabootovat systém z alternativního média asi tak tři roky; za tu dobu vyšlo šest verzí Fedory, tzn. rescue bych šestkrát aktualizoval, což je rozhodně víc práce, než si ho připravit jednou on demand

(no, ve skutečnosti to není tak úplně pravdivý příklad, protože doma používám Gentoo - což by asi bylo ještě horší, neb je to rolling release, nevím, jak často, a popravdě vůbec jakým způsobem, bych měl kontrolovat, zda je rescue ještě stále použitelné s aktuální verzí nainstalovaného systému ...)

Nehledě na to, že každý admin live systém k dispozici má, za předpokladu že má bootovatelné medium a přístup k internetu.

vpodstatě to samé co výše, předpoklad nesplněn

[pavlix]

O adminech, co nemají přístup k internetu a nemůžou pustit stovku za médium se nemám v plánu vůbec bavit.

[mankind_boost]

Ale PROČ? P-R-O-Č?!
Proč, když už máme řešení, které to nepotřebuje? Je to krok zpět.

[pavlix]

Jestli máš řešení, které dokáže oživit zcela libovolný systém bez použití live systému, instalování nového systému nebo vyndavání disků, tak si o něm rád poslechnu. Zní mi to jako černá magie.

[mankind_boost]

Tak většina initrd má možnost spustit shell (většinou ash z busyboxu). V tomhle shellu si můžu přečíst plaintext log naprosto bez problému, zjistit kde přesně je problém (kvůli kterému nemohu nabootovat) a manuálně ho opravit (pohrabat se v konfigurácích, kouknout na binárky a v nejhorším chroot/pivot_root a řešit to přímo). U journald na mě Lennart ukazuje prostředníček.

[JS1]

Tohle casem vyresi busybox s journalctl.. (nebo neco na ten zpusob)

Ale i tak - Pavlix se opravnene ptal, zda to vyresi vsechny problemy. Sotva. Podle me neco adminovat a nemit po ruce aspon jeden zalozni system (jak jsem psal, nemusi byt na flashce), ktery ma aktualni nastroje na obnoveni systemu, znamena koledovat si o problem. Nu, a na takovem systemu bude i journalctl, pokud byl na puvodnim stroji. Pokud jde o situaci, na kterou se ptal Kavol, ze tam tam ten systemd prave nekdo poprve nainstaloval, a nestihl si jeste vytvorit zadnou zalozni instalaci (se systemd), tak predpokladam, ze ho prilis netrapi, proc se to zhroutilo.

[kavol]

se ptal Kavol, ze tam tam ten systemd prave nekdo poprve nainstaloval, a nestihl si jeste vytvorit zadnou zalozni instalaci (se systemd)

nepodsouvej mi nesmysly

[j]

Boze to je demagogie, NIC nevyresi vsechny problemy, ale binarni log je ZNASOBI. Stejne jako kazda jedna komponenta celyho systemd. Vysledek je takovej, ze OS ebz systemd a s system bude mit 10 radu rozdil ve spolehlivosti, protoste proto, ze binarni blob se nekde podela, a nikdo nebude ani vedet kde a proc, protoze i ty logy budou binarka.

A porad tu ty, pavlix a dalsi mamlasove melete neco o placce/flashce a dalsich kravinach, pricemz dotycnej stroj muze klidne bejt na Mesici.

[pavlix]

Co kdybys šel radši nadávat svojí matce a to především za špatné vychování?

[Václav "Darm" Novák]

Stroj na měsíci bude asi řešen jinak. Osobně bych v něm nechal dvě úložiště s OS a v případě nenastartování jednoho bych ho nechal automaticky nahodit systém z druhého. Ta spolehlivost zmenšená o deset řádů je měřená jak? Zohledňuje to i rychlejší obnovení systému díky lepší čitelnosti a snazšímu vyhledávání problémů v logu?

[pavlix]

Ano, to beru. Pokud máš v pořádku staticky linkovaný toolset schopný přečíst logy, tak skutečně dokážeš... přečíst logy. Pokud je ten toolset dostatečně schopný na opravování systému (což je u busyboxu čirá teorie) a udržuješ si zálohu provozuschopného kernelu, tak máš vyhráno.

Moje zkušenost ale říká, že to nefunguje a že potřebuješ ten toolset obohatit o další nástroje a přijde mi daleko jednodušší prostě sesbírat užitečné nástroje a udělat z nich rescue image třeba v podobě initramdisku. Ale to už máš de facto minimalistický live systém vytvořený na míru tvým potřebám. Obecný live systém má tu výhodu, že si ho nerozbiješ.

U journald na mě Lennart ukazuje prostředníček.

To je nesmysl, lennart ti nebrání používat s journald textové logy, pokud je to tvým přáním.

[Jendа]

což je u busyboxu čirá teorie

V busyboxu je vi, takže pokud je důvodem nefunkčnosti chybně nastavený konfigurační soubor (stává se mi), tak se edituje a systém se opraví. Ale jinak kdykoli to jde používám plnohodnotný rescue systém (konkrétně jsem si oblíbil sysresccd).

[pavlix]

V busyboxu je vi

You don't say :).

[j]

Duvodem muze byt spatny init, ten scriptovany pomoci vi opravis, vadny binarni blob systemd stim neopravis.

[kavol]

Pokud je ten toolset dostatečně schopný na opravování systému (což je u busyboxu čirá teorie)

do RHEL5 to nebyla čirá teorie nýbrž plně podporovaná záležitost - sám jsem testoval jednu opravu busyboxu, aby toho byl schopný (konkrétně šlo o selhání rpm appletu při reinstalaci glibc)

[kavol]

Jestli máš řešení, které dokáže oživit zcela libovolný systém

strawman

problém byl definován jako "takze kdyz si na ponicenym systemu budes chtit precist logy"

prosté přečtení si logů != oživení zcela libovolného systému

[pavlix]

Vzhledem k tomu, že se už v diskuzi několikrát objevilo, že admin musí především udržovat službu v běhu a v případě průseru ji znovu zprovoznit a vzhledem k tomu, že je to důvod, proč spolu s dalšími tvrdím, že je možnost použití live systému pro administrátora tak jako tak klíčová, a vzhledem k tomu, že čtení logů není cílem, ale prostředkem, nezbývá mi než konstatovat, že ten problém definuješ od začátku špatně a byl jsi na to několikrát upozorněn.

[kavol]

kecy, kecy

abych ten prostředek mohl využít, musím se k němu nějak dostat - v tu chvíli se stává (dílčím) cílem

jestliže k naprosté většině oprav žádné live nepotřebuju, nevím, proč bych měl ztrácet čas jeho udržováním; pokud jediným tvým prostředkem k dosažení cíle zprovoznění systému je live, budiž, tvoje volba, ale je faul tvrdit, že to tak musí mít každý, a tedy že vlastně není žádná zátěž, když se tu uměle vytvoří problém, který bez toho (live) rozumně řešit nejde, když to (live) stejně každý má

[pavlix]

kecy, kecy

Taky jsem si všiml.

[mankind_boost]

Co takhle reagovat k věci? Ty jsi hroznej demagog.

[pavlix]

Vždyť to máš i s citací. Myslel jsem, že jsi se uklidnil a začal psát inteligentně, ale jestli se vracíš k nadávání, tak pro mě diskuze s tebou jaksi ztrácí smysl, podobně jako nemá moc smysl diskuze s kavolem.

[mankind_boost]

Takže nic? Žádná odpověď? Víš, on toho napsal víc, než jen dvě slova....

"ale jestli se vracíš k nadávání,"
Kdy a kde jsem ti předtím nadával?

[pavlix]

Nenapsal nic nového, na co by tu už odpověď nebyla. A taky už na vás dneska nemám moc čas.

[mankind_boost]

Škoda. Chtěl jsem aspoň odpověď na "Kdy a kde jsem ti předtím nadával?", když už nic jiného.

PS:
"Nenapsal nic nového, na co by tu už odpověď nebyla."
Asi máme každý jinou představu o tom, co je to odpověď.

[pavlix]

Kdyby nebyla ta diskuze plná buď nesouvisejícího nebo opakovaného bordelu, tak bych měl ještě náladu si to pečlivě projít a poodpovídat. Je pravda, že jsem měl z tvých příspěvků od začátku negativní dojem a pak se to značně zlepšilo, takže mě to celkem motivovalo k diskuzi.

[Václav "Darm" Novák]

Vždy se najde situace kdy to člověk potřebuje. Nebo je snad přístup k logu záruka zprovoznění systému? Je dost trapné přijít na místo a zjistit že byla cesta k ničemu, protože jsem nevybavený. Ideální je mít při zásahu u nefunkčního systému po ruce CD (osvědčilo se mini CD) a Flash se záchranným systémem, pro jistotu i USB redukci na připojení HDD k laptopu.

[mankind_boost]

"Nebo je snad přístup k logu záruka zprovoznění systému?"

To jsem někde psal? Kde? Já jen říkám, že plaintext syslog je spolehlivější než náhodně rozbité logy vytvářející journald. Log mi často pomůže zjistit příčinu problému. Rozbitý log je mi na nic. Toť vše. Jen spolehlivější logger a méně spolehlivý logger.

[kavol]

a nemůžou pustit stovku za médium

což mi tak připomíná, neměla mi v kanclu náhodou přistát nějaká slibovaná basa piva na podporu nás socek, co nerady vyhazujou prachy pro nic za nic?

[pavlix]

Jo, párkrát jsem si na tebe vzpomněl, ale možná by bylo nakonec jednodušší, kdybys mi poslal číslo účtu a obvyklou cenu basy piv, abych se mohl ze závazku vyplatit. Jinak se ti piva budu snažit dodat, ale i tak už mi to trvá dlouho.

[kavol]

to bys měl moc jednoduchý :-p

[pavlix]

V tom případě se dál připomínej nebo si to dej do statusu ;).

[pavlix]

Ale flashku ti k tomu přibalovat nebudu, na to ti seru.

[j]

Jedinej blb ses tady leda ty, textovej soubor si prectu i na telefonu bez systemu. Neses admin ale hubu plnou kecu co je pro adminy dobry ... zjevne stejnej idiot jako lenart.

[Sid]

ono to mas troska pomylene kto na kom je zavisly. Ci myslis ze Linux sa niekde vyskytol? Takze na mieste adminov by som pozdvihol level (lebo zjavne kazdy druhy je najchytrejsi na svete a po jednom scripte uz dokazu rozumiet celemu navrhu OS do detailov) a urobil si svoj super mega OS.

[mankind_boost]

"Tak si to udělej sám!" je naprosto dementní argument. To je jako kdybych si koupil notebook, pak zjistil, že je rozbitý a výrobce by mi na to řekl "tak si ho vyrob sám!". Nemusím být slepice, abych poznal zkažené vejce.

Binární logy jsou prostě nevhodné. Něco tak důležitého jako logy musí být čitelné za každých okolností i s nástroji z doby kamenné. A to splňuje jen a pouze plaintext.

[pavlix]

Jsou systémy, které neukládají logy v žádném formátu. Na OpenWRT zcela běžná věc. Je potřeba si zvyknout, že ne všichni mají stejné potřeby a pokud já potřebuju textové logy, musím si je (a) zapnout nebo (b) zvolit systém, kde jsou zapnuté ve výchozí konfiguraci, pokud mi někdo takový systém nabídne. Pokud se nechci na vývoji systémů podílet, nezbyde mi než volit peněženkou.

[mankind_boost]

"Jsou systémy, které neukládají logy v žádném formátu. Na OpenWRT zcela běžná věc."
Že na OpenWRT nejsou logy, tak je třeba rovnou zrušíme, ne? Nebo co jsi tím chtěl říct?

"Je potřeba si zvyknout, že ne všichni mají stejné potřeby a pokud já potřebuju textové logy, musím si je (a) zapnout nebo (b) zvolit systém, kde jsou zapnuté ve výchozí konfiguraci, pokud mi někdo takový systém nabídne. "
Ano, ne všichni mají stejně potřeby. Jsem si ale docela jistý, že pro většinu uživatelů/adminů je nejvyšší prioritou schopnost přečíst si ty logy ať se děje cokoliv. A tohle prostě binární logy nesplňují tak dobře jako plaintext. O tom se snad dohadovat nebudeme. No a o tom to je - plaintext je pro tento problém vhodnější než binární logy systemd.

[Ruža Becelin]

Jsem si ale docela jistý, že pro většinu uživatelů/adminů je nejvyšší prioritou schopnost přečíst si ty logy ať se děje cokoliv.

Pro vetsinu adminu je nejvyssi prioritou uvest system zpet do provozuschopneho stavu, format logu je vedlejsi. Pokud se bavime o log souborech generovanych sluzbami, ty byvaji automaticky preposilane na centralni log servery, a logy vazane na konkretni HW se daji precist zpetne, pokud se v nich vubec nekdo najde, protoze lokalni syslog server casto padne nadrzku jeste predtim, nez dojde k pruseru a v takovem pripade byvaji jedine dostupne logy vypis na konzoli.

[mankind_boost]

"Pro vetsinu adminu je nejvyssi prioritou uvest system zpet do provozuschopneho stavu, format logu je vedlejsi. "
Jenže k tomu, abys fixnul problém, potřebuješ vědět, v čem ten problém vlastně je. A k tomu slouží právě ty logy. No a pokud si je nemohu z nějakého důvodu přečíst, tak to jaksi nezjistím, že?

"protoze lokalni syslog server casto padne nadrzku jeste predtim"
Jenže když padne syslog, tak tam bude maximálně kus zprávy chybět (třeba v půlce slova). Když se podělá journal od systemd, tak je celej log v háji nebo je přinejmenším značná část rozbitá a nečitelná (např. zde a zde)

[Ruža Becelin]

Coz, jak rikam, se muze stat i textoveho logu. Kazdopadne to je bug a mel by byt nahlasen a opraven.

[mankind_boost]

Ne, to se u textového logu opravdu stát nemůže (pokud tedy není chyba v kernelu v IO nebo filesystemu nebo HW chyba disku). Ten se totiž vždy připisuje na konec souboru, víme?

[Ruža Becelin]

(pokud tedy není chyba v kernelu v IO nebo filesystemu nebo HW chyba disku), napr. XFS sveho casu, ze?

Ale jak uz jsem psal - pokud dojde k poskozeni celeho souboru, je to bug.

[mankind_boost]

"(pokud tedy není chyba v kernelu v IO nebo filesystemu nebo HW chyba disku), napr. XFS sveho casu, ze? "
Jenže tomuhle se nejde nijak vyhnout, takže je to argument čistě nulové hodnoty při výběru syslog/journald. Postihuje to syslog, systemd i cokoliv jiného. Rozbití celého (nebo značné části) logu ale postihuje jen systemd, plaintext log se moc rozbít nedá.

"Ale jak uz jsem psal - pokud dojde k poskozeni celeho souboru, je to bug."
Jenže ty bugy tam budou pořád a všude, protože binární logy jsou mnohem *mnohem* složitější (a navíc ze systemd bude timhle tempem vývoje zachvíli gigantická žumpa, což se dost blbě udržuje => další bugy). U syslog mám jistotu, že celej log se mi prostě na 99,99 % nerozsype - protože je to záležitost jen volání write ve smyčce, který jen připojuje bajty na konec souboru.

Na jednoduchej problém jednoduchý řešení. Protože jen jednoduchá implementace může být bezpečná, robustní a stabilní. Koneckonců, na této filosofii byl celý Unix a GNU(/Linux) postavený.

[Ruža Becelin]

Rozbití celého (nebo značné části) logu ale postihuje jen systemd, plaintext log se moc rozbít nedá. Jak jsem napsal, pokud k tomu dojde, je to bug v systemd, k rozbiti binarniho logu by nemelo dojit jenom proto, ze je binarni.

protože binární logy jsou mnohem *mnohem* složitější

Neznam implementaci v systemd, ale nemusi byt pravda, binarni logy muzou byt rychlejsi, presnejsi na kontrolu integrity, indexaci, porovnavani, atd, atd.

[j]

Ale to nikoho nezajima. Logy se pouzivaji ke zjistovani, proc neco nefunguje. Kdyz si budu jistej, ze vsechno bude fungovat, nepotrebuju logy. A poskozenej binarni log se neda precist, narozdil od poskozenyho textaku.

Az budu potrebovat indexovat TB logu, tak si je (ty blbe textaky) budu mozna importovat do nejaky databaze. Ta bude asi tak 100 000x rychlejsi a efektivnejsi, nez nejakej podelanej demon.

[mankind_boost]

No konečně někdo chápe, co jsem tu chtěl říct.

[pavlix]

Tak se poplácejte po ramenou...

[mankind_boost]

Zdá se mi to nebo si to bereš nějak osobně? Docela útočnej tón...

[pavlix]

Zdá, nemám jak bych si to mohl brát osobně. Jen mě fascinuje, jak může člověk, který o sobě tvrdí, že má rád jednoduché věci, reagovat pozitivně na následující...

Az budu potrebovat indexovat TB logu, tak si je (ty blbe textaky) budu mozna importovat do nejaky databaze. Ta bude asi tak 100 000x rychlejsi a efektivnejsi, nez nejakej podelanej demon.

Člověk, který se někdy hrabal v nějakém reálném systému se syslogem tuší, že problémy začínají u relativně malého počtu záznamů a není řeč o žádných terabajtech. Převádět strukturovaná data ztrátově do texťáku, aby se s nimi nedalo rychle pracovat a neobsahovaly původní sadu informací a následně tato data převádět třeba do nějakého obecného databázového systému je řešení poněkud nouzové.

[mankind_boost]

Tak to jsem se špatně vyjádřil, to patřilo k tý první části.

[j]

Viz vejs, pokud padne nadrzku binarni log, tak je celej v hajzlu. Pokud padne na hubu log textovej, tak mozna chybi jeho konec, ale to je tak vse. Jop, uz to vidim jak zivy, jak v hexa editoru opravujes binarni log, aby ho ten uzasnej nastroj nejak prechroupal ...

[Ruža Becelin]

Viz vyse, pokud dochazi k poskozeni celeho logu, je to bug, ktery se ma opravit, popr. maji byt nastroje na jeho opravu. Souborovy system taky bezne neopravuju v hexa editoru. Pokud mi padal na hubu sluzba, mam to na centralnim serveru, pokud cely system, je to na konzoli a popr. v textovem logu, ktery mi system vytvori vedle binarniho.

[lucky]

Bug to sice je, ale podle autoru se opravovat nebude a jedina moznost je tento bug ignorovat :D Ostatne taky reseni ze :D Ten jejich pristup je pro me hlavni duvod, proc se mi u systemd otvira kudla v kapse. Nastesti v *BSD svete nehrozi, aby tam zacal uradovat nejakej Lennart a jeho Melody boys.

[pavlix]

Tak tam budou úřadovat jiní melody boys.

[mankind_boost]

No jako sorry, ale přístup vývojářů ve stylu "they are nothing we really need to fix hence." u náhodně rozbitýho/nečitelnýho logu je naprosto k pláči. Je to smutný, ale z GNU/Linuxu se stávají druhá Windows.

Takže podle Lennarta tam ten bug bude asi napořád, protože rozbíjení logů "přece není potřeba řešit".

[pavlix]

No jako sorry, ale přístup vývojářů ve stylu "they are nothing we really need to fix hence." u náhodně rozbitýho/nečitelnýho logu je naprosto k pláči.

A co já s tím?

Je to smutný, ale z GNU/Linuxu se stávají druhá Windows.

Nic není znovu stejné, žádná druhá Windows už nejspíš nikdy nebudou.

Takže podle Lennarta tam ten bug bude asi napořád, protože rozbíjení logů "přece není potřeba řešit".

Lennart takhle funguje a bohužel není v open source světě zdaleka jediný. Pokud máš nějaký bezva nápad, jak to změnit, jsem jedno velké ucho.

[mankind_boost]

"Pokud máš nějaký bezva nápad, jak to změnit, jsem jedno velké ucho. "
Jeden nápad bych měl: aby vývojáři fixovali své bugy. Zabugovaný nestabilní nespolehlivý software = nepoužitelný software. Já nemám čas ani schopnosti opravovat journald, takže prostě přejdu na jinej software - syslog. Protože se na něj můžu spolehnout. Protože prostě funguje.

[Václav "Darm" Novák]

A co takhle přiznat si, že některé věci prostě ve světě Windows fungují lépe? Třeba správu zvuku ve Windows předehnalo použitelností až PulseAudio (Teď naopak zažívám závist od uživatelů Windows, protože si mohu u každého programu nastavit defaultní výstup a nemůže se mi stát, že mi třeba po připojení HDMI nepůjde zvuk z repráků PC, ale z televize.)

[mankind_boost]

Copak já říkám, že ne? Zrovna PulseAudio je snad jedinej počin od Lennarta, kterej mám fakt rád. Ale trvalo to roky, než se stal vůbec použitelnej.

Narážel jsem na to, že zrovna Windows jsou dosti nespolehlivý software.

[Ruža Becelin]

Aha - no uvidime, jestli se k tomu postavi stejne, az se zacnou ozyvat zakaznici s RHEL7

S cimz zrejme autori pocitaji, protoze v tomu bugu Zbigniew napsal, ze _v soucasnosti_ to lze akorat ignorovat...

Nastesti v *BSD svete nehrozi, aby tam zacal uradovat nejakej Lennart a jeho Melody boys.

Aby ses nedivil, pred par lety v Linuxu taky neuradoval "nejakej Lennart a jeho Melody Boys"

Ono v *BSD prave hrozi, ze si v budoucnu projde tim, cim si prochazi Linux ted: Rust popularity Linuxu s sebou prinesl pozitiva (sirsi podpora HW od vyrobcu, natup Linuxu do firem), jenze s tim prisly i negativa (do vyvoje se pres zamestnavatele zapojuji i lide, kteri by driv nemeli sanci, rozsirovani uzivatelske zakladny "obycejnymi lidmi" = snizovani prumerne inteligence uzivatelu). takze na jednu stranu je fajn, ze Linuxu mi jede bz problemu na novejsim HW bez nutnosti kompilace kdeceho, na druhou stranu se zvysuje riziko, ze se do OS zavlecou veci, ktere driv nikomu nechybely a ted, kdyz se implementuji, tak se na to jde ne uplne dobrym zpusobem.

A *BSD muze dopadnout stejne. To, ze se to nedeje je proto, ze popularita *BSD mezi BFU je nulova.

[mankind_boost]

" Zbigniew napsal, ze _v soucasnosti_ to lze akorat ignorovat... "
To napsal 2013-08-05. A Lennart tam 2014-06-25 (tedy nedavno) napsal, že to není třeba řešit. Ono obecně mi přijde, že Lennart vždycky naprogramuje nějakou supr-čupr fičuru, která všechno rozbije, a ostatní to po něm musí uklízet.

[Ruža Becelin]

On se taky RHEL7 zatim nenasazuje tak masove, jak RHEL6, takze to moc lidi nepali. Az zacne, tak to budou muset spravit, at se jim to libi nebo ne. Do te doby si na Freedesktop muze psat, co chce...

[lnykryn]

V rhelu7 není journald v perzistentním režimu.

[udf]

souhlasim, je to takova analogie evolucniho uteku pred parazity v biologii (paradox cervene kralovny). No co, aspon se porad budou vyvijet nove systemy pro pokrocile uzivatele... dalsi zastavka po BSD muze byt treba minix :)

[lima]

Ono v *BSD prave hrozi, ze si v budoucnu projde tim, cim si prochazi Linux ted: Rust popularity Linuxu s sebou prinesl pozitiva (sirsi podpora HW od vyrobcu, natup Linuxu do firem), jenze s tim prisly i negativa (do vyvoje se pres zamestnavatele zapojuji i lide, kteri by driv nemeli sanci, rozsirovani uzivatelske zakladny "obycejnymi lidmi" = snizovani prumerne inteligence uzivatelu). takze na jednu stranu je fajn, ze Linuxu mi jede bz problemu na novejsim HW bez nutnosti kompilace kdeceho, na druhou stranu se zvysuje riziko, ze se do OS zavlecou veci, ktere driv nikomu nechybely a ted, kdyz se implementuji, tak se na to jde ne uplne dobrym zpusobem.

+1

bohuzel :(

[Jendа]

Viz vyse, pokud dochazi k poskozeni celeho logu, je to bug, ktery se ma opravit, popr. maji byt nastroje na jeho opravu.

Je zde snad nějaká nevyřčená implikace? Aby to nedopadlo stylem pokud se systém rozbíjí, je to bug, ktery se ma opravit, a proto nepotřebujeme rescue systém nebo dokonce logy nejsou potřeba, protože pokud je něco špatně, je to bug, ktery se ma opravit.

Je hezké, že je to bug a má se opravit. Když to ale nastane, tak už se s tím musí něco udělat. A pak komplexní technologie k bugům přímo vybízejí, jako třeba ShitFX.

[Ruža Becelin]

se ma = by mel byt = nekdo by mel

Nic jineho v tom nebylo.

[mankind_boost]

Jóó nějaký "kdyby" ti fakt pomůže, až se ti rozsype systém, a ty nezjistíš, co se děje, protože Lennartovo nextgen ubermegasuper journald píše do logu náhodný bajty. Teorie != skutečnost

[pavlix]

Pro vetsinu adminu je nejvyssi prioritou uvest system zpet do provozuschopneho stavu, format logu je vedlejsi.

+1

Konec konců udržování služeb v provozu je to, za co jsou placení.

[mankind_boost]

Takže znovu:
"Jenže k tomu, abys fixnul problém, potřebuješ vědět, v čem ten problém vlastně je. A k tomu slouží právě ty logy. No a pokud si je nemohu z nějakého důvodu přečíst, tak to jaksi nezjistím, že?"

[Ruža Becelin]

Coz plati i u textovych logu, pokud se mi prepisou nulama nebo zapisou nekam, kde je neprectu. Od toho tu mame preposilani logu na jiny server.

Pokud journalctl ma problem s uzaviranim logu, je to bug na mel byt byt raportovan (coz se predpokladam stalo).

[mankind_boost]

"pokud se mi prepisou nulama"
Citation needed. O tomhle jsem zatím ještě neslyšel, ale možná se pletu.

[Honza Jaroš]

Tipuju to na tu starou chybu XFS, co už je dávno opravená...

[Ruža Becelin]

Presne ta

[mankind_boost]

A vůči ní je journald odolnej? Nebo proč to do toho taháš? Jakej software je odolnej vůči chybě v implementaci filesystému? Nebo to už má systemd v sobě nějakej vlastní filesystém?

[j]

Jezis ty ses taky tupej ... co kdyz se stroj odpoji od site, proste zbuchne sit (a to je se systemd a jeho demonama asi tak o 3-5 radu pravdepodobnejsi nez bez nich) ... ale rozbita sit neni pricinou problemu, ta je nekde v logu. Nasledne stroj zbuchne a uz nenastartuje.

Jiste, tobe tvuj chlebodarce s radosti zaplati letenku pres 1/2 zemekoule aby sis namiste moh pripojit svoje live distro ... a pustit si svuj uzasny tool. Normalni admin se pripoji na HW konzoli, a jde se podivat, co je v logu. V textovym, protoze z ty konzole nic jinyho neprecte.

[Ruža Becelin]

Jiste, tobe tvuj chlebodarce s radosti zaplati letenku pres 1/2 zemekoule aby sis namiste moh pripojit svoje live distro ... a pustit si svuj uzasny tool. Normalni admin se pripoji na HW konzoli, a jde se podivat, co je v logu.

Je fajn v jedne odpovedi poprit sam sebe. Normalni admin si pusti z HW konsole rescue, pokud se bavime o HW konsoli na urovni DRAC, iLO nebo RSA.

[pavlix]

Mst. Spider už výše dodal podle mého názoru uspokojivou odpověď. Nemá smysl se opakovat.

[Václav "Darm" Novák]

A jak ten textovej soubor do mobilu dostaneš, když se ti sesype systém? USB host a SATA adaptér?

[j]

Zebych se pripojil trebas na DRACa? Nebo jinou HW konzoli? To jsou tu vazne takovi tupci kteri jezdej rozbitej SW spravovat tam, kde je HW?

[Honza Jaroš]

Jsou... :-/

[mankind_boost]

A nesel by udelat nejakej jednoduchej wrapper, kterej by to za behu konvertoval do plaintextu? Jen se ptam, systemd nepouzivam.

[JS1]

Na to uz ma systemd journalctl -f

[David Jaša]

Na opravdu poničeným systému si ani ty logy nepřečteš.

[kavol]

co je "opravdu poničený"? - třeba nějaký fuckup při upgrade glibc a tedy (skoro) žádná binárka spustitelná?

sice nevím, jestli by v takové situaci pomohlo číst logy, ale dejme tomu, že ano, tak s init=/sbin/busybox si textové logy přečtu, journal asi fakt ne ...

[j]

Textovej log si prectu v nouzovy konzoli gruba ... binarku si muzu leda strcit.

[pavlix]

To bych nechtěl dělat, navíc k tomu nevidím moc důvod. Pokud k tomu někdo důvod vidí, tak ať textové logy má, zajistit si textové logy je vcelku triviální.

[mankind_boost]

"To bych nechtěl dělat, navíc k tomu nevidím moc důvod."
Vždyť to samo je ten důvod LOL Představ si situaci, kdy se mi totálně p0mrdá systém, že ani pořádně nenabootuje (k tomu stačí třeba i známá "černá obrazovka" u nouveau). Žádnej live systém po ruce nemám. No tak si prostě přečtu plaintext log přes tenhle způsob a vidím, kde je problém. U systemd si můžu leda tak hodit mašli.

Asi jsem žil v omylu, že novější řešení mají být lepší než ty předchozí.

[pavlix]

Žádnej live systém po ruce nemám.

Oni vypli internet?

[mankind_boost]

Třeba. Nebo nemám žádnej jinej počítač, kde bych si tu flashku připravil. Třeba u sebe nemam tu flashku. Třeba ten počítač neumí bootovat z USB. Třeba nemá DVD mechaniku. Třeba nemám volná DVD. Možnosti jsou nekonečné.

Teď bych se tě rád zeptal: Proč bych měl používat binární logy, když přináší téměř jen nevýhody oproti plaintextu? Opravdu těch pár nedůležitých vedlejších výhod binárních logů vyváží naprosto nezbytnou robustnost a spolehlivost plaintextu? Proč proboha nahrazovat dobré řešení horším? Proč?

[Honza Jaroš]

Protože v případě pavlixe výhody binárních logů prostě převážily nad nevýhodami. Už to tady (ne v téhle diskusi) párkrát psal. Takže v tomto směru je diskuse zbytečná, on má svoje preference, vy (a já taky) máte svoje. My bohužel taháme za ten kratší konec...

[pavlix]

Protože v případě pavlixe výhody binárních logů prostě převážily nad nevýhodami.

Především u mě převážila flexibilita, kdy je možné logy ukládat v jakékoli podmnožině dostupných formátů. Mně především vadí logy v nestrukturované a nekonzistentní formě. Mám rád, když je ve věcech pořádek. Zda jsou pak strukturované logy ukládané binárně nebo textově by mi bylo teoreticky jedno, ale zatím mi práce s logy v journald vychází řádově rychlejší než práce s logy v syslogu, takže nevidím důvod ztrácet drahocenný čas.

[j]

Protoze proste ... proto? Ne, widle to tak prece taky maj, takze kdyz ti nenastartujou, tak proste nezjistis proc. A projistotu bych prestal logovat vsechny zasadni veci a logoval (stejne jako ty widle) jen kraviny.

[mankind_boost]

No aby to tak za pár let opravdu nebylo, zatím to jde přesně tímto směrem.

[j]

Ne, on mu treba jen chlebodarce nechce platit letenku, aby si tam to USBcko moh pripojit. Nebo se mu nechce jet nekam 200km autem.

[Petr Ježek]

Předně je třeba se starat, aby se systém neponičil. Vím, že to občas je "out of the box" a starost o poničený systém nastane. Proto i rsyslog a rescue médium, že... Takže stačí vědět jak...

[sigma]

rsyslog si vezme info z journald a posle je evt. dal pres tcp/udp 514

Ta metoda jak s TCP tak s UDP verzí standardního syslog protokolu je broken by design. Tedy pokud vám vadí, že se občas můžou nějaké log zprávy ztratit.

I při TCP totiž při přerušení spojení není implementováno žádné potvrzování přijetí. Řeší to nějak rsyslog REPL http://www.rsyslog.com/doc/rsyslog_reliable_forwarding.html ale ideální řešení to taky není.

Takže něco lepšího by se hodilo - byť nevím, jestli systemd-journal-remote má toto vyřešené.

[Václav "Darm" Novák]

Předpokládám že ro bude pro ty, kterým vyhovuje formát logů z journald

[randy]

toto systemd pekne vystihuje :))))

[mankind_boost]

[JZD]

ROFL.

[lnykryn]

What do you as a user love about systemd?

[JS1]

Diky, to je dobra stranka. Kritici by si to urcite meli precist - je tam spousta uzitecnych tipu, jak pouzivat systemd.

[pta]

bla, bla, bla

Muzes uvest aspon 3 konkretni priklady vyhod systemd pro bezneho uzivatele, ktere puvodni system neumoznuje ?

[Václav "Darm" Novák]

Rychlejší start (alespoň všude kde jsem na systemd migroval), jednotné rozhraní, pro které se lépe píše klikací konfigurátor (i běžný uživatel si může chtít nastavit, které služby chce po startu systému) a pro pokročilejší: Napsat si kvalitní service je mnohem snazší a přehlednější než init skript.

[pta]

Rychlejsi start ? Arch mi proti Debianu startuje o trochu rychleji, ale ten rozdil je marginalni. Pokud je rychlost startu kriticka, daleko zasadnejsi vliv ma vymena bootvaciho zarizeni (HDD 5400rpm -> SSD) nebo spravna konfigurace sitovek. Pri pouzivani hibernace typicky u notebooku rozdil uz neni. Nepodstatne.

Lepe se pise klikaci konfigurator ? To je otazka jak lepe. Klikaci konfiguratory tu uz existuji dlouhou dobu a muze byt jednodusi je udrzovat nez je kompletne prepisovat. Hlavne to muze byt vyhoda pro vyvojare a ne uzivatele , jak jsem se ptal.

Proc by si mel uzivatel psat vlastni service/init skript ? To je snad starost spravcu distribuce ? Kdyz uz se ale do toho nekdo pusti, tak znalost programovani v shellu mu bude k nicemu, protoze se vedle toho musi naucit jeste format service files systemd a jeho dalsi nastroje, ktere mu uz ale k nicemu jinemu nebudou. Na rozdil od univerzlne pouzitelneho shellu.

IMHO moc slabe duvody pro tak radikalni zmeny.

[Ruža Becelin]

Rychlejsi start sere pes, ale ma lepe resene zavislosti.

Kdyz v RHEL vymenili sysvinit za upstart, tak si toho pomalu nikdo ani nevsiml a vsichni si dal mastili init skripty. Pokud vim, tak systemd umoznuje spustit init skripty a pokud by to prestali podporovat, napsat wrapper, co by to umel a spoustet ho jako service je primitivni.

Za sebe muzu rict, ze systemd je pro me nastroj, stejne jako runit/upstart/sysvinit/smc, a pokud ho mam pouzivat, tak se ho holt naucim, u nas si piseme vlastni init skripty, z prichodem RHEL7 zacneme psat unity a kde to nepujde, tak init skripty nechame.

Takze se znalost shellu bude hodit tak jako tak. Ona se bude hodit kazdopadne, nikdo se neuci skriptovaniv shellu kvuli init skriptum

[Václav "Darm" Novák]

Možnost přehledné konfigurace pro uživatele beru jako jednoznačné plus. A že GUI pro nastavení služeb pro sysvinit existuje? Prosím ukázku něčeho univerzálně fungujícího, co si nebastlí tvůrci distribuce pro svou konkrétní implementaci. Něco co funguje třeba takhle nebo takhle.

k services:

Psal jsem pro pokročilé. Napsat si třeba service pro minecraft server je mnohem snazší, než datlit init skript. Už jen z toho důvodu, že programování v shellu není potřeba. Struktura service souboru je mnohem čitelnější a pochopitelné i pro zkušenějšího uživatele. Nech někoho podobného napsat init skript a s křikem uteče.

[Petr Ježek]

Mně ceteris paribus rychleji. Ono to chce zamyslet se nad obsahem, řazením a hlavně smyslem init prvků.

[j]

Takze jenom zvasty. Rychlejsi start se nekona, jednotny rozhrani taky ne, a kdyz se neco podela, beznej user ani beznej admin to nespravi, protoze nema jak.

[Petr Ježek]

Žvástavé j. Zcela konzistentní systemctl, journalctl a další analytické příkazy - nechtěl bych už hledat ty z sysVinitu, nelogické podmínky sekvencí v rc.d a podobně.

[j]

Zvastavy jezecku, kazdy admin si umi spravit nefungujici script, nebo napsat vlastni. Kazdej srv se inicializuje 100x dyl, nez jak dlouho startuje system (bezne i 15minut a vic). Normalni user pak nikdy nic nekonfiguruje, protoze stejne nevi jak a kde, a to ani ve widlich jejich klikacima nastrojema.

A jesli mi na desktopu system nastartuje za 1,2s nebo za 0,9, to je opravdu vyhra ...

[Jendа]

bezne i 15minut a vic

To máš hodně dojebaný server. Já bych fakt nerad protahoval krátký výpadek energie v datacentru na několikanásobek.

[michi141]

A to máš podle jaké šablony? Když si vezmu zapříklad třeba jen API instance, co používáme u nás ve firmě: boot samotné instance, deploy prostředí, git checkout API projektu a případných závislostí volitelně ve více BC verzích, unit testy, nakonec zařazení do load balanceru, pokud se všechno povede, zpropaguje, usage test – to všechno může klidně hezkých pár minut trvat…

[Václav "Darm" Novák]

Bomba! Skoro jako první jsem našel kvóty. CPUQuota=n%. OK, jdu se znova zahrabat do manuálu systemd, těch pokladů tam bude víc.

[tomvec]

A v příští verzi bude přidána komponenta Bulánci.

[j]

Ty uz tam sou, proc myslis ze to zere tolik RAMky? Jen je musis najit, podobne jako tusim v opicich 95 byl celej Doom.

[miros]

Hm, timedatectl uz neumi zapnout jine NTP demony nez ten jejich, takze muzeme prepisovat dokumentaci a ucit uzivatele zase neco noveho.

[Ruža Becelin]

Hmm, Ja jsem o timedatectl ani nevedel, NTP mi resi ntpd a pro novejsi systemd maji primo postup, jak vypnout tu vnitrni implementaci:

* timedated no longer reads NTP implementation unit names from
/usr/lib/systemd/ntp-units.d/*.list. Alternative NTP
implementations should add a

Conflicts=systemd-timesyncd.service

to their unit files to take over and replace systemd's NTP
default functionality.

[pavlix]

Hezké.

[miros]

Jo, ten konflikt je nutny k tomu, aby nebezeli dva NTP demoni najednou, kdyz je timesyncd zapnuty by default, a nehadali se kdo bude ovladat hodiny. Problem je, ze timedatectl s jinym demonem ted uz neukaze "NTP enabled: yes". Spravne by to teda vlastne nemel ukazovat ani u timesyncd, protoze je to jen SNTP implementace :).

[Petr Ježek]

Chrony ano.

[pta]

odstraneni firmware loaderu z udevu

Asi jim vadi alternativni eudev, Debian je vadny protoze udrzuje starsi kernely a z G.K.Hartmana se vyklubal dalsi arogantni demagog. Asi se to siri jak chripka.

[mankind_boost]

Gentoo folks, this is your wakeup call.

Lennart

Hm...

[pavlix]

Možná taky potřebují, aby se na u2u netlink zapomnělo, protože by si někdo mohl uvědomit, že to umí spoustu věcí, kvůli kterým se používá d-bus ;).

[Ruža Becelin]

Nebudou podporovat novy systemd pro stara jadra, protoze podpora pro to, co potrebuji pro beh systemd, ve starych kernelech neni, tenhle argument chapu.

Pokud budu chtit pouzit starsi kernel, zablokuje mi to update systemd, nic, co by se v Debianu uz nepouzivalo, o Gentoo nemluve. Pro RHEL a klony to problem neni tuplem.

GKH rika, ze problem lezi na tech, kteri se rozhodli podporovat starsi jadra, co je na tom demagogickeho, navic to neni poprve, kdy tam tahle podminka je (je to zmineho v jednom z vlaken)

[pta]

Na argument ze ponechani toho kodu nepredstavuje zadnou zatez ale nikdo nedokazal odpovedet.

Debian prijde se systemd jako vychozim teprve az po novem roce a minimalne aspon na prechodnou dobu je rozumne to tam nechat. Jaka nastala situace, ze prave ted je potreba se toho zbavit ?

[Ruža Becelin]

Ja mam pocit, ze LP a dalsi trpi trochu syndromem "nove prijateho managera" (= vsechno bylo doted spatne).

Na druhou stranu, Debian muze do prechodu na novou verzi pouzivat systemd <=213, ktera jim bude fungovat bez problemu (coz tam nekdo podotkl), tady se jedna o konflikt mezi systemd 216 a jadrem 3.2, ktere oni podporovat nechteji...

[pavlix]

Pokud vím, tak v systemd je řada konkrétních věcí nedořešených z důvodu, že je lennart odkládá až na podporu kdbusu. Patří mezi to třeba nemožnost ovládat dbusovou aktivaci, tedy například ji vypnout.

[andree]

Parada...

3.4.2012: After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially.

...

1.6.2014: this will effectively also mean that we will not support non-systemd systems with udev anymore

...kto by to bol cakal .-)

[pavlix]

Člověk by čekal, že to nevydrží ani ty dva roky.

[lima]

Odvolavam co jsem odvolal, slibuji co jsem slibil

Ze to jeste nekoho prekvapuje. Do top10 hitparady nesmyslnych otazek urcite patri dotazy k budoucnosti projektu psycho-teamu kolem Lennarta.

[j]

Hlavne bych tu tech ocekaval vsechny ty kriklouny, kteri tu porad rvali, ze to neni pravda, ze to bude fungovat zvlast.

[pavlix]

Pokud někdo tvrdil, že to bude fungovat zvlášť, měl pravdu. Docela dlouho to zvlášť fungovalo ;).

[j]

Potrefena husa se ozvala ...

[pavlix]

Kvalitní hulení máš, poděl se taky trochu.

[Pavel 'TIGER' Růžička]

Hmmm, systemd u mne pracuje tak jak má, dá se říci, že mu rozumím a umím si ho nastavit, tak jak potřebuji. Ale s tou filozofií se nesžiji. O realizaci toho všeho ani nemluvě. Ať se na ten projekt snažím dívat z jakéhokoliv úhlu, tak si říkám, že ta cesta není správná. Doufám, že v brzké době vznikne nějaká alternativa, přál bych si, aby se Linux opět vrátil k jednoduchosti, které se momentálně dost vzdaluje.

[Ruža Becelin]

S timhle plne souhlasim, dodal bych, ze alternativa vznikne v okamziku, kdyz o ni bude vetsi zajem, tak, jak to bylo s runit, upstart a koneckoncu i systemd.

Systemd jako init mi nevadi (koneckoncu dela to, co SMC v Solarisu), ostatni komponenty tady ne, pokud budou modularni. Pokud ne, nekdo to forkne, vzdyt Linux je jenom jadro a k tomu, bych mel pouzitelny OS nepotrebuju ani sysvinit/runit/upstart/systemd, ani syslog/jourland apod.

Nakonec i LFS se da automatizovat do te miry, ze pridat k tomu DEB/RPM, tak je z toho druhe Gentoo a jestli tam bude systemd nebo ne, uz rozhodne ten, kdo se o to bude starat.

[mankind_boost]

"Nakonec i LFS se da automatizovat do te miry, ze pridat k tomu DEB/RPM, tak je z toho druhe Gentoo a jestli tam bude systemd nebo ne, uz rozhodne ten, kdo se o to bude starat. "
Jenže třeba Gnome už má systemd jako tvrdou závislost. A není samo.

[Ruža Becelin]

Tomu rozumim, ale to je jejich rozhodnuti a pokud nekdo bude chtit Gnome bez systemd, muze se to pokusit forkout. Nebo ne, je tu KDE, LXDE a dalsi...

[Pavel 'TIGER' Růžička]

Ano, s tou závislostí to není nic dobrého, ale na druhou stranu, člověk gnome nepotřebuje. Co je gnome? Jen desktopové prostředí, které naštěstí není jediné. A potřebuje člověk vůbec desktopové prostředí, když jedinou jeho funkcí je spouštění aplikací, kterou zvládne každý window manager? Někdy i lépe, rychleji a bez systémových nároků! Důležité je, aby se používané aplikace vyhnuli závislosti na desktopu, který závisí na systemd, nebo přímo závislosti na systemd. Svého času jsem používal editor gedit, na který jsem po mceditu nedal dopustit. Jeho koncept se natolik zvrhl, že jsem jej opustil a začal používat medit, který dnes považuji za lepší gedit. Naštěstí člověk nemusí opouštět své zvyky kvůli vývojářským inovacím. Tedy zatím, a to je třeba všude zdůrazňovat.

Zajímal by mne skutečný cíl systemd. Ne to, jak se nám prezentuje, ale co je skutečně jeho cílem. To je to čeho se děsím! Pravda, mohu mu křivdit, což ukáže až čas. Pokud tomu tak bude, rád se potom veřejně omluvím, stejně jako teď píši o obavách z něj.

[Drom]

pluma je fork geditu 2.x pro MATE, pokud by ses chtěl někdy vrátit :)

[Pavel 'TIGER' Růžička]

Vím, z MATE používám caju, ale medit mi vyhovuje více.

[asdf]

pravdepodobne totalni windowsizace linuxu ve smyslu neprehledny neodstranitelny monolit plny zakernych bugu z nichz pulka je tam schvalne aby se dala exploitovat jako backdoor.

Proste nad stadem musi byt dohled, a kdyz se ted tolik lidi presouva pod linux, tahne se spolu s tim i toto.

[pavlix]

Jenže třeba Gnome už má systemd jako tvrdou závislost. A není samo.

Na jednu stranu není nutné Gnome používat, na druhou stranu lze Gnome poskytnout stejná API, jaká nabízí komponenty systemd. Kdyby nic jiného, tak jdou ta API použít jako jeden z výčtů toho, co by se mohlo hodit mít.

[Pavel 'TIGER' Růžička]

Ono je otázkou, jak moc to bude mezi sebou provázané a jestli Gnomáci budou schopni akceptovat i jiné API. Jak je to třeba teď s Gnome a OpenRC? Tuhle variantu nemám otestovanou a celkem by mne to zajímalo. Předpokládám však, že Gnome bude řvát o nepřítomnosti systemd.

[pavlix]

Pokud nebudou akceptovat jiné API, tak zůstávají dvě výše popsané možnosti. Nabídnout jim API, které akceptují nebo nepoužívat Gnome.

[pta]

Alternativa rozhodne nevznikne jen z duvodu vetsiho zajmu. Cokoliv komplexnejsiho nema bez financniho zazemi sanci, zvlast v soucasnosti.

Zajem chapu v obecne rovine, o nejakem sirokem vselinuxovem hlasovani kam by se mel vyvoj ubirat nevim.

Ona tady alternativa prakticky je, staci jen udelat krok zpatky a vykrocit znovu a lepe.

[Pavel 'TIGER' Růžička]

Já tak nějak nadějně vzhlížím ke gnu dmd, leč obávám se doby jeho vývoje.

[Ruža Becelin]

Zkus to hodit na Kickstarter, vzhledem k tomu, ze lidi (?) jsou dneska schopni prispet i na bramborovy salat, tak verim, ze by to ufinancovalo par lidi na full-time :-P

[Petr Ježek]

Jednoduchý init dnes těžko uspokojí složité HW. On se nám ten svět kolem nějak rychle pohybuje...

[psio]

Jednoduchý init dnes těžko uspokojí složité HW

Co to je za blabol ?

Jak vysoke IQ je potreba k ziskani doktoratu z miltidisciplinárního znalostního zázemí ? Na urovni tykve ?

[psio]

O systemd jako svchostu z MS Windows pisou na InfoWorldu.

[rADOn]

…good idea poorly implemented, developed by people with enormous egos who firmly believe they can do no wrong

To sedí.

[jirka]

bohužel to co dnes se systemd pozorujeme je tzv. Debilizace Desktopem. Linux na desktopu stejně nedosáhne většího komerčního úspěchu, takže cui bono ?. Dněšní uživatel nejraději matlá prstem po obrazovce na jednouúčelovém zařízení ala iPhone, iPad a jiné. Ostatní sahnou po Windows a Mac OS X. A na server už beze sporu patří jen Hypervizor. Linux měl šanci nejen jako Hypervizor a nebo 7-24 OS, vše ale zahodil onou Debilizací Desktopem systemd - gnome atd.

Infrastrukturu na RHEL7 a KVM bude dnes snad provozovat jen magor :) A nebo se pletu ? Má někdo z RedHatu statisku přechodu na RHEL7 ?

[lnykryn]

Na nějaké statistiky je ještě brzo, žádná rozumná větší firma nebude hromadně přecházet na X.0 verzi čehokoliv. A jinak do budoucna se předpokládá obrovký boom virtualizace přes kontejnery a tam se systemd hodí. Spíš si myslím, že rhel7 v tomhle ohledu bude trochu neštastná opačným směrem, protože se tam pár zajímavých technologií už nedostalo.