KDE Plasma 5.27 LTS za dveřmi, Plasma 6 za rohem
Vývoj desktopu KDE se v posledním týdnu a kousek dostal do přelomové fáze. Finišují práce na posledním pětkovém vydání Plasmy 5.27, které bude současně LTS, tedy s dlouhodobou podporou a v téže době se viditelně posouvá vývoj příští verze Plasmy 6.0, která bude první postavená na frameworku Qt6.
Předevčírem napsal Nate Graham na svém blogu, že Plasma 5.27 LTS bude vydána během pár dnů. kdo se drží vývojové větve, už ji nyní fakticky provozuje. Novinek je logicky poskrovnu, vylepšení více, jde o poslední třešničku na pětkovém dortíku. Předevčírem už byly pouhé tři regrese bránící vydání a jak Nate dodává, důraz na vyladěnost místo nových vlastností se vyplatí (dodejme: z dlouhodobého hlediska). Jednou z věcí, na kterou se tvůrci soustředili, je oprava podpory vícemonitorových setupů. Další je třeba spouštění XWaylandu pouze v případě, že si to nějaká aplikací žádá – platí samozřejmě pro běh Plasmy na Waylandu.
Šestková Plasma
Krátce ještě připomeňme Nateho povídání o šestkové Plasmě ze začátku měsíce. Letmý přehled toho, co se v KDE Frameworks 6 a KDE Plasma 6 řeší, je na domovském webu, procest portování celého desktopu, tedy Frameworks + Gear + Plasma na Qt6 lze sledovat na vlastní doméně, aktuální stav říká, že portováno je na Qt6 už 362 z 580 projektů desktopu a stále platí informace, že Plasma 5.27 bude po svém vydání udržována minimálně do vydání Plasmy 6.0, která zatím nemá stanovené datum vydání.
Z aktuálních novinek vyvíjené Plasmy 6.0 Nate vypichuje rozšíření škály podporovaných nastavení pro výchozí aplikace činností v systémovém nastavení. Dále pak vylepšení uživatelského rozhraní pro přehrávač Elisa, rozhraní pro akcentové barvy, zobrazení procent stavu akumulátoru u bezdrátových zvukových zařízení ve widgetu při jejich přepnutí či vylepšení vzhledu rohů QtQuick aplikací.
Transmission 4.0.0 přechází na čistší C++
Nová verze 4.0.0 oblíbeného bittorrent klienta Transmission se nese v duchu řady změn v kódu projektu, který tvůrci převedli ze starého C90 s řadou ručně doháčkovaných věcí na modernější C++ využívající standardizované knihovny. Díky tomu se objem kódu projektu zmenšil o 18 %.
Zmizely dosavadní žáby na prameni, kdy náročnost na cykly CPU je nižší o 50 % a při testu s 25 tisíci otevřených torrentů je program víceméně limitován jen I/O přenosy, ničím jiným a množství potřebné alokované paměti oproti trojkové verzi kleslo o celých 70 %. Části projektu také využívají kompresi pomocí knihovny libdeflate, značně rychlejší než výchozí zlib.
GTK klient byl portován na gtkmm, webový klient byl přepsán do modernější JavaScriptu a již nevyužívá jQuery – celý zaGZipovaný klient zabírá jen 68 kB a podporováno je i použití na mobilních zařízeních. Tvůrci děkují uživatelské komunitě za mnoho přínosů do projektu a dodávají, že další a další pull requesty jsou stále vítány.
Nově pak přibyla podpora pro BitTorrent v2 a hybridní torrenty (podpora jejich tvorby se teprve dokončuje). Nově přidané seedy se spouští okamžitě a jsou ověřovány za běhu, nečeká se tedy nejprve na jejich ověření před spuštěním seedování. Podporována jsou IPv6 blocklisty. U nově vytvářených torrentů lze specifikovat velikost částí.
Audacious 4.3 Beta přináší Qt6, PipeWire a návrat GTK3 rozhraní
Přehrávač Audacious přišel se čtyřkovou řadou s přechodem z GTK na Qt (byl jsem jedním z těch, které to s ohledem na vzhledovou spíše-ne-funkčnost Qt aplikací v tmavém nastavení GNOME 3.xx nenadchlo). Nyní tvůrci u vývojové verze budoucího vydání Audacious 4.3 přináší mimo jiné právě návrat GTK3 rozhraní mezi nabízená, jakkoli je výchozím GTK stále GTK2. Na Qt straně se nadále pilně pracuje na Qt6, práce notně pokročily, ale výchozím je stále Qt5 (i s ohledem na výše uvedené o KDE Plasmě beztak rozumné rozhodnutí).
Z dalších novinek tu máme nativní plugin pro výstup před PipeWire, zahrnutí vlastního dekodéru formátu Opus. Z opravených chyb tu máme třeba zvýšení limitu velikosti playlistů M3U z 16 na 256 MB. Podrobnosti v oznámení Audacious 4.3-beta1 na domovském webu projektu.
FFmpeg chce více AVX-512 optimalizací
Nějaké optimalizace pro instrukční sadu (sady) AVX-512 už ve FFmpegu najdeme, ale není jich mnoho. Vývojáři by rádi přitvrdili, dodejme, že to dává smysl zejména s ohledem na to, jak povedenou implementaci AVX-512 předvedla AMD v procesorech generace Zen 4 (narozdíl od Intelu, jehož dosavadní implementace znamenaly výrazné snížení taktů CPU za současně výrazného zvýšení spotřeby, takže často se použití AVX-512 oproti AVX-2 téměř nevyplatilo). A dodejme, že jakou doufejme předvedou nově uváděné Xeony.
O věci hovořil vývojář FFmpeg Kieran Kunhya na FOSDEMu 2023 v Brusselu [viz jeho prezentace v PDF, plus příslušné WebM video]. Připomínal AVX-512 optimalizace v AV1 dekodéru dav1d, konstatoval smutný fakt, kdy Intel odstranil podporu AVX-512 v CPU od 12. generace Core Alder Lake (navzdory tomu, že podpora se v křemíku nachází). Podle prvních dílčích testů to vypadá, že prostor pro solidní optimalizace (de)kodérů zde je, zejména u formátu AV1 s jeho velkými velikostmi bloků (například u x264 bude případný přínos viditelně menší).
ČLÁNKY DO MAILU