Talk:Singularity (operating system)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
WikiProject iconMicrosoft: .NET
WikiProject iconThis article is within the scope of WikiProject Microsoft, a collaborative effort to improve the coverage of articles relating to Microsoft on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
???This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject .NET (assessed as Low-importance).

singularity[edit]

The concepts of "unsafe" and "safe mode" should be explained in this article since they're obviously not very common terms. -- intgr 16:48, 20 May 2006 (UTC)[reply]

Linked each to type safety to provide context. Vesta 03:06, 26 May 2006 (UTC)[reply]
I'm sorry, but I took those out because I don't think it has anything to do with type safety. C# is always a type safe language, for example. This seem to be talking of a "mode" rather than a programming language concept. Are you really sure this was about type safety? I first thought it spoke of unsafe code, but the sentence still doesn't make much sense to me even if that would be the case. — Northgrove 02:01, 6 March 2008 (UTC)[reply]

Also, does this operating system assume that the virtual machine executing the code is 100% bulletproof? Since it seems that you can circumvent any restrictions once you manage to gain control of the virtual machine, and thus also control the entire operating system as you see fit. -- intgr 16:48, 20 May 2006 (UTC)[reply]

I don't see what you're getting at. Microsoft uses a JIT compiler rather than a virtual machine. Vesta 03:06, 26 May 2006 (UTC)[reply]
I think they're called virtual machines whether they compile the bytecode into native code or interpret it, but I guess that is debatable. Either way, JIT compilers are not necessarily completely secure. The optimizations performed by the compiler can create plenty of loopholes that can be used to trick the compiler into executing malformed or custom-crafted machine code. So I'm asking if hypothetically one of such bugs could be used to gain control of the entire virtual machine. -- intgr 17:47, 26 May 2006 (UTC)[reply]
Such a bug can probably be exploited to gain control of the entire machine, not just the VM. Let's hope that the developers build the compiler correctly. :) -- Vesta 02:11, 28 May 2006 (UTC)[reply]
In one of their videos they mentioned this. They plan on moving from "trusting" Bartok to compiling to some kind of typed assembly language. That way the actual byte code can be verified. -- Jmacdonagh 02:00, 24 October 2006 (UTC)[reply]
In fact it could be theoricaly possible to create a prooved implementation. However such a task is pretty complex. A Typed Assembly Language such as TALx86 could indeed be used to detect some compilation bugs. It is important to note that even with Typed Assembly Language, security holes are still possible. Nevertheless such an architecture would result in far more security holes than typical 'modern' OS.--debackerl 18:18, 29 October 2006 (UTC)[reply]

Shouldn't we mention JNode here? it is more or less the same thing, but in java. —Preceding unsigned comment added by 57.79.167.12 (talkcontribs)

Overly Technical[edit]

I added the overly technical box since an average user would have no idea what's going on in this article. Nrbelex (talk) 21:30, 4 October 2006 (UTC)[reply]

The casual user would probably not have much interest in Singularity as it does not provide any applications. It is more of a showcase, or proof of concept, rather than an operating system one might use to create a workstation out of (in it's current form). In fact, one might say it's technical merits are it's only merits. 209.197.144.123 (talk) 23:50, 13 June 2008 (UTC)[reply]

OSs[edit]

Whats with the os's on the right: how can this have anything to do with DOS if the priject started in 2003? —Preceding unsigned comment added by 86.29.53.244 (talk) 08:42, 22 October 2007 (UTC)[reply]

This is not DOS. This is just console. Singularity does not have anything from DOS --94.179.44.178 (talk) 10:49, 22 January 2009 (UTC)[reply]

So why doesn't the CPU do this?[edit]

"Instead, there is only a single address space in which "Software-Isolated Processes" (SIP) reside. Each SIP has its own data and code layout, and is independent from other SIPs. These SIPs behave like normal processes, but do not require the overhead penalty of task-switches. Protection in this system is provided by a set of invariants"

Ok, I get the idea here. But if this results in real-world performance benefits due to the lack of task switching overhead, doesn't this suggest that the CPU could be extended to provide the same sort of invariants and thereby offer the same benefit to all OS's?

Maury (talk) 14:47, 6 March 2008 (UTC)[reply]

The invariants it is referring to here are the assurances the OS makes that a program will not access memory that it does not own. The OS can make this assurance when the program is installed and it analyzes the MSIL code. The performance benefits are realized because the safety checking is done only once, at install time, instead of at runtime by the CPU. —Preceding unsigned comment added by 207.13.122.233 (talk) 16:17, 10 March 2008 (UTC)[reply]
Sure, but what I'm thinking is that the compiler could export this into CPU primitives driving the MMU, avoiding doing any of this "in code" at all. Modern CPUs are already trying to handle this invisibly through hyper-threading and such, it seems that making this explicit would be a great improvement. I can't help thinking about the Transputer's approach. Maury (talk) 12:22, 13 March 2008 (UTC)[reply]
I think you are confusing what an invariant is. It is not some operation that is done on the processes or applications. Rather it is a set of guarantees - the OS guarantees you that no matter what the installed applications do, the effects of memory protection (one app cannot modify the memory of another and so on) will hold true.
The OS can guarantee this because of the architecture of the Operating System. All applications are written using type-safe and verifiable language (like C#) which does away with unsafe stuff like pointers and unchecked buffers and invalid casts. Such code is further subjected to static analysis at compile time/and or installation. During this analysis, it can be checked whether the application does anything that might violate the invariants. The OS, during installation, checks the applications. If it does not pass the test, it is not installed. Consequently, if it gets installed, it is guaranteed not to violate memory protection requirements. The check is done at install-time, not at run-time.
How many times do you install a software as compared to how many times is it run? As such, things that happen at run time are a much better candidate for hardware acceleration. Also, different OSs might do this stuff in different ways and a CPU has to be as generic as possible. As such there is very little incentive at the CPU level to incorporate things that are done by a single OS only. --soum talk 12:41, 13 March 2008 (UTC)[reply]

RDK 2.0 out[edit]

Hey guys, I'm a Wikipedia admin as well as a lead developer on the Singularity RDK, and just wanted to let you know a new major revision is out at CodePlex. Feel free to incorporate this into the article in any manner you feel is appropriate, I'm avoiding editing for WP:COI. :-) Dcoetzee 03:00, 15 November 2008 (UTC)[reply]

Minimum system requirements[edit]

Dose anyone know what are minimum system requirements for this thing? —Preceding unsigned comment added by 82.179.85.3 (talk) 14:44, 26 November 2008 (UTC)[reply]

There aren't any official system requirements, but we've run it on some shuttle boxes with quite limited specs, like 512MB of RAM, a single 2.0 GHz proc, no hard disk. It's been run in Virtual PC with quite limited resources too, but I don't think you could push the RAM requirement much lower than 512 MB. Dcoetzee 19:36, 22 January 2009 (UTC)[reply]

New image[edit]

Galen Hunt, with Singularity running on the monitor in the background.

Hey all, I've uploaded a portrait of Galen Hunt, the principle researcher behind Singularity (right). Not sure if it's useful for this article, or just for a future biographical article, but feel free to use. Dcoetzee 00:33, 4 June 2009 (UTC)[reply]

AS/400 etc ?[edit]

Might IBM/s System/38, AS/400, etc. deserve places on the Related Technologies list? —Preceding unsigned comment added by 69.248.248.11 (talk) 15:10, 23 August 2009 (UTC)[reply]

Review and revise in light of discussion?[edit]

Good article with some ambiguities. Good discussion in which some of those ambiguities are cleared up. Might be good to go back over the article and apply some of the clarifications made on the discussion page to the article itself.

Points that leap to mind:

-- Make first mention of "safe mode" a link to the safe mode article.

-- Explicitly use the term "type safety" in connection with the "safer" languages and make it a link to an article that explains what that means.

-- Make it clearer that the static analysis mentioned in the article occurs at application install time rather than at run time as explained in the discussion.

There may be others I've missed. —Preceding unsigned comment added by 69.248.248.11 (talk) 15:40, 23 August 2009 (UTC)[reply]

Some changes to the Related software section[edit]

This Wikipedia articles on Singularity and Midori seem to be the best that is offered on most of the visible Web; the press and blogosphere is on to some incredibly speculative stuff, especially in regards to Midori. So while I'm not a frequent contributor to Wikipedia, I decided to improve this article some more, specifically the "Related software" section.

-- The title "related software" seemed rather vague, and since the articles in the list seemed to be either similar projects by entities besides Microsoft Research or adjacent projects by Microsoft and/or Microsoft Research itself, I split the section into two: one called Similar projects and another called See also. I ordered the See also section in order of generality.

-- I couldn't figure out why Erlang's message passing would be related specifically to Singularity but not to anything else (I think it's a rather common mechanism by now), so I removed the link. Please restore this link if there is indeed a significant relationship that I'm unaware of.

-- The phrase at the beginning: "The ideas of Singularity are not unique, and can also be seen in other software projects, listed here." seemed to be rather weasely and vague and unnecessary, so I removed it. It was unclear whether by "the ideas" it was meant that none of the ideas in Singularity are unique, or simply that some of them are visible in other projects. The former insinuation would likely be incorrect. For instance, no mention is made in any of the other operating system articles about the goal of dependability that is primary to Singularity, nor about what design principles were brought to the table (e.g. OS-managed installation, compilation and static verification) in order to achieve that goal.

rei 174.1.36.72 (talk) 10:27, 4 September 2009 (UTC)[reply]

Should we also add a link to Qubes OS? Its idea of using virtualization to strictly separate different domains seems to be related. In fact, the two were also compared on Slashdot. Jonas Wagner (talk) 13:25, 28 November 2011 (UTC)[reply]

[edit]

It appears that the logo has been deleted. Perhaps you should re-upload it, this time with licensing information. -143.215.112.125 (talk) 07:32, 21 July 2010 (UTC)[reply]