Beiträge von Xaar

Auch wenn ich eher der AMD-Anhänger bin (und das auch schon seit gut 'nem Vierteljahrhundert), so find' ich die Probleme bei Intel schon etwas schade - kann man nur hoffen, dass die wieder auf den Grünen Zweig kommen. Aber AMD (siehe die Probleme mit der FX-Serie) und auch Intel (Pentium-4-/-D-Ära) hatten schon schon schwierige Zeiten.

Am Ende sehe ich's ähnlich wie michi Konkurrenz belebt das Geschäft.

Boney M. - Belfast

Zitat von Sje

Der SiS-Fluch kann es nicht sein, das Board hat den Via KT400

Ist bestimmt ein SiS-Chipsatz im Undercover-Einsatz, getarnt als VIA-Chipsatz

Vielen Dank!

Zitat von Dirk

Ich weiß nicht wie andere Betriebssysteme das machen. Bei Linux hängt man ja meißt in der Konsole, und die ist auch schwarz. Vermutlich stimmt es schon, dass die meisten Anwender damit nichts anfangen können, oder auch durch den Trend zu kompakten Geräten und Laptops meist Hardwarefehler auch nicht ohne weiteres behoben werden können. Und bei Software muss man halt wissen, wo es her kommt.

Eben um zu wissen "wo es her kommt", ist 'ne detailliertere Fehlermeldung schon echt praktisch. Kann man ja auch so gestalten, dass der Laie damit nicht überfordert wird - und eben einen recherchierbaren Fehlercode ergänzen.

Wie wichtig sowas ist, sehe ich gerade an einem Beispiel bei mir, wenn auch unter Arch Linux: Hab' da auf einem Notebook alles an Paketen aktualisiert - und dann festgestellt, dass mein Chromium (ungoogled-chromium-bin ist das Paket da in dem Fall) nicht mehr startet - ohne eine Fehlermeldung. Per Kommandozeile aufgerufen, kam außer einem ":("-Smiley auch nix Verwertbares bei rum - am Ende hat einfach der Rebuild des Chromium-Pakets geholfen, was ich aber nur durch Zufall rausgefunden habe. Bei einem anderen Notebook mit ähnlichem Problem (wobei ich da vom normalen Chromium zum Ungoogled Chromium gewechselt bin) funktioniert das allerdings nicht. Da gibt's am Ende aber auch keine hilfreiche Fehlermeldung. Da muss ich mal guggen, ob's irgend eine Art Logfile oder so gibt

Zitat von Steffen90

Für alle die leer ausgegangen sind, hier noch digitale Versionen der Dokumente.

Könntest du die Dokumente nochmal hochladen/bereitstellen? Bei mir steht, dass die Links alle erloschen sind (war auch am Freitag Abend schon der Fall).

Das hilft auch wirklich nur, wenn auf dem Schwarzen Bildschirm dann nur noch die Fehlermeldung "Es ist ein Fehler aufgetreten" steht - damit man auch ja nicht nach einer Ursache suchen kann.

Aber hey: Immerhin brauchen wir dann keine Farbbildschirme mehr, um einen Absturz zu erkennen

John Parr - Westward Ho

Trabi Go!

Hab' mir gerade den Film Idiocracy angesehen...

Klingt echt interessant - hab' aber leider keinen Platz dafür D:

Always the

Ja gut, die Belegung könnte man ja ändern - die Stecker kannst du umändern. Die Frage wäre aber: Welche von den Andern ist da was? Vermutlich ist Rot +5 Volt und Schwarz Masse (GND) - und Grün und Weiß dann Data+/Data- (oder umgekehrt).

Ist die andere Seite vom Kabel zugänglich? Also so, dass du erkennen kannst, wo welche Ader vom Kabel auf der Leiterplatte verlötet ist und wie die einzelnen Leiterbahnen auf der Leiterplatte zu den USB-Ports verlaufen?

Die "normalen" USB-Header haben eigentlich 4 Signale pro USB-Port dran: +5 Volt, Data+, Data- und Masse (GND) - und da meist zwei USB-Ports auf einem Stecker zusammengefasst sind und die Stecker verdrehsicher sein sollten, sind es meist 10-Pin-Header, bei denen Pin 9 fehlt. Pin 10 ist unbelegt.

Für dein Gigabyte-Board findest du die Belegung hier: https://download1.gigabyte.com/Files/Manual/m…-s2l(s2c)_e.pdf auf Seite 30.

Für das Gehäuse musst du eigentlich "nur" guggen, dass die Leitungen vom Header auf dem Mainboard am richtigen Kontakt vom USB-Port ankommt (Belegung siehe hier: https://de.wikipedia.org/wiki/Universal…cker_Typ-A_&_-B - allerdings musst du das auf die USB-A-Buchse übertragen, da ist der USB-A-Stecker dargestellt). Heißt im ungünstigsten Fall, dass du den USB-Anschluss im Gehäuse ausbauen musst.

Mal eine kleine Frage: Ich hab' hier an einem Rechner (Ryzen 3000 Mobile-APU mit Vega-IGP) mit Linux drauf, der nur einen DisplayPort-Anschluss für den Bildschirm zur Verfügung hat. Ich habe auf der anderen Seite aber nur einen Monitor/Projektor mit HDMI-Anschluss zur Verfügung und nutze daher einen DisplayPort-zu-HDMI-Adapter. Wenn ich nun den Monitor darüber anschließe, erhalte ich automatisch erstmal nur ein Bild in 640x480. Mit xrandr kann ich 'ne höhere Auflösung einstellen, die auch flüssig läuft. Nutze ich testweise den selben Monitor mit dessen DisplayPort-Anschluss, so läuft der direkt in nativer Auflösung. Das Phänomen habe ich sowohl bei Linux Mint 22.1 als auch bei Ubuntu 24.04 LTS - und auch beim testweise gebooteten grml Linux 2024.12 (die ja alle irgendwo auf Debian aufsetzen).

Gibt's hier einen Kniff, dass die Erkennung über den DisplayPort-HDMI-Adapter auch automatisch funktioniert? Oder habe ich dafür evtl. einfach den "falschen" Adapter erwischt?

Deswegen brauchst du ja auch mehr

Zitat von Dirk

Krasser CPU Kühler. Aber du brauchst dringend mehr Festplatten. Gibs SCSI mit PCI-E?

Jo, den Adaptec ASC-29320LPE z. B. - ansonsten gibt's ja auch noch SAS.

Mal ein paar Ergebnisse mit verschiedenen RAM- und OS-Konstellationen für einen Ryzen 5 8500GE mit Zen-4- und Zen-4c-Cores:

CPU

OpenCL

Vulkan

Interessant, dass die IGPU mit OpenCL kaum davon profitiert, ob der RAM im Dual Channel läuft, während der Abstand mit Vulkan doch deutlicher ist. Auch schön ist aber, dass der 8500GE nahezu gleichauf mit dem 8500G im DeskMeet X600 ist - wenngleich der thermisch gedrosselt ist.

Und auch nochmal für Geekbench 6 für die selbe Maschine die Werte.

CPU

OpenCL

Vulcan

Mal ein paar verschiedene Ergebnisse für einen Core i7 8750H. Interessant, wie krass der Unterschied zwischen Single Channel (mit etwas geringerem Takt) und Dual Channel ist. Außerdem ein paar GPU-Benchmarks für die beiden GPUs des Rechners.

CPU

OpenCL

Vulcan

CUDA