Connor Byrne z USA používal pro přihlašování na svůj iPhone 13 s iOS 18 heslo obsahující háček. Po aktualizaci na iOS 26.4 se už ale do telefonu nepřihlásí. Při přihlašování nelze tento háček zadat. Apple jej prostě odstranil [The Register].
Linus Torvalds vydal jádro Linux 7.0. Podrobný výčet změn je ke zhlédnutí na stránce Kernel Newbies, stručné výběry v LWN (část první, druhá).
Na čem aktuálně pracují vývojáři GNOME? Pravidelný přehled novinek v Týden v GNOME. Vypíchnout lze novou verzi 2026.1 přehrávače hudby Amberol (Flathub).
Byla vydána verze 12.0 s kódovým jménem Ecne linuxové distribuce Trisquel GNU/Linux. Založena je na Ubuntu 24.04 LTS a podporována bude do roku 2029. Trisquel patří mezi svobodné distribuce doporučované Nadací pro svobodný software (FSF).
Open-source citační manažer Zotero (Wikipedie, GitHub) byl vydán v nové major verzi 9. Přehled novinek v příspěvku na blogu.
Libre Graphics Meeting 2026, tj. čtyřdenní konference a setkání vývojářů a uživatelů svobodných a otevřených grafických softwarů, proběhne od 22. do 25. dubna v Norimberku. Dění lze sledovat na Mastodonu.
Vývojář Alexandre Gomes Gaigalas na GitHubu zveřejnil c89cc.sh, parser a kompilátor jazyka C89 napsaný v pouhém jediném skriptu o přibližně 8000 řádcích čistého bashe (bez dalších externích závislostí), který generuje ELF64 binárky pro x86-64. Jedná se o velmi jednoduchý kompilátor, který nepodporuje direktivy #include a dokonce ani funkci printf (lze použít puts), všechny dostupné deklarace lze nalézt v proměnné _BUILTIN_LIBC na konci skriptu. Skript je volně dostupný pod ISC licencí.
Francouzská vláda oznámila, že v rámci strategie 'digitální suverenity' zahájí 'přechod od systému Windows k počítačům s operačním systémem Linux' (sa sortie de Windows au profit de postes sous système d'exploitation Linux). DINUM (meziresortní ředitelství pro digitální technologie) požádalo ministerstva, aby do podzimu 2026 vypracovaly konkrétní plány nasazení Linuxu. Francie již dříve migrovala části státní správy na otevřená řešení.
Nezisková organizace Electronic Frontier Foundation (EFF) hájící občanské svobody v digitálním světě po téměř 20 letech opouští platformu X (dříve Twitter). Na platformách Bluesky, Mastodon, LinkedIn, Instagram, TikTok, Facebook, Threads a YouTube zůstává.
Terminálový textový editor GNU nano byl vydán ve verzi 9.0. Vylepšuje chování horizontálního posouvání pohledu na dlouhé řádky a chování některých klávesových zkratek. Více v seznamu změn.
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: