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.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Společnost OpenAI představila text-to-video AI model Sora 2 pro generování realistických videí z textového popisu. Přesnější, realističtější a lépe ovladatelný než předchozí modely. Nabízí také synchronizované dialogy a zvukové efekty.
Aktuální vývojová verze jádra je 3.12-rc6 vydaná 19. října. Linus k ní řekl: Během uplynulého týdne se nic velkého neudálo a příští týden bude asi také poklidný, jelikož hodně hlavních správců bude v Edinburghu na KS [Jaderný sumit].
Stabilní aktualizace: verze 3.11.6 a 3.10.17 vyšly 18. října a byly následovány verzemi 3.4.67 a 3.0.101 22. října. Toto je konec údržby řady 3.0: Další vydání 3.0.x už dělat NEbudu. Pokud stále závisíte na řadě 3.0.x, měli byste přejít na novou řadu 3.10.x nebo v horším případě na 3.4.x.
[Stromy zařízení mají] mnoho výhod. Bylo by skvělé jich využívat, dokud to nebude mít dopad na rychlost změn a ochotu rozvíjet kód, což vždy bylo silnou stránkou vývojových procesů v jádře. Tato přednost je až příliš cenná na to, abychom ji vyměnili za vizi „Strom zařízení jako ABI“.
-- Matt Porter
Jsi si jistě vedom toho, že dle obecné shody má zodpovědnost za vývoj generické implementace třetí člověk, co ji přepisuje, což pro změnu v tomto případě nejsem já...
Pokud jste firma, co si myslí, že vaše drobná změna v jádře vám dává náskok před konkurencí, pak asi budete čelit ekonomickým problémům. Měli byste se raději starat o to, abyste vyrobili ten nejlepší hardware za co nejnižší cenu.
Pro ty z vás, kteří se zajímají o nftables, náhradu subsystému pro firewall v jádře, je tu novinka: tento kód byl právě přetažen do stromu net-next. To znamená, že pokud se neobjeví nějaké problémy, tak dojde k začlenění během vývojového cyklu 3.13. Tento kód ještě není připraven na to, aby nahradil iptables, ale po zařazení do hlavní řady by se rychlost prací měla zvýšit. Kdokoliv, kdo by chtěl nftables vyzkoušet, si může přečíst rychlé howto.
První den na Jaderném sumitu 2013 byl vyhrazen pro různé drobné mini-sumity na všelijaká témata. Jedním z těchto témat byla kontroverzní oblast plánovače, který bere ohled na spotřebu energie [power-aware scheduling]. Byla zaslána spousta patchů, které se snaží vylepšit plánovač, ale žádný z nich se hlavní řadě jádra nepřiblížil. Na tomto setkání se sešli vývojáři ze světa embedded zařízení a hlavní vývojáři plánovače, aby se pokusili věci posunout kupředu; ještě se uvidí, jestli se jim to podařilo, ale jisté kroky se podařilo určit.
Jedním z organizátorů této debaty byl Morten Rasmussen, autor sady patchů big LITTLE MP. Začal programem tohoto setkání a podpůrnými slajdy; probírala se tato témata:
Pokusil se diskuzi otevřít tématem subsystémů cpufreq a cpuidle, ale netrvalo dlouho, než se konverzace posunula jinam.
Ingo Molnar přišel se stížností: žádná z prací na správě výkonu nezačíná měřeními chování výkonu systému. Bez sourodého přístupu k měření dopadů patche není žádný pořádný způsob, jak rozhodnout, které patche by měly být začleněny. Nemůžeme začlenit patche do plánovače jen na základě víry, že věci nějak zlepší.
Poté se rozběhla diskuze o tom, jak by taková metrika měla být vytvořena. Je jasné, co by vývojáři plánovače chtěli: jak dlouho trvalo spustit určený objem práce a kolik energie bylo spotřebováno? Někdo má zájem znát i nejhorší latenci, kterou zátěž zaznamenala během svého běhu. Jakmile budeme mít opětovně vytvořitelná čísla pro tyto kvantity, pak by mělo být možné zjistit, které patche pomáhají při jaké zátěži a posouvají věci kupředu.
V této oblasti se ale nepodařilo dosáhnout shody všech. Mark Gross z Intelu tvrdil, že tento typ metriky výkonu je „cestou do pekla“. Místo toho řekl, že benchmarky výkonu by se měly zaměřit na nízkoúrovňové chování jako stavy spánku procesoru ("C"). Pro jakýkoliv stav spánku musí procesor zůstat v tomto stavu po určitou dobu, než dojde ke skutečným úsporám. Proto musí subsystém cpuidle dělat odhady, jak dlouho musí být procesor nečinný, než vybere odpovídající stav spánku. Doba nečinnosti je něco, co se pak dá měřit; později pak člověk může získat přehled o tom, jak moc odpovídají odhady jádra skutečnosti. To je podle Marka benchmark, který by jaderní vývojáři měli používat.
Jiní argumentovali, že odhad času nečinnosti je nízkoúrovňové měření, které nemusí moc dobře odpovídat tomu, co uživatelé vlastně chětjí: mít práci hotovou rychle, bez nepřijatelných latencí a s minimální spotřebou energie. Ale získat skutečná měření spotřeby je těžké; výrobci procesorů nejsou ochotní tyto údaje jádru dávat. Žádnou dobrou sadu metrik pro zhodnocování patchů pro plánovač se tedy nepodařilo najít. Ingo nakonec řekl, že první patch, který do adresáře tools přidá rozumný benchmark zaměřený na spotřebu energie, může být zařazen; pak se může doladit.
Odtamtud se diskuze přesunula k tématu, jak zlepšit charakteristiku spotřeby v plánovači. Bylo odsouhlaseno, že je nutné mít lepší mechanismus, jak by aplikace mohla jádru sdělit své požadavky na latenci. S těmito požadavky na latenci je pak nutné opatrně zacházet: není možné držet všechna CPU v systému vzhůru jen proto, že aplikace na jednom z nich potřebuje latenci v určitých mezích.
Probíralo se přidání určitého modelu využívání energie do simulátoru – buď nástroje linsched, nebo perf sched – aby bylo možné dělat standardizované testování patchů s určitou zátěží. Linsched byl vyvíjen stážistou v Google, ale práce nebyla dokončena, proto ještě není připraven pro zařazení. Ingo poznamenal, že prostředky nutné pro odvedení této práce jsou k dispozici; konec konců tu máme vývojáře, jež mají zájem na začlenění kódu pro zohlednění spotřeby energie do plánovače.
Rafael Wysocki se zeptal vývojářů plánovače: jaké informace od hardwaru potřebujete na to, abyste dělali lepší rozhodnutí při plánování? Odpověděl Paul Turner: náklady na běh systému při daném nastavení; Peter Zijlstra dodal, že by rád znal náklady na spuštění dodatečného CPU. Markovou odpovědí bylo to, že toto vše závisí na tom, jaká generace hardwaru se používá. Intel obecně není moc ochoten tyto informace zpřístupnit, což je postoj, který moho vývojářů plánovače hněvá.
Jak čas běžel, tak se během diskuze podařilo víceméně ujasnit, co by komunita okolo plánovače chtěla. K infrastruktuře domén plánování by měla být připojena určitá metrika nákladů; měla by plánovači říkat, jaká je cena spuštění daného procesoru. Tato informace by se musela objevovat na více úrovních; spuštění prvního procesoru ve fyzickém jiném balení bude například jednoznačně stát víc než přidání procesoru v již aktivním balení.
S tímto souvisí koncept stavů výkonu („P"), který je obecně považován za “frekvenci CPU". Hovořit o frekvenci je poněkud zastaralé, ale přetrvává to tak v subsystému cpufreq, který by, jak skoro všichni souhlasili, měl být odstraněn. Plánovač musí rozumět nákladům (a změnám ve výkonu) spojeným se změnou P stavu; to by mu umožnilo rozhodovat se mezi navýšením P stavu a přesunem úlohy na nové CPU. Jak by procesor tyto údaje zveřejňoval, není jasné, ale pokud by byly dostupné, mohlo by se díky tomu dělat lepší rozhodnutí.
Jak by se tato rozhodnutí měla dělat, zůstává nejasné. Mluvilo se o přípravě sady standardizovaných zátěží, ale to je předčasné. Paul navrhoval, že by mohla vzniknout sada „příběhů“, které by v lidsky čitelné formě popisovaly určité zátěže. Jakmile by byla sestavena takováto sada příběhů, pak by vývojáři mohli začít hledat společné části, na základě nichž by pak mohli vymyslet algoritmy pro lepší a energeticky ohleduplnější plánování.
Krátce se mluvilo o Mortenových nedávných patchích pro plánovač. Dohodlo se, že představují rozumný začátek práce na přesunu povědomí o frekvenci CPU a nečinnosti do plánovače. Bylo navrženo, že by se nejprve do plánovače přesunulo cpuidle; většina vývojářů by aktuálně nejradši viděla odstranění cpufreq.
V tento moment bylo účastníkům připomenuto, že oběd začal už před necelou hodinou. Materiály, na základě kterých by vývojáři mohli pracovat, jsou přinejmenším stále vágní, ale přesto se podařilo dopracovat k některým hodnotným závěrům, kterým vévodí potřeba vytvořit sadu použitelných metrik. To by mělo stačit na to, aby se vývoj mohl drobnými krůčky posouvat vpřed.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz