Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Začleňovací okno 4.6 zůstává i nadále otevřeno. Viz článek o novinkách, které byly začleněny za poslední týden.
Stabilní aktualizace: Žádné nebyly vydány, žádné nejsou v procesu revidování.
Mám úplně zavařený mozek, jak týdny koukám na výsledky fuzzingu, měl bych nějakou dobu dělat něco jiného… cokoliv jiného.
-Peter Zijlstra k málo známým nebezpečím současných debuggovacích metod
V době psaní tohoto článku začlenil Linus 11 118 neslučovacích sad změn vývojového cyklu 4.6 do hlavního repozitáře. Zhruba 10 000 jich přibylo od shrnutí z minulého týdne. Příliv patchů se již nedá popsat jako „pomalý“. V jejich záplavě můžeme najít spoustu významných novinek.
Mezi ty nejvýrazněji viditelné pro uživatele patří:
gpio_chip
je nyní skutečným zařízením v modelu zařízení. K získávání informací o GPIO slouží nové ABI, ale ještě je třeba něco dodělat. Linus Walleij k tomu podotkl: „Nyní můžeme GPIO pořádně detekovat z uživatelského prostoru. Stále jsme však nepřišli se způsobem, jak GPIO z uživatelského prostoru použít.“ Viz tools/gpio/lsgpio.c
pro ukázku nového ABI. Původní ABI sysfs je nyní považováno za zastaralé (ale ještě nebylo kompletně nahrazeno)./proc/PID/timerslack_ns
.tcp_syn_retries, tcp_synack_retries, tcp_syncookies, tcp_reordering, tcp_retries1, tcp_retries2, tcp_orphan_retries, tcp_fin_timeout, tcp_notsent_lowat, igmp_max_memberships, igmp_max_msf, igmp_llm_reports
a igmp_qrv
) si je nově vědomý síťového jmenného prostoru, takže různé jmenné prostory mohou mít různé hodnoty.Documentation/networking/checksum-offloads.txt
.Změny viditelné pro vývojáře jádra:
K dispozici je nová funkce pro uvolňování sady objektů:
void kfree_bulk(size_t size, void **objects);
Od kmem_cache_free_bulk() se liší absencí ukazatele na strukturu kmem_cache, což znamená, že je možné uvolnit objekty z vícero slabů současně. Tato metoda něco stojí, takže někdy se doporučuje používat kmem_cache_free_bulk().
%[
(např. %[abc]
k nalezení některého abc). Porovnávány mohou být pouze explicitně vyjmenované skupiny, "-" nemá v setu znaků žádný speciální význam.V tuto chvíli to vypadá, že většina změn již byla v tomto vývojovém cyklu začleněna. Okno pravděpodobně zůstane otevřené do 27. března (tzn. nyní je již zavřené), takže je možné, že se ještě něco zajímavého objeví. Příští týden se Jaderné noviny budou věnovat shrnutí významných změn, které se objeví na konci začleňovacího okna 4.6.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Většina commitů přichází prostřednictvím pull requestů (příklad) od maintainerů jednotlivých subsystémů. Patche z toho pull requestu už předtím prošly review buď přímo příslušným maintainerem subsystému nebo maintainery jednotlivých menších částí (v tomto případě např. netfilter nebo IPsec). Linus pak neprochází každý jednotlivý patch, ale jen to, co ho z nějakého důvodu zaujme.
Ten post Jardika neni az tak mimo.
Hm… vy opravdu věříte tomu, že "Jardík" při každém updatu každého balíčku prochází kompletní diff natolik důkladně, aby odhalil případný backdoor? A že i v případě jádra mu to trvá jen "celý den"? Kdyby takový člověk existoval, určitě by neřešil otázku, jak sehnat práci, kam by nemusel dojíždět, protože by ho několik firem ochotně zaměstnalo, i kdyby trval na tom, že bude pracovat na home office z vily na Malibu, kterou mu tam firma bude muset postavit a platit její provoz.
Co se týká toho zbytku, jak byste si to tedy představoval jinak? Že se vývoj jádra zpomalí natolik, aby Linus osobně stíhal dělat důkladný review každého jednotlivého patche? Že se omezí jeho velikost natolik, aby Linus dostatečně detailně rozuměl celému stromu? A hlavně: když nedůvěřujete maintainerům jednotlivých subsystémů, proč absolutně důvěřujete Linusovi?
Verim spise mnozstvi vyvojaru kteri pohledem do konkretni casti kodu a jeho ladenim mohou odhalit mnohem drive prusvih - diky otevrenosti, nez v uplne uzavrenem kodu.
Tak to v podstatě funguje. V těch exponovanějších částech jádra se patch typicky pošle do příslušného mailinglistu, kde se má možnost vyjádřit každý, koho to zajímá. Pak je nějakou dobu v gitu příslušného subsystému (u větších a kontroverznějších featur může trvat i několik vývojových cyklů, než se vůbec dostane tam), z něj teprve následuje pull request do Linusova stromu a i tam de facto čeká skoro dva měsíce, než se dostane do release. U bugfixů je celý proces rychlejší, ale ty zase bývají méně rozsáhlé a méně komplikované.