Insofern muss ich einigen hier im Forum widersprechen, welche diesen
Umstand zum Kernproblem erheben.
Dann auch wenn das heute von der Anzahl der Installationen her eine
korrekte Beobachtung zu sein scheint, möchte ich die geehrten Poster
daran erinnern dass es Windows früher auch für andere Architekturen
gab.
Ich erinnere mich zumindest noch an eine DEC ALPHA Version von
Windows NT, und ich glaube es gab noch mehr unterstützte
Architekturen.
Richtig ist allerdings, dass keine davon ein "Renner" wurde, und
Microsoft sie schließlich alle der Reihe nach eingestellt hat.
Dennoch beweist dieser historische Umstand, dass die Kettung von
Windows auf eine bestimmte CPU-Architektur nicht das eigentliche
Problem ist.
Meiner Meinung ist das Problem das Windows hat einzig und allein der
starke Fokus auf ClosedSource-Software der dort seit je her
verbreitet ist.
Um das auszuführen möchte ich erläutern, *warum* Linux, BSD & Co auf
so vielen CPU-Architekturen zu finden sind, während man bei Windows
in der Praxis an x86 gekettet ist.
Der Grund dafür ist nicht weil x86 alt und schlecht ist, sondern weil
es für eine Linux-Distribution so einfach ist eine neue
CPU-Architektur zu unterstützten.
Denn im wesentlichen liegen alle Pakete als Quelltexte vor. Es gibt
einige Ausnahmen, aber das sind dann meist auch die Pakete welche die
meisten Probleme machen und nicht auf allen Architekturen verfügbar
sind.
Im Falle von Debian Linux liegen die Pakete nicht nur als
Binärversionen vor, sondern auch als Quelltextpakete.
Gentoo Linux ist eine Distribution wo im Normalfall überhaupt nur
Quelltexte heruntergeladen und automatisch auf der eigenen Maschine
kompiliert werden.
Daher kann man unter Debian im wesentlichen dadurch eine neue
CPU-Architektur unterstützen, indem man alle Quelltextpakete für die
neue Zielplattform übersetzen lässt, und schon hat man die
Binärpakete welche sich die User herunterladen können.
Unter Gentoo braucht man nicht einmal das zu tun, da muss man nur
neue Installationsmedien veröffentlichen welche die Compilier-Tools
für die neue CPU-Architektur enthalten und auf dieser laufen.
Natürlich setzt dies voraus, dass auch der jeweilige Kernel (Linux,
BSD, ...) die neue CPU-Architektur unterstützt sowie ein C-Compiler
Code dafür erzeugen kann.
Letzteres ist aber fast immer gegeben, und auch Microsoft hat
zweifellos die Mannstärke um das NT Kernel bei Bedarf auf jede neue
CPU-Architektur zu portieren.
Da Microsoft alle Quelltexte von Windows hat, könnten sie Windows
wohl auch relativ problemlos auf eben so vielen Plattformen heraus
bringen wie Linux.
Doch hier kommt das große Problem: Was nützt einem ein schönes neu
installiertes Windows, wenn es keinerlei andere Software dafür gibt?
Genau an dieser Stelle rächt sich nämlich der Umstand, dass
Windows-Programme normalerweise nur als ClosedSource-Programme
vertrieben werden.
Während man bei Debian und Gentoo einfach lustig den C-Compiler
anwirft, alle Pakete für eine neue CPU-Architektur übersetzt, und
schon stehen zigtausende Applikationen für die neue CPU-Architektur
bereit - schaut es bei Windows anders aus.
Dort kann man dann nur mit den von Microsoft gelieferten Programmen
zehren, und sich mit Paint, Notepad, Minesweeper und Co begnügen.
Weil sonst gibt es ja nichts.
Natürlich könnten theoretisch alle Software-Produzenten auch unter
Windows ihre Produkte einfach "durch den Compiler drehen" und
Versionen für andere Plattformen heraus bringen.
Aber da beginnt dann wieder das Installations-Chaos, weil es unter
Windows keinen einheitlichen Paketmanager gibt, sondern jeder sein
eigenes Süppchen kocht.
Außerdem werden die Hersteller sich diese Arbeit sicherlich vergolden
lassen, sprich man müsste neue Versionen aller Software kaufen.
Und selbst wenn diese Versionen billiger sein sollten, ist es dennoch
ein finanzieller Mehraufwand den kein Kunde ohne zwingenden Grund
mitmachen wird.
Die Probleme daher also noch einmal zusammen gefasst, Bottom-To-Top:
* Die Kunden müssten die meiste Software neu kaufen wenn sie die
Architektur wechseln
* Daher bleiben sie unter Windows lieber bei x86 wo sie schon alles
haben
* Microsoft kann daher tun was sie wollen, keiner wird an
Windows-Versionen für andere Architekturen interessiert sein solange
die bereits vorhandene x86 Software dort nicht läuft.
* Microsoft ist daher an x86 gekettet
* Doch x86 ist stromhungrig und energieverschwendend, wenn auch
schnell
* Unnötig verbratene Energie kostet bares Geld. Bei Rechenzentren
macht der Stromverbrauch heute schon den Großteil der Betriebskosten
aus.
* Unnötig verbratene Energie aufgrund einer zu komplizierten
CPU-Architektur ist aber auch bei Mobilgeräten ein No-Go, da sich die
Akkulaufzeit dadurch verringert.
* Außerdem brauchen Stromfresser-CPUs meist auch Lüfter. Wer würde
sich ein Handy kaufen in dem ein Lüfter läuft? Davon abgesehen
braucht der Lüfter auch noch zusätzlichen Strom.
Die Lage ist daher dumm für Microsoft.
Sie machen dabei ohnehin bereits das einzige, was sie sinnvoller
Weise tun konnten: Alles auf .NET umstellen und Bytecode statt
Maschinencode ausliefern. Damit könnten sie auch mit
ClosedSource-Software CPU-neutral werden.
Nur leider löst das ihr Problem mit den anderen Anbietern nicht:
Solange diese nicht ebenfalls gewillt sind alle ihr Software auf .NET
zu portieren, stehen sie erst recht wieder vor dem Dilemma dass nicht
alles unter .NET läuft, und man somit auf x86 angewiesen ist.
Blieben noch Emulatoren... aber Software-Emulation von x86 kostet
noch viel mehr Strom als x86 stromfressend nativ auszuführen.
Wenn Microsoft von Anfang an auf .NET bzw CLI gesetzt hätte, hätten
sie dieses Problem nun nicht, und die Windows RT unter ARM wäre ein
vollwertiges, energiesparendes Windows dass eine Konkurrenz zu
Android & iOS sein könnte.
Aber Microsoft hat sich früher ja dazu entschlossen, lieber mit INTEL
zusammen die x86-Architektur zu monopolisieren.
Und dabei waren sie sehr erfolgreich im Etablieren einer Monokultur.
Doch nun fällt ihnen diese Monokultur beiden auf den Kopf, da sie
sich selbst an diese gekettet haben und mit ihr unterzugehen drohen.
Wobei die Lage für INTEL wesentlich rosiger ist als für M$: Intel
bräuchte nur ihren Stolz zu überwinden, eine ARM-Lizenz zu lösen und
könnte schon fröhlich weiter verkaufen.
Es ist ja nicht so, dass die ARM-Lizenzen teuer wären.
Vermutlich hat INTEL früher für die Weiterentwicklung von x86
wesentlich mehr ausgeben müssen als hätten sie ARM die Arbeit
überlassen und nur eine Lizenz genommen.
Aber das wäre von INTEL natürlich sehr undankbar Microsoft gegenüber.
Weil die könnten dann ja eigentlich nur noch bitterlich weinen.
Umstand zum Kernproblem erheben.
Dann auch wenn das heute von der Anzahl der Installationen her eine
korrekte Beobachtung zu sein scheint, möchte ich die geehrten Poster
daran erinnern dass es Windows früher auch für andere Architekturen
gab.
Ich erinnere mich zumindest noch an eine DEC ALPHA Version von
Windows NT, und ich glaube es gab noch mehr unterstützte
Architekturen.
Richtig ist allerdings, dass keine davon ein "Renner" wurde, und
Microsoft sie schließlich alle der Reihe nach eingestellt hat.
Dennoch beweist dieser historische Umstand, dass die Kettung von
Windows auf eine bestimmte CPU-Architektur nicht das eigentliche
Problem ist.
Meiner Meinung ist das Problem das Windows hat einzig und allein der
starke Fokus auf ClosedSource-Software der dort seit je her
verbreitet ist.
Um das auszuführen möchte ich erläutern, *warum* Linux, BSD & Co auf
so vielen CPU-Architekturen zu finden sind, während man bei Windows
in der Praxis an x86 gekettet ist.
Der Grund dafür ist nicht weil x86 alt und schlecht ist, sondern weil
es für eine Linux-Distribution so einfach ist eine neue
CPU-Architektur zu unterstützten.
Denn im wesentlichen liegen alle Pakete als Quelltexte vor. Es gibt
einige Ausnahmen, aber das sind dann meist auch die Pakete welche die
meisten Probleme machen und nicht auf allen Architekturen verfügbar
sind.
Im Falle von Debian Linux liegen die Pakete nicht nur als
Binärversionen vor, sondern auch als Quelltextpakete.
Gentoo Linux ist eine Distribution wo im Normalfall überhaupt nur
Quelltexte heruntergeladen und automatisch auf der eigenen Maschine
kompiliert werden.
Daher kann man unter Debian im wesentlichen dadurch eine neue
CPU-Architektur unterstützen, indem man alle Quelltextpakete für die
neue Zielplattform übersetzen lässt, und schon hat man die
Binärpakete welche sich die User herunterladen können.
Unter Gentoo braucht man nicht einmal das zu tun, da muss man nur
neue Installationsmedien veröffentlichen welche die Compilier-Tools
für die neue CPU-Architektur enthalten und auf dieser laufen.
Natürlich setzt dies voraus, dass auch der jeweilige Kernel (Linux,
BSD, ...) die neue CPU-Architektur unterstützt sowie ein C-Compiler
Code dafür erzeugen kann.
Letzteres ist aber fast immer gegeben, und auch Microsoft hat
zweifellos die Mannstärke um das NT Kernel bei Bedarf auf jede neue
CPU-Architektur zu portieren.
Da Microsoft alle Quelltexte von Windows hat, könnten sie Windows
wohl auch relativ problemlos auf eben so vielen Plattformen heraus
bringen wie Linux.
Doch hier kommt das große Problem: Was nützt einem ein schönes neu
installiertes Windows, wenn es keinerlei andere Software dafür gibt?
Genau an dieser Stelle rächt sich nämlich der Umstand, dass
Windows-Programme normalerweise nur als ClosedSource-Programme
vertrieben werden.
Während man bei Debian und Gentoo einfach lustig den C-Compiler
anwirft, alle Pakete für eine neue CPU-Architektur übersetzt, und
schon stehen zigtausende Applikationen für die neue CPU-Architektur
bereit - schaut es bei Windows anders aus.
Dort kann man dann nur mit den von Microsoft gelieferten Programmen
zehren, und sich mit Paint, Notepad, Minesweeper und Co begnügen.
Weil sonst gibt es ja nichts.
Natürlich könnten theoretisch alle Software-Produzenten auch unter
Windows ihre Produkte einfach "durch den Compiler drehen" und
Versionen für andere Plattformen heraus bringen.
Aber da beginnt dann wieder das Installations-Chaos, weil es unter
Windows keinen einheitlichen Paketmanager gibt, sondern jeder sein
eigenes Süppchen kocht.
Außerdem werden die Hersteller sich diese Arbeit sicherlich vergolden
lassen, sprich man müsste neue Versionen aller Software kaufen.
Und selbst wenn diese Versionen billiger sein sollten, ist es dennoch
ein finanzieller Mehraufwand den kein Kunde ohne zwingenden Grund
mitmachen wird.
Die Probleme daher also noch einmal zusammen gefasst, Bottom-To-Top:
* Die Kunden müssten die meiste Software neu kaufen wenn sie die
Architektur wechseln
* Daher bleiben sie unter Windows lieber bei x86 wo sie schon alles
haben
* Microsoft kann daher tun was sie wollen, keiner wird an
Windows-Versionen für andere Architekturen interessiert sein solange
die bereits vorhandene x86 Software dort nicht läuft.
* Microsoft ist daher an x86 gekettet
* Doch x86 ist stromhungrig und energieverschwendend, wenn auch
schnell
* Unnötig verbratene Energie kostet bares Geld. Bei Rechenzentren
macht der Stromverbrauch heute schon den Großteil der Betriebskosten
aus.
* Unnötig verbratene Energie aufgrund einer zu komplizierten
CPU-Architektur ist aber auch bei Mobilgeräten ein No-Go, da sich die
Akkulaufzeit dadurch verringert.
* Außerdem brauchen Stromfresser-CPUs meist auch Lüfter. Wer würde
sich ein Handy kaufen in dem ein Lüfter läuft? Davon abgesehen
braucht der Lüfter auch noch zusätzlichen Strom.
Die Lage ist daher dumm für Microsoft.
Sie machen dabei ohnehin bereits das einzige, was sie sinnvoller
Weise tun konnten: Alles auf .NET umstellen und Bytecode statt
Maschinencode ausliefern. Damit könnten sie auch mit
ClosedSource-Software CPU-neutral werden.
Nur leider löst das ihr Problem mit den anderen Anbietern nicht:
Solange diese nicht ebenfalls gewillt sind alle ihr Software auf .NET
zu portieren, stehen sie erst recht wieder vor dem Dilemma dass nicht
alles unter .NET läuft, und man somit auf x86 angewiesen ist.
Blieben noch Emulatoren... aber Software-Emulation von x86 kostet
noch viel mehr Strom als x86 stromfressend nativ auszuführen.
Wenn Microsoft von Anfang an auf .NET bzw CLI gesetzt hätte, hätten
sie dieses Problem nun nicht, und die Windows RT unter ARM wäre ein
vollwertiges, energiesparendes Windows dass eine Konkurrenz zu
Android & iOS sein könnte.
Aber Microsoft hat sich früher ja dazu entschlossen, lieber mit INTEL
zusammen die x86-Architektur zu monopolisieren.
Und dabei waren sie sehr erfolgreich im Etablieren einer Monokultur.
Doch nun fällt ihnen diese Monokultur beiden auf den Kopf, da sie
sich selbst an diese gekettet haben und mit ihr unterzugehen drohen.
Wobei die Lage für INTEL wesentlich rosiger ist als für M$: Intel
bräuchte nur ihren Stolz zu überwinden, eine ARM-Lizenz zu lösen und
könnte schon fröhlich weiter verkaufen.
Es ist ja nicht so, dass die ARM-Lizenzen teuer wären.
Vermutlich hat INTEL früher für die Weiterentwicklung von x86
wesentlich mehr ausgeben müssen als hätten sie ARM die Arbeit
überlassen und nur eine Lizenz genommen.
Aber das wäre von INTEL natürlich sehr undankbar Microsoft gegenüber.
Weil die könnten dann ja eigentlich nur noch bitterlich weinen.