Re: Martin's Privatmeinung

As norbert.meissner(at)daimlerchrysler.com wrote:

> >Koenntest Du die Scheisse mit Subject: Antwort: unterlassen? Und das
> >vor allem mehrfach. Glaubst Du, Du bist allein auf der Welt oder
> >was?
>
> Ich bin solche Faekalsprache nicht gewoehnt. Aber vielleicht moechtest
> du uns allen mehr von dir zu Hause erzaehlen.

Ich kann Martins Reaktion verstehen, auch wenn ich sie nicht billigen
mag. (Hängt vielleicht damit zusammen, das ich täglich mit Kunden zu
tun habe, die ähnlich besch***ene Software verwenden wie Du, so daß
ich verstümmelte Threads, nicht ordentlich markierte Quotes etc.
mittlerweile gewohnt bin. Dennoch k*tzen sie auch mich genauso an wie
Martin. Nicht die Leute, die so einen Mist verwenden müssen, obwohl
sie nicht anders dürfen [in der Firma], sondern eher die
Programmierer, die so einen nicht mit Internet-Gepflogenheiten
konformen Quatsch verzapft haben, sowie das Resultat, das uns dann
präsentiert wird und uns das Leben schwerer macht als nötig.)

Aber: steter Tropfen höhlt den Stein. Auch DaimlerChrylserBMWwasweissich
nimmt irgendwann eine andere Software, wenn sich nur genügend Leute über
den Müll beschweren, den die jetzige fabriziert. Davor steht aber Deine
Erkenntnis, _daß_ Eure Software Datenmüll produziert.

> Leider wieder falsch. Da Kompression ein statistisches Verfahren ist,
> erreicht man in groesseren Dateien (=Bloecke) bessere Kompressions-
> raten.

Im Prinzip ja. Komprimierung der Tapelaufwerke ist aber an deren
Hardware-Blockgröße gebunden. Leider lassen nur wenige Hersteller so
tief in Details gucken, daß Du darüber was erfährst. Du kannst aber
davon ausgehen, daß die größten Hardwareblockgrößen heutiger
Tapelaufwerke bei einigen wenigen Kilobyte liegen. Komprimiert wird
dann innerhalb dieser Blöcke, mehr nicht. Die Limitierung auf
derartige Blockgrößen ist für die Anwendung einer automatischen
Fehlerkorrektur unabdinglich -- wir leben schließlich nicht mehr in
einer Zeit wie früher bei den Floppies, wo man hinterher alles nochmal
kontrollesen mußte...

> Das habe ich auch so nicht behauptet. Ich weiss nur, das ich in der
> liste mal gelesen habe, das das SCSI-System maximal 64Kb grosse
> Bloecke verarbeitet und darueber also kein Performancegewinn mehr
> auf Platte oder Band zu erwarten ist.

Der Performancegewinn ist schon darunter sehr gering. Probier's mal
aus, den Unterschied zwischen 10 KB (default Größe vom tar) und 32 KB
(default von dump für einige Laufwerke) zu messen.

> Ich moechte dir jetzt hier zum zweiten Mal empfehlen deinen Schreibstil
> zu ueberdenken bzw. dir eine andere Liste zu suchen.

Wir würden Dir hier zum N-ten Mal empfehlen, eine Software zu
benutzen, die zumindest die Threads beisammen läßt. Es liest sich
_sehr_ lästig, wenn man zum gleichen Thema an drei verschiedenen
Stellen lesen muß. Es zählt dabei auch nicht als Entschuldigung, daß
die von Dir verwendete Software sowieso keine Ahnung von Threads hat
und Dir folglich diese auch nicht darstellen kann (das ist
ausschließlich Dein Problem), sondern entscheidend ist, daß die
`References' Headers so benutzt werden, wie sie auch der Rest der Welt
benutzt.

> >Die variable Blocksize hat m.W. nicht das geringste mit Kompression
> >oder Comprimierbarkeit zu tun,
>
> Schoen, das du lesen kannst.

Schön, daß Du Ahnung hast, um mit Deinen Worten zu kontern...

> Wie erklaerst du dir eigentlich das Vorhandensein von variablen
> Blockgroessen bei DLT, DAT oder VXA ?

Wie erklärst Du nun eigentlich deren praktisches Nichtvorhandensein?
:-)

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message