Anthony Enzor-DeMeo je novým CEO Mozilla Corporation. Mozillu převzal po dočasné CEO Lauře Chambers. Vybudovat chce nejdůvěryhodnější softwarovou společnost na světě. Firefox by se měl vyvinout v moderní AI prohlížeč.
Byla vydána nová verze 9.20 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze například nový balíček RustDesk Server pro vzdálený přístup.
Jonathan Thomas oznámil vydání nové verze 3.4.0 video editoru OpenShot (Wikipedie). Představení novinek také na YouTube. Zdrojové kódy OpenShotu jsou k dispozici na GitHubu. Ke stažení je i balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit.
Byla vydána nová verze 1.6 otevřeného, licenčními poplatky nezatíženého, univerzálního ztrátového formátu komprese zvuku Opus (Wikipedie) a jeho referenční implementace libopus. Podrobnosti na demo stránce.
Vojtěch Polášek představil Vojtux, tj. linuxovou distribuci pro zrakově postižené uživatele. Vychází ze spinu Fedory 43 s desktopovým prostředím MATE. Konečným cílem je, aby žádný Vojtux nebyl potřeba a požadovaná vylepšení se dostala do upstreamu.
Byla vydána (Mastodon, 𝕏) druhá RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 160 (pdf).
Izrael od února zakáže dětem používat v prostorách základních škol mobilní telefony. Podle agentury AFP to uvedlo izraelské ministerstvo školství, které zdůraznilo negativní dopady, které na žactvo používání telefonů má. Izrael se tímto krokem přidává k rostoucímu počtu zemí, které dětem ve vzdělávacích zařízeních přístup k telefonům omezují.
Internetová společnost Google ze skupiny Alphabet pravděpodobně dostane příští rok pokutu od Evropské komise za nedostatečné dodržování pravidel proti upřednostňování vlastních služeb a produktů ve výsledcích vyhledávání. V březnu EK obvinila Google, že ve výsledcích vyhledávání upřednostňuje na úkor konkurence vlastní služby, například Google Shopping, Google Hotels a Google Flights. Případ staví Google proti specializovaným
… více »Byl oznámen program a spuštěna registrace na konferenci Prague PostgreSQL Developer Day 2026. Konference se koná 27. a 28. ledna a bude mít tři tracky s 18 přednáškami a jeden den workshopů.
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: