1 Einleitung

Viele Computer-Anwender fragen heutzutage "Was kann Linux, das Windows nicht kann?" und "Kann mir Linux den Komfort und die Sicherheit bieten, den mir Windows bietet?". Diese Fragen werden hier nicht beantwortet, aber mit Hilfe des folgenden Vergleichs zwischen Linux und Windows soll dafür eine Entscheidungshilfe bereitgestellt werden.

Diese Informationen sind dabei nicht als absolut und unveränderlich zu betrachten. Sie sind vielmehr stark vom Einsatz-Szenario abhängig und werden sich im Laufe der Weiterentwicklung von Windows und Linux auch ändern. Letztlich ist zu erwarten, dass beide Systeme aus den Stärken und Schwächen des jeweiligen anderen lernen und sich weiterentwickeln. Denn "Konkurrenz belebt das Geschäft", wie man z.B. an Intel und AMD sehen kann, die auf dem Prozessor-Sektor in einem ähnlichen Wettbewerbs-Verhältnis stehen.

Ein Vergleich der beiden Betriebssysteme Linux und Windows ist ein komplexes und subjektives Thema. Beide Systeme bieten inzwischen eine überwältigende Fülle von Funktionalitäten an und die Bewertung dieser Eigenschaften ist stark abhängig vom Einsatzzweck (Desktop-Computer, Workstation, Server, Embedded Devices). Außerdem kennt sich kaum mehr jemand auf beiden Systemen bis auf die Detailebene hinunter gleich gut aus.

Daher soll hier keine Wertung in Form von Noten oder Punkten vorgenommen werden, sondern die aus unserer Sicht positiven und negativen Eigenschaften beider Systeme einander strukturiert gegenübergestellt werden. Jeder soll dann selbst entscheiden, welche dieser Eigenschaften für ihn wichtig sind und welche nicht.

(Fast) alles, was hier zu Linux gesagt wird, gilt übrigens auch für andere UNIX-Systeme (z.B. OpenBSD, Solaris, HP-UX, AIX), trotzdem wird hier immer der Begriff "Linux" verwendet.

1.1 Eine Bitte

Wenn Sie daher Ergänzungen, Vorschläge, Wünsche oder Fehlerkorrekturen haben, mailen Sie uns diese bitte einfach zu. Wir werden Ihre Anregungen dann gerne in unseren Vergleich "Windows versus Linux" einarbeiten.

1.2 Parallelbetrieb

• Auf 2 getrennten PCs oder einem PC mit Wechselplatten-Laufwerk…

• Linux und Windows können auf einem PC nebeneinander installiert werden (auf getrennten Partitionen oder Platten). Beim Booten ist dann eine Auswahl zu treffen, welches der beiden Betriebssysteme man gerade nutzen möchte. Häufig wird nach einer kleinen Wartezeit eines der installieren Betriebssysteme automatisch als Standard gestartet.

  Die wichtigsten Linux-Distributionen erkennen bei ihrer Installation ein bereits installiertes Windows-System, reduzieren automatisch die Windows-Partitionsgröße (wenn genug Plattenplatz vorhanden ist), um Raum für eine Linux-Partition zu schaffen, und richten einen Boot-Loader (z.B. GRUB, LILO) ein, der beim Booten eine Auswahl des zu startenden Betriebssystems zulässt.

  Wichtig ist, dass Linux nach Windows installiert wird, da es alle vorher installierten Systeme erkennt und im Bootmenü berücksichtigt. Windows installiert sich hingegen ohne Beachtung vorhandener Betriebssysteme, diese sind dann entweder zerstört oder zumindest nicht mehr direkt bootbar.

  Der Platzbedarf für die Linux-Partition inklusive einer Grundausstattung an Anwendungs-Software beträgt etwa 2-4 GByte. Wird die mitgelieferte Anwendungs-Software vollständig installiert, sind 7-8 GByte notwendig.

• Mit einer sogenannten Linux-Live-CD/DVD (z.B. Knoppix ) kann Linux ohne Installation und damit ohne jede Veränderung am eigenen PC ausprobiert werden. Bei Bedarf können sogar System-Einstellungen und persönlichen Dateien dieses Linux-LIVE-Systems als Image-Datei auf dem Windows-Dateisystem abgespeichert werden, um nicht immer wieder von vorne alles einrichten zu müssen und Dateien auch speichern zu können. Diese Art des Linux-Einsatzes ist aber je nach CD/DVD-Laufwerk-Geschwindigkeit und Speicherausbau mit Performanz-Einbußen behaftet (z.B. starten alle Programme deutlich langsamer).

• Bei einigen Linux-Live-Systemen kann auf der Windows-Partition oder einem USB-Stick eine Datei abgegelegt werden, die ein Image einer Partition darstellt. Hier werden die System-Einstellungen und die Benutzer-Daten gespeichert und können so bei nächsten Booten wieder verwendet werden. Diese Datei wird meist automatisch erkannt und eingebunden.

• Eine weitere Alternative ist der Betrieb von Linux in einer virtuellen Maschine unter Windows (z.B. unter VMware ) oder umgekehrt. Dann können Windows und Linux parallel laufen und z.B. sogar Cut/Copy&Paste zwischen den beiden Systemen genutzt werden. Auch hier ist je nach Prozessor-Geschwindigkeit und Speicherausbau mit (leichten) Performanzeinbußen zu rechnen.

• Die letzte Alternative ist der Einsatz eines Windows-Emulators (z.B. WINE, CrossOver von CodeWeavers, Win4Lin ). Damit können viele Windows-Programme (z.B. die komplette Office-Suite) auch direkt unter Linux genutzt werden (leider nicht alle, z.B. PhotoShop, ImageReady). Sogar Cut/Copy&Paste zwischen den beiden Systemen ist möglich. Auch hier gibt es je nach Prozessor-Geschwindigkeit und Speicherausbau (leichte) Performanz-Einbußen (vor allem beim Starten von Programmen).

1.3 Philosophie-Vergleich

Die Philosophien von Windows und Linux unterscheiden sich sehr. Die folgende Tabelle listet die 4 Grundphilosophien der beiden Systeme auf und gibt Beispiele für ihre Ausprägungen.

1.4 Links

• Security Report: Windows vs Linux (The Register, eng)
• Linux versus Windows (Lehrer-Online, deu)
• Linux versus Windows (c't 17/2000, S. 90)
• Warum ist Linux schlecht (Argumente von Microsoft, deu)
• Vergleich Linux versus Windows (Michael Prokop, deu)
• Microsoft Windows NT Server 4.0 versus UNIX (eng)
• Linux is Not Windows (eng)
• Linux ist nicht Windows (deu)
• Why Linux?
• Windows v Linux security: the real facts

2 Tabellarischer Vergleich

2.1 Grundlegende Merkmale

2.2 Technische Merkmale

2.3 Usability

2.4 Grafische Oberfläche

2.5 Dateisystem

2.6 Kommandozeile

2.7 Sicherheit

3 Detaillierter Vergleich

3.1 Administrator

Unter Windows heißt der Administrator "Administrator". Er kann noch durch Zugriffsrechte eingeschränkt sein. Es kann noch weiteren Benutzern der Kontotyp "Computer-Administrator" zugewiesen werden. Zwischen allen diesen Administratoren besteht kein Unterschied.

Unter Linux gilt: An der grafischen Oberfläche grundsätzlich nicht als Administrator anmelden, sondern bei Bedarf mit "su" oder "sudo" oder ähnlichen Mechanismen nur für ein Programm oder Fenster auf den Administrator umschalten. Es ist absolut unüblich (und auch nicht notwendig), dass normale Anwender mit Administrator-Rechten arbeiten.

Anwender-Programme mit Administrator-Rechten laufen lassen, ist nicht notwendig (bzw. durch "sudo" und das Set-UID/GID-Recht für einzelne Programme einstellbar doch möglich, ohne das Administrator-Passwort kennen zu müssen).

Unter Windows bleibt einem gar nichts anderes übrig, als sich an der grafischen Oberfläche als Administrator anzumelden, wenn man den Rechner verwalten will.

Dass man auf seinem Rechner als einziger Anwender arbeitet und sich daher der Einfachheit halber auf vielen Windows-Rechnern als Administrator anmeldet oder seinem Account den Kontotyp "Computer-Administrator" gibt, ist eine sehr schlechte Angewohnheit. Behält man diese Angewohnheit unter Linux bei (obwohl sie dort nicht üblich und auch nicht notwendig ist), dann ist das Linux-System wieder genauso offen für Angriffe wie ein Windows-System, es besteht kein prinzipieller Unterschied mehr.

3.2 Anmelden/Einloggen

Bei Windows NT/2000/2003/2008/XP/Vista/7 wird inzwischen streng getrennt zwischen dem Administrator und den einzelnen Benutzern. Allerdings gibt es keinen Zwang, sich auf einem Rechner anzumelden, er kann z.B. mit einem Standard-Benutzer ohne Passwort eingerichtet sein. Viele private Anwender machen dies auch so oder arbeiten gleich als Administrator, da sie in der Regel der einzige Benutzer des Windows-Rechners sind.

Unter Linux muss man sich stets mit einem Benutzernamen + Passwort anmelden. Somit weiß das System immer, wer man ist. Dem Anwender wurden beim Einrichten vom System-Administrator gewisse Rechte oder Verbote erteilt. Er kann auf dem System genau diejenigen Dateien einsehen, ändern oder löschen, wie es ihm vom Administrator erlaubt wurde. Die eigentlichen Systemdateien darf er beispielsweise nicht ändern. So kann man nicht aus Versehen das System beschädigen, Konfigurations-Dateien löschen oder gar die Festplatte formatieren. Von ihm neu angelegte Dateien und Verzeichnisse werden automatisch diesem Benutzer zugeordnet.

Bei der grafischen Oberfläche KDE kann sogar eingestellt werden, dass beim Start ein Benutzer automatisch angemeldet wird (war bei SuSE-Linux mal die Standard-Einstellung). Dies ist aber sicherheitstechnisch überhaupt nicht sinnvoll.

Man kann unter Linux auch nicht auf die Dateien von anderen Anwendern zugreifen oder diese einsehen (ob lokal oder über das Netz), außer es wurde explizit von diesen erlaubt. Grundsätzlich gilt folgende Regel: "Es ist alles verboten, das nicht ausdrücklich erlaubt ist". Daher bitte nicht wundern, wenn ab und zu die Meldung "Permission denied" angezeigt wird.

3.3 Anwendungen

Linux bietet ebenfalls viele Anwendungs-Programme, die aber nicht immer die Funktionalität und Usability von Windows-Programmen erreichen. Allerdings ist hier die Frage, ob normale Anwender z.B. wirklich alle Features des Microsoft Office-Pakets benötigen oder ob nicht "weniger mehr wäre".

Weiterhin gibt es unter Linux bei einigen Spezialanwendungen wie CAD-Programmen, Programmier-IDEs, Home-Banking, Branchenlösungen, Konfigurations-Management, CRM, ERP,… eine deutlich geringere Auswahl an Software-Produkten. Dies hat seine Ursache auch in der Weigerung einiger Software-Hersteller (z.B. Microsoft: Office, Adobe: Acrobat-Writer, AutoDesk: AutoCAD, …), ihre Software auf Linux zu portieren.

Diese Situation wird sich mit zunehmender Verbreitung von Linux verbessern.

3.4 Auslagerungsdatei/Swap

Unter Linux wird eine Swap-Partition mit fixer Größe (meist 1- bis 2-fache Hauptspeichergröße) verwendet, die beim Installieren des Systems (oder auch später) angelegt wird. Es sind weitere Swap-Partitionen fester Größe auf beliebigen Laufwerken möglich. Bei kurzzeitigem Bedarf sind zusätzlich Swap-Dateien fester Größe einsetzbar (dies ist aber kein Standard unter Linux).

Bei Windows ist eine Änderung der Größe einer Auslagerungsdatei oder das Hinzufügen zusätzlicher Auslagerungsdateien nur dann wirksam, wenn der Rechner danach neu gebootet wird. Bei Linux können Swap-Partitionen und Swap-Dateien während dem Betrieb "on-the-fly" (de)aktiviert werden.

Bei Linux kann die Swap-Partition ohne Probleme weggelassen werden, wenn der Hauptspeicher genügend groß ist. Bei Windows sollte die Auslagerungsdatei nicht deaktiviert werden (auch wenn dies prinzipiell möglich ist), sonst kann es zu seltsamen Effekten kommen (welchen?).

Bei Linux wird die Swap-Partition erst dann genutzt, wenn der Hauptspeicher nicht mehr ausreicht, dies sorgt für maximale Performanz Bei Windows wird die Auslagerungsdatei bereits vom Booten an benutzt, dies kostet Performanz.

Die Vorgehensweise von Windows mit einer in der Größe dynamisch änderbaren Auslagerungs-Datei statt ainer statischen Swap-Partition ist zwar flexibler, hat aber auch Nachteile:

• Eine Auslagerungsdatei ist langsamer als eine Swap-Partition, da das Dateisystem darunter Performanz kostet.
• Die Auslagerungsdatei stört beim Sichern und beim Image-Ziehen des Dateisystems, auf dem sie liegt.
• Die dynamische Größe der Auslagerungsdatei sorgt mit der Zeit für eine "Fragmentierung" dieser Datei über die ganze Platte hinweg (abhängig von der Qualität des Dateisystems). Dies kann Performanz kosten. Es ist daher unter Windows ab und zu sinnvoll, die Platte mit der Auslagerungsdatei zu defragmentieren, damit diese wieder "am Stück" auf der Platte liegt.

Es ist zu vermuten, dass Windows eine Auslagerungsdatei verwendet, weil normale Windows-Anwender mit einer nicht formatieren Swap-Partition ohne Laufwerksbuchstaben nicht zurechtkämen. Unter Windows werden letztlich die Begriffe Dateisystem (logische Struktur) und Partition (Hardware) nicht sauber getrennt.

3.5 Ausführbare Dateien

Unter Linux werden beliebige Dateien durch ein Ausführungs-Recht (x=executable) zu einem ausführbaren Programm gemacht. Anhand eines Präfix bei Binärdateien oder einer sogenannten "Shee-Bang-Zeile" der Form #!/PFAD/ZU/PGM im Dateikopf bei Skripten kann Linux erkennen, wie diese Programm-Datei beim Ausführen genau zu starten ist. Der Inhalt einer solchen Datei muss natürlich ein sinnvolles Programm sein, sonst "hagelt" es Fehlermeldungen.

D.h. Programme in Skript-Sprachen wie Shell, Awk, Perl, PHP, Tcl/Tk, Python, Ruby, Lua können unter Linux wie jedes andere Programm oder Kommando aufgerufen werden.

Häufig wird unter Windows bereits beim Download einer Datei im Web-Browser die Extension interpretiert und das Programm im Falle einer EXE-Datei z.B. sofort zur Ausführung angeboten. Dies ist zwar sehr bequem, aber auch sehr unsicher.

Bei Linux wird das Ausführungsrecht nicht mit übertragen, d.h. Downloads sind nicht sofort ausführbar, sondern müssen erst gespeichert und dann mit dem Ausführungs-Recht versehen werden.

3.6 Dateinamen

Linux kennt aufgrund der verwendeten Dateisysteme schon immer lange Dateinamen (bis 1024 Zeichen) und erlaubt eine maximale Pfadnamenlänge von 4095 (UNIX-Systeme hatten anfangs eine maximale Dateinamenlänge von 14 Zeichen, Pfadnamen waren auf 255 Zeichen beschränkt).

In Dateinamen sind folgende Zeichen nicht erlaubt (siehe MSDN: Naming Files, Paths, and Namespaces)

• Linux: 2 Zeichen:
  • / (Verzeichnistrenner)
  • NUL-Byte (Kennzeichnet das Ende eines Strings in C)
• Windows: 9 + 1 + 31 = 41 Zeichen:
  • : (Laufwerktrenner)
  • \ (Verzeichnistrenner)
  • ? * (Dateisuchmuster)
  • < > | (Umlenkungen und Pipe)
  • " / (Quotierung und ???)
  • NUL-Byte (Kennzeichnet das Ende eines Strings in C)
  • Steuerzeichen mit Code 1-31 (außer in Alternate Data Streams)
  • Leerzeichen oder Punkt am Ende eines Dateinamens
  • Folgende spezielle Dateinamen CON, PRN, AUX, NUL, COM1-9, LPT1-9 (ohne und mit Extension)

Windows unterscheidet Groß- und Kleinschreibung beim Zugriff nicht. Beim Anlegen wird die Datei/das Verzeichnis in genau der Schreibweise angelegt, die angegeben wurde. Diese Schreibweise wird auch zur Anzeige im Windows Explorer bzw. beim Kommando DIR benutzt. Die 8+3-Kurznamen werden immer mit Großbuchstaben dargestellt und sind nur beim Kommando DIR /X (extended) oder in alten Windows-Anwendungen sichtbar.

Linux unterscheidet immer zwischen Groß- und Kleinschreibung, auch bei Dateinamen. In einem Linux-Verzeichnis könnten z.B. die Dateien "TEXT", "Text", "tExT" und "text" liegen. Es handelt sich dabei um unterschiedliche Dateien, die natürlich auch einen unterschiedlichen Inhalt haben können (ob diese Namen gleichzeitig verwendet werden sollten, sei dahingestellt ;-).

Unter Linux werden (im Gegensatz zu Windows) Leerzeichen und Sonderzeichen wie äöüÄÖÜß in Verzeichnis- und Dateinamen kaum verwendet. Sie sind aber prinzipiell möglich, allerdings nur im Zusammenhang mit geeigneter Quotierung ("…" '…' \C). Unter Windows ist das Leerzeichen ein sehr häufiges Zeichen in Dateinamen (leider), besser wäre es, dafür einen Unterstrich zu verwenden.

Unter Linux stellt der Punkt "." in Dateinamen keine Trennung zwischen Name und Extension dar (wie unter Windows), sondern er ist ein ganz normales Zeichen. Unter Windows ist z.B. die Verwendung von zwei Punkten in Dateinamen "gefährlich", weil nicht genau definiert ist, welche der beiden Endung dargestellt wird und welche der zwei Endungen wirklich interpretiert wird (siehe ILOVEYOU-Virus).

Unter Linux werden Dateien "versteckt", indem als Dateinamenanfang ein Punkt "." verwendet wird. Unter Windows wird dies durch das Dateiattribut HID(DEN) erreicht.

Unter Linux hat die Endung/Extension einer Datei eher informativen Charakter und wird von den Anwendungen nicht benötigt, unter Windows muss man dagegen auf die korrekte Dateiendung achten. So sollte dort z.B. bei einem Textdokument die Endung ".txt" lauten, da mit dieser Anklicken Unter Linux kann man die Endung beliebig wählen (z.B. ".txt", ".dokument", ".privat") aber auch ein Dateiname ohne Endung ist möglich. Linux erkennt über den Datei-Inhalt, um welchen Dateityp es sich handelt.

Allerdings kennen unter Linux Desktop-Systeme wie KDE, Gnome oder auch Web-Browser die Möglichkeit, Dateien mit einer bestimmten Endung einer Anwendung zuzuordnen. Diese Zuordnungen sind (wie bei Windows) vom Anwender konfigurierbar.

3.7 Dateisystem

Linux kann auf jeden Fall immer auf alle Windows-Dateisysteme lesend und schreibend zugreifen während umgekehrt Windows leider nicht auf alle Linux-Dateisysteme zugreifen kann (es gibt aber Zusatz-Software für diesen Zweck).

Unter Windows gibt es pro Partition bzw. pro verbundener Netzwerk-Freigabe einen Laufwerksbuchstaben A:, B:, C:, D:,… mit jeweils einem eigenen Dateibaum. Zumindest Laufwerk C: existiert immer.

Unter Linux gibt es nur einen einzigen Dateibaum, in dem die Dateisysteme der einzelnen Partitionen in bestimmten (leeren) Verzeichnissen "eingehängt" (montiert) werden. Startpunkt ist die "root"-Partition, die beim Booten vom Kernel montiert wird. In den Dateibaum dieser Partition werden gemäß den Angaben in der Datei /etc/fstab gegebenenfalls weitere Partitionen eingehängt.

Bevor unter Linux ein Datenträger (Platte, CD, Diskette, USB-Stick, …) benutzt werden kann, muss er "eingehängt" (montiert) werden. Analog muss er "ausgehängt" (demontiert) werden, bevor er wieder entfernt werden darf. Das Dateisystem auf dem Datenträger erscheint an einer (meist wählbaren Stelle) des Gesamt-Dateisystems, z.B. unter /media/dvd, /media/usb, …). Inzwischen ist auch unter Linux ein "Hotplugging" möglich, bei dem das Montieren durch das Einstecken/Anschließen des Datenträgers automatisch ausgelöst wird.

Windows macht das "Einhängen" automatisch und blendet das Dateisystem unter einem Laufwerkbuchstaben (z.B. E:, F:, …) ein. Das "Herausziehen" des Datenträgers unter Windows sollte wie bei Linux vorher durch die Funktion "Hardware sicher entfernen" angekündigt werden, sonst sind Datenverluste vorprogrammiert. Da Windows jederzeit mit dem unangekündigten "Herausziehen" des Datenträgers rechnen muss, kann es meist nicht so ausgeklügelte Chaching/Pufferungs-Mechanismen wie Linux einsetzen.

3.8 Datenschutz

Microsoft sagt bis heute nicht eindeutig, welche Daten dabei genau übertragen werden. Dieses Wissen liegt vielleicht sogar nirgendwo vollständig vor, sondern ist aufgeteilt auf Hunderte von Programmierteams.

Zitat Wilhem Hoegner (Projekt LiMux in München): "Einen Einsatz solcher Programme in einer öffentlichen Verwaltung, wo strengster Datenschutz herrschen muss, kann eigentlich niemand verantworten."

3.9 Dokumentation

Die eigentlichen "Innereien" von Windows, Teile seines API (Application Programming Interface) und viele der von Windows(-Anwendungen) verwendeten Datenformate (NTFS, Registry, Office-Dokumente, …) sind hingegen weniger gut dokumentiert. Vieles was hier bekannt ist, wurde von Freiwilligen durch "Reverse Engineering" ermittelt. Allerdings wird diese Fleißarbeit aufgrund der regelmäßigen Erweiterungen und Änderungen des Herstellers Microsoft immer wieder notwendig.

Die Hersteller von Windows-Anwendungen und Windows selbst sind der Meinung, dass dies ihre Geschäftsgrundlage sichert und das Windows-System sicherer macht. Darauf gibt es eine ganz einfache Antwort: "Security by obscurity doesn't work" [Bruce Schneier].

Linux und seine Anwendungen sind ebenfalls gut dokumentiert, meist in Form von englisch-sprachigen man- oder info-Pages oder Textdateien. Übersetzungen für viele dieser Informationen sind vorhanden, wenn auch nicht immer auf dem aktuellen Stand oder völlig fehlerfrei. Für viele Anwendungen gibt es eine eingebaute elektronische Hilfe und nicht zuletzt sind inzwischen auch in diesem Bereich sehr viele (englische und deutsche) Bücher von ausgewiesenen Experten erhältlich.

Folgende entscheidenden Unterschiede zu Windows gibt es allerdings:

• Die "Innereien" von Linux sind vollständig offengelegt.
• Das API (Application Programming Interface) von Linux und der zum Programmieren verwendeten Bibliotheken (X, Qt, GTK, GTK+, …) ist vollständig offengelegt.
• Die verwendeten Dateiformate sind vollständig offengelegt.
• Der Quellcode zu Linux und vielen Linux-Anwendungen ist verfügbar.

3.10 Drucken

Drucken unter Linux ist ein Kapitel für sich, denn es geht grundsätzlich von einem PostScript-Drucker als Druckmodell aus. Schließt man also einen PostScript-Drucker an, so kann man ihn auf jeden Fall vernünftig ansteuern. Alle anderen Drucker werden über sogenannte Filter angesteuert, die die PostScript-Kommandos in die jeweilige Druckersprache umwandeln. Im Extremfall wird dann die komplette Druckaufbereitung unter Linux durchgeführt und nur noch Pixel an den Drucker geschickt (ähnlich wie dies unter Windows für GDI-Drucker stattfindet). Dieser ganze Konvertierungsvorgang wird von GhostScript (einem freien PostScript-Interpreter) und anderen Hilfsprogrammen durchgeführt.

Konnten früher nur wenige Drucker angesteuert werden, hat sich die Situation inzwischen entscheidend verbessert. Bereits bei der Installation werden von dem mittlerweile standardmäßig eingesetzten modernen Drucksystem CUPS (Common UNIX Printing System) sehr viele Drucker erkannt und korrekt eingebunden.

Bei sehr neuen Drucker-Modellen kann es natürlich immer noch Probleme geben, wenn der Hersteller z.B. keine Linux-Treiber mitliefert. Findet man zu diesem Drucker allerdings eine sogenannte PPD-Datei (PostScript Printer Description), dann kann man ihn auf jeden Fall mit allen seinen Eigenschaften (Schächte, Duplex, Schwarzweiß/Farbe) unter CUPS in Betrieb nehmen.

Es gibt inzwischen für Linux auch kommerzielle Druckertreiber-Sammlungen (z.B. Turboprint, ESP Print Pro), die für relativ wenig Geld sehr viele Drucker mit sehr hoher Qualität ansteuern können.

3.11 Erlernbarkeit

Spätestens dann erkennt man, dass man einige Jahre (oder sogar Jahrzehnte) langsam und stetig in die Windows-Welt "hineingewachsen" ist und dabei einen nicht zu unterschätzenden Lernaufwand hatte (der sich aber auf einen sehr langen Zeitraum verteilt hat).

Lässt man Leute mit Systemen unter Linux (oder Apple) arbeiten, die bisher kaum Computer bedient haben, so kommen diese in der Regel sehr gut zurecht. Sie sind noch nicht an eine bestimmte "Bedienphilosophie" gewohnt und daher oft flexibler als jemand, der schon immer unter Windows arbeitet.

Nicht zuletzt zeigt die Vielzahl der zu Windows angebotenen Kurse, dass sich das System (und die darauf laufenden Anwendungen) mitnichten von selbst erklärt, sondern die Anwender und System-Administratoren auch hier erst mal lernen müssen.

Die gute Botschaft lautet allerdings: "Linux lässt sich ausgehend von Windows erlernen", weil vieles aus der Windows-Welt schon bekannt ist und unter Linux genauso aussieht und funktioniert. Die Frage ist dann nur noch, ob man das fehlende Delta noch "draufpacken" will, oder lieber bei dem mit Windows erreichten Stand bleibt.

3.12 Garantie

Linux und unter der GPL veröffentlichte Software schließen eine Haftung generell aus. D.h. die Software wird auf eigenes Risiko eingesetzt, es gibt niemanden, den man bei Fehlfunktionen oder fehlender Funktionalität verantwortlich machen kann. Eine Garantie wie bei Windows für Datenträger-Ersatz oder Rückzahlung der Lizenzkosten bei nicht erfüllter Funktionalität gibt es nicht (es sei denn, ein Distributor bietet sie für sein Linux-Paket an). Allerdings ist dies aufgrund der geringen bis gar nicht vorhandenen Lizenzkosten sowieso nicht notwendig.

Zwischen den beiden Betriebssystemen besteht hier also kein wesentlicher Unterschied.

3.13 Gerätedateien (Devices)

3.13.1 Linux

Jegliche Hardware (bis auf Netzwerkkarten ;-) wird unter Linux als Gerätedatei angesprochen. Handelt es sich um Hardware mit wechselbaren Datenträgern, so muss man die darin eingelegten/angesteckten Datenträger klar vom Gerät selbst unterscheiden. Damit auf einen solchen Datenträger zugegriffen werden kann, muss er vorher unter einem (leeren) Verzeichnis montiert (eingehängt) werden. Der Inhalt des Datenträgers wird dann unterhalb dieses Verzeichnisses in den Dateibaum eingeblendet. Soll der Datenträger wieder entfernt werden, muss er vorher demontiert (ausgehängt) werden. Bei diesem Vorgang werden evtl. noch verzögerte Schreibvorgänge abgeschlossen (sync). Solange ein Datenträger also montiert ist, kann er in der Regel nicht aus dem Gerät entfernt werden. Alle Gerätedateien sind im Verzeichnis /dev (devices) zu finden, typische Gerätedateien sind z.B.:

Einige Pseudogeräte zu Spezialzwecken sind z.B.:

Es werden 2 prinzipielle Arten von Gerätedateien unterschieden:

Hier eine von ls -l /dev produzierte Liste von Gerätedateien (c=character, b=block):

  brw------- 1 root   disk  27, 16 2004-12-31 19:08 zqft0
  crw-rw-rw- 1 root   root  27, 16 2005-01-09 15:16 zero
  crw-rw-rw- 1 root   root   1,  3 2005-01-09 15:16 null
  crw-rw-rw- 1 root   root   1,  8 2005-01-09 15:16 random
  crw-r--r-- 1 root   root   1,  9 2005-01-09 15:16 urandom
  brw-rw---- 1 root   disk   3,  0 2005-01-09 17:19 hda
  brw-rw---- 1 root   disk   3,  1 2005-01-09 17:19 hda1
  crw------- 1 user   audio 14,  4 2005-01-09 17:19 audio


Hinter jeder Gerätedatei steckt ein Treiber (device driver), der beim Lesen von/Schreiben auf diese(r) Datei automatisch vom Kern angesprochen wird. Listet man die Gerätedateien in /dev auf, dann sieht man anstelle der Dateilänge (die sinnlos wäre, da es sich ja um keine echten Dateien handelt) 2 Zahlen: die Major und die Minor Device Number. Erstere adressiert den Treiber über eine Sprungtabelle, die zweite wählt bei Verwendung des gleichen Treibers (z.B. für Festplatten) die Untereinheit eines Gerätes aus (z.B. Partition).

Damit auf ein Gerät lesend/schreibend zugegriffen werden kann, müssen die Zugriffsrechte entsprechend gesetzt sein. Viele Geräte gehören dem Benutzer root und der Gruppe root (das ist ein Unterschied!) und für "Alle anderen" sind keine Zugriffsrechte gesetzt. Diese Geräte können dann von normalen Benutzern nicht verwendet werden. Dazu gehören z.B. Festplatten oder CD/DVD-Brenner.

Für einige spezielle Geräteklassen gibt es besondere Gruppen, in die man Benutzer eintragen muss, wenn sie auf diese Geräte Zugriff haben sollen. Dazu ist in der Gruppenbeschreibungs-Datei /dev/group hinter dem Gruppennamen die Liste der Mitglieder zu erweitern.

Eine andere Alternative sind sogenannte Set-UserID/GroupID-Programme, um auf Geräte zuzugreifen. Sie schalten beim Aufruf den Prozessbesitzer bzw. die Prozess-Besitzergruppe vom Aufrufer auf den Besitzer des Programms (häufig root) um. Der Prozess hat dann aufgrund der Besitzverhältnisse und der Zugriffsrechte der Gerätedatei in /dev das Recht, mit ihr zu arbeiten.

Dazu können z.B. die CD/DVD-Brennprogramme k3b oder xcdroast gehören. Weitere Programme dieser Art findet man durch find / -type f \( -perm -4000 -o -perm -2000 \) -ls. Auf einem sicheren System sollten nur sehr wenige Programme mit diesen Rechten ausgestattet werden, da dies eine Sicherheitslücke darstellen kann.

3.13.2 Windows

Der Zugriff auf Geräte wird nicht über Dateirechte geregelt, sondern über den HAL (Hardware Abstraction Layer).

3.14 Grafische Oberfläche (GUI)

Die Windows GUI hat sich über die verschiedenen Windows-Versionen stark verändert (was grafisches Aussehen und Zugriff auf die einzelnen Komponenten betrifft) und wird sich auch in der nächsten Version wieder ändern. In einer bestimmten Windows-Version besteht aber keine Wahlmöglichkeit der GUI, außer dass alle Windows-Versionen ab Windows XP auf eine GUI im Windows 2000 Design umgeschalten werden können.

Das Verstecken des Betriebssystems und seiner Komplexität hinter einer grafischen Oberfläche hat seine Vorteile, aber auch Schattenseiten:

• Die Komplexität verschwindet dadurch nicht, sie ist nach wie vor vorhanden. Dies bedeutet unter anderem, der Anwender muss immer noch wissen, was er tut, das nimmt ihm die grafische Oberfläche nicht ab.
• Grafische Oberflächen führen bei Problemen zu hektischem "Herumklicken" und "Ausprobieren". Eine systematische Fehlersuche ist häufig nicht möglich, weil nicht klar ist, was genau die Mausklicks im Hintergrund auslösen.
• Die Bedienung eines Computers über eine Grafische Oberfläche wird als schnell und einfach empfunden. Sind Tätigkeiten wiederholt durchzuführen oder Daten mehrfach zu verwenden, ist das Arbeiten damit jedoch häufig eine Qual.
• Es gibt immer noch Tätigkeiten, die nicht über die grafische Oberfläche durchführbar sind. Dann muss man doch wieder auf die Kommandozeile ausweichen und es sind doch genaue Kenntnisse über das Betriebssystem notwendig.
• Grafische Oberflächen lassen sich schlecht "automatisieren". Soll also die gleiche Tätigkeit wiederholt werden, so ist jeder Mausklick erneut durchzuführen, sie lassen sich nicht "programmieren". Hier haben zwar Windows-Tools wie AutoIt oder der Windows-Scripting-Host oder Linux-Tools wie KCOP bzwl DCOP Abhilfe geschaffen, aber entweder sind diese Tools kostenpflichtig oder ihr Einsatz erfordert mehr Aufwand (weil z.B. das "Aussehen" oder die "Struktur" der grafischen Oberfläche sich ändert).
• Ein erfahrender Anwender arbeitet mit Tastatur und kommando-orientierter Bedienung meist schneller und fehlerfreier (GUIs "nerven" ihn eher!).
• Remote-Administration ist damit schlecht möglich (besonders über langsame Verbindungen wie Telefon oder Handy).

Bei Linux wird eindeutig zwischen dem Betriebssystem-Kern an sich und der grafischen Oberfläche unterschieden. Linux lässt sich jederzeit auch ohne grafische Oberfläche betreiben, gerade im Server-Bereich ist dies häufig der Normalfall. Hierdurch spart man Speicherplatz und gewinnt Performanz, Sicherheit und Stabilität, denn grafische Oberflächen sind aufgrund ihres Umfanges und ihrer Komplexität eine notorisch fehlerbehaftete Software (der KDE-Desktop umfasst z.B. inzwischen mehr Programmzeilen als der Linux-Kernel). Trotzdem lassen sich in einem "Terminal" über eine Shell alle notwendigen Aufgaben effizient und komfortabel erledigen.

Ein Nachteil der kommando-orientierten Bedienung ist die längere "Anlaufzeit", bis man damit gut umgehen kann. Mit einer Grafischen Oberfläche kann man dagegen in der Regel sofort "loslegen".

Grafische Oberflächen sind natürlich auch unter Linux verfügbar. Der wesentliche Unterschied liegt aber darin, dass diese Oberfläche (meist das X Window-System) kein fester Bestandteil des Betriebssystems ist, sondern wie jedes andere Anwender-Programm auch gestartet wird (ohne Administrator-Rechte). D.h. Fehler darin oder ein Absturz der grafischen Oberfläche haben keine Auswirkung auf das eigentliche Betriebssystem (wie bei Windows).

Die Entkopplung von Betriebssystem und GUI ist auch der Grund für die einfache Remote-Anwendung und -Administration von Linux.

Unter Linux gibt es keine einheitliche grafische Oberfläche, sondern sehr viele Varianten, die zwei bekanntesten sind KDE und Gnome. Diese Vielfalt ist zwar etwas verwirrend und kann als Nachteil gewertet werden, aber man kann so auch eine genau für den beabsichtigten Einsatzzweck passende grafische Oberfläche auswählen. Z.B. kann man Linux im Prinzip wie Windows aussehen lassen, was manchem Anwender vielleicht die Migration erleichtert. Der Grund für diese Flexibilität ist natürlich, dass die GUI optional ist, d.h. für den eigentlichen Betrieb gar nicht notwendig ist.

Der wesentliche Vorteil von grafischen Oberflächen ist die "Führung", die sie einem unerfahrenen Anwender geben. Er kann keine groben Fehler mehr begehen. Allerdings kann er immer noch viele kleine Fehler begehen, indem er z.B. vergisst, ein Kästchen anzukreuzen. Oder er "verläuft" sich in den vielen Dialogboxen, die ständig "aufpoppen". Oder er "irrt" sich in der Bedeutung von Dialogbox-Elementen.

Den erfahrenen Anwender "nerven" grafische Oberflächen eher, da sie ihn am schnellen und effizienten Arbeiten hindern und nicht "programmierbar" sind. Vorteil von grafischen Oberflächen ist aber, dass Aufgaben, die nur 1x im Jahr durchzuführen sind, damit leichter zu handhaben sind.

Ein weiterer Vorteil der hohen "Integration" der grafischen Oberfläche, dem eigentlichem Betriebssystem und den Anwendungen unter Windows ist die höhere Performanz bei grafischen Anwendungen (z.B. Spielen).

3.15 Gruppen

Anwender können unter Windows zu Gruppen zusammengefasst werden. Es wird unterschieden zwischen lokalen Gruppen und Domain-Gruppen. Dateien und Verzeichnisse können für diese Gruppen Zugriffsrechte zugeteilt bekommen.

Unter Linux gibt es ebenfalls Benutzer-Gruppen. Darin kann man mehrere Anwender zusammenfassen und anschließend Dateien für diese Gruppen mit Rechten versehen. Somit spart man sich die Arbeit, für jeden einzelnen Anwender eine Datei mit Zugriffsrechten zu versehen. In großen Netzwerken mit vielen Anwendern erleichtert das die Verwaltung erheblich.

Allerdings ist in einer Gruppe keine Zusammenfassung von anderen Gruppen möglich (wie bei Windows).

In mindestens einer Gruppe, der sogenannten "Primären Gruppe" (heißt meist "staff", "users" oder "wheel") ist man immer Mitglied. Neu angelegte Dateien und Verzeichnisse werden automatisch dieser Gruppe zugeordnet.

3.16 Hardware

Für jede gängige Hardware gibt es heutzutage Linux-Treiber. Sie sind aber eventuell nicht so schnell verfügbar wie unter Windows oder können nicht sämtliche Feinheiten der Hardware ansprechen. Probleme gibt es hier vor allem mit (künstlich) "abgespeckter", brandneuer oder Highend-Hardware, z.B.:

• Win-Modems (eigentlich nur eine Sound-Karte mit Modem-Treiber, häufig in Notebooks eingebaut)
• GDI-Drucker (die Drucker-Intelligenz sitzt im Windows-Druckertreiber)
• 3D-Grafikkarten (die Hardware-Ansteuerung wird nicht offengelegt)
• WLAN (es gab zunächst nur binary-only Treiber)
• Bluetooth
• Infrarot
• Serial-ATA
• Scanner
• APM und ACPI (fast von keinem BIOS vollständig und fehlerfrei implementiert)

Die fehlenden Hardware-Treiber unter Linux beruhen vor allem darauf, dass die Treiber-Erstellung für Windows von den Hardware-Herstellern umsonst für Microsoft übernommen wird. Und für Linux fehlen diesen Herstellern dann Motivation, Zeit, Geld und Verkaufszahlen, um den Treiber zu schreiben bzw. zu portieren.

Dies wird sich aber mit der zunehmenden Verbreitung von Linux verbessern. Es gibt bereits einige Hersteller, die hier umgedacht haben (z.B. ATI, Nvidia, Dell, FSC-Computer)

Will ein Freiwilliger die Erstellung des Hardware-Treibers übernehmen, dann hat er meist folgendes Problem: Der Erwerb der Hardware-Dokumentation vom Hersteller (die zum Schreiben des Treibers notwendig ist) erzwingt die Unterzeichnung eines "Non-Disclosure-Agreements" (Vertraulichkeits-Erklärung) durch den Treiber-Entwickler. D.h. dieser muss unterschreiben, dass er die erhaltenen Informationen Dritten nicht zugänglich macht.

Und das beißt sich dann mit der GPL/Linux-Philosophie, die verlangt, dass der Software-Quellcode immer mitgeliefert wird. Dieser Quellcode stellt im Falle eines Hardware-Treibers aber gerade eine exakte Dokumentation der Hardware-Details dar.

Bleibt also als einzige (mühsame) Möglichkeit zur Ermittlung der Hardware-Eigenschaften das "Reverse Engineering" übrig (d.h. das Beobachten der Kommunikation zwischen Windows-Treiber und Hardware und dem Ableiten der Hardware-Ansteuerung daraus). Diese Art der Informations-Gewinnung dauert lange und führt nicht immer zur vollständigen Kenntnis über die Hardware, man kann also eventuell nicht alle Features ausnutzen.

Hier einige Stellen im Internet, wo man Informationen zur Lauffähigkeit von Hardware unter Linux findet (noch weitere Links):

• ALSA (Advanced Linux Sound Architecture, Soundkarten unter Linux)
• IEEE1394/FireWire-Schnittstelle
• Linmodems (Linux-Modem-Treiber)
• Linux auf Handhelds
• Linux auf Laptops (eng)
• Linux auf Toshiba Laptops
• Linux Hardware (Suchmaschine für Linux Hardware)
• Linux Laptop (eng)
• Linux on Laptops (kharker, eng)
• Linuxprinting (Drucken unter Linux)
• Linux Sound (Sound und MIDI für Linux)
• LinuxTV (Fernseh-Karten unter Linux)
• Linux USB (USB-Treiber für Linux)
• SuSE Hardware Datenbank (deu)
• Tuxhardware (Hardware für Linux, deu)
• Tuxmobil (Info zur Linux-Installation auf Laptops, deu)

Im Prinzip könnten PCs auch zusammen mit einem fertig installierten Linux verkauft werden, wie das bei Windows der Fall ist. Einige Hersteller haben dies auch schon getan oder beabsichtigen dies. Allerdings enthalten Verträge mit den PC-Herstellern wohl Vereinbarungen, die diesen den Verkauf anderer Betriebssysteme zusammen mit der Hardware verbieten, wenn sie die günstigen Windows-OEM-Konditionen von Microsoft nutzen wollen.

3.17 Heimatverzeichnis

Unter Windows NT/2000/2003/2008/XP/Vista/7 existiert pro Anwender ein Verzeichnis "Eigene Dateien", in dem er standardmäßig seine Dateien ablegt. Allerdings hat man als Anwender an vielen anderen Stellen im Windows-Dateisystem ebenfalls Schreibrecht und muss daher seine Dateien nicht unbedingt darin ablegen. Eine besonders beliebte, aber auch unschöne Art der Dateiablage ist der "Desktop", wo die Dateien dann als "Icons" herumliegen und das Benutzer-Profil anwachsen lassen.

Unter Windows gibt also es viele mögliche Ablageorte für die Dateien eines Anwenders, dies verwirrt gelegentlich den Benutzer:

• Eigene Dateien
• Desktop
• Lokale Laufwerke (C:, D:)
• Netzwerk-Laufwerke

Unter Linux existiert für jeden Anwender ein sogenanntes Heimatverzeichnis für seine persönlichen Daten. Nach der Anmeldung springt er sich automatisch dorthin. Dieses Verzeichnis gehört ihm, und er kann darin (fast) alles tun und lassen, was er will: Er seine Daten speichern, seine E-Mails archivieren und eigene Programme installieren. Auch die individuellen Einstellungen für seinen Desktop und der von ihm eingesetzten Programme werden dort gespeichert. Auf alle anderen Stellen des Dateisystems hat man als Anwender keinen schreibenden Zugriff (außer im temporären Verzeichnis "/tmp").

Dieses Heimatverzeichnis ist ein privater Bereich, und alle Konfigurationen, die die persönliche Arbeitsumgebung betreffen, werden hier gesammelt und gespeichert. Diese Daten werden weder vom Betriebssystem noch von anderen Anwendern verwendet oder geändert.

3.18 Installation/Konfiguration

Die Konfiguration der Software erfolgt fast immer über eine Grafische Oberfläche, in der man alle Einstellungen vornehmen kann. Diese Einstellungen werden dann an unbekannter Stelle in der Registry und/oder in Konfigurations-Dateien abgelegt.

Vom Standpunkt der Usability aus gesehen ist das das Optimum, vom Standpunkt der Security eher nicht. Gründe dafür sind:

• Das "Durcheinander" von System- und Anwendungs-DLLs in den gleichen Verzeichnissen, so dass später nicht mehr sauber zwischen ihnen getrennt werden kann.
• Vor der Installation wird nicht offengelegt, was alles wo im Windows-System eingetragen wird.
• Für die Installation (und die Anwendung!) der Software sind häufig Administrator-Rechte notwendig.
• Mein weiß nicht genau, was alles installiert wird (bzw. überschrieben wird).

Die Deinstallation von Software ist unter Windows im Prinzip ebenso einfach, indem man im "Start-Menü" den Punkt "System-Administration" und dann die Dialogbox "Software" auswählt. Hier werden alle installierten Programme aufgelistet, man wählt die zu deinstallierende Software per Maus aus und beantwortet im automatisch gestarteten Deinstaller ein paar Fragen.

Aus mehreren Gründen kann es dabei aber Schwierigkeiten geben (die DLL-Probleme sind auch als "DLL-Nightmare" bekannt):

• Der Deinstaller entfernt nicht alle installierten Dateien oder noch weitere, die nicht zu Anwendung gehören.
• Registry-Einträge werden nicht entfernt, sodass die Registry immer größer wird.
• Bei der Installation wurden DLLs überschrieben, deren alte Version dann nicht wieder hergestellt werden kann.
• DLLs werden deinstalliert, obwohl sie noch von anderen Programmen benutzt werden.

Unter Linux ist die Installation und auch die Deinstallation von Software nicht einheitlich gelöst. Das liegt vor allem daran, dass es so viele Hersteller von Linux-Distributionen gibt und dass es nicht nur eine Hardware-Plattform (Intel386) gibt.

Im einfachen Fall erhält man die Software mit allen notwendigen Dateien und Informationen vom Distributor seiner Linux-Version (oder einer anderen Quelle) in einem (RPM/APT-)Paket vorübersetzt, das wie unter Windows per Mausklick installiert und auch wieder deinstalliert werden kann.

Im komplexen Fall muss man sich ein Archiv mit dem Quellcode der Software herunterladen, das Archiv auspacken, den Quellcode an die eigene Plattform anpassen (dieser Vorgang ist automatisiert), ihn dann mit Make und einem C/C++-Compiler übersetzen und das entstehende Produkt dann installieren ("Linux-Dreisatz": configure; make; make install. In der Regel ist mit Make auch eine saubere Deinstallation möglich.

Die Konfiguration der Software erfolgt fast immer über ASCII-Konfigurations-Dateien, in denen man alle Einstellungen vornehmen kann. Die Namen und die Lage dieser Dateien ist fix und der Installations-Anleitung zu entnehmen.

Beim Aufruf der Software wird meist im Heimatverzeichnis des Anwenders eine "versteckte ASCII-Konfigurations-Datei" oder "-Verzeichnis" angelegt, in dem der Anwender eigene Einstellungen durchführen kann.

Meist müssen der "Suchpfad" ($PATH) ergänzt und Umgebungs-Variablen in der Benutzerumgebung gesetzt und exportiert werden.

Vom Standpunkt der Usability ist das keineswegs das Optimum (eher das Gegenteil!), vom Standpunkt der Security schon eher:

• Es gibt keine Registry, sondern ASCII-Konfigurations-Dateien, deren Inhalt überprüft werden kann und die auch wieder sauber entfernt werden können.
• System- und Anwendungs-DLLs werden in verschiedenen Verzeichnissen getrennt installiert.
• Es können mehrere Versionen der gleichen DLL gleichzeitig installiert sein, sie werden über eine Versionsnummer zum DLL-Namen unterschieden. Jedes Programm weiß, welche Version einer DLL es benötigt.
• Vor der Installation ist überprüfbar, was alles wo eingetragen wird.
• Für lokale Installation der Software sind keine Administrator-Rechte notwendig, für zentrale Installation sehr wohl.
• Für Anwendung der Software sind keine Administrator-Rechte notwendig.

Aus diesen Gründen ist eine vollständige und saubere Deinstallation einer Software meist ohne Schwierigkeiten möglich.

3.19 Kommandozeile (Shell)

Unter Linux stellt die Kommandozeile unter der Shell in einem Terminal nach wie vor ein sehr wichtiges Arbeitsmittel dar. Alle Programme können von dort aus gestartet werden (wobei grafische Anwendungen natürlich eine X Window-Umgebung für den Start benötigen) und die komplette System-Administration kann darüber durchgeführt werden.

Die unter Linux verfügbaren Shells sind deutlich mächtiger als die Shell des Kommandozeilenfensters unter Windows. Sie eignen sich auch zur Programierung und automatisierten Ausführung von Tätigkeiten.

Leider gibt es verschiedene Shells (z.B. sh, csh, tcsh, ksh, bash, zsh), die sich in Syntax und Funktionalität unterscheiden. Unter Linux hat sich aber inzwischen mit der sehr leistungsfähigen bash eine Standard-Shell herauskristallisiert.

3.20 Konfigurierbarkeit

Linux wird daher inzwischen sehr häufig in sogenannten "Appliances" eingesetzt, die als Fix-und-Fertig-Produkt für bestimmte Anwendungsfälle dienen (DSL-Router, Firewall, WLAN-Access-Point, Druckserver, Fileserver, Paketfilter, Applikations-Gateway, Webserver, TV-Festplatten-Recorder, Handy, Palmtop, NAS/SAN). Das Linux-System wird dabei von allen nicht notwendigen Komponenten befreit, es hat daher eine sehr geringe Größe und benötigt wenig Ressourcen (Speicher, CPU, Strom). Diese Geräte benötigen meist keinen Lüfter und sind somit lautlos (sofern sie "diskless" sind).

3.21 Lizenzen und Kosten

Die Lizenzmodelle vieler Windows-Software-Produkte sind inzwischen so komplex geworden, dass bereits das Berechnen der Lizenzkosten für bestimmte Einsatz-Szenarien sehr aufwendig sein kann. Diese Zeit könnte man besser in ganz andere Dinge investieren, z.B. in die Ausbildung der Administratoren und Mitarbeiter.

Linux kennt nur ein prinzipielles Lizenz-Modell, die GPL (GNU General Public License). Diese besagt im Wesentlichen, dass es keine Lizenzgebühren geben darf (aber sehr wohl ein Copyright). Die reinen Lizenzkosten für Linux sind daher gleich Null.

Das Installieren und Administrieren von Windows und Linux-Systemen kostet natürlich immer Arbeitszeit und damit Geld. Hier gibt es derzeit keine klaren Aussagen, welches der beiden Betriebssysteme für welche Einsatz-Szenarien höhere/niedrigere Kosten verursacht. Für beide Betriebssysteme gibt es viele TCO- (Total Cost of Ownership) und ROI-Berechnungen (Return of Investment), die je nach Randbedingungen und Zielen bzw. Affinität des Erstellers Vorteile für Linux oder für Windows ermitteln.

3.22 Multi-User

Linux wurde von Beginn an als Mehrbenutzer-System konzipiert. Daher benötigt man immer einen Benutzernamen und das zugehörige Passwort und ein Heimatverzeichnis (für die persönlichen Daten), um sich anmelden zu können. Benutzername und Passwort werden auch als Benutzerkonto bezeichnet.

Unter Linux ist es daher möglich und auch absolut üblich, dass mehrere Anwender "gleichzeitig" auf einem Rechner arbeiten, indem sie sich z.B. über Netzwerk dort anmelden. Diese Anwender arbeiten voneinander völlig unabhängig, außer dass sie sich natürlich die Ressourcen des Rechners teilen (Speicher, CPU, I/O-Kanäle, Festplatte, Drucker, …). Nicht nur Terminals, sondern auch grafische Anwendungen lassen sich auf diese Weise netzwerkweit benutzen.

Windows war und ist primär ein Einzelbenutzer-System, auch wenn Windows NT/2000/2003/2008/XP/Vista/7 inzwischen echte Mehrbenutzerfähigkeit auf Prozessebene anbietet. Es gibt aber kaum Mechanismen, um auf einer entfernten Windows-Maschine komfortabel arbeiten zu können.

Diese Lücke wird zwar von den "Windows Terminal-Servern" (z.B. Citrix) geschlossen, für die jedoch die Verwendung spezieller Clients notwendig ist und die zusätzliche hohe Lizenzgebühren kosten. Alle Windows-Server-Versionen enthalten bereits einen Windows Terminal-Server mit 2 Client-Lizenzen.

3.23 Netzwerk

3.24 Pfadsuche (Suchpfad)

Unter Windows wird grundsätzlich zuerst das aktuelle Verzeichnis nach einem Programmnamen durchsucht (mit einer der automatisch angehängten Endungen .EXE/COM/BAT/CMD/MSI). Wenn es dort nicht gefunden wird, dann werden die Verzeichnisse in der Umgebungsvariablen PATH in der dort aufgeführten Reihenfolge nach dem Programmnamen durchsucht (Trennung der Verzeichnisse durch ";", die Variable ist mit echo %PATH% anzeigbar).

Die Suchpfadvariable ist unter Windows normalerweise relativ kurz und enthält z.B. den Wert C:\;C:\windows\system32. Wird neue Software installiert, dann wird die Variable meist nicht verlängert. Zum Aufruf eines Programms ist also auf der Kommandozeile meist der volle Pfad anzugeben (oder ein Menüpunkt im Startmenü, ein Icon auf dem Desktop oder das Programmname im Windows Exporer "anzuklicken"). Kann der Programmname (mit der angehängten Endung .EXE/COM/BAT/CMD/MSI) nicht gefunden werden, erhält man die Meldung "Kommando XXX nicht gefunden".

Unter Windows ist der Suchpfad eine systemweite Einstellung und für alle Benutzer gleich.

Unter Linux werden Programme ausschließlich in den im Suchpfad aufgelisteten Verzeichnissen gesucht. Diese Verzeichnisse (durch ":" in der "bash" oder " " in der tcsh getrennt) werden in der aufgeführten Reihenfolge nach dem vollständigen Programmnamen durchsucht. Das aktuelle Verzeichnis wird nur dann nach dem Programm durchsucht, wenn die Suchpfadvariable PATH (oder path in der tcsh) den Verzeichnisnamen "." (für "aktuelles Verzeichnis") enthält. Über seine Position im Suchpfad kann gesteuert werden, ob es zuerst, mittendrin oder zuletzt nach dem Programmnamen durchsucht wird.

Die Suchpfadvariable ist unter Linux normalerweise relativ lang und enthält für einen normalen Benutzer user z.B. den Wert /bin:/usr/bin:/usr/local/bin:/opt/kde3/bin:/usr/X11/bin:/usr/lib/java/bin:/home/user/bin. Wird neue Software installiert, dann wird die Variable meist verlängert. Zum Aufruf eines Programms ist also auf der Kommandozeile meist nur der Programmname anzugeben. Kann der Programmname nicht gefunden werden, erhält man die Meldung "Kommando XXX nicht gefunden".

Zum Aufruf eines Programms PGM im aktuellen Verzeichnis muss daher meist ./PGM angegeben werden. Dies ist insbesondere für den Benutzer root notwendig, da in dessem Suchpfad aus Sicherheitsgründen nie das aktuelle Verzeichnis . steht.

Unter Linux ist der Suchpfad eine benutzerabhängige Einstellung und wird für jeden Benutzer getrennt bei seiner Anmeldung eingestellt. Insbesondere hat der Systemadministrator "root" eine völlig andere Suchpfadeinstellung als die normalen Benutzer (z.B. /usr/sbin:/bin:/sbin:/usr/sbin). Er kann also normalerweise Systemadministrations-Programme direkt aufrufen, dafür aber nicht alle Benutzerprogramme (wie z.B. die der grafischen Oberfläche).

Die Windows-Variante ist bequemer, hat aber folgende Nachteile:

• Vor dem Programmaufruf wird häufig mit cd in das entsprechende Verzeichnis gewechselt (oder der absolute Pfad angegeben), das ist umständlich.
• Ein von einem böswilligen Benutzer in einem Verzeichnis abgelegtes "Trojaner-Programme" mit dem gleichen Namen wie ein Systemprogramm wird immer zuerst aufgerufen, das ist gefährlich (Sicherheitsproblem!).
• Kommando-Vervollständigung ist auch ab Windows NT möglich. Hierzu muss bei Windows NT/2000 ein Registrierungsschlüssel modifiziert werden. Ab Windows XP/2003 ist dieser von Haus aus aktiv.

Die Linux-Variante ist unbequemer, hat aber folgende Vorteile:

• Die "root" muss bewusst Programme im aktuellen Verzeichnis aufrufen, indem sie den Pfad ./ davorstellt (das ist anfangs eine der größten Hürden für an Windows gewöhnte Benutzer!).
• Es ist egal wo ein installiertes Programm steht, es kann immer über seinen "Namen" aufgerufen werden, wenn der Suchpfad geeignet angepasst wurde (dies fördert die saubere Trennung von Softwarepaketen und erleichtert so ihre Deinstallation ungemein).
• Die Suchpfade jedes einzelnen Benutzers können unterschiedliche Werte haben, (zugeschnitten auf seine Aufgaben, d.h. er kann erst mal Programme gar nicht aufrufen, die er nicht kennt — kleines Sicherheitsplus basierend auf "Unwissenheit" des Anwenders).
• Alle gemäß Suchpfad verfügbaren Kommandos können durch Eingabe von TAB TAB (bash) oder TAB Strg-D (tcsh) aufgelistet werden (automatische Kommando-Vervollständigung).

3.25 Portabilität

Linux ist für etwa 30 Prozessorplattformen verfügbar (Intel386, PowerPC, Sparc, MIPS, PA-RISC, 68000, ARM, Alpha, …) und sehr gut portabel, da der Quellcode hauptsächlich in C und C++ geschrieben ist und nur wenig Assembler-Code enthält.

3.26 Quellcode (Source)

Windows ist nicht im Quellcode verfügbar und somit eine "Black-Box". Es kann daher auch nicht in Einzelteile zerlegt und dann am Bedarf orientiert installiert werden. Für einzelne große Kunden werden hier sehr wohl Ausnahmen gemacht, jedoch nicht generell.

Linux ist im Quellcode verfügbar und dementsprechend sehr leicht auf bestimmte Einsatz-Szenarien zuschneidbar. Z.B. ist es durchaus möglich, in 1-2 MByte ein voll funktionsfähiges Linux-System unterzubringen (allerdings ohne grafische Oberfläche).

3.27 Schriftarten (Fonts)

Sie (bzw. das Codierungschema True Type 1) sind aber mit Lizenzen von Microsoft behaftet und dürfen daher z.B. nicht in Linux-Distributionen mitgeliefert werden. Aufgrund einer Lizenzlücke sind sie aber ohne Kosten über das Internet nachinstallierbar (die sogenannten Corefonts).

Fonts sehen unter Windows vor allem auf dem Bildschirm schöner aus als unter Linux. Auch dies liegt daran, dass Microsoft und Adobe bestimmte Verfahren der Fontcodierung (das "Hinting") mit Lizenzen versehen haben. Der Einsatz dieser Verfahren ist aber für eine ordentliche Darstellung vieler gängiger Fonts auf dem Bildschirm notwendig. Auch hier kann man über das Internet Fonts mit Hinting nachinstallieren bzw. es sind inzwischen rechtefreie Ersatzfonts verfügbar

3.28 Sicherheit

Unter Linux ist sämtliche verfügbare Software schon immer an diese saubere Trennung angepasst. D.h. man kann grundsätzlich mit jeder Anwender-Software als normaler Anwender arbeiten und wird nur bei Bedarf kurzzeitig für ein einzelnes Programm (z.B. YaST) oder in einem einzelnen Fenster (z.B. Terminal) der Administrator. Und als normaler Anwender kann man maximal seine eigenen Daten infizieren/zerstören, aber nicht die anderer Anwender und schon gar nicht die des Systems.

Aufgrund seiner geringeren Verbreitung gibt es für Linux (derzeit) deutlich weniger Viren/Würmer/Trojaner als für Windows. Prinzipiell sind aber auch unter Linux derartige Programme möglich und werden mit höherem Einsatzgrad auch vermehrt auftreten (z.B. RootKits). Trotzdem sind aufgrund der internen Architektur und der sauberen Trennung von System-Administrator und Anwendern sowie Betriebssystem, Grafischer Oberfläche und Anwendungen hier deutlich weniger Probleme zu erwarten.

Unter Linux laufen standardmäßig nur die unbedingt notwendigen Dienste. Alles was nicht unbedingt notwendig ist, ist standardmäßig abgeschalten. Unter vielen Windows-Versionen (bei Windows 2003/2008/XP/Vista/7 inzwischen nicht mehr) sind nach einer Standard-Installation mehr als 30 Dienste automatisch aktiviert. Man kann sie auch nicht abschalten, da sie von Windows intern benötigt werden.

Soweit möglich, laufen Dienste unter Linux statt mit Administrator-Rechten mit den Rechten eines speziell für jeden Dienst eingerichteten Verwaltungs-Benutzers, der wie alle normalen Anwender fast nichts darf (meist kann er sich nicht mal anmelden, da für ihn kein Passwort existiert).

Linux trennt im Gegensatz zu Windows folgendes sehr streng voneinander:

• System- und Anwender-Daten
• System- und Anwender-Programme
• Daten der verschiedenen Anwender
• Zusätzlich installierte SW-Pakete von der System-Software
• Zusätzlich installierte SW-Pakete untereinander
• Unterschiedliche Versionen der gleichen DLL

3.29 Software

Im Open Source Bereich gibt es kein Marketing und damit auch keinen Veröffentlichungs-Druck. Es kann im Gegenteil sogar sehr lange dauern, bis eine Software wirklich für Produktionszwecke freigegeben wird, obwohl sie als Testversion schon monatelang stabil läuft, weil die Entwickler lieber noch Tests durchführen und nach Fehlern suchen. D.h. eine Versionsnummer 1.0 bedeutet (fast) immer eine hohe Software-Qualität. Es gibt sogar Programme, die seit Jahren höchst stabil laufen und immer noch eine Versionsnummer "0.x" haben.

Es gibt immer eine klare Trennung zwischen Test- und Produktions-Versionen. Wer unbedingt mit der neuesten Version arbeiten will, kann sich auch die Test-Versionen herunterladen und installieren. Meist kann man mehrere Versionen der gleichen Software sogar parallel einsetzen (z.B. Apache 1.3 und 2.0).

3.30 Spiele

Linux bietet ebenfalls viele Spiele, aber bei weitem nicht die Vielfalt wie sie auf der Windows-Seite gegeben ist. Die neuesten Windows-Spiele sind ganz selten auch unter Linux verfügbar.

Mit Hilfe der Projekte Wine, WineX/Cedega und PlayOnLinux wird versucht, Windows-Spiele unter Linux in einer Emulation laufen zu lassen. Diese Vorgehensweise ist durchaus erfolgreich, aber nicht das eigentliche Ziel.

Diese Situation wird sich mit zunehmender Verbreitung von Linux verbessern. Insbesondere existieren für Linux eine Reihe von Spiele-Engines (Löve, OGRE) oder Spiele-Bibliotheken (Genesis3D, Allegro, ClanLib) die die Entwicklung neuer Spiele stark vereinfachen. Ebenso sind Multi-Platform Engines verfügbar (Unigine), mit deren Hilfe Spiele einheitlich für Windows, Linux, Apple und z.B. Spielekonsolen entwickelt werden können.

Für die Fans von Spielen auf älteren Computer-Systemen (C64, Spektrum, Atari) oder von Spiele-Konsolen (Gameboy, PS/2) ist sicher interessant, dass sowohl Windows als auch Linux Emulatoren für viele dieser Plattformen bietet, sodass diese Spiele auch auf einem Windows- oder Linux-PC ausgeführt werden können.

3.31 Stabilität

Selbst wenn die grafische Oberfläche nicht mehr bedienbar ist und an der Grafischen Oberfläche nichts mehr eingegeben werden kann, ist ein Linux-System über Netzwerk (SSH-Anmeldung) praktisch immer noch erreichbar und kann darüber dann auch gesteuert werden (z.B. um die grafische Oberfläche neu zu starten).

Linux-Systeme laufen monate- und jahrelang stabil und ohne Probleme.

Unter Windows sind die grafische Oberfläche und das eigentliche Betriebssystem eng verzahnt und entsprechend anfällig. Sie können auch prinzipiell nicht getrennt werden. Bleibt der Windows- oder Internet-Explorer "hängen" oder tritt ein "Bluescreen" auf, ist das System nicht mehr bedienbar und muss neu gebootet werden.

3.32 Standards

Diese Meinung wird zementiert durch die fast ausschließliche Verwendung von Windows und Windows-Produkten in Firmen, Ämtern, an Schulen, Volkshochschulen, Universitäten und nicht zuletzt bei Schulungsanbietern. Linux entspricht nicht diesem "Standard" und wird daher oft als "fremd" empfunden.

Dabei ist genau das Gegenteil der Fall: Windows und die typischen Windows-Anwendungen sind kein echter Standard, sondern "Pseudo"-Standards. Versionsabhängig ändern sich ihre Eigenschaften, ihr Aussehen und sie verhalten sich evtl. völlig anders.

Probleme eines "Pseudo"-Standards sind:

• Kann jederzeit ohne Ankündigung geändert werden.
• Kann nicht offengelegte Funktionalitäten enthalten, die dem Erfinder einen Vorteil verschaffen.
• Kann nicht offengelegte Funktionalitäten enthalten, die Software von Konkurrenten "aushebelt".
• Kann Spionage-Funktionalitäten enthalten, die zum Ausspähen des Anwenders benutzt werden.
• Kann nicht erkannte Sicherheitslücken enthalten.

Ein echter Standard (z.B. XML, C, C++, Java) wird nicht durch ein Produkt (z.B. JavaScript, HTML, Webbrowser) definiert, sondern durch formale Dokumente, die exakt festlegen, welche Fähigkeiten und Eigenschaften er hat (und welche nicht). Ihm geht ein Einigungsprozeß mehrerer Parteien voraus, dessen Ablauf und Ergebnisse dokumentiert werden (z.B. in Form eines RFC = Request for Comment).

Linux hält viele Standards ein (POSIX, X/Open, RFCs, …) bzw. legt alle Standards, die in seinem Zusammenhang geschaffen werden, in Form von öffentlich zugänglichen Dokumenten offen. Diese Vorgehensweise hat mehrere Vorteile:

• Standards können von unabhängigen Parteien geprüft werden, ob sie klar formuliert, widerspruchsfrei und vollständig sind.
• Widersprüche und Fehler im Standard können behoben werden, bevor es Produkte dafür gibt.
• Die Qualität der Software bezüglich der Erfüllung eines Standards ist überprüfbar.
• Andere können Produkte entwickeln, die den Standard erfüllen.
• Es gibt keine "geheimen Ecken und Kanten", die Mitbewerber außen vor halten.
• Sicherheitsrelevante Eigenschaften können geprüft werden.

• Es dauert länger, wenn mehrere Parteien sich auf einen Standard einigen, als wenn eine Partei einen "Standard" für sich definiert und ihn dann auf dem Markt durchsetzt.
• Geheimhaltung der eingesetzten Technologien ist nicht mehr möglich.
• Marktabschottung ist nicht mehr möglich.

Allerdings hat die "Schnelligkeit" in der Vergangenheit schon viele Probleme bereitet. Z.B. ist das ursprüngliche HTML-Format nach seiner Vorstellung von Herstellern wie Netscape und Microsoft unüberlegt und adhoc weiterentwickelt worden. Dabei wurden viele Inkompatibilitäten geschaffen und unterschiedliche Vorgehensweisen für die gleichen Zwecke implementiert. Der HTML-Standard wurde sozusagen "aufgeweicht und verwässert". Die eigentlich mit HTML beabsichtigte Trennung von Inhalt und Aussehen wurde dadurch aufgegeben.

Heute rächt sich dies, indem die verschiedenen Browser die gleiche HTML-Seite unterschiedlich interpretieren und darstellen. Es ist schwierig geworden, eine für alle Browser gleichermaßen geeignete HTML-Seite zu erstellen.

3.33 Support

• Vom Hersteller selbst (gegen Geld).
• Von Dienstleistern, die sich mit den Produkten gut auskennen (gegen Geld).
• Von anderen Anwendern (die es zuhauf gibt, umsonst).
• Im Internet und vielen Foren (umsonst).

Für Linux ist Support aus genau den gleichen Quellen erhältlich, allerdings aufgrund der deutlich geringeren Verbreitung nicht im gleichen Umfang. Andererseits gibt es hier eine sehr aktive "Community", die bei Problemen gerne und vor allem schnell Hilfe leistet.

Wieder gibt es aber den entscheidenden Unterschied, dass der Quellcode verfügbar ist. Daher können Fehler "von jedem" behoben werden, der genügend Knowhow hat. Meist wird diese Korrektur anschließend sofort wieder den anderen Anwendern als Patch zur Verfügung gestellt. Dieses Modell vermeidet "Featuritis" und sorgt vor allem dafür, dass Fehler, die viele Anwender betreffen, auch schnell behoben werden.

Analoges gilt für Erweiterungen: Auch hier kann beim Linux-Modell im Prinzip jeder tätig werden und von seinen Erweiterungen können auch auch alle anderen Anwender profitieren.

3.34 Usability

Weiterhin gibt es zur Unterstützung der Usability viele Windows-Funktionalitäten und -Automatismen wie:

• Eingelegte(r) CD/Diskette/USB-Stick/… wird automatisch angezeigt
• Software-Installation per "Mausklick"
• Treiber-Installation on-the-fly
• Office-Dokumente sind weltweit austauschbar
• Vorinstallierte Standard-Fonts
• Aktive Elemente in Dokumenten und HTML-Seiten
• HTML-Mails
• VBA-Skripting
• Viele Dienste werden beim Booten automatisch gestartet
• Anwendungs-DLLs werden beim Booten automatisch geladen, damit die Anwendung schneller startet
• Umschreiben von Firewall-Regeln durch Anwendungen
• Einbettung des Datei-/Internetbrowsers in das Betriebssystem
• Einbettung von Musik- und Video-Playern in das Betriebssystem

Da die meisten Windows-Programme grafisch orientiert sind und eine umfassende interaktive Hilfe mit sich bringen, kann man häufig ohne große Lernphase durch "Herumklicken" und "Ausprobieren" damit zurechtkommen. Sehr schnell hat man damit Erfolge und löst auch schon mal kleinere Probleme.

Viele "Chefs" sind inzwischen sogar der Auffassung, dass Mitarbeiter keine Kurse mehr für Windows-Programme benötigen, sondern sich eigenständig per "Learning by doing" darin einarbeiten können. Ob dies bei aller Usability der Windows-Programme eine sinnvolle Vorgehensweise ist, darf bezweifelt werden.

Häufig werden so nur die trivialen 20% Funktionalität eines Programms erlernt, die restlichen (meist sehr mächtigen) 80% Funktionalität liegen brach. Oder es werden langwierige und umständliche Vorgehensweisen gewählt, statt elegant und effizient zu arbeiten.

Typische Beispiele für derartiges "Halbwissen" sind das visuelle Formatieren von Texten statt Formatvorlagen zu verwenden und das Erzeugen von mehrspaltigem Text durch Leerzeichen / Tabulatoren statt durch Tabellen.

Überhaupt wird durch grafische Oberflächen das visuelle, interaktive und iterative Arbeiten gefördert, auf gründliche Vorüberlegung und Planung wird dabei gerne verzichtet, sondern man "legt gleich los".

Fazit: Auch grafisch orientierte Windows-Programme muss man gründlich erlernen, um sie sinnvoll und effizient einsetzen zu können. Gerade dieses "Erlernen" wird aber den unter Linux gerne verwendeten kommandozeilen-orientierten Programmen häufig vorgeworfen, ist also ein Schein-Argument gegen Linux.

Noch einen weiteren Gesichtspunkt gilt es hier zu berücksichtigen: "Usability und Security stehen sich diametral gegenüber". Daher muss ein Teil der Windows-Usability dann aufgegeben werden, wenn man mehr Sicherheit als bisher erreichen will. In diesem Fall ist der Abstand zu der bei Linux z.B. mit KDE oder Gnome inzwischen erreichten Usability nur noch gering.

Ein dritter Punkt ist die Weiterverarbeitung von Daten. Unter Windows ist ein Programm häufig ein "Closed Shop", die Weitergabe von Daten an andere Programme ist nicht vorgesehen. Dies führt häufig zu "Eierlegenden Wollmilchsäuen", die fast alles können, aber auch softwaretechnisch sehr schwierig zu realisieren sind und viele Fehler enthalten.

Linux wählt einen anderen Ansatz, nämlich den "werkzeug-basierten". Viele Programme können "nur eine Sache", diese dafür aber fehlerfrei, performant und mit allen Schikanen. Sie sind im Ausgleich dazu in der Lage, die Daten anderer Programme zu empfangen bzw. sie an diese weiterzugeben. D.h. man kann aufwendige "Verarbeitungsketten" durch Aneinanderhängen vieler kleiner Werkzeuge per Pipe realisieren.

Dieser Ansatz ist sehr flexibel und performant. Allerdings ist er wenig visuell, sondern mehr abstrakt und er verlangt einen gewissen Einarbeitungsaufwand. Weiterhin sind derartige Abläufe auch programmierbar und automatisierbar. Kurzfristig gesehen hat diese Vorgehensweise Nachteile, mittel- und langfristig gesehen bietet sie aber Vorteile.

3.35 Variablen

Jeder Prozess hat eine Umgebung (ein ihm exklusiv zugeordneter Speicherbereich), in dem seine Variablen abgelegt sind. Die bekannteste Variable ist die Pfadvariable ($PATH, $path oder %PATH%), die unter Windows und Linux steuert, in welchen Verzeichnissen automatisch nach ausführbaren Dateien gesucht wird.

Fenster in Grafischen Oberflächen sind übrigens auch nur "Prozesse", die mit Hilfe von Grafikfunktionen ein "Abbild" auf dem Desktop erzeugen. Daher werden auch grafische Programme durch Variablen beeinflusst.

Unter Linux gibt es sehr viele Variablen, z.B.:

Fast jedes Kommando kennt eine oder mehrere speziell für sich festgelegte Variablen, die in seiner man-Page ausführlich beschrieben werden. Damit lässt sich häufig das Standard-Verhalten von Kommandos weitgehend an die Benutzerbedürfnisse anpassen.

Unter Linux sind die Variablen je nach Aufgabe in 2 Gruppen aufgeteilt:

1. Shell-Variablen: Steuern das Verhalten der aktuellen Shell.
   Sie werden nicht an andere Programme vererbt.
2. Umgebungs-Variablen: Steuern das Verhalten von Programmen, die aus der Shell heraus aufgerufen werden.
   Sie werden an andere Programme vererbt (exportiert).

Unter Linux hat jeder Prozess und insbesondere jede Shell einen eigenen Variablenbereich, der bei ihrem Start vom Elternprozess gefüllt wird und der ihm exklusiv gehört. Sie können darin beliebige Änderungen vornehmen, der Bereich ist lokal zu diesem Prozess. Wird ein Kindprozess gestartet, so erhält dieser eine Kopie des Variablenbereichs seines Elternprozesses, danach sind die beiden Bereiche wieder voneinander unabhängig.

Für die Skript-Programmierung ist dieses lokale Verhalten sehr wichtig, da sich Skripte deswegen nicht darum kümmern müssen, ob sie andere Prozesse mit ihren Variablen beeinflussen. Dies ist schlichtweg prinzipiell nicht möglich (bis auf Vererbung an Kindprozesse beim Start von diesen).

Variablen können unter Linux bereits beim Booten des Kernels festgelegt werden. Viele Prozesse (insbesondere Shells) lesen beim Start bestimmte festgelegte Konfigurations-Dateien, (z.B. die bash liest /etc/profile, ~/.profile, ~/.bashrc,…), in denen dann häufig Variablen definiert werden.

Unter Windows-Anwendern sind Variablen wenig bekannt, was auch am geringen Einsatz der Kommandozeile und an der geringen Anzahl der Variablen liegen mag. Dabei sind Variablen auch dort für alle Prozesse, insbesondere auch für Prozesse, die in der grafischen Oberfläche gestartet werden, sehr wichtig. Bekannte Variablen von Windows sind:

Unter Windows sind die Variablen in 2 Gruppen aufgeteilt:

1. Benutzer-Variablen: Sind einem bestimmten Anwender zugeordnet. Werden aktiviert, wenn sich dieser Anwender anmeldet.
2. System-Variablen: Sind dem System zugeordnet. Werden aktiviert, wenn das System gebootet wird.

Dieses globale Verhalten ist leider im Rahmen der Batch/Skript-Programmierung schlecht, da sich Skripte und Prozesse dadurch gegenseitig unbemerkt und unerwünscht beeinflussen können.

3.36 Versionen

• Win3.x: Umfasst Windows 3.0, 3.1, 3.11 = WfW (Windows for Workgroups).
• Win9x: Umfasst Windows 95, 98, 98SE, ME.
• WinNT: Umfasst Windows NT 3.1, NT 3.5, NT 3.51, NT 4.0, 2000, 2003, 2008, XP, Vista, 7.

• Debian GNU/Linux (nicht-kommerzielle "reine" Linux-Distribution)
• Fedora (ehemals RedHat)
• Fli4l (ISDN/DSL/Ethernet-Router auf 1 Diskette)
• Gentoo (Linux selbst aus den Quellen "hochziehen")
• IPCop (Firewall auf Diskette/CD)
• Knoppix (Linux auf CDROM mit KDE)
• Linux from Scratch (Linux selbst aus den Quellen "hochziehen")
• Linspire (hieß bisher Lindows, ein Linux-System das aussieht wie Windows)
• Mandriva (französischer Marktführer)
• OpenSuSE Linux (deutscher + europäischer Marktführer)
• RedHat Linux (nordamerikanischer Marktführer)
• Slackware (sehr lange existierende Distribution)
• Turbolinux (asiatischer Marktführer)
• Ubuntu Linux (deutscher + europäischer Marktführer)
• Xandros (Corel Nachfolger, Linux-Desktop)

Ein herausstechendes Unterscheidungs-Merkmal von Linux gegenüber Windows ist seine Zuschneid(er)barkeit auf bestimmte Einsatzzwecke hin. Dies beruht auf der modularen Struktur von Linux und der Verfügbarkeit des Quellcodes und ist auch die Ursache für die vielen verschiedenen Distributionen.

3.37 Zeilenende-Kennzeichen

• Linux: Zeilenvorschub (Newline, Line Feed, LF, Ctrl-J, 10, 0x0A).
• Apple Macintosh: Wagenrücklauf (Carriage Return, CR, Ctrl-M, 13, 0x0D).
• Windows: Kombination dieser beiden Zeichen, nämlich CR-LF.

Um derartige Probleme zu beheben, gibt es Programme zur Konvertierung der Zeilenenden (z.B. unix2dos, dos2unix, recode). Dieser Vorgang ist unkompliziert, wird aber beim Transfer von Text-Dateien gerne vergessen.

4 Zugriffsrechte

4.1 Windows 95-ME

Die Anmeldung dient nur zur Auswahl des passenden Anmelde-Profils (speichert pro Anwender lediglich seine persönlichen Einstellungen und den eingerichteten Desktop), das Passwort ist hingegen beliebig wählbar (wird aber bei Anbindung an Netzwerk-Freigaben verwendet).

Pro Datei gibt es immerhin folgende 5 "Datei-Attribute", die schon in MS-DOS vorhanden waren:

4.2 Windows NT-XP

Die Versionen Windows NT/2000/2003/2008/XP/Vista/7 kennen darüber hinaus aufgrund des meist verwendeten NTFS-Dateisystems Besitzverhältnisse und folgende 6 Zugriffsrechte:

Diese Basisrechte werden zur einfacheren Rechtevergabe und Rechteanzeige zu folgenden 7 Gruppen zusammengefaßt (für Verzeichnisse gibt es alle 7 Gruppen, für Dateien nur 4 Gruppen):

4.2.1 Besitzer(Gruppe)

Jede Datei und jedes Verzeichnis hat einen Besitzer (Owner), der normalerweise als einziger berechtigt ist, die Zugriffsrechte einer Datei zu ändern. Durch das Recht P = "Berechtigung übernehmen" kann er dieses Recht auch an andere Benutzer/Gruppen weitergeben.

4.2.2 Vererbung

Verzeichnisse haben unter Windows NT/2000/2003/2008/XP/Vista/7 2 Rechtesätze. Der 1. gilt für das Verzeichnis selbst, der 2. gilt für alle darin neu erzeugten Objekte (Dateien und Verzeichnisse), d.h. darüber wird eine "Vererbung" der Dateirechte realisiert. Zwischen WinNT und Win2000 hat sich die Semantik dieser Vererbung geändert. Bei WinNT wurde statisch vererbt, ab Win2000 wird dynamisch vererbt. D.h. Änderungen an Zugriffsrechten eines Verzeichnisses wirken sich ab Win2000 dynamisch auf alle seine Unterdateien und Unterverzeichnisse aus.

4.2.3 Kombination

Die Rechtesätze können in den zu jeder Datei/jedem Verzeichnis vorhandenen ACLs (Access Control Lists) für beliebige Benutzer und Benutzer-Gruppen getrennt vergeben werden. Es ist also eine sehr "feingranulare" Rechtevergabe möglich, deren Feinheiten aber erst einmal verstanden werden müssen.

Die obigen 6/7 Rechte können in jeder ACL gesetzt oder gelöscht werden. Ist ein Benutzer Mitglied in mehreren Gruppen, für die zu einer Datei oder einem Verzeichnis eine ACL vorhanden ist, so werden die gesetzten Rechte dieser ACLs verodert (die Obermenge gilt) und mit den gelöschten Rechten dieser ACLs verundet (die Untermenge gilt). D.h. durch Hinzufügen von ACLs zu einem Dateisystemobjekt können Zugriffsrechte auch wieder weggenommen werden.

4.3 Linux

4.3.1 Dateirechte

Linux kennt an Zugriffsrechten für jede Datei die 3 Rechte

Die 3 Rechte regeln, was mit dem Datei-Inhalt erlaubt ist:

Diese 3 Rechte gibt es jeweils für die 3 Benutzertypen (also insgesamt 3 × 3 = 9 Rechte):

Will man alle 3 Benutzertypen zusammen ansprechen, ist statt ugo das Kürzel a (all) verwendbar. Diese 9 Rechte werden mit dem Kommando ls -l (long) immer in der gleichen Reihenfolge in der 1. Spalte aufgelistet (fehlt ein Recht, so wird stattdessen ein "-" angezeigt):

Beispiel für eine Ausgabe von ls -l (Verzeichnisinhalt auflisten):

4.3.2 Dateitypen

In der ersten Zeichenspalte wird beim Kommando ls -l der Datei-Typ gemäß folgender Tabelle angezeigt:

4.3.3 Verzeichnisrechte

Die gleichen 3 Rechte sind auch für Verzeichnisse vorhanden und regeln dort, was mit den Dateinamen im Verzeichnis erlaubt ist:

Das x-Recht eines Verzeichnisses entscheidet nicht nur über den Zugang zu diesem Verzeichnis, sondern auch über den Zugang zu allen seinen Unterverzeichnissen und ihren Dateien (sofern keine Hard Links auf Dateien eingesetzt werden).

4.3.4 Rechteanomalie

Die Definition der Zugriffsrechte scheint zunächst eine sogenannte Rechteanomalie zu bedingen: eine Datei kann gelöscht werden (Schreibrecht in ihrem Verzeichnis), obwohl sie nicht schreibbar ist (Schreibrecht für die Datei selbst). Dabei handelt es sich aber nur um eine streng logische Definition und Anwendung dieser Rechte. Mit dem Sticky-Recht kann diese Rechteanomalie bei Bedarf "behoben" werden.

4.3.5 Prozessrechte

Prozesse haben ebenfalls einen Besitzer und eine Besitzer-Gruppe (meist derjenige, der den Prozess startet und seine Primäre Gruppe). Durch Vergleich der Besitzverhältnisse des Prozesses und der Dateien/Verzeichnisse, auf die er zugreifen will, wird ermittelt, welche Zugriffs-Rechte er konkret hat:

4.3.6 Besitzer(Gruppe)

Besitzer einer Datei/eines Verzeichnisses ist anfangs derjenige, der das Objekt anlegt, Besitzer-Gruppe ist anfangs seine Primäre Gruppe (meist "users" oder "staff"). "Alle Anderen" umfasst die restlichen Anwender und Gruppen.

Die Besitzer-Gruppe kann jederzeit vom Besitzer geändert werden. Der Besitzer kann nur vom Administrator geändert werden! Die Zugriffsrechte kann nur der Besitzer (oder der Administrator) ändern. Im Unterschied zu Windows gibt es also kein Recht, das einem die Besitzübernahme einer Datei oder die Änderung von Zugriffsrechten gestattet!

Da (nur) der Besitzer einer Datei immer ihre Zugriffsrechte ändern kann, kann er sich bei Bedarf immer die von ihm benötigten Zugriffsrechte daran verschaffen.

4.3.7 Gerätedateien

4.3.8 Sonderrechte

Neben diesen Standardrechten kennt Linux noch 3 Sonderrechte, die für ausführbare Dateien (Programme) bzw. Verzeichnisse mit speziellen Aufgaben gedacht sind:

Sie überlagern beim Auflisten eines Verzeichnisinhalts mit ls -l (long) die 3 x-Zugriffsrechte (da sie sowieso nur zusammen mit diesen sinnvoll eingesetzt werden können).

Beispiel für eine Ausgabe von ls -l (Verzeichnisinhalt auflisten):

  -rwsrw-r-- 1 tom staff  1724 2004-12-31 19:08 pgm1
  -rwxr-xs-x 1 tom staff 10001 2005-01-09 15:16 pgm2
  drwxrwxr-t 2 tom staff  8192 2005-01-09 17:19 tmpdir


Werden diese Sonderrechte groß dargestellt (d.h. als S oder T), so fehlt das jeweils "darunterliegende" x-Recht (eine an sich unsinnige Kombination). Beispiel für eine Ausgabe von ls -l (Verzeichnisinhalt auflisten):

  -rwSrw-r-- 1 tom staff  1724 2004-12-31 19:08 pgm1
  -rwxr-xS-x 1 tom staff 10001 2005-01-09 15:16 pgm2
  drwxrwxr-T 2 tom staff  8192 2005-01-09 17:19 tmpdir


4.3.9 Oktalform

Für alle 12 Zugriffsrechte kennt Linux neben der Textform mit den Kürzeln r w x s t auch eine numerische Form (Oktalzahl), die beim Kommando chmod zum Ändern der Rechte verwendbar ist (und auch bei anderen Kommandos wie z.B. umask, find).

Den 3 prinzipiellen Rechten "rwx" ist dabei eine feste Nummer zugeordnet (r=4, w=2, x=1), die an 3 verschiedenen Stellen stehen kann (je nachdem, ob die Rechte für den Besitzer, die Besitzer-Gruppe oder die "Anderen" gelten). An der 4. Stelle stehen die 3 Sonderrechte (Set-UID, Set-GID und Sticky):

Durch Aufsummieren der Zahlenwerte der Einzelrechte erhält man die dieser Rechtekombination entsprechende Oktalzahl, Beispiel:

4.3.10 Usage-Mask

Wird eine Datei/ein Verzeichnis neu angelegt, so gehört sie/es automatisch dem angemeldeten Benutzer und seiner aktuellen Gruppe (meist users oder staff). Als Standard-Zugriffsrechte werden die maximal sinnvollen eingestellt, d.h.

Begründung: Dateien sollen nur ganz selten ausführbar sein. Wird dies gewünscht, dann ist es mit dem Befehl chmod a+x DATEI explizit einzustellen. Verzeichnisse sollen immer ausführbar sein, sonst kann man nicht mit cd in sie hineinwecheln und nicht mit ls ihren Inhalt auflisten.

Mit dem Befehl umask können von diesen maximalen Rechten einige entfernt werden, während eine Datei oder ein Verzeichnis angelegt wird (für bereits angelegte Dateien/Verzeichnisse hat dieser Befehl keine Wirkung!). Normalerweise wird diese sogenannte Usage-Mask der zu entfernenden Rechte in Oktalform angegeben (genau deshalb muss man sich mit dieser Oktalform überhaupt auseinandersetzen). Hier einige umask-Werte und die daraus resultierenden Standardrechte:

Die Usage-Mask wird beim Login durch entsprechende umask-Befehle in den zentralen oder benutzerspezifischen Shell-Konfigurationsdateien (z.B. /etc/profile, ~/.profile oder ~/.bashrc) gesetzt. Sie hat pro Prozess (d.h. auch pro Anmeldung) einen eigenen Wert, der unabhängig von allen anderen ist. Mit dem Ende eines Prozesses geht auch sein Usage-Mask-Wert verloren.

Typische Standard-Werte der Usage-Mask sind 002 (z.B. OpenSUSE), 022 (z.B. Debian, RedHat), 007, 027 oder 077.

4.3.11 Weitere Rechte

Einige Dateisysteme kennen noch weitere Rechte pro Datei bzw. Verzeichnis, z.B. kennt Ext2/Ext3/ReiserFS folgende Rechte:

4.3.12 ACLs

ACLs (Access Control Lists) wie unter Windows NT/2000/2003/2008/XP/Vista/7 gab es unter Linux sehr lange nicht. Inzwischen werden sie aber von vielen Dateisystemen (z.B. Ext3, XFS, JFS, ReiserFS), aber eventuell noch nicht von allen Anwendungen unterstützt. Pro ACL-Benutzer und -Gruppe sind allerdings (wieder nur) die UNIX/Linux-Zugriffsrechte read, write und execute vergebbar.

Die üblichen Zugriffsrechte von UNIX/Linux kann man als 3-elementige ACL interpretieren (für einen Benutzer, für eine Gruppe und für alle anderen), die für einen Zugriff in dieser Reihenfolge von oben nach unten abgeprüft wird:

Dies ist definitiv ein Nachteil, allerdings kann die extensive Verwendung von ACLs und ACL-Vererbung zu einer unübersichtlichen Verrechtung führen, die normale Anwender nicht mehr verstehen.

Bezüglich ACLs haben Verzeichnisse unter Linux 2 Rechtesätze. Der 1. namens "Standard-ACL" gilt für das Verzeichnis selbst, der 2. namens "Default-ACL" gilt für alle darin neu erzeugten Objekte (Dateien und Verzeichnisse) zum Zeitpunkt des Anlegens. D.h. darüber wird eine "statische Vererbung" der Zugriffsrechte realisiert. Änderungen an Zugriffsrechten eines Verzeichnisses wirken sich daher nicht auf die Zugriffsrechte anderer Verzeichnisse oder Dateien aus ("Keep it Simple").

Die ACLs werden grundsätzlich verodert, d.h. es genügt, wenn ein Benutzer durch eine ACL ein Zugriffsrecht bekommt. Für alle ACLs gemeinsam gibt es allerdings eine Maske, über die die maximal erlaubten Zugriffsrechte festgelegt werden können. Diese Maske wird anstelle der Gruppenrechte angezeigt, sobald mindestens eine ACL zu einer Datei definiert wurde. Sie beeinflusst nicht die Zugriffsrechte des Besitzers und die "aller Anderen".

4.3.13 Vererbung

Unter Linux findet (bis auf eine Ausnahme: Set-GroupID-Recht) keine Vererbung der 12 Standard-Rechte statt. Jedes Verzeichnis und jede Datei hat ihren eigenen Standard-Rechte-Satz. Das Set-GroupID-Recht bei einem Verzeichnis sorgt dafür, dass dieses Recht selbst und die Besitzer-Gruppe beim Anlegen eines neuen Verzeichnisses darin an dieses vererbt wird.

Der 2. ACL-Rechtesatz von Verzeichnissen wird beim neu Anlegen von Dateien und Verzeichnissen darin an diese als Standard-Rechtesatz und als Default-Rechtesatz vererbt.

Durch Änderung der Zugriffsrechte eines Verzeichnisses kann der Zugang auf den kompletten Dateibaum darunter beeinflusst (erlaubt/gesperrt) werden (sofern keine Hard Links von außen auf Dateien in diesem Dateibaum zeigen).

4.4 Komplexität

Für den gleichen einfachen Fall ergeben sich bei Windows 3⁶ × 3⁶ = 729 × 729 = 531441 prinzipielle Rechtekombinationen (alle Kombinationen von 6 Verzeichnisrechten (egal, setzen, wegnehmen), alle Kombinationen von 6 Dateirechten (egal, setzen, wegnehmen)). Viele davon sind unsinnig (welche???), das Erzeugen und Ausprobieren aller dieser Kombinationen ist praktisch unmöglich.

Durch die bei Windows üblichen ACLs auf Gruppen und Benutzer wird die Anzahl der Rechtekombinationen sehr hoch, mit entsprechenden Folgen für die Übersicht und Verständlichkeit.

Bei Verzicht auf ACLs bleibt das Linux-Rechtemodell sehr einfach. Aber auch wenn ACLs verwendet werden, ist die Verständlichkeit der möglichen Rechtekombinationen einfacher als bei Windows.

4.5 Fazit

Die unter Windows NT/2000/2003/2008/XP/Vista/7 vorhandenen feingranularen Möglichkeiten zur Zugriffsrechte-Steuerung werden aufgrund der Windows-Historie von den Windows-Anwendungen zu wenig berücksichtigt. Daher gibt es auch heute noch Windows-Anwendungen, die Zugriffsrechte nicht beachten und nur mit Administrator-Rechten laufen (z.B. Spiele). Das Windows-Zugriffsrechte-System ist komplex.

Zugriffsrechte-Systeme sollten einfach sein, damit Anwender sie auch verstehen können, nur dann werden sie (vernünftig) eingesetzt. Sie sollten aber auch leistungsfähig genug sein, um die wichtigen Anwendungsfälle abzudecken. Das Linux-Standard-Rechtesystem (ohne ACLs) erfüllt diese beiden Kriterien. Bei ACLs sind die Meinungen geteilt, auch wenn Windows-Kenner es für das Non-plus-ultra halten und vom Standard-Linux-Rechtesystem erst einmal enttäuscht sind.

Anmerkung zu ACLs: Aufgrund der nicht-transparenten Handhabung bei entsprechend umfangreicher Benutzer-/Gruppen-/Verzeichnisanzahl und Berechtigungsschemata entstehen gerade dadurch ungewollte Sicherheitslöcher (welcher Windows-Administrator hat noch nicht die Klage eines Anwenders erlebt: "Ich kann auf (m)eine Datei nicht zugreifen" und sich dann auf eine längere Suche gemacht, warum das so ist).

5 Kleine Unterschiede

5.1 Spezielle Verzeichnisnamen

5.2 Standard-Ein/Ausgabe

5.3 Spezielle Zeichen

5.4 Quotierung

5.5 Rechte-System

5.6 Variablen

5.7 Prompt

6 Kommando-Vergleich

6.1 Kommandos allgemein

6.2 Aliase

6.3 Netzwerk-Kommandos

6.4 Datei-Kommandos

6.5 Verzeichnis-Kommandos

6.6 Datenträger-Kommandos

6.7 Cut/Copy/Paste

6.8 Sonstige Kommandos

7 Samba

Einerseits sind wir dankbar, dass es Samba gibt und setzen es (von uns aus und auf Kundenwunsch) auch gerne ein. Uns gefällt vor allem die Möglichkeit, auf UNIX/Linux-Ebene einzugreifen (per Scripting oder ähnlichem), um etwas elegant "unter dem Dateisystem" zu realisieren, was auf der Windows-Seite nur schwer möglich wäre.

Andererseits erschliesst sich der Sinn dieser Vorgehensweise (das Nachprogrammieren großer Teile der Funktionalität von Windows-Servern und -Clients in Form von Samba und CIFS) von Jahr zu Jahr immer weniger aus folgenden Gesichtspunkten:

• Damit wird Windows als Client erst recht zementiert, alle Alternativen müssen auch die Windows-Protokolle sprechen.
• Die Lücke zwischen Windows und Samba wird immer > 0 bleiben, das Rennen ist für Samba prinzipiell nicht zu gewinnen.
• Es gibt immer wieder feine Abweichungen zwischen dem Verhalten von Windows-Servern und der Samba-"Emulation", die man nicht hätte, wenn man stattdessen gleich einen Windows-Server benutzen würde (z.B. Drucken, BDC, …).
• Die Analyse und Behandlung dieser Abweichungen erfordert tiefes Wissen auf Windows, Samba und UNIX/Linux-Ebene gleichzeitig. Welcher Durchschnitts-Administrator hat dieses schon?
• Die UNIX/Linux-Umgebung unterhalb von Samba und die Interaktion von Samba mit Windows und dem UNIX/Linux-Basissystem wird von vielen Windows-Administratoren gar nicht verstanden. Unseres Erachtens darf man aber Samba guten Gewissens nicht einsetzen, wenn dieses Wissen nicht vorhanden ist.
• Das ACL-Rechtesystem von Windows ließ sich sehr lange nicht in Samba nachbilden. Die unter UNIX/Linux zur Verfügung stehenden POSIX-ACLs sind dafür nicht ausreichend, da sie nur die Rechte rwx kennen. Inzwischen gibt es Mechanismen, die das komplette Windows-Rechtesystem für Samba auch unter UNIX/Linux nachbilden. Allerdings ergibt sich daraus wieder das Problem, dass auf dem UNIX/Linux-Basissystem eine andere Rechtesystematik herrscht als auf den von Samba verwalteten Freigaben. Gibt es Zugriffe auf die gleichen Dateien unter beiden Systemen, dann entstehen regelmäßig Probleme mit zuwenig oder zuviel vergebenen Zugriffsrechten
• Ein Active Directory Domänencontroller kann mit Samba bisher nicht realisiert werden. D.h. man muss bei NT Domänen bleiben, wenn man Samba als Domänencontroller einsetzten möchte. Inzwischen gibt es aber Admin- und auch User-Software im Windowsbereich, die Active Directory zwingend voraussetzt (z.B. AppSense, Altiris). Mit Samba 4 ist hier eine Lösung im Entstehen, die aber noch nicht produktiv eingesetzt werden sollte
• OpenLDAP als Basis für die Benutzer- und Gruppendatenbank von Samba ist keine Software, die grosses Vertrauen erweckt. Aus gutem Grund wird inzwischen von den Samba-Entwicklern die für Samba notwendige LDAP-Teilmenge nachprogrammiert (auch so eine kritisch zu hinterfragende Mehrfachentwicklung ;-).

• Da Microsoft das SMB-Protokoll nicht offenlegte (inzwischen durch die EU erzwungen), reverse engineeren die Samba-Entwickler das Protokoll, indem sie den Netzwerkverkehr zwischen Windows-Rechnern "mitsniffen", seine Bedeutung entschlüsseln und es anschließend sauber dokumentieren. Wir wissen aus persönlicher Quelle von Samba-Entwicklern, dass dies eine ungeheuer aufwendige Arbeit ist. Wir bewundern sie dafür!
• Das Ergebnis ist eine vollständige und saubere Dokumentation des SMB-Protokolls (warum muss das nicht aufgrund von Gesetzen der Hersteller leisten?).
• Es gibt Szenarien (Konsolidierung mehrerer Windows-Server auf einer Maschine), die nur mit Samba machbar sind.
• Die Konkurrenz durch Samba zwingt Microsoft zu ständiger Verbesserung der Software im Sinne von Fehlerkorrektur und neuen Merkmalen.
• Die Konkurrenz durch Samba zwingt Microsoft zu preislicher Reaktion.
• Die Samba-Entwickler haben nun mal mit Samba angefangen, jetzt müssen sie auch weitermachen, damit alle, die Samba einsetzen nicht enttäuscht werden. Auch dafür kann man die Samba-Entwickler nur bewundern!
• Die Samba-Entwickler können das alles mit einer viel kleineren Mannschaft als Microsoft. Das Samba-Kernteam z.B. besteht nur aus etwa 20 Leuten!

Das ist alles sehr schön und angenehm. Das Resultat ist aber letztendlich die Zementierung einer (über viele Jahre gewachsenen und damit teilweise inkonsistenten und kaputten) Protokollfamilie, deren undokumentierte Entwicklung aufgrund von Marketingzwecken technischen Prinzipien nicht so gehorcht, wie man das gerne hätte.

Nichts für ungut, das soll weder eine Kritik an Samba noch an Windows sein. Wir sind nur gelegentlich am (ver)zweifeln, ob das wirklich alles so sein muss oder ob nicht eine komplett andere Alternative besser wäre:

Anstelle dem Nachprogrammieren des im Wesentlichen für lokale Netzwerke gedachten SMB-Protokolls unter UNIX/Linux ein WAN-Protokoll sauber konzipieren und dann implementieren, mit dem die gleichen Dinge möglich sind, das aber auch für Netzwerke mit langsamen und gestörten Verbindungen gut funktioniert und das auf allen Rechnerplattformen (Windows, UNIX/Linux, Apple OS X) einheitlich implementiert und weiterentwickelt wird.

8 Todo

8.1 Windows Vista und Windows 7

• User Account Control (UAC).
• Protected Mode des IE 7.
• IE 7.
• DirectX 10.
• Neuere Treiber als bei XP sind dabei.
• Neue Werkzeuge (z.B. crcdisk).
• Einige Verbesserungen, die die meisten Leute gar nicht benutzen (z.B. EFS).

8.2 Grafische Oberfläche

• Linux-GUIs und -Anwendungen sind leichter an hohe Bildschirmauflösung anpassbar (Größe der Symbole, Taskleiste, Beschriftung der Fenster, Menüs, Dialogboxen), bei Windows muss dies der Grafikkartentreiber zur Verfügung stellen (NVidia, ATI).
• Einfacher Mausklick bei Linux, doppelter Mausklick bei Windows zum Programmstart oder Öffnen einer Datei verwendet (in KDE sogar einstellbar). Dies führt häufig dazu, dass Anwender "grundsätzlich" doppelklicken, auch wenn dies (z.B. in Webbrowsern) überhaupt nicht sinnvoll ist.
• Windows ist die "Verniedlichung" eines Betriebssystems (durch Grafik, Icons, Farben, Dialogboxen, …). Es erzeugt die Illusion, alles kann per "Point-and-Click" bedient werden.
• Point-and-Click-Sequenzen sind schlecht reproduzierbar. Weiterhin kann es sein, dass die Reihenfolge oder die Geschwindigkeit der Clicks eine Rolle spielt, ohne dass dies aus der Oberfläche ersichtlich ist.
• Unter Windows gibt es viele Erfolgsmeldungen (Messageboxen), die man umständlich wegklicken muss (auch unter Linux bei KDE). Oft werden sie daher gar nicht mehr gelesen (zu viel Text oder der Text ist unverständlich), obwohl sie gelegentlich wichtige Warnungen/Hinweise enthalten.
• Unter Windows gibt es viele grafische Gimmicks ("fliegender" Ordner beim Datei-Kopieren), die Performance kosten, aber eigentlich keinerlei Mehrwert bieten, außer den Anwender während der Wartezeit zu unterhalten (auch unter Linux bei KDE).

8.3 Security

• Zumindest der 1. User, der bei einer Installationen angelegt wird, ist unter Windows automatisch Administrator (Sicherheitsproblem).
• Bei KDE ist eine Anmeldung an die grafische Oberfläche ohne Passwort für einen bestimmten Benutzer einstellbar (Sicherheitsproblem).
• Das Verzeichnis C:\…\system32 ist für alle Anwender schreibbar (Sicherheitsproblem).
• Software-Kopierschutz erfordert direkten Hardwarezugriff = Adminrechte (Sicherheitsproblem).
• Für hohe Spiele-Performanz ist Direktzugriff auf Hardware nötig = Adminrechte (Sicherheitsproblem).
• Windows ist nur dann "einfach", wenn man ständig als Administrator arbeitet (Sicherheitsproblem).
• Eine homogene IT-Landschaft ist zutiefst "unsicher".
• Wie die genetische Verschiedenheit verhindert, dass eine Epidemie eine ganze Spezies auf einmal auslöscht, ist auch die Verschiedenheit in der Software eine feine Sache. [Clifford Stoll, Das Kuckucksei]
• Starke Integration der Anwendungen unter Windows (-> Sicherheitsproblem, aber z.B. Startzeit von Programmen unter Windows deutlich kürzer)
• Sicherheit tut immer weh ("Security always hurts").
• Choose Two: Easy, cheap, secure.
• Windows: Application driven policy, Linux: Security driven policy.
• Installation oder Betrieb einer Windows-Anwendung schreibt im Hintergrund die Firewall-Regeln um, damit Kontakt nach außen möglich ist.
• Der HTTP-Port 80 wird in zunehmenden Maße für andere Zwecke missbraucht, weil Firewalls ihn praktisch immer durchlassen ("Tunnel").
• Dass etwas schief geht, wird unter Windows in Kauf genommen, die Usability zählt mehr.
• Unterschied Open Source <-> Closed Source (Sourcecode).
• Der Linux-Quellcode ist verfügbar -> Software-Review möglich.
• Personal-Firewalls auf dem Arbeitsplatzrechner gaukeln dem Anwender eine Sicherheit vor, die nicht gegeben ist (da von der Software auf dem Rechner jederzeit manipulierbar).

8.4 Standards

• ActiveDirectory = Kombination der 4 Standard-Protokolle LDAP + DynamicDNS + Kerberos + CIFS (mit ein paar Microsoft-Spezifischen Erweiterungen, z.B. das LDAP-Schema).
• MS-Office und seine Dokumentenformate sind ein proprietärer Standard (nicht beeinflussbar, nicht offengelegt, ständig geändert!).
• DOC/XLS/PPT-Dateien von MS-Office sind 1:1 mit StarOffice bzw. OpenOffice austauschbar (bis auf Dinge wie: Makros, einige eingebettete Objekttypen (WAV, andere Office-Dokumente), MS-Excel-Add-Ins).
• Die von Microsoft inzwischen angekündigte/verwirklichte Verwendung von XML zur Datenspeicherung ist kein Allheilmittel für den Datenaustausch. XML sorgt nur für eine standardisierte (Grund)Syntax, die konkrete Syntax (und ihre Semantik) wird dadurch nicht festgelegt (das drückt schon der Name "extensible" aus!). D.h. es ist ohne Dokumentation sehr schwer, eine konkrete Syntax (und ihre Semantik) zu verstehen. Weiterhin sind viele verschiedene konkrete syntaktische Ausprägungen vorstellbar, die für den gleichen Sachverhalt denkbar. Auch hier sind sind also hochkomplexe, proprietäre Formate möglich, die mit Patenten geschützt werden.
• Dokumentenformate (Inkompatibilitäten), XML (kein Standard).
• Standard-Anwendungen.

8.5 Kommandozeile

• Quotierung von Parametern auf der Kommandozeile mit '…' und \ funktioniert unter Windows nicht.
• Kommando-Substitution auf der Kommandozeile mit `…` oder $(…) funktioniert unter Windows nicht.
• Inzwischen sind die Linux-Werkzeuge auch unter Windows verfügbar: SFU 3.5, Cygwin, GNUwin
• Inzwischen Betonung der Kommandozeile (z.B. Kommando net) auch unter Windows. Warum dann nicht gleich Linux nehmen?
• Der Unterschied zwischen absolutem/relativem Pfad wird durch die grafische Oberflächen nicht mehr wahrgenommen (die Anwender wissen nicht mehr, was sie wo abgelegt haben).
• Vergleich der Kommandosyntax (Parameter + Optionen).
• Hard Link unter Windows NTFS mit fsutil hardlink create HARDLINK ORIGINALFILE oder mklink /h LINK ORIGmöglich
• Symbolischer Link unter Windows NTFS mit fsutil hardlink create HARDLINK ORIGINALFILE oder mklink /H LINKFILE ORIGFILE oder mklink /D LINKFILE ORIGDIRmöglich.
• Junction Point (symb. Link zu lokalem Verz.) unter Windows NTFS mit linkd oder mklink /J LINK ORIG oder junction -d LINK ORIG möglich.
• Reparse Point unter Windows NTFS mit fsutil hardlink create HARDLINK ORIGINALFILE möglich

8.6 Netzwerk

• Fernadministration (z.B. mit VNC).
• Netzwerk-Unterschiede (NFS, LANManager, NetBIOS, SMB, CIFS, Samba, Laufwerke, transparent eingebunden, TCP/IP, Windows ist broadcast-orientiert).
• Domänen-Konzept (zentrale Benutzerverwaltung) unter Windows?
• Unterschied Active Directory <-> OpenLDAP + DNS + Kerberos + CIFS.
• TCP/IP-Stack bei Windows wurde nachträglich "aufgepfropft".

8.7 Interner Aufbau

• Modulare Struktur von Linux.
• Komplexitätsvergleich der beiden Betriebssysteme (Anzahl Zeilen, Schnittstellen, interne Struktur, Dokumentationsumfang).
• Gruppen (Linux: max. Mitglied in 16/32 Gruppen, aber mit Kernel-Patch mehr möglich, keine Verschachtelung von Gruppen, Anzahl Mitglieder in einer Gruppe beschränkt?).
• Ressourcen-Verbrauch?
• Dynamically Loaded Libraries (*.dll) <-> Shared Objects (*.so).
• Bluescreen <-> Kernel panic.
• HAL (Hardware Abstraction Layer).
• RunAs <-> sudo.

8.8 Dateisystem

• Windows Laufwerk-Buchstaben sind Hardware-abhängig, werden aber in Dateipfaden (z.B. bei mehrteiligen Word- oder Exel-Dokumenten) "hardcoded" (bei Änderung der Plattenstruktur müssen alle Konfigurationsdaten geändert werden). Dies kann durch geänderte Referenzierung in der Form \\SERVER\FREIGABE\PFAD_ZU_DATEI umgangen werden (wer macht sowas schon?, Freigaben werden meist über Laufwerk-Buchstaben eingebunden!).
• Fragmentierung der Dateisysteme?
• Wirkung des "SYS"-Rechts unter Windows?
• Saubere Pufferung bei montierten (Wechsel)Laufwerken unter Linux leichter als unter Windows.
• ADS (Alternate Data Streams) in NTFS.
• Windows: Zeichen NUL-Byte in Dateinamen erlaubt (bei Linux nicht)?
• Will man vollständig portabel bleiben, sollten in Dateinamen ausschließlich folgende Zeichen verwendet werden:

  A...Z a...z 0...9 - . _

  Weiterhin sollte das Zeichen - nicht am Anfang eines Dateinamens stehen.
• Die Anwender können bei der Ablage von Dateien häufig nicht unterscheiden zwischen:
  1. Desktop
  2. Eigene Dateien
  3. Lokalem Laufwerk
  4. Netzwerklaufwerk

8.9 Sonstiges

• Reale(r) und Effektive(r) User/Gruppe (UID, GID, EUID, EGID).
• Samba, OpenLDAP, Kerberos und CIFS.
• Forrests und Sites in Windows-Domänen.
• Anforderungen der Privatanwender / Firmenanwender / Client / Desktop / Server sind völlig unterschiedlich!
• TCO (Total Cost of Ownership) und ROI (Return of Investment) Vergleich.
• Marketing -> ständig neue Namen für vergleichbare Produkte.
• Featuritis unter Windows (und auch unter Linux, siehe Optionen der GNU-Tools).
• MIME-Typen.
• COM, COM+, DCOM, ActiveX, .NET (Mono unter Linux!).
• Gibt es "Strg-X" unter Linux?
• GNU.
• Linux: Viel Anwendungs-Software mitgeliefert.
• Links auf andere Vergleiche.
• Quellenangaben.
• Windows: Betriebssystem und GUI/Explorer eng verzahnt.