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.
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ů.
12. črc - 21. črc
Linus Torvalds oznámil Linux 2.6.13-rc3 a Lee Revell poznamenal: Výchozí hodnota Hz je pořád 250. Jak už bylo vysvětleno v jiném vláknu, způsobí to, že některé aplikace, např. MIDI sekvencery, nebudou fungovat, ale žádné velké ušetření energie baterií to nepřinese. Dokud nejsou tyhle problémy vyřešeny, měla by být výchozí hodnota 1000. Ale Linus odpověděl:
Přestaň s tím už otravovat. Já tu diskuzi viděl a naprosto nesouhlasím s tím, že by "to tam bylo vysvětleno". To prostě není pravda.
Pravda je pouze to, že 100Hz je pro některé účely příliš málo a 1000Hz je pro některé účely příliš moc. NIKDO nedemonstroval, že by 250Hz nebylo v pořádku. Lidi si jen stěžovali a kňourali, že to možná není v pořádku.
Faktem je, že programování je o nacházení řešení, které funguje "dostatečně dobře". Pokud si _ty_ myslíš, že 1000Hz je správná odpověď, pak si to tak _ty_ nastav. Ale pokud nedokážeš pochopit skutečnost, že jiní lidé mají jiné názory, proč by s tebou o tom měl někdo diskutovat?
Tohle je základní fakt programování (a vlastně jakékoliv jiné oblasti života):
Nedokážeš-li uznat, že jiní lidé mají jiné cíle a potřeby než ty, pak proč se s ostatními lidmi vůbec bavíš?
Takže to nechte být. Uvědomte si, že pro Hz neexistuje "perfektní" hodnota. 250 je teď právě docela rozumné, a máš-li extrémní potřeby, můžeš vždy zvolit svou vlastní hodnotu. Nenuť však své představy ostatním.
A mimochodem, až si někdo bude příště stěžovat ohledně Hz, budu chtít OPRAVDOVÁ DATA. Nechci kňourání. Přestaňte mě dávat do CC, nemáte-li skutečná data a neumíte-li pochopit, že jiní lidé mají _jiná_ skutečná data.
Lee odpověděl: OK, pochopil jsem. S tímhle problémem jsem v LKML skončil. Pokud o tom chce někdo dále diskutovat, pojďte do konference linux-audio-dev.
14. črc - 15. črc
Kenneth W. Chen napsal:
S radostí oznamuji, že jsme založili projekt pro sledování výkonu jádra hostovaný na sourceforge.net:
http://kernel-perf.sourceforge.net
V LKML se mnohokrát diskutovalo o tom, že linuxové jádro potřebuje systematický a disciplinovaný způsob, jak pravidelně měřit a sledovat jeho výkonnost. Abychom toho dosáhli, rozhodli jsme se pravidelně provádět rozsáhlou sadu benchmarků, které pokrývají základní komponenty jádra (správa virtuální paměti, I/O subsystém, plánovač procesů, souborový systém, síť, ovladače zařízení atd.). Benchmarky jsou spouštěny každý týden na různých platformách (4P Intel Xeon procesor, 2P Xeon, několik serverových strojů ia64 atd.) a měří poslední snapshoty Linusova git stromu. Souhrnná data o výkonu v našich testech budou vydávána tak, aby k nim byl snadný přístup.
Naším cílem je pracovat s linuxovou komunitou na zvyšování výkonnosti jádra. Data dostupná na našich stránkách umožňují členům komunity sledovat zlepšení a zhoršení výkonu u každé verze jádra.
Andi Kleen odpověděl:
Tohle je výborné. Díky moc.
Bylo by možné do grafů pro porovnání přidat i údaje o 2.4.30 a případně i o jednom nebo dvou distribučních jádrech (dejme tomu RHEL3/4, SLES8/9)? Jsou to velmi vyladěná jádra a ukázalo by se tak, kde za nimi hlavní jádro zaostává.
A spouštěli jste netperf? Lokálně nebo k jinému stroji? Asi by to bylo dobré zdokumentovat.
Také by bylo fajn mít nějaké oprofile výpisy z pár testovacích průběhů.
Kenneth odpověděl, že pro hlavní jádra se rozhodli kvůli konzistenci, ale zkusí přidat i distribuční. Ohledně netperf Kenneth potvrdil, že byl spouštěn lokálně, a že to uvede v dokumentaci. O výpisech oprofile Kenneth řekl: Na tom se pracuje. Profilová data budeme uploadovat. S oprofile mám u některých verzí jádra problém, který se právě teď řeší. Andi reagoval Pokud používáte staticky zkompilovaná jádra, můžete klidně použít i starý readprofile. Jen nefunguje s moduly. A Randy Dunlap připojil: Lze zařídit, aby fungoval i s moduly (šlo to s 2.6.6), ale kdybych měl na výběr, tak bych prostě moduly nepoužíval.
15. črc
Jeff Garzik napsal:
Aktualizoval jsem svého průvodce pro rychlý začátek s gitem:
http://linux.yyz.us/git-howto.htmlOdkazuje teď na každodenní snapshoty pro počáteční nahození [bootstrapping] od DaveJ a je lépe organizovaný pro snadnější navigaci.
A bonusový návod: jak importovat Linusovy pack [balík] soubory (je to snadné).
Tento návod předpokládá, že máte repozitář s vanilla jádrem od Linuse (/repo/linux-2.6) a svůj vlastní repozitář (/repo/myrepo-2.6).
$ cd /repo/myrepo-2.6 $ git-fsck-cache # fsck, ujisti se, že jsme v pořádku $ git pull /repo/linux-2.6/.git # ujisti se, že jsme aktualizovaní $ cp -al ../linux-2.6/.git/objects/pack .git/objects $ cp ../linux-2.6/.git/refs/tags/* .git/refs/tags $ git-prune-packed $ git-fsck-cache # fsck č. 2, ujisti se, že jsme v pořádku
Tento postup zmenšil mojí synchronizaci s kernel.org z nějakých 50 000 na 5 000 souborů.
18. črc - 19. črc
Někdo se zeptal, jak se stát vývojářem jádra, a několik lidí poskytlo své rady. Jesper Juhl napsal:
Pár věcí, které bys měl udělat:
A v dalším emailu doplnil:
Pomoci můžeš také testováním vývojových jader - potřebují otestovat co nejvíce lidmi. Začni testováním -rc jader, každodenních git snapshotů a také -mm jader. Vyzkoušej, jestli se zkompilují s tvou běžnou konfigurací, s "allnoconfig", "allyesconfig", "allmodconfig" a třeba s pár náhodnými konfiguracemi. Zjisti, jestli v pořádku nabootují, jestli mohou bez problému delší dobu běžet atd.
Když narazíš na problém, můžeš ho zkusit sám opravit a poslat patch do konference a osobě, která za daný kód odpovídá. Pokud problém neumíš opravit, pošli do konference a osobě odpovědné za kód podrobné hlášení o chybě. Podívej se na soubory REPORTING-BUGS a Documentation/BUG-HUNTING.
Brian O'Mahoney souhlasil s Jesperovými radami, ale připojil, že testování a vývoj jádra by se neměl dělat na "hlavním počítači". A pokud ano, tak je třeba neustále zálohovat. Kromě toho upozornil, že pro používání nástrojů jako kdb, kgdb a kprobe je potřeba sestava dvou počítačů.
18. črc
Mezi diskuzemi o odstranění DevFS z jádra se poprvé po letech na krátko objevil původní autor DevFS, Richard Gooch. Stručně reagoval na některé výroky Grega KH.
Greg prohlásil, že Richard uznal udev jako správnou náhradu za DevFS. Richard odpověděl: Tak to je pro mě novinka!
Greg také řekl, že DevFS by mělo být odstraněno, protože postupy [policy] by měly být implementovány v uživatelském prostředí, ne v jádře. Richard poukázal na to, že SysFS, které z velké části vyvinul Greg, také implementuje postupy v jádře.
Na Gregův názor, že DevFS je nepořádek a zmatek, Richard řekl, že to záleží na tom, kdo se dívá.
A na Gregovo tvrzení, že DevFS nefunguje a nelze opravit, Richard prostě odpověděl: Žádný důkaz. Nikdy neříkej nikdy...
Jan Engelhardt se zeptal, kde byl Richard celé ty roky, očekával-li že bude DevFS spravováno a zachováno v jádře. Daniel Phillips odpověděl, že ho vyhnal svými neúnavnými útoky Alexander Viro.
V originálu Kernel Traffic 320 vyšla navíc ještě tato témata:
Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: