Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Po více než 3 měsících vývoje od vydání verze 238 oznámil Lennart Poettering vydání verze 239 správce systému a služeb systemd (GitHub, NEWS).
Tiskni
Sdílej:
Fungovalo vsecko tak jak clovek ocekaval.Tak určitě.
Tohle totiž umí systemd řešit velmi dobře.Ne, porad to neumi. Spadne Apache, databaze a systemd s klidem tvrdi, ze sluzba bezi v poradku. Tohle mi uz delsi dobu pije krev.
[Unit] Description=Apache Web Server After=network.target [Service] ExecStart=/usr/sbin/httpd -DFOREGROUND [Install] WantedBy=multi-user.target
Proč si vymýšlíte? Že chyba není nikdy v systemd tu nikdo nepsal.Ironie, sarkasmus? Beres se vzdycky tak vazne?
Ale z toho, co popisujete, chyba není v systemd, protože si stěžujete na absenci něčeho, co ve skutečnosti systemd umí. Příslušné jednotkové soubory jste sem nedal, tak jak asi máme vyvěštit, kde je chyba?Neni potreba to dal rozebirat. Chyba je jednoznacne ve mne. Uz jen proto, ze jsem se odvazil pouzivat hned nekolik distribuci, kde se systemd pouziva, a rict, ze mi tam proste nektere veci nefunguji.
Ale z toho, co popisujete, chyba není v systemd, protože si stěžujete na absenci něčeho, co ve skutečnosti systemd umí.A varianta, ze to treba dela blbe, te nenapadla? Uprimne, tim, ze je systemd binarka, hledat v tom vysvetleni, proc se neco chova divne je vylozene utrpeni. Jednou jsem si tim prosel, kdy se mi root ,,sam od sebe'' premountovaval do readonly (a prakticky s tim pocitacem neslo pracovat) a uz to nechci opakovat.
Uprimne, tim, ze je systemd binarka, hledat v tom vysvetleni, proc se neco chova divne je vylozene utrpeni.Ano, tohle je problém, a přesně to mě potrápilo, když jsem měl rc.local jako oneshot (už si nepamatuju jestli to bylo default nebo jsem to někde opsal) i když jsem v něm dělal fork (proto teď mám service types nastudované). Prostě to „podivně nefungovalo“ a v logu nic a jak tohle chcete ladit.
Jednou jsem si tim prosel, kdy se mi root ,,sam od sebe'' premountovaval do readonly (a prakticky s tim pocitacem neslo pracovat) a uz to nechci opakovat.A tohle se mi taky stalo, pokud si vzpomínám, tak problém byl v tom, že mount už není mount(2), ale vygenerované mount unity, a po změně /etc/fstab bylo potřeba cosi (celý systemd?) reloadnout :(.
25.6.2018 20:20
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
A tohle se mi taky stalo, pokud si vzpomínám, tak problém byl v tom, že mount už není mount(2), ale vygenerované mount unity, a po změně /etc/fstab bylo potřeba cosi (celý systemd?) reloadnout :(.Jo, s tímhle je hrozná sranda. Pokud se mění device ale nemění se mountpoint, tak mount (bez reloadu systemd) namountuje původní device a nikoliv ten nový uvedený ve fstabu. Ale ani toto chování není konzistentní, protože někdy se po editaci fstab ty mount unity automaticky přegenerují a jindy ne. Takže od jisté doby po každé editaci fstabu vždy dávám
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
24.6.2018 16:23
systemctl daemon-reload. Což je jistě super a přínosné vylepšení administrace systému.
Chyba je jednoznacne ve mne. Uz jen proto, ze jsem se odvazil pouzivat hned nekolik distribuci, kde se systemd pouziva, a rict, ze mi tam proste nektere veci nefunguji.Jasně, další ironie, sarkasmus. Mimochodem, vy jste nepsal, že vám některé věci nefungují v distribucích, vy jste psal, že něco neumí systemd – něco, co ve skutečnosti umí.
A varianta, ze to treba dela blbe, te nenapadla?Napadla. Ale když porovnám variantu, že všichni, kdo to používají (včetně mě), si nevšimli, že jim to nefunguje, a variantu, že to máte špatně vy (když ani neukážete konfigurační soubor), co je asi pravděpodobnější?
Uprimne, tim, ze je systemd binarka, hledat v tom vysvetleni, proc se neco chova divne je vylozene utrpeni. Jednou jsem si tim prosel, kdy se mi root ,,sam od sebe'' premountovaval do readonly (a prakticky s tim pocitacem neslo pracovat) a uz to nechci opakovat.To vůbec nesouvisí s tím, že systemd je binárka. SysVinit je taky binárka, bash je taky binárka… Problém spíš je, že věříte hloupostem z internetových diskusí, a když vás někdo upozorní, že jsou to nesmysly, tak se urazíte.
neumí systemd – něco, co ve skutečnosti umíPuvodni tvrzeni bylo:
Tohle totiž umí systemd řešit velmi dobře.Křičte si na mě, bijte si mě, mučte si mě chlebovou polívkou! Ale trvám si na tom, že velmi dobře to opravdu bude fungovat, až to bude fungovat všude.
že to máte špatně vy (když ani neukážete konfigurační soubor), co je asi pravděpodobnější?A co by to řešilo, když ani u sebe to nejsem schopen deterministicky zreprodukovat? Jenom mi cas od casu chcipne nejaka sluzba a systemd se tvari, ze je vse v poradku.
To vůbec nesouvisí s tím, že systemd je binárkaAno, souvisi. Kdyby to nebyla binarka, resp. nekolik uzce provazanych binarek, tak si muzu s klidem projit, ktera cast je pouzivana a jak a urcit/opravit chybu. Treba ve Slackware neni problem vzit si jakykoliv systemovy skript (a bud clovek hned vidi, kde je problem) nebo si jej muze bez problemu radek po radku provest a kontrolovat, jestli se stalo, co se melo stat. To se systemd pada a pokud nemas nainstalovane i debug balicky (kdo z vas je ma?), tak zjistit, proc se system chova divne, je ukol pro ty nejotrlejsi.
Problém spíš je, že věříte hloupostem z internetových diskusíAno, priznavam, ten problem s tim automatickym premountovani, nad kterym jsem stravil pet nebo sest hodin, misto toho, abych se venoval praci, jsem si nasel v prehledu hloupych internetovych diskuzi.
Ale trvám si na tom, že velmi dobře to opravdu bude fungovat, až to bude fungovat všude.Ono to ale funguje všude. Že si to někdo neumí zapnout, to není problém systemd.
A co by to řešilo, když ani u sebe to nejsem schopen deterministicky zreprodukovat? Jenom mi cas od casu chcipne nejaka sluzba a systemd se tvari, ze je vse v poradku.Co s tím má systemd dělat, když to máte špatně nakonfigurované? Systemd bohužel musí podporovat i legacy služby, takže vám nemůže bránit v tom nakonfigurovat to špatně.
Ano, souvisi. Kdyby to nebyla binarka, resp. nekolik uzce provazanych binarek, tak si muzu s klidem projit, ktera cast je pouzivana a jak a urcit/opravit chybu. Treba ve Slackware neni problem vzit si jakykoliv systemovy skript (a bud clovek hned vidi, kde je problem) nebo si jej muze bez problemu radek po radku provest a kontrolovat, jestli se stalo, co se melo stat. To se systemd pada a pokud nemas nainstalovane i debug balicky (kdo z vas je ma?), tak zjistit, proc se system chova divne, je ukol pro ty nejotrlejsi.Systemd je opensource, zdrojáky jsou k dispozici. Ale hlavně systemd nemusíte ladit takhle složitě. Ukázal jsem vám jednotkový soubor pro Apache, kde máte tři řádky konfigurace. Z toho dva řádky jsou určení závislostí, takže zbývá jeden řádek s příkazem, co se má spustit. Ten příkaz klidně můžete vzít a spustit ho v shellu.
Systemd je opensource, zdrojáky jsou k dispozici.Ano, to bylo moc fajn. Na jednom pocitaci strace + gdb bez debuginfo a na druhem zdrojaky na githubu, abych aspon trosku tusil, proc se systemd chova divne.
Ale hlavně systemd nemusíte ladit takhle složitěA co kdyz chci? A jak ho jinak ladit? Pres gdb?
Ukázal jsem vám jednotkový soubor pro Apache, kde máte tři řádky konfiguraceTo jsou ty ucebnicove priklady pro dny, kdy sviti slunicko a vsechno hezky funguje. V momente, kdy veci prestanou jit podle idealniho scenare, zacne systemd tvorit neprostupnou mlhu.
Ten příkaz klidně můžete vzít a spustit ho v shellu.A jak mi toto pomuze nalezt problem v tom, kdy mi chcipne sluzba a systemd tvrdi, ze porad bezi?
ExecStart do jednotkového souboru (akorát cestu k binárce musíte uvést jako absolutní cestu).
Pokud to mermomocí musíte dělat složitěji, je to vaše volba, ale pak si nestěžujte na systemd.
A jak mi toto pomuze nalezt problem v tom, kdy mi chcipne sluzba a systemd tvrdi, ze porad bezi?Jeste jednou (a naposledy). Kdekoliv jinde, kde system pro spousteni sluzeb neni polovicni blackbox, muzu vcelku jednoduse (i kdyz ty tvrdis ze komplikovane) projit, co se deje a identifikovat, kde je problem. Se systemd, musim hadat, kde by mohl byt problem, jen proto, ze maintainer distribuce, jejich QA a kdo vi kdo jeste, neumi napsat triradkovy konfigurak pro tak jednoduchou vec jako je systemd.
Kdekoliv jinde, kde system pro spousteni sluzeb neni polovicni blackbox, muzu vcelku jednoduse (i kdyz ty tvrdis ze komplikovane) projit, co se deje a identifikovat, kde je problem.Já vám to neberu, akorát nechápu tu vaší obsesi vytvářením problémů při spouštění služeb. Já mám radši správce služeb, kde ty vaše problémy vůbec nevznikají, takže je pak nemusím řešit. Ale nevnucuju vám to, pokud vy máte radši systém, kde tyhle problémy z principu vznikají, abyste si pak mohl užívat jejich řešení, klidně si dál používejte to klubko shell skriptů. Někdo má rád únikové hry, někdo šifrovačky a někdo rád řeší problémy se spouštěním služeb pomocí shell skriptů, ať se každý zabaví po svém.
Se systemd, musim hadat, kde by mohl byt problem, jen proto, ze maintainer distribuce, jejich QA a kdo vi kdo jeste, neumi napsat triradkovy konfigurak pro tak jednoduchou vec jako je systemd.Jasně, a to je problém systemd. Když jednotkový soubor editujete ve
vimu a nevíte, jak vim ukončit, je to taky problém systemd.
Nebo se nepovede mount zcela nepodstatného adresáře uvedený ve fstab.Tohle jsem taky potkal, fakt na zabiti.
Sám jsem si párkrát vyzkoušel jeho nástrahy, jako že třeba když síťovka nedostane IP adresu (nemá připojený kabel), systemd při bootu zastaví, protože tahle unita defaultně nemá nastavený timeout.Tohle chcete zjišťovat debugováním systemd? Není jednodušší si vypsat konfiguraci té jednotky?
Nebo se nepovede mount zcela nepodstatného adresáře uvedený ve fstab.Řekl bych, že debugovat
mount bude stejně obtížné, jako debugovat systemd.
Ovšem tyhle chyby snad nikdo nehledá debugováním aplikací. Spíš pročtením logu a konfigurace. Moje zkušenost je taková, že systemd do logu píše víc užitečných informací, než kolik jich v logu bývalo od shellových startovacích skriptů.
25.6.2018 20:34
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Sám jsem si párkrát vyzkoušel jeho nástrahy, jako že třeba když síťovka nedostane IP adresu (nemá připojený kabel), systemd při bootu zastaví, protože tahle unita defaultně nemá nastavený timeout.Ano, případně se systemd rozhodne vyřadit start služby pro aktivaci sítě, protože detekuje smyčku závislostí služeb (která tam není nebo možná je jen během bootu), takže server naběhne bez sítě (což je jistě fajn). Zajímavé je, že potom stačí napsat
systemctl start netw... a bez keců tu službu nahodí, zřejmě smyčka závislostí unit zázrakem sama od sebe zmizela.
Pochopitelně to není nijak deterministické, někdy vyhodí službu pro síť (toho si teda všimnu pokaždé), jindy třeba consolesetup (což vlastně ani nepoznám). Takže každý boot nenajede jiná služba.
Ano, „nevyrábějte si ty problémy“ vskutku není odpověď na otázku „iniciativně jsem si vyrobil problém, jak ho mám teď řešit“. Je to jenom doporučení, jak postupovat, aby vůbec nevyvstala potřeba takovou otázku klást. Ale když mermomocí trváte na tom, že si problémy budete vytvářet, tak si je vytvářejte – ale nechtějte pak po ostatních, aby vám pomáhali je řešit.“Tak jeste jednou a pomalu. Mam dve distribuce (Debian, openSUSE) s distribucni konfiguraci sluzeb, do ktere jsem nijak nehrabal. Podivne chovani, ze sluzba spadne a systemd hlasi, ze je vse OK, jsem zaregistroval minimalne u Apache a Postgresu na obou distribucich. (U tech to vim urcite, protoze to jsou kriticke sluzby a kdyz nefunguji, poznam to hned.) Muzes mi rict, kde jsem teda, cituji: „iniciativně [jsem] si vyrobil problém, jak ho mám teď řešit“.? Ano, jsem ochoten uznat, ze je to chyba konfigurace, ale ten vyskyt napric distribucemi a ruznymi aplikacemi mi jednoduse indukuje problem nekde jinde.
Já mám radši správce služeb, kde ty vaše problémy vůbec nevznikají, takže je pak nemusím řešitTo ti neberu. Ale u me ty problemy proste vznikaji (a neni ted podstatne, jestli za ne muze systemd nebo maintaineri) a musim je resit. A systemd mi v tom vubec nepomaha.
Dovolil bych si tvrdit, ze pokud hlavni uzivatele (maintaineri) nedokazi spravne pouzivat dany nastroj, pada cast viny i na ten nastroj.Se systemd, musim hadat, kde by mohl byt problem, jen proto, ze maintainer distribuce, jejich QA a kdo vi kdo jeste, neumi napsat triradkovy konfigurakJasně, a to je problém systemd. Když jednotkový soubor editujete ve vimu a nevíte, jak vim ukončit, je to taky problém systemd.
Muzes mi rict, kde jsem teda, cituji: „iniciativně [jsem] si vyrobil problém, jak ho mám teď řešit“.?Místo toho, abyste si napsal jednoduchou funkční jednotku, nebo si alespoň přečetl konfiguraci té distribuční (a opravil jí), chcete debugovat systemd. Přitom byste tím debugováním stejně dospěl jenom k tomu, co máte napsané v tom jednotkovém souboru.
Ano, jsem ochoten uznat, ze je to chyba konfigurace, ale ten vyskyt napric distribucemi a ruznymi aplikacemi mi jednoduse indukuje problem nekde jinde.Vzhledem k tomu, že jinde to funguje, asi nebude problém v systemd. Zrovna PostgreSQL pomocí systemd spouštím a o ukončení procesu systemd vždy věděl.
Ale u me ty problemy proste vznikaji (a neni ted podstatne, jestli za ne muze systemd nebo maintaineri) a musim je resit. A systemd mi v tom vubec nepomaha.Nikoli, nepomáhá vám v tom to, že se ty problémy pokoušíte řešit komplikovaně, jako byste je řešil při spouštění služeb z shellu. Když se systemd nedozví o ukončení nějakého procesu, stačí se podívat do jednotkového souboru, který proces se má spouštět a jaký typ služby je nakonfigurován. Pokud se spouští nějaká řídící utilita místo cílové služby, nebo pokud se ta služba odforkuje, systemd (ani žádný jiný správce služeb) se samozřejmě nemůže dozvědět, když se proces ukončí. Ano, dá se to věštit – zapíšete si PID do souboru, pak se podíváte, zda proces s takovým PID běží, a když ano, budete se modlit, aby to byl ten původní. Ale systemd funguje tak, aby nebylo nutné se při jeho používání modlit.
Dovolil bych si tvrdit, ze pokud hlavni uzivatele (maintaineri) nedokazi spravne pouzivat dany nastroj, pada cast viny i na ten nastroj.Obávám se, že je to komplikovanější. Že maintaineři například chtějí udržovat zpětnou kompatibilitu nebo možnost volby správce služeb, a pak nemůžou systemd používat pořádně.
Místo toho, abyste si napsal jednoduchou funkční jednotku...Je odpoved na otazku: Muzes mi rict, kde jsem teda, cituji: „iniciativně [jsem] si vyrobil problém, jak ho mám teď řešit“.? Uz jsem to tu jednou psal, ze to chapu, ze systemd je v poradku, problem je jednoznacne ve mne, protoze pouzivam distrubuce zalozene na systemd. Tecka. Neni potreba to opakovat.
Vzhledem k tomu, že jinde to funguje, asi nebude problém v systemd.Vzhledem k tomu, ze jinde postgresql a apache funguje, asi v nich taky problem nebude. Mluvim tu o problemu, ktery se objevi tak jednou za pul roku v dost nereprodukovatelnych podminkach.
Že maintaineři například chtějí udržovat zpětnou kompatibilitu nebo možnost volby správce služeb, a pak nemůžou systemd používat pořádně.Sluselo by se dodat, ze skutecnost, ze systemd nepodporuje tyto use-casy, je opet problem maintaineru a uzivatelu distribuci.
Vzhledem k tomu, ze jinde postgresql a apache funguje, asi v nich taky problem nebude.Já jsem psal, že je problém v jednotkách, ne v aplikacích.
Sluselo by se dodat, ze skutecnost, ze systemd nepodporuje tyto use-casy, je opet problem maintaineru a uzivatelu distribuci.Systemd podporuje i legacy služby, ale nemůžete čekat, že ta podpora bude stejně dobrá, jako u moderních služeb. Kdyby šlo legacy služby spravovat stejně dobře, jako moderní služby, nebylo by přece potřeba psát nic nového.
To vůbec nesouvisí s tím, že systemd je binárka. SysVinit je taky binárkaJá jsem problémy se sysvinit řešil "bash -x /etc/init.d/služba akce" a typicky v tom výpisu bylo vidět, co se stalo - deda.jabko by v tomto případě viděl, jak "status" dojde k tomu, že služba běží, a tedy kde je chyba (např. že má blbě nastavený pidfile, že v cgrupě té služby stále hnije jeden proces).
25.6.2018 20:13
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Používáš distribuci s blbě napsanými unit filesTahle reakce je super a líbí se mi. Jako jedno z lákadel na systemd se psalo, že psát rc skripty je strašně těžký, dávaly se příklady tisíci řádkových rc skriptů (a protože je to bash, tak to podle některých ani jinak napsat nešlo) apod a říkalo se, že systemd unity všechno vyřeší, je to na pár řádků a nastane ráj na zemi. O pár let později tady máme blbě napsané unity.
Jako ... fakt super odpověď
No ale dost sarkasmu. Jako jasně, i já vidím často totálně blbě napsané unity stejně jako před tím byly totálně blbě napsané rc skripty. To, že rc skript v bashi nemusí mít milion řádků ale může to být krásně přehledný jednoduchoučký skript vidíme třeba v FreeBSD. Jen tím chci říct, že evidentně není problém ve formátu rc skriptů nebo unit, ale v lidech, kteří je píší. Změnou ze sysv na systemd se toto nevyřešilo.
dávaly se příklady tisíci řádkových rc skriptů (a protože je to bash, tak to podle některých ani jinak napsat nešlo)Meanwhile in slackware
25.6.2018 21:45
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
.
25.6.2018 20:04
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
25.6.2018 21:34
service httpd reload se musel dívat ještě na ps aux | grep httpd zda mu ten apache skutečně běží. A že prý systemctl reload httpd tohle řeší, protože v případě problémů to napíše.
Neřeší a nenapíše. Zažil jsem několik případů, kdy po systemctl reload apache2 apache nenajel (čímž teda procesy zmizeli i z cgrupy, kterou systemd tak pečlivě hlídá) a systemd to bylo totálně jedno, systemctl nic nevypsal, jen prostě služba nejela (z důvodů chyby konfigurace se apache při reloadu složil). Takže už i po systemctl reload apache2 dělám buď systemctl status apache2 nebo staré dobré ps aux | grep, abych se ujistil, že to jede. Podotýkám všechno je čistě distribuční, na rozdíl od kolegy tazatele s logrotatem, jsem si už ani nedovolil něco měnit.
Bobtnající linuxový kernelano, zvlášť když tam většina toho zabírají ovladače pro x desítek staré architektury a stroje, že
Nakonec jej nemusíte používat, můžete si zvolit jinou rakovinu
A co se systemd týče, je mi jedno zda je lepší než minule nebo běží na toustovači... nejsem nucen jej totiž používat, a to mám stejný OS jako vy. Ale rád se podívám, co zase soudruzi "vymysleli".
Bobtnající linuxový kernel začíná připomínat oligopolizaci ekonomiky jako první stádium rakoviny.No nejvíc nabobtnaly ty šílený headery pro AMD grafiky, ale pořád to nemusíš kompilovat když ten HW nemáš.
26.6.2018 08:21
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Ako základ sa zvyčajne berie to o čom píšeme (teda dostupnosť). Vo vašom príklade používate ako základ nedostupnosť. Nebolo by jednoduchšie písať nedostupnosť sa zvýšila o 1000%?
26.6.2018 10:47
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Zobral som plný pohár vody (tj. 100% objemu tvorí voda). Vyparovaním sa stratilo 0.1% z celkového objemu vody. Ak z neho vylejem 10% vylejem 0.01% objemu?
nová_dostupnost = původní_dostupnost - 10 × původní_dostupnost. Pokrátit už to snad zvládnete sám.