Hallo Andres,
Mozilla ist mit Quicklaunch fast schneller als der IE.
Scherzkeks. Nicht jeder will, dass Mozilla ständig 15-20 MB RAM belegt.
Wieviel belegen die Bibliotheken, die der IE benötigt, die ständig im System geladen bleiben? Nicht das das jetzt ein Argument für Quicklaunch sein soll, es soll nur den Vergleich mit dem IE darstellen.
Ich weiß es nicht, es ist aber für das Argument des Geschwindigkeitsvorteils des MSIE irrelevant. Pragmatisch gesehen geht es nicht darum, welcher Browser insgesamt faktisch mehr RAM verbraucht beziehungsweise unter Berücksichtigung aller Komponenten und Bibliotheken schneller lädt. Denn wenn man als gegeben annimmt, dass der Internet Explorer in das System verwoben ist und sowieso per se teilweise vorgeladen wird bzw. im Speicher bleibt - also gewissermaßen unweigerlich über einen »Quicklaunch« verfügt -, ist es nur folgerichtig, dies als Grund *für* den MSIE anzusehen, weil der Wechsel auf einen anderen Browser so gesehen nie eine Abkehr sein kann, sondern nur ein weiterer Browser zusätzlich in den Speicher geladen wird.
Nun kann man sich natürlich darüber echauffieren, dass der MSIE nicht ins System eingebunden sein sollte, aber in puncto Schnelligkeit ist die Kausalkette für einen pragmatischen Anwender, der lediglich einen schnellen und bezüglich Speicherverbrauch genügsamen Browser verwenden will, resümiert folgendermaßen:
- MSIE ist tief ins System eingebunden, wodurch bereits ein Geschwindigkeitsvorteil entsteht.
- Einige seiner Komponenten werden sowieso geladen, egal ob der MSIE benutzt wird oder nicht, was Ladezeit beim Windows-Start bedeutet und ständige Speicherbelegung zur Folge hat, welche nicht entscheinend minimiert werden kann.
- Die Benutzung eines Zweitbrowsers führt dazu, dass ein »halber« Browser ständig im Speicher verbleibt und ein weiterer kompletter geladen werden muss.
- Der naheliegende Schluss wäre, den bereits eingebauten Browser zu verwenden, um den Speicher optimal auszunutzen und die Ladezeiten so klein wie möglich zu halten.
Sicherlich mag dieses Argument nicht die übrigen Nachteile des MSIE aufwiegen - es ist aber meines Erachtens für sich betrachtet in sich logisch und zutreffend.
Ausserdem, wie oft startet ihr eure Browser neu?
Da ich ständig zwischen drei bis sechs Browsern bzw. -versionen hin- und herschalte beim Entwickeln und nur über arg begrenzte Ressourcen verfüge, kann ich nur zwei oder drei Browser gleichzeitig geöffnet haben. Somit starte und schließe ich ständig Browser, auch wenn ich zum »Surfen« in der Regel nur einen Browser in einer Version verwende.
Diese 5 Sekunden 2-3 mal am Tag sind nun wirklich nicht schlimm.
Siehe oben. Und bspw. ein Mozilla-Start braucht bei mir 35-40 Sekunden, bei entsprechender Speicherbelegung auch 50 Sekunden.
Diese Art von Nutzung hat jedoch nichts mit der selbständigen Einrichtung eines Betriebssystems samt Software, Hardware-Treiber, Netzzugang et cetera zu tun. Und in diesem Punkt liegen zwischen einem Linux-System und Windows Welten in Bezug auf Bedienbarkeit bzw. Komplexität, wenn es sich nicht gerade um eine vollgrafische SuSE-Installation handelt, wo man im Grunde nur immer auf »Weiter« klicken muss. Zum Vergleich kannst du deine Mutter bspw. vor eine Bash-Konsole setzen und beobachten, wie sie sich zurechtfindet.
Was spricht gegen eine solche grafische Installationsroutine?
Nichts, ich wollte sie auch nicht pauschal loben oder kritisieren. Dennoch wird man - wie übrigens bei Windows ebenfalls, nur in kleinerem Maße - nicht umhinkommen, Feineinstellungen per Hand vorzunehmen, in Konfigurationsdateien et cetera.
Wobei ich jetzt nicht umbedingt von Yast spreche, sondern eher von der von Mandrake, die ich wesentlich angenehmer finde. Man kann meiner Meinung nach problemlos ein System aufsetzen, ohne ein einziges Mal eine Konsole benutzt zu haben.
Zwar kenne ich das Mandrake-Installationsprogramm nicht, aber wenn tatsächlich alles Genannte reibungslos bis zur Installation einer grafischen Oberfläche verläuft, ohne dass Treiber bzw. Patches manuell eingespielt werden müssen oder Software über die bekannten Methoden von Hand installiert werden muss, dann hast du wahrscheinlich Recht. Von SuSE kann ich nur sagen, dass spätestens bei der Einrichtung von Hardware und Netzzugang Schluss mit Yast & Co. war, dort musste manuell eingegriffen werden, was natürlich das bekannte Beschäftigen mit den Interna sowie Studium von manpages et cetera bedeutet, worauf sich viele wahrscheinlich nicht einlassen möchten.
Ich verstehe unter einer Installation eines Betriebsystems auch das sichere konfigurieren desselben, was meiner Meinung nach unter win wesentlich schwieriger ist. Siehe ActiveX usw.
Ich denke nicht, dass das Absichern eines Linux-Systems einfacher ist, weil Linux von Haus aus mehr eingebaute Sicherheit bietet und deshalb der Benutzer vergleichsweise sorglos schalten und walten kann. Dann entsteht nur das bereits im Zusammenhang mit Personal Firewalls genannte trügerische Gefühl der Sicherheit. Beispielsweise das Verstehen und aktive Nutzen des Mehrbenutzerkonzepts oder anderen Sicherheitsfeatures benötigt nicht weniger Wissen und Einarbeitungszeit als grundlegende Sicherungsmethoden in Windows. ActiveX ist natürlich tatsächlich ein spezielles Problem, was besondere Aufmerksamkeit benötigt.
Vor kurzem hat MS angekündigt, dass sie mehr Konsolentools anbieten werden. In ihrem Anti-Linux-Marketing-Pdf das vor kurzer Zeit unter anderem hier im Forum kursierte, hatten sie genau das bei Linux beklagt, da grafische Oberflächen doch viel bequemer seien.
Im Grunde ist ein solcher Vergleich nicht möglich: Anwendungen, welche sich speziell über die Konsole effizient bedienen lassen, werden durch eine grafisches Frontend vielleicht einfacher bedienbar sein, nur leidet dann bekanntermaßen die Möglichkeit, Komplexes beim Beherrschen der Anwendung mit wenig Aufwand zu lösen; genauso sind Automatisierbarkeit und Flexibilität nicht gegeben. Anders herum gibt es tatsächlich zahlreiche Fälle, in welchen das Erlernen von Kommandozeilenoptionen oder der Syntax einer kryptischen Konfigurationsdatei im Endeffekt keine Zeitersparnis bzw. Flexibilitätsgewinn darstellt - vielleicht auch, weil die Anwendungen zwar extrem skalierbar angelegt sind, diese Features aber in der Regel nicht genutzt werden.
Insofern lässt sich die Nutzbarkeit eines Werkzeugs nicht pauschal bewerten; genauso wie die Aussage unmöglich ist, dass ein bestimmtes Werkzeug für jede beliebige Aufgabe (besser) angemessen und geeignet ist.
Grüße,
Mathias