[linux-l] Quoting und so

[Steffen Dettmer]

* Norman Steinbach wrote on Sat, Dec 16, 2006 at 21:37 +0100:
> Steffen Dettmer wrote:
> 
> Aber es ist doch NACH der Reihe an >>>>en ein Leerzeichen, also zwischen
> >>> und Text gibts eins - reicht das nicht? Klar, dass es GANZ ohne
> leerzeichen scheiße aussieht - aber wofür die Platzverschwendung,
> > > hinter
> > jedem
> > > > Quotingzeichen ein Leerzeichen zu machen - das erschwert IMHO wie
> > bereits
> > > > gesagt die Lesbarkeit des Textes wegen der vielen unnötigerweise
> > eingefügten
> > > > Zeilenumbrüche extrem!
> >>> während es so wie in diesen 2 Zeilen schön und einfach erkennbar,
> >>> sozusagen "perfekt" ist ;-)
> 
> Das nur mal als Beispiel...

Für mich ist das Beispiel oben einfach nur KAPUTT. Da stimmt doch
wirklich überhaupt nix.

> Theoretisch gibt es dann also als Unterfall von ">" noch zwei weitere
> Fälle, nämlich einmal ">>>Text", und einmal ">>> Text". Dass ersteres
> ebensolcher Bullshit ist wie "> > > > Text", ist klar.

Ich würde "> > > > Text" nicht als "Bullshit" sondern als "korrekt"
bezeichnen :)

> > Die neue Zeile hat doch genau die übernommenen "> " Zeichen, da muss
> > doch nix geändert werden?
> Außer, sie ist durch den Zeilenumbruch bzw. den zuvor weggenommenen
> (weil durch Quoting "verschobenen") Zeilenumbruch nun nochmal am Ende
> umgebrochen.

(versteh ich nicht, aber ist ja auch egal. Beim Umbrechen muss der
Editor natürlich die korrekte Anzahl von Quoting-Zeichen wiederholen).

> > Kenne nix, was sowas kann. Kann mir auch nicht vorstellen, wie man das
> > Unterscheiden möchte - man weiss ja nicht, ob umgebrochen wurde, weil zu
> > breit oder weil der Autor das extra wollte.
> 
> Ja, dafür müsste vor dem Quoten die Mail einmal durchsucht werden und
> der Algo sich dann merken, wo die Umbrüche die auch schon vorher da
> waren dann sitzen.

Das geht nicht. Man kann nicht unterscheiden, welche Umbruch "hart" und
gewollt und welcher "weich" und automatisch "gemeint" ist.

> >> dieselbe anzahl an ">"- bzw. "> "-Zeichen handelt (Die IMHO unnötigen
> >> Leerzeichen vor dem letzten ">" in jeder Zeile werden natürlich
> >> gelöscht, wenn sie vorhanden sind)
> > mmm... Löschen? mmm... Ich hab die gerade mit Finden/Ersetzen wieder
> > "repariert" ... :)
> Was bin ich so froh, dass das Mnenhy-Plugin bei SeaMonkey mir diese
> "Reparatur" abnimmt: 

(Das Beispiel oben ist so kaputt, dass man meinen möchte "schmeiss es
weg, Dein Plug-In, es taugt nicht!" lol)

> Wie man sieht, nur perfektes Quoting: Keine unnötigen Leerzeichen
> zwischen den einzelnen Quote-charakters, 

Doch, die Leerzeichen sind korrekt vorhanden. Falls Du sich nicht
wolltest (was an sich falsch wäre), noch ein Bug im Plug-In?

> > Aber so entsteht doch ein schön "flüssiger" Text, oder?
> Flüssig wäre er dann, wenn mit Leerzeilen möglichst sparsam umgegangen
> würde, eben z.B. keine zwischen Zitat & Antwort und eine (völlig
> ausreichend bei keiner zwischen Zitat&Antwort) unter der Antwort/vorm
> nächsten Zitat.

Meiner Erfahrung nach beschleunigen gut gesetzte Leerzeilen die
Lesegeschwindigkeit und reduzieren Verwirrung. Für das "extensive" Lesen
("überfliegen"), wenn man z.B. nur mal gucken möchte, ob was
interessantes dabei ist oder so, sind Leerzeilen sehr hilfreich: man
liest nach jeder Leerzeile eine Zeile an. Das macht ein geübter Leser
ganz unbewusst. Funktioniert mit Farben nicht so gut. Leerzeilen trennen
optisch, Farbwechsel nicht wirklich.

(alles meine Meinung, bin aber kein Druck/Medientechniker :))

> > Na ja, in der aktuellen SelfLinux-Version scheint jedenfalls kein Index
> > drin zu sein.
> 
> ...was mir absolut unverständlich ist, denn schließlich wäre ein solcher
> das absolute Killerfeature, was die freie Auswahl der Nutzer des
> Dokuments anbelangt, welchen Teil sie davon nun lesen möchten.

Ja, mir war das und diverse andere Sachen auch unverständlich - sonst
wäre ich vielleicht auch im Projekt geblieben :)

> > Analog dazu hätte man eine Glossary machen können und (halb)
> > automatisch Worte an Textstellen auf diese verlinken können.
> > Irgendwie hat das wohl nicht so geklappt; naja.
> 
> Index & Glossar, ja, das wären 2 absolut notwendige Dinge die ich an
> einer Dokumentation haben wollen würde. Damit wäre wahrscheinlich auch
> schon das meiste abgedeckt, was ich an "sonderwünschen" haben könnte
> ;-)

Ja, Index & Glossar sollte man wirklich haben, finde ich auch. Beides
nicht einfach zu machen, darf man nicht unterschätzen, aber wichtig und
hilfreich.

> >> Die "Handvoll Befehle" sind ja nur der Anfang, bzw. wenn man dann vom
> >> schwierigkeitsgrad her tiefer in die materie einsteigt, wirds ja
> >> automatisch mehr. 
> > Na ja, aber dann wird's schnell schwierig mit "Aufgabenorientiertheit"
> > weiter zu kommen, glaub ich.
> 
> Wieso? Aufgabenorientiert, sortiert nach Häufigkeit der benötigten
> Aufgaben - wo ist das Problem?

/Das/ ist das Problem. Ist ein LVM auf RAID1 häufiger als RAID5 auf LVM?
Oder ist LVM gar selten? Vielleicht erstmal Hardware-Raid? Nee,
rsync-Backup, oder? Moment, warum nicht erstmal CVS für die wichtigen
Dateien. Besser RCS, ist allgemeiner und geht als root. Aber nimmt man
heute noch RCS? 

na, und so weiter. Da kannste zu jeder "häufigen" Aufgabe ein prima
Gegenbeispiel finden und endlos diskutieren.

> > oder ein Wiki? Ich glaube, da gibt es sogar einige solcher Projekte.
> Ja, ein Wiki böte sich hierfür fast optimal an. Das einzige, was dann
> noch fehlen würde, wäre eine entsprechende Gliederung (ich habe
> zumindest noch nie bewusst ein Wiki mit Gliederung wahrgenommen) 

de.wikipedia.org

> und eine entsprechende "information review", so dass nicht jeder
> sonstwas da reinschreiben kann.

Warum kann nicht jeder schreiben?

> Wenn ein Compile-Vorgang mit einem "make" getan ist, wie kann dann die
> Einrichtung sonderlich schwerer sein? 

Weil man für die Einrichtung einer Datenbank beispielsweise viele SQL
oder sonstige Kommandos verwenden muss, sich mit Zeichensätzen rumärgern
muss usw. 

http://www.selflinux.org/selflinux/html/postgresql02.html:

"Übersetzen und Installieren" ist gaaaanz kurz.  Dann kommt
Grundkonfiguration mindestens viermal so lang, ach, reicht nicht, aber
die eigentliche Einrichtung ist im Kapitel "Administration" an vielen
Stellen beschrieben.

Schon allein die Konfigurationsdatei kennt viel mehr Optionen als
"configure" :-)

> Mit "selbst compilen" meinte ich natürlich auch das entsprechende
> Wissen, um auch änderungen am Code vornehmen zu können 

Warum das denn?! Man muss doch nicht Informatik studieren, um Linux
verwenden zu können...

(wobei es auch davon abhängt, was man mit "Änderungen vornehmen
*können*" genau meint)

> - ansonsten wäre "Compilen" natürlich als Trivial anzusehen. Das ist
> z.B. etwas, was ich von einer Lösungsorientierten Dokumentation
> erwarte: Dass sie bei solchen "Anforderungsprofilen" keinen
> Unterschied zwischen "Compilen" und "Coden" macht. 

Eine Applikationsdokumentation sollte IMHO überhaupt nicht auf
Softwareentwicklung, Projektmanagement und Unternehmensführung eingehen,
weil das gar nichts damit zu tun hat!

Ich erwarte doch von "man ls" nicht, das es beschreibt, wie ich eigene
Sortierungsoptionen implementieren könnte!

> Sprich: Wer "Compilen" lernen will/muss, muss dafür auch "Coden"
> lernen/können, ansonsten wäre es bullshit, überhaupt den make-befehl
> zu erläutern.  

Diese Ansicht teile ich nicht.

> > Aber eigentlich ist es komisch. Es gibt viel Dokumentation zu
> > Linuxgeschichten. Gerade Einsteigerdoku ist doppelt und dreifach
> > vorhanden. Also, eher zehn oder hundertfach. Aber Autoren für so
> > "mehrschichtige Texte" zu finden (was ja nicht nur Texte und nicht nur
> > Hypertexte, sondern Texte mit Sichten sind!), ist scheinbar schwierig.
> 
> Auch hier wieder mein geliebter Hinweis auf das "SNAFU-Prinzip"...

(Was Phänome in der Kommunikation zwischen Hierarchiestufen mit
mehrfach-redundanter Dokumentation zu tun?)

> > Denkbar wäre ja auch ein Tutorial-Lernprogramm. Da kann man dann üben,
> > wie man meinetwegen Christina Aguilera Lieder findet, auch wenn man sich
> > nicht sicher ist, ob sie sich mit q oder g schreibt oder so. Sieht z.B.
> > aus wie ne Shell, sagt aber richtig oder falsch und kann Hinweise geben
> > - oder irgendsowas.
> 
> Ja, das wäre sicherlich einerseits ganz praktisch, andererseits wage ich
> aber zu bezweifeln, wie der Lerneffekt durch einmaliges Abtippen einer
> Befehlszeile zustande kommen soll?

Ohh, ich denke das bringt viel. Lerning-by-doing ist mehr als leere
Worte. Auch der Sinn von begreifen (anfassen, tun) passt dazu.

> > nee, usbfs ist was anderes, kein filesystem Typ.
> 
> ARGH, da fängt der Hirnkrampf schon wieder an!!! WARUM steht USBFS dann
> in einer Reihe mit allen anderen FILESYSTEMEN in der Dokumentation für
> Mount/fstab? 

Weil es ein Filesystem ist, wie proc, aber es gibt genau eine Instanz
davon (und sie ist virutell). Kann man nicht zur Speicherung von Daten
auf Floppies verwenden, ist also kein allgemeiner "typ".

> Warum wird nicht extra darauf eingegangen, was man anstatt von
> filesystem typen da noch angeben kann, wann es sinn macht, welchen typ
> anzugeben und was wofür undsoweiter ist?  

Weil man dann ein komplettes Unix-Konzept-Buch mit "alles sind files
oder processes" in der man page hätte. Entweder lernt man das oder
akzeptiert das (ohne die Hintergründe zu wissen). Man kann ja nicht
gleichzeitig alles erklären und dann noch kurz und Aufgaben-orientiert!

> weiter damit zu beschäftigen. Sowas ist von der Dokumentation her kurz
> gesagt dann einfach nur noch: KRAMPF!

Mach doch mal ein Beispiel, wie es Deiner Meinung nach besser wäre. Dann
schickst Du es dem Autor bzw. der FSF oder so. Vielleicht sind in drei
Jahren ja dann viele Man-pages / Dokumentationen viel besser und von Dir
:)

Ich kann mir jedenfalls jetzt nicht so vorstellen, wie man essentiell
bessere Kompromisse zwischen den verschiedenen Anforderungen treffen
könnte (also noch mehr aber noch kürzer erklären, auf Details überall
aber doch nur bei Bedarf eingehen etc)

> > Nein, es heisst dass man USB Geräte wie Dateien ansprechen kann.
> > Googel fand

> wenn es dateien sind, was haben diese dann beim mounten von
> datenträgern(Massenspeichern) zu suchen? 

Bestehen denn nicht alle Filesysteme aus Dateien?!

Aber es stimmt schon, logisch sind proc und so eher "blockdevices" beim
Mounten als "filesystemtypen", also eher Instanzen als Klassen. Aber das
ist schon fast spitzfindig...

> ja, ich weiß, dass der massenspeicher, um als datei angesprochen
> werden zu können, erstmal dem system als speicheradresse bekannt
> gemacht werden muss - trotzdem stellt das imho einen sonderfall von
> "mount" dar, der in einem gesonderten dokument (z.b. "wenn sie
> speichermedien nicht als verzeichnisse im Dateisystem einbinden
> wollen")

Es werden ja (virtuelle) Speichermedien als Verzeichnisse im Dateisystem
eingebunden. Wie auch andere Files sind das technisch Schnittstellen.
"reguläre Files" verhalten sich so: man schreibt was rein und liest das
wieder raus. Fein. Gerätedateien kann man aber evtl. gar nicht schreiben
oder man liest und schreibt ganz unterschiedliche Sachen. Eine Datei ist
etwas, wo man reinschreiben und rauslesen kann. Das ist eine Datei! Eine
Datei ist nicht ein sequentieller Bytespeicher. Das war bei DOS und
Windows mal fast so (aber auch hier gabs COM1: usw!). Das ist aber
falsch. Eine Datei ist kein Bytespeicher, sondern etwas, was man lesen
und schreiben kann. Eventuell wird das geschriebene einfach gespeichert
und kann gelesen werden, gut. Sonderfall, mehr nicht.

(Solche Fallen waren es, in die man meiner Meinung nach tappen kann, wenn
man "aufgabenorientiert" lernen möchte.)

> behandelt gehört, da er mit dem "alltag" (gerät
> anschließen/datenträger einlegen; mounten; benutzen) nix zu tun hat.

Das ist doch nicht der Alltag. /proc gibt's bei Linux immer, USB ist ne
Ausnahme (also nicht in 100% der Fälle da). Also ist ja /proc wohl der
Alltag und nicht USB mounting.

Auch wenn *Du* persönlich öfter USB mounten magst als /proc (und von
letzerem nichtmal was merkst) :-)

> In der dokumentation darf auch gerne auf die modularität und die
> funktionen der einzelnen module hingewiesen werden, aber für mich
> haben die schreiber der dokumentation eindeutig aus den augen
> verloren, wie jemand, der von der modularität als anwender nichts
> mitbekommt, mit dem system umzugehen lernt.

Wo wir wieder beim Ursprung wären. Woher weiss mount nun eigentlich, was
proc und ubsfs sind? Was sie können? Soll in der mount man page drin
stehen, dass /proc/kmem nicht geschrieben werden sollte? Gehört es da
hin? Wenn man sucht, ob man da schreiben soll oder nicht, würde man doch
nie in man mount gucken? Oder schreibt man alles rein, dann hat man aber
wieder ein Buch, und genau das findest Du ja auch nicht gut.

Wie wäre es denn Deiner Meinung nach richtig?

> > Wird beim mounten kein filesystem typ angegeben, wird geraten. Das
> > klappt meist ganz gut. Es klappt nicht, wenn man exotische Sachen
> > hat, aber wenn man exotische Sachen hat, weiss man das meistens auch
> > :)
> 
> Woran erkenne ich exotische Sachen, wenn ich sie haben sollte?

Wenn Du ein Loch im Fuss hast, weil Du Dir da reingeschossen hast, weil
Du was exotisches machen musstest/wolltest, hast Du vermutlich exotische
Sachen...

Der pragmatische Ansatz ist, kein FS anzugeben und zu probieren, ob
mount klappt. Wenn mount dann sagt "must specify FS type", hat man wohl
was exotisches. Wenn einem das bisher unbekannt war, hat man ein
Problem.

Vielleicht stellt sich am Ende raus, das der USB Stick dann doch ein
Drucker war. Achtung, in "man mount" steht nicht, wie man einen Drucker
einrichtet. SCNR.

> > Weiss nicht was Du meinst. Ich meinte, Zielgruppe ist nicht klar (und es
> > müsste ja etliche geben) und diaktisch sind die meisten man pages auch
> 
> Siehe hierzu die zuvor geschriebenen Abschnitte, wo ich mich über die
> fehlende Begrenzung des modularen Denkens aufgeregt habe ;-)

(ja, fehlen nur die Alternativen. Nicht-modular geht nicht. Wenn
modular auch nicht geht, was geht dann?)

> Huch, hier ist mir ein Teil des Satzes beim Schreiben durch die
> (frontalen Schädel)Lappen gegangen. Sollte heißen: anhand der Häufigkeit
> von bestimmten in Linux-Anfängerforen *gestellten Fragen* aufgebaut werden.

Dann beschreibt Dein Werk viele Sachen, die man eigentlich überhaupt
nicht machen sollte. Viele Anfängerfragen sind im Stil von "Wie kriege
ich Windows Bug X mit Linux realisiert"?

> > mmm... Ich fand es sehr nervig, in MSDOS genug "unteren Speicher"
> > freizukriegen und so. Klar, wochenlanges Einrichten gabs kaum, weil die
> > Software nicht so anpassbar war.
> 
> Also 628kB waren immer drin - mehr brauchte dann aber auch fast keine
> Anwendung. Ansonsten mussten halt QEMM und ähnliche Spielereien ran
> ;-)

Du Glücklicher... (Ich kann mich erinnern, dass wir spezial-DOS-es
verwendet haben, ohne command.com, mit mini io.sys und so, damit der
remote debugger und die Anwendung noch in den Speicher passt...)

> > Was nicht heisst, dass ext3 auf Flash ne gute Idee ist (wg.
> > Flash-Zell-Alterung etc). Auf keinen Fall atime auf flash benutzen :)
> 
> Was ist "atime"? Die automatische Defragmentierung von ext-Filesystemen?

nein, access time (Zeitstempel des letzten Zugriffs).

Warum atime (man denke ans Hauptverzeichnis des Mediums) bei Flash
tötlich ist, ist nicht so ohne weiteres klar, wenn man nicht weiss dass
und wie Flash altert. Sollte das auch in der man page zu mount stehen?
Wegen dem Blick fürs Ganze?

> > Nee, dann würde man eher "safe" als "secure" sagen. Bei SD sind
> > irgendwelche TCPA Gverwandten Geschichten dabei oder sowas.
> 
> Also das einzige, was ich als "Sicherzeitsmaßnahme" diesbezüglich auf
> SD-Karten gesehen habe, war ein kleiner Schalter, der einen
> Schreibschutz aktivieren/deaktivieren kann. 
 [...] 
> Sicherlich gäbe es Anwendungsfälle für SD-Karten, die ihre Daten nur
> preisgeben wenn der darauf Zugreifende sich mit einem entsprechenden
> "Private Key" authentifizieren kann, und zum Beschreiben gäbe es dann
> einen Public-Key, wobei noch zusätzlich sichergestellt werden müsste,
> dass nur mit dem Private Key auch vorher bereits geschriebene Daten
> darauf verändert werden dürfen - aber: In wie vielen Fällen machte so
> etwas sinn, verglichen mit der Insgesamten Einsatzhäufigkeit solcher
> Karten? Und: In welchen Digitalkameras/sonstigen mobilen Endgeräten
> würden solche Karten dann heute noch funktionieren?

Das ist wieder ein Beispiel für die Gefahr von "Aufgabenorientiertem
Leren". Du hast angenommen, SD Karten sind einfache Flashspeicher, die
einen kleinen Hardwareschreibschutzschalter haben (so mehr oder
weniger).

Das ist falsch.

Wikipedia:

> Der Name Secure Digital leitet sich von zusätzlichen Hardware-Funktionen
> für das Digital Rights Management (DRM) ab. Mittels eines vom Nutzer
> nicht einsehbaren Speicherbereichs soll die Karte das unrechtmäßige
> Abspielen geschützter Medien-Dateien verhindern. Die genaue
> Spezifikation steht unter Verschluss und kann nur von den zahlenden
> Lizenznehmern der SDCard Association eingesehen werden.

Es geht also um DRM (also eher Datenschutz als Datensicherheit).

Halb- und Viertelwissen:
Es ist nicht bekannt, ob und wie Spezialanwendungen solche Funktionen
benutzen (oder benutzen können). MP3 Player benutzen wohl u.U. das DRM
von den Karten überhaupt nicht.

Deine Annahme passt recht gut zu den auch von Dir genannten MMC Karten.
Das ist im Wesentlichen Flash-Medien ohne weiter Funktionalitäten - aber
auch mit internem Controller, der vermutlich automatisch Blöcke rotiert,
um Alterung vorzubeugen, das ist heute Standard.

Die ct' hat mal versucht, einen USB Stick kaputt zu schreiben, in dem
der gleiche Block Millionenfach geschrieben wurde - hat es aber nicht
geschafft. So ein Kontroller kann vermutlich viel trixen, vielleicht
sogar hotfix-area nutzen, wie Festplatten das tun.

> > Ein Beispiel ist diese Vodafone "Easybox Zuhause". Das ist ein USB UMTS
> > Modul mit Massenspeicher (paar MB). Über "autoplay" wird bei Windows ein
> > Treiber installiert. Steckste als bloss an, dann wird Treiber
> > installiert, gibste Deine UMTS PIN ein und bist im Internet.
> 
> Ist ja ein tolles Feature, wenn das unter einem Betriebssystem
> funktioniert....
> Will sagen: Hallo, dies ist eine Linux-Liste? Was ist, wenn ich das Teil
> an einen Linux-PC anstöpsele?

Funktioniert das Windows-Autoplay-Install-Feature natürlich nicht.

Laut Vodafone wird Linux nicht unterstützt.

(praktisch gesehen kann man das Teil öffnen und ein #99* schicken, also
ob es ein GSM Gerät wäre - es macht dann ne UMTS Verbindung. Für PIN und
so sind sicherlich paar Sachen zu beachten, keine Ahnung, anderes
Thema).

> => Sowas ist IMHO in der Praxis nur mit einem proprietären
> Software-Monopol möglich. Oder meinst Du, jeder WLAN-Datenstick sollte
> auch nochmal 128MB Speicher haben, damit 64MB davon mit Treibern für
> Windows, 50MB mit Mac-Treibern und die verbleibenden 13,irgendwas MB
> mit Linux/BSD/sonstwas-Unix-Treibern gefüllt werden können?

Ich meine nicht so sehr "sollte", sondern eher "könnte". Linux
interessiert Billig-Hardware-Hersteller nicht so sehr. Linux-Benutzer
sind im Schitt auch in der Lage, selbst Geräte zu konfigurieren (und
wenn nicht, ist das dann nicht Problem des Herstellers).

Warum Treiber so riesig sind, ist mir kaum erklärlich.

Man braucht bestimmt 100.000 Zeilen Code, um 64 KB in C
vollzuprogrammieren. 64 MB sind ca. das eintausendfache. Das wären nach
einer Milchmädchenrechnung 100.000.000 Zeilen Code. Das kann man einfach
nicht brauchen müssen...

Also hätte man vielleicht 1 MB Speicher, das ist riesig fett viel, und
jeweils ein paar KB Treiber. Idealerweise natürlich nicht für win i386
und für die 10 wichtigsten Linuxplatformen sondern einmal. Vielleicht
als ne Art Bytecode. Oder als ein microkernel module. GNU Hurt ist ja
bald fertig looooooooool

> > (natürlich blöd, wenn jemand den Treiber gegen einen Trojaner getauscht
> > hat ;) - autoplay hat auch Nachteile ;))
> 
> Hat autoplay auch Vorteile?

Ich vermute das, weil es sonst wohl nicht so populär wäre. Bei Win XP
kann man es nichtmal so einfach abschalten. Hotplug ist auch sehr
beliebt. Verstehe ich allerdings beides nicht.

> > Ja OK, Flash ist vielleicht blöd, k.A.. Man muss auch gucken, was billig
> > ist.  Ich glaub, Flash ist beliebt als Firmwarespeicher, weiss nicht, ob
> > was hier ideal wäre.
> 
> Ich glaube, Flash ist als Firmwarespeicher vor allem deshalb so beliebt,
> weil es bedeutet, dass man bei der Programmierung von Firmwares nicht so
> viel in Qualität und Stabilität investieren muss, weil man ja die Fehler
> nachträglich noch leicht durch Firmware-Updates ausbessern kann.
> Da es die EEPROM-Technik schon länger gibt als Flash-Speicher, wäre
> meine nächste Frage: Wieso sollte Flash billiger sein als EEPROM? Weil
> es massenhafter produziert wird?

Kommt auch auf weitere Faktoren an. Firmware-Updates müssen heute wohl
immer möglich sein, weil Software > 100.000 Zeilen Code garantiert
mehrere Bugs enthält. Diese Komplexität beherrschen Menschen meiner
Meinung nach noch nicht (benutzen sie aber).

> >> Es gibt - lustigerweise meistens nur unter Windows lauffähige -
> >> Spezialhardware, die das kann. USB-Festplattengehäuse mit
> >> Fingerabdrucksensor, oder die erst ein bestimmtes Zertifikat von einem
> >> am PC angeschlossenen SmartCard-Reader benötigen usw.
> > Man kann auch einfach das Floppy ausbauen und die USB Anschlüsse
> > versiegeln...
> Ja, damit würde man ein völlig anderes Sicherheitsszenario realisieren
> als mit einem "geschützten" USB-Massenspeicher...

(Es ging darum, keine Daten rauf- oder runterzukriegen. Hier hilft kein
"geschützten" USB-Massenspeicher nicht, weil man ihn nicht benutzen
muss.)

> > Sowas gibt's standardmässig bei USB meines Wissens nach nicht. Aber es
> > /geht/. Über USB kann man ja auch Netzwerk machen etc.
> Klar, ich kann auch übern RS232-Port 2 PCs miteinander verbinden und
> Daten übertragen....

Mit Unix (Linux) eben nicht unbedingt, weil Du /dev/ttyS0 nicht benutzen
darfst. Wie genau das bei Windows aussieht, weiss ich nicht. Das ist
IMHO auch das komische an USB und Linux Desktop und dem ganzen Kram.
Warum darf der, der sich zufällig lokal anmeldet, auf einemal Hardware
direkt benutzen?!

> > Ja, schon klar. Vermutlich liest diesen langen Thread auch kein
> > anderer auf der Liste, aber vielleicht antwortet ja doch jemand, wer
> > weiss :)
> 
> Möchstes Du damit ausdrücken, dass der Thread hier eigentlich
> überflüssig ist? Dann sag das doch bitte direkt! :-)

Nein, ich wollte damit ausdrücken, dass ich die Frage in einer extra
Mail hätte stellen sollen, hätte ich auf eine Antwort Wert gelegt :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.