PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Tento článek nebude o školnících ani instalatérech. Místo toho přinese pár kapitol z příběhu o životě (nejen) binárního balíčku v linuxové distribuci.
V diskusi pod mým posledním článkem se objevil názor, že o opravy chyb v balíčcích by se spíš než distributoři měli starat autoři. To je pěkná představa, která ale z mnoha důvodů narazí na tvrdé hrany reality: předně, neexistuje žádná páka, jak autora donutit, aby problém spravil (ve skutečnosti dá občas pořádnou fušku ho donutit, aby vydal novou verzi i s opravou, kterou jsme mu zaslali). Potom, i ochotné autory open source programů jejich balíček obvykle neživí a než si na něj mohou udělat čas, nejspíš najdete ještě dalších deset chyb. Navíc uživatele jednotlivých distribucí možná přesvědčíme, aby hlásili chyby v distribuční bugzille, ale určitě je nedonutíme, aby se ještě sháněli po autorovi. A konečně, některé problémy balíčku, které se projevují v konkrétní distribuci, autor stejně vyřešit nemůže.
Každý distributor si tak musí zajistit tým lidí, kteří se kromě jiného zabývají také péčí o jednotlivé balíčky obsažené v distribuci. Komunitní distra to mají celkem jednoduché, obvykle sdružují velké množstvín dobrovolníků starajících se jen o pár balíčků, které je zajímají. Komerční distributoři potom musí rozdělit své balíčky mezi své zaměstnance: u některých panuje anarchie a o balíky se stará ten, kdo má zrovna čas, u dalších jsou všechny rozděleny mezi jednotlivé vývojáře, kteří pak řeší veškeré problémy s nimi spjaté.
Naše distribuce je ztělesněním druhého jmenovaného modelu. Kromě toho, že většina vývojářů si mimo běžné náplně práce balí pár svých oblíbených balíčků, existují také balíkáři - specialisti. Balíky, které mají v péči, se počítají na stovky a jejich udržování věnují celou svou pracovní dobu. Jak jejich práce vypadá?
Jak říkávám, práce balíkáře znamená opravovat chyby v programech, které neznáme, a které jsou napsané v jazycích, které neumíme. K většině programů přijde balíkář jak slepý k houslím a jejich kód poprvé spatří až ve chvíli, kdy řeší nějaký problém. Občas tak dochází k nemilým překvapením: už jsem tady vyprávěla, jak jsem se učila Fortran a v nejbližší době se zřejmě dočkáte pokračování, tentokrát se bude týkat Scheme. Smůla je, že k normálnímu programování se balíkář dostane obvykle jen ve volném čase: obyčejně pár hodin kouká do kódu, a potom odevzdá patch čítající pět řádků.
Většinu času balíkář stráví v relativním klidu a pohodě (řeší jen problémy s přechodem na nové verze gcc, glibc, portováním na různé absurdní architektury a uživateli domáhajícími se nesmyslných featur), ta se ale rychle rozplyne přibližně týden před tím, než je vyhlášen freeze na nové verze balíků v nadcházející verzi distribuce. Tehdy je totiž třeba co nejrychleji aktualizovat všechny balíčky: pouštět se do toho dřív nemá valného smyslu, protože potom stejně ještě vyjdou nové verze. Dělat si strejčka se vyplatí jen u knihoven. Někdy má člověk štěstí a všechno jde jako po másle, jindy dře jako otrok na plantáži.
Výsledkem této akce je distribuce ve stavu připomínajícím dort pejska a kočičky: nastává chvíle, kdy programy padají jak zralé ovoce a je na vývojářích, aby chyby našli a opravili. Než se nadějí, uplyne čas do první bety a k chybám nalezeným vlastnoručně přibudou hromady hlášení od uživatelů. V těchto okamžicích naprosto nemá smysl spoléhat na opravy od autorů jednotlivých programů: nebylo by to dost rychle a navíc ukázat jim, jak chybu zreprodukovat, by mnohdy dalo víc práce, než ji spravit. Nepříjemnosti, které toto období přináší, jsou způsobeny jen a pouze tím, že nové verze programů obvykle přicházejí na svět nedostatečně odladěné.
V praxi tedy ráno člověk přijde k počítači, vypije si první kafe a přitom si prohlédne seznam nových bugreportů, které přibyly přes noc (uživatelé pilně testují ve všech časových zónách). Pak je probírá jeden po druhém, a když má štěstí, opraví jich tolik, že se seznam přes den neprodlouží. V noci u posledního kafe potom rozešle své patche autorům jednotlivých programů. Text mailu mnohdy najde jako komentář ke svému kódu v dalším vydání programu: občas i přesto, že jde o slova jako "tento pointer je občas NULL, nevím proč." Tolik tedy k ochotě upstream autorů zabývat se chybami ve svém kódu.
Nakonec se začne frekvence hlášení snižovat. Když se z bety stává RC, je seznam bugreportů téměř prázdný a přichází čas věnovat se běžným denním radostem: proklínání programátorů, co nikdy neslyšeli slovo bigendian, nadávání na vývojáře gcc proměňující warningy v chyby a pročítání požadavků na nové featury s úsměvem, který rychle tuhne na rtech ve chvíli, kdy se za ně postaví management. Patche už nepadají z klávesnic jako mince z kouzelného beránka, kódu použitelného pro původní autory software ale vzniká i tak dost. Za to, že se autoři nemusejí hrabat v chybách, a místo toho se věnují novým vlastnostem, tedy uživatelé vděčí svým distributorům a asi by bylo nemoudré to chtít jinak.
Tiskni
Sdílej:
ale vtípek jsem si odpustit nemohl. :D Lisp jsem se zkoušel učit, jediná knížka v místní vědecké knihovně, která připomínala učebnici Lispu byla z roku 1976 a měla hezky žluté stránky, ale základy jsem snad pochopil
Seriál s názvem Těžký život vývojáře Linuxové distribuce. Já bych si to docela rád četl, alespoň bych se dozvěděl nějaké klepy z firemního prostředí. Ale to by jsi musela psát asi pod jinou přezdívkou. ))
15.5.2006 22:36
brozkeff | skóre: 13
| blog: Zpátky po 10 letech
| Žďár nad Sázavou
15.5.2006 22:40
brozkeff | skóre: 13
| blog: Zpátky po 10 letech
| Žďár nad Sázavou
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
13.5.2006 15:51
