Ubuntu 26.10 bude Stonking Stingray (úžasný rejnok).
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.3.0. S experimentální podporou FLTK 1.4. S příkazem dilloc pro ovládání prohlížeče z příkazové řádky. Vývoj prohlížeče se přesunul z GitHubu na vlastní doménu dillo-browser.org (Git).
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vývojáři v přehledu vypíchli vylepšenou instalaci, podporu senzoru okolního světla, úsporu energie, opravy Bluetooth nebo zlepšení audia. Vývoj lze podpořit na Open Collective a GitHub Sponsors.
raylib (Wikipedie), tj. multiplatformní open-source knihovna pro vývoj grafických aplikací a her, byla vydána ve verzi 6.0.
Nové verze AI modelů. Společnost OpenAI představila GPT‑5.5. Společnost DeepSeek představila DeepSeek V4.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 164 (pdf) a Hello World 29 (pdf).
Bylo oznámeno, že webový prohlížeč Opera GX zaměřený na hráče počítačových her je už také na Flathubu and Snapcraftu.
Akcionáři americké mediální společnosti Warner Bros. Discovery dnes schválili převzetí firmy konkurentem Paramount Skydance za zhruba 110 miliard dolarů (téměř 2,3 bilionu Kč). Firmy se na spojení dohodly v únoru. O část společnosti Warner Bros. Discovery dříve usilovala rovněž streamovací platforma Netflix, se svou nabídkou však neuspěla. Transakci ještě budou schvalovat regulační orgány, a to nejen ve Spojených státech, ale také
… více »Canonical vydal (email, blog, YouTube) Ubuntu 26.04 LTS Resolute Raccoon. Přehled novinek v poznámkách k vydání. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 11. vydání s dlouhodobou podporou (LTS).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Gitea (Wikipedie) byla vydána v nové verzi 1.26.0. Přehled novinek v příspěvku na blogu.
Aktuální vývojová verze jádra je 3.11-rc6 vydaná 18. srpna. Linus k ní řekl: Byl to vcelku poklidný týden a rc se rozhodně zmenšují. A to mě těší. Konec vývojového cyklu 3.11 se blíží.
Stabilní aktualizace: Greg Kroah-Hartman makal jako šroubek, 14. srpna vydal verze 3.10.7, 3.4.58 a 3.0.91 a 20. srpna vydal verze 3.10.8, 3.4.59 a 3.0.92. O pár hodin později vydal verze 3.10.9 a 3.0.93 s jediným patchem navíc, co opravoval problémy ve verzích 3.10.8 a 3.0.92. Aby předešel podobným problémům v budoucnu, tak aktuálně zvažuje úpravy v tom. jak bude vybírat patche pro stabilní vydání. Ve zkratce: až na urgentní opravy budou všechny patche čekat asi týden, než budou zařazeny do stabilního vydání.
Minulý týden ještě vyšly další aktualizace, a to 3.6.11.7 (19. srpna), 3.5.7.19 (20. srpna) a 3.5.7.20 (21. srpna).
Na Linux.com vyšel pohled na řídící skupiny (cgroups) zaměřený na problémy v aktuální implementaci a to, jak se budou opravovat. Článek řeší také to, jak systemd chystá podporu jednotné hierarchie řadičů namísto vícero hierarchií, co se používají teď. „To je částečně kvůli tomu, že cgroups přidávají dodatečnou složitost a režii do existujících subsystémů a přilepení načeho navrch je často cestou nejmenšího odporu,“ říká Tejun Heo, správce subsystému řídících skupin. "Spolu se skutečností, že cgroups prozkoumávají nové oblasti bez zavedených příkladů, které by bylo možné následovat, to vedlo k pochybným rozhodnutím v návrhu a relativně velké nekonzistenci.
Software Freedom Conservancy oznámilo, že pomohlo tomu, aby Samsung vydal svou implementaci systému souborů extFAT pod GPL. Kód byl dříve neoficiálně vydán poté, co jeho kopie unikla ze Samsungu. Hlavním cílem organizace vždy bylo a je pomáhat a radit s cílem dosáhnout nejlepšího řešení co se dodržování GPL týče. Conservancy je potěšeno, že bylo dosaženo správného výsledku: legitimního, úplného vydání kódu ze strany Samsungu, a to pod licencí Linuxu, tedy GPL verze 2.
V roce 2007 si vývojáři jádra uvědomili, že udržování času posledního přístupu k souboru („atime“) představuje nemalý výkonnostní problém. Aktualizace atime převedly všechny operace čtení na zápis, což značně zpomalovalo I/O subsystém. V reakci na to přibyla volba pro připojování „relatime“, která snížila četnost aktualizací atime na minimum bez rizika rozbití aplikací. Od té doby se o výkonnostních problémech spojených s aktualizací časových razítek moc neuvažovalo.
Až doteď. Unixové systémy pro každý soubor udržují tři časová razítka: kromě atime systém eviduje čas poslední změny v obsahu souboru („mtime“) a čas poslední změny v metadatech („ctime“). Na první pohled nevypadá vedení těchto razítek jako výkonnostní problém; aktualizace mtime nebo ctime vyžaduje opětovný zápis inode na disk, ale operace způsobující tento zápis samy o sobě spočívají v zápisu na disk. Takže by si člověk řekl, že dodatečná režie se v tom jednoduše ztratí.
Ukazuje se, že se najdou situace, kdy tomu tak není – při zápisu do souboru přes mapování vytvořené pomocí mmap(). Zapisovatelné mapované soubory jsou pro operační systém docela výzva: aplikace může změnit jakoukoliv část souboru pomocí jednoduchého zápisu do paměti bez upozornění jádra. Ale jádro se o zápisech musí nějak dozvědět, aby bylo možné upravená data zapsat zpět do trvalého úložiště. Proto, jakmile je soubor označen pro zápis a stránka je přenesena do paměti, jádro (v hardwaru) označí tuto stránku jako pouze ke čtení. Zápis do této stránky způsobí výpadek, takže jádro se dozví, že stránka byla upravena. V tento moment je možné učinit stránku zapisovatelnou, takže další změny už výpadek nezpůsobí; může zůstat zapisovatelnou do doby, než jádro stránku vyčistí zápisem na disk. Jakmile je stránka čistá, musí být opět označena jako jen ke čtení.
Jak Dave Chinner vysvětluje, problém je následující: jakmile jádro obdrží výpadek stránky a učiní stránku zapisovatelnou, tak musí aktualizovat časová razítka souboru a u některých systémů souborů i čítač revize souboru. K tomu dochází synchronně v transakci systému souborů během procesu obsluhy výpadku stránky a umožňování zápisu. Proto se rychlá operace změny stránky na zapisovatelnou stává náročnou operací na systému souborů a dochází k tomu vždy, když aplikace zapíše do čisté stránky. Pokud aplikace zapisuje mnoho stránek, které byly namapovány do paměti, tak bude následkem velké zpomalení. A většina tohoto úsilí je zbytečná: změny razítka se vzájemně přepisují, takže přežije jen ta poslední.
Shodou náhod má Andy Lutomirski aplikaci, na kterou tento problém těžce dopadá. O jeho předchozím úsilí výkonnostní problém vyřešit – MADV_WILLWRITE – se nedávno psalo tady. Není divu, že současné chování okolo aktualizací mtime a ctime se mu nezamlouvá. Navíc tvrdí, že současné chování je v rozporu se Single Unix Specification, které říká, že tato razítka musí být aktualizována mezi jakýmkoliv zápisem do stránky a buď následujícím voláním msync() nebo zpětným zápisem daných dat. Říká, že jádro aktuálně požadované chování neimplementuje.
Zejména poukazuje na to, že razítko je změněno po prvním zápisu do dané stránky. Po tomto prvním použití zůstává stránka zapisovatelnou a jádro nebude vědět o dalších úpravách, dokud nebude stránka zapsána. Pokud stránka zůstává v paměti dlouho (řadu sekund) před zápisem na disk – jak se často stává – pak bude razítko nesprávně ukazovat čas prvního zápisu, nikoliv posledního.
Ve snaze opravit problémy s výkonem i správností připravil Andy sadu patchů, které mění to, jak jsou aktualizace časových razítek řešeny. V tomto novém návrhu se časová razítka neaktualizují v moment, kdy je stránka učiněna zapisovatelnou; namísto tohoto je v příslušné struktuře address_space nastaven nový příznak (AS_CMTIME). Někdy v budoucnu pak jádro zavolá novou operaci flush_cmtime(), která systému souborů řekne, že časy inodu by měly být aktualizovány; k tomuto volání dojde v reakci na zpětný zápis nebo volání msync(). Proto pokud dojde k úpravě tisíců stránek před zpětným zápisem, všechny aktualizace časových razítek budou zjednodušeny do jediné transakce, což operaci podstatně urychlí. Navíc razítko bude odpovídat času poslední úpravy namísto první.
Kvůli tomtu přístupu se vynořily nějaké připomínky. Jedni mají obavu, že při ošetřování časových razítek a čísel revize systémů souborů exportovaných přes NFS platí přísné požadavky. Klienti NFS používají tato razítka k tomu, aby se dozvěděli, kdy jsou cachované kopie zastaralé; pokud jsou aktualizace razítek odkládané na později, je tu riziko, že by klient mohl po nějakou dobu pracovat se starými daty. Andy tvrdil, že při současném přístupu mohou razítka být špatně ještě mnohem déle, takže jeho patch představuje zlepšení, i když není dokonalý. David Lang navrhl, že dokonalosti by bylo dosaženo tím, že by se časová razítka aktualizovala v paměti při prvním zápisu, ale nedocházelo by k zápisu na disk; Andy v tom vidí přínos, ale ještě to neimplementoval.
V době psaní tohoto textu se reakce na tuto sadu patchů dotýkaly hlavně implementačních detailů. Andy bude v patchi muset změnit řadu věcí; je potřeba implementace v systémech souborů dalších než jen ext4 a rozšířit balíček xfstest, aby bylo dokázáno, že to funguje správně. Ale hlavní myšlenka už není kontroverzní. Pokud komunita neobrátí svůj postoj, pak se rychlejší obsluha výpadků u stránek mapovaných na soubor dostane do hlavní řady brzo.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Imho těžko může Microsoft někoho soudit za patenty. To byste museli používat kód MicrosoftuPo tomtu příspěvku nelze než odkázat na nějakou základní literaturu o (softwarových) patentech.