Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Len Brown má určitě sebemrskačské sklony; je totiž správcem linuxového ACPI subsystému. To není lehká pozice: ACPI znamená práci s BIOSem, což je oblast systémového softwaru, která se většinou nevyznačuje pečlivou a kvalitně odvedenou prací. Podpora ACPI je úkol, který - mimo jiné - vyžaduje vložení specializovaného interpreteru do jádra, a to není zrovna populární myšlenka. Přes to všechno je třeba se zamyslet nad tím, jak moc velká dávka masochismu je potřeba k tomu, aby člověk přednesl tři samostatné přednášky na linuxovém symposiu 2007 v Ottawě. Přesně to však Len udělal; výsledkem byl podrobný pohled na mnohé aspekty otázky správy napájení.
První řeč (o beztikovém jádře) měl původně přednést Suresh Siddha, který se však nakonec nemohl zúčastnit. Patche implementující dynamický tik nejsou nijak nové. Přednáška nebyla ani tak o tom, jak tyto patche fungují, jako spíše o věcech, které zbývá dodělat, abychom mohli beztikový design plně využít. Vypadá to, že doposud odvedená práce je jen začátek.
Jedním z problémů je to, že na systému, který používá Suresh a spol., se průměrná doba spánku procesoru nedostala nad 1 ms, i když byl zapnut kód s dynamickým tikem. Vzhledem k tomu, že hlavní motivací pro dynamický tik je nechat procesor delší dobu spát - a tím ušetřit energii - je to mizerný výsledek. Je však hodně věcí, které by situaci mohly vylepšit.
Prvním krokem je vyřešit jeden jaderný problém: existuje hodně aktivních jaderných časovačů, které mají tendenci se časem rozbíhat od sebe. Kvůli tomu se jádro budí daleko častěji, než kdyby byly časovače dostatečně koordinované, aby co nejčastěji vypršely ve stejnou chvíli. Mnohé jaderné časovače totiž nevyžadují velkou přesnost; pokud časovač spustí o pár milisekund později, než jak byl nastaven, není to problém. Kdyby tedy jádro mohlo některé časovače pozdržet, aby spustily ve stejný okamžik jako jiné, snížil by se počet probuzení. Patch, který implementuje odložitelné časovače, přesně tohle umí; funkce round_jiffies() (přidaná v 2.6.19) by jádru také mohla pomoci řadit události. Přidání tohoto kódu zvýšilo průměrnou dobu spánku na 20 ms, přičemž systém zpracovával 90 přerušení za vteřinu.
Další problém je s hardwarovými časovači. Na architektuře i386 se preferuje lokální APIC (LAPIC) časovač, který je zabudován do procesoru a lze jej naprogramovat velmi rychle. Jenže uspání procesoru uspí i LAPIC časovač, což Len přirovnal k vypnutí budíku než člověk usne. V obou případech může být nechtěným výsledkem zaspání. Programovatelný intervalový časovač [programmable interval timer (PIT)] sice zůstává vzhůru a je snadné jej použít, ale maximální doba, na kterou lze nastavit, je 27 ms. Pokud bychom chtěli, aby spal procesor déle, bude nutné najít jiné řešení. A tím je časovač událostí s vysokým rozlišením [high-precision event timer (HPET)], který má maximální interval alespoň tři vteřiny. Může být však obtížné získat k HPET přístup; dobrá podpora v BIOSu není moc častá a HPET je obvykle vypnutý. Pokud by však bylo možné vynutit zapnutí, mohla by se průměrná doba spánku zvýšit až na 56 ms, přičemž by zpracovával 32 přerušení za vteřinu.
Ještě lepší je vzít HPET z "legacy mode" [režim pro kompatibilitu se starším hardwarem/funkcemi], který teď Linux používá. Tento režim je snadno použitelný, ale vyžaduje přeposílání časovačových přerušení na víceprocesorových systémech. HPET však umí pracovat s kanály pro jednotlivé procesory, což tento problém odstraňuje. Výsledkem je nárůst průměrné doby spánku na 74 ms.
V tuto chvíli se věc přesouvá do uživatelského prostoru. Od vydání powertop toho bylo v této oblasti spoustu uděláno; uživatelské aplikace, které mohou způsobovat zbytečně časté probouzení, jsou hned rozpoznány a mohou být opraveny. Ale, jak poznamenal Len, uživatelský prostor je furt na houby.
Trochu to vypadá, že už Lena unavuje neustálé stěžování uživatelů na ACPI v Linuxu. Jeho odpovědí byla přednáška "Deset mýtů o ACPI" - i když se pak seznam rozrostl na dvanáct.
#1: Zapnuté ACPI nepřináší žádné výhody. Lenova odpověď měla dvě části, z nichž ta první je, že už pomalu nejsou žádné alternativy. Rozhraní APM je zastaralé a Vista ho už nepodporuje vůbec. Takže brzy už nebude APM podporovat ani žádný hardware; je to mrtvý standard. Standard MPS (používaný pro nacházení procesorů) je také starý a pomalu odumírá. Ať se vám to líbí nebo ne, ACPI je potřeba, abyste mohli svůj hardware používat.
Pozitivní však je to, že používání ACPI vám zpřístupní různé funkce hardwaru, například softwarem ovládaná tlačítka na vypínání a uspávání. Budete mít k dispozici údaje o stavu baterie a také možnosti, jak snížit spotřebu a prodloužit baterii výdrž. S ACPI je také možné za běhu připojovat komponenty (hotplug) a dokovat.
#2: Potíže s uspáváním na disk má na svědomí ACPI. Ve skutečnosti se jen malá část procesu uspávání na disk [suspend-to-disk] týká ACPI - všechno ostatní je v jiných částech jádra. Pokud máte problémy s uspáváním na disk, radí Len, stěžujte si Pavlu Machkovi, ne mně.
#3: Když nefungují speciální tlačítka, je to chyba ACPI. V tomto případě je problém v tom, že podpora "hotkeys" není součástí specifikace ACPI. Všechny ty extra čudlíky na noteboocích jsou funkce, které přidali výrobci. Ovladače získané pomocí zpětného inženýrství, které jsou teď v jádře, jsou heroický výkon, ale neměly by být potřeba. Výrobci by měli pro svůj hardware dodávat ovladače.
#4: Problémy při bootu se zapnutým ACPI jsou chyba ACPI. Len připouští, že tohle by občas mohla být pravda. Ale vypnutí ACPI vypíná i jiné funkce hardwaru - především IO-APIC. Takže problémy související s těmi ostatními částmi systému budou vypnutím ACPI skryty. Vypadá to, že původní problém byl s ACPI, ale ve skutečnosti je to více komplikované.
#5: Problémy s ACPI způsobuje nekvalitní BIOS platformy. Existují tři hlavní zdroje ACPI nekompatibilit. Jen jedna z nich je však BIOS, který porušuje specifikaci ACPI; nekompatibilní záležitosti, které nevadí Windows, často testováním proklouznou. Může s tím pomoci kit pro vývojáře firmwaru od Intelu. Dalším zdrojem problémů jsou odlišné interpretace specifikace, která je dlouhá a komplikovaná. Vývojáři linuxového ACPI pomáhají s vyjasňováním těchto záležitostí, když na nějaké narazí. A konečně poslední možnost - v linuxovém kódu prostě mohou být chyby.
#6: Linuxová komunita nemůže pomáhat vylepšovat specifikaci ACPI. Ve skutečnosti ACPI tým posílá vylepšení, většinou formou "objasnění specifikace". Mnohé z nich byly zařazeny a objevily se v aktualizacích specifikace.
#7: ACPI kód se hodně mění, ale ne k lepšímu. Intel sestavil sadu s více než 2000 testy; změny ACPI teď musí všemi testy projít, než jsou začleněny. Počet nových chyb se zmenšuje - i když možná pomaleji, než bychom si přáli.
#8: ACPI je pomalé a škodlivé pro regulátory procesorů [CPU governor] zaměřené na vysoký výkon. ACPI interpreter se nepoužívá v situacích, kde by záleželo na výkonu, takže nemůže věci zpomalovat. ACPI je využíváno pro konfiguraci.
#9: Regulátor speedstep-centrino je rychlejší než acpi-cpufreq. Acpi-cpufreq se dočkal mnoha vylepšení a umí teď přistupovat k MSR rychleji a snáze podporovatelným způsobem. Jeho výkon je tedy optimální a speedstep-centrino bude odstraněn.
#10: U procesoru je lepší mít více stavů nečinnosti. To by mohla být pravda u kteréhokoliv procesoru, ale nejde na základě toho procesory porovnávat. Záleží pouze na tom, kolik energie tyto stavy ušetří.
#11: Snižování frekvence procesoru [CPU throttling] ušetří energii. Tady je problém se záměnou termínů "příkon" a "energie". Procesor se sníženou frekvencí může šetřit mít menší příkon, ale je nutné ho mít puštěný déle, aby udělal svou práci. Takže přiškrcení procesoru (při zachování stejného napětí) může mít za následek více energie. Skoro vždy je lepší běžet s plnou frekvencí, jakou aktuální napětí povoluje, a dodělat práci rychleji; Len to popsal jako úprk k odpočinku.
Existují však druhotné účinky, které je možné vzít do úvahy. Především to, že baterie vydrží déle, pokud jsou vybity za delší dobu. Přiškrcený procesor může být také cladnější, což umožňuje vypnutí větráků. Přiškrcování může být nezbytné kvůli regulaci teploty. Ale z pohledu šetření energií jde skutečně jen o druhotné aspekty.
#12: Nemohu přispívat ke zlepšení ACPI v Linuxu. Stejně jako každý další projekt, i ACPI by uvítalo nové vývojáře. A kromě toho lze testovat jádra a reportovat chyby. Ve skutečnosti existuje mnoho příležitostí ke zlepšování ACPI kódu.
Lenova poslední přednáška přešla od spotřeby energie k jejím účinkům - především vytváření tepla. Přebytečné teplo není vítáno v žádném zařízení, ale v handheldech [zařízení do ruky] dvojnásob. Zařízení, kvůli kterým se ruka potí, není moc příjemné používat; a ty, která jsou tak horká, že je nejde držet, mohou být zcela nepoužitelná. Správa teploty je tedy velmi důležitá. Jenže sama podstata těchto zařízení regulaci teploty velmi ztěžuje: v linuxovém mobilu není prostor pro větráky a odvádění tepla bývá všeobecně dost obtížné.
Specifikace ACPI 3.0 obsahuje komplikovaný teplotní model. Zařízení je rozděleno na zóny a všechny komponenty mají charakterizovaný svůj příspěvek každé zóně. Implementace této specifikace je složitá - do té míry, že vývojáři linuxového ACPI vůbec nepočítají s tím, že by to dělali. Místo toho se zaměří na něco jednoduššího.
To něco je teplotní model ACPI 2.0. Součástí jsou teplotní zóny, z nichž každá má teplotní senzory a několik spouštěcích stupňů [trip point]. Spouštěcí stupeň "kritické vypnutí" je nastaven těsně před tím, než se zařízení začne tavit; kdyby začalo být tak velké teplo, musí se zařízení co nejrychleji vypnout. Ještě předtím dojde na jiné spouštěcí stupně; měly by zařídit čím dál přísnější opatření pro omezení teploty. Může se jednat o zapnutí větráků (pokud jsou k dispozici), snížení frekvence nebo uspání zařízení na disk. ACPI 2.0 obsahuje řadič, který monitoruje teplotní senzory systému a posílá procesoru události, když se stane něco zajímavého.
Vyvíjený kód pro regulaci teploty zatím využívá stávající mechanismus pro kritické vypnutí, který je zabudován do ACPI. Existuje už také podpora pro některé pasívní spouštěcí stupně, které se starají o snižování frekvence procesoru. U teplotních zón, jež se netýkají procesoru, je však lepší nechat rozhodnutí o dalším postupu na uživatelském prostředí - takže to tak ACPI kód udělá. Bude připraveno netlink rozhraní, přes které bude možné posílat teplotní události a nastavovat sysfs adresáře pro čtení hodnot senzorů. Sysfs strom bude také obsahovat ovládací soubory, a ty bude moci využít uživatelský démon k přiškrcování různých zařízení na základě teplotních událostí.
Takže jádro bude nakonec jen spojka pro přenos událostí a ovládacích nastavení mezi komponenty zařízení a uživatelským prostorem. Objevily se otázky, jestli bude k dispozici standardizovaná sada sysfs čudlů pro ovládání každého zařízení; odpověď bude asi "ne". Každé zařízení je jiné, všechna mají své vlastní ovládací parametry; bylo by těžké vytvořit standardní sadu, která by je všechna popsala. Navíc jsou cílovou skupinou embedded zařízení, z nichž každé je unikátní. Očekává se, že každé zařízení bude mít svého vlastního specializovaného démona, který bude napsán přímo pro něj, takže není důvod věci zevšeobecňovat.
Ze všech těchto přednášek to vypadá, že v oblasti správy napájení se toho děje docela dost, ačkoliv to po dlouhou dobu byla část Linuxu, která nedosahovala potřebné kvality. Narůstající využívání Linuxu v embedded zařízeních tomu může jen pomoci; je dost výrobců, kteří mají velký zájem na vylepšené podpoře inteligentního využívání energie. Dostane-li se správě napájení času a dalšího úsilí, přestane to být možná zanedlouho problém, který by bylo potřeba řešit.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
#11 v originale 'processor throttling' . Tim se AFAIK obvykle oznacuje spis nucene vkladani idle cykluAha... upravím.
/proc
a počítač výrazně zpomalil, přestože neuměl měnit frekvenci; samo se to spínalo při přehřátí. Teď mám Athlon64, který umí měnit frekvenci a v /proc/acpi/processor/CPU0/throttling
je napsáno "not supported"
To bylo ironické - myslí se tím dosažení nebezpečné teploty.Také to tak chápu.
Přiškrcený procesor může být také cladnější, což umožňuje vypnutí větráků.