Ein langjähriger Debian-Entwickler glaubt, dass ohne proprietäre Firmware in der Linux-Distribution nicht mehr viel geht.

Eines der wohl wichtigsten Prinzipien der Debian-Community ist es, dass die erstellte Linux-Distribution und Software des Projekts komplett freie Software ist. Die dafür festgelegten Richtlinien (DFSG) sind sogar Teil des eigenen Gesellschaftsvertrags, der eine Art Verfassung für das gesamte Projekt ist. Der langjährige Debian-Entwickler Steve McIntyre schreibt nun aber in seinem Blog, dass das Projekt diesen Standpunkt zumindest für Firmware-Pakete überdenken müsste.

McIntyre ist seit 1996 an dem Debian-Projekt beteiligt, fungierte als Projektleiter und ist an den Arbeiten des Firmware-Supports sowie für den Debian-Installer beteiligt. Der Entwickler schreibt: “Meiner Meinung nach ist die Art und Weise, wie wir mit (unfreier) Firmware in Debian umgehen, ein Chaos, und das schadet vielen unserer Benutzer jeden Tag.”

Dass dem so ist, ist wohl schlicht der generellen Entwicklung der IT geschuldet. Noch vor etwa einem Jahrzehnt sei Firmware höchstens für WLAN-Adapter notwendig gewesen, so McIntyre. Inzwischen werde derartiger Code aber auch für GPUs, Sound-Ausgaben und auch für die Haupt-CPU eines Systems selbst benötigt. In den allermeisten Fällen ist dieser Code proprietär und wird den Debian-Richtlinien folgend nicht standardmäßig mit dem System ausgeliefert.

McIntyre schreibt dazu: “Lange Zeit haben wir so getan, als ob die Unterstützung und Einbindung von (unfreier) Firmware auf Debian-Systemen nicht notwendig sei. Wir wollen unseren Benutzern keine (unfreie) Firmware zur Verfügung stellen, und in einer idealen Welt würden wir das auch nicht müssen. Dies ist jedoch ganz klar kein vernünftiger Weg mehr, wenn wir versuchen, viele gängige aktuelle Hardware zu unterstützen.”

Als mögliche nächste Schritte schlägt McIntyre vor, die bisher inoffiziellen Debian-Abbilder mit nicht-freier Firmware wie die offiziellen zu behandeln oder direkt nur noch offizielle Images mit proprietärer Firmware zu verteilen. Möglich wäre laut dem Entwickler aber auch, die Firmware-Komponenten separat zum Rest der proprietären Software zu pflegen und etwa in ein eigenes Repository auszulagern. Über eine spezielle Option könnte dann die nicht freie Software in den offiziellen Abbildern genutzt werden.

Über die von McIntyre vorgestellten Optionen will der Entwickler in einer Art Basisabstimmung (General Resolution) des Debian-Projekts entscheiden lassen. Erhält eine der Optionen eine Mehrheit, dürfte diese umgesetzt werden.

Der Beitrag Debian bekommt Probleme mit proprietärer Firmware erschien zuerst auf Linux-Magazin.

Die alten Framebuffer-Treiber in Linux werden seit etwa einem Jahrzehnt kaum noch gepflegt. Fedora macht nun Schluss mit der Technik.

Die Version 36 der Linux-Distribution Fedora, deren Veröffentlichung für kommende Woche geplant ist, wird auf die alten Framebuffer-Treiber (Fbdev) des Linux-Kernel verzichten. Darauf weist der an den Arbeiten beteiligte Entwickler Javier Martinez in einem aktuellen Blogpost hin. Die Framebuffer-Geräte im Linux-Kernel sind die historische Möglichkeit für eine einfache Grafikausgabe.

An einem prinzipiellen Ersatz der Nutzung des Framebuffers arbeitet die Linux-Kernel-Community mit dem Direct Rendering Manager (DRM) seit etwa zwei Jahrzehnten. Erst die Nutzung des DRM ermöglicht die moderne und inzwischen standardmäßige 3D-Hardwarebeschleunigung von Anwendungen oder dem Desktop. Dass der Framebuffer-Support dennoch weiter in Linux verfügbar ist, liegt an der Abwärtskompatibilität. So ist der Framebuffer bisher genutzt worden, sofern aus unterschiedlichen Gründen kein DRM-Treiber bereitstand.

Wie Martinez in seinem Blog schreibt, wird der Framebuffer-Code durch die Linux-Entwickler aber bereits seit rund zehn Jahren als veraltet angesehen und seit sieben Jahren werden auch keine neuen Framebuffer-Treiber mehr in den Code aufgenommen. Die nun von Fedora umgesetzte endgültige Abkehr gelang aber erst durch einen SimpleDRM genannten Treiber aus dem vergangenen Jahr. Damit ist eine Ausgabe analog zu dem alten Framebuffer per DRM auch dann möglich, wenn kein DRM-Treiber für die genutzte Hardware bereitsteht oder dieser deaktiviert wird.

Bisher hat der Framebuffer-Code die von der Firmware (BIOS oder UEFI) initialisierten Video-Modi zur Grafikausgabe für das laufende System übernommen. Dafür sorgt nun SimpleDRM. Für die Nutzung des neuen Treibers in Fedora mussten die beteiligten Entwickler laut Martinez außerdem noch zahlreiche Bugs im Linux-Grafik-Stack beheben, etwa in Plymouth, Xorg oder GDM. Grund dafür waren im Code umgesetzte Annahmen über das Vorhandensein des Framebuffer-Geräts.

Der Beitrag Linux-Grafik: Fedora verzichtet auf alte Framebuffer-Treiber erschien zuerst auf Linux-Magazin.

Ein Ausfall von Slack im Februar resultierte aus einem kaskadierenden Fehler, den das Team aufgrund der Komplexität nur schwer beheben konnte.

In seinem Engineering-Blog beschreibt ein Technikteam des Messengerdienstes Slack Ursachen und Fehlerbehebung eines Ausfalls im vergangenen Februar. Dabei hält das Team schon zu Beginn eine wohl eher unbequeme Erkenntnis fest: “Dieser Vorfall war ein Paradebeispiel für ein komplexes Systemversagen: Es gab eine Reihe von Faktoren, die dazu beitrugen, und ein Teil des Vorfalls bestand aus einem kaskadenartigen Fehlerszenario.”

Der Ausfall des Systems machte sich dem Beitrag zufolge dadurch bemerkbar, dass Nutzer Probleme damit hatten, sich am Morgen (US-Zeitzonen) mit dem Messenger zu verbinden. Unabhängig davon erhielt das Team automatische Fehlermeldungen des Alarmsystems.

Die Probleme zeigten sich laut dem Blogpost an der Technik durch einen deutlichen Anstieg der Last der Datenbanksystemen. Das Team schreibt: “Was anfangs nicht klar war, war die Frage, warum die Datenbank so stark belastet wurde (..) und wie wir zu einem normalen Betriebszustand gelangen konnten.” Lösen konnte das Slack demnach nur durch eine größere interne Kooperation unter Beteiligung mehrerer Teams.

Die zunächst naheliegende Lösung, zur Lastvermeidung die Anzahl neuer Clients zu reduzieren, die sich mit neu mit dem System verbanden, und anschließend diese Zahl wieder langsam zu erhöhen, hatte aber nicht den erhofften Erfolg. Das Team war offenbar schlicht zu ungeduldig und erzeugte zu schnell wieder zu viel Last, ohne den zugrunde liegenden Fehler zu beheben.

Zur Ursachensuche schreibt das Team: “Wie kam es dazu, dass wir von einem stabilen Auslieferungszustand in einen Zustand der Überlastung gerieten? Die Antwort lag in den komplexen Interaktionen zwischen unserer Anwendung, den Vitess-Datenspeichern, dem Caching-System und unserem Service Discovery System.” Bei Vitess handelt es sich um ein Datenbank-Cluster-System für MySQL, das gestartet wurde, um die Skalierungsprobleme von Youtube zu lösen.

Ausgangspunkt war den Angaben zufolge ein Upgrade von Consul, das für Service Discovery genutzt wird. Wie schon mehrfach zuvor sollten dabei nur 25 Prozent der Server aktualisiert werden. Das hatte zwar zuvor geklappt, zusammen mit einer gestiegenen Last durch die Clients führte es aber letztlich am Tag des Ausfalls von Slack zu bisher unbekannten Problemen.

Mit den Upgrades von Consul wurden nach und nach die davon überwachten Cache-Knoten offline genommen. Die Automatisierung von Slack startete dann zwar ersatzweise neue Knoten mit Memcached, letztlich führte der Updateprozess aber dazu, dass sich die Cache Hit Rate immer stärker verringerte.

Da die Abfragen im Cache nicht erfolgreich waren, wurden die eigentlichen Datenbanken verstärkt angefragt, die aufgrund einer spezifischen Anfrage und der Verteilung der angefragten Daten im System immer mehr unter Last gerieten. Dazu schreibt das Team: “Die Datenbank war überfordert, da die Leselast im Verhältnis zum Prozentsatz der Cache Misses superlinear anstieg.” Die Systeme erreichten laut Slack schließlich einen Kipppunkt, ab dem sich der Fehler selbst weiter verstärkte.

Das Team reduzierte zum Beheben der Probleme zunächst die Anzahl sich verbindender Clients, verbesserte die ineffiziente Datenbankabfrage, um nur noch jene Daten zu lesen, die tatsächlich im Cache fehlten, und die Datenbank-Replicas wurden als Systeme zum Lesezugriff bereitgestellt. Letztlich konnte der Cache so wieder aufgefüllt werden, bis alle Clients ihre Daten wieder daraus erhalten konnten.

Der Beitrag Slack erklärt “Paradebeispiel für komplexes Systemversagen” erschien zuerst auf Linux-Magazin.

Riesige Sprachmodelle sind meist nicht öffentlich verfügbar oder replizierbar. Meta will das mit OPT ändern und gute Qualität liefern.

Ein großes Forschungsteam der KI-Abteilung des Facebook-Mutterkonzerns Meta hat die Open-Pre-trained-Transformer-Sprachmodelle (OPT) in einer wissenschaftlichen Abhandlung vorgestellt. Das dabei wohl wichtigste Anliegen der Beteiligten ist es, ein modernes und großes Sprachmodell zu erstellen, das, anders als bisher meist üblich, komplett zur Verfügung gestellt wird, um die die konkreten Einzelheiten untersuchen zu können.

Das Team von Meta vergleicht das Sprachmodell selbst in Bezug auf Ziel, Fähigkeiten und Größe mit GPT-3 von OpenAI. Letzteres steht zwar zur Nutzung zur Verfügung, jedoch nur über eine API. Eine Untersuchung der inneren Abläufe und Gewichtungen ist so für Dritte nicht möglich. Im Vergleich zu GPT-3 soll die größte Variante von OPT mit 175 Milliarden Parametern außerdem nur ein Siebentel des CO2-Fußabdrucks aufweisen.

Ziel der Entwicklung sei es, “reproduzierbare und verantwortungsvolle Forschung in großem Maßstab zu ermöglichen”. Ebenso sollen die Auswirkungen dieser riesigen Sprachmodelle besser untersucht werden können. Dazu heißt es weiter: “Die Definitionen von Risiko, Schaden, Verzerrung, Toxizität usw. sollten von der gesamten Forschungsgemeinschaft formuliert werden, was nur möglich ist, wenn Modelle zur Untersuchung bereitstehen.”

Konkret geplant ist nun von Meta, dass die OPT-Modelle mit einer Parametergröße von 125 Millionen bis 30 Milliarden frei zur Verfügung gestellt werden. Der Zugriff auf das Modell mit 175 Milliarden Parametern soll auf Anfrage für Forschungsteams ermöglicht werden. Das gelte für Regierungen, Zivilgesellschaft, Wissenschaft sowie Industrieteilnehmer. Ebenso frei veröffentlicht werden soll das Team-eigene Logbuch, das beim Erstellen des Modells geführt wurde, sowie der Code, mit dem das Modell erstellt wurde.

Der Beitrag KI: Meta will GPT-3-Alternative öffentlich bereitstellen erschien zuerst auf Linux-Magazin.

Mit den aktuellen Rust-Patches für den Linux-Kernel bekommt das Projekt ein neues Programmiermodell, das es mit C so nicht gibt.

Der Betreuer des Projekts, Rust im Linux-Kernel zu etablieren, Miguel Ojeda, hat seine Patch-Serie aktualisiert und dabei erstmals Unterstützung für Netzwerk-Code umgesetzt sowie erste Arbeiten am Async-Support vorgenommen. Beides zusammen könnte ein grundlegend neues Programmiermodell im Linux-Kernel etablieren, sofern die Rust-Patches irgendwann im stabilen Hauptzweig landen.

Für die Netzwerkunterstützung sind vor allem einige sehr wichtige und grundlegende Datentypen hinzugekommen. Dazu zählen etwa Typen für IPv4- und IPv6-Adressen sowie Socket-Adressen für IPv4 und IPv6, ein Buffer für Sockets, Namensräume sowie mit TcpListener und TcpStream ein prinzipieller Ersatz für die klassischen Netzwerk-Sockets.

Darüber hinaus ist das Async-Modul von Rust auf den Linux-Kernel adaptiert worden. Damit könnte das Projekt erstmals eine in die Sprache eingebaute Möglichkeit zur asynchronen Programmierung erhalten. Das ist mit C so bisher nicht möglich. Umsetzen lassen soll sich so etwa asynchroner TCP-Socket-Code, was Ojeda auch direkt mit einem Code-Beispiel in Rust illustriert und dieses erklärt. Dazu heißt es, dass der Code sehr ähnlich zu seiner synchronen Variante sei, der sogenannte Executor aber noch fehle.

Neu zum Rust-Code hinzugekommen sind außerdem Paketfilter, einige Locking-Mechanismen, eine einfache Mutex-Variante, die weniger Funktionen als das vorhandene C-Pendant bietet, sowie ein neuer Datentyp zu Referenzzählung, der das Definieren von Wrapper für den C-Code erleichtern soll. Möglich ist mit dem Rust-Code nun auch, Dokumentationstests auszuführen. Durch Umbauarbeiten am Code lassen sich so auch Kernel-APIs testen.

Der Beitrag Programmierung: Rust im Linux-Kernel bekommt Async und Netzwerk-Code erschien zuerst auf Linux-Magazin.

Der Global Interpreter Lock in Python verhindert echte Nebenläufigkeit. Ein Projekt zur Abschaffung trifft auf Begeisterung des Kern-Teams.

Im Blog der Python Foundation fasst Entwickler Alex Waygood eine der wohl wichtigsten Diskussionen des vergangenen Python Language Summit zusammen: die Frage nach der Abschaffung des Global Interpreter Lock (GIL) der Sprache. Der GIL verhindert effektiv eine echte Nebenläufigkeit der Sprache. In der Vergangenheit gab es immer wieder Versuche, diese Technik in der Standardimplementierung CPython abzuschaffen. Eine neue Idee stößt nun offenbar auf große Unterstützung.

Konkret handelt es sich dabei um das Nogil-Projekt von Sam Gross, das auf vorigen Arbeiten zu der Idee basiert, den GIL in Python abzuschaffen. Verfügbar ist der experimentelle Beispielcode seit Oktober 2021. Er hatte zunächst vor allem Probleme bei Python-Projekten, die Drittanbieter-Code nutzten.

Zu dem Problem, das sich durch den Verzicht auf den GIL ergibt, heißt es im Blog: “Damit Python auch ohne die GIL effektiv arbeiten kann, müssen zu einem Großteil des Codes neue Sperren hinzugefügt werden, um sicherzustellen, dass er weiterhin Thread-sicher ist. Das Hinzufügen neuer Sperren zu bestehendem Code kann jedoch sehr schwierig sein, da es in einigen Bereichen zu großen Verlangsamungen kommen kann.” In einem früheren Experiment führte der Verzicht auf den GIL etwa zu einer massiven Verlangsamung für Single-Thread-Code.

Gross’ neue Arbeiten stoßen aber offenbar auf “Begeisterung” beim Rest des Kern-Entwicklungsteams von Python. Zu lösen ist vor allem die Frage, wie eine derart massive Änderung in CPython umgesetzt werden könnte. Gross schlägt dafür einen Compiler-Flag vor. Letztlich hieße das aber auch, zwei Versionen parallel zueinander zu pflegen – mit und ohne GIL. Eine finale Entscheidung zur Umsetzung ist noch nicht gefallen.

Der Beitrag Unterstützung für Python ohne Global Interpreter Lock wächst erschien zuerst auf Linux-Magazin.

Amazon, Microsoft, Google und andere wollen das Problem der IT-Security vor allem mit Geld lösen. 30 Millionen US-Dollar dafür stehen schon.

Mit dem Kollaborationsprojekt der Open Source Security Foundation (OpenSSF) wollen Größen der IT-Industrie ihre Security-Praxis vereinheitlichen und so die Open-Source-Welt besser absichern. Ein dafür vorgestellter Zehn-Punkte-Plan der OpenSSF soll im Laufe der kommenden zwei Jahre eine Finanzierungssumme von etwa 150 Millionen US-Dollar dafür umfassen, wie die Organisation mitteilt.

Eine erste Tranche der geplanten Summe stammt dabei von frühen Unterstützern der OpenSSF. Dazu zählen laut Ankündigung Amazon, Ericsson, Google, Intel, Microsoft, und VMware, die dafür zunächst gemeinsam 30 Millionen US-Dollar bereitstellen wollen. Dazu heißt es weiter: “Im Zuge der weiteren Entwicklung des Plans werden weitere Finanzmittel ermittelt, und die Arbeit wird in dem Maße beginnen, wie die einzelnen Finanzströme vereinbart werden.”

Zu den Maßnahmen des Zehn-Punkte-Plans gehören unter anderem eine bessere Ausbildung für die Security, der Aufbau einer Risiko-Analyse für Tausende Open-Source-Komponenten, das Ausrollen digitaler Signaturen für Veröffentlichungen sowie der Ersatz bestehender Komponenten in einer Sprache mit Speichersicherheit. Letzteres wird derzeit bereits von Google vorangetrieben, etwa über ein Rust-Modul für den Apache-Webserver, Rustls oder Rust im Linux-Kernel.

Die OpenSSF setzt außerdem auf Code-Scanning oder das Absichern der sogenannten Software-Supply-Chain, was Paketmanager wie NPM umfasst. Ein großer Teil der Arbeiten wird dabei nicht von der Organisation selbst umgesetzt, sondern von deren Mitgliedsunternehmen. So hat Google eine Open Source Maintenance Crew angekündigt, die gemeinsam mit den Upstream-Projekten an deren Sicherheit arbeiten soll.

Der Beitrag OpenSSF: 150 Millionen US-Dollar sollen Open Source absichern erschien zuerst auf Linux-Magazin.

Erstmals erkennt ein US-Gericht an, dass aus der GPL auch Verbraucherrechte folgen könnten. Die Kläger bezeichnen das als “Wendepunkt”.

Die für die Vertretung von zahlreichen Softwareprojekten sowie auch für ihre GPL-Klage bekannte Organisation Software Freedom Conservancy (SFConservancy) meldet einen möglicherweise weitreichenden Zwischenerfolg in ihrer Klage gegen den Smart-TV-Hersteller Vizio. Vizio wollte demnach die GPL-Klage allein auf Grundlage des Urheberrechts verhandeln lassen. Das ist nun aber laut der SFConservancy von einem US-Bundesgericht zurückgewiesen worden, wie die Organisation in ihrem Blog schreibt. Die Rechtmäßigkeit einer möglichen Verbraucherklage könnte also gegeben sein.

Der Hersteller soll laut SFConservancy die GPL-Quellen seiner genutzten Software nicht GPL-konform bereitstellen und auch nicht mehr auf Anfragen der SFConservancy reagiert haben. Mit einer besonderen und bisher einmaligen Klageart will die Organisation versuchen, die Rechte der GPL durchzusetzen. Dazu versetzt sich die SFConservancy auf den Standpunkt der Verbraucherrechte. Immerhin ist die Copyleft-Lizenz GPL explizit darauf ausgerichtet, dass diese denjenigen den Zugriff auf den Quellcode einer Software ermöglichen soll, die auch die Binärdateien erhalten – also Endkunden.

Bisher wird die GPL von vielen Juristen und auch für entsprechende Klagen zur Rechtedurchsetzung als reine Urheberrechtslizenz gesehen. Einzelne Urheber müssen also zunächst nachweisen, dass diese tatsächlich Rechte an einem bestimmten Werk halten, um die Bedingungen der GPL zur Offenlegung der Quellen durchsetzen zu können. Die GPL-Klage von Linux-Kernel-Entwickler Christoph Hellwig gegen VMware hat gezeigt, wie schwierig das sein kann.

Die Geschäftsführerin der SFConservancy und Juristin Karen Sandler schreibt zu der aktuellen Entscheidung: “Das Urteil ist ein Wendepunkt in der Geschichte der Copyleft-Lizenzierung. Dieses Urteil zeigt, dass die GPL-Vereinbarungen sowohl als Urheberrechtslizenzen als auch als vertragliche Vereinbarungen funktionieren.” Die SFConservancy sieht ihre Klage dabei als zentralen Bestandteil eines Rechts auf Reparatur moderner IT-Hardware. Immerhin kann nur durch den Zugang zu den Software-Quellen eine vollständige Reparatur eines Geräts gewährleistet werden.

Der Beitrag Vizio: GPL-Durchsetzung darf als Verbraucherklage verhandelt werden erschien zuerst auf Linux-Magazin.

Das Tape-Archiv eines BBS mit Schwarzkopien aus den 90ern lädt Google-Entwickler Tavis Ormandy zum Retro-Hacking ein.

Der bei Google angestellte Hacker und Sicherheitsforscher Tavis Ormandy hat ein Faible für die Kommandozeile und Retro-Computing – insbesondere für die Tabellenkalkulationen Lotus 1-2-3 aus den 80ern. Ormandy schreibt gar, er wäre eine 1-Mann-Enthusiasten-Community für das Programm, immerhin pflegt er einen eigenen Display-Treiber, damit die Anwendung gut auf modernen DOS-Emulatoren aussieht. In seinem Blog beschreibt der Entwickler nun, wie er die Tabellenkalkulationen auf Linux portiert hat.

Der Erklärung zufolge versuchte Ormandy in den vergangenen Jahren vor allem immer wieder, mehr über die speziell für Lotus 1-2-3 erstellte Erweiterungssprache herauszufinden sowie über das dazu notwendige SDK. Das SDK selbst sei aber für rund 400 US-Dollar verkauft worden und Ormandy konnte davon zunächst kein Backup mehr ausfindig machen.

Wie der Entwickler aber schreibt, fand er letztlich eine Person, die “in der BBS-Szene der 90er Jahre als Sysop tätig war”. In den Tape-Archiven der alten BBS-Nachrichten, die diese Person noch hatte, fand Ormandy eine Schwarzkopie des SDK und konnte damit neue Plugins bauen.

Darüber hinaus schreibt Ormandy: “Es stellte sich heraus, dass das BBS auch eine Schwarzkopie von Lotus 1-2-3 für Unix hatte. Dieses Programm galt weithin als verschollen – man sagte mir, dass es nicht mit einem populäreren Unix-Büropaket namens SCO Professional konkurrieren konnte, weshalb nicht viele Kopien verkauft wurden.”

Ormandy musste daraufhin zunächst mit dem Abbild-Format aus den 80ern kämpfen, das er nie zuvor gesehen habe. In dem Archiv fand der Entwickler nach dem Umwandeln und Entpacken aber die komplette Binärdatei mit sämtlichen Symbolen und Debug-Informationen der Tabellenkalkulationen.

Um die Anwendung aber noch auf Linux ausführen zu können, musste der Objektcode von Coff in das Elf-Format von Linux überführt werden. “Lustigerweise war die erste Version von Linux noch nicht einmal veröffentlicht worden, als diese Objektdatei kompiliert wurde”, schreibt Ormandy dazu. Probleme machten ihm zusätzlich zu dem Format auch inkompatible Systemaufrufe und weiteres.

Für die Umwandlung schrieb Ormandy deshalb ein eigenes kleines Programm. Die dazu notwendigen Wrapper-Funktionen bereiteten ihm aber wiederum einige Probleme, weil diese doch komplexer waren als erwartet. Zur Ausführung der Anwendung musste Ormandy aber auch noch sein Reverse-Engineering-Wissen nutzen, um die Lizenzabfrage von Lotus 1-2-3 zu umgehen.

Den Code, um die mehr als 30 Jahre alte Tabellenkalkulationen auf Linux auszuführen, stellte Ormandy auf Github. Eine Kopie des alten Lotus 1-2-3 hinterlegte der Entwickler darüber hinaus im Internet-Archiv.

Der Beitrag Retro Computing: Lotus 1-2-3 auf Linux portiert erschien zuerst auf Linux-Magazin.

Seit zwei Jahren arbeitet die Perl-Community an der Version 7. Doch eine Veröffentlichung ist weiter nicht in Sicht.

Das Leitungsgremium der Programmiersprache Perl gibt in einem aktuellen Blogpost eine Aussicht auf die kommenden Version 7 der Sprache sowie vor allem auf deren geplanten Veröffentlichungstermin. Wirklich eindeutig beantworten können und wollen das die Beteiligten zwar nicht, der Blogpost soll aber dazu dienen, endlich eine offizielle Stellungnahme dazu veröffentlichen zu können.

Die Arbeit an Perl 7 hatte das Team überraschend vor rund zwei Jahren angekündigt. Die Community der Sprache will damit vor allem zahlreiche alte Funktionen überwinden, die sich nach wie vor in dem aktuellen Perl 5 finden, dessen erste Version bereits im Oktober 1994 erschienen war.

In den letzten Jahrzehnten wurden aber immer mehr von den Standards abweichende Einstellungen erforderlich, da Default-Werte nicht geändert werden sollten, um die Kompatibilität zu den Vorversionen nicht zu brechen. Neu eingeführte Pragmas müssen deshalb immer einzeln aktiviert werden. In Version 7 sollen etwa die Strict- und Warning-Features automatisch aktiviert sein.

Der genaue Umgang mit diesen Plänen sorgt weiter für Diskussion in der Perl-Community und hat sogar zu komplett neuen internen Regeln samt der Etablierung des Leitungsgremiums geführt. Und dieses schreibt nun: “Im Moment ist unser Plan, weiterhin neue Funktionen einzuführen und alle bestehenden experimentellen Funktionen aufzulösen, so dass sie entweder fallengelassen oder zu nicht-experimentellen Funktionen werden (und somit im Versionspaket enthalten sind).”

Das wiederum führe aber dazu, das viele Nutzer nicht wüssten, welche Version von Perl jetzt genau welche dieser Funktionen unterstütze und welche nicht. “Irgendwann in der Zukunft” werde das Leitungsgremium aber entscheiden, “dass die Funktionen zusammengenommen einen ausreichend großen Schritt nach vorne darstellen, um eine neue Basisversion für Perl zu rechtfertigen. Wenn das passiert, wird die Version auf 7.0 angehoben.”

Der Beitrag Perl 7 wird fertig, wenn es soweit ist erschien zuerst auf Linux-Magazin.

Viele Nutzer fordern es seit Jahren: Nun kommt das Windows Subsystem für Linux auch offiziell auf den Windows Server.

Mithilfe eines Patch-Updates, das sich derzeit noch in einer Vorschauphase befindet, erhält Windows Server 2022 erstmals offiziell Unterstützung für das Windows Subsystem für Linux (WSL). Das gibt unter anderem der für das WSL zuständige Program Manager Craig Loewen auf Twitter bekannt.

Konkret genutzt werden kann das WSL auf Windows Server laut Loewen derzeit mit dem Patch KB5014021. In den dazugehörigen Release Notes findet sich jedoch noch keine entsprechende Information. Die Funktion des WSL soll außerdem “bald” als reguläres Update für Microsofts Server-Betriebssystem bereitstehen.

Der bei Microsoft für den Azure Stack HCI und Windows Server verantwortliche Jeff Woolsey schreibt, dass das mit dem kumulativen Juni-Update umgesetzt werden soll. Mit der Einführung des WSL in Windows Server endet vorerst eine jahrelange Produktentwicklung, mit der Microsoft sein Betriebssystemangebot revolutioniert hat. Erstmals kündigte Microsoft die Technik vor sechs Jahren an, damals noch als eine Emulations- und Übersetzungsschicht, die Linux-Aufrufe auf Windows überträgt. Mit dem WSL 2, das nun auch erstmals im Windows Server genutzt wird, führt Windows einen Linux-Kernel in einer virtuellen Maschine auf einem minimalen Hypervisor aus. Das ermöglicht eine volle Unterstützung nativer Linux-Software. Ob Microsoft hier künftig Unterschiede etwa im Support-Umfang im Vergleich zum WSL auf dem Windows Desktop macht, ist derzeit noch nicht bekannt.

Immerhin ist das WSL in Windows 10 und 11 eigentlich nur als Entwicklungsumgebung gedacht. Mit einem Verweis darauf erteilte Loewen dem Wunsch zur Unterstützung des WSL 2 in Windows Server durch Nutzer auch noch vor einem Jahr eine Absage. Zum produktiven Linux-Einsatz empfahl das Team damals eine Hyper-V VM oder Azure Stack HCI. Künftig gibt es nun aber doch offiziell das WSL in Windows Server.

Der Beitrag Microsoft: Windows Server 2022 bekommt WSL 2 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Durch den Wechsel auf eine neue Komprimierung konnte AWS den Speicherplatzbedarf im Exabyte-Bereich reduzieren.

Mit dem Wechsel des Kompressionsalgorithmus von Deflate in Gzip auf Zstd habe der Cloud Hoster AWS eine Reduktion des Speicherplatzbedarfs für komprimierte S3-Speicher um 30 Prozent senken können. Das berichtet der ehemalige Vice President für Nachhaltigkeit bei dem Unternehmen, Adrian Cockcroft, auf Twitter. Diese Einsparung bewege sich im Exabyte-Bereich, heißt es weiter.

Das Kompressionsverfahren Zstd, kurz für Zstandard, stammt ursprünglich von Yann Collet, der dieses bei Facebook erstellt hat. Zstd verspricht eine ähnlich hohe Kompressionsrate wie das bislang gängige Zlib, soll aber eine deutlich schnellere Kompression und Dekompression ermöglichen. Im Vergleich zu Lzo soll hingegen die Kompressionsrate von Zstd höher sein. Die Technik nutzt teilweise eine Variante des Kodierungsverfahrens Asymmetric Numeral Systems (ANS), dessen Verwendung in der Vergangenheit zu Patentstreits führte, da der Erfinder das System eigentlich freihalten möchte.

Facebook nutzte Zstd zuerst für das Dateisystem Btrfs und die Technik wanderte bald nach der Erstellung standardmäßig in den Linux-Kernel. Inzwischen nutzen weitere Teile des Kernels ebenfalls Zstd, einige Linux-Distributionen nutzen die Technik für ihre Pakete und das in vielen Linux-Distributionen standardmäßig als Pack- und Archivierungsprogramm verwendete Tar des GNU-Projekts unterstützt ebenfalls Zstd.

Über die Einsparungen bei AWS dank Zstd schrieb Cockcroft als Antwort auf die Frage des Elektroingenieurs Dan Luu, wie viel Müll wohl durch Collet und dessen Erstellung von Zstd habe vermieden werden können. Für Twitter spare die Nutzung von Zstd im Jahr demnach einen mittleren achtstelligen Betrag an Kosten ein, schreibt Luu. Im dem geschilderten Fall von AWS dürfte der Betrag noch deutlich größer sein.

Der Beitrag AWS spart 30 Prozent Speicherplatz dank Zstd erschien zuerst auf Linux-Magazin.