V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
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?
Tiskni Sdílej: