Byla vydána nová verze 3.27 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 3.6 souvisejícího programovacího jazyka Dart (Wikipedie).
Byla vydána (𝕏) listopadová aktualizace aneb nová verze 1.96 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.96 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
OpenMandriva ROME, tj. průběžně aktualizovaná (rolling) edice linuxové distribuce OpenMandriva, byla vydána ve verzi 24.12.
U příležitosti oslav sedmi let prací na debianím balíčku vyšlo GPXSee 13.33. Nová verze přináší rychlejší vykreslování vektorových map a vylepšení/doladění nového stylu pro OpenAndroMaps/Mapsforge mapy. Kdo by rád OSM mapy v "prémiovém" barevném schématu a nechce čekat až nová verze dorazí do jeho distribuce, nalezne zdrojové kódy na GitHubu.
Tým Google Quantum AI představil kvantový čip Willow se 105 qubity.
Byla vydána nová verze 257 správce systému a služeb systemd (GitHub).
RPCS3 (Wikipedie), tj. open source emulátor Sony PlayStation 3, nově oficiálně běží také na architektuře arm64. Podporován je Apple Silicon (YouTube) je i Raspberry Pi 5 (YouTube).
Jaký byl rok 2024 ve vyhledávání Googlu? Mistrovství světa v hokeji, triumf Davida Pastrňáka, Robert Fico nebo loučení s herečkou Simonou Postlerovou. To jsou některá z témat, která letos nejvíce rezonovala ve vyhledávání na Googlu. Češi s velkým zájmem zjišťovali, proč je přestupný rok, a s podobnou intenzitou hledali důvod absence Zdeňka Chlopčíka ve StarDance. Kompletní žebříčky včetně globálních a další zajímavosti.
Chatbot Grok AI je nově pro uživatele sítě 𝕏 zdarma (návod). S omezením 10 zpráv za dvě hodiny a tři obrázky za den.
GNU Shepherd (Wikipedie) dospěl do verze 1.0.0. Po 21 letech. Jedná se o init systém a správce služeb napsaný v Guile Scheme. Původně se jmenoval GNU dmd (Daemon managing Daemons). Používá se v systému GNU Guix.
Aktuální předverze jádra řady 2.6 je 2.6.20-rc4, vydaná 6. ledna. Linus o ní řekl: Vůbec nic zajímavého - pokud si nechcete hrát s KVM nebo se vás netýkala chyba s těmi starými verzemi linkeru, kvůli které mizely části entry.S."
Do hlavního git repozitáře bylo od té doby začleněno přibližně 100 patchů. Jde o opravy, většinou v subsystémech architektur, ALSA a síťování.
Aktuální verze -mm stromu je 2.6.20-rc3-mm1. Mezi nedávné změny patří KVM (vizte níže), další sada změn API pracovních front a virtualizace struct user.
Aktuální stabilní 2.6 jádro 2.6.19.2, vydané 10. ledna. Obsahuje dlouhou řadu oprav, včetně opravy problému s poškozováním souborů a několika bezpečnostních potíží.
Starší jádra: 2.6.16.38-rc1 bylo vydáno 9. ledna a také obsahuje spoustu oprav - mnohé z nich řeší bezpečností chyby.
Kernel.org je hlavním repozitářem pro zdrojové kódy linuxového jádra, množství vývojových stromů a hromadu příbuzného materiálu. Nabízí také zrcadlení několika dalších projektů souvisejících s Linuxem - například CD obrazy distribucí. Uživatelé kernel.org si občas všímali, že je server dost pomalý. Jednotlivým vydáním jaderných stromů trvá dlouho, než se objeví na hlavní straně a zrcadlení zaostává. Vypadá to, že tato důležitá součást vývojové infrastruktury nedrží krok s nároky, které jsou na ni kladeny.
Z diskuzí v konferencích je zřejmé, že servery kernel.org (jsou dva) často běží s průměrnou zátěží v rozsahu 2-300. Není tedy moc překvapivé, že se vždy nechovají tak svižně, jak by se od nich očekávalo. Mluví se o přidání serverů, ale zároveň panuje shoda v tom, že by se současné servery se zátěží měly umět vypořádat. Takže se vývojáři snažili zjistit, co se děje.
Problém je patrně způsobován gitem. Kernel.org hostuje docela dost git repozitářů a také systém gitweb - i když gitweb je často vypínán, když zátěž příliš stoupne. Problémy s gitem zase vycházejí z toho, jak rychle umí Linux načítat adresáře. Podle administrátora kernel.org H. Petera Anvina:
Během extrémně vysoké zátěže to vypadá, že více než cokoliv jiného je kernel.org zpomalován tím, jak dlouho trvá každé jednotlivé volání getdents(). Když jsem to sledoval, naměřil jsem časy od 200 ms po až skoro 2 vteřiny! Tak si to spočítejte sami, když nezabalený *NEBO* nepročištěný [unpruned] git strom přidává k čistě zabalenému stromu 256 adresářů.
Zjevně je něco v nepořádku s tím, jak se při velkých zátěžích zachází s objemnými souborovými systémy. Část problému může být v tom, že Linux v takové situaci nevyhrazuje dost paměti pro kešování adresářů, ale hlavní chyba je jinde. Ukazuje se, že:
Třetí z těchto neduhů může být vyřešen přechodem na XFS, kterému se lépe daří udržovat adresáře pohromadě. Kernel.org by takový přechod mohl podstoupit - za cenu týdenního odstavení každého ze serverů. Nedá se proto čekat, že se tak stane přes noc.
Prioritou číslo jedna pro zlepšení situace je tedy pravděpodobně implementování nějakého přednačítání adresářů. To by ubralo na čase stráveném při čekání na I/O adresářů, ale především by to nevyžadovalo žádnou změnu stávajících souborových systémů. Dokonce ani zálohu a obnovu. Jeden raný readahead patch už se objevil, ale protože jde o komplexní záležitost, bude potřeba několik kol pečlivých kontrol, než bude hotovo opravdové řešení. Výsledek tedy čekejte kolem 2.6.21.
O sadě patchů KVM jsme stručně mluvili minulý říjen. Ve zkratce: KVM umožňuje (relativně) jednoduchou podporu virtualizovaných klientů na novějších procesorech. Na CPU s podporou intelské nebo AMD hardwarové virtualizace může hypervizor otevřít /dev/kvm a prostřednictvím série ioctl() volání vytvořit virtualizované procesory; a na těch spustit hostované systémy. Ve srovnání s plnou paravirtualizací (jako je Xen) je KVM poměrně prosté a přímočaré; to je jeden z důvodů, proč bylo KVM zařazeno do 2.6.20, zatímco Xen zůstává venku.
Ačkoliv je KVM v hlavním jádře, nedá se říci, že by bylo dokončené - a před i po vydání 2.6.20 by se ještě mohlo dočkat výrazných změn. Jeden aktuální problém se týká implementace "stínových tabulek stránek" [shadow page tables], která nepodává požadovaný výkon. Řešení je koncepčně jednoduché - tedy když pochopíte, co stínové tabulky stránek dělají.
Tabulka stránek samozřejmě představuje mapování z virtuální adresy na příslušnou fyzickou adresu (nebo příznak, který říká, že mapování v tuto chvíli neexistuje). Virtualizovanému operačnímu systému je přidělen rozsah "fyzické" paměti, se kterou může pracovat, aby si implementoval vlastní tabulky stránek, které budou mapovat mezi jeho virtuálními adresními prostory a přiděleným paměťovým rozsahem. Ale hostova "fyzická" paměť je ve skutečnosti virtuální rozsah spravovaný hostitelem; hostované systémy nepracují přímo s "železem". Výsledkem je, že mezi virtuálním adresním prostorem na virtualizovaném hostu a skutečnou fyzickou pamětí, na kterou mapuje, máme dvě sady tabulek stránek. Host může nastavit jednu úroveň překládání, ale pouze hostitel může spravovat mapování mezi "fyzickou" pamětí hosta a opravdovou pamětí.
Tato situace je řešena pomocí stínových tabulek stránek. Virtualizovaný klient si myslí, že spravuje své vlastní tabulky stránek, ale procesor je ve skutečnosti nepoužívá. Místo toho implementuje hostitelský systém "stínovou" tabulku, která zrcadlí tabulku hosta, ale mapuje hostovy virtuální adresy přímo na fyzické adresy. Stínová tabulka je vytvořena prázdná; každý výpadek stránky [page fault] na hostovi pak způsobí zaplnění příslušné stínové položky. Jakmile u hosta proběhnou výpadky ve stránkách, které potřebuje, bude moci běžet nativní rychlostí bez nutnosti dalšího zapojení hypervizora.
S verzí KVM, která je v jádře 2.6.20-rc4, však toto šťastné soužití moc dlouho nevydrží. Jakmile host provede přepnutí kontextu [context switch], je ta obtížně vybudovaná stínová tabulka stránek zahozena a nahrazena novou. Výměna stínové tabulky je nutná, protože proces běžící po přepnutí kontextu bude mít odlišnou sadu mapování adres. Ale když se předchozí proces dostane zpátky na procesor, bylo by fajn, kdyby tam na něj jeho stínová tabulka čekala.
Patch pro kešování stínových tabulek stránek, který poslal Avi Kivity, dělá přesně to. Místo aby prostě stínovou tabulku zahodil, dá ji na stranu, aby mohla být natažena, až bude příště potřeba. Nápad je to jednoduchý, ale implementace vyžaduje 33dílný patch - je potřeba se postarat o hodně drobností. Spousta potíží vychází z toho, že hostitel nedokáže pokaždé odhadnout, jestli host v položce tabulky stránek provedl nějaké změny. Proto musí být hostovy tabulky stránek chráněny před zápisem [write-protected]. Kdykoliv pak host provede změnu, narazí na hypervizora, který změnu dokončí a příslušným způsobem aktualizuje stínovou tabulku.
Aby systém ochrany před zápisem fungoval, musí kešovací patch přidat mechanismus pro reverzní mapování, který mu umožní sledovat výpadky nazpět až k tabulce(-kám), o kterou jde. Občas může dojít k zajímavé situaci, při které přestane být tabulka stránek používána, aniž by o tom hostitelský systém věděl. Aby tuto situaci odhalil, hlídá si kód KVM příliš časté nebo odchýlené [unaligned] zápisy, které (heuristicky) značí, že se funkce stránky změnila.
Jádro 2.6.20 je v poměrně pokročilém stádiu vývoje; finální verze by měla vyjít někdy koncem měsíce. Přesto by si Avi přál, aby byly tyto velké změny začleněny ještě teď. Ingo Molnar souhlasí:
Testoval jsem ty nové změny MMU docela zevrubně a vychází to pěkně. Režii spojenou s přepnutím kontextu sráží desetkrát a více, dokonce i u mikrobenchmarků: místo zahazování celé té pracně sestavené hierarchie stínových tabulek umožňuje tato sada patchů inteligentní kešování. Efekt je vidět pouhým okem - systém je zřetelně svižnější.
Protože je KVM v jádře 2.6.20 nové, nezpůsobí změny v jeho rámci žádné regrese. Je tedy pravděpodobné, že tato nová funkce bude přidána, i když už je tak pozdě ve vývojovém cyklu.
Jeden dlouho známý (a v Linuxu dlouho nepodporovaný) koncept souborového systému je union filesystem [sjednocený souborový systém]. Union souborový systém je logickou kombinací dvou nebo více dalších souborových systémů, což vytváří iluzi jediného souborového systému s obsahem všech.
Jako příklad si představte uživatele, který by chtěl připojit DVD s distribucí plné balíčků. Bylo by fajn mít možnost přidávat aktualizované balíčky opravující bezpečnostní chyby, ale DVD je médium, na které nejde zapisovat. Řešením je unionfs. Administrátor systému může vzít zapisovatelný souborový systém a spojit jej s read-only DVD, čímž vytvoří zapisovatelný souborový systém s obsahem obou. Pokud pak uživatel přidá balíčky, půjdou na zapisovatelný souborový systém, který tak může být menší, než kdyby měl pojmout celý obsah.
Unionfs patch od Josefa Šípka tuto možnost nabízí. S unionfs pak může administrátor systému sestavit spojené souborové systémy pomocí následujících příkazů:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
mount -r /dev/dvd /mnt/media/dvd
mount /dev/hdb1 /mnt/media/dvd-overlay
mount -t unionfs \
-o dirs=/mnt/media/dvd-overlay=rw:/mnt/media/dvd=ro \
/writable-dvd
První dva řádky jen připojí DVD a zapisovatelný oddíl jako běžné souborové systémy. Poslední příkaz je spojí do jediného svazku [union], který je připojen jako /writable-dvd. Každá "větev" svazku má prioritu určenou pořadím, ve kterém jsou uvedeny v parametru dirs=. Když je hledán soubor, jsou větve prohledávány podle priority, přičemž uživateli je vrácen první nález. Je-li učiněn pokus o zápis read-only souboru, bude tento zkopírován do zapisovatelné větve s nejvyšší prioritou a tam zapsán.
Jak je asi zřejmé, musí jít o dost komplexní systém, aby všechno tohle fungovalo. Spojování hierarchií souborových systémů, kopírování souborů mezi nimi a vkládání "zabělených" míst kvůli maskování souborů vymazaných z read-only větví. To jsou jen některé z problémů, které je nutné řešit. Zdá se, že kód unionfs většinu z nich zvládá dobře.
Při kontrole kódu se tedy všichni pustili do výjimky, která je zmíněna v dokumentaci:
Provádění změn přímo ve větvi unionfs ve chvíli, kdy je připojen svazek, není v současné době podporováno. Všechny takové změny mohou způsobit vše od žádné reakce, přes oops unionfs, až po ZTRÁTU DAT.
Znamená to, že je nebezpečné se vrtat přímo v souborových systémech, které byly spojeny do svazku. Andrew Morton poznamenal, že z hlediska uživatelského rozhraní se jedná o dost hrubý nedostatek. A protože připojení pomocí --bind tento problém nemá, zeptal se, proč by takovou past na uživatele měl mít unionfs. Josef odpověděl:
Připojení přes bind je záležitost na úrovni VFS. Unionfs je však, jak naznačuje název, souborový systém. Minulý rok na OLS to vypadalo, že se mnoho lidí shoduje v tom, že svazkování [unioning] není věc ani čistě FS, ani VFS.
To vyvolalo docela rázná prohlášení v tom smyslu, že by unionfs měl být implementován na úrovni virtuálního souborového systému. Bez toho není jisté, že by se kdy podařilo udržet koherentní jmenný prostor při změnách na všech úrovních svazku. Jak se zdá, unionfs bude potřebovat přepsat, aby si získal souhlas vývojářů jádra. Andrew Morton uvažoval o tom, jestli by neměla být aktuální verze začleněna v naději, že by to tento přepis podnítilo. Doposud nebylo žádné rozhodnutí učiněno, takže vůbec není jasné, zda bude mít Linux v dohledné době podporu unionfs nebo ne.
Následující obsah je © KernelTrap
9. led, originál
Adrian Bunk vystavil seznam známých regresí v posledním jádře 2.6.20-rc4 oproti předchozím stabilním vydáním verze 2.6.19. Ve dvou zprávách vyjmenoval šest regresí, pro které ještě nejsou opravy, a šest opravených, jejichž opravy ještě nebyly začleněny.
V jiném emailu Linus Torvalds načrtl, že pro 2.6.20 má v plánu především zaměření na stabilitu. Také uvedl, že stabilní jádro se chystá vydat někdy po skončení konference linux.conf.au, která se letos koná v Sydney od 15. do 20. ledna. Vysvětlil: Poslední -rc snad vyjde před LCA, ale vlastní vydání 2.6.20 nechám až na potom. Nechci, aby období pro začleňování nových věcí probíhalo během LCA, protože jak já, tak mnozí další budou stejně pryč. Bude tedy lepší, aby LCA proběhlo ke konci stabilizační fáze, kdy se toho snad moc dít nebude.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
time perl -e 'foreach my $i (1..35000) { mkdir($i) or die $!; } '
30.1.2007 12:28
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Dík za tip, na noťasu mam výsledek
$ time perl -e 'foreach my $i (1..35000) { mkdir($i) or die $!; } '
0.02user 3.31system 0:23.92elapsed 13%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+421minor)pagefaults 0swaps - je to ok?
30.1.2007 16:14
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Bez chyby doběh ... paseku mi tu ten skript udělal pěknou ... 
a jinak mam reiserfs asi 3.6 v def. konfiguraci.
0.20s user 14.00s system 41% cpu 34.328 totalMoze to byt aj mierne odlisnym HW. Ale na druhej strane toto cislo nic neznamena. Na vytazenych serveroch je dolezity vykon pri paralelnych a opakovanych citaniach/zapisoch. Btw.
time /bin/ls -la > /dev/null na tomto adresari s 35 tis. podadresarmi za 1.2 - 1.9 sec.
Skusme este toto:
mkdir x;
cd x;
time perl -e 'foreach my $i (1..150000) { mkdir($i) or die $!; } '; \
time /bin/ls -la > /dev/null ; time /bin/ls -la > /dev/null
cd ..
time rm -rf x > /dev/null
Vysledok:
perl -e 'foreach my $i (1..150000) { mkdir($i) or die $!; } ' \
0.77s user 51.86s system 30% cpu 2:53.09 total
/bin/ls -la > /dev/null 1.88s user 4.38s system 43% cpu 14.298 total
/bin/ls -la > /dev/null 1.52s user 1.38s system 86% cpu 3.337 total
rm -i -v -rf x > /dev/null 5.30s user 63.94s system 39% cpu 2:54.92 total
Ma niekto niekde ext3 filesystem? ;)
30.1.2007 17:15
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
Já bych to svaloval na těch 1.5GB RAM, co vy?
$ free -m
total used free shared buffers cached
Mem: 1390 1294 95 0 57 467
-/+ buffers/cache: 768 621
Swap: 0 0 0
Nechápu tak úplně smysl toho vašeho smajlíku. 150000 podadresářů sice na ext3 nevytvoříte (vzhledem k 16-bitové hodnotě link count), ale pro 31900 mi to vychází takto:
# ext3 real 0m5.515s user 0m0.012s sys 0m1.884s real 0m0.790s user 0m0.372s sys 0m0.408s real 0m0.425s user 0m0.264s sys 0m0.164s real 0m11.698s user 0m0.068s sys 0m11.301s # XFS real 1m37.638s user 0m0.060s sys 0m3.560s real 0m0.757s user 0m0.300s sys 0m0.456s real 0m0.374s user 0m0.200s sys 0m0.172s real 1m26.941s user 0m0.276s sys 0m5.764s
Oba filesystémy byly vytvořeny s defaultními parametry, pouze u ext3 jsem použil '-m 0' (což by ale na rychlost nemělo mít vliv). Výsledky XFS by asi šlo nastavením parametrů vylepšit, ale i tak bych řekl, že s tou pomalostí ext3 to nebude až tak strašné, jak naznačujete…
time perl -e 'foreach my $i (1..150000) { open(F, ">$i") or die $!; close(F); } ';
time /bin/ls -la . > /dev/null ; time /bin/ls -la . > /dev/null ;
perl -e 'foreach my $i (1..150000) { open(F, ">$i") or die $!; close(F); } ' \
1.09s user 9.92s system 11% cpu 1:34.37 total
/bin/ls -la . > /dev/null 1.49s user 2.14s system 63% cpu 5.712 total
/bin/ls -la . > /dev/null 1.48s user 1.34s system 73% cpu 3.812 total
P.S.: /bin/ls je pustene po sebe 2x schvalne, aby sa ukazalo cahovanie dat.
Tady jsou výsledky pro 150000 souborů (nevytvářel jsem je ale tím perlovým skriptem, napsal jsem si na to prográmek v C):
ext3: real 0m5.717s 0m2.550s 0m2.516s 0m3.661s user 0m0.164s 0m1.664s 0m1.700s 0m0.052s sys 0m5.076s 0m0.884s 0m0.816s 0m3.604s XFS: real 8m12.059s 0m2.472s 0m1.936s 7m41.173s user 0m0.312s 0m1.192s 0m1.072s 0m0.224s sys 0m17.365s 0m1.272s 0m0.864s 0m16.457s
Ty výsledky XFS při vytváření a mazání souborů se mi nějak nelíbí, asi to ještě vyzkouším na ramdisku.
$ time perl -e 'foreach my $i (1..150000) { open(F, ">$i") or die $!; close(F); } ';
real 0m17.068s
user 0m0.676s
sys 0m8.321s
$ time /bin/ls -la . > /dev/null ; time /bin/ls -la . > /dev/null ;
real 0m1.604s
user 0m1.268s
sys 0m0.280s
real 0m1.606s
user 0m1.336s
sys 0m0.272s