amd64 und die Ports

Styx

Universaldilettant
Hallo Leute,
ich bin gerade dabei so nach und nach von i386 auf amd64 umzusteigen, da ich denke, dass das auf lange Sicht notwendig sein wird. Meine Desktop-PC hat jetzt aktuell 2 Gig RAM und evtl. will ich noch ein wenig nachrüsten.

Wie dem auch sei, ich habe gerade ein wenig Zeit mich mal mit den verfügbaren Programmen für amd64 zu beschäftigen. Ich hatte vor hier die Ports aufzulisten, die es derzeit nur für i386 gibt, damit man mal eine Übersicht hat und der Umstieg vielleicht dem einen oder anderen etwas leichter fällt, denn diese Architektur wird in nächster Zeit sicherlich stark an Bedeutung gewinnen.

nVidia
Das schon bekannte Problem: Den nVidia-Treiber in den Ports gibt es nur für i386. Ich habe mal gehört, dass nVidia für Mitte 2008 auch einen für amd64 geplant hat, aber ich weiß nicht mehr, wo ich das her hatte. Für Linux-64bit-Systeme gibt es einen Treiber, hoffentlich passiert da noch was.
Ich selber nenne eine nVidia 7900 GS mein eigen und diese läuft sehr gut mit dem xorg-eigenen Treiber "nv", was mir erstmal reicht. Derzeit werden nur die 8000er-Chips nicht von dem nv unterstützt.

Linux-Browser-Plugins
Früher ein sehr wichtiges Thema, jetzt durch viele Programme überholt. So unterstützt das mplayer-plugin ja so ziemlich alle gängigen Multimediaformate. Die Linux-Emu selber läuft einwandfrei unter amd64, aber der linuxpluginwrapper geht nicht. Dadurch kann man z.B. das Acrobat-Browser-Plugin nicht verwenden, was aber verschmerzbar sein sollte ;)
Flash ist ja selbst unter i386 ein Problem. Gnash und swfdec sind aber auch unter amd64 verfügbar. Leider in ähnlicher Qualität wie unter i386, kurz gesagt: es stürzt gerne ab.

Windows-Emulation
Wine läuft nicht und das mir bis vor kurzem vollkommen unbekannte win4bsd gibts auch nur für i386. Das dritte Emu-Tool für Win-Applikationen in den Ports heißt wine-doors und scheint auch für amd64 verfügbar zu sein. Ich werde das nachher mal testen und dann meine Erfahrungen hier posten.

Womit ich mich noch gar nicht beschäftigt habe ist die 32bit-Emulation, die amd64 mitgeliefert hat. Es gibt wohl zwei Möglichkeiten 32bit-Programme unter amd64 laufen zu lassen:

1. Ein chroot-System zu erstellen und dort einen i386er-Kernel laufen zu lassen.
2. Die Datei /usr/lib32 verwenden.

Mit beiden Varianten habe ich mich noch nicht näher beschäftigt. Ich werde mal schauen, ob es da irgendwo was im Internet zu gibt und werde entsprechend berichten.

Wer ebenfalls bereits Erfahrungen mit amd64 gemacht hat, ist herzlich eingeladen diese hier kund zu tun :)
 
nVidia
Das schon bekannte Problem: Den nVidia-Treiber in den Ports gibt es nur für i386. Ich habe mal gehört, dass nVidia für Mitte 2008 auch einen für amd64 geplant hat,
Ich habe mal gehört, dass es Anfang 2006 soweit sein soll. Meine Anfrage im nvforum ist von 11/2005. Ich habe da keine Hoffnung mehr.
Flash ist ja selbst unter i386 ein Problem. Gnash und swfdec sind aber auch unter amd64 verfügbar. Leider in ähnlicher Qualität wie unter i386, kurz gesagt: es stürzt gerne ab.
Auch da ist wenig Abhilfe in Sicht. Der dazugehörige PR ist leider seit knapp einem Jahr tot. Liefe es dann auf i386, könnte man anfangen zu überlegen, wie man es für amd64 realisiert.

Ansonsten habe ich mit FreeBSD/amd64 wenig Vergnügen gehabt. Nicht nur, dass der proprietäre Krams fehlt, meine Kompilate warfen hier auch über alle maßen viele Coredumps.
 
Das mit nVidia wird nix mehr. Letzten wurde auf current@ dazu der Verdacht geäußert, dass nVidia eine Reihe mehr oder weniger sinnbefreiter Features im Kernel haben will - die sie im übrigen unter i386 nicht gebraucht haben - um nicht klar in der Öffentlichkeit sagen zu müssen "Hey, FreeBSD hat für uns keinen relevanten Marktanteil und geht uns daher so ziemlich am Hinterteil vorbei". Meine persönliche Befürchtung ist, dass es nur eine Frage der Zeit sein dürfte, bis Linux/i386 und FreeBSD/i386 zuweit auseinanderlaufen und nVidia FreeBSD endgültig fallen lässt. Meine Hoffnungen gehen im Bereich 3D inzwischen eher in Richtung ATI/AMD (radeonhd) und Intel (Larabee).

Ansonsten bin ich im Sommer vollständig und endgültig auf FreeBSD/amd64 umgestiegen, schlicht aus der Notlage heraus, dass ich für i386 zu viel RAM habe. Bisher habe ich es nicht bereut und kann keine Probleme feststellen. Ich muss zugeben, dass seit meinen ersten amd64 Gehversuchen zu Zeiten von 6.0 sich einiges zum Guten verbessert hat. Mit nv(4x) kann ich beide Monitore ansprechen, Xinerama läuft auch (siehe Wiki). Softwareseitig ist alles für mich relevante vorhanden, als Browser nutze ich Linux-Opera, in dem funktioniert das doofe Flashplugin auch mehr oder weniger problemlos. So problemlos wie ein Flash halt geht. ;)
Inzwischen ist Mplayer auch in der Lage fehlerfrei H.264 Videos abzuspielen, bis zur letzten Version hatte die libav da noch einige Probleme unter amd64. Dank Diablo-JDK (das JDK16 habe ich noch nicht probiert), laufen auch Freemind, Eclipse und co einwandfrei. Alles in allem nichts zu nörgeln.
Was Probleme machte, war einmal die SB Audigy. Aber das Problem dürfte eher bei der Hardware zu suchen sein, denn auch unter Linux und Windows x64 knackte sie nur blöd. Spiele gehen auch, sowohl Doom3 als auch Quake3 starten. Mangels 3D-Beschleunigung sind sie aber unspielbar, hier wird man wohl auf radeonhd warten müssen. Den meisten propitären Kram habe ich ohne viel Gefrickel entweder im Linuxulator zum Laufen bekommen (was gibt's da schon nativ für FreeBSD?), Softmaker und Quake3 (ja, man kann da auch ein nativ kompiliertes ioq3 nutzen) mit den lib32. Ein i386-Chroot habe ich aktuell nicht, da ich einfach keinen Bedarf habe. Die Einrichtung ist aber trivialst, nur X11 brauch ein wenig Fingerspitzengefühl (sofern man den unter amd64 auf dem Host laufenden X-Server verwenden möchte).

Alles in allem nichts zu nörgeln und nach und nach werden die i386-Systeme hier wohl verschwinden. Auch wenn es durch den Lebeszyklus der alten Hardware teils wohl noch Jahre dauern wird.
 
@styx
Dem ein oder anderen ist es gelungen in einer 32-Bit Jail Wine-Programme laufen zu lassen.
 
[...] Wie dem auch sei, ich habe gerade ein wenig Zeit mich mal mit den verfügbaren Programmen für amd64 zu beschäftigen. Ich hatte vor hier die Ports aufzulisten, die es derzeit nur für i386 gibt, damit man mal eine Übersicht hat und der Umstieg vielleicht dem einen oder anderen etwas leichter fällt, denn diese Architektur wird in nächster Zeit sicherlich stark an Bedeutung gewinnen. [...]
In dem Zusammenhang übrigens interessant: http://bsdstats.org/releases.php

Wie man sieht, sind ca. 95% der BSD-Installationen (mit bsdstat) i386 und derzeit nur ca. 5% amd64.

Ich hatte, bevor ich diese Statistik gesehen hatte auch angenommen, dass amd64 schon einiges an Bedeutung haben müsste. Scheinbar ist es aber nur jedes zwanzigste System und der Umstieg geht auch sehr langsam, die Zahl ändert sich jedenfalls über die letzten Monate kaum. ;)

Dennoch gut, dass es den Thread gibt. Schon allein wegen des Speicherhungers von ZFS wird amd64 langsam richtig interessant. Und jeder, der mehr als 2 GB RAM hat, profitiert ja ebenso von amd64 (Aufteilung i386 Adressraum auf 2 GB Kernel-Space und 2 GB User-Space).
 
Zu Wine auf amd64 gab es letztens einen Thread auf de-bsd-questions. Leider sind durch den Ausfall des Servers einige Mails nicht im Archiv gelandet, daher zitiere ich hier den entscheidenden Teil:
Oliver Fromme schrieb:
Da hast Du ausgerechnet eines der wenigen Packages er-
wischt, die unter amd64 nicht laufen. Wine versucht,
auf relativ niedriger Ebene auf Prozessor-Features
Einfluss zu nehmen, die unter amd64 einfach nicht in
dieser Form existieren. Die Details haben ja schon
andere sehr gut erläutert.

Falls Du zwingend bestimmte Windows-Programme unter
FreeBSD/amd64 benutzen musst, solltest Du evtl. mal
qemu versuchen. Das ist im Gegensatz zu Wine zwar
keine ABI-Emulation, sondern emuliert die Hardware
(mit entsprechenden Vor- und Nachteilen), aber grund-
sätzlich sollte es funktionieren.

Was die Statistik angeht: Angeblich sind fast die Hälfte der Systeme noch 1.x. Anscheinend mischen die aber sämtliche BSD-Derivate ohne weitere Unterscheidung zusammen. Es könnte sich also z.B. um DragonFlyBSD 1.x handeln. Aber selbst dann halte ich die Zahlen dort nicht für realistisch.
 
Was die Statistik angeht: Angeblich sind fast die Hälfte der Systeme noch 1.x. Anscheinend mischen die aber sämtliche BSD-Derivate ohne weitere Unterscheidung zusammen. Es könnte sich also z.B. um DragonFlyBSD 1.x handeln. Aber selbst dann halte ich die Zahlen dort nicht für realistisch.
Ich denke eher, dass die 1.x-User einfach PC-BSDler sind. Die haben bsdstats ja afaik standardmäßig installiert, deshalb ist deren Anteil auch so hoch. Alle anderen müssen bsdstats explizit installieren, daher passt die Statistik dann doch wieder meiner Meinung nach.
 
Nein, es paßt eben nicht. (Ich verstehe auch nicht, wie du bei deiner Argumentationskette zu dieser Schlußfolgerung kommst, aber egal.) Die Statistik läßt vermuten, daß ein sehr großer Anteil an den Daten von PC-BSD- und/oder DragonFly-Benutzern (oder von wem auch immer, keine Ahnung, steht ja nicht dabei!) stammen könnte. Du willst jetzt daraus aber die Verbreitung von amd64 ablesen. Dafür sind PC-BSD und DragonFly nun wirklich ganz schlechte Indikatoren...

Die Statistik ist aufgrund der mangelhaften Datenerfassung ohnehin völlig sinnfrei. Was sind das zum Beispiel für 4.x-Systeme? Uralte FreeBSD-Gurken oder aktuelle NetBSD- oder OpenBSD-Büchsen? Keine Ahnung, steht dort nicht. Das sind ganz grundlegende, handwerkliche Fehler.
 
Naja, es ist nicht ganz ohne Grund, dass bsdstats.org mehrfach scharf in die Kritik geraten ist. Um eine repräsentative Statistik zu erstellen braucht es halt ein gutes Grundkonzept und auch einen Weg, um Verfälschungen zumindestens mittelstark auszuschließen.
 
Also wenn ich das richtig gesehen habe, ermittelt das Skript die Version mittels $(uname -r). Das sollte doch auch auf einem PC-BSD den Wert "6.2" oder "6-STABLE" oder so etwas in der Richtung liefern. Die werden ja wohl nicht uname(1) so umgebogen haben, daß es hinterher "PC-BSD 1.6" o.ä. liefert. Also ich verstehe die Statistik wirklich nicht. Sind diese knapp 50% doch alles DragonFlyBSDs?

Ich habe aber das Gefühl, daß wir "langsam" OT werden. :rolleyes: Daher zurück zum Thema...

Ich bin ja gespannt, wie das im 3D-Grafikmarkt weitergeht. Bisher konnte man zumindest auf i386 nVidia-Karten kaufen, wenn man ordentliche 3D-Leistung haben wollte. Diese Möglichkeit wird aber wohl in naher Zukunft wegfallen (oder die kümmern sich doch noch um amd64). Mit AMD und ATI habe ich vor langer Zeit schlechte Erfahrungen bei der Qualität gemacht. Intel ist zwar qualitativ gut, baut aber nicht wirklich schnelle GPUs. Tja...

Die Sache mit Wine ist aber IMHO nicht das Problem. Wer amd64 einsetzt, hat ja eine vergleichsweise moderne Kiste und sollte daher mit QEmu eine vernünftige Performance bekommen. Außerdem habe zumindest ich die Erfahrung gemacht, daß QEmu wesentlich einfacher und streßfreier ist als das Gebastel mit Wine.

Zu Flash äußere ich mich an dieser Stelle lieber nicht. ;)

In zwei oder drei Jahren hat sich amd64 sicherlich etabliert und die Kinderkrankheiten sind ausgemerzt.
 
Die Statistik läßt vermuten, daß ein sehr großer Anteil an den Daten von PC-BSD- und/oder DragonFly-Benutzern (oder von wem auch immer, keine Ahnung, steht ja nicht dabei!) stammen könnte.
Die Daten sind auch alle haarklein aufgeschlüsselt. Man darf außer bei den stark verdichteten Daten links auch mal ein wenig in den Details stöbern. :) Warum eigentlich so diese anti-bsdstats Haltung? Ist an dem Projekt irgendwas schlecht? Ich finde es ziemlich interessant.
Du willst jetzt daraus aber die Verbreitung von amd64 ablesen. Dafür sind PC-BSD und DragonFly nun wirklich ganz schlechte Indikatoren...
Nein. Ich habe nur geschrieben, dass dort eben einige Zusammenhänge aufgezeigt werden und dies natürlich nur bei Systemen, die bsdstats installiert haben. Aber auch wenn man PC-BSD rausrechnet und von mir aus nur noch FreeBSD betrachtet, ist die amd64-Zahl eben sehr gering. Und das schreibe ich ohne Wertung oder Ziele. Den Zahlen aber einfach so aus einem Bauchgefühl (?) die Aussagekraft abzusprechen... Nunja, wenn du willst. Ich sage nur, dass das Ergebnis interessant ist.

Die Statistik ist aufgrund der mangelhaften Datenerfassung ohnehin völlig sinnfrei. Was sind das zum Beispiel für 4.x-Systeme? Uralte FreeBSD-Gurken oder aktuelle NetBSD- oder OpenBSD-Büchsen? Keine Ahnung, steht dort nicht. Das sind ganz grundlegende, handwerkliche Fehler.
Wie schon gesagt: schau mal genauer hin. Nicht nur auf die großen Zahlen der Zusammenfassung gucken und die dann als Mist hinstellen, weil man die Verhältnisse nicht mag. :)

DragonFly ist übrigens mit 0,2% erwartungsgemäß kaum vertreten, PC-BSD aber wegen der Standard-bsdstats Ausrüstung übermäßig stark: http://bsdstats.org/
 
Ansonsten habe ich mit FreeBSD/amd64 wenig Vergnügen gehabt. Nicht nur, dass der proprietäre Krams fehlt, meine Kompilate warfen hier auch über alle maßen viele Coredumps.

Also die Programme, die sich kompilieren lassen, laufen problemlos. Allerdings macht OpenOffice bei mir unter amd64 Probleme. Es lässt sich kompilieren, funktioniert aber nicht korrekt.

Kamikaze schrieb:
@styx
Dem ein oder anderen ist es gelungen in einer 32-Bit Jail Wine-Programme laufen zu lassen.

