Byla vydána beta verze Ubuntu 25.04 s kódovým názvem Plucky Puffin. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 25.04 mělo vyjít 17. dubna 2025.
Textový editor Neovim byl vydán ve verzi 0.11 (𝕏). Přehled novinek v příspěvku na blogu a poznámkách k vydání.
Živé ISO obrazy Debianu Bookworm jsou 100 % reprodukovatelné.
Boudhayan "bbhtt" Bhattcharya v článku Uzavření kapitoly o OpenH264 vysvětluje, proč bylo OpenH264 odstraněno z Freedesktop SDK.
Představeny byly nové verze AI modelů: DeepSeek V3-0324, Google Gemini 2.5 a OpenAI 4o Image Generation.
XZ Utils (Wikipedie) byly vydány ve verzi 5.8.0. Jedná se o první větší vydání od backdooru v XZ v loňském roce.
Byla vydána nová verze 0.40.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 2.20 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
LibrePCB, tj. svobodný multiplatformní softwarový nástroj pro návrh desek plošných spojů (PCB), byl vydán ve verzi 1.3.0. Přehled novinek v příspěvku na blogu a v aktualizované dokumentaci. Vypíchnut je interaktivní HTML BOM (Bill of Materials) a počáteční podpora Rustu. Zdrojové kódy LibrePCB jsou k dispozici na GitHubu pod licencí GPLv3.
Minulý měsíc Hector "marcan" Martin skončil jako upstream vývojář linuxového jádra i jako vedoucí projektu Asahi Linux. Vývoj Asahi Linuxu, tj. Linuxu pro Apple Silicon, ale pokračuje dál. Byl publikován březnový přehled dění a novinek z vývoje. Vývojáře lze podpořit na Open Collective.
Při startu serveru dojde k automatickému připojení šifrovaného oddílu s btrfs. Klasicky standardní cestou, nic extra. Problém je, že dvě služby se v rámci systemd spustí dřív, než je partition namapována. Těmi službami je minidlna a nfs-kernel-server. Obě hlásí nedostupnost adresáře, který je na dané partition. Služby se tedy nespustí. V konfiguraci služeb není žádný problém, stačí je restartovat a vše šlape.
Unity zmíněných služeb nejsou nijak modifikovány, vše by default. Z nějakého důvodu se neaplikuje "After=local-fs.target". Distribuce Debian 11, origo kernel, stable větev.
Jedná se opravdu o hloupost a není to bug, ale fce.
Zdar Max
PS: Znovu připomínám, že problém je dávno vyřešen, ale přišlo mi to celkem zajímavé jako kvízek.
Tiskni
Sdílej:
legitimni, kdyz lide vyjadri nazor k systemd takovym tim zkratkovitym zpusobem - totiz ze to nazvou srackouLegitimní to není, systemd není sračka, protože přináší jednoznačné benefity oproti původnímu SysV init (nebudu znovu vyjmenovávat).
jsem programoval jeden init-script asi tak jednou za 5 let. U systemd budu tedy muset editovat jedenkrat za 5 let nejaou unit. Uspora ??Úspora je v tom, že ten unit poběží všude (bude-li mít správně nastavené a standardní dependencies) a nebudeš muset pokaždé vymýšlet číslo, které mu přiřadit, aby na daném počítači fungovalo. Což u pár počítačů asi nebude velký problém, ale vývojář software nezávislého na distribuci nemá naprosto představu, na jak obskurním setupu může software běžet. PS: Já pořád nechápu tu averzi k systemd, co je s těma lidma? Kdysi jsem psal process manager (ještě v dobách před systemd) a deklarace pořadí byla dána závislostmi - nikdy by mě nenapadlo dělat jej přes čísla. Jako chápu, že u SysV initd kdysi dávno někdo zvolil čísla, ale obhajovat to jako lepší řešení, když dnes vedle sebe postavím číselné a deklarativní, to už musí být něco sakra špatně...?
PS: pokud ti nevyhovuje journalctl, používej rsyslog a logrotate, nic ti v tom nebráníKdyž nebude mít funkční journal s dostatečnou historií, tak kdykoli udělá
systemctl start mojeslužba
(které mimochodem nejde debugovat co vlastně přesně spouští, aby to člověk mohl zkusit ručně nebo se prostě podíval co se sakra děje) a nenaběhne to, tak si nemá jak vypsat, co to řeklo na stdout a stderr než to umřelo, ne?
StandardOutput=append:/var/log/app/app.log StandardError=append:/var/log/app/error.lognebo:
StandardOutput=syslog StandardError=syslog #StandardError=inherit SyslogIdentifier=<your program identifier> # without any quote SyslogFacility=local4Nebo pak jak jsem zmínil, tak globálně přesměrovat journald:
nano /etc/systemd/journald.conf ... [Journal] ... ForwardToSyslog=yes MaxLevelSyslog=debug ...Prostě možností je spousta. Buď lze přesměrovat jen něco, nebo všechno, nebo nezapisovat do journald, ale rovnou do souboru apod.
Obecně není s funkčností problém, takže někde asi děláš chybu.To není pravda, například neskipnutelné (e.g. zmáčknutím Ctrl+C na konzoli) čekání při bootu nebo absence základní funkčnosti v journalu jsou normálně oficiální vlastnosti.
journalctl
, ale musis zadat konkretny namespace (ako parameter).
[1] https://github.com/poettering/systemd/commit/cc4df240559aa56407ca0a0c5d2abf635b5ba477
- Pretoze je to proti filozofii Linuxu(zbytek přeskočím) Co přesně je na tom proti filozofii Linuxu? "Filozifií Linuxu" je nastartovat systém a pustit klíčové procesy po startu systému. To dělá initd i systemd, systemd řekněme spolehlivěji a efektivněji. Ve skutečnosti, funkcionalita systemd by šla zjednodušit na to, co dělá initd, ale stejně to nikdo neudělá, protože se nikdo nechce vracet o desítky let zpátky. Stejně jako nikdo nejde zpátky do dob kernelu 2.0.x , přestože byl jednoduchý a každá část dělala přesně jednu věc, na kterou byla určena - jednoduše byl neefektivní... Byl devfs proti filozofii Linuxu? Jsou GPU drivery v kernelu proti filozofii Linuxu? PS: Nechcu spadnou do flamewar. Je to jenom reakce na termín "filozofie Linuxu" a jeho ohýbání pro účely vlastní argumentace.
To dělá initd i systemd, systemd řekněme spolehlivějiMinimálně než byly odladěné různé problémy tak to s tou spolehlivostí nebylo moc slavné. Teď už jsem naštěstí dlouho na problém nenarazil, ale pokud někdo přecházel v období kdy to ještě nebylo ready, tak má pachuť dost velkou.
Uhádnete, kde byl problém?
Že systemd je sračka?
Bol problém v tom,že After=
určuje len poradie a Requires=
vyžaduje aby bol daná služba, proces už pri spustení aktívny.
systemd-analyze dot 'nfs-server.*' | dot -Tsvg > systemd.svgPřípadně pak ještě konkrétněji:
# vygeneruje jen dependency "After=, Before=" systemd-analyze dot 'nfs-server.*' --order | dot -Tsvg > systemd.svg # vygeneruje jen dependency "Requires=, RequiresOverridable=, Requisite=, RequisiteOverridable=, Wants=, Conflicts=" systemd-analyze dot 'nfs-server.*' --reuire | dot -Tsvg > systemd.svgAtd. Jde si s tím dost hrát a znázornit si jednoduše pořadí, jak by mělo docházet ke spouštění.
/etc/fstab
pre GFS2 pridat parameter x-systemd.after=drbd.service
, inac mi to stale pripajalo este pred tym, ako nabehlo DRBD.
systemctl enable
ExecStartPre=bash -c 'sleep 23s'
, pripadne zkusit vyuzit neco ze skupiny StartLimit*
Ma se na neho pockat a pak pokracovat bez ohledu na vysledek.To je otázka, zejména když to čekání je nepřeskočitelné a pak člověk teče když čeká někde v mrazu/hluku u konzole než to napočítá do 90. Manuál taky píše boot will continue without waiting, ale manuály k systemd už mají ten syndrom co mají zákony, že je prostě člověk kvůli jejich objemu nemůže znát všechny a pak ho něco překvapí. A o kousek výš se asi píše jak z toho ven (ale nezkoušel jsem to), že i nofail záznamu můžeš dát
x-systemd.before=nějaká_unita
, a pak by to mohlo počkat a až pak spustit ten NFS server nebo co to tam Max měl. Ještě teda nevím jak je to s pokusem o další spuštění - třeba by NFS server měl že když selže, tak se to po 10 sekundách restartuje, ale když se nepodaří ten mount, tak se NFS možná ani nedostane do toho failed stavu kdy by se zkoušelo otáčet (spolu se svými závislostmi). Vida, taky by to asi šlo vyřešit tím, že se NFS dá after=ten_mountpoint, ne?