Manjaro lässt 32-Bit endgültig fallen

Verfasst von

Bereits 2017 stellte die auf Arch Linux basierte Distribution Manjaro die Unterstützung für die 32-Bit Plattform ein. Manjaro 17.03 sollte die letzte Version sein, die Besitzer alter Schätzchen ohne 64-Bit Unterstützung installieren können. Als Gründe gaben die Entwickler an, die abnehmende Zahl an Anwendern rechtfertige nicht die schwieriger werdende Unterstützung für diese Plattform.

Kein 32-Bit-Abbild mehr

Über das Projekt manjaro32.org konnte anschließend die Unterstützung für weitere drei Jahre bereitgestellt werden. Das Projekt muss nun aus Zeitmangel und wegen Hardwareversagens auch die Segel streichen. So verkündete Projektleiter Phillip Müller jetzt das endgültige Aus für i686 bei Manjaro.

Zunehmende Zahl

Damit folgt Manjaro einer zunehmenden Zahl an Distributionen, die in den letzten Jahren beschlossen, die 32-Bit Architektur aufzugeben, um die vorhandenen Entwickler-Ressourcen auf 64-Bit zu konzentrieren. Darunter sind Projekte wie Fedora, Tails und Linux Mint, OpenMandriva und GhostBSD.

Canonicals Sonderweg

Canonical revidierte aufgrund von vielfachem Protest aus der Community seine Pläne mehrmals. Die Auslieferung von Abbildern mit der Plattform wurde bereits nach Ubuntu 18.04 eingestellt, Canonical wollte allerdings 2019 auch die entsprechenden Pakete aus den Archiven entfernen.

Noch ausreichend Unterstützung

Trotzdem gibt es noch viele Distributionen, die 32-Bit weiterhin mit Abbildern unterstützen. Eine Liste im Manjaro-Forum zeigt unter anderem die anhaltende Unterstützung von namhaften Distributionen wie Arch Linux, Knoppix und openSUSE Tumbleweed bis hin zu kleineren Projekten wie MX-Linux und antiX, Bunsenlabs, SparkyLinux, Puppy Linux und Void.

Was denkt ihr? Ist es in Ordnung, Entwicklerzeit lieber in die Unterstützung moderner Hardware zu investieren, anstatt eine Plattform mitzuschleppen, deren Ende sowieso absehbar ist?

Manjaro

Kommentare

23 Antworten zu „Manjaro lässt 32-Bit endgültig fallen“

2020-07-02

Uwe

Nun, die technische Entwicklung bleibt nicht stehen. Also ist dies schon nachvollziehbar, das die Programmierer sich von 32 bit verabschieden. Wer allerdings noch Altgeräte hat, der kann ja auf die vorhandenen Debian-ISOs im Archiv zurückgreifen. Da gibts auch das jeweilige Gesamtpaket auf DVD.

Glücklicherweise!
Man mus nur suchen.

Beispiel: Version 10.4 in 32bit

https://cdimage.debian.org/debian-cd/current/i386/iso-dvd/

Für den Fall, das mir eine alte PC-Kiste unterkommt, habe ich mir vor einiger Zeit schon, auch eine DVD-Kollektion gezogen.

Antworten
2020-07-02

wurzel99

Eins der zentrale Argumente für Linux war die Nachhaltigkeit: Alte Hardware weiter nutzen. Das geht immer mehr den Bach runter.
Für Opensuse kann ich nur noch die neuesten Nvidia-Karten mit den proprietären Treibern nutzen und der Nouvea-Treiber ist und bleibt ziemlich buggy ..
Jetzt gehen noch die 32-bit-Systeme den Bach runter (ich habe dazu mehrere Notebooks).
Die Sammlung an Linux-Alt-Releases hilft nicht denn da gibt es keine Sicherheits- und Programmupdates oder die Exoten-32-bit-Distris sind eben Exoten.

Antworten
1. 2020-07-02
  
  tuxnix
  
  Ich würde antix nicht als Exoten bezeichnen. Es ist bei Distrowatch auf Platz 13, fusst auf Debian und ist mit MX Linux verbaldelt. Ein altes Vaio läuft mit aktueller Software damit wie am ersten Tag. Und ein IBM T43 rollt mit Arch Linux 32 immer noch Top. Ich kann mich da nicht beschweren.
  
  Antworten
2. 2020-07-03
  
  Daniel
  
  Für Opensuse kann ich nur noch die neuesten Nvidia-Karten mit den proprietären Treibern nutzen und der Nouvea-Treiber ist und bleibt ziemlich buggy ..
  
  Das hat weniger mit openSUSE zu tun, als vielmehr das NVIDIA die alter Treiber nicht mehr pflegt und die deshalb mit neuen Kerneln nicht mehr kompiliert werden können.
  Ich hatte das gleiche Problem und bin umgestiegen auf AMD, seitdem ist Ruhe (gerade ein Upgrade von Leap 15.1 mit Kernel 4.12 auf Leap 15.2 mit Kernel 5.3.18 gemacht, funktioniert immer noch).
  
  Antworten
  1. 2020-07-03
    
    wurzel99
    
    damit hast du Recht – die Verantwortung liegt primär bei NVIDIA abes bleibt einfach die Tatsache, dass aus meiner Sicht Linux nicht nachhaltig ist: Ältere Hardware ist relativ rasch für die Mülltonne.
    Der Wechsel zu AMD (den ich auch machen werde) ist in diesem Sinne keine Lösung denn die NIVIDIA-Grakas sind dann eben Schrott – obwohl lauffähig.
    
    Antworten
    1. 2020-07-03
      
      René
      
      Das ist Unsinn die meiste ältere Hardware kann 64Bit gerade die Core 2 Reihe die 2006! auf den Markt kam läuft hervorragend mit Linux man muss nur die richtige Distribution wählen.Das einzige Manko sind die damals verbauten Nvidia Karten aber das Problem gehen die Distributionen teils sehr unterschiedlich an Manjaro bietet zum Beispiel eigene Nvidia Treiberpakete für ihre Kernels an, die auf dem jeweilig letzten Nvidia Treiberpaket für die Karte basieren und auch funktionieren. Habe erst vor kurzen einen Laptop von 2009 mit Nvidia Karte damit bestückt und dank dem Longtime Kernel 5.4 der bis 2025 unterstützt wird ist der Betrieb bis dahin sicher gestellt. Und mal ehrlich die Nutzungszeit der Hardware hat sich schon massiv verlängert niemand wäre zum Beispiel 2009 als Win7 erschien auf die Idee gekommen einen Computer von 1999 damit zu bestücken heute können moderne Betriebssysteme auf deutlich älterer Hardware laufen.
      
      Antworten
      1. 2020-07-04
        
        Anja
        
        Dir ist schon klar das NVIDIA die Unterstützung des „340 Series Legacy Linux Graphics Driver“ im Januar eingestellt hat? G8x, G9x, und GT2xx GPUs werden nicht mehr unterstützt, oder in anderen Worten alle Karten von der GeForce8 bis zur GeForce300. Selbstverständlich kann man den Treiber noch bis 2025 benutzen, ich kann z.B. auch ein Windows 98 oder einen ungewarteten 2.x Linux-Kernel noch bis 2025 benutzen. Die Frage ist, ob das unbedingt sinnvoll ist… 😉
      2. 2020-07-04
        
        René
        
        Dir ist schon klar das der Treiber auf dem Longtime Kernel 5.4 läuft dessen Unterstützung auf 6 Jahre verlängert wurde, also sprich bis Ende 2025 (brauchst bloß mal hier auf der Seite suchen gab es vor kurzen eine News darüber)? Also nix mit ungewarteten Kernel. Habe ich auch im Text eindeutig geschrieben aber lesen und verstehen sind halt zwei Dinge.
      3. 2020-07-05
        
        Anja
        
        Der Kernel ist schon aktuell, aber der Treiber nicht. Und da der (seit Januar 2020 nicht mehr gewartete) Treiber direkt auf den Kernel zugreift, macht der das komplette System inklusive Kernel unsicher. Das der Kernel LTS ist und bis 2025 unterstützt wird ändert daran überhaupt nichts.
        Genau das ist ja der Grund dafür, warum andere Distributionen keine ungewarteten Treiber mit aktuellen Kerneln zusammenbacken. Manjaro ist die Sicherheit des Systems offensichtlich völlig egal. Nun ja, wer damit leben kann… 😉
      4. 2020-07-06
        
        René
        
        Sorry das ist Haarspalterei erstens weil gar nicht klar ist ob der Treiber überhaupt nutzbare Sicherheitslücken enthält. Zweitens kann es auch in gewarteten Treibern sein das entsprechende Lücken nicht entfernt werden solange die nicht öffentlich bekannt gemacht werden und da der Nvidia Treiber rein proprietär ist kann das auch keiner nach prüfen. Drittens ist der Linux Kernel so gebaut das er mit den Fehlern anderer rechnet also sprich die Kernel Entwickler haben die Möglichkeit fehlerhafte Treiber nicht bloß zu blocken sondern gefährliche Code Ausführung durch Treiber auch zu unterbinden.
      5. 2020-07-06
        
        Anja
        
        „Sorry das ist Haarspalterei erstens weil gar nicht klar ist ob der Treiber überhaupt nutzbare Sicherheitslücken enthält“
        
        Also im Juni hatten wir z.B. folgende Sicherheitsprobleme:
        CVE-2020-5962 CVE-2020-5963 CVE-2020-5964, CVE-2020-5965, CVE-2020-5966, CVE-2020-5967, CVE-2020-5968, CVE-2020-5969, CVE-2020-5970, CVE-2020-5971, CVE-2020-5972, CVE-2020-5973
        CVE-2020-11896, CVE-2020-11897, CVE-2020-11898, CVE-2020-11899, CVE-2020-11900, CVE-2020-11901, CVE-2020-11902, CVE-2020-11903, CVE-2020-11904, CVE-2020-11905, CVE-2020-11906, CVE-2020-11907, CVE-2020-11908, CVE-2020-11909, CVE-2020-11910, CVE-2020-11911, CVE-2020-11912, CVE-2020-11913, CVE-2020-11914
        Quelle: NVIDIA Product Security- SECURITY BULLETINS
        Aber Du wirst mir jetzt bestimmt erzählen, dass dies bei 340.x und Manjaro gaaaaanz anders ist, richtig? 😉
        
        Zweitens kann es auch in gewarteten Treibern sein das entsprechende Lücken nicht entfernt werden solange die nicht öffentlich bekannt gemacht werden und da der Nvidia Treiber rein proprietär ist kann das auch keiner nach prüfen.
        
        Ist so wie bei MS-Windows, nicht? Da werden die Lücken auch nicht öffentlich bekannt gemacht (Code ist rein proprietär) und da gibt und gab es bekanntlich auch überhaupt keine, niemals, nie Sicherheitsprobleme. 😀
        
        „Drittens ist der Linux Kernel so gebaut das er mit den Fehlern anderer rechnet also sprich die Kernel Entwickler haben die Möglichkeit fehlerhafte Treiber nicht bloß zu blocken sondern gefährliche Code Ausführung durch Treiber auch zu unterbinden.“
        
        Da habe ich noch nie etwas von gehört, dass der Kernel tolerant auf fehlerhafte Kernelmodule oder binäre Treiber sein soll. Da hätte ich gerne eine Quellenangabe.
      6. 2020-07-07
        
        Nick
        
        Ich schätze mal worauf er hinaus will, ist der neue „fail safely“ Ansatz hinsichtlich der Linux Entwicklung. Somit wird grundlegend der Standpunkt vertreten, dass es immer Fehler und Sicherheitslücken geben kann, und durch eine Kombination von immer mehr Sicherheitsmechanismen weitgehend versucht wird, eintretende Probleme auf sichere Weise abzuhandeln. Es wird also unterbunden das ein Problem in unkontrollierter Weise ausartet. Hierbei hat es in den letzten Jahren große Fortschritte gegeben, gerade im Rahmen des KSPP, um insbesondere typischen 0-Days entgegenzuwirken. Nur aufgrund der Komplexität von Sicherheitslücken die sich statischen Analysen entziehen, bleibt das auch weiterhin ein aktiver Arbeitsbereich. Mit Linux 5.8 hält wieder eine Erweiterung dessen Einzug, in Form des KCSAN um zuverlässiger als je zuvor Race-Conditions und ähnlich gelagerte Probleme im Linux-Kernel zu finden.
      7. 2020-07-07
        
        René
        
        Schön das du die ganzen Lücken auflistest blöd nur das es so gut wie alles Windows Lücken sind, für Linux also nicht relevant. Und die 2 Linux Lücken sind beide nur über lokalen Zugriff möglich und wahrscheinlich benötigt der Angreifer dazu auch Root Rechte. Da mit Root sowieso so gut wie alles möglich ist, wird sich niemand die Mühe machen die zu nutzen. Und da du es noch schwarz auf weiß haben willst https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project hier das was Nick schon geschrieben hat.
      8. 2020-07-07
        
        Anja
        
        Schön das du die ganzen Lücken auflistest blöd nur das es so gut wie alles Windows Lücken sind, für Linux also nicht relevant.
        
        Da 340.x wie schon gesagt nicht mehr gewartet wird, war die Liste nur ein Beispiel dafür, wieviele Bugs in vier Monaten in einem gewarteten Treiber gefunden werden. Um es noch einmal deutlich zu erwähnen: Die Bugs in den nicht mehr gewarteten NVIDIA-Treibern werden nicht mehr gefunden, da niemand mehr nach ihnen sucht. 😉
        
        Und da du es noch schwarz auf weiß haben willst
        
        Danke, scheint ein sehr interessantes Projekt zu sein. Leider ist das Projekt noch ziemlich neu und laut dem Hauptentwickler, Kees (“Case”) Cook von Google, noch weit davon entfernt alle Bereiche abzudecken (deshalb ist z.B. Grsecurity immer noch im Geschäft). Also ist z.Z. das Sicherheits-Problem mit den nicht gewarteten NVIDIA Treibern immer noch aktuell, in ein paar Jahren könnte es dann (vielleicht) funktionieren. 😉
      9. 2020-07-08
        
        René
        
        Was du bei deiner These aber vergisst ist das die älteren Treiber wesentlich weniger Code enthalten und dadurch die Wahrscheinlichkeit auf Fehler kleiner ist. Nur ein kleines Beispiel der 340x Linux Treiber ist 66Mb groß der 440x Treiber ist mit 140Mb mehr als doppelt so groß, was aber auch heißt das die älteren Treiber nicht unbedingt für die Fehler der neueren Treiber anfällig sind, weil schlichtweg der anfällige Code nicht enthalten ist. Letztendlich ist es auch egal man muss das nehmen was da ist und geht und gängige Geräte weg zu schmeißen nur weil der Treiber eventuell Sicherheitslücken enthalten könnte ist ziemlich bescheuert. Alternativ kann man ja noch den Nouveau Treiber nehmen. Nur leider sind die so schlecht das man da eher das Risiko mit den ungewarteten Treiber eingeht.