Gibt es dazu irgendwo Anleitungen? Ich habe zwar bisher nur flüchtig gesucht, aber absolut nichts gefunden.

Zu qemu: qemu auf amd64 habe ich bisher nicht getestet, aber auf dem gleichen Rechner unter i386 (AMD64 X2 5000+ 2 GB RAM) kraucht qemu ganz schön langsam vor sich hin, so dass es nicht wirklich eine Alternative darstellt. Man kann ein paar Programme nutzen, aber wirklich Spaß macht es nicht.

Die sonstige Diskussion über den Sinn- und Unsinn der bsdstats ist recht interessant. Dennoch denke ich, dass amd64 i386 als "wichtigste" Architektur irgendwann ablösen wird. Das wird noch ein Weilchen dauern, aber es wird so kommen. Vielleicht sogar früher als wir alle denken.
 
Meine persönliche Befürchtung ist, dass es nur eine Frage der Zeit sein dürfte, bis Linux/i386 und FreeBSD/i386 zuweit auseinanderlaufen und nVidia FreeBSD endgültig fallen lässt.
Du könntest recht haben, erste Anzeichen gibt es bereits: http://www.pro-linux.de/news/2008/12237.html

Neue Treiber für Linux und Solaris, FreeBSD fehlt noch. Sonst sind die in den letzten Releases AFAIR immer zeitgleich ausgeliefert worden.
 
Du könntest recht haben, erste Anzeichen gibt es bereits: http://www.pro-linux.de/news/2008/12237.html

Neue Treiber für Linux und Solaris, FreeBSD fehlt noch. Sonst sind die in den letzten Releases AFAIR immer zeitgleich ausgeliefert worden.
Außerdem braucht der Treiber immernoch COMPAT5x . FreeBSD hat halt in den letzten Jahren ein paar mal gleich die ABI (oder war es API?) gebrochen...
wenn Linux das auch machen würde, würden sie vielleicht die Entwicklung der Community überlassen, weil es für sie zu anstrengend wird ;) und die Quellen rausrücken!
 
im gegensatz zu freebsd scheints für linux auch ne x86_64 version zu geben. schon traurig, dass sie das so stiefmütterlich behandeln. naja, hoffentlich wird der radeonhd-treiber bald volle unterstützung der ati-karten mit sich bringen; dann ist die krux mit den ati-eigenen treibern auch endlich vorbei (ob der dann auch auf win portiert wird, oder müssen die dann immer noch die ati-treiber nehmen)
 
Mal zur Kenntnisnahme:
zander (NVIDIA Corporation) schrieb:
There's been no back and forth that I'm aware of and to the best of my knowledge, the need for the features requested in an email to freebsd-hackers has been neither disputed nor has a lack of details been brought to my attention. As far as I know, the work required is understood by at least some FreeBSD developers (e.g. John Baldwin) and is blocked on either lack of time/resources or other kernel development work.

NVIDIA has expressed interest in working with FreeBSD developers to help make it possible to provide NVIDIA graphics drivers for FreeBSD/amd64, as well as to achieve feature parity with the Linux/Solaris graphics drivers on FreeBSD/i386, but any such support continues to be gated by the features in question.
Quelle:
http://www.nvnews.net/vbulletin/showpost.php?p=1520840&postcount=252

Der 169.07 nvidia-driver ist ja auch nachgekommen,
auch wenn der nvidia-driver 169.07 für Linux und Solaris früher verfügbar war,
haben ihn die Nvidia Entwickler auch für FreeBSD i368 angepasst.
Ein inoffizieller Bastelport für den 169.07 nvidia-driver für i386 exisitiert:
https://forum.bsdgroup.de/showthread.php?t=1552
Ob der auch für andere FreeBSD i386 Nutzer funktioniert,
kann ich leider nicht sagen, für mich tut er es.

Im NV News Forum gibt es auch noch einen Thread
bezüglich Linuxator und Hardwarbeschleunigung durch nvidia-driver
und Auswirkungen verschiedener sysctl compat.linux.osrelease:
http://www.nvnews.net/vbulletin/showthread.php?t=105545


Gruß, Fusselbär
 
Zurück
Oben