OpenTTD (Wikipedie), tj. open source klon počítačové hry Transport Tycoon Deluxe, byl vydán v nové stabilní verzi 15.0. Přehled novinek v seznamu změn a také na YouTube. OpenTTD lze instalovat také ze Steamu.
Správce oken IceWM byl vydán ve verzi 4.0.0, která např. vylepšuje navigaci v přepínání velkého množství otevřených oken.
Od 1. ledna 2026 jsou všechny publikace ACM (Association for Computing Machinery) a související materiály přístupné v její digitální knihovně. V rámci této změny je nyní digitální knihovna ACM nabízena ve dvou verzích: v základní verzi zdarma, která poskytuje otevřený přístup ke všem publikovaným výzkumům ACM, a v prémiové zpoplatněné verzi, která nabízí další služby a nástroje 'určené pro hlubší analýzu, objevování a organizační využití'.
K 1. lednu 2026 končí 70leté omezení majetkových autorských práv děl autorů zesnulých v roce 1955, viz 2026 in public domain. V americkém prostředí vstupují do public domain díla z roku 1930, viz Public Domain Day.
Všem vše nejlepší do nového roku 2026.
Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.60. Vyzkoušet lze online demo.
Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
ip route add 0/0 dev ppp0 table 200nmcli modify "Tvoje DSL" +ipv4.routes "0/0" ipv4.route-table 200Pet minut hledani..
nmcli con modify DSL +ipv4.routes "0.0.0.0/0" ipv4.route-table 200
systemd-networkd
“beru to jako věc, která se se.e do všeho, ale nic neumí pořádně” == ”nemám tušení, která bije, a musím se tím náležitě pochlubit”
…přiznávám, že systemd-networkd jsem ještě nepoužil a neznám jej…
Manuálové stránky na Fedoře fungují? Co jsem se posledně díval, fungovaly.
Už to jde používat bez systemd-journald?
Proč by chtěl někdo používat jakýkoliv systém bez rozumně fungujícího správce logů, který má (konečně!) korektně synchronizovaný čas mezi různými zdroji logů, indexování a vyhledávání, kompresi, podpisy a ochranu před manipulací s logy, atd. atp.?
Strach z „neznámého“? Ten by byl omluvitelný možná v roce 2010. Dnes nemáme rok 2010.
Je neuvěřitelné, jak se dodnes vynořuje to uvažování z divokých devadesátých let, podle kterého je normální spustit službu z rozbitého Bash skriptu spuštěného kdovíčím a kdovíodkud, samozřejmě, že pod rootem a bez “hardeningu”, jak jinak; skript pak možná selže, možná občas ne, ale žádný problém, nikoho to nesere, hlavně když od toho nikde nebude vidět žádný stav ani log, a když náhodou jo, tak logy nebudou správně prokládané v čase vůči logům od zbytku systému, nebude to umět reagovat na uspání / probuzení / změnu nastavení sítě / jinou zásadní událost v systému…
No ale furt se najdou lidi, kteří budou tvrdit, že tenhle↑↑↑ stav věcí byl přijatelný, zatímco systemd prý jako fakt ne.
systemd FTW.
Není v tom žádný strach z neznámáho, prostě zásada držet se věcí které fungují…
Nefungují. (Přesněji řečeno: nefungovaly. Proto vznikl systemd.)
Nápodobně bash scripty - na to, co jsem potřeboval, fungovaly skvěle, jsou čitelné, univerzální a maximálně flexibilní.
Tak určitě. Dobrý vtip.
Ale třeba mne někdo přesvědčí o nějakých zásadních výhodách...
A třeba ne. Není úkolem ostatních přesvědčovat někoho o výhodách té či oné technologie. Proč by to dělali?
auth logy chcem drzat 1 rok, nejake aplikacne logy pol roka a ostatne 1 mesiac?
Rizikový nápad. Proto nic takového neřeším.
Když jeden chytrolín tuhle nedávno obešel můj SSH tarpit, nebýt systemd-journald, byl by mi zaplnil dost rychle celou kvótu logy. Nemluvě o tom, kdybych se pokoušel takové logy udržovat rok. Naštěstí systemd-journald situaci zvládl. Historii (konec řidších logů před začátkem „útoku“) jsem pak už dohledal v Btrfs snapshotech.
Což zároveň odpovídá na původní dotaz: Dokud budou logy dost řídké, budou se ve snapshotech záloh překrývat a doba jejich skladování jaksi odpovídá algoritmu pro „ředění“ a mazání zálohovacích snapshotů. Jakmile začnou být logy hustohusté (a tím pádem zároveň nepříliš zajímavé a dost rychle taky škodlivé), kus se jich (naštěstí, díky systemd-journald) do snapshotů nedostane a zbude díky tomu místo pro smysluplnější data.
journalctl.
Mimochodem, jak ze se cte ten blob kdyz jediny co funguje je vi?
O jaké situaci je tady řeč? Po apokalypse? Proč by měl fungovat jenom paskvil vi?
Počítač se nedá nabootovat z média s live systémem? Proč?
Úložiště se nedá připojit k jinému počítači? Proč?
route1=0.0.0.0/0 route1_options=table=200
Tiskni
Sdílej: