IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Aktuální předverze je (k 15. 8. 2007) 2.6.23-rc3, vydaná 12. srpna Buď se lidi opravdu zklidňují, nebo je to prostě kvůli tomu, že je půlka srpna a přinejmenším v Evropě jsou skoro všichni na dovolené. Většina změn byly opravy; vizte podrobnosti v dlouhém changelogu.
Od vydání -rc3 bylo do hlavního repozitáře začleněno několik desítek dalších oprav.
Aktuální verze -mm stromu je 2.6.23-rc2-mm2. Mezi nedávné změny patří nový síťový ovladač e1000, několik aktualizací IDE a podpora NUMA uzlů, které nemají žádnou paměť.
Aktuální stabilní verze řady 2.6 je 2.6.22.3, vydaná 15. srpna. Obsahuje několik oprav, z nichž jedna se týká bezpečnosti. 2.6.22.2 (s větší sadou oprav) byla vydána 9. srpna.
Starší jádra: Willy Tarreau oznámil, že plánuje připravit několik dalších stabilních aktualizací 2.6.20. První z nich by měla vyjít každou chvíli.
15. srpna vyšlo 2.4.35.1. Obsahuje pár kompilačních oprav a jeden bezpečnostní patch.
Teoreticky je možné se souborovými systémy pro flash dosáhnout lepšího výkonu než se současným emulovaným přístupem. V praxi se ovšem stávající flashové souborové systémy tomuto teoretickému cíli ani nepřibližují. LogFS je už v aktuální podobě mnohem blíže.
-- Jörn Engel
Kdykoliv nějaký proces provede běžný, bufferovaný write() do souboru, vytvoří v paměti jednu nebo více nečistých stránek. Tyto stránky musí být dříve nebo později zapsány na disk. Dokud se data nepřesunou na trvalé úložiště, nemohou být stránky paměti, které obsazují, použity k ničemu jinému - i pokud už je původní zapisující proces nepotřebuje (jak tomu často bývá). Je důležité zabránit tomu, aby nečisté stránky zaplnily příliš systémové paměti; pokud by jich bylo moc, dostal by se systém pod tlak a nemusel by mít ani dost paměti na provedení potřebných zápisů a uvolnění dalších stránek.
Obecně platí, že software zvládá vytvářet více nečistých stránek, než jsou úložná zařízení schopna pobrat. Musí být tedy nasazovány různé mechanismy, které udržují počet nečistých stránek na zvladatelné úrovni. Jedním z těchto mechanismů je jednoduchá forma přiškrcování zápisu [write throttling]. Jakmile proces znečistí nějaké stránky, zkontroluje jádro, jestli není počet nečistých stránek v systému příliš vysoký. Pokud je, musí nevychovaný proces chvíli vykonávat veřejně prospěšné práce ve formě zapisování stránek na disk. Přiškrcování tímto způsobem má dva užitečné účinky: nečisté stránky jsou zapsány na disk (a tím očištěny) a proces na chvíli přestane s vytvářením dalších nečistých stránek.
Tento mechanismus však není dokonalý. Proces, který je načapán při překračování globálního limitu nečistých stránek, nemusí být skutečným viníkem; v takovém případě je nevinný proces přinucen k práci, zatímco opravdový pachatel dál dělá nepořádek. Pokud musí být všechny nečisté stránky zapsány na jediné zařízení, nemusí být výhodné přiškrcovat procesy, které pracují se soubory na jiných discích - výsledkem by mohlo být to, že cvrkot na jednom disku v podstatě odstaví ostatní, které by jinak mohly dělat něco užitečného. Používání jediného globálního limitu může prostě vést k nezanedbatelným potížím jak pro procesy, tak pro zařízení.
A může být ještě hůře. Představte si, co se stane, když jsou bloková zařízení vrstvená - například obyčejné LVM nebo MD zařízení postavené nad jedním nebo více fyzickými disky. Velké množství I/O přes LVM vrstvu by mohlo vytvořit spousty nečistých stránek určených pro fyzické zařízení. Pokud však bude limitu dosaženo na úrovni LVM, mohl by se proces zablokovat ještě než fyzické zařízení začne stránky zapisovat. V nejhorším případě by výsledkem bylo tvrdé zatuhnutí systému - a tak si uživatelé většinou spolehlivost nepředstavují.
Peter Zijlstra pracuje na řešení - sadě patchů pro přiškrcování zápisu na jednotlivých zařízeních. Základní myšlenka je prostá: místo používání jediného globálního limitu nečistých stránek dostane takový limit každé zařízení, na které jsou stránky zapisovány. Při znečištění stránek se ověří, kolik stránek míří na jedno zařízení, a pokud má dané zařízení příliš mnoho nečistých stránek, proces je přiškrcen. Žádné zařízení tedy nesmí přijmout příliš velkou část nečistých stránek.
Trochu problematické však může být určování "příliš velké části". Mohli bychom prostě globální limit rovnoměrně rozdělit mezi všechna bloková zařízení, ale výsledek by nebyl zrovna optimální. Některá zařízení mohou být neustále velmi aktivní, zatímco jiná nic nedělají. Jedno zařízení může být lokální rychlý disk, zatímco jiné je třeba připojené pomocí NFS přes GPRS. V obou případech lze tvrdit, že systém podá lepší výkon, pokud ta rychlejší, častěji používaná zařízení dostanou větší díl paměti než ta pomalá a neaktivní.
Aby to tak fungovalo, vytvořil Peter knihovnu "proměnných proporcí" [floating proportions]. Tato knihovna umí efektivním způsobem a podle procesorů sledovat události podle jejich zdroje a určit, kolik procent celku přichází z každého ze zdrojů. Patch knihovnu používá k počítání dokončených uložení stránek u všech zařízení. Takže zařízení, která jsou schopna dokončit uložení rychleji, dostanou větší porci z limitu nečistých stránek. Obecně aktivnější zařízení budou mít také vyšší limit.
Patch zatím ještě neřeší problém, který nastane, když jeden uživatel zaplní paměť nečistými stránkami na úkor ostatních - zvláště když uživatelé soupeří o šířku pásma jediného zařízení. Na tento problém se snaží odpovědět jiná část patche. Další sada počítadel proporcí je používána ke sledování toho, kolik stránek znečisťují jednotlivé procesy. Když dojde ke znečištění stránky a systém se pustí do vypočítávání limitu pro příslušné zařízení, je limit snížen úměrně tomu, kolika nečistými stránkami už proces přispěl. Takže proces, který produkuje velké množství nečistých stránek, bude přiškrcen dříve než další, umírněnější procesy.
Patch je teď v osmé verzi a tentokrát se neobjevilo moc kritiky. Linusova reakce:
Ok, patche rozhodně vypadají pěkně a opravil jsi tu jedinou věc, na kterou jsem si minule stěžoval (názvy), takže z mého pohledu už je to teď jen otázka toho, jestli to funguje. Předpokládám, že zařazení do -mm pomůže, ale bylo by fajn, kdyby to aktivně testovali lidé s několika disky atd.
Reakcí zatím moc nebylo, ale někteří testeři dali vědět, že s patchem jejich systémy fungují lépe. Nedávno však byla funkce odstraněna z -mm kvůli častým pádům, takže je ještě potřeba se postarat o nějaké chybky. Dlouhodobě to však vypadá, že šance na začlenění je docela slušná - i když u patchů týkajících se správy paměti si člověk nemůže být nikdy jistý.
Jedním ze základních principů vývoje linuxového jádra je to, že rozhraní pro uživatelský prostor jsou tesána do kamene. Jakmile je API jednou zpřístupněno uživatelskému prostoru, musí být podporováno (aniž by způsobilo nefunkčnost aplikací) navždy. Toto pravidlo bylo sice párkrát porušeno, ale dokonce i v oblastech, které jsou známé tím, že dělají potíže (například sysfs), bylo uživatelské API měněno jen relativně málo.
Teď obraťte svou pozornost k systémovému volání timerfd(), které bylo přidáno do jádra 2.6.22. Účelem tohoto volání je umožnit aplikacím získat popisovač souboru, který lze použít s událostmi časovače, takže není nutné používat signály. Vypadá takto:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
long timerfd(int fd, int clockid, int flags, struct itimerspec *utimer);
Pokud má fd hodnotu -1, bude vytvořen nový popisovač souboru časovače a vrácen aplikaci. Jinak bude nastaven časovač podle daného clockid na dobu určenou v utimer. Příznak TFD_TIMER_ABSTIME může být nastaven, aby ukazoval, že je potřeba absolutní doba vypršení časovače; jinak bude specifikovaný čas relativní k aktuálnímu času. Parametr flags lze také využít k vyžádání opakovaného časovače.
timerfd() API má však ještě jeden aspekt: čtení popisovače souboru časovače vrátí celočíselnou hodnotu, která říká, kolikrát časovač spustil od předchozího čtení. Pokud k žádnému vypršení časovače nedošlo, volání read() se zablokuje. V jádře 2.6.22 měla vracená hodnota 32 bitů (na všech architekturách). Od té doby však vývojáři dospěli k rozhodnutí, že 64bitová hodnota by byla vhodnější, a patch, který tuto změnu provádí, byl začleněn do 2.6.23. Stabilní aktualizace 2.6.22.2 tuto změnu API také obsahovala.
Tím však příběh nekončí. Když pro nové systémové volání psal Michael Kerrisk manuálové stránky, narazil na několik nedostatků. Konkrétně není možné se systému zeptat, kolik času ještě časovači zbývá. Jiná časovačová volání takový druh dotazu umožňují - buď jako samostatnou operaci, nebo při změně časovače. Michael usoudil, že systémové volání timerfd() by mělo fungovat podobně jako ta ostatní.
Takže Michael poslal patch, který rozhraní timerfd() opravuje. S tímto patchem by systémové volání vypadalo takto:
long timerfd(int fd, int clockid, int flags, struct itimerspec *utimer,
struct itimerspec *outmr);
Nový ukazatel outmr musí být při vytváření popisovače souboru NULL. V jakékoliv jiné situaci bude využit k vrácení času, který ještě zbývá. Takže se lze z uživatelského prostoru nedestruktivně dotazovat prostřednictvím volání timerfd() s hodnotou NULL v utimer. Pokud jsou oba ukazatele ne-NULL, bude časovač nastaven na utimer, přičemž předchozí hodnota bude vrácena v outmr.
Jde samozřejmě o naprosto nekompatibilní změnu API, které už bylo exportováno do uživatelského prostoru; pokud dojde k začlenění, tak všechen kód, který používá timerfd(), přestane fungovat. Podle pravidel by k začlenění takové změny nemělo dojít, ale vypadá to, že pravidla budou tentokrát přiohnuta. Dá se argumentovat tím, že ve skutečnosti ještě API nebylo zpřístupněno: nevyšla zatím žádná verze glibc, která by timerfd() podporovala. Počet aplikací využívajících toto systémové volání musí být velmi nízký - jestli vůbec nějaké. Takže změna v tuto chvíli, zvláště pokud se dostane do 2.6.23, rozhraní vylepší, aniž by uživatelskému prostoru způsobila potíže.
Ačkoliv oprava timerfd() je pravděpodobně ještě možná, není pochyb o tom, že by bylo lepší, kdybychom podobné problémy s API dokázali odstranit ještě předtím, než se dostanou do stabilního jádra, kde pak musí být API mnoho let podporováno. A v tom to vězí: systémová volání (a další prvky uživatelského API) jsou do jádra přidávána velmi rychle, ale kontrola takových změn zaostává. Vzhledem k obtížnosti opravování chyb v uživatelských API se zdá, že by laťka pro kontroly v případech přidávání API měla být obzvláště vysoko. Nebude však snadné to zařídit; vývojáři, kteří by kontrolovali cizí kód, jsou v komunitě svobodného softwaru nedostatkové zboží.
V minulosti se objevil nápad označovat všechna nová uživatelská rozhraní zřetelně jako "beta" - tj. ve stavu, kdy může docházet ke změnám. Dokud by API bylo v tomto stavu, mohli by jej vývojáři jádra měnit. Aplikace by na takové rozhraní spoléhaly na vlastní nebezpečí. Takový postup však byl už dříve zavržen; lidé v tom viděli způsob, jak se vyhnout pořádnému promyšlení, než dojde k začlenění. Za předpokladu, že tento postoj stále platí, bude nutné najít jiný způsob.
Částí řešení by mohlo být to, jak se přišlo na problémy s timerfd(). Michael předvedl, že jedním z nejlepších způsobů, jak objevit nedostatky v API, je pokusit se o napsání podrobné dokumentace. Kdyby se jaderná komunita dohodla, že nezačlení uživatelské API, dokud nebude kompletně zdokumentováno, mohlo by to poskytnout potřebný impuls k pečlivé kontrole.
Diskutovat se o tom pravděpodobně bude na jaderném summitu příští měsíc (pro který byl právě zveřejněn předběžný program). Jak to bude přijato, to si může každý tipnout; psaní dokumentace se zdá být tak náročný úkol, že se ho bojí i jaderní hackeři. Pokud by však odměnou v budoucnosti bylo méně dlouhodobých problémů s uživatelským API, možná by to stálo za to.
Následující obsah je © KernelTrap
14. srp, originál
Joe Perches poslal do LKML obrovskou sadu patchů čítající 556 zpráv. Cílem bylo zpřístupnit informace o velkém počtu správců jednotlivých souborů v rámci stromu jádra. Vysvětlil: Už mě unavovalo hledání příslušných emailových adres, které dát u patchů do CC. Joeovy patche přidávají nový řádek do souboru MAINTAINERS, který je parsován přiloženým skriptem get_maintainer.pl.
Většina reakcí kritizovala velký počet patchů, které zaplavily inboxy členů konference. Další lidé poukazovali na to, že by šlo tyto informace lépe získat z gitu než ze zdrojových souborů. Alan Cox navrhl: Můžeš pracovat s git stromem, protože ukazuje, kdo a proč v poslední době prováděl změny, což je důležité, když se snažíš vystopovat chyby. Chris Wright připojil: Myslím, že tato data snadno zastarají. Co že bylo důvodem té akce? A dodal: Stačí použít git (nebo gitweb), stávající soubor MAINTAINERS a selský rozum (nebo trochu detektivního talentu), a zatím jsem nenarazil na žádný velký problém. Adrian Bunk oponoval: U aktivních vývojářů, jako jsi ty nebo já, to není problém. Ale pro ostatní není zrovna snadné zjistit, kdo je správcem určité části jádra.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Michael předvedl, že jedním z nejlepších způsobů, jak objevit nedostatky v API, je pokusit se o napsání podrobné dokumentace. Kdyby se jaderná komunita dohodla, že nezačlení uživatelské API, dokud nebude kompletně zdokumentováno, mohlo by to poskytnout potřebný impuls k pečlivé kontrole.
Ono by to také odstranilo riziko, že nebudou pořádně zdokumentována nikdy…
