Linux 3.11

Installationsdisketten Windows 3.11 for Workgroups

Immerhin kam der jüngste Abkömmling des Linux-Kernels nicht am gleichen Tag heraus, wie die September-Ausgabe von freiesMagazin, das hätte mich nur geärgert. Damit es bis zum nächsten Kernelrückblick aber nicht zu lang wird, schaue ich mir den Drei-Elfer mal ein bissschen an.

Die noch eingebrachten Änderungen sind sehr überschaubar. Eine Korrektur verbessert das Verhalten bei der Verarbeitung von Multicast-Netzwerkpaketen im Zusammenhang mit IGMP oder dem Multicast Listener Discovery (MLD) unter IPv6, beides Mechanismen zur Organisation von Gruppen von Netzwerkteilnehmern.

Ein paar Daten zum Linux-Kernel 3.11: Die Entwicklung war mit 64 Tagen recht kurz, 62 Tage war das kürzeste, was die 3er Kernel-Serie bislang geschafft hat. Dafür ist auch eine moderate Zahl an Änderungen aufgenommen worden. Der Patch für Linux 3.11 ist mit 9,4 MB etwas kleiner als der Vorgänger, während die Gesamtgröße der Kernelquellen um drei MB auf 108 MB gewachsen ist, wobei hier jeweils mit Gzip gepackte Archive betrachtet werden. „Linux 3.11 for Workgroups“ würde erheblich mehr Disketten benötigen, als das System, von dem es sich den Namen entliehen hat.

Unter den bemerkenswerten Neuerungen sind einige im Umfeld der ARM-Architektur zu finden. Zum einen werden nun große Speicherseiten unterstützt, sowohl für 32bit- als auch 64bit-ARM-Systeme. Dies vereinfacht die Zuweisung großer Speichermengen an Prozesse, indem einfach größere Speicherstücke als die üblichen 4 KiB zum Anwendung kommen. Zum Zweiten unterstützen die Virtualisierer KVM und Xen nun auch die 64bit-ARM-Architektur und kommen somit künftig als Host-Systeme in Frage. Eine Anekdote am Rand: Ein Patch zieht die Behandlung eines Registers gerade, sodass nun prinzipiell Windows-RT-Anwendungen mittels Wine unter dem neuen Linux-Kernel laufen können.

Um die Leistungseinbußen beim Zugriff auf den Auslagerungsspeicher (Swap) zu minimieren, wurde Zswap entwickelt. Normalerweise würden nicht oder wenig genutzte Speicherseiten, aus dem Arbeitsspeicher in den Swap verschoben, der üblicherweise auf einer Festplatte liegt und könnten damit nur mit recht langen Zugriffszeiten aufgerufen werden. Zswap versucht nun, solche Speicherseiten abzufangen und in einen Komprimierten Speicherbereich zu legen um die Verlagerung auf den sehr viel langsameren Massenspeicher zu vermeiden.

Standardmäßig derzeit noch nicht aktiv, da als experimentell betrachtet, lässt der Code für das dynamische Energiemanagement von AMD/ATI Radeon-Grafikprozessoren dennoch hoffen. Die Grafikprozessoren seit der etwa sechs Jahre alten Serie R600 verfügen bereits über die Voraussetzungen, um davon profitieren zu können, sowie dem neuen Code die Reife für den breiten Einsatz zugesprochen wird.

Obwohl Lustre nicht für die breite Masse der Nutzer von Interesse sein wird, ist dieses verteilte Dateisystem doch ein gutes Beispiel für die Vielseitigkeit von Linux. Lustre ist für die Nutzung auf Hochleistungs-Rechnersystemen ausgerichtet und kann zehntausende von Knoten bedienen. Es soll mehrere Petabyte an Speicher verwalten können, die über hunderte von Servern verteilt sein dürfen und dabei einen Gesamtdurchsatz im Terabyte-pro-Sekunde-Bereich unterstützen (Wow!). Derzeit wird es auf sechs der zehn schnellsten Supercomputer genutzt. Der nun in den staging-Bereich aufgenommene Code liefert die Client-Unterstützung für Lustre, auch wenn diese derzeit noch als experimentell gekennzeichnet ist. Außerhalb des Linux-Kernels wurde Lustre bereits seit 1999 entwickelt und kam erstmals 2003 beim MCR Linux Cluster zum Einsatz.

Ich habe nur ein paar der aus meiner Sicht interessantesten Punkte betrachtet. In der kommenden Ausgabe von freiesMagazin werde ich wohl noch etwas ausführlicher.

Die kleine Statistik:

Commits geänderte Dateien eingefügte Zeilen gelöschte Zeilen Datum Tage *
3.11-rc1 10 160 8 889 770 288 238 578 14.07.2013 14
3.11-rc2 252 662 3 588 93 838 21.07.2013 7
3.11-rc3 379 339 6 882 4 754 29.07.2013 8
3.11-rc4 394 386 6 662 5 011 04.08.2013 6
3.11-rc5 220 188 1 850 1 143 11.08.2013 7
3.11-rc6 170 184 1 580 777 11.08.2013 7
3.11-rc7 166 150 996 505 25.08.2013 7
3.11 102 99 956 410 02.09.2013 8

* Tage seit dem letzten rc/Release

Version Commits geänderte Dateien eingefügte Zeilen gelöschte Zeilen Datum Tage *
3.0 9 843 7 946 554 267 440 894 22.07.2011 64
3.1 9 380 9 181 726 251 602 017 24.10.2011 94
3.2 12 695 12 608 1 645 447 1 417 264 04.01.2012 72
3.3 11 416 10 698 599 885 432 464 18.03.2012 74
3.4 11 829 11 086 576 155 358 368 20.05.2012 63
3.5 11 771 9 631 623 283 410 763 21.07.2012 62
3.6 11 129 8 296 528 478 256 828 30.09.2012 71
3.7 13 004 15 886 1 570 793 1 247 129 10.12.2012 71
3.8 13 525 11 701 577 870 352 685 18.02.2013 70
3.9 12 955 11 120 609 300 339 293 29.04.2013 70
3.10 14 736 10 471 663 996 395 390 30.06.2013 62
3.11 11 850 9 692 789 124 341 338 02.09.2013 64

* Tage seit dem letzten Release

Quellen:

Tags:

Kommentare

Ok der vergleich währe wohl nicht wirklich Brauchbar, aber würde man einen kerne für eine mit Win 3.11 kompatiblen Rechner kompilieren. Wie gross wäre der dann. Und würde man dazu noch den schmalbrüstigste Dektop dazu tun. Wie wären die Grössenverhältnisse zwischen den beiden?

Die Frage lässt sich höchstens über den Daumen beantworten. Damn Small Linux liefert eine grafische Umgebung mit den wichtigsten Tools und ist auf (aus heutiger Sicht) extralahme Rechner getrimmt, die um die 50 MB Festplatte, nur 16 MB RAM und einen 486er-Prozessor haben – so in ungefähr wie das Ding, auf dem bei mir mal M$-DOS 6.x mit Windows 3.11 lief. Trotzdem war auf den Installations-Disketten für Win 3.11 nur knapp 14 MB Platz, also dürften mindestens 35 MB Differenz dazwischen liegen – Ich weiß nicht, wie viel Platz die Systeme unkomprimiert und installiert benötigen.

Ein aktueller Kernel würde auf manchen der Win3.11-belasteten Rechner schon gar nicht mehr starten: Die Unterstützung für die 386-Prozessoren, für die Linux ursprünglich entwickelt wurde, ist mit dem Kernel 3.8 abhanden gekommen.