Sehe ich genauso, es muss nicht alles auf eine SSD
Bei der Umnutzung diverser ausrangierter Bürorechner (Dunstkreise: Athlon64 X2, Phenom II X4, FX) als Messrechner führte das Entfernen der HDDs in allen Fällen zu einer deutlich verbesserten Responsivität insbesondere bei der Nutzung des Dateimanagers. Positiver Seiteneffekt ist die deutlich reduzierte Erschütterungsempfindlichkeit der Kisten ohne HDDs (und optischen Laufwerken) drin.
--> Ich hab übrigens schon bestellt. 386SX Single Board Computer; ISA Backplane;
Klingt irgendwie nach Frustkauf.
Ist das 'n Teil mit ALi M6117 (386SX Single Chip PC) drauf?
CodeMotherboard: CPU Typ HexaCore AMD Ryzen 5 2600X, 4000 MHz (40.25 x 99) Motherboard Name Asus Prime X370-Pro (3 PCI-E x1, 3 PCI-E x16, 1 M.2, […] Festplatte WDC WD10EZEX-60WN4A1 (1 TB, 7200 RPM, SATA-III)
Aller Augen warten auf dich, Festplatte …
HDD raus schmeißen = performance boost
Eine 1 GB PCIe 3.0 NVMe SSD kostet nicht mehr die Welt.
Macht es überhaupt Sinn die 3dfx mit jüngerer Hardware zu kombinieren?
Nein.
Die 3dfx gehört auf ein Brett aus der Zeit vor AGP.
Da auf Win9x verwiesen wurde und dieses Treiberarchiv auch den Schwerpunkt darauf setzt, würde ich ein Brett mit Sockel-7 (z.B. mit Pentium-S 200) oder maximal Sockel-7 "split voltage" (z.B. mit Pentium MMX 233 oder K6 233 Model 6) dafür nehmen. Dazu passt dann auch Win9x treibermäßig.
Win9x auf Hardware, die deutlich neuer als die 3dfx ist, ist ein mehr oder weniger übles Gewürge wegen der Treiberei. Zudem bremst die 3dfx dann den Rest aus. Wenn die Hardware mindestens Windows 2000 verlangt, mag ein Treiber dabei sein, der die Anzeige der GUI erlaubt, aber wohl kaum ernsthaft 3D, insbesondere das zu der Zeit schon recht verstaubte Glide unterstützt.
Falls Du über Dualboot nachdenkst: Unter Linux werden die 3dfx-Karten mit dem tdfx-Treiber bestiefelt. So etwas läuft hier (3Dfx Voodoo3 2000 auf Sockel-7-Brett mit Pentium-S 200), aber ernsthaft 3D habe ich darauf noch nicht getestet.
Dass 386er Bretter nur die ×9 organisierten Module (SIMM, SIPP) unterstützen, scheint eher die Regel als die Ausnahme zu sein.
Als Fan von RAM-Maximalbestückungen könnte das ja für dich von Interesse sein, kannst ja mal schauen ob bei deinem 386 A11 (Adress-Line für 16 MB Module) verkabelt ist.
Von fisseligen Lötarbeiten bin ich aber aus "optischen" Gründen gar kein Fan mehr. Alles kleiner RM2,5 muss nicht mehr … fortschreitende Vergreisung halt.
Laut Doku ist bei den drei aufgebauten 386ern und den beiden aufgebauten 486ern nur mit je acht SIMM Slots an Bord jeweils bei 32 MiB RAM = 8× 4 MiB SIMM Schluss.
Einzig ein 486er, der zwei PS/2 Slots und vier SIMM Slots an Bord hat, kann laut Doku 128 MiB RAM = 2× 32 MiB PS/2 FPM + 4× 16 MiB SIMM. Da limitiert jedoch die VL-Bus-Grafikkarte, die ihren Adressbereich unsinnigerweise bei 62 MiB einblendet, weshalb in der Kiste aktuell bei 48 MiB RAM = 2× 16 MiB PS/2 FPM + 4× 4 MiB SIMM Schluss ist.
Die Diagnosekarte ist dieses einfache
Prinzipiell interessant, nur werde ich vor der Alpenfahrradtour nix mehr bestellen, damit kein Kram während der Tour ankommt. Danach kann man für 12,- € + Versand nicht sooo viel falsch machen.
XT-Bus-Slots:
Die Leiterbahnen sind zwischen den beiden XT-Bus-Slots und den unbekannt vielen (4 ?) ISA-Bus-Slots durchgeschliffen. Die musst Du also so oder so wieder durchgängig machen. Dann könntest Du auch wieder zwei neue XT-Bus-Slots einlöten. Die ausgelöteten XT-Bus-Slots würde ich direkt entsorgen.
RAM:
Die 72-poligen PS/2-Module gibt es in den Versionen FPM und EDO. Ein PS/2 FPM Riegel ist elektrisch die Zusammenfassung von vier SIMM Riegeln. Da sollte also elektrische Kompatibilität gegeben sein. EDO ist elektrisch inkompatibel zu FPM, wird also auf dem Brett mit sehr hoher Wahrscheinlichkeit nicht funktionieren. Solltest Du das Brett in Gang bekommen und es hapert nur am RAM, kann ich Dir evtl. 4× 1 MiB SIMM zukommen lassen. Angeblich lassen SIMM sich recht einfach durch Anlöten von Drähten an die Kontakte zu SIPP umbauen, habe ich aber mangels Bedarf nie probiert.
Diagnosekarte:
Taugt die was? Würde mich grundsätzlich mal interessieren.
Soundkarte:
In einem meiner 386er steckt eine "Best Union Electronics MF-1868" mit ESS 1868 Chip und PnP-IDE-Port, wobei am PnP-IDE-Port ein CDROM-Laufwerk hängt. Das geht grundsätzlich also. Auf dem 386er (i386DX-33 + i387 16-33; 32 MiB RAM) läuft Linux mit Kernel 2.4.33.3, der das ISA-PnP unabhängig vom BIOS übernimmt. Der Treiber für den PnP-IDE-Port ist gut versteckt im Kernel, der Soundtreiber kommt bei Kernel 2.4 noch extra als alsa-Treiber. Unter DOS hast Du die Soundkarte ja in Gang gekriegt. Das sollte also auch auf dem 386er gehen, sofern mit dem DOS-Treiber das im BIOS fehlende ISA-PnP umgangen werden kann. Es gibt für DOS auch CDROM-Treiber, denen IRQ und I/O-base des IDE-Ports, an dem das CDROM-Laufwerk hängt, als Parameter verabreicht werden können, womit ebenfalls das im BIOS fehlende ISA-PnP umgangen wird.
FPU:
Die lohnt sich nur, wenn Du auf der Kiste ein Programm laufen lassen möchtest, das nach damaligen Maßstäben ohne FPU unerträglich lahm oder gar nicht läuft. Beispiele: AutoCAD für DOS läuft meines Wissens gar nicht ohne FPU. Der Linux-Kernel muss ohne FPU die "math emulation" nutzen, wodurch Linux dann wie 'ne Schlaftablette läuft.
Das SoaD Cover ist ja mal geil. Kannte ich gar ned
Dass ein Violoncello ähnlich bratzen kann wie eine verzerrte E-Gitarre, war mir bekannt, aber "Double Bass Drumming" auf einer Djembe kannte ich vorher auch nicht.
System of a Down - B.Y.O.B. (Cello Cover)
und hier mal die "andere Richtung":
J. S: Bach: Suite Nr. 1 für Violoncello solo G-Dur BWV 1007 – Prélude (E-Guitar cover)
Ist aber Overkill für eine treiber senke. Aber ein Backup wäre nicht schlecht.
Eine externe HDD ist in Verbindung mit moderner Hardware einfach nur noch eines: unendlich lahm!
Zudem ist eine SSD in einem robusten Gehäuse wesentlich weniger stoßempfindlich als eine externe HDD. 
Daher spiele ich mit Linux seit einigen Jahren. Ich komm inzwischen gut damit klar, nur einige Programme vermisse ich schmerzlich.
Das ist völlig normal, war vor über 20 Jahren, als ich umstieg, auch nicht anders. Erfahrung sagt aber, dass sich für die meisten Programme recht zeitnah brauchbarer Ersatz findet, und diesbezüglich ist die Situation heute deutlich entspannter als vor 20 Jahren. Problematisch wird es nur bei irgendwelcher Supersommersonderspezialsoftware wie etwa Maschinensteuerungen oder vielleicht auch einigen Spielen und Simulatoren. Vor 20 Jahren gehörten in diese Kategorie auch so Software wie Notensatz, Vektorgrafik, FEM, CAD oder Buchhaltung. Heute ist es eher so, dass man nur wechseln wollen muss.
OT: Als dieser Thread erstellt wurde, lief hier noch die Kiste mit dem FX 8350 drin, weshalb ich mit "Nein, meine Hardware gibt es nicht her" stimmte. Nach dem Hardwareupgrade auf den Ryzen 7 5800+ im Arbeitsrechner und den Ryzen 5 5600+ im Software-Ausprobierrechner wurde auf Windows 11 umgestellt, wobei das allerdings nur sehr selten genutzt wird, weil normalerweise Linux läuft. Windows 10 läuft hier nur noch auf einer Museumskiste, der der Internetzugang unter Windows im Herbst 2025 genommen werden wird. Auf Arbeit wird das noch Gewürge werden, weil da noch Hardware – Dort laufen noch einige AMD FX, und die sind eher nix für Windows 11. – gekauft werden muss, und wenn es dumm läuft und die Lizenzrettung über das Microsoft-Konto nicht mehr funktionieren sollte, auch Windows 11 Lizenzen. Der Chef hat aber 'nen Igel im Portemonaie …
Im UEFI-Bios ist ein Home-Key hinterlegt, das WIN10 habe ich aber mal mit einem alten W7-Key in Pro umgewandelt. Das müßte ja beim Upgrade als digitale Lizenz übernommen werden, oder?
Die Betonung liegt auf dem Konjunktiv "müsste". Jede Änderung an der Hardware kann eine Neuaktivierung erfordern, und dann ist Schluss mit lustig.
Für den Fall der Fälle könnte ich vorher eine Art "Maintenance-WIN10" auf meinem Laufwerk D: installieren, damit ich an alles herankomme, falls beim Upgrade auf C: irgendetwas schief läuft.
Das kann vom Update aber auch zerlegt werden. Nur wenn Laufwerk D: eine zweite SSD/HDD ist, die vor dem Update abgestöpselt wird, passiert erst mal nix damit.
Aber wozu überhaupt der Aufwand? Vor so etwas macht man eh ein Backup. Und an den Kram selbst kommt man auch mit einem Live-Linux dran. Anders als mit einem zweiten Windows sind da keine Wechselwirkungen mit dem ersten Windows zu erwarten.
Auf der Platte befinden sich ca. 1.3TB in über 600.000 Dateien […] welches beim Sichern auf eine ext. USB-Platte jetzt erstmal trotz USB3 über einen Tag dauern wird
Ist das etwa noch eine USB-HDD? Dann gibt es kein Mitleid! 
Stand der Technik ist eine PCIe 3.0 NVMe-SSD in einem USB 3.2 Gen 2-Gehäuse.
ein Bild von damals, als auch im Harz die Fichten noch Nadeln trugen
Auf den ersten Blick löst ein grid-Layout das Problem.
Die html-Datei wird dadurch etwas übersichtlicher. In der css-Datei ist es quasi egal.
Mit ganz alten Brausen wird sich das dann aber nicht mehr anzeigen lassen. Wenn ich das richtig verstanden habe, ist die Historie bei den html-Layouts: table → div → grid
Für eine Fotogalerie, die gleich die kompletten Bildsätze in voller Auflösung lädt, ist aber eh etwas mehr Bums in der Kiste und auf der Leitung erforderlich. Dafür ist 'n Athlon XP mit Windows XP und Firefox 48.0.2 wohl doch etwas zu schlapp.
Ach ja, die schwarzen Beerdigungsrahmen um die Bilder kommen natürlich noch weg. Die dienen hier nur dem Debugging.erl.
Und wenn schon grid, dann kommt das auch noch für die beiden anderen "Tabellen" (Text über Bildern und Fußzeile) statt div-Layout.erl.
zu früh gefreut 
Wenn unter einem Bild, das nicht am rechten Rand steht, die Bildunterschrift mehr Zeilen benötigt als bei anderen Bildern in der Zeile, passiert das.
Wieso passiert das und wie lässt sich das verhindern, sodass es keine leeren "Plätze" mehr gibt (außer evtl. ganz unten nach dem letzten Bild) und wieder alle "Plätze" innerhalb einer Zeile mit je einem Bild samt Bildunterschrift gefüllt werden?
Das passierte bereits mit <div class="gallery">, der Wechsel auf <figure class="gallery"> brachte dahingehend leider keine Änderung. Auch sonst änderte sich dadurch nix, nur die html-Datei wurde etwas übersichtlicher, da nun weniger geschachtelte <div> drin sind.
Das war inna Nacht ein 1. Schuss. Vorhin bei einer kurzen Fahrradrunde "für 'n Kreislauf" fiel die Entscheidung, die doch recht voluminöse Box rauszuschmeißen. Ein sich ändernder Mauszeiger, die sich ändernde Opazität des Bildes und ein dabei erscheinender blauer Rahmen um das Bild – Textlinks wurden und werden oftmals ebenfalls blau dargestellt – reichen hoffentlich, die Leute zum drauf klicken zu animieren. Durch den Rauswurf der Box sind zudem sowohl die html-Datei als auch die css-Datei etwas schlanker geworden.
Mit position: relative; ging das Zentrieren der Box irgendwie nicht, dafür traten unerwünschte Nebenwirkungen auf. Wahrscheinlich geht das nur mit Script, und das sehe ich für so etwas nicht ein, da das "Kanonen auf Spatzen" wäre.
Dass die "Masse da draußen" sich 'ne Fotogalerie auf dem Mäusekino rein zieht, ist schwer vorstellbar. Da drauf erkennt man doch nix. Minimal sollte es schon ein Tablet sein.
Hier läuft gerade ein kleinerer HTML-Nahk(r)ampf.
Seiten dieser Art sollen zukünftig in dieser Art angezeigt werden, also kein grundsätzlich neues Design, aber Änderungen in Details. "Unter der Haube" passiert dafür notwendigerweise einiges, so geht das nicht mehr in HTML 4, womit auch CSS nötig wird. JavaScript bleibt aber draußen! Insbesondere wird von table-Layout auf div-Layout umgestellt.
Was mich am obigen Ergebnis noch stört, ist die Einblendung des "tooltips" bei mouse hover unter den Bildern. Der soll eigentlich mittig in den Bildern eingeblendet werden.
Code wird bei Bedarf nachgereicht.
[quote='Arnulf zu Linden','RE: Dateisystem für Zugriff durch Linux und Windows']
In dem Zuge gleich 'ne Frage: Wie krieg' ich raus, über welchen Treiber auf ein Dateisystem zugegriffen wird?
Ein Blick in /etc/fstab sollte Klarheit bringen, in diesem Fall steht da ntfs-3g oder ntfs.
Hier zu Hause und auf Arbeit wird dafür (mit Linux Kernel 6.6 & Windows 10|11 – alles 64-Bit) exFAT genutzt, das mittlerweile quelloffen ist.
Nachteil: exFAT hat kein journaling, aber man hat ja ein Backup für den Fall der Fälle …
Kernel 6 bringt auch einen nativen NTFS-Treiber mit, womit NTFS-3G obsolet wird. Mehr als mal probeweise habe ich diesen nativen NTFS-Treiber (genauso wie NTFS-3G ) aber noch nicht benutzt.
FAT32 wird hier nur für Museumskisten benutzt, die maximal 'ne Distro mit Kernel 4 mit sinnvoller Performance stemmen können und daneben Windows 2000|XP|Vista drauf haben – ist dann auch in Hard- und Software alles komplett nur 32-Bit.
Hier würde ich eher noch mal schauen, ob nicht noch weniger reicht. Ist halt die 125W Version und etwas sparen wäre für alle Komponenten gut.
Hart weniger für Sockel AM2 bzw. Sockel AM2+ liegt hier inna Kramkiste, die sind also übrig:
Auf einem Athlon64 X2 4800+ (Brisbane) mit 8 GiB RAM lief hier anno knips mal kurzzeitig Windows XP 32-Bit + Gavotte RAM-Disk. Das wurde damals aber doch recht bald von Windows 7 64-Bit und Linux 64-Bit abgelöst. Und danach musste der Athlon64 X2 4800+ einem Phenom II X4 945 (3,0 GHz ×4; 95 W) Platz machen.
