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í vývojová verze jádra je 3.5-rc6 vydaná 7. července. Jsou tam hlavně věci kolem btrfs a md, dále pak běžné změny v ovladačích, architektuře arm a v síťování. A pak ještě trocha ostatních věcí (jako dokumentace apod.). Nic z toho nevypadá děsivě, není to rozsáhlé a ani těch malých změn není tolik. Linus také upozornil, že začleňovací okno 3.6 nastane pravděpodobně v době, kdy je mnoho vývojářů na dovolené, takže 3.6 bude mít asi docela málo novinek.
Stabilní aktualizace: verze 3.2.22 vyšla 5. července. Verze 3.2.23 se aktuálně reviduje.
Co je pro jednoho idiom, je pro druhého pitomost.
Možná je to překlep a mělo to být Aargh64.
-- Jan Ceuleers
No nevím, v moment, kdy Apple přijde se svým 64bitovým iPhone 6 (nebo v kterém vlastně nakonec přejdou na 64 bitů), *všichni* se hned budou z marketingových důvodů snažit přejít na 64 bitů. Kód a podrobnosti kolem SoC budou převedeny na 64 bitů obvyklým způsobem: co nejvíc narychlo.
Je tu i technologická hranice: jakmile velikost RAM na typickém chytrém telefonu překročí hranici 2 GB, problémy s 32bitovým jádrem budou značné. Do tohoto zlomu zbývá asi tak jeden rok.
Nuže, jsi si *opravdu* jistý, že barvitý svět ARM SoC nepřejde na 64 bitů a všichni budou svorně stát za jednou platformou a že si tento proces můžeme vynutit tím, že nebudeme přijímat patche, které nejsou obecné? Je podobný návrh platformy vynucován ARMem, stejně jako to má Intel u x86?
-- Ingo Molnar
Parta vývojářů šla jednoho večera šplhat do jedné tělocvičny a skončilo to tak, že jsem šplhal s jedním jaderným vývojářem, co pracoval pro jinou firmu, a byl to někdo, jehož kód jsem v minulosti z různých důvodů zamítl a nakonec až po několika pokusech jsem jej přijal. Od té doby si říkám: „Snaž se vždy být po e-mailu přátelský, nikdy nevíš, kdy bude adresát držet lano, které tě jistí“.
Jennifer Cloer připravila pro Linux.com rozhovor s Gregem Kroah-Hartmanem. Byl jsem vývojářem pro embedded zařízení a testoval jsem zařízení, na kterém jsem dělal (čtečka čárových kódů) na všech možných operačních systémech, abych si byl jistý, že jsem připravil firmware správně. Linux měl tehdy velmi špatnou podporu USB a já jsem si uvědomil, že bych mohl pomoci s vylepšením. Slovo dalo slovo a zanedlouho jsem na plný úvazek pracoval na vývoji linuxového jádra, to bylo před 10 lety a nikdy jsem se už neohlédl.
ARM je jedna z nejúspěšnějších procesorových architektur; většina z nás vlastní několik ARMů na každý x86 procesor. Na ARM se obvykle nahlíží jako na procesor pro embedded systémy; je zaměřený na minimální spotřebu energie a schopnost fungovat ve spoustě zařízení typu system-on-chip. Image procesoru pro „malé systémy“ je jistě posílena faktem, že procesory ARM jsou jen 32bitové. Tato situace by se ale měla změnit, a to s příchodem 64bitových ARMů. Linux bude na tyto systémy připraven – první sada patchů pro podporu 64bitových ARMů byla právě zaslána – ale stále probíhají debaty o některých zásadních věcech.
Někteří možná přemýšlejí, jestli jsou 64bitové ARM procesory vůbec potřebné. 64bitová výpočetní technika se zdá být nadbytečná i do těch nejluxusnějších telefonů nebo tabletů, co teprve do embedded řadičů, kde ARMy vládnou. Jenže mobilní zařízení se začínají dostávat na hranice možností adresace 32bitových systémů; dokonce i 1GB systém vyžaduje high memory ve většině konfigurací. Tudíž, i když na předvídané 64bitové ARM servery možná nikdy nedojde, budeme 64bitové ARMy potřebovat už jen kvůli efektivnímu používání paměti, která na budoucích mobilních zařízeních bude. „Mobilní“ a „embedded“ už nemusí znamenat „drobný“.
Podpora Linuxu je přirozeně zásadní podmínkou pro úspěšný nástup 64bitových ARM procesorů, takže ARM na tom už nějakou dobu pracuje. Počáteční patche pro GCC byly zaslány už v květnu a první sada jaderných patchů byla zaslána Catalinem Marinasem 6. července. Tento kód existuje navzdory tomu, že zatím není k dispozici žádný 64bitový hardware; vše bylo vyvinuto na simulátorech. Jakmile se nějaký ten hardware objeví, tak by software měl fungovat správně s minimem ladění.
Podpora 64bitového ARMu znamená přidání tisíců řádek nového kódu v patchi o 36 částech. Jsou tam i nějaké ty zbrusu nové věci jako schopnost používat 64KB nativní velikost stránky a spousta důležitých technických rozhodnutí, která je ještě nutno zrevidovat. A tak jaderní vývojáři začali dělat právě to, co by se dalo očekávat: začali si stěžovat na jméno architektury. Název „AArch64“ spoustě lidí přijde jako redundantní (no jasně, že je to architektura) a neinformativní („A" znamená co?). Spousta by preferovala ARMv8 (což je skutečný název hardwaru – “AArch64" je 64bitový operační režim ARMv8) nebo arm64.
Mezi argumenty pro zachování aktuálního jména patří to, že se název už používá pro identifikaci architektury v ELF trojici v binárkách; používání stejného názvu na všech místech by bylo méně matoucí. Ale jak Arnd Bergmann poznamenal: Pokud je všechno ostatní aarch64, tak bychom to měli použít i pro adresář v jádře, ale pokud tomu už všichni stejně říkají arm64, měli bychom použít právě to pro co nejvíce věcí. Jon Masters dodal, že jemu se zase líbí současné jméno; Fedora plánuje použít „aarch64“ jako název pro svá vydání pro 64bitový ARM. Jiní, jako Ingo Molnar, zase dávají přednost změně jména, dokud to ještě lze relativně snadno udělat. Catalin je spíše nakloněn zachování současného názvu, ale před zasláním další verze patche o tom ještě popřemýšlí.
Řada vývojářů řešila podstatně důležitější věc: nebylo by smysluplné sjednotit 32bitovou a 64bitovou implementaci ARM už od počátku? Spousta jiných architektur (x86, PowerPC, SPARC a MIPS) začala s oddělenými implementacemi, ale nakonec došlo ke sloučení, což si obvykle vyžádalo značné úsilí. Bylo navrženo, že než aby tomu byli vývojáři ARM v budoucnu vystaveni, bylo by asi lepší to tak mít hned od začátku.
Pro oddělenou implementaci 64bitového ARMu je mnoho důvodů. Většina z nich je uvedena v tomto mailu od Arnda. 64bitová instrukční sada je na ARM naprosto odlišná od 32bitové, a to tak moc, že je nemožné napsat kód v assembleru, který by fungoval na obou architekturách. Rozhraní pro systémová volání se také podstatně liší, 64bitová verze používá běžnější přístup a zbavuje se tak legacy zátěže. 64bitová implementace se také snaží hodit za hlavu celý koncept 32bitové ARM platformy; a jak to Jon popsal, cílem je i to, aby bylo možné mít hned od počátku jádro, které poběží na všech 64bitových ARM systémech. Obecně se mluví o tom, že start s čistým štítem ve své vlastní hierarchii umožní odhození spousty historické zátěže a povede k lepší implementaci.
Ostatní rychle upozornili na to, že podobné argumenty se ozývaly i ohledně jiných architektur. x86_64 také mělo původně znamenat začátek od píky a zahození spousty starého kódu pro i386. Nakonec to ale dopadlo jinak. Je možné, že to tady dopadne odlišně; 32bitový ARM má více historické zátěže než ostatní architektury a rozdíl mezi procesory se zdá být větší. Nekteří říkají, že je to jako x86 a ia64, ačkoliv člověk může nabýt dojmu, že se vývojáři AArch64 snaží přirovnávání k ia64 vyhýbat.
Toto rozhodnutí závisí na tom, co nakonec budou vývojáři AArch64 chtít; je jen na nich, aby připravili funkční implementaci a udržovali ji v budoucnu. Pokud budou trvat na tom, že musí jít o zcela oddělenou architekturu, tak jim v začlenění nikdo asi jen kvůli tomu bránit nebude. Pak ale bude samozřejmě zase jen na těchto vývojářích, aby se v budoucnu postarali o případné sloučení, kdyby se to ukázalo být potřebným. A když už nic jiného, život v oddělené hierarchii umožní vývojářům experimentování bez rizika rozbití starších 32bitových systémů; takže výsledkem by mohla být i lepší sloučená architektura během několika let, pokud by na to mělo dojít.
Prozatím se nikdo moc nepustil do kritiky hlubších technických stránek patche pro AArch64. Na to ještě může dojít. Kód už prošel spoustou interních revizí, do čehož byli zapojeni prominentní vývojáři, takže to nejhorší by už mělo být vyřešené. Jen málo vývojářů navíc rozumí tomuto procesoru natolik, aby dokázali většinu kódu pochopit. Tudíž se to celé může dostat do hlavní řady (snad už v 3.7) bez podstatnějších úprav. Pak už bude chybět jen samotný hardware; a právě tehdy to začne být opravdu zajímavé.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Co je pro jednoho idiom, je pro druhého pitomost.Ale tady šlo původní vyznění vcelku triviálně zachovat. Dokonce jsem hodhadnul ještě než jsem si to rozklik.
One man's idiom is another man's idiocy.
arch/aarch64/aneb ať žije redundance...