Na konferenci LinuxDays 2025 byl oficiálně představen nový router Turris Omnia NG.
Přímý přenos (YouTube) z konference LinuxDays 2025, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.
V únoru loňského roku Úřad pro ochranu osobních údajů pravomocně uložil společnosti Avast Software pokutu 351 mil. Kč za porušení GDPR. Městský soud v Praze tuto pokutu na úterním jednání zrušil. Potvrdil ale, že společnost Avast porušila zákon, když skrze svůj zdarma dostupný antivirový program sledovala, které weby jeho uživatelé navštěvují, a tyto informace předávala dceřiné společnosti Jumpshot. Úřad pro ochranu osobních údajů
… více »Google Chrome 141 byl prohlášen za stabilní. Nejnovější stabilní verze 141.0.7390.54 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Za nejvážnější z nich (Heap buffer overflow in WebGPU) bylo vyplaceno 25 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
eDoklady mají kvůli vysoké zátěži technické potíže. Ministerstvo vnitra doporučuje vzít si sebou klasický občanský průkaz nebo pas.
Novým prezidentem Free Software Foundation (FSF) se stal Ian Kelling.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za září (YouTube).
Vyšla kniha Počítačové programy a autorské právo. Podle internetových stránek nakladatelství je v knize "Významný prostor věnován otevřenému a svobodnému softwaru, jeho licencím, důsledkům jejich porušení a rizikům „nakažení“ proprietárního kódu režimem open source."
Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Aktuální vývojová verze jádra je 3.10-rc6 vydaná 15. června. V oznámení Linus Torvalds zmínil, že počty patchů (226 od -rc5) se lehce snižují. Ale i pokud jste luddita a ještě jste se neseznámili s rozkošemi práce s gitem, pak byste jistě měli mít zájem používat poslední jádro. Tak se na to vrhněte a odhalte případné regrese. Protože oprav tam máme všude hodně...
Stabilní aktualizace: Greg Kroah-Hartman dne 13. června vydal stabilní jádra 3.9.6, 3.4.49 a 3.0.82. Stabilní jádro 3.2.47 vydal Ben Hutchings dne 19. června.
Jádra 3.9.4, 3.4.50 a 3.0.83 se aktuálně revidují a jejich vydání lze očekávat 20. června nebo krátce poté.
OK, ještě jsem tu nenašel žádnou chybu, ale ty tvé bývají zákeřnouškééé. My neradi zákeřnoušké a musíme najít miláška!
Kvůli tomuhle kódu začínám vypadat jako Glum.
Můj názor je ten, že se vším, co má co do činění s NetWarem, je nejlepší, když zacházejí fajn lidé z Miskatonické univerzity, a to se všemi náležitostmi, když se pracuje se zárodky po dávných bozích.
-- Al Viro
Když už jsme u toho, tak křečci jsou opravdu zlá stvoření.
Samozřejmě, že můžete svého malého chlupatého křečka Ferdíka mít rádi, ale pod roztomilým a skromným zevnějškem se skrývá vypočítavé a černé malé srdce.
Takže za zaklínání křečků není potřeba se omlouvat. Můžou si za to sami.
No jasně, rád se spokojím s „Můžu to udělat později“, pokud dotyčnému nebude zase vadit mé „Začlením to později“ :)
Nedávno se na LWN psalo o prvotním návrhu od Inga Molnara týkajícího se plánovače ohleduplného ke spotřebě energie. Fragmentace zodpovědnosti za správu výkonu CPU mezi plánovačem, frequency governorem a subsystémem CPUidle musí podle něho být nahrazena jednotným řešením, které umístí rozhodování týkající se správy výkonu na místo, kde je vždy nejvíce informací: do plánovače. Po tomto prohlášení následovala velmi živá diskuze a postupně se začíná rýsovat možné řešení. I nadále jde ale o složitý problém.
Převelení zodpovědnosti za rozhodnutí týkající se správy výkonu CPU na plánovač CPU má určitý šmrnc, plánovač je snad v dobrém postavení na to, aby věděl, zda systém bude v nejbližší době potřebovat výpočetní výkon. Ale tato myšlenka hned naráží na probém kvůli jinému trendu v jádře: rozhodnutí týkající se správy výkonu se přesouvají z plánovače do nízkoúrovňového kódu ovladačů. Jak Arjan van de Ven poznamenal už v květnu v diskuzi na Google+, politika správy výkonu u procesorů značky Intel se v posledních jádrech řeší v kódu specifickém pro tato CPU:
Ačkoliv si uvědomuji, že toto může být kontroverzní, tak říkám, že kombinujeme řídící algoritmus s ovladačem CPU na jediném místě. Pravdou je, že takové řídící algoritmy jsou specifické pro konkrétní CPU, idea obecných governorů „pro všechna CPU“ je už od začátku mylná; chování hardwaru je pro algoritmy klíčové.
Arjan upozorňuje, že debaty kolem řízení frekvencí a napětí CPU se nedotýkají jedné důležité věci: současné procesory mají komplikovanější správu výkonu a mezi jednotlivými generacemi hardwaru se značně liší. Plánovač není správným místem pro veškeré nízkoúrovňové informace; místo toho patří do nízkoúrovňového kódu specifického pro daný hardware.
Obecně ale lidé souhlasí, že předávání více informací mezi plánovačem a nízkoúrovňovým kódem pro správu výkonu by bylo ku pomoci. Zejména je velký zájem o lepší integraci mezi vyvažováním zátěže v plánovači (který rozhoduje o tom, jak rozdělit procesy mezi dostupnými procesory) a logikou správy výkonu. Při vyvažování zátěže se ví, jaké jsou aktuální potřeby a je možné dělat nějaké odhady týkající se blízké budoucnosti; proto dává smysl, že by se ten samý kód účastnil rozhodování, jaké procesorové prostředky by pro danou zátěž měly být k dispozici.
Na základě těchto myšlenek a dalších postřehů Morten Rasmussen zaslal návrh přepracovaného plánovače, ohleduplného ke spotřebe energie. Současný plánovač by byl rozdělen do dvou oddělených modulů:
Plánovač CPU bude řešit plánování jako doposud. Plánovač výkonu si zase bude brát informace o zátěži od plánovače CPU a podle potřeb bude měnit nastavení výkonu systému tak, aby to lépe odpovídalo této zátěži. Mezi tyto změny může patřit přesun CPU mezi stavy výkonu [power state] nebo uspání (nebo probuzení) CPU. Plánovač výkonu by komunikoval se současnými ovladači pro správu frekvence, ale tyto ovladače by nadále byly oddělené a specifické pro konkrétní hardware. Při tomto návrhu by vyvažování zátěže zůstalo pod kontrolou plánovače CPU; k přesunu do plánovače výkonu by nedošlo.
Zajisté je tu spousta problémů, které je nutné vyřešit mimo jednoduchou implementaci plánovače výkonu a definice rozhraní k plánovači CPU. Plánovač CPU nadále musí získat schopnost používat procesory s různými výpočetními schopnostmi; je to nutné pro architekturu big.LITTLE, ale i pro pokročilejší správu stavů výkonu. Aktuálně se procesům započítává, kolik času stráví během na CPU; to jednoznačně není fér vůči procesům spouštěným na pomalejším procesoru. Proto bude nutné používat jinou jednotku než čas, například počet instrukcí. Plánovač CPU si bude muset být vědom uplatňované politiky správy výkonu. Plánování procesů tak, aby byl využit režim „turbo boost“ (kdy je možné přetaktovat jediné CPU za předpokladu, že ostatní CPU jsou nečinná), zůstává otevřenou otázkou. Teplotní omezení přidávají do rovnice další proměnné. A tak dále.
Je také možné, že se oddělení plánování CPU a výkonů nepovede; Morten to popsal takto:
Jsem si vědom, že rozhodování plánovače a plánovače výkonu nemusí být oddělitelné, takže se možná rozhodneme je sloučit. I tak si myslím, že stojí za to snažit se oddělit rozhodování o výkonu od plánovače, leda by se ukázalo, že to jinak nejde.
I s těmito nejistotami se zdá přístup používající „plánovač výkonu“ jako dobrý začátek; Morten a jeho kolegové mají v plánu v brzké budoucnosti zaslat prvotní implementaci plánovače výkonu. Pak se snad od Inga dozvíme, jak dobře tento návrh splňuje požadavky; on (stejně jako ostatní vývojáři plánovače) se od posledních debat drželi stranou. Tak či tak to vypadá, že komunita bude na novém plánovači pracovat docela dlouho.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Jenže tady je to zcela určitě špatně:
… dne 13. června vydal stabilní jádra 3.9.6, … Jádra 3.9.4, … se aktuálně revidují a jejich vydání lze očekávat 20. června nebo krátce poté …
Reality check: 3.9.4 vyšlo 24. května, 3.9.6 13. června a 3.9.7 20. června. Takže místo 3.9.4 má být 3.9.7.