[OT][Rant] Sympathie für RPi-Hasser

Dir ist aber schon klar, daß es ein Dutzend unterschiedlicher Bauformen/ Versionen dieser Kiste gibt?

Joseph

Also, ich hab bestimmt 1000 mal weniger Erfahrung mit Linux als der Durchschnitt hier, aber eine Lieblingsfalle habe ich früh kennengelernt, daher mal die ganz doofe Frage: Daß Du Dir die angemessenen Rechte zum Schreiben in der fraglichen Umgebung eingerichtet hast, ist sicher kein Thema, oder?

Gruß, U.

Wieso ist das eine Falle? Erfahrungswert (sicher nicht nur meiner aus inzwischen ~ 4 1/2 Jahren Linux): Wenn irgendwas "nicht (richtig) geht", liegt's zu gefühlten 90% an "falschen" oder fehlenden Rechten.

Eine Falle kann ja auch zum Wohnsitz werden ... ;)

Some people repeat the same mistake for twenty years and call that experience.

Gruß, U.

Am 11.11.2013 22:56, schrieb Ulrich G. Kliegis:

Das sollte normalerweise sofort beim Schreibversuch sichtbar werden. Vor vielen Jahren hatte ich einen alten Schlepptop an der Telefonanlage zur Konfiguration und Protokollierung dran. Lief auch wunderbar, aber irgendwann startete der mal neu und dann hatte ich beim draufgucken auf die Platte ein Deja-Vu-Erlebnis: Alle Dateien waren alt, die vor wenigen Tagen noch dagewesenen Protokolle: weg. WTF? Ich konnte das dann soweit rekonstruieren das wohl irgendwann der flush-daemon gestorben ist und der Rest der Änderungen am Dateisystem nicht mehr persistent gespeichert wurde.

Bernd

--
Meine Glaskugel ist mir leider unvorhersehbarerweise vom Balkon gefallen. 
P.Liedermann in defa

In dem ich mich seit geraumer Zeit (richtig "eingerichtet") entschieden wohler fühle als unter dem "Konsumterror" vom B.Ga?es@M$.com. ;

Am 12.11.2013 10:56, schrieb Bernd Laengerich:

Nicht unbedingt, zumindest nicht die Ursache. Z.B. dass User Anton nicht wie erforderlich Mitglied der Gruppe Berta ist, kann sich je nach dem Programm, das sich darauf "verlässt", auf sehr unterschiedliche Weise bemerkbar machen ...

Ulrich G. Kliegis schrieb:

Genau, aus Fehlern lernen heißt, daß man sie wiedererkennt, wenn man sie das nächste mal macht.

Marc

Am 12.11.2013 15:41, schrieb Marc Santhoff:

Naja, wenn man dann wenigstens erkennt, dass man nichts gelernt hat, ist ja noch nicht alles verloren. ;)

P

Das stimmt nur fast. Die Adresse physikalische 20-Bit-Adresse ist tatsächlich 000C0, allerdings liegt dort der Interrupt-Vektor 30h. Der FAR-JMP-Befehl ist 5 Byte groß, und erstreckt sich bis in den In terrupt

31h. Die hier genannten Interrupts 24h, 25h und 26h gehören wie der ganze 2x-Bereich zum DOS-Interface. Konkret ist 24h ein Callback, der bei einem schwerwiegenden Hardwarefehler ("Datenfehler beim Lesen von Laufwer k A, Wiederholen, Abbrechen, Ignorieren, Fehler") ausgeführt wurde, un d genannte 4 Aktionen durch einen Rückgabewert signalisiert, 25h und 2 6h wurden im Zugriff auf die Diskette auf Sektor-Basis am Dateisystem vorbei verwendet, und haben sich von der Aufrufkonvention wie FAR-Unterfunktione n und nicht wie Interrupts verhalten, was zu zwei Bytes Müll auf dem S tack bei primitivem Aufruf mit dem INT-Opcode geführt hat.

(A20)

Das kann so nicht stimmen. Der AT hat einen eigenen uC in der Tastatur, und die Status-LEDs werden über ein serielles Kommandoprotokoll gest euert. Der Keyboard-Controller auf dem Mainboard hat also keine Digitalausgä nge für CAPS, NUM und SCROLL.

Der XT zwar hat auf dem Mainboard statt eines uC ein diskretes Keyboard-Interface, was um einen Intel 8255 aufgebaut ist, der auf Port A den letzten Scan-Code liefert (da ist dann wohl ein externes Schieberegister, und auf Port B Steuerbits (z.B. Speaker on/off und Gate für den zugeordneten Timer) ausgibt, aber auch hier werden die LEDs nicht vom I/O-Baustein auf dem Mainboard gesteuert, sondern sind komplett Tastatur-Intern. Wer auf einem PC/XT in einem Spiel mit eigener Tastatur-Behandlung auf Caps-Lock drückt, schaltet die LED in der Tastatur um, ohne dass das BIOS seinen Status aktualisiert, und bis zum nächsten Reset ist die LED dann invertiert.

Gruß, Michael Karcher