AlmaLinux byl vydán v nové stabilní verzi 9.4 (Mastodon, 𝕏). S kódovým názvem Seafoam Ocelot. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Před 50 lety, 5. května 1974 v žurnálu IEEE Transactions on Communications, Vint Cerf a Bob Kahn popsali protokol TCP (pdf).
Bylo vydáno do češtiny přeložené číslo 717 týdeníku WeeklyOSM přinášející zprávy ze světa OpenStreetMap.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.10.38 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Google zveřejnil seznam 1220 projektů od 195 organizací (Debian, GNU, openSUSE, Linux Foundation, Haiku, Python, …) přijatých do letošního, již dvacátého, Google Summer of Code.
Na základě DMCA požadavku bylo na konci dubna z GitHubu odstraněno 8535 repozitářů se zdrojovými kódy open source emulátoru přenosné herní konzole Nintendo Switch yuzu.
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Následující obsah je © KernelTrap.
2. únor, originál
Nejnovější vydání GITu - 1.5.4 - je k dispozici na obvyklých místech, oznámil správce Gitu Junio Hamano. Byl to poněkud dlouhý vývojový cyklus, 5 měsíců od posledního vydání verze s novými vlastnostmi - 1.5.3 - je trochu mnoho. Doufám ale, že stálo za to si počkat. Děkuji všem, kteří pracovali na vylepšeních. Dodal, že se připojilo celkem 165 přispěvatelů, což vedlo ke 684 změněným souborům, což zahrnuje 70435 vložení a 28984 výmazů.
Distribuovaný systém správy verzí Git byl původně napsán Linusem Torvaldsem v dubnu 2005 jako dočasná náhrada BitKeeperu, který se používal ke správě zdrojových kódů jádra od února 2002. Junio Hamano převzal správcovství Gitu o pár měsíců později v červenci 2005 a nástroj jako takový je nyní vcelku oblíbený dokonce i mimo vývoj jádra. Co se nejnovější stabilní verze týče, Junio zdůraznil některé ze změn.
Před vydáním budu na HAMMERu pracovat tak dlouho, jak budu moci, ale stejně tohle vydání určitě bude ve stavu brzké alfaverze.
Matthew Dillon, zpráva z 1. února 2008 na DragonFlyBSD -user mailing list.
3. únor, originál
Jednoho dne jsem znovu udělal nějaké statistiky tempa vývoje jádra a zároveň změnil vzorec poté, co mě Andrew obvinil, že výsledné číslo je mnohem nižší, než by mělo být, psal Greg KH během diskuze o stabilitě jádra Linuxu během významných změn. Ukázalo se, že do vydání 2.6.24-rc8 jádra 2.6.24 jsme udělali: řádků přidáno za den: 4945; řádků odebráno za den: 2006; řádků modifikováno za den: 1702.
Podotýkám, že tohle jsou skutečné údaje, nezahrnují přejmenování nebo přesouvání souborů, protože git je do toho umí nezapočítat. To platí pro těch 99 dní, které uběhly, než jsme vydali 2.6.24-rc8 (je potřeba ty skripty spustit znovu, když je teď 2.6.24 vydáno). Je děsivě ohromující, že věci vůbec fungují... To bylo jen tak něco, abyste v noci dobře spali :).
Čas od času si všichni nosíme hnědý papírový pytlík, a proto když vezmu v potaz začleňovací maelström v každém začleňovacím okně, tak mě udivuje, jak málo věcí přestává fungovat.
Jeff Garzik, zpráva z 2. února 2008 na Linux kernel mailing list
4. únor, originál
Joseph Myers oznámil, že GCC 4.2.3 je k dispozici: GCC 4.2.3 je vydání, které opravuje chyby [bug-fix release], obsahuje opravy regresí verze 4.2.2 vzhledem k předchozím verzím GCC. Jako vždycky do tohoto vydání přispělo ohromné množství lidí -- příliš mnoho na to, aby jim bylo možné děkovat jednotlivě!
GCC je sada překladových nástrojů GNU (GNU Compiler Collection), která zahrnuje překladače pro C, C++, Objective-C, Fortran, Javu a Adu. GCC 4.2.3 můžete stáhnout z nejbližšího zrcadla gcc.gnu.org.
LKML je ta správná mailová konference pro hlášení chyb v Linuxu. Trend, který jsem v poslední době viděl, je extrémně škodlivý: někteří vývojáři jádra z nějakého důvodu odklánějí tok hlášení o chybách pryč od LKML tím, že testerům naznačují, že LKML je tak nějak nevhodná pro hlášení chyb.
Ingo Molnár, zpráva z 28. ledna 2008 na Linux kernel mailing list
5. únor, originál
Nedávno bylo poukázáno na to, že většina patchů pro architekturu x86 byla začleněna do hlavní řady jádra 2.6.25. Výjimkou byly pouze patche kgdb. Linus Torvalds odpověděl: O přetažení nebudu ani uvažovat do doby, dokud to nebude nabídnuto jako samostatný strom, ne smíchané s dalšími věcmi. V takovém případě bych se na to podíval.
Jinak řečeno, vysvětlil jsem Ingovi, proč mě to nějak obzvláště nezajímá. Myslím si, že ladění zaměřené na vývojáře není ani zdaleka náš problém. Osobně by mě mnohem víc zajímala infrastruktura, která by běžným uživatelům pomohla poskytovat lepší hlášení o chybách. A to kgdb ani zdaleka nedělá.
Takže bych v mžiku začlenil patch, který vypíše informace o oops (nebo celý výpis z konzole) v Intel Management záležitostech. Ten kód je pravděpodobně mnohem ubožejší, než kgdb kdy bude (Intel v tom rozhraní skutečně zkazil, co mohl, a udělal z toho šílenou XML záležitost), ale je také podstatně důležitější - pokud to bude znamenat, že nám budou moci běžní uživatelé dát hlášení o oopsu poté, co se jim stal v X (dneska pravděpodobně častěji během suspend/resume), a ten stroj prostě umřel.
Patche jako tenhle mě přímo děsí.
Andrew Morton, zpráva z 1. února 2008 na Linux kernel mailing list
6. únor, originál
Ještě jsem neměl v plánu uvolnit verzi 0.12, protože jsem chtěl, aby v ní byl základ podpory několika zařízení [multiple devices, MD]. Nicméně jsem udělal několik vylepšení ohledně výkonnosti a opravil nějaké menší chyby, takže to vydávám předtím, než dojde na (destabilizující) práci na MD, psal Chris Mason o vydání verze 0.12 jeho souborového systému btrfs. Btrfs (vizte také blog Linuxová konkurence ZFS od Oracle - Btrfs) byl poprvé oznámen v červnu 2007 jako souborový systém alfa-kvality, který mimo jiné nabízí kontrolní součty všech souborů a metadat, na rozsazích [extents] založené ukládání dat, efektivní ukládání malých souborů, dynamickou alokace inodů, zapisovatelné snapshoty, zrcadlení a striping na úrovni objektů a rychlé offline kontroly souborového systému.
Na webových stránkách projektu se píše: Linux má nepřeberné množství souborových systémů, ze kterých si lze vybrat, ale na velkých subsystémech, které jsou čím dál tím běžnější v dnešních datacentrech, čelíme mnoha potížím se škálováním. Souborové systémy potřebují škálovat svou schopnost adresovat a spravovat velká úložiště a také schopnost detekovat, opravovat a tolerovat chyby v datech uložených na disku.
Ohledně nejnovější verze Chris řekl: Tak tady je v0.12. Dodává se s nablýskaným nový formátem disku (sorry), ale zisk při náhodném zápisu do existujících souborů je značný. Při testování se fáze náhodného zápisu v tiobenchi zrychlila z 1 MB/s na 30 MB/s. Oprava spočívala ve změně způsobu, jakým se počítaly hashe zpětných referencí pro souborové rozsahy.
V uživatelském prostoru si můžeš hrát, ale jsi naivní, pokud si myslíš, že to můžeš udělat i v jádře. A určitě jsi naivní, pokud věříš, že mmap() řeší problémy s výkonností. 'Bez kopírování' [zero-copy] se nerovná 'rychle'. Rychlost paměti může být menší než rychlost jádra CPU, ale ne nekonečně.
Linus Torvalds, zpráva ze 4. února 2008 na Linux kernel mailing list
8. únor, originál
Během posledních několika týdnů se nám s pomocí Ingo Molnára a Pekky Enberga podařilo vytvořit novou verzi kmemcheck! oznámil Vegard Nossum. Současná verze patche nabootuje na reálném hardwaru, ale na některých strojích jsem ji viděl vytuhnout, takže ještě není perfektní (jinými slovy, tento patch je VELMI experimentální, používáte ho na svoje riziko atd.). K tomu přidal krátké shrnutí, co patch dělá.
Kmemcheck je patch do linuxového jádra, který detekuje používání neinicializované paměti. Toho dosahuje zachycením všech zápisů a čtení paměti, která byla alokována dynamicky (např. pomocí kmalloc()). Jestli je čteno z paměťové adresy, na kterou nebylo nic zapsáno, do jaderného logu se vypíše zpráva.
Ingo Molnár ukázal užitečnost patche tím, že už našel 4 chyby v jádře. Také napsal další podrobnosti ohledně toho, jak patch funguje a proč je užitečný: Mělo by být zdůrazněno, že nejenom že kmemcheck spotřebuje polovinu RAM, je také velmi, velmi pomalý, protože téměř každá instrukce z jaderného prostoru vygeneruje výpadek stránky [pagefault], načež je krokována, což vyžaduje také ladící výpadek [debug fault]. To je samozřejmě totálně šílené, ale je to také OK a je to důvod, proč je tato vlastnost tak zajímavá a výkonná.
Je to ascii obrázek, který jsem před dvanácti lety vzal z něčího podpisu. Má to být chlápek z obalu jedné z edicí Stopařova průvodce po galaxii od Douglase Adamse. Nepropadejte panice! :-)
David Miller, zpráva ze 6. února 2008 na Linux kernel mailing list
9. únor, originál
I když tento den je pravděpodobně jeden z posledních dní začleňovacího okna, zvaž prosím ještě přetažení gitového stromu 'kgdb light', psal Ingo Molnár.
Tohle je zeštíhlená a pročištěná verze KGDB, kterou jsem vytvořil z původních patchů poslaných před dvěma týdny. S Thomasem jsme patche prošli, vyhodili jsme všechno, co se nám nelíbilo, a pročistili zbytek. KGDB je stále stejně funkční, jako bylo předtím (testoval jsem to na 32-bit i 64-bit x86) a jakékoliv schopnosti či problematičtější záležitosti navíc by měly být přidány jako rozdílová vylepšení, nikoliv v tomto počátečním začlenění.
Ingo poznamenal, že předchozí verze modifikovala 41 souborů, kdežto tento nový požadavek jich mění pouze 22. Ze změn upozornil zvláště na tyto:
Ingo to shrnul: Výsledkem je, že série patchů kgdb má zjevně na jádro nulový dopad, protože se prostě nedotýká žádné nebezpečné cesty v kódu [codepath]. Z toho stavu se KGDB může vyvíjet malými, dobře kontrolovanými dětskými krůčky stejně jako ostatní jaderný kód. Výsledné kgdb stále velmi dobře funguje; stále může přerušit běh jádra (pomocí SysRq-G), může zachytit pády, může krokovat atd. Už nyní je to použitelný první krok.
Když budeš pozorně naslouchat, uslyšíš tucty vývojářů linuxového jádra, kteří kolektivně zadržují dech a myslí si 'Možná Linus konečně začlení kgdb'. Ano, hlášení o chybách od uživatelů jsou důležitá. Efektivita vývojářů je důležitá také.
Daniel Phillips, zpráva ze 7. února 2008 na Linux kernel mailing list
10. únor, originál
Ok, tohle je pekelně velký -rc (ostatně, to byl i 24-rc1), pravděpodobně protože vývojový cyklus 2.6.24 se protáhl, takže lidé měli připravenou spoustu věcí, psal Linus Torvalds v oznámení jádra 2.6.25-rc1, kompletní diff je asi 11 MB velký a má 1,4 M lišících se řádek, z čehož většina jsou aktualizace architektur a ovladače.
Abych se trochu pobavil, udělal jsem jednoduché statistiky - z 1,4 M řádek je okolo 38 % - 530k řádek - v souborech týkajících se architektur (400k+ řádek v arch/, 100k+ řádek v include/asm-*). Další velký shluk je v ovladačích (včetně zvuku), má podíl 44 % - 610k řádek - změn. Zbytek je mnohem menší, viditelnější je ještě síťování (8 % - 110k řádek), souborové systémy se 4 % a dokumentace 2 %. Zbylé drobty jsou rozházeny hlavně v blokové vrstvě, crypto, jádře jádra [kernel core] a aktualizaci bezpečnostní vrstvy (tj. SElinux a smack). Linus upozornil na některé změny:
Nebo bychom mohli napsat nejošklivější patch v historii, tedy
-#define pcibus_to_node(node) (-1) +#define pcibus_to_node(node) ((int)(long)(node),-1)
Wow. To je tak ošklivé, že to skoro přetéká, přechází na druhou stranu a vypadá hezky.
Linus Torvalds, zpráva z 11. února 2008 na Linux kernel mailing list
11. únor, originál
Patche pro chybu jádra Linuxu, která umožňovala lokálně získat práva roota, byly dnes vydány jako 2.6.24.2, 2.6.23.16 a 2.6.22.18. Nejnovější chyba značená jako CVE-2008-0600 byla do jádra 2.6 zanesena ve verzi 2.6.17 se systémovým voláním vmsplice(). Je to již třetí v sérii chyb umožňujících získání roota, které se tohoto systémového volání týkají. Dvě dřívější byly označeny CVE-2008-0009 a CVE-2008-0010. Pro staré CVE-2008-0010, které se týkalo jader 2.6.23 a 2.6.24, i pro nové CVE-2008-0600 existují snadné způsoby, jak chybu zneužít, což lokálnímu uživateli umožňuje získat oprávnění superuživatele.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
20.2.2008 02:48
Chces-li dobry vykon pro takovou sluzbu (service), musis ji zpravidla nechat bezet (run) z jadre. V uzivatelskem prostoru (userspace) muzes treba hrat, ale je blbost si myslet, ze to pujde stejne dobre (vykonne) jako bys to delal v jadre. A totalni blbost je myslet si, ze mmap() vyresi problemy vykonu. "Nerozkopirovane" (zero-copy) se nerovna "rychle". Rychlosti pameti muzou byt mensi nez rychlosti procesorovych jader ALU (core CPU speeds), ale ne tak ohromne.
Omlouvam se za nepresnosti, ale u par slov a vyrazu me nenapadla zadna lepsi ceska alternativa :/
A snazil jsme se smysl uprednostit nad doslovnou presnosti, napr. o "but not infinitely so!" si nemyslim ze znamena "ale ne nekonecne", ale "ale ne tak ohromne" nebo tak 
20.2.2008 08:15
michich | skóre: 51
| blog: ohrivane_parky
"but not infinitely so!" by se pak prekladalo "ale ne tak nekonecne!"Tam není "but not so infinitely", ale "but not infinitely so". To znamená něco jiného. Time is an illusion. Lunchtime doubly so. -- Douglas Adams
Chces-li dobry vykon pro takovou sluzbu (service), musis ji zpravidla nechat bezet (run) z jadre.Až na řídké výjimky překládám jenom to, co je přímo na kerneltrapu (na hlavní straně), takže proto tahle věta chybí.
V uzivatelskem prostoru (userspace) muzes treba hrat, ale je blbost si myslet, ze to pujde stejne dobre (vykonne) jako bys to delal v jadre.Podle mě to "as well" v tomhle případě neznamená "stejně dobře", ale spíš "stejně tak" nebo něco podobného. Tedy v userspace můžeš něco dělat, ale pleteš se, pokud si myslíš, že můžeš stejně tak (as well) činit v jádře.
"Nerozkopirovane" (zero-copy) se nerovna "rychle".Řekl bych, že bez kopírování je pro zero-copy lepší překlad, než nerozkopírované. Mj. proto se v podobných případech (už delší dobu, jako kompromis) nechává i anglický termín - aby lidi místo stěžování si, že je to špatně přeložené, mohli nabídnout ustálený český překlad, pokud existuje.
rychlosti procesorovych jader ALU (core CPU speeds)Tenhle překlad je hodně nepřesný a podle mě i nesmyslný.
A snazil jsme se smysl uprednostit nad doslovnou presnostiJá ne. U článků se snažím vystihnout význam a dovolím si nějaké ty nepřesnosti, ale jestliže je to citát, tak ho překládám co nejvíc doslova tak, aby to v češtině ještě dávalo smysl. Chci, aby z citátů bylo znát, jakým způsobem se lidé, kteří tvoří jádro, vyjadřují. I za cenu, že to zní trochu neobvykle. Zvykejte si.
Podle mě to "as well" v tomhle případě neznamená "stejně dobře", ale spíš "stejně tak" nebo něco podobného. Tedy v userspace můžeš něco dělat, ale pleteš se, pokud si myslíš, že můžeš stejně tak (as well) činit v jádře.Obecne mas pravdu, ale podle kontextu soudim, ze se v tomto pripade jedna o vykon.
Řekl bych, že bez kopírování je pro zero-copy lepší překlad, než nerozkopírované. Mj. proto se v podobných případech (už delší dobu, jako kompromis) nechává i anglický termín ...O tom muzeme polemizovat do nekonecna a oba budeme mit pravdu. Uznavam ze nejlepsi reseni je proste napsat zero-copy. Vsichni vime co to znamena a nebudem se hadat ...
rychlosti procesorovych jader ALU (core CPU speeds) => Tenhle překlad je hodně nepřesný a podle mě i nesmyslný.To mas pravdu, sorry, to mi ujelo. Napsal jsem "rychlosti ALU", pak mi doslo ze je to kravina, chtel jsem to prepsat na "rychlosti procesorovych jader" a to "ALU" mi tam zustalo :/ Na mysli sem mel "rychlosti procesorovych jader" jako takovych, ne jen ALU (pak to smysl dava).
A snazil jsme se smysl uprednostit nad doslovnou presnosti => Já ne. U článků se snažím vystihnout význam a dovolím si nějaké ty nepřesnosti ...V tom pripade muzem mit oba pravdu a presto se nikdy neshodnem
Uznavam ze nejlepsi reseni je proste napsat zero-copy. Vsichni vime co to znamena a nebudem se hadat ...Nejlepší řešení není prostě napsat zero-copy, protože by se někdo ozval, že by se anglické termíny měly překládat... už se to několikrát stalo, proto je tam obojí.
[ 0.982046] \|/ ____ \|/ [ 0.982054] "@'/ .. \`@" [ 0.982058] /_| \__/ |_\ [ 0.982063] \__U_/tieto jderne noviny mi pripadaju ako keby som nahodne zobral daky text a prelozil iba polovicu, a potom polovicu dal sem ,nema to ani hlavu ani petu.
20.2.2008 04:02
