I7 L640, elementary OS und Treiber

Die ersten HD Graphics im Core sind sogar zu langsam fuer einfache Sachen, nicht mal Doom 3 lief da.

Da war man damals mit AMD APU echt viel besser dran

Zitat von Dosenware

Das wäre dann aber leider nicht der Sinn der Sache, ich wollte explizit die Linuxvariante testen... aber daraus wird wohl nichts...

Ja, kann man leider nicht ändern. Wie gesagt Unity3D hat einen Fallback Renderpfad auf DX9, aber leider nicht auf OpenGL2.

Bleibt nur ältere Versionen oder auf llvmpipe umschalten.

In diesem Fall ist eine Fehlermeldung sogar ultra schwer zu machen. Da die 32-bit Schicht, quasi eine 32-bit OS im 64-bit OS ist und wenn man versucht die 32-bit Binary auszuführen, dann weiß Linux nicht, was er damit machen soll. Für ihn ist es eine Binäre Datei aus einer anderen Welt. Man könnte ja versuchen ein ARM Binary auszuführen und sehen was passiert. Die Frage ist, wer soll die Fehlermeldung ausgeben, dass die Datei, die man gerade versucht auszuführen mit der verwendeten Plattform inkompatibel ist? Die Applikation selbst kann es nicht, weil nicht lauffähig und das OS auch nicht, weil dafür ist es einfach nur irgendeine Binäre Datei.

Wo ich auf jeden Fall zustimme ist, dass es für einen Anfänger nicht ersichtlich ist, dass viele Linux Distributionen die 32-bit Schicht irgendwann aus der Standardinstallation raus geschmissen haben. Und die Fehlermeldung "File not Found" irreführend ist, weil man nicht versteht, dass das, was nicht gefunden wurde der 32-bit Interpreter ist und nicht das Programm, welches man versucht zu starten.

Aber Grundsätzlich an alle Mitleser. Wenn Ihr 32-bit Applikationen bei Euch aufrufen wollt, installiert die 32-bit Schicht mit, sonst kann man nur 64-bit Applikationen starten.

EDIT: Manche mögen wenn erst alles installiert wird und man dann das deinstalliert, was man nicht braucht und manche mögen, wenn nur das installiert wird, was wirklich notwendig ist und man installiert dann alles nach, was man braucht. Ich gehöre auf jeden Fall in die zweite Gruppe.

Dosenware hast Recht, unter Windows geht es so lange die Datei *.EXE heißt. Ich korrigiere meine Aussage, da Linux Dateien anders behandelt und da grafische Oberfläche nicht zum Betriebssystem gehört, sonder nur eine Art Shell ist, ist es dort sehr schwer so eine Fehlermeldung zu machen. Die Shell sagt dem Betriebssystem, dass es die Datei ausführen soll und das Betriebssystem weiß eigentlich nichts von der Shell. In Windows ist die grafische Oberfläche untrennbar mit dem Kernel verbunden.

Zitat von Dosenware

Und das das System nicht mit der Shell kommuniziert kann ich mir wirklich nicht vorstellen...

Das geht jetzt zu tief in die Materie, aber kann's nicht. Es geht allein schon aus Sicherheitsgründen starke Trennung zwischen den Schichten. Der Kernel kann auch kein Fenster öffnen um Dir die Fehlemeldung anzuzeigen, wie etwa bei Windows. Es gibt sehr viele Gründe dazu aber in dieses Kaninchenloch möchte ich jetzt nicht absteigen. Und ob Dir die Fehlermeldung "Es ist ein Fehler -42 passiert" helfen würde, das bezweifle ich sehr, denn die Fehlercodes sind nicht wirklich standardisiert (nur 0, was kein Fehler bedeutet). Das einzige worüber man sich Gedanken machen könnte ist, dass die Desktop Environment Entwickler (Gnome, KDE etc.) sich etwas überlegen und den Output der unteren Schichten als Fehlermeldung anzeigen. Allerdings ist es auch nicht einfach, weil die ausgeführten Programme (und das tun wirklich die meisten) auf den STDOUT loggen. Würde die Grafische Oberfläche grundsätzlich da alles umleiten, hättest Du ganz schon viel Müll auf dem Bildschirm.

Jedenfalls ist das der Punkt, wo sich Windows und Linux sehr stark unterscheiden, mit allen Vor- und Nachteilen. Und der Nachteil von Linux in diesem Fall, dass eine grafische Fehlermeldung schwer zu machen ist, wenn Du versuchst eine Datei auszuführen, die mit der Plattform inkompatibel ist. Wenn es einem hilft, falls ein Programm unter Linux nicht läuft, sucht die Fehlermeldungen grundsätzlich auf dem STDOUT (Konsole) und ihr spart euch viel Zeit. Ist von Windows zwar ungewohnt, aber in Wirklichkeit halb so wild. So bald eine Applikation wirklich läuft, ist es dann die Aufgabe der Applikation die Fehler anzuzeigen und viele Entwickler machen das mit einem einfachen printf(...), daher fällt alles auf der Konsole raus.

Is wie früher auf unseren Bankterminals: "Was'n hier los? das geht gar ni!?!" - "Musste mal ins Journal gucken warum der spinnt!"

Manchmal stellen wir uns etwas eine Weise vor und doch funktioniert es auf eine ganz andere. Wie gesagt, es ist nicht so einfach. Die Fehlercodes sind nicht standardisiert, die Desktop Umgebung weiß nicht von wem der Fehlercode kommt, von der Applikation oder vom System. Alles was gesehen wird, es gab einen Fehler. Dazu kommt noch, dass die Applikationsentwickler sich oft überhaupt nicht dran halten und entweder immer mit 0, oder immer mit einem Fehlercode aussteigen. Und mit DOS würde ich das ganze sowieso nicht vergleichen, da liegen Welten zwischen, wenn wir auch noch Real Mode anfangen anzuschauen....

Wie gesagt, ich möchte da nicht absteigen, falls es Interesse gibt, es gibt viel Dokumentation und andere Foren, wo so etwas erforscht werden kann. Wenn man eine Gitarre spielen kann, heißt es noch lange nicht, dass man weiß, wie eine Geige zu spielen ist, obwohl beides Saiteninstrumente sind und man kann an beiden zupfen. Beide klingen auch unterschiedlich und es gibt schon Gründe dafür, auch wenn diese manchmal nicht sofort ersichtlich sind.

Kleine Anmerkung in diesem Zusammenhang von mir:

Wer z.B. den Steam-Client unter Linux installieren will, braucht ebenfalls die 32-bit Schicht.

Ja. Beim Suspend-To-Disk wird Dein Arbeitsspeicher komplett in den Swap geschrieben, d.h. der Swap muss mindestens so groß sein, wie der Arbeitsspeicher. Du musst die Kernel boot Option resume=UUID hinzufügen, wo der Swap zu finden ist. Ich bin mir jetzt nicht ganz sicher, wo man das bei Debian macht, aber ich glaube das geht so:

In die Datei /etc/initramfs-tools/conf.d/resume musst Du folgendes einfügen, wobei UUID muss angepasst werden, dass es der deiner Swap Partition ist

RESUME=UUID=010325a0-3867-4606-94da-51efff3e57ba

Danach in der Konsole ein Mal ausführen:

# update-initramfs -u -k all

Achte dass es keine Fehler gibt, sonst hast Du beim nächsten Boot ggf. ein Problem.