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.
Aktuální předverze je (k 5. 9. 2007) 2.6.23-rc5, kterou Linus vydal 31. srpna, těsně před odjezdem na kernel summit. Obsahuje slušnou řádku oprav; jádro se stabilizuje, ale než bude připraveno k vydání, bude ještě potřeba trochu práce.
Od vydání -rc5 přibylo do hlavního git repozitáře jen několik oprav.
Aktuální verze -mm stromu je 2.6.23-rc4-mm1. Mezi nedávné změny patří výrazné interní implementační změny v sysfs, změny API pro souborové systémy, patche pro odstranění sysctl() a patche pro regulaci využití paměti v kontejnerech.
Aktuální stabilní verze řady 2.6 je 2.6.22.6, vydaná 30. srpna s pár desítkami oprav.
Chceme-li administrátorům systémů něco vzkázat, neměli bychom je nutit ten vzkaz hledat v gitu a diskuzích na LKML!
Soudě podle počtu a vážnosti hlášení o chybách, která tu létají, není 2.6.23 zrovna na spadnutí.
Michael Kerrisk, od roku 2004 správce linuxových manuálových stránek, přednesl během prvního dne konference LinuxConf Europe 2007 řeč o hodnotě dokumentace. Ačkoliv je dokumentace užitečná i pro koncové uživatele, na ně se Michael nezaměřoval; místo toho mluvil o tom, jak může dokumentace pomoci dělat lepší jádro. Psaní dokumentace podle Michaela odhaluje chyby a špatné návrhy rozhraní, než se stanou součástí vydaného jádra. A to může ušetřit spoustu nepříjemností jak vývojářům jádra, tak uživatelských aplikací.
Michael nabídl tři příklady na ukázku toho, jak může psaní dokumentace odhalit chyby:
Podle Michaela je přítomnost vadných rozhraní ve stabilních vydáních jádra důsledkem nedostatečného testování -rc verzí během vývojového procesu. S tímto problémem může pomoci lepší dokumentace. Ta by ostatně mohla pomoci i při samotném návrhu API. Navrhování API je složité a ještě jej ztěžuje fakt, že chyby v návrhu musí být podporovány navždy. Takže cokoliv pomůže s vytvářením lepších API si zaslouží pozornost.
Dobré API se vyznačuje jednoduchostí, snadností použití, obecností, konzistencí s dalšími rozhraními a integrací s dalšími rozhraními. Špatně navržená rozhraní tyto vlastnosti nemají. Jako příklad nabídl Michael rozhraní dnotify - předchozí pokus o poskytnutí služby, která by informovala o změnách souborů. Dnotify mělo problémy kvůli používání signálů, což je vždy zárukou obtížně použitelného rozhraní. Mohlo sledovat pouze adresáře, ne jednotlivé soubory. Vyžadovalo také udržování otevřeného popisovače souborů, takže nebylo možné odpojit žádný souborový systém, kde bylo dnotify používáno. Množství informací poskytovaných aplikacím bylo také omezené.
Jako další příklad byla uvedena systémová volání mlock() a remap_file_pages(). Obě mají parametry start a length pro určení rozsahu ovlivněné paměti. Rozhraní mlock() zaokrouhluje parametr length na další stránku, kdežto remap_file_pages() zaokrouhluje dolů. Rozhraní se liší také v tom, kdy parametr length uplatňují. Výsledkem je, že volání
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
mlock (4000, 6000);
ovlivní bajty 0..12287, zatímco
remap_file_pages (4000, 6000, ...);
ovlivní bajty 0..4095. Taková nekonzistence vývojářům znesnadňuje práci.
O tom, jak jsou tato rozhraní špatná, by se dalo vyplýtvat hodně bitů, ale Michael položil i otázku, jestli je to vůbec chyba jejich autorů. Nepřispěla k těmto problémům také absence kontroly?
Mnohé potíže pramení ze skutečnosti, že ti, kdo rozhraní systémových volání navrhují (hackeři jádra), obvykle daná rozhraní nepoužívají. Ve snaze zlepšit situaci Michael navrhl formalizaci vývojového procesu rozhraní systémových volání. Uznal sice, že bude těžké něco takového prosadit, ale potřeba vytvářet bezvadná rozhraní z toho dělá nutnost. Takže by rád docílil zavedení formální povinnosti podepisování [signoff] API - i když neupřesnil, kdo by podepisoval. Než by mohlo k podpisu dojít, musela by proběhnout kontrola návrhu, musela by existovat kompletní dokumentace a sada testů. Testy by musely být alespoň zčásti od někoho jiného než vývojáře rozhraní, který si nikdy nedokáže představit všechny bláznivé věci, které by s novým rozhraním mohli chtít uživatelé dělat.
Dokumentace je důležitou součástí procesu. Při psaní dokumentace často vyjdou najevo chyby. Kromě toho je díky dokumentaci pro ostatní snazší navrhovanému rozhraní porozumět, takže je více kontrolováno a testováno. Bez testování ze strany vývojářů aplikací se na chyby v novém API často přijde až po zařazení do stabilního vydání jádra, kdy už je pozdě.
Při následné debatě se mluvilo tom, že přimět vývojáře aplikací, aby testovali systémová volání v -rc jádrech bude obtížné. Alternativou, která už byla zmíněna dříve, by bylo označovat po několik vývojových cyklů od přidání nová systémová volání jako "experimentální". Pak by bylo možné vyzkoušet nová volání bez provozování testovacích jader a pořád mít vliv na to, jak bude finální podoba API vypadat. Možná by bylo snazší vývojáře jádra přesvědčit k tomuto postupu, místo komplikovaného formálního schvalování. Jak tato diskuze dopadne, to bude záležet na tom, nakolik vývojáři považují současný způsob návrhu a nasazování nových API pro uživatelských prostor za problém.
Následující den přednesl Arnd Bergmann řeč o tom, jak nenavrhovat jaderná rozhraní. Začal tím, že dobrá rozhraní jsou navrhována "vkusně"; ale rozhodování o dobrém vkusu není vždy snadné. Vkus je subjektivní a časem se mění. Některé charakteristiky vkusného rozhraní jsou však jasné: jednoduchost, konzistence a používání správného nástroje pro daný úkol. Je to samozřejmě velmi podobné tomu, co říkal Michael den předtím.
Jak tomu bývá i v jiných oblastech, návrhy rozhraní se nejlépe popisují pomocí poukazování na věci, které by se dělat neměly. Arnd začal systémovými voláními, která jsou primárním rozhraním jádra. Přidávání nových systémových volání není snadné; nejprve musí projít množstvím kontrol (ačkoliv, jak bylo zmíněno výše, pořád jich patrně není dost). Ale často může být alternativní řešení ještě horší; Arnd uvedl jako příklad hypotetické zařízení /dev/exit; proces, který dokončil svou práci, by se ukončil otevřením a zápisem na toto zařízení. Takové schéma by umožnilo odstranění systémového volání exit(), ale v žádném případě by se nejednalo o vkusnější rozhraní.
Systémové volání ioctl() je už dlouho terčem kritiky; není typově bezpečné, těžko se skriptuje a představuje snadný způsob, jak do jádra propašovat změny ABI, aniž by si toho někdo všiml. Na druhou stranu je dobře zavedené, snadno rozšiřitelné, funguje v modulech a může poskytnout dobrý způsob k prototypování systémových volání. A snaha o obcházení ioctl() může opět vést k horším věcem; Arnd představil příklad z kódu InfiniBand, který interpretuje data zapsaná do speciálního popisovače souboru, aby mohl spouštět příkazy. Výsledkem je v podstatě ioctl(), ale ještě méně přehledné.
Sokety jsou další dobře zavedené rozhraní, které by, podle Arnda, v současné době nebylo do jádra za žádnou cenu přijato. Jsou naprosto nekonzistentní se vším ostatním, pracují se zařízeními, která nejsou součástí stromu zařízení, mají volání pro čtení a zápis, ale nejsou to read() a write() a tak dále. Netlink, který rozhraní soketů ještě zkomplikoval, zrovna situaci v uživatelském prostoru nepomohl; podle Arnda je lepší se jejich použití vyvarovat. Ale podstatné je, že je lepší použít netlink, než jej vynalézat znovu. API bezdrátových rozšíření [wireless extensions] bylo uvedeno jako další příklad, jak věci nedělat; založení bezdrátových rozšíření na netlinku zkombinovalo do jediného rozhraní nejhorší vlastnosti soketů a ioctl().
"V módě" je teď navrhování nových rozhraní s pomocí virtuálních souborových systémů. Ale i s tím jsou potíže. /proc se stalo smetištěm nových rozhraní, dokud se na přidávání dalších věcí nezačali vývojáři dívat přísněji. Sysfs bylo zamýšleno jako řešení mnoha problémů s /proc, ale zjevně nebyl vyřešen problém se nestabilitou API. Virtuální souborové systémy jsou možná nejlepší způsob vytváření nových rozhraní, ale i tam číhají nepříjemnosti.
Nakonec se mluvilo o navrhování rozhraní, která by usnadnila emulaci ABI. Arnd navrhoval, aby byly datové struktury stejné v jádře i uživatelském prostoru. Je-li to možné, neměly by se používat long proměnné a ukazatele. K problémům může vést i vatování struktur [structure padding] - ať už explicitní nebo způsobené špatně zarovnanými poli. A tak dále.
Byla to zajímavá přednáška s velkou účastí publika. Součástí Linuxu je množství chyb v návrhu uživatelských rozhraní, která musejí být už navždy podporována. Je však také velký zájem se podobným chybám v budoucnu vyhnout. I s mnoha zkušenostmi jde však pořád o velmi obtížný problém.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Navrhování API je složité a ještě jej ztěžuje fakt, že chyby v návrhu musí být podporovány navždy.Zajímalo by mě, proč nefunguje princip "tady je nové API, za dva roky staré odstraníme. Používejte nové." IMHO jsou dva roky dost času na to, aby bylo možné upravit drtivou většinu programů.
18.9.2007 10:09
zoul | skóre: 43
| blog: ☂
| Boskovice
