Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červenec (YouTube).
Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »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.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
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...