Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Když jsem nedávno na svém Lenovo R61 updatoval jádro a nějaké další balíčky, nestačil jsem se po již zaběhnutém po-updatovském kolotoči (spočívající v dokompilování tp_smapi a testů, jestli ještě pořád fungují oba druhy suspendů, což ještě pořád není samozřejmé) divit. KThinkBat využívající tp_smapi fungovalo opět bezvadně, zato KPowersave nějak zblblo. Přestože obě baterie (jednu mám v UltraBay) byly plně nabité, KPowersave se tvářilo, jakože celkově má k dispozici právě 36 % možné energie. Čili počítalo podle rovnice: "nabitá baterie + nabitá baterie = z pouhých 36 % nabitá kombinace baterií".
Od nějaké doby se updatů jádra bojím jako čert kříže. Zkušenosti ukazují, že kerneloví vývojáři v honbě za novými funkcemi při spravení něčeho rozbijí něco jiné. Nemám jim to za zlé, hardwaru a požadavků na user-friendly je zřejmě až příliš. Ale uživatel, který chce mít funkční stroj, si tak musel vždycky vybrat. V 2.6.23, které přišlo s Fedorou 8, fungoval wi-fi ovladač ke kartě Intel3945 podivně (a hlavně neblikal LED-kou, takže člověk netušil, co se děje). Lepší variantou byl od intelu dodávaný IPW3945, který ovšem tu a tam zpanikařil a s ním celé jádro. Výsledek: výtuh.
Jádro 2.6.24 sice přineslo funkční IWL3945, nicméně při pokusu o hotplug výměnu baterky za DVD-ROM panikaří s následným výtuhem. To v 2.6.23 fungovalo bez problémů. Takže je na výběr: buď Wifi, nebo hotplug UltraBay slot. Existuje workaround, a to sice výměna zařízení v bayi ve stavu suspend-to-disk. Ale kdo by to tak chtěl provozovat navždycky, že?
Jádro 2.6.25 stále má funkční IWL3945, dokonce funguje hotplug v UltraBay slotu. Nicméně někoho napadlo, že staré rozhraní o stavu baterie v /proc/acpi
doplní novým, v /sys/class/power_supply/
. Zde poznámka: tato změna prý měla nastat už v 2.6.24 jádře, kde jsem ji však nazaregistroval. Zřejmě měl v té době někdo z Fedoří komunity dost rozumu na to, aby ji do distribučního jádra nezahrnoval.
Výsledkem je, že HAL z distribuce, na nějž spolehá KPowerSave, vidí místo dvou baterií čtyři, z nichž dvě ještě navíc blbě čte. Baterie v UltraBay slotu se mu zdá "doplňková", čili plná je pro něj prázdná a prázdná je naopak podle HALu plná. KPowerSave je vcelku oprávněně zmatené a taky se podle toho chová.
A řešení? Kompilaci se nejde vyhnout. Buď se musí zkompilovat jádro a zakázat jedno z těch dvou interfejsů. S HALem verze 0.5.10 lépe to v /sys
, protože toto HAL 0.5.10 stejně neumí číst správně (neboť špatně předpokládá, že dostane informaci od inotify, o něhož však nic nepřichází a nepřichází, a...). Nebo je nutné zkompilovat HAL. Verze 0.5.11 má tento problém vyřešený. A nebo, pokud chcete mít v systému (čímž teď myslím zejména ten balíčkovací) alespoň trochu pořádek, musíte použít balíčky z vývojové Fedory a přebalit je pro Fedoru 8.
Ani to není tak jednoduché, jak by mohlo vypadat. HAL-0.5.11 totiž chce (k přebalení) PolicyKit s verzí větší než 0.7 a pozor, PolicyKit s verzí větší než 0.7 požaduje HAL-0.5.11. Což je triviálně řešitelné, existují-li už hotové balíčky, horší už v situaci, kdy oba balíčky potřebujete přebalit. Postup, který fungoval je tedy přebalit a nainstalovat libsmbios z Fedory Development (o něj si řekne PolicyKit z Fedory Development), posléze přebalit PolicyKit a nainstalovat jen "natvrdo", tedy bez kontroly závislostí. No a teď je již možné přebalit HAL z Fedory Development a nainstalovat jej.
Na závěr již očekávané service haldaemon restart
a KPowerSave vidí opět pouhé dvě baterie se správnými kapacitami.
Naštěstí tedy řešení existuje. Stálo mě to "jen" hodinu práce a dvě hodiny studia vývojářských mailing-listů. Každopádně si do budoucna update jádra a dalších low-level záležitostí pěkně rozmyslím. Pokud tedy nepřijdu na vlastnost, která v 2.6.23 a 2.6.24 fungovala, v 2.6.25 ale ne...
P.S. Ještě doplnění týkající se všech notebooků Lenovo ?61: Pokud si myslíte, že máte-li v systému nabitou baterii, systém je zapojen k napájení a to náhle vypadne, že budete za každých okolností v pohodě, tak se šeredně pletete. A to v případě, že máte napájení přes dokovací stanici. Chlapci z Lenova se totiž domnívají, že když vypadne napájení docku, je to z hlediska notebooku to samé, jako kdybyste mu přímo z desky utrhli třeba sériový port. Nezávisle na OS (který ani nemusí být spuštěný) laptop prostě zmrzne, rychlost procesoru vyskočí na maximum a do hodiny spotřebuje baterku. Máte-li tento problém, updatujte BIOS a v něm pak zakažte pod Config -> Docking station veškerá Legacy zařízení. Přijdete tak o sériové a paralelní port v docku, odměnou však bude to, že až zase vypadne elektřina, notebook si nenechá vaši rozdělanou práci pouze pro sebe.
Tiskni
Sdílej:
/sys/devices/platform/smapi
a pak vždy zápisem hodnot lze přikázat nabíjení/vybíjení jedné nebo druhé baterky (a nastavit fůru dalších věcí). Nepochybně by to šlo démonizovat např. nějakým skriptem v cronu, který by mezi oběma baterkama třeba přepínal.