Linked by Thom Holwerda on Sat 19th Aug 2006 16:11 UTC
Microsoft MSDN's Channel 9 has two videos in their 'Going Deep' series which dive, well, deeper into Singularity, the operating system in development at Microsoft's research department. The first of the two is about, among other things, Software Isolated Processes (SIPs). The second of the two actually shows Singularity in action.
Thread beginning with comment 153964
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: R&D
by butters on Sat 19th Aug 2006 18:43 UTC in reply to "R&D"
butters
Member since:
2005-07-08

But the OS didn't impress me to much, they didn't came up with something new or exciting, just ordinary micro kernel.

First, plain old microkernel? Show me a viable microkernel operating system that really functions like a microkernel OS should--with all device drivers in userspace and only the VM service in the kernel. Sure, MINIX, L4, Mach, Plan9, and others are headed down that path, but none have been successful. If Singularity really was a true microkernel operating system, that would be impressive.

But it isn't. Although Singularity has a really small surface area of trusted code, lots of managed code lives in kernelspace to avoid the overhead of IPC and context switches. Singularity, believe it or not, is closer is design to a mainframe operating system like IBM's VM. Isolated processes are nothing new in general, but they are revolutionary on "new-school" architectures like x86, PPC, and SPARC. The classic mainframes in the 1970s and 80s all had isolated processes, although they were at least partially isolated in hardware. The idea of a strictly software isolated process model might be uncharted territory (not sure).

What whould realy be interesting is if they did an OS not in an imperative language, but in functional, e.g. by incoporating MS other R&D project like F#.

I'm sure that's possible in theory, but it wouldn't be easy, and it certainly wouldn't be pretty. Operating systems are all about side-effects, and functional programming (strictly speaking) doesn't allow them.

C is the language of choice for systems programmers everywhere. The C language is the greatest triumph of computer science. It's the wheel, it's fire, it's sliced bread. As they say, choose the right tool for the right job. But C will continue to be right for many jobs well after the newer languages fall out of favor.

Reply Parent Score: 5

RE[2]: R&D
by Ronald Vos on Sat 19th Aug 2006 19:29 in reply to "RE: R&D"
Ronald Vos Member since:
2005-07-06

I've read about 'side-effects' in imperative languages before (possibly in your posts), but what is exactly meant by them?

Reply Parent Score: 2

RE[3]: R&D
by grayrest on Sat 19th Aug 2006 19:54 in reply to "RE[2]: R&D"
grayrest Member since:
2006-03-14

I've read about 'side-effects' in imperative languages before (possibly in your posts), but what is exactly meant by them?

A side-effect is something that changes the state of the system. Simple example (javascript):

pure_functional = function(a){return a+2;}

side_effect = function(a){a += 2; return a;}

In the first case, you get back a+2 but a remains the same, in the second you get back the same thing but the value of a is changed.

This is a rather trivial example, but more significant things like I/O are also side effects. Wikipedia has a rather extensive treatment of functional programming, side effects, etc if you're interested.

Reply Parent Score: 3

RE[2]: R&D
by Ronald Vos on Sat 19th Aug 2006 19:44 in reply to "RE: R&D"
Ronald Vos Member since:
2005-07-06

First, plain old microkernel? Show me a viable microkernel operating system that really functions like a microkernel OS should--with all device drivers in userspace and only the VM service in the kernel. Sure, MINIX, L4, Mach, Plan9, and others are headed down that path, but none have been successful. If Singularity really was a true microkernel operating system, that would be impressive.

As an aside: being a microkernel has never been a goal. And with managed code, it should be useless to be a microkernel, except if you would want all services restartable.

Reply Parent Score: 2

RE[2]: R&D
by grayrest on Sat 19th Aug 2006 20:14 in reply to "RE: R&D"
grayrest Member since:
2006-03-14

But it isn't [a microkernel]. Although Singularity has a really small surface area of trusted code, lots of managed code lives in kernelspace to avoid the overhead of IPC and context switches.

Well technically, all the code in the system lives in kernel space and runs at Ring 0. That they can do this and still claim security is, by my understanding, the primary finding of the project.

If you watch the older videos, IPC between processes is basically passing a pointer to a page in memory. There is no context switch unless you deliberately set one up in hardware (what a good chunk of this video is about). My impression is that the processes in Singularity are closer to the weight of threads that don't share memory (erlang processes would be a good example).

I'm pretty sure this research leans more towards the applied than the theoretical. It was started when MS began their big security push and the goal seems to be making the most robust OS possible and then showing it can be made into a workable production system. They occasionally do less applied stuff, but I always get the impression that "windows longhorn/vista+2" is the target for the project.

Edited 2006-08-19 20:16

Reply Parent Score: 2

RE[2]: R&D
by segedunum on Sat 19th Aug 2006 20:35 in reply to "RE: R&D"
segedunum Member since:
2005-07-06

First, plain old microkernel? Show me a viable microkernel operating system that really functions like a microkernel OS should--with all device drivers in userspace and only the VM service in the kernel.

Well quite. The problem is a microkernel seems like a great idea, and then inevitable compromises are made over things like performance and you end up coming to the same conclusions everyone else has for the past twenty or thirty years.

Reply Parent Score: 2

RE[3]: R&D
by netpython on Sat 19th Aug 2006 20:40 in reply to "RE[2]: R&D"
netpython Member since:
2005-07-06

Why just one and not more micro kernels for critical areas?

Reply Parent Score: 1

RE[3]: R&D
by CaptainPinko on Sat 19th Aug 2006 21:52 in reply to "RE[2]: R&D"
CaptainPinko Member since:
2005-07-21

with multicore why not just have one core be a kernel and then use the other 1,3, 31 for user-level threads? should prevent latency since no switching right?

Reply Parent Score: 1

RE[2]: R&D
by baad_to_The_bone on Sat 19th Aug 2006 21:12 in reply to "RE: R&D"
baad_to_The_bone Member since:
2006-02-08

C is the language of choice for systems programmers everywhere

Not everywhere. IBM's VM, which you mention, isn't written in C.

Reply Parent Score: 1

RE[3]: R&D
by netpython on Sun 20th Aug 2006 05:53 in reply to "RE[2]: R&D"
netpython Member since:
2005-07-06

True,a know i flight control centre who almost solely uses ADA for their mission critical systems.

Edited 2006-08-20 05:54

Reply Parent Score: 1