Posted: Thu May 08, 2008 11:51 pm
Aber wie gesagt du verkennst da das Zentrale: Das bei den Linuxdistributionen ist einfach ein Problem von open source und gewünschter Dynamik. Da hat kein Distributor wirklich Schuld dran. Es kommen halt regemäßig Releases von diversen Programmen(einschließlich dem Kernel). Dadurch lassen sich über diese enorme Menge an Material Kompatibilitäten nicht einhalten. Und Grundstandards werden schon definiert über LSB. Aber viel mehr ist einfach aus rein OS-philosophischen Gründen nicht möglich. Klar gibt es hier und da auch taktische Verweigerung. Aber da ist wohl auch Microsoft ganz vorn mit dabei.
Das ist bei MS und Windows ganz anders. Das ist ein System von einem einzigen Hersteller. Die kochen nur ihr eigenes. Da kann man natürlich viel eher für Kompatibilität sorgen, weil alles in einer Hand ist. Und nebenbei kann man so viele Hacks einbauen, wie man will. Das wird auch gemacht, damit einige Programme überhaupt so lange auf einem Windows laufen können.
Das will man aus gutem Grund bei Open Source-Software vermeiden, u.a. auch deshalb, weil sonst der Code so unübersichtlich wird das niemand extern mehr in die Entwicklung einsteigen könnte.
Und selbst, wenn sie alles in der Hand haben und Hacks einbauen wie sie wollen kommt es öfter zu Problemen (siehe allein XP vs. Vista).
Und dann zum Thema Paketmanager / Installer, weil du es ansprichst.
Erstens ist da eine Trennung schwierig und zweitens nicht unbedingt das einzige und zentrale Thema bzgl. der Kompatibilitäten. Die Dinge die ich vorher angesprochen habe, machen dann auch Probleme bei diesen Paketmanagern, aber die Paketmanager nicht der Kern des Problems.
Genau genommen ist ist die Nutzung von msi auch die Nutzung eines Paketmanagers. Und Paketmanager in Verbund mit Paketen unter Linux auch Installer. Paketmanager sind nur eigentlich nur eine organisatorische Einheit, die die Platzierung von Informationen und Dateien handelt und registiert. Das macht auch msi.
Es gibt ja unter Linux teils auch Installer (bsw. Loki Installer) wie man sie so naiv vielleicht als was eigenes definiert. Das hilft halt auch nicht immer. Die laufen dann auch hier und da nicht. Und andersherum gibt es auch unter Windows Installer, die msi nicht nutzen und trotzdem gut funktionieren.
Und wenn du meinst Redhat, Suse und Co. würden jeweils ihr eigenes Sübchen kochen. Klar, machen sie das, wie oben schon gesagt aus OS-philosopischen Gründen, und nicht um sich um sich abzuschotten. Und vorallem ist damit nicht so einfach erklärbar, warum manche Pakete innerhalb der Distributionsreleasefolge dann doch hier un da mal versagen. Das wird wohl kaum Absicht sein, da würden sie sich ja ins eigene Fleisch schneiden. Das ist einfach darin begründet, dass sie halt auch auf den Open Source-Programmen basieren und entsprechende Probleme haben wie oben beschrieben.
Allein der Fakt, dass Linux kein Betriebsystem ist, sondern ein Kernel, der in Zusammenspiel mit anderen Systemprogrammen zum Betriebsystem wird, zeigt die Fülle an Problemen die auf einen zukommen. Bei Windows ist das alles "eins" und beinhaltet dann noch Kompatibilitätslayer.
ReactOS ist ja nun auch keine Distribution vom Windowskernel. Es ist ein Clone vom Betriebsystem Windows. Das wäre so als würde man einen Clone von SLED 10 machen(mal Anwendungsprogramme ausgeklammert) und halt nicht von "Linux". Dann wäre klar, dass man auch alle Pakete konstant haben kann und selbst Installer hätten auf beiden System keine Probleme (bzw. die gleichen ^^).
Von daher ist das alles auch nicht so zu vergleichen. MS steht in einer gänzlich anderen Ausgangslage als die Distributoren. Und der Übergang von Installer zu Paketmanager ist fließend und krankt vorallem an Symptomen eines anderen Problems.
Ich will nicht abstreiten oder sogar hervorheben, dass es für den privaten Desktopanwender unter Linux extrem nervt, das man kaum Einheitliches findet, was man explizit auf seinem Rechner so installieren kann. Das ist ein Problem. Für den Profi vielleicht weniger, da der in der Regel Support nutzt und unbedingt immer die neuste Version eines Programms oder Bleeding Edge nutzt. Aber für den Desktopanwender ist das extrem nervig.
Das ist bei MS und Windows ganz anders. Das ist ein System von einem einzigen Hersteller. Die kochen nur ihr eigenes. Da kann man natürlich viel eher für Kompatibilität sorgen, weil alles in einer Hand ist. Und nebenbei kann man so viele Hacks einbauen, wie man will. Das wird auch gemacht, damit einige Programme überhaupt so lange auf einem Windows laufen können.
Das will man aus gutem Grund bei Open Source-Software vermeiden, u.a. auch deshalb, weil sonst der Code so unübersichtlich wird das niemand extern mehr in die Entwicklung einsteigen könnte.
Und selbst, wenn sie alles in der Hand haben und Hacks einbauen wie sie wollen kommt es öfter zu Problemen (siehe allein XP vs. Vista).
Und dann zum Thema Paketmanager / Installer, weil du es ansprichst.
Erstens ist da eine Trennung schwierig und zweitens nicht unbedingt das einzige und zentrale Thema bzgl. der Kompatibilitäten. Die Dinge die ich vorher angesprochen habe, machen dann auch Probleme bei diesen Paketmanagern, aber die Paketmanager nicht der Kern des Problems.
Genau genommen ist ist die Nutzung von msi auch die Nutzung eines Paketmanagers. Und Paketmanager in Verbund mit Paketen unter Linux auch Installer. Paketmanager sind nur eigentlich nur eine organisatorische Einheit, die die Platzierung von Informationen und Dateien handelt und registiert. Das macht auch msi.
Es gibt ja unter Linux teils auch Installer (bsw. Loki Installer) wie man sie so naiv vielleicht als was eigenes definiert. Das hilft halt auch nicht immer. Die laufen dann auch hier und da nicht. Und andersherum gibt es auch unter Windows Installer, die msi nicht nutzen und trotzdem gut funktionieren.
Und wenn du meinst Redhat, Suse und Co. würden jeweils ihr eigenes Sübchen kochen. Klar, machen sie das, wie oben schon gesagt aus OS-philosopischen Gründen, und nicht um sich um sich abzuschotten. Und vorallem ist damit nicht so einfach erklärbar, warum manche Pakete innerhalb der Distributionsreleasefolge dann doch hier un da mal versagen. Das wird wohl kaum Absicht sein, da würden sie sich ja ins eigene Fleisch schneiden. Das ist einfach darin begründet, dass sie halt auch auf den Open Source-Programmen basieren und entsprechende Probleme haben wie oben beschrieben.
Allein der Fakt, dass Linux kein Betriebsystem ist, sondern ein Kernel, der in Zusammenspiel mit anderen Systemprogrammen zum Betriebsystem wird, zeigt die Fülle an Problemen die auf einen zukommen. Bei Windows ist das alles "eins" und beinhaltet dann noch Kompatibilitätslayer.
ReactOS ist ja nun auch keine Distribution vom Windowskernel. Es ist ein Clone vom Betriebsystem Windows. Das wäre so als würde man einen Clone von SLED 10 machen(mal Anwendungsprogramme ausgeklammert) und halt nicht von "Linux". Dann wäre klar, dass man auch alle Pakete konstant haben kann und selbst Installer hätten auf beiden System keine Probleme (bzw. die gleichen ^^).
Von daher ist das alles auch nicht so zu vergleichen. MS steht in einer gänzlich anderen Ausgangslage als die Distributoren. Und der Übergang von Installer zu Paketmanager ist fließend und krankt vorallem an Symptomen eines anderen Problems.
Ich will nicht abstreiten oder sogar hervorheben, dass es für den privaten Desktopanwender unter Linux extrem nervt, das man kaum Einheitliches findet, was man explizit auf seinem Rechner so installieren kann. Das ist ein Problem. Für den Profi vielleicht weniger, da der in der Regel Support nutzt und unbedingt immer die neuste Version eines Programms oder Bleeding Edge nutzt. Aber für den Desktopanwender ist das extrem nervig.