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.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Aktuální vývojová verze jádra je 3.3-rc5 vydaná 25. února. Vida, tenhle týden bez zpoždění. A ani se neděje nic divného. Možná se to konečně uklidňuje. Do tohoto vydání šlo 164 neslučovacích změn; krátký seznam změn je jako obvykle v oznámení.
Stabilní aktualizace: verze 3.2.8 vyšla 27. února. Toto je „zajímavá“ aktualizace, a to v tom, že je tu opravována „jen“ jediná chyba, jde o ošetření problému s plovoucími čísly na nových procesorech x86 v 32bitovém režimu. Ale opravovány jsou v této oblasti i problémy na x86-64, takže upgrade se doporučuje všem uživatelům. Pokud někdo narazíte na problémy, tak nám dejte hned vědět.
Aktualizace 3.0.23 a 3.2.9 vyšly 29. února; obě obsahují něco přes 70 důležitých oprav.
Ve starých dobách jsme snadno mohli odhalit kód, který potřebuje audit, podle stylu psaní kódu (nebo spíše chybějícího stylu). Ale pak někdo rozhodl, že nejdůležitější vlastností dobrého kódu je způsob používání bílých znaků. A napsal se na to nástroj.
Nějakou dobu bylo pro nás, správce, těžké určovat, kterými patchi se máme zabývat! Bojovníci postavení proti bílým znakům pak naštěstí navrátili původní stav: teď můžeme začátečníky odhalit podle toho, že dají na checkpatch.pl.
Projekt linuxového jádra má závažné a přetrvávající strukturální problémy a myslím si, že je pro nás jako pro projekt [Debian] důležité nechat si zadní vrátka.
-- Ian Jackson
UIO poskytuje framework, který doopravdy funguje (na rozdíl od toho, o co se snažily všechny ty výzkumné práce) a je používán na skutečných systémech (roboti svařující laserem!) každý den, vyrábějí věci, které používáte a jste na nich závislí.
Tím, že odstraníte UIO, riskujete, že ty roboty naštvete, je to na vás, ale já s jistotou vím, že to neudělám...
Zalamování řádků po 80 znacích téměř nikdy není známkou pokulhávající hardwarové výbavy, ale spíše symptomem nedostatečného uvažování.
-- Ingo Molnar
Nástroj, který byl dříve znám jako návěští pro skoky [jump labels], je navrhnut pro minimalizaci režie spojené s výjimečně užívanými funkcemi v jádře. Klasickým příkladem jsou body sledování [tracepoints], které jsou po většinu času vypnuté. V ideálním stavu by režie zakázaného bodu sledování byla nulová, nebo by to tomu bylo velice blízko. Návěští pro skoky (nyní „statické klíče“) používají úpravy kódu za běhu, aby z kódu kompletně odstranily nepoužívané funkce, dokud je někdo nezapne.
Za podpory Inga Molnara nedávno Jason Baron zaslal sadu patchů, která upravuje mechanismus návěští pro skoky tak, že vypadají následovně:
if (very_unlikely(&jump_label_key)) { /* Zde má místo výjimečně používaný kód */ }
Řada lidí si stěžovala, že very_unlikely() vypadá jen jako posílená obdoba makra unlikely(), které funguje poněkud odlišně. Ingo odpověděl, že podoba není náhodná a dává smysl, ale moc lidí nepřesvědčil. Po chvíli dalšího dohadování to Ingo vzdal a přestal název very_unlikely() protlačovat.
Namísto toho máme zase další podobu návěští pro skoky, popis najdete v tomto dokumentu. Návěští pro skoky statický klíč je definován jako jeden z těchto řádků:
struct static_key key = STATIC_KEY_INIT_FALSE; struct static_key key = STATIC_KEY_INIT_TRUE;
Počáteční hodnota by měla odpovídat nastavení pro běžné užití – tedy té rychlejší možnosti. Používání statických klíčů vypadá takto:
if (static_key_false(&key)) { /* Zde se nachází kód pro nepravděpodobné situace */ }
Je třeba věnovat pozornost tomu, že static_key_false() lze používat pouze s klíčem inicializovaným pomocí STATIC_KEY_INIT_FALSE; u klíčů, které jsou ve výchozím stavu nastaveny na true, se musí používat static_key_true. Pro nastavení klíče na true jej stačí předat do static_key_slow_inc(); odstranění reference na klíč (a tedy pravděpodobně i nastavení na false) se dělá pomocí static_key_slow_dec().
Tato podoba změny už nebyla tak kontroverzní a dá se tedy odhadovat, že se probojuje do začleňovacího okna verze 3.4. Poté se dá očekávat, že se tento mechanismus nebude po alespoň jeden nebo dva vývojové cykly přepracovávat.
Řídící skupiny [control groups] jsou jednou z funkcí, které jaderní vývojáři mají v oblibě nenávidět. Není těžké dohledat případy, kdy si na ně vývojáři stěžují a dokonce vyhrožují, že je jedné temné noci, až se nikdo nebude dívat, zlikvidují. Je ale méně obvyklé být svědkem diskuzí kolem konkrétních aspektů řídících skupin, které se vývojářům nelíbí, resp. jak by se to mohlo zlepšit. Nedávná diskuze na linux-kernel byla ale trochu výjimkou.
Mechanismus řídících skupin je zjednodušeně řečeno způsob, jakým může administrátor systému rozdělovat procesy do jedné nebo více hierarchických skupin. Hierarchií může existovat vícero a jeden proces je možné umístit do několika z nich. S řídícími skupinami souvisí koncept „řadičů“ [controllers], které konkrétní hierarchii řídících skupin nastavují určitá pravidla. Řadič skupinového plánovače [group scheduling controller] umožňuje řídícím skupinám přetahovat se mezi sebou o čas procesoru, konkrétně tedy omezovat to, jak hodně může jedna skupina procesů upírat procesorový čas jiné. Řadič paměti omezuje to, kolik paměti a swapu může spotřebovávat určitá skupina. Řadič síťové priority, který byl začleněn do verze 3.3, umožňuje administrátorovi dávat skupinám lepší nebo horší přístup k síťovým rozhraním. A tak dále.
Diskuzi zahájil Tejun Heo, a to dlouhou zprávou, ve které shrnul své stížnosti na mechanismus řídících skupin a jak si myslí, že by bylo možné to napravit. Podle Tejuna bylo chybou umožnit existenci vícero hierarchií procesů. Myšlenkou vícero hierarchií bylo umožnit nastavovat různá pravidla podle různých kritérií. Dokumentace k řídícím skupinám uvádí příklad se dvěma odlišnými hierarchiemi, které by se mohly objevit na univerzitním systému:
Na první pohled poskytují různé hierarchie administrátorům užitečnou ohebnost pro to, aby mohli nastavovat rozličná pravidla. V realitě nicméně komplikují kód a vytvářejí zajímavé problémy. Jak Tejun poukazuje, řadiče mohou být přiřazeny jen k jedné hierarchii. U řadičů, které nějakým způsobem řídí přidělování prostředků, toho omezení dává trochu smysl; jinak by se procesy mohly stát předmětem protichůdných pravidel, jakmile by se dostaly do několika hierarchií. Jenže pak tu jsou řadiče, které mají jiný význam; řadič „freezer“ (mrazák) jednoduše zastavuje procesy, které najde v dané řídící skupině, což umožňuje vytvoření checkpointu nebo další operace. Neexistuje žádný důvod, proč by tato funkce nemohla být dostupná v libovolné hierarchii, jenže pokud by to bylo možné, značně by to zkomplikovalo implementaci řídících skupin.
Největší stížností je ale to, že jen málo vývojářů považuje tuto funkci za skutečně užitečnou na reálných systémech. Není jasné, zda se to doopravdy používá. Tejun navrhuje postupné vyřazení této funkce, pravděpodobně po nějakém dosti dlouhém přechodovém období. Nakonec by podle Tejunových slov mohla hierarchie řídících skupin v podobě nezávislé struktury zmizet a řídící skupiny by mohly být postaveny nad existující hierarchií procesů. Někteří s tím nesouhlasí, Peter Zijlstra řekl: Raději budu přiřazovat procesy do řídících skupin, které jsem stvořil, než abych jejich podobu musel kopírovat v hierarchii procesů. Takže možnost mít hierarchii řídících skupin, která se liší od hierarchii procesů, asi nezmizí, a to i kdyby se podpora vícero hierarchií časem stala zastaralou.
S tím souvisí jiný problém, na který Tejun upozornil, a to že různé řadiče s hierarchií řídících skupin zacházejí odlišně. Zejména jde o to, že několik řadičů prošlo určitou evolucí, kdy počáteční implementace nerozpoznávala vnořené řídící skupiny a místo toho hierarchii zploštila. Pozdější aktualizace plnou podporu hierarchií případně doplnily. Takový řadič blokového I/O se plné podpory dočkal až minulý rok, ostatní se toho třeba ještě ani nedočkaly. Aby se systém choval správně, tak podle Tejuna musí všechny řadiče vnímat hierarchii stejně.
Obecně byly řadiče za poslední roky zdrojem spousty zlé krve. Obvykle jsou implementovány tak, aby byl jejich vliv na systém, kde nejsou používány, co nejmenší – a to z dobrého důvodu – jenže to má za následek dosti slabou integraci. Řadič paměti například vytvářel svůj vlastní sledovací systém stínových stránek, což vedlo k nepořádku a značnému využívání prostředků, přičemž toto bylo napraveno až ve verzi 3.3. Řadič hugetlb není integrován s řadičem paměti a ve verzi 3.3 máme zase dva nezávislé řadiče sítě. A jak se množství malých řadičů zvyšuje (dokonce byl navržen řadič pro polevování časovačů), může v tom být ještě větší nepořádek.
K nápravě řadičů je hlavně zapotřebí, aby někdo začal pracovat jako hlavní správce řídících skupin. Tuto funkci mají podle souboru MAINTAINERS Teun a Li Zefan, ale pravdou je, že nikdo nevykonává dozor za celý systém, takže se změny dějí v rámci různých subsystémů. Je to ale administrativní problém; mělo by proto být možné to vyřešit.
Náprava řídících skupin bude obtížnější, zejména pak pokud se dostane na odstranění funkce vícero hierarchií. To je pochopitelně změnou ABI pro uživatelský prostor; než by k tomu došlo, tak by mohly uběhnout roky, pokud by to vůbec bylo možné. Tejun navrhuje nahnat lidi k tomu, aby používali jednotnou hierarchii spolu s tím, že by se u všech řadičů správně ošetřilo vnořování. Od určité verze by jádro začalo varovat, jakmile by se používalo vícero hierarchií. Nakonec, pokud by si nikdo nestěžoval, by funkce mohla konečně zmizet.
Pokud se zjistí, že vícero hierarchií nikdo nepoužívá, tak by se to pochopitelně mohlo stát rychleji. Nikdo se za tuto funkci nepostavil, ale samozřejmě šlo o debatu mezi vývojáři, nikoliv mezi uživateli. Pokud je tu někdo, kdo tuto funkci používá, tak by se měl ozvat. Informace o tom, jak funkci používají, by mohly ovlivnit budoucí podobu řídících skupin; pokud nikdo s takovými informacemi nepřijde, tak by tato budoucnost mohla býti dosti odlišná.
.Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Když se Linuxu něco stane, tak Debian pojede dál na kFreeBSD.To by bylo pro uživatele opravdu "terno", viz úžasná "podpora" WiFi, například.
Myslím, že v současné době je už celkem těžké narazit na tak malý displej, který by 120 znaků dlouhý řádek nepojmul.
Ne všichni automaticky roztahují všechna okna na celou šířku obrazovky.
crash
s disassemblovanou funkcí, ve druhém její zdroják (a to by to ještě chtělo mít ve třetím backtrace)).
Až na to, že to je 80 znaků textu, ne zanořený kód, ve kterém je prvních 48 znaků odsazení.Jo... 48 znaků odsazení naznačuje nešťastně mnoho vnoření, nešťastně zvolenou šířku odsazení, či obojí dohromady. Vždyť je to 6*8, 8*6, 12*4 nebo nedej bože 24*2. Používání osmiznakového tabu na odsazení je zvěrstvo. Škoda, že se něco takového kdy začalo používat, 12 a více odsazení už mi taky přijde jako zvěrstvo, pokud nejde o výpočty na hodně hluboko strukturovaných polích, ale tam mi zase přijde rozumnější kašlat na pravidla vymyšlená pro normální kód.
teď můžeme začátečníky odhalit podle toho, že dávají na checkpatch.plTohle mi nějak nedává smysl. Dle originálu bych řekl, že tam bude něco jako "dávají pozor" nebo že jej vůbec spustí.
checkpatch.pl
, to už v tom IMHO nehraje moc roli.