OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Současné vývojové jádro bylo 4.13-rc5 vydané 13. srpna.
Seznam regresí ze 12. srpna čítá 11 známých problémů v jádře 4.13-rc5.
Stabilní aktualizace: Tohle byl pro stabilní vydání rušný týden. Verze 4.12.6, 4.9.42, 4.4.81 a 3.18.64 byly vydány 11. srpna, rychle je následovaly verze 4.12.7, 4.9.43, 4.4.82 a 3.18.65 13. srpna. Dne 16. srpna byly vydány stabilní verze 4.12.8, 4.9.44, 4.4.83 a 3.18.66.
Mým kolegům správcům: Zůstaňte ostražití a nebojte se říkat „NE“ a „Proč?“ Špatných nápadů je víc než těch dobrých a složitost je pro nás hackery-můry jako svíčka. Ale buďte mírní, milí a odpouštějte svým kolegům: respekt od lidí, které respektujete je obvykle jediná odměna, která má hodnotu.
Sbohem všichni, těším se, až se zase potkáme!"
Scaling the kernel's MAINTAINERS file. Jonathan Corbet. 10. srpna 2017
Komunita vývojářů jádra je tak velká, že někdy není jasné, komu by se měl daný patch poslat. Jak komunita rostla, vyvinuly se v ní mechanismy pro sledování těchto informací zvláště v textovém souboru pojmenovaném MAINTAINERS. Nyní se však zdá, že má tento škálovací mechanismus vlastní problém se škálovatelností.
Soubor MAINTAINERS se nachází na vrcholku stromu se zdrojovými kódy jádra. Jedná se o prostý textový soubor s řadou polí, která popisují, jak jsou řízeny různé podsystémy jádra. Například následující záznam byl konzultován pro účely nedávného článku o problémech stromů zařízení:
OPEN FIRMWARE AND FLATTENED DEVICE TREE M: Rob Herring <robh+dt@———> M: Frank Rowand <frowand.list@———> L: devicetree@vger.kernel.org W: http://www.devicetree.org/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git S: Maintained F: drivers/of/ F: include/linux/of*.h F: scripts/dtc/ F: Documentation/ABI/testing/sysfs-firmware-ofw
Tento záznam říká, že subsystém zploštěných (flattened) stromů zařízení má dva správce (pole „M:
“), Roba Herringa a Franka Rowanda. Dále má zadanou poštovní konferenci (L:
) a webovou stránku (W:
), jakožto i strom subsystému v Gitu (T:
). Řádky začínající F:
popisují soubory a adresáře, které jsou považovány za součást subsystému. Soubor se dá číst v textovém editoru, ale často se s ním pracuje skrze skript get_maintainer.pl, který přečte patch a vygeneruje seznam adres, na které by daný patch měl být poslán.
Soubor je v současných jádrech delší než 14 tisíc řádků a obsahuje záznamy o více než 1700 jaderných subsystémech. Zdálo by se, že subsystémy jsou seřazeny podle abecedy, ale jak poznamenal Randy Dunlap v patchi z července, mnoho záznamů není na svém správném místě. Jeho patch se snažil tohle vyřešit, ale právě tady začaly skutečné problémy.
V tak velké komunitě, jako je ta jaderná, se změny subsystémů dějí často. Pokud dávají správní správci pozor, tyto změny vedou k patchům souboru MAINTAINERS – řádově stovkám patchů v každém vývojovém cyklu. Netřeba dodávat, že některé patche budou kolidovat s jinými, načež tenhle nepořádek musí odstranit Linus Torvalds. Když Dunlapův patch nevyhnutelně vyústil v konflikt při slučování, dal Torvalds najevo svou nespokojenost se souborem MAINTAINERS. Zeptal se, zda by soubor nešlo rozdělit.
Jeho původním návrhem bylo šířit informace o správcích stromem zdrojových kódů jádra, stejně jako byl rozdělen konfigurační soubor jádra počínaje vydáním 1.3.36. Později navrhl, že by informace o správcích mohla sídlit v souborech Kconfig
vedle konfiguračních voleb, i když tenhle nápad se daleko nedostal. Bez ohledu na konkrétní schéma, vysvětlil, by rozdělení informací o správcích ulehčilo řešení konfliktů.
Výhody méně frustrovaného Linus Torvaldse jsou zřejmé většině vývojářů jádra, takže zájem o vylepšení souboru MAINTAINERS je poměrně velký. Joe Perches navrhl rozdělit soubor MAINTAINERS do adresáře na nejvyšší úrovni stromu, což by umožnilo snadný přístup k informacím a skriptům by se s nimi také lépe pracovalo. A to by zřejmě opravdu mohla být cesta, kterou se věci budou ubírat.
Zůstává tedy otázka, jak soubor rozdělit. Další Torvaldsův návrh byl rozdělit soubor podle poštovních konferencí, aby všechny záznamy mířící do stejné konference skončily ve stejném souboru. Perches se ale vrátil se skriptem, který místo toho rozděluje soubor podle hierarchie adresářů. Výsledkem je 54 souborů, pojmenovaných namátkou arch_arm64, drivers_gpu_drm nebo filesystems
, v adresáři MAINTAINERS. Subsystémy, které neobsahují dostatečné množství záznamů, aby si zasloužily vlastní soubor, skončí v MAINTAINERS/MAINTAINERS.
Torvalds to vyzkoušel, ale rozhodl se, že tudy ne. Měl k rozdělení nějaké poznámky, ale dospěl k závěru, že „*něco* z toho vypadá velmi dobře.“ Ovšem obava, která věci zastavila, byla všem známá. Provedení této změny povede ke konfliktům při začleňováním dotýkajícím se libovolného stromu subsystému, který bude obsahovat změny souboru MAINTAINERS. Nejpravděpodobnějším řešením tohoto problému je provést změnu bezprostředně po vydání verze 4.14-rc1. Torvalds sice neslíbil, že se tomu tak stane, ale vypadá to, že k rozdělení MAINTAINERS v dohledné době opravdu dojde.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
MAINTAINERS
file. Takže se asi nic nestalo. Ví někdo proč?
git blame
? Není to poněkud zvrhlé?