Warum die Aufregung?

[papa_hilft]

Singularity oder nun halt Helios ist seit langem ein versuch das perfekte OS, vor allem das perfekt sichere OS zu bauen.

Dieses OS ist wie die Studien (Nicht prototypen!) der Automobilindustrie ein Wegweiser und Ideengeber für die Serienproduktion.

Dieses OS ist genausoweit von Windows entfernt wie die Saturnrakete vom ersten Auto. Mittlerweile sind einige Erfindungen wie etwa der Bordcomputer in das Auto eingebaut, aber zum Mond fliegen kann man damit immer noch nicht.

Daher sind die flames hier recht sinnentleert, und auch Hoffnungen das Helios (in den nachsten 15 Jahren?) zu einem OS für den Normaluser wird.

Gruß Papa_hilft

[Yeeeeeeeeha]

Vielen Dank für diesen Hinweis, auch wenn die Forentrolle hier das nichtmal verstehen wollen. :(

Denen gebe ich auch zu bedenken, dass bei MS nicht lauter Idioten arbeiten, sondern mehr als genug hochgebildete und erfahrere Informatiker, Mathematiker usw., von denen mit Sicherheit auch ein guter Teil in der Freizeit an Oopen Source Software beschäftigt ist. MS hat eine Menge Know How und mehr als genug Geld um weiteres hinzuzukaufen. Es kommt zwar trotzdem viel Mist dabei raus, aber das trifft nicht nur auf MS zu!

Yeeeeeeeeha - Nur echt mit 2^3 e
Perl-Monk, Java-Trinker, Objective-C Wizard, PHP-Kiddie, unfreiwilliger FreeBSD-/Linux-Teilzeitadmin

[sn4fu]

papa_hilft schrieb:
--------------------------------------------------------------------------------
> Singularity oder nun halt Helios ist seit langem ein versuch das perfekte OS, vor allem das perfekt sichere OS zu bauen.

Einer von uns Beiden hat da was ganz massiv falsch verstanden und nachdem ich mir eben die Muehe gemacht hab nochmal bei Wikipedia nach Singularity zu suchen neige ich zur Auffassung, dass du jener bist. (=

"...it invokes the kernel, whose runtime and garbage collector are written in Sing# (an extended version of Spec#, itself an extension of C#) and runs in unsafe mode."

oder verkuerzt: "...the kernel ... runs in unsafe mode."

und weiter: "Unlike most historical microkernels, its components execute in the same address space (process), which contains "software-isolated processes" (SIPs). ... These SIPs behave like normal processes, but avoid the cost of task-switches."

Zu Deutsch es wird mutwillig auf die in Hardware implementierten Funktionen zur Trennung der Adressraeume verzichtet, Betriebssystem wie Anwendungen teilen sich den selben Adressraum (das nannte sich glaub seinerzeit "kooperatives Multitasking" und wenn eine Anwendung nicht kooperativ war, war der naechste Reboot faellig), damit das nicht von vornherein ein Stabilitaets- und Sicherheitsdesaster gibt, darf auf diesem System nur noch interpretierter Code laufen und Microsoft (sic!) wacht mit seinem Interpreter darueber, dass sich auch ja niemand daneben benimmt!

Nochmal auf deutsch: Wir missachten die in jeder modernen Architektur verankerte Speicherverwaltung, weil wir in Software theoretsich schneller sein koennten und implementieren die notwendige Speichertrennung nachtraeglich in Software (weil wir cleverer sind als der Rest der Menschheit, vor allem cleverer als alle Hardware-Entwickler zusammen).

Das hoert sich doch wirklich wie eine tolle Idee an um Betriebssysteme stabiler und sicherer zu machen.

Ich lasse mich nicht darueber aus, was ich von der Idee halte dieses Konzept auch noch ueber mehrere Prozessoren mit dedizierter Speicheranbindung und moglichst auch noch verschiedenen Hardwarearchitekturen auszudehnen...

snafu

[Hello_World]

sn4fu schrieb:
--------------------------------------------------------------------------------
> "...it invokes the kernel, whose runtime and garbage collector are written
> in Sing# (an extended version of Spec#, itself an extension of C#) and runs
> in unsafe mode."
>
> oder verkuerzt: "...the kernel ... runs in unsafe mode."
Ähm, und? Das trifft auf den Kernel prizipiell immer zu. Es gibt eben keine sichere Laufzeitumgebung, in der der Kernel laufen könnte, da der Kernel selbst diese für Programme bereitstellt.
> Zu Deutsch es wird mutwillig auf die in Hardware implementierten Funktionen
> zur Trennung der Adressraeume verzichtet, Betriebssystem wie Anwendungen
> teilen sich den selben Adressraum
Wenn man statisch nachweisen kann, dass ein Programm niemals auf fremden Speicher zugreift, braucht man auch keinen Speicherschutz. Oder anders gesagt: wenn die Programme in einer Sprache geschrieben sind, die automatisch Prüfungen für Array-Grenzen, Null-Checks usw. einfügt, gibt es keinen Grund, die Performancenachteile von Speicherschutz in Kauf zu nehmen.
> (das nannte sich glaub seinerzeit
> "kooperatives Multitasking" und wenn eine Anwendung nicht kooperativ war,
> war der naechste Reboot faellig),
Schwachsinn, das ist eine ganz andere Baustelle.
> damit das nicht von vornherein ein
> Stabilitaets- und Sicherheitsdesaster gibt, darf auf diesem System nur noch
> interpretierter Code laufen und Microsoft (sic!) wacht mit seinem
> Interpreter darueber, dass sich auch ja niemand daneben benimmt!
>
> Nochmal auf deutsch: Wir missachten die in jeder modernen Architektur
> verankerte Speicherverwaltung, weil wir in Software theoretsich schneller
> sein koennten
Nein, weil sie in Software schneller _sind_.
> und implementieren die notwendige Speichertrennung
> nachtraeglich in Software (weil wir cleverer sind als der Rest der
> Menschheit, vor allem cleverer als alle Hardware-Entwickler zusammen).
Blödsinn, es geht einfach darum, dass man sich mit gewissen Nachteilen (nämlich der Inkompatibilität mit vorhandenen C- und C++-Anwendungen) auf anderen Gebieten Vorteile erkaufen kann.
> Das hoert sich doch wirklich wie eine tolle Idee an um Betriebssysteme
> stabiler und sicherer zu machen.
Das tut es in der Tat.
> Ich lasse mich nicht darueber aus, was ich von der Idee halte dieses
> Konzept auch noch ueber mehrere Prozessoren mit dedizierter
> Speicheranbindung und moglichst auch noch verschiedenen
> Hardwarearchitekturen auszudehnen...
Ist wohl besser so.

[Foxfire]

> Nochmal auf deutsch: Wir missachten die in jeder modernen Architektur
> verankerte Speicherverwaltung, weil wir in Software theoretsich schneller
> sein koennten und implementieren die notwendige Speichertrennung
> nachtraeglich in Software (weil wir cleverer sind als der Rest der
> Menschheit, vor allem cleverer als alle Hardware-Entwickler zusammen).

Du checkst es einfach nicht: Die Idee ist eine Architektur zu haben bei der die Speichertrennung bereits fixer Bestandteil ist. Dadurch müss sie nicht mehr wie bisher zur Laufzeit durchgeführt werden. Weder in Hardware NOCH in Software.

> Das hoert sich doch wirklich wie eine tolle Idee an um Betriebssysteme
> stabiler und sicherer zu machen.

Zumindest hört es sich nach einem tollen Ansatz an.