Společnost Framework Computer představila novou vylepšenou verzi svého modulárního notebooku Framework Laptop 13 s Intel Core Ultra Series 1, displej s lepším rozlišením a novou webovou kameru. Přímo do Česka jej zatím koupit nelze.
Byla vydána nová verze 2.16 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
TerminalTextEffects (TTE) je engine pro vizuální efekty v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Od čtvrtka 30. 5. do soboty 1. 6. lze v Praze navštívit Veletrh vědy, tj. největší populárně naučnou akci v České republice, kterou každoročně od roku 2015 pořádá Akademie věd ČR. Vstup zdarma.
Canonical představil Ubuntu optimalizované pro jednodeskový počítač s RISC-V procesorem Milk-V Mars.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 24.5.1 Havier. Přehled novinek v Changelogu.
Společnost xAI založena Elonem Muskem a stojící za AI LLM modelem Grok získala investici 6 miliard dolarů.
Finálový zápas mistrovství světa v ledním hokeji přinesl nový rekord NIX.CZ (𝕏): "Dosavadní absolutní maximum našeho propojovacího uzlu bylo překonáno v čase 21:10, kdy jsme při přenosu dat dosáhli 3,14 Tbps. Je třeba také doplnit, že po deváté hodině večerní byly na maximu i ostatní datové přenosy nesouvisející s hokejovým šampionátem".
Přihlaste svou přednášku na další ročník konference LinuxDays, který proběhne 12. a 13. října na FIT ČVUT v pražských Dejvicích. CfP poběží do konce prázdnin, pak proběhne veřejné hlasování a výběr přednášek.
Na crowdsourcingové platformě Crowd Supply byla spuštěna kampaň na podporu open source biometrického monitoru ve tvaru hodinek HealthyPi Move. Cena je 249 dolarů a plánovaný termín dodání listopad letošního roku.
Současné vývojové jádro 2.6 je 2.6.26-rc8, které Linus vydal 24. června. Vím, že to nebyl týden a sada změn byla od -rc7 poměrně malá, ale příští týden nebo tak budu převážně nekomunikato, takže jsem vydal to, co snad bude poslední -rc. Všechny detaily vizte v dlouhém changelogu.
2.6.26-rc7 bylo vydáno 20. června; obsahuje další sadu oprav a podporu pro nějaké nové grafické karty.
V době psaní tohoto článku nebyly od vydání 2.6.26-rc8 do gitového repozitáře hlavní řady začleněny žádné patche.
Současné stabilní jádro 2.6 je 2.6.25.9 vydané 24. června. Obsahuje malou sadu oprav, pár z nich má vliv na bezpečnost. 2.6.25.8 bylo vydáno 21. června a obsahuje okolo tuctu oprav.
Problém s tím, že necháme všechno laditelné, spočívá v tom, že chceme po uživatelích, aby si vybrali, ale přitom jim nedáme informace potřebné k tomu, aby si mohli vybrat. Jestli ušetříte energii tím, že zastavíte disk, záleží na tom, jestli bude dostatečně dlouho neaktivní, aby se ušetřilo víc energie, než kolik se spotřebuje na jeho opětovné roztočení. Nastavte to špatně a vystavíte svůj disk zátěži navíc, snížíte výkonnost a spotřebujete víc energie, než když jste začali.
Jestli si s tím někdo chce hrát, bavte se. Neudělal jsem "change_bit()", protože nikdo příčetný tuhle věc stejně nepoužívá. Nic nezaručuji. Pokud se to rozbije, nikdo jste neviděl, že bych něco dělal. Nemůžete dokázat, že tento e-mail neposlal někdo, kdo je dobrý v podvrhávání smtp.
Podívejte se na to takhle: není způsob, jak by revidovatel tohoto patche (tj. já) mohl zjistit, proč tahle funkce existuje. Takže ani další lidé, kteří v budoucnu budou kód číst, nebudou moci přijít na to, proč ta funkce existuje. To je špatně. Tyto věci by měly být popsány v komentářích kódu a v changelogu (podle toho, co je vhodnější).
Bylo vydáno prohlášení o postoji k distribuci uzavřených jaderných modulů a podepsáno dlouhým seznamem vývojářů. My, níže podepsaní vývojáři jádra Linuxu, považujeme všechny linuxové jaderné moduly či ovladače s uzavřeným zdrojovým kódem za škodlivé a nežádoucí. Opakovaně jsme zjistili, že jsou újmou pro uživatele Linuxu, obchody a větší linuxový ekosystém. Takové moduly anulují otevřenost, stabilitu, flexibilitu a udržovatelnost linuxového vývojového modelu a uzavírají svým uživatelům přístup k odborným znalostem linuxové komunity. Výrobci, kteří poskytují jaderné moduly s uzavřeným zdrojovým kódem, nutí své zákazníky vzdát se klíčových výhod Linuxu nebo zvolit nového výrobce. Pročež, aby získali plné výhody úspory nákladů a sdílené podpory, které může open source nabídnout, naléháme na výrobce, aby přijali politiku podpory svých uživatelů v Linuxu otevřeným jaderným kódem. Níže najdete další informace a jména signatářů.
James Bottomley napsal a na stránkách Linux Foundation zveřejnil esej o grafických ovladačích. Co se Linuxu týče, nejlepší způsob, jak objektivně demonstrovat spokojenost uživatelů, je pomocí projektu kerneloops, který sleduje nahlášené problémy s různými jádry (a oops je něco, co je ekvivalentní panice u Unixu nebo modré obrazovce ve Windows). Když se například podíváme na nedávno vydané jádro 2.6.25, můžeme vidět, že binární Nvidia ovladač a binární ovladač firegl od ATI drží místo mezi patnácti nejčastějšími oopsy. Když se potom podíváme na historii, zjistíme, že binární ovladače do tohoto seznamu vždy přispívají významně, kdežto ovladače s otevřeným kódem se objevují a mizí (podle toho, jak v nich lidé narážejí na chyby a opravují je). To poskytuje objektivní argument v diskuzi o tom, že v binárních ovladačích je těžší opravit chyby. Další významný fakt je, že grafiky od Intelu se v tomto seznamu objevují málokdy, což ukazuje, že pokud chcete grafiku, která 'prostě funguje', pak Intel je ta správná volba.
Začleňovací okno je hektická fáze vývojového cyklu jádra. Do gitového repozitáře hlavní řady si během přibližně dvou týdnů najde cestu pět až deset tisíc sad změn. Jenom správa tolika patchů je složitá, ale ta práce je značně komplikována faktem, že tyto sady změn na sobě nejsou nezávislé. První změna, která je začleněna, může změnit základnu kódu takovým způsobem, že to zabrání pozdějším patchům úspěšně se aplikovat. Proto začleňovací okna tradičně vyžadovala, aby správci přepracovali patche ve své frontě, aby vyřešili problémy, které se objeví ve chvíli, kdy jsou začleněny ostatní stromy. Je známo, že vzhledem k časovému omezení (patche, které nejsou připraveny v době, kdy se začleňovací okno uzavírá, obvykle sedí a čekají do dalšího cyklu) tento integrační proces na správce subsystémů vyvíjel značný tlak.
Další osobou pod tlakem byl Andrew Morton; jedním z jeho mnoha úkolů bylo srazit všechny subsystémové stromy dohromady v -mm vydáních. To mu zabralo hodně času a ani to problém skutečně nevyřešilo; část práce, která se objevuje v -mm, není zamýšlena pro příští vývojový cyklus. Konečným důsledkem toho všeho bylo, že každé začleňovací okno svedlo dohromady spoustu kódu, který do té doby integrován nebyl.
V únoru byl oznámen strom linux-next, který měl poskytnout způsob, jak s těmito problémy pomoci. Nyní se blížíme ke konci prvního celého vývojového cyklu, při kterým byl linux-next použit, takže už se můžeme podívat, jak fungoval.
Myšlenka tohoto stromu je relativně jednoduchá. Správce stromu linux-next Stephen Rothwell udržuje seznam stromů (spravovaných gitem i quiltem), které jsou zamýšleny k začlenění do dalšího vývojového cyklu. V době psaní tohoto článku seznam obsahuje 95 stromů, všechny jsou plné patchů, které míří do 2.6.27. Jednou za den Stephen projde procesem začleňování těchto stromů do hlavní řady, jeden po druhém. S každým začleněním hledá začleňovací konflikty a selhání překladu. Původní plán pro linux-next tvrdil, že stromy, které způsobí konflikt nebo znemožní překlad, budou prostě zahozeny. Ve skutečnosti si zatím Stephen obvykle najde čas a problém vyřeší; potom opraví nebo zahodí individuální patch, aby všechno dál fungovalo.
Když je tento proces dokončen, vydá výsledný strom linux-next pro ten den. Ostatní ho vezmou a provedou testování překladem; někteří lidé dokonce denní vydání linux-next bootují a používají. Výsledkem toho je plynulý proud hlášení o problémech, malých oprav, patchů, které se přesouvají z jednoho stromu do druhého a tak dál - různé kousky sjednocující práce, která je potřeba, aby se všechny části hezky složily.
Je zde zajímavý druh implicitní hierarchie, podle které se stromy řadí. U subsystémových stromů, které jsou začleněny jako první, je menší pravděpodobnost, že se objeví konflikty, než u těch, které jsou začleněny později. Když se u dvou stromů objeví konflikt, je to vlastník toho pozdějšího stromu - toho, u kterého se konflikt projeví - kdo cítí největší tlak, aby věci opravil. Historie ale zatím ukázala, že když se objeví konflikty, a objevují se téměř každý den, neukazuje se prstem. Všichni vývojáři rozumí tomu, že pracují na stejném jádře a sdílí společný zájem na řešení problémů.
Zatím se zdá, že linux-next funguje tak, jak bylo zamýšleno. Slouží jako bod sjednocení pro příští jádro a pomáhá odstranit mnoho začleňovacích problémů předem. Jeden aspekt tohoto systému nicméně ještě otestován nebyl: přesunutí patchů z linux-next do hlavní řady. Tak, jak si věci stojí, neexistuje žádné automatické přesouvání mezi stromy; místo toho správci zašlou jako vždycky své požadavky na přetažení přímo Linusovi. Jestliže Linus odmítne některé stromy začlenit nebo je začlení v pořadí jiném, než jak byly řazeny v linux-next, problémy s integrací se mohou vrátit. Nakonec se zdá, že linux-next bude muset řídit konečný sjednocující proces víc, než je teď očekáváno. Bude pravděpodobně potřeba několik vývojových cyklů, aby se přišlo na to, jak to zařídit, aby všechno fungovalo.
Mezitím může každý, koho zajímá 2.6.27, vzít linux-next a zkoušet to, co bude z velké části jádrem 2.6.27. Tento strom objasnil jeden aspekt vývojového procesu: dvou- až tříměsíční "vývojový cyklus", který provozuje Linus, je ve skutečnosti jenom špičkou ledovce vývoje jádra. Je to jen ta závěrečná integrační a stabilizační fáze. Linux-next téměř zdvojnásobuje délku viditelného vývojového cyklu tím, že dá dohromady další jádro dlouho předtím, než na něm Linus začne pracovat. A i linux-next přichází na řadu až na konci života patche.
V minulosti Linus bez obalu pracoval na tom, aby se vyhnul překrytí vývojové a stabilizační fáze vývojového cyklu. Po dobu téměř jednoho roku nebyl žádný vývojový strom v době, kdy bylo 2.4 dováděno do rozumného stavu. Toto oddělení bylo udržováno jednoduše ze strachu, že otevřený vývojový strom bude vývojáře vyrušovat od důležitějšího úkolu, kterým je hledání a opravování chyb v současném stabilním vydání.
Toto oddělení je nyní minulostí; nyní jsou tucty vývojových stromů, které mají neustále otevřeno. To může být pro ty, kdo se zabývají kvalitou jádra, znepokojující; proč by se vývojáři měli zabývat chybami v 2.6.26, když je dáváno dohromady 2.6.27 a 2.6.28 je již na dohled? Jestli jsou tyto obavy na místě, bude pravděpodobně záležitost pokračující debaty.
Mezitím se zdá, že linux-next se na poli vývoje jádra usadil jako něco, co jen tak nezmizí. Slouží svému účelu jako místo, kde je možné najít a vyřešit problémy sjednocování; také sňal spoustu této sjednocovací práce z ramen Andrewa Mortona. A to by zase obratem mělo jemu uvolnit dost času na to, aby se mohl pokusit donutit vývojáře opravit všechny ty chyby.
(Vizte wiki linux-next, kde najdete víc informací o tom, jak s tímto stromem pracovat.)
23. června společnost HP oznámila, že uvolňuje zdrojové kódy pro "Tru64 Advanced Filesystem" (Tru64 pokročilý souborový systém, též AdvFS) pod GPL verze 2. To je od HP zjevně velké uvolnění kódu. Méně zjevné je, jaká je hodnota tohoto uvolnění pro Linux. Nakonec bude pravděpodobně významná, ale bude nejspíše realizována relativně nepřímými a těžko měřitelnými způsoby.
AdvFS byl původně vyvinut firmou Digital Equipment Corporation pro jejich verzi Unixu; HP se k němu dostal, když převzal Compaq, který převzal DEC v roce 1998. Tento souborový systém nabízí množství obvyklých vlastností. Je zamýšlen jako vysoce výkonný souborový systém - přirozeně. Jsou poskytovány správa bloků založená na rozsazích a indexy adresářů. Žurnáluje kvůli rychlému obnovení po pádu, má možnost obnovit smazané soubory. AdvFS je také navržen k práci v prostředí clusterů.
Mnoho snahy, která byla AdvFS věnována, souvisí s vyhýbáním se nutnosti vypnout počítač. Existuje možnost vytvářet snapshoty, které vytvoří konzistentní zálohy běžícího systému. Defragmentaci lze provádět online. Souborový systém obsahuje zabudovanou vrstvu správy svazků, která do něj umožňuje přidat (nebo z něj odstranit) úložná zařízení za běhu; soubory lze také přesídlit mezi zařízeními, ale nic pokročilejšího než toto se nenabízí; AdvFS bude nicméně šťastně fungovat nad schopnějším správcem svazků.
Je pár věcí, které AdvFS nemá. Neexistují kontrolní součty pro data a tím žádná možnost, jak zachytit poškození. Testování integrity souborového systému za běhu, zdá se, není podporováno. Maximální velikost systému (16TB) možná v době začátku devadesátých let vypadala jako nekonečná, ale dneska je poněkud omezující. Obecně AdvFS vypadá jako něco, co bylo před deseti nebo patnácti lety hezký souborový systém, ale teď nemá nic, co by v Linuxu buď už nebylo k dispozici, nebo na čem se aspoň nepracuje. A AdvFS na Linuxu ani nefunguje - nikdo se nesnažil ho portovat a není jisté, jestli se o to někdo pokusí. Takže je toto vydání prostě další odhození kódu, který jeho vlastnická firma opouští?
Dalo by se jednoduše odpovědět, že ano. I kdyby to byla pravda, stále by to bylo vítané. Jestliže se společnost rozhodne vzdát se nějakého kódu, je mnohem lepší, když ho nabídne k adopci pod GPL, než aby ho nechala hnít do doby, než ho nikdy nikdo nenajde. V tomto vydání by se však nějaká hodnota skrývat mohla.
I kdyby nebyl důvod snažit se rozchodit ho pod Linuxem, kód AdvFS je zásoba více než desetiletí zkušeností se snahou o vytvoření highendového souborového systému v komerčním prostředí. Autor článku přestal v DEC systems pracovat v době, kdy byl AdvFS vydán, ale slyšel, že první vydání byla něco, co, řekněme, poučilo správce o hodnotě častých záloh. Současný kód zohledňuje všechny tyto tvrdé lekce, které vývojáři dostali, než se k němu dopracovali.
Chris Mason, který v současnosti pracuje na souborovém systému Btrfs, to řekl takto:
Myšlenka je taková, že dobře zavedené souborové systémy nás mohou hodně naučit o rozvržení a o optimalizacích, které byly přidány v reakci na požadavky zákazníků. Mít k těmto optimalizacím kód je velmi užitečné.
Mít kód pod GPL je obzvlášť užitečné: jakýkoliv kód, který se může hodit ve své současné podobě, může být do Linuxu rychle přetažen. A i kdyby kód sám o sobě použít nešlo, nápady, které obsahuje, si lze bez obav vypůjčit. A to je přesně to, co chtěla HP tímto vydáním podpořit:
Pro případ, že by to nebylo jasné, toto je technologické vydání pod GPLv2, nikoliv skutečný port pro Linux. Doufáme, že kód a dokumentace budou užitečné při vývoji nových souborových systémů pro Linux, které poskytnou podobné možnosti, a možná bude použit při ladění těch stávajících.
A zdá se, že to se pravděpodobně stane. Postupem času by si nejlepší nápady a zkušenosti z AdvFS měly najít cestu do souborových systémů, které Linux podporuje, i když se AdvFS sám o sobě nikdy mezi tyto souborové systémy nezařadí. Tím HP významně přispěla do vývojového procesu jádra, i když se pravděpodobně nijak neprojeví v počtu sad změn ani jiném snadno získatelném měření.
(Ti, kdo se o AdvFS zajímají více, si mohou stáhnout tarball s dokumentací ze stránek AdvFS na sourceforge. "Stopařův průvodce" [Hitchhiker's Guide] je dobrý startovní bod, i když při 229 stránkách není určen pro stopaře, kteří rádi cestují nalehko).
Zdá se, že někteří jaderní vývojáři v těchto dnech myslí na zmrazování, jestli to způsobuje léto na severu nebo zima na jihu, není jasné. Dva nedávné patche zaslané do linux-kernel se dívají na zmrazování - v podstatě uspávání - dvou různých částí jádra: souborových systémů a kontejnerů. Pro kontejnery je to další krok na cestě zajistit, aby bylo možné migrovat běžící procesy jinam, kdežto pro souborové systémy to umožní vytvořit záložní snapshot v konsistentním stavu souborového systému. Kromě konceptu nemají patche spolu nic společného, ale oba jsou docela malé a samostatné, takže se na ně můžeme podívat naráz.
Takashi Sato navrhuje vzít vlastnost specifickou pro XFS a přesunout ji do kódu souborových systémů. Patch by poskytl ioctl() pro pozastavení přístupu k zápisu do souborového systému, zmrazení a stejně tak rozmrazovací volbu pro obnovení možnosti zapisovat. Pro zálohy, které dělají snapshot souborového systému nebo jinak pracují přímo na blokovém zařízení to zajistí, že bude souborový systém v konzistentním stavu.
Tento patch v podstatě exportuje jadernou funkci freeze_bdev() tak, aby ji mohl volat i uživatel. freeze_bdev() zamyká souborový systém v konzistentním stavu tak, že zapíše superblock a synchronizuje [sync] zařízení. Patch také přidává sledování zmrazeného stavu do položky state struct block_device. V nejjednodušší formě by se zmrazení a rozmrazování souborového systému dalo udělat takto:
ioctl(fd, FIFREEZE, 0); ioctl(fd, FITHAW, 0);
Kde fd je popisovač přípojného bodu a argument je ignorován.
V další části sady patchů Takashi přidává hodnotu časového limitu [timeout] jako argument k ioctl(). Pro kompatibilitu s XFS - i když je díky patchi od Davida Chinnera ioctl() specifické pro XFS odstraněno - znamená hodnota 1 parametru ukazatel, že limit není nastaven. Hodnota 0 tohoto argumentu také znamená, že není časový limit, ale jakákoliv jiná hodnota je považována za ukazatel na hodnotu časového limitu ve vteřinách. Zdá se, že odstranění ioctl() specifického pro XFS stejně rozbije všechny programy, které ho používají, takže zachování kompatibility hodnoty parametru 1 je poněkud podivné.
Když vyprší časový limit, souborový systém bude automaticky rozmrazen. To slouží jako ochrana proti problémům se zálohovacím systémem. Byl přidán další ioctl() příznak (FIFREEZE_RESET_TIMEOUT) který aplikaci umožní resetovat odpočet časového limitu, dokud pracuje. Jestliže dojde k deadlocku nebo program z jiného důvodu odpočet nevyresetuje, souborový systém se rozmrazí. Další FIFREEZE_RESET_TIMEOUT poté, co se tak stane, vrátí EINVAL, takže program může rozeznat, k čemu došlo.
Když se přesuneme ke kontejnerům, Matt Helsley zaslal patch, který používá infrastrukturu softwarového uspání (swsusp) k implementaci zmražení všech procesů v kontrolní skupině [cgroup]. Nyní ji lze použít k zastavení a opětovnému startu úloh, ale nakonec by mělo být možné použít ji k migrování úloh úplně jinam například za účelem vyrovnávání zátěže či z jiného důvodu. Mattův patch je založen na práci, kterou původně udělal Cedric Le Goater.
Prvním krokem je zpřístupnit volbu pro zmrazování ve formě příznaku TIF_FREEZE všem architekturám. Když je to hotovo, přesunout dvě funkce - refrigerator() a freeze_task() - ze subsystému správy napájení do nového souboru kernel/freezer.c, což umožní zmrazovat úlohy i architekturám, které správu napájení nepodporují.
Jak je pro kontrolní skupiny obvyklé, zmrazování a rozmrazování se ovládá přes souborový systém cgroup. Přidání volby freezer při připojování umožní přístup k souboru freezer.state každého kontejneru. Ze souboru lze číst aktuálního stavu mrazáku, zápis do něj stav změní:
# cat /containers/0/freezer.state RUNNING # echo FROZEN > /containers/0/freezer.state # cat /containers/0/freezer.state FROZEN
Je potřeba poznamenat, že je možné, aby byly úlohy v kontrolní skupině zaneprázdněny něčím, co by jim neumožnilo nechat se zmrazit. V takovém případě by stav byl FREEZING. Mrazení v takovém případě lze zkusit znovu opětovným zápisem FROZEN nebo zrušit zápisem RUNNING. Odstranění překážející úlohy z kontrolní skupiny také umožní zbytek skupiny zmrazit. Když stav dosáhne hodnoty FROZEN, kontrolní skupinu lze rozmrazit zápisem RUNNING.
Aby mohly swsusp a kontrolní skupiny sdílet refrigerator(), je nutné zajistit, že zmrazené kontrolní skupiny nebudou probuzeny, když swsusp probouzí systém po uspání. Poslední patch v sadě zajišťuje, že thaw_tasks() vyhledá zmrazené kontrolní skupiny a při probouzení je vynechá.
V linux-kernel se o patchích příliš nediskutovalo, ale ACK od Pavla Machka se zdá být dobrým znamením. Některé komentáře od Paula Menage, který kontrolní skupiny vyvinul, také naznačují zájem na tom, aby byla tato vlastnost začleněna.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
11.8.2008 15:28
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Bylo vydáno prohlášeníNo, ale to je asi tak všechno co mohou…škoda.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz