Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
Následující obsah je © KernelTrap.
Tenhle kód nebude začleněn. Nebude začleněn před 2.6.26 a nezačlení se ani potom. Buď ho přepiš, nebo ne. Je mi to fuk. S radostí budu nezačleňovat svinstvo po celý zbytek života.
Linus Torvalds, zpráva z 7. května 2008 na Linux Kernel mailing list.
19. května, originál
Tentokrát máme 60+ % změn v ovladačích, hlavně v drivers/video a drivers/media, nějaké v infiniband, síťování a USB to vše doplňuje, oznámil Linus Torvalds jádro 2.6.26-rc3. Zbytek jsou (jako vždycky) aktualizace architektur, v tomto případě nejvíce mips, m68k a uml. Linus zmínil, že vývoj jádra už je gitem spravován stejnou dobu, jako byl spravován BitKeeperem - něco málo přes tři roky pro oba nástroje. K tomu napsal: Ten nejvýraznější rozdíl nemá nic společného ani s gitem, ani s BK (jenom to, že díky časování jsem se podíval), ale spočívá v tom, že nejenom že dál vyvíjíme, ale vyvíjíme rychleji a s více lidmi.
Během tří let 2002->2005 jsme měli 63428 commitů přiřazených 1560 autorům (poznámka: překlepy a podobné způsobují, že někteří lidé jsou započítáni více než jednou). Během posledních tří let jsme jich měli 96885 přiřazených k 4068 různým autorům (se stejnou poznámkou, což je zjevné).
Nedělal jsem zatím mnoho statistik podle jednotlivých commitů, ale z toho mála, co jsem udělal, to také vypadá, že jsme se zlepšovali v dělání malých commitů (což je pravděpodobně jeden z důvodů, proč jich máme větší množství, ale také proč máme více autorů - malé commity jsou cestou, kterou se lidé dostávají k vývoji jádra).
Už jsi měl někdy ve tři ráno za sebou hodinu a půl hledání půlením [bisection] a narazil na masivní oops hluboko v TCP kódu, který byl rozprostřen přes mnoho commitů? Já jo a sranda to nebyla. Pokud si dobře vzpomínám, vzdal jsem to a šel spát.
Andrew Morton, zpráva z 14. května 2008 na Linux Kernel mailing list.
20. května, originál
Je někde sepsáno, co považuješ za 'správný' průběh práce gitu? ptal se Theodore Ts'o Linuse Torvaldse. Proč považuješ změnu základního bodu [rebasing] tématických větví [topic branch] za špatnou věc? Linus odpověděl: Změna základního bodu vůbec není špatná věc pro jednotlivé vývojáře. Nicméně to je špatná věc pro správce subsystému. Potom pokračoval výpisem rozdílů mezi 'pěšáky', kteří píší kód, a 'manažery', kteří hlavně sbírají kód jiných. Pěšák by měl používat 'git rebase', aby svůj kód udržel ve shodě se stromem. Technický manažer, i když snad dělá nějakou užitečnou práci sám o sobě, by se měl snažit donutit ostatní, aby udělali tolik práce, kolik je jenom možné. Pak je 'git rebase' špatná věc, protože to vždycky ztíží lidem okolo tebe sledování tvého stromu a pomoc při jeho aktualizaci. [viz také Nová větev linux-next a způsob správy patchů]
Linus porovnal svůj vlastní styl správy patchů a produktivitu od doby před více než šesti lety, kdy ještě nepoužíval BK, do dneška, kdy používá git: Buď se můžeš pokusit pít z požární hadice a nevyhnutelně dostat vynadáno, protože něco zdržuješ nebo něčemu nevěnuješ dostatečnou pozornost, kterou si to zasluhuje. Nebo se můžeš pokusit zajistit, aby ti mohli pomoci ostatní. A raději by sis měl vybrat 'nechat ostatní, aby ti pomohli', protože jinak se určitě spálíš. Není to záležitost 'jestli', ale 'kdy'. [...]
Když jsi na takovém hřišti, měl by sis představit, že jsi na tom stejně, jako jsem byl já před BK. Skutečně by ses měl hodně snažit, abys nebyl ten článek, na kterém věci váznou, a měl bys sis naplánovat provádění začlenění v gitu. [...] Myslím si, že spousta lidí je mnohem spokojenější se současným způsobem, jakým můžu převzít jejich práci, než před těmi šesti+ lety.
RTOS (operační systém reálného času [Real-time Operating System]) obětuje výkonnost, aby se dosáhlo determinismu (nízkých latencí). Několik klíčových rysů RT systému obvykle funguje jen za cenu ztráty výkonnosti. Ne-RT systém bude v 99 % případů fungovat rychleji než RTOS. Nicméně stačí jen jednou propásnout limit a RT systém zhavaruje. RTOS může být mírně pomalejší, ale nebude mít tyto bludné kameny, které by měl normální desktopový systém.
Steven Rostedt, zpráva z 20. května 2008 na Linux Kernel mailing list.
27. května, originál
Teď už víte, jak to chodí: další týden, další -rc, oznámil Linus Torvalds jádro 2.6.26-rc4. Je tu spousta malých záležitostí, většina lidí si jich ani nevšimne. Nejvýraznější věc platí pro vás všechny, kdo používáte 32bit x86 a PAE (povolené volbou HIGHMEM64G) kvůli tomu, že máte ve svém stroji příliš mnoho paměti - mprotect() byl rozbit kvůli nějakým opravným/pročišťovacím patchům, takže NX bit nebyl nastavován správně. Linus opravenou chybu popsal:
Pokud jste měli povolené PAE a dostatečně nové CPU, které má NX, ale ne dost nové na to, aby bylo 64bit (nebo jste byli prostě perverzní a chtěli provozovat 32bitové jádro na čipu, který umí pracovat 64bitově, a přitom měli tolik paměti, že jste rozhodně měli použít 64bitové jádro), objevovaly se vám různé náhodné pády programů se SIGSEGV. To se dělo v rozsahu od nestartujících X, po nefungující OpenOffice, pokud X nastartovala.
Pokračoval obvyklým seznamem: Většina změn - 60 % - je jako obvykle v ovladačích, kde největší část představují změny v DRI (opravují mnoho dalších regresí hlavně odstraněním nedovařené aktualizace vblank). Nějaké aktualizace se také dostaly do ovladačů pro síť, MMC, USB, watchdog a IDE. Také jsme měli nějaké aktualizace CIFS a NFS a jako obvykle nějaké v architekturách. Linus zprávu uzavřel: Nic opravdu hodně vzrušujícího; myslím si, že ve vývojovém cyklu si vedeme docela dobře, a mám pocit, že věci se zklidňují.
Všichni se teď zhluboka nadechněme a uklidněme, ok? Byl nám agresivně předložen patch a agresivně jsme ho odmítli. Nemusíme okolo toho dělat další humbuk. Tady není nic k vidění lidi, pokračujte...
Mike Galbraith, zpráva z 27. května 2008 na Linux Kernel mailing list.
28. května, originál
Jde o vysoce výkonný síťový souborový systém s lokální koherentní cache dat a metadat. Jeho hlavním cílem je distribuované paralelní zpracování dat, psal Jevgenij Poljakov v oznámení nejnovější verze paralelního optimalizovaného hostitelsky vrstveného souborového systému s výměnou zpráv. Dodal, že kromě mnoha oprav chyb tato verze zahrnuje následující nové vlastnosti:
Jevgenij také psal, že začal pracovat na podpoře pro paralelní zpracování dat, jedné z klíčových vlastností zamýšlených pro tento souborový systém. Dodal, že počáteční logika již byla přidána, takže data mohou být naráz zapsána na více serverů a čtení může být vyvažováno mezi více servery, ale ještě není souborovým systémem využívána.
Doporučuji tobě i všem ostatním, kteří chtějí zlepšit kvalitu této komunity, aby se do ní zapojili. Naučte se o nějakém subsystému. Zasílejte patche, které řeší problémy, které lidi zajímají. Naslouchejte kritice a konstruktivně na ni reagujte.
Chris Snook, zpráva z 27. května 2008 na Linux Kernel mailing list.
30. května, originál
Zezačátku byl tento projekt považován za způsob, jak do vývoje jádra dostat čerstvou krev tím, že dáme lidem vcelku jednoduché, ale obecně užitečné úkoly a budeme doufat, že se posunou blíže ke střednímu proudu, začal James Bottomley vlákno nazvané Oprava projektu jaderných údržbářů [kernel janitors]. Když se ale přesuneme do roku 2008, údržbářské patche způsobují značné a rostoucí třenice. Odkázal na nedávné vlákno, které si stěžuje na bezcenné patche, které se dostávají do lkml. Později v diskuzi dodal:
To je důvod, proč si myslím, že by se ten proces měl změnit. Jestliže ponecháme projekt údržbářů, je nutné zvednout laťku, aby se lidé více účastnili vývoje a zaměřili na úkoly, které vyžadují přemýšlení (tj. od počátku eliminovat každého, kdo nebude postupovat od primitivních změn k užitečnějším). Proto si myslím, že je lepší hledat a hlásit chyby. V hledání chyb je sice také určitá strojovitost, ale je to užitečná služba. Opravování chyb znamená účastnění se, protože mezi opravářem a ohlašovatelem probíhá komunikace a pár lidí nakonec začne projevovat zájem o to, jak se chyba spustila, a pak si jdou přečíst kód.
Jestliže neumíš správně použít strcpy a strlcpy, neměl bys dělat programátora.
Theo de Raadt, zpráva z 27. května 2008 na OpenBSD -misc mailing list.
2. června, originál
V dubnu se správce jádra 2.4 Willy Tarreau zeptal v mailové konferenci Linux kernel na to, jak se používá jádro 2.4. Poté zaslal shrnutí odpovědí, kde psal, že okolo 5 % uživatelů provozuje jádro 2.4 doma na starých recyklovaných noteboocích nebo na PDA a tenkých klientech, kde záleží jen na tom, aby to běželo, a upgrade není potřeba. Dalších 5 % uživatelů jsou desktopová PC a monitorovací stanice, které nejsou upgradovány proto, že "to funguje".
Odtud dál 50 % uživatelů provozuje jádro 2.4 na serverech všeobecně a pravidelně aktualizují; starší jádro používají kvůli nedostatku času, nepotřebují nové vlastnosti nebo jejich dřívější pokusy o upgrade selhaly. Dalších 20 % provozuje jádro 2.4 na aplikačních serverech, kde je nejdůležitější spolehlivost. 10 % uživatelů má starší stabilní jádro na routerech, firewallech a systémech pro detekci průniků s 1 až 2letými uptime a omezenými aktualizacemi v obchodních nasazeních a kratšími uptime a častějšími aktualizacemi v osobních nasazeních.
Závěrečných 10 % používá jádro na embedded systémech, kde je opět velmi důležitá stabilita a strom může být značně modifikován, což způsobuje, že nejméně jeden významný výrobce síťového vybavení stále dodává zařízení s jádrem 2.4.2.
Podle toho a náplně práce, kterou mi lidé popsali, si uvědomuji, že rozlišení mezi -pre a -rc je k ničemu (bink! Linusi, jestli to čteš, nebij mě). Ve skutečnosti lidé buď chtějí absolutní spolehlivost a pak si vyberou jádro ze stabilní větve 2.4.x.y, nebo chtějí nejnovější aktualizace a pak jednoduše nakoupí ve větvi -master, což je docela jednoduché díky rozhraní Gitweb. V 2.4 ale nejsou téměř žádní testeři, jenom uživatelé. To znamená, že nemohu očekávat okamžitou zpětnou vazbu, když pošlu -pre vydání. Několikrát se stalo, že jsem dostal hlášení o chybě při překladu několik týdnů po vydání.
Navíc, vzhledem k tomu, že většina lidí neaktualizuje víc než jednou až dvakrát za rok, nemá moc smysl vydávat víc než jednu až dvě verze za rok, obzvlášť když máme stabilní verzi. Z toho důvodu si myslím, že budu vydávat stabilní vydání trochu častěji, aby se k uživatelům rychleji dostaly opravy, ale také postupně zvýším intervaly mezi hlavními verzemi. Ty budou vydávány jenom s novými PCI ID, velkými aktualizacemi ovladačů, podporou překladače atd.
Myslím si, že chybně předpokládáme, že každý, kdo chce přispívat do jádra, chce programovat. Nebo že každý chce dosáhnout na čelní místo v seznamu přispěvatelů velkých vlastností. Pro spoustu lidí budeme ten experiment z vysoké, který později v životě nebudou chtít spravovat.
Chris Mason, zpráva z 28. května 2008 na Linux Kernel mailing list.
3. června, originál
Webová stránka http://www.kerneloops.org/ sbírá jaderné oopsy a varování z různých mailových konferencí, bugzill a od uživatelů, kteří si nainstalovali klienta, který oopsy posílá automaticky, začal Arjan van de Ven a odkázal se na webovou stránku, která byla poprvé oznámena loni v prosinci. Tento týden bylo hlášeno celkem 3670 oopsů a varování; pro porovnání - minulý týden to bylo 3029. Klient 'kerneloops' je k dispozici na stránkách projektu a je postupně zahrnován do mnoha distribucí. Po Fedoře zahrnul klientskou aplikaci do své výchozí GUI instalace i Debian, díky moc za to! psal Arjan a poté zmínil některé změny:
Tento týden jsem na základě zpětné vazby rozdělil hlášení na 'neposkvrněná' [untainted] a 'způsobená proprietárními ovladači'. Dejte mi vědět, jestli v tom mám pokračovat, nebo jestli byl původní formát lepší.
Jako experiment jsem (na žádost) exportoval databázi do textových souborů (jeden soubor na hlášení) a strčil je do gitového repozitáře. Můžete se podívat pomocí git clone git://www.kerneloops.org/. Návrhy k vylepšení formátu jsou samozřejmě velice vítány, stejně jako komentáře 'ano, užitečné' a 'ne, zbytečné'. Ještě jednou - je to experiment a pokud nebude považován za užitečný, mohu s tím přestat.
Tato bootování náhodných jader v minulosti našla spoustu chyb a souběhů, 'ke kterým nemůže dojít'. Příčinou schopnosti najít souběhy je náhodnost časování výsledného náhodného jádra: zpoždění způsobená náhodnými kombinacemi ladících prostředků, variant překladu a variant jaderných subsystémů, které máme.
Ingo Molnár, zpráva ze 4. června 2008 na Linux Kernel mailing list.
4. června, originál
Tony Luck poskytl nějaké statistiky o tom, jak často se vyskytují vývojáři, kteří do jádra přispívají jednorázově. Prošel jsem to a hledal jsem přispěvatele, co jenom jeli kolem (definováni tak, že přispěli jenom do jednoho vydání a už o nich nebylo slyšet). Počínaje jádrem 2.6.11 uvedl tato čísla:
Bylo poukázáno na to, žy tyto statistiky jsou zkreslené směrem nahoru kvůli překlepům a jiným změnám ve jménech a mnoho z uvedených lidí ve skutečnosti na Linuxu stále pracuje. Greg KH dodal: No, asi víš, že rozdělení všech našich uživatelů je: 50 % přispělo jen jedním patchem; 25 % přispělo dvěma; 12 % přispělo třemi; 6 % přispělo 4 a tak dál? Poté upozornil na to, že:
Naše křivka se nicméně mnohem lépe vyrovnává. Na celém vydání 2.5 udělalo přes 80 % práce 30 nejaktivnějších lidí. Nyní dělá 30 nejaktivnějších 30 % práce. Situace se tedy značně zlepšuje. Dokud budeme schopni udržet rychlé tempo změn, které se dějí, a obrovské množství vývojářů, měli bychom být v pohodě. Tenhle seznam tedy nutně neznamená, že je něco špatně, jenom to, že 50 % jsou jednorázové příspěvky. Já si myslím, že to ukazuje, že dostat změnu do našeho stromu je jednoduché pro kohokoliv a že od sebe lidi neodháníme.
Klíčovým důvodem, proč se Linuxu podařilo uspět, je to, že se aktivně snaží, aby fungoval různým lidem, pro různé účely a na různých produktech. Jeden operační systém je nyní silným hráčem na trhu embedded zařízení, na trhu nasazení v reálném čase a na trhu výpočtů s vysokým výkonem [high performance computing] a zároveň významným hráčem na mnoha dalších trzích. To je vcelku omračující úspěch.
Paul Jackson, zpráva ze 4. června 2008 na Linux Kernel mailing list.
5. června, originál
Další týden, další dávka ponejvíce vcelku malých oprav. Seznam regresí se nadějně změnšuje a opravili jsme přinejmenším pár oopsů z Arjanova seznamu, psal Linus Torvalds v oznámení jádra 2.6.26-rc5. Jako obvykle je nejvíc změn v ovladačích a kódu architektur - společně jim patří asi 70 % diffstatu. A statistiky arch se nafoukly díky několika novým/aktualizováným defconfig souborům u SH a avr, což je v tomto stádiu také vcelku běžné.
Možná poněkud neobvykle je 13 % v kernel/, téměř většina z toho opravuje nějaké problémy plánovače - největší část z toho je pár revertů kvůli regresím výkonnosti. Nicméně je tam i mnoho dalších oprav. Pak následuje síťování a nějaké aktualizace ocfs2. Společně s různými jednořádky rozházenými všude možně.
Zkrácený log (přiložen) dává na celou věc rozumný pohled. Nic hodně vzrušujícího mě nenapadá, ale myslím si, že jsme neměli žádná místa s hodně vzrušujícími problémy.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
oznámil Linus Torvalds jádro 2.6.23-rc3
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz