Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
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