Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Evropská komise (EK) nařídila americké společnosti Meta, že musí znovu umožnit bezplatný přístup konkurenčním obecně zaměřeným asistentům umělé inteligence (AI) k WhatsAppu a tento přístup musí zachovat až do ukončení antimonopolního šetření. Opatření je dočasné a má zabránit vážnému a nevratnému poškození konkurence na rychle rostoucím trhu s obecnými AI asistenty. Meta uvedla, že se proti rozhodnutí odvolá.
Společnost Anthropic představila AI modely Claude Fable 5 a Claude Mythos 5. Claude Fable 5 je první model třídy Mythos určený pro běžné použití.
Byla vydána nová stabilní verze 3.24.0, tj. první z nové řady 3.24, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Přehled novinek v poznámkách k vydání.
Na čem pracují vývojáři v Rustu napsaného mikrokernelového unixového operačního systému Redox OS (Wikipedie)? Byl publikován přehled vývoje za květen. Vypíchnout lze nový scheduler EEVDF nebo port desktopového prostředí Xfce na Redox OS.
Upozornění pro uživatele Asahi Linuxu: Neaktualizujte macOS na verzi 27 Golden Gate! Apple změnil detekci spouštěcích oddílů. Po aktualizaci oddíl s Asahi Linuxem nevidí. Snad je to jenom chyba.
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: