SD-Karte nicht mehr beschreibbar

[Volker Bartheld]

On Tue, 05 Feb 2019 12:21:16 +0100, Ralph A. Schmid, dk5ras wrote:

Volker Bartheld <news2018@bartheld.net> wrote:
Und die DSP-Baugruppe hat keinen RAM? Nicht einmal irgendeinen Puffer? Und
Doch, der wird aber geprüft beim Booten.

Wie wird er denn geprüft beim Booten? So wie Non-ECC-RAM vom BIOS im
"Quick"-Modus? Oder eher wie im "Extended"-Modus? Oder gar so, wie es
c't-Ramtest tut? Und was wäre dann der fundamentale Unterschied zu einem
PC, dessen RAM die Daten manchmal nicht halten kann?

Nein, keine Utopie. Genau so anno 2001 in der VIA-Soutbridge 82C686B
passiert: https://www.heise.de/newsticker/meldung/VIA-Chipsatz-beschaedigt-Daten-35848.html
Klar, shit happens, das ist nix Neues

Und wenn Scheiße _nicht_ passieren würde, bräuchte wir weder ECC-RAM, noch
irgendwelche RAID-Level, Prüfsummen, Backups oder sonstwelche Vorkehrungen
zur Erhöhung der Datensicherheit.

Es ist halt so, wie einer meiner Vorredner schon kundgetan hat: Man
definiert seinen Ponyhof in Sachen Datensicherheit/-integrität. Dann
schaut man auf den Kostenfaktor und ist u. U. relativ plötzlich bereit,
deutliche Abstriche zu machen.

So schaut es aus - oder auch rein, was technisch machbar ist. Wenn es
was nicht gibt, dann gibt es das eben nicht.

Es gibt tatsächlich erstaunlich vieles.

Du kannst Dir ein zertifiziertes, nicht total auf Kante gebügeltes
Server-Motherboard mit ECC-RAM in ein elektrisch gut abgeschirmtes
Fort-Knox-Gehäuse einbauen, darauf ein OS mit Bitrot-sensibilisiertem
Dateisystem installieren, dessen Sourcecode in unabhängigen Reviews auf
Herz und Nieren geprüft wurde.

Der Prozessor hat hoffentlich kein Problem mit Spectre/Meltdown und
unterstützt DEP/das NX-Bit. Dortdrinnen bringst Du (mindestens) fünf
Massenspeicher an den Start, drei SSDs von unterschiedlichen Chargen
unterschiedlicher Hersteller und zusätzlich noch Dreheisen.
Austausch/Migration in regelmäßigen Zeitabschnitten, nicht erst, wenn
SMART mit der roten Fahne wedelt.

Daten werden sebstverständlich in versionierenden Repositories abgelegt
(SVN, GIT) und das Backup erfolgt mehrkanalig rotierend z. B. via NAS,
Cloud, externe USB-Laufwerke, usw., regelmäßige Kontrolle der dabei
erzeugten Hashes sind natürlich ebenso Pflicht wie die Unterbringung von
mindestens zwei Kopien in räumlich getrennten, explosions-/feuer- und
fremdzugriffsgeschützten Panzerschränken.

In Sachen "Benutzermanagement" trennst Du strikt zwischen Administrator und
sonstigen Rollen, lebst den Gedanken von Elevation und "so wenig Rechte wie
möglich, so viele Rechte wie nötig", testest jegliche Software zunächst auf
Herz und Nieren in einer Virtualisierungsumgebung und sorgst dafür, daß Du
bei jedem Softwareupdate eine Kopie des früheren Installers zu
Referenzzwecken aufhebst, damit Du die Daten bei möglichen
Inkompatibilitäten mit der Applikation aufmachen kannst, die sie originär
erzeugt hat.

Damit ließe sich schon ordentlich arbeiten. Entscheide selbst, wie weit Du
gehen willst. Letztlich kann man Sicherheit in einem Maße steigern, daß
sie nur noch durch die praktische Unbenutzbarkeit des System gegeben ist,
wie sich im digitalen Zahlungsverkehr (Mehrfaktorauthentisierung, PIN/TAN,
Sicherheitsabfragen, Captchas, usw.) schon abzeichnet. Dann sinkt die
Akzeptanz rapide ab und man verständigt sich recht fix auf die
individuelle Wohlfühlgrenze, da - allen anderslautenden Parolen unserer
Politiker zum Trotz, Sicherheit kein Selbstzweck ist.

Volker

 

[Hanno Foest]

Am 06.02.19 um 10:50 schrieb Volker Bartheld:

Es gibt tatsächlich erstaunlich vieles.

Du kannst Dir ein zertifiziertes, nicht total auf Kante gebĂźgeltes
Server-Motherboard mit ECC-RAM in ein elektrisch gut abgeschirmtes
Fort-Knox-Gehäuse einbauen, darauf ein OS mit Bitrot-sensibilisiertem
Dateisystem installieren, dessen Sourcecode in unabhängigen Reviews auf
Herz und Nieren geprĂźft wurde.

Schon beim BIOS/UEFI kannst du das mit dem Sourcecode und unabhängigen
Reviews knicken.

Der Prozessor hat hoffentlich kein Problem mit Spectre/Meltdown und
unterstĂźtzt DEP/das NX-Bit. Dortdrinnen bringst Du (mindestens) fĂźnf
Massenspeicher an den Start, drei SSDs von unterschiedlichen Chargen
unterschiedlicher Hersteller und zusätzlich noch Dreheisen.

Man kann alles Ăźbertreiben, und man kann auch alles veralbern. Ich hab
hier ECC RAM, RAID, SystemvollverschlĂźsselung und eine gegen
Spectre/Meltdown einigermaßen unempfindliche CPU. Und Backups, teilweise
außer Haus. Der Aufwand ist nicht völlig insignifikant, hält sich aber
in Grenzen. Es ist wie mit einer Versicherung: Bezahlt man den Aufwand
nicht, hat man mit einer gewissen Wahrscheinlichkeit später deutlich
mehr Ärger. Ob sich das lohnt, muß jeder selber wissen - und ggf. meinen
Spott ertragen.

Hanno

 

[Volker Bartheld]

On Tue, 5 Feb 2019 17:13:33 +0100, Hanno Foest wrote:

Tatsächlich hatte ich schon anno 1983
Problem mit gurkigem RAM in einem Sinclair ZX Spectrum
Der Unterschied zu PCs ist aber, daß man auf den Dingern nicht größere
Mengen Daten bearbeitet und archiviert, weswegen Crashes vielleicht
ärgerlich sind, aber nicht die Datensicherheit/-integrität von
Geschäftsdaten, Steuererklärung, Videosammlung etc. gefährden.

Dem kann ich mich nicht anschließen.

Ich habe damals etliche Megabytes auf Kompaktassetten gespeichert (das
steht vermutlich in einem ähnlichen Verhältnis zum Hauptspeicher wie es
heute bei PCs der Fall ist) und auf dem ZX Microdrive (~3xRAM). Beide
Medien sind an magnetischen und mechanischen Problemen eingegangen, die
ich schon berichtet habe und hier den Rahmen sprengen würden. Überall dort
sind hunderte Mannstunden an Arbeitszeit verloren gegangen, ich gab mich
der Sicherheit hin, daß ein paarmal auf Band und noch einmal auf dem
Microdrive Cartridge wohl ausreichend wäre.

Betroffen ist schriftliche Korrespondenz
(http://www.worldofspectrum.org/infoseekid.cgi?id=0008854), Programmcode
(http://www.worldofspectrum.org/infoseekid.cgi?id=0008091), Tabellen,
gescannte, Bilder, Teile von Studienprotokollen, usw.

Einen wesentlichen Unterschied zur Gegenwart kann ich also nicht erkennen.

Und diejenigen, die vor etlichen Jahren Xerox ihre Dokumente anvertraut
haben
(http://www.dkriesel.com/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning),
sind vermutlich auch nicht gerade erbaut, egal, ob nun das famose BSI
Verfahren verboten hat, die "Pattern Matching & Substitution" nutzen. Mit
dem gleichen Argument, können wir übrigens jegliche fortgeschrittenen
OCR-Techniken ebenfalls in die Tonne treten.

die 500 Schleifen für eine Umrüstung auf X99-E WS fand ich dann doch
nicht ganz so attraktiv.
Es war halt immer etwas teurer, einen seltsamen Geschmack zu haben...

Unbestritten.

Volker

 

[Volker Bartheld]

On Wed, 6 Feb 2019 11:12:36 +0100, Hanno Foest wrote:

Am 06.02.19 um 10:50 schrieb Volker Bartheld:
Du kannst Dir ein zertifiziertes, nicht total auf Kante gebügeltes
Server-Motherboard mit ECC-RAM in ein elektrisch gut abgeschirmtes
Fort-Knox-Gehäuse einbauen, darauf ein OS mit Bitrot-sensibilisiertem
Dateisystem installieren, dessen Sourcecode in unabhängigen Reviews auf
Herz und Nieren geprüft wurde.

Schon beim BIOS/UEFI kannst du das mit dem Sourcecode und unabhängigen
Reviews knicken.

Dann darf der Hardliner eben keinen PC benutzen. Gibt ja auch
Schreibmaschinen.

Der Prozessor hat hoffentlich kein Problem mit Spectre/Meltdown und
unterstützt DEP/das NX-Bit. Dortdrinnen bringst Du (mindestens) fünf
Massenspeicher an den Start, drei SSDs von unterschiedlichen Chargen
unterschiedlicher Hersteller und zusätzlich noch Dreheisen.

Man kann alles übertreiben, und man kann auch alles veralbern.

Kann man. Mir ist es aber todernst mit der Aussage. Du kamst IIRC mit der
Google-Statistik und hast sie auf das Resümee "[...] more than 8% of DIMMs
affected by errors per year. [...]" verkürzt. Ich weiß nicht, ob die
Fehlerrate im Vergleich zu der von z. B. SSDs, Festplatten, Pfusch im
Chipset, usw. relevant ist und einen Handlungsbedarf erfordert. "Es kann
jedenfalls nicht schaden" ist leider noch nie eine vernünftige Erklärung
für akuten Handlungsbedarf gewesen, auch wenn ECC möglicherweise einfach
und einigermaßen günstig umzusetzen wäre. Du bleibst jedenfalls die
stichhaltige Erklärung schuldig, warum ich lediglich übertreibe
(veralbere) und Deine Herangehensweise vernünftig ist.

Ich hab hier ECC RAM, RAID, Systemvollverschlüsselung und eine gegen
Spectre/Meltdown einigermaßen unempfindliche CPU. Und Backups, teilweise
außer Haus. Der Aufwand ist nicht völlig insignifikant

Das ist schön für Dich und ein durchaus sinnvoller Ansatz. So wie ich Dich
kenne, hast Du auch gegen "Layer-8-Fehler" Vorkehrungen getroffen und
kannst ggfs. versehentlich überschriebene Daten aus ihrer Historie wieder
herstellen. Damit tust Du vermutlich weit mehr als Andere.

Es ist wie mit einer Versicherung: Bezahlt man den Aufwand nicht, hat man
mit einer gewissen Wahrscheinlichkeit später deutlich mehr Ärger.

Das stochastische Konzept des Erwartungswerts, ja. Kein Widerspruch. Leider
ist das mit dem "gefühlten Erwartungswert", d. h. der menschlichen
Risikowahrnehmung dann schon wieder ein wenig anders. Ich bemühe jetzt
bewußt nicht die allseits beliebten Rad- und Skihelme und wiege auch nicht
die Opfer der diversen Nuklearhoppalas, von Terrorismus, usw. gegen
Abtreibungen, Tote des motorisierten Individualverkehrs, Genußgifte und
Bewegungsarmut auf.

Aber sagen wir, Du erleidest morgen einen tödlichen Schlaganfall und
gesetzt die Hypothese, daß Du Dich nicht nur aus rein egoistischen Gründen
um die Integrität Deiner Daten sorgst, sondern, weil Du Werke geschaffen
hast, die Du ggfs. der Nachwelt erhalten willst. Gibt es das Paßwort für
Deine Systemvollverschlüsselung im Testament? Und jetzt rechne die
Fehlerwahrscheinlichkeit von Non-ECC-RAM gegen Deinen potentiellen Exodus
im Straßenverkehr, durch Herzinfarkt oder Schlaganfall.

Soll heißen: Du bist technisch affin, suchst und propagierst daher
technische Lösungen. Das umschreibt man gerne mit "Kaum, da ich einen
Hammer besitze, sieht für mich alles wie ein Nagel aus." und sei Dir
gegönnt. Ob diese Lösungen im Gesamtkontext sinnvoll und angemessen oder
nur Bauchgefühl sind, könnte man diskutieren. Mich stört nur ein wenig die
Absolutheit Deiner Aussagen, die fast schon einen missionarischen
Charakter haben. Dererei fordert natürlich meinen Humor heraus, der Dir in
diesem Zusammenhang offenbar abgeht. Auch ein Indiz für missionarischen
Ehrgeiz.

Ob sich das lohnt, muß jeder selber wissen - und ggf. meinen Spott
ertragen.

Den sitze ich locker auf einer Arschbacke aus. Falls es dem Thema nichts
weiter hinzuzufügen gibt als Bauchgefühle ist für mich an dieser Stelle
EOD.

Volker

 

[Bernd Laengerich]

Am 06.02.2019 um 11:52 schrieb Volker Bartheld:

hast, die Du ggfs. der Nachwelt erhalten willst. Gibt es das Paßwort für
Deine SystemvollverschlĂźsselung im Testament? Und jetzt rechne die

https://www.golem.de/news/quadrigacx-kryptomarktbesitzer-tot-137-millionen-dollar-unerreichbar-1902-139166.html

Bernd

 

[Hanno Foest]

Am 06.02.19 um 11:19 schrieb Volker Bartheld:

Tatsächlich hatte ich schon anno 1983
Problem mit gurkigem RAM in einem Sinclair ZX Spectrum
Der Unterschied zu PCs ist aber, daß man auf den Dingern nicht größere
Mengen Daten bearbeitet und archiviert, weswegen Crashes vielleicht
ärgerlich sind, aber nicht die Datensicherheit/-integrität von
Geschäftsdaten, Steuererklärung, Videosammlung etc. gefährden.

Dem kann ich mich nicht anschließen.

Ich habe damals etliche Megabytes auf Kompaktassetten gespeichert (das
steht vermutlich in einem ähnlichen Verhältnis zum Hauptspeicher wie es
heute bei PCs der Fall ist) und auf dem ZX Microdrive (~3xRAM). Beide
Medien sind an magnetischen und mechanischen Problemen eingegangen, die
ich schon berichtet habe und hier den Rahmen sprengen würden. Überall dort
sind hunderte Mannstunden an Arbeitszeit verloren gegangen, ich gab mich
der Sicherheit hin, daß ein paarmal auf Band und noch einmal auf dem
Microdrive Cartridge wohl ausreichend wäre.

Erstens, das ist kein "Problem mit gurkigem RAM", wie noch eingangs
zitiert. RAM vs. Permanentspeicher.

Zweitens, meine ZX Spectrum Cassetten sind (soweit getestet) noch
lesbar. Ich erwarte da aber keine Überraschungen: Meine ähnlich alten
Audiocassetten hĂśren sich ja auch noch gut an. Dem rasenden SchnĂźrsenkel
(Microdrive) dagegen hab ich nie wichtige Daten anvertraut und war eher
überrascht, daß das nach 10 Jahren noch lesbar war (ist jetzt aber auch
schon ne Weile her, ich werde da auch noch mal mit Filztausch aus
RetrocomputinggrĂźnden experimentieren).

Drittens, damals wußte man es nicht besser, und besseres Material gab es
nicht bzw. es wäre prohibitiv teuer gewesen - was aufs gleiche
rauskommt. Heute weiß man es besser, das bessere Material gibt es, und
man kann es sich leisten.

Dumme Leute machen immer die gleichen Fehler. Kluge Leute machen immer
neue Fehler

Hanno

 

[Volker Bartheld]

On Wed, 6 Feb 2019 12:24:19 +0100, Bernd Laengerich wrote:

Am 06.02.2019 um 11:52 schrieb Volker Bartheld:
hast, die Du ggfs. der Nachwelt erhalten willst. Gibt es das Paßwort für
Deine Systemvollverschlüsselung im Testament? Und jetzt rechne die
https://www.golem.de/news/quadrigacx-kryptomarktbesitzer-tot-137-millionen-dollar-unerreichbar-1902-139166.html

Bestimmt auf RAID5, ECC und in 10 unabhängigen Backups unzugänglich. ;-)

Ahso: "[...] Die Kryptowährungsbörse hat zudem keine Backups oder andere
Sicherheitsmaßnahmen für ein solches Ereignis höherer Gewalt eingerichtet,
obwohl es solche Richtlinien bereits seit 2015 gibt. [...]". Ups. Nadann.

Vielleicht nutzte er ja immer noch den Dual_EC_DRBG nach den
NIST-Empfehlungen. Dann könnte man die NSA um Hilfe bitten [1]. SCNR.

Vol"Nein, ich kannte den Fall nicht!"ker

[1] https://blog.cryptographyengineering.com/2013/12/28/a-few-more-notes-on-nsa-random-number/

 

[Volker Bartheld]

On Wed, 6 Feb 2019 13:22:34 +0100, Hanno Foest wrote:

Am 06.02.19 um 11:19 schrieb Volker Bartheld:
Tatsächlich hatte ich schon anno 1983
Problem mit gurkigem RAM in einem Sinclair ZX Spectrum
Der Unterschied zu PCs ist aber, daß man auf den Dingern nicht größere
Mengen Daten bearbeitet und archiviert, weswegen Crashes vielleicht
ärgerlich sind, aber nicht die Datensicherheit/-integrität von
Geschäftsdaten, Steuererklärung, Videosammlung etc. gefährden.
Erstens, das ist kein "Problem mit gurkigem RAM", wie noch eingangs
zitiert. RAM vs. Permanentspeicher.

Du hast natürlich Recht.

Auf "gurkigem RAM" archiviert(!) man aber auch nicht "größere Mengen von
Geschäftsdaten" usw., außer, Du willst auf die Spitzfindigkeit hinaus,
Flash-Speicher erlaube ebenfalls wahlfreien Schreib-Lesezugriff. Ich kann
Dir nicht sagen, welche Crashes und nicht mehr lesbaren Dateien und mithin
Mannstunden auf das Konto von "gurkigem RAM" in meinem Homecomputer gingen,
einfach, weil ich es nicht weiß.

Wenn sich eine Datei nicht mehr laden ließ, weil das Parity-Bit nicht mehr
stimmte, dann war für mich die Sache erledigt, große Anstrengungen zur
forensischen Datenwiederherstellung in Maschinencode habe ich nicht
betrieben. Das ist mit der heutigen Hard- und Software leichter möglich,
da könnte ich die durchkopierten, verrauschten Bänder und die aus der
Reihe geratenen Blöcke auf einem Microdrive-Cartridge sicher wieder
einigermaßen zusammenpuzzlen.

Zweitens, meine ZX Spectrum Cassetten sind (soweit getestet) noch
lesbar.

YMMV. Ich habe den Kram kürzlich zur Gaudi getestet
(https://shred.zone/cilla/page/390/recovering-old-zx-spectrum-tapes.html)
und die Sache gestaltete sich weit schwieriger als zunächst angenommen. Von
"einfach mit Originalhardware zurücklesen" war das Material meilenweit
entfernt, obwohl es sich "gut anhörte".

> Meine ähnlich alten Audiocassetten hören sich ja auch noch gut an.

Das ist ein niedliches Argument. Du jagst eine "Datei" durch ein
intelligentes, psychoakustisches Expertensystem, das eine Datenbandbreite
von vielleicht 16kHz besitzt und als Filter obendrauf noch die
Erwartungshaltung an ein mit ferromagnetischem Material beschichtetes
Stückerl Plastik, das mit ungefähr 4cm pro Sekunde an einem Tonkopf
vorbeischleicht. Das vergleichst Du mit einem obskuren Konglomerat
diskreter Hardware, das aus ein paar Widerständen, Dioden, Kondensatoren
und einem Spezialchip besteht, dessen genaue Funktion bis heute nicht
restlos geklärt ist und schon damals nicht gerade für seine
Zuverlässigkeit berühmt war.

Ich würde sagen, Du probierst es einfach mal aus. Würde mich brennend
interessieren und "geht auf dem ZX Spectrum besser einzulesen als mit
96kHz-Abtastung, PC-Soundkarte und forensischer Software" wäre für mich
echt erstaunlich.

Dem rasenden Schnürsenkel (Microdrive) dagegen hab ich nie wichtige Daten
anvertraut und war eher überrascht, daß das nach 10 Jahren noch lesbar
war (ist jetzt aber auch schon ne Weile her, ich werde da auch noch mal
mit Filztausch aus Retrocomputinggründen experimentieren).

Auch hier sieht meine Praxiserfahrung anders aus und ich lade Dich herzlich
ein, es mal mit mdv2img (s. http://www.worldofspectrum.org/pub/sinclair/tools/pc/mdv2img.zip)
zu versuchen. Die Software ist zweilig, der Z80-Assemblercode pumpt die
Daten vom Microdrive via RS232 in den PC und der stöpselt dann ein
Microdrive-Image zusammen, das mit allen gängigen Emulatoren spielen
sollte.

Meine anfängliche Euphorie wurde schnell gedämpft, als frisch formatierte
Cartridges zwar astrein funktionierten (quasi als Integrationstest), es
bei altem Zeugs aber HDCHK-, DESCHK- und DCHK-Fehler hagelte. Wenn Du Dich
etwas mit den Interna des ZX Microdrive auskennst, sollten Dir de
Fehlerklassen ein Begriff sein.

Viel Vergnügen!

Drittens, damals wußte man es nicht besser, und besseres Material gab es
nicht bzw. es wäre prohibitiv teuer gewesen - was aufs gleiche
rauskommt. Heute weiß man es besser, das bessere Material gibt es, und
man kann es sich leisten.

Mmmmmh. Wenn Du es sagst...

Dumme Leute machen immer die gleichen Fehler. Kluge Leute machen immer
neue Fehler

Dann bin ich wohl irgendwo dazwischen angesiedelt, ich mache neue Fehler,
die sich dann bei Lichte betrachtet nur als alte Fehler im neuen Gewand
entpuppen.

Volker

 

[Hanno Foest]

Am 06.02.19 um 11:52 schrieb Volker Bartheld:

Man kann alles Ăźbertreiben, und man kann auch alles veralbern.

Kann man. Mir ist es aber todernst mit der Aussage. Du kamst IIRC mit der
Google-Statistik und hast sie auf das ResĂźmee "[...] more than 8% of DIMMs
affected by errors per year. [...]" verkürzt. Ich weiß nicht, ob die
Fehlerrate im Vergleich zu der von z. B. SSDs, Festplatten, Pfusch im
Chipset, usw. relevant ist und einen Handlungsbedarf erfordert.

Da bin ich mir einigermaßen sicher. "SSDs, Festplatten" ist mit RAID
abgefackelt, alle Transferbusse mit größeren Datendurchsatz haben
Checksummen, und bei "Pfusch im Chipset" verlasse ich mich mal drauf,
daß das andere eher als ich entdecken. Ist einer der Gründe, daß ich
kein brandneues Zeug kaufe (Preis und Linux-UnterstĂźtzung, die meist
etwas auf sich warten läßt, sind die anderen).

Ja, es gibt vermutlich Restrisiken, die ich nicht auf dem Schirm habe.
Und? Kein Grund, sich nicht gegen die Dinge zu schĂźtzen, die
bekannterweise vorkommen.

Es ist wie mit einer Versicherung: Bezahlt man den Aufwand nicht, hat man
mit einer gewissen Wahrscheinlichkeit später deutlich mehr Ärger.

Das stochastische Konzept des Erwartungswerts, ja. Kein Widerspruch. Leider
ist das mit dem "gefĂźhlten Erwartungswert", d. h. der menschlichen
Risikowahrnehmung dann schon wieder ein wenig anders. Ich bemĂźhe jetzt
bewußt nicht die allseits beliebten Rad- und Skihelme und wiege auch nicht
die Opfer der diversen Nuklearhoppalas, von Terrorismus, usw. gegen
Abtreibungen, Tote des motorisierten Individualverkehrs, Genußgifte und
Bewegungsarmut auf.

Das Digitalgerümpel hat den Vorteil, daß es bei der Frage nach Funktion
und Nichtfunktion wenig Grauzonen gibt. Ich arbeite im RZ-Umfeld und
weiß daher, was alles passieren kann, und ich weiß auch, was es für
Maßnahmen gibt, sich (wirksam!) davor zu schützen. Eine Risikoanalyse,
ob sich die Maßnahmen auch finanziell lohnen, hab ich nicht. Aber da der
finanzielle Einsatz sehr Ăźbersichtlich ist, mach ich das einfach.

Aber sagen wir, Du erleidest morgen einen tĂśdlichen Schlaganfall und
gesetzt die Hypothese, daß Du Dich nicht nur aus rein egoistischen Gründen
um die Integrität Deiner Daten sorgst, sondern, weil Du Werke geschaffen
hast, die Du ggfs. der Nachwelt erhalten willst. Gibt es das Paßwort für
Deine SystemvollverschlĂźsselung im Testament?

Mangels Testament hat ein Freund hat eine Passphrase, die ich in
unregelmäßigen Abständen abfrage...

Soll heißen: Du bist technisch affin, suchst und propagierst daher
technische LĂśsungen. Das umschreibt man gerne mit "Kaum, da ich einen
Hammer besitze, sieht fĂźr mich alles wie ein Nagel aus." und sei Dir
gegĂśnnt. Ob diese LĂśsungen im Gesamtkontext sinnvoll und angemessen oder
nur BauchgefĂźhl sind, kĂśnnte man diskutieren. Mich stĂśrt nur ein wenig die
Absolutheit Deiner Aussagen, die fast schon einen missionarischen
Charakter haben.

Manche Sachen sind mir selber auf den Fuß gefallen (defektes RAM),
andere anderen Leute zuerst (schlechte oder keinen Backups), weswegen
ich in der luxuriĂśsen Position war, aus den Fehlern anderer lernen zu
können. Probleme zu kennen und Gegenmaßnahmen zu propagieren ist
missionarisch? IBTD.

Dererei fordert natĂźrlich meinen Humor heraus, der Dir in
diesem Zusammenhang offenbar abgeht. Auch ein Indiz fĂźr missionarischen
Ehrgeiz.

Die Leute, denen ihre Daten flöten gegangen sind, fanden das großenteils
gar nicht lustig. Wie fandst du das mit deinen ZX Spectrum Bändern?

Man spottet ja, daß oft die ITler, die wissen, wie es richtig geht, die
schlechtesten Backups, OpSec etc. haben. Kann man machen, aber ich halte
das fĂźr Pfusch und gehe da lieber mit gutem Beispiel voran. Wie bei der
alten Regel zu Umgangsformen "Benimm dich zu Hause, als wenn du beim
Kaiser wärst. Dann kannst du dich beim Kaiser benehmen, als wenn du zu
Hause wärst." Ist außerdem eine gute Fingerübung.

Ich halte es jedenfalls fĂźr keinen Fehler und auch nicht sinnvoll
kritisierbar (humoristisch oder anderswie), nicht nur zu sagen, wie man
es richtig macht, sondern auch zeigen zu können, daß es mit geringem
finanziellen Mehraufwand praktikabel ist. Damit Leute, die das lesen,
das nicht als viel zu kompliziert, teuer und unpraktikabel abtun und
daher weiter vor sich hinpfuschen bis zum Daten-GAU. Wenn sie in
Kenntnis aller Optionen und Gefahren trotzdem der Meinung sind, daß ihre
Zeit und/oder ihre Daten den Mehraufwand nicht wert sind, ist das
natĂźrlich ihre Entscheidung.

Hanno

 

[Hanno Foest]

Am 06.02.19 um 13:55 schrieb Volker Bartheld:

Auf "gurkigem RAM" archiviert(!) man aber auch nicht "größere Mengen von
Geschäftsdaten" usw., außer, Du willst auf die Spitzfindigkeit hinaus,
Flash-Speicher erlaube ebenfalls wahlfreien Schreib-Lesezugriff. Ich kann
Dir nicht sagen, welche Crashes und nicht mehr lesbaren Dateien und mithin
Mannstunden auf das Konto von "gurkigem RAM" in meinem Homecomputer gingen,
einfach, weil ich es nicht weiß.

Ich kann auch keine Abschätzung bieten, weil ich nicht weiß, wie und
womit du gearbeitet hast und wobei genau eventuelle Fehler auftraten. Da
ich Sinclair-Hardware recht gut kenne, würde ich vermuten, daß für die
meisten Crashes ein wackeliger Edge-Connector verantwortlich sein
dĂźrfte, gefolgt von einem wackeligen Stromversorgungsstecker. RAM?
Unklar - ich hab hier Geräte, die laufen wochenlang tadellos.

Meine ähnlich alten Audiocassetten hÜren sich ja auch noch gut an.

Das ist ein niedliches Argument. Du jagst eine "Datei" durch ein
intelligentes, psychoakustisches Expertensystem, das eine Datenbandbreite
von vielleicht 16kHz besitzt und als Filter obendrauf noch die
Erwartungshaltung an ein mit ferromagnetischem Material beschichtetes
Stßckerl Plastik, das mit ungefähr 4cm pro Sekunde an einem Tonkopf
vorbeischleicht. Das vergleichst Du mit einem obskuren Konglomerat
diskreter Hardware, das aus ein paar Widerständen, Dioden, Kondensatoren
und einem Spezialchip besteht, dessen genaue Funktion bis heute nicht
restlos geklärt ist und schon damals nicht gerade fßr seine
Zuverlässigkeit berßhmt war.

Im Gegensatz zum ZX81 hab ich das ZX Spectrum Tape-Interface als
durchaus sehr zuverlässig in Erinnerung. Vielleicht ist das ja ein Teil
des Problems: Wenn du damals schon grenzwertig aufgenommen hast, ist die
Qualität der Aufzeichnung auch durch lediglich geringe Alterung
vielleicht aus den knappen Toleranzgrenzen herausgedriftet.

Ansonsten wird das Alterungsverhalten von Bandaufzeichungen so seit den
30er Jahren des letzten Jahrhunderts erforscht und ist im Wesentlichen
gutmĂźtig: Die hohen Frequenzen leiden, es gibt Dropouts und
Durchkopieren - die letzteren beiden Probleme aber eher bei schlechtem
Bandmaterial (grobe Fehler wie sich ablösende Beschichtung mal außen
vor). Das Gesamtsystem ist Ăźbersichtlich, die Bauteile im Spectrum haben
sich in den letzten 30 Jahren nicht geändert. Etwaige Probleme wßrde ich
eher in der Mechanik suchen.

Ich wĂźrde sagen, Du probierst es einfach mal aus. WĂźrde mich brennend
interessieren und "geht auf dem ZX Spectrum besser einzulesen als mit
96kHz-Abtastung, PC-Soundkarte und forensischer Software" wäre fßr mich
echt erstaunlich.

Mach ich glatt. Wozu hab ich mein Tapedeck erst kĂźrzlich Ăźberholt...
brÜselnde Zahnräder, bäh.

Dem rasenden SchnĂźrsenkel (Microdrive) dagegen hab ich nie wichtige Daten
anvertraut und war eher überrascht, daß das nach 10 Jahren noch lesbar
war (ist jetzt aber auch schon ne Weile her, ich werde da auch noch mal
mit Filztausch aus RetrocomputinggrĂźnden experimentieren).

Auch hier sieht meine Praxiserfahrung anders aus und ich lade Dich herzlich
ein, es mal mit mdv2img (s. http://www.worldofspectrum.org/pub/sinclair/tools/pc/mdv2img.zip)
zu versuchen. Die Software ist zweilig, der Z80-Assemblercode pumpt die
Daten vom Microdrive via RS232 in den PC und der stĂśpselt dann ein
Microdrive-Image zusammen, das mit allen gängigen Emulatoren spielen
sollte.

Ich hab jetzt seit längerer Zeit die Cartridges nicht mehr getestet und
muß erst mal nach geeignetem Filz-Ersatz-Material suchen, da das
AndruckgedĂśns schon rein optisch nicht mehr gut aussieht. Urs KĂśnig (in
der QL Welt bekannt) sagte mir, er habe mit MĂśbelfilzen gute Erfahrungen
gemacht, aber das scheint mir zu grob... er konnte jedenfalls seinen
Kram noch lesen.

Meine anfängliche Euphorie wurde schnell gedämpft, als frisch formatierte
Cartridges zwar astrein funktionierten (quasi als Integrationstest), es
bei altem Zeugs aber HDCHK-, DESCHK- und DCHK-Fehler hagelte. Wenn Du Dich
etwas mit den Interna des ZX Microdrive auskennst, sollten Dir de
Fehlerklassen ein Begriff sein.

Wie gesagt, Urs KĂśnig hat seinen Kram auch ohne KlimmzĂźge nach
Filztausch lesen können. Und irgendwo hab ich gesehen, daß jemand mit
einem USB Logic Analyzer (Salae oder kompatibel) die Daten vom
Microdrive komplett mitgeschnitten und hinterher analysiert hat. Mal
schaun, ob ich das wiederfinde.

> Viel VergnĂźgen!

Danke

Hanno

 

[Ralph A. Schmid, dk5ras]

Hanno Foest <hurga-news2@tigress.com> wrote:

Ja, und wir schmeißen die eh weg, das Handling, um die billigen Dinger
tauschen zu lassen, kostete ein Vielfaches des Warenwertes.

Das, was hier liegt, sind IIRC über 100 EUR NP. Mag sein, daß sich die
Garantieabwicklung für eine Firma nicht lohnt - ich als Privatmensch
sehe das etwas anders.

Neee, so teuer sind die Riegel hier nicht, irgendwas harmlos
Zweistelliges. Wie gesagt, RMA ausfüllen, Papierkram, eintüten,
wegschicken, wäre alles teurer.


-ras

--
Ralph A. Schmid +49-171-3631223 +49-911-21650056
http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/

 

[Axel Berger]

Hanno Foest wrote:
> ein Freund

Vermutlich in Deinem Alter und Dich halte ich nicht für viel jünger als
mich selbst.

--
/Ż\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

 

[Hanno Foest]

Am 06.02.19 um 17:28 schrieb Axel Berger:

ein Freund

Vermutlich in Deinem Alter und Dich halte ich nicht fĂźr viel jĂźnger als
mich selbst.

IIRC ist besagter Freund 8 Jahre jĂźnger, und ich bin 51. Das reicht
erstmal, denke ich. Wobei ich nicht glaube, daß an meinem Datenbestand
so viel interessant fĂźr andere sein kĂśnnte. Wenn sie in dem Sammelsurium
Ăźberhaupt was finden...

Hanno

 

[Volker Bartheld]

On Wed, 6 Feb 2019 15:02:04 +0100, Hanno Foest wrote:

Am 06.02.19 um 13:55 schrieb Volker Bartheld:
[Alte Sinclair ZX Spectrum Tapes laden, weil]
Meine ähnlich alten Audiocassetten hören sich ja auch noch gut an.
Im Gegensatz zum ZX81 hab ich das ZX Spectrum Tape-Interface als durchaus
sehr zuverlässig in Erinnerung. [...] Wenn du damals schon grenzwertig
aufgenommen hast, ist die Qualität der Aufzeichnung auch durch lediglich
geringe Alterung vielleicht aus den knappen Toleranzgrenzen
herausgedriftet.

Möglich. Tatsächlich hörte sich das Zeugs (nach der unvermeidlichen
Azimutkorrektur) durchaus brauchbar an, die via DIN-Stecker und Line-In
der Audiochipsatzes erzeugten Samples waren nicht übersteuert und
eigentlich recht schön sinusförmig, so wie ich das auch erwartet hatte.
Zuspieler war natürlich nicht irgendein Akai DX-57, ein Technics RS BX626
oder wenigstens ein Onkyo TA 2630 was damals wohl als Gold- bzw.
Silberstandard galt, sondern ein Grundig RR 280 aus dem Radiomuseum
(https://www.radiomuseum.org/r/grundig_rr_280.html). Auch nicht zu
schäbig.

Trotzdem hatte tzxwav, das durchaus einigen Aufwand bei der Rekonstruktion
betreibt (s. auch
https://shred.zone/cilla/page/393/recovering-old-zx-spectrum-tapes-part-2.html)
seine liebe Not mit dem Zeugs, Alternativen (z. B.
http://ramsoft.bbk.org.omegahg.com/maketzx.html) haben vollkommen versagt.
Da kann ich gleich Lottozahlen ziehen.

Ansonsten wird das Alterungsverhalten von Bandaufzeichungen so seit den
30er Jahren des letzten Jahrhunderts erforscht und ist im Wesentlichen
gutmütig: Die hohen Frequenzen leiden, es gibt Dropouts und
Durchkopieren - die letzteren beiden Probleme aber eher bei schlechtem
Bandmaterial (grobe Fehler wie sich ablösende Beschichtung mal außen
vor). Das Gesamtsystem ist übersichtlich, die Bauteile im Spectrum haben
sich in den letzten 30 Jahren nicht geändert.

Naja, was soll ich sagen... Irgendworan wirds wohl gelegen haben.

ich lade Dich herzlich
ein, es mal mit mdv2img (s. http://www.worldofspectrum.org/pub/sinclair/tools/pc/mdv2img.zip)
zu versuchen. Die Software ist zweilig, der Z80-Assemblercode pumpt die
Daten vom Microdrive via RS232 in den PC und der stöpselt dann ein
Microdrive-Image zusammen, das mit allen gängigen Emulatoren spielen
sollte.

Ich hab jetzt seit längerer Zeit die Cartridges nicht mehr getestet und
muß erst mal nach geeignetem Filz-Ersatz-Material suchen

Die Filze würde ich nicht ersetzen, nur den schwammförmigen Schaumstoff
untendrunter. Da nimmst Du https://www.amazon.de/dp/B002ZXWUEY oder
irgendwas Ähnliches und klebst damit den Filz wieder fest. Die Reinigung
der Andruckfeder (speziell die frühere, dünnere Variante) ist etwas
frickelig, ebenso das Unterfangen aus Schaumstoffklebeband-Rollenware
kleine Klötzchen zu schneiden und mittig festzukleben, aber mit einem
scharfen Skalpell und spitzer Pinzette geht das recht gut. Leuchtlupe und
3. Hand aus dem Lötzubehör kann natürlich nicht schaden.

Urs König (in der QL Welt bekannt) sagte mir, er habe mit Möbelfilzen
gute Erfahrungen gemacht, aber das scheint mir zu grob...

Viel zu grob. Das 3M-Zeugs ist um Längen besser, es gibt keinen Grund den
Filz selbst zu tauschen.

Wie gesagt, Urs König hat seinen Kram auch ohne Klimmzüge nach
Filztausch lesen können. Und irgendwo hab ich gesehen, daß jemand mit
einem USB Logic Analyzer (Salae oder kompatibel) die Daten vom
Microdrive komplett mitgeschnitten und hinterher analysiert hat. Mal
schaun, ob ich das wiederfinde.

Ich habe die Cartridges alle aufgehoben und sicher drei Microdrives
gebunkert, weiteren Experimenten steht deswegen nichts im Wege.

Volker

 

[Rupert Haselbeck]

Gerrit Heitsch schrieb:

Der eigentliche Mehraufwand ist 1/8 beim RAM-Preis weil man 9 statt 8
RAM-Chips braucht. Der Rest ist schon vorhanden aber abgeschaltet.

Ja

Auswirkungen eines RAM-Fehlers? Tja, von gar keinen weil in einem
unbenutzten Teil des RAMs zu teurem Hardwareschaden weil extern
angeschlossene Hardware falsch angesteuert wird. Selbst in der
Buchhaltung bei den Excel-Experten kann so ein RAM-Fehler teuer werden
wenn damit eine Zahl an der falschen Stelle verfälscht wird. Wenn man es
nur immer vorher wĂźsste...

Eben!
Genau darum geht es. Man kann demnach nicht das von manchem so beliebte
Pauschalurteil zum Besten geben, wonach ausschliesslich ECC-RAM sinnvoll
sein kÜnne. Es hängt von einigen Faktoren ab, ob das nun lediglich nett,
sinnvoll oder auch zwingens erforderlich ist. Wenn die Auswirkungen eines
RAM-Fehlers vernachlässigbar sind, dann kann man keinen Cent mehr in das
Gerät stecken, wenn es dabei um Consumerware geht, die gewinnbringend
verkauft werden soll. Ansonsten macht der Konkurrent, der sinnvoller mit den
Ressourcen umgeht, das Geschäft.
Umgekehrt muss man natßrlich alle gängigen Absicherungen implementieren,
wenn ein unbemerkter Fehler im Datenpfad oder irgendeiner Art von Speicher
zu Beschädigungen, zu Verletzungen oder Schlimmerem, oder auch (nur) zu
finanziellen Verlusten fĂźhren kann.
Da ist vielfach nicht der Ingenieur gefragt, der solche Fragen häufig nicht
zu klären vermag, weil es kein technisches Problem ist und dem der nÜtige
wirtschaftliche Sachverstand oft fehlen wird. Es braucht hier den
Haushälter, den Controller, den "doofen" BWLer. Und am Besten funktioniert
es, wenn beide gedeihlich zusammenwirken

MfG
Rupert

 

[Gerrit Heitsch]

On 2/6/19 7:20 PM, Rupert Haselbeck wrote:

Gerrit Heitsch schrieb:

Der eigentliche Mehraufwand ist 1/8 beim RAM-Preis weil man 9 statt 8
RAM-Chips braucht. Der Rest ist schon vorhanden aber abgeschaltet.

Ja

Auswirkungen eines RAM-Fehlers? Tja, von gar keinen weil in einem
unbenutzten Teil des RAMs zu teurem Hardwareschaden weil extern
angeschlossene Hardware falsch angesteuert wird. Selbst in der
Buchhaltung bei den Excel-Experten kann so ein RAM-Fehler teuer werden
wenn damit eine Zahl an der falschen Stelle verfälscht wird. Wenn man es
nur immer vorher wĂźsste...

Eben!
Genau darum geht es. Man kann demnach nicht das von manchem so beliebte
Pauschalurteil zum Besten geben, wonach ausschliesslich ECC-RAM sinnvoll
sein kÜnne. Es hängt von einigen Faktoren ab, ob das nun lediglich nett,
sinnvoll oder auch zwingens erforderlich ist. Wenn die Auswirkungen eines
RAM-Fehlers vernachlässigbar sind, dann kann man keinen Cent mehr in das
Gerät stecken, wenn es dabei um Consumerware geht, die gewinnbringend
verkauft werden soll.

Wobei es interessant ist, daß an allen andere Stellen entweder mit ECC
(CPU-Caches) oder Checksummen (PCIe, SATA, TCP/IP...) gearbeitet wird.
Nur beim RAM verlässt man sich auf 'wird schon gutgehen'.

Da ist vielfach nicht der Ingenieur gefragt, der solche Fragen häufig nicht
zu klären vermag, weil es kein technisches Problem ist und dem der nÜtige
wirtschaftliche Sachverstand oft fehlen wird. Es braucht hier den
Haushälter, den Controller, den "doofen" BWLer. Und am Besten funktioniert
es, wenn beide gedeihlich zusammenwirken

Das Problem wird dann eines wenn der Ingenieur sagt 'das muss aber so
weil...' und der Controller trotzdem ablehnt. Gehts dann schief hats ja
keiner ahnen kĂśnnen.

Gerrit

 

[Hanno Foest]

Am 06.02.19 um 19:20 schrieb Rupert Haselbeck:

Genau darum geht es. Man kann demnach nicht das von manchem so beliebte
Pauschalurteil zum Besten geben, wonach ausschliesslich ECC-RAM sinnvoll
sein kĂśnne.

Sagen wir mal so: Ich kenne nur sehr wenige Fälle, in denen es sinnvoll
sein kĂśnnte, nicht mit mĂśglichst hoher Konfidenz die Werte aus dem RAM
zurĂźckzubekommen, die man mal reingeschrieben hat.

Es hängt von einigen Faktoren ab, ob das nun lediglich nett,
sinnvoll oder auch zwingens erforderlich ist. Wenn die Auswirkungen eines
RAM-Fehlers vernachlässigbar sind, dann kann man keinen Cent mehr in das
Gerät stecken, wenn es dabei um Consumerware geht, die gewinnbringend
verkauft werden soll.

Das ist die eine Perspektive - im Sinne der Gewinnerzielung des
Verkäufers ist es natßrlich, mÜglichst billigen Dreck zu verkaufen, der
so dysfunktional sein mag wie er will, solange es noch gerade nicht zu
rechtlichen Ansprßchen des Kunden gegen den Händler reicht (gelobt sei
hier das Fernabsatzgesetz). Ob das auch im Sinne des Kunden ist wage ich
allerdings zu bezweifeln.

Nun ist es sicherlich so, daß bei einem beispielsweise als Daddelkiste
genutzen Rechner die Daten, die morsches RAM vernichten kĂśnnte,
entbehrlich sind (konstruierte Beispiele wie ein Crash 10 Sekunden vor
Gewinn der E-Sport-Weltmeisterschaft mal außen vor). Falls dem Gamer die
Abstßrze auf Dauer lästig werden, kann er allerdings lediglich entweder
zeitaufwendig Fehler suchen, oder die unzuverlässige Kiste als ganzes
wegwerfen und neu kaufen - und da stellt sich dann auch bei weniger
wichtigen Daten beim Kunden die Frage nach der Wirtschaftlichkeit.

Nicht, daß ich Gamern zu ECC-RAM raten würde - soweit ich mich recht
erinnere, taktet nicht-ECC-RAM hĂśher und das ist denen im Zweifelsfall
wichtiger.

Hanno

 

[Hergen Lehmann]

Am 06.02.19 um 19:47 schrieb Hanno Foest:

Genau darum geht es. Man kann demnach nicht das von manchem so beliebte
Pauschalurteil zum Besten geben, wonach ausschliesslich ECC-RAM sinnvoll
sein kĂśnne.

Sagen wir mal so: Ich kenne nur sehr wenige Fälle, in denen es sinnvoll
sein kĂśnnte, nicht mit mĂśglichst hoher Konfidenz die Werte aus dem RAM
zurĂźckzubekommen, die man mal reingeschrieben hat.

Sehr viele solche Fälle liefert der gesamte Entertainment-Sektor.

Es ergibt wenig Sinn, zusätzliches Geld in ECC-RAM zu investieren, nur
weil mit einer gewissen Wahrscheinlichkeit alle x Monate ein
zusätzliches MPEG-KlÜtzchen oder ein kleiner Texturfehler auf dem Schirm
erscheinen kĂśnnte. Ja, das Bit kann blĂśderweise auch mal im Code kippen,
aber da dieser vergleichsweise klein ist, ist die Wahrscheinlichkeit
entsprechend gering.

Tatsächlich kann ECC-RAM in diesem Umfeld sogar kontraproduktiv sein,
weil bei nicht korrigierbaren Fehlern das System hart angehalten wird,
statt nur einen harmlosen Bildfehler zu riskieren.

Hergen

 

[Gerrit Heitsch]

On 2/6/19 8:23 PM, Hergen Lehmann wrote:

Am 06.02.19 um 19:47 schrieb Hanno Foest:

Genau darum geht es. Man kann demnach nicht das von manchem so beliebte
Pauschalurteil zum Besten geben, wonach ausschliesslich ECC-RAM sinnvoll
sein kĂśnne.

Sagen wir mal so: Ich kenne nur sehr wenige Fälle, in denen es
sinnvoll sein kĂśnnte, nicht mit mĂśglichst hoher Konfidenz die Werte
aus dem RAM zurĂźckzubekommen, die man mal reingeschrieben hat.

Sehr viele solche Fälle liefert der gesamte Entertainment-Sektor.

Es ergibt wenig Sinn, zusätzliches Geld in ECC-RAM zu investieren, nur
weil mit einer gewissen Wahrscheinlichkeit alle x Monate ein
zusätzliches MPEG-KlÜtzchen oder ein kleiner Texturfehler auf dem Schirm
erscheinen kĂśnnte. Ja, das Bit kann blĂśderweise auch mal im Code kippen,
aber da dieser vergleichsweise klein ist, ist die Wahrscheinlichkeit
entsprechend gering.

Tatsächlich kann ECC-RAM in diesem Umfeld sogar kontraproduktiv sein,
weil bei nicht korrigierbaren Fehlern das System hart angehalten wird,
statt nur einen harmlosen Bildfehler zu riskieren.

Was du bei nicht korrigierbaren Fehlern machst bleibt deiner Software
Ăźberlassen, es ist nicht Pflicht eine Systempanic hinzulegen.

Aber ja, bei einem Mediaplayer ist das nicht so das Problem. Der gibt
Ăźblicherweise nur Daten wieder die woanders noch existieren.

Gerrit

 

[Hanno Foest]

Am 06.02.19 um 20:23 schrieb Hergen Lehmann:

Sagen wir mal so: Ich kenne nur sehr wenige Fälle, in denen es
sinnvoll sein kĂśnnte, nicht mit mĂśglichst hoher Konfidenz die Werte
aus dem RAM zurĂźckzubekommen, die man mal reingeschrieben hat.

Sehr viele solche Fälle liefert der gesamte Entertainment-Sektor.

Verschmerzbar ist was anderes als sinnvoll, und Gaming (ebenfalls
Entertainment) nannte ich ja bereits selber. Sinnvoll wäre es vielleicht
da, wo man einen sehr schlechten Zufallsgenerator bauen mĂśchte.

Tatsächlich kann ECC-RAM in diesem Umfeld sogar kontraproduktiv sein,
weil bei nicht korrigierbaren Fehlern das System hart angehalten wird,
statt nur einen harmlosen Bildfehler zu riskieren.

Ob du anhältst oder sonstwas machst ist dir ßberlassen. Wobei ich nicht
glaube, daß ein System, was nichtkorrigierbare Fehler wirft, noch lange
läuft, selbst wenn man es ließe.

Hanno