[Debian]:Re: Betriebssysteme (Was: Re: Zeitschrift: Linuxer...) (fwd)

[Holger Rauch <Holger.Rauch@heitec.de>]

Das ist bis jetzt die letzte der mails. Mir geht es darum, dass sich jeder
ein Urteil sowohl ueber meine Argumentation als auch ueber die von Stefan
Nobis bilden kann. Auch wenn es sich brutal anhoert: Ich frage mich, was
Leute auf einer user mailing list wollen, wenn sie

a) nicht richtig mails lesen koennen (da sie Aussagen aus dem Zusammenhang
reissen, indem sie lediglich die 2-3 Zeilen einer Aussage lesen anstatt
den kompletten Absatz zu lesen, bevor sie antworten).
b) selbst nicht praxisbezogen argumentieren koennen (ihre Aussagen durch
konkrete Beispiele mit Leben erfuellen koennen)
c) praxisorientierten Argumenten nicht zugaenglich sind (sie als
"nebensaechlichen Kleinkram" bzw. "nebensaechlich Details" bezeichnen)

Aber wie gesagt, bildet Euch Euer Urteil drueber und teilt mir Eure
Meinung mit.

Im uebrigen war sich der Herr Nobis offensichtlich zu fein dafuer, auf die
untenstehende mail zu antworten.

Gruss,

	Holger

---------- Forwarded message ----------
Date: Mon, 15 May 2000 08:43:34 +0200 (CEST)
From: Holger Rauch <Holger.Rauch@heitec.de>
To: Stefan Nobis <stefan@snobis.de>
Subject: Re: Betriebssysteme (Was: Re: Zeitschrift: Linuxer...)

Hallo!

Zunaechst mal ein paar grundsaetzliche Anmerkungen und schon mal danke im
voraus fuer die Ausdauer beim Lesen der mail (vorausgesetzt, Du nimmst Dir
die Zeit). 

Ich habe den Eindruck, dass ein Grossteil der Missverstaendnisse dadurch
entsteht, dass Du die Absaetze nicht als Einheit betrachtest, sondern dass
sich Deine Argumente oft auf 2 oder 3 Zeilen aus einem Absatz beziehen.
Nehme Dir doch bitte die Zeit und lese die Absaetze komplett durch, bevor Du
Dich in Deinen Antworten auf meine Aussagen beziehst. Ich nehme mir
umgekehrt auch die Zeit und lese Deine Aussagen komplett durch, bevor ich
darauf eingehe.

Bei Deinen mails faellt mir auf, dass Du ueberwiegend von der theoretisch-
konzeptionellen Seite an die Sache rangehst. Das ist Dein gutes Recht. 
Was ich nicht verstehe ist, dass Du Argumente, die eher praxisorientiert sind, 
unter den Rubriken "Kindergartenniveau" (dazu sage ich spaeter noch was) oder 
"nebensaechliche Kleinigkeiten" abheftest.
Was die "Nebensaechlichkeiten" angeht, muss ich sagen, dass sie aus
praktischer Sicht nicht von der Hand zu weisen sind und fuer einen Admin,
der vor dem Rechner hockt, schlicht und ergreifend laestig sind. Sicherlich
moegen diese Dinge vom konzeptionellen Standpunkt aus betrachtet
"nebensaechlich" sein, das aendert aber nichts daran, dass sich ein Admin
mit ihnen herumschlagen muss und dass diese Dinge ihm zum Teil unnoetig Zeit
kosten, ob er will oder nicht.

Darueber hinaus bemerke ich, dass Du manche Argumente, die ich bringe,
einfach unter den Teppich kehrst, ohne vernuenftig darauf einzugehen.

Beispiele:

1. Ich habe in meinen vorherigen mails an Dich u. a. die mangelnde Transparenz
von WinNT beklagt und dabei WINS, die registry und die service packs als
Beispiel gebracht. Als Du mich gefragt hast, ob es denn hinsichtlich der
Transparenz unter Linux besser ausschaut, habe ich das mit den HOWTOs, den
info und man pages, den change logs und der HTML-Doku gerechtfertigt.
Seltsamerweise hast Du mir bis heute nicht gesagt, wie Du dazu stehst.

2. Auf mein Argument hinsichtlich der groesseren Auswahl an mitgelieferter
SW bei Linux-Distributionen im Vergleich zu WinNT bist Du ebenfalls nicht
eingegangen. Wenn sich unter Linux herausstellt, dass ein Programm
groessere Sicherheits-Luecken hat (z. B. sendmail, wu-ftpd) kann ich in den
meisten Faellen eine entsprechende Alternative von der Distribution nehmen
(z. B. Postfix und ProFTPD). Wenn mir bei MS das mitgelieferte Zeug nicht
gefaellt, muss ich mir so gut wie alles aus dem Internet saugen und das ist
doch sehr zeitaufwendig, insbesondere dann, wenn man ein einigermassen
sicheres NT haben will.

3. Was mein Argument mit den mail progs anbelangt, scheint das bei Dir auch
auf taube Ohren gestossen zu sein. Hier ging es darum, dass ich erwaehnt
habe, dass unter Unix kein mir bekannter mail client attachments automatisch
ausfuehrt, wenn man drauf klickt.

Ach ja, warum laesst Du manche meiner Fragen einfach unbeantwortet? Ich habe
Dich z. B. in den vorangegangenen mails folgendes gefragt:

1. Ich wollte von Dir wissen, welchen DoS-Angriff Du gemeint hast, als
Anfang dieses Jahres angeblich tausende von Unix-Rechnern lahmgelegt wurden.
Ich bin bei der CERT mailing list subscribed und habe kein derartiges advisory bekommen. Auch als
ich meine Ausgaben von "free x" und des "Linux Magazin" durchgeblaettert
habe, konnte ich nichts entdecken. Ich kann mir nicht vorstellen, dass es
eine plattformuebergreifende Attacke war, da die Unix kernels in
Detailfragen doch sehr unterschiedlich implementiert sind. Ausserdem wollte
ich in diesem Zusammenhang wissen, welche Unix-Derivate davon betroffen
waren.

Desweiteren bemerke ich, dass Du Deine Argumente relativ selten mit
konkreten Beispielen belegst (siehe unten). Wenn Du das naemlich von
vornherein machen wuerdest, waeren viele Deiner Argumente nachvollziehbarer
und man muesste sich nicht fragen: "Was konkret meint er eigentlich?" 

Du hast in Deiner urspruenglichen mail an die debian-user mailing list
behauptet, dass WinNT "im Kern" nicht sicherer oder virenanfaelliger ist als
Linux, FreeBSD und Co.
Wenn ich "im Kern" richtig verstehe, meinst Du damit den eigentlichen kernel
des OS. Nur vermisse ich bis heute von Dir Argumente, die das WIRKLICH
belegen. Mal ganz abgesehen davon, dass man es sich eigentlich nur in
Ausnahmefaellen leisten kann, alle Unix-Derivate ueber einen Kamm zu scheren, 
weil sie sich speziell bei Kernel-Angelegenheiten in Detail-Fragen voneinander 
unterscheiden. Deshalb an dieser Stelle mal eine Frage:

WAS GENAU veranlasst Dich dazu, zu glauben, dass Unix-Derivate im Kern
(wobei ich hiermit speziell bei Linux aktuelle Standard-Kernels, also 
2.2.14/2.2.15 meine) nicht sicherer oder virenanfaelliger sind als WinNT, 
z. B. in den Bereichen

1. Dateisystem(e)
2. TCP/IP protocol stack
3. Firewall und masquerading
4. Memory management
5. Prozess-Verwaltung (scheduler)
6. Device drivers allgemein

Ausserdem hast Du von Implementationsdetails von Linux gesprochen, die
negativere Auswirkungen haben als die Punkte, die mich an Windows stoeren.
Auch hier vermisse ich bis heute entsprechende Beispiele, die sich auf
Kernel-Interna beziehen.
Du hast einzig das rewriting des firewall code in den Kernel-Versionen
2.0-2.4. genannt. Der Grund fuer dieses rewriting waren aber nicht
Sicherheitsprobleme, sondern weil sich der Autor eine Loesung gewuenscht
hatte, die flexibler ist als die vorherige. Dieses Vorhaben war bei 2.2
noch nicht abgeschlossen und deshalb gibt es halt bei 2.4. eine neue
Version. Aussserdem gibt es Konvertierungs-Scripts, die es dem Admin
ermoeglichen, die bestehende config zu portieren.

Sicherheit ist insgesamt ein recht dehnbarer Begriff und sollte nicht nur
als Schutz gegen unbefugten Zugriff verstanden werden. Zusaetzlich sind hierbei
unter anderem auch 

1. Integritaets-Aspekte (z. B. Wiederherstellung des Dateisystems nach einem 
Systemabsturz), 
2. Robustheit gegen Ausfaelle, die durch Software-Fehler hervorgerufen
werden sowie 
3. unnoetige downtime durch reboots (das waere sozusagen die Sicherheit bzw.
Unsicherheit, ob mein System ueberhaupt benutzbar ist)
4. Die Sicherheit (Gewissheit), seine Dateisysteme on the fly erweitern zu
koennen.
5. Die Sicherheit, dass nicht ein einzelner das ganze Dateisystem fuer
sich in Beschlag nehmen kann (erreichbar durch disk quotas).
 
zu beruecksichtigen.

1. Wenn es um Dateisystem-Integritaet geht, hat WinNT bis heute keine
absolut zuverlaessige Loesung zu bieten. Verschiedene Unix-Derivate sind da
wesentlich weiter, da sich ueber journaling filesystems verfuegen. Dies gilt
fuer AIX, IRIX, Solaris (sofern man den Veritas Volume Manager besitzt) und
mittlerweile auch fuer Linux.
Journaling funktioniert so, dass alle Aenderungen des Dateisystems an
superblock und i-nodes in einem log mitprotokolliert werden. Die Aenderungen
verbleiben so lange im log, bis die Aenderung tatsaechlich im Dateisystem
vorgenommen wurde. Erst dann wird sie aus dem log geloescht. Bei jedem
Boot-Vorgang wird das journal log daraufhin ueberprueft, ob es Daten
enthaelt. Falls ja, ist das ein Anzeichen darauf, dass die Aenderung nicht
im Dateisystem durchgefuehrt wurde. Solche "uebriggebliebenen" Aenderungen
weden beim Boot-Vorgang wieder eingespielt. Dem Ganzen liegt ein
Transaktions-Konzept wie bei DBs zugrunde. Entweder die Aenderungen werden
vollstaendig durchgefuehrt (dann ist das log beim naechsten reboot leer)
oder gar nicht (dann verbleiben die Meta-Daten des Dateisystems im log und
werden beim naechsten reboot eingespielt). Vorteile: Das Dateisystem selbst
(die Verwaltungs-Informationen) bleiben konsistent. Ausserdem wird dadurch
ein langwieriger fsck so gut wie ueberfluessig (die Zeit zum Hochfahren des
Systems wird wesentlich verringert. 
Fuer die Implementation des journal log gibt es unterschiedliche Ansaetze.
Bei AIX gibt es ein eigenes Datei-System dafuer, in das die Dateisysteme
ihre Infos schreiben. Als Faustregel gilt bei AIX, das pro 2 GB Plattenplatz
ein journal log von 4 MB anzulegen ist (das wird aber bei der Installation
von AIX automatisch gemacht). Linux ist hier (momentan noch) "gefraessiger".
Bei ReiserFS oder auch ext3 gehen pro Dateisystem erst mal 30 MB fuer das
journal log drauf. Hieraus ergeben sich gewisse Mindest-Anforderungen fuer
die Groesse eines Journaling-Dateisystems. Durch Ausprobieren habe ich
herausgefunden, dass es bei SuSE 6.4 mindestens 120MB sein muessen.

2. Hier liegt bei WinNT sehr viel im argen (auch wenn es nicht so krass ist
wie bei Win95/98). So ziemlich alle neueren Unix-Derivate sind da wesentlich
unanfaelliger.

3. Auch hier ergeben ergeben sich bei WinNT deutliche Nachteile. Warum muss
ich jedesmal wenn ich z. B. an der TCP/IP-Konfiguration etwas aendere (z. B. 
DNS server, WINS server) den Rechner rebooten? Haengt das etwa mit der registry
von NT zusammen, d.h. wird die nur einmal beim Booten eingelesen? Falls ja,
muss ich sagen, dass es auch Unix-Derivate gibt, die so etwas wie eine
Datenbank ueber die System-Konfiguration verwalten (z. B. AIX).
Das Pendant unter AIX nennt sich ODM (Object Data Mangager). Hier werden
saemtliche Geraete mit ihren zugehoerige config options in Klassen und 
entsprechende Unterklassen eingeteilt. So gibt es z. B. eine Klasse "SCSI" und
verschiedene Unterklassen (z. B. "disk", "tape"). Allerdings waren die Jungs 
und Maedels bei IBM schlau genug, dem AIX beizubringen, dass es diese Datenbank 
on the fly updaten kann und dass die Aenderungen sowohl sofort als auch beim
naechsten reboot wirksam werden. 
So was vermisse ich bei der registry von WinNT. Wenn NT sich seine registry
gleich noch mal reinziehen koennte, kaeme man sehr wahrscheinlich bei
Aenderungen an der Konfiguration ohne reboots aus.

4. Um das zu bewerkstelligen, braucht man einen Logical Volume Manager
(LVM) sowie Dateisysteme, die online resizing erlauben. Der LVM sorgt
dafuer, dass ich zunaechst mal genug Plattenplatz fuer das zu erweiternde
Dateisystem bekomme. So was gibt es u. a. fuer AIX, OSF/1, HP-UX, Solaris
und mittlerweile auch fuer Linux. Bei Solaris muss ich mir aber erst mal
ein StorEdge (wird wirklich so geschrieben) A 5200 fuer ca. 100.000,--
kaufen, damit ich ihn kriege.
Unter AIX und auch unter Linux funktioniert der LVM so:
Platten, die man unter Kontrolle des LVM stellen will, werden als Physical
Volumes (PVs) bezeichnet. Jede dieser PVs wird durch den LVM in
Partitionen gleicher Groesse zerlegt (sogenannte Physical Extents
(PEs) unter Linux bzw. Physical Partitions (PPs) unter AIX. Eine PE
ist mit einer Partition im herkoemmlichen Sinne vergleichbar. Diese sind
alle gleich gross und haben im Regelfall eine Groesse von 4 MB, wobei
dieser Parameter aber konfigurierbar ist. Mindestens eine PV bildet eine
Volume Group (VG). Innerhalb einer solchen VG kann man mindestens ein
Logical Volume (LV) anlegen. Auf diesen LVs werden dann auch die
Dateisysteme angelegt. Hierbei ist es so, dass die Gesamtheit aller
verfuegbaren PEs bzw. PPs fuer den Volume Manager einen pool bildet, aus
dem er sich bei Bedarf (beim Erzeugen eines neuen bzw. erweitern eines
bestehenden LVs) neuen Speicherplatz holt. Das geschieht so, dass fuer
jedes LV die PEs bzw PPs auf Logical Extents (LEs) bzw. Logical Partitions
(LPs) abgebildet werden (d.h. ein pointer gebildet wird). Jedes LE
entspricht groessenmaessig einem PE. Hierbei ist es egal, auf welchem PV
der VG die PEs liegen. Ein LV entsteht durch Zusammenfassung mehrerer LEs
zu einem Ganzen. LVs sind in der Groesse veraenderbar (vor allem
erweiterbar, manchmal je nach Implementierung auch reduzierbar). Wenn mir
in einer VG die PEs ausgehen, haengt man einfach noch mal eine Platte
rein, stellt diese unter die Kontrolle des LVM und nimmt dieses PV dann in
die entsprechende VG auf (erweitert diese).
IBM hat seinerzeit (soweit ich weiss, vor ungefaehr 10 Jahren) der OSF
seine Implementierung des LVM zugaenglich gemacht. Dadurch wurde der LVM
Bestandteil von OSF/1 und HP-UX. 
An erweiterbaren Dateisystemen fuer Linux gibt es derzeit ReiserFS, ext2
(mit entsprechenden patches und user tools) und glaub ich auch noch ext3.
Auf diesem Gebiet hat NT denke ich wenig zu bieten. Was mache ich dort,
wenn mir auffaellt, dass der Platz auf der Partition knapp wird? 

5. Disk quotas gibt es zwar seit Version 4 auch unter NT. Nur hat
Microsoft mal wieder so getan, als waere das "ganz neu", obwohl es sowas
bei den allermeisten Unix-Derivaten schon sehr lange gibt (seit mindestens
10 Jahren, wenn nicht noch laenger). Gut, Linux ist hier eine Ausnahme,
aber das gibt es ja noch nicht ganz so lange ,-)
Was mich in dem konkreten Fall an der Argumentation von MS stoert, ist die
Tatsache, dass versucht wird, Leute mit solchen Schein-Argumenten zum
Umstieg auf NT zu bewegen, als ob es disk quotas noch unter keinem anderen
OS gegeben haette.  

Aber nun (endlich) zu Deiner mail.

Stefan Nobis <stefan@snobis.de> wrote:

>> wenigstens die Moeglichkeit, ziemlich sofort noch Bekanntwerden eines
>> solchen Angriffs entsprechende patches einzuspielen bzw. neue Versionen
>> des betroffenen daemon durch den compiler zu hauen. Bei Win* muss ich
>> drauf warten, bis Mircrosoft sich bequemt, den naechsten service pack
>> rauszubringen und das dauert manchmal ein bisschen.

> Das stimmt so auch nicht: Für sicherheitsrelevante Bugs gibt es zum
> einen oft bekannte Workarounds und zum anderen gibt es von MS dafür
> meist recht schnell Patches.

Das hat mir ehrlich gesagt noch keiner meiner Kollegen, die Tag ein, Tag aus
mit WinNT arbeiten, bestaetigt.

> Sicherlich ist die Situation insgesamt bei Unix und insbesondere bei
> OSS wie Linux etwas besser. Aber das Grundproblem bleibt doch: Was
> bringt mir der so schnell verfügbare Fix, wenn ihn keiner nutzt? Und
> damit bleibe ich bei meinem Standpunkt: Bei der derzeitigen Mentalität
> (und Qualifikation?) im EDV-Bereich, ist das BS ziemlich nebensächlich
> und man bekommt mit dem Wechsel des BS eben keine gestiegene
> Sicherheit.

Wie kommst Du denn ueberhaupt zu der Meinung, dass die Mentalitaet im
EDV-Bereich so schlecht ist und keiner verfuegbare fixes nutzt?

Was die Qualifikation anbelangt, so muss ich ganz klar feststellen, dass in
zu vielen Firmen immer noch zu sehr auf moeglichst gute Abschluesse geachtet
wird (zumindest in Deutschland), ohne in Betracht zu ziehen, was sich jemand 
privat an praktischen Kenntnissen angeeignet hat. Ich habe 7 Fachsemester 
Informatik an der FH studiert (die angeblich im Vergleich zur Uni 
praxisorientierter sein soll) und muss sagen, dass ich von den Lehrinhalten, 
die ich so mitbekommen habe, in der Praxis vielleicht gerade mal 5% brauchen 
kann. Deshalb vertrete ich die Auffassung, dass ein Diplom allein noch kein 
Guetesiegel fuer einen guten Informatiker darstellt (egal, ob er als 
Anwendungsentwickler oder Administrator arbeitet). Wer sich heutzutage nicht 
waehrend des Studiums durch Ferienjobs bzw. in seiner Freizeit durch 
entsprechendes Literaturstudium auf dem Laufenden haelt, fuer den ist der 
Zug sowieso abgefahren. Es sei denn, er/sie beschaeftigt sich mit Gebieten, bei 
denen es ueberwiegend um Modellierung geht (z. B. Software-Architektur z. B. 
mit UML) oder mit Gebieten, bei denen von Natur aus viel Mathe dabei ist 
(z. B. Kryptographie), weil man in solchen Gebieten das im Studium 
vermittelte Wissen durchaus brauchen kann. Natuerlich muss man auch in
solchen Gebieten Buecher waelzen, aber insgesamt kommt es da nicht ganz so
stark auf Praxis-Erfahrung an, in dem Sinne, dass man am Rechner etwas
zustande bringt (also hacken kann). Was natuerlich immer dazukommt, ist die 
praktische Erfahrung an sich. Hiermit meine ich nicht nur 
Berufserfahrung, sondern auch z. B. die Mitarbeit an GNU-Projekten. 
Was ist Deine Meinung zur Qualifikation im EDV-Bereich? 

> Ebenso wie man NT im wesentlichen genauso sicher bekommen
> kann wie ein Unix-System -- es bedarf nur etwas mehr Aufwand.

Super. Ich muss erst mal kraeftig fuer das Zeug blechen und dann darf ich
auch noch mehr Arbeitsstunden investieren, um es "im Wesentlichen" genauso
sicher wie ein Unix-System zu bekommen. Wobei sich mir hier die Frage
stellt, was mit "im Wesentlichen" genau gemeint ist. Vor allem das "nur" an
dieser Aussage ist nicht zu verachten. Das man da Probleme bekommt, wenn es
darum geht, seinen Vorgesetzen soweit zu bekommen, solche Strategien zu 
finanzieren, glaube ich. Was muesste denn konkret getan werden, um NT im
Wesentlichen genauso sicher zu bekommen?

>> recht. Es ist halt die Frage, ob Firmen eigene Admins haben oder jemand
>> hinsetzen, der vielleicht schon Ahnung von der Sache hat, aber vielleicht
>> noch an vielen anderen Projekten mitarbeiten muss.

> Nein, das ist nicht das Problem. Das Problem ist: "Wie? Sie wollen
> Zeit und Geld in die Rechner investieren? Was muss da denn gemacht
> werden, wofür ist denn der teure Virenscanner nötig? Muss das wirklich
> sein? Es läuft doch alles!"

Diese Argumentation mag vielleicht in 3-Mann-Betrieben an der Tagesordnung
sein, in denen der Chef keine Ahnung von dem Problem hat, um das es
ueberhaupt geht (und der auch nicht mit sich darueber reden laesst). 
Aber ich kann mir nicht vorstellen, dass das in mittelstaendischen und 
grossen Unternehmen grundsaetzlich genauso ist (Ausnahmen gibt's natuerlich
immer). Wie gesagt, auch hier lasse ich mich gerne eines Besseren belehren, 
sofern Du konkrete Beispiele bringst.
 
Was den "teuren Virenscanner" anbelangt, kaeme ein
halbwegs vernuenftiger Admin nicht auf die Idee, den ueberhaupt zu
verlangen, denn er ist naemlich ueberhaupt nicht notwendig.
Eine moegliche Loesung:
Man nehme FreeBSD fuer den mail server, als MTA Postfix (das hat den
Vorteil, dass kein Prozess mit "root"-Rechten laeuft und das es modular
aufgebaut ist; letzteres bedingt eine bessere Konfigurierbarkeit, da ich
auch gleich einen mail filter mit "anflanschen" kann) und konfiguriere den
mail filter so, dass er erst gar keine Outlook-Mails annimmt. Damit hat man
sich schon mal gegen eine Gruppe von Viren gewappnet. Die naechste grosse
Gruppe (Word-Makro-Viren) kann ich verhindern, indem ich kein Word einsetze.
Es gibt genug Alternativen, die genauso gut, wenn nicht sogar besser sind.
Konkret: ApplixOffice, StarOffice und um mal ein professionelles
DTP-Programm zu nennen: FrameMaker. Ausserdem kann man auch "latex"
verwenden, wenn man KLyx als Aufsatz benutzt. Damit kann man auch solche
Anwender gewinnen, die mit markup languages nicht so viel am Hut haben. So
hat man einen Grossteil der im WinNT-Bereich vorkommenden Viren schon mal
erschlagen. Natuerlich brauche ich nach wie vor firewalls, die entsprechend
abgesichert sein muessen, daraus will ich keinen Hehl machen. Dann gelten
natuerlich auch noch die Grund-Regeln:

- dass man soviele Dienste wie moeglichin der "inetd.conf" auskommentieren 
sollte (bzw. ganz allgemein nur die tatsaechlich benoetigten Dienste laufen 
sollten)
- dass man in den kernel nur das reinkompilieren sollte, was man unbedingt 
braucht
- dass man grundsaetzlich auf alle "r commands" verzichten sollte
- "ssh" statt "telnet" benutzen sollte
- und die Mechanismen zur Sicherstellung vernueftiger Passwoerter soweit wie
moeglich einsetzen sollte. 
Darueber hinaus sollte man seinen "syslogd" vernuenftig konfigurieren und seine log files regelmaessig
ueberpruefen. Dadurch bekommt man zwar noch kein sicheres System, aber man ist
auf einem halbwegs guten Weg dorthin.

>> sein. Aber ein Grund-Problem bei Win* ist, dass man zunaechst einmal mit
>> dem vorlieb nehmen muss, was einem in verschiedenen Bildschirm-Masken
>> angeboten wird. Wenn das ausreicht, gut. Wenn nicht, Pech gehabt. Welche

> Ach komm, was ist das denn für ein Argument? Bei Unix muss ich mit dem
> vorlieb nehmen, was in den verschiedenen Konfig-Dateien so an
> Einstellungen angeboten wird. Bildschirmmasken sind doch nun wirklich
> nicht das Problem. Und auch unter Unix habe ich schon gelegentlich
> geflucht, warum dies oder jenes nun nicht vernünftig beeinflussbar
> sondern hardcoded war. Und nicht jedem ist auch nur die Zeit gegeben,
> mal eben die Quelltexte zu analysieren und anzupassen, mal abgesehen
> davon, dass es auch unter Unix Software gibt, für die der Quelltext
> nicht erhältlich ist.

Du haettest den Abschnitt, auf den Du da bezug nimmst, bis zum Ende lesen
sollen. Ich habe im weiteren Verlauf die Frage gestellt, welche
Moeglichkeiten man denn hat, auf das System Einfluss zu nehmen, wenn das in
den Bildschirm-Masken angezeigte nicht ausreicht. Im uebrigen habe ich nicht
behauptet, dass die Bildschirm-Masken das Problem sind, sondern dass man in
einen Dialog (und ich meine hier einen Dialog im GUI-Sinne) bzw. in Menues
nicht die Flexibilitaet wie in config files unterbringen kann, weil das sehr 
zu Lasten der intuitiven Bedienung geht. Als Beispiel moechte ich hier mal den
"XEmacs" nennen. Dort hat man versucht, im "Option"-Menue so ziemlich alles 
unterzubringen, was irgendwie konfigurierbar ist. Das Ergebnis sind 5 oder 6 
Menue-Ebenen mit jeweils unzaehligen Eintraegen. Und da ist es dann doch besser,
man editiert config files, weil man sich eh nicht mehr merken kann, in welchem 
Menue die konkrete Option war, die man aendern will. Da macht es dann keinen 
Unterschied mehr, ob ich mich durch Menues hangle oder in einer man oder info 
page nach der entsprechenden Option suche. Um Missverstaendnisse zu vermeiden: 
Ich halte den "XEmacs" fuer einen sehr guten Editor, ich habe an diesem 
Beispiel lediglich versucht, aufzuzeigen, dass man selbst mit einem sehr gut 
durchdachten GUI nicht an die Flexibilitaet von config files herankommt. 
Genau diese Art von Flexibilitaet ist aber im administrativen Bereich 
wuenschenswert und notwendig. Microsoft macht hier halt Abstriche und sagt 
sich: "Wir bieten nur soviel an, dass das System noch inituitiv benutzbar 
bleibt".

Was die hardcodeden Sachen in Unix apps anbelangt, so frage ich mich, was Du
konkret mit der allgemeinen Floskel "dies und jenes" meinst.

Natuerlich hat nicht jeder die Zeit, Quelltexte durchzuschauen und an die
eigenen Beduerfnisse anzupassen. 

Was die Unix apps anbelangt, die nicht im Quelltext erhaeltlich sind, so 
bieten sich als Loesung frei verfuegbare Programme an.
Einige Hersteller (z. B. Sun und Bull) bieten fuer SPARC bzw.
RS/6000-Maschinen CDs mit GNU SW bzw. freier SW im allgemeinen an. Und
selbst wenn die SW nicht auf CDs angeboten wird, haben viele Hersteller
binaries fuer ihre Architekturen erstellt. 
Dadurch habe ich zwei Vorteile:
1. Ich habe den Quelltext
2. Ich habe bei verschiedenen Unix-Derivaten tools mit einheitlicher
Bedienung und gleich gutem Leistungsumfang. Das mit der einheitlichen
Bedienung ist speziell beim C compiler nicht zu verachten und vom
Leistungsumfang her sind die GNU tools den vergleichbaren mitgelieferten
tools oft ueberlegen. Selbverstaendlich gibt es trotzdem noch SW, fuer die
ich den Quelltext nicht bekomme (meistens sind das kommerzielle
Anwendungen), aber speziell bei tools ist die GNU-Variante ein guter Ansatz.

> Man könnte einzig einwenden, dass MS bei Windows stärker versucht,
> Interna und Einstellungsmöglichkeiten zu verstecken, was in der Tendez
> sicher unbestreitbar ist.

Genau. Und dieses Versteckspiel bringt lediglich dem Anwender was. Das
belegt, das Windows zwar anwender-freundlich, dafuer aber admin-unfreundlich
ist. Letzteres finde ich nicht gut. 

> Deshalb kann WinNT/2000 im Detail an einigen
> Stellen aber dennoch besser konfigurierbar sein (z.B. ACLs).

ACLs gibt es zwar nicht unter Linux, dafuer aber z. B. bei AIX und HP-UX.
Hewlett-Packard hat das meines Wissens von DomainOS (das ist das
Unix-Derivat von Apollo) uebernommen, als sie Apollo aufgekauft haben. Um
ACLs auch unter Linux zu haben, braeuchte man:

- Support in der glibc
- Support im kernel
- Support in den einzelnen Datei-Systemen
- die entsprechenden user space tools (aclput, aclget, acledit)

Ich bin mir nicht sicher, ob diese Aufzaehlung vollstaendig ist, aber
diese Dinge muessen auf jeden Fall erfuellt sein.

So schoen ACLs auch sein moegen, sie haben den Nachteil, nicht portabel zu
sein, d. h. man muesste sich dann zum Beispiel ein Netz aus lauter
AIX-Rechnern aufbauen, um ACLs im Netz sinnvoll einsetzen zu koennen. In
heterogenen environments bringen ACLs gar nichts.

>> zweite wesentliche Punkt ist, was mir das BS an Moeglichkeiten der
>> Absicherung bietet. Und hier habe ich bei Unix einfach mehr
>> Moeglichkeiten.

> Das bringt aber nichts, wenn diese Möglichkeiten nicht genutzt werden!
> Und ausserdem kann ich dem so nicht ganz zustimmen. Wenn man NT
> wirklich gut beherrscht, dann kann man es ziemlich genauso gut
> absichern wie ein Unix-System -- nur evtl. mit mehr Aufwand.

Was verstehst Du in bezug auf NT unter "wirklich gut beherrschen", d. h. was
muesste der admin ueberhaupt koennen?

> Ich will hier ja kein Hohelied auf NT singen, ganz im Gegenteil. Ich
> will nur deutlich machen, dass die Nutzung dieses oder jenes Systems
> nicht automatisch mehr oder weniger Sicherheit bedeutet, 

Von einem Automatismus in bezug auf Sicherheit habe ich nie gesprochen. Ich
habe lediglich gesagt, dass einem unter Unix (und ich denke, dass kann man
ausnahmsweise mal auf alle Unix-Derivate beziehen) im allgemeinen wesentlich
mehr Moeglichkeiten geboten werden, um ein sicheres System zu schaffen. Das
das nichts bringt, wenn die Moeglichkeiten nicht genutzt werden, ist auch
klar. Nur was bringt ein admin, der sein System sicher machen will, wenn ihm
vom OS nur begrenzt die Moeglichkeiten dazu gegeben werden?

> sondern dass
> die Sicherheit eines Systems/Netzes schlicht mit der Qualifikation und
> dem Arbeitsaufwand des/der zuständigen Admins steht und fällt. Sprich:
> Schlechter Admin, tolles Unix, aber trotzdem unsicheres System und
> toller Admin, schlechtes NT, aber trotzdem sicheres System (wobei
> "sicher" natürlich schrecklich relativ ist :)).

Stimmt.

> administrieren sein, aber mit config files ist man einfach flexibler als
> ueber irgendwelche Dialoge. Es wird nicht gelingen, all das, was man mit

> Das ist so pauschal schlicht und ergreifend falsch!

> Ob ich etwas per Mausklick in einem Dialog an- oder ausstellt oder ob
> ich dies in einer ASCII-Datei erledige ist schlicht
> scheißegal. Dialogorientierte Konfiguration ist per se absolut nicht
> schlechter oder besser. Das einzige, was man NT anlasten könnte, wäre
> die Tatsache, dass es versucht viele Dinge vor dem Benutzer zu
> verstecken. Aber das ist ein völlig anderes Problem und wäre mit
> Textdateien auch völlig problemlos umsetzbar.

Auch dieses Missverstaendnis ist dadurch entstanden, dass Du Dich nur auf
zwei Zeilen des Absatzes bezogen hast anstatt ihn bis zum Ende durchzulesen.
Ich sprach im weiteren Verlauf davon, dass es nicht gelingen wird, die
Flexibiltaet, die einem in config files gegeben wird, in Dialoge bzw. Menues
zu packen. Dies wuerde nur zu einer Ueberfrachtung des Dialogs fuehren und
somit zu einem Verlust an inituitiver Bedienung. Das ist ein Bereich, der
mit GUI design zu tun hat. Hier muss der Betriebssystem-Hersteller die
Grundsatz-Entscheidung treffen, ob er sein OS anwender-freundlich oder
admin-freundlich gestalten moechte. Beides zusammen in Perfektion geht nicht. 
Ein anwender-freundliches OS (WinNT) beschneidet den administrator in seinen
Moeglichkeiten, ein admin-freundliches OS (Unix allgemein) ist fuer 
Nur-Anwender ohne entsprechende Zusaetze in Form von GUIs relativ schwer
zu bedienen. Natuerlich kann ein admin unter NT an der registry rumfummeln,
aber hier waeren wir wieder mal beim Problem der Transparenz. Gibt es denn
von Microsoft eine Doku, die alle moeglichen Registry-Eintraege mit ihren
Bedeutungen entsprechend erlaeutert?
(Ich weiss, ich hab die Frage schon mal gestellt, aber Du hast sie mir aus
unerfindlichen Gruenden unbeantwortet gelassen.) 

> Wenn du schon Kritik anbringen möchtest, dann bitte an den richtigen
> Stellen und nicht einfach wahllos Dinge aus den Fingern saugen, die
> nicht mal einem ersten prüfenden Blick standhalten.

Zum einen sauge ich mir keine Dinge wahllos aus den Fingern, zum andern
scheint sich Dein "erster pruefender Blick" darauf zu beschraenken, jeweils
immer nur 2 oder 3 Zeilen eines Absatzes zu sehen, anstatt den Absatz bis
zum Ende zu lesen und so die Aussage im Zusammenhang zu sehen.

>> Editoren in config files bewerkstelligen kann (und ich rede hier mal von
>> gueltigen Eintraegen) in Dialoge zu packen, da das zu Lasten der
>> inituitiven Bedienung geht.

> Auch das ist so allgemein schlicht falsch. Mal abgesehen davon, dass
> das, was du so im Editor machst, letztlich direkt oder indirekt auch
> Dialoge sind. Damit führst du deine eigene Aussage ja ad absurdum.

Ich fuehre meine Aussage nicht ad absurdum, da ich mit "Dialog" nicht
Benutzer-Interaktion allgemein meinte, sondern einen Dialog im GUI-Sinne.
(Also in der Motif-Sprechweise so ein XmDialogWindow mit XmPushButtons,
XmText widgets, XmRadioButtons und XmToggleButtons drin). Mir ist im 
Uebrigen schleierhaft, wie man das in dem Zusammenhang in dem ich das 
benutzt habe, so allgemein auffassen kann, wie Du es offensichtlich getan hast. 
Ich gehe mal davon aus, dass die meisten praktisch denkenden Menschen 
verstanden haetten, was ich gemeint habe. Ein paar Theoretiker gibt's immer.

>> Wirklich? Dann schau Dir mal den Inhalt/Organisation der init scripts
>> an. Es ist schon so, dass ein gewisser Kern zur Standard-Ausstattung einer
>> Linux-Distribution gehoert. Nur sind die Distributionen wenn es um
>> administrative Angelegenheiten geht, sehr verschieden. So erlaubt zum
>> Beispiel Mandrake das Einstellen von verschiedenen Sicherheitsstufen.

> Das ist doch Augenwischerei! Praktisch alle Distris benutzen SysV-Init
> und damit ist es eine Frage von 2-3 Versuchen herauszufinden, wo genau
> die Scripte liegen - für einen Angreifer absolut kein Problem, diese
> nebensächlichen Details.

Natuerlich ist das fuer einen Angreifer kein Problem. Meine Argumentation
zielte aber nicht nur auf Angreifer ab, sondern auf Unterschiede der
verschiedenen Linux-Distributionen und dem damit verbundenen administrativen
Aufwand allgemein. SysV-Init besagt lediglich, dass man verschiedene runlevels 
hat, wobei ein master rc script zwischen den runlevels wechselt. Unterhalb von
"/etc/rc.d" habe ich dann dirs der Form "rc<runlevel>.d" und in diesen
wiederrum symlinks auf die entsprechenden scripts in "/etc/rc.d".
Insbesondere besagt SySVInit nicht, welche Bedeutungen den einzelnen
runlevels zugrunde liegt. Es hat sich lediglich eingebuergert, dass runlevel
0 system halt ist, 1 single-user mode und 6 reboot. Die Bedeutung der
runlevel 2-5 variiert von einer Distro zur naechsten. Von den Namen und
Inhalten der jeweiligen scripts, die in den jeweiligen runlevels aufgerufen
werden, mal ganz abgesehen. Wie gesagt, es ist nicht alles so einheitlich, 
wie manchmal getan wird. 

> Und Mandrakes Einstellungen sind doch nur auf
> das System aufgepropft, d.h. da habe ich einen Dialog, in dem ich was
> einstelle und daraus werden dann Einträge in den ganz normalen
> Konfig-Dateien erzeugt und nur damit arbeiten letztlich die ganzen
> Programme.

Das sollte auch nur ein Beispiel fuer die Unterschiede zwischen den distros
in bezug auf den administrativen Bereich sein. Mehr nicht. Ein besseres ist 
vielleicht der ausgelieferte apsfilter bei SuSE 6.2. Selbst nach
ordnungsgemaesser Konfiguration konnte man keine Binaer-Formate (dvi, tiff,
usw.) drucken. Und zwar unabhaengig vom verwendeten Drucker. Wie sich nach
etwas laengerer Suche herausgestellt hat, war eine neue Version von "grep"
die Ursache, die einen switch gebraucht hat, um binary files zu erkennen.
Natuerlich haben die das Drucken mit dem apsfilter nicht ausprobiert.
Insbesondere bei den Drucker-Filtern ergeben sich deutliche Unterschiede
zwischen den distros (magicfilter bei debian, Read Hat Printing System bei
Red Hat basierten distros und apsfilter bei SuSE).
Ein weiteres Beispiel ist das "hostid" Programm. Bei manchen Versionen kann
man sich auch als "root" die hostid nur anzeigen lassen, sie aber nicht
setzen. Red Hat basierte distros sind Kandidaten fuer so was. 
Ich will damit nur sagen, dass bei weitem nicht alles alles so einheitlich
Du meinst, inbesondere nicht bei sogenannten "nebensaechlichen
Details". Hast Du ueberhaupt schon mal Linux-Rechner, auf denen verschiedene
distros installiert sind, administriert? Falls ja, haettest Du eigentlich
verstehen muessen, worauf ich anspiele. 

> Wenn man mal von Installationsroutinen und der Optik sowie
> Konfig-Aufsätzen, die letztlich mehr oder weniger direkt die
> eigentlichen, ganz normalen Konfig-Dateien erzeugen, absieht, kann man
> die Unterschiede der Distris schon fast an einer Hand abzählen. 

Mag sein, dass man oberflaechlich betrachtet die Unterschiede an einer Hand
abzaehlen kann. Als admin muss man sich aber mit den von Dir so verpoenten
"nebensaechlichen Details" rumschlagen und spaetestens da stimmt Deine
Behauptung einfach nicht mehr.

> Und diese Unterschiede werden auch bald noch verschwinden im Rahmen der
> Bemühungen um Linux Standard Base (LSB).

Wenn ich mir die mails auf der "debian-lsb-discuss" list so anschaue, habe
ich meine Zweifel, ob die LSB bald kommen wird und somit die von Dir
angesprochenen Unterschiede bald verschwinden. Es stehen noch einige Punkte
aus (z. B. das layout fuer den "gnome" tree oder auch fuer KDE). Ausserdem
weigert sich z. B. Red Hat, sich in manchen Punkten an die LSB zu halten.
Ich kann Dir jetzt nicht aus dem Stegreif sagen, welche das genau sind, aber
ich habe die mails noch und kann sie mir daraufhin noch mal durchschauen.

>> bekomme ich bei einer Distribution wenigstens was bootfaehiges und muss
>> nicht der Reihe nach 6 oder 7 oder was weiss ich wieviele service packs
>> einspielen, bis ich ein System habe, das einigermassen up to date ist.

> Hast du eigentlich schon mal mit NT gearbeitet? Ich muss nämlich nur
> das letzte ServicePak einspielen.

Ja, ich habe schon mit NT gearbeitet (es installiert und standard SW
benutzt). Und das hat mir ehrlich gesagt gereicht. Das mit der mangelnden
Transparenz bei den service packs weiss ich von einem Arbeitskollegen, der
taeglich mit NT arbeitet, da er in Java programmiert und unter NT Java zur
Zeit noch performanter laeuft als unter Linux. Im Zusammenspiel von Java
IDEs (soweit ich mich erinnere Borland JBuilder) unter NT mit bestimmten 
service packs gibt's auch gewisse Probleme, die soweit gehen, dass die
Anwendung gar nicht laeuft. Das mit den seltsamen Netzwerk-Gruppen beim WINS 
server hat mir einer unserer NT-Admins gezeigt. Auch wenn man selbst nicht
sehr viel mit NT zu tun hat (und zu tun haben moechte), kann auf diese Weise
eine Menge drueber mitbekommen (wenn auch zugegenermassen nicht alles; 
dass nur der letzte service pack reicht, wusste ich nicht).

> > > > 2. Wenn man sich bei der Installation von NT fuer das NTFS als Dateisystem
> > > > entscheidet, wird trotzdem erst ein FAT installiert und dann beim
> > > > naechsten reboot ein NTFS draus gemacht. Warum? Warum nicht von Anfang an
> > > > ein NTFS, wenn der admin es sich so wuenscht?
> > 
> > > Das ist ein Implemtationsdetail, das ja nun wirklich absolut kein
> > > nennenswertes Kriterium darstellt. Linux kann bis heute mit dem
> > > Anwenderkernel keine Datei >2GB bearbeiten. Also ist Linux absoluter
> > > Schrott?
> >
> > Es mag vielleicht nicht nennenswert sein, aber es ist ein Zeichen, wie
> > sich Microsoft um updates kuemmert. Und es ist einfach umstaendlich. Das
> > mit der 2GB-Grenze mag im Enterprise-Bereich (vielleicht DBs?) von
> > Bedeutung sein. Fuer den Privat-Anwender oder den "normalen" Anwender ist
> > es weitgehend bedeutungslos.

> Verstehe: Wirklich problematische Grenzen unter Linux (sowohl für
> Enterprise als auch privat, z.B. Video-Bearbeitung) sind ja nicht so
> schlimm, aber absolute Nebensächlichkeiten unter NT, von denen man
> normalerweise nicht mal etwas mitbekommt und die abolut keinerlei
> negative Auswirkungen haben, sind eine Katastrophe und nur deshalb
> schon sollte man NT ächten?

Ich habe nie gesagt, dass die Punkte die ich in bezug auf NT angesprochen
habe, eine "Katastrophe" sind. Das ist wieder sowas, was Du
reininterpretiert hast. Warum kannst Du die Aussagen nicht einfach so
nehmen, wie sie dastehen anstatt irgend etwas dazuzuerfinden, das hinten und
vorne nicht stimmt? Das war doch bei Deiner ersten mail auch schon so, dass
Du mir nachgesagt hast, ich wuerde Unix "vergoettern" bzw. "anbeten" und
WinNT "blind bashen". Im uebrigen ist es NICHT so, dass ich mich "mit
aller Gewalt an irgend etwas festkralle".

Im uebrigen gibt es fuer glibc 2.1.3 basierte Linux-Systeme (momentan nur
SuSE 6.4, abgesehen von Systemen, die man selber hochgezogen hat) patches 
fuer den kernel, so dass file sizes > 2GB gehandled werden koennen. Was ich 
nicht sicher weiss, ist, ob es entsprechende patches auch fuer die user tools 
gibt. Soweit mir bekannt ist, ging's darum, dass die pointer nicht gross genug
waren, um die files entsprechend adressieren und damit ansprechen zu koennen.
Natuerlich gibt es auch im privaten Bereich Anwendungen, bei denen man das
2GB-Limit ueberschreiten kann, aber deswegen von "wirklich problematischen"
Grenzen zu sprechen (vor allem im privaten Bereich), halte ich fuer
ueberzogen. Du tust ja gerade so, als wuerden die meisten Linux-Anwender 
jeden Tag Video-Bearbeitung machen (dann koennte man tatsaechlich von einer
"wirklich problematischen" Grenze sprechen). Hier waere eine etwas
realistischere Sicht auf die Dinge sicherlich angebrachter. Aber es gibt ja,
wie bereits erwaehnt, patches.

Desweiteren hab ich nicht gesagt, dass man NT "nur deshalb" aechten sollte.
Von "Aechtung" habe ich ebenfalls nie gesprochen. Ich habe Punkte
aufgezaehlt, die aus der praktischen Sicht eines admins einfach nervig und
nicht von der Hand zu weisen sind. Natuerlich hat der Punkt mit dem NTFS
keine negativen Auswirkungen - mal abgesehen davon, dass es doppelt so lang
dauert, bis ich zum gewuenschten Dateisystem komme. Die anderen Punkte
- insgesamt fehlende Transparenz
- nicht boot-faehige service packs
- unsichere Anwendungen (vor allem Outlook; der Internet Explorer war lange
Zeit auch sehr unsicher)
sind nicht von der Hand zu weisen. Bei allen 3 genannten Punkten hatte ich
bisher nicht den Eindruck, dass Mircrosoft die Absicht verfolgt, daran etwas
zu aendern. Lediglich fuer den Internet Explorer gab's des Oefteren patches.

Ich vertrete schlicht und ergreifend die Auffassung, dass NT das Geld nicht
wert ist, das Microsoft dafuer verlangt (vor allem aus qualitativer Hinsicht
nicht). Gruende dafuer habe ich ja bereits genannt und es folgen auch noch
welche.

> Wenn du auf dem Niveau diskutieren willst, such dir jemand anderen,
> aber auf dieses Kindergartenniveau habe ich wirklich keinen
> Bock. Dafür ist mir meine Zeit zu schade.

Ein paar grundsaetzliche Fragen und die dazugehoerigen Gruende, warum ich
sie stelle:
- Hast Du schon mal in heterogenen Unix-Umgebungen gearbeitet? Wenn ja, wie
lange und was? (Hiermit meine ich praktische Arbeit am Rechner)
Wenn ich mir die Auslegung meiner Aussagen zum einen und Deine Aussagen zum
anderen anschaue, habe ich nicht den Eindruck, dass Du schon mal Unix-Systeme
administriert bzw. auf Unix-Systemen programmiert hast.
Wie gesagt, es ist nur ein Eindruck; ich habe NICHT gesagt, dass dem so ist.

- Wie kommst Du dazu, Dir ein Urteil ueber meinen Kenntnisstand zu erlauben,
ohne ihn zu kennen?
Du hast mir in einer Deiner letzten mails unterstellt, ich haette weder
Ahnung von NT noch von Linux. Was den administrativen Bereich anbelangt,
habe ich die Karten ja schon auf den Tisch gelegt. Daraus sollte auch fuer
Dich nachvollziehbar hervorgehen, dass ich Ahnung von Linux habe. Zur Zeit
arbeite ich bei einer Firma, die ein Dokumenten-Management-System fuer
Krankenhaeuser vertreibt. Das besteht insgesamt aus ca. 1 Million Zeilen C
code, davon bin ich fuer die Pflege und Weiterentwicklung von ca. 40000 
Zeilen zustaendig. Es laeuft unter Linux, Solaris und WinNT. 
Es ist in C geschrieben; als GUI wird Motif in Kombination mit Xmt verwendet. 
Setup tools sind in Tcl/Tk geschrieben, tools in perl. Ich bin fuer den
Linux sowie den Solaris port zustaendig. Um die Unix-Funktionalitaet
(speziell Motif) unter NT nutzen zu koennen, wird NutCracker eingesetzt.
Aus dem Gesagten sollte ersichtlich werden, dass ich es absolut nicht noetig
habe, mich von irgend jemandem grundlos dumm anreden zu lassen. Ausserdem
finde ich es sowieso nicht gut, wenn man jemandem einfach was unterstellt,
ohne Bescheid zu wissen. Das hat etwas mit grundlegenden
Charakter-Eigenschaften zu tun und hat in einer mail eigentlich nichts zu
suchen.

- Wieso interpretierst Du des Oefteren Sachen rein, die gar nicht dastehen?
Das verstehe ich ueberhaupt nicht. Dadurch dramatisiert Du nur unnoetig
meine Aussagen.

- Wieso liest Du Dir Absaetze nicht komplett durch und beurteilst die darin
getaetigten Aussagen als Ganzes?
Dadurch dass Du meine Aussagen teilweise nur halb durchliest, entstehen bei
Dir Missverstaendnisse, die nicht entstehen wuerden, wenn Du Dir die
Aussagen in den Absaetzen komplett durchlesen wuerdest. Ich lese mir ja
Deine Argumente auch komplett durch, bevor ich darauf antworte.

- Hast Du studiert?
Falls ja, habe ich irgendwie den Eindruck, dass Du theoretisch-abstrakte
Sichtweise auf die Dinge zu sehr verinnerlicht hast. Das wird z. B. an dem
Missverstaendnis mit dem "Dialog" deutlich oder auch daran, dass fuer Dich
praktische Dinge in den meisten Faellen absolut "nebensaechliche Details"
darstellen. Und wenn ich mich dann schon hinstelle und vom
"Kindergartenniveau" rede, muss ich selber ein bisschen auf Zack sein und
nicht nur um den heissen Brei herumreden, ohne konkrete Beispiele zu
bringen. Mal ganz abgesehen davon, dass es total arrogant ist, wenn man 
jemandem nachsagt, er wuerde auf einem
"Kindergartenniveau" argumentieren. Das findet man aber oefters und ist
nicht nur auf Dich allein bezogen (wobei ich aber NICHT sage, dass
grundsaetzlich jeder, der mal studiert hat, so ist). Ich kenne allerdings
von der FH her genug Leute, die sich aehnlich aeussern und fuer die
Argumente aus der Praxis grundsaetzlich "nebensaechliche
Details" darstellen. So was hefte ich unter der Rubrik "Zu Risiken und
Nebenwirkungen lesen Sie die Packungsbeilage und fragen Sie Ihren Arzt
oder Apotheker" ab.
Falls Du nicht studiert hast, ist es mir ein Raetsel, wie Du ueberhaupt zu 
Deiner Sichtweise kommst. 

> > > Und Implemtationsdetails von Linux, die bedeutend negativere
> > > Auswirkungen als obiges haben, gibt es zur Genüge. 
> 
> > Dann zaehl halt ein paar auf ,-)

> Von 2.0 über 2.2 bis 2.4 wurde jedesmal der Firwall- und
> Forwarding-Code komplett über den Haufen geschmissen. Bei MS hätte man
> im selben Fall öffentliche Verbrennung gefordert.

Den Grund fuer das rewriting des firewall code habe ich ja oben schon
genannt. Wie gesagt, es kommt auf den Grund an, warum der firewall code
ueber den Haufen geworfen wurde. Ausserdem haette ich MS bestimmt nicht die
Muehe gemacht, Konvertierungs-Scripts mitzuliefern. Denn das waere ja
kundenfreundlich und fuer diese Eigenschaft war diese Firma ja noch nie
bekannt.

Jetzt uebertreib mal nicht mit der "oeffentlichen Verbrennung". Fakt ist,
dass man bei Microsoft einfach zu wenig fuer das viele Geld geboten bekommt.
Da ist es doch kein Wunder, wenn die Aktivitaeten dieser Firma ein bisschen
kritischer gesehen werden. 

Ein wesentlich besseres Argument waere gewesen, wenn Du auf die
NFS-Probleme unter Linux (unter anderem UID/GID mapping von Leuten, die auf
verschiedenen Systemen unterschiedliche UIDs haben) zu sprechen gekommen 
waerst. Da wird sich jedoch in naechster Zeit was tun, da Sun die
Implementierung von NFS Version 3 unter die Sun Community License, die der
GPL aehnlich ist, gestellt hat. In einer der naechsten Kernel-Versionen wird
das neue NFS dann sicherlich auch auftauchen. 

Ueberhaupt muss man sagen, dass sich durch das Engagement von IBM, SGI und Sun 
im Linux-Bereich bezahlt macht. So stellt z. B. IBM sein JFS fuer Linux und 
das Java Development Kit zur Verfuegung. Von SGI stammen das XFS (ebenfalls 
ein journalig filesystem) sowie support fuer raw devices im kernel (wichtig 
fuer DBs), ein kernel debugger sowie einige OpenGL-Anwendungen und Sun 
steuert wie erwaehnt NFS Version 3 bei. Speziell die Neuerungen fuer den 
kernel werden Linux im Enterprise-Bereich auf die Spruenge helfen.

Was man auch noch gegen Linux anfuehren koennte, ist, dass es sehr lange
gedauert hat, bis die USB-Unterstuetzung in den kernel kam. Aber mit 2.4.0
bzw. 2.3.99 ist auch das behoben. Ein Arbeitskollege von mir hat sich mal
einen 2.3.99er kernel geholt, um den USB support mit seiner
Kodak-Digitalkamera zu testen. Das ging einwandfrei (das zugehoerige
Programm fuer Digitalkameras nennt sich "gphoto").

> Es gibt etliche Stellen, die mehr Hack als ordentliche Lösung
> darstellen. Das ist an sich ja auch kein Problem, in der Praxis kann
> man mit sowas leben.

Auch wieder so eine ungenaue Aussage. Um welche Stellen handelt es sich denn?

> Unverschämt finde ich es nur, wenn man bei Linux sowas als cool
> bezeichnet oder es schlicht unter den Tisch fallen lässt und im selben
> Atemzug wesentlich nebensächlichere Probleme von NT derselben Art als
> absolute Katastrophe hinstellt.
> Das hat nichts mit Sachlichkeit, sondern viel mehr mit Verbohrtheit zu
> tun.

Ich denke nicht, dass es die hacks an sich sind, die man als cool bezeichnet. 
Was als cool bezeichnet wird, ist zum Beispiel die Tatsache, dass es zum
Beispiel fuer die verschiedenen Pentium bugs wesentlich schneller
workarounds gegeben hat wie fuer NT. Im Englischen wird fuer so was
allgemein der Begriff "responsiveness" verwendet. Damit ist gemeint, in
welcher Art und Weise und wie schnell auf bug reports oder
Verbesserungs-Vorschlaege reagiert wird. Und hier sehe ich sowohl im
Open-Source-Bereich als auch bei den Anbietern von kommerziellen Unix-Derivaten 
klar Vorteile gegenueber Microsoft.

Und die angeblich so "wesentlich nebensaechlicheren" Probleme von NT hat
niemand als "Katastrophe" hingestellt. Insofern lasse ich mir auch nicht
nachsagen, dass ich "verbohrt" waere.

Zu guter Letzt: Du hast auf der Debian user mailing list erwaehnt, dass Du
begeisterter Linux user bist und dass Du NT nimmst, weil Du bei den
Anwendungen mehr Auswahl hast. Welche Anwendungen fehlen Dir denn unter
Linux?

Und noch mal danke fuer Deine Ausdauer beim Lesen der mail.

Gruss,

	Holger


------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie
bitte eine E-Mail an majordomo@jfl.de die im Body
"unsubscribe debian-user-de <deine emailadresse>"
enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@jfl.de
------------------------------------------------
Anzahl der eingetragenen Mitglieder:     729