Tschüß, M$! - Willkommen in der Freiheit

[Frank Klemm]

Frank Klemm: Klar, die Powershell bring schon viele Vorteile. Programmiert man direkt in der Shell oder was meinst du mit Programmiersprache?

Die Powershell ist eine turing-vollständige Programmiersprache. Die Bash ist es nicht. Die Bash ist nie designt worden, aber immer ein klein bißchen weiterentwickelt. Richtige Probleme sind nie gelöst, sondern immer nur ein weiteres Schwalbennest zum Umgehen rangehängt worden, bis keiner mehr durchgeblickt hat. Konstrukte wie `'"@$"'` gibt es in Unmassen, um Interpretationen von Texten in bestimmten Reihenfolgen zu erzwingen. Viele Scripte funktionen sofort nicht, wenn man Sonderzeichen in Dateinamen hat. Mit ", `, ', eval und noch einem ganzen Haufen von Hilfsmitteln schafft man es meist trotzdem, dem Programm nach vielen Versuchen die richtige Bedeutung zu gehen. Allerdings gibt es auch Fälle, die in der Bash nicht lösbar sind.

Klar, die Shells unter Unix sind aus den Anfängen, aber auch diese sind kontinuierlich weiterentwickelt worden und ich muss sagen vom Umfang her schon sehr groß.

Die Sprachen (bash, csh, ksh) sind nicht weiterentwickelt worden, sondern sie sind notdürftig erweitert worden, ohne generelle Probleme zu lösen. Hinzu kommt noch, daß in den letzten 10 Jahren gar nichts mehr passiert ist und es viele interne Restriktionen gibt (command line too long), die man immer wieder ein bißchen verschoben hat.

Auch die Möglichkeiten von Shellscripten und Interaktion mit anderen Programmen (awk, sed, perl, etc) sind ausgereift.

Monad braucht kein awk oder sed. Man sollte sich überlegen, warum es sackweise solche Tools für die Unix-Shells gibt. Der Grund ist, daß die Sprache nicht vollständig ist und man für einfachste Dinge Zusatzprogramme braucht, um einfache Aufgaben erledigen zu können. Ein weiteres Problem ist, daß die Kommunikation per Texte mit Inline-Signalling erfolgt. Jede Interpretationsstufe wirft für folgende Stufen wichtige Informationen weg. Ein schönes Beispiel:

$ rm -i *

in einem Verzeichnis mit einer Datei "-rf". In einem System, welches Konzepte der 90er Jahre beinhaltet, würde der Dateiname "-rf" nicht in eine Option "-rf" konvertiert werden.

Das Zusatztool perl gehört in eine andere Gruppe, die heißt, daß man Shells zum Aufrufen ordentlicher Scripting-Systeme verwenden soll. Das hat nichts mit der Leistungsfähigkeit der Shell zu tun, sondern mit der Möglichkeit, dieses Gefängnis zu verlassen.

Das Problem wird nun bei der Entwicklung sein, wofür entwickel ich? Gerade als Admin muss man nun berücksichtigen, ob man schon auf Vista umgestiegen ist oder noch eine XP/2K Umgebung oder sogar eine Mischumgebung hat. Oder kann man die Shell auch unter XP Pro/2K installieren?

Sie läuft unter Windows XP. .NET Version 2 - Framework installieren (das ist die libc des aktuellen Jahrzehnts ;-) und dann kannst Du Monad installieren. Aufruf erfolgt mit "msh".

Kristian Köhntopp: ,,Benutze Perl. Shell will man können, dann aber nicht benutzen.''

Ein Streitgespräch über die Schwächen der Unix Shells gab es in den 1990er Jahren in diversen Unix und BSD-Newsgruppen. Microsoft hat nach 10 Jahren darauf reagiert (es gibt eine Schwachstellenanalyse der Unix-Shells, die genau die in den späten 1990er Jahren diskutierten Punkte enthält). Eine Chance, daß dort unter Unix/Linux/BSD was passiert, sehe ich im wesentlichen über das Mono-Projekt. Schob verstorbene Mitglieder der "Church of Linux" werden sich wahrscheinlich bei dem gedanken schon im Grabe umdrehen ...

 

[Frank Klemm]

Warten wir erstmal ab, bis sie sich bewährt! Im übrigen ist diese Museums-Shell in ihren Abwandlungen sehr genügsam und läuft auch auf kleinsten Systemen.

Speicherbedarf auf der Platte:
* ca. 50 MByte für den .NET 2.0-Framework (wenn er nicht schon installiert ist)
* ca. 4 MByte für das Monad-System
gegenüber
* ca. 8 MByte für die benötigten Bibliotheken (dort allerdings immer schon installiert)
* ca. 0,6 MByte für die Shell.
Beide Größen sind allerdings für heutige Festplattengrößen irrelevant, wenn man 20.000 MByte an Programmen installiert hat.

Wer sich über 50 MByte + 4 MByte aufregt, kann das Spiel aber genauso rückwärts gehen und sich über die Monstergröße der aktuellen Bash aufregen (Anfang der 90er hatte eine HPUX-Sh um die 60 Kbyte.

Es stimmt das Shell-Scripting ist nicht die einfachste Form, aber man sollte nicht vergessen, dass die Shell ja nicht nur für Skripte gedacht ist, sondern um diverse alltägliche Aufgaben darauf effizient zu erledigen

Nicht einfach => nicht effizient. Ich bin häufig genug bei einem Perl-Programm oder C-programm gelandet, weil das Problem prinzipiell nicht mit der Bash lösbar waren.

und die sind in der Regel von der Natur <Befehl (meistens aus drei Buchstaben )> <Optionen> <Parameter>... Also ganz einfach und direkt.

Unter Monad sind sie noch einfacher. Insbesondere haben Kommandos einen herleitbaren Namen (alle Löschbefehle fangen mit remove- an, alle Kopierbefehle mit copy-, u.s.w.). Unix-Anwender brauchen sich nicht umzugewöhnen, mit Aliasen kann man einen Großteil der Funktionalität der Bash nachbilden, wenn man das unbedingt will.

MSH C:\> $a=dir
MSH C:\> $a
Zeigt inhaltsverzeichnis an
MSH C:\> $a | sort LastWriteTime
Zeigt Inhaltsverzeichnis nach der letzten Schreibzeit an.
MSH C:\> $a[4]
Zeigt fünfte Datei im Verzeichnis an.
MSH C:\> $a[4..6]
Zeigt fünfte bis siebte Datei im Verzeichnis an.
MSH C:\> get-childitem . | measure-object -property length -sum
Bytes aller Dateien im aktuellen Verzeichnis.
MSH C:\> get-childitem . | measure-object -property length -sum -average -min -max
Bytes aller Dateien im aktuellen Verzeichnis + durchschnittliche Größe + minimale Größe + maximale Größe.
MSH C:\> "hallo welt!".ToUpper()
HALLO WELT!
MSH C:\> for ( $i = 3; $i -lt 100; $i += 2 ) { $np=1; for ( $j = 3; $j * $j -lt $i; $j += 2 ) { if (
$i % $j -eq 0 ) { $np=0; break ; } } if ( $np -eq 1 ) { write-object $i } }
Primzahlen zwischen 3 und 100.
MSH C:\> $a=get-history -count 32767
Lesen der Historyliste
MSH C:\> $a.length
Wieviele Einträge hat diese?

So, das sind vorsichtige Beispiele. Das ganze geht bis hin zu ganzen fensterbasierten Applikationen.

Alte Microsoft-Manier: Ideen nehmen, Schwachstellenanalyse, Programmieren und dann drauf hoffen, daß es andere nicht nachimplementieren, weil es per Definition Evil ist.

 

[DerDude]

Speicherbedarf auf der Platte:
* ca. 50 MByte für den .NET 2.0-Framework (wenn er nicht schon installiert ist)
* ca. 4 MByte für das Monad-System
gegenüber
* ca. 8 MByte für die benötigten Bibliotheken (dort allerdings immer schon installiert)
* ca. 0,6 MByte für die Shell.
Beide Größen sind allerdings für heutige Festplattengrößen irrelevant, wenn man 20.000 MByte an Programmen installiert hat.

Beide Größen? Du hast vier aufgezählt, aber egal. Ich habe übrigens von kleinen Systemen gesprochen, z.B. Router-Boxen, wie der berühmte Linksys WRT.

Wer sich über 50 MByte + 4 MByte aufregt, kann das Spiel aber genauso rückwärts gehen und sich über die Monstergröße der aktuellen Bash aufregen (Anfang der 90er hatte eine HPUX-Sh um die 60 Kbyte.

Ich rege mich nicht auf. Aber erzähl mir doch nicht, dass eine Shell, das komplette .net-Framework verlangt genügsam ist.
Dass die bash auch größer wird ist ja normal und auch kein Problem. Es ist alles eine Frage der Größenordnung.

Nicht einfach => nicht effizient. Ich bin häufig genug bei einem Perl-Programm oder C-programm gelandet, weil das Problem prinzipiell nicht mit der Bash lösbar waren.

Ich sehe nichts schlimmes darin Perl oder Python zu benutzen.

Unter Monad sind sie noch einfacher. Insbesondere haben Kommandos einen herleitbaren Namen (alle Löschbefehle fangen mit remove- an, alle Kopierbefehle mit copy-, u.s.w.).

OHH wie innovativ!!! unter Linux beginnt es mit rm... na und?

Unix-Anwender brauchen sich nicht umzugewöhnen, mit Aliasen kann man einen Großteil der Funktionalität der Bash nachbilden, wenn man das unbedingt will.

Wenn jemand sowas unter Unix/Linux implementiert, wird sie wohl auch so benutzt wie es gedacht ist.
Andererseits ist es fraglich, warum eine Shell eine ganze Programmiersprache implementieren muss, wenn es doch wunderbare interpretierte Sprachen gibt.

So, das sind vorsichtige Beispiele. Das ganze geht bis hin zu ganzen fensterbasierten Applikationen.

Ist eben die Frage, warum ich Applikationen als Shell-Skript realisieren sollte -- kann ich viel besser in einer geeigneten Programmiersprache. Es geht ja vielmehr darum, gewisse Sprachkonstrukte auch in der Shell zu haben. Es gibt zu diversen Sprachen Shells: Java (geht natürlich nicht in beliebiger Ebene, da die Sprache nicht interpretiert ist), Perl, Python...

Ich habe nichts gegen die PowerShell (auch wenn der Name mal wieder MS-typisch großkotzig ist), aber es ist auch nicht ein solch revolutionäres Konzept eine Sprache als syntaktisch/semantische Grundlage zu nehmen und Spracheigene Bibliotheken dabei einzubinden. Große Euphorie ist also überflüssig, auch wenn es für Windows gemessen am DOS-Prompt ein großer Schritt ist.
Vielleicht wird unter Linux auch etwas ähnliches mal auf Basis von Mono implementiert. Aber auch dann wird es bash, ash, esh, fish, zoid, psh, scsh, zsh, KornShell, IPython etc. nicht ersetzen, sondern neben ihnen existieren.
Vielleicht bekommen Shells im allgemeinen ja unter Windows jetzt mehr Bedeutung.

 

[photourist]

Wie wäre es, man würde unter Linux/BSD etc. die Systemshell(s) durch eine moderne objektorientierte Skriptsprache wie Python oder Ruby zu ersetzen?
Die Systemskripte umzuschreiben ist ja kein großer Akt.
Natürlich müssten aus Kompatibilitätsgründen die traditionellen Shells (sh, csh, (pd)ksh, bash, zsh etc.) weiterhin zur Verfügung stehen.

 

[uwet]

Spätestens im Jahre 2007 ist Linux endgültig reif für den Desktop und Windows - mit Vista - reif für die Mülltonne.
[/INDENT]

Kann ich nicht glauben. Ich kenne unter Linux nicht eine einzige Software die in meiner Firma ansatzweise nutzbar wäre. Mit Textverarbeitung und Tabellenkalkulation kann ich den Betrieb nicht verwalten. Und Probleme mit Windows habe ich eigentlich seit WIN 98 und meinen Gamerzeiten nicht mehr.
Ich wäre froh eine vernünftige Wahlmöglichkeit zu haben aber Linux ist dort auf Jahre keine Alternative.

 

[DerDude]

Wie wäre es, man würde unter Linux/BSD etc. die Systemshell(s) durch eine moderne objektorientierte Skriptsprache wie Python oder Ruby zu ersetzen?
Die Systemskripte umzuschreiben ist ja kein großer Akt.
Natürlich müssten aus Kompatibilitätsgründen die traditionellen Shells (sh, csh, (pd)ksh, bash, zsh etc.) weiterhin zur Verfügung stehen.

Es ist nicht notwendig. Ich kann in einem Skript einfach oben den verlangten Interpreter angeben und der wird dann verwendet.
Ein klassisches Shell-Skript beginnt mit "#!/bin/sh", ein perl-Skript etwa mit "#!/usr/bin/perl". Man kann also jederzeit in anderen Sprachen skripten. Die Anforderung an die Sprache ist lediglich, dass sie interpretiert ist. Also geht das z.B. mit Java oder C nicht.
Die Systemskripte umzuschreiben ist nicht unbedingt notwendig, denn sie laufen stabil und shell-skripte sind nun auch bei weitem nicht so unleserlich, wie es hier auf den ersten Blick scheinen mag. Dazu kommt eben, dass die Shell in Form einer bash -- oder auf kleinen Systemen die ash -- vielfach als vorhanden angenommen wird. Sehr elementare Skripte, die auch auf Minimalinstallationen laufen sollen setzen dann eben nicht das Vorhandensein eines perl- oder python-Interpreters voraus.

Edit: @photourist: mir fällt gerade auf, dass du möglicherweise eine Shell mit einer Sprache verwechselst! Eine Shell und Programmiersprache sind nicht identisch!

 

[DerDude]

Kann ich nicht glauben. Ich kenne unter Linux nicht eine einzige Software die in meiner Firma ansatzweise nutzbar wäre.

Es geht nicht darum, ob es Software dafür gibt, die du gerade brauchen kannst. Technisch ist Linux seit langem reif für den Desktop! Und es gibt auch keine technischen Hindernisse für Linux zu programmieren. Im Gegenteil.
Viele Softwarehersteller haben tatsächlich Schwierigkeiten mit OpenSource-Modellen, weil dies ein fundamental anderer Ansatz ist. Ich denke es bestehen da viele Vorurteile und Unsicherheiten, wie sich ein ClosedSource Produkt dort integriert. Dass es geht wird ja z.B. mit Bibble oder Oxygen bewiesen.

 

[photourist]

Es ist nicht notwendig. Ich kann in einem Skript einfach oben den verlangten Interpreter angeben und der wird dann verwendet.
Ein klassisches Shell-Skript beginnt mit "#!/bin/sh", ein perl-Skript etwa mit "#!/usr/bin/perl". Man kann also jederzeit in anderen Sprachen skripten. Die Anforderung an die Sprache ist lediglich, dass sie interpretiert ist. Also geht das z.B. mit Java oder C nicht.

Das ist mir völlig klar, bin ja selbst "Skripter". Doch hatte ich den Eindruck, dass hier die Skriptsprachen bzw. Systemshells unter Linux/Unix für veraltet gehalten würden (siehe weiter oben). Ihr Ersatz wäre lediglich eine kosmetische Maßnahme, die dem System insgesamt einen zeitgemäßeren Touch geben würde.

Die Systemskripte umzuschreiben ist nicht unbedingt notwendig, denn sie laufen stabil und shell-skripte sind nun auch bei weitem nicht so unleserlich, wie es hier auf den ersten Blick scheinen mag. Dazu kommt eben, dass die Shell in Form einer bash -- oder auf kleinen Systemen die ash -- vielfach als vorhanden angenommen wird. Sehr elementare Skripte, die auch auf Minimalinstallationen laufen sollen setzen dann eben nicht das Vorhandensein eines perl- oder python-Interpreters voraus.

Edit: @photourist: mir fällt gerade auf, dass du möglicherweise eine Shell mit einer Sprache verwechselst! Eine Shell und Programmiersprache sind nicht identisch!

Ich weiss auch, dass zwischen Interpreter und Shell zu unterscheiden ist. Doch bringt Python bereits eine interaktive Shell mit und für Ruby gibt es die "irb" (interactive ruby shell).

 

[Frank Klemm]

Beide Größen? Du hast vier aufgezählt, aber egal. Ich habe übrigens von kleinen Systemen gesprochen, z.B. Router-Boxen, wie der berühmte Linksys WRT.

Genügsamkeit ist das Verhältnis aus benötigten Ressourcen und verfügbaren Ressourcen. Verfügbare Ressourcen können mittlerweile von 2 KByte (8-bit MC) bis 1 GByte RAM/>>100 GByte Festplattenplatz.

Auf einem 8 bit-MC hat eine Bash eine astronomische Größe, auf einem aktuellen Rechner ist die Größe der Monad-Shell vernachlässigbar.

Ein Programm hat nie die Eigenschaft genügsam, sondern erst eine Kombination Programm/Rechner.

Eine andere Eigenschaft ist die Geschwindigkeit und der Hauptspeicherverbrauch. Hier ist die Bash für größere Aufgaben sehr ressourcenfressend. Zum einen ist sie langsam, zum anderen kann sie nicht effizient mit größeren Listen umgehen (sie kann Listen nicht sequentiell aufbauen und abarbeiten).

Ich rege mich nicht auf. Aber erzähl mir doch nicht, dass eine Shell, die das komplette .NET-Framework verlangt, genügsam ist.

Ich rege mich nicht auf. Aber erzähl mir doch nicht, dass eine Shell, die die libc.so verlangt, genügsam ist.

Ich sehe nichts schlimmes darin Perl oder Python zu benutzen.

Ich auch nicht. Allerdings sind die Fähigkeiten von Perl, Python oder Tcl/Tk keine Fähigkeiten der Bash. Die dazu notwendige Funktionalität der Shell ist das "#!"-Kommando (übrigens auch nachträglich dazugekommen).

OHH wie innovativ!!! unter Linux beginnt es mit rm... na und?

Bei rmdir stimmt da ja noch.
umount heißt ja auch rmfilesystem
kill heißt ja auch rmprocess
unset heißt ja auch rmset

Wenn jemand sowas unter Unix/Linux implementiert, wird sie wohl auch so benutzt wie es gedacht ist.
Andererseits ist es fraglich, warum eine Shell eine ganze Programmiersprache implementieren muss, wenn es doch wunderbare interpretierte Sprachen gibt.

Vielleicht gibt es Leute, die nicht dauernd die programmiersprache wechseln wollen, wenn sich Anforderungen langsam verändern. Vielleicht weil es Leute gibt, die nicht die Muse haben, für jede Spezialaufgabe eine neue Programmiersprache zu lernen? Monad würde ich mit TcL/Tk vergleichen. Damit hat es noch die meisten Ähnlichkeiten.

Ob ich nun eine vollständige oder unvollständige Programmiersprache implementiere, ist nur eine Sache von wenigen Kilobyte. Der Hauptaufwand steckt darin, daß das ganze auf ein größeres Subsystem aufgesetzt ist, das in meinen Augen zwei Nachteile und ca. 40 Vorteile hat. Die Nachteile sind die 50 MByte und der notwendige JIT-Compiler. Die Vorteile fangen bei der Unmöglichkeit von Pufferüberläufen an und gehen weiter in die Richtung, daß das ganze (endlich!) prozessorunabhängig wird.

Ist eben die Frage, warum ich Applikationen als Shell-Skript realisieren sollte -- kann ich viel besser in einer geeigneten Programmiersprache. Es geht ja vielmehr darum, gewisse Sprachkonstrukte auch in der Shell zu haben.

Wie zählt eine Bash von 1 bis 1.000.000 und druckt dabei alle Primzahlenpärchen aus?

Oder was praxisnäheres:
Man habe eine Liste von Verzeichnissen, in denen Unterverzeichnisse sind. Die Inhalte der Unterverzeichnisse sollen angezeigt werden, dabei sollen die Unterverzeichnisse alphabetisch sortiert werden und nach jedem Anfangsbuchstabenwechsel soll eine horizontale Zeile mit '-' gedruckt werden. Die Verzeichnisnamen können Leerzeichen enthalten. Das ganze soll sowohl unter deutscher wie unter englischer Locale laufen.

Ich habe nichts gegen die PowerShell (auch wenn der Name mal wieder MS-typisch großkotzig ist), aber es ist auch nicht ein solch revolutionäres Konzept eine Sprache als syntaktisch/semantische Grundlage zu nehmen und Spracheigene Bibliotheken dabei einzubinden.

Der Meinung bin ich auch. Trotzdem hat es keiner gemacht. Linux ist mir zu viel Sozialismus. Aus der moralischen Überlegenheit heraus unterläßt man viele notwendige Dinge. Dies ist ein harmloses Beispiel. Aber davon gibt es zu viele. Und es gibt weniger harmlose Beispiele (Systemtest!).

Ich habe nichts gegen Linux. Aber gegen zu viel Ideologie und gegen Probleme, die nach 10 Jahren immer noch so unbearbeitet sind und gleichzeiiges Aufregen über Schwachstellen in Windows, die vor 2 Jahren gründlich gelöst wurden. Probleme von Win95, Win98 und WinME werden heutzutage immer noch als Windows-Fehler hingestellt, obwohl sie seit WinNT 3.51 und WinXP home behoben sind.

 

[photourist]

Es geht nicht darum, ob es Software dafür gibt, die du gerade brauchen kannst. Technisch ist Linux seit langem reif für den Desktop! Und es gibt auch keine technischen Hindernisse für Linux zu programmieren. Im Gegenteil.
Viele Softwarehersteller haben tatsächlich Schwierigkeiten mit OpenSource-Modellen, weil dies ein fundamental anderer Ansatz ist. Ich denke es bestehen da viele Vorurteile und Unsicherheiten, wie sich ein ClosedSource Produkt dort integriert. Dass es geht wird ja z.B. mit Bibble oder Oxygen bewiesen.

Hier wird schon wieder die Tauglichkeit des Systems als solches mit der Tauglichkeit vorhandener oder nicht vorhandener Anwendungssoftware verwechselt. Jeder, der sich zum Thema Linux äußert, sollte sich fragen, ob er Linux oder die (nicht) vorhandene Software kritisiert.

Natürlich kann man vergleichend Gesamtlösungen für eine konkrete Aufgabenpalette - bestehend aus OS und Anwendungssoftware - nebeneinander stellen und deren jeweilige Tauglichkeit messen. Man sollte dann aber differenzieren, ob die Vor- und Nachteile, die sich dann herausstellen, zugunsten oder -lasten der Software oder dem OS gehen.

Ich denke, dass für viele - und für die Heimanwender im Besonderen - Linux sehr wohl für den Desktop taugt. Es sollten auch nicht einfache Heimanwender (wie wohl viele hier) als Entschuldigung immer wieder die Argumente der Business-Anwender in's Feld führen!

Eine breitere Anwender-Basis im Consumer-Bereich wird einer Verbreitung im Business-Bereich schon Vorschub leisten. Also traut Euch!

Das System als solches, also das System vom Kernel bis zum grafischen Desktop (KDE oder GNOME) samt der in den Distributionen durchschnittlich vorhandenen Anwendungssoftware, ist sehr wohl für den Desktop tauglich. Eine durchschnittliche Linux-Installation ist aus dem Stand schon für alle möglichen Alltagsaufgaben gerüstet ganz im Gegensatz zur "Windoze-Distribution", bei welcher mit "Outlook Express", "WordPad" und "Paint" Schluss ist.

Darüberhinaus ist es Sache der Software-Hersteller, die fehlenden Anwendungen bereitzustellen. Gewisse Produkte wie Applixware und WordPerfekt sind leider wieder vom Linux-Markt verschwunden. Andere, wie der FrameMaker, haben es nur bis zur Beta-Version oder einer Ankündigung geschafft. Vor allem sind auch die Umsteigwilligen und die schon überzeugten Linux-User gefragt, ihre Nachfrage laut anzumelden. Keinesfalls ist aber die Zurückhaltung oder Lähmung der Softwarehersteller Linux anzulasten.

Vielmehr sind ja viele Lücken durch freiwilliges Engagement der Community geschlossen worden bzw. zahlreiche Alternativen zu Vorhandenem entstanden: z.B. KOffice als sehr flexible komponentenbasierte All-in-One-Office-Lösung für den KDE-Desktop (inklusive Krita), Evolution (PIM-Lösung) oder K3B als Brennsoftware usw.

Irgendwann wird der Linux-Zug, wenn die Softwarehersteller weiter die Hände im Schoß ruhen lassen, im Stillen an ihnen vorübergezogen sein - nämlich wenn für alles Erdenkliche eine OpenSource-Lösung bereitstehen wird. Hier verpasst die Industrie gerade (monetäre) Chancen.

Leider hat OpenSource in der Regel keine große Lobby, da keine potenten Budgets für Werbung vorhanden sind (fehlende Anzeigenkunden für die Medien). Hat schonmal jemand eine Anzeige für KOffice, Evolution, Gimp, Blender oder K3B gesehen? Entsprechend wird auch die Fachpresse diese hervorragenden Produkte weiterhin geflissentlich "übersehen".

Ergänzung:
In vielen Tests von EBV-Software in Software- und Foto-Magazinen wird Gimp zwar in die Betrachtung mit einbezogen, oft aber nicht bewertet, "da es ja auch nichts koste". Der wahre Grund ist wohl, dass man die Anzeigenkunden der kommerziellen Produkte nicht vergraulen will.

 

[photourist]

[...] Aufregen über Schwachstellen in Windows, die vor 2 Jahren gründlich gelöst wurden. Probleme von Win95, Win98 und WinME werden heutzutage immer noch als Windows-Fehler hingestellt, obwohl sie seit WinNT 3.51 und WinXP home behoben sind.

Was ist z.B. mit den beschränkten und beschränkenden Laufwerksbuchstaben? Gibt's im Jahre 2007 immer noch! Statt einen Verzeichnisbaum wie in Unix einzurichten! Man könnte ja übergangsweise die Laufwerksbuchstaben durch Links auf diesen Baum abbilden, um sie später ganz abzuschaffen.

Wehe, Du installierst Windows und hast aus Versehen noch einen USB-Multi-Cardreader angestöpselt. Dann ist das Systemlaufwerk plötzlich Laufwerk "H" oder ähnlich. Das ist immer noch so ein Überbleibsel aus der Zeit der FloppyDisks, wo man nicht viel weiter als von "A:" nach "B:" oder höchsten bis "D:" denken konnte.

Dateisysteme? Hat sich da was getan? FAT, NTFS? Soll das etwa alles sein?

Hochskalierbare Journaling-Filesysteme? Benutzerrechte auf Dateisystemebene? Anscheinend Fehlanzeige (Man überzeuge mich gerne eines Besseren!)

 

[Frank Klemm]

Was ist z.B. mit den beschränkten und beschränkenden Laufwerksbuchstaben? Gibt's im Jahre 2007 immer noch! Statt einen Verzeichnisbaum wie in Unix einzurichten! Man könnte ja übergangsweise die Laufwerksbuchstaben durch Links auf diesen Baum abbilden, um sie später ganz abzuschaffen.

Ein Problem, was in der Professional-Reihe (OS/2, NT 3.5, NT 4.0, 2000, XP) nie existiert hat. Das ganze geht auf frühe OS/2-Zeiten zurück.

Es nutzt aber so gut wie keiner.

Du kannst Laufwerke oder einzelne Verzeichnisse über Shares ansprechen. Das ganze nennt sich UNC-Dateinamen. Weiterhin kannst Du Laufwerke so wie unter BSD mounten (das Basis-Dateisystem muß allerdings HPFS oder NTFS sein).

Das ganze ist projektiert worden, da habe ich noch mit MS-DOS 3.3 rumgemacht und Linus kannte sich noch nicht mit dem 386er Protected Modus aus und hat mit Minix rumgemacht.

Wehe, Du installierst Windows und hast aus Versehen noch einen USB-Multi-Cardreader angestöpselt. Dann ist das Systemlaufwerk plötzlich Laufwerk "H" oder ähnlich.

Der Standardbuchstabe, unter dem das Systemlaufwerk erreichbar ist, wird bei der Installation festgelegt und kann nicht geändert werden. Es verändert sich auch nicht aus Versehen. Alle anderen Laufwerke kannst Du umändern. Wenn es was zu meckern gibt, dann über die fehlende Möglichkeit des Read-Only-Mountens. Aber Linuxer kennen erfahrungsgemäß nur nicht existente Probleme, nie die wirklichen Schwachstellen.

Ein weiteres Medium, was nicht umgelegt werden kann, sind Laufwerke ohne Partitionen (zum gut deutsch: Floppy).

Das ist immer noch so ein Überbleibsel aus der Zeit der FloppyDisks, wo man nicht viel weiter als von "A:" nach "B:" oder höchsten bis "D:" denken konnte.

Du kannst bei aktuellen Rechnern ohne Floppy bis auf C: vollständig laufwerksbuchstabenfrei arbeiten. Bei alten Rechnern mit einem Floppylaufwerk kommt noch A: und bei zwei Floppylaufwerken kommt noch B: hinzu.

Dateisysteme? Hat sich da was getan? FAT, NTFS? Soll das etwa alles sein?

NTFS gibt es in der fünften Version. FAT32 versucht Microsoft auszurotten, aber die Benutzer nutzen es weiter.

Hochskalierbare Journaling-Filesysteme?

NTFS ist ein Journaling-Dateisystem. War es von Anfang an. Größe pro Partition ist derzeitig auf 2 TB begrenzt.
Bei Vista 64 fällt diese Grenze (die übrigens seit fast 7 Jahren da drohnt). Ich erinnere mich noch an die Probleme mit Linux, als die ersten Partitionen größer als 2 GByte, 8 GByte, 32 GByte und 128 GByte waren. Es gab immer irgendwelchen Ärger, weil es immer versteckte Fehler im Dateisystemtreiber gab, die man mit aktuellen Platten sofort hätte bemerken müssen. Auf Anfrage dazu mehr.

Benutzerrechte auf Dateisystemebene?

ACLs gibt es unter Windows und Solaris schon deutlich länger als unter Linux. Unter Solaris könnten sie älter als Linux sein.

Anscheinend Fehlanzeige (Man überzeuge mich gerne eines Besseren!)

Ich empfinde das mangelnde Wissen über Windows bei vielen Linuxverfechtern als erschreckend.
Weitere erschreckende Dinge (weiß nicht, ob das bei Dir der Fall ist):

• Fehlende Kenntnisse über Schwachstellen von Linux
• Fehlende Kenntnisse über aktuelle Projekte von MS (hinter MS steckt Geld, wenn die wollen, können die auch ziemlich radikale Ansätze durchdrücken) (Zentralistische Strukturen haben auch Vorteile)

Links:

• http://chaosradio.ccc.de/cre022.html
• http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf

 

[DerDude]

Ein Programm hat nie die Eigenschaft genügsam, sondern erst eine Kombination Programm/Rechner.

Da ein Programm nicht beliebig klein werden kann, hat es durchaus seine Berechtigung die Größe absolut zu betrachten.

Ich auch nicht. Allerdings sind die Fähigkeiten von Perl, Python oder Tcl/Tk keine Fähigkeiten der Bash. Die dazu notwendige Funktionalität der Shell ist das "#!"-Kommando (übrigens auch nachträglich dazugekommen).

Wie aus meinem anderen Posting erkennbar kenne ich die Interpreterangabe. Nein, es ist nicht bestandteil der Shell. Das macht auch nichts und eine Schwäche der Shell ist es erstrecht nicht. Die Shell bietet einen Satz funktionen, die man benutzen kann und die auch benutzt werden. Wenn man eine andere Sprache benutzen will, kann man das. Dann hat man doch alles was man braucht.
Es würde für eine Shell schon reichen, wenn sie die Benutzereingaben entgegen nimmt und dafür sorgt, dass die Kommandos ausgeführt werden indem der dazu notwendige Interpreter verwendet oder das jeweilige Programm gestartet wird. Die bash (und ihre Varianten) arbeiten im wesentlichen so. Das ist eine sehr generische Form, die sehr nützlich ist. Dann gibt es eben die Shells, die sich an eine Programmiersprache binden. Auch die haben ihre Berechtigung.

Du sagst #! sei "übrigens auch nachträglich dazugekommen". Bleibt die Frage "na und??". Man hätte die Shell-Sprach mächtiger machen können, aber dann würde man im Grunde das Rad nochmal erfinden, andere Sprachen können das mindestens genausogut.

Bei rmdir stimmt da ja noch.
umount heißt ja auch rmfilesystem
kill heißt ja auch rmprocess
unset heißt ja auch rmset

rmfilesystem ist jetzt ein Scherz, oder?

Über kill und rmprocess könnte man streiten, aber rmset ist schon wieder ziemlich an den Haaren herbeigezogen.

Ob ich nun eine vollständige oder unvollständige Programmiersprache implementiere, ist nur eine Sache von wenigen Kilobyte.

...und wie beschrieben eine Frage der Notwendigkeit.

Wie zählt eine Bash von 1 bis 1.000.000 und druckt dabei alle Primzahlenpärchen aus?

Oder was praxisnäheres:
Man habe eine Liste von Verzeichnissen, in denen Unterverzeichnisse sind. Die Inhalte der Unterverzeichnisse sollen angezeigt werden, dabei sollen die Unterverzeichnisse alphabetisch sortiert werden und nach jedem Anfangsbuchstabenwechsel soll eine horizontale Zeile mit '-' gedruckt werden. Die Verzeichnisnamen können Leerzeichen enthalten. Das ganze soll sowohl unter deutscher wie unter englischer Locale laufen.

Natürlich gar nicht. Dafür nehme ich dann eine geeignete Sprache... Ist ja auch Teil des Konzepts.

Der Meinung bin ich auch. Trotzdem hat es keiner gemacht.

doch... nur eben nicht für .net.

Linux ist mir zu viel Sozialismus. Aus der moralischen Überlegenheit heraus unterläßt man viele notwendige Dinge

Sorry, aber mit Sozialismus hat Linux gar nichts zu tun!! Das ist schlicht Falsch!! Es ist -- wenn man es schon mit einem politischen system vergleichen muss -- vielmehr demokratisch organisiert und es setzen sich Tools im großen Stil durch, für die Bedarf besteht und die als gut anerkannt werden, oder sie verschwinden durch nicht-Verwendung oder bleiben eine Randerscheinung, die immernoch vielen gute Dienste leistet.
Es wird auch nichts aus einer moralischen Überlegenheit unterlassen. Du vermengst da irgendwelche Dinge, die nichts miteinander zu tun haben.

Dies ist ein harmloses Beispiel. Aber davon gibt es zu viele. Und es gibt weniger harmlose Beispiele (Systemtest!)

Die Shells sind kein Beispiel für Unterlassung. Ich weiß nicht genau worauf du mit Systemtest anspielen willst, das kann man in viele Richtungen interpretieren.

Ich habe nichts gegen Linux. Aber gegen zu viel Ideologie ...

Auch Ideologie ist begrifflich mal wieder danebengegriffen. Es gibt gewisse Philosophien, die ihre Berechtigung haben. Im übrigen steht Linux permanent unter einen erhöhten Rechtfertigungsdruck, da der Quellcode offenliegt.

 

[Frank Klemm]

Da ein Programm nicht beliebig klein werden kann, hat es durchaus seine Berechtigung die Größe absolut zu betrachten.

Das ist ein Nicht-Argument. Mit diesem Argument kannst Du auch die Bash genauso verurteilen.

Ein Kommandointerpreter aus 8-bit-Zeiten (500 bis 800 Byte lang) und konnte weniger als ein Kommandointerpreter aus 16-bit-Zeiten (12 bis 60 KByte). Der konnte wieder weniger als die Bash (die auch wieder größer war, Größe hängt davon ab, ob statisch oder dynamisch gelinkt und ob man die libc dazuzählt). Und das gleiche gilt für die msh (die auch wieder größer war, Größe hängt davon ab, ob Du den .NET 2.0 Framework mitzählst oder nicht).

Ob das groß oder klein ist, hängt davon ab, ob diese Größe das System belastet oder nicht. Auf Embedded-Systemen, auf denen die msh zu groß ist, ist auch schnell die bash (trotz kleinerer Größe) zu groß (man setzt dann dort was wirklich schlankes ein, z.B. die Tiny SHell). Gemessen an der Funktionität ist die bash in meinen Augen ziemlich verfettet.

Wie aus meinem anderen Posting erkennbar kenne ich die Interpreterangabe. Nein, es ist nicht bestandteil der Shell. Das macht auch nichts und eine Schwäche der Shell ist es erstrecht nicht. Die Shell bietet einen Satz funktionen, die man benutzen kann und die auch benutzt werden. Wenn man eine andere Sprache benutzen will, kann man das. Dann hat man doch alles was man braucht.
Es würde für eine Shell schon reichen, wenn sie die Benutzereingaben entgegen nimmt und dafür sorgt, dass die Kommandos ausgeführt werden indem der dazu notwendige Interpreter verwendet oder das jeweilige Programm gestartet wird.

Das ist ein sinnvoller Ansatz. Man verlegt die Verwaltungsaufgaben in die Shell und diese dient nur zum Verknüpfen von Funktionen von externen Funktionen. Diese bleibt dabei smart und klein.

Die bash (und ihre Varianten) arbeiten im wesentlichen so.

Die bash ist von dieser Lösung weit entfernt. Soll ich das Handbuch der Bash hier mal reinkopieren?

Du sagst #! sei "übrigens auch nachträglich dazugekommen". Bleibt die Frage "na und??".

Leider fängt man sich damit wieder Restriktionen oder Einbruchsmöglichkeiten in das System ein. Das ganze ist vor 13,5 Jahren ausdiskutiert worden und es hat sich nichts getan (steht im Inkomplöhntopp).

Man hätte die Shell-Sprache mächtiger machen können, aber dann würde man im Grunde das Rad nochmal erfinden, andere Sprachen können das mindestens genausogut.

Diese Einstellung führt zu einem weiteren Problem, daß im OSS-Bereich wesentlich häufiger als im Nicht-OSS-Bereich auftritt. Es gibt zu viele Lösungen für vorhandene Probleme und viele Probleme erfordern an einer Stelle einen Wechsel der Sprache.
Unter Linux fange ich einfache Probleme mit der bash an, diese wachsen und wachsen und irgendwann muß man die Sprach wechseln und steht vor der Frage perl, python, C+compilieren, Tcl/Tk.

Das geht deutlich eleganter.

rmfilesystem ist jetzt ein Scherz, oder?

Nein.

... und wie beschrieben eine Frage der Notwendigkeit.

Das ist eine Möglichkeit der Ansicht. Allerdings muß man auch konsequent sein.

Entweder ich sage, eine leistungsfähige Shell ist nicht notwendig, weil ich ja was draufsetzen kann, was das kann.

Oder ich sage, ich brauche eine leistungsfähige Shell, weil ich damit allein richtig arbeiten will.

Linux-Ideologen stellen sich genau dazwischen und verwenden wechselnde Standpunkte, je nachdem, was für das Antlitz von Linux besser ist.

Wenn ich darauf verweise, daß man nur elementare Dinge mit der Shell machen will, dann reicht unter Windows die cmd.exe und unter Linux die /bin/bash.
Will ich richtig damit arbeiten, verwende ich tcl/tk, perl oder was auch immer. Bei cmd.exe und /bin/bash sind die Grenzen etwas unterschiedlich, wo man den Schnitt/Wechsel durchführen sollte.

Stelle ich die /bin/bash als das Werkzeug hin und verteufle die cmd.exe, dann muß ich auch akzeptieren, daß die /bin/bash gegenüber der msh.exe ziemlich alt aussieht.

 

[DerDude]

Der konnte wieder weniger als die Bash (die auch wieder größer war, Größe hängt davon ab, ob statisch oder dynamisch gelinkt und ob man die libc dazuzählt). Und das gleiche gilt für die msh (die auch wieder größer war, Größe hängt davon ab, ob Du den .NET 2.0 Framework mitzählst oder nicht).

Gehen wir mal von dem üblichen Fall des dynamischen Verlinkens aus, ist die libc eine ganz normale Systembib. .Net kommt noch zu vergleichbaren Bibs unter Windows dazu, ählnlich wie Java.

Auf Embedded-Systemen, auf denen die msh zu groß ist, ist auch schnell die bash (trotz kleinerer Größe) zu groß (man setzt dann dort was wirklich schlankes ein, z.B. die Tiny SHell). Gemessen an der Funktionität ist die bash in meinen Augen ziemlich verfettet.

Ja, man setzt Varianten des shells ein, die sich im wesentlichen aber sehr ähnlich sind. Die ash ist auch so ein Beispiel und in weiten Teilen zur Skriptsprache der bash kompatibel.

Das ist ein sinnvoller Ansatz. Man verlegt die Verwaltungsaufgaben in die Shell und diese dient nur zum Verknüpfen von Funktionen von externen Funktionen. Diese bleibt dabei smart und klein.
Die bash ist von dieser Lösung weit entfernt. Soll ich das Handbuch der Bash hier mal reinkopieren?

Der entscheidende Punkt ist die Auswahl des Interpreters in Abhängigkeit vom Skript. Der "#!" wird nicht umsonst auch für Shellscripte angegeben. Der Shell-interpreter käme in einer Umgebung, in der es nur Perl, Python und vielleich Ruby-skripte gäbe, gar nicht zum Einsatz. Er wäre eben nur da. Was so gesehen fehlt ist vielleicht eine klare Trennung der Shell-Skriptsprache von der Shell. Ich habe mir den Code nicht angesehen, kann also nicht sagen wie weit das wirklich getrennt ist. Historisch bedingt ist sowas ja meistens nicht unbedingt einfach.

Leider fängt man sich damit wieder Restriktionen oder Einbruchsmöglichkeiten in das System ein. Das ganze ist vor 13,5 Jahren ausdiskutiert worden und es hat sich nichts getan (steht im Inkomplöhntopp).

Kann da jetzt kein Thread oder Artikel finden, den du meinst. Praxisrelevante Sicherheitsprobleme, solche für die es Exploits gibt, werden normalerweise in der Linuxwelt sehr schnell behoben. Das etwas diskutiert wird heißt nicht, dass das betreffende Problem existiert.

Diese Einstellung führt zu einem weiteren Problem, daß im OSS-Bereich wesentlich häufiger als im Nicht-OSS-Bereich auftritt. Es gibt zu viele Lösungen für vorhandene Probleme und viele Probleme erfordern an einer Stelle einen Wechsel der Sprache.
Unter Linux fange ich einfache Probleme mit der bash an, diese wachsen und wachsen und irgendwann muß man die Sprach wechseln und steht vor der Frage perl, python, C+compilieren, Tcl/Tk.

Das hat nicht mit Open oder ClosedSource zu tun. Im ClosedSource-Bereich redet man nicht drüber und zeigt eben auch den Code nicht und damit auch das ganze Gefrickel nicht, was entsteht, wenn man dann aus Kostengründen den Wechsel der Programmiersprache nicht vollzieht. Dass dir irgendwann die Sprache nicht mehr reicht oder sie für bestimmt Dinge zu umständlich wird, kann dir immer passieren.
Was heißt außerdem es gibt zu viele Lösungen? Meistens hat jede auch ihre Berechtigung. ClosedSource hat auch viele Lösungen, denk nur an die unmengen Grafiksoftware, insbesondere Bilddatenbanken.

rmfilesystem ist jetzt ein Scherz, oder?

Nein.

Du kannst aber schon einen semantishcen Unterschied zwischen dem Entefernen oder dem Aushängen eines Dateisystems erkennen oder? rmfilesystem heißt für mich das Dateisystem zu löschen.

Das ist eine Möglichkeit der Ansicht. Allerdings muß man auch konsequent sein.

Die meisten Inkonsequenzen unter Windows bleiben dir verborgen dank ClosedSource.

Entweder ich sage, eine leistungsfähige Shell ist nicht notwendig, weil ich ja was draufsetzen kann, was das kann.
Oder ich sage, ich brauche eine leistungsfähige Shell, weil ich damit allein richtig arbeiten will.

Diese Inkonsequenz besteht so ja nicht wirklich. Der Shell-Interpreter steht gleichberechtigt neben den anderen.

Linux-Ideologen stellen sich genau dazwischen und verwenden wechselnde Standpunkte, je nachdem, was für das Antlitz von Linux besser ist.

herje...

Stelle ich die /bin/bash als das Werkzeug hin und verteufle die cmd.exe, dann muß ich auch akzeptieren, daß die /bin/bash gegenüber der msh.exe ziemlich alt aussieht.

Ich habe ja bereits dargestellt, dass die bash mich nicht auf ihre eigene Skriptsprache festlegt. Die Powdershell tut das zunächst, oder entscheidet sie auch anhand des Skriptes welcher Interpreter verwendet wird.
Und wieder sind wir bei dem was ich sagte: Die Powdershell ist nichts revolutionäres vom Konzept her. Sie verwendet eben eine umfangreiche Sprache, wenn man die benutzen will, wird einem diese Shell freuen, will man Perl oder Python programmieren, hilft sie einem weniger.

 

[elastico]

sorry - aber zu windows + Laufwerksbuchstaben:
Das ist echt eine Seuche!

Klar kann ich einem Laufwerk einen festen Buchstaben zuordnen. Aber jetzt mal was aus dem Leben:

a) Ich habe eine Wechselplatte. Darauf Programme die ich an mehreren Rechnern nutzen möchte. Blöd, dass diese in den Konfig-Files wissen müssen, wo sie laufen und ihre Daten speichern können. Also Laufwerksbuchstabe zuweisen - z.B. H: und alles Konfigs auf H: anpassen.
Nun gehst Du damit zum nächsten Rechner... Hoppala.. da ist H: aber ein Netzwerklaufwerk was in der Firma benötigt wird... ja so ein Pech aber auch

b) Ich habe meine lokalen Partitionen mit festen Laufwerksbuchstaben versehen. C: = system, D: = cdrom, E: = brenner, F: = frei für USB-Geräte, G: = Software, H: = Quellcodes/Entwicklung
Soweit so gut. solange ein Cardreader (damals) nur einen slot hatte oder man nur eine externe Platte anschloss... inzwischen werden die Laufwerke munter verteilt... eines wird F: die anderen I: J: K: .... man sieht natürlich auch kaum ob und wo eine Karte eingelegt ist - also immer munter probieren.
Nun kam es, dass es die Registry oder sonstwas zerlegt hatte und ich eine Reperaturinstallation laufen lassen musste. Guess What? Hinterher Gab es:
C: = System, D, E, F für die Partitionen, H:, I: für die CD-Laufwerke...
Alles durcheinander und zunächst lief natürlich nix mehr - bis die Zuordnung wieder hergestellt war - dazu musste ich aber zwischendurch booten, weil man erstmal Laufwerksbuchstaben FREI bekommen musste um sie neu zuordnen zu können etc.... Dreieckstausch klappt nicht immer.


Bei anderen Systemen sieht das so aus:
- Wechselplatte hat einen Namen
- Speicherkarten haben einen Namen
- Anstecken - benutzen und Konfigs einrichten. Passt immer! an jedem Rechner!
- System neu aufsetzen oder Reparieren? Who cares. Partitionen und Karten behalten ja ihren namen - da wird nichts umsortiert.

Ich finde die Windows-Lösung (eigentlich alte DOS-Lösung) nicht so prickelnd und inzwischen deutlich überholt. Wird Zeit, dass MS da mal einen dicken Schlussstrich zieht! Auch wenn das bedeutet, dass unsere Firma zig Programm anpassen muss.

 

[Backbone]

Hallo alle zusammen,

ich hoffe ich zerreiße den Thread hier nicht, aber ich will kurz mal einen Zwischenstand geben. Ich hab heute auf meinem Laptop (Acer Aspire 3003Wlmi) eine Live-Version von Fedora Core 6 ausprobiert. Die Grafikkarte wird perfekt erkannt und die Auflösung richtig eingestellt. Sogar das WLan-Modul wird richtig erkannt, leider lässt sich das nicht aktivieren. Die LED am Laptopgehäuse bleibt tot.

Ich werd wohl weiter schaun müssen.

Backbone

 

[PoRcUpInE]

Sogar das WLan-Modul wird richtig erkannt, leider lässt sich das nicht aktivieren.

Hi,

was geht denn nicht? wenns ja richtig erkannt wird, sollte es funktionieren.
Ist bei Fedora mittlerweile der NetworkManager dabei?

Die LED am Laptopgehäuse bleibt tot.

Die LED funktioniert unter Linux nicht/nur mit viel viel Handarbeit, sollte aber nicht weiter Tragisch sein.

Gruß
Mike

 

[photourist]

ACLs gibt es unter Windows und Solaris schon deutlich länger als unter Linux. Unter Solaris könnten sie älter als Linux sein.

Dann gibt es unter Windows aber kein vernünftiges Benutzerinterface (auf Shell-Ebene!) für die Dateizugriffsrechte à la

drwxrwxrwx benutzer:gruppe

sowie "chmod", "chown", "chgrp" etc.

Die Zugriffsrechte-Vergabe-Möglichkeiten im Windows-Explorer (und das ist das Werkzeug, mit dem der 0815-User arbeitet), sind dagegen ein Witz!

Gibt es unter Windows etwas Entsprechendes wie die Dateibesitzer-spezifische "umask" unter Unix? Neu erstellte Dateien werden automatisch mit den Rechten, wie in der umask nach dem Schema "ugo" (User-Group-Others) angegeben, erstellt.

Und auf dem Linux-"Desktop", z.B. in der GNOME-Oberfläche, sieht das viel besser als unter Windows aus (das ist doch wohl nicht von der Hand zu weisen, oder?): (siehe die Grafik!)

Und wem das nicht reicht, der kann noch zusätzlich SELinux konfigurieren.

*** edit *** Da hierzu sich niemand äußert, scheine ich doch mal in's Schwarze getroffen zu haben, wenn ich auch sonst nicht viel von Windows verstehe ...

 

[Trendliner]

... aber von XP nach Vista gibt es hauptsächlich folgende "Verbesserungen": Gimmicks und Gängelung!

Vielleicht hättest du rechtzeitig die Chance ergreifen und eine Beta von Vista selbst antesten sollen - die gab es völlig kostenlos und es wäre bestimmt nicht umsonst gewesen. Vielleicht würdest du dann die eine oder andere mit doch eher ungesunden Halbwissen geprägte Zeile etwas anders beurteilen

Ansonsten dachte ich eigentlich, hier in einem Foto-Forum zu sein. Warum müssen nun auch hier diese nichtsbringenden Grabenkämpfe ausgetragen werden? Reicht das Heise-Forum dafür nicht aus?