Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
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.
Aktuální vývojová verze jádra je 3.13-rc3 vydaná 6. prosince. Linus k ní řekl: Stále dělám vydání v pátek, ale doufám, že se to brzy změní – důvod, proč jsem toto vydání neprotahoval do neděle, je ten, že to bylo už dost velké, a já počkám, než se to uklidní. Což by teď opravdu mělo. Ehm, ehm.
Stabilní aktualizace: verze 3.12.4, 3.10.23 a 3.4.73 byly vydány 8. prosince. V době psaní tohoto textu se verze 3.12.5, 3.10.24 a 3.4.74 revidují; jejich vydání lze očekávat 12. prosince nebo později.
"zpívání modulů" [singing vs. signing] zní jako příšerný nápad! Je autor vůbec hudebně nadaný? Slyšel jsem, že akorát říká David Vyje [Howls vs. Howells].
Pokud jsme Documentation/memory-barriers.txt nemohli ke strašení malých dětí používat dřív, tak teď už určitě můžeme.
-- Mel Gorman
Vytváření jaderných rozhraní, která fungují na 32 i 64bitových procesorech, se ukázalo být dosti náročné. Jedinou z problémových oblastí je předávání argumentů do ioctl(), aby ten samý kód fungoval na obou typech procesorů – v big i little endian variantách. Nedávná diskuze ukázala, že ne všechny z těchto problémů se podařilo doposud vyřešit.
Aurelien Jarno poslal na mailing list linux-fsdevel otázku o FS_IOC_GETFLAGS a FS_IOC_SETFLAGS (které pracují s příznaků inodů souborů). Poznamenal, že definice těchto požadavků v include/uapi/linux/fs.h specifikuje typy argumentů jako ukazatele na long, až na verze pro 32bitovou kompatibilitu, kde se používá int *. Kód v jaderných systémech souborů očekává a používá 32bitovou kvantitu a většina – ale ne všechen – kódu v uživatelském prostoru předává ukazatel na 32bitové číslo.
Jakákoliv aplikace, která předá ukazatel na 64bitové číslo bude fungovat, ale jen na systémech little endian. Protože jaderný kód zachází s ukazatelem jako s odkazem na 32bitovou hodnotu, je pak otázkou, které čtyři bajty jsou při dereferencování použity. Na procesorech big-endian to jsou čtyři nejvýznamnější bajty, kdežto na procesorech little-endian to budou ty druhé čtyři bajty. Protože všechny příznaky jsou ve spodních čtyřech bajtech, tak systémy big-endian efektivně předávají do FS_IOC_SETFLAGS nulu nebo obdrží hodnotu s nedefinovaným obsahem vyšších bitů z FS_IOC_GETFLAGS.
Darrick J. Wong poukázal na to, že jaderný ovladač FUSE používá typy z tohoto hlavičkového souboru, což také zapříčiňuje problémy. Jaderný ovladač očekává přenos 64bitové kvantity, ale většina programů v uživatelském předává jen 32 bitů. Má v plánu speciálně ošetřit tyto požadavky ioctl() pro FUSE.
Množství big-endian 64bitových systémů (např. PowerPC, MIPS a s390) je oproti počtu little-endian x86-64 systémů opravdu malé. To znamená, že jen málo lidí mohlo zpozorovat problém, ale také to, že jakákoliv oprava se musí udělat opatrně tak, aby nedošlo k rozbití milionů stávajících systémů. To je u jádra vždy přednostně důležité, ale Ted Ts'o upozornil na tuto skutečnost, když vysvětloval, jak toto celé vzniklo a proč prostá změna na long * na všech místech nepomůže. Jelikož většina programů v uživatelském prostoru předává int *, tak by taková změna pravděpodobně vedla k rozbití na všech 64bitových systémech bez ohledu na endian.
Jarno ale zdůraznil, že kdokoliv se pokusí napsat kód správně a podívá se na typ argumentu v <linux/fs.h>, ten se se zlou potáže. Alespoň bychom mohli připsat upozornění blízko k definici vysvětlující, proč používat int a ne long.. Ukazuje se, že se tam nacházejí celkem čtyři požadavky ioctl() (ještě FS_IOC_GETVERSION a FS_IOC_SETVERSION kromě těch dříve zmíněných), které mají problematickou definici. Jarno zaslal patch, který tuto změnu uskutečňuje; konkrétně přidává do include/uapi/linux/fs.h (které se instaluje do include/linux) následující varování:
/* * VAROVÁNÍ: Následující čtyři ioctl přijímají ve skutečnosti jako argument int, * navzdory své definici. Toto je důležité pro podporu 64bitových big-endian * strojů. */
Človek by si mohl myslet, že prostá změna argumentu na 32 bitů v tomto hlavičkovém souboru by také byla možností, ale to se také nemůže udělat. Mapování názvu požadavku na číslo se provádí pomocí sady maker, která dělá sizeof() na argumentu „type“. Na 64bitových systémech to dělá osm pro long, ale na 32bitových to jsou čtyři. Protože jsou tato vypočítávaná čísla neměnnou součástí linuxového ABI, změna typu argumentu v tomto hlavičkovém souboru by problém nevyřešila.
Několik lidí navrhlo přidání nového typu požadavku (například FS_IOC_GETFLAGS_NEW nebo FS_IOC_GETFLAGS_WIDE). Přijímalo by ukazatel na 64bitové číslo na všech architekturách. To by mělo jako výhodu zdvojnásobení počtu možných příznaků, pro které teď už nemusí zbývat moc místa. Dnes jich zbývá asi tak deset, přidání dalších 32 by mohlo pokrýt budoucí potřeby, i když jiní nevěří, že 32 bude stačit.
Požadavky FS_IOC_[GS]ETFLAGS byly původně přidány pro systémy souborů ext*, ale časem je začaly používat i další systémy souborů. Kromě toho existují další příznaky pro jiné systémy souborů, které jsou dostupné jen přes ioctl(). Podle Davea Chinnera jich XFS má asi tak deset; další systémy souborů budou mít zase jiné vlastní příznaky. Takže když už děláme změnu, říká Chinner, proč neudělat takovou, která by sjednotila zacházení s těmito příznaky; udělalo by se to tak, aby se počítalo s více než 64 příznaky, které by se mohly brzy vyčerpat.
Ts'o není přesvědčen, že za to ta dodatečná složistost stojí. Ale Chinner předvídá přidání desítek nových příznaků inodů do XFS v dalších letech. Další systémy souborů mohou mít podobné potřeby. Proto není bitmapa o pevné délce nejlepším řešením z dlouhodobého hlediska, ale nepanovala zrovna shoda na tom, jaká alternativa by měla být zvolena.
Chinner navrhoval použít nějaké rozhraní postavené na atributech, které by bylo rozšiřitelné tak, aby ošetřovalo jakékoliv příznaky inodů na jakýchkoliv systémech souborů. Jako další možnost zmínil systémové volání xstat(). Jenže Andreas Dilger upozornil na to, že xstat() už bylo navrhováno mnohokrát, ale nikdy se do jádra nedostalo.
Takže tu máme možná řešení, která vyřeší problém jednou provždy (jak to popsal Chinner), ale není jasné, jestli má někdo úmysl protlačovat jedno z nich. Mezitím Jarnova „oprava“ v hlavičkovém souboru alespoň pomůže uživatelům předávat správný typ argumentu. Aplikace, jež předávají ukazatel na long (byly zmíněny bup a libexplain) se musí změnit, ale to by nemělo být tak těžké. Lepší, celkové řešení nemusí být hotové v dohledné době.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
ioctl
dělá sizeof
, co je na tom těžkého poznat, jestli je parametr int
nebo long
?
int
nebo long
, protože výsledek bude stejný int
předaný z user space se v jádře čte jako 8bajtový long
nebo obráceně.
sizeof
, ne?
sizeof
na argp
, což je ukazatel, čímž se sice odliší, jestli je to 32 bit nebo 64 bit, ale už se nezjistí, jestli je tam int
nebo long
.