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.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
XLibre Xserver byl 21. prosince vydán ve verzi 25.1.0, 'winter solstice release'. Od založení tohoto forku X.Org serveru se jedná o vůbec první novou minor verzi (inkrementovalo se to druhé číslo v číselném kódu verze).
systemctl stop NetworkManager
bude postačující. Jaké je mé zděšení, když po chvíli celkem pravidelně zjistím, že NM zase běží. systemctl stop NetworkManager sice NM zastaví, ale po chvíli jej zase spustí. Stop v tomto případě neznamená stop, ale spíš pazu.
Prosím tedy místní systemd guru o radu, jak v systemd vypnout službu tak, aby se nezapnula, dokud neřeknu nebo nerebootuji. Jako berlička mi zatím slouží systemctl disable NM, systemctl stop NM. Stop musím poslat několikrát, potom mám jistotu, že znovu nenastartuje. Každopádně to považuji za chybu, nebo nerozumím tom, jak stop funguje...
systemctl mask NetworkManager.serviceodstřelí službu úplně, takže ji nelze spustit ani ručně, dokud se neodmaskuje
systemctl disable NetworkManager.servicezpůsobí, že službu lze spustit jen ručně. Pokud chcete zabránit tomu, aby šel NM spustit "on demand" přes D-Bus, můžete v /usr/lib/systemd/system/NetworkManager.service zakomentovat tento řádek:
Alias=dbus-org.freedesktop.NetworkManager.service
NetworkManager.conf, že některá rozhraní má nechat na pokoji:
[keyfile] unmanaged-devices=interface-name:tun0V Debianu je pro ovládání NetworkManageru
nmcli a VPN podporuje po doinstalování příslušných balíčků (např. network-manager-openvpn).
systemctl --runtime mask před zastavením služby. Nemá to nepříjemné vedlejší efekty a funguje to bezvadně a univerználně.
Každopádně to považuji za chybu, nebo nerozumím tom, jak stop funguje...Obojí platí. V systemd už neexistuje přímý vztah mezi službou, tak jak ji vidí administrátor, a službou, tak jako je dostupná v uživatelském rozhraní nebo ve filesystému. Na efektivní práci s distribucemi se systemd musí člověk přemýšlet na nižší úrovni abstrakce a znát věci více do detailu.
Tohle není ani tak záležitost systemd jako D-Busu.V případě NetworkManageru je to především věc systemd i když technicky vzato to dělá dbus, protože nebýt systemd, tak by se tam dbusová aktivace nepoužívala vůbec.
Že takový nástroj stejně nechytne všechno, protože pravidla polkitu se píší v turingovsky úplném jazyce, je poslední hřebík do rakve Linuxu jako jednoduchého operačního systému.Pořád ještě můžeš nad Linuxem a dalšími open source nástroji relativně jednoduchý operační systém postavit, ale holt to není o tom stáhnout si mainstreamovou distribuci a mít hotovo.
systemctl disable NetworkManager.service způsobí, že službu lze spustit jen ručně.Nikoliv, neplatí to pro služby Online-accounts ani Avahi, stále se spouští i po administrátorském příkazu. Takže ty příkazy jsou buď nefunkční nebo omezené. proč tam vůbec jsou ... Vím, že způsob komentování, mazání nebo přejmenování v systémovém souboru není doporučovaný, což asi stále mnozí buď neví, nebo nechtějí vědět, nebo nečtou hlavičky v tom souboru. Protože cesta k změně je vytvoření změněného obsahu v uživatelském profilu. Nástroje v gui jsou pro srandu králikům a nefunkčnost ani terminálového příkazu k tomu určeného je už vrchol. Nicméně mě už nebaví, řešit linuxové nedodělky a ignoranstství některých vývojářů a koupím raději Windows 10, kde nebudu muset řešit už od instalace nedodělky a aktualizace dalších nedodělků, včetně problémového správce sítě, protože Linux bez síťě je čtvrteční.
Jestli tomu dobře rozumím, tak disable je něco jako smazání linku z /etc/rcX.d/. Pokud chceš opravdu zakázat službu, tak můžeš dát mask, které je ekvivalent nahrazení souboru v /etc/init.d/ prázdným souborem.Přesně tak, a důležitá věc je i to, že disable je negativní (opak k enable), zatímci mask je pozitivní. Po dobu runtime umí systemd přerazit konfiguraci jen pozitivní změnou, tedy s
--runtime funguje jenom mask a nikoli disable.
Výsledek celé diskuze je tedy takový, že systemd nemá prostředek, jak obecně nějakou službu zastavit a mít jistotu, že nenastartuje.Nemá takový prostředek pro dbusové služby, ale s kdbusem se to má změnit. Nicméně i tak budeš muset zastavovat dvě různé jednotky, protože ovládání systemd se odvíjí od jeho implementačních detailů a nikoli od potřeb administrátora.
Kde je tedy reálný přínos systemd? Rychlý start je v současnosti nezajímavý -- co se vypíná, to se uspává. Výkonu je taky na rozdávání, takže služba může běžet od startu a ne až na požádání a ztrácím kontrolu nad službami systému. Prosím jen fundované odpovědi, nechci flame.Vždyť je to typický flamebait, systemd linuxáky hodně rozděluje, nemůžeš si vybírat, jaké reakce dostaneš a jak budou fundované.
A vznikl Wayland. Je tu, ale nikdo mne nenutí ho používat.Zatím tě nikdo nenutí ho používat, přesněji řečeno zatím někoho ještě baví starat se o Xorg a udržovat s ním aplikace kompatibilní.
Pak tu máme systemd, který někdo prokřičel do distribucíJinými slovy ho distribuce přijaly, ať už z jakýchkoli důvodů. Nicméně tenhle způsob vyjádření už vůbec nevede k fundovaným reakcím, ale je to jen podtržení toho flamebait. Doporučuju se především zaměřit na ty, kteří měli možnost toto rozhodnout, a na jejich zdůvodnění.
Nicméně i tak budeš muset zastavovat dvě různé jednotky, protože ovládání systemd se odvíjí od jeho implementačních detailů a nikoli od potřeb administrátora.... ale já jako administrátor potřebuji dosáhnout určitého cíle. K čemu je mi implementace, která k cíli nevede?
Jinými slovy ho distribuce přijaly, ať už z jakýchkoli důvodů. Nicméně tenhle způsob vyjádření už vůbec nevede k fundovaným reakcím, ale je to jen podtržení toho flamebait. Doporučuju se především zaměřit na ty, kteří měli možnost toto rozhodnout, a na jejich zdůvodnění.To bylo jen srovnání s projektem, který má přinést podobnou revoluci do světa Linuxu. A souhlasím, nechal jsem se trochu unést.
... ale já jako administrátor potřebuji dosáhnout určitého cíle. K čemu je mi implementace, která k cíli nevede?To je hluboce filosofická otázka. :)
Tiskni
Sdílej: