Po pěti letech vývoje vyšla česká počítačová hra Scarlet Deer Inn (ProtonDB). Scarlet Deer Inn je vyšívaná temná středověká pohádka. Zatímco život ve zdánlivě obyčejné vesnici se točí kolem běžných povinností a sousedských drbů, v podzemí se skrývají zlověstná tajemství.
Představen byl Raspberry Pi Touch Display 2 s uhlopříčkou 10 palců a rozlišením 1200 × 1920 pixelů. Cena je 80 dolarů.
RPCS3 (Wikipedie), tj. open source emulátor Sony PlayStation 3, snížil minimální požadavky. Nově jsou podporovány starší grafické karty ATI Radeon řady HD 2000, 3000 a 4000 z let 2007 až 2009. Na PC běží už 75 % všech her pro PlayStation 3. V budoucnu bude RPCS3 fungovat bez firmwaru z PS3. V RPCS3 byl implementován systémový modul cellSysmodule (𝕏).
Vyšel open-source nástroj winetop (MIT) — nativní CLI/TUI pro sledování a ukončování Wine, Proton, Lutris, Heroic a Bottles sezení. Seskupuje procesy podle WINEPREFIX / Steam AppId, umí bezpečně zabít jen hru (včetně Steam reaperu) a nabízí i skriptovatelné příkazy (list, kill, orphans, …). Balíčky jsou mimo jiné na crates.io, Copru (dnf copr enable kovariadam/winetop), PPA ppa:kovariadam/winetop a AUR (winetop-bin).
Ve spolupráci společností OpenAI a Work Louder byla představena (𝕏) hardwarová klávesnice Codex Micro pro práci s AI agenty. Cena klávesnice je 230 dolarů.
Byl vydán Mozilla Firefox 153.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 153 bude brzy k dispozici také na Flathubu a Snapcraftu.
V linux-cve-announce bylo oznámeno 433 zranitelností za jediný den (19. července).
Byla vydána nová verze 5.44 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 71 vývojářů. Změněno bylo přibližně 270 tisíc řádků v 1 300 souborech. Přehled novinek a změn v podrobném seznamu.
Na 23. září 2026 je do bratislavské Nové Cvernovky naplánovaná jednodenní konference #nobullshit.camp pro tech leadery, DevOps a platform inženýry. Mají tu zaznít upřímné příběhy z praxe o tom, co v produkčních systémech reálně fungovalo, co se pokazilo a co si z toho lidé odnesli. Témata pokrývají tři oblasti – DevOps a platformy (Kubernetes, cloud, provoz systémů), firemní kulturu a leadership. Program běží ve dvou formátech: hlavní
… více »Byla vydána nová verze 1.58 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Josephine Pfeiffer. Vypíchnout lze možnost nmtui zobrazit nastavení Wi-Fi jako QR kód nebo podporu CLAT (464XLAT) a tunelů GENEVE (Generic Network Virtualization Encapsulation).
Současné vývojové jádro je 4.1-rc7, vydané 7. června.
"Obvykle bývá rc7 posledním rc vydáním a neděje se nic zvláštního, co by vyžadovalo jiný postup. Nicméně stále máme několik nedořešených regresí a jak jsem zmínil minulý týden, také mě čeká každoroční dovolená s rodinou, takže bude ještě rc8 a jeden týden navíc, než skutečně dojde k vydání 4.1.
Stabilní aktualizace: 4.0.5, 3.14.44 a 3.10.80 byly vydány 6. června.
Ohledně pojmenování: Dobré jméno je popisné a zároveň krátké, příkladem nám může být "Linux" a "Git". Oh, moment...
Proč to nevzít důsledně a nepojmenovat to strtrtsstrrrtst(), přičemž strtrtssstrrtst() by dělalo skoro (ale ne tak docela) totéž.
Geoff Huston napsal o multipath TCP dlouhý sloupek.
"Ve většině případů má možnost využívat více adres nízké využití. Obyčejně je každá nová relace směřována ke konkrétnímu rozhraní, dostane odchozí adresu, která je daná lokálním nastavením. Ovšem když se zamyslíme nad využitím v situacích, kdy je vazba na umístění a identitu proměnlivá (fluid), kdy je nestálé síťové připojení a kde se různí kapacita a nároky připojení, jako je tomu u současných celulárních rádiových sítí nebo bezdrátových roamingových sítí, potom se možnost využívat relaci, která nabízí jistou pružnost pro přepínání mezi sítěmi, její jako celkem dobrý nápad."
(viz. také článek na LWN o implementaci multipath TCP pro Linux z roku 2013).
Kristen Accardi začala svůj příspěvek na LinuxConu v Japonsku tvrzením, že nečinné procesy jsou největší pracovní zátěží na většině zákaznických počítačích. Kancelářské počítače jsou vytížené méně než ve 25 % času a uživatelské počítače ještě méně. Takže jalový výkon je, s ohledem na spotřebu energie, celkem důležitý. Dobrou zprávou je, že inženýři se snaží snížit spotřebu nečinných systémů, špatnou naopak to, že operačním systémům se této možnosti nedaří dost dobře využívat.
Za "starých dobrých časů" byl podle Kristen power management relativně jednoduchý - a relativně neúčinný. Advanced Power Management (APM) byl zcela řízen BIOSem, takže si ho operační systémy nemusely příliš všímat. Technologie Intel SpeedStep nabídla přesně jeden krok pro škálování frekvence CPU. Operační systém mohl maximálně ztlumit jas displeje na přenosných počítačích. Zhruba takový byl rozsah možností správy napájení (power management), kterou tehdy hardware poskytoval.
Se vzestupem mobilního trhu se power management trochu zkomplikoval. Díky ACPI přešla velká část power managementu do správy operačních systémů. S ACPI byly zavedeny pojmy "S-stavy" (pro celosystémové stavy napětí - po uspání počítače), "C-stavy" (pro stavy nečinnosti CPU) a "P-stavy" (pro výkon - frekvenci a napětí procesoru). Celkem může těchto stavů být až 25.
To ovšem není vše. V posledních letech došlo k velkému boomu funkcí pro power management. Jmenují se SOix (nový stav nízkého napájení) a PSR ("panel self refresh"). Všem těmto funkcím musí operační systém rozumět, také musí fungovat společně, jinak nebudou účinné.
Podle Kristen existují tři základní stupně nečinnosti systému. Různí se množstvím spotřebovávané energie a časem, který je nutný, aby se počítač dostal zpět do aktivního stavu. Úroveň s nejnižší spotřebou energie je při vypnutém počítači (off). Jedná se o celkem nezajímavý stav, mnohá spotřebitelská zařízení již ani tlačítko pro vypnutí nemají. Podpora operačních systémů pro stav "off" je poměrně jednoduchá, takže není moc o čem mluvit.
Další dva stavy jsou "suspend" (pozastavený systém) a "runtime idle" (systém v nečinnosti). Pozastavený systém je systém v přechodném stavu mezi vypnutím a stavem, kdy normálně běží. Systém v nečinnosti má blíž k normálně běžícímu systému, s krátkým časem pro odezvu v případě potřeby. Podpora těchto dvou stavů se v jádře liší hned v několika věcech. Stav "suspend" se týká celého systému a je iniciován uživatelem, zatímco k "runtime idle" dochází příležitostně. V pozastaveném systému (suspended) dojde k zmrazení všech úloh, zařízení přejdou do nečinnosti, naopak v režimu nečinnosti mohou probíhat naplánované úlohy a zařízení mohou být aktivní. K pozastavení (suspend) může dojít kdykoli, kdežto do režimu "runtime idle" dojde pouze v době nečinnosti zařízení.
Ovladače daného počítače musí podporovat oba tyto stavy odděleně. Je to náročnější, ale důležité. Stejně důležitá je podpora na úrovni různých platforem. V případě SoC řešení (System on Chip) dochází ke spoustě interakcí mezi jednotlivými komponenty. Stačí, aby byl jeden z nich aktivní a zamezí přechodu celého systému do režimu úspory napájení.
Můžeme si to ukázat na příkladu. Vezměte si mechanismus TLR (latency tolerance mechanism), zabudovaný do moderních sběrnic. Kterékoli zařízení na sběrnici může naznačit, že bude vyžadovat pozornost CPU v rámci maximální doby (tolerance latence). CPU tedy udržuje tabulku popisující množství času, které je zapotřebí k návratu k aktivní operaci z každého ze svých stavů nečinnosti (idle). V okamžiku, kdy se CPU chystá přejít do stavu nízkého napětí, budou porovnány požadavky latence aktivních zařízení s hodnotami v tabulkách a určí se nejnižší možný stav, do kterého může CPU přejít. Vyžaduje-li běžící zařízení nízkou latenci, může zabránit CPU přejít do hlubokého stavu nečinnosti.
Kristen prošla části systému, které mají tento efekt hlavně na svědomí. Na prvním místě jsou to grafické procesory (GPU), jsou to složitá zařízení a nastavení správy spotřeby paměti u nich chvíli trvá. Mechanismus "RC6" popisuje sadu stavů napájení pro grafické čipy. Pokud GPU právě nepracuje, měl by být v nízkém režimu. Komprese framebufferu může také snížit využití paměti podle toho, co framebuffer zrovna obsahuje. Nižší počet odesílaných video dat znamená nižší spotřebu paměti. Kristen navrhla, aby k dosažení nejlepší spotřeby energie, uživatelé na svém zařízení nastavili jednoduchý (vysoce komprimovaný) obraz pozadí. Technologie "Panel self refresh" (např. zde na youtube) dovoluje CPU přestat na displej odesílat data v případě, že se na obrazovce nic nemění a znovu je odeslat, dojde li k nějaké změně - např. animaci.
Další problém způsobuje audio. Na spoustě systémů mohou být zvuková data směřována skrze GPU, čímž čipu brání v přechodu do nečinnosti. Audio zařízení jsou také poměrně složitá, skládají se jednak z ovladače a kodeku a řadiče musí řídit stavy napájení pro obě tato zařízení společně.
Nové USB 3.0 přidalo několik velmi užitečných nástrojů pro správu napájení. USB 2.0 podporovalo (a stále podporuje) selektivní přerušení (suspend), ale přidává mnoho latence, což snižovalo účinnost. Verze 3.0 se umí sama přerušit, ovšem pouze jsou-li suspendována všechna připojená zařízení. USB mechanismus "link power management" detekuje nízké úrovně aktivity a snižuje spotřebu energie.
SATA zařízení mohou využívat hned tři technologie pro řízení napájení. Mechanismus řízení spotřeby dokáže zařízení uspat a má-li oprávnění, vypnout sběrnici zcela. ZPODD je řízení spotřeby pro optická zařízení, Kristen ovšem nikdy nikoho neviděla tento mechanismus používat. Obecně jsou dnes optická zařízení méně častá. Řadiče SATA také nabízí jisté možnosti pro řízení spotřeby, bývají ovšem problematické, takže se v Linuxu příliš nepoužívají.
Sběrnice PCI Express nabízí celou řadu možností pro řízení napájení, včetně ASPM (Active State Power Management) pro link-level management, RTPM jako runtime funkce pro řízení napájení a zprávy o latency tolerance. Sběrnice I2C nabízí méně funkcí, ale obvykle bývá možné snížit napájení I2C řadičů. Vstupní zařízení, která se skrze I2C obvykle připojují, mají tendenci zůstávat pod napětím když jsou spuštěná, což může být problém pro správu napájení celého systému.
Samozřejmě, že také softwarová aktivita může zabránit systému od přechodu do stavu nečinnosti. Jestliže procesy trvají na chodu, zůstane CPU aktivní a jediným řešením pro úsporu energie bude pozastavený systém. I velmi krátké okamžiky běhu CPU, pokud způsobí probuzení ze stavu nečinnosti (idle), mohou významně snížit výdrž baterie.
Z toho všeho plyne, že řízení spotřeby (power management) vyžaduje koordinované úsilí. Aby se systém mohl přepnout do stavu nízkého napětí, musí se stát řada věcí. Uživatelský prostor musí být v klidu, platforma musí podporovat režim nízkého napětí na všech zařízeních a jádro musí také správně podporovat funkce pro řízení spotřeby všech zařízení. Důležitý je také správně nakonfigurovaný systém. Kristen vyjádřila svou nespokojenost s hlavními distribucemi, které nedokáží vytvořit řádný power management při instalaci, čímž vlastně marní úsilí, které bylo do podpory power managementu vloženo na nižších úrovních. Zkoordinovat všechny součásti dohromady může být dost obtížné, ale výsledek - systém, který dokáže efektivně zpracovat nejdůležitější pracovní zátěž - za to stojí.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz