Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Operating Systems Microsoft

"Midori" Concepts Materialize In .NET 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."
This discussion has been archived. No new comments can be posted.

"Midori" Concepts Materialize In .NET

Comments Filter:
  • Linus (Score:2, Funny)

    Presumably this is the project they hired Linus to head up? /ducks

  • 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.

    • 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.
      • by nurb432 ( 527695 )

        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 (Score:5, Funny)

    by Steauengeglase ( 512315 ) on Monday April 05, 2010 @03:06PM (#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.

  • 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?

    • by Anonymous Coward on Monday April 05, 2010 @03:41PM (#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.

      • 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: (Score:1, Insightful)

      by Anonymous Coward

      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.

    • 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!

  • by shutdown -p now ( 807394 ) on Monday April 05, 2010 @03:38PM (#31740476) Journal

    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].

    • 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.
    • by EvanED ( 569694 )

      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 e

      • by EvanED ( 569694 )

        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).

        • 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. ~

          • 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".

            • Of course, typing in F# (assuming it works the same way as in OCaml, which, as far as I know, it does)

              It does with a few exceptions. Specifically for + (and other arithmetic operators), they're overloaded on int and float, rather than having separate operator +. etc for float as in OCaml.

              However, they're not properly polymorphic, in a sense that there's no way to constrain a type on "having operator +" (which would require proper type classes) - so, when it sees + in a context of some unknown type 'a, it has to constrain 'a to be a specific type with +, and it always picks int, so your example still works a

  • It left sour taste in my mouth.
  • What does my lovely Guitar Hero waifu have to do with anything MS does??

  • Midori? (Score:5, Funny)

    by IGnatius T Foobar ( 4328 ) on Monday April 05, 2010 @03:47PM (#31740640) Homepage Journal
    Forget about Midori ... I want to know when parts of Mojave will find their way into Windows and .net !!
  • 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?
    • 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

      • by Suiggy ( 1544213 )
        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.
  • are condemned to reinvent it, poorly.

  • 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:

    • I've already been awarded Troll for expressing my doubts that MS is clear about what problem it's solving (instead just experimenting with a tech and then shoehorning some of it into a low-risk existing product, as is typical for them), but I think it's clear that, aware that they can't just replace one OS kernel with another, their ostensible intention is to begin by offering their new magic as a VM on top of Windows. If Silverlight is their delivery platform, I'll be surprised if they don't get the same r

"Life sucks, but death doesn't put out at all...." -- Thomas J. Kopp

Working...