Bun (Wikipedie), tj. běhové prostředí (runtime) a toolkit pro JavaScript a TypeScript, alternativa k Node.js a Deno, byl vydán ve verzi 1.4. Představení novinek také na YouTube. Bun byl přepsán z programovacího jazyka Zig do Rustu. Pomocí Claude Fable 5.
Vývojáři KDE na Mastodonu oznámili vydání balíku aplikací KDE Gear 26.08. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Společnost PINE64 kvůli nedostatku a vysokým cenám DRAM a eMMC dočasně pozastavuje výrobu linuxových zařízení. Výroba zařízení jako PineTime, PineVoice a Pinecil pokračuje.
Společnost Stripe se dohodla na akvizici společnosti OpenRouter. Za 7,5 miliardy dolarů.
Byla vydána nová verze 1.27 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
V pátek 28. srpna se v Praze uskuteční již osmý Mobile Linux Hackday. Jako obvykle se potkáme v pražské pobočce SUSE v Karlíně na Křižíkově, takže kromě mobilního Linuxu je to tentokrát i příležitost přijít se podívat na nově zrekonstruované kanceláře. Začínáme v 10:00, ale dorazit můžete samozřejmě kdykoliv v průběhu dne. Setkáním vás provede David Heidelberg, vývojář GPU ovladačů v Mesa 3D a jeden z hlavních lidí české komunity kolem … více »
Představen byl Raspberry Pi Compute Module 5 Programming Jig. Jedná se o zařízení umožňující připravit Compute Module 5 do plně funkčního stavu bez nutnosti použití dalších vstupně / výstupních desek. Podporuje automatizaci pomocí nástroje rpi-sb-provisioner. Podrobnosti v dokumentaci.
Hackeři ve Francii ukradli data více než půl milionu daňových poplatníků. Je to jeden z největších hackerských útoků v dějinách země. O útoku z konce června informovala až teď daňová správa. Teprve od pondělí dotčeným občanům zasílá e-maily s instrukcemi, jak postupovat dál. Hackeři se sice nedostanou k penězům dotyčných, hrozí ale věrohodné podvody. Hackeři získali třeba celá jména, údaje o rodinných příslušnících nebo také údaje o
… více »Společnost Framework představila nový Framework Laptop 12 s Intel Core Series 3, Thunderbolt 4, Wi-Fi 7, volitelnou čtečkou otisků prstů a podsvícenou klávesnicí s open-source firmwarem ZMK. Objednat lze s předinstalovanou Fedorou 44 KDE Plasma.
Byl vydán Mozilla Firefox 154.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 154 bude brzy k dispozici také na Flathubu a Snapcraftu.
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: