plwm je nový, poměrně minimalistický správce oken pro X11. Podporuje dynamické dláždění okny, plochy, pravidla pro okna atd. Zvláštností je, že je napsaný v logickém programovacím jazyce Prolog. Používá implementaci SWI-Prolog.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Sean Heelan se na svém blogu rozepsal o tom, jak pomocí OpenAI o3 nalezl vzdálenou zranitelnost nultého dne CVE-2025-37899 v Linuxu v implementaci SMB.
Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."
Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 26 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.
Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Java má dnes 30. narozeniny. Veřejnosti byla představena 23. května 1995.
Aktuální vývojová verze jádra je 3.15-rc4 vydaná 4. května. Linus říká: Několik známých problémů ještě čeká na opravu (například zajímavé poškození seznamu dentries – při normálním používání byste na to ale nenarazili), obecně to ale probíhá v poklidu a nic mě neděsí. Jsme v půli období zklidnění a tak to mám rád.
Stabilní aktualizace: verze 3.14.3, 3.10.39 a 3.4.89 vyšly 6. května s obvyklou dávkou důležitých oprav.
Každá nová kombinace v konfiguraci je novou situací, která při testování konkuruje ostatním.
-- David Miller
Okolo patchů udržovaných mimo strom oprávněně panuje jisté stigma, ve kterém jde přibližně o to, že „lidé by měli patche předávat do upstreamu, patche mimo strom bychom neměli podporovat a ani se o ně starat“. Ale to funguje, jen pokud reagujeme na zaslané patche slovy „Ne, protože musíš opravit X, Y a Z“ nebo „Ne, protože vašemu případu užití lépe poslouží stávající mechanismy, co už v jádře jsou“, nikoliv však „Ne, váš případ užití není validní“.
Pokud používáte glibc a nástroje GNU, tak to nebude fungovat, ale před dlouhou dobou byly napsány nástroje, které odváděly právě tu práci, co měly, a byly drobné a čisté. Programátoři měli k jejich kombinaci za složitějšími úkoly používat shellové skripty, než aby to bylo tak, že jednou za rok někdo na světě spustí nějakou hloupost od GNU jako --naformátuj-na-bok-a-zpívej --melodie=matyldin-valčík.
-- Alan Cox
Co se ohlašování [dlouhodobě udržovaných stabilních vydání] předem týče, už to nikdy neudělám, následky byly hrozné, jelikož tam lidé cpali věci, které tam nemají být. Dokonce jakmile lidé vědí, z kterých verzí budou enterprise jádra, tak začnou do upstreamu cpát věci „předem“, takže se tento problém opakuje.
Vyšel GlusterFS ve verzi 3.5. Mezi nové funkce patří lepší logování, možnost pořizovat snapshoty jednotlivých souborů (zatím není možné dělat snapshoty celých jednotek), komprese při přenosu, šifrování na disku a lepší podpora geo-replikace.
Systémové volání remap_file_pages() je taková podivnost; umožňuje procesu vytvořit složité, nelineární mapování mezi svým adresním prostorem a příslušným souborem. Takového mapování lze dosáhnout i pomocí několika volání mmap(), ale náklady na straně jádra jsou pak vyšší: každé volání mmap() vytvoří v jádře oddělenou oblast virtuální paměti (VMA), zatímco remap_file_pages() si vystačí s jedinou. Pokud má v sobě mapování velké množství skoků, pak může být rozdíl na straně jádra významný.
remap_file_pages() má ale malé množství uživatelů. Je jich tak málo, že Kirill Shutemov poslal patch, který volání zcela odstraňuje. Říká: Nelineární mapování se těžko podporují a jelikož jsou teď 64bitové systémy běžně dostupné, tak to vypadá, že už nejsou žádné legitimní případy užití." Patch zatím nenavrhuje k začlenění, je to zatím jen koncept.
Není těžké pochopit, proč je tato změna zajímavá; odstraňuje z jádra přes 600 řádek záludného kódu. K odstranění ale nedojde, pokud se bude považovat za porušení ABI. Někteří jaderní vývojáři evidentně věří, že si odstranění remap_file_pages() nikdo nevšimne, ale od dojmu k potenciálnímu rozbití aplikací vede dlouhá cesta. Proto se mluví o přidání varování; Peter Zijlstra navrhl jít o krok dál a vyžadovat pro aktivaci systémového volání nastavení volby přes sysctl. To by navíc pomohlo zjistit, jestli by se současní uživatelé remap_file_pages() ozvali; když se ozvou hned, předejdou tak problémům v budoucnosti.
Zaslání patche zmenšujícího jádro vyvolalo rozsáhlejší debatu o tom, co se musí s jádrem udělat, aby se vešlo na drobné systémy, ale také o tom, jestli jde vlastně o něco, o co se chce komunita vůbec pokusit.
Šlo o patch o 24 částech od Andiho Kleena, který přidává do sestavování možnost sestavit minimalistický síťový subsystém. Andiho zajímá možnost běhu Linuxu na systémech s pouhými 2 MB paměti; na těchto systémech, když síťová vrstva v Linuxu představuje zátěž 400 KB jen pro základní podporu IPv4, je problém něco takového mít. Odstraněním řady funkcí, změněním některých datových struktur a používáním LTO k odstranění nepotřebného kódu se Andimu podařilo kód zredukovat na 170 KB. To vypadá jako užitečné zlepšení, ale jak brzy uvidíme, cesta do jádra nebude úplně hladká.
Mezi změny v Andiho patchi patří:
Výše uvedený výčet by mohl být kratší, ale asi vám už je jasné, jak to dopadlo: patch nebyl komunitou okolo síťování přijat s otevřenou náručí. Tato komunita je silně zaměřená na výkon a funkce současného hardwaru; síťoví vývojáři (nebo alespoň někteří z nich) nechtějí být obtěžováni výzvami, které přináší podpora uživatelů na drobných systémech. Eric Dumazet to shrnul slovy:
Kdysi jsem začal používat Linux na počítačích typu 386/486, které měly více než 2 MB paměti, takže jsem smutný z toho, že chceme spouštět linux-3.16 na takovém typu hardwaru a trávit čas tím, že na pár místech ušetříme několik KB.
Vývojáři síťové vrstvy také nechtějí, aby začali dostávat hlášení chyb od uživatelů se silně odlehčenou síťovou vrstvou a museli pak přemýšlet, jak to, že to přestalo chodit. Na to by jistě došlo, jakmile by podobné patche byly začleněny. Člověk si může představit, jaká funkčnost je naprosto zásadní a jaká je na drobných systémech volitelná, ale různí uživatelé dojdou k různým závěrům. Jediná volba „zmenši to“ může třeba poskytnout síťovou vrstvu pokrývající 99 % potřeb uživatelů drobných systémů – ale chybějící 1 % se bude u každého uživatele lišit.
Poukazovat na některé těžkosti spojené s takovým úsilím pořád neznamená říkat, že by se jádro nemělo snažit malé systémy vůbec podporovat, ale právě to zdá se lidé od síťování říkají. V jeden moment Andi poslal správci síťové vrstvy Davidu Millerovi přímou otázku: Které části bys odstranil ty, abys snížil využití paměti pro 2MB jednoúčelový stroj?„ Davidova odpověď byla jednoduchá: Nepoužil bych Linux, tečka. Možná před dvaceti lety, ale ne teď, tyhle časy jsou už pryč. Jinými slovy, bychom se podle něj neměli ani snažit o to spouštět Linux na takových strojích; namísto toho bychom měli použít nějaký specializovaný operační systém.
Tento přístup může pro mnoho dlouholetých pozorovatelů linuxové komunity být překvapivý. Jaderní vývojáři obecně vždy usilovali o to, aby systém fungoval na pokud možno jakémkoliv hardwaru. Odpověď typu „jdi pryč a používej něco jiného“ byla jen výjimečně slýchána v souvislosti s proprietárním a uzavřeným hardwarem, ale i v těchto případech to s Linuxem nakonec někdo obvykle rozchodí. Tentokrát tu ale máme typ hardwaru, na kterém by Linux mohl běžet, s uživateli, kteří by tam Linux rádi používali, ale nějací jaderní vývojáři jim říkají, že nemají zájem pro ně přidávat podporu. To není vzkaz, který uvítají.
Bylo nebylo, výrobci mainframů se kdysi posmívali minipočítačům – až do doby, než mnoho z jejich zákazníků přešlo na minipočítače. Výrobci minipočítačů vnímali pracovní stanice, osobní počítače a Unix jako hračky; jen málo takových společností tu je s námi doteď. Mnozí z nás si pamatují, jak svět proprietárního Unixu vnímal Linux v době, kdy začínal: mávali nad ním rukou, protože jej brali jako chabou hračku, která nestojí za pozornost. Stačí poznamenat, že dnes toho o proprietárním Unixu moc neslyšíme. Je to typický příběh o tom, jak průlomové technologie dělají čáru přes rozpočet zavedeným firmám.
Není jasné, jestli mikroskopické systémy představují zrovna takový typ průlomových technologií; přístup „počkat, než hardware dozraje“ pro Linux v minulosti často fungoval dobře. Obvykle je bezpečné sázet na to, že výpočetní schopnosti v budoucnosti porostou, takže úsilí spojené s podporou nevýkonných systémů za to často nestojí. Možná se ale setkáváme s novou kategorií hardwaru, kdy „menší a levnější“ je důležitější než „výkonnější“. Pokud bude možné tyto systémy vyrábět ve velkém a šířit je jako „chytrý prach“, pak se mohou stát důležitou součástí výpočetní techniky budoucnosti.
Proto by možnost, že by budoucí drobné systémy mohly ohrozit Linux, měla určitě být zvážena. Pokud Linux na těchto zařízeních nepoběží, tak něco jiného ano. Možná to bude linuxové jádro se síťovou vrstvou kompletně nahrazenou něčím v uživatelském prostoru jako lwIP nebo to třeba bude nějaký jiný svobodný operační systém, jehož komunita bude mít o podporu tohoto hardwaru větší zájem. Nebo to možná bude něco proprietárního a nepříjemného. Jakkoliv se tato situace vyvine, bylo by smutné jednoho dne vzpomínat a říkat si, že vývojáři Linuxu mohli jádro rozchodit na důležitém typu počítačů, ale rozhodli se, že tak neučiní.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Pokiaľ nebude riešená bezpečnosť týchto systémov, tak je lepšie keď zostanú za NAT. Na riadenie domácich spotrebičov je vhodnejšie riešenie na základe PLC. Kde je väčšia šanca, že pri chybe to nezlikviduje spotrebič.