3. 2020-07-03
  
  ymlak
  
  definiere „alte“ hardware. wie lange gibts jetzt schon 64BIT? 15 jahre? 20? und selbst mit denen kann man heute wirklich nicht mehr anständig arbeiten
  irgendwann ist dann auch mal genug.
  
  Antworten
  1. 2020-07-03
    
    wurzel99
    
    eine typische Linux-diskussion..leider ..
    ich habe mehrere 32-Bit-notebooks laufen, die ihren Anforderungen hervorragend gewachsen sind. Ich kann keine moderne, verbreitete Distri darauf mehr installieren weil mit 32bit einfach Schluss ist.
    
    Linux ist das Problem. Ich mache niemandem und keinem distri-Verantwortliche einen Vorwurf. Es ist einfach Tatsache.
    
    Und:
    Wie kommst du dazu, beurteilen zu wollen und zu können womit ‚man‘ noch anständig arbeiten kann und will.
    
    Antworten
    1. 2020-07-06
      
      ymlak
      
      welche anforderungen sind das? erzählt doch einfach was du so tolles mit deinen 32 bit notbooks so anstellst
      
      sollte es in den letzten jahren nicht genug weckrufe gegeben haben, dass 32bit ausstirbt?
      also es ist wirklich nicht so, als hätte man das nicht kommen gesehen
      
      Antworten
  2. 2020-07-05
    
    Anja
    
    Für den Desktop gibt es 64Bit CPUs seit ungefähr 2002/2003 (ich habe jetzt nicht nachgeschaut). Intel hat aber noch 32Bit CPUs für Mobilanwendungen bis ungefähr 2013 verkauft (Intel Atom z600). Und da die dann noch einige Zeit bei den Computerherstellern und -händlern auf Lager gelegen haben, rate ich jetzt mal das der letzte „neue“ x86 32Bit so um 2015/2016 verkauft wurde. Ist also nicht sooo lange her.
    
    Antworten
    1. 2020-07-05
      
      Florian
      
      Da Notebooks mit diesen CPUs eher nicht benutzt werden um Distributionen zu bauen, ist genau dies das Problem. Server und Workstations sind schon lange 64Bit und die letzten, jetzt rund 18 Jahre alten 32Bit Server und Workstations sterben gerade aus… 😉
      
      Antworten
    2. 2020-07-06
      
      ymlak
      
      hätten sich die leute, die das gekauft haben auch denken können, dass darauf bald nichts mehr läuft
      genauso wie bald alle apple spiele nicht mehr auf apple laufen, wenn die auf ARM umstellen. also jeder, der sich einen ARM apple holt muss damit rechnen, dass seine komplette steam bibliothek nutzlos ist
      
      Antworten
2020-07-02

tuxnix

Ich denke mal, dass Manjaro auch nicht so im Fokus ist für Leute die noch 32 bit Hardware nutzen. Manjaro erleichtert die Installation von Arch Linux, konfiguriert die wichtigsten Desktop Oberflächen vor und entwickelt hilfreiche Tools.
Das ist für Neueinsteiger sehr hilfreich, aber die alten Hasen mit der alten Hardware dürften hier ohnehin eher zu Arch Linux 32 tendieren. Insofern ist dieser Schritt eher undramatisch. Mit etwas Geschick dürfte sogar der Umstieg ohne Neuinstallation gelingen, wenn man zusätzlich die Manjaro spezifischen Anteile deinstalliert.
Auf der anderen Seite hat Manjaro auf der aarch64 Architektur kräftig zugelegt. Hier bringen sie oft auch wichtige Patches in den kernel ein.
Wandel muss sein. Schade wäre es, wenn die Unterstützung für i686 ganz verschwinden würde. Aber es ist wohl auch besser wenn sich die verbliebenen Maintainer in wenigen Distributionen sammeln als wenn wie bei Manjaro geschehen nur noch ein einzelner alles allein stemmen muss.

Antworten
1. 2020-07-06
  
  Anja
  
  „Aber es ist wohl auch besser wenn sich die verbliebenen Maintainer in wenigen Distributionen sammeln als wenn wie bei Manjaro geschehen nur noch ein einzelner alles allein stemmen muss.“
  
  Das machen die ja nicht aus Bosheit oder weil sie keine Lust mehr haben. Wie weiter oben von Florian schon geschrieben wurde: Denen stirbt langsam die Hardware weg um eine Distri zu bauen.
  
  Antworten