Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
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é.