OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Aktuální vývojová verze jádra je 3.3-rc4 vydaná 18. února, což je o pár dnů později, než se čekalo. Tentokrát je důvodem pro zpoždění to, že nám trvalo několik dnů, než jsme vystopovali narušování stavu plovoucích čísel, ke kterému docházelo na 32bitovém x86 – ale jen pokud jste měli moderní CPU (proč pak používáte 32bitová jádra?) s podporou instrukcí AES-NI. A pak jste museli zapnout podporu těchto instrukcí *a* použít bezdrátový ovladač, který jich využívá. Nejpravděpodobnějším důvodem je používání infrastruktury mac80211 s WPA se šifrováním AES (tedy typicky WPA2). Dále se dostalo i na řadu dalších oprav; krátký seznam změn najdete v oznámení.
Stabilní aktualizace: verze 3.0.22 a 3.2.7 byly vydány 20. února; obsahují obvyklý výčet důležitých oprav.
Když napíšete
if (ret) { one_line_statement(); }tak někde umře štěňátko. A lidi od DRM právě odrovnali celý útulek.
-- David Miller
Systémové volání poll() má tři parametry, jedním z nich je hodnota časového limitu (timeout), která určuje horní mez (v milisekundách) toho, jak dlouho bude proces čekat. Manuálová stránka říká, že typem této hodnoty je int. Z důvodů, které už dávno zapadly v historii, interní jaderná implementace poll() vždy očekávala hodnotu časového limitu v podobě long. A to bylo zdrojem občasných bugů.
Většinou to funguje, jak má. Typy int a long jsou na většině architektur shodné a pokud už se liší, tak se glibc postará o příslušnou změnu se zachováním znaménka. Pokazí se to ale právě tehdy, když 32bitový proces běží na systému x86-64. V tomto případě 32bitová funkce sys_poll() předá hodnotu nativnímu jadernému protějšku jen tak, aniž by docházelo ke znaménkové úpravě. Takže pokud je hodnota záporná (značící, že poll() může klidně čekat donekonečna), jádro místo ní uvidí velkou kladnou hodnotu.
Problém se dá opravit několika způsoby. Linus se rozhodl pro změnu parametru časového limitu na int v jádře. Díky tomu, že teď je timeout 32bitovou hodnotou na všech systémech, je hned o jednu příčinu zmatků méně. Tento přístup má ale jedno drobné riziko: nelze vyloučit, že existuje nějaká aplikace, která skutečně používala 64bitové timeouty. Aby taková aplikace mohla fungovat, znamenalo by to obcházení glibc (protože její operace se znaménky používání 64bitových hodnot znemožňuje), tudíž je nepravděpodobné, že se s tím někdo někdy obtěžoval, ale kdo ví. Pokud by tato změna nějakou skutečnou aplikaci porouchala, musel by se patch zase odstranit a muselo by se najít nějaké komplikovanější řešení.
Linusův patch byl začleněn do verze 3.3-rc5, takže máte několik týdnů na vyjádření svých obav.
Mechanismus pro sdílení bufferů DMA byl zařazen do jádra verze 3.3; jde o možnost, jak pod taktovkou uživatelského prostoru umožnit sdílení bufferů DMA mezi nezávislými ovladači zařízení. Patche dma-buf v podobě, v jaké byly začleněny do verze 3.3, obsahují řadu funkcí, které ovladače používají pro přístup k takovým bufferům; tyto funkce jsou exportovány jako „pouze pro GPL“. Kvůli tomu se ozval Robert Morell z NVIDIA, kterému se pochopitelně nelíbilo, že by toto rozhraní nebylo přístupné proprietárnímu ovladači z dílny jeho firmy.
Moc čtenářů asi nepřekvapí, že reakce na Robertovu stížnost nebyly zrovna plné pochopení. Po chvíli diskuze utichla bez jakéhokoliv řešení. Nedávno ale Rob Clark zpravil svět o debatě, která proběhla na Embedded Linux Conference:
V reakci na proběhlou debatu musím souhlasit, že infrastruktura dma-buf je zamýšlena jako rozhraní mezi subsystémy ovladačů. A protože (prozatím) veškerá podpora pro ARM SoC GL bohužel znamená používání uzavřeného kódu v uživatelském prostoru a protože považuji uživatelský prostor a jádro v oblasti grafických ovladačů za úzce provázané, nemyslím si, že se zde můžeme odvolávat na nějaký zavedený morální standard. Tudíž nemohu namítat proti tomu, aby se místo EXPORT_SYMBOL_GPL() objevilo EXPORT_SYMBOL().
Od té doby se o tom už nemluvilo; stejně tak se ani v jádře nic ohledně těchto funkcí nezměnilo. Změna tónu ve výše citovaných větách může znamenat, že se snad postoje lidí obměkčují a že API pro sdílení bufferů bude nakonec dostupné i pro proprietární moduly.
Oracle oznámil dostupnost betaverze trasovacího frameworku DTrace, který byl přeportován na jejich „Unbreakable Enterprise Kernel“. Ohledně toho, jak port funguje nebo jak se používá, se tohoto teď moc neví; linuxové fórum DTrace zatím zeje dost prázdnotou. Ukázka použití je ale k mání v blogovém zápisku od Wima Coekaertse.
Obecně platným pravidlem vývojářů jádra je vyhýbat se rozbíjení kódu v uživatelském prostoru, i když je takový kód často vnímán jako principiálně špatný. Ale jsou tu i výjimky; nedávná debata týkající se chování časovače může být ukázkou, jak k takovým výjimkám může dojít.
Standardní céčková funkce sleep() má tu definici, že uspí volající proces na alespoň tolik sekund, kolik bylo určeno. Člověk by si mohl myslet, že volání sleep() s argumentem nula asi moc nedává smysl; proč uspávat procesor na 0 sekund? Jenže se ukázalo, že někteří vývojáři dělají taková volání, aby se CPU na chvilku vzdali. Smyslem je chovat se slušně a před pokračováním v práci nechat krátce běžet i jiné procesy. Aplikace, které dělají polling nebo jsou z jiného důvodu náchylné k přílišnému vytěžování CPU, jsou často „napravovány“ voláním nulových sleepů.
Bylo nebylo za horami v zemi Linuxu, sleep(0) vždy uspával volající proces na alespoň jeden ti(c)k hodin. S příchodem časovačů o vysokém rozlišení do jádra se toto chování změnilo; pokud proces požádal o uspání na vypršeném časovači (což je situace sleepu na nula sekund), volání se jednoduše vrátilo zpět do volajícího procesu. Pak bylo přidáno polevování časovačů [timer slack], které může protáhnout čekání s cílem probouzet najednou hned několik procesorů. Toto chování způsobuje to, že časovače běží o trochu déle, než se žádalo, ale výsledkem je méně probouzení procesorů a tudíž úspora energie. V případě sleepu na nula sekund přidání polevování časovačů mění vypršený časovač na nevypršený časovač, takže volající proces je opět uspáván.
Výchozí polevování trvá 50 µs, takže je nepravděpodobné, že by to ve většině aplikací způsobovalo viditelné změny. Ale zdá se, že na některých systémech je tato hodnota nastavena trochu moc vysoko – v řádu sekund – aby se dosáhlo největších úspor energie. To pak odpovídajícím způsobem může prodloužit sleep a tedy aplikace trochu porouchat.
Matthew Garrett, který zastává názor, že není dobré aplikace rozbíjet, zaslal patch, který sleepy na nula sekund speciálně ošetřuje. Myšlenka je prostá: pokud je požadovaný čas nulový, polevování se mu vyhne a proces nebude uspáván po neurčitou dobu. Problémem tohoto přístupu k věci je to, že proces stále nedocílí kýženého výsledku: namísto vzdání se procesoru jen dojde ke zbytečnému systémovému volání a proces bude zase pokračovat v tom, co dělal doposud. Bez polevování časovačů se požadavek na uspání nad vypršeným časovačem vrátí hned zpátky do uživatelského prostoru, aniž by jakkoliv prošel plánovačem.
Alternativou by bylo přeměnit volání sleep(0) na volání sched_yield(). Jenže tento nápad se netěší popularitě mezi vývojáři plánovače, kteří si myslí, že volání sched_yield() jsou téměř vždy špatný nápad. Říkají, že je lepší opravit aplikace tak, aby přestaly dělat polling nebo obecně to, o čem si vývojáři myslí, že je dobrým důvodem k explicitnímu vzdávání se procesoru.
Podle Matthewa se to týká nemalého množství aplikací:
Testování na Fedoře odhalilo přibližně 125 balíčků z 11000 nebo tak nějak, takže přibližně 1 % uživatelského prostoru v některých situacích používá sleep(0). Všechno v distribuci asi opravit můžeme, ale i tak to znamená, že je na světě znatelné množství kódu, které je porouchaný.
Obvyklým přístupem při vývoji jádra by bylo vyhnout se rozbíjení těchto aplikací. I když aplikace závisí na nedefinovaném nebo nedokumentovaném chování – což je rozhodně tato situace – je stále lepší, když aktualizace jádra nepromění funkční kód v rozbitý. Někteří účastníci se vyjádřili v tom smyslu, že by se tak mělo postupovat i tentokrát.
Situace kolem sleep(0) se ale od jiných trochu liší. Vývojáři aplikací se v tomto případě nemohou odvolávat na dlouhodobě funkční chování, protože během poslední desítky let se reakce jádra na sleep(0) několikrát změnila. A podle Thomase Gleixnera je těžké poznat, kdy by se k takovému volání mělo přistupovat jinak nebo co by se mělo dělat:
Krucinál, nemůžeme přece dát dohromady rozumnou definici, jak takovou věc odlišně ošetřit, protože prostě není ani možné udělat jasnou hranici, co je zvláštní případ a co ne. A neexistuje žádná rozumná definice, co dělat – hned se vrátit nebo projít přes schedule() nebo něco jiného.
Thomas má obavy, že by se pak lidé mohli dovolávat zvláštního ošetřování u podobných volání – například u nanosekundové obdoby nanosleep() – a výsledkem by pak bylo hromadění nepořádku v hlavním kódu časovače. Takže než abychom se snažili tyto případy definovat a donekonečna museli výsledek tohoto snažení udržovat, si myslí, že bychom měli v případech, kdy je polevování časovače nastaveno na velkou hodnotu, nechat postižený kód svému osudu. A v tomto bodě diskuze odezněla, což znamená, že se ohledně omezení dopadu polevování časovače asi nebude nic dělat.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Preco je sched_yield() spatny napad? Ja som ho napriklad pouzil vo viacvlaknovom programe, ked mi pri specifickej datovej strukture (kt. si konzistenciu zarucovala sama) nastala kolizia a nechcel som, nech sa 1 vlakno so "spinlockom" toci dlhu dobu (toto tocenie v cykle program viditelne spomalovalo). "Klasicke" zamykanie a semafory som nemohol pouzit, lebo ich obsluha bola pomerne draha v pripade, ze kolizia nenastala. sched_yield() nielenze zabranilo vytazovaniu CPU tocenim sa v cykle, ale zaroven to zrychlilo aj vykonavanie programu - pravdepodobne preto, lebo sa dostalo druhe vlakno na radu skor.
Pravdupovediac, veci ako sleep(0) by ma nikdy nenapadli, lebo sa mi zdaju byt nelogicke, uz pri precitani nazvu. Na prvy pohlad ide o nahodne side efekty a teda sa na ne neda spolahnut. Urcite by som sa s tym netrapil, ako opisani vyvojari.
U RCU se spinlock exkluzivně zamyká jenom ve chvíli, kdy se dělá update, takže tam by s tím problém nebyl, update je výjimečný a pravděpodobnost, že nastane dvakrát za sebou ve stejném vlákně, je prakticky nulová.Moc nerozumím tomu, k čemu je na RCU potřeba zamykat čtení. Na to by přeci měla stačit atomická proměnná.
Zamykání pro čtení je u spinlocku velice levné, protože to je jen inkrementace atomické proměnné,Jen? Inkrementace atomické proměnné je docela drahá operace, protože zpusobuje, že si procesory příslušný cacheový řádek pinkají mezi sebou po poměrně pomalé sběrnici.
což u RCU musíte dělat stejně.Opravdu? Nestačí mi atomickou proměnnou číst?
Jen? Inkrementace atomické proměnné je docela drahá operace, protože zpusobuje, že si procesory příslušný cacheový řádek pinkají mezi sebou po poměrně pomalé sběrnici.Ve srovnání s voláním jádra, co dělají semafory a dělaly mutexy, je to velmi levné.
Opravdu? Nestačí mi atomickou proměnnou číst?A kdo bude uklízet?
Ve srovnání s voláním jádra, co dělají semafory a dělaly mutexy, je to velmi levné.To ano, ale dá se obejít i bez toho. (Mimochodem, pod Linuxem by ani semafory neměly v případě, že nečekají, volat jádro.)
A kdo bude uklízet?Dá se to udělat například tak, že každé vlákno jednou za čas projde nějakým synchronizačním bodem, ve kterém je jisté, že zrovna do žádné datové struktury nekouká, a přitom zvýší per-thread čítač. Uklízecí vlákno pak po čase podle čítačů zjistí, že do staré verze struktury už dávno nikdo nekouká, a uvolní ji.
Komu se ještě nikdy nestalo, že z nepozornosti přidal druhý příkaz a zapomněl na složené závorky, ať hodí kamenem.Možno kedysi veľmi dávno, ale odkedy používam počítačový jazyk so syntaxou pre normálnych ľudí, tak sa mi to nestalo
if(...) {
, tak to je jiné, ale v tom se radši ani nehrabu.
Myslel jsem spíš chyby typu
if (cond) do_something(); + do_something_else(); go_on();
případně
if (cond) + do_something_first(); do_something(); go_on();
Právě tomu používání složených závorek i u jednořádkových větví docela účinně předchází.
if (...) { neco(); }ten kód znatelně protáhne... Stačí jen pár takových ifů pod sebou.
tak skoro vsechno melo nejake vedlejsi efekty
Jestli má 3 řádková metoda vedlejší efekt, tak to už musel být skoro kouzelník
Kdyz to nekde vyhodilo chybu, byl zdroj chyby nejspis v okolnich 10 radcich, nikoli v jinem souboru.
Jsem si vždy myslel, že výjimky vznikají v metodách a ne souborech. Zase jsem se něco naučil.
Ten původní kód psalo prase, bez ohledu na to, že dodržovalo nějaké doporučení. Délka metod nemá nic společného s tím, kdy metoda kromě návratu hodnoty také cosi nastaví (nebo naopak nenastaví). Metoda má dělat jen jednu věc a ta věc by měla odpovídat názvu.
promenna dostane prirazenou hodnotu ve zcela jine metode, co je umistena ve zcela jinem souboru
Já v Javě pojem "proměnná v jiném souboru" opravdu neznám. Proměnná je v nějakém objektu (tedy atribut; field), nebo může být v dané třídě statická. Nevím, který z těchto dvou případů to byl, zřejmě se jednalo o nějakou statickou nefinální proměnnou s přístupem public... Jak jsem psal, ten kód psalo prase.
pokud to nekde spadlo, tak misto vzniku chybu (neosetreni cehosi) bylo vetsinou jen par radku od mista projevu chyby
Podle stacktrace se to dá někdy snadno vypátrat (někdy samozřejmě ne), nez ohledu na počet tříd.
Nevim, kde jsi prisel na to, ze by to melo byt v jave.
Aha, za to se omlouvám, to poznámku o Javě a tomto způsobu psaní psal někdo jiný, ty jsi potom volně pokračoval o C.
Jinak v podstatě souhlas, pokud někdo používá poučky ad absurdum, k ničemu dobrému to nevede.
Jenže právě proto, že jsou to triviální metody, je celá jejich funkce popsána jejich názvem, takže netřeba číst jejich kód. Takový zdroják se mi naopak dobře čte - metoda o 5 řádcích z toho 3 řádky jsou volání jiných metod a vše plyne už z jejich názvu.Pak její zápis měří o 4 řádky víc, než je zdrávo. Daleko lepší je napsat:
method catch() { .bark; .bite; .tail.wag; }
Věnovat takovému štěku víc než jeden řádek je nestoudné plýtvání elektrony, prostorem ve Vesmíru i čtenářovou pozorností.
Někde to nejde, většinou jo.Jenže i když to jde, často je to na škodu celkové čitelnosti kódu. Nedává smysl optimalizovat na čitelnost jedné metody (zvlášť když nic zajímavého nedělá). Daleko důležitější je, jak je snadné pochopit celou třídu.
Vrcholem jsou programy v Javě rozdělené na desítky naprosto triviálních tříd plných triviálních metod, navíc každá třída v jiném souboru, ty se nedají číst vůbec.
No tak zrovna v tomhle ohledu na tom některé části linuxového jádra nejsou o moc lépe. Běžně se mi stává, že abych zjistil, co vlastně dělá určitá funkce, musím postupně projít čtyři funkce, na střídačku z adresáře příslušného subsystému a include
. Při troše smůly se do toho zamíchá ještě nějaké těžko dešifrovatelné makro a když je smůly víc, tak jako bonus arch
a include/asm
.
Závorky by měly být ze zákonaSuhlasim.
if(...) { on_line_statement(); }tak chcípně vždy je 1/2 štěňátka.