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.
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.
Následující obsah je © KernelTrap.
Na kód se dívám, zjevně protože nejsem dostatečně optimistický táta. Ale hej, kdybyste měli tři předpubertální holky, možná byste také nebyli tak optimističtí.
Linus Torvalds, zpráva z 21. července 2008 na Linux kernel mailing list.
22. července, originál
V nedávném vlákně se na lkml diskutoval zápis v blogu, který tvrdil, že minimální podpora pro ZFS v GRUBu je k dispozici pod licencí GPL. Teď bychom ten kód mohli použít k implementování podpory pro ZFS v linuxovém jádře.
Alan Cox ale řekl: Ne, nemůžeme. Ty kousky ZFS, které jsou pod GPL, nezahrnují různé metody, které by porušily patent, takže to nepůjde. Několikrát jsem žádal Sun, aby nám dali povolení, a oni mi ani neodpověděli. Vidím u Sunu jenom jednu možnou motivaci - chtějí vypadat otevřeně, ale ví, že ZFS je jediná věc, která by mohla Solaris zachránit jako produkt, který je nasazován v datacentrech, takže nejsou připraveni nechat Linux ho používat. H. Peter Anvin dodal: Z toho, co vidím, se jedná o absolutně minimální implementaci pouze pro čtení.
Christoph Hellwig se přidal: Přidání ovladače pro čtení ZFS do Linuxu by bylo z různých důvodů užitečné. A přidávání souborových systémů, které jsou pouze pro čtení, je v Linuxu skutečně snadné. S odkazem na člověka, který diskuzi začal, dodal: Jestliže o to Fred má skutečný zájem, rád mu poradím s implementací. Pro něj by to mohlo být velmi dobré cvičení, ve kterém se něco naučí.
Když byl dotázán, jestli se ta nabídka vztahuje i na někoho dalšího, Christoph odpověděl: Samozřejmě, tato nabídka platí pro každého, kdo má zájem. Ale není to čistě jenom snaha o integraci v tradičním smyslu. Rozhraní souborového systému v grubu je dost odlišné od toho, které je v Linuxu, a struktura kódu i styl jsou hodně odlišné. Nicméně, jestli se chcete něco naučit, mělo by to být velmi zajímavé.
Wow. 6924d1ab8b7bbe5ab416713f5701b3316b2df85b je umělecké dílo. Je to tetris v ascii-art? Obrázek magického oka? Rozhodněte vy! V gitk vypadá dokonce ještě efektněji.
Dave Jones, zpráva z 15. července 2008 na Linux kernel mailing list.
25. července, originál
Zdá se, že se poslední dobou všichni baví tvorbou nových souborových systémů, tak jsem si říkal, že se přidám, začal Daniel Phillips oznámení verzovacího souborového systému Tux3. Tux3 je verzovací souborový systém založený na b-stromech, s libovolným zápisem [write anywhere] a atomickými commity. Částí této práce je revize starobylého HTree designu použitého v Ext3 a Lustre tak, aby lépe podporoval NFS a možná byl i efektivnější.
Hlavním účelem Tux3 je obsahovat moje nové nápady o verzování dat v úložišti. Druhým cílem je poskytnout efektivnější metody vytváření snapshotů a replikace pro Zumastor NAS projekt a třetím je být lepší než ZFS.
Ve svém emailu s oznámením Daniel poznamenal, že práce na implementaci probíhá, mnoho z práce sestává z kopírování a vkládání kousků kódu, který jsem vyvinul během let, například kousků z HTree a ddsnap. Momentálním cílem je vytvořit funkční prototyp, který funguje jednoduše, například s ukazateli na bloky místo rozsahů, bitmapou alokace místo stromu volných rozsahů, lineárního prohledávání místo indexovaného a úplně bez atomických commitů. Jen takový, který by ověřil verzovací algoritmy a vyvinul nová uživatelská rozhraní pro správu verzí.
Tyjo ty jsi náročný! Kdyby byl každý jako ty, nepotřebovali bychom ten hezký kód na vypisování oopsů.
Andrew Morton, zpráva ze 7. července 2008 na Linux kernel mailing list.
29. července, originál
Je to dva týdny (a jeden den) a začleňovací okno končí, začal Linus Torvalds oznámení jádra 2.6.27-rc1. Konečně. Nevím proč, ale tohle se mi zdálo dost rušné. A velikost patche k -rc1 to potvrzuje - při 12 MB je přibližně o 50 % větší než 26-rc1 (ale ne o tolik větší než 24/25-rc1, takže nejde o nic neslýchaného). Nad tím zauvažoval: Samotná velikost jednotlivých -rc mě poněkud znervózňuje. Jasně, znamená to, že jsme dobří a podařilo se nám to všechno sloučit, ale musím říct, že se občas zamýšlím nad tím, jestli toho nezačleňujeme příliš mnoho naráz a jestli dokonce i náš současný (vcelku krátký) vývojový cyklus není ve skutečnosti příliš dlouhý.
Co se samotných změn týče, Linus shrnul: Mnoho z -rc1 bylo v linux-next, ale rozhodně ne všechno. Uvidíme, jak se celá ta věc vyvine - určitě nevyřešila všechny problémy a objevilo se nějaké hašteření o věcech, které tam nebyly (a o některých, které tam většinou byly ;-), ale [linux-next] možná pomohl. Objevila se spousta nových záležitostí, ale osobně si myslím, že zajímavé věci jsou vytlačování BKL a bezzámková get_user_pages_fast(). Překladový systém byl zaktualizován, což umožňuje přesunout include soubory architektur ('include/asm-xyz') do podadresářů architektur ('arch/xyz/include/asm'), a zdá se, že sparc toho již využil.
Mezi další změny, které Linus zdůraznil, patří začlenění souborového systému UBI stejně jako sledování [tracing], nahrávání firmwaru, pokračující slučování architektury x86 a přesouvání více kódu do obecné podpory (unifikované obecné IPI řízení [unified generic IPI handling], koherentní alokace dma paměti, show_mem atd.) Přepsání bootmem. A nějaká podpora pro další škálovatelnost (tj. 4k cpu jader.)
Jestliže ten, kdo nahlásil chybu, neodpoví a neřekne 'je to stále otevřené', je potřeba to uzavřít. Ani trochu nezáleží na tom, jestli se tím zabýval některý z vývojářů nebo ne. Nemůžeme nechávat stará hlášení otevřená - pro vývojáře je totální ztráta času dokonce i podívat se na cokoliv, co je víc než přibližně měsíc staré a není potvrzeno, že je to stále problém.
Linus Torvalds, zpráva ze 6. července 2008 na Linux kernel mailing list.
5. srpna, originál
Myslím si, že 'next' tak, jak je, má pár problémů a ty je potřeba buď opravit (nepravděpodobné - to je účel next), nebo se musí vyhlásit, že jsou to problémy a pochopit to psal Linus Torvalds o vývojovém stromu linux-next, který byl původně založen jako způsob, jak více zapojit správce subsystémů do řešení konfliktů při začleňování. Nemyslím si, že by kdokoliv chtěl, aby zmizel. Otázka, kterou mám na mysli, je, jak/jestli by se měl změnit. Objevily se nějaké hádky o patchích, které v něm nebyly, a nějaké o částečných sériích, které v něm byly, ale dokončovací práce věci rozbily.
Vyjmenoval své hlavní obavy: Nemyslím si, že dělá 'kontrolu kvality' a o té si myslím, že je poměrně zásadní a Nemyslím si, že ta 'next' věc funguje stejně dobře pro občasného vývojáře, který má ve frontě pár patchů, jako pro správce subsystému, který je na ni zvyklý. Ani jedno z výše uvedených nepovažuji za 'problém' - prostě myslím, že by se obojí mělo vzít na vědomí. Myslím si, že 'next' je pro velké vývojáře subsystémů dobrý způsob, jak včas objevit problémy, ale skutečně doufám, že ho nikdy nikdo nebude považovat za 'tohle je cesta do Linusova stromu', protože z uvedených důvodů si nemyslím, že by tak mohl fungovat.
Andrew Morton poznamenal, že spousta chyb, které zasáhly tvůj strom, by se v linux-next objevily stejně rychle. Pak dodal: To je ale jenom šoupání lehátky. Začleňujeme díky tomu kód lépe? Jsme opatrnější, lépe revidujeme a lépe testujeme? Neřekl bych.
Moje rada pro tebe by byla: najdi si připomínky, které v té době měli revidovatelé, a ujisti se, že na ně bylo reagováno. Pak znovu zažádej o revizi kódu a slib, že nebudeš nadávat a urážet na cti a napadat motivy revidovatelů, jako to dělal Hans.
Theodore Ts'o, zpráva z 1. srpna 2008 na Linux kernel mailing list.
6. srpna, originál
Musel jsem aplikovat patche reiser4 z -mm jader do sady patchů založené na vanille více než rok. Reiser4 funguje dobře, co je potřeba k tomu, aby se dostal do vanilly? začínalo krátké vlákno v mailové konferenci Linux Kernel. Theodore Ts'o nabídl několik odkazů, které detailněji rozebíraly zbývající problémy s Reiser4, pak navrhl: Lidé, kterým se opravdu líbí reiser4, by se mohli chtít podívat na btrfs; má mnoho stejných nápadů v designu, jako měl reiser3/4 --- kromě toho, že (a) formát souborového systému má podporu pro některé pokročilé vlastnosti, které jsou určené k předstižení ZFS, (b) správce není blázen a dobře spolupracuje s ostatními vývojáři v LKML (tip zdarma: pokud potřebuješ, aby byl tvůj kód revidován, aby se dostal dovnitř, a revidovatelů je nedostatek; neurážej a nenadávej revidujícím dobrovolníkům, jako to dělal Hans --- to není dobrý plán!)
Edward Shishkin poznamenal, že vývoj Reiser4 pokračuje: Pracuji na dokumentu o designu pluginů. Hotov bude přibližně v září. Věřím, že zareaguje na všechny zmíněné stížnosti. Tento dokument definuje pluginy a primitiva (jako je konverze objektu v čase běhu), které reiser4 používá, a popisuje všechna rozhraní reiser4, takže bude jasné, že funkce VFS není duplikována, v reiser4 nejsou VFS vrstvy atd.
Hans Reiser, původní vývojář souborového systému Reiser4, byl 28. dubna odsouzen za vraždu prvního stupně. Nejnovější patche Reiser4 v současnosti žijí na kernel.org, stejně jako potřebné podpůrné programy.
Citát: Hash, ne modlitbu
Tohle potřebuje práci s hashováním, ne modlitbu '32 slotů je dost'.
Alan Cox, zpráva z 3. srpna 2008 na Linux kernel mailing list.
7. srpna, originál
Tak od -rc1 to byl týden a -rc2 je venku, začal Linus Torvalds oznámení jádra 2.6.27-rc2. Napsal k němu: Je v něm spousta náhodných změn a doufám, že se začínáme uklidňovat, ale určitý druh náhodné změny pravděpodobně stojí za to, abych na něj explicitně ukázal kvůli věcem, ve které může vyústit: jde o fakt, že mnoho architektur využilo období klidu po -rc1 (hah!) k přejmenování 'include/asm-xyz' => 'arch/xyz/include/asm' Linus vysvětlil, že lidé, kteří aktivně vyvíjejí a začleňují kód gitem, by měli dávat pozor na to, že nedávno bylo více přejmenování, než je výchozí limit detekce přejmenování v gitu, takže pokud to někomu způsobí konflikt přejmenování<->změna dat, možná by měl výchozí limit zvýšit.
Linus poznamenal, že vývojáři s dostatkem RAM mohou nastavit renamelimit=0 a limit zcela vypnout a ostatní ho mohou nastavit na vysokou hodnotu, jako je 5 000. Výchozí limit je docela nízký, aby nezpůsobil problémy lidem, kteří mají ve svých strojích méně paměti, než mívají jaderní vývojáři...
Linus pokračoval: Dirstat (se zapnutou detekcí přejmenování, aby se přesuny nezobrazily jako velké změny) je vcelku obvyklý, většina změn je v ovladačích společně s ext4 a xfs aktualizacemi, díky kterým vyčnívají dost vysoko i 'fs'.
Zkrácený log je příliš velký na to, abych ho sem dával (opět jako obvykle - obvykle zkrácené logy zasílám pro -rc3 a další, když už se to dá zvládnout), ale dovolte mi o něm říci, že není zase až tak zajímavý. Je v něm spousta malých změn, ale nic, co by vás přinutilo říct 'Wow!' Samozřejmě, ne že by něco takového v -rc2 mělo být, takže si nestěžuji.
Takže ty nás zkoušíš donutit začlenit něco do linuxového jádra kvůli bezpečnostním nedostatkům zcela jiného operačního systému? Tenhle argument si možná chceš rozmyslet.
Greg KH, zpráva z 5. srpna 2008 na Linux kernel mailing list.
7. srpna, originál
Velká výhoda, kterou má Hammer oproti Tux3, je to, že funguje a je vydáván v distru Dragonfly, začal Daniel Phillips a nabídl srovnání mezi těmito dvěma souborovými systémy. Největší nevýhoda je, že běží na BSD, ne na Linuxu, a tak implementuje hodně funkcí, které v Linuxu poskytuje VFS a bloková vrstva, díky čemuž by port na Linux byl všechno jen ne triviální. Nakonec k tomu pravděpodobně dojde, ale možná bude tou dobou Tux3 hotový a stabilní. To vedlo k dlouhé a zajímavé technické diskuzi mezi Danielem a autorem HAMMERu Matthewem Dillonem, ve které se design obou souborových systémů porovnával.
Matthew prošel zápisy o Tux3 a odpověděl: Vypadá to, že Tux3 používá mnoho podobných nápadů jako HAMMER. Myslím si, že jsi na správné cestě. Přidám jedno velké varování, které pochází z mé zkušenosti při implementaci HAMMERu, protože si myslím, že narazíš na stejné problémy. Strávil jsem 9 měsíců návrhem HAMMERu a 9 měsíců jeho implementací. Během implementace jsem vyházel asi 80 % původního návrhu. Daniel poznamenal, že na designu Tux3 pracuje kolem deseti let a poslední tři roky nebo tak vážně pracuji na zjednodušujících prvcích buď úplně na papíře, nebo v související práci, jako je ddsnap a LVM3.
Matthew ho varoval: Můžu říct, že jsi o Tux přemýšlel docela dlouho. Kdybych měl nějakou obavu, co se implementace týče, bylo by to o algoritmické složitosti. Musíš se vypořádat s cache v paměti, logem, B-stromem plus sekundárním indexováním zachycených [snapshotted] prvků a tunou zvláštních případů úplně všude. Tvůj obecný vyhledávací kód bude velmi, velmi komplexní. Můj původní návrh pro HAMMER byl o mnoho komplexnější (pokud tomu uvěříš!) než konečný výsledek. Velká část toho, co jsem musel udělat při přechodu mezi konceptem a skutečností, bylo tuto komplexitu hodně omezit. Přátelský rozhovor nabízí velmi detailní pohled na rozhodnutí při návrhu, která byla v každém z těchto souborových systémů udělána.
Možná bychom měli Andrewovi ve zdrojácích jádra změnit jméno na Adrew Norom, to by také mohlo ušetřit pár bytů.
Russell King, zpráva z 10. července 2008 na Linux kernel mailing list.
8. srpna, originál
Btrfs v0.16 je k dispozici ke stažení začal Chris Mason oznámení nejnovějšího vydání svého souborového systému Btrfs. v0.16 má nový nablýskaný diskový formát a není kompatibilní se souborovými systémy vytvořenými staršími vydáními Btrfs. Ale měl by to být doteď nejrychlejší Btrfs se spoustou oprav škálovatelnosti a novými vlastnostmi.
Vylepšení škálovatelnosti a výkonnosti zahrnují jemné zamykání b-stromů, vytlačení operací náročných na CPU, jako je počítání kontrolních součtů, do vlastních vláken na pozadí, vylepšený režim data=ordered a nová cache, která redukuje IO požadavky, když se pročišťují staré transakce. Další nové vlastnosti zahrnují podporu ACL, prevenci opuštěných [orphaned] inodů, takže se soubory po pádu neztratí, a robustnější formát indexu adresářů.
Chris psal: Stále jsou v plánu další změny formátu, ale snažíme se dostat je z cesty tak rychle, jak můžeme. Na časové ose vývoje můžete vidět velké vlastnosti, které máme v plánu. [...] Jaderný modul btrfs má nyní 30 000 řádek kódu, což znamená, že se dostáváme velmi blízko k velikosti ext[34].
Výchozí hodnota by měla být 'vypnuto', pokud ji lidé nepotřebují mít zapnutou. Podívali jste se, pánové, v poslední době na velikost jádra? Bloatware je bloatware. To, že je to něčím podmíněné, není omluva.
Linus Torvalds, zpráva z 14. července 2008 na Linux kernel mailing list.
9. srpna, originál
Mikuláš Patočka oznámil nové patche zavádějící slučování snapshotů pro linuxového správce logických svazků. Slučování snapshotů umožňuje začlenit obsah snapshotu zpět na původní zařízení. Nejužitečnějším použitím je možnost převinout stav celého počítače po selhání aktualizace balíčku nebo chybě administrátora. Patche jsou pro jádro 2.6.26 s device mapperem 1.02.27 a LVM2.2.02.39.
Mikuláš psal, že jsou podporovány tři typy slučování - --nameorigin, --namesnaphost a --onactivate. Výchozí začleňovací metoda je --nameorigin, které začleňuje snapshot na původní svazek, který lze připojit kdykoliv poté, co začleňování začne. Metoda --namesnapshot začleňuje do snapshotu, který lze poté připojit. Metoda --onactivace naplánuje začlenění na příští aktivaci svazku - například po rebootu. Mikuláš poznamenal: Tato implementace slučování snapshotů je míněna jako stabilní, možné chyby mi hlaste.
Momentálně nevíme o žádných chybách, ale jsem si jistý, že to se změní, až ten souborový systém začne více uživatelů DragonFly používat :-).
Matthew Dillon, zpráva z 8. srpna 2008 na DragonFly BSD kernel mailing list.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Možná bychom měli Andrewovi ve zdrojácích jádra změnit jméno na Adrew Norom, to by také mohlo ušetřit pár bytů.
Zajímavé, že nepoužil rovnou Moron, když se to tak nabízelo.
26.8.2008 00:46
frEon | skóre: 40
| Praha
26.8.2008 01:03
Kamil Páral | skóre: 13
| blog: Kamil Páral
| Brno
"Citát: Tento argument si možná chceš rozmyslet"Pripsano Gregovi KH, ktery ale citoval Jonathana Presse.
CZ "v0.16 má lesklý nový diskový formát" EN "v0.16 has a shiny new disk format"Uh?
26.8.2008 02:18
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Pripsano Gregovi KH, ktery ale citoval Jonathana Presse.Možná mi něco nedochází, ale nemám ten dojem.
CZ "v0.16 má lesklý nový diskový formát"Změnil jsem na nový nablýskaný.
Změnil jsem na nový nablýskaný.A důvod?
26.8.2008 14:20
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
26.8.2008 15:06
herne the hunter | skóre: 10
| tor lara
26.8.2008 15:20
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
lesklý nový mi připadá, že se k tomu nehodí. Ty bys to snad v takové situaci řekl?Ano, proto jsem to tak přeložil. Jsem jednoznačně pro to, aby se v článku opravovaly chyby. Ale to, že se opravuje něco, co není chyba (aspoň podle mě ne), to už se mi moc nelíbí.
26.8.2008 23:39
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Žádná hrubá chyba to není, ale jen (nám) to zní líp. A o to jde, aby se to lidem četlo dobře.
Hlavním účelem Tux3 je obsahovat moje nové nápady o verzování dat v úložišti.
Asi by bylo alespoň trošičku lepší něco ve stylu (ne, že bych tomu až tak moc rozuměl):
Tux3 především obsahuje moje nové nápady týkající se verzování dat v úložišti.
26.8.2008 07:40
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
26.8.2008 15:02
David Watzke | skóre: 74
| blog: Blog...
| Praha
26.8.2008 17:06
default | skóre: 22
| Madrid
Matthew prošel zápisy o Tux3 a odpověděl: Vypadá to, že Tux3 používá mnoho podobných nápadů jako HAMMER. Myslím jsi, že jsi na správné cestě.…Myslím si…
Vlákno bylo přesunuto do samostatné diskuse.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz