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).
Do konference přišlo celkem 1935 emailů, nejvíce jich poslali Greg KH, Adrian Bunk a Andrew Morton.
31. říj - 4. lis
Russell King napsal:
Ok, tohle je zásadní aktualizace. Obsahuje:
register_serial/unregister_serial už se nepoužívá. Místo toho používejte ke komunikaci s ovladačem 8250 serial8250_register_port() a serial8250_unregister_port().
Stará rozhraní mají několik omezení:
Patch má asi 50K, takže neprojde do LKML. Najdete jej tedy zde:
http://www.arm.linux.org.uk/~rmk/misc/linus-serial.diff
Patch by měli určitě otestovat lidi, kteří používají:
Jakmile to bude začleněno, začnu posílat další patche, které budou odstraňovat tabulky sériových zařízení v include/asm-arm/arch-*/serial.h.
Pár lidí nemělo s testy problémy, ale dalším se nedařilo patch aplikovat na současný Linusův BitKeeper strom. Proběhlo ještě pár patchů a v jednu chvíli se Russell zeptal Andrew Mortona: Chtěl bys, aby se tyhle změny nejprve objevily v jednom -mm jádře, předtím než půjdou k Linusovi? Andrew odpověděl: Ani ne - máme spoustu času na zachycení všech chyb.
3. lis - 10. lis
Timothy Miller se zeptal, proč se věnuje tolik úsilí podpoře starších verzí kompilátorů GCC. Jsou-li lidi ochotni upgradovat jádro, nebudou také ochotni upgradovat překladač? Matti Aarnio poznamenal, že nejnovější a nejskvělejší kompilátory nejsou vždy tak skvělé i na jiných architekturách. Giacomo A. Catenazzi podotkl, že kdyby byli lidi přinuceni používat nejnovější kompilátory, přispělo by to k rychlejšímu odhalení chyb v těchto překladačích. Chris Wedgwood oponoval: Problém je, že já chci zkompilovat funkční kernel *teď*, ne čekat, až budou v GCC opraveny chyby, které se tam pro mou architekturu dostaly s verzí 3.2.3. Takže já si zatím ponechám 3.2.2 (za 3.2.2 si klidně dosaďte jakoukoliv verzi). A Miles Bader dodal:
Tohle je dvojnásob pravda na okrajových architekturách.
Např. když pro své CPU používáš kompilátor, který je oproti běžnému gcc pozměněný, výrobce, který změny provedl, dodává nové verze se zpožděním oproti běžnému gcc, a ty změny jsou tak komplexní, že to nechceš opravovat sám.
Máme sice GPL, takže je _možné_ udělat to sám a zprovoznit i nové gcc, ale někdy je fajn mít také možnost nemuset...
Na jiném místě redukoval Christoph Hellwig celý problém na rychlost: Lidi chtějí používat starší překladače proto, že ty nové jsou o hodně pomalejší. Díky tomuto argumentu se rozvinulo nové velké podvlákno. Adam Heath nevěřil vlastním očím a odsekl: To snad nemyslíš vážně, že by tohle byl problém. Ale Martin J. Bligh napsal: Je to pravda. Většinou navíc produkují větší a pomalejší kód. A Chris reagoval: Zkus si to. Řekněme gcc 2.95 vs. gcc 4.0... Když jsem to zkoušel naposledy, byla starší verze více jak dvakrát rychlejší. Adam řekl, že se nepře o tom, jestli tam rozdíl v rychlosti je nebo není, ale o tom, jestli to tolik vadí: Jak často si kompiluješ jádro? To se ukázalo být nevhodným dotazem v konferenci vývojářů jádra. Chris Friesen odpověděl, že mnoho lidí v této konferenci jádro kompiluje několikrát denně. A Valdis Kletnieks napsal, že mnoho vývojářů používá starší hardware, na kterém může kompilace kernelu trvat i několik hodin. Adam několikrát zopakoval, že řešením je prostě koupit lepší hardware, ale to se také nesetkalo s pochopením. Několik lidí se přihlásilo s tím, že od Adama rádi přijmou darovaný hardware.
V jednu chvíli poznamenal Ioan Ionita: Nové verze gcc sice kompilují pomaleji, ale generují rychlejší kód.
Linus Torvalds také reagoval na Adamovo tvrzení, že doba kompilace není důležitá:
Zaprvé, pro mnohé lidi je kompilace jádra to hlavní, co jejich procesor dělá.
Zadruhé, nejde jen o to, že jsou ty kompilátory pomalejší. Nové verze gcc bývají:
Dlouhou dobu bylo jediným důvodem pro upgrade gcc podpora C++; základní podpora C šla v nových kompilátorech dolů v každém směru.
Poslední dobou se to trochu zlepšuje, ale do nějaké verze 3.3 nestála řada gcc-3.x kvůli běžnému C za upgrade.
Adam opět zopakoval, že by si lidi měli prostě pořídit lepší hardware, chtějí-li rychleji kompilovat. Linus odpověděl, že ne každý si to může dovolit, a že při výběru počítače nehraje roli pouze rychlost: I já preferuji spíše "pěkný a tichý" před absolutní rychlostí. A připojil: Tvůj argument "používejte nové verze, i když nejsou v ničem lepší" nedává smysl. Nejsou-li lepší, proč je používat? Xose Vazquez Perez odpověděl: Možná proto, že staré nejsou podporované... Adam Linusovi také odpověděl v tom smyslu, že chápe, když lidi používají starší verze, pokud produkují lepší kód. Tvrdil však, že rychlost kompilace sama o sobě není dostatečným důvodem pro použití starého kompilátoru: Pokud se lidi nebudou obtěžovat používat novější překladače kvůli jejich nedostatkům, nebudou ty problémy nikdy vyřešeny. Linus odpověděl:
Jediné, na čem záleží, je "co je nejlepší nástroj". A při vybírání nejlepšího nástroje hraje výkon svou roli. Není to jediný důvod, ale je dost zásadní.
Sám jsi to řekl, když jsi tvrdil, že by si lidi měli prostě koupit rychlejší hardware. Stroj, který používáš, je jedním z dalších nástrojů. Proč kupovat rychlejší stroj, kdyby na výkonu nezáleželo?
Nerozumím tomu, proč nejprve vypustíš výkon a pak ignoruješ i všechny další věci, které jsem popisoval.
A tvůj argument, že "problémy budou opraveny, budeš-li používat novou verzi" ve skutečnosti neplatí. Zaprvé, není-li problém ve staré verzi, vyřeší se to právě tím, že neupgraduješ.
A říct vývojáři "nepoužívám novou verzi proto, že ve srovnání s tou starou stojí za houby", to je úplně v pořádku. A je pravděpodobné, že to bude mít větší motivační účinek, než když uživatelé jako ovce poslušně přecházejí na nejnovější verzi.
Existují lidé, kteří používají Linux-2.0. A jsou asi i lidé, kteří používají dokonce Linux-1.2. A víš co, je to OK. Pro starší stroje to může být ta správná volba - zvláště pokud dělají totéž, co před několika lety. Tvrzení, že se musí upgradovat na nejnovější verzi, to je NESMYSL.
6. lis - 10. lis
Andries Brouwer si všiml, že nedávná oprava v jádře 2.6.9 odhalila větší problém s ovladačem myši pro PC110. Až do 2.6.9 nefungoval test prováděný tím ovladačem, takže nezískal přístup do paměti, ani nezabral IRQ. Když byl test opravený, myš získala IRQ i RAM, ale kolidovala s ethernetovou kartou, takže nefungovala síť. Myš se pak se svou RAM a IRQ pokusila o I/O, ale vrátily se jí chyba, a proto také nefungovala. Takže oprava v 2.6.9 způsobila, že nefungovalo ani síťování, ani myš.
Rychlou nápravou bylo nastavit při konfiguraci 'CONFIG_MOUSE_PC110PAD=n' a zakázat tak ovladač úplně, ale lepším řešením by bylo detekovat při startu konflikt, a kdyby nějaký problém byl, odmítnout ovladač myši natáhnout. Jenže nevěděl, jak hardware detekovat, takže se v konferenci zeptal, jestli by mu někdo neporadil.
Linus Torvalds navrhl linkovat ovladač do jádra až na poslední chvíli a tím dát ostatním ovladačům šanci zabrat zdroje, což by zabránilo vážnějšímu konfliktu. Ale řekl že nemá tušení, jak testovat přítomnost hardwaru. Zeptal se Alana Coxe, ale ten odpověděl: Mám nějaké informace o registrech. Ten ovladač byl napsán díky rozebrání ovladače pro PC-DOS, který IBM dodávala s PC110. Ten stroj ještě nemá PCI ani DMI, takže neexistuje žádný zřejmý způsob, jak to zjišťovat. Není to něco, bys chtěl vestavěné a ne jako modul na čemkoliv jiném než PC110. Linus odpověděl:
Aha, to je ale věc, kterou testovat můžeme: "má tento stroj PCI?".
Jinými slovy, můžeme mít jednoduchý test "není-li seznam PCI zařízení prázdný, ihned zastav". Nebo ne?
To by znamenalo, že (více méně) každý, kdo by ovladač natáhl omylem, by byl ušetřen starostí.
To se Alanovi líbilo a Linus poslal krátký patch, u kterého byl ve zdrojáku komentář: "Snažíme se vyhnout zapínání tohoto hardwaru, není-li přítomen. Ale nevíme, jak to zjistit. Víme však, že PC110 není PCI systém. Takže pokud nalezneme nějaká PCI zařízení, nejedná se o PC110." Andries i Alan potvrdili, že to na jejich strojích problém vyřešilo.
V originálu Kernel Traffic 285 vyšla navíc ještě tato témata:
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
(
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
include/linux/device.h)
Jinak díky za článek.