Slashdot Mirror


Nothing of .Net in Longhorn?

turnitover writes "We've been waiting for Longhorn before we really get on the .Net train, but should we bother at all? According to Mary Jo Foley at Microsoft Watch, Longhorn won't be based on .Net at all. Foley, who's usually right on target, calls this MS's 'dirty little secret'." From the article: "We're guessing that Microsoft will maintain that nothing has changed-that no one ever promised that the .Net Framework 2.0 would be the foundation for Longhorn. But developer types we've been chatting with seem to find this update a newsworthy revelation."

6 of 479 comments (clear)

  1. So Why .NET? by geomon · · Score: 4, Interesting

    If Microsoft seems unwilling to bind .NET to its next flagship OS, then why all the rush to produce .NET-capable products? Is .NET going to be a wash? Why bother worrying about Mono's fate as well? If Microsoft doesn't seem to work hard to integrate it into their primary platform, then should the Mono developers continue to look over their shoulders?

    Is .NET another Microsoft vaporware?

    Instead, the .Net Framework will be the core for a small subset of Longhorn, specifically the Windows API Platform (WAP), which consists primarily of the "Avalon" Windows presentation system and the "Indigo" Windows communications system, our tipsters say.

    Okay, but will Avalon be a core system in Longhorn? The new file system is out, and some of the early discussion from Microsoft indicated that Avalon might be 'out' until after the first version of Longhorn ships.

    I use Microsoft products and am really getting confused about their software roadmap.

    --
    "Rocky Rococo, at your cervix!"
    1. Re:So Why .NET? by Sique · · Score: 4, Interesting

      The question was not, if .NET (version 1.0, version 1.1) are vaporware. They are present and usable.

      The question was, if the .NET OS is vaporware, and if the rumours are somewhat related to the truth, it may be. The question was, if the rush to rebuild everything on .NET to be able to serve Microsoft's next generation OS, was founded on vaporware. It might be, if the rumours contain a grain of correctness.

      --
      .sig: Sique *sigh*
    2. Re:So Why .NET? by toddbu · · Score: 4, Interesting
      The strategy has been in place for five years.

      I want to ask a really serious question here - What exactly is the .Net strategy? I ask this question because people ask me what .Net is, and after all this time all I can only tell them is that it's given us a new programming language similar to Java. Forget the FUD, what is .Net really? I'm not looking for a link to MSDN. I'm looking for is a single concise statement about the technology. For example, I could say that managed code is "a replacement for traditional programming techniques that focuses on eliminating mistakes made by novice programmers thereby improving program stability and security". Is there such a one-liner for the .Net strategy?

      --
      If you don't want crime to pay, let the government run it.
  2. this IS significant! by yagu · · Score: 5, Interesting

    First off, let me preface this post with the lol: I find it amazingly ironic that the advertisement on the Slashdot "read more" page has the Microsoft .NET ad, apparently Macro Flash.... with the hook: "If it takes eighteen months to write and integrate a new application...", [fade to next frame...], "It's not really new anymore, is it?".... the ad is for .NET!

    I find Microsoft's "not eating their own dog food" rumors to be significant. Why does the rest of the world have to eat it (literally and figuratively) and not Microsoft?

    More hubris from Microsoft. Apparently .NET is something Microsoft discussed and presented and strategized around at one of Bill Gates' yearly "meeting of the minds" at his Hood Canal retreat a number of years ago... Former Microsoft CFO John Connors bragged on this during a one-day glad handing session with the company I worked for at the time. He got up for a impromptu presentation as we all worked on our .NET "labs", and described how worked up into a slather the Microsofties were at the retreat.... describing the .NET architecture, and philosophy. He said, and I quote, "We realized that not only had we won the battle [with .NET], but we've won the war [against(?) the industry]".

    The collective sound generated of all of the techies eyes rolling in the conference room was deafening, but the upper level management (and really, this entire session was about them getting to meet with Microsoft royalty, and cinching a sale/contract) postively glowed and nodded knowingly and smugly that they were part of this technology nirvana about to sweep the world.

    I would say we're at least four or five years into this and so far what I've seen with .NET is:

    • it doesn't always work
    • .NET 2 is not retro compatible with .NET 1.1 (they say it is, it isn't).
    • .NET is monstrously large
    • .NET does not solve the dll hell problem (they said it would.)

    So, again, the fact that by the time (and I guess we're all speculating here) Longhorn gets here if Longhorn is not largely based on and implemented with .NET says a lot for either: how difficult it really is to move applicatioins to the .NET architecture, or, how much even Microsoft itself believes in the technology. Neither possibility is good. Other slashdotters feel free to offer other theories.

  3. Layering will not fix a bloated OS by Animats · · Score: 5, Interesting
    The software industry has settled on a strategy for dealing with the fact that its operating systems are bloated and insecure. This strategy is roughly as follows:
    • Put virtual machines on top, like Java and .NET. Claim that they're more secure than the OS.
    • Put virtual machines underneath, like VMware. Claim that they're more secure than the OS.
    • Add software to catch known attacks, like firewalls, virus scanners, and spyware removers.
    • Patch, patch, patch.
    It's not working.

    It's not just a Microsoft problem, either; Linux is acquiring exactly the same set of problems as the kernel grows and grows.

    It doesn't have to be this bad.

    Dave Cutler, the architect of Windows NT, tried to fix it. NT 3.51 was the last version he controlled, and the last one that looks even vaguely like a "microkernel". He once told Bill Gates "I won't pollute it [NT] with crap!" So he was taken off NT, and for NT 4, the kode kiddies from the Windows 95 team were allowed to put huge volumes of crap Win95 code in the kernel, for "compatibility". The end result is XP, which in practice is only slightly less vulnerable than Windows 95.

    It's striking to run QNX, which is a true microkernel (about 60K of code), with drivers, file systems, and networking outside the kernel. It can run X windows, Firefox, multimedia players, and now has OpenGL. That's a demonstration that you don't need a bloated kernel. Nor do you need one that changes much. The QNX kernel changes very slowly; new capabilities are added outside the kernel, in user space. Unfortunately, QNX on the desktop is going nowhere, because there are few applications and the current marketing push is for automotive applications. Nor is QNX intended as a secure operating system, just a reliable real-time one. Despite this, it's a clear demonstration that the basic OS does not have to be big or constantly changing.

    If the Hurd guys had a clue, and could write something as good as QNX, there might be some hope from that direction. But after ten years of screwing up, there's not much hope there.

  4. Re:asdf by aoteoroa · · Score: 4, Interesting

    This is why you should be able to club marketing reps to death.

    After working as a programmer for 6 years I have heard a lot of marketing hype through brochures, white papers, and information seminars and I have come up with this principal: "Never promise that a task can be done based on what documentation or white papers say."

    When a new API, IDE, framework or whatever is realeased I try building a small prototype, or test application, and only after first hand experience do I promise a project manager that it can be done. Otherwise I tell him that this new technology represents an unknown that could (is likely to) throw our timeline out of whack