Wofür braucht man denn ein extra 64bit Rettungssystem? Das macht meiner Meinung nach wirklich keinen Sinn, besonders wenn man ja eh schon eine "normale" 32bit Version im Programm hat.
Für Systemrettung macht das meiner Ansicht nach derzeit auch wenig Sinn. Allerdings kann man grml ja auch für andere Zwecke einsetzen, z.B. Benchmarking oder Dienste, die einfach von einem Mehr an Leistung oder Speicher profitieren. Darüber hinaus wird 64-Bit ohnehin früher oder später für jede Distro ein Thema werden. Warum nicht schon jetzt damit anfangen?
Von Gods-Army-Germany am Sa, 19. Mai 2007 um 11:26 #
um seine 64 bit apps zu testen. (chroot) Auch bei einem chroot wird der kernel von der LiveCD benutzt.Ein 32 bit kernel und 64 bit apps machen keinen Sinn.
Nun, ich für meinen Teil hoffe, dass der 32-bit-Modus der 64-bit-CPUs irgendwann mal wegoptimiert wird, weil die Anwendungen portiert sind und es nicht mehr benötigt wird. Insofern ist jede Anstrengung in dieser Richtung am Ende vielleicht Gold wert.
Die letzten 25 Jahre EDV-Geschichte zeigen Dir eigentlich genau das Gegenteil, wenn auch etwas behäbig. 8- oder 16-bit-Anwendungen kann heute kein gängiges System mehr ausführen.
Eine CPU kann sehr wohl mit < 32 Bit Software umgehen. Nur, weil es die meisten Betriebssysteme erschweren, ist der Teil nicht aus den CPUs verschwunden.
Das eine schließt das andere nicht aus. Das man ein kompiliertes Binary ausführen kann, wenn der damals verwendete Befehlssatz noch verfügbar ist, ist aber nur das eine. Identisches Verhalten bei den Datentypbreiten ist aber das andere, das kann man nicht einfach mal so restaurieren.
Das beschreibt es ziehmlich genau. Ein konkretes und vermutlich nicht seltenes Beispiel ist ein ausgesperrtes Gentoo-System. Wenn man beim Herumbasteln irgend ein wichtiges Verzeichnis oder Skript zum Hochfahren gelöscht bzw. beschädigt hat. Ein simples emerge kaputtespaket bereinigt im chroot-modus der livecd das Problem sofort und sauber. Nur lässt sich ein 64bit-emerge halt nicht in einer 32bit-chroot-Umgebung ausführen. und das bezieht sich hier nicht nur auf emerge (=portage tool), sondern sicher auch auf debians apt, SuSE/Redhats/Mandrivas rpm...
weil ein grml2hd (also eine hdinstall) gerade mal 7min dauert und man dann ein fertig configuriertes debian unstable mit grml paketen (aka. grml) auf der platte hat.
wlan geht, x geht, ... das schaffst mit KEINER normalen install cd!
Das macht meiner Meinung nach wirklich keinen Sinn, besonders wenn man ja eh schon eine "normale" 32bit Version im Programm hat.
Darüber hinaus wird 64-Bit ohnehin früher oder später für jede Distro ein Thema werden. Warum nicht schon jetzt damit anfangen?
Auch bei einem chroot wird der kernel von der LiveCD benutzt.Ein 32 bit kernel und 64 bit apps machen keinen Sinn.
lg
Erik
lg
Erik
mfG
lg
Erik
mfg,
-mika-
Ein konkretes und vermutlich nicht seltenes Beispiel ist ein ausgesperrtes Gentoo-System. Wenn man beim Herumbasteln irgend ein wichtiges Verzeichnis oder Skript zum Hochfahren gelöscht bzw. beschädigt hat. Ein simples emerge kaputtespaket bereinigt im chroot-modus der livecd das Problem sofort und sauber. Nur lässt sich ein 64bit-emerge halt nicht in einer 32bit-chroot-Umgebung ausführen. und das bezieht sich hier nicht nur auf emerge (=portage tool), sondern sicher auch auf debians apt, SuSE/Redhats/Mandrivas rpm...
wlan geht, x geht, ...
das schaffst mit KEINER normalen install cd!