Harbor je open source registr kontejnerů – místo, kam si organizace ukládají obrazy kontejnerů, balíčky Helm, artefakty OCI i modely pro strojové učení. Patří k nejrozšířenějším řešením mezi těmi, kdo si registr provozují sami, a v nadaci CNCF má status graduovaného projektu, tedy nejvyšší stupeň zralosti. Od začátku k němu patřil ještě jeden kus techniky, o kterém se moc nemluví: Redis. Ve verzi 2.15.2 ho Harbor vyměnil za Valkey.

K čemu je registru rychlé úložiště

Harbor není prostý souborový server. Při každém nahrání nebo stažení obrazu odbavuje několik věcí zároveň a část z nich by hlavní databázi zbytečně zatěžovala. Proto k sobě od začátku měl Redis, rychlé úložiště, které data drží v paměti. Podle týmu Harboru na něm stojí čtyři věci:

• přihlašovací sezení uživatelů,
• vyrovnávací paměť manifestů, aby se popis obrazu (OCI manifest) při stažení nemusel pokaždé číst z databáze,
• fronta úloh na běh na pozadí – kontroly zranitelností, úklid nepoužitých dat a replikace mezi registry,
• počítadlo kvót, které hlídá, kolik obrazů se do jednoho projektu nahrává naráz.

Po výměně dělá Valkey přesně totéž. Uživatel ani provozovatel na sobě změnu nepozná, protože obě úložiště mluví stejným jazykem.

Co se stalo ve verzi 2.15.2

Tým Harboru otevřel návrh #22935 v březnu 2026 s jednoduchým zadáním: nahradit Redis Valkeyem ve všech místech, kde ho registr používá, a zařídit hladký přechod. Vlastní změnu přinesl pull request #23157, který se do hlavní větve dostal 28. dubna. K uživatelům ji tým poslal později, přenesením do opravného vydání: v poznámkách k verzi 2.15.2 je vedená jako přenesený commit „replace redis with valkey as cache backend“.

Technicky šlo o výměnu obrazu vnitřní cache. Harbor nově staví na obrazu valkey-photon, tedy Valkey postaveném nad distribucí Photon OS, ze které skládá i ostatní své součásti.

Proč pryč od Redisu

Důvod tým shrnul stroze: Redis v posledních letech opakovaně měnil licenci, a to je pro projekt, který na něm závisí, riziko. Redis si tou licenční houpačkou vážně prošel. V roce 2024 opustil svou původní licenci BSD a přešel na dvojici zdrojově dostupných licencí SSPL a RSAL, které Open Source Initiative za svobodné neuznává. Právě tehdy vznikl Valkey jako fork spravovaný nadací Linux Foundation. V květnu 2025 se Redis vrátil k otevřené licenci, když k osmé verzi přidal jako možnost AGPLv3, kterou už OSI schvaluje. Vývoj Redisu se od té doby nezastavil – v řadě 8 přišel třeba úspornější způsob ukládání hašů.

Přesto Harbor zvolil Valkey. Za rozhodnutím je podle týmu souběh několika věcí: permisivní licence BSD 3-Clause klade na uživatele méně omezení než copyleftová AGPL, projekt vede Linux Foundation s předvídatelným cyklem vydání a Valkey je zpětně kompatibilní na úrovni protokolu. Používá totiž stejný protokol RESP jako Redis, takže Harbor nemusel v kódu, který s úložištěm mluví, přepsat ani řádek; upravily se jen šablony obrazů.

O rychlost přitom nešlo. Valkey se sice chlubí tím, že se od svého základu ve verzi 7.2 zrychlil – jeho autoři uvádějí u verze 9.1 až dva miliony požadavků za sekundu ve vlastních měřeních, tedy víc než dvojnásobek –, jenže to je číslo výrobce a Harbor ho jako důvod přechodu neuvádí. Rozhodla licence a způsob správy, ne benchmark.

Přechod zatím není úplný

Jedna věc kulhá: oficiální šablona Helm, kterou většina lidí Harbor instaluje, se zatím neupravila a pořád jako výchozí stahuje obraz Redisu. Kdo chce Harbor s Valkeyem hned, musí obraz vnitřní cache přepsat ručně. V praxi to jsou dva parametry navíc při instalaci:

helm install harbor harbor/harbor \
  --set redis.internal.image.repository=goharbor/valkey-photon \
  --set redis.internal.image.tag=v2.15.2

První parametr říká šabloně, ať místo Redisu vezme obraz valkey-photon z Docker Hubu, druhý určuje jeho verzi. Až se výchozí hodnota v šabloně změní, odpadne i tohle.

Co z toho plyne

Výměna je z pohledu uživatele nenápadná a právě to je na ní podstatné: díky společnému protokolu šla provést, aniž by se venku cokoli pohnulo. Zapadá do širšího obrázku – Valkey dnes nabízejí jako spravovanou službu Amazon, Google i menší poskytovatelé a Harbor je jen jedním z větších projektů, které k němu od Redisu přešly. Kdo registr provozuje, si zatím vystačí se dvěma parametry navíc; zbytek se stane sám, až se doladí šablona.

Zdroje

• Harbor Chose Valkey, blog projektu Valkey, 28. července 2026
• Replace Redis with Valkey, návrh #22935 v repozitáři goharbor/harbor
• feat: replace redis with valkey as cache backend, pull request #23157
• Harbor v2.15.2, poznámky k vydání
• Redis is now available under the AGPLv3 open source license, blog Redisu, květen 2025

Běžná webová stránka se serveru ptá pořád stejně: pošle požadavek, dostane odpověď, spojení se zavře. Když má ale ukazovat něco, co se mění každou chvíli – zprávu v chatu, upozornění, číslo na živém přehledu –, tenhle model naráží. WebSocket ho řeší jinak: otevře jedno spojení a nechá ho otevřené oběma směry.

Proč se opakovaný dotaz nehodí na živá data

Nejjednodušší cesta k „živé“ stránce je HTTP polling: prohlížeč se v pravidelném intervalu ptá, jestli nejsou nová data. Každý dotaz je celý požadavek i s hlavičkami, i když odpověď zní „nic nového“, a interval se nedá nastavit dobře – krátký znamená spoustu prázdných dotazů, dlouhý zprávu se zpožděním. Navíc je to jednosměrné: server čeká, až se stránka zeptá. Šikovnější long polling (server odpověď drží, dokud nemá co poslat) zpoždění odstraní, ale je to jen obcházení toho, že HTTP na obousměrný provoz stavěné nebylo.

WebSocket: jedno spojení oběma směry

WebSocket je samostatný protokol popsaný v RFC 6455 (vydané v prosinci 2011). Spojení začíná jako obyčejný HTTP požadavek, který serveru řekne „přepni tohle spojení na WebSocket“ (handshake). Když server souhlasí, totéž TCP spojení zůstane otevřené a obě strany po něm můžou kdykoli posílat zprávy – bez nových hlaviček, bez čekání na dotaz. Adresa má schéma ws://, pro šifrovanou variantu wss://.

V prohlížeči se s tím pracuje přes objekt WebSocket: vytvoří se konstruktorem, poslouchají se události open, message, error a close, posílá se metodou send().

// Klient v prohlížeci
const socket = new WebSocket("wss://example.com/chat");

socket.addEventListener("open", () => {
  socket.send("ahoj");
});

socket.addEventListener("message", (event) => {
  console.log("prislo:", event.data);
});

socket.addEventListener("close", () => {
  console.log("spojeni se zavrelo");
});

Stav spojení drží vlastnost readyState. MDN u toho upozorňuje na jednu věc: WebSocket API neumí takzvaný backpressure – když zprávy chodí rychleji, než je stránka stíhá zpracovat, hromadí se v paměti a tempo si musí program ohlídat sám. Server se píše v Node.js, Pythonu nebo čemkoli jiném přes knihovnu pro daný jazyk.

Co k WebSocketu přidává socket.io

Holý WebSocket funguje, ale pár věcí neřeší: co když spojení spadne, co když ho podniková proxy nebo antivirus vůbec nepustí a jak zprávy rozlišovat podle druhu. Tyhle mezery zaplňuje socket.io, knihovna pro Node.js a prohlížeč, která nad WebSocketem staví pohodlnější vrstvu.

Uvnitř se dělí na dvě části. Spodní, Engine.IO, se stará o spojení a výběr přenosu. Má tři: HTTP long-polling, WebSocket a novější WebTransport. Trik je v pořadí: spojení se ve výchozím nastavení naváže nejdřív přes long-polling, který projde skoro všude, a teprve pak se po tichu povýší na WebSocket, pokud to jde. Tomuhle záložnímu chování se říká fallback a je to důvod, proč socket.io funguje i tam, kde čistý WebSocket neprojde. Horní vrstva pak přidává znovupřipojení, frontu neodeslaných zpráv, potvrzování doručení, skupiny (rooms) a jmenné prostory (namespaces).

Server se namontuje na HTTP server a poslouchá událost connection. Zprávy jsou pojmenované události – místo jednoho anonymního proudu dat má každý druh zprávy své jméno, na které se navěsí obsluha.

// Server (Node.js)
const { createServer } = require("node:http");
const { Server } = require("socket.io");

const server = createServer();
const io = new Server(server);

io.on("connection", (socket) => {
  console.log("klient se pripojil");

  socket.on("zprava", (text) => {
    io.emit("zprava", text); // rozesle vsem pripojenym
  });

  socket.on("disconnect", () => {
    console.log("klient odpojen");
  });
});

server.listen(3000);

Klient v prohlížeči je zrcadlo: zavolá io(), poslouchá stejné události přes on() a posílá je přes emit().

// Klient v prohlizeci
const socket = io();

socket.on("zprava", (text) => {
  // vykresli prichozi zpravu
});

socket.emit("zprava", "ahoj");

Volání io.emit() rozešle událost všem připojeným. To se ale hodí málokdy – zprávu z jedné chatovací místnosti nemají dostat všichni na webu.

Rooms: vysílání jen části klientů

Room je pojmenovaný kanál, do kterého socket vstoupí a zase z něj vystoupí. Je to čistě serverová věc – klient o seznamu svých místností nic neví. Vstup zařídí socket.join(), vysílání jen do dané místnosti pak io.to("nazev").emit(...).

io.on("connection", (socket) => {
  socket.join("mistnost-42");
});

// odejde jen do klientu v teto mistnosti
io.to("mistnost-42").emit("zprava", "ahoj mistnosti");

Vysílání z jednoho socketu přes socket.to("nazev").emit(...) dostanou všichni v místnosti kromě odesílatele – přesně to, co chatovací okno potřebuje. Při odpojení socket opustí všechny své místnosti sám. Rooms se hodí i na adresování jednoho uživatele: socket se přidá do místnosti pojmenované jeho identifikátorem a upozornění pak dorazí na všechny jeho karty a zařízení najednou.

Když spadne spojení

Jestli spojení žije, hlídá tlukot srdce (heartbeat): server v pravidelném intervalu (ve výchozím nastavení po zhruba 25 sekundách) pošle paket ping a čeká na pong; když se nevrátí, spojení se považuje za zavřené. Po výpadku se socket.io ve výchozím nastavení sám snaží připojit znovu – opakovaně a s prodlužujícími se odstupy, aby po pádu serveru nepřišla záplava dotazů naráz. Neodeslané zprávy počkají ve frontě.

Kdy stačí jednosměrné SSE

WebSocket ani socket.io nejsou vždycky potřeba. Když data tečou jen jedním směrem, ze serveru do prohlížeče, stačí lehčí nástroj: Server-Sent Events (SSE). Jede po obyčejném HTTP, v prohlížeči se obsluhuje objektem EventSource a znovupřipojení zvládá samo. Podle MDN je to jednosměrné spojení – klient přes něj serveru nic poslat nemůže.

const zdroj = new EventSource("/udalosti");

zdroj.onmessage = (event) => {
  console.log(event.data);
};

Na živé skóre, průběžné výsledky výpočtu, tok upozornění nebo streamování logu je SSE často přesně akorát: méně kódu než WebSocket a projde i přes prostředí, kde WebSocket vázne. Jakmile ale potřebujete posílat data i od klienta – typicky psát zprávy –, jednosměrný kanál nestačí a jste zpátky u WebSocketu.

Kdy realtime sáhnout

Ve zkratce tři případy. Když se data mění zřídka a pár sekund zpoždění nevadí, stačí obyčejný dotaz nebo občasný polling. Když server jen posílá a klient poslouchá (přehledy, upozornění, průběh), sáhněte po SSE. A teprve tam, kde spolu obě strany mluví oběma směry a na zpoždění záleží – chat, spolupráce v jednom dokumentu, hry, komunitní a chatovací weby –, se vyplatí WebSocket; a pokud chcete fallback, znovupřipojení a skupiny bez ručního dopisování, socket.io nad ním.

Za tu pohodlnou vrstvu se platí: socket.io přenáší data ve vlastním formátu, takže na druhém konci musí být zase socket.io, ne holý WebSocket klient. Kdo potřebuje mluvit s cizí službou nebo si vystačí s jedním druhem zpráv, bývá s čistým WebSocketem jednodušší. Co si vybrat, je hlavně otázka toho, kolik z přidaných funkcí opravdu využijete.

Zdroje

Zdroje: dokumentace socket.io, oddíl How it works (rozdělení na Engine.IO a socket.io, tři přenosy a povyšování spojení), tatáž dokumentace k rooms (rooms jsou serverový pojem, join a io.to().emit()), MDN: WebSocket (události, readyState a chybějící backpressure), RFC 6455 (standard protokolu, prosinec 2011) a MDN: Using server-sent events (SSE je jednosměrné).

Vite je nástroj, který stojí mezi vývojářem a prohlížečem: v jednom režimu obsluhuje kód, na kterém se právě pracuje, ve druhém z něj skládá balík pro nasazení. Ty dva režimy fungují každý jinak a právě v tom je jádro toho, proč je Vite rychlý. Vývojový server se rozjede skoro okamžitě i u velké aplikace, produkční build projde celý kód a zoptimalizuje ho. Následující řádky popisují, jak obojí funguje a kde jsou meze.

Vývojový server nad nativními ES moduly

Starší nástroje – bundlery jako webpack – musely před prvním zobrazením stránky projít celou aplikaci a slepit ji do jednoho souboru. Čím větší projekt, tím delší čekání. Vite tuhle práci rozdělí. Zdrojový kód aplikace, který se mění často, podává prohlížeči přes nativní ES moduly (ESM). Prohlížeč si o každý modul řekne sám ve chvíli, kdy ho potřebuje, a Vite ho v tu chvíli přepíše do podoby, které prohlížeč rozumí. Načte se jen to, co je pro aktuální stránku nutné, takže start serveru je takřka okamžitý bez ohledu na velikost projektu.

Výjimkou jsou knihovny z node_modules. Bývají jich stovky a nativní ESM neumí importy typu import { x } from 'knihovna' bez cesty k souboru. Vite je proto jednou předzpracuje (pre-bundling): převede starší formáty CommonJS a UMD na ESM a přepíše importy na platné adresy. Ve Vite 8 tohle dělá Rolldown, bundler psaný v Rustu; podle dokumentace je díky němu studený start výrazně rychlejší než u bundleru psaného v JavaScriptu. Výsledek se drží v mezipaměti, takže se předzpracování při dalších startech přeskočí.

HMR: výměna jednoho modulu za běhu

Když se soubor uloží, Vite nezahodí celou stránku. Přes rozhraní HMR (Hot Module Replacement, výměna modulů za běhu) vymění v prohlížeči jen ten modul, který se změnil, a nechá aplikaci ve stavu, v jakém byla – rozepsaný formulář zůstane vyplněný, otevřený panel otevřený. HMR jede taky přes nativní ESM. Frameworky se na něj napojují: Vite má vestavěnou podporu pro Vue single file components a pro React Fast Refresh. Aktualizace se podle dokumentace projeví v prohlížeči do 50 ms.

Produkční build: z modulů jeden balík

Pro nasazení se přístup obrací. Poslat do prohlížeče stovky samostatných souborů přes ESM by na produkci znamenalo stovky požadavků, takže tady Vite naopak bundluje. Build projde závislosti, vyhodí nepoužitý kód (tree-shaking), rozdělí výstup na části (code splitting), zmenší ho (minifikace) a do názvů souborů přidá otisk kvůli cachování.

Historicky na to Vite používal dva různé nástroje: esbuild pro rychlý překlad ve vývoji a Rollup pro důkladnou optimalizaci v produkci. Dvě odlišné pipeline ale znamenaly drobné rozdíly v chování a dvojí systém pluginů. Vite 8 je proto sjednotil do jednoho bundleru, Rolldownu. Ten je psaný v Rustu, k parsování a minifikaci používá Oxc a zůstává kompatibilní se stejným rozhraním pluginů, na které byl ekosystém Rollupu zvyklý. Nastavení buildu se ladí přes build.rolldownOptions.

import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    rolldownOptions: {
      input: {
        main: 'index.html',
        admin: 'admin.html',
      },
    },
  },
})

TypeScript: přepis bez kontroly typů

Soubory .ts umí Vite importovat rovnou, bez další konfigurace. Důležité je vědět, co přitom dělá a co ne: typy jen odstraní, nekontroluje je. Přepis (transpilaci) obstará Oxc, což je řádově rychlejší než klasický tsc – ale typová kontrola se přeskočí.

Není to nedodělek, ale záměr. Přepis běží po jednotlivých souborech a sedí na model, kdy se každý soubor zpracuje ve chvíli, kdy si o něj prohlížeč řekne. Kontrola typů oproti tomu potřebuje znát celý graf modulů; nacpat ji do téhle pipeline by srazilo rychlost, kvůli které Vite existuje. Typy se proto hlídají zvlášť – při buildu příkazem tsc --noEmit, během vývoje v editoru nebo přes tsc --noEmit --watch v samostatném procesu.

Protože Oxc přepisuje soubor bez znalosti typů z ostatních souborů, dokumentace doporučuje zapnout v tsconfig.json volbu isolatedModules a u importů, které slouží jen pro typy, používat import type.

// tsconfig.json: "isolatedModules": true

import type { User } from './types'

export type { User }

SCSS a další preprocesory

Vite zpracuje .scss, .sass, .less i .styl bez zvláštního pluginu – stačí doinstalovat samotný preprocesor. Pro Sass a SCSS je to jeden balíček:

npm add -D sass-embedded

Dokumentace zároveň u nových projektů doporučuje spíš nativní CSS proměnné a PostCSS než plný preprocesor; vestavěné SCSS je tu hlavně pro projekty, které ho už mají. Přípona .module.scss spojí preprocesor s CSS moduly.

Entry pointy a konfigurace

Vstupním bodem Vite není soubor s JavaScriptem, ale index.html. Vite v něm najde značky <script type="module"> a <link> a odtud sleduje, co všechno do aplikace patří. Víc stránek znamená víc HTML souborů zapsaných do pole input v konfiguraci (viz ukázka výše).

Celé se to ovládá třemi skripty v package.json, které do projektu vloží už zakládací nástroj:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

dev spustí vývojový server s HMR, build vyrobí produkční balík a preview ten hotový balík lokálně naservíruje ke kontrole, než se nasadí. Konfigurace přitom bývá pár řádků: u běžného projektu si Vite vystačí s výchozími hodnotami a do vite.config.ts se sahá jen kvůli pluginům, více vstupům nebo úpravě buildu.

Za rychlostí Vite tedy nestojí jeden trik, ale rozdělení práce – ve vývoji se nebundluje skoro nic a kód jde do prohlížeče tak, jak je, kdežto při buildu se bundluje naplno. Že je to rychlejší než starší celobundlové nástroje, ovšem stojí zatím hlavně na číslech z dokumentace samotného Vite; nezávislé měření tenhle text nepřebírá.

Zdroje

• Dokumentace Vite – Features: z ní text bere předzpracování závislostí Rolldownem, chování TypeScriptu (jen přepis, ne kontrola typů), podporu preprocesorů a skripty v package.json.
• Dokumentace Vite – Why Vite: odtud pochází historie dvojice esbuild a Rollup a jejich sjednocení do Rolldownu ve Vite 8.
• MDN – JavaScript modules: standard nativních ES modulů, na kterých vývojový server stojí.

Heslo je sdílené tajemství. Jeden řetězec zná uživatel i server a kdo ho získá, vydává se za majitele účtu. Podle průvodce webauthn.guide stojí za ukradeným nebo slabým heslem 81 % průniků spojených s hackingem. Heslo se dá vylákat podvodnou stránkou, vytáhnout z uniklé databáze nebo uhodnout, když ho uživatel použil i jinde.

Passkey tenhle model obrací. Místo jednoho tajemství vzniká dvojice klíčů a server nikdy nedostane nic, co by šlo zneužít. Standard, který to řídí, se jmenuje WebAuthn a píše ho W3C společně s aliancí FIDO.

Dvojice klíčů místo sdíleného tajemství

Passkey stojí na asymetrické kryptografii. Při registraci autentikátor – čip v telefonu, notebooku nebo v hardwarovém klíči – vytvoří dvojici matematicky svázaných klíčů. Soukromý klíč zůstane bezpečně uložený v zařízení a nikdy ho neopustí. Veřejný klíč spolu s náhodným identifikátorem přihlašovacího údaje putuje na server, který si ho uloží k účtu.

Veřejný klíč není tajný: bez odpovídajícího soukromého klíče se s ním nedá přihlásit. To má dopad na bezpečnost celé databáze. Únik tabulky s veřejnými klíči útočníkovi nepomůže, protože chybí ta druhá polovina páru. Vývojář navíc nemá co hašovat ani solit – veřejný klíč se ukládá tak, jak přišel.

Klíč patří jen jedné doméně

Nejdůležitější vlastnost passkey je, že klíč je svázaný s konkrétním původem (origin). Při registraci server uvede pole rp.id, takzvané relying party ID – identifikátor strany, která uživatele ověřuje. Musí to být doména, na které se stránka právě nachází, nebo její nadřazená doména. Dvojice klíčů vytvořená pro webauthn.guide se nedá použít na evil-webauthn.guide.

Odtud plyne odolnost vůči phishingu. Když uživatel omylem přistane na podvodné kopii přihlašovací stránky, prohlížeč jednoduše žádný klíč pro cizí doménu nenajde a podpis nevznikne. Autentikátor totiž do podepisovaných dat vkládá skutečný původ stránky; server pak ověří, že sedí s tím jeho. U hesla stačí, aby ho uživatel napsal do falešného pole. U passkey není co napsat a podvodná doména podpis nedostane.

Registrace: navigator.credentials.create()

Přihlašovací údaj vzniká v prohlížeči voláním navigator.credentials.create(). Server k němu dodá parametry – hlavně náhodnou výzvu (challenge), která musí mít aspoň 16 bajtů a brání přehrání zachycené odpovědi.

const publicKeyCredentialCreationOptions = {
  challenge: challengeFromServer,          // >= 16 nahodnych bajtu
  rp: { name: "Moje appka", id: "example.com" },
  user: {
    id: userIdBytes,                       // ne osobni udaj
    name: "lee@example.com",
    displayName: "Lee",
  },
  pubKeyCredParams: [{ alg: -7, type: "public-key" }], // ES256
  authenticatorSelection: { authenticatorAttachment: "platform" },
  timeout: 60000,
  attestation: "none",
};

const credential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions,
});

Hodnota alg: -7 odkazuje do registru COSE a znamená ECDSA nad křivkou P-256 s hašem SHA-256 – nejběžnější volba. Pole attestation říká, jak moc server stojí o doklad původu autentikátoru; hodnota none znamená, že se o něj nezajímá, a pro většinu webů je to správně. Výsledný objekt obsahuje veřejný klíč zabalený v response.attestationObject a posílá se na server k uložení.

Přihlášení: navigator.credentials.get()

Při přihlášení uživatel dokazuje, že soukromý klíč vlastní. Server pošle novou výzvu, prohlídač zavolá navigator.credentials.get() a autentikátor výzvu podepíše – vznikne assertion, tedy podepsané tvrzení.

const publicKeyCredentialRequestOptions = {
  challenge: challengeFromServer,
  allowCredentials: [{
    id: credentialIdBytes,                 // ulozene pri registraci
    type: "public-key",
    transports: ["usb", "ble", "nfc", "internal"],
  }],
  timeout: 60000,
};

const assertion = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions,
});

Server podpis ověří veřejným klíčem uloženým při registraci. Zkontroluje tři věci: že podepsaná výzva odpovídá té, kterou vydal, že sedí původ stránky a že sedí relying party ID. Když všechno platí, přihlášení je hotové – a po síti přitom nikdy neproletělo žádné tajemství.

Autentikátor v telefonu, nebo na klíčence

Autentikátory se dělí na dva druhy a výběr řídí pole authenticatorAttachment:

• Platform autentikátor je zabudovaný v zařízení – Windows Hello, Touch ID nebo Face ID. Je po ruce, ale je vázaný na ten konkrétní přístroj.
• Roaming (v API cross-platform) je přenosný. Typicky hardwarový klíč, který se připojí přes USB, NFC nebo Bluetooth a dá se použít na víc počítačích.

S tím souvisí ještě jedno dělení. Discoverable přihlašovací údaj (dřív se říkalo resident key) si autentikátor pamatuje celý včetně jména účtu, takže uživatel nemusí zadávat login – prohlížeč sám nabídne, s kterým účtem se přihlásit. Passkey je z definice vždy discoverable. U non-discoverable údaje se naopak klíč ukládá zašifrovaný na serveru a uživatel musí nejdřív říct, kdo je.

Kde do toho zapadá FIDO2

WebAuthn není osamocený. Je to browserová část většího celku zvaného FIDO2, který tvoří dvě specifikace. WebAuthn od W3C pokrývá API mezi webovou stránkou a prohlížečem. Druhá půlka je CTAP (Client to Authenticator Protocol) od aliance FIDO – protokol mezi prohlížečem a samotným autentikátorem. CTAP řeší, jak si spolu povídá počítač a bezpečnostní klíč nebo telefon.

Na CTAP stojí i přihlášení napříč zařízeními: passkey z telefonu jde použít při přihlášení na notebooku. Alliance FIDO tomu říká Cross-Device Authentication a jede po přenosu „hybrid“, který přes Bluetooth Low Energy ověří, že obě zařízení jsou opravdu blízko sebe. Pro vývojáře webu je podstatné, že CTAP implementují prohlížeče a autentikátory, ne server – ten vidí jen WebAuthn.

Ověření na serveru v PHP

Klientská část je jen půlka práce. Odpověď autentikátoru musí server rozebrat a ověřit, a to není triviální – specifikace popisuje u registrace vícebodovou proceduru. V PHP tuhle práci obstará knihovna web-auth/webauthn-lib od Spomky-Labs, dostupná i jako balíček pro Symfony.

composer require web-auth/webauthn-lib

Nejdřív se sestaví serializer, který převede zakódovaná data z prohlížeče na objekty, a správce podpory attestation. Pro běžný web bez potřeby dokládat model autentikátoru stačí typ none.

<?php

declare(strict_types=1);

use Webauthn\AttestationStatement\AttestationStatementSupportManager;
use Webauthn\AttestationStatement\NoneAttestationStatementSupport;
use Webauthn\Denormalizer\WebauthnSerializerFactory;

$attestationManager = AttestationStatementSupportManager::create();
$attestationManager->add(NoneAttestationStatementSupport::create());

$serializer = (new WebauthnSerializerFactory($attestationManager))->create();

Vlastní kontrolu obstarají dva validátory – jeden pro registraci (attestation), druhý pro přihlášení (assertion). Oba dostanou takzvaný Ceremony Step Manager, který v sobě nese jednotlivé ověřovací kroky.

<?php

use Webauthn\AuthenticatorAssertionResponseValidator;
use Webauthn\AuthenticatorAttestationResponseValidator;
use Webauthn\CeremonyStep\CeremonyStepManagerFactory;

$csmFactory = new CeremonyStepManagerFactory();

$attestationValidator = AuthenticatorAttestationResponseValidator::create(
    $csmFactory->creationCeremony()
);
$assertionValidator = AuthenticatorAssertionResponseValidator::create(
    $csmFactory->requestCeremony()
);

Validátor pak nad přijatou odpovědí ověří podpis, výzvu, původ i relying party ID a vrátí záznam přihlašovacího údaje k uložení. Tím se kruh uzavírá: klíč vytvořený v prohlížeči má na serveru protějšek, který ho umí zkontrolovat, aniž by kdy potřeboval znát nějaké heslo.

Zdroje

• MDN: Web Authentication API – průběh registrace a přihlášení, discoverable klíče, platform vs. roaming autentikátor.
• webauthn.guide – vázání klíče na doménu, ukázky volání create() a get(), údaj o 81 % průniků přes hesla.
• FIDO Alliance: FIDO2 – že FIDO2 tvoří WebAuthn a CTAP a jak funguje přihlášení napříč zařízeními.
• web-auth/webauthn-lib – serializer, správce attestation a oba validátory pro ověření odpovědi v PHP.

Každý objekt v aplikaci něco potřebuje: úložiště článků potřebuje databázi, odesílač pošty připojení k SMTP, kontroler potřebuje obojí. Otázka je, odkud si to má vzít. Špatná odpověď zní, že si to objekt obstará sám – zavolá globální funkci, sáhne na singleton nebo si spojení vyrobí uvnitř metody. Tím vznikne skrytá vazba, kterou z hlavičky třídy nikdo nepozná.

class ArticleRepository
{
    public function save(Article $article): void
    {
        $db = Database::getInstance();  // skryta vazba na globalni stav
        $db->query('INSERT INTO articles ...', $article);
    }
}

Kdo tuhle třídu čte, netuší, do jaké databáze se ukládá ani jak ji vyměnit. Dependency injection je na to jednoduchá odpověď: co třída potřebuje, to jí předáte zvenčí jako parametr. Úvodní kapitola dokumentace Nette to shrnuje do jednoho pravidla – ať je vám to podáno. Žádná magie, jen předání argumentů.

Hned na začátku je dobré nesplést si dva pojmy. Dependency injection je návrhový vzor, tedy způsob, jak psát kód. DI kontejner je nástroj, který to předávání za vás obstará. Jedno jde použít bez druhého: injektovat závislosti můžete i bez kontejneru, ručním předáním v konstruktoru.

Závislost je jen parametr

Nejběžnější způsob předání je přes konstruktor. Hodí se pro závislosti, bez kterých objekt nemá smysl – když je nedostane, nedá se vůbec sestavit. Od PHP 8.0 se dá zkrátit takzvanou promocí parametrů, kdy se vlastnost deklaruje rovnou v hlavičce konstruktoru, a od PHP 8.1 ji jde označit jako readonly, aby se po sestavení už neměnila.

class ArticleRepository
{
    public function __construct(
        private readonly Nette\Database\Explorer $db,
    ) {
    }

    public function save(Article $article): void
    {
        $this->db->table('articles')->insert([
            'title' => $article->title,
        ]);
    }
}

Teď je z hlavičky vidět všechno: třída potřebuje databázi a dostane ji zvenčí. Kdo ji použije, ji taky sestaví, a při tom rozhodne, kterou databázi dostane. Vedle konstruktoru zná Nette i předání přes setter (metoda set*()) pro nepovinné závislosti a zápis přímo do veřejné vlastnosti; ten se ale nedoporučuje, protože vlastnost musí být veřejná a stává se součástí rozhraní třídy.

Od ručního skládání ke kontejneru

Předávat parametry je hezké, dokud jich je málo. Jenže úložiště potřebuje databázi, ta potřebuje spojení, kontroler potřebuje úložiště – a než sestavíte jeden objekt, musíte ručně poskládat celý řetěz pod ním:

$controller = new EditController(
    new ArticleFactory(
        new Nette\Database\Connection($dsn, $user, $password),
    ),
);

Přesně tuhle práci dělá DI kontejner. Je to objekt, který umí vytvořit a nastavit ostatní objekty – v terminologii Nette se jim říká služby. Poprosíte ho o výsledný objekt a on si sám dohledá, co k jeho sestavení potřebuje. Aby přitom nevznikala pokaždé nová databáze, drží už vytvořené služby stranou a podruhé vrátí tutéž. Dokumentace to ukazuje na kontejneru napsaném ručně; skutečný kontejner v Nette (balíček nette/di, řada 3) si ale kód generuje a aktualizuje sám, takže ho nikdo nepíše ani neudržuje.

Autowiring hledá závislost podle typu

Služby se popisují v konfiguraci ve formátu NEON, což je čitelný textový formát podobný YAMLu. Bez další pomoci byste u každé služby museli vypsat všechny její závislosti:

services:
    articles: App\Model\ArticleRepository(@database, @cache.storage)

To je práce, kterou umí odvodit stroj. Slouží k tomu autowiring: podívá se na typy parametrů konstruktoru a dosadí odpovídající službu sám. Zápis se pak scvrkne na jméno třídy:

services:
    - App\Model\ArticleRepository
    - App\Model\ArticleFactory

Podstatné je, čím se autowiring řídí: výhradně typy, nikdy jmény služeb. Ví proto i o tom, že třída splňuje rozhraní, která implementuje, a třídy, ze kterých dědí. Jméno služby je jen pomocný štítek a jeho přejmenování nic nerozbije.

Má to jednu podmínku: každý typ smí být v kontejneru právě jednou. Kdyby byly dvě služby téhož typu, autowiring by nevěděl, kterou podat, a vyhodí výjimku. Řeší se to buď vyřazením jedné služby z autowiringu (autowired: false), nebo upřednostněním jedné z nich:

services:
    mainDb: PDO(%dsn%, %user%, %password%)
    tempDb:
        create: PDO('sqlite::memory:')
        autowired: false           # tempDb je z autowiringu vyrazena
    articles: App\Model\ArticleRepository   # do konstruktoru tedy dostane mainDb

Továrny, které Nette dopíše samo

Kontejner drží službu jako jeden sdílený kus. Někdy ale potřebujete vyrábět nové objekty za běhu – třeba nový článek pokaždé, když ho někdo napíše. K tomu slouží továrna: objekt, který jiné objekty vytváří a dodává jim jejich závislosti. V Nette ji nemusíte psát. Stačí rozhraní s jedinou metodou create() a deklarovaným návratovým typem a implementaci dopíše Nette DI za vás:

interface ArticleFactory
{
    function create(): Article;
}

services:
    - ArticleFactory

V kódu si pak vyžádáte objekt podle rozhraní a zavoláte create(). Když metoda přijme parametr, předá ho továrna do konstruktoru – podmínkou je, že se parametr jmenuje stejně jako parametr konstruktoru, podle čehož si je Nette spáruje.

class EditController
{
    public function __construct(
        private ArticleFactory $articleFactory,
    ) {
    }

    public function add(): void
    {
        $article = $this->articleFactory->create();
    }
}

Proč se to testuje líp

Výhoda, kterou injektování přináší zadarmo, se ukáže až u testů. Když třída dostává databázi zvenčí, můžete jí v testu místo ostré databáze podat náhradu – třeba SQLite v paměti nebo prázdnou atrapu – a sestavit ji přímo, bez kontejneru:

$repository = new ArticleRepository($fakeDb);
$repository->save($article);
// zadna ostra databaze, zadny globalni stav k prepsani

U té první, skryté verze to nešlo: Database::getInstance() uvnitř metody se v testu těžko obchází, protože sáhne na globální stav, který test neřídí. Úvodní kapitola dokumentace na to míří stejnou otázkou – do jaké databáze vlastně skrytý objekt ukládá, do ostré, nebo testovací, a jak se to změní. S injektováním je odpověď v hlavičce třídy a test si dosadí, co potřebuje.

Kontejner tedy není to hlavní. Hlavní je pravidlo, že si objekt závislost nebere sám, ale dostane ji podanou. Kontejner to jen zautomatizuje ve chvíli, kdy objektů přibude natolik, že by je ruční skládání pohřbilo.

Zdroje

• Nette: What is Dependency Injection? – pravidlo „ať je vám to podáno“ a rozdíl mezi vzorem a kontejnerem.
• Nette: Passing Dependencies – konstruktor, setter a property injection včetně promoce parametrů a readonly.
• Nette: Autowiring – řízení podle typů, podmínka jedné služby na typ a autowired: false.
• Nette: Generated Factories – generování továrny z rozhraní s jednou metodou create().

Balík shadow drží na linuxových systémech soubory /etc/passwd a /etc/shadow a patří k němu příkazy passwd, chage, useradd nebo su. Verze 4.20.0 s přezdívkou Ibores vyšla 29. července 2026 a zajímavá je hlavně tím, co v ní není.

Co ve vydání skončilo

Odstraněné věci byly ohlášené jako zastaralé už ve vydání 4.19 z prosince 2025, některé dřív. Podle poznámek k vydání zmizely:

• příkaz expiry(1), kterým si uživatel mohl nechat zkontrolovat platnost vlastního hesla,
• minimální doba mezi dvěma změnami hesla, a to najednou v pěti podobách: přepínač chage -m včetně interaktivní verze, passwd -n, proměnná PASS_MIN_DAYS v souboru login.defs a pole sp_min v /etc/shadow, které se nově ignoruje a maže,
• nástroj groupmems(8) na správu členství ve skupině, který má nahradit usermod(8),
• démon logoutd(8), který odhlašoval uživatele mimo povolené hodiny,
• překonané způsoby hašování hesel: hodnoty DES a MD5 u proměnné ENCRYPT_METHOD a proměnná MD5_CRYPT_ENAB.

Programy nově skončí chybou, když jim některý z odstraněných přepínačů nebo některou z proměnných podstrčíte. Poznámky k vydání to označují za záměr: má to pomoct najít skripty, které na nich stojí.

Dolní mez odešla proto, že ji nikdo nepředepisuje

Stárnutí hesel míří v projektu k úplnému konci. Návrh, který ho označil za zastaralé, se jmenuje rovnou Remove password aging a jeho autor Alejandro Colomar v něm napsal, že hesla by nikdy neměla vypršet a že je doloženo, jak tím bezpečnost hesel klesá (citace přeložena z angličtiny). Návrh na odstranění zbytku je pořád otevřený a autor si do něj poznamenal, že chce vyčkat asi rok, než se ve světě usadí následky téhle změny.

Proč šla jako první dolní mez, a ne horní, stojí v návrhu na odstranění pole sp_min: minimální doba mezi změnami hesla podle něj nevypadá, že by ji něco regulovalo, takže ji šlo odstranit hned. Poznámky k vydání jsou k ní tvrdší, píše se v nich, že se ta možnost považuje za zranitelnost a náhradu nedostane.

Obě meze přitom dělají něco jiného. Horní hranice, tedy PASS_MAX_DAYS, je ta, která uživatele každých pár měsíců nutí vymýšlet nové heslo. Právě tu americký NIST ve čtvrté revizi doporučení SP 800-63B zakazuje: ověřovatel nesmí po uživateli chtít, aby si heslo měnil pravidelně, a smí ho k tomu donutit jen tehdy, když má doklad o kompromitaci. Dolní mez naopak brání tomu, aby si uživatel po vynucené změně hned nastavil zpátky to staré. O ní se v tom doporučení nepíše.

V samotné verzi 4.20.0 horní mez zůstává, jen se z výchozího souboru login.defs vytratily předvyplněné hodnoty PASS_MAX_DAYS a PASS_WARN_AGE. Spolu s nimi jsou dál označené za zastaralé přepínače chage -M, -W a -I a jejich protějšky v passwd, useradd a usermod.

Výchozím hašováním je SHA512

Druhá velká změna se týká toho, čím se heslo v systému uloží. Podpora SHA256 a SHA512 byla dosud volitelná, ve verzi 4.20.0 je bezpodmínečná, a výchozí hodnota ENCRYPT_METHOD se posunula z DES na SHA512. Projekt k tomu dodává, že si správci mají metodu stejně napsat do konfigurace výslovně, protože jiné programy, které login.defs čtou, můžou pořád vycházet z DES.

Dvě regrese, které tam zůstanou

Poznámky k vydání mají vlastní oddíl na dvě chyby, které vznikly jako vedlejší účinek oprav a se kterými se podle projektu musí uživatelé srovnat. První se týká su(1): pouštět ho jako root je kvůli volání ioctl zvanému TIOCSTI nebezpečné, a když to volání nejde zakázat, su nově skončí chybou. Uživatel, který na to narazil, dostal místo přihlášení hlášku o tom, že shell neumí nastavit procesovou skupinu terminálu, a jeho hlášení z 30. července je pořád otevřené.

Druhá se týká usermod(8): když se mu nepodaří odemknout heslo, protože žádné neexistuje, neudělá teď nic. Dřív to byla jen výstraha a příkaz proběhl. Z balíku navíc vypadla nepoužívaná závislost na knihovně libattr.

Kdy to dorazí k uživatelům

Rychlé distribuce jsou u toho hned. Arch Linux má balík shadow ve verzi 4.20.0 v repozitáři core od 31. července 2026. Debian je jinde: podle jeho vlastního přehledu zdrojových balíků mají 8. srpna 2026 vývojové větve sid i forky verzi 4.19.3, stabilní trixie 4.17.4 a bookworm dokonce 4.13.

Kdo tedy o odstraněné přepínače zakopne, pozná to nejdřív na domácím nebo vývojářském stroji. Návrh na odstranění zbytku stárnutí hesel prosí distribuce, ať trojici PASS_MIN_DAYS, PASS_MAX_DAYS a PASS_WARN_AGE vyházejí ze svých souborů login.defs co nejdřív: až vyjde 4.21, programy s takovou konfigurací skončí chybou.

Pro správce z toho plyne konkrétní úklid. Projít skripty a konfigurační management, jestli někde nevolají chage -m, passwd -n, expiry, groupmems nebo logoutd, a podívat se do login.defs na PASS_MIN_DAYS. Chybová hláška místo tichého ignorování je v tomhle případě dobrá zpráva, protože se ta místa ozvou sama.

Zdroje

• shadow-4.20.0 (Ibores), poznámky k vydání projektu shadow, 29. července 2026
• Remove password aging, otevřený návrh v repozitáři shadow-maint/shadow
• Remove support for shadow(5)'s sp_min, návrh začleněný 11. července 2026
• Deprecate and remove the groupmems utility, hlášení z 25. srpna 2025
• NIST SP 800-63B, Digital Identity Guidelines, čtvrtá revize
• shadow 4.20.0.arch1-1, repozitář core Arch Linuxu
• shadow, přehled verzí zdrojového balíku v Debianu

Jack Huey za skupinu, která na Poloniu pracuje, oznámil 4. srpna, že se do nočních sestavení Rustu zapíná nová podoba borrow checkeru. Příspěvek o tom píše v přítomném čase, samotná úprava se ale do repozitáře dostala až o den později, 5. srpna ve 21:37 světového času. První nightly, které ji nese, je tedy až to ze 6. srpna: jeho manifest uvádí verzi 1.99.0-nightly (7608eb7b0 2026-08-05) a 7608eb7b0 je právě commit, kterým se ta změna slučovala.

Kontrola, která sleduje tok programu

Borrow checker je část překladače, která hlídá půjčené odkazy – že odkaz nepřežije data, na která ukazuje, a že vedle měnitelného odkazu neexistuje druhý. Dnešní stabilní podoba se jmenuje NLL a v Rustu je od roku 2019, kdy nahradila úplně první a hodně omezenou implementaci; její přechodový režim, který zůstal jen kvůli hezčím chybovým hláškám, zmizel v roce 2022.

Polonius Alpha přidává jedinou schopnost, zato podstatnou: vztahy mezi životnostmi posuzuje podle toho, kudy program teče. NLL je v tomhle slepé a dívá se na funkci jako na celek. Nejmenší příklad, na kterém je rozdíl vidět, uvádí oznámení takhle:

fn reborrow(a: &mut u8) -> &mut u8 {
    let b = &mut *a;
    if true { b } else { a }
}

Praktičtější případ je funkce, která z HashMap vrátí měnitelný odkaz na hodnotu a chybějící klíč nejdřív doplní. NLL usoudí, že půjčka vzniklá voláním map.get_mut žije po celou funkci, protože tak vypadá návratový typ – a tvrdí to i o větvi, kde se žádná hodnota nenašla a kde se do mapy vzápětí zapisuje. Právě proto ten zápis odmítne. Polonius Alpha pozná, že v téhle větvi už půjčka živá není, a kód přeloží.

Se starým Poloniem se nepřekrývá úplně

Jméno Polonius nesl už rozbor, který se od prací na NLL odštěpil v roce 2018. Ten prošel celou testovací sadou NLL a přijímal i kód, který NLL nepřijme, jenže byl pomalý – u některých programů natolik, že s ním podle oznámení nešlo počítat. Roky pokusů o rychlejší implementaci téhož zadání k ničemu nevedly. Až v roce 2023 vznikla jiná formulace, která staví na stávající infrastruktuře NLL a vyžaduje jen malou přestavbu; stabilizovat se měla původně už v roce 2024.

Slovo Alpha v názvu má svůj důvod. Některé programy, které starý Polonius přeložil, nová podoba odmítne; oznámení ukazuje cyklus while let, který si uvnitř přepůjčuje odkaz do dalšího prvku spojového seznamu. Platí to i obráceně, takže ani jedno není podmnožinou druhého.

Za přijatý kód se platí časem překladu

Polonius Alpha dělá vždy stejně práce jako NLL, nebo víc; méně nikdy. Návrh změny, který compiler team přijal 25. července, uvádí v měřicí sadě překladače průměrné zpomalení kolem 2 %. Z deseti tisíc nejstahovanějších crate jich 91 překročilo práh 2 % při celé kompilaci i se závislostmi a z pěti tisíc nejstahovanějších jich 61 překročilo práh 1 %, když se měřil jen samotný crate bez závislostí.

Ta dvě čísla se v oznámení na blogu slévají do jednoho: ukazuje jediný graf, mluví u něj o deseti tisících crate i o prahu 1 % a měřený čas u něj popisuje jako čas samotného crate bez závislostí. Návrh takovou dvojici nemá – vzorek pěti tisíc a vzorek deseti tisíc jsou v něm dvě různá měření s různým prahem.

Nejhorší zpomalení uvnitř první desetitisícovky je podle návrhu kolem 20 %. Mimo ni se tým díval hlavně na projekty s velkým počtem půjček a našel i horší případy: sestavovací skript jednoho z nich se překládá dvakrát až třikrát déle. Autoři to považují za přijatelné i v případě, že se to opravit nepodaří, protože jde o vzácné a povětšinou malé zpomalení; část příčin už prošla tříděním a na zmírnění se pracuje. Pro představu, o jaká čísla u rychlosti překladu jde: za předchozích osm měsíců rustc zrychlil o 5,6 %. Obě čísla ale pocházejí z jiných měření, takže se od sebe odečítat nedají.

Zapíná se při stavbě překladače, ne za běhu

Přepínač -Zpolonius v rustc existuje léta. Nové je to, čím se přepnula jeho výchozí hodnota: sestavovací skript nastaví proměnnou CFG_DEFAULT_POLONIUS_NEXT jen tehdy, když se překladač staví v kanálu nightly nebo dev. Beta ani stabilní vydání ji nedostanou a výchozí hodnota tam zůstává vypnutá.

Kdo o novou kontrolu na nightly nestojí, předá překladači -Zpolonius=off, ať už přímo, přes proměnnou RUSTFLAGS, nebo v souboru .cargo/config.toml. Pozor na jednu past: -Zpolonius bez hodnoty znamená legacy, tedy tu starou pomalou implementaci z roku 2018, ne novou. Přijímané hodnoty jsou legacy, off a next, jak stojí ve zdrojovém kódu rustc.

Kdy to bude ve stabilním Rustu

Projekt chce Polonius Alpha nechat na nightly zapnutý až do stabilizace a počítá s ní ještě letos. Do té doby sbírá hlášení o výkonnostních propadech, o nesprávně přijatém kódu a o podivných chybových hláškách; u posledního bodu oznámení dodává, že žádnou změnu proti NLL zatím nezaznamenali. Kdyby se něco vážného ukázalo, na nightly se kontrola zase vypne.

Po stabilizaci má vývoj Polonia utichnout. Optimalizovat a dolaďovat výkon se ještě chvíli bude, ale na další schopnosti – tedy na programy, které nepřeloží ani Alpha, ani NLL – se podle oznámení zatím nikdo nechystá. Projekt to zdůvodňuje tím, že Alpha řeší většinu případů, na které lidé v praxi narážejí, a že jsou přednější jiné věci.

Zdroje: oznámení na blogu Rustu, návrh změny v repozitáři compiler teamu, sloučená úprava rust-lang/rust a manifest kanálu nightly ze 6. srpna 2026.

Linuxové jádro umí od roku 2022 přijímat kód napsaný v Rustu, jeho překlad ale zajišťuje výhradně rustc, oficiální kompilátor založený na LLVM. Projekt gccrs od roku 2020 staví alternativu – rustový frontend přímo pro GCC. Podle shrnutí na LWN.net a vlastních měsíčních zpráv věnoval tým první polovinu roku 2026 právě tomu, aby jím šlo přeložit rustové části jádra, a cestou odhalil a opravil několik zásadních chyb ve zpracování jmen, destruktorů i metadat.

Proč vedle LLVM ještě GCC

Rust v jádře dnes běží výhradně přes rustc s LLVM backendem – experimentální podpora GCC jako backendu přes rust_codegen_gcc existuje, ale samotný frontend zůstává rustc. LLVM ale nepokrývá všechny architektury, které umí GCC, a nedává přístup do jeho pluginového ekosystému. S tím, jak rustová část jádra roste, roste i tlak distribucí na to, aby toolchain nebyl vázaný na jediný kompilátor.

Tři milníky místo verzí GCC

V březnu 2026 tým přeorganizoval plán práce: místo cílení na konkrétní vydání GCC zavedl tři milníky podle schopností. „Embedded Rust compiler“ má zvládnout programy bez standardní knihovny, závislé jen na balíčku core. „Rust-for-Linux compiler“ k tomu přidá balíček alloc a konkrétní balíčky, které používá jádro. „General purpose compiler“ má nakonec zvládnout rustový kód obecně, ne jen jádro.

První milník je podle květnové zprávy skoro hotový. Druhý, klíčový pro jádro, stoupl z 16 procent v únoru na 35 v květnu. Dílčí čísla to rozepisují podrobněji: podpora balíčku compiler_builtins a funkce build_error je hotová na sto procent, balíček ffi na 40, ale makra jádra, rozhraní uapi i hlavní soubory jádra byly v květnu pořád na nule.

Chybějící destruktory

Rust spravuje zdroje modelem RAII: když hodnota vypadne ze scope, kompilátor sám zavolá její destruktor podle traitu Drop. Sledovat, kdy se má proměnná uklidit, je složité, protože stav její inicializace se mění podle průběhu programu – kompilátor proto musí analyzovat řídicí tok a generovat takzvané drop flags, tedy proměnné za běhu, které říkají, jestli je hodnotu ještě potřeba zrušit. Tahle analýza v gccrs podle LWN chyběla úplně, takže se volání Drop::drop() někdy vynechávalo nebo bylo špatně.

V jádru to není kosmetická chyba. Rust-for-Linux vrací při zamčení zámku takzvaný MutexGuard, jehož implementace Drop zámek uvolní. Bez správného volání Drop by zámek zůstal držený i po tom, co strážce vypadl ze scope – to znamená zablokovaný kód nebo deadlock. Na infrastruktuře pro Drop od května pracuje účastnice Google Summer of Code Janet Chien.

Jmenný prostor, který si kompilátor pletl

Testování na standardní knihovně a jádru odhalilo i chybu ve zpracování jmen. Rust rozlišuje čtyři jmenné prostory – pro hodnoty (funkce, statické proměnné), makra, typy a pro životnosti a návěští. Když gccrs hledal definici položky, hledal ji rovnou ve prostoru cílového typu: u funkce tedy ve prostoru hodnot. Jenže moduly a veřejně viditelné importy leží ve prostoru typů, takže bez jejich vyřešení tam kompilátor nedokázal projít cestou k funkci vůbec.

Oprava znamenala přepsat vnitřní datové struktury a část visitor kódu v celém překladači. Do května se tím podařilo správně rozpustit hluboko zanořené importy v balíčku core a chování se přiblížilo rustc.

Atributy pro jádro a chybějící metadata

Podle únorové zprávy přepracoval hlavní vývojář Pierre-Emmanuel Patry i zpracování atributů typu #[cfg()], které řídí podmíněný překlad. Odstraňování položek podle cfg rozdělil do dvou průchodů – bez toho nešlo podporovat nestabilní funkce jádra, které při expanzi maker potřebují atributy nejdřív odstranit a teprve pak validovat. V březnu k tomu přibyl přepínač -frust-crate-attr, obdoba přepínače -Zcrate-attr v rustc, který umí vložit atribut (třeba #![no_core]) při volání kompilátoru bez zásahu do zdrojového kódu.

Propojování rustových balíčků jádra pak odhalilo další chybu: exportovaná metadata v souborech .rlib některým balíčkům chyběla u vnořených modulů, takže se nepodařilo dohledat závislosti. Testy na to nenarazily, protože počítaly s plošší strukturou modulů – objevilo se to až na reálném kódu jádra a vyvolalo přepracování celého zpracování metadat.

Kde to dnes stojí

Gccrs dnes umí přeložit samostatné programy bez závislosti na core (no_core) a zvládá zpracovat kód balíčku core i většinu jádra po syntaktické stránce. Skutečné spuštění jádra je ale pořád daleko – ukazují to nulová procenta u maker, uapi a hlavních souborů jádra ve vlastním přehledu projektu. Letos začali přispívat i dva účastníci Google Summer of Code (Enes Çevik na balíčku alloc, Janet Chien na destruktorech) a stážista Zhi Heng, který se věnuje testům na kódu jádra a průběžné integraci.

Slabinou dlouho bylo prosazování změn do hlavního stromu GCC – rozsáhlé záplaty jako přepis jmenných prostorů narážely na omezenou kapacitu recenzentů. Podle LWN se to zlepšilo poté, co dva vývojáři gccrs dostali status správců GCC a mohou si změny připravovat ve vlastní větvi a slučovat je hromadně. Patry a Arthur Cohen mají letos přednášku „Compiling the Linux kernel with gccrs“ na RustConf v Montrealu a na EuroRust v Barceloně.

Výčet opravených chyb by mohl budit dojem, že má jádro k překladu blízko – čísla z vlastního přehledu gccrs ale ukazují, že klíčové části pro jeho spuštění jsou pořád na nule. Chyby, na které tým narazil (špatný jmenný prostor, chybějící destruktory, děravá metadata), jsou přesně ten druh problémů, který se v malých testech neprojeví a vyleze až na reálném kódu.

Zdroje

• Progress toward compiling Linux with gccrs, LWN.net, 28. července 2026
• May 2026 Monthly report, gccrs (Rust-GCC)
• February 2026 Monthly report, gccrs (Rust-GCC)
• Rust-GCC/gccrs, GitHub

GCC je sada překladačů projektu GNU; vedle jazyků C a C++ jich zvládá dalších deset, od Fortranu přes Adu a Go po Rust. Jeho řídicí výbor oznámil 29. července 2026, že přijal doporučení pracovní skupiny a projekt má od té chvíle pravidla pro příspěvky, na kterých se podílel jazykový model. Celé znění je na stránce ai-policy.html.

Hranice je v cizím dokumentu, ne v pravidlech samotných

Nosná věta zní, že projekt zatím odmítne každý „právně významný“ příspěvek, který obsahuje výstup jazykového modelu nebo je z takového výstupu odvozený. Co je právně významné, si pravidla nedefinují – přebírají to z pokynů pro správce balíků GNU. Tam stojí, že hranice leží kolem patnácti řádků kódu nebo textu; pod ní podle nadace nevzniká potřeba řešit práva zvlášť.

Týž dokument ale dodává něco, co se v přehledech obvykle ztratí. Nepočítá se jedna záplata, počítá se souhrn všeho, co daný člověk projektu poslal, a nezáleží na tom, kdy jednotlivé kusy poslal. Kdo tedy pošle desetkrát pět řádků od modelu, hranici překročí, i když ji jednotlivou záplatou nepřekročil ani jednou.

Testovací sady jsou výslovná výjimka

Jedinou výjimku dělají pravidla opačným směrem, než by se čekalo: právně významný příspěvek do testovacích sad smí správce přijmout, i když ho model vyrobil celý. Menší příspěvky projít můžou taky, ale musí splnit obvyklé podmínky a být zřetelně označené. Mimo pravidla stojí kód, který GCC jen přebírá odjinud a spravuje ho někdo jiný; jmenován je knihovní balík libsanitizer.

Podepsat se smí jen člověk

Druhá polovina textu je o stopě, kterou to nechá v historii. Zpráva u commitu, který nese obsah od modelu, musí obsahovat značku Assisted-by:. Příspěvek musí poslat člověk, který změně rozumí a umí na dotazy k ní odpovědět, a rozhodnout o jejím přijetí musí zase člověk. Značku Signed-off-by:, tedy potvrzení Developer Certificate of Origin, smí připojit jedině člověk a model nesmí do repozitáře commitovat vůbec.

Má to praktický důvod. GCC nabízí přispěvatelům dvě cesty, jak vyřešit práva k většímu příspěvku: buď je postoupí Nadaci pro svobodný software, nebo se pod něj podepíšou právě tou značkou. Obojí stojí na tom, že se konkrétní člověk zaručí za původ kódu – a u textu, který vypadl z modelu, se za původ zaručit nedá.

Co pravidla nezakazují

V tomhle je text nezvykle konkrétní. Rešerše, rozbor, hledání a hlášení chyb, revize záplat i ladění modelem jsou v pořádku, dokud jeho výstup neskončí v příspěvku. U hlášení chyb je připsaná podmínka, že se výstup neposílá doslova bez rozmyslu, a u revize, že model lidskou revizi doplňuje, ne nahrazuje.

Stranou stojí i osobní nástroje: čtečka obrazovky, převod textu na řeč, překlad, kontrola pravopisu a gramatiky. Jedinou podmínkou je, že si přispěvatel jejich výstup ověří.

Napsané tak, aby to šlo opsat

Pravidla připravila pracovní skupina vedená Jonathanem Wakelym a oznámení jmenuje dalších sedm lidí, kteří v ní byli. Text je označený licencí CC0 1.0, tedy vzdáním se práv – jiný projekt si ho může vzít a použít, aniž by se koho ptal. Výbor zároveň píše, že se pravidla budou vyvíjet; nejzazší termín revize dává na začátek roku 2027.

Slabým místem je vymahatelnost a diskuse pod zprávou o pravidlech na LWN se točila hlavně kolem ní: pravidlo, které se nedá ověřit, podle jedněch trestá poctivé a vyrábí tiché obcházení. Proti tomu tam zaznělo, že řada přispěvatelů ho dodrží prostě proto, že si projektu váží. Pravidla ten spor neřeší a ani se o to nepokoušejí – jejich úplně první oddíl místo toho žádá, aby se s přispěvatelem, který je ještě nezná, jednalo vlídně.

Podobným směrem šly v posledních týdnech i jiné projekty: Codeberg zakázal projekty psané převážně modely a GNOME naopak sepsal pravidla pro rozšíření, která modely generují.

Náš názor: měřitelný dopad bude mít nejspíš značka Assisted-by:. Je to jediná část pravidel, po které v repozitáři zůstane něco, co jde spočítat – u zbytku se projekt spoléhá na to, že mu přispěvatelé řeknou pravdu.

Zdroje

• AI Policy projektu GCC, gcc.gnu.org
• GCC AI Policy Announcement, archiv konference gcc@gcc.gnu.org, 29. července 2026
• Legally Significant Changes, Information for Maintainers of GNU Software
• Contributing to GCC, oddíl Legal Prerequisites
• GCC steering committee announces AI policy, LWN.net, 29. července 2026

Vývojový tým PHP oznámil 30. července třetí alfu verze 8.6. Alfa je předběžné vydání pro zkoušení, oznámení u ní výslovně varuje, že do ostrého provozu nepatří. Zajímavá je tím, co se do ní dostalo: částečná aplikace funkcí, jejíž menší verzí byl zkrácený zápis odkazu na funkci z PHP 8.1.

Otazník místo argumentu

Částečná aplikace znamená, že se funkce zavolá jen s částí argumentů a zbytek se doplní později. Nový zápis to dělá dvěma značkami: otazník zastupuje právě jeden argument a tři tečky zbytek. Když je PHP ve volání najde, funkci nezavolá, ale vyrobí closure (anonymní funkci), jehož parametry odpovídají tomu, co zůstalo nedoplněné.

function stuff(int $i, string $s, float $f): string {}

// closure, které čeká jen na $s
$c = stuff(1, ?, 3.14);

// closure, které čeká na $s i $f
$d = stuff(1, ...);

Praktický smysl to má u zpětných volání. Návrh RFC to ukazuje na array_map(): místo anonymní funkce, ve které se musí ručně zopakovat všechny parametry i typy, se napíše volání s otazníkem na místě, kam přijde položka pole.

$result = array_map(str_replace('hello', 'hi', ?), $arr);

Co closure podědí z původní funkce

Z původní funkce se do vzniklého closure přenese jméno parametru, jeho typ, volitelnost, výchozí hodnota i to, jestli se předává odkazem. Z atributů ale jen dva: #[NoDiscard] a #[SensitiveParameter]. Návrh to zdůvodňuje tím, že oba mají přímý dopad za běhu, kdežto #[Deprecated] by ohlásil zastaralost dvakrát místo jednou a #[Override] na closure nedává smysl. U vlastních atributů PHP neví, jestli je kopírovat, takže je zahazuje.

Tím se nový zápis liší od zkráceného odkazu na funkci, který přidalo PHP 8.1 pod názvem first-class callable syntax. Ten si atributy nechává všechny, protože mezilehlé closure vůbec nevytváří, jen na funkci odkazuje. Návrh sám ho popisuje jako degenerovaný případ částečné aplikace: foo(...) je zápis, ve kterém se nedoplňuje nic.

V dodatku k návrhu stojí ještě jedna věc, kterou samotný text původně neuváděl. Closure dědí rozsah, ve kterém vzniklo, stejně jako každé jiné. Částečně použít se proto dá i soukromá metoda a výsledek se pak dá předat ven z třídy.

Od hlasování do alfy uplynulo necelých osm měsíců

Návrh nese jméno Partial Function Application (v2), podepsaní jsou pod ním Larry Garfield a Arnaud Le Blanc a je datovaný 3. června 2025. Je to druhý pokus: podle vlastních slov je v podstatě shodný s dřívějším návrhem téhož jména a zkrácený odkaz na funkci z PHP 8.1 z něj tehdy vznikl jako menší první krok.

Ke schválení bylo potřeba dvoutřetinové většiny; konec hlasování měl podle návrhu připadnout na 5. prosince 2025 ve 12 hodin světového času a dnes je uzavřené. Stav návrhu je dnes uvedený jako implementovaný a odkazuje na dva sloučené commity s poznámkou, že jsou v alfě 3. Mezi koncem hlasování a vydáním, ve kterém si zápis může někdo poprvé vyzkoušet, je tedy necelých osm měsíců.

Co dalšího do alfy přibylo

Poznámky k přechodu v souboru UPGRADING vypisují u 8.6 i řadu drobností. Funkce clamp() vrátí hodnotu, pokud je v zadaném rozsahu, a jinak nejbližší mez. Přibyl výčtový typ SortDirection, funkce grapheme_strrev() v rozšíření intl, ReflectionParameter::getDocComment() a mysqli::quote_string(). Větší kusy jsou tři: rozhraní pro polling, tedy dotazování na připravenost vstupu a výstupu (jmenný prostor Io\Poll), obnovení relace TLS u proudů a nové rozhraní pro chyby proudů. Opcache umí nově překlad za běhu i pro vláknově bezpečná sestavení (ZTS) na procesorech Apple Silicon.

Nezávislý přehled novinek na PHP.Watch u verze 8.6 uvádí tutéž alfu 3 a ze zmíněných věcí jmenuje clamp(), SortDirection a grapheme_strrev().

Co se naopak ruší

Za zastaralé je nově označené celé mbregex, tedy regulární výrazy v rozšíření mbstring (funkce mb_ereg a další). Důvod je v samostatném návrhu: knihovna Oniguruma, na které rozšíření stojí, se už neudržuje. Zastarání samo nic nerozbije, program jen začne hlásit varování; je to ale upozornění dopředu pro každého, kdo tyhle funkce v kódu má.

Zastaralé je taky vracení hodnoty z __construct() a __destruct() a jejich psaní jako generátoru. Adresa php://filter s víc než šestnácti filtry hlásí varování, dokud se počet nenastaví výslovně. Ze změn, které nejsou zpětně slučitelné, jsou podstatné dvě: preg_grep() při chybě knihovny PCRE vrátí false místo částečného pole a vlastnosti rozšíření DOM, které byly dosud v dokumentaci označené jen ke čtení, jsou nově deklarované s asymetrickou viditelností, takže zápis zvenčí hlásí jinou chybu než dřív.

Beta 13. srpna, ostrá verze v listopadu

Plán vydání je rozepsaný do 19. listopadu 2026, kdy má vyjít ostrá verze. Do 11. srpna mají být sloučené všechny návrhy mířící na 8.6, 13. srpna přijde beta 1 a s ní měkké zmrazení novinek, u kterého už musí být hlasování uzavřená. Tvrdé zmrazení je na 22. září, první kandidát na vydání o dva dny později. Vydání řídí trojice: Daniel Scherzer jako veterán, Matteo Beccati a Joe Ferguson jako nováčci.

Pro toho, kdo píše knihovny, je alfa první příležitost, jak narazit na problém dřív, než se verze uzavře. Otazník ve volání navíc není povinnost: kdo ho psát nechce, píše anonymní funkce jako dosud a nic se mu nerozbije. Změní se podle nás spíš zvyk – tam, kde se dnes opisuje celá hlavička funkce kvůli jednomu argumentu, bude stačit jeden znak.

Keith Packard zveřejnil 1. srpna Picolibc 1.8.12. Předchozí vydání 1.8.11 je z 27. ledna, takže mezi nimi uplynulo půl roku; srovnání obou značek na GitHubu vypisuje 426 commitů.

Picolibc je knihovna jazyka C pro vestavěné systémy s málo pamětí. Vznikla smícháním kódu z newlibu a AVR Libc a šíří se pod licencemi typu BSD. Vedle linuxové úlohy průběžné integrace má repozitář i úlohy pro Zephyr a coreboot a samostatný adresář se soubory pro Zephyr.

Nová vrstva volá jádro sama

Nejpodstatnější změna je adresář libos, který ve verzi 1.8.11 v repozitáři vůbec nebyl. Podpora poloviční hostitelské obsluhy, tedy semihostingu, se do něj přestěhovala z nejvyšší úrovně a vedle ní přibyly tři sourozenci: fallback, dummyhost a hlavně linux.

Ten poslední obsahuje 110 zdrojových souborů v jazyce C. Většina z nich je jedna funkce POSIX: open, poll, sigaction, mmap, waitpid, obsluha terminálu přes tcgetattr a tcsetattr. Nejsou to obálky nad cizí knihovnou C. Zbytek souborů jsou převodní pomůcky mezi tvarem, který drží jádro, a tím, se kterým pracuje knihovna. Vstup do jádra řeší assemblerový soubor syscall.S v adresáři podle architektury; vlastní ho aarch64, arm a x86. Hlavičky s čísly volání, chybovými kódy a rozložením struktur jsou tamtéž pro pět architektur, k předchozím třem navíc pro i686 a x86_64.

Poznámky k vydání to shrnují stručně: nativní podpora Linuxu na několika architekturách dovolí sestavit řadu linuxových aplikací a testovacích případů. Ta druhá polovina není vedlejší. Picolibc se dosud testovalo hlavně na holém železe pod emulátorem QEMU, takže možnost pustit sadu testů rovnou na hostiteli zkracuje smyčku vývoje.

Zajímavý je způsob, jak se knihovna vyrovnává s rozdílnými datovými strukturami. Dřív se některé struktury Picolibc snažily napodobit rozložení, které používá Linux. Nové vydání to opouští a obsah převádí až za běhu. V adresáři je i podadresář utils s generátory make-syscall.c, make-errno.c a struct-analyze.c, ke kterým patří popisy struktur v souborech JSON.

Kolik architektur to vlastně je

Server Phoronix, který o vydání psal 1. srpna, napsal, že Picolibc rozšiřuje nativní podporu Linuxu na další procesorové architektury, a připojil výčet: ARC, ARM, i386, LatticeMico32, LoongArch, m68k, MIPS, MSP430, Nios II, OpenRisc, Power9, Renesas RX, RISC-V, SparcV8, SuperH, x86_64 a Xtensa ESP32.

Ten seznam ale v souboru README stojí pod nadpisem Supported Architectures a úvodní věta pod ním mluví o architekturách, pro které má knihovna zabudované testování. Na nativní linuxovou vrstvu se ten výčet nevztahuje. Nativní port má v repozitáři pět architektur hlaviček a tři se vstupním kódem do jádra, jak je vidět výš. Poznámky k vydání ostatně mluví o několika architekturách, ne o všech. Rozdíl je podstatný pro každého, kdo si podle výčtu vybírá cíl.

Typ off64_t zmizel

Z hlavičkových souborů zmizel typ off64_t. Nová verze má jen off_t a ten je vždy 64bitový. Jinde je to dvojice: 32bitový off_t na velké soubory nestačil, takže k němu přibyl širší typ a s ním druhá sada funkcí s příponou 64. Vestavěná knihovna psaná od nuly tenhle dluh nést nemusí, takže si Picolibc zvolilo jeden typ. Kdo měl off64_t v kódu, musí ho přepsat.

RISC-V kopíruje paměť vektorově

Funkce memset, memcpy a memmove dostaly pro RISC-V vektorové provedení, které přispěl Pincheng Wang. Abdallah Abdelhafeez k tomu doplnil 32bitové vektorové varianty a přeuspořádáním instrukcí zrychlil strcmp. Týž přispěvatel opravil v obecné céčkové verzi memcpy pro RISC-V smyčku, která kopírovala devět prvků místo osmi.

Přibyla i podpora rozšíření Zcmt (Sam Elliott) a varianta spouštěcího kódu, která zapíná ochranu toku řízení přes zicfilp a zicfiss (Ahmed Shehab). Na architektuře AArch64 inicializuje spouštěcí kód picocrt jednotku SME.

Zamykání se pročistilo

Vnitřní zámek knihovny se přestal zamykat rekurzivně a Kushal Pal opravil souběh při líné inicializaci vyrovnávaného vstupu a výstupu. Brian Cain doplnil k funkcím, které mění stav zámku, anotace pro rozbor bezpečnosti vláken v překladači Clang. Dokumentace ke knihovně popisuje jediný globální zámek pro sdílená data (malloc, atexit, arc4random, getenv, časová pásma a staré globální proměnné stdio) a zámky na jednotlivé soubory pro vyrovnávaný vstup a výstup.

Z drobnějších změn: obsluha semihostingu na ARM nově zachovává registr LR a umí použít instrukci hlt místo svc; pro architekturu verze 8 a vyšší je to doporučený postup. Přibyly funkce pro práci se souborem skupin podle POSIX, fopencookie a open_memstream od Alexeye Lapshina a dvojice quick_exit a at_quick_exit. Architektura Hexagon dostala semihosting, prostředí pro práci s plovoucí čárkou, dynamické linkování i optimalizované matematické funkce.

Podle nás je nativní linuxová vrstva zajímavější jako nástroj pro vývojáře knihovny než jako nabídka koncovým programům. Kdo píše běžnou aplikaci pro Linux, glibc ani musl neopustí; kdo ladí Picolibc, ušetří kolo přes emulátor.

Zdroje

• Picolibc 1.8.12, poznámky k vydání (GitHub)
• Adresář libos/linux ve značce 1.8.12
• README Picolibc
• Phoronix: Picolibc 1.8.12 Brings Latest Improvements To This Embedded-Focused C Library

Projekt PHP vydal 30. července 2026 opravné verze všech čtyř udržovaných větví naráz: 8.2.33, 8.3.33, 8.4.24 a 8.5.9. Dvě z opravených chyb dostaly podle CVSS 4.0 shodnou známku 8,1, tedy vysokou závažnost. Jedna z nich dovoluje podstrčit vlastní SQL dotaz aplikaci, která ukládá data do PostgreSQL přes funkce vestavěné v PHP. Udržované větve jsou podle přehledu na php.net právě čtyři; nejstarší z nich, 8.2, je od konce roku 2024 jen v bezpečnostním režimu a opravy má dostávat do konce letošního roku.

Escapování, které nepočítalo se zpětným lomítkem

Čtyři funkce rozšíření pgsql – pg_insert(), pg_update(), pg_select() a pg_delete() – berou hodnoty jako pole a dotaz si z nich složí samy. Ošetření hodnot má na starosti vnitřní funkce php_pgsql_convert(). Ta zavolá knihovní PQescapeStringConn() z libpq a výsledek zabalí do řetězce ve tvaru E'…'.

Právě to zabalení je jádro chyby, kterou popisuje hlášení GHSA-7qpv-r5mr-78m4, v registru vedené jako CVE-2026-17543. Řetězec uvozený písmenem E je v PostgreSQL takzvaný escape string constant, tedy literál, ve kterém má zpětné lomítko zvláštní význam. PQescapeStringConn() ale zpětné lomítko nechá být, protože počítá s obyčejným literálem. Apostrof zdvojí, lomítko ne – a útočníkovi stačí poslat hodnotu, kde lomítko stojí těsně před apostrofem.

$result = pg_select($db, 'user', ['name' => "zzz\\' OR 1=1 --"]);
// SELECT * FROM "user" WHERE "name"='zzz\'' OR 1=1 --';

V předané hodnotě je zpětné lomítko jen jednou; dvojité je zápis v PHP. Escapování z apostrofu udělá dvojici, jenže první z nich se kvůli lomítku čte jako obyčejný znak. Druhý apostrof tedy řetězec ukončí a všechno za ním se stane součástí dotazu – ukázka v hlášení vrátila celou tabulku. Oprava mění zabalování: hodnoty teď končí v obyčejném literálu, kde lomítko žádnou zvláštní roli nemá.

Nastavení, se kterým se počítalo obráceně

Že PQescapeStringConn() zpětné lomítko neošetří, není chyba libpq. Funkce se řídí nastavením spojení a dokumentace PostgreSQL u parametru standard_conforming_strings uvádí, že od verze 9.1 je výchozí hodnota zapnuto, kdežto starší vydání ho měla vypnuté. Zapnutý parametr znamená, že obyčejný literál bere zpětné lomítko doslova, jak žádá norma SQL – a escapovací funkce se podle toho zachová.

Nesoulad vzniká až tím, že PHP hotový řetězec vloží do E'…', kde platí opačné pravidlo. Dokumentace libpq k tomu říká, že PQescapeStringConn() apostrofy kolem literálu sám negeneruje a dodat je musí volající. PHP je dodalo v podobě, se kterou se ošetření hodnot rozešlo.

Druhá díra je v bccomp() a starších větví se netýká

CVE-2026-17544 je jiného druhu: zápis mimo přidělenou paměť. Podle hlášení GHSA-x692-q9x7-8c3f vzniká v převodní funkci bc_str2num(), když zadané měřítko číslo zkrátí a z výsledku se pak ještě odstraní koncové nuly. Kód sníží počet desetinných míst, ale ukazatel na konec desetinné části nechá tam, kde byl. Následné kopírování pak přenese původní, nezkrácené číslo do vyrovnávací paměti, která je na ně malá.

BCMath drží malá čísla v malé oblasti na zásobníku a teprve větší v haldě, takže poškodit jde obojí. Oprava přidává jediný řádek: po odstranění nul se dorovná i ukazatel na konec. Záznam v registru CVE uvádí jako postižené jen větve 8.4 a 8.5 – starší 8.2 a 8.3 dostaly z tohohle vydání zbylé opravy, tuhle ne.

Kdo má spěchat

Vedle obou vysoce hodnocených chyb jsou ve vydání ještě dvě bezpečnostní opravy: pád při zpracování archivu phar s kruhovými symbolickými odkazy (CVE-2026-7260, známka 5,4) a aktualizace knihovny libgd kvůli CVE-2026-9672.

Podle nás spěchá nejvíc pgsql, i když obě chyby mají tutéž známku. Vektor CVSS u SQL injekce uvádí útok po síti, nízkou složitost a žádná potřebná oprávnění, a hlášení jmenuje jako místo, kde se vadné ošetření používá, právě ty čtyři funkce pro práci s tabulkou. Volání bccomp() s hodnotou od uživatele je proti tomu situace, kterou v běžné aplikaci potkáte spíš výjimečně. O jiných cestách k PostgreSQL, tedy o parametrizovaných dotazech přes pg_query_params() nebo přes PDO, hlášení nemluví.

Oba záznamy CVE mají ve vektoru zapsáno, že o zneužití v praxi se zatím neví. To ale platí ke dni vydání a u chyby, jejíž ukázka se vejde na jeden řádek, je to údaj s krátkou trvanlivostí. Podle nás je na téhle dvojici pozoruhodné hlavně to, že SQL injekce nevznikla v aplikaci, ale v kusu jazyka, který měl aplikaci před injekcí chránit.

Odpovědí není nový filtr ani zákaz. Je jí dokument psaný pro stroje. Příspěvek An Open Letter to AI for Generating GNOME Shell Extensions vyšel 27. července na blogu Javada Rahmatzadeha a hned první věta říká, proč vznikl: protože prohledávače pro jazykové modely blogy GNOME indexují, má text sloužit jako veřejná reference a měřítko pro modely, které kód rozšíření generují. O den později se jeho obsah objevil v oficiální dokumentaci projektu jako stránka Best Practices; commit, který ji do repozitáře gjs-guide přidal, nese datum 28. července.

Seznam zlozvyků, ne obecné rady

Dokument je stavěný jako dvojice: špatný tvar a vedle něj správný. Nejčastější položkou je zbytečný blok try-catch kolem volání, které za normálního běhu výjimku nevyhodí. Metody jako destroy(), connect(), disconnect() nebo GLib.Source.remove() podle dokumentu neošetřené výjimky neháží, takže je nemá smysl obalovat:

// spatne
if (this._sourceId) {
    try {
        GLib.Source.remove(this._sourceId);
    } catch (e) {
    }
    this._sourceId = null;
}

// spravne
if (this._sourceId) {
    GLib.Source.remove(this._sourceId);
    this._sourceId = null;
}

Druhá opakovaná vada jsou obranné kontroly, které nemají co kontrolovat: volání přes ?.() nebo test typeof u metod, které v dané třídě prokazatelně jsou. Dokument u toho rovnou pojmenovává příčinu. Modely se snaží napsat kód, který poběží na několika verzích GNOME Shellu naráz, a tyhle kontroly jsou vedlejším produktem té snahy. Návod žádá opak: cílit na jednu verzi a při skutečné potřebě sáhnout po samostatném průvodci portováním.

Zbytek seznamu má stejný ráz. Žádné příznaky typu this._destroyed, které mají hlídat pořadí volání; místo připojení signálu destroy se má rovnou přepsat stejnojmenná metoda; ikony patří do Gtk.Image a St.Icon, ne do znaků emoji; ukazatel průběhu se skládá z widgetu, ne z řetězce blokových znaků. Řádek smí mít nejvýš 200 znaků, aby recenzent nemusel v prohlížeči rolovat do strany. A komentáře, které jen převádějí kód řádek po řádku do věty, jsou zakázané.

Značka, kterou si má model napsat sám

Jeden bod se od zbytku liší, protože nemluví o kódu, ale o odpovědnosti. Vydat rozšíření na EGO je podle dokumentu závazek, že ho bude někdo pro uživatele udržovat. Kdo neumí JavaScript číst a ladit, má si vygenerovaný balíček nechat na svém počítači. A model má tuhle podmínku připomenout sám: do generovaných souborů má vložit komentář.

// Generated with AI for personal use.
// Do NOT upload to extensions.gnome.org (EGO) unless you understand JavaScript
// and can maintain this code.

Zákaz v recenzních pokynech je o půl roku starší

Samotné pravidlo z minulého týdne není. Oddíl Extensions must not be AI-generated přibyl do recenzních pokynů 30. listopadu 2025. AI jako pomůcku při učení nebo doplňování kódu nezakazuje; požaduje, aby autor uměl odůvodnit a vysvětlit, co poslal. Odmítnout se mají balíčky s velkým množstvím zbytečného kódu, nejednotným stylem, voláním neexistujícího rozhraní nebo s komentáři, které jsou vlastně zadáním pro model.

Týden nato, 6. prosince 2025, to Rahmatzadeh popsal na blogu z druhé strany. Přibývání zbytečných bloků try-catch ho zarazilo, tak se autorů zeptal, odkud se berou, a dostal odpověď, že z AI. V témže textu psal, že některé dny stráví posuzováním přes šest hodin a projde přes 15 000 řádků kódu. Jednou zavedený zlozvyk se podle něj šíří jako domino a objevuje se v dalších balíčcích.

Že to zabere, nikdo doložit neumí

Celá konstrukce stojí na předpokladu, který zvenčí ověřit nejde: že prohledávače stránku načtou a modely se podle ní zařídí. Nikdo nezveřejňuje, co který model z indexovaných stránek do svých odpovědí promítne, takže úspěch se pozná jedině tak, že recenzentům ubude práce. Podle nás je to spíš pokus než opatření.

Skeptický je i sám autor, jen v jiné věci. V prosincové diskusi pod svým příspěvkem odepsal čtenáři, který žádal, aby se rozšíření označovala štítkem podle toho, jestli u nich pomáhala AI: štítkovat se to podle něj snadno nedá, protože modely se učí a zbytečné řádky, které jsou dnes nápadné, nemusí být poznat příště. Text z 27. července s tím počítá. Nesnaží se generovaný kód poznat, snaží se ovlivnit, jak vypadá.

Pravidla si projekt v posledních týdnech přepsal i jinde: bezpečnostní chyby nahlášené GNOME se od 1. srpna zveřejňují po třiceti dnech místo po devadesáti.

Stránka Best Practices nabízí i syrovou verzi v Markdownu ke stažení, aby šla nástroji předat jako soubor s pokyny. To je z celé věci ta nejpraktičtější část: kdo si rozšíření nechává generovat, může návod modelu podstrčit sám a nespoléhat na to, že ho prohledávač najde dřív.

Zdroje: blog Javada Rahmatzadeha z 27. července 2026 a 6. prosince 2025, dokumentace gjs.guide, týdenní přehled projektu z 31. července a historie repozitáře gjs-guide, kterou bez přihlášení vydá REST API GitLabu; jeho webové rozhraní odpovídá robotům kódem 406.

GNU Binutils je sada, bez které se na Linuxu nepřeloží skoro nic: assembler gas, linker ld a nástroje na čtení objektových souborů, mezi nimi objdump a readelf. Vydání 2.47 oznámil 26. července Nick Clifton, hlavní správce projektu. Balíky na ftp.gnu.org nesou totéž datum.

Linkování se dá zrychlit tím, že se práce ubere

Nejnápadnější změna je v linkeru. Překladač označuje některé sekce jako slučitelné: typicky tam leží řetězcové konstanty a podobná data, u kterých nevadí, když se dvě shodné kopie sloučí v jednu. Linker takové sekce prochází, hledá v nich duplicity a výsledek tím zmenšuje. Stojí ho to čas.

Binutils 2.47 dovoluje tuhle práci vypnout. Nový stupeň optimalizace -O 0 u linkeru BFD podle poznámek k vydání linkeru zastaví slučování obsahu slučitelných sekcí, což „může výrazně zrychlit proces linkování za cenu větších binárek“ (přeloženo z angličtiny). O kolik, projekt neuvádí, a závisí to na tom, kolik takových dat program má.

Komu se to hodí, je vidět z povahy věci: při vývoji se linkuje pořád dokola a na velikosti výsledku většinou nezáleží. To už je naše hodnocení, v poznámkách žádné doporučení není.

Hromada objektových souborů, která se tváří jako archiv

Druhá novinka linkeru jsou volby --start-lib a --end-lib plus příkaz LIB ve skriptu linkeru. Objektové soubory mezi nimi se berou jako členové umělého archivu, tedy jako soubor .a, který nikdy nevznikl. Rozdíl proti obyčejnému výčtu souborů je v tom, že z archivu linker vytáhne jen to, na co se někdo odkazuje.

Není to nápad z tohoto vydání. Tytéž volby zná linker lld z LLVM, v jehož manuálové stránce stojí, že jde o skupinu objektů, se kterou se zachází, jako by byly společně v archivu. Binutils si tím doplňuje kus rozhraní, na který jsou překladové systémy zvyklé odjinud.

K archivům patří ještě jedna změna: ld nově zpracuje i archiv bez rejstříku symbolů, a to ve všech formátech, ne jen v XCOFF. Chování je ve výchozím stavu zapnuté a vypíná se volbou --no-link-mapless.

Assembler: RISC-V přibývá, Arm dvě rozšíření stahuje

Assembler dostal volbu --reloc-section-sym se třemi hodnotami (all, internal, none). Řídí, jestli se relokace odkazující na lokální symboly přepíšou na symboly sekcí.

Delší je seznam nových rozšíření RISC-V. Ze standardních přibyla zalasr, svrsw60t59b, zvabd a smpmpmt ve verzi 1.0 a k tomu řada vektorových rozšíření se jmény začínajícími na zvqw, zvfw a zvfb; z dodavatelských pak xsmtvdot a xsmtvdotii od firmy SpacemiT. Úplný výčet je v poznámkách assembleru.

Opačným směrem jde Arm. Rozšíření TME a MPAMv2_VID se podle týchž poznámek nikdy neobjevila v žádném výrobku a Arm je z architektury stáhl; assembler na jejich instrukce a systémové registry nově upozorní varováním a podvolba +mpamv2 zmizela. Za zastaralé jsou označené i direktivy .vtable_entry a .vtable_inherit, které byly potřeba pro překladače GCC starší než 3.0.

Objdump ukáže, kde jsou globální proměnné

Nástroj objdump umí nově volbu --map-global-vars, která vypíše umístění a typ globálních proměnných v objektovém souboru. Poznámky k vydání u ní jmenují autora, Guillauma Vacheriase.

Spolu s readelf přijal objdump také volbu --debug-dir, kterou se dá říct, kde hledat oddělené soubory s ladicími informacemi. Rozklad instrukcí pro AArch64 zná navíc -M annotate, který u nedefinovaných instrukcí ukáže odpovídající symbol; na x86 a x86-64 dělá totéž u přímých operandů -M annotate-immediates.

Pro 32bitový s390 už překlad sám od sebe neproběhne

Podpora 32bitového cíle s390 je označená za zastaralou a počítá se s jejím odstraněním. Konfigurační skript na takový cíl hlásí chybu, kterou lze přebít volbou --enable-obsolete. Šedesátičtyřbitový s390x zůstává podporovaný beze změny.

Binutils v tom nejdou první. Podle týchž poznámek odstranilo jádro Linuxu 6.19 podporu 32bitové kompatibility s390 a knihovna glibc 2.43 i GCC 16.1 tenhle cíl označily za zastaralý s úmyslem ho v budoucnu vypustit. Ve stejném duchu se u rodiny H8 mění výchozí architektura z H8/300 na H8/300H, protože podpora té starší zmizela z GCC už v roce 2020.

Liché číslo znamená bez GOLDu

Oznámení připomíná pravidlo, které nováčka zaskočí: protože jde o liché vydání, zdrojové texty linkeru GOLD v balíku nejsou. Kdo je potřebuje, musí sáhnout po sudé verzi nebo přímo do repozitáře.

Archivy se zdrojovými texty jsou přitom sestavené tak, aby šly sestavit znovu se stejným výsledkem: skript src-release.sh soubory seřadí a předá taru pevné datum, které se bere z posledního commitu souboru bfd/version.m4. Kdo si chce ověřit, že stažený archiv odpovídá zdrojovému stromu, má tím pádem z čeho vyjít.

K běžnému uživateli se novinky dostanou přes distribuce, které si sadu přebalují samy; na vydání samotné je vázaný jen ten, kdo si toolchain překládá. O vydání psal také Phoronix, který si všímá, že týž víkend vyšla i knihovna GNU C Library 2.44.

Nástroj, který otevře žádost o sloučení hned, jak vyjde nová verze knihovny, dělá útočníkovi službu. Napadené vydání někdo obvykle odhalí během hodin, jenže to je pořád dost času na to, aby se stihlo dostat do cizích projektů. GitHub proto oznámil 23. července 2026, že jeho Dependabot napříště tři dny počká, než novou verzi nabídne.

Dvě různé práce jednoho nástroje

Dependabot dělá dvě věci, které se snadno pletou. Bezpečnostní aktualizace reaguje na vydaný záznam o zranitelnosti: přijde upozornění a s ním žádost o sloučení, která projekt posune na opravenou verzi. Aktualizace verzí naproti tomu jen drží závislosti aktuální bez ohledu na to, jestli je se stávající verzí něco v nepořádku.

Čekání platí výhradně na to druhé. Dokumentace to popisuje jako výchozí chování: tři dny se uplatní, i když volbu cooldown nikdo v souboru dependabot.yml nenastavil, a na bezpečnostní aktualizace se nevztahují. GitHub to zdůvodňuje tím, že by šlo o zdržení opravy vady, která je už veřejná.

Samotná volba nová není. Podle přehledu, který v březnu 2026 sepsal Andrew Nesbitt, dostal Dependabot blok cooldown už v červenci 2025. Změna je v tom, že se čekání nově uplatní i u projektů, které si o ně neřekly.

Případ, na kterém to GitHub vysvětluje

V září 2025 vylákal útočník podvodným e-mailem přihlašovací údaje jednoho správce v registru npm a vydal upravené verze balíčků chalk, debug a zhruba tuctu dalších. Dohromady mají přes dvě miliardy stažení týdně. Vložený kód přepisoval v prohlížeči adresy kryptoměnových peněženek.

Jak dlouho byly ty verze v registru, se v pramenech liší. GitHub píše o zhruba dvou hodinách, bezpečnostní inženýr William Woodruff uvádí ve svém rozboru u balíčku chalk „méně než dvanáct hodin“. Ani jeden z nich neuvádí, od čeho a po co přesně měří, takže rozdíl rozhodnout nejde. Na tom podstatném to nic nemění: automatický nástroj se do takového okna vejde i v té kratší podobě.

Kolik dní je dost

Tady se GitHub rozchází s lidmi, od kterých ten nápad pochází. Woodruff sestavil tabulku deseti známých případů a u každého odhadl, jak dlouho byla napadená verze dostupná. Osm z deseti mělo okno kratší než týden, takže sedmidenní čekání by podle něj většinu z nich zastavilo, čtrnáctidenní všechny kromě jediného. Tím jediným je xz-utils s oknem asi pět týdnů.

Táž tabulka ale ukazuje i případy, na které tři dny nestačí nebo je stačí jen tak tak: útok na tj-actions v ní má okno tři dny a napadený Kong Ingress Controller zhruba deset. GitHub svoji hranici obhajuje jinou sadou dat, totiž přehledem 21 široce popsaných útoků z let 2018 až 2026, a odůvodňuje ji tím, že tři dny jsou kompromis: dost na většinu útoků, ne tak dlouho, aby závislosti zbytečně zastarávaly.

Ostatní nástroje se rozhodly různě. Nesbitt uvádí, že Snyk má napevno zabudovaných 21 dní bez možnosti nastavení, kdežto Mend v Renovate 42 udělal tři dny výchozí hodnotou pro balíčky npm ve svém doporučeném nastavení. Samotný Renovate tuhle vlastnost zná léta pod jménem minimumReleaseAge, dřív stabilityDays, a jako příklad v dokumentaci uvádí čtrnáct dní.

Osmnáct nových škodlivých balíčků npm denně

Proč se tím vůbec někdo zabývá, ukazují čísla z databáze bezpečnostních hlášení, kterou GitHub vede. Za rok končící květnem 2026 v ní přibylo přes 6 500 hlášení o škodlivém kódu v npm, o rok dřív jich bylo kolem 6 200. To je zhruba osmnáct nově zachycených balíčků každý den.

Proti čemu čekání nepomůže

GitHub v oznámení sám vypisuje, co tímhle opatřením neošetří: zadní vrátka, která útočník do vydání vloží a nechá spát, sabotáž samotného správce projektu a napadený systém pro sestavení balíčku. Právě sem patří xz-utils, jehož okno Woodruff odhaduje na pět týdnů; na tak dlouhou lhůtu nedosáhne ani Snyk se svými jednadvaceti dny. Čekání je stavěné na jeden konkrétní vzorec, kdy se napadená verze vydá, rychle rozšíří a rychle odhalí.

Jako doplněk GitHub jmenuje připínání verzí zámkovým souborem, vypnutí instalačních skriptů v prostředí pro sestavení, omezení oprávnění přístupových tokenů a čtení změn před sloučením.

Jak si to nastavit jinak

Kdo chce jinou lhůtu, nastaví ji v bloku cooldown. Položka default-days platí pro závislosti bez vlastního pravidla; u správců balíčků, kteří rozlišují úrovně sémantického verzování, jdou zvlášť nastavit semver-major-days, semver-minor-days a semver-patch-days. Seznamy include a exclude pojmou po 150 položkách a přijímají hvězdičku jako zástupný znak; když je balíček v obou, vyhrává exclude a aktualizuje se hned.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7
      exclude:
        - "@nase-firma/*"

Seznam podporovaných správců balíčků je v dokumentaci dlouhý a sahá od Bundleru a Carga přes Gradle, Maven a NuGet až po Terraform a vcpkg. Rozlišování podle úrovně sémantického verzování ale nemají všichni.

Zbytek ekosystému to má taky

Dependabot je jen jedno místo, kde se čekání dá zapnout, a podle Nesbittova přehledu ne to první. V JavaScriptu přišel pnpm s volbou minimumReleaseAge v září 2025, Yarn týž měsíc pod jménem npmMinimalAgeGate, Bun v říjnu 2025 a samotné npm v únoru 2026 jako min-release-age. V Pythonu má uv přepínač --exclude-newer, pip od verze 26 --uploaded-prior-to, Poetry vlastní obdobu. Ruby dostalo čekání v Bundleru 4.0.13 začátkem června 2026.

Nesbitt k tomu dodává, že u distribucí jako Debian nebo Fedora by totéž opatření stálo víc, než by přineslo, protože mezi vydáním knihovny a jejím rozšířením u nich stojí člověk, který balíček prohlédne a přebalí. V registrech typu npm nebo PyPI je vydání a rozeslání jeden a týž úkon. Čekání na aktualizaci tedy těmhle ekosystémům dodatečně vyrábí něco na způsob prodlevy, kterou nikdy neměly.

Hash je v Redisu tabulka dvojic jméno pole a hodnota, tedy to, do čeho se běžně ukládá jeden uživatel, jedna objednávka nebo jedno sezení. Když jich má aplikace miliony a všechny mají stejná pole, uloží se jméno každého pole tolikrát, kolik je klíčů. U pole email a dvou milionů uživatelů to je dva miliony kopií pěti písmen.

Jména polí se uloží do šablony a klíč si nese jen odkaz

Nové kódování zavádí šablonu: neměnný seznam jmen polí, který leží v paměti jednou a odkazuje se na něj každý klíč se stejnou sadou polí. Klíč si pak drží už jen své hodnoty. Redis šablony zakládá, sdílí a uvolňuje sám, aplikace o nich neví a všechny dosavadní příkazy nad hashem se chovají stejně jako dřív.

Jména polí jsou v šabloně seřazená (nejdřív podle délky, pak po bajtech), takže se index pole hledá půlením. Vedle jmen má šablona ještě malé pořadové číslo a klíč si nese právě to, ne osmibajtový ukazatel; komentář ve zdrojovém kódu t_hash.c uvádí, že odkaz na šablonu tak vyjde i na zhruba dva bajty. Kódování jsou dvě, template-listpack pro malé hashe a template-array pro ty, které se do listpacku nevejdou. Obě vypíše příkaz OBJECT ENCODING. Jeho vlastní stránka v dokumentaci je ale 31. července u hashů pořád neuvádí a končí u listpacku.

Nový příkaz HIMPORT posílá jména polí jednou za celou dávku

Druhá novinka je příkaz HIMPORT na hromadné plnění. Klient si nejdřív pojmenuje sadu polí a pak už posílá jen hodnoty:

HIMPORT PREPARE u name email age
HIMPORT SET user:1 u alice a@example.com 30
HIMPORT SET user:2 u bob b@example.com 25

Sada polí patří jedinému spojení. Ostatní klienti ji nevidí a zmizí, jakmile se spojení zavře nebo klient pošle RESET. Proti volání HSET pro každý klíč tím ubude provozu po síti i práce na straně serveru, a Redis si navíc z toho, že všechny klíče sdílejí jednu sadu polí, vezme pokyn uložit je rovnou v novém kódování.

Čísla jsou z jednoho běhu na jednom stroji

Kolik to ušetří, uvádí popis změny na jednom měření jejího autora. Sada měla 2 800 000 hashů nad stovkou různých sad polí, každý hash 20 až 50 polí (v průměru zhruba 34), jméno pole průměrně 13 bajtů a hodnota také 13 bajtů. Obyčejné hashe zabraly 3,49 GB, tytéž v novém kódování 1,77 GB, tedy asi o 49 % méně.

Je to vlastní běh autora změny, ne nezávislé měření, a jeho výsledek závisí na tom, jak velkou část klíče tvoří jména polí. Popis to říká rovnou: nejvíc ušetří klíče s krátkými hodnotami, protože u nich jsou opakovaná jména polí většina objemu. U klíče s jednou dlouhou hodnotou je úspora malá.

Co za to

Šablona je neměnná. Když se do hashe přidá nové pole nebo se jedno smaže, šablona se neupraví – klíč se přesune k jiné, kterou Redis buď najde v registru, nebo pro něj vyrobí. Provoz, který jména polí často mění, tak za úsporu paměti platí hledáním a zakládáním šablon při každém takovém zápisu. Čtení a přepis hodnoty existujícího pole zůstávají stejně rychlé jako dřív.

Změna je navíc jednosměrná: jakmile klíč přejde na šablonu, zůstane u ní po celý svůj život. Mezi šablonami se stěhuje podle toho, jak se mění sada polí, ale zpátky na obyčejný hash se nevrátí. Jedinou výjimkou je vypršení jednotlivých polí – HEXPIRE nad takovým klíčem ho převede zpět na obyčejný hash a úspora je pryč. Hashe, které vypršení polí používají, se do šablony nepřevádějí vůbec.

Poslední rozdíl se týká procházení. HSCAN vrátí u klíče v novém kódování všechna pole naráz a kurzor rovnou nulový. Klientovi, který cyklí do nuly, to nevadí, ale u velmi širokého hashe dorazí v jedné odpovědi to, co by se dřív rozpadlo do několika dávek.

Samo se to nezapne

Automatický převod je vypnutý. Řídí ho pětice nových nastavení v redis.conf a všechna mají výchozí hodnotu 0, což u nich znamená „nedělej nic“. Dvě platí pro běžné zápisy: hash-min-template-entries říká, od kolika polí se hash při dalším zápisu převede, hash-max-template-entries pak horní mez, aby se hodně široké hashe do sdíleného registru nedostaly. Změna se projeví líně, tedy až při dalším zápisu do konkrétního klíče, ne v okamžiku, kdy ji správce nastaví.

Zbylá tři nastavení převádějí hashe při načítání RDB souboru a míří na jednorázový přechod ze starších verzí: soubor uložený dřív, než šablony vznikly, se dá při načtení převést, aniž se data přepisují. Na soubor, ve kterém už nějaká šablona je, se neuplatní. K nim patří práh hash-rdb-load-template-disassembly-threshold: šablona, kterou na konci načítání sdílí míň klíčů, než kolik práh žádá, se rozebere zpět na obyčejné hashe, protože by víc paměti spotřebovala, než ušetřila. Týž práh slouží i jako pojistka – jakmile vznikne aspoň tisíc šablon a víc než polovina z nich je pod prahem, Redis uprostřed načítání nové šablony zakládat přestane a zbytek dat nechá tak, jak je.

Kolik toho šablony zabírají, hlásí INFO

Kolik šablon server drží a kolik klíčů na nich visí, hlásí INFO stats v položkách hash_templates a hash_template_keys. Kolik paměti šablony zabírají dohromady, uvádí INFO memory jako used_memory_hash_templates. Příkaz MEMORY USAGE k paměti jednoho klíče připočte jeho podíl na sdílené šabloně, rozpočítaný rovným dílem mezi všechny klíče, které ji používají.

Ostatní body seznamu se týkají jednotlivých příkazů. LMOVEM a BLMOVEM přesunou mezi seznamy víc prvků najednou, SUNIONCARD a SDIFFCARD vrátí počet prvků sjednocení a rozdílu množin, aniž je posílají, XREAD a XREADGROUP umí novými parametry MAXCOUNT a MAXSIZE omezit velikost odpovědi, přibyl příkaz BACKUP pro zálohu nad vícedílným AOF a servery mezi sebou se nově dokážou ověřit certifikátem protistrany v TLS. Sedm zbylých bodů patří vyhledávacímu a časovému modulu: výpis aliasů indexu, stemmery pro malajštinu a tagalog, rozšíření JSONPath a čtyři změny nad časovými řadami. Poslední položkou seznamu je obecné „zrychlení“ bez podrobností.

Zdroje: poznámky k vydání 8.10.0, popis a rozprava k změně 15364, konfigurační soubor ve značce 8.10.0, dokumentace příkazu HIMPORT a oficiální obraz na Docker Hubu.

Osm rubrik a vyrovnané délky

Sitemapa webu obsahovala 31. července ráno 51 adres: úvodní stranu, osm rubrikových výpisů, 41 článků a jednu jedinou další stránku. Kromě rubrikových výpisů tedy web žádnou další stránku nemá – ani kontaktní, ani o webu.

Rubrik je osm a čísla u nich má web vypsaná v postranním panelu. Nejvíc, deset článků, má Programování, šest Vesmír, po pěti Bezpečnost, Internet a sítě a Počítače, po čtyřech Technologie a Věda a nejméně, tři, mají Auta. Součet dává 42, tedy o jedna víc, než kolik je článků. Jde o zprávu o normě SPHBM4 pro paměti HBM, kterou web zařadil do Technologií i do Počítačů zároveň; ostatní články mají rubriku jednu.

Délkou jsou články vyrovnané. Když se z kanálu RSS odstraní značky a rozbalí entity, má nejkratší z nich 3 655 znaků, prostřední 5 502 a nejdelší 6 737. Žádná krátká zpráva o třech větách mezi nimi není.

Výpis se dá řadit trojicí přepínačů: Trending, Nejnovější a Nejčtenější. Na stránce je dvanáct článků a stránky jsou čtyři. Hledání je fulltextové a funguje i na text uvnitř článků: dotaz „DNS“ vrátil tři záznamy. Vpravo nahoře je přepínač světlého a tmavého motivu.

V RSS je celý text, e-mailem se neposílá nic

Odběr má web vyřešený netypicky. Místo pole na e-mail stojí v patičce věta, že nové články se odebírají přes RSS a e-mailem se neposílá nic. Kanály jsou dva, RSS i Atom.

Podstatnější je, co v nich je: element content:encoded nese celý text článku včetně odkazů, ne jen upoutávku. Soubor RSS má proto přes 350 kB a čtenář ve čtečce dostane všechno, aniž by musel na web. Je to volba proti vlastní návštěvnosti: kdo čte ve čtečce, na stránku nedojde.

Jméno autora v kanálu je, jenže je u všech článků stejné a je to jméno webu. Ani jeden ze 41 článků nemá podepsaného člověka.

Čím je to postavené

Jediná nečlánková stránka na webu je O magazínu a je na ní jedna věta: „Zkušební instalace odlehčeného CMS nad SvelteKitem a SQLite.“ Nic víc tam není. SvelteKit potvrzují i cesty ke skriptům a hlavička x-sveltekit-page, kterou server posílá u každé stránky. O databázi SQLite se dá věřit jen tomu prohlášení, zvenčí ji poznat nejde.

Hlavičky odpovědi má web utažené. Politika obsahu má script-src 'self' s jednorázovým klíčem místo obvyklého unsafe-inline, dále object-src 'none', frame-ancestors 'none', base-uri 'self' a form-action 'self'. K tomu chodí X-Frame-Options: DENY, X-Content-Type-Options: nosniff a odkazovací politika omezená na původ. Server neprozrazuje ani hlavičkou, na čem běží.

Jedna hlavička ale chybí: Strict-Transport-Security. Bez ní prohlížeč neví, že se na doménu má napříště připojovat rovnou šifrovaně, takže první požadavek po zadání adresy jde nezabezpečeně. U webu, který jinak dbá na politiku obsahu, je to nedůslednost, ne zásadní díra.

Soubor robots.txt zakazuje robotům dvě cesty, /admin a /api, a odkazuje na sitemapu. Ta je vygenerovaná i s obrázky, každý ze 41 článků v ní má vlastní. Stránka se z mého připojení stáhla za necelou desetinu vteřiny a úvodní strana váží 190 kB.

Co na webu není

Seznam chybějících věcí je delší než seznam stránek. Web nemá tiráž ani kontakt: nikde není e-mailová adresa, jméno vydavatele ani formulář. Slova „autor“ a „redakce“ se na úvodní straně sice vyskytnou, ale výhradně uvnitř článků a o cizích lidech. Nikde není napsané, kdo za obsah odpovídá a komu se má hlásit chyba.

Anglická verze neexistuje: adresa /en vrací chybu 404. Chybí i stránka o zpracování osobních údajů, přestože web nabízí registraci a účet s e-mailem.

Diskuse pod články je zapnutá a prázdná. Pod každým článkem stojí „Zatím tu nikdo nediskutuje.“ a psát mohou jen přihlášení; registrace chce jméno do diskuse, e-mail a heslo o osmi znacích a rovnou u ní stojí, že účet slouží jen k psaní příspěvků. Zatím to nikdo nevyužil.

Vidět je i čtenost. Pod datem každého článku svítí počítadlo zhlédnutí a čísla jsou jednociferná: u vzorku článků z 31. července tam byly trojky a čtyřky. Vlastní návštěvy při psaní tohohle textu se do nich započítaly taky, takže skutečná čtenost je ještě o něco nižší.

Podle nás je zajímavější než počet článků to, jak jsou postavené. Každý končí odstavcem se zdroji, odkazy vedou na primární dokumenty a nesou rel="noopener", a názor je v textu označený slovy „podle nás“. Chybějící tiráž to ale sráží: u textu bez podpisu se čtenář nemá koho zeptat, když najde chybu, a doložené zdroje mu to nenahradí.

Zdroje: úvodní strana, stránka O magazínu, kanál RSS, sitemapa a robots.txt webu magazin2.chatujme.cz, čtené 31. července 2026. Hlavičky odpovědi změřeny týž den.

Nicholas Nethercote pracuje na rychlosti překladače Rustu deset let a jednou za čas sepíše, co se za tu dobu povedlo. Poslední díl vyšel 31. července 2026 a pokrývá období od 3. prosince 2025 do 29. července 2026.

Souhrnné číslo zní 5,59 % – o tolik se v průměru zkrátila doba běhu měřených úloh. Zhruba polovinu toho zisku ale nepřinesl samotný překladač, nýbrž rustdoc, nástroj na generování dokumentace: ten zrychlil v průměru o 37,92 %. Když se rustdoc z výpočtu vyjme, zbude 2,90 %.

To je poctivé rozlišení, které se v podobných shrnutích často ztrácí. Kdo překládá kód a dokumentaci negeneruje, těch pět a půl procenta nepocítí.

Kde se vzalo těch skoro čtyřicet procent

Za největší kus stojí čtyři změny Noaha Leva, které omezily práci při zpracování bloků impl. Autor shrnutí u nich přiznává, že jim do podrobností nerozumí – a cituje Guillauma Gomeze. Ten to shrnul větou, kterou tu překládáme: „to všechno proto, že někdo narazil na podivnou chybu při používání rustdocu.“

Druhá změna je vděčnější na vysvětlení. Jakub Beránek přidal měřicí úlohy rustdocu do trénovací sady pro PGO – optimalizaci, při které se program nejdřív spustí, změří se, kudy běh doopravdy chodí, a teprve pak se přeloží podle toho. Rustdoc díky tomu zrychlil v průměru o 2,85 %, v nejlepším případě přes šest procent. Nethercote k tomu píše, že se PGO nastavuje obtížně, ale umí hodně změnit – a že na trénovací sadě záleží.

Třetí je jeho vlastní: změna způsobu, jakým rustdoc řadí bloky impl. Dřív se řadily dlouhé vygenerované řetězce HTML, teď se řadí podle kratší textové podoby jména. Sloučeno 31. května 2026, dvacet přidaných a dvacet šest odebraných řádků; v nejlepším případě to ubralo přes šest procent instrukcí.

Většina volání nedělala nic

Nejnázornější případ se týká Clippy, nástroje na kontrolu stylu a častých chyb. Clippy má stovky samostatných kontrol a každá z nich může obsloužit několik desítek událostí – check_item, check_stmt, check_expr a další. Při průchodu stromem se pro každý uzel zavolá příslušná metoda u každé kontroly.

Jenže většina kontrol si všímá jen jedné události, často jediné. Zbylá volání tedy nedělají nic – a přesto je každé z nich virtuální, tedy takové, u kterého se cíl skoku hledá až za běhu. Vývojář vystupující jako xmakro našel způsob, jak průchody spojit tak, aby se prázdné metody nevolaly vůbec.

Nethercote zkoumal tentýž problém současně a přišel s vlastním řešením. Nesloučilo se – bylo funkčně rovnocenné, ale zasahovalo do kódu víc. Změřil u něj ale podrobnosti, které stojí za citaci: doba běhu Clippy klesla ve většině případů o 10 až 30 %, chybné předpovědi skoků o 20 až 80 % na skutečných příkladech a o 97 % na jednom zátěžovém testu.

Sám k tomu dodává, že po deseti letech práce na výkonu překladače zkoušel optimalizovat Clippy poprvé, našel vážný problém, opravil ho – a pak zjistil, že ho někdo o pár dní předběhl.

Osm bajtů nad mezí

Druhý případ je ještě konkrétnější a týká se nového řešitele takzvaných traitů, tedy té části překladače, která rozhoduje, jestli typ splňuje požadované vlastnosti. Vývojář lcnr upozornil na dva balíčky, kde nový řešitel běžel výrazně pomaleji.

Nethercote je proměřil a zjistil, že skoro polovinu času tráví překladač ve funkci memcpy, tedy prostým kopírováním paměti. Příčina: horké pole obsahovalo prvky o velikosti 136 bajtů. LLVM, které rustc používá na generování strojového kódu, přepíná u hodnot nad 128 bajtů z přímých instrukcí právě na volání memcpy.

Oprava udělala dvě věci: vyhnula se dvěma třetinám přesunů a zmenšila typ na 104 bajtů, aby zbylé přesuny pod tu mez spadly. U dvou nejhorších balíčků to zkrátilo dobu běhu o 40 %. Sloučeno 28. července 2026, sedmdesát tři přidaných řádků.

Naše hodnocení: tohle je poučnější než souhrnné procento. Osm bajtů nad prahem, o kterém programátor v Rustu běžně neuvažuje, protože ho určuje až vrstva pod ním.

Co ještě a kdo

U přírůstkového překládání – kdy se po úpravě nepřekládá všechno znovu – přibylo šest drobnějších změn od vývojářů vystupujících jako Zalathar, zetanumbers a xmakro; nejlepší z nich ubraly 5 až 10 % instrukcí.

Nový řešitel traitů se chystá na vydání a na jedné z měřicích úloh klesla doba běhu za tři měsíce z 27 sekund pod jednu. Nethercote zároveň upozorňuje, že o většině té práce sám nemá přehled.

Za zmínku stojí i to, kdo změny psal. Kromě dlouholetých přispěvatelů se objevují dvě nová jména: už zmíněný xmakro a arya dradjica, autorka experimentálního překladače Rustu zaměřeného na rychlost, která na práci nově dostává finanční podporu a věnuje se rozbalování maker.

Zdroje

• Nicholas Nethercote: How to speed up the Rust compiler in July 2026, 31. 7. 2026
• rust-lang/rust #160005 — Avoid excessive memcpys with the new solver, sloučeno 28. 7. 2026
• rust-lang/rust #157179 — rustdoc: optimize impl sorting, sloučeno 31. 5. 2026

Čísla u obou změn v seznamu jsou ověřená proti rozhraní GitHubu, ne jen proti shrnutí: autor, datum sloučení i rozsah zásahu sedí.

Ve čtvrtek 30. července v 1.49 UTC dorazil do mailing listu projektu Mesa dotaz s předmětem Upstreaming a Vulkan driver with a closed shader backend. Napsal ho jingxu zhang a hned v první větě uvedl, pro koho pracuje: dělá v Huawei na ovladači Vulkan pro grafický čip, který si firma navrhuje sama. Odeslal ho ze soukromé adresy na Gmailu, ne z firemní.

Mesa je sbírka otevřených grafických ovladačů; vyvíjí se hlavně pro Linux, ale podle vlastní dokumentace běží i na Windows a dalších systémech. Patří do ní i RADV, ovladač Vulkan pro karty AMD, jehož port na Windows platí Valve.

Co přesně by zůstalo zavřené

Zhang popsal jedno omezení. Instrukční sadu čipu, tedy soupis příkazů, kterým procesor rozumí, Huawei zveřejnit nemůže. Z toho plyne dělení: samotný ovladač otevřený být může, stejně jako převody na úrovni NIR, což je společný mezijazyk, do kterého Mesa shadery překládá, než z nich udělá strojový kód. Zavřená by zůstala jen poslední fáze, která NIR přeloží do strojového kódu Huawei. Ta by se dodávala jako binárka, kterou si ovladač natáhne za běhu.

Ten rozdíl stojí za zdůraznění, protože se v přetisku ztratil. Phoronix o věci napsal, že open source nemůže být kompilátor shaderů; ve skutečnosti jde jen o jeho koncovou část. Zbytek řetězce, včetně optimalizací nad NIR, by byl k dispozici.

Zhang zároveň napsal, že si přečetl dva dokumenty projektu, docs/license.rst a docs/submittingpatches.rst, a ani v jednom takový zákaz nenašel. Dodal ale, že mlčení nepovažuje za souhlas. Také uvedl, že nenašel starší případ, kdy by se na totéž ptal jiný výrobce, ať už dopadl jakkoli.

Odpověď přišla za sedm hodin

V 8.54 UTC odpověděl Dave Airlie, který podle serveru Phoronix pracuje v Red Hatu. Začal jednou větou: „It's very unlikely we would accept this upstream, just open the ISA, your customers will be much happier in the long run.“ V překladu: je velmi nepravděpodobné, že by to projekt přijal, ať Huawei radši otevře instrukční sadu, zákazníci z toho budou mít dlouhodobě víc.

Pak vyjmenoval důvody. První je nerovnováha: podle něj by z takového uspořádání měl výrobce víc než projekt. Druhý je technický a míří na to, že by uprostřed stromu vzniklo umělé rozhraní mezi otevřenou a zavřenou částí. Airlie k tomu připsal, že problémů s rozhraním vůči LLVM má Mesa dost i teď, „and that's open source“ – a to je open source; zavřená obdoba by podle něj byla „horribly limiting“, tedy hrozně svazující.

Třetí důvod je o rovných podmínkách. Ostatní, kdo mají kód v Mese, si s tím poradili, píše Airlie, a ptá se, proč by komunita měla pouštět dovnitř někoho, kdo na stejnou laťku nedosáhne.

Nakonec přidal poznámku, která by před dvěma lety nedávala smysl: „With claude it would take someone who cared a week of tokens to figure out your ISA, I'm not sure what secret you'd be hiding.“ Tedy že s jazykovým modelem by odhalení instrukční sady stálo někoho zaujatého týden tokenů, a Airlie si není jistý, jaké tajemství by se tím vlastně chránilo.

Zbylí dva se přidali

Odpoledne dorazily další dvě reakce. Alyssa Rosenzweig napsala dvě věty: přidává se k Daveovi a pro jakýkoli otevřený ovladač je tohle naprosto nepřijatelné. O šestatřicet minut později Faith Ekstrand souhlasila s Airliem a dodala, že jakkoli by ráda viděla podporu čipů Huawei v Mese, závislost na vnějším binárním kompilátoru prostě není schůdná.

Formálně nešlo o rozhodnutí projektu. Zhang žádný kód nepodal, jen se zeptal, a v listu se nehlasovalo. Odpověděli mu ale tři lidé, kteří v Mese dlouhodobě pracují, a shodli se.

Zákaz v pravidlech opravdu není

V jedné věci měl Zhang pravdu. Dokumentace Mesy o binárních částech ovladače nemluví: stránka o licenci jen popisuje, že jádro knihovny je pod licencí MIT, jednotlivé soubory můžou mít vlastní licenci a rozhodující je identifikátor SPDX přímo ve zdrojovém souboru. Žádná věta o tom, že ovladač nesmí za běhu natahovat binárku, tam není.

Odpor je tedy zavedená praxe, ne odstavec v pravidlech. Opírá se o to, co říká Airlie: ostatní si s tím poradili. Dokumentace Mesy vede jako otevřený ovladač Vulkan třeba PowerVR pro čipy Imagination Technologies.

Jak to nejspíš dopadne

Zhang na konci dotazu napsal, že v otevírání kódu bude Huawei pokračovat tak jako tak. Otázka podle něj zněla jen, jestli tu práci mířit do hlavního stromu Mesy. Pokud firma instrukční sadu nezveřejní, zůstane ovladač nejspíš mimo něj, tedy jako samostatný projekt, který si musí uživatel sehnat a udržovat sám.

O jaký čip vlastně jde, se z vlákna nedozvíte. Zhang návrh nijak nepopsal a Phoronix k tomu dodává, že Huawei dnes neprodává herní ani univerzální grafické karty; má akcelerátory Ascend a Atlas určené pro výpočty umělé inteligence. Jestli je ovladač Vulkan právě pro ně, ani jeden zdroj neuvádí.

Podle nás je na celé věci zajímavější Airlieho argument o tokenech než samotné odmítnutí. Utajení instrukční sady bylo dlouho drahé prolomit. Jestli platí, že dnes stačí týden strojového času, ztrácí smysl chránit ji zrovna tímhle způsobem.

Zdroje

• Vlákno Upstreaming a Vulkan driver with a closed shader backend v archivu mailing listu mesa-dev, 30. července 2026
• Phoronix: Huawei Considers Open-Sourcing A Half-Hearted Mesa Vulkan Driver
• Dokumentace Mesy: License and Copyright

Od forku k přepisu

Costa a spoluzakladatel Pekka Enberg odešli z firmy ScyllaDB a v San Franciscu založili ChiselStrike. Potřebovali databázi pro cloudovou službu a sáhli po SQLite, který v roce 2000 napsal D. Richard Hipp. Naráželi ale na to, že Hipp drží záběr SQLite úmyslně malý a nepřijímá cizí příspěvky. Oznámení Tursa k tomu dodává, že uzavřená je i proslulá testovací sada SQLite.

ChiselStrike proto SQLite rozvětvil pod jménem libSQL. Drobnosti šlo doplňovat i tak, ale bohatší typový systém by znamenal sáhnout na samotné jádro. Firma se tedy pustila do úplného přepisu s krycím jménem Limbo. Mezitím se přejmenovala na Turso a Limbo převzalo jméno po ní; Turso je mořská obluda Iku-Turso z finské Kalevaly.

Dnešní Turso umí otevřít i vytvořit soubor SQLite. Oproti předloze přidává souběžné zápisy, bohatší typy a materializované pohledy, které se podle autorů aktualizují samy. Kód je pod licencí MIT a k 30. červenci má repozitář na GitHubu přes 23 tisíc hvězd. Oznámení uvádí přes 260 přispěvatelů – to číslo pochází od firmy a nezávisle jsme ho neověřovali.

SQLite je uvnitř virtuální stroj

Celý nápad stojí na jedné vlastnosti SQLite, kterou zvenčí není vidět. SQLite dotaz nevykonává přímo: přeloží ho do vlastního bajtkódu zvaného VDBE a ten pak spouští. Není to univerzální jazyk jako bajtkód Javy, instrukce mají databázový význam typu „najdi záznam v B-stromu“. Pořád je to ale bajtkód a Turso stejný návrh převzalo.

Aby autoři ukázali, že jejich verze toho bajtkódu zvládne i něco jiného než dotazy, napsali malý překladač z jazyka C do VDBE a přeložili jím Doom. Hra běží přímo v databázovém stroji: každý vykreslený snímek je jeden řádek výsledku a paměť zastupují binární data, ze kterých se čte a do kterých se zapisuje. Demo je na stránce oznámení a spustí se v prohlížeči.

Co znamená psát Postgres v Tursu

Spojit SQLite s Postgresem zkoušel kdekdo, obvykle překladem dotazů z jednoho dialektu do druhého. Turso jde jinudy. Postgres se rozebere do společné stromové podoby dotazu a ta se přeloží do téhož bajtkódu – jazykové rozhraní se tedy stává vyměnitelnou součástkou.

Rozdíly mezi oběma databázemi tím nemizí. Postgres drží řádky v haldových souborech s oddělenými indexy, verzuje záznamy a musí po sobě uklízet průchodem zvaným vacuum; SQLite skládá všechno do jednoho B-stromu. Podle oznámení jde ale o rozdíly v uspořádání dat na disku, ne v tom, co databáze dělá – a co v bajtkódu chybí, se do něj doplní.

Prototyp jménem pgmicro už je začleněný do hlavní větve. „Turso se stává LLVM databází. Jedno moderní a spolehlivé jádro, nad ním víc databázových rozhraní přeložených do něj,“ stojí v oznámení (přeloženo). Firma zmiňuje jako další možné kandidáty MySQL a Redis.

Motivem není nespokojenost s Postgresem. „Nemyslím si, že by na Postgresu bylo něco zásadně špatně. Kdyby bylo, nepřepisovali bychom ho,“ řekl Costa serveru The Register (přeloženo). Argumentem je architektura: nová databáze podle oznámení nemá držet vlastní proces pro každé připojení a má běžet i v prohlížeči nebo jako jediný soubor.

Co zatím není hotové

Oznámení samo píše, že jde o základ, ne o hotový produkt. Balíčky ke stažení nejsou žádné; kdo si to chce zkusit, musí si projekt přeložit ze zdrojového kódu příkazem cargo run v adresáři postgres/cli.

Úplná shoda s Postgresem se navíc neplánuje. Firma píše, že cílí na „dostatečnou“ kompatibilitu v základní funkčnosti, ne na sto procent, protože některé věci chce dělat jinak – materializované pohledy se v Tursu aktualizují průběžně a autoři nevidí důvod doplňovat kvůli shodě i variantu, která to nedělá. Síťový protokol a serverovou část slibují, takže by se stávající aplikace i klient psql měly připojit beze změny.

Dvě věci zůstávají otevřené. Procedurální jazyk PL/pgSQL firma nejspíš nenapíše přímo, ale postaví něco vlastního a k tomu vrstvu, která PL/pgSQL zpřístupní. U rozšíření Postgresu má zatím jen důkaz proveditelnosti: nahrávají se v kontejneru WebAssembly, což stojí výkon, a firma výslovně píše, že se touhle cestou vydat nemusí a některá rozšíření nepůjdou nikdy.

Termín zazněl jediný a je to slib, ne plán s daty: dost velkou část Postgresu na to, aby byl v praxi užitečný, chtějí autoři mít během pár měsíců.

Kde to stojí mezi ostatními

Databáze, která umí mluvit víc jazyky, není nová myšlenka. Nabízí se Spanner od Googlu a Cosmos od Microsoftu, oba ale podle Costy pracují ve vrstvení výš. Blíž má Turso podle The Register k projektu Apache DataFusion, rovněž psanému v Rustu. Rozdíl shrnul Costa tak, že Turso sedí na nejnižší možné úrovni, přesně jednu vrstvu nad úložným strojem.

Náš názor: na hodnocení je brzy. Zajímavé na oznámení není to, že někdo přepisuje Postgres – takových pokusů byla řada –, ale že se to tentokrát dělá nad jádrem, které už jednu velkou databázi obsluhuje a je veřejně k vyzkoušení. Jestli to vyjde, ukáže až chvíle, kdy půjde ta „dostatečná“ kompatibilita změřit na skutečné aplikaci.

Zdroje

• Turso: We're building Postgres in Rust. Using the LLVM of databases (16. července 2026)
• The Register: After rewriting SQLite in Rust, Turso turns its sights on Postgres (29. července 2026)
• Repozitář projektu na GitHubu – licence a popis projektu

SQLite vydal 24. července verzi 3.53.4. Je to čtvrtá opravná verze větve 3.53 za necelé čtyři měsíce a SQLite ji popisuje větou, jakou u opravného vydání jinde nenajdete: opravuje chyby, které většinou objevily AI.

Rozepsanější je novinkový zápis k témuž datu. „Krátce po vydání 3.53.0 (2026-04-09) přišel obrovský nápor hlášení chyb pořízených s pomocí AI, ale v poslední době tempo hlášení znatelně kleslo a chyby, které se hlásí, jsou čím dál bezvýznamnější,“ píše se v něm (přeloženo). Následuje otázka, ne tvrzení: jestli lavina nekončí a jestli AI nenašly skoro všechno, co najít umějí. Zápis dodává, že příští vydání už možná bude 3.54.0 s novými funkcemi.

Co k tomu říká záznam změn

SQLite vyvíjí ve Fossilu a celá časová osa je veřejná, takže se ta věta dá zkusit ověřit. Vzali jsme check-iny větve branch-3.53 od vydání 3.53.0 a rozdělili je do oken mezi jednotlivými opravnými verzemi. Tatáž oprava se do stromu obvykle dostane dvakrát, do hlavní větve i do 3.53, takže se dvojice slučovaly na jednu položku.

• 3.53.1, okno 26 dní: 36 check-inů, z toho 13 s odkazem na hlášení
• 3.53.2, okno 29 dní: 73 check-inů, z toho 35 s odkazem na hlášení
• 3.53.3, okno 23 dní: 78 check-inů, z toho 44 s odkazem na hlášení
• 3.53.4, okno 28 dní: 36 check-inů, z toho 20 s odkazem na hlášení

„Odkazem na hlášení“ myslíme zprávu check-inu, která jmenuje příspěvek na fóru, číslo hlášení nebo toho, kdo problém nahlásil. Přepočteno na den je to 0,5, 1,2, 1,9 a 0,7 takové opravy. Pokles proti červnovému vrcholu je tedy zhruba na dvě pětiny a tvar odpovídá tomu, co SQLite píše. Je to ovšem počet oprav, ne počet hlášení, a datum opravy nemusí být datem, kdy chyba přišla.

Jedna věc se s popisem míjí. Nápor podle novinek přišel „krátce po vydání 3.53.0“, v záznamu je ale první okno nejchudší ze všech a vrchol spadá až na květen a červen. Kdo by chtěl vlnu vidět v dubnu, v časové ose ji nenajde.

Kde se AI v záznamu jmenuje

V celé větvi se AI jmenuje přímo dvakrát. Check-in z 23. června nese zprávu „opravy tří samostatných chyb objevených AI v nedodávaných rozšířeních“ (přeloženo). Jde o zaokrouhlování samých devítek v rozšíření decimal, o odstranění uvozovek v parametrech virtuální tabulky fuzzer a o čtení za koncem vyrovnávací paměti ve funkci next_char() rozšíření spellfix. Žádné z těch tří rozšíření se s knihovnou nedodává, používají se při testování.

Druhá zmínka váží víc. Check-in z 9. července říká, že v programu sqlite3_rsync opravuje „tři vady, které identifikoval Anthropic“ (přeloženo). Tenhle nástroj se dodává a slouží k tomu, aby se kopie databáze na druhém stroji srovnala s originálem, případně přes SSH. Změna sahá na jediný soubor, tool/sqlite3_rsync.c.

U ostatních oprav se ve zprávě check-inu o původci nedočtete. Zpráva odkáže na příspěvek na fóru nebo na časové razítko hlášení a tím to končí, takže poměr „kolik z toho našly AI“ jde z veřejného záznamu odhadnout jen podle toho, co SQLite napsal v novinkách.

Testovacího kódu má SQLite 590krát víc než vlastního

SQLite se dlouhodobě chlubí testováním a čísla k tomu má. Podle vlastní stránky How SQLite Is Tested má projekt 590krát víc testovacího kódu než kódu knihovny, čtyři nezávisle vyvíjené sady testů a stoprocentní větvové pokrytí v takové konfiguraci, v jaké se knihovna dodává. Ty údaje jsou ovšem počítané k verzi 3.42.0 z května 2023, novější stránka neuvádí.

Že to nestačí, ukázala sama větev 3.53. Vznikla jako znovuvydání staženého 3.52.0 a nese opravu chyby, která poškozovala databáze; v seznamu změn vystupuje jako chyba při resetu žurnálu WAL. K verzi 3.52.0, kde se oprava objevila poprvé, SQLite 6. března napsal, že jde o patnáct let starou chybu nalezenou pár dní předtím. Kdo ji objevil, v novinkách nestojí.

U curlu má vlna jiný průběh

U curlu vypadá totéž období opačně. Ten podle vlastního odhadu projektu běží asi ve třiceti miliardách instalací, od telefonů po tiskárny. Jeho zakladatel Daniel Stenberg napsal 26. května příspěvek The pressure, ve kterém popisuje tempo příchozích bezpečnostních hlášení jako čtyř až pětinásobek roku 2024 a dvojnásobek roku 2025, tedy v průměru přes jedno hlášení denně. Nejde podle něj o nesmysly: kvalita hlášení je vyšší než kdy dřív a jsou dlouhá a podrobná. Uvádí i osobní cenu, kterou to má: podle vlastních slov poprvé v životě vyjádřila jeho žena obavy z jeho pracovní doby.

Čísla si lze ověřit v seznamu zranitelností curlu, který projekt vydává i jako strojově čitelný soubor. Za rok 2026 je v něm k 1. srpnu 36 zveřejněných zranitelností proti devíti za celý rok 2025 a jedenácti za rok 2024. Vycházejí v dávkách spolu s vydáním knihovny: šest v lednu, čtyři v březnu, osm v dubnu a osmnáct 24. června. Novější dávka zatím není, protože curl od té doby nevydával, takže o červenci ten seznam neříká nic.

Závažnost je přitom nízká. Ze všech letošních je 22 hodnoceno jako Low a 14 jako Medium, žádná výš. Stenberg to sám zmiňuje: poslední curlí zranitelnost se stupněm High vyšla podle něj v říjnu 2023.

Co ta čísla nedokládají, je příčina. Seznam zranitelností u jednotlivých záznamů neuvádí, jestli za nálezem stál člověk, nástroj, nebo obojí; spojení s AI je Stenbergovo, ne údaj z evidence.

Dvě fáze, ne dva názory

Rozdíl mezi oběma projekty nemusí být rozdíl v postoji. SQLite popisuje vlnu, která u něj začala v dubnu a v červenci opadá; curl popisoval na konci května stav, kdy vlna teprve narůstala, a jeho poslední dávka hlášení je z 24. června. Jestli i curlu tempo klesá, se pozná až s příštím vydáním. Zatím platí jen to, že jeden z nich má vlnu podle vlastních slov za sebou a druhý o jejím konci nic nehlásí.

Zdroje

• SQLite Release 3.53.4 On 2026-07-24, poznámky k vydání
• Recent SQLite News, zápis z 24. července 2026
• SQLite: časová osa větve branch-3.53, repozitář Fossil
• Check-in c980094956, 23. června 2026, a check-in b6ab126399, 9. července 2026
• How SQLite Is Tested, údaje k verzi 3.42.0
• Daniel Stenberg: The pressure, 26. května 2026
• curl: seznam zranitelností, počty a závažnosti dopočítány ze strojově čitelné podoby seznamu

Jazykový model sám o sobě neumí nic než psát text. Aby sáhl do databáze, přečetl soubor nebo založil lístek v evidenci chyb, potřebuje domluvu, podle které se mu nástroj ohlásí a on ho pak zavolá. Tou domluvou je Model Context Protocol, zkráceně MCP. Vlastní dokumentace ho přirovnává k portu USB-C: „Stejně jako USB-C poskytuje standardizovaný způsob, jak propojit elektronická zařízení, MCP poskytuje standardizovaný způsob, jak propojit aplikace s umělou inteligencí s vnějšími systémy“ (přeloženo). Podporují ho mimo jiné Claude, ChatGPT, Visual Studio Code i Cursor.

28. července 2026 vyšla revize 2026-07-28, první od loňské 2025-11-25. Verze protokolu se značí datem schválně: podle vlastního popisu se to datum mění jen tehdy, když přibude změna rušící zpětnou slučitelnost. Tahle taková je.

Konec sezení

Dosud fungovalo MCP jako spojení, které se musí navázat. Klient poslal initialize, server odpověděl, klient potvrdil initialized, a teprve pak šlo posílat práci. Server si přitom pamatoval, s kým mluví, a účastníky rozlišoval hlavičkou Mcp-Session-Id.

Obojí je pryč. „Oficiálně jsme zrušili výměnu initialize/initialized spolu s hlavičkou Mcp-Session-Id,“ píše oznámení projektu (přeloženo). Verzi protokolu i schopnosti klienta nese nově každý požadavek zvlášť, v poli _meta. Kdo potřebuje, aby si server něco pamatoval mezi voláními, dostane od něj obyčejný identifikátor a posílá ho zpátky jako běžný parametr nástroje.

Dopad je prostý: požadavek může obsloužit kterýkoli běžící server. Do té doby musel provoz hlídat, aby všechny požadavky téhož klienta dopadly na týž stroj – anebo si stroje musely sezení sdílet přes společné úložiště.

Přibyl proto nový povinný dotaz server/discover. Server jím na jedno zavolání ohlásí, které verze protokolu umí, co nabízí a kým je. Klient ho použít nemusí; může rovnou poslat práci a počkat, jestli se nevrátí chyba o nepodporované verzi.

Vedlejší produkt vlastního původu

Craig McLuckie, šéf firmy Stacklok, řekl serveru The Register, že stavovost MCP „byla vlastně vedlejší produkt toho, že vzniklo jako způsob podpory vývojářů používajících nástroje na psaní kódu“ (přeloženo). Protokol tedy vznikl pro jeden editor běžící na jednom počítači a teprve pak se z něj stalo něco, co jede ve velkém.

Rozsah zásahu přiznává i projekt sám. David Soria Parra, jeden ze dvou vedoucích správců specifikace, ho pro The Register označil za „nejpodstatnější změny, jaké jsme ve specifikaci udělali, patrně od doby, kdy jsme přidali autorizaci“ (přeloženo).

Co se ruší a co se jen odkládá

Tři starší schopnosti dostaly nálepku zastaralých: Roots (klient serveru sděloval, které adresáře ho zajímají), Sampling (server si mohl vyžádat odpověď od modelu) a Logging (protokolové zprávy). „Pořád fungují a fungovat budou nejméně dvanáct měsíců,“ stojí v oznámení (přeloženo). Doporučená náhrada je pokaždé jiná: adresáře předávat jako parametr nástroje, na model se obracet přímo přes rozhraní jeho poskytovatele a zapisovat na stderr nebo přes OpenTelemetry.

Stejnou nálepku dostal starý přenos HTTP+SSE a dosavadní způsob registrace klienta u autorizačního serveru. Naopak bez odkladu zmizely ping, logging/setLevel a obnovování přerušeného datového proudu – když spojení spadne uprostřed požadavku, klient ho musí poslat znovu jako nový.

Snadno se přehlédne jedna drobnost: chyba „zdroj nenalezen“ má nově kód -32602 místo -32002, aby odpovídala JSON-RPC.

Kdo si server psal sám, má práci

Parra to řekl bez obalu: „Kdo si postavil vlastní implementaci, čeká ho velký kus práce“ (přeloženo). Kdo staví na oficiálních knihovnách, je na tom líp – ty pro TypeScript, Python, Go a C# už novou verzi podporují, ta pro Rust je v betě.

Zpětná slučitelnost je slabým místem celého kroku. Server podle nové revize se se starým klientem nedomluví a naopak; specifikace na to má samostatnou kapitolu, bezbolestné to ale není. Někdo se připravil dopředu: GitHub oznámil 23. července, že jeho server MCP novou specifikaci podporuje ještě před jejím vydáním.

