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.
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.
25. dub - 4. kvě
Matt Mackall napsal:
Tímto oznamují aktualizovanou verzi Mercurialu. Mercurial je rychlý, škálovatelný, distribuovaný SCM, který funguje na podobném modelu jako BK a Monotone. Má funkční podporu klonování/větvení [clone/branch] a stahování/slučování [pull/merge]. Funkční je i první pokus o implementaci síťového stahování. Nástroj je velmi malý a lze snadno upravovat: má kolem 1000 řádků kódu.
Tohle jsou výsledky při přidávání [checking in] prvních 12 vydání Linuxu 2.6 do prázdných repozitářů Mercurial v0.3 (hg) a git-pasky-0.7. Prováděno na mém notebooku s 512M Pentium M. Časy jsou v sekundách.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
uživ. systém skutečný du -sh
ver souborů hg git hg git hg git hg git
2.6.0 15007 19.949 35.526 3.171 2.264 25.138 87.994 145M 89M
2.6.1 998 5.906 4.018 0.573 0.464 10.267 5.937 146M 99M
2.6.2 2370 9.696 13.051 0.752 0.652 12.970 15.167 150M 117M
2.6.3 1906 10.528 11.509 0.816 0.639 18.406 14.318 152M 135M
2.6.4 3185 11.140 7.380 0.997 0.731 15.265 12.412 156M 158M
2.6.5 2261 10.961 6.939 0.843 0.640 20.564 8.522 158M 177M
2.6.6 2642 11.803 10.043 0.870 0.678 22.360 11.515 162M 197M
2.6.7 3772 18.411 15.243 1.189 0.915 32.397 21.498 165M 227M
2.6.8 4604 20.922 16.054 1.406 1.041 39.622 25.056 172M 262M
2.6.9 4712 19.306 12.145 1.421 1.102 35.663 24.958 179M 297M
2.6.10 5384 23.022 18.154 1.393 1.182 40.947 32.085 186M 338M
2.6.11 5662 27.211 19.138 1.791 1.253 42.605 31.902 193M 379M
tar adresáře .hg/ 108175360
tar adresáře .git/ 209385920
Celý strom: stav změn (žádné změny):
hg: skut. 0.799s uživ. 0.607s sys 0.167s
git: skut. 0.124s uživ. 0.051s sys 0.051s
Čas stažení [check out] (2.6.0):
hg: skut. 34.084s uživ. 4.069s sys 2.024s
git: skut. 30.487s uživ. 2.393s sys 1.007s
Celý strom: diff pracovního adresáře (2.6.0 základ
a 2.6.1 v pracovním adresáři):
hg: skut. 4.920s uživ. 4.629s sys 0.260s
git: skut. 3.531s uživ. 1.869s sys 0.862s
(k tomu bylo kromě git commitu potřeba update-cache --refresh,
což trvalo dalších: skut. 2m52.764s uživ. 2.833s sys 1.008s)
Sloučení z 2.6.0 na 2.6.1:
hg: skut. 15.507s uživ. 6.175s sys 0.442s
git: ještě jsem nezjistil, jak na to
Pár poznámek:
Přes to všechno je na tom ve srovnání s gitem dobře jak s rychlostí, tak s úložným prostorem. Kdyby se snížila úroveň zlib komprimace, mohl by pravděpodobně vyhrát na celé čáře.
Více o Mercurialu najdete zde:
Linus Torvalds odpověděl:
Ten čas, který si to vezme při přidávání věcí, mi dělá starosti.
U "gitu" je to v podstatě přímo úměrné velikosti patche. A protože já pracuji většinou s patchi, které se skládají jen z pár souborů, vyhovuje mi to tak. Patche, které přidáváš ty, jsou obrovské - já nikdy nepracuji se změnou, která by byla velká jako celá verze.
Vypadá to, že "hg" je tím pomalejší, čím více patchů aplikuješ. Těžko odhadovat z tak malého množství testů, ale podívej se na čas "uživ." - zvyšuje se z 6 na 27 vteřin.
Chceš-li udělat zajímavý test, zkus aplikovat prvních 200 patchů z aktuálního git archívu jádra. Zvládneš tři za vteřinu? TO je to, pro co bys měl optimalizovat, ne pro přidávání obrovských změn.
27. dub - 1. kvě
Nguyen Anh Quynh napsal:
V současné době není konfigurační rozhraní Filesystem zrovna jednotné:
Posílám patch, který ten problém řeší: přesune konfiguraci XFS z fs/xfs/Kconfig do fs/Kconfig, dá všechny konfigurační volby na stejnou stránku (odstraněním direktivy "menu") a odstraní zbytečný fs/xfs/Kconfig.
Christoph Hellwig odpověděl: To přehození na stejnou stránku je fajn, ale neodstraňuj prosím fs/xfs/Kconfig. Správa je s tím pro nás, kdo se zabýváme XFS, mnohem snazší. Nguyen řekl:
Nechápu, proč bychom měli ve stromu jádra ponechávat nepoužívaný soubor. No, to je jedno. Tady je další patch, který fs/xfs/Kconfig neodstraňuje.
Ale Christoph odpověděl, že nejen soubor by měl zůstat, ale i jeho funkce. Nguyen reagoval: OK, tady je ještě jeden patch. Je na Andrewovi, aby si vybral ten správný. Já však i nadále preferuji ten první, protože zaručuje konzistenci nejen v rozhraní, ale i v konfiguraci.
28. dub - 29. dub
Alan Cox napsal:
Kdysi dávno jsme přidali ovladač ide_default, který se staral o všechny krajní případy, jako falešná [spurious] přerušení [IRQ] u zařízení, které nemělo žádný vhodný ovladač (např. ide-cd bez ovladače CD), a také o ioctl a přístup k souborům.
2.6.12rc jej odstraňuje. Bohužel to také znamená, že máte-li jediné IDE zařízení a konfigurovali jste jej ručně, nemůžete už Linux používat. Mění se i další věci, i když ty asi většině lidí nepřipadají problémové. Už nelze:
Aniž byste měli ovladač speciálně pro dané zařízení - a to funguje pouze tehdy, když už bylo zařízení správně detekováno.
Nemám zrovna teď nástroje, pomocí kterých by šla generovat falešná přerušení u zařízení bez nataženého ovladače, ale vypadá to, že ten kód by mohl klidně havarovat. Podle toho, jak byly změny provedeny, to vypadá, že současní správci IDE nikdy nepochopili, že ide_default existoval kvůli mnoha jiným věcem kromě pročištění ide-proc - také kvůli starání se o přerušení, otevírání prázdných slotů, ioctl a správě napájení.
Bartlomiej Zolnierkiewicz odpověděl: Možná bys měl poslat mail současnému správci, než začneš se šířením FUD, ne? A dodal: Pokud vím, nebyla odebrána žádná funkce, podívej se na patche. Strávil jsem dost času tím, že jsem se snažil zajistit, aby něco nepřestalo fungovat (jedné věci jsem si nevšiml, ale někdo už do LKML poslal patch, který to opravil). Tyto patche byly poslány nejméně dvakrát jak do linux-ide, tak do linux-kernel. Byly v -mm hodně dlouho. Kde jsi se schovával? Připojil, že už se o tom několikrát diskutovalo a ještě dodal: Alane, o co ti jde? Alan se nechal slyšet, že mu jde to, že IDE vrstva se místo zlepšování spíš zhoršuje, což, vezme-li se v potaz počáteční situace, je pozoruhodný výsledek.
Alan pokračoval s kritikou a prohlásil, že pokud to musí takhle vysvětlovat, možná by se o ten kód neměl Bartlomiej starat.
Bartlomiej na to odvětil: Napiš to podrobně, nebo si přestaň stěžovat. Hádka pokračovala a ukončil ji až Bartlomiej, když řekl: Jestli chceš, klidně si vytvoř vlastní verzi [fork], abys plýtval jen svým časem, ne mým.
28. dub - 30. dub
Benjamin LaHaise napsal:
Prohlédněte si, prosím, následující patche, které sjednocují implementaci semaforů na všech architekturách - byly testovány pouze na x86-64. Generovaný kód je funkčně stejný jako dřívější varianta pro i386, ale protože gcc neumí vzít podmínkové kódy jako výsledky, jsou tam vložené dvě další instrukce z obecných atomických operací. Podtrženo sečteno, těch více než 6000 vymazaných řádků kódu zaručuje daleko snazší změny funkčnosti semaforů v budoucnu.
http://www.kvack.org/~bcrl/patches/sem-cleanup-A2/10-rename_semaphore_h.diff
Zavádí linux/semaphore.h. Konvertuje všechny uživatele
asm/semaphore.h na linux/semaphore.h.
http://www.kvack.org/~bcrl/patches/sem-cleanup-A2/20-move_rwlock.diff
Přesune pomocné funkce i386 rwlock ze semaphore.c do
samostatného souboru rwlock.c.
http://www.kvack.org/~bcrl/patches/sem-cleanup-A2/30-one_semaphore.diff
Nahradí všechny implementace semaforů jedinou implementací
odvozenou z i386 kódu pomocí atomických operací. Testováno na x86-64,
kompilováno na i386 a ia64.
James Bottomley odpověděl:
To je všechno moc pěkné pro platformy, které mají účinné atomické operace. Na PARISC však takový luxus nemáme (procesor nemá žádné atomické operace, takže se s nimi musíme patlat v jádře pomocí zámků), a proto to vypadá, že naše semaforové operace budou s tvým kódem méně účinné..
Nemohl bys vymyslet méně monolitický způsob, jak to sdílet, abychom mohli i nadále pracovat s implementací semaforů pomocí spinlocků místo atomických operací?
Benjamin na to řekl: Podle toho, jak tomu kódu rozumím já, by to nemělo vadit: PARISC vezme spinlock v rámci atomické operace a pak jej uvolní, což způsobí, že stará rychlá cesta pro semafory bude stejná jako ta nová rychlá cesta (obě berou i uvolňují jeden spinlock). David S. Miller odpověděl: Myslím, že PARISC by měl mít možnost zvolit si svou implementaci semaforů. Hele, když se semafory nějak změní, bude to na nich, aby svoji PARISC verzi udrželi aktuální.
Russell King nechápal, proč ty patche vůbec vznikly: Kam se poděla efektivita a výkon? Myslel jsem, že ty inline [vložené] části implementace semaforů byly jednou z důležitých oblastí - tak důležitých, že je někteří lidé napsali v assembleru. Trond Myklebust vysvětlil: Začalo to snahou o rozšíření existujících implementací, aby podporovaly nové funkce - třeba asynchronní oznamování. To je v současné době nemožné, pokud tvoje supervývojářské schopnosti nezahrnují i to, jak dát dohromady 24 různých správců subsystémů, aby pracovali na řešení. Jinými slovy, hlavním důvodem je udělat to spravovatelné.
V originálu Kernel Traffic 310 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:
