Richard Hughes oznámil, že službu Linux Vendor Firmware Service (LVFS) umožňující aktualizovat firmware zařízení na počítačích s Linuxem, nově sponzoruje také společnost HP.
O víkendu proběhla demopárty Outline 2026. Publikována byla prezentovaná dema. Upozornit lze na 16 bajtové, opravdu šestnáct bajtové, zvukově obrazové demo Wake Up! 16b (YouTube).
Byla vydána nová verze 9.5 multiplatformní digitální pracovní stanice pro práci s audiem (DAW) Ardour. Přehled novinek, vylepšení a oprav v poznámkách k vydání a na YouTube.
Dnes a zítra probíhá vývojářská konference Google I/O 2026. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
Canonical vydal Ubuntu Core 26. Vychází z Ubuntu 26.04 LTS a podporováno bude 15 let. Ubuntu Core je minimální neměnný operační systém určený pro vestavěné systémy.
Bylo vydáno OpenBSD 7.9. Po dlouhé době opět se songem: Diamond in the Rough.
Byl vydán Mozilla Firefox 151.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 151 bude brzy k dispozici také na Flathubu a Snapcraftu.
Elon Musk prohrál soudní spor se společností OpenAI, která se podle jeho žaloby odchýlila od původně uváděného cíle vyvíjet umělou inteligenci (AI) ku prospěchu lidstva. Porota včera po necelých dvou hodinách dospěla k jednomyslnému závěru, že Musk žalobu podal příliš pozdě. Musk byl jedním ze spoluzakladatelů společnosti OpenAI, která vznikla v roce 2015 a vyvinula populární chatovací systém ChatGPT. V roce 2018 na svůj post ve vedení
… více »Byla vydána nová verze 10.4 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Opraveny jsou zranitelnosti Copy Fail a Dirty Frag. Přibyl nový obraz pro Orange Pi 5B.
Pokud je zranitelnost Linuxu v nepoužívaném jaderném modulu, lze ji jednoduše vyřešit zakázáním automatického načítání tohoto konkrétního zranitelného modulu. Projekt ModuleJail si klade za cíl zvýšit bezpečnost Linuxu zakázáním automatického načítání všech nepoužívaných jaderných modulů. Jedná se o skript, který dá všechny nepoužívané jaderné moduly na blacklist (/etc/modprobe.d/modulejail-blacklist.conf).
Původně jsem chtěl tenhle dotaz do pléna hodit do poradny, ale nebylo mi jasné do které ze stávajících skupin dotazů bych ho měl dát. Takže mi nezbylo než se otázat takhle. Zpracovávám v GIMPU skenované dokumenty, což obnáší aplikaci nejrůznějších filtrů, atp. Některé jsou náročné a trvají déle, jiné tak náročné nejsou. Bohužel ale netuším jakým způsobem bych mohl zjistit jak přesně trvají dlouho
Jde o to, že stejného výsledku lze dosáhnout mnoha různými způsoby, které se ovšem v konečném důsledku liší tím, kolik sežerou času a výpočetního výkonu. Což se dá ovšem jen těžko předem posoudit, když nevím, jak dlouho operace s určitými parametry trvá. Tj. jestli se vyplatí, nebo už ne.
Nenapadá někoho řešení, jakým způsobem by se to dalo zjistit?
Je možné že na to GIMP má i nějaké udělátko. Jenom o něm nevím, protože způsob, jakým je dokumentován, je taky pěkná tragédie.
Ale pokud budete mít k tomu nějakou užitečnou poznámku, určitě ji uvítám.
Aktuálně jsem vyřešil problém sice humpolácky, nicméně způsobem dostačujícím. Sledováním procesu přes strace.
strace -tT -e trace=read -p …
Chci-li zjistit, jak dlouho ta operace bude trvat, nahodím výše uvedeným způsobem strace na spuštěnou instanci gimpu.
Takhle nějak to vypadá např. při vypnutí zobrazení některé vrstvy:
14:42:36 read(4, "\1\0\0\0\0\0\0\0", 16) = 8 <0.000090> 14:42:36 read(10, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0`\0\0\0N\10\6\0\0\0\337>\23"..., 65536) = 8708 <0.000178> 14:42:36 read(10, "", 65536) = 0 <0.000114> 14:42:41 read(4, "\1\0\0\0\0\0\0\0", 16) = 8 <0.000044>
Jak vidíte, překreslení obrazu trvalo cca 5 sekund. A následující výpis demonstruje, jak to vypadalo, po aplikaci filtru "Rozostření pomocí mediánů". Něž se vygeneroval nový náhled, zabralo to 39 sekud.
14:45:05 read(4, "\1\0\0\0\0\0\0\0", 16) = 8 <0.000102> 14:45:05 read(4, "\1\0\0\0\0\0\0\0", 16) = 8 <0.000093> 14:45:45 read(4, "\1\0\0\0\0\0\0\0", 16) = 8 <0.000157> 14:45:46 read(4, "\1\0\0\0\0\0\0\0", 16) = 8 <0.000160> 14:45:46 read(10, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0`\0\0\0N\10\6\0\0\0\337>\23"..., 65536) = 8708 <0.000174> 14:45:46 read(10, "", 65536) = 0 <0.000123> 14:45:55 read(4, "\1\0\0\0\0\0\0\0", 16) = 8 <0.000022>
Jak jste se mohli dozvědět z mého následujícího blogpostu o GIMPu, při hledání nástroje jsem – víceméně náhodou – narazil na to, kde má GIMP vlastní udělátko na sledování zátěže, které si můžete otevřít v postraním doku Okna → Dokovatelná dialogová okna → Sledování zátěže (Windows → Dockable dialogs → Dashboard) .
Nicméně to co mne zajímalo, se z něj stejně nedá zjistit. Ale může vám to pomoci při práci s velkými soubory, při kterých začnete narážet na limity vašeho HW k tomu, abyste zbytečně neprodlužovali svou práci tím, že budete mít zbytečně velké soubory s desítkami vrstev v situaci, kdy to není nutné. Více vi odkazovaný blogpost.
Tiskni
Sdílej: