Freie Chip-Designs können dank Google künftig auch kostenfrei bei Globalfoundries gefertigt werden. Genutzt wird dafür aber alte Technik.

Google hat seine Initiative zur kostenfreien Herstellung von Chips mit einem offenen Design um einen wichtigen Partner erweitert: Globalfoundries. Das Unternehmen gehört zu den größten Auftragsfertigern in der Halbleiterindustrie, was entsprechende Kapazitäten für die Initiative bedeutet. Darüber hinaus produziert Globalfoundries in Deutschland und in den USA, was eventuell Tests der hergestellten Chips erleichtert.

Der Ankündigung zufolge veröffentlichen nun beide Unternehmen gemeinsam ein sogenanntes Process Design Kit (PDK) für die 180MCU-Technologie unter der Apache-2.0-Lizenz. Damit können die eigentlichen Chips passgenau auf den von Globalfoundries genutzten Herstellungsprozess entworfen werden. Damit einher gehe explizit eine kostenfreie Herstellung von Open-Source-Designs der Efabless-Platform. Dank der freien Verfügbarkeit des PDK könnten bestehende EDA-Werkzeuge für das eigentliche Chip-Design leicht den Prozess von Globalfoundries unterstützten. Ebenso könnten bereits vorhandene IP-Blöcke auf den Prozess portiert werden.

Die für das Programm bei Globalfoundries nun bereitstehende 180nm-Strukturbreite ist im historischen Vergleich eher alt und kommt seit mehr als 20 Jahren zum Einsatz. Der Markt für damit gefertigte Chips werde jedoch in den kommenden Jahren von mehr als 16 Millionen Wafern auf über 22 Millionen steigen, so Globalfoundries. Weiter heißt es in der Ankündigung: “Der 180-nm-Anwendungsbereich verzeichnet weiterhin eine starke Marktdynamik bei Motorcontrollern, RFID, Allzweck-MCUs und PMICs sowie bei neuen Anwendungen wie IoT-Sensoren, Zweifrequenz-RFID und Motorantrieb.”

Google schreibt zu der Kooperation mit Globalfoundries: “Basierend auf dem Umfang und der Breite der Technologie- und Fertigungskompetenz von Globalfoundries erwarten wir, dass wir gemeinsam mehr tun werden, um den Zugang und die Innovation in der Halbleiterentwicklung und -fertigung zu fördern.” Über die Kooperation mit dem ersten Partner des Google-Programms, Skywater, konnten bereits 350 Designs eingereicht werden, von denen letztlich 240 gefertigt worden seien, so Google.

Der Beitrag Globalfoundries tritt Open-Source-Chip-Initiative bei erschien zuerst auf Linux-Magazin.

Der Linux-Support von Lenovo soll auf 30 Geräte wachsen. Ausgerechnet den ARM-Support gibt es zwar, aber nicht offiziell.

Linux-Nutzer, die nativ einen leistungsfähigen Laptop mit moderner ARM-CPU nutzen wollen, können künftig bald zusätzlich zu den neuen Macs mit Apple Silicon auch das Thinkpad X13s von Lenovo mit Snapdragon 8cx Gen3 einsetzen – wohl aber noch mit zahlreichen Einschränkungen und ohne offiziellen Support durch den Hersteller.

Das sagte der für die Linux-Initiative bei Lenovo verantwortliche Mark Pearson in einem Vortrag auf der vergangenen Debconf, dessen Videoaufzeichnung nun verfügbar ist. Demnach plant das Unternehmen noch im Jahr 2022 offiziell mehr als 30 seiner Geräte mit Linux zu unterstützen. Dazu gehören Thinkpads mit x86-Chips von Intel sowie von AMD und auch die Workstationserie von Lenovo. Diese Initiative hatte das Unternehmen bereits vor mehr als zwei Jahren gestartet.

Die Arbeiten an dem ARM-basierten Thinkpad X13s seien darüber hinaus aber nicht offiziell Teil des Linux-Programms, so Pearson. Lenovo arbeite dennoch eng mit ARM und Linaro an dem Linux-Support im Rahmen einer Machbarkeitsstudie. Noch funktionierte aber weder Sound noch WLAN, die Energieverwaltung sei unzuverlässig und ob die Kamera überhaupt je laufen können werde, sei noch nicht sicher.

Trotz allem laufe Linux bereits auf den Geräten. Ziel sei dabei auch, eine einfache und die übliche bekannte Installation über einen USB-Stick zu ermöglichen. Noch fehle dafür aber die Firmware-Unterstützung. Außerdem nutze das System noch Device-Trees statt etwa ACPI. Auch der Bootloader müsse angepasst werden. Sobald das umgesetzt sei, soll eng mit den Linux-Distributionen zusammengearbeitet werden.

Pearson sagt darüber hinaus, dass die für das Projekt umgesetzten Linux-Patches in den Hauptzweig eingepflegt werden sollen. Ein Teil davon ist auch bereits eingepflegt oder, wie die Device Tress für das X13s, schon eingereicht worden. Für einen offiziellen Support der Arbeiten sei es laut Pearson notwendig, dass Lenovo einen Markt dafür sehe. Mit der ersten Machbarkeitsstudie könnte dies nun vielleicht gezeigt werden, hofft Pearson.

Der Beitrag Lenovo will ARM-Thinkpads noch nicht mit Linux ausstatten erschien zuerst auf Linux-Magazin.

Für die Programmierung der Dienste von Facebook-Mutter Meta darf nun auch offiziell Rust verwendet werden. Die Nutzung wachse rasant, heißt es.

Für die Programmierung der serverseitigen Dienste des Facebook-Mutterkonzerns Meta können die Angestellten künftig auch offiziell die als besonders sicher geltende Programmiersprache Rust verwenden. Das kündigt das Team in seinem Engineering-Blog an. Damit zählt Rust nun zu den wenigen intern unterstützten Sprachen.

Zum Hintergrund der Entscheidung heißt es: “Die Unterstützung einer neuen Sprache ist keine Entscheidung, die wir leichtfertig treffen. Es ist wichtig, dass jede Sprache, die wir übernehmen, für einen bestimmten Anwendungsfall am besten geeignet ist, daher lassen wir bei der Bewertung einer Sprache ein hohes Maß an Sorgfalt walten. Sprachentscheidungen bleiben in der Regel bestehen, sobald sie einmal getroffen wurden, daher möchten wir von Anfang an bewusst vorgehen, um unseren Entwicklern die besten Werkzeuge zum Arbeiten zur Verfügung zu stellen.”

Die interne Unterstützung bedeutet laut Meta, dass die Entwickler mit den üblichen Werkzeugen zum Schreiben von Code, Debugging, den Builds und dem Ausrollen gut arbeiten können. Ähnliches gilt für Kernbibliotheken und Interoperabilität. Bisher zählten zu der Liste der unterstützten Sprachen die Eigenentwicklung Hack sowie Python und C++.

Die Nutzung von Rust empfiehlt Meta parallel zu C++ für Backend-Dienste, deren Leistung besonders kritisch ist. Das Unternehmen schreibt dazu: “Der Anteil von Rust an unseren Produkten und Dienstleistungen nimmt rapide zu, wir setzen uns langfristig für Rust ein und begrüßen Early Adopters.”

Zusätzlich dazu sollen mit Rust vor allem Kommandozeilenwerkzeuge erstellt werden. Für zustandslose Anwendungen werde hingegen Hack bevorzugt, Python wiederum für Data-Science- und Machine-Learning-Anwendungen. Nur in kleinen Teilbereichen werde außerdem auf Go, Java, Erlang und Haskell gesetzt.

Der Beitrag Meta empfiehlt Rust für CLIs und als C++-Alternative erschien zuerst auf Linux-Magazin.

Die auch für Tracking genutzten Third-Party-Cookies will Google in Chrome ersetzen. Das soll nun erst in zwei Jahren geschehen.

Seit inzwischen fast drei Jahren arbeitet Google an Techniken, die die bisher für webseitenübergreifendes Tracking genutzten Third-Party-Cookies im Chrome-Browser ersetzen sollen. Die Umsetzung hat Google nun aber erneut verschoben: auf Ende 2024, wie es in einem aktuellen Blogeintrag des Unternehmens heißt.

Bereits im vergangenen Jahr musste Google den Termin verschieben, ursprünglich geplant war die Einführung neuer Technik und die Abschaffung der Third-Party-Cookies eigentlich früh im Jahr 2022. Als Grund für die Verzögerungen nennt das Unternehmen vor allem das Feedback der Web-Community, die sich mehr Zeit zum Testen der neuen alternativen APIs gewünscht habe. Konkret handelt es sich dabei um die Privacy-Sandbox-APIs.

Google selbst räumt aber ein, dass die Verzögerungen auch im Einklang mit Forderungen von Markt- und Kartellwächtern stehe, damit die Industrie genügend Zeit hat, auf die neuen Techniken zu wechseln. Immerhin sammelt Google auch selbst Daten auf Webseiten und vermarktet diese zu Werbezwecken. Eine zu schnelle Einführung der Technik könnte die Konkurrenz massiv benachteiligen. Der Testzeitraum soll entsprechend deutlich vergrößert werden, bevor die Third-Party-Cookies in Chrome wirklich abgeschafft werden.

Zwar könnten Entwickler die Technik schon nutzen, noch im August würden die Versuche damit aber auf “Millionen von Nutzern weltweit” ausgeweitet. Die Anzahl der ausgewählten Nutzer soll dabei bis ins Jahr 2023 hinein kontinuierlich ansteigen. Die Nutzer sollen dabei entscheiden können, ob sie teilnehmen wollen oder nicht, und werden darüber über ein gesondertes Fenster informiert.

Im dritten Quartal 2023 sollen die APIs dann weltweit an alle Chrome-Verwender verteilt werden und standardmäßig in Chrome verfügbar sein. In der zweiten Hälfte des Jahres 2024 erst soll die Unterstützung für Third-Party-Cookies auslaufen.

Der Beitrag Google verschiebt Ende von Third-Party-Cookies erschien zuerst auf Linux-Magazin.

Das verschlüsselte DNS in Android läuft nun auch über HTTP/3. Im Vergleich zu DoT werde dadurch die Latenz verringert, so Google.

Zusätzlich zu dem bereits verfügbaren DNS über TLS (DoT), das Google seit Android P in sein Mobilbetriebssystem integriert hat, kann in Android nun auch DNS-over-HTTP/3 genutzt werden, wie Google in seinem Security-Blog ankündigt. Google verspricht sich davon laut eigenen Aussagen vor allem Verbesserungen im Vergleich zu dem bisher verfügbaren DoT.

Der Nachteil von DoT ist laut der Ankündigung der Mehraufwand, der durch die Verschlüsselung der DNS-Anfragen entstehe. Zu DNS über HTTPS (DoH) heißt es: “Während die Verwendung von HTTPS allein den Overhead nicht wesentlich reduziert, verwendet HTTP/3 QUIC, ein Transportprotokoll, der mehrere Streams über UDP effizient multiplext, indem eine einzige TLS-Sitzung mit Sitzungswiederaufnahme verwendet wird. All diese Funktionen sind entscheidend für den effizienten Betrieb auf mobilen Geräten.”

Wichtig für den Mobilbetrieb ist unter anderem, dass bei den häufigen Wechseln zwischen den Netzen die Verbindungen bei DoT jedes Mal wieder neu aufgebaut werden müssten. Da HTTP/3 aber eben auf QUIC basiert, könne dessen Technik zur Wiederaufnahme einer Sitzung auch in DoH genutzt werden, wie Google schreibt. Die in QUIC integrierten Kontrollflusstechniken könnten bei unzuverlässigen Verbindungen gar dazu führen, das DNS über HTTP/3 schneller sei, als das klassische unverschlüsselte DNS.

Die Nutzung von DoH3, wie Google dies selbst nennt, hat das Unternehmen über ein Play-Store-Update an Android-Nutzer verteilt. Zur Verfügung steht dies damit nun für alle Versionen ab Android 11. Als DNS-Server unterstützt werden bisher die Dienste von Google sowie auch von Cloudflare, für deren Nutzung nun keine DoT mehr zum Einsatz kommt. In der Ankündigung weist Google außerdem noch auf den Standard-Entwurf Discovery of Designated Resolvers (DDR) hin, dessen Umsetzung die Konfiguration und Auswahl der DNS-Server vereinfachen und damit weiter beschleunigen soll.

Der Beitrag Google macht DNS auf Android per DoH schneller erschien zuerst auf Linux-Magazin.

Dass Linux-Systeme nicht auf Lenovo-Rechnern starten, liegt wohl an Bedingungen von Microsoft. Die sind aber weder öffentlich noch abgestimmt.

Mit der Initiative der Secured-Core-PCs und dem speziell dafür erstellten Security-Chip Pluton will Windows-Hersteller Microsoft die Sicherheitsarchitektur der Rechner auf Jahre verändern. Im Fall eines Thinkpad z13 von Lenovo führt dies aber dazu, dass Linux-Systeme offenbar nicht standardmäßig booten. Linux-Entwickler Matthew Garrett schreibt nun unter Berufung auf Lenovo in seinem Blog, das liege an bestimmten Bedingungen der Secured-Core-PCs-Initiative von Microsoft.

Der Grund dafür, dass die Linux-Systeme standardmäßig nicht booten, ist technisch der, dass der von Microsoft für Secure Boot erstellte CA-Schlüssel für Dritte nicht von der Firmware akzeptiert wird. Damit signierten Systemen wie Linux-Distributionen wird somit der Start verweigert. Microsoft forciert dies offenbar bei seinen Partnern der Secured-Core-PCs.

Diese Bedingungen sind laut Garrett außer durch das eine Dokument von Lenovo aber nicht öffentlich bekannt und wohl auch nicht mit der Linux-Community abgestimmt, obwohl Microsoft und die Linux-Distributoren seit Jahren zu Fragen rund um die Technik UEFI-Secure-Boot zusammenarbeiten. Immerhin signiert Microsoft die Bootloader der Distributionen, nachdem der Hersteller im Jahr 2012 die Unterstützung von Secure Boot als Voraussetzung für seine OEM-Partner einführte. Und die Community habe für diese Zusammenarbeit zahlreiche Anstrengungen unternommen, so Garrett.

Der Entwickler kommentiert die aktuelle Situation so: “Wenn also Microsoft, der selbsternannte Verwalter des UEFI-Secure Boot-Ökosystems, eine Kehrtwende macht und sagt, dass ein Haufen Binärdateien (…), die von Microsoft signiert wurden, jetzt von Microsoft als unsicher angesehen werden, ist das, ähm, irgendwie unhöflich? Vor allem, wenn ungeprüfte herstellersignierte Binärdateien immer noch als vertrauenswürdig gelten, obwohl überhaupt keine externe Überprüfung durchgeführt wird.”

Diese für die Linux-Community und -Nutzer eher unschöne Situation könne leicht durch Microsoft gelöst werden, indem das Unternehmen klare Regeln aufstelle, die auch von der der Community eingehalten und umgesetzt werden könnten. Dazu könnten auch zusätzliche Überprüfungen gehören, schlägt Garrett vor. Doch die bisherigen Entscheidungen seien ohne jede Rücksprache mit wichtigen Beteiligten umgesetzt worden, so Garrett.

Der Beitrag Auflagen für Secured-Core-PC verhindern Linux-Boot erschien zuerst auf Linux-Magazin.

Für das GUI-Toolkit GTK könnte künftig komplett auf Wayland gesetzt werden. Bis es soweit ist, könnten aber noch Jahre vergehen.

Die Entwicklungscommunity der Gnome-Desktop-Umgebung diskutiert derzeit die Idee, für ihr GUI-Toolkit GTK künftig komplett auf die Unterstützung des X11-Fenstersystems zu verzichten. Das geht aus einem Eintrag von Entwickler Matthias Clasen im Issue-Tracker des Teams hervor. Als mögliches Ziel für die Umsetzung wird die kommende Version GTK 5 anvisiert. Einen konkreten Zeitplan für die Veröffentlichung von GTK 5 gibt es derzeit aber noch nicht.

Zur Begründung des Verzichts auf den X11-Support heißt es schlicht: “Es wird nicht besser und Wayland ist weit verbreitet.” Clasen spielt damit auf eine seit mehreren Jahren geführte Diskussion der Linux-Desktop-Community an, in der der X-Server zwischenzeitlich sogar als Abandonware bezeichnet worden war. Als Abandonware wird Software bezeichnet, die nicht mehr aktiv gepflegt wird und vom Hersteller schlicht aufgegeben wurde.

Tatsächlich wird der X.org-X-Server und das damit umgesetzte X11-Fenstersystem für Linux kaum noch gepflegt. So ist die aktuelle Hauptversion erst drei Jahre nach der vorhergehenden Version und nur dank finanzieller Unterstützung aus der Community heraus überhaupt erschienen. Ebenso lassen sich viele X11-Treiber gar nicht mehr kompilieren.

All das bereitet darauf aufsetzenden Projekten wie GTK einige Probleme und größeren Supportaufwand. Hinzu kommt, dass die Wayland-Unterstützung immer besser wird und einige Linux-Distributionen inzwischen standardmäßig auf Wayland statt auf X11 setzen. Entwickler Emmanuele Bassi führt weiter aus: “Das offensichtliche Problem ist, dass X11 keine Funktionalität mehr erhält und GTK sich bereits in Richtung Wayland als primäres Design für Funktionen und API bewegt hat.” Mittelfristig könnte der X11-Support sogar eine Hürde für die Umsetzung neuer Funktionen in GTK sein, gibt Bassi zu bedenken.

Der Beitrag GTK-Entwickler diskutieren Ende von X11-Support erschien zuerst auf Linux-Magazin.

Der erste Laptop mit RISC-V soll noch in diesem Jahr verfügbar sein und eine Quadcore-CPU samt 16 GByte RAM bieten.

Die beiden in China ansässigen Unternehmen Deepcomputing und Xcalibyte haben mit ihrer Entwicklungsplattform, die Roma genannt wird, eigenen Angaben zufolge den ersten RISC-V basierten Laptop vorgestellt. Laut Ankündigung soll sich das Gerät bereits vorbestellen lassen, auf der dazugehörigen Webseite befindet sich bisher jedoch nur ein Formular zu Registrierung.

Grundlage des Laptops soll eine bisher noch nicht angekündigte RISC-V-CPU mit vier Kernen sein. Eine Pro-Variante soll in einem 12nm-Verfahren und eine Standard-Variante in einem 28nm-Verfahren gefertigt werden. Der CPU stehen 16 GByte LPDDR4/LPDDR4X RAM sowie 256 GByte nicht näher spezifizierter Flash-Speicher zur Seite. Hinzukommen sollen eine GPU sowie eine NPU zur Beschleunigung der Videoverarbeitung sowie für KI-Aufgaben.

Weiter heißt es, dass das Gerät über ein Motherboard verfügen soll, das ein austauschbares SoC beziehungsweise SoM unterstützt. Der Hersteller verspricht außerdem kostenfreie Upgrades dafür. Unterstützt werden soll die Roma Entwicklungsplattform darüber hinaus von der aktuellen Linux-Distribution.

Aufgrund der wenigen technischen Details oder auch einer fehlenden Preisangabe sowie einer Verknüpfung des Roma-Laptop mit Web3 und NFT in der Ankündigung, schreibt etwa Phoronix, dass es sich dabei auf den ersten Blick auch um Satire handeln könnte. Auch das Magazin The Register kommentiert die Ankündigung gewohnt bissig.

Der Roma-Laptop mit RISC-V befindet sich aber wohl wirklich in Entwicklung und genießt die Unterstützung des RISC-V-Konsortiums, welches das Gerät anscheinend als eine Art Machbarkeitsstudie sieht.

Wie The Register zuvor berichtete, ist solch ein RISC-V-Laptop bereits von Calista Redmond, CEO von RISC-V International, in Aussicht gestellt worden. Auf einer RISC-V-Partnerveranstaltung ist wohl auch ein entsprechendes Gerät ausgestellt worden. Die von diesem Prototypen kursierenden Fotos entsprechen den nun zur Vorstellung bereitgestellten Design-Studien der Roma-Entwicklungsplattform.

Ein Laptop mit RISC-V könnte die Arbeit mit der neuen Befehlssatzarchitektur im Vergleich zu bisherigen Lösungen teils deutlich vereinfachen. So gibt es für RISC-V-SoC bisher meist nur Entwicklungsplatinen oder Embedded-Geräte. Ein vollständiger Laptop wäre ein wichtiger Meilenstein für die Weiterentwicklung von RISC-V.

Der Beitrag RISC-V-Laptop soll native Entwicklung ermöglichen erschien zuerst auf Linux-Magazin.

Eine kurzer, aber weltweiter Ausfall der Cloudflare-Dienste hat Hunderte Kunden und Webseiten betroffen. Die Ursache war wohl ein BGP-Fehler.

Der Anbieter von Internetdiensten Cloudflare hat eine Zusammenfassung und Erklärung eines massiven Ausfalls seines Angebots veröffentlicht, das am Morgen des 21. Juni zwischen 6:34 Uhr und 8:06 Uhr UTC (8:34 bis 10:06 Uhr MESZ) zahlreiche Webseiten betraf. Viele Onlineangebote waren deshalb nicht erreichbar. Der Fehler sorgte laut Cloudflare für einen Abfall des Netzwerkverkehrs auf ungefähr 50 Prozent im Vergleich zur normalen Auslastung.

Ironischerweise wurde der Ausfall durch Änderungen verursacht, die laut Cloudflare, “Teil eines langjährigen Projekts zur Erhöhung der Ausfallsicherheit an unseren größten Standorten war”. Diese Standorte wickeln demzufolge den größten Teil des internen Netzwerkverkehrs ab. Eine Konfigurationsänderungen am Netzwerk sorgte aber für einen Ausfall an diesen Standorten.

Eigentlich sollte genau das durch eine neue Netzwerkarchitektur verhindert werden, die Cloudflare seit einiger Zeit in seinen großen Standorten umsetzt. Wichtigste Idee dabei ist laut dem Anbieter eine neue interne Routing-Ebene, die es ermöglicht, “Teile des internen Netzwerks in einem Rechenzentrum zu Wartungszwecken oder zur Behebung eines Problems einfach zu deaktivieren und zu aktivieren”.

Als technische Erklärung für den Ausfall schreibt Cloudflare, dass diese Netzwerke per BGP miteinander verbunden seien. Einzelne BGP-Richtlinien würden zudem sequenziell evaluiert und dann abgearbeitet. “Während wir eine Änderung an unseren Richtlinien zur Präfix-Ankündigung einführten, führte eine Neuordnung der Bedingungen dazu, dass wir eine wichtige Teilmenge von Präfixen zurückziehen mussten.” Das wiederum habe einen sich selbst verstärkenden Effekt gehabt, da dies den Technikern von Cloudflare erschwert habe, auf die betroffenen Systeme überhaupt zugreifen zu können.

Erschwert worden seien die Arbeiten darüber hinaus durch die Netzwerktechniker selbst, wie Cloudflare schreibt: “Dies verzögerte sich, da die Netzwerkingenieure die Änderungen gegenseitig übergingen und die vorherigen Rücknahme rückgängig machten, was dazu führte, dass das Problem sporadisch erneut auftrat.”

Der Beitrag Cloudflare-Projekt zur Resilienz verursacht Ausfall erschien zuerst auf Linux-Magazin.

Hackern ist es gelungen, Linux auf die A7- und A8-SoCs von Apple zu portieren. Alte Geräte können so wieder genutzt werden.

Die beiden Entwickler Konrad Dybcio und Markuss Broks haben es eigenen Angaben zufolge nach mehr als einem Jahr Arbeit geschafft, Linux auf vergleichsweise alte Apple-Geräte zu portieren, welche die SoCs A7 und A8/A8X verwenden. Nach ersten Bildern eines iPad Air 2 mit Linux, welche die beiden in der vergangenen Woche veröffentlichten, zeigte Dybcio nun eine Zusammenfassung der Arbeiten sowie Anleitungen und Code dafür.

Technische Grundlage dafür, dass Linux überhaupt auf den Apple-Geräten läuft, die das eigentlich nicht zulassen, ist der Checkra1n-Jailbreak. Dabei handelt es sich um eine erweiterte und verbesserte Variante von Checkm8, der wiederum eine nicht behebbare Sicherheitslücke im Boot-ROM ausnutzt, das Apple SecureROM nennt.

Neben dem iPad Air 2 arbeiten die Entwickler an Linux-Ports für iPhones, welche die genannten Chipgenerationen Apples verwenden – etwa das iPhone 5s. Darüber hinaus hofft das Team, seinen Code auf allen Geräten mit einem A7- oder A8-SoC zum Laufen zu bringen. Dazu gehöre auch der erste Homepod Apple, twitterte Dybcio.

Inspiration für die Arbeiten waren laut Dybcio einerseits das Project Sandcastle, das einen Android-Port für das iPhone 7 bereitstellt, sowie andererseits ein altes iPhone 5s, das Dybcio bekommen habe, “um damit rumzuspielen”. Weiter schrieb Dybcio, Broks und er seien nach vielen Versuchen der Portierung immer wieder am Initialisieren der MMU gescheitert.

Das Problem sei letztlich gewesen, die richtige Speicheradresse zum Laden des Linux-Abbilds zu setzen. Was folgte, war laut Dybcio das Hacken unter Linux – und anschließend Treiber für den Interrupt-Controller (AIC) sowie zahlreiche weitere Peripherie-Geräte. Die Patches sollen außerdem in den Hauptzweig von Linux eingepflegt werden.

Dybcio stellt eine Anleitung zum Ausprobieren des Linux-Ports bereit. Voraussetzung ist neben einem der Mobilgeräte ein Rechner mit MacOS zum Ausführen des Checkm8-Jailbreaks.

Der Beitrag Linux läuft auf dem iPad Air 2 erschien zuerst auf Linux-Magazin.

Die Community des Atom-Editors von Github sei inzwischen zu klein und mit den Codespaces und Visual Studio Code gebe es eine gute Alternative.

Der Code-Hoster Github hat angekündigt, die Entwicklung seines eigenen Editors Atom zum Ende des Jahres, am 15. Dezember 2022, einzustellen. Dazu heißt es in der Ankündigung: “Während das Ziel, die Community der Softwareentwickler zu vergrößern, bestehen bleibt, haben wir uns entschieden, Atom in den Ruhestand zu versetzen, um unser Engagement für die Bereitstellung einer schnellen und zuverlässigen Softwareentwicklung in der Cloud über Microsoft Visual Studio Code und Github Codespaces fortzusetzen.”

Begonnen hatte die Entwicklung an Atom bereits im Jahr 2011 mit dem Ziel, einen Editor zu erstellen, der einerseits leicht zu benutzen ist und andererseits sehr tiefgreifend konfigurierbar ist. Im Frühjahr des Jahres 2014 stellte Github schließlich den Code als Open Source bereit. Microsoft folgte schon ein Jahr später mit dem eigenen Editor Visual Studio Code, der auf Atom basiert.

Zu Atom selbst schreibt Github, dass der Editor seit Jahren bereits keine bedeutenden neuen Funktionen mehr erhalte und sich das Team vor allem auf die Pflege und Sicherheitsupdates der Software konzentriert habe. “Da im Laufe der Jahre neue Cloud-basierte Tools aufgetaucht sind und sich weiterentwickelt haben, ist die Beteiligung der Atom-Community deutlich zurückgegangen”, schreibt Github weiter zur Begründung.

Github bezeichnet das nun verkündete Ende als “schweren Abschied”, immerhin sei Atom der Beginn des Electron-Frameworks gewesen, das inzwischen wiederum “Tausende” von Apps als Grundlage für ihre Desktop-Clients verwenden. Da es immer noch Nutzer gebe, die Atom einsetzen, gebe Github der Community nun rund ein halbes Jahr Zeit für einen Wechsel. Neben dem Desktop-Client Visual Studio Code von Github-Mutterunternehmen Microsoft stehen mit den Github Codespaces auch ein Online-Editor und Cloud-IDE als Alternative bereit. Das Entwicklungsteam von Github ist erst im vergangenen Jahr auf die Codespaces gewechselt.

Der Beitrag Github beendet Entwicklung von Atom-Editor erschien zuerst auf Linux-Magazin.

Auch die Nutzer der Virtualisierung auf Macs mit Apple Silicon können künftig auch x86-Apps ausführen – unterstützt wird das für Linux.

Mit der nach dem Rosettastein benannten Technik Rosetta für die aktuellen Macs auf ARM-Basis will Apple seinen Nutzern den Übergang weg von der x86-Architektur erleichtern. Immerhin können damit alte x86-Binärdateien auf dem neuen ARM-Mac ausgeführt werden. Diese Technik stehe künftig auch in Linux-VMs bereit, die auf den Macs mit dem sogenannten Apple Silicon laufen, wie Apple auf seiner Entwicklungsmesse WWDC mitteilt.

Die Dokumentation dazu hat Apple bereits veröffentlicht. Demnach soll die Funktion bereits mit dem kommenden MacOS 13 alias Ventura genutzt werden können, das im kommenden Herbst erscheinen wird. Umgesetzt wird das dabei über das hauseigene Virtualisierungs-Framework. Apple weist jedoch explizit daraufhin, dass dies nicht heiße, dass x86-basierte Linux-Distributionen auf den Macs mit ARM-Chips genutzt werden könnten. Bei der vorgestellten Lösung handelt es sich also nicht um eine komplette Virtualisierung der Architektur, wie dies mit anderer Software möglich ist.

Bei der nun angekündigten Lösung handelt es sich offenbar vielmehr um die Rosetta-Technik, die auch unter MacOS genutzt wird und nun in die Linux-VMs weitergereicht wird. Praktisch umgesetzt wird das über einen zwischen der VM und dem Host-System geteilten Ordner, über den die Laufzeitumgebung von Rosetta bereitgestellt wird. Haupteinsatzzweck der Technik dürfte es sein, x86-basierte Container künftig weiter lokal auf den Maschinen ausführen zu können. Weitere Details zu der Technik soll ein Vortrag auf dem WWDC liefern.

Darüber hinaus diskutieren Nutzer auf Twitter die technische Umsetzung des Rosetta-Ports für Linux und damit die technische Möglichkeit, die Software auch außerhalb der Apple-Umgebung auf anderen ARM-Systemen zu nutzen. Darauf, dass dies möglich sein dürfte, verweist etwa der Entwickler Hector Martin, der das Asahi-Linux-Projekt gegründet hat. Legal wäre diese Art der Nutzung sehr wahrscheinlich nicht, weshalb auch Martin dazu aufruft, Rosetta nicht für diesen Zweck “zu stehlen”.

Der Beitrag WWDC: Apple bringt Rosetta in Linux-VMs erschien zuerst auf Linux-Magazin.