Že nejde o okrajovou záležitost, ukazují čísla, která projekt uvádí sám o sobě: „Napříč našimi knihovnami první úrovně vidíme skoro půl miliardy stažení měsíčně, přičemž knihovny pro TypeScript i Python překročily hranici miliardy stažení celkem“ (přeloženo). Nezávisle ověřená ta čísla nejsou.

Poprvé s pravidly pro rušení

Vedle technických změn přibyla věc procesní, která bude nejspíš důležitější než kterákoli jednotlivá úprava: formální pravidla životního cyklu. Každá schopnost je nově buď aktivní, zastaralá, nebo odstraněná, a mezi zastaráním a odstraněním musí uplynout aspoň dvanáct měsíců. Zkrácená lhůta devadesáti dnů existuje, ale jen jako výjimka.

Pro provozovatele je to větší jistota než dosud. Kdo pouští nástroje, ke kterým se dostane cizí model, ví, že každá změna protokolu je zároveň změna bezpečnostní – červencový průnik do infrastruktury Hugging Face ukázal, co dokáže sestava agentů puštěná na cizí stroje. Roční lhůta na přechod aspoň znamená, že se nebude muset opravovat za pochodu.

Zdroje: oznámení projektu MCP, seznam změn ve specifikaci, The Register a changelog GitHubu.

Když si dnes chatovací aplikace potřebuje sáhnout do kalendáře, do databáze nebo do repozitáře, může k tomu použít MCP, Model Context Protocol. Podporují ho Claude i ChatGPT a z vývojářských nástrojů třeba Visual Studio Code nebo Cursor. Jeho nová specifikace, označená 2026-07-28, vyšla 28. července a mění na něm to nejzákladnější.

Co se změnilo

Autoři to shrnují jednou větou: „MCP se mění z obousměrného stavového protokolu na bezstavový protokol typu požadavek–odpověď“ (přeloženo). Prakticky to znamená, že „jsme oficiálně vyřadili výměnu initialize/initialized spolu s hlavičkou Mcp-Session-Id“ (přeloženo).

Co přesně si obě strany v úvodním pozdravu vyměňovaly, oznámení nerozvádí. Píše ale, co se děje místo toho: „Každý požadavek teď putuje sám za sebe a nese svou verzi protokolu, identitu klienta a jeho schopnosti v poli _meta“ (přeloženo). Kdo potřebuje zjistit schopnosti serveru předem, má na to nové volání server/discover.

Proč to někoho zajímá

Rozdíl je vidět až ve chvíli, kdy takový server někdo provozuje pro víc než jednoho člověka. Se stavovým protokolem musely všechny požadavky jednoho klienta dojít na tutéž instanci serveru – jinde by jeho relace nebyla. Tomu se říká sticky sessions a znamená to buď chytřejší load balancer, nebo sdílené úložiště relací pro všechny instance.

Bez relace tenhle požadavek mizí. Autoři to shrnují tak, že „kterýkoli požadavek může dopadnout na kteroukoli instanci za obyčejným round-robin load balancerem“ (přeloženo) – tedy za rozdělovačem, který posílá požadavky do kola bez ohledu na to, kdo je poslal.

Co se dá poznat z hlavičky

Z bezstavovosti plyne druhá praktická věc. Požadavek nese v hlavičkách Mcp-Method a Mcp-Name, o jakou metodu a o jaký nástroj jde. Brána, omezovač provozu nebo aplikační firewall tak podle autorů může směrovat a měřit podle nich, místo aby rozebírala tělo v JSONu.

Podobně cílí i další novinka: odpovědi na výpisy nástrojů, promptů a zdrojů teď nesou položky ttlMs a cacheScope, aby si klient mohl určit, jak dlouho a v jakém rozsahu si je smí schovat, a nestahoval je pokaždé znovu.

Co to rozbije

Toto je ta část, kterou oznámení o vydáních obvykle nepíšou nahlas. Podle rozboru na Stacktree čeká server postavený na staré specifikaci trojí práce: opustit sdílené úložiště relací, číst verzi protokolu a schopnosti z pole _meta u každého požadavku a doplnit metodu server/discover. Kdo používá dlouhoběžící úlohy, musí přejít na rozšíření Tasks a výsledek si vyzvedávat dotazem, místo aby čekal na odpověď.

Vydání nové verze ale není vypnutí té staré. Servery a klienti na specifikaci z listopadu 2025 podle autorů fungují dál. Vlastnosti označené za zastaralé – Roots, Sampling, Logging a starý přenos přes HTTP a SSE – mají zůstat ve specifikaci nejméně dvanáct měsíců.

Rozšíření místo verzí

Druhá změna je organizační. Novinky, které nepatří do jádra, se dělají jako rozšíření s identifikátorem v obráceném tvaru doménového jména a vlastním číslováním verzí, nezávislým na specifikaci samotné.

Dvě z nich jsou vidět nejvíc. MCP Apps dovolují serveru poslat interaktivní HTML rozhraní, které hostitelská aplikace vykreslí v odděleném rámu. Tasks řeší úlohy, které trvají déle než jedno volání: server na požadavek odpoví úchytem úlohy a klient si pak chodí pro výsledek.

Kdo za tím stojí

Specifikaci vedou dva správci, David Soria Parra a Den Delimarsky. Kdo protokol původně vytvořil, ani jeden z použitých zdrojů neuvádí; dokumentace ho popisuje jako otevřený standard a mezi podporovanými klienty jmenuje Claude, ChatGPT, Visual Studio Code i Cursor. Spolu se specifikací vyšly aktualizované sady SDK první úrovně.

Náš názor: přepsat protokol do bezstavové podoby takhle brzy vypadá spíš na to, že původní návrh mířil na spojení jednoho klienta s jedním serverem, kdežto provoz si vyžádal něco, co unese běžná webová infrastruktura.

Zdroje: oznámení na blogu MCP (28. července 2026) a rozbor změn na Stacktree.

Nový operační systém se dnes ohlašuje skoro každý měsíc a většina z nich skončí u README souboru. LiberSystem je jiný aspoň v jednom ohledu: kódu je tam hodně a přibývá rychle. Na druhou stranu je repozitář starý šest týdnů, hvězdiček má čtrnáct a stáhnout si hotový obraz nejde. Podívali jsme se, co za tím je.

Jádro jako malý rozhodčí

LiberSystem není distribuce Linuxu ani unixový klon. Je to samostatný systém psaný od nuly v jazyce Rust a postavený na mikrojádru. To znamená, že v privilegovaném režimu běží jen nezbytné minimum: správa paměti, plánování, meziprocesová komunikace a hlídání přístupu k hardwaru. Ovladače, souborové systémy i síť jsou obyčejné služby v uživatelském prostoru. Když ovladač spadne, správce zařízení mu odebere oprávnění a restartuje ho, místo aby padl celý stroj. Linux to má obráceně, většina ovladačů žije uvnitř monolitického jádra.

Druhý pilíř je kapabilitní model. Kapabilita je nepadělatelný odkaz na objekt jádra spolu se seznamem práv, jako je čtení, zápis nebo mapování paměti. Proces nemá žádná okolní oprávnění, dostane jen to, co mu někdo výslovně předá. Účet root, který smí všechno, v tomhle návrhu neexistuje vůbec. Dokumentace to shrnuje tak, že komponenta smí pojmenovat věc, na kterou nedosáhne, protože pravomoc žije jen v kapabilitě, ne ve jméně.

Třetí odlišnost se týká disků. Místo jednoho globálního stromu s přípojnými body pracuje LiberSystem s explicitními svazky. Cesta patří vždy právě jednomu svazku, který se identifikuje podle UUID, a je to typovaný objekt, ne řetězec znaků. Jednotlivé části cesty jsou položky seznamu, takže klasický útok přes dvě tečky a lomítko nemá kde vzniknout. Když svazek není dostupný, operace selže. Nikdy potichu nezapíše na jiný disk.

Aplikace: nativní rozhraní a nad ním WebAssembly

Základní smlouva pro aplikace je nativní typované rozhraní přes kapability, stejné, jaké používá jádro a systémové služby. Nad ním má běžet hostitel pro WebAssembly, konkrétně Component Model a rozhraní WASI. Kalkul je jednoduchý: jeden balíček aplikace poběží na architektuře x86-64, ARM64 i RISC-V a je izolovaný už z principu.

Autoři si přitom nechali zadní vrátka. V návrhovém dokumentu stojí, že WASI je jen jeden z hostitelů nad stabilním nativním kontraktem, ne definice systému. Pokud se ta poměrně mladá specifikace změní, přepíše se jedna vrstva a ne celé jádro. Kompatibilita s POSIX, tedy schopnost spouštět běžný unixový software, je v plánu jako volitelná překladová vrstva v uživatelském prostoru. Zatím není.

Co už opravdu běží

Snímky obrazovky na webu projektu ukazují víc než obvyklý „ahoj světe“ z jádra. Systém nabootuje pod emulátorem QEMU, rozjede všechna procesorová jádra (na snímku 52 z 52), spustí ovladače virtio pro disk, síť, konzoli, vstup, grafiku a zvuk, k tomu ovladač USB řadiče xHCI, přihlásí jedenáct zařízení a nastaví síť přes DHCP. Pak naskočí textový shell s výzvou ve tvaru vol://.

Na dalším snímku je vidět výpis přerušení, překlad doménového jména a příkaz ping, který umí vypsat výsledek jako JSON. To je praktická ukázka principu, na kterém systém stojí: existuje jedno typované rozhraní a binární podoba, JSON, CBOR i čitelný text jsou jen jeho reprezentace. Banner v konzoli hlásí verzi 0.0.1.

Sestavit se to dá zatím jen na Linuxu s noční verzí Rustu. Skript stáhne toolchain, příkaz just build přeloží jádro i uživatelskou část a just run ji spustí v emulátoru. Bootovatelný obraz pro reálný počítač s UEFI vyrobit jde, starý BIOS projekt nepodporuje. Jestli někdo LiberSystem skutečně nabootoval na fyzickém železe, se mi ověřit nepodařilo. Všechny doložené snímky pocházejí z emulátoru a i dokumentace mluví o testech v QEMU.

Kdo za tím stojí a jak je to staré

Za projektem je organizace LiberSoft, která na GitHubu vede i decentralizované sdílení souborů LiberShare a starší komunikační projekt Yellow. Všechno pod licencí Unlicense, tedy uvolněné do veřejného vlastnictví. Kontaktní adresa uvedená na webu vede do Liberlandu, což je mikrostát na sporném území u Dunaje. Web i návrhové dokumenty existují v české verzi a analytiku měří česká služba, takže čeští autoři jsou pravděpodobní. Konkrétní jména ale nikde uvedená nejsou a nepodařilo se mi je ověřit.

Repozitář vznikl 17. června 2026. Za šest týdnů do něj přibylo přes sedm set commitů, tempo se drží mezi osmdesáti a stošedesáti commity týdně a poslední změna je z dneška. Přispěvatel je ale jediný účet, forků nula, otevřených issues nula. Návrhový dokument má přes osmdesát kilobajtů textu a existuje v angličtině i češtině, k tomu je popsaný model hrozeb, vlastní jazyk pro definici rozhraní a formát nativního souborového systému. Na projekt starý šest týdnů je to nezvykle důkladná dokumentace.

Co chybí a kde je riziko

Vydání zatím žádné. Tlačítko „Stáhnout“ na webu vede na stránku vydání na GitHubu, která je prázdná, a projekt to sám přiznává větou, že vydání se publikují, jakmile budou k dispozici. Kdo si chce systém zkusit, musí ho přeložit ze zdrojových kódů.

Model hrozeb otevřeně vyjmenovává, co ještě řešené není: ověřený start systému a podepsaný obraz, postranní kanály typu Spectre, fyzické útoky na hardware, šifrované svazky ani formální verifikace jádra. Jádro je tedy důvěryhodné, ale nedokázané. To není podvod, je to poctivé přiznání stavu, ale mění to význam slova „bezpečný“ v marketingovém popisu.

Plán vývoje má sedm fází. Grafické rozhraní a desktop jsou až v páté, kompatibilita s POSIX a podpora reálných počítačů ve čtvrté. Aktuální prioritou je fáze pro takzvané appliance, tedy jednoúčelová síťová zařízení. Cesta k systému, na kterém by šlo pracovat, je pořád dlouhá.

Riziko číslo jedna je podle mého názoru jediný přispěvatel. Kód, dokumentace i web stojí na jednom účtu, a pokud ten přestane, nemá projekt kdo převzít. Slabinou je i licence Unlicense: dává maximální volnost, ale patenty neřeší nijak, což velké firmy u systémového softwaru sledují.

Pozornost zvenčí je zatím minimální. Odkaz na Hacker News z 8. července získal jediný bod a jediný komentář, ve kterém se čtenář ptá, čím se LiberSystem liší od existujících mikrojader v Rustu, jako je Redox, Tock nebo Xous. Odpověď tam nepřišla. Vlákno na fóru jazyka Rust má pár reakcí. České weby, které o projektu psaly, převzaly texty z jeho vlastních stránek a nic neověřovaly.

Pro koho to dnes je

Nasadit LiberSystem na cokoliv, na čem záleží, dnes nejde a autoři to netvrdí. Pokud hledáte bezpečnější počítač na práci, tohle není odpověď a nebude jí ani příští rok. Zajímavý je jinak: jako čitelně napsaný a rychle rostoucí příklad toho, jak by vypadal systém postavený od začátku na kapabilitách a typovaných objektech. Kdo se učí psát jádra nebo ho zajímá návrh operačních systémů, dostane osmdesát kilobajtů promyšleného textu zdarma a k tomu kód, který nabootuje.

Zdroje: web projektu LiberSystem, repozitář na GitHubu včetně návrhového dokumentu a modelu hrozeb, a diskuse na Hacker News. Údaje o stáří repozitáře, počtu commitů a přispěvatelů pocházejí z veřejného rozhraní GitHubu ke dni 27. července 2026.

Skupina Khronos vydala 31. července aktualizaci specifikace Vulkanu s označením 1.4.358. Přibylo v ní jediné nové rozšíření, zato takové, pod kterým jsou podepsaní lidé z AMD, Valve, Samsungu, NVIDIE, Intelu a Nintenda: VK_EXT_image_tiling_control.

Dvě hodnoty, za kterými se skrývá víc možností

Obrazem (VkImage) se ve Vulkanu myslí blok obrazových dat v paměti grafické karty – textura, plocha, na kterou se vykresluje, hloubková mapa. Jak se ta data v paměti poskládají, dosud řídily dvě hodnoty. VK_IMAGE_TILING_LINEAR je ukládá po řádcích za sebou, jak by je člověk psal na papír. VK_IMAGE_TILING_OPTIMAL nechává uspořádání na ovladači: ten si obraz rozseká na dlaždice a poskládá je tak, aby bylo čtení sousedních bodů rychlejší.

Návrhový dokument rozšíření to popisuje jako typický kompromis mezi místem a časem: lineární uspořádání šetří paměť, optimální zrychluje přístup. Potíž je v tom, co se skrývá pod druhou z těch hodnot. Karta jich totiž může umět víc – několik různých optimálních uspořádání, každé s jinou spotřebou paměti a jinou rychlostí – a která se použije, si ovladač vybírá sám. Aplikace o té volbě neví a nemá ji jak ovlivnit.

Podle návrhu má přitom vývojář navíc informace, ke kterým se ovladač nedostane: ví, jak se obraz bude používat, a zná cílovou platformu. „Byly zjištěny případy, kdy ovladač nedokáže bez dalších podrobností zvolit nejlepší možnost pro všechny aplikace,“ stojí v dokumentu (přeloženo z angličtiny). Dosavadní náhrada byla nepřímá – měnit parametry vytvoření obrazu a pak měřit, jestli se uspořádání vůbec změnilo. Že ladění a měření vadí vývojářům shaderů ze všeho nejvíc, ukázala i anketa Khronosu mezi více než čtyřmi sty z nich.

Tři hodnoty místo zkoušení

Rozšíření přidává strukturu VkImageTilingControlCreateInfoEXT, kterou aplikace připojí k popisu vznikajícího obrazu. Obsahuje jedinou položku a ta nabývá tří hodnot:

• VK_IMAGE_TILING_CONTROL_DEFAULT_EXT – chová se stejně, jako by struktura nebyla připojená vůbec;
• VK_IMAGE_TILING_CONTROL_MIN_SIZE_EXT – ovladač má zvolit uspořádání s nejmenší spotřebou paměti;
• VK_IMAGE_TILING_CONTROL_MAX_PERFORMANCE_EXT – má zvolit to nejrychlejší, i za cenu vyšší spotřeby.

Vedle toho přibývá příznak imageTilingControl; podle návrhu ho musí karta podporovat vždy, když podporuje samotné rozšíření. Návrh vysvětluje i to, proč nestačil jeden přepínač: u pouhého zapnuto/vypnuto by se muselo dodat zvlášť zjišťování výchozího chování, a to se může časem měnit.

Záruka platí jen v jednom směru

Hodnota pro nejmenší velikost je závazná: paměťový nárok obrazu s ní nesmí být větší než u zbylých dvou. U hodnoty pro nejvyšší rychlost žádný slib není. Návrh to říká rovnou – doba přístupu k obrazu závisí na příliš mnoha věcech, takže ovladač udělá, co může. Obě volby se navíc u některých obrazů srovnají do téhož výsledku; třeba tam, kde rozměry přesně vycházejí na velikost dlaždice, žádný kompromis neexistuje.

Zato se volba musí promítnout do dotazů, kterými si aplikace zjišťuje velikost a rozvržení obrazu ještě před jeho vytvořením. Jinak by si vývojář vyžádal úsporné uspořádání a paměť si naplánoval podle čísel platných pro jiné.

Zarovnání šlo ovlivnit už dva roky, uspořádání ne

Ve specifikaci je rozšíření VK_MESA_image_alignment_control, jehož jediným autorem je Hans-Kristian Arntzen z Valve; popis rozšíření nese datum poslední úpravy 3. května 2024. Řeší příbuzný problém z druhé strany: aplikace jím žádá o menší zarovnání obrazu v paměti, než jaké by karta jinak vyžadovala. Popis uvádí jako příklad vrstvení nad rozhraním Direct3D 12, kde se u umísťovaných prostředků počítá s určitým zarovnáním a napodobit to jinak znamená plýtvat výplní.

Nové rozšíření to starší neruší a Arntzen je podepsaný i pod ním. Když aplikace určí strop zarovnání, musí to omezit i výběr uspořádání – obojí platí zároveň.

Co dalšího v 1.4.358 je

Zbytek aktualizace jsou opravy a upřesnění: rozvolnění požadavku na jedinečnost identifikátoru paměťového objektu v hlášení o alokacích, upřesnění, že rozložení VK_IMAGE_LAYOUT_PREINITIALIZED se týká jen lineárních obrazů, nebo dovolení, aby dotaz na počet ořezaných útvarů přeskočil zdegenerované trojúhelníky. Vydání také přebírá změny z bezpečnostně kritické varianty Vulkan SC 1.0.22.

Předchozí aktualizace 1.4.357 vyšla 17. července, mezi oběma je tedy čtrnáct dní. Stejnou dvoutýdenní pauzu bez aktualizace specifikace zmiňuje i server Phoronix.

Ve specifikaci ano, v ovladači zatím neznámo

Rozšíření nese pořadové číslo 688 a revizi 1 z 19. června 2026; jako autor je u něj uvedený Noah Fredriks z AMD. Je to rozšíření zařízení, tedy volitelná část rozhraní – aplikace si musí zjistit, jestli ho konkrétní karta a ovladač nabízejí. Jestli už to některý z nich umí, se ze seznamu změn nepozná – o implementacích v něm není nic.

Strojový popis rozhraní, ze kterého se generují hlavičkové soubory, dnes vede 472 rozšíření označených jako podporovaná pro Vulkan. Sto padesát jedna z nich má předponu EXT a 149 předponu KHR; příloha specifikace ta první označuje za vícedodavatelská a ta druhá za khronosovská.

Zdroje: seznam změn ve Vulkanu 1.4.358, návrhový dokument rozšíření, jeho příloha ve specifikaci, příloha k VK_MESA_image_alignment_control a zpráva serveru Phoronix. Počty rozšíření jsou spočítané ze souboru vk.xml ve stejné verzi.

Proč by měl otevřený ovladač zajímat i uživatele Windows

Autor zprávy Louis-Francis Ratté-Boulianne vypisuje, co by se získalo: jedna kódová základna pro obě platformy, snazší ladění a pokusy, rychlejší opravy a možnost, aby chyby hlásili nebo opravy posílali lidé mimo AMD, třeba vývojáři her. Oprava by pak platila bez ohledu na operační systém.

Valve na tom má praktický zájem. Firma už dnes platí několik vývojářů pracujících na RADV a na dalších částech linuxové grafické vrstvy; podle serveru Phoronix má ovladač velký podíl na tom, jak dopadl Steam Deck a nově Steam Machine.

Privátní data, která nikdo nepopsal

Projekt navazuje na práci Faith Ekstrand. Ta proveditelnost zkoumala jako první a výsledky přednesla na konferenci XDC 2024. Podstatné zjištění: od Windows 10 existuje rozhraní WDDM2, které slušně popisuje, jak spolu má mluvit ovladač v uživatelském prostoru (UMD) a ovladač v jádře systému (KMD).

Háček je v tom, že spousta volání s sebou nese privátní data výrobce. Jsou to neprůhledné bloby, jejichž obsah si určuje ovladač sám, takže obě poloviny zůstávají pevně svázané a rozhraní mezi nimi není nikde zdokumentované. Ekstrand kvůli tomu napsala nástroj wddm2-pdd-re, který u vybraných aplikací D3D12 zaznamenává volání i obsah těch dat. Zpětným rozborem se dostala tak daleko, že RADV dokázal poslat práci uzavřenému ovladači v jádře, a na obrazovce se jí nakonec otočil trojrozměrný model.

Od modelu k první hře

Collabora si k tomu vytkla tři cíle: ubrat napevno zadané hodnoty, aby ovladač zvládl různý hardware, rozběhat ho přímo na Windows místo v prostředí WSL a hlavně ho stabilizovat. Dosavadní verze totiž padala po dvou minutách testů deqp-vk. Přibylo zpracování command streamu a synchronizace, dále sparse bindings, tessellation, task shadery a dynamické zjišťování vlastností karty.

Zpráva výsledek neuhlazuje. Ovladač pořád není konformní, i když úspěšnost testů podle Collabory výrazně stoupla. Zato na něm běží první hra: Counter-Strike 2. Podle zprávy si to s tímhle ovladačem může zkusit každý, stačí hru spustit s parametrem -vulkan.

Kde to drhlo

Collabora pracovala na Radeonu RX 7900 XT, kdežto Ekstrand na RX 7800 XT, a rozdíly mezi kartami znamenaly, že se cizí výsledky dlouho nedařilo zopakovat. Jakmile se zkusilo něco víc než vyplnit plochu napevno zadanou barvou, karta se zasekla. Nástroje na ladění takových zásek na Windows nejsou, takže si je museli postavit sami: z reverzní utility udělali plnou logovací vrstvu WDDM2, která umí rozebrat libovolnou aplikaci běžící pod oficiálním ovladačem Vulkan, a přidali výpis command streamů, registrů a kódu shaderů.

Druhá potíž byla přízemnější. Mesa se vyvíjí hlavně proti překladačům GCC a Clang a spoléhá na předpoklady, které u Microsoftího MSVC neplatí. Zpráva jmenuje zacházení s výčtovými typy: MSVC umí hodnotu vzít jako znaménkovou a omezit ji na 32 bitů, což vede k překvapivému chování.

Bez AMD se dál nepokročí

Největší otevřená otázka je právě rozhraní k uzavřenému ovladači v jádře. Psát vlastní KMD Collabora za reálnou možnost nepovažuje, takže musí mluvit s tím od AMD. Dnes to stojí na zpětně odvozené znalosti privátních datových struktur, a to je křehké ze své podstaty: uživatelská a jádrová část se dodávají jako pár, žádnou zpětnou kompatibilitu si neslibují a struktury se můžou změnit s libovolnou novou verzí ovladače bez ohlášení.

Aby byl RADV na Windows opravdu stabilní a udržovatelný, potřebuje podle Collabory jedno ze dvou. Buď stabilní a zdokumentované rozhraní k uzavřenému ovladači v jádře, nebo mezivrstvu, která komunikaci zprostředkuje a udrží tvar i tehdy, když se bloby pod ní změní.

Druhá nedodělaná oblast je zobrazení hotového snímku. RADV na Windows zvládá zatím jen pomalejší cestu přes procesor. Použití swapchainů DXGI by vyžadovalo umět importovat obraz z D3D12 a poslední stupeň, výměna snímků bez kopírování, by podle zprávy mohl u aplikací neomezených výkonem karty přinést až trojnásobek. Ten krok už se ale neobejde bez přímé účasti AMD a nejspíš i Microsoftu.

Co je vidět v repozitáři

Kód leží ve větvi wddm2 ve vlastní kopii Mesy na GitLabu freedesktop.org. Commitů s datem 23. července 2026 je tam čtyřicet, třiatřicet od Ratté-Boulianna a sedm od Ekstrand. Větev končí commitem, jehož název začíná slovem HACK, což o stavu práce vypovídá podobně jako celá zpráva.

Podle nás je tohle zajímavější jako signál než jako software. Použitelný ovladač z toho zatím není a Collabora si to nenamlouvá; smysl té práce je ukázat AMD, že o otevřený Vulkan na Windows je zájem, a že dokud výrobce nedodá popsané rozhraní, zbývá jen zpětné odvozování cizích datových struktur.

Zdroje: Cracking Windows Open: Porting RADV to WIN32 na blogu Collabory, zpráva Valve Sponsors Work Bringing Open-Source RADV Driver To Windows na Phoronixu a větev wddm2 v repozitáři Mesy.

Unity je po Unrealu druhý nejpoužívanější nástroj na stavbu her. Na konferenci Unite Seoul v Jižní Koreji firma 21. července 2026 zveřejnila plán vývoje sedmé generace. Není to vydání ani beta – je to rozvrh, co a kdy přijde.

Termíny a čísla, která firma uvedla

Podle tiskové zprávy začne uzavřené testování bety v prosinci 2026 a plné vydání je plánované na první čtvrtletí 2027. Server Game Developer, který o oznámení psal nezávisle, uvádí opatrněji „začátek roku 2027“.

Z výkonnostních údajů zpráva jmenuje jediné číslo: sestavení shaderů, tedy programů pro grafickou kartu, má být až o 90 % rychlejší než v šestce. Zbytek slibů je popisný – „téměř okamžitý“ přechod do herního režimu a znovunačtení kódu jen pro to, co se opravdu změnilo.

Novinky firma rozdělila do pěti okruhů: rychlejší práce v editoru, otevřenější okolí (nové rozhraní příkazové řádky a veřejné programové rozhraní), grafika s osvětlením Surface Cache GI, nástroj Unity Vector na výdělek ze hry a slib, že se nic nerozbije. Součástí druhého okruhu je i bezplatné napojení přes protokol MCP, kterým se do vývoje mají zapojit programovací agenti postavení na jazykových modelech. Game Developer k tomu cituje z prezentace formulaci, že volba, jestli je tým použije, „je vždy na týmu, ne na platformě“.

Prezident a výkonný ředitel Unity Matt Bromberg oznámení uvedl větou, kterou překládáme: „Vývoj her se mění rychleji než kdykoli v historii. Budoucnost nepatří největšímu týmu, ale těm, kdo dokážou novou technikou vytvořit něco svébytného a najít publikum.“

Skutečná změna je pod kapotou

Nejpodstatnější věc na sedmičce v tiskové zprávě zaniká pod slovem „modernizace“. Unity opouští Mono – volnou implementaci prostředí .NET, na které se hry v Unity dosud spoléhaly – a přechází na CoreCLR, tedy na běhové prostředí přímo od Microsoftu. Firma si od toho slibuje vyšší výkon a kratší čekání při překladu kódu.

Tenhle přechod se přitom nechystá teprve teď. Vlastní příručka Unity Path to CoreCLR, 2026: Upgrade Guide, zveřejněná na vývojářském fóru firmy 26. března 2026, popisuje tentýž krok a váže ho k verzi 6.8, ne k sedmičce. Uvádí i verzi prostředí: .NET 10.

Kde slib „bez přepisování“ naráží

Marketingové heslo oznámení zní, že projekty, dovednosti i kód přejdou dál hladce a bez přestavby. Táž příručka k přechodu na CoreCLR je opatrnější. Doslova říká, že změna bude „z velké části zdrojově kompatibilní se stávajícími projekty, ale některé podstatné rozbíjející změny jsou v plánu“ – a pak je vyjmenovává:

• CoreCLR přísněji vynucuje pravidla přístupnosti typů, takže kód, který si sahal, kam neměl, přestane překládat.
• Třída BinaryFormatter je v .NET 10 označená za zastaralou kvůli dlouholetým bezpečnostním problémům.
• Statické konstruktory se nově volají při prvním použití dat nebo statických polí daného typu, ne při prvním překladu metod za běhu. Kdo se spoléhal na dosavadní pořadí, dostane jiné.
• Vlastnost Assembly.Location vrátí prázdný řetězec.

Rozpor to není – obojí může platit současně, protože Unity samo čeká, že přechod bude z velké části zdrojově kompatibilní. Ale kdo čte jen titulek oznámení, dozví se z něj polovinu. Experimentální podoba nového běhového prostředí je k dispozici už v alfě větve Unity 6.7 LTS; příručka u ní výslovně píše, že podporovaná není.

Jméno, které loni v prosinci zmizelo

Sedmička není nový nápad. Server GameFromScratch napsal 2. prosince 2025 po konferenci Unite v Barceloně, že v tehdejším plánu vývoje o sedmičce nepadla ani zmínka, a vyvodil z toho, že projekt skončil. Podle téhož článku se většina funkcí slibovaných pro sedmičku měla objevit v řadě 6.x a část z nich, například nové animační nástroje, byla zrušená úplně.

Unity ale zrušení nikdy neoznámilo – komentátoři ho odvodili z toho, že název na pódiu nezazněl. Tentýž server teď k návratu jména poznamenává, že sedmička je v časové ose víceméně jen Unity 6.8. To sedí s tím, co stojí v příručce firmy: přechod na CoreCLR se plánoval pod číslem 6.8.

Kde Unity mezi vývojáři stojí

Průzkum State of the Game Industry, který organizátoři konference GDC vydali letos na základě odpovědí více než 2 300 lidí z oboru, staví Unity na druhé místo. Za hlavní nástroj označilo Unreal Engine 42 % dotázaných, Unity 30 %. To je hodnocení postavení na trhu, ne měření kvality – průzkum se ptá, s čím lidé pracují, ne co je lepší.

Unity si navíc pořád nese následky poplatku Runtime Fee, kterým chtěla účtovat za instalace her a který po odporu vývojářů zrušila. Slib „nic vám nerozbijeme“ v tomhle světle není jen technické sdělení.

Co z oznámení opravdu platí, se pozná v prosinci, až začne uzavřené testování bety. Do té doby je Unity 7 rozvrh, ne nástroj.

Zdroje

• Unity 7 Roadmap Revealed At Unite Seoul – přetisk tiskové zprávy Unity z 21. července 2026
• Game Developer: Unity unveils Unity 7 roadmap
• Path to CoreCLR, 2026: Upgrade Guide – příručka Unity z 26. března 2026
• GameFromScratch: Unity 7 is Dead (2. prosince 2025) a Unity 7 is Back
• GDC 2026 State of the Game Industry

Vývojářské sdružení PostgreSQL Global Development Group vydalo 16. července 2026 druhou betu databáze PostgreSQL 19. Beta není hotové vydání a projekt to říká rovnou: „některé podrobnosti vydání se během beta období mohou změnit“ (přeloženo z angličtiny). Ostrou verzi čeká na září nebo říjen 2026 a do té doby počítá s dalšími betami a s jednou či více kandidátskými verzemi.

Za pozornost stojí hlavně to, co se do devatenáctky dostalo už v první betě ze 4. června 2026. Jednou větou: relační databáze se naučila dotazovat grafy.

Graf bez grafové databáze

Grafem se v informatice myslí struktura z uzlů a spojnic mezi nimi – lidé a jejich známosti, zákazníci a jejich objednávky, letiště a linky. Data v tomhle tvaru se v běžném SQL dotazují mizerně: každý další krok po spojnici znamená další JOIN a dotaz rychle přeroste přes hlavu. Proto vznikly zvláštní grafové databáze a s nimi povinnost udržovat data na dvou místech.

PostgreSQL 19 zavádí podporu SQL/PGQ, tedy části normy SQL věnované dotazům nad grafy. Podle oznámení projektu umožňuje „provádět dotazy nad grafy vlastností pomocí syntaxe podle normy SQL“ (přeloženo). Grafem se přitom nestává nic nového – jen se nad existující tabulky položí popis, co je uzel a co spojnice:

CREATE PROPERTY GRAPH myshop
    VERTEX TABLES (
        products,
        customers,
        orders
    )
    EDGE TABLES (
        order_items SOURCE orders DESTINATION products,
        customer_orders SOURCE customers DESTINATION orders
    );

Dotaz se pak píše konstrukcí GRAPH_TABLE, ve které se cesta grafem kreslí šipkami:

SELECT customer_name FROM GRAPH_TABLE (myshop
    MATCH (c IS customers)-[IS customer_orders]->(o IS orders
        WHERE o.ordered_when = current_date)
    COLUMNS (c.name AS customer_name));

Výsledkem je obyčejná tabulka, se kterou se dá dál pracovat jako s čímkoli jiným. Server InfoQ shrnul význam té změny tak, že PostgreSQL 19 „umožňuje grafové dotazy nad existujícími relačními tabulkami, aniž by byla potřeba samostatná grafová databáze nebo přesun dat“ (přeloženo).

Přestavba tabulky skoro bez zámku

Druhou novinkou je příkaz REPACK. Ten přepíše celý obsah tabulky do nového souboru na disku bez volného místa navíc, takže se místo po smazaných řádcích vrátí operačnímu systému. Dosud se totéž dělalo příkazem VACUUM FULL, o kterém dokumentace píše, že „vyžaduje zámek ACCESS EXCLUSIVE na každou zpracovávanou tabulku“ (přeloženo) – tedy nejpřísnější druh zámku, po jehož dobu se s tabulkou nedá dělat vůbec nic.

