Ubuntu 26.04 (Resolute Raccoon) už nebude v desktopové instalaci obsahovat GUI nástroj 'Software & Updates'. Důvodem jsou obavy z jeho složitosti pro běžné uživatele a z toho plynoucích bezpečnostních rizik. Nástroj lze doinstalovat ručně (sudo apt install software-properties-gtk).
Thomas Dohmke, bývalý CEO GitHubu, představil startup Entire - platformu pro spolupráci vývojářů a agentů umělé inteligence. Entire získalo rekordních 60 milionů dolarů na vývoj databáze a nástrojů, které mají zefektivnit spolupráci mezi lidmi a agenty umělé inteligence. Dohmke zdůrazňuje potřebu přepracovat tradiční vývojové postupy tak, aby odpovídaly realitě, kdy většinu kódu produkuje umělá inteligence.
Toyota Connected North America oznámila vývoj open-source herního enginu Fluorite, postaveného na frameworku Flutter. Pro renderování grafiky využívá 3D engine Filament od společnosti Google a dle svého tvrzení cílí na konzolovou kvalitu her. Fluorite je zřejmě navržen tak, aby fungoval i na méně výkonném hardware, což naznačuje možnost použití přímo v ICE systémech vozidel. Zdrojový kód zatím zveřejněný není.
Byl vytvořen nástroj a postup pro překonání věkového ověření platforem Discord, Kick, Twitch, Snapchat (a možná dalších), kód je open-source a dostupný na GitHubu. Všechny tyto sítě používají stejnou službu k-ID, která určuje věk uživatele scanem obličeje a na původní server posílá pouze šifrovaná metadata, ty ale sociální síť už nedokáže sama nijak validovat, 'útok' spočívá ve vygenerování a podstrčení legitimně vypadajících ověřovacích metadat.
Jihokorejská kryptoměnová burza Bithumb přiznala vážné selhání interních systémů, které ji vystavilo riziku sabotáže a nezabránilo chybné transakci v hodnotě přes 40 miliard dolarů (814 miliard Kč). Druhá největší kryptoměnová burza v Koreji minulý týden při propagační akci omylem rozeslala zákazníkům zhruba 620 000 bitcoinů místo 620 000 wonů (8700 Kč). Incident vyvolal pokles ceny bitcoinu o 17 procent. Většinu
… více »Google Chrome 145 byl prohlášen za stabilní. Nejnovější stabilní verze 145.0.7632.45 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Zpátky je podpora grafického formátu JPEG XL, viz Platform Status. Odstraněna byla před třemi lety. Nový dekodér JPEG XL jxl-rs je napsán v Rustu. Zobrazování JPEG XL lze vyzkoušet na testovací stránce. Povolit lze v nastavení chrome://flags (Enable JXL image format).
Byla vydána nová verze 1.26 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
CrossOver, komerční produkt založený na Wine, byl vydán ve verzi 26. Přehled novinek v ChangeLogu. CrossOver 26 vychází z Wine 11.0, D3DMetal 3.0, DXMT 0.72, Wine Mono 10.4.1 a vkd3d 1.18. Do 17. února lze koupit CrossOver+ se slevou 26 %.
KiCad je nově k dispozici také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit [Mastodon, 𝕏].
Šenčenská firma Seeed Studio představila projekt levného robotického ramena reBot Arm B601, primárně coby pomůcky pro studenty a výzkumníky. Paže má 6 stupňů volnosti, dosah 650 mm a nosnost 1,5 kilogramu, podporované platformy mají být ROS1, ROS2, LeRobot, Pinocchio a Isaac Sim, krom toho bude k dispozici vlastní SDK napsané v Pythonu. Kompletní seznam součástek, videonávody a nejspíš i cena budou zveřejněny až koncem tohoto měsíce.
… více »Současný vývojový kernel nese označení 4.5-rc2. Vydán byl 31. ledna a podle Linuse se práce na vydání zrychlily: „Ještě v pátek jsem měl v plánu zmínit, jak prima je nový trend malých rc2 vydání, protože až do pátku nebylo příliš mnoho žádostí o zařazení. Jenomže se ukázalo, že všechny žádosti se objevily až o víkendu a 4.5-rc2 nakonec až tak malým vydáním nebude. Za víkend se prakticky zdvojnásobila.“
Stabilní aktualizace: 3.14.60 a 3.10.96 byly vydány 29. ledna a o dva dny později je následovaly 4.4.1, 4.3.5 a 4.1.17.
*Nejhorší* chyby jsou ty, kde kód dává smysl a na lokální úrovni funguje bez problému, ale kombinace dvou nebo tří částí kódu, které jsou jednotlivě srozumitelné, z jakýchsi podivných důvodů nefunguje – kvůli absenci tranzitivity. S tím je opravdu těžké se vypořádat.
Vskutku, paměťový model definovaný výhradně testy lakmusovými papírky by se dal kvalifikovat jako exotická forma mučení.
Bylo nebylo, blokové I/O plánovače, zodpovědné za optimalizování proudu I/O požadavků k úložným zařízením, byly oblastí intenzivního vývoje. Charakteristika rotujících disků znamenala, že výkon I/O se hodně různil podle toho, v jakém pořadí byly požadavky vyřizovány. Změny v hardwaru (hlavně přechod k SSD) způsobily úpadek motivace na práci v této oblasti. To nejlepší, čeho může u moderních disků I/O plánovač dosáhnout je, že zůstane stranou. I přesto přetrvává aspoň nějaký zájem na vylepšování I/O plánovačů a dokládá to zejména návrat plánovače BFQ (budget fair queuing).
Plánovač BFQ vyvinuli Paolo Valente a Arianna Avanzini a naposledy se o něm psalo v červnu 2014. Je odvozen od plánovače CFQ I/O, který je obsažen v současných jádrech. Na většině systémů se jedná o výchozí plánovač, ačkoliv někteří uživatelé s rychlejšími disky jej nahrazují některým z jednodušších plánovačů. Nicméně, BFQ se od svých kořenů v CFQ za tu dobu hodně odchýlil.
Pro podrobnosti o tom, jak BFQ funguje, viz zmíněný článek z roku 2014. Následuje jen velmi zkrácené shrnutí. Pro jakékoli blokové zařízení BFQ vytvoří frontu požadavků pro každý proces v systému. Každá fronta získá rozpočet, který představuje množství I/O provozu, které může vyslat k diskové jednotce v daném plánovacím cyklu. Rozpočet je stanoven plánovačem podle priority I/O a pozorováním I/O chování procesu. Odesílaný kód (pod názvem B-WF2Q+) obsluhuje každou frontu zvlášť; v jednotlivých krocích je uvolněno určité množství I/O až do výše přidruženého rozpočtu. Správným nastavením rozpočtů se BFQ snaží zajistit, aby každý z procesů dostal spravedlivé množství dostupného I/O pásma, a to v celkem malých mezích latence.
Hlavní myšlenka je jednoduchá, ale reálný svět je o něco složitější, a tak BFQ, stejně jako předtím CFQ, nashromáždil velké množství heuristik, jejichž cílem je zlepšení výkonu v konkrétních oblastech. Dochází ke sloučení front spolupracujících procesů ve stejné oblasti disku, což umožňuje větší konsolidaci požadavků. Pokud proces vykonávající požadavek na čtení vyprázdní svou frontu před vyčerpáním rozpočtu, bude zařízení na krátkou dobu označeno jako nečinné, aby tak proces získal šanci vytvořit další požadavek. Procesy, identifikované jako soft realtime (ty s mírnými požadavky na šířku pásma a pravidelně přerušovaným cyklem žádostí) získají vyšší prioritu, stejně jako právě začínající procesy atd.
Podle všeho se BFQ od června 2014 příliš nezměnilo. Popisované heuristiky jsou více méně stejné. Jistě došlo k odstranění chyb a zlepšení výkonu na základě zkušeností z využívání plánovače v ostrém provozu – plánovač se dodával v několika méně rozšířených distribucích a zřejmě byl využíván v některých telefonech. Původní patche pocházely od Paola z univerzity v Modeně a Reggio Emilia, ale ty současné chodí z adresy v Linaru, což by mohlo naznačovat nějaký komerční zájem.
Plánovači BFQ se dostalo v roce 2014 dobrého přijetí – na rozdíl od navrženého postupu zavedení do jádra. V té době byl BFQ přidán jako nový I/O plánovač spolu s ostatními do kernelu, bohužel komunita kolem jádra neměla vůbec chuť na další plánovač, natož takový, který by se tolik podobal plánovači CFQ. Vzhledem k tomu, že BFQ je hlavně vylepšením CFQ, bylo Paolovi doporučeno zapracovat na sérii patchů vyvíjejících CFQ požadovaným směrem. To se snadněji řekne než udělá, přestože BFQ původně z CFQ pochází. Tyto dva plánovače se během vývoje BFQ značně vzdálily. V důsledku tohoto požadavku zmizel BFQ plánovač z e-mailové konference na více než rok.
Jeho návrat naznačuje, jak mají BFQ vývojáři v plánu uspokojit požadavek, který jim byl zadán. Nový patchset se skládá z 22 změn, rozdělených do tří kroků:
V době psaní tohoto článku nebyl ještě nový patch nikým komentován, takže se teprve ukáže, zda komunita patch přijme či nikoli. Dá se říct, že jaderní vývojáři mají rádi kód, který se vyvíjí po menších krocích. Velký kus nového kódu v jediném patchi je složitý na kontrolu a je velké riziko problémů s výkonem či regresemi. CFQ se hojně využívá, jeho destabilizace po několik vydání není nejlepší nápad. Je tedy možné, že tento příspěvek nebude o moc úspěšnější než ten předešlý.
Na druhou stranu, možná v současné době neexistuje lepší způsob, jak BFQ do kernelu dostat. Pokud by nadšení pro BFQ bylo nízké, znamenalo by to, že bude odsouzen k životu mimo hlavní strom i nadále. Jenže BFQ se zdá být prokazatelně lepší než CFQ a jeho heuristiky jsou srozumitelnější, takže motivace pro zavedení do jádra by tu byla. Lze si představit, že vybudovat kvalitní kód bude nějaký čas trvat, takže bychom se BFQ mohli dočkat třeba ve vývojovém cyklu 4.6. Tou dobou by vývojová komunita mohla přijít na způsob, jak tento kód začlenit a jak ho učinit dostupným celé uživatelské komunitě.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: