Re: Martin's Privatmeinung

From: Martin Cracauer <cracauer(at)cons.org>
Date: Tue, 21 Nov 2000 18:05:01 +0100

In <0057440004484033000002L432*@MHS>, 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 wuerd Dich ja gerne ins Killfile nehmen, aber Du redest so viel
> >Unsinn, dass FreeBSD in Verruf kommen koennte, wenn Du nicht
> >korrigiert wirst.
>
> In diesem Falle solltest du jede Mail, in der meine Adresse als
> Absender vorkommt *kommentarlos* loeschen. Es wird deine Lebens-
> erwartung um Jahre verlaengern.

Ich wuerde das gerne tun, aber das Du die kompletten Threads versaust,
bringt das nicht viel. Ausserdem hast Du meinen Satz, warum Du nicht
in mein Killfile kannst, nicht verstanden.

[...]
> >Deine Behauptung, dass die Blockgroesse auswirkungen auf den
> >Kompressionsfaktor hat, ist m.E. auch Unsinn, die Kompression des
> >tapes geschiet nicht auf Basis der von der Software gelieferten
> >Bloecke.
>
> Leider wieder falsch. Da Kompression ein statistisches Verfahren ist,
> erreicht man in groesseren Dateien (=Bloecke) bessere Kompressions-
> raten.

Selbstverstaendlich. Nur leider arbeitet die Kompression des Tapes
nicht auf den Bloecken, die vom Kernel/Applikation kommen. Also nicht
"=Bloecke".

> >Ich glaube, wir brauchen hier dringend mal jemanden, der eine Tape-FAQ
> >verspeist und den ganzen Quatsch, der in diesem Thread gelabert wurde,
> >korriert. Ist ja schrecklich. Ich hab Joerg mal CC'ed, der sollte
> >sich einigermassen auskennen.
>
> Ich moechte dir jetzt hier zum zweiten Mal empfehlen deinen Schreibstil
> zu ueberdenken bzw. dir eine andere Liste zu suchen.

An diesem speziellen Absatz von mir kann ich nichts Schreibstil-
falsches erkennen. Es ist ein Fakt, dass in diesem Thread zuviel
technischer Bloedsinn gelabert wird (auch von mir) und wir brauchen
jemanden, der so was wie Kompetenz besitzt.

[...]
> >sondern man braucht sie fuer bestimmte
> >>Tape-Typen (z.B. die 9-Spur-Laufwerke), die komplett anders gesteuert
> >>werden als moderne QIC, DAT oder DLTs.
>
> Interessante Ansicht ;-)
> Wie erklaerst du dir eigentlich das Vorhandensein von variablen
> Blockgroessen bei DLT, DAT oder VXA ?

Siehe Joerg's reply.

Alte Tapes hoerten wirklich noch auf die Blocksize und haben das auch
so auf's Band geknallt. Moderne Laufwerke machen was sie wollen, aber
eben kompatibel zu den Alten. Das erklaert auch Dein Missverstaendis,
warum Du annimmst, dass auf Ebene der von der Applikation gewaehlten
Blocksize komprimiert werden muss.

"variable blocksize" ist ausserdem nicht nur ein Kommando an das Tape,
sondern wird auch benutzt, um dem Kernel (nicht dem Laufwerk) zu
sagen, dass man "egal was kommt" lesen moechte.

> In Hoffnung deiner Besserung

Gleichfalls.

Martin

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany     http://www.bsdhh.org/
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 21 Nov 2000 - 18:05:12 CET

search this site