Im (ausführlicheren) Artikel der c't zum neuen Kernel habe ich einen interessanten Hinweis gefunden:
Der Meltdown-Schutz für 32-bit-Kernel wird wohl noch einige Zeit auf sich warten lassen.
Ich war bisher bei 32bit-Linuxen verblieben, weil meine Kisten max. 4GB RAM haben und ich gelegentlich einige 32bit-Windows-Programme unter Linux ausführen möchte. Da hat es sich eigentlich nicht gelohnt, auf 64bit umzusteigen - ich habe aber inzwischen notgedrungen wegen MeltDown umgestellt.
Der c't-Artikel erwähnt jedoch, dass man durchaus einen 64bit-Kernel in einem reinen 32bit-System verwenden kann. Im Detail mag es Probleme geben, zumindest auf den ersten Blick läuft aber alles (Slackware 14.2 - unter Distributionen, deren Paketmanager eine Abhängigkeitsprüfung durchführen, wird man basteln müssen, um ihnen einen 64bit-Kernel unterzuschieben).
Dass man ein 32bit-Subsystem unter einem 64bit-System installieren kann, um z.B. 32bit-Windows-Programme unter einem 32bit-Wine auszuführen , ist ja bekannt und trivial. Mir jedenfalls war jedoch nicht bekannt, dass ein 64-bit-Kernel ein reines 32bit-System starten kann.
64-bit-Kernel oder kernelnahe Software lassen sich selbstverständlich nicht auf dem System kompilieren, und ich bin gespannt, an welchen Stellen es noch krachen wird.
Von Verfluchtnochmal am Di, 3. April 2018 um 03:31 #
Dem Kernel ist das doch naturgemäß völlig wurscht weil er ganz oben in der Nahrungskette läuft und alles andere auf ihm aufsetzt
Ich frage mich nur was all das Geschiss soll
x86_64 hat einen Haufen andere Vorteile wie zB dass SSE mandatory ist und damit viele Software schneller läuft während ix86 bei so gut wie allen Distributionen immer noch von Hardware aus dem letzten Jahrtausend ausgeht
Sorry, aber noch nichtmal auf einer VM mit unter 1 GB RAM kommt mir seit mehr als 10 Jahren auch nur das kleinste 32bit Binary drauf
Unter Slackware ist es vergleichsweise umständlich, auf einem 64bit-System ein 32bit-Subsystem einzurichten und aktuell zu halten, darum habe ich es möglichst lange rausgezögert.
Nich jeder braucht möglichst viel Geschwindigkeit und RAM. Warum soll man mit dem SUV Brötchen holen, wenn es auch ein Fahrrad tut?
Von Verfluchtnochmal am Di, 3. April 2018 um 11:47 #
Ähm hat Slackware keine Paketverwaltung? "yum install wine.i686" auf einem Redhat zieht dir alles was gebraucht wird und fertig
Der SUV/Fahrradvergleich ist selten dämlich, es gibt keinen rationalen Grund nach 2007 noch ein 32bit System aufzusetzen und egal ist es nur wenn man alle paar Jahre neu installiert - Bei mir haben alle Systeme Redundanz und sterben nicht weg, ergo ist umsiedeln auf neue Hardware eine non-hostonly initrd zu bauen, runter fahren, Platten raus und in den neuen Rechner, einschalten, MAC-Adresse der internen NIC anpassen, durchstarten und fertig ist der Lack
Du bist ja auch Füchschen Oberschlau, hat die Weißheit mit Löffeln gefressen! Nur - als die zwischenmenschlichen Beziehungen verteilt wurden hast Du offensichtlich geschwänzt.
Von Verfluchtnochmal am Mi, 4. April 2018 um 12:46 #
Ein Paketmanager ohne Abhängigkeiten? Was für ein Dreck!
RHEL hat WINE, das EPEL-Repo ist Teil des Fedora-Projekts und damit extrem nahe zu Redhat https://koji.fedoraproject.org/koji/buildinfo?buildID=1053044
"Michael Cronenworth redhat" in eine Suchmaschine eintippen - Oh, das ist sogar der Bugtracker von redhat.com
64-Bit Systeme haben doch schon immer Unterstützung für 32-Bit Anwendungen. Wenn du ab und an mal eine 32-Bit Anwendung brauchst, muss doch nicht das ganze System 32-Bit sein.
Auch wenn man 4GB RAM hat, haben 64-Bit Systeme deutliche Vorteile. Das wurde doch schon so oft erwähnt, als die entsprechenden CPUs rauskamen. Von deinen 4GB kannst du unter 32-Bit z.B. nur etwas mehr als 3GB nutzen.
IMO liegt das Problem etwas verzwickter und ändert im Grunde an der 32bit-Patchproblemstellung für Meltdown und Spectre nichts. Wenn man 32bit-Anwendungen unter 64bit benutzt, kann sich hier auch das 32bit-Meltdown- und Spectre-Problem auswirken, z.B. wenn man eben 32bit-Windows- oder 32bit-Linux-Software unter einem 64bit-Linux ausführt.
Ich betreibe z.B. unter Debian Wheezy 32bit einen 64bit-Kernel, Probleme habe ich bis dato noch nicht festgestellt (Wheezy ist zum Glück multiarch-fähig). Diese 32bit-Installation stammt aus einer Zeit (so um die Squeeze-Veröffentlichung), in der die meisten Distros noch standardmäßig 32bit-Images zur Installation anboten.
Im Prinzip müsste ich "nur" das 32bit-Userland auf 64bit upgraden können.
Es ist IMO symptomatisch, dass das Gros der Arbeit am Meltdownschutz für 32bit von einem Mitarbeiter von Opensuse-/Suse stammt, obgleich Opensuse 32bit im Prinzip "aussortiert" hat (außer in Tumbleweed). Hätte Torvalds nicht jüngst gesagt, dass die 32bit-Unterstützung noch 5 bis 10 Jahre beibehalten werden muss, wäre die 32bit-Architektur mit Meltdown/Spectre vielleicht schon aufgegeben worden.
Zudem ist das Ausmaß der Ausnutzung von Meltdown unter 32bit nachwievor vollkommen unklar. U.U. schützt der übliche 1/3GB-Split zwischen Kernel und Userland schon ausreichend gegen Meltdown? Die noch nicht vollständigen Spectre-Schutzmaßnahmen für 64bit funktionieren hingegen auch bereits jetzt unter 32bit.
Im (ausführlicheren) Artikel der c't zum neuen Kernel habe ich einen interessanten Hinweis gefunden:
Der Meltdown-Schutz für 32-bit-Kernel wird wohl noch einige Zeit auf sich warten lassen.
Ich war bisher bei 32bit-Linuxen verblieben, weil meine Kisten max. 4GB RAM haben und ich gelegentlich einige 32bit-Windows-Programme unter Linux ausführen möchte. Da hat es sich eigentlich nicht gelohnt, auf 64bit umzusteigen - ich habe aber inzwischen notgedrungen wegen MeltDown umgestellt.
Der c't-Artikel erwähnt jedoch, dass man durchaus einen 64bit-Kernel in einem reinen 32bit-System verwenden kann. Im Detail mag es Probleme geben, zumindest auf den ersten Blick läuft aber alles (Slackware 14.2 - unter Distributionen, deren Paketmanager eine Abhängigkeitsprüfung durchführen, wird man basteln müssen, um ihnen einen 64bit-Kernel unterzuschieben).
Dass man ein 32bit-Subsystem unter einem 64bit-System installieren kann, um z.B. 32bit-Windows-Programme unter einem 32bit-Wine auszuführen , ist ja bekannt und trivial. Mir jedenfalls war jedoch nicht bekannt, dass ein 64-bit-Kernel ein reines 32bit-System starten kann.
64-bit-Kernel oder kernelnahe Software lassen sich selbstverständlich nicht auf dem System kompilieren, und ich bin gespannt, an welchen Stellen es noch krachen wird.
Wird nicht krachen. Das funktionierte schon immer.
Hatte früher ne Zeit lang Lolbuntu 6.06 genau so laufen.
Dem Kernel ist das doch naturgemäß völlig wurscht weil er ganz oben in der Nahrungskette läuft und alles andere auf ihm aufsetzt
Ich frage mich nur was all das Geschiss soll
x86_64 hat einen Haufen andere Vorteile wie zB dass SSE mandatory ist und damit viele Software schneller läuft während ix86 bei so gut wie allen Distributionen immer noch von Hardware aus dem letzten Jahrtausend ausgeht
Sorry, aber noch nichtmal auf einer VM mit unter 1 GB RAM kommt mir seit mehr als 10 Jahren auch nur das kleinste 32bit Binary drauf
ix86 ist tot und weiss es nur noch nicht
Unter Slackware ist es vergleichsweise umständlich, auf einem 64bit-System ein 32bit-Subsystem einzurichten und aktuell zu halten, darum habe ich es möglichst lange rausgezögert.
Nich jeder braucht möglichst viel Geschwindigkeit und RAM. Warum soll man mit dem SUV Brötchen holen, wenn es auch ein Fahrrad tut?
Ähm hat Slackware keine Paketverwaltung? "yum install wine.i686" auf einem Redhat zieht dir alles was gebraucht wird und fertig
Der SUV/Fahrradvergleich ist selten dämlich, es gibt keinen rationalen Grund nach 2007 noch ein 32bit System aufzusetzen und egal ist es nur wenn man alle paar Jahre neu installiert - Bei mir haben alle Systeme Redundanz und sterben nicht weg, ergo ist umsiedeln auf neue Hardware eine non-hostonly initrd zu bauen, runter fahren, Platten raus und in den neuen Rechner, einschalten, MAC-Adresse der internen NIC anpassen, durchstarten und fertig ist der Lack
Ach, behalt' einfach deine Meinung und ich behalt' meine.
Du bist ja auch Füchschen Oberschlau, hat die Weißheit mit Löffeln gefressen!
Nur - als die zwischenmenschlichen Beziehungen verteilt wurden hast Du offensichtlich geschwänzt.
Ich suche auf einer Technikseite auch keinen Lebenspartner, ich wundere mich lediglich wie rückständig bis hilflos die meisten User agieren
Slackware hat offiziell kein Wine, genausowenig wie RHEL.
Und Slackware zieht Dir mit den pkgtools keinerlei Abhängigkeiten automatisch nach. Keine einzige, gar nichts.
Dein wahrscheinliches Gefluche in Foren angesichts dieser Tatsache möchte ich mir gar nicht ausmalen.
Ein Paketmanager ohne Abhängigkeiten? Was für ein Dreck!
RHEL hat WINE, das EPEL-Repo ist Teil des Fedora-Projekts und damit extrem nahe zu Redhat
https://koji.fedoraproject.org/koji/buildinfo?buildID=1053044
"Michael Cronenworth redhat" in eine Suchmaschine eintippen - Oh, das ist sogar der Bugtracker von redhat.com
64-Bit Systeme haben doch schon immer Unterstützung für 32-Bit Anwendungen. Wenn du ab und an mal eine 32-Bit Anwendung brauchst, muss doch nicht das ganze System 32-Bit sein.
Auch wenn man 4GB RAM hat, haben 64-Bit Systeme deutliche Vorteile. Das wurde doch schon so oft erwähnt, als die entsprechenden CPUs rauskamen. Von deinen 4GB kannst du unter 32-Bit z.B. nur etwas mehr als 3GB nutzen.
IMO liegt das Problem etwas verzwickter und ändert im Grunde an der 32bit-Patchproblemstellung für Meltdown und Spectre nichts. Wenn man 32bit-Anwendungen unter 64bit benutzt, kann sich hier auch das 32bit-Meltdown- und Spectre-Problem auswirken, z.B. wenn man eben 32bit-Windows- oder 32bit-Linux-Software unter einem 64bit-Linux ausführt.
Ich betreibe z.B. unter Debian Wheezy 32bit einen 64bit-Kernel, Probleme habe ich bis dato noch nicht festgestellt (Wheezy ist zum Glück multiarch-fähig). Diese 32bit-Installation stammt aus einer Zeit (so um die Squeeze-Veröffentlichung), in der die meisten Distros noch standardmäßig 32bit-Images zur Installation anboten.
Im Prinzip müsste ich "nur" das 32bit-Userland auf 64bit upgraden können.
Es ist IMO symptomatisch, dass das Gros der Arbeit am Meltdownschutz für 32bit von einem Mitarbeiter von Opensuse-/Suse stammt, obgleich Opensuse 32bit im Prinzip "aussortiert" hat (außer in Tumbleweed). Hätte Torvalds nicht jüngst gesagt, dass die 32bit-Unterstützung noch 5 bis 10 Jahre beibehalten werden muss, wäre die 32bit-Architektur mit Meltdown/Spectre vielleicht schon aufgegeben worden.
Zudem ist das Ausmaß der Ausnutzung von Meltdown unter 32bit nachwievor vollkommen unklar. U.U. schützt der übliche 1/3GB-Split zwischen Kernel und Userland schon ausreichend gegen Meltdown? Die noch nicht vollständigen Spectre-Schutzmaßnahmen für 64bit funktionieren hingegen auch bereits jetzt unter 32bit.