Podstatná je u REPACKu volba CONCURRENTLY. S ní se podle dokumentace tvrdý zámek bere „jen na výměnu souborů tabulky a indexu“; změny, které mezitím do tabulky přišly, se zachytí logickým dekódováním a dohrají předtím, než si příkaz o zámek řekne. Zámek se tak drží jen krátce, ne po celou dobu přestavby.

Vstupy a výstupy, které se ladí samy

Asynchronní vstupně-výstupní podsystém přišel do PostgreSQL už v osmnáctce. Zjednodušeně: databáze nečeká na každé čtení z disku, ale zadá jich víc naráz a zpracovává je, jak se vracejí. Nevýhodou bylo, že počet pracovních procesů pro tuhle práci musel správce nastavit ručně.

V devatenáctce se počet škáluje sám podle nových parametrů io_min_workers a io_max_workers. Christophe Pettus ze společnosti PGX k tomu ve svém rozboru z 23. dubna 2026 doporučuje správcům, kteří počet nastavovali ručně na osmnáctce, aby to zrušili a vyzkoušeli výchozí hodnoty devatenáctky. Přibyly také parametry io_worker_idle_timeout a io_worker_launch_interval a příkaz EXPLAIN ANALYZE nově umí volbu IO, která ukáže, kolik čtení dotaz opravdu vydal.

Drobnosti, které potěší denní provoz

Seznam dalších změn z oznámení první bety je delší, než se sem vejde. Za zmínku stojí čtyři:

• GROUP BY ALL – místo ručního vypisování všech neagregovaných sloupců stačí jedno slovo.
• WAIT FOR LSN – příkaz, po kterém replika počká, až k ní dorazí konkrétní místo v protokolu změn. Řeší tím starý problém, kdy aplikace zapíše na hlavní server a hned nato čte z repliky data, která tam ještě nedorazila.
• Replikace sekvencí – logická replikace nově přenáší i hodnoty sekvencí, což podle projektu zjednodušuje povýšení verze za provozu.
• Paralelní autovacuum – automatický úklid smí zapřáhnout víc procesů naráz, počet omezuje nový parametr autovacuum_max_parallel_workers.

René Cannaò, zakladatel projektu ProxySQL, označil pro InfoQ za důležitou právě konstrukci WAIT FOR LSN kvůli sladění čtecích replik.

Co beta 2 opravila

Druhá beta je oprava chyb, ne nová funkčnost. Její seznam ale prozrazuje, kde to zatím drhne: mezi opravami je „několik oprav nové vlastnosti grafů podle SQL/PGQ“ a „několik oprav nové syntaxe FOR PORTION OF pro časové tabulky“ (přeloženo). Opraveno bylo i to, že proces příkazu REPACK po havarijním ukončení nezmizel, jak měl.

Beta není vydání

Hodnocení: SQL/PGQ je z uvedených novinek jediná, která mění, co se s databází vůbec dá dělat. Zbytek jsou vylepšení provozu – a právě ta možná rozhodnou o tom, jestli se firmám vyplatí povýšit. Christophe Pettus to pro InfoQ shrnul tak, že změny v devatenáctce, které nejspíš ovlivní chování v provozu, nejsou ty, o kterých se píše v titulcích (přeloženo).

Do produkčního nasazení nicméně vede ještě dlouhá cesta. Beta slouží k testování, projekt sám upozorňuje, že se podrobnosti můžou změnit, a datum ostrého vydání je zatím jen odhad na září či říjen.

Zdroje: oznámení druhé bety PostgreSQL 19 a oznámení první bety od PostgreSQL Global Development Group, rozbor serveru InfoQ, text Christopha Pettuse o asynchronním I/O a dokumentace ke grafům vlastností.

Shader je krátký program, který běží na grafickém čipu – typicky rozhoduje o tom, jakou barvu bude mít každý jednotlivý bod na obrazovce, ale počítá se jím i geometrie nebo úloha, která s vykreslováním nesouvisí vůbec. Píšou ho lidé, kteří dělají hry, filmové efekty i vědecké vizualizace, a čísel o tom, co je na té práci nejtěžší, moc není. Konsorcium Khronos Group zveřejnilo 21. července zprávu, která se o to pokouší.

Khronos vydává grafické normy, mimo jiné Vulkan, OpenGL a formát glTF. Dotazník sbíral odpovědi od 16. června do 10. července 2026 a vyplnilo ho přes 400 lidí – grafických programátorů, vývojářů her a enginů, rendering inženýrů a autorů nástrojů.

Kdo odpovídal

Největší skupinou byli grafičtí programátoři (35 procent) a vývojáři her a herních enginů (29 procent). Zbytek tvořili rendering inženýři, autoři middlewaru a nástrojů, výzkumníci a techničtí výtvarníci.

Obor, ve kterém respondenti pracují, potvrzuje, kde se shadery používají nejvíc: hry uvedlo 79 procent. Vedle nich se objevil middleware a nástroje (26 procent), vědecká vizualizace (16 procent), průmyslová vizualizace, film a rozšířená realita.

Zajímavější je rozložení platforem. Windows používá 88 procent dotázaných, Linux 74 procent a macOS 35 procent. Sedmdesát čtyři procent u Linuxu je na obor, kde vládnou hry pro Windows, hodně – Khronos to sám v textu označuje za nápadné a vykládá si to jako známku toho, že velká část lidí píše shadery mimo hry, ve výpočtech a strojovém učení.

Ladění bolí nejvíc

Nejsilnější výsledek celého průzkumu je jednoznačný. Ladění a profilování shaderů zařadilo mezi tři největší problémy 53 procent respondentů, což je o víc než patnáct procentních bodů před druhou položkou v pořadí.

Khronos se ptal i na míru: jak bolestivé je dnes ladění a profilování na cílových platformách, na stupnici od nuly („naprosto v pohodě“) do sta („denní noční můra“). Průměr vyšel 52. Rozložení je ale vychýlené nahoru – nejobsazenější je pásmo 61 až 80, které označilo 31 procent lidí, a spolu s pásmem nad 80 dalo hodnocení v horní části stupnice 40 procent dotázaných. Přesně sto, tedy maximum, zvolilo třináct lidí.

Proč zrovna ladění, zpráva nerozebírá. Podle nás za tím stojí povaha úlohy: shader běží na grafickém čipu po tisících kopií naráz a klasické nástroje na krokování programu se na něj špatně roubují. Když se výsledek na obrazovce liší od očekávání, vývojář často nemá jak zjistit, která z těch kopií a v jaké chvíli spočítala něco jiného.

Přenášení mezi platformami

Druhý opakovaný problém je přenositelnost. Nějaké úsilí na přizpůsobování shaderů mezi platformami, rozhraními nebo nástroji vynakládá 64 procent dotázaných. Skoro desetina to popsala jako významný náklad, nebo dokonce jako jednu z největších inženýrských položek vůbec.

Ve volných odpovědích se podle Khronosu opakovala poptávka po ukazatelích, volání funkcí a skutečné práci s adresami – tedy po tom, aby se jazyky pro grafické čipy chovaly spíš jako běžné systémové programovací jazyky.

Čím se dnes shadery píšou

Nejrozšířenější zůstává GLSL se 60 procenty, následuje HLSL se 41 procenty a SPIR-V, které přímo nebo přes nástroje používá 39 procent dotázaných. Čtvrtý skončil Slang s 34 procenty.

U Slangu je namístě jedna poznámka. Je to projekt, jehož repozitář vznikl v roce 2017; dřív patřil NVIDII a dnes ho pod otevřenou správou hostuje sám Khronos, jak uvádí stránky projektu – konsorcium tedy v tomto bodě měří rozšíření vlastního projektu. Neznamená to, že je číslo špatně; znamená to, že ho vydal ten, komu se hodí. Slang měl v době psaní článku na GitHubu necelých pět a půl tisíce hvězd a poslední změna v něm je stará hodiny.

Respondenti u jazyků zmiňovali, že by pomohla stabilnější překladač, lepší dokumentace a celkově příjemnější práce. To platí i pro Slang, u kterého Khronos tuhle zpětnou vazbu uvádí výslovně.

Co s tím chce Khronos dělat

Nejvýš hodnocenou možností byl společný standard pro ladění shaderů napříč výrobci – zájem o něj dostal 4,18 bodu z pěti. Ochotu zapojit se do budoucích pracovních skupin nebo připomínkových kol vyjádřilo 73 procent dotázaných.

Objevil se i návrh, aby konsorcium vzalo pod křídla další projekty: VCC/Shady, tedy překladač Clang pro Vulkan, a Rust-GPU, který má z Rustu udělat jazyk pro psaní shaderů. Část respondentů ale zároveň upozorňovala, že vedle nových věcí je potřeba dál zlepšovat nástroje, které už existují.

Co z čísel nevyplývá

Průzkum si zadalo, provedlo i vyhodnotilo jedno konsorcium a zveřejnilo ho na svém blogu. Odpovědi nesbíral nezávislý subjekt a surová data má k dispozici jen Khronos – členům je nabízí jako tabulku na vyžádání, veřejně je k dispozici zpráva se sedmnácti otázkami v PDF.

Vzorek navíc vznikl samovýběrem: odpovídal ten, kdo o dotazníku věděl a chtěl. Přes 400 lidí je na anketu v úzkém oboru slušné číslo, ale není to reprezentativní vzorek všech, kdo shadery píšou. Podle nás jsou proto použitelná spíš pořadí a velké odstupy – jako těch patnáct procentních bodů u ladění – než jednotlivá procenta na desetinu přesně.

Zdroje: zpráva Khronos Group o výsledcích průzkumu, stránky projektu Slang a repozitáře shader-slang/slang a Rust-GPU/rust-gpu.

Červen byl na commity rekordní, 558 proti 534 v dubnu a 391 v květnu. Projekt u toho poznamenává, že za měsíc pročítá přes čtyřnásobek toho, co v září 2023, kdy s měsíčními zápisy začínal. Kvůli tomu spustil robota, kterému autor štítkem řekne, že jde o zajímavou změnu, a on mu pak položí otázky, které se z kódu nevyčtou: koho se úprava týká, jestli je vidět a jestli se musí zapnout přepínačem.

Weby, které se vykreslí líp

Nejvíc je na vydání vidět práce na skutečných stránkách. Podle projektu se výrazně zlepšilo rozvržení na šachovém serveru lichess.org a jinak psaná podpora proměnných fontů (#45768) udělala čitelnějšími další weby, jmenovitě Zulip a Speedtest. Google Photos a australský Cash Converters fungovaly už dřív a fungují dál. Mapy Google a OpenStreetMap se vykreslí dobře, jenže ovládání v nich vázne.

S tím souvisí dotazy na média, tedy pravidla, kterými stránka pozná, na čem se zobrazuje. Servo jich přidalo hned několik naráz: rozměrové device-width, device-height, height a aspect-ratio včetně variant min- a max-, k tomu orientation, pointer, any-pointer, hover a any-hover. Web, který podle nich přepíná rozvržení nebo velikost ovládacích prvků, se jimi ve Servu do té doby řídit nemohl.

Z nových rozhraní DOM přibyl SharedWorker, tedy vlákno na pozadí sdílené více kartami téhož webu, dále vlastní registry pro uživatelské HTML prvky a zachytávání ukazatele přes setPointerCapture(). Demonstrační prohlížeč servoshell mezitím dostal přetahování souborů myší, vodorovně posuvnou lištu karet a na Androidu nově vyžaduje verzi 13 a novější.

Označit text ve stránce se teprve začalo psát

Ve stejném zápisu stojí věta, která o zralosti Serva řekne víc než seznam funkcí: projekt začal pracovat na viditelném a interaktivním výběru textu (#46107) a sám ho označuje za jednu z nejdéle očekávaných funkcí jakéhokoli prohlížeče. Ve verzi 0.4.0 tedy text ve stránce myší neoznačíte.

Za přepínačem zůstává i přístupnost, tedy zpřístupnění obsahu odečítačům obrazovky: kód existuje, spouští se ale volbou --pref accessibility_enabled. Totéž platí pro WebGPU, pro webové animace a pro obecnější podobu funkce attr() v CSS. V servoshellu se to všechno zapíná najednou v experimentálním režimu.

Opravy z Firefoxu ESR a jedna díra, která zůstává

JavaScript ve Servu obstarává SpiderMonkey, tedy motor Firefoxu. Verze 0.4.0 ho posunula ze 140.10.1 na 140.11.0 a pak na 140.12.0. První skok zavírá čtyři chyby z oznámení MFSA 2026-48 k Firefoxu ESR 140.11: CVE-2026-8388, CVE-2026-8391, CVE-2026-8974 a CVE-2026-8975. Mozilla to oznámení vydala 19. května, do vydání Serva se ty opravy dostaly na konci července. U druhého skoku, k němuž patří MFSA 2026-58 ze 16. června, projekt píše, že zatím neví, které z tamních chyb se ho týkají.

Vlastní chybu Servo opravilo ve výpisu adresářů na file:///. Jméno souboru, ve kterém byl řetězec </script>, se dalo použít k podstrčení cizího HTML.

Jedna zranitelnost naopak zůstává otevřená a projekt na ni upozorňuje sám. Operace RSA v rozhraní SubtleCrypto sice nově počítají modulární mocninu v konstantním čase, jenže použitá knihovna rsa je pořád zranitelná útokem Marvin: z rozdílů v době výpočtu, měřitelných po síti, jde odvodit soukromý klíč. Záznam RUSTSEC-2023-0071 ho vede od listopadu 2023, hodnotí ho známkou 5,9 a v kolonce s opravenou verzí má „no patched versions“.

Rust nemá stabilní ABI, dopisuje se rozhraní v céčku

Servo se má dát vložit do cizí aplikace a právě tady naráží na jazyk, ve kterém je psané. Rust nemá stabilní binární rozhraní, takže dosud šlo Servo vestavět jen tak, že si ho vývojář přeložil ze zdrojových kódů. Projekt proto navrhuje obalové rozhraní v céčku (#44984), přes které půjde použít předem sestavenou sdílenou knihovnu. Nad ním má později vzniknout obal v Rustu, aby zůstalo pohodlí jazyka a odpadl překlad celého jádra.

Šetřit se zkoušelo i uvnitř. Servo umí v částech kódu dokázat, že tam nemůže proběhnout úklid paměti v JavaScriptu, a v takovém úseku pak nemusí objekty zamykat proti uklizení. Na rozvržení stránky a na kolekci HTMLCollection to podle projektu ubralo přes jedno procento režie.

Servo vzniklo v roce 2012 v Mozilla Research, správu nad ním v roce 2020 převzala Linux Foundation a od roku 2023 sídlí v Linux Foundation Europe. Svůj krátkodobý cíl si projekt formuluje střízlivě: dostat se z výzkumného projektu k použitelnému jádru se stabilním rozhraním. Na to má trvalé dary ve výši 7 681 dolarů měsíčně, tedy o 0,2 % víc než v květnu, a platí z nich servery na překlad a měření i část práce správců. Náš názor: proti rozpočtům, se kterými se dělá Chrome a Firefox, je to číslo, které o tempu vypovídá líp než rekord v počtu commitů.

Microsoft vydal 8. července 2026 verzi TypeScript 7.0. Nepřináší žádnou novou vlastnost jazyka. Mění se to, čím se překládá: dosavadní překladač napsaný v JavaScriptu nahradil program napsaný v jazyce Go, který běží jako nativní kód a umí zapřáhnout víc jader naráz.

Výsledek stojí za pozornost. Úplné sestavení zdrojových kódů editoru Visual Studio Code trvalo na šestce 125,7 sekundy, na sedmičce 10,6 sekundy. To je bezmála dvanáctinásobné zrychlení téže práce nad týmž kódem.

Přenesení, ne přepsání

TypeScript je nadstavba nad JavaScriptem, která do něj doplňuje typy. Typ je slib, jakou hodnotu smí proměnná nést; překladač ten slib zkontroluje a typy pak z kódu zase odstraní, protože prohlížeč o nich nic neví. Právě ta kontrola je na velkých projektech drahá – a právě ona zrychlila.

Podstatné je, jak se to udělalo. Nešlo o nový návrh překladače, ale o přenesení stávajícího kódu do jiného jazyka se zachováním jeho struktury i postupů. Microsoft to shrnuje tak, že si nová základna drží původní logiku a členění, aby zůstala slučitelná se starou. Prakticky to znamená, že sedmička kontroluje typy stejně jako šestka; kdyby je kontrolovala jinak, byla by to chyba, ne vlastnost.

Vnitřní název projektu byl Corsa, původní základna se v repozitáři označuje jako Strada. Zdrojový kód portu vznikal veřejně v repozitáři microsoft/typescript-go pod licencí Apache 2.0.

Naměřená čísla

Microsoft zveřejnil srovnání na třech otevřených projektech. Uvádí čas úplného sestavení a spotřebu paměti při něm:

Spotřeba paměti klesla mírněji, o šest až šestadvacet procent: u Visual Studio Code z 5,2 na 4,2 gigabajtu, u Bluesky z 1,8 na 1,3 gigabajtu. Zrychlila také práce v editoru – dobu, než se ve zdrojových kódech Visual Studio Code objeví hlášení o chybách, uvádí Microsoft nově pod 1,3 sekundy proti dřívějším 17,5 sekundy.

Zrychlení má dva zdroje. Prvním je nativní kód, který nemusí procházet běhovým prostředím JavaScriptu. Druhým je souběžnost: sedmička umí rozdělit kontrolu typů mezi několik pracovních vláken se sdílenou pamětí. Zapíná se volbou --checkers, výchozí počet je čtyři; volba --builders obdobně paralelizuje projekty propojené odkazy. Obě jsou zatím označené jako pokusné a existuje i --singleThreaded pro případ, že by souběžnost překážela při hledání chyb. Režim sledování změn --watch stojí na sledovači souborů z projektu Parcel, přeneseném rovněž do Go.

Firmy hlásí kratší čekání

K oznámení Microsoft připojil zkušenosti několika firem, které sedmičku zkoušely před vydáním. Ve Slacku podle nich klesl čas kontroly typů v průběžné integraci ze 7,5 minuty na 1,25 minuty a doba strávená ve frontě na sloučení změn se zkrátila o čtyřicet procent. V Canvě se čekání na vypsání chyb zkrátilo z 58 na 4,8 sekundy. Vlastní tým Microsoftu pro zpravodajské služby uvádí úsporu 400 hodin měsíčně stráveného čekáním na sestavení. Jsou to údaje od zúčastněných stran, ne nezávislé měření – řádově ale odpovídají číslům z tabulky výše.

Chybí rozhraní, na kterém stojí celá jedna vrstva nástrojů

Tady přichází druhá polovina zprávy. TypeScript 7.0 nemá veřejné programové rozhraní. Dosud si mohl cizí program překladač zavolat jako knihovnu, předat mu soubor a ptát se ho na typy. Na tom stojí nástroje, které kontrolují typy v souborech, jež nejsou obyčejný TypeScript – tedy v šablonách.

Postižené jsou Vue, Svelte, Astro, MDX a šablony Angularu. Nástroje jako Volar, které typovou kontrolu v šablonách zajišťují, se na sedmičku zatím napojit nedokážou. Kdo takový projekt vyvíjí, zůstává na TypeScriptu 6.0, a to i kdyby ho zrychlení lákalo sebevíc.

Microsoft slibuje nové rozhraní ve verzi 7.1. Datum k němu neuvádí. Repozitář portu u položky „veřejné rozhraní“ stále vede stav, že hotové není.

Verze 6.0, která vyšla 23. března 2026, tak dostává jasnou úlohu: je to poslední vydání postavené na dosavadní javascriptové základně a zároveň most k sedmičce. Obě verze jde nainstalovat vedle sebe.

Co ze sedmičky vypadlo

Přenesení do Go posloužilo i k úklidu. Tvrdou chybou nově končí překlad do ES5, tedy do starší podoby JavaScriptu, dále modulové systémy AMD, UMD a SystemJS, původní způsob dohledávání modulů a volba baseUrl, kterou nahrazuje výslovné vypsání cest.

Změnily se také výchozí hodnoty nastavení. Sedmička je má takto:

{
  "compilerOptions": {
    "strict": true,
    "module": "esnext",
    "rootDir": "./",
    "types": []
  }
}

Nejzrádnější je poslední řádek. Dřív si překladač typové definice ze závislostí dohledával sám; nově je nutné je vypsat, například "types": ["node", "jest"]. Kdo to neudělá, dostane hlášení o neznámých globálních jménech. Přibylo i seřazení typů, které je nově stálé a nedá se vypnout.

Zúžila se podpora JavaScriptu psaného s komentáři JSDoc. Podle soupisu úmyslných rozdílů v repozitáři portu už neprojdou funkce používané místo tříd, značky @enum a @class ve stylu knihovny Closure ani některé starší zápisy. Sjednotila se naopak práce se znaky mimo základní rovinu Unicode: řetězcová šablona nad textem „😀abc“ se nově dělí na „😀“ a „abc“, ne uprostřed dvojice kódových jednotek.

Kdy má smysl přejít

Hodnocení: přechod dává smysl hned tam, kde je projekt psaný v čistém TypeScriptu a kde kontrola typů zdržuje. Čísla jsou dost velká na to, aby se vyplatilo projít změněná nastavení a odstraněné volby.

Kdo staví na Vue, Svelte, Astru nebo šablonách Angularu, nemá zatím na výběr. A protože Microsoft k rozhraní žádný termín neuvedl, není jasné, jak dlouho ten stav potrvá – což je u vydání označeného jako stabilní nezvyklé. Ohlášené rozhraní není vydané rozhraní.

Zdroje: oznámení TypeScriptu 7.0 a oznámení verze 6.0 na vývojářském blogu Microsoftu, repozitář portu včetně soupisu úmyslných rozdílů proti šestce a nezávislý rozbor Dennise Morella.

Dialog je nástroj, který v textovém terminálu kreslí nabídky, formuláře a potvrzovací okna. Instalátor FreeBSD ho takhle používal léta, než dostal vlastní náhradu bsddialog. Zpráva u commitu to shrnuje bez okolků: jde o poslední kus softwaru pod GPL v základním systému, instalátor přešel na bsddialog před čtyřmi lety a poslední program, který dialog ještě volal, je vypnutý přes dva roky.

Věta, která stála nad tabulkou s otevřenými položkami

Projekt vede o téhle práci veřejný přehled na stránce GPLinBase. Po červencovém commitu na ni přibylo prohlášení, které nenechává prostor pro výklad: „FreeBSD is free from ANY GPL code in its Base System. Mission accomplished!“ Tedy že FreeBSD je ve svém základním systému prostý jakéhokoli kódu pod GPL.

Jenže o kus níž na téže stránce je tabulka nedodělků a v archivním snímku ze 17. července v ní jsou dvě položky ve stavu Open, tedy otevřené. Obě mají v názvu slovo kernel: gcov, tedy měření pokrytí kódu testy, a bwn, ovladač bezdrátových karet Broadcom.

Server Phoronix si toho 29. července všiml a napsal, že stránka byla mezitím upravena – nově má říkat, že bez GPL je uživatelská část základního systému, ne celý základ.

Co v jádře opravdu zůstalo

Nález se dá ověřit přímo v repozitáři. Soubor sys/dts/include/dt-bindings/soc/qcom,tcsr.h má hned na prvním řádku značku SPDX-License-Identifier: GPL-2.0 a pod ní copyright nadace Linux Foundation z let 2015 až 2018. Je to hlavičkový soubor převzatý z jádra Linuxu; definuje číselné hodnoty pro registry v čipech Qualcommu.

Druhý příklad je z popisu hardwaru: axs103.dts nese značku GPL-2.0-only a copyright firmy Synopsys. Device tree je datový popis, ze kterého jádro pozná, jaké součástky na desce jsou a na jakých adresách. Podle Phoronixu je většina ostatních nálezů GPL v jádře dvojlicencovaná, tedy použitelná i pod BSD – tyhle dva soubory ale dvojí licenci nemají.

Proč to projektu vadí

Rozdíl mezi oběma licencemi je v tom, co žádají po tom, kdo kód použije. GPL je reciproční: odvozené dílo musí vyjít znovu pod GPL. Licence BSD chce jen uvedení původu. Server Hackaday to v článku z 28. července ilustruje na dvou opačných příkladech: kód z BSD skončil v macOS i v systému herní konzole PlayStation, kdežto GPL donutila firmu Linksys otevřít firmware routerů řady WRT54G, z čehož vyrostl projekt OpenWrt.

Pro projekt, který chce mít celý strom pod jednou permisivní licencí, je jediný soubor pod GPL stejná překážka jako sto souborů. Podle nás je to důvod, proč se tak pečlivě váží formulace.

Poprvé to v hlavní větvi vydrželo dvě hodiny

Cesta k červencovému commitu nebyla přímá. Obě změny byly do hlavní větve zapsány už 29. června v 13:49 a téhož dne v 15:53 je týž vývojář vrátil zpět dvojicí revertů. Důvod v jejich zprávách nestojí. Sedmého července přišly znovu, tentokrát s odkazem na recenze D55424 a D55425 v projektovém Phabricatoru. Návrh na odstranění dialogu tam byl založený 21. února a dnes je uzavřený.

Uživatel to zatím nepozná

Změna je zatím jen v hlavní vývojové větvi. Poslední produkční vydání je podle stránky vydání FreeBSD 15.1 ze 16. června 2026; hlavní verze 15.0 vyšla druhého prosince 2025. Verze 16.0 na seznamu chystaných vydání ještě není a projekt k ní žádné datum nezveřejnil. Phoronix uvádí prosinec 2027, zdroj toho čísla ale neudává.

Prakticky se běžnému uživateli nemění nic. Instalátor vypadá stejně jako předtím, protože bsddialog kreslí tytéž nabídky, a celá věc se týká jen základního systému, ne softwaru, který si uživatel doinstaluje z portů a balíčků. Rozdíl je v tom, co smí projekt o svém stromu tvrdit. Po opravě na wiki to je o jednu větu opatrnější.

Co skončí a kdy

Datum oznámil 1. prosince 2025 Max Mether, viceprezident MariaDB pro serverové produkty. Ve firemním blogu stojí doslova: „Support for all current MySQL Galera Cluster versions ends on September 30, 2026.“ Do té doby firma slibuje opravy chyb, nové funkce už jen v MariaDB Galera Cluster. Codership, které Galeru napsalo, MariaDB plc koupila v květnu 2025 a vývojáři přešli k ní.

Migrace „na místě“ znamená jinou databázi

Firma nabízí dvě cesty: přes replikaci mezi starým a novým klastrem, nebo takzvanou in-place migraci s téměř nulovou odstávkou. To druhé označení svádí k představě, že se vymění knihovna a jede se dál. MariaDB si ale v témže textu vypisuje, co je nutné udělat předem: MariaDB má jinou strukturu systémových tabulek, datový slovník se podle firmy liší „fundamentally“, tedy zásadně, a uživatelské účty ani jejich práva se nemapují jeden na jednoho, takže je nutné je založit znovu.

Percona, která nabízí konkurenční Percona XtraDB Cluster, na to 22. července navázala vlastním čtením téže dokumentace: „you are not upgrading MySQL Galera Cluster. You are moving to a different database that also happens to use Galera.“ V překladu: nepovyšujete stávající klastr, přecházíte na jinou databázi, která taky používá Galeru. Percona je v téhle věci strana sporu a nabízí vlastní produkt, ale ta věta se opírá o migrační poznámky samotné MariaDB.

V únoru se rada Foundation od firmy odklonila

U MariaDB je potřeba rozlišovat dvě organizace: MariaDB plc je firma s produkty a zákazníky, MariaDB Foundation je nezisková organizace, která má držet kontinuitu serveru nezávisle na jakékoli firmě. Zápis ze schůze její správní rady z 25. února je veřejný a je z něj vidět, jak se rozhodovalo.

Rohit de Souza, který v radě zastupuje MariaDB plc, tam předložil plán firmy ve třech bodech: ponechat Galeru ve verzi 11.8 LTS do konce její podpory, od Community Serveru 12.3 ji vyřadit a dál ji nabízet jako součást Enterprise. Zdůvodnění podle zápisu bylo, že Galera slouží hlavně velkým provozům, že firma koupila práva ke Galeře místo toho, aby si GPL kód jen forkla, a že vývoj plně platí. Následuje věta, kterou zápis uvádí bez obalu: „Open source does not equate to ‚free for everyone in perpetuity‘.“ Tedy že otevřený zdrojový kód neznamená zdarma pro každého a navěky. K tomu poznámka, že dlouhodobá životnost Foundation závisí na tom, aby se firmě vedlo dobře.

Předseda dal radě na výběr ze tří postojů: úplně se s firmou srovnat, otevřeně se od ní odklonit a koordinovat práci komunity na GPL kódu, nebo rozhodnutí firmy respektovat a jen mírnit dopady na uživatele. Rada zvolila druhou možnost. Rozhodla, že Foundation bude „coordinate and accept community work around Galera GPL code contributions going forward“, tedy koordinovat a přijímat příspěvky komunity ke GPL kódu Galery.

Dva dny po té schůzi, 27. února, firma oznámila, že Community Server 12.3 knihovny Galery obsahovat bude. Formulace je opatrná: „now is not the time for a major change“, teď není čas na velkou změnu. Oznámení jmenovitě děkuje dvěma lidem, Frédéricu Descampsovi a Renému Bonvaniemu; oba v té radě sedí. Že jedno způsobilo druhé, ale netvrdí ani firma, ani zápis.

Ve 12.3 Galera je, ale musí se doinstalovat

Verze 12.3.2 vyšla 28. května jako stabilní a její poznámky k vydání ukazují, v jaké podobě Galera v komunitní verzi zůstala. Pro balíčky Deb a RPM vznikl samostatný mariadb-server-galera a kdo klastr provozuje, musí si ho nainstalovat výslovně. Při aktualizaci ze starší verze se závislosti Galery nainstalují, ale neaktualizují, a definice služeb v systemd bez toho balíčku neumí ani bootstrap klastru, ani přenos stavu mezi uzly.

Kde se kód vyvíjí dnes

Veřejný repozitář Galery je pořád na místě a pořád pod GPLv2, jen se přestěhoval: adresa codership/galera na GitHubu dnes přesměrovává na mariadb-corporation/galera. Ve větvi 4.x je poslední commit z 27. května 2026, verzi 26.4.27 tam někdo povýšil 12. května a otevřených hlášení je 252. Organizace codership na GitHubu už žádný veřejný repozitář nemá a doména galeracluster.com přesměrovává na produktovou stránku MariaDB Enterprise Cluster.

Jinak je to s repozitářem, ve kterém leží záplata pro samotné MySQL. Poslední zápis do mysql-wsrep nese datum 18. srpna 2023 a nejvyšší větev je 5.7. Z veřejného GitHubu se tedy nedá poznat, odkud se berou binárky, jejichž údržbu firma do konce září slibuje.

Dvě cesty a dva měsíce

Frédéric Descamps z MariaDB Foundation řekl 30. července The Registeru, že „most of the team that worked on Galera“, tedy většina lidí, kteří na Galeře pracovali, podle něj dělá na řešení pro firemní zákazníky. Otázku i odpověď k tomu připojil sám: „Will that become open source one day? That's not the current direction.“ Že to teď takhle nasměrované není. Co ten tým dělá, neupřesnil. Firemní blog MariaDB z února jmenuje v podnikové nabídce MariaDB Advanced Cluster postavený na protokolu Raft, který je zatím v technickém náhledu.

Vikas Mathur, produktový ředitel MariaDB plc, hájí přechod k MariaDB tím, že inovace v ekosystému MySQL se podle něj zastavila a zákazníci to vědí. Marco Tusa z Percony napsal 30. června, že Codership jako firma skončilo a že Foundation kód udrží tak, jak je, pokud se do vývoje nepustí komunita sama.

Podle nás je v celé věci nejdůležitější ta jedna věta z únorového zápisu o tom, že otevřený kód neznamená zdarma navěky. Popisuje totiž, jak firma o věci uvažuje, bez ohledu na to, jak dopadl jeden konkrétní ústupek v jedné konkrétní verzi. Příští schůze rady Foundation je podle zápisu 9. září 2026, tedy tři týdny před koncem podpory.

Zdroje: oznámení Upgrade Now: Announcing MySQL Galera Cluster In-Place Migration to MariaDB Galera Cluster a MariaDB Community Server 12.3 Will Include Galera Cluster na blogu MariaDB, zápis ze schůze správní rady MariaDB Foundation z 25. února, poznámky k vydání MariaDB 12.3.2, A Friendly Reset: Understanding the MariaDB Foundation's Role na blogu Frédérica Descampse, How to Migrate from MySQL Galera Cluster to Percona XtraDB Cluster na blogu Percony, The Galera Crossroads Marca Tusy, zpráva MariaDB again faces questions over Galera's open source future na The Registeru a repozitář galera na GitHubu.

Začalo to jako obyčejná stížnost na padající program. Za dva dny z ní byla analýza, která ukazuje jinam, než kde se hledalo: do správy paměti v jádře Linuxu.

Padalo jen sestavení proti musl

Daniel Fox Franke otevřel v neděli 26. července v repozitáři vyhledávacího nástroje ripgrep hlášení číslo 3494. Popsal v něm, že binárka pro cíl x86_64-unknown-linux-musl občas skončí signálem SIGSEGV, když prochází opravdu velký strom adresářů a běží přitom v mnoha vláknech. Pád nastal vždy na stejném místě: v kontrole vnitřní konzistence haldy uvnitř alokátoru mallocng, kam se program dostal přes obyčejné otevření adresáře.

Správce ripgrepu, který na GitHubu vystupuje pod jménem BurntSushi, se zeptal, jestli padají i jiné binárky. Franke odpověděl, že s ničím slinkovaným proti glibc pád vyvolat nedokázal a že stejně padá i starší ripgrep 15.1.0.

Vlákno přestane vidět, co samo napsalo

V úterý 28. července přibyl pod hlášením vzkaz, že králičí nora vede hlouběji a že podle Frankeho jde o chybu jádra. Doklady zveřejnil týž den v samostatném repozitáři pod licencí MIT-0.

Jádrem nálezu je pozorování, které na správně fungujícím počítači nemá jak nastat. Vlákno zapíše bajt na stránku paměti, kterou právě dostalo, a zhruba o deset strojových instrukcí později si totéž místo přečte – a najde nulu. Franke to změřil dvěma čteními naráz: to bezprostředně po zápisu hodnotu vidělo správně, to opožděné už ne.

Ten rozdíl je podstatný. Kdyby zápis jen nestihl dojít do paměti, procesor by ho pozdějšímu čtení podstrčil z vlastní fronty zápisů a vidělo by ho obojí. Když ho vidí jen to první, buď hodnotu mezitím přepsal někdo jiný, nebo se pod toutéž adresou vyměnila celá stránka paměti.

Pro druhou možnost mluví pohled do souboru /proc/self/pagemap v okamžiku neshody: stránka je hlášená jako přítomná a zapsaná, ale s číslem fyzického rámce 0. To je nulová stránka, kterou si jádro drží pro čtení z dosud nezapsané paměti.

Co pád zastaví a co ne

Tu první možnost, tedy přeteklé pole nebo použití uvolněné paměti, vyloučil Franke čtyřmi variantami knihovny musl. Liší se jen tím, co se se stránkami stane předtím, než do nich alokátor poprvé zapíše.

• P0 bez úprav: 250 běhů, 4 pády.
• P1 se dotkne předem všech stránek skupiny: 304 běhů, ani jeden pád.
• CTRL se dotkne předem jen té jedné stránky, na které k chybě dochází: 305 běhů, ani jeden pád.
• FAKEPF se zdrží stejně dlouho a stejně dlouho drží zámek alokátoru, ale zapisuje jinam: 308 běhů, 3 pády.

Podstatná je poslední položka. Kdyby pád způsobovalo zdržení nebo držení zámku, zmizel by i u varianty FAKEPF. Rozhoduje tedy to, jestli se na stránku sáhne dřív, než na ni alokátor poprvé zapíše – a to žádná chyba v programu ani v knihovně nevysvětlí.

Reprodukce vyšla na jednom stroji z pěti

Pád se dá vyvolat na povel, ale ne všude. Návod je v repozitáři: vygenerovat strom o zhruba 20 GiB v 1 841 862 souborech a nad ním pořád dokola pouštět rg s dvanácti vlákny. Pád přijde v průměru jednou za jednu až tři minuty; havarující běh trvá kolem 1,6 sekundy, čistý zhruba 7,6 sekundy.

Ze zkoušených pěti počítačů uspěl jen ten původní, Threadripper 9960X s jádrem 7.0.12 z openSUSE Tumbleweed. Threadripper 9970X téže generace s jádrem 6.19.10 pád nevydal, stejně jako EPYC 9575F a Xeon 678X s jádrem 6.8.0 a Ryzen AI MAX+ 395 s jádrem 6.18.35. „Pád sleduje verzi jádra, ne rodinu procesorů,“ uzavírá analýza tuhle část (přeloženo).

Kam ukazuje srovnání zdrojových kódů

Vysvětlení, ke kterému Franke došel, je souběh dvou cest v jádře. První je obsloužení výpadku stránky při zápisu do dosud nepoužité paměti; té dnes stačí zámek jedné oblasti a nemusí zamykat celou paměť procesu. Druhá je odmapování paměti voláním munmap, po kterém se všem procesorům rozešle žádost o zneplatnění záznamů v TLB, tedy v tabulce překladů adres uvnitř procesoru.

Zámek jedné oblasti proti odmapování nechrání. Když první cesta zveřejní nový záznam v tabulce stránek a druhá už mezitím touž adresu vyčistila, dorazí zneplatnění až po zveřejnění a smaže překlad, který právě vznikl.

Kde se to zhoršilo, hledal Franke porovnáním větví jádra. Cesta výpadku stránky je mezi verzemi 6.19 a 7.0 beze změny; změnil se úklid tabulek stránek při odmapování. Analýza jmenuje tři změny z ledna 2026, které ve verzi 7.0 jsou a v 6.19 nejsou: 4c640eb4181c, fb4ddf208511 a eda8c5e77622. Odpovídá to i rozdělení strojů výše.

Patří k tomu ale výhrada, kterou si Franke napsal sám: je to silná shoda, ne důkaz. Zdrojově nedoložil, že nová cesta opravdu strhne záznam, který výpadek stránky právě zveřejnil, a potvrzení nechává na revizi na straně jádra. Dotčené funkce se navíc od verze 7.0 po současný vývojový strom nezměnily, takže opravené to zatím není.

Model od OpenAI odmítl s laděním pomoct

Druhou polovinu příběhu popsal server The Register ve středu 29. července. Franke ladil chybu s pomocí jazykových modelů a u těch uzavřených narazil. Model GPT-5.6 Sol od OpenAI podle něj nespolupracoval, protože ho zastavil bezpečnostní klasifikátor; chybová hlášení ho posílala do firemního programu Enterprise Trusted Access. Modely Anthropicu prý ani nezkoušel, protože čekal totéž.

„Bezpečnostní klasifikátor OpenAI je pěkná otrava, když se snažíte vystopovat segfault,“ řekl Franke serveru The Register (přeloženo). Jinde dodal, že nástroj, který odmítá spolupracovat, je pro něj prostě rozbitý nástroj. Sama chyba se přitom poprvé ozvala v ripgrepu přibaleném k nástroji OpenAI Codex; ta binárka je podle Frankeho bajt po bajtu totožná s oficiálním vydáním 15.2.0.

Analýzu nakonec dotáhly modely s otevřenými váhami od čínských firem. Podle Frankeho přinesl klíčový průlom Kimi K3 od Moonshot AI a práci dokončil GLM 5.2 od Z’ai. Vyjádření OpenAI ani Anthropicu The Register neuvádí.

Stopy modelů jsou vidět i v dokladech samotných. Skript, který generuje testovací strom, je podle hlášení napsaný jazykovým modelem a jeden z commitů v repozitáři s analýzou se jmenuje „Human edit pass on AI prose“, tedy lidská redakce textu od modelu. Jestli takový kód patří do svobodných projektů, řeší chystané hlasování v Debianu.

Pro běžného uživatele z toho neplyne skoro nic: pád potřebuje binárku slinkovanou proti musl, skoro dva miliony souborů, dvanáct vláken a jednu konkrétní řadu jádra. Hodnota té analýzy je podle nás jinde. Ukazuje, kolik práce stojí dojít od „občas to spadne“ k pojmenování konkrétní části zdrojového kódu, a jak snadno by se u toho člověk zastavil na prvním podezřelém, tedy na alokátoru musl.

Zdroje: hlášení 3494 v repozitáři ripgrepu a repozitář s analýzou včetně dat a záplat pro musl, o části s modely psal The Register. Názvy tří jmenovaných změn jsme ověřili v repozitáři jádra Linuxu.

Jellyfin je svobodný mediální server. Člověk si ho pustí doma na vlastním stroji, uloží do něj filmy, seriály a hudbu a pak je přehrává na televizi, na mobilu nebo v prohlížeči – bez cizí služby a bez předplatného. Vznikl v roce 2018 odštěpením od uzavřeného Emby a sám sebe popisuje jako obdobu Emby a Plexu. Kód má pod licencí GPL-2.0 a na GitHubu přes 55 tisíc hvězd.

Mezi 17. a 19. červencem 2026 z něj odešli tři lidé, kteří u něj byli prakticky od začátku.

Tři odchody ve třech dnech

Jako první opustil 17. července organizaci Andrew Rabert. Oznámil to v hlášení nazvaném „Přejmenovat aplikaci“ ve svém repozitáři: „Tohle už není oficiální projekt organizace Jellyfin. Potřebuje nový název a značku“ (přeloženo z angličtiny). Desktopový klient, který od prosince 2025 psal znovu od základu, se tak dostal mimo projekt a jmenuje se nově Jellium Desktop.

Důvod shrnul jednou větou: „Abych shrnul, proč se to přesunulo: vyhoření z práce uvnitř organizace Jellyfin.“ Přepis původního klienta podle něj začal kvůli letitým potížím – chybějící podpoře HDR a údržbě knihovny Qt. „Způsob, jakým jsem to vyvíjel, podporovala jen hrstka členů organizace, včetně části vedení. Celkové naladění ale bylo velmi negativní a čím dál zatěžující a svazující“ (přeloženo).

O dva dny později, 19. července, odstoupili vedoucí projektu Joshua Boniface a člen jádra týmu Anthony Lavado, který se u projektu staral hlavně o komunikaci s komunitou a o administrativu. Lavado podle přetisků odchod vysvětlil tím, že se mu mění život a přednost musí dostat jiné věci; o vyhoření nemluví.

Co napsal odstupující vedoucí

Boniface, který stál u odštěpení od Emby a vedl projekt víc než sedm let, k tomu 22. července zveřejnil delší text na svém blogu. Vysvětluje v něm, že role vedoucího mu nikdy nesedla: „Nemám povahu, která by se hodila na řízení velkého projektu.“ A dodává: „Nejsem dobrý vedoucí lidí“ a „nerad říkám lidem ne“ (vše přeloženo z angličtiny).

Bezprostřední důvod je ale jinde. „Prostě jsem už nedokázal vynakládat úsilí – duševní ani časové –, které ta role vyžadovala,“ píše. Slovo vyhoření podle něj sedí přesně v tomhle smyslu: „Nejsem člověk, který by dokázal dělat věci v rozporu se svou povahou donekonečna.“

Do textu zasahuje i téma, které se v otevřeném softwaru řeší poslední rok skoro všude. „Technologická změna tak zásadní, jako jsou jazykové modely, a jejich místo v tomhle projektu – na to má silný názor skoro každý, uvnitř projektu i mimo něj,“ píše Boniface. Zároveň zdůrazňuje, že spor o ně nebyl jediným ani hlavním důvodem jeho odchodu, jen „další stéblo na hřbetě příslovečného velblouda“.

Za zmínku stojí, co v pramenech není. Několik přetisků uvádí, že Rabertův odchod souvisel s odporem týmu vůči jeho používání nástrojů s umělou inteligencí. V jeho vlastním oznámení ale slova umělá inteligence, jazykový model ani jméno konkrétního nástroje nepadnou ani jednou a žádný z těch přetisků pro to neuvádí zdroj.

Vlna vygenerovaných příspěvků, o které projekt psal už v květnu

Že je tým unavený, přitom nebylo tajemství. Ve zprávě o stavu projektu z 24. května 2026 stojí: „Zaplavily nás pull requesty psané umělou inteligencí různé kvality. Tím se ohromně zvýšilo množství práce, které tým má na talíři“ (přeloženo). A o kus dál rovnou: „Zvýšený počet žádostí o podporu spolu s příspěvky kódu od umělé inteligence vedl k vyhoření na různých úrovních vývojového i administrativního týmu.“

Pull request je nabídnutá změna kódu, kterou musí někdo z projektu přečíst a posoudit, než ji přijme. Právě to čtení je ta drahá část a u strojově psaných příspěvků je dražší, protože chybu v nich není vidět na první pohled. Podle vlastních čísel projektu se za dvanáct měsíců od května 2025 do dubna 2026 sloučilo měsíčně mezi 182 a 434 pull requesty.

Zpráva zároveň ohlásila pravidla pro jazykové modely. Nejsou to zákaz ani volná ruka. Výstup modelu se nesmí použít pro přímou komunikaci – do hlášení, do diskuse pod změnou, na fórum; tam má člověk psát vlastními slovy. Při psaní kódu model použít lze, ale jen tehdy, když přispěvatel změnám rozumí a umí je vlastními slovy vysvětlit, otestovat a sám si je obhájit v připomínkovém řízení. Výjimku mají překlady do angličtiny, pokud je přiložen původní text.

Nástupce určí hlasování podle ústavy

Jellyfin má psanou ústavu a stojí v ní, že vychází z té debianské. Postup pro tenhle případ tedy existoval dřív, než nastal: po rezignaci vedoucího navrhne vedoucí tým jednoho nebo víc kandidátů a hlasují o nich všichni členové týmu přispěvatelů. Volí se pořadím kandidátů s postupným vyřazováním, dokud někdo nezíská nadpoloviční většinu. Když je kandidát jediný a většinu nedostane, rozhoduje hlas odstupujícího vedoucího.

Ústava také říká, že vedoucí musí být zároveň členem vedoucího týmu a tříčlenné finanční komise, a popisuje Bonifaceovo postavení bez příkras: prvního vedoucího nikdo nevolil, jmenoval se sám jako ten, kdo odštěpení od Emby rozjel.

Sám Boniface tvrdí, že projekt tím neskončí: „titíž lidé, kteří tu práci posledních několik let opravdu dělali, u projektu zůstávají.“ Nové vedení podle něj zachová Jellyfin jako svobodný software bez zpoplatnění.

Co z toho plyne

Hodnocení, ne údaj ze zdroje: na Jellyfinu je vidět, jak křehké je uspořádání, kde dobrovolníci obsluhují software s velkou uživatelskou základnou. Boniface sám mluví o dvou až třech vlnách Plexfugees, tedy uprchlíků od Plexu, za poslední tři až čtyři roky. Uživatelů přibývá skokově, lidí, kteří jim odpovídají na hlášení, ne.

Odchod tří lidí najednou zní přitom dramatičtěji, než jak ho popisují sami aktéři. Boniface označuje rozchod za přátelský a o rozkol nad směřováním projektu nešlo ani u Raberta – ten mluví o atmosféře kolem své práce, ne o sporu, kam má Jellyfin jít. Ověřitelné bude až to, co přijde potom: kdo bude zvolen a jestli se rychlost oprav a vydání udrží. To se pozná za pár měsíců, ne z prohlášení.

Zdroje: text Joshuy Bonifacea o jeho rezignaci, oznámení Andrewa Raberta na GitHubu, zpráva o stavu projektu z 24. května 2026, pravidla projektu pro jazykové modely a ústava projektu. Souhrny přinesly servery Linuxiac a It's FOSS.

Do Debianu se balíček nedostane jen tím, že ho někdo nahraje. Pokud v distribuci ještě nikdy nebyl, spadne do fronty zvané NEW a čeká, až ho člověk projde ručně. Nekontroluje se přitom, jestli program funguje – kontroluje se, jestli jeho licence a licence všeho, co si s sebou nese, odpovídají pravidlům svobodného softwaru.

Kdo to dělá

Má to na starosti DFSG, Licensing & New Packages Team, zkráceně DFSG tým. Jeho jádro tvoří podle wiki Debianu delegáti vedoucího projektu podle § 8 ústavy a poslední delegace je z letošního ledna. Úkol týmu zní „projít balíčky ve frontě NEW a potvrdit, že plně odpovídají Debian Free Software Guidelines“ (přeloženo).

Ruční kontrola je podle téhož zdroje potřeba proto, aby nahrané balíčky splnily standardy distribuce a aby dovnitř neprošly „balíčky s právními problémy nebo s hrubými vadami zabalení“ (přeloženo). Naopak za to, že je balíček bez závažných chyb, tým odpovědnost výslovně nemá – to je věc správce balíčku.

Co se vlastně kontroluje

Debian Free Software Guidelines jsou deset bodů, které Debian přijal v roce 1997 jako součást své společenské smlouvy; návrh sepsal Bruce Perens a měsíc ho pak v e-mailové konferenci připomínkovali ostatní vývojáři. Vyjmenovávají, co musí licence dovolit, aby software mohl být v distribuci.

První tři body dávají představu o zbytku. Licence nesmí nikomu bránit software prodávat ani rozdávat jako součást většího celku. Program musí mít zdrojový kód a smět se šířit v něm i přeložený. A licence musí dovolit úpravy a odvozená díla, a to za týchž podmínek jako původní software.

Kontrola v NEW se tedy netýká jen licence samotného programu. Balíček s sebou nese i knihovny, obrázky, písma nebo ukázková data a každá taková součást musí projít.

Co v té frontě je

Od února má fronta veřejný přehled. Reinhard Tartler ho oznámil 12. února se slovy, že „poprvé má každý – nejen vývojáři Debianu – přehled o tom, co se ve frontě přesně děje“ (přeloženo). Nešlo podle něj o pouhou vizuální úpravu, ale o „zásadní posun v tom, jak balíčky řadíme a zpracováváme“ (přeloženo).

Přehled je otevřený, takže jsem se do něj podíval. Stav k 29. červenci:

• ve frontě čeká 36 balíčků, z toho 6 přednostně,
• nejdéle čeká pjproject – 21 dní,
• nejmladší položka byla v tu chvíli ve frontě dvě hodiny.

Za týden od 22. do 29. července prošlo frontou 89 kontrol a všechny skončily přijetím. Zamítnutí za ten týden není ani jedno; u některých balíčků je v poznámce připomínka recenzenta, která ale schválení nezabránila.

Sto procent přijatých je číslo, které svádí k závěru, že kontrola je formalita. Z jednoho týdne se to ale tvrdit nedá – stejně dobře to může znamenat, že správci balíčků vědí, co se po nich chce, a problémové věci se řeší dřív, než se do fronty vůbec dostanou.

Podle čeho se řadí

Pořadí ve frontě není podle data nahrání. Skládá se ze tří věcí: jak dlouho balíček čeká, jak je podle statistiky PopCon rozšířený, a jestli na něj čekají další hlášené chyby. Tým k tomu uvádí jednoduchý cíl – „snížit frontu“ (přeloženo).

PopCon je dobrovolná statistika, kterou Debian sbírá od uživatelů o tom, co mají nainstalované. Náš názor: balíček, který v distribuci ještě není, se v ní z podstaty objevit nemůže, takže nováček vstupuje do řazení s nulou v jednom ze tří kritérií.

Proč je to vidět zrovna teď

Tým shrnul, jak mu první měsíce po osamostatnění vyšly, na letošní konferenci DebConf. Server LWN.net z toho referoval 28. července, jeho článek je ale přístupný jen předplatitelům, takže obsah té zprávy tady nerozvádím – čísla výše jsou z veřejného přehledu, ne z ní.

Debian tenhle rok řeší i jinou otázku kolem toho, co do distribuce smí: v červenci projednával čtyři návrhy, jak naložit s příspěvky od jazykových modelů. Obě věci mají společné to, že se rozhoduje o původu kódu, ne o jeho funkci.

Zdroje: wiki Debianu, oznámení Reinharda Tartlera (12. února 2026) a veřejný přehled fronty NEW, ze kterého jsou čísla k 29. červenci 2026.

Mezi vytvořením a otevřením je okno

Volání mkdir() adresář založí, ale nevrátí nic, čím by ho program mohl dál držet. Volání open() a openat() naopak adresář otevřou, jenže jen takový, který už existuje. Kdo tedy zakládá strom adresářů a chce jim nastavit práva, vlastníka, časy nebo rozšířené atributy, musí to udělat na dva kroky: nejdřív vytvořit, pak otevřít podle jména.

V té mezeře je závod. Jori Koolstra to v popisu klíčové záplaty píše natvrdo: než se program dostane k otevření, může adresář někdo vyměnit za něco jiného. Obejít se to dá jen napůl. Program si smí hned po otevření zavolat fstat() a ověřit, že drží adresář s očekávaným vlastníkem a právy, ale podle Koolstry se to snadno naprogramuje špatně a hlavně to neřekne to podstatné: kdo adresář vytvořil. Adresář založený jiným procesem se stejnými oprávněními je od toho vlastního nerozeznatelný, takže se program nedozví, jestli je jeho a má ho na starost.

Nápad není nový. Stojí v seznamu přání skupiny UAPI, který totéž žádá i pro zařízení a pojmenované roury a jako řešení navrhuje samostatné volání mkdirat_fd().

Příznak, který tři roky vrací jen chybu

Koolstra sáhl po jiné cestě: po kombinaci příznaků, která dnes nedělá nic. O_CREAT říká „vytvoř, když to neexistuje“, O_DIRECTORY říká „uspěj jen tehdy, když je to adresář“. Dohromady si protiřečí a jádro se s nimi nikdy nevypořádalo rozumně. Když cesta neexistovala, vytvořilo obyčejný soubor. Když na ní ležel obyčejný soubor, vrátilo ENOTDIR. Když adresář, vrátilo EISDIR.

V roce 2020 to commit Ala Vira, který se dostal do jádra 5.7, změnilo ještě k horšímu: jádro začalo v prvním případě vracet ENOTDIR a soubor přitom stejně vytvořilo. Tři roky si toho nikdo nevšiml, až v roce 2023 na to narazil Pedro Falcato. Christian Brauner tehdy navrhl, ať se místo návratu ke starému chování udělá to, co dělá NetBSD, tedy vracet EINVAL vždycky. Linus Torvalds podle tehdejšího rozboru na LWN.net souhlasil; v překladu řekl: „Myslím, že můžeme docela dobře předpokládat, že to nikdo doopravdy nepoužívá, a klidně to můžeme pořádně vyčistit.“ Falcato u té příležitosti zjistil, že POSIX nezakazuje ani jedno z těch chování a že FreeBSD kombinaci propustí, pokud adresář existuje.

Brauner změnu zapsal v březnu 2023 do commitu 43b450632676 a do jeho zprávy dal i důvod: kromě úklidu staré chyby to podle něj otevírá možnost dát té kombinaci příznaků v budoucnu něco intuitivnějšího. Právě o tu možnost teď jde.

Co série mění

Nová sémantika je prostá. O_CREAT|O_DIRECTORY provede mkdir a otevře, co vzniklo, a vrátí přitom deskriptor, který adresář drží. Poslední verze série z 12. července má deset záplat, mění 224 řádků v souboru fs/namei.c a přidává test o 201 řádcích. Jedna ze záplat musela předsunout kontrolu, jestli smí program adresář otevřít pro zápis: u obyčejných souborů se dělá až na konci, tady by to znamenalo adresář vytvořit a hned potom volání odmítnout.

Ne všude to bude fungovat. Souborové systémy s vlastním atomickým otevíráním, tedy 9p, Ceph, FUSE, GFS2, NFS, klient SMB a vboxsf, by na to podle Koolstry potřebovaly rozšířit své protokoly. Zatím u nich jádro bit O_CREAT odstraní: existující adresář se otevře, ale u toho, který se měl vytvořit, přijde ENOENT.

Druhé omezení se týká adresářů s příznakem sticky, tedy třeba /tmp, kde smí soubor smazat jen jeho vlastník. Vlastní přepínač pro adresáře série nezavádí a dosavadní pojistka pro obyčejné soubory na ně nedosáhne: podle Koolstry by to zaskočilo správce, kteří s takovou možností nepočítají.

Spor je o to, jak program pozná, že to jádro umí

Spor se nevede o samotnou vlastnost, ale o to, že se zapíná kombinací příznaků, a ne novým voláním. Christoph Hellwig namítá, že jádro neznámé a neověřené kombinace příznaků u open() odjakživa ignoruje, takže se jim nesmí potichu dát význam, pokud to není zpětně slučitelné. Na Braunerovu obranu, že se dosud nic nerozbilo, odpověděl v překladu takto: „Samozřejmě se dosud nic nerozbilo, protože to nikdo nepoužíval. Jakmile tomu dáme význam, začne se to používat a rozbije se to.“

Falcato ten problém rozepsal na příklady. Program by se musel vyrovnat se čtyřmi chováními téže kombinace. Zjistit podle verze jádra, na kterém běží, které z nich platí, přitom nemusí být možné: podniková jádra si vlastnosti backportují na přání, jak se stalo u atomických zápisů v souborovém systému XFS, které vyšly v jádře 6.16 a v SUSE Linux Enterprise Serveru i v Oracle UEK 8 se objevily už v 6.12. K tomu se přidává filtr seccomp, který může neznámé volání odmítnout hláškou o tom, že volání vůbec není.

Brauner, správce vrstvy VFS, to označil za konstrukci, která neobstojí: oprava, po které kombinace vrací tvrdou chybu, je podle něj v dlouhodobě podporovaných jádrech roky a nepřišlo na ni ani jedno hlášení o regresi. Připomněl i tři případy, kdy jádro už jednou obsazený příznak přeznačilo: CLONE_STOPPED na CLONE_NEWCGROUP, CLONE_PID na CLONE_PIDFD a O_TMPFILE na kombinaci __O_TMPFILE|O_DIRECTORY. Sám přitom rozlišuje, co je a co není v pořádku: dát význam kombinaci, která se dřív ignorovala, se podle něj nemá, kdežto použít znovu kombinaci, která byla odmítána, ano.

Do jednoho bodu se ti dva nesejdou. Brauner tvrdí, že se změna z roku 2023 dostala do všech dlouhodobě podporovaných jader, Falcato uvádí, že vyšla v jádře 6.4, dostala se zpětně do 6.1, ale ne do 6.2 a 6.3 a ne do 5.15 ani 5.10. Kdo z nich má pravdu, se z diskuse nedozvíme; ani jeden pro své tvrzení odkaz neuvedl.

Koolstra odpovídá, že komu záleží na starých jádrech, ať si po vytvoření ověří, že opravdu drží adresář, nebo ať si prostě vyžádá rozumnou minimální verzi jádra. NeilBrown navrhl kompromis, který by hádání zrušil: přidat do volání openat2() příznak ve smyslu „selži, pokud tuhle kombinaci výslovně neumíš“. Ptá se, proč to neudělat rovnou, když by se tím psaní bezpečné aplikace i výběr jádra staly snadné.

Koolstra proti tomu má dvě námitky, ani jednu ale nepovažuje za zabijáka nápadu. Volání openat2() podle něj blokovala a možná dosud blokuje řada profilů seccomp, mimo jiné v systemd, takže by se k tomu zjišťování nedostaly zrovna ty velké aplikace, jejichž potřeby změny v rozhraní jádra obvykle pohánějí. A za druhé je to podle něj věc slohu: openat2() má otevírat soubory, ne zjišťovat vlastnosti jádra. Sám nadhodil samostatné volání has_feature(2), kterému by se předalo číslo volání a popis vlastnosti.

Kde to stojí

Sloučeno není nic. Brauner 24. července požádal o novou verzi s podporou v openat() i openat2(); Koolstra odpověděl, že to už v posílání z 12. července je a jen zapomněl sérii označit jako čtvrtou. Dřív téhož měsíce ho Brauner požádal, ať ze série vyndá nesouvisející opravy, protože zásah do auditu by si vyžádal zapojení lidí od auditu a slučování by zdržel. To se stalo: nová verze má deset záplat místo čtrnácti a audit řeší zvlášť.

Kdo o tom rozhodne, napsal Koolstra sám: je to na Christianovi.

Zdroje: série záplat a diskuse k ní v archivu konference linux-kernel na marc.info, rozbor LWN.net z 27. března 2023, commit 43b450632676 v repozitáři jádra a seznam přání skupiny UAPI.

Většina projektů řeší otázku kódu od jazykových modelů potichu, někde v diskusi pod žádostí o začlenění. Debian ji řeší způsobem, který má zapsaný ve své ústavě: obecným usnesením, o kterém hlasují všichni vývojáři projektu.

Rozprava začala 24. července a potrvá nejméně dva týdny. Teprve po ní přijde hlasování. Do té doby neplatí žádné z níže popsaných pravidel – Debian příspěvky od jazykových modelů ani nezakázal, ani formálně nepovolil.

Čtyři návrhy na stole

Návrh A předložil Matthias Geiger a je z celé čtveřice nejtvrdší. Zakazuje příspěvky napsané s pomocí jazykových modelů a chce to zapsat přímo do Společenské smlouvy, tedy do jednoho ze zakládajících dokumentů projektu. Navrhovaná věta v překladu zní: „Nedovolíme přímé příspěvky do Debianu napsané s použitím nebo pomocí velkých jazykových modelů.“

Návrh B pochází od Lucase Nussbauma, bývalého vedoucího projektu, a jde opačným směrem. Příspěvky povoluje, ale za šesti podmínkami: licence nástroje nesmí kolidovat s tím, jak Debian software šíří a upravuje; u převzatých částí musí být ověřený původ; odpovědnost nese vždy člověk, který příspěvek podává; podstatný podíl strojově vytvořeného textu se musí přiznat; hromadné úpravy je nutné předem probrat; a citlivá data se nesmí posílat neprověřeným poskytovatelům.

Návrh C od Iana Jacksona je kompromis. Vývojáře žádá, aby se jazykovým modelům vyhýbali, kde to jde, ale připouští, že úplný zákaz je v praxi nevymahatelný. Zajímavé je, co z něj vyjímá a co naopak přitvrzuje: zprávy určené lidem – hlášení chyb, e-maily, zápisky – má psát člověk. Zároveň výslovně říká, že kdo nepíše anglicky rodile, může používat překladače bez pocitu viny.

Návrh D předložil Pierre-Elliott Bécue a povoluje pomoc modelů jen pro práci na samotném Debianu, ne pro projekty, ze kterých Debian software přebírá. Kdo příspěvek podává, musí mu rozumět natolik, aby ho obhájil, podepisuje ho svým jménem a pomoc modelu má vyznačit v popisu změny.

Čeho by se zákaz týkal

U nejtvrdšího návrhu je rozsah širší, než by čekal ten, kdo si pod „příspěvkem“ představí jen kód. Týkal by se zdrojových balíků, softwaru vyvíjeného přímo Debianem (jmenovitě nástroje lintian), oficiálních webových stránek, dokumentace, překladů i projektové komunikace.

Naopak by se netýkal tří věcí: projektů, ze kterých Debian software přebírá a které si modely používají po svém; balíků, které samy o sobě slouží k práci s umělou inteligencí; a záplat a bezpečnostních oprav přebíraných od autorů původního softwaru. Bez téhle výjimky by pravidlo v praxi znamenalo vyhodit velkou část distribuce.

Proč to někdo chce zakázat

Argumenty proti se opakují ve všech podobných diskusích: model si věci vymýšlí a chyba se pak hledá hůř než u člověka; když kód píše stroj, přestává mu rozumět komunita, která ho má za deset let udržovat; provoz modelů stojí energii; trénovalo se na cizí práci bez svolení; a u výsledku není jasné, jak je to s licencí.

Argumenty pro jsou stručnější a praktičtější: nástroje vývojářům reálně pomáhají, zákaz stejně nejde vymáhat a v okamžiku, kdy je používá skoro každý, se projekt zakazováním jen připraví o přispěvatele.

Ta nevymahatelnost je jádro sporu. Nikdo neumí spolehlivě poznat, jestli patch napsal člověk, nebo model. Návrhy B až D proto místo zákazu staví na přiznání: kdo si nechal pomoct, má to uvést u příspěvku.

Jak se v Debianu rozhoduje

Obecné usnesení je nástroj, kterým Debian řeší věci, na kterých se neshodne běžnou cestou. Návrhy potřebují podporu dalších vývojářů; u těchto čtyř se pohybuje mezi šesti a devíti podporovateli.

Hlasuje se preferenčně: vývojář nevybírá jednu možnost, ale seřadí je podle toho, které dává přednost. Ve výsledku tak může zvítězit i návrh, který nebyl ničí první volbou, zato ho většina snese.

Jeden rozdíl mezi návrhy je čistě formální, přesto důležitý. Návrh A mění Společenskou smlouvu, tedy zakládající dokument. Návrh B se tomu vědomě vyhýbá a opírá se o článek 4.1 (5) ústavy – pravidlo by pak šlo upravit bez dalšího hlasování celého projektu.

Proč na tom záleží i mimo Debian

Debian je základ, ze kterého vychází Ubuntu a přes něj i většina desktopových distribucí Linuxu. Jeho pravidla mají dosah, ale hlavně se tu poprvé rozhoduje veřejně a hlasováním o něčem, co jinde vzniká jako neformální zvyk.

Ať dopadne hlasování jakkoliv, výsledek bude dost podrobný na to, aby se dal převzít. A pokud vyhraje některý z prostředních návrhů, vznikne v otevřeném softwaru něco, co zatím chybí: běžný způsob, jak u příspěvku vyznačit, že u něj asistoval stroj.

Zdroje: oficiální stránka usnesení na debian.org, zpravodajství heise online a Linuxiac.

Největší novinka je soubor /etc/tunables.conf. Nastavují se v něm takzvané tunables, tedy přepínače, kterými jde měnit chování knihovny za běhu – od prahů, kdy alokátor paměti vrací paměť zpátky systému, po využití bezpečnostních rozšíření procesoru. Dosud se zadávaly proměnnou prostředí GLIBC_TUNABLES, a tím pádem zvlášť pro každé spuštění.

Hodnoty projdou přes ldconfig do mezipaměti

Podle dokumentace, kterou k funkci napsal DJ Delorie, má soubor jeden přepínač na řádek:

glibc.malloc.trim_threshold=128
glibc.malloc.check=3

Samotný soubor ale programy nečtou. Přeloží ho ldconfig, tedy nástroj, kterým se po instalaci knihoven obnovuje jejich rejstřík, a uloží hodnoty jako rozšíření do mezipaměti /etc/ld.so.cache. Odtud si je vezme každý program při startu. Na už běžící programy změna nemá vliv. Soubor umí i vkládat další soubory příkazem include, stejnou syntaxí jako dávno zavedený ld.so.conf.

Předpona rozhoduje, kdo smí hodnotu přepsat

Hodnoty ze systémového souboru fungují jako výchozí: přebíjejí to, co má program zabudované, ale samy je pořád možné přebít proměnnou prostředí. Právě tohle jde u jednotlivého řádku vypnout. Předpona nonoverridable nebo znak - zablokuje změnu z prostředí a dá přednost systémovému nastavení, overridable či + je výchozí chování.

Druhá sada předpon vybírá podle toho, jestli proces běží s vyššími právy – dokumentace mluví o příznaku AT_SECURE, tedy o programech se setuid, setgid nebo se zvýšenými oprávněními. onlysecure (@) se použije jen na ně, nonsecure ($) jen na ostatní, anysecure (*) na všechny.

Filtr umí zacílit na jediný program

K tomu přibyly filtry. Řádek ve tvaru [proc:vzor] omezí následující přepínače na konkrétní program, ať už podle celé cesty, nebo jen podle jména souboru. Jméno procesu si knihovna přečte z /proc/self/exe, a když to nejde, z argv[0] – to ale ne u procesů s vyššími právy. Ukázka z dokumentace zapíná v celém systému ochranu návratových adres stínovým zásobníkem a jednomu programu, který na ní padá, ji vypíná:

-glibc.cpu.x86_shstk=1
[proc:/usr/bin/program_that_crashes_with_shstk]
+glibc.cpu.x86_shstk=0

Filtr platí do dalšího filtru, do řádku s prázdnými hranatými závorkami, nebo do konce souboru. Kód pochází z dílny Red Hatu; dokumentaci zapsal Delorie 26. června a revidoval ji Arjun Shankar.

Rozhraní, které se smí změnit

Oznámení k vydání k novince připojuje větu, která stojí za přečtení dřív, než si ji správce zapíše do konfigurace serverů: konkrétní přepínače, formát souboru /etc/tunables.conf ani cesta k němu nepatří mezi stabilní rozhraní knihovny a mezi vydáními se můžou změnit. Kdo si na tenhle soubor postaví nasazení, počítá s tím, že mu příští verze glibc může sáhnout na syntaxi.

Server Phoronix při zápisu funkce do repozitáře upozornil ještě na jednu věc: díky předponě, která zakáže přepsání z prostředí, jde nově některé přepínače uzamknout.

Tři bezpečnostní upozornění, čtyři čísla CVE

Bezpečnostní oddíl oznámení jmenuje tři upozornění. Dvě se týkají funkcí gethostbyaddr a gethostbyaddr_r: podle popisu u CVE-2026-4437 mohla podvržená odpověď DNS serveru vést k tomu, že program vzal část odpovědi, která odpovědí není, jako platnou; CVE-2026-4438 pak popisuje vracení neplatných jmen. Obojí se týká verzí 2.34 až 2.43. Třetí, CVE-2026-4046, je pád funkce iconv na kontrolním výrazu při převodu ze znakových sad IBM1390 a IBM1399; záznam u něj rovnou uvádí, že se to dá obejít odstraněním obou sad ze systému, kde je nikdo nepotřebuje.

V seznamu opravených chyb je ale ještě čtvrté číslo. U hlášení 34069 stojí CVE-2026-6238, přečtení paměti za koncem vyrovnávací paměti ve funkci ns_sprintrrf u poškozených záznamů DNS. Samostatné upozornění k němu v oznámení není. Záznam v databázi jmenuje tři zavržené funkce určené jen k ladění aplikací; překladač jmen je při své práci nevolá a doporučení nepoužívat je platí od verze 2.34.

Přibyl LoongArch32, zmizela 31bitová podpora s390

Ze zbytku vydání vyčnívá jedna věta pro programátory v jazyce C. Dokumentace nově říká, že příští verze glibc můžou zmírnit požadavky na zarovnání u malých alokací: malloc(1) tak jednou může vrátit ukazatel na lichou adresu, protože objekt velikosti 1 žádné větší zarovnání nepotřebuje. Kdo se spoléhá na to, že z alokátoru chodí adresy zarovnané jako dosud, má varování.

Matematické funkce cosh, sinh a tanh jsou převzaté z projektu CORE-MATH, který se zabývá správně zaokrouhlenými implementacemi. Makro assert zvládne kvůli chystanému C++26 víc argumentů oddělených čárkami. Na procesorech RISC-V dostalo vektorové varianty třináct funkcí pro práci s řetězci a pamětí. Na AArch64 přibyly vektorizované varianty dalších matematických funkcí a u rozšíření Guarded Control Stack se po jeho zapnutí operace s ním zamknou, aby program nemohl ochranu za běhu vypnout.

Podpora architektur se rozešla na dvě strany: přibyl 32bitový LoongArch, naopak 31bitová varianta s390 skončila. Zrušená je i volba překladu --enable-memory-tagging a s ní i příslušná funkce pro AArch64. Přibylo jazykové prostředí hrx_BR pro hunsrik, kterým se mluví v Brazílii.

Do systémů se novinky dostanou s dalším kolem vydání distribucí; Phoronix jmenuje Ubuntu 26.10 a Fedoru 45. Hlavní vývojová větev se mezitím otevřela pro verzi 2.45; zpráva o tom leží v archivu konference hned nad oznámením o vydání.

Na Codebergu, veřejném úložišti zdrojového kódu, za kterým stojí spolek Codeberg e. V., skončilo 22. července hlasování členského shromáždění. Prošly dva návrhy a oba se týkají jazykových modelů. První zavazuje provozovatele, druhý omezuje uživatele. Spolek o výsledku informoval na svém blogu následující den.

Ten první bod prošel snadno. Zní, že forge Codeberg ani jeho přidružené služby nepoužívají a nebudou používat kód ani data projektů a uživatelů k učení nástrojů typu velkých jazykových modelů. Zákaz cizího vytěžování hostovaného kódu to není, jde o závazek samotného provozovatele.

Druhý návrh byl sporný. Do výčtu zakázaného obsahu v § 2 podmínek užití přibyla věta: „Nesmíte sdílet projekty, které se z větší části skládají z kódu napsaného nástroji ‚generativní AI‘ (včetně služeb jako Claude nebo OpenAI Codex).“ Citace je přeložená z anglického originálu. Pro hlasovalo 358 členů, proti 144, zdrželo se 14. Podle spolku se zúčastnila zhruba polovina aktivních členů.

Rozhoduje slovo „z větší části“

Zákaz není plošný a spolek to sám zdůrazňuje. Nedotčené mají zůstat „projekty, které mají činnou komunitu, jež se o software stará a udržuje ho“. Vítané naopak nebudou „projekty psané a udržované s výrazným využitím modelů“. Kde je mezi tím hranice, podmínky neříkají.

Proč to spolek dělá

Blogový zápis, pod kterým jsou podepsáni Bastian Greshake Tzovaras, Otto Richter a William Zijl, uvádí dva důvody. Prvním jsou peníze. „Typ disku, který jsme před pár lety pořídili za 700 eur, dnes stojí 3 700 eur – a často není skladem,“ stojí v textu. K tomu spolek dodává, že ve Frankfurtu už datová centra spotřebují 40 % místní elektřiny a poptávka roste. Stavba počítačových sálů pro modely tedy podle něj zdražuje provoz i těm, kdo je nepoužívají.

Druhým důvodem je licence. U copyleftových projektů podle zápisu modely vedou k „praní licencí“, tedy stavu, kdy je copyleftový kód zbaven požadavku na reciprocitu tím, že se „vygeneruje“ z trénovacích dat. Copyleft je licenční ujednání, které nutí každého, kdo kód převezme, šířit i svou úpravu pod stejnými podmínkami; když projde modelem, tahle vazba se ztratí.

Zátěž správců není téma jen Codebergu. Z Jellyfinu letos v červenci odešli vedoucí projektu i dva dlouholetí členové týmu.

Co bude s existujícími repozitáři

Nic hromadného. „Náš moderátorský tým nezačne tím, že by sestavil vyčerpávající seznam dotčených repozitářů k odstranění,“ píše spolek. Automatické prohledávání obsahu se dělat nebude, případy se mají řešit jeden po druhém, až se objeví.

Je to zároveň nejslabší místo celé změny. Pravidlo mluví o podílu strojově psaného kódu, jenže ten podíl nikdo neumí změřit a provozovatel se o to ani nepokouší.

Kryptoměny týmž shromážděním

Vedle obou hlasování o modelech prošla ještě jedna změna podmínek. Návrh přihlášený 2. července uživatelem Gusted byl sloučen 22. července a doplňuje mezi zakázaný obsah takový, který poškozuje pověst Codebergu; jako příklad podmínky jmenují projekty spojené s kryptoměnami. Diskuse pod návrhem se točila právě kolem toho, co všechno se pod takový příklad vejde; vlákno nakonec někdo uzavřel kvůli návalu příspěvků zvenčí.

Kritika míří na nevymahatelnost

Autor frameworku Flask Armin Ronacher shrnul svou výhradu 24. července v zápisu nazvaném Codeberg Divides. Právo spolku takové pravidlo přijmout nezpochybňuje, vadí mu jeho tvar: čára je podle něj otevřená výkladu přesně tam, kde by měla být vymahatelná. Dodává, že u řady svých vlastních nedávných projektů by sám nedokázal spolehlivě určit podíl autorství. Podle jeho názoru měl Codeberg buď zakázat modely úplně, nebo mířit konkrétně na samočinně zakládaný spam a na spotřebu zdrojů.

Codeberg tedy nevyřešil, jak strojově psaný projekt poznat, a podle vlastních slov se o to nechystá pokoušet. Změnil něco jiného: kdo takový repozitář nahraje, nemá se napříště o co opřít, protože podmínky ho už nekryjí. Zbytek zůstává na ohlášení od lidí.

Zdroje: zápis na blogu Codebergu, platné znění podmínek užití, The Register a zápis Armina Ronachera.

Grafické čipy NVIDIE se na Windows s procesorem Arm doteď obešly bez oficiální podpory. Kdo chtěl na takovém stroji spustit cokoli postavené na CUDA – tedy na rozhraní, kterým NVIDIA pouští výpočty na grafické kartě – měl smůlu. Šestnáctého července to firma změnila: na svém vývojářském fóru vydala CUDA Toolkit 13.4 jako Developer Preview a spolu s ním ovladač pro Windows 11 na Arm64.

Co je v balíku

Preview má tři části: vývojářský ovladač pro chystanou platformu RTX Spark, samotný toolkit ve verzi 13.4 a dokumentaci. Instalační soubor ovladače se jmenuje 616.00_DeveloperPreview_win11_arm64_International.exe. Vedle něj NVIDIA nabízí i verzi pro x64, aby šlo programy pro Arm křížově překládat na běžném počítači.

Podstatné je, že k začátku není potřeba nic kupovat. „Nepotřebujete hardware RTX Spark, abyste mohli začít – použít se dá existující vývojový systém s Windows na Armu,“ píše NVIDIA v oznámení (přeloženo z angličtiny). Programátoři si tak mohou aplikaci přeložit, najít v ní závislosti, které pro Arm neexistují, a připravit první sestavení dřív, než se čip vůbec objeví v prodeji. Ověření na skutečném RTX Sparku má podle stejného textu přijít, „až bude podporovaný hardware a software k dispozici“ (rovněž přeloženo).

Instalační soubor prozradil, co má chystaný čip uvnitř

Zajímavější než ovladač sám je jeho instalační předpis. Web Windows Latest si 18. července všiml, že soubor nv_surface_woa.inf vyjmenovává dvě zařízení: „NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU)“ a „NVIDIA RTX Spark N1X (5120-core Blackwell RTX GPU)“. Chystaný čip tedy nepřijde v jediné podobě, ale nejméně ve dvou, a liší se počtem jader grafické části.

Vyšší z nich odpovídá tomu, co Microsoft uvedl na začátku června při ohlášení notebooku Surface Laptop Ultra: dvacetijádrové procesorové pole složené z deseti jader Cortex-X925 a deseti Cortex-A725, grafika se 6 144 jádry architektury Blackwell a až 128 GB paměti sdílené mezi procesorem a grafikou. Server PCWorld k tomu dodává, že stejný počet grafických jader má stolní karta GeForce RTX 5070.

Co N1X umí ve výpočtech, zatím nikdo nezměřil. Microsoft u svého notebooku mluví o výkonu „až petaflop“ v úlohách umělé inteligence, což je údaj výrobce, ne výsledek nezávislého testu.

Co zatím nefunguje

Omezení vypisuje NVIDIA v oznámení sama. Nástroj Nsight Copilot je na Windows ARM64 v tomto preview vypnutý a nedostupný. U knihovny PyTorch firma varuje, že spuštění jejích testovacích úloh v režimu CI/CD může vyvolat vypršení časového limitu grafiky. Balík není finální vydání a NVIDIA ho tak ani neoznačuje – v názvu souboru i v titulku oznámení stojí Developer Preview.

Ovladač 616.00 navíc obsluhuje pouze hardware RTX Spark. Na žádnou jinou grafickou kartu NVIDIE se nevztahuje, což u vývojářského balíku mířícího na jediné zařízení dává smysl.

Proč na tom pro Arm záleží

Windows na Armu naráží dlouhodobě na tentýž problém: software napsaný pro x86 na něm buď neběží, nebo běží v emulaci a pomaleji. U výpočtů na grafické kartě byla situace horší, protože chyběla samotná knihovna – a bez CUDA se neobejde většina nástrojů kolem strojového učení. Vydáním pro Arm64 se ta mezera zavírá. Zatím ovšem jen ve vývojářské podobě a pro jedinou chystanou platformu; to je hodnocení redakce, ne tvrzení výrobce.

Kdy se hardware objeví, NVIDIA v oznámení neuvádí. Podle Windows Latest se první stroje s RTX Sparkem čekají na podzim a kromě Surface Laptopu Ultra se mluví o Lenovu Yoga Pro 9n. Microsoft u svého notebooku uvedl podzim 2026 rovněž, cenu ale zatím neřekl.

Vydání ovladače tedy není zpráva o výkonu, ale o načasování. NVIDIA dala vývojářům zhruba dva měsíce náskok, aby jejich programy fungovaly hned první den prodeje – a mimoděk jim přitom v obyčejném textovém souboru prozradila, kolik variant čipu chystá.

Release manager Hugo van Kemenade vydal 18. července čtvrtou betu Pythonu 3.15. Je poslední plánovaná: nové funkce do jazyka nesměly přibývat už od 7. května, kdy vyšla beta první, a od téhle chvíle se nemá měnit ani binární rozhraní, na které se váží knihovny psané v jazyce C. První kandidát na vydání má vyjít 4. srpna, druhý 1. září a ostrá verze 1. října 2026.

Podle plánu vydání dostane 3.15 opravné aktualizace zhruba jednou za dva měsíce po dobu dvou let, bezpečnostní pak až do roku 2031. Novinek je uvnitř dlouhý seznam, tři z nich ale stojí za pozornost, i když s Pythonem jen občas něco spustíte.

Výchozí kódování určuje Python, ne systém

Dosud platilo, že když program otevře soubor bez uvedení kódování, použije se to, které hlásí systém. Na Linuxu z toho vycházelo UTF-8 skoro vždycky, na Windows se řídilo národním nastavením, a tentýž skript tak na dvou počítačích četl tentýž soubor jinak. Od 3.15 to neplatí: dokumentace uvádí, že Python nově používá UTF-8 jako výchozí kódování nezávisle na prostředí systému, takže volání open('flying-circus.txt') bez dalšího údaje čte v UTF-8. Týká se to i standardního vstupu a výstupu a rour mezi programy.

Změnu popisuje PEP 686 od Inady Naokiho, který je od 3.15 ve stavu Final. Jeho argument je prostý: UTF-8 se stalo faktickým standardem u formátů jako JSON, TOML nebo YAML i u editorů a webů, a rozdílné chování Pythonu na různých systémech je zdrojem chyb, které ostatní jazyky neřeší.

Nepříjemná část je v oddílu o zpětné kompatibilitě téhož dokumentu. Program, který se na dosavadní výchozí kódování spoléhal, může podle PEPu skončit chybou UnicodeError, vypsat zpřeházené znaky, nebo si tiše poškodit data (v originále „silent data corruption“). Nejvíc to dopadá na Windows, kde bylo výchozí kódování dosud odvozené od nastavení systému. Staré chování se vrací proměnnou prostředí PYTHONUTF8=0 nebo přepínačem -X utf8=0; režim UTF-8 se tedy dá i nadále vypnout, jen se nově nemusí zapínat. Dokumentace k tomu dodává, že nejlepší je kódování u každého otevření souboru napsat výslovně.

Líný import existuje, ale musí se vyžádat

Druhá viditelná novinka je klíčové slovo lazy. Zápisem lazy import json nebo lazy from pathlib import Path se modul nenačte hned, ale až ve chvíli, kdy program se jménem poprvé opravdu pracuje. Import tak může zůstat nahoře v souboru, kam patří, aniž by se za něj platilo při každém spuštění.

lazy import json
lazy from pathlib import Path

print("Starting up...")  # json ani pathlib zatím načtené nejsou

data = json.loads('{"key": "value"}')  # tady se načte json
p = Path(".")                          # a tady pathlib

PEP 810 zdůrazňuje, že jde o volbu, ne o změnu chování: existující programy běží dál stejně, dokud si o líné načítání někdo neřekne. Kdo ho chce zapnout plošně bez zásahu do kódu, má na to přepínač -X lazy_imports a proměnnou PYTHON_LAZY_IMPORTS. Omezení jsou tvrdá – lazy smí stát jen na úrovni modulu, uvnitř funkce, těla třídy nebo bloku try skončí chybou syntaxe, a stejně dopadne hvězdičkový import i import z __future__.

S čísly je to horší. PEP mluví o zkrácení startu o 50 až 70 procent u nástrojů příkazové řádky a o úspoře paměti 30 až 40 procent „v reálném provozu“, u žádného z nich ale neuvádí, odkud se vzalo. Jediný údaj s doloženým zdrojem je zrychlení startu o 10 až 20 procent u aplikací postavených na PySide, kde PEP odkazuje na konkrétní hlášení v systému chyb Qt. Doložená je i jiná věc: v samotné standardní knihovně je už dnes zhruba 17 procent importů mimo testy schovaných uvnitř funkcí, tedy skoro 3 500 importů v 730 souborech. Líné načítání si tedy vývojáři dělali ručně dávno, jen kvůli tomu musel import z hlavičky souboru zmizet dovnitř funkce.

Rychlost nástrojů je téma i v jiných jazycích. TypeScript kvůli ní přepsal celý překladač do Go a sestavení tím zkrátil na osminu až dvanáctinu.

Rozšíření pro běh bez globálního zámku mají vlastní stabilní ABI

Třetí změna je pod povrchem a týká se knihoven psaných v C. Python má v běžném sestavení globální zámek interpretu, který pouští ke kódu v jednu chvíli jen jedno vlákno. Od verze 3.13 vedle něj existuje sestavení bez tohoto zámku a od 3.14 se nepovažuje za pokus, jenže rozšíření se pro něj musela stavět zvlášť pro každou verzi Pythonu.

PEP 803 od Petra Viktorina a Nathana Goldbauma zavádí variantu stabilního rozhraní abi3t, ve které jde rozšíření přeložit jednou a používat i na sestaveních bez zámku. Cena za to není malá. Struktura PyObject se stává neprůhlednou, takže se do ní nesmí sahat přímo ani ji vkládat do vlastních struktur; knihovna musí přejít na rozhraní zavedené v PEP 697 a místo dosavadní vstupní funkce PyInit_ použít nový vývozní bod PyModExport_ z PEP 793. Dokumentace navíc upozorňuje, že stabilní rozhraní nenabízí všechno, co CPython umí – kdo se do něj nevejde, staví dál zvlášť pro klasické stabilní ABI a zvlášť pro verzi bez zámku.

Drobnost pro uživatele Maců: oficiální instalátory pro macOS nově instalují podporu běhu bez globálního zámku ve výchozím stavu.

Co se ještě do 3.15 vešlo

Vedle toho přibývá neměnný slovník frozendict, vestavěný typ sentinel pro zástupné hodnoty, rozbalování v seznamových a podobných zkrácených zápisech, samostatný balíček na profilování s novým vzorkovacím profilerem Tachyon a ukazatele na rámce zapnuté ve výchozím stavu, což usnadňuje sledování běžícího programu nástroji operačního systému. Překladač JIT se podle poznámek k vydání výrazně změnil; konkrétní naměřené zrychlení v nich ale není, a čísla, která kolují po přetiscích, se nedají doložit z původního zdroje.

Do ostré verze zbývají dva kandidáti na vydání a dva měsíce. Kdo spravuje kód, který otevírá soubory bez uvedeného kódování, má právě teď nejlepší příležitost zjistit, kolik takových míst v něm vlastně je.

Zdroje: oznámení Python 3.15.0b4 na blogu vývojářů, poznámky k vydání 3.15, návrhy PEP 686, PEP 810 a PEP 803, plán vydání PEP 790 a text Tima Andersona na The Register.

Rust 1.97 vyšel 9. července a na první pohled je to nezajímavé vydání: pár nových metod na celých číslech, drobnost v Cargu. Jenže obsahuje jednu změnu, kterou pozná každý, kdo někdy ladil pád aplikace v uvolněném sestavení. Kompilátor od této verze používá jako výchozí kódování symbolů schéma v0.

Co je kódování symbolů a proč na něm záleží

Když překladač vyrobí binárku, musí každou funkci pojmenovat jedním řetězcem v tabulce symbolů. To jméno smí obsahovat jen omezenou sadu znaků, takže se cesta k funkci i její typové parametry zakódují do jednoho slova. Tomu se říká mangling, tedy zkomolení jména.

Podle tohoto jména se pak orientuje ladicí program, profiler i výpis zásobníku po pádu. Když je kódování špatné, ladicí nástroje zobrazí místo funkce jen shluk znaků a vývojář hádá.

Rust do teď používal starší schéma, které si s obecným kódem neporadilo. Pokud jste měli funkci s typovým parametrem a zavolali ji pro deset různých typů, vzniklo deset různých funkcí, jenže jejich konkrétní typy se do jména nedostaly. Nahradil je hash. Ve výpisu jste tedy viděli, že spadla nějaká varianta obecné funkce, ale ne která.

Co dělá v0 jinak

Schéma v0 vzniklo podle návrhu RFC 2603 a jeho hlavní vlastnost je obousměrnost. Kódování je navržené tak, aby z výsledného jména šlo zpětně přečíst, co v něm bylo, včetně typových parametrů. Oznámení k vydání to shrnuje jednou větou: dosazení obecných parametrů si zachovává své hodnoty, místo aby bylo sledované jen za hashem.

Kromě typů umí v0 zakódovat i životnosti, konstantní generické parametry, meze s vyšším řádem, uzávěry a další konstrukce, na které starší schéma nemyslelo. Jména používají jen znaky A–Z, a–z, 0–9 a podtržítko, takže projdou beze změny každým linkerem. Aby přitom nebyla nekonečně dlouhá, používá formát zpětné odkazy na už zakódované části.

Ukázkový symbol ve formátu v0 vypadá takto:

_RNvMsr_NtCs3ssYzQotkvD_3std4pathNtB5_7PathBuf3newCs15kBYyAo9fc_7mycrate

Po rozkódování je z něj čitelné <std::path::PathBuf>::new.

Samotné schéma není novinka. Zapnout se dalo ručně přepínačem od verze 1.59, tedy od února 2022. Novinkou je, že se čtyři a půl roku poté stalo výchozím.

Na co si dát pozor

Dokumentace kompilátoru na dvou místech mírní očekávání. Zaprvé: v0 není stabilní binární rozhraní Rustu. Je definované natolik, aby z něj šlo vyrobit čitelný tvar, ne aby se na jeho podobu daly vázat cizí nástroje.

Zadruhé: neexistuje jediný předepsaný způsob, jak symbol zobrazit. Dokumentace doporučuje oddělovat cesty dvojtečkami, psát implementace vlastností jako <Typ as Vlastnost> a uzávěry jako {closure#N}, ale je to doporučení, ne norma. Dva profilery tedy mohou tentýž symbol vypsat jinak.

Nástroje, které rozkódování zvládají, mají podle dokumentace při setkání s neznámou značkou raději vypsat původní zkomolené jméno než spadnout. Kdo používá starší verzi ladicího programu nebo vlastní nástroj nad tabulkou symbolů, měl by po přechodu na 1.97 zkontrolovat, že to skutečně dělá.

Zbytek vydání

Druhá praktická změna se týká linkeru. Jeho hlášky se dosud zahazovaly; nově se zobrazují jako varování pod kontrolou lintu linker_messages. Potíže s linkováním se tak nebudou projevovat až záhadným chováním výsledné binárky.

Cargo umí nově řídit chování varování přes proměnnou prostředí CARGO_BUILD_WARNINGS s hodnotami allow, warn a deny. Podstatné je, že změna této hodnoty neshodí vyrovnávací paměť sestavení, takže přepnutí na deny v průběžné integraci nestojí celý překlad znovu.

Ze standardní knihovny přibyly metody pro práci s bity celých čísel: isolate_highest_one, isolate_lowest_one, highest_one, lowest_one a u typů bez znaménka bit_width. Stejná sada je i na typech NonZero. Metoda char::is_control je nově použitelná v konstantním kontextu.

O týden později, 16. července, vyšla opravná verze 1.97.1.

Zdroje: oznámení vydání na blogu projektu Rust a kapitola o kódování v0 v příručce kompilátoru.

Prohlížeč se dnes aktualizuje sám a většina lidí si čísla verzí nevšimne. Přesto se během letoška stalo něco, co se nestává: všichni tři velcí výrobci nezávisle na sobě oznámili stejnou změnu. Hlavní verze bude nově vycházet každé dva týdny místo jednou za čtyři.

Kdo kdy začne

První je na řadě Microsoft Edge. Podle oznámení na firemním blogu z 11. června začíná dvoutýdenní tempo verzí 152, která vyjde 27. srpna 2026.

Firefox naváže o pět dní později. Verze 154 z 18. srpna bude poslední vydaná v dosavadním rytmu, Firefox 155 přijde 1. září. Změnu oznámil ředitel Mozilly Sylvestre Ledru v polovině července ve vývojářské konferenci dev-platform, tedy v mailové skupině, kde se probírá vývoj jádra prohlížeče. Týká se počítačů i Androidu.

Chrome je z celé trojice první, kdo o tom mluvil, a poslední, kdo to spustí. Google zveřejnil plán už 3. března a dvoutýdenní cyklus u něj startuje verzí 153 osmého září. Platí pro počítače, Android i iOS; větve Dev a Canary zůstávají beze změny. Beta každé verze vyjde tři týdny před její stabilní podobou. V praxi to znamená zhruba šestadvacet hlavních vydání ročně místo dosavadních třinácti.

Rychleji neznamená víc

Zásadní je, co se nemění. Množství novinek zůstává stejné, jen se rozdělí na dvojnásobek dávek. Microsoft to popisuje přímo: každé vydání přinese „zhruba polovinu obsahu než dřív, zato dvakrát častěji“.

Stejně to formuluje i Mozilla. Zkrácení cyklu podle ní neznamená, že by se na hotovou práci mělo tlačit rychleji – funkce, které nejsou připravené, se nemají uspěchat a mohou zrát dál. Smysl je opačný: to, co už hotové je, nemusí čekat další tři týdny na nejbližší vlak.

Z toho plyne i druhý efekt, o kterém výrobci mluví méně nahlas. Když jede vlak každých čtrnáct dní, klesá tlak na takzvané uplifty, tedy dodatečné protlačování oprav do už uzavřené verze. Uplift je vždycky riziko: mění se kód, který už nikdo znovu neprošel celý. Čím menší dávka změn a čím kratší čekání, tím méně důvodů ho použít.

Firmy o pomalejší větev nepřijdou

Rychlejší tempo je noční můra každého, kdo v podniku validuje prohlížeč proti interním aplikacím. Proto zůstává zachovaná pomalá větev.

U Chromu se Extended Stable nemění vůbec – dál vychází jednou za osm týdnů. Edge má stejný interval, jen se přepočítal na nové číslování: aktualizace dostane každé čtvrté vydání, tedy verze 156, 160, 164 a tak dál. Model podpory ani harmonogram se u něj podle Microsoftu nemění.

Správcům, kteří na osmitýdenní větvi zůstanou, Microsoft doporučuje přidat pilotní skupinu uživatelů na kanál Beta a testovat od prvního dne, aby měli na ověření co nejvíc času. Pro tenhle účel nabízí Enterprise Preview s návodem pro správu.

Co z toho mají weboví vývojáři

Pro toho, kdo dělá weby, se mění hlavně rychlost, se kterou se nová vlastnost prohlížeče stane použitelnou.

Kdo dnes dokončí funkci těsně po uzavření vlaku, čeká na další skoro čtyři týdny. Nově budou nejvýš dva. U vlastností, které se v prohlížečích objevují postupně, se tím zkracuje doba, po kterou musí web počítat se dvěma různými chováními naráz.

Druhá strana mince je testování. Kdo hlídá vlastní aplikaci proti konkrétním verzím prohlížeče, bude mít dvakrát tolik cílů. Automatizované testy to zvládnou, ruční matice podporovaných verzí se ale bude potřeba přepsat – a to se týká i toho, jak dlouho drží platnost výsledky staršího testovacího kola.

Mozilla mluví o pokusu

Ze tří oznámení je nejopatrnější to od Mozilly. Firma dvoutýdenní cyklus výslovně označuje za experiment a připouští, že od něj může ustoupit, kdyby se objevily nečekané problémy. Chrome ani Edge takovou podmínku ve svých oznámeních nemají.

Rozdíl dává smysl. Mozilla má výrazně menší tým než Google a Microsoft a její vydávací proces je vázaný na jednu kódovou základnu bez zázemí velké platformy. Že se do stejného kroku pouští i tak, hodně vypovídá o tom, jak silný je dnes tlak držet krok s tempem Chromu – ať už jde o nové vlastnosti webu, nebo o bezpečnostní záplaty.

Pro běžného uživatele se v praxi nezmění skoro nic. Prohlížeč se aktualizuje na pozadí a nová čísla verzí poletí dvakrát rychleji, aniž by si toho kdokoli všiml. Zajímavější je, že se tři konkurenti bez domluvy shodli na tom, že měsíční cyklus už není správná délka.

Zdroje: oznámení Chromu na developer.chrome.com, blog Microsoft Edge a kalendář vydání Firefoxu, ve kterém jsou termíny verzí 154 až 157 čtrnáct dní po sobě.

Sdílení souborů mezi lidmi má na internetu dlouhou historii a jednu opakující se slabinu: i sítě, které se tvářily jako decentralizované, obvykle stály na několika serverech, kde se dalo hledat. Když ty spadly nebo je někdo vypnul, síť samotná sice žila dál, ale nikdo v ní nic nenašel. LiberShare zkouší postavit sdílení tak, aby takové místo neexistovalo.

Co to je

Projekt se sám popisuje jako „software pro sdílení souborů peer-to-peer postavený na moderních decentralizovaných technologiích“ (v překladu z angličtiny). Vyvíjí ho organizace Libersoft, tedy stejná parta, která staví operační systém LiberSystem.

Kód je veřejný na GitHubu a uvolněný pod licencí Unlicense, což znamená vzdání se autorských práv, jak jen to právní řády dovolují – prakticky veřejná doména.

Jak se peery hledají navzájem

Základ je knihovna libp2p, tedy stavebnice pro sítě peer-to-peer, kterou zná i svět kolem IPFS. Přímé spojení mezi dvěma počítači navazuje LiberShare přes WebRTC. Ten se běžně používá na videohovory v prohlížeči a umí se prokousat přes domácí routery, které jinak příchozí spojení nepouštějí.

Vyhledávání peerů řeší distribuovaná hašovací tabulka, konkrétně Kademlia z libp2p. Zjednodušeně: seznam „kdo co má“ není nikde celý. Každý uzel drží kousek a dotaz se k cíli doptává po několika skocích. Právě tohle je ten rozdíl proti starším sítím – není centrální rejstřík, který by šlo vypnout.

Úplně bez pevného bodu se to ale neobejde. Nastavení sítě podle specifikace povinně obsahuje seznam takzvaných bootstrap peerů – adres, na které se nový uzel připojí jako první, aby vůbec někoho poznal. Rozdíl proti serveru je v tom, že bootstrap peer nic neindexuje ani nezprostředkovává přenosy; slouží jen jako dveře do sítě a může jich být uvedeno víc. Kdo si založí vlastní síť, uvede prostě adresu svého uzlu.

Vlastní formát místo torrentu

Místo souborů .torrent má projekt vlastní formát, kterému říká LISH. Je popsaný ve třech specifikacích přímo v repozitáři: datový formát, formát sítě a síťový protokol. Poslední z nich je označený jako verze 1 z 24. října 2025.

Formát je postavený na JSONu, takže se dá otevřít v textovém editoru a přečíst. Nese strukturu adresářů, oprávnění a údaje pro ověření celistvosti dat. Protokol z něj skládá přenosy, které se dají přerušit a navázat a které umí táhnout z víc zdrojů naráz.

Sítě s rolemi, ne jedna velká síť

Nejméně obvyklá část návrhu je řízení přístupu. LiberShare nepočítá s jednou globální sítí, ale s libovolným počtem sítí, z nichž každá má vlastní pravidla a čtyři role: vlastníci, správci, vydavatelé a stahující.

Vlastník mění nastavení sítě a přiděluje ostatní role, správce může přidávat vydavatele a stahující, vydavatel smí do sítě přidávat obsah. Dvě nepovinná nastavení pak určují, jestli publikovat a stahovat smí opravdu jen ti, kdo mají příslušnou roli, nebo kdokoliv. Ve výchozím stavu je síť otevřená.

Prakticky to znamená, že tatáž technologie může sloužit jak veřejné síti, kam přispívá kdokoliv, tak uzavřené skupině – třeba filmovému archivu, kde publikovat smí hrstka lidí a stahovat okruh členů.

V jakém je to stavu

Tady je namístě střízlivost. Repozitář vznikl 22. října 2025, má přes patnáct set commitů a tři přispěvatele, poslední změny jsou z posledních dnů. Zároveň ale zatím nevyšla žádná verze – sekce vydání je prázdná a k dispozici je jen zdrojový kód.

Podle údajů GitHubu je většina kódu v TypeScriptu, k tomu přibližně třetina objemu v Svelte, tedy uživatelské rozhraní. Menší podíl tvoří instalátor pro Windows, skripty a kousek Rustu. Popularita je zatím komorní: jednačtyřicet hvězd a tři forky.

Proč to sledovat

Zajímavé na projektu není to, že dělá sdílení souborů – to umí kdejaký klient BitTorrentu, a lépe, protože má za sebou dvě desetiletí ladění. Zajímavé je spojení tří věcí, které se obvykle nepotkávají: síť bez indexeru, přístupová práva uvnitř sítě a rozhraní, které vypadá jako přehrávač médií, ne jako správce stahování.

Jestli to dopadne, se pozná až podle první vydané verze a podle toho, kolik lidí ji rozběhne naráz. Distribuovaná hašovací tabulka na papíře funguje vždycky; teprve provoz ukáže, jak se chová, když je uzlů málo nebo když polovina z nich sedí za přísným routerem.

Zdroje: repozitář LiberShare na GitHubu včetně specifikace síťového protokolu LISH; údaje o rozsahu a stáří kódu pocházejí z veřejného rozhraní GitHubu, ne z tvrzení projektu.