Singularity

[Monger]

Keine Ahnung ob das jetzt besser in Spekulationen reinpasst, aber ich fand das schon sehr spannend.

http://www.heise.de/newsticker/meldung/65804

Vorallem das offizielle Dokument ist lesenswert.

ftp://ftp.research.microsoft.com/pub/tr/TR-2005-135.pdf


Microsofts verlässliches Betriebssystem "Singularity"
Seit Microsofts Forschungsabteilung das Konzept Singularity Projekt über ein von Anfang an neu konzipiertes Betriebssystem vor ein paar Tagen online gestellt hat, kochen die Diskussionen in den einschlägigen Foren hoch. Nicht Performance soll im Mittelpunkt des Betriebssystems Singularity stehen, sondern "dependability" zu deutsch: Verlässlichkeit. Mit diesem Begriff umfasst Microsoft Zuverlässigkeit, Verfügbarkeit und Sicherheit (reliability, availability, security, safety). Mit Windows hat Singularity nichts zu tun, es verwendet so genannte Software-isolated Processes (SIPs) als geschlossene Objekt-Räume, die einzelne Bestandteile sicher voneinander abkoppeln, Informationen voreinander verstecken, eigene Fehlerbehandlung bieten und die über eine "strenge" Schnittstelle miteinander kommunizieren. Anzeige


Sichere Compiler wie C# und Java sind nach den Ausführungen der Microsoft-Entwickler für verlässliche Systeme unabdingbar, für Singularity verwendeten sie eine spezielle Compilerversion Sing#, die sich von dem C#-Derivat Spec# ableitet. Eine andere Microsoft-Forschungsgruppe entwickelt parallel dazu einen weiteren neuen Compiler namens Concur, speziell für parallele Systeme.

Trotz seiner höheren Verlässlichkeit ist Singularity im Umgang mit Prozessen etwa beim Erzeugen und Starten eines Prozesses weitaus schneller: 300.000 CPU-Takte im Unterschied zu Windows (5,4 Millionen), BSD (1 Million) oder Linux (719.000). Auch bei Disk-I/O oder SPECweb99 schlägt es sich nicht schlecht. Die Code-Größe etwa von "Hello World" bleibt bei Sing# mit 286 KByte im Rahmen, hier ist Windows-C++ mit 69 KByte klar besser, wohingegen Linux-C++ 984 KByte verschlingt.

Ob und wann sich jedoch ein Produkt aus diesem Forschungsvorhaben herauskristallisieren wird, ist derzeit noch völlig unklar. (as/c't)



Ich bin noch nicht ganz durch mit dem PDF, aber was sie da erklären finde ich einleuchtend. Vorallem dass Singularity offenbar nicht nur "schön", sondern auch schnell ist, zeigt doch dass der Ansatz richtig ist.

[Demirug]

Dort gibt es ein Video mit 2 von den Entwicklern: http://channel9.msdn.com/Showpost.aspx?postid=68302

[Cyphermaster]

Ausgezeichnete Idee imho (soweit ich mit meinem arg begrenzten Programmierwissen das PDF verstanden hab), aber wenn das dann genauso wird wie bei Windows95, das ja seinerzeit schon das versprochen hat, was Windows XP jetzt 10 Jahre später hält... :rolleyes:

LOLig ist aber, daß man an den Zahlen schön sehen kann, was bei Windows derzeit passiert: BSD und Linux kommen mit ~1Mio Takten pro Prozeß aus, Windows braucht dazu aber nochmal ~4,5Mio Takte, um die zugehörige system-inhärente Spy- und Nagware mit zu starten... :upara: :devil: ;)

[HellHorse]

OMG, OS in C# / Java geschrieben! Der Untergang der Welt! Alles kotze-langsam! :D

Bleibt zu hoffen, dass daraus mehr wird als ein blosses Forschungsprojekt.

[Demirug]

OMG, OS in C# / Java geschrieben! Der Untergang der Welt! Alles kotze-langsam! :D

Bleibt zu hoffen, dass daraus mehr wird als ein blosses Forschungsprojekt.

Jemand von Windows Kernel Team hat schon mal über einen .Net Framework für Kerneltreiber sinniert.

[kelo]

Habe mich über die Beiträge im Heise-Forum kichern/lächeln müssen.
MS versucht das OS neu zu schreiben, vor allem in Hinsicht Sicherheit (DRM, TCPA usw.)

[mbee]

[] Du hast wirklich verstanden, worum es dabei geht und das dies ein Forschungsprojekt ist...
Die Newsticker-Meldung ist allerdings mal wieder typisch heise (Fehler, mies recherchiert): Mit denen geht es immer schneller bergab (die meisten langjährigen freien Autoren schreiben nicht mehr für den Verlag und es scheint bezüglich der Website auch nur noch der Traffic in den Foren zu interessieren).

[RaumKraehe]

LOLig ist aber, daß man an den Zahlen schön sehen kann, was bei Windows derzeit passiert: BSD und Linux kommen mit ~1Mio Takten pro Prozeß aus, Windows braucht dazu aber nochmal ~4,5Mio Takte, um die zugehörige system-inhärente Spy- und Nagware mit zu starten... :upara: :devil: ;)

Ist zwar Offtopic aber: Was sagen diese Taktzahlen genau aus? Also wie kann ich das verstehen? Ich dachte immer wenn ich ein Prozess starte dann wird mit dem doppelklick oder der Eingabetaste der Prozess (Programm?) gestartet. Aber ich hätte nicht gedacht das man 1 Mio Takte braucht um den Prozeß "Hello World" zu starten. :eek:

Und mal von der Spyware und sonstigem abgesehen, was macht Windows da noch?

[Ganon]

Und mal von der Spyware und sonstigem abgesehen, was macht Windows da noch?

Ich denke mal die ganze Speicher anfordern Geschichte.

[Monger]

Ist zwar Offtopic aber: Was sagen diese Taktzahlen genau aus? Also wie kann ich das verstehen? Ich dachte immer wenn ich ein Prozess starte dann wird mit dem doppelklick oder der Eingabetaste der Prozess (Programm?) gestartet. Aber ich hätte nicht gedacht das man 1 Mio Takte braucht um den Prozeß "Hello World" zu starten. :eek:

Und mal von der Spyware und sonstigem abgesehen, was macht Windows da noch?

Speicher allokiieren, Prozess starten und branchen, Klassen von der Festplatte in den Speicher kopieren... dabei ist natürlich immer der Kernel im Spiel, der ständig alle "Threads" (sagt man das so bei Prozessen?) in den Händen halten muss und den Zugriff auf Treiber (auch Festplatte) kontrollieren muss.

Ich kann mir schon vorstellen dass das Zeit braucht. Dass es so viel ist, hat mich aber auch verblüfft.

@topic: ich habe jetzt auch das Video auf Channel9 gesehen - und bin umso mehr begeistert. Vorallem wie einheitlich plötzlich alle Vorgänge betrachtet werden können. Unterschiede zwischen Betriebssystem und Anwendungssoftware schwinden völlig. Das Ding heißt nicht umsonst "Singularity". Und wie das beschrieben wird, erinnert mich das ein bißchen an Agentensoftware - halt nur koordiniert auf einem Rechner zusammengepfercht.
Zu Schade, dass sowas (wenn überhaupt) furchtbar lange braucht, bis es in fertige Produkte miteinfließen kann. Wie ja auch schon im Video gesagt: Kompatibilität ist ein wichtigeres Kriterium als Sicherheit. Ein Betriebssystem auf dem keine Software läuft, ist wertlos.

[kelo]

[] Du hast wirklich verstanden, worum es dabei geht und das dies ein Forschungsprojekt ist...
Die Newsticker-Meldung ist allerdings mal wieder typisch heise (Fehler, mies recherchiert): Mit denen geht es immer schneller bergab (die meisten langjährigen freien Autoren schreiben nicht mehr für den Verlag und es scheint bezüglich der Website auch nur noch der Traffic in den Foren zu interessieren).
Muss mal den Artikel suchen (irgendwo in den News). Jedenfalls wird darin informiert, dass das ständige "chaotische" hinzuprogrammieren von Features in Windows zu kompliziert macht. Deswegen verzögert sich Windows Vista.
Ein Parallelansatz ist es, das OS bzw. Kernel in c# (C++ ist laut MS am aussterben) komplett neu zu schreiben. Das es dabei ein Forschungsprojekt ist, sollte klar sein. Aber es ist auch die Absicht, einen neuen Weg zu gehen.
Vielleicht wird der Kernel neu, und die zusätzlichen Komponenten (IE, WMP, DX...) werden über Schnittstellen angesprochen.
Bei Linux wurde ja auch der Kernel "komplett" neu geschrieben. (man erfindet dabei nicht das Rad jedesmal neu)

[Demirug]

Muss mal den Artikel suchen (irgendwo in den News). Jedenfalls wird darin informiert, dass das ständige "chaotische" hinzuprogrammieren von Features in Windows zu kompliziert macht. Deswegen verzögert sich Windows Vista.
Ein Parallelansatz ist es, das OS bzw. Kernel in c# (C++ ist laut MS am aussterben) komplett neu zu schreiben. Das es dabei ein Forschungsprojekt ist, sollte klar sein. Aber es ist auch die Absicht, einen neuen Weg zu gehen.
Vielleicht wird der Kernel neu, und die zusätzlichen Komponenten (IE, WMP, DX...) werden über Schnittstellen angesprochen.
Bei Linux wurde ja auch der Kernel "komplett" neu geschrieben. (man erfindet dabei nicht das Rad jedesmal neu)

IIRC war der Artikel in den News nicht das eigentliche Original. Dort wurde die Sache nämlich sehr genau beschrieben und es war nicht Windows welches zu kompliziert wurde sondern die Entwicklung. Microsoft hast es einfach nicht mehr geschafft die vielen hundert Entwickler zu koordinieren.

Und C++ stirbt bei MS keineswegs aus. Sie haben den neuen Compiler nochmal extrem verbessert. Das macht man nicht wenn man nicht mehr an eine Zukunft des Produkts glaubt.

[Coda]

(C++ ist laut MS am aussterben)Das halte ich aber für ein Gerücht. Wenn das der Fall wäre hätten sie nicht immens Resourcen in VC C++ .NET 2005 gesteckt.

Edit: Demi kam mir mal wieder zuvor ;)

[Senior Sanchez]

Das halte ich aber für ein Gerücht. Wenn das der Fall wäre hätten sie nicht immens Resourcen in VC C++ .NET 2005 gesteckt.

Edit: Demi kam mir mal wieder zuvor ;)

Singularity klingt auf jeden Fall interessant :) Wenn es die klasse von WM 2003 SE aufn Desktop bringt, das wäre klasse ;)

OTT:
Was wurde denn an VC C++ 2005 so verbessert?

[kelo]

IIRC war der Artikel in den News nicht das eigentliche Original. Dort wurde die Sache nämlich sehr genau beschrieben und es war nicht Windows welches zu kompliziert wurde sondern die Entwicklung. Microsoft hast es einfach nicht mehr geschafft die vielen hundert Entwickler zu koordinieren.

Und C++ stirbt bei MS keineswegs aus. Sie haben den neuen Compiler nochmal extrem verbessert. Das macht man nicht wenn man nicht mehr an eine Zukunft des Produkts glaubt.
Ja, die Entwicklung von Windows wurde zu kompliziert, weil vieles angebaut worden war. Irgendwann ist der Zeitpunkt gekommen, wo man sich sagt, der Aufwand zu flicken und schustern ist zu groß, reißen wir es ab und bauen es komplett neu auf. Auch mit dem Ziel das ganze besser zu machen.
C# sollte mal C++ ablösen. Haben sie sich doch anders überlegt.

Was wurde insgesamt verbessert? Muss mal in Ruhe danach suchen.

[Grestorn]

C# sollte mal C++ ablösen. Haben sie sich doch anders überlegt.Nein. C# und C++ haben unterschiedliche Einsatzzwecke. Ich glaube nicht, dass jemand, der sich wirklich auskennt, ernsthaft Treiberprogrammierung mit C# o.ä. in Erwägung gezogen hat. Auch wenn man das hin und wieder mal irgendwo hört...

[Demirug]

Ja, die Entwicklung von Windows wurde zu kompliziert, weil vieles angebaut worden war. Irgendwann ist der Zeitpunkt gekommen, wo man sich sagt, der Aufwand zu flicken und schustern ist zu groß, reißen wir es ab und bauen es komplett neu auf. Auch mit dem Ziel das ganze besser zu machen.
C# sollte mal C++ ablösen. Haben sie sich doch anders überlegt.

Was wurde insgesamt verbessert? Muss mal in Ruhe danach suchen.

Das einzige was Microsoft abgerissen hat ist das Entwicklungsmodel. Sie haben zwar im Prinzip noch einmal auf der Basis der 2003er Servers von vorne mit der Entwicklung von Vista angefangen aber die Teams haben dabei Code den sie schon hatten zum Teil wieder einfliessen lassen.

Das Problem bei Vista war das zu viele Teams an zu vielen Stellen des Systems gleichzeitig gearbeitetet haben und sich so ständig gegenseitig aufgehalten haben weil jeder auf den anderen warten musste. Das neue Model funktioniert jetzt anders um genau das zu vermeiden. Es gibt jetzt während der Entwicklung nicht mehr ein einziges großes Windows an dem alle arbeiten sondern jede Ebene wird zyklisch für die darüber liegenden zyklisch eingeforen. Ist alles sehr kompliziert aber was soll man auch erwarten beim größten Softwareprojekt der Welt?

C# sollte niemals C++ ablösen. Microsoft möchte das man so viel wie möglich Software für die Managed Umgebung schreibt. Das geht aber auch in C++ und letzten Endes ist es Microsoft völlig egal welche Sprache man nimmt. C# hat aber in den meisten Fällen den Vorteil das man damit produktiver als mit C++ ist.

[Demirug]

Nein. C# und C++ haben unterschiedliche Einsatzzwecke. Ich glaube nicht, dass jemand, der sich wirklich auskennt, ernsthaft Treiberprogrammierung mit C# o.ä. in Erwägung gezogen hat. Auch wenn man das hin und wieder mal irgendwo hört...

Ich kann bei Windows Vista bereits Treiber mit C# schreiben und wie gesagt ich weiß von Aussagen der Kernelentwickler selbst das dort mit einer Managed Umgebung für Treiber geliebtäugelt wird. Allerdings frühstens in der nächsten Version nach Vista weil das ein Bruch im Treibermodel wäre.

[Grestorn]

Ich kann bei Windows Vista bereits Treiber mit C# schreiben und wie gesagt ich weiß von Aussagen der Kernelentwickler selbst das dort mit einer Managed Umgebung für Treiber geliebtäugelt wird. Allerdings frühstens in der nächsten Version nach Vista weil das ein Bruch im Treibermodel wäre.Nenn mich konservativ, aber hardwarenahe Programmierung und eine Virtual Machine, was die .NET CLR ja nun auch ist, sind für mich zwei unvereinbare Konzepte.

Man kann sicher bestimmte Treiberschichten auf .NET aufsetzen, aber das hat irgendwo immer seine Grenzen.

[Senior Sanchez]

Nenn mich konservativ, aber hardwarenahe Programmierung und eine Virtual Machine, was die .NET CLR ja nun auch ist, sind für mich zwei unvereinbare Konzepte.

Man kann sicher bestimmte Treiberschichten auf .NET aufsetzen, aber das hat irgendwo immer seine Grenzen.

Zumindest für Java gibts ja auch CPUs die den Bytecode native ausführen ;) vllt auch mal für .NET CLR, dann ginge das natürlich auch ;)

Also ich denke, dass es schon ginge, zumal die VM in vielen Fällen eine erhöhte Sicherheit und Stabilität verspricht.

[Demirug]

Nenn mich konservativ, aber hardwarenahe Programmierung und eine Virtual Machine, was die .NET CLR ja nun auch ist, sind für mich zwei unvereinbare Konzepte.

Man kann sicher bestimmte Treiberschichten auf .NET aufsetzen, aber das hat irgendwo immer seine Grenzen.

MSIL wird ja immer gejittet (OK Mono kann auch interpretieren und ich habe auch schon mal einen Crosscompiler dafür geschrieben). Das Kernel Team sprach ja auch davon das man Kerneltreiber bei der Installation Prejitten würde. Ein entsprechender Jitter könnte dann sogar problemlos mit dem HAL zusammen arbeiten und dadurch sogar besseren Treibercode erzeugen als das im Moment möglich ist. Beim HAL wechseln müsste dann natürlich alles nochmal gejittet werden aber das ist ja kein Problem.

Das es technisch möglich ist und auch von der Performances kein wirkliches Problem darstellt wurde mit Singularity ja gezeigt.

[Grestorn]

Das es technisch funktioniert bezweifle ich gar nicht so sehr.

Ich will an bestimmten Stellen aber genau bestimmten können, wann Speicher allokiert und wann er freigegeben wird. Ich will direkt auf den Speicher zugreifen können ohne Umweg über aufgeblasene Klassen. Ich will Interrupts sperren können. Ich will vielleicht sogar inline ASM Code einfügen, wenn etwas performancekritisch ist (Interrupt-Handler z.B.).

Mag sein, dass man das alles irgendwie erreichen kann. Aber wenn man C# derart erweitert, dann kann man auch gleich C++ nehmen. Dass der Code durch vorkompiliert ändert daran nicht viel.

C# hat seine Vorteile an anderer Stelle, aber für einen Treiber würde ich niemals auf eine derart abstrakte Ebene gehen, wie C#.

[Demirug]

Das es technisch funktioniert bezweifle ich gar nicht so sehr.

Ich will an bestimmten Stellen aber genau bestimmten können, wann Speicher allokiert und wann er freigegeben wird. Ich will direkt auf den Speicher zugreifen können ohne Umweg über aufgeblasene Klassen. Ich will Interrupts sperren können. Ich will vielleicht sogar inline ASM Code einfügen, wenn etwas performancekritisch ist (Interrupt-Handler z.B.).

Mag sein, dass man das alles irgendwie erreichen kann. Aber wenn man C# derart erweitert, dann kann man auch gleich C++ nehmen. Dass der Code durch vorkompiliert ändert daran nicht viel.

C# hat seine Vorteile an anderer Stelle, aber für einen Treiber würde ich niemals auf eine derart abstrakte Ebene gehen, wie C#.

Du hast schon mal Treiber für Windows programmiert?

[Ganon]

Wie werden Treiber denn zur Zeit unter Windows programmiert? C oder C++? Oder geht beides?

[Demirug]

Wie werden Treiber denn zur Zeit unter Windows programmiert? C oder C++? Oder geht beides?

Es geht beides. Die API ist wie alle Windows API primär natürlich C. Es gibt aber auch einen schönen OOP Framework für die Treiberentwicklung.

[Grestorn]

Du hast schon mal Treiber für Windows programmiert?Für Windows nicht, nein.

[Demirug]

Für Windows nicht, nein.

Das erklärt einiges weil viele deiner Forderungen in der Windows Treiber Entwicklung geradezu verpönnt sind.

Nahezu jede Systemkomponete die sich mehrer Geräte Teilen müssen (DMA, Interrupt usw) ist hinter einer dicken API Mauer und dem HAL geschützt. Oder anders ausgedrückt ein guter Windows Treiber ist auf der Sourcecode Ebene völlig Platform unabhänigig.

[Grestorn]

Das erklärt einiges weil viele deiner Forderungen in der Windows Treiber Entwicklung geradezu verpönnt sind.

Nahezu jede Systemkomponete die sich mehrer Geräte Teilen müssen (DMA, Interrupt usw) ist hinter einer dicken API Mauer und dem HAL geschützt. Oder anders ausgedrückt ein guter Windows Treiber ist auf der Sourcecode Ebene völlig Platform unabhänigig.Wieder was dazugelernt. :smile: