×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

"Midori" Concepts Materialize In .NET

Soulskill posted about 4 years ago | from the creeping-in dept.

Operating Systems 106

dp619 writes "Concepts outlined in Microsoft's internal 'Midori' OS documents are materializing in .NET, according to an SD Times report. Midori is a new operating system project that is designed for distributed concurrency. Microsoft has assigned some of its all-star programmers to the project, while recruiting others. It is also working on other projects to replace Windows that make the OS act more like a hypervisor."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

106 comments

midori??? (0)

Anonymous Coward | about 4 years ago | (#31739386)

i will return???

Will Linux get to enjoy "Distributed Concurrency"? (1)

Taco Cowboy (5327) | about 4 years ago | (#31745202)

So MS is gonna get this "Distributed Concurrency" thing into Windows.

How about Linux?

When will Linux get enhanced by "Lidori" (Linux version of Midori)?

Where is the Borg King? (1)

You'reJustSlashFlock (1708024) | about 4 years ago | (#31739396)

Oh great and powerful /. editors, where is that visage that you love so much? Representing the Evil that is present no place else in this universe.

Re:Where is the Borg King? (1)

K. S. Kyosuke (729550) | about 4 years ago | (#31740442)

Given that the topic is "distributed concurrency", I find the Borg Gates pic especially fitting for the occasion. :)

Wasn't Windows 95 and 98 built from the ground up? (-1, Troll)

Anonymous Coward | about 4 years ago | (#31739438)

Wasn't Windows 95 built from the ground up? How much Linux code did they need to steal?

Re:Wasn't Windows 95 and 98 built from the ground (4, Informative)

x2A (858210) | about 4 years ago | (#31739628)

Win9x were built upon DOS (although replaced and virtualised it underneath itself) and provided win16/32 calls etc as subsystems. They're talking here about a fresh codebase that runs as a hypervisor and executes managed code. The idea basically being kinda like a microkernel but with increased isolation using newer virtualisation technology rather than the old erm... virtual memory technology... which has never really been used to its full potential I don't think.

Re:Wasn't Windows 95 and 98 built from the ground (2, Interesting)

ka9dgx (72702) | about 4 years ago | (#31740312)

Managed code doesn't fix things, because it doesn't allow the user to decide how his computer should be used by an application he's decided to execute. Nothing to date seems to do this basic task, outside of some stuff in research or military land.

Re:Wasn't Windows 95 and 98 built from the ground (2, Insightful)

psetzer (714543) | about 4 years ago | (#31741708)

That's the problem with any software that's not running on bare iron. A C program running on Linux is still limited in the exact same way that managed code is. It's just that the OS imposes those limitations with SIGSEGV rather than simply not deallocating referenced memory. If it really did let you do whatever you want that the hardware allows, that'd be a tremendous security hole.

Re:Wasn't Windows 95 and 98 built from the ground (1, Interesting)

Anonymous Coward | about 4 years ago | (#31742030)

You miss the point. The problem with mainstream OSes is that once you run an app it's free to do anything you can do, which includes shitting all over your data. He's talking about limiting what applications can do, not letting them do more. Google Capability Security Model for details.

Re:Wasn't Windows 95 and 98 built from the ground (2, Interesting)

x2A (858210) | about 4 years ago | (#31744414)

"A C program running on Linux is still limited in the exact same way that managed code is"

Not really. Managed code will tend to grow buffers, moving them if need be, rather than allow one out-of-bounds write to a buffer overwrite something next to it as unmanaged code will do.

Re:Wasn't Windows 95 and 98 built from the ground (1)

jpmorgan (517966) | about 4 years ago | (#31745396)

Not really. Managed code will use static analysis to prove that out-of-bounds writes will never happen.

Magically growing datastructures can be implemented in any language, managed or not.

Re:Wasn't Windows 95 and 98 built from the ground (1)

K. S. Kyosuke (729550) | about 4 years ago | (#31740510)

"and executes managed code."

...rendering hopelessly inefficient all the programming languages that won't fit the execution model of the one particular managed code spec that MS chooses to implement. Goodbye, Scheme, continuations etc.

Re:Wasn't Windows 95 and 98 built from the ground (1)

jared9900 (231352) | about 4 years ago | (#31741134)

Not to be an MS apologist, but IronScheme runs on the .NET (or more specifically CLR) platform. Also F#--which will be included in VS 2010-- supports continuations (found during a quick Google search of f# and continuations). Not that this effects me too much since I'm primarily using Linux/FreeBSD these days, but should I ever end up on an MS system based on these ideas there may still be hope.

Re:Wasn't Windows 95 and 98 built from the ground (1)

K. S. Kyosuke (729550) | about 4 years ago | (#31741470)

Yes, and Gambit Scheme is still miles ahead. You will never beat native code compilers on this. If anything, microkernels are the way to go. Language-based security enforcement OSes work for...well, supported languages. All the others will be either slow (either interpreted code or compiled code with workarounds) or simply unsupported. Say "no" to serious programming language research on such a platform, unless unmanaged code will be supported as well.

Re:Wasn't Windows 95 and 98 built from the ground (1)

cjl224 (840027) | about 4 years ago | (#31740584)

Windows 2008 is pretty much a hypervisor anyway with one 'guest' OS (itself). Installing the HyperV role only really virtualises the hardware and exposes the functionality to multiple guests. Not entirely accurate but close enough.

Re:Wasn't Windows 95 and 98 built from the ground (2, Informative)

BitZtream (692029) | about 4 years ago | (#31741548)

Contrary to what their marketing would have you believe it isn't anything like that. Infact, its more like firing up Windows 7 and replacing explorer with the hyperv manager.

Re:Wasn't Windows 95 and 98 built from the ground (1)

BitZtream (692029) | about 4 years ago | (#31741286)

The problem is they can't fix Windows so their coming up with a unique and non-obvious way to start from scratch without telling everyone they are starting from scratch.

They aren't actually doing anything new. Its just a different way to implement EXACTLY what we have in OSes now.

The REAL problem is ... when you have all these systems interacting with each other, they ALL have to be secure or it falls apart. Rewriting it isn't going to change that. I mean, sure it will in theory, and it will in practice right up until the point where the OS actually becomes useful for something. Why? Because to actually be useful you have to interact with something else. Notepad is useless if it can't take keyboard input/display output. Its worth is questionable at best if it can't print. Saving and loading are rather important. Even in a simple app like notepad there are many interactions between components of differing levels of access. By the time 'Midori' becomes useful, all these things will be back.

Applications within the OS are already supposed to be 'virtualized' and 'isolated' ... you know ... thats what the OS is supposed to do already.

All we're doing is making the shared portion of our computers smaller and smaller, which means bloat bloat bloat and issues with updating all the various bits multiple times.

It really bothers me that people thing vmware/hyper-v/virtualbox are acceptable. If the OS actually did its job right, these wouldn't be needed. When you use these tools you're just running multiple OSes. You've solved nothing and added more bloat and bugs.

Re:Wasn't Windows 95 and 98 built from the ground (1)

x2A (858210) | about 4 years ago | (#31744144)

"without telling everyone they are starting from scratch"

What?! That's exactly what they're telling everyone. A new system as a replacement to Windows, written from the ground up around extended concurrency models (to take more advantage of multicore/proc) and protection.

"They aren't actually doing anything new. Its just a different way to implement EXACTLY what we have in OSes now"

You think it inconceivable that the differences might mean things that you haven't thought of??

What if you forget about "malicious" for a moment (there's TPM chips for that) and think 'bugs'? With so many stability issues with Windows related to bugs in third party drivers and software, virtualising hardware interaction can be very beneficial, such as to the DMA chips. Without virtualising this, buggy drivers can end up reading/writing all over memory, beyond what permissions in the page table would allow CPU memory access. Windows wouldn't be the only OS to ever have problems with that occuring.

"Applications within the OS are already supposed to be 'virtualized' and 'isolated' ... you know ... thats what the OS is supposed to do already"

Well OSs often only really use a couple of the CPUs protection rings, with either all-in ring0 or all-out ring3. With "all or nothing", anything needing more than nothing needs to take everything. Evidentally whatever they're doing isn't always 100% successful, and one thing can crash another, even when there's no reason why those two things should be able to influence each other at all. Ignoring this fact and not putting some research into other ways of tacking the problem... well, would be pretty stupid, so I don't know why you would suggest that trying something that's not working in a different way would be a bad thing.

"All we're doing is making the shared portion of our computers smaller and smaller"

Yeah, why should your network card driver be able to read/write to memory allocated to your filesystem driver? These bits of memory shouldn't be shared. It doesn't mean "bloat bloat bloat"; you're not duplicating the filesystem drivers memory to allow the network card driver to write over its own copy of it "safely"; the network driver just doesn't get to see it at all.

"It really bothers me that people thing vmware/hyper-v/virtualbox are acceptable"

Well go on then Mr Perfect, write the perfect operating system that doesn't need them... making no mistakes ever, and not accepting any help of anybody who you couldn't absolutely guarentee wouldn't make any mistakes either.

It really bothers me that people think you should ignore a problem, and any solutions for the problem, simply because you don't think the problem should exist.

There's a reason why layers of abstraction occur in computing. Don't convince yourself that there can be no reason for something just because you can't think of it yourself. There's a lot of people out there. They will think of things you don't.

Re:Wasn't Windows 95 and 98 built from the ground (2, Insightful)

Cyberax (705495) | about 4 years ago | (#31741294)

Not exactly. Traditional microkernels turned out to be too slow and complex because of high overhead of context switching and complexity of distributed algorithms.

Microsoft is planning to replace context switches with statically-checked managed code. Managed code by its nature can work WITHOUT memory protection at all. And unmanaged code (aside from some thin driver-support code) can be nicely segregated into virtual machines.

It's actually quite a clever approach, not without its problems, of course.

Re:Wasn't Windows 95 and 98 built from the ground (1)

x2A (858210) | about 4 years ago | (#31744380)

Ahh... of course, you do away with MMU overhead, TLB flushes, stack overflows, and you can still translate much (if not all) to native code... if you can do that with lower overheads than context switching etc gives you, you've got a win. I've never really understood though why OSs (at least on x86, which is all I can comment on) rely so soley on the page table and TLB flushing as they do, while ignoring selector based protection and having them just map the whole of their address space. Eg, your code selector should not allow higher memory access than the bottom of your stack, and as your stack maps from the top of the stack selectors limit, different processes stacks could be placed at different places in memory, rather than at the same "the top of the address space" which requires flushing those TLBs between context switches. I suppose it would make calling conventions harder where the stack's used for storage... I dunno, I'm rambling, just surprised they seem so under utilised.

Cheers for that info anyway.

Re:Wasn't Windows 95 and 98 built from the ground (1)

setagllib (753300) | about 4 years ago | (#31744984)

Managed code by its nature can work WITHOUT memory protection at all.

How did you think the "management" worked? Either you trap each pointer access manually (and maintain all of that state and overhead), or you use a memory management unit to do it for you (and accept the cost of traps and context switches).

The very best that a VM runtime can do is infer that a class of access is impossible and thus exclude traps for it. This only works in extremely limited circumstances, and still requires code to be correct. It in fact makes profiling really difficult - and performance is the whole problem in the first place.

Re:Wasn't Windows 95 and 98 built from the ground (1)

Mr2001 (90979) | about 4 years ago | (#31745230)

The very best that a VM runtime can do is infer that a class of access is impossible and thus exclude traps for it. This only works in extremely limited circumstances, and still requires code to be correct.

That's exactly what "managed code" means in this context: the VM spec and the JIT-time verifier prohibit the types of accesses that would need to be trapped.

For example, you can't dereference a pointer that might point to any arbitrary memory location, because the verifier won't let you cast an integer to a managed pointer; you can only get a managed pointer by taking the address of a variable. You can't dereference a pointer to a local variable in a stack frame that no longer exists, because the verifier won't let you return the pointer out of that frame, and won't let any other function store the pointer anywhere except in an even deeper stack frame. This is checked statically, before the code runs, and then doesn't need to be checked again. (Certain operations do need runtime checking, like object casts and array access.)

The circumstances in which it works aren't really all that limited: just look at all the programs that have been written for .NET and Java. As for requiring code to be correct, well, that's what the verifier is for.

.. i must have seen that before (0)

Anonymous Coward | about 4 years ago | (#31739474)

Oh, you mean something like a micro-kernel (hypervisor like mini-OS to run a full fledged one on top)?

Re:.. i must have seen that before (0)

Anonymous Coward | about 4 years ago | (#31739558)

sounds like this is minix++ (or even minix#). A hypervisor is much more powerful than a regular mickrokernel, because it can spawn off vm's with protected 0-ring privileges.

Re:.. i must have seen that before (3, Informative)

shutdown -p now (807394) | about 4 years ago | (#31740274)

If it's anything like Singularity, then the point is to exploit static memory safety analysis (which is possible for sandboxed managed code) to avoid the overhead of virtual memory protection. Basically, if you have two processes for which you can statically prove that they never try to access each other's memory (e.g. because all pointer accesses are via pointers which are derived from heap allocations for that particular process, and no arithmetic is done on them that can put the result out of bounds of the original allocated block), then you can safely run them in a single memory space.

Re:.. i must have seen that before (4, Interesting)

ShadowRangerRIT (1301549) | about 4 years ago | (#31741350)

Midori [wikipedia.org] is just a first stab at a commercial version of Singularity. When I was working at MS a few years ago Midori was already being worked on; some of Windows built-in apps were being converted to run on it so they had something to test with it. It's not exactly new, and it's only a step or two from the Research group; I don't expect to see an actual released OS from the project for a long time.

From my impression of the project, it was mostly about finding a way to make the OS scale to massively multi-core machines; Windows can run on a many-core OS, but eventually all the locking and contention at the kernel level starts costing you a lot. Both the OS and the associated .NET-like language are designed to put constraints on the programming such that the processes can be parallelized efficiently without excessive locking.

Re:.. i must have seen that before (0)

Anonymous Coward | about 4 years ago | (#31741462)

Yebbut is it good or is it whack?

Re:.. i must have seen that before (1)

shutdown -p now (807394) | about 4 years ago | (#31741956)

Depends on how you define either one.

Anyway, Wikipedia has a more detailed high-level description [wikipedia.org] of Singularity, and the source code for it is available [codeplex.com] (use, modification and redistribution allowed non-commercial academic use only - not FLOSS). Assuming that Midori is a further development from that (and we don't really know), you can take a look at those two and judge for yourself.

Re:.. i must have seen that before (1)

pydev (1683904) | about 4 years ago | (#31744914)

If it's anything like Singularity, then the point is to exploit static memory safety analysis (which is possible for sandboxed managed code) to avoid the overhead of virtual memory protection.

That's been tried many times before, including with runtimes like Java, with signed code, and even with program analysis.

It's going to fail. Most of the commercial processors have virtual memory hardware. Even if eliminating it would result in speedups, no processor without virtual memory hardware is going to be optimized as much as the mainstream processors that have it. As a result, in practice, this is going to be slower. And even if they succeed in that, we would have to throw away most of the software and compilers we already have; it's not going to happen.

A much more sensible way is to add some kind of pointer verification to our processors. That way, existing programs could run more safely without a rewrite. In fact, that's already feasible for many programs even just using existing hardware, and hardware changes would be minimal.

These Microsoft projects are just academic; they are not going to lead anywhere. But even as academic interests, they don't really deliver much innovation.

Re:.. i must have seen that before (1)

shutdown -p now (807394) | about 4 years ago | (#31744952)

That's been tried many times before, including with runtimes like Java, with signed code, and even with program analysis.

It's all of the above, with DbC thrown into the mix.

It's going to fail. Most of the commercial processors have virtual memory hardware. Even if eliminating it would result in speedups, no processor without virtual memory hardware is going to be optimized as much as the mainstream processors that have it. As a result, in practice, this is going to be slower. And even if they succeed in that, we would have to throw away most of the software and compilers we already have; it's not going to happen.

Probably not in near future. However, consider this: Windows Phone 7 restricts software to managed & sandboxed only. Is it just to limit features and contain potential malware, or is there a long-term plan there?..

These Microsoft projects are just academic

True.

they are not going to lead anywhere.

That doesn't follow. Typical software development methodologies and tools of today were considered academic a few decades ago (e.g. OOP was an obscure academic experiment for quite some time; more recently, FP has been transitioning from academia to mainstream).

Hypervisor (-1, Troll)

WrongSizeGlass (838941) | about 4 years ago | (#31739524)

It is also working on other projects to replace Windows that make the OS act more like a hypervisor."

So this means your hypervisor can get infected? Is it really such a great idea to use the largest individual security risk in computers as a hypervisor?

Re:Hypervisor (4, Insightful)

sopssa (1498795) | about 4 years ago | (#31739606)

What are you smoking? Windows kernel itself hasn't really been vulnerable to anything, it's the third party software like Flash, Adobe PDF Reader, internet browsers, and previously some services.

Re:Hypervisor (1, Troll)

Zixaphir (845917) | about 4 years ago | (#31739658)

Internet explorer is third party? O.o

Re:Hypervisor (1, Insightful)

Anonymous Coward | about 4 years ago | (#31739732)

It may as well be.

Re:Hypervisor (4, Informative)

Anonymous Coward | about 4 years ago | (#31739850)

I believe he was stating that Microsofts ring 0 processes usually arent the security risk.

Re:Hypervisor (1, Troll)

The MAZZTer (911996) | about 4 years ago | (#31739752)

Then what is Microsoft patching every month?

Re:Hypervisor (5, Insightful)

Jahava (946858) | about 4 years ago | (#31740114)

What are you smoking? Windows kernel itself hasn't really been vulnerable to anything, it's the third party software like Flash, Adobe PDF Reader, internet browsers, and previously some services.

So here's what Google [google.com] has to say on the subject:

For the lazy reader, almost every article here has the phrase "An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode." For the even lazier, allow me to summarize: "That's a Bad Thing"

Indeed, like any long-lasting public multi-version kernel, the Windows kernel has had a hefty share of vulnerabilities. What you said is just plain false. However, to the OP:

So this means your hypervisor can get infected? Is it really such a great idea to use the largest individual security risk in computers as a hypervisor?

You may want to think a little harder about what you mean by kernel [wikipedia.org] . Every hypervisor is a type of kernel. Some things that perform hypervisor-like roles are full-fledged kernels [wikipedia.org] . However, if you actually click the link in the article that you're quoting, you'd see that they're not talking even remotely about what you think they are. The article details how Microsoft is investigating changing some fundamental (read: legacy, UNIXy, etc.) kernel models and roles to take a shot at getting more successful multicore performance and a better user experience. It's less about "zomg Windows is a hypervisor" and more about "what traditional Kernel roles can we modify?"

If you understood even fundamental systems architecture concepts, you'd realize that Windows as a hypervisor is a lot less scary than Windows as a standalone OS, as the latter is not only handed full system control, but is also responsible for arbitrating userspace execution.

Google says about Microsoft (-1, Offtopic)

Anonymous Coward | about 4 years ago | (#31740818)

Are you going to trust what Google says about Microsoft?

Lets try someone [bing.com] without a vested interest in flaunting the vulnerabilities of Microsoft products.

Oh, never mind, looks pretty much the same, carry on.

Re:Hypervisor (1)

virgilp (1774784) | about 4 years ago | (#31740448)

Name one successful Flash exploit out there. I could name several in the core windows services... Conficker, for one.

Re:Hypervisor (1)

cjl224 (840027) | about 4 years ago | (#31740674)

Well, there was that rootkit that intercepted a kernel call a month or two ago. That said, it was not an issue on x64 platforms and as MS have already dropped dev on 32bit server OSs, looks like they're going the right way to get away from that sort of thing.

Re:Hypervisor (1)

sopssa (1498795) | about 4 years ago | (#31740844)

But it wasn't even Microsoft's fault, it was a bug in the rootkit code. They overwrote OS code they though never gets updated, and when MS update patched it.. well, crash.

Re:Hypervisor (1)

gbjbaanb (229885) | about 4 years ago | (#31741074)


What are you smoking? Windows kernel itself hasn't really been vulnerable to anything, it's the third party software

but there have been several security updates for the kernel, so its more a case of what are you drinking?

(the MS koolaid, obviously).

As for 3rd party apps, yes, that true there are way more vulnerabilities in them, but that mostly applies to the Windows userland apps. I can tell how many vulnerabilities there are in Windows simply by looking at my update history - all those critical updates aren't distributed for fun.

Re:Hypervisor (0)

Anonymous Coward | about 4 years ago | (#31741484)

Did you just point your finger and say "Its not my problem, its their problem"? I thought so. Its not the car that's bad, its the roads, the gasoline, the weather, the tires, the air, the driver..... But... other cars go over those same roads, use the same gas, have the same weather, tires.....and they don't go boink all the time. So is it the theoretical showroom car (the one in the glossy magazine ads) that's the perfect version of the car, and only when you put the key in the ignition when the bad things happen (or dropping the analogy, when you press the power button).

Re:Hypervisor (1)

pydev (1683904) | about 4 years ago | (#31744930)

Of course it's mostly the application programs and libraries that get hacked. But the Windows kernel is ultimately responsible for those vulnerabilities because it defines the security and protection model that application programmers have to use. A well-designed kernel should make it hard to write software that is vulnerable.

Re:Hypervisor viruses (1)

nurb432 (527695) | about 4 years ago | (#31739714)

Sure there is a small potential, but it works well for 100's of thousands of ESX installs..

Re:Hypervisor (1)

davester666 (731373) | about 4 years ago | (#31739718)

They're just trying to make it so their problems affect everybody. That way, it's more likely that things like this http://www.computerworld.com/s/article/9164438/Microsoft_s_security_chief_suggests_Net_tax_to_clean_computers [computerworld.com] would be seriously considered by governments for example. And it becomes a way for them to try to reclaim Linux servers [so you still pay a Microsoft tax even if you run Linux servers...

Re:Hypervisor (0)

Anonymous Coward | about 4 years ago | (#31740690)

Where does it say the user will be acting more like a hypervisor?

Oh? (0, Offtopic)

Zixaphir (845917) | about 4 years ago | (#31739596)

Midori? [wikipedia.org]

Re:Oh? (3, Funny)

Minwee (522556) | about 4 years ago | (#31739942)

And here I thought it was Midori [wikipedia.org] . Perhaps she and SteveB could discuss alternative uses for chairs or something.

Re:Oh? (0)

Anonymous Coward | about 4 years ago | (#31740472)

And here I thought it was Midori [wikipedia.org] .

Re:Oh? (1)

Zantac69 (1331461) | about 4 years ago | (#31740762)

And here I thought it was Midori [wikipedia.org]

Re:Oh? (0)

Anonymous Coward | about 4 years ago | (#31744594)

That explains Microsoft's design process pretty well.

A hypervisor (1)

nurb432 (527695) | about 4 years ago | (#31739680)

That is tied to the Microsoft 'cloud' for its core functionality.. A return to the mainframe days where if you don't continue to pay, you don't have squat.

Re:A hypervisor (1)

ShadowRangerRIT (1301549) | about 4 years ago | (#31741424)

What are you smoking? Just because the OS supports distributed concurrency doesn't mean a cloud OS. The design is intended to support massively multi-core machines; the same techniques happen to be useful for distributed concurrency as well, but Midori isn't a cloud OS any more than an OpenMPI "OS" would be.

Re:A hypervisor (1)

nurb432 (527695) | about 4 years ago | (#31743008)

Smoking? No. However i do read papers that Microsoft publish that outlines their long term roadmap.

Midori is a step in the direction of a cloud based desktop, which is a stated goal. ( as is the current slow migration of their back office products )

TFA (4, Funny)

Steauengeglase (512315) | about 4 years ago | (#31739828)

An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Yep, bright future ahead.

Re:TFA (0)

Anonymous Coward | about 4 years ago | (#31740724)

I'm picturing a kind of big, "war room" like board with "Incoming slashdot effect!" signs lighting up, blaring sirens, and all sorts of people running around crazily with fire extinguishers or hiding under their desks in fear.

Don't worry, guys. I'm sure some people at sdtimes.com will survive in the basement shelters.

Re:TFA (0)

Anonymous Coward | about 4 years ago | (#31741368)

Quick! install X11 on there servers, so we can run a browser from the local machine and see the actual error message!

Re:TFA (1)

commodore73 (967172) | about 4 years ago | (#31741444)

I doubt you tried this, but I seem to remember that if you did a view source on some error pages returned from some versions of IIS, they show the stack trace, even though the configuration implied that it hid error details. I don't know if this is the case anymore. Security by attempted obscurity is no security at all.

where are you getting at? (1, Troll)

FuckingNickName (1362625) | about 4 years ago | (#31739894)

As always, MS, you're right that there are abstraction improvements which can be made at systems and app level, but as always, MS, you're never clear about what the problem is and what you're offering with your solution.

What do I get with Midori that I didn't get before? What's going to improve, for programmer or user?

Re:where are you getting at? (4, Insightful)

Anonymous Coward | about 4 years ago | (#31740526)

It would help if you'd bother reading the docs on Midori and the Singularity core it's built on.
For starters it's a microkernel, which, at least according to Liedke's principal of minimality offers flexibility and reliability through minimality. Because everything that isn't part of the microkernel is isolated from the kernel, and from other processes (via SIPs (Software Isolated Processes)) a service that crashes or goes goes does not take the kernel or anything else with it, instead the "service" is stopped, and detatched from everything depending on it, restarted and reattached - crashes behave like a web browser would, should the internet connection be severed - it just sits there and wait for the connection to be re-established, leaving you with a much more robust and reliable system.

Second, it also "acts like a hypervisor" (mind you, a hypervisor is little more than a glorified microkernel which doesn't completely adhere to Liedke's principal of minimality), to run an OS written entirely in managed code (Sing# and Spec# in this case, IIRC) which conveys they security benefits of managed code to the entire OS, leeaving you, once again, with as more secure and more reliable system, with a fun bonus that what is essentially the .NET framework becomes to Midori, what Win32 is to previous and current edditions of Windows.

There's also the ease of debugging and management argument; which is easier to manage, debug and ultimately least likely to contain critical bugs, a 4,000 line kernel, or a 15,000,000 line kernel? And the performance argument of old regarding microkernels don't apply here (and haven't really applied anyway, since L4 and much more so when hypervisors started popping up all over the place), I don't recall the number OTOH (but they're available at MSL's site under the section devoted to Singularity), though they manage to put out impressive perf numbers,. apparently mostly due to its use of SIPs, rather than more traditional means of process isolation..

All the information is readily available on MSL and has been for quite some time, in fact, the Singularity RDK has been freely available for at least two years now, and the whitepapers and such for longer. You'll find that MS has been fairlt forthcoming regarding the answers you're looking for.

Re:where are you getting at? (1)

FuckingNickName (1362625) | about 4 years ago | (#31740894)

No, you're inventing a problem ("insecure, hard to manage kernels/services") and proposing a solution ("the microkernel!") in the style of Tanenbaum vs Torvalds back in '91. There tends not to be a problem with stable, insecure kernels on modern server platforms.

MS appear to be offering an Ocaml implementation, right? And then want to implement everything system-flavoured under it, in the style of a LISP machine, right?

Re:where are you getting at? (1, Insightful)

Anonymous Coward | about 4 years ago | (#31740706)

These articles were not written by Microsoft to promote itself. These articles were written by outsiders to discuss the implications of the extremely little that people know about Midori.

It's green! (0)

Anonymous Coward | about 4 years ago | (#31740758)

> What do I get with Midori that I didn't get before? What's going to improve, for programmer or user?

Well, they're calling it Midori, so I'm assuming it's some kind of green tech?

Or at least the boxes the software comes in are green. I dunno.

Re:where are you getting at? (1)

BitZtream (692029) | about 4 years ago | (#31741726)

Its going to be exactly like we have now, except basically you'll have two layers of kernels and abstraction to go through instead of one!

NUMA + MPI? (0)

Anonymous Coward | about 4 years ago | (#31740034)

Well, I personally tested a 4 processor 32 cores 64 threads beast.

I have found that with integrated RAM controllers connected to separate RAM banks and without going to NUMA + MPI, one would simply waste CPU cycles waiting for RAM transaction to complete.
Local MPI helps a lot but requires a lot of code re-shuffling.

In few years multi-core single CPUs will choke on memory bandwidth too and we will have separate RAM controllers on die.
This will bring NUMA and MPI horros to a desktop PC.

So yes, I think I see where it goes: to something more manageable then MPI, with .Net wrappers and such.

Sounds like more vapourware (-1, Troll)

Pop69 (700500) | about 4 years ago | (#31740384)

So will we be getting this before or after the database filesystem that's been promised since around 1990 ?

Hell, I'd expect to be able to play Duke Nukem Forever on it

Corrections regarding F# (5, Insightful)

shutdown -p now (807394) | about 4 years ago | (#31740476)

There are a few things in SDTimes article, in the bit where they talk about F#, which are incorrect:

For instance, F# is highly immutable—meaning that object states cannot be modified once created

This isn't really true. F# defaults to immutable locals and record/object fields, but you can always declare them as mutable explicitly if you want. In that, it's quite similar to OCaml, and quite different from Haskell. Example:

type Foo =
  let x = 0 // immutable field
  member this.Bar() =
    let y = x // immutable local
    y <- y + 1 // error
    x <- y // error
 
// Mutable class
type Foo =
  let mutable x = 0 // mutable field
  member this.Bar() =
    let mutable y = x // mutable local
    y <- y + 1 // okay
    x <- y // okay

And then also:

... and has an implicit type system

There's nothing "implicit" about F#'s type system - it's quite in-your-face, in fact even more so than in a typical OO language such as C# or Java. For example, it won't do automatic upcasts.

I guess what they meant there is that F# has Hindley-Milner type inference [wikipedia.org] .

Re:Corrections regarding F# (1)

GigaHurtsMyRobot (1143329) | about 4 years ago | (#31741718)

Great post... no mod points. I looked into F# for a work project and was very interested in learning it, just haven't found the time.

Re:Corrections regarding F# (1)

EvanED (569694) | about 4 years ago | (#31744066)

There's nothing "implicit" about F#'s type system - it's quite in-your-face, in fact even more so than in a typical OO language such as C# or Java. For example, it won't do automatic upcasts.

Actually "implicit" is a pretty decent description of type systems that do type inference.

What's the definition of "implicit"? Random House says (for the first definition), "implied, rather than expressly stated." But this is exactly what happens in a language like ML or Haskell. If I say "fun f x = x + 1", I have not expressly stated that f's type is "int -> int", but that's exactly what that code implies.

Re:Corrections regarding F# (1)

EvanED (569694) | about 4 years ago | (#31744330)

In fact, take a look at that Wikipedia article that you linked to. Here's how it starts: "Type inference, or implicit typing, refers to the ability to deduce automatically the type of a value..." (my emphasis).

Re:Corrections regarding F# (1)

shutdown -p now (807394) | about 4 years ago | (#31744582)

Fair enough. I must admit that it's the first time I've heard the word used in this context, though. But then I can't even complain about how WP may be incorrect, since I was the one to link to it... pwned all the way. ~

Re:Corrections regarding F# (1)

RAMMS+EIN (578166) | about 4 years ago | (#31745210)

Of course, typing in F# (assuming it works the same way as in OCaml, which, as far as I know, it does) is not really implicit, it's just that the types are specified by the operations when they aren't specified explicitly.

If you write

let f x y = x + y

the + says that x and y are ints just as surely as if you had written

let f (x : int) (y : int) = x + y

Still, it is true that, in the first example, the name of the type doesn't occur anywhere. So I think that is what people mean when they say "implicit".

Mac OSX Microkernel (1)

PimpDawg (852099) | about 4 years ago | (#31740730)

The Mach kernel uses a message-passing micro-kernel implementation. But it also has a nifty copy-on-write scheme that allows it to be fast and circumvent the usual problems with micr-kernels (copying of messages 300 times between layers).

sigh... (-1, Offtopic)

Anonymous Coward | about 4 years ago | (#31741056)

Here we go again. Netscape is becoming a platform that threatens to make the OS irrelevant? Let's "integrate" Internet Explorer into the OS! Java threatens to become the platform of choice? Here comes C#! Now VMware is becoming the environment of choice, so let's bundle virtualization with the next Windows! It's amazing what this people get away with...

Managed code? (1)

Suiggy (1544213) | about 4 years ago | (#31741230)

Will this spell the death of of unmanaged programming languages like C and C++ and the respective software developers who uses those languages? How will people such as game developers, who are heavily entrenched in C++ development, migrate themselves and their game engines and code bases to this new operating system?

Re:Managed code? (1)

gbjbaanb (229885) | about 4 years ago | (#31742556)

I doubt it.

eg. from TFA:

The Midori programming model includes Bartok, an MSR project that endeavored to create a lightweight compiled and managed runtime system that was more efficient than the .NET Framework

So maybe its not quite .NET after all. Anyhow, I think this research project is something that they;'re using to take the good ideas out of - especially where they apply to cloud computing as MS doesn't really have much there yet and they see it as a great way of making you pay for a subscription to their software instead of a one-off purchase.

As for C/C++, there's a reason game programmers write in those languages and not .NET, though you do see some more strategy-based games coming out made in XNA, they're not at the cutting edge. Games sell either as mass-market, run-everywhere flash-type things (eg little games on your iPhone), or big super-graphically based ones. There's not that much market for .NET games that fall somewhere in the middle.

Re:Managed code? (1)

Suiggy (1544213) | about 4 years ago | (#31743090)

Right, but if Midori replaces Windows, what's going to happen to PC gaming? All current popular gaming devices support native C/C++ development, including the iPhone OS and Android with the NDK.

fiRst po5t (-1, Offtopic)

Anonymous Coward | about 4 years ago | (#31741946)

found out about the AAsholes, as they Whether you juggernaut either Are almost big picture. What Unless you cani work to download the fear the reaper

"all star programmers" huh... (0)

Anonymous Coward | about 4 years ago | (#31742160)

only 11 guys working on the next gen OS.
Good to know M$ is keeping the development team compact and agile.
Shouldn't take much more than 20 years for these 11 guys to get the RC1 out the door.

Offtopic, but I hope with an os redesign that they (0)

Anonymous Coward | about 4 years ago | (#31742802)

I just want an os with application level etiquette that doesn't steal focus from where I'm typing. It's very frustrating to type something, hit space as soon as some dialogue comes up, and not know wtf just happened... Or get an IM while typing an e-mail and find a few words in the IM window, possibly followed by making it permanent. This is made worse when the applications are slow and effectively prevents you from doing anything until it finishes because you know it'll steal focus.

It's my biggest pet peeve with computing today, and I hope they take advantage of this opportunity (of redesigning the os) to redefine how applications should work on it.

Re:Offtopic, but I hope with an os redesign that t (1)

Kazoo the Clown (644526) | about 4 years ago | (#31743228)

I second that motion, kill ugly popups. Or at least, delay them until there's sufficient pause in my typing...

Those who don't understand UNIX ... (0, Troll)

BalkanBoy (201243) | about 4 years ago | (#31744628)

are condemned to reinvent it, poorly.

Those who are too stupid to understand OS design.. (0)

Anonymous Coward | about 4 years ago | (#31746086)

to comment on this article seem to be the ones leaving boring un-funny comments.

old hat; try solving the hard problems instead (1)

pydev (1683904) | about 4 years ago | (#31744900)

These "operating system concepts" have been explored at length in systems like Plan 9, Inferno, Mach, various Java distributed toolkits, agent-based programming, and God knows how many more obscure operating systems and platforms.

As usual, Microsoft is late and non-innovative. If Microsoft had actually managed to deliver a commercial kernel based on those concepts, that might have been interesting. But just folding the stuff into .NET is the same kind of retreat everybody else who has tried this has made: they all started off dreaming of building the next gen OS, and they all ended up with a bunch of bloated libraries and frameworks that are barely used.

The tough part is not figuring out what the right thing to do is in this area, the tough part is figuring out how to build a real operating system around it that real developers and users will actually want to use.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...