Could .NET Render An MS Breakup Verdict Irrelevant?

AntiFreeze writes: "The Economist has a very interesting article about Microsoft's plans for .NET and how it would effectively remove most damage caused by a government orderred breakup. The article is written towards the layman, but is very clear and sort of scary." He cites this excerpt from the article, as well: "Even so, it is remarkable how effectively .NET could insulate the firm in the event of its being divided into an operating-system company (which would own Windows) and an applications company (owning Office)."

Comments

Re:Doomed to fail

[cduffy]

There certainly are plusses to .NET -- indeed, I honestly wish it were developed and controlled by an open project or standards body (or a vendor with more of an interest in cross-platform support). It standardizes calling conventions and data types (removing issues such as the binary compatibility problems between G++ 2.95 and 3.0), permits debugging tools to work with support only for the platform in general rather than the specific language (a great thing for those who happen to like coding in Eiffel or something else off the wall but are interested in using our other debugging tools). And no, it doesn't require its own language.

I really think .net has a future of some sort. Whether it becomes the new win32 API that everyone else is incompatible with (except for via some rather dodgy ports/reimplimentations), a competitor for Java bytecode or even universally ubiquitous I don't know, though.

Re:Aren't you a little afraid...

[cduffy]

Howdy. As a software developer (professionally) and sysadmin (on the side) with both win32 and *nix experience, I've got to dispute what you're saying. (Note that my win32 experience is getting increasingly dated; I'd be happy to know if any of my statements are outdated -- for instance, if Windows actually has logical volume management or online filesystem resizing support now).

Command line OSes are harder to learn than GUI-based administrative systems -- I'll agree with you there. The thing is that us Unix folks distinguish between "hard to learn" and "hard to use". If after scaling that steep learning curve we can then get our work done faster -- and we can -- then by our definition Unix is easier to use. Furthermore, because we've mastered all that (hard to learn) control, we can do our jobs better.

The current effort is on getting the best of both worlds by putting together GUI-based administrative tools, so that folks can use whatever they choose. For those of us who've already finished the learning curve thing, though, there's no more need; we're there.

Let me rephrase one of your earlier sentences. MS software is centered around making learning my job easier and saving training time. I'll agree that it does both of those. However, once I'm done with the learning, I can do a better job on a Unix-based system than on Windows. Why? The same reason it's hard to learn -- I've got more control. Can *you* add another hard drive with your machine still running and resize your filesystem online, with all your software still running? As long as my box has hardware and BIOS support (thanks 3ware!), I can. Furthermore, because more of the 'guts' of a Unix system are available for inspection, debugging and postmortem analysis is much easier. Trust me, when you're trying to figure out why your VPN isn't working, it sure helps if you can add a few lines of code to dump the keys on each side out to the syslog for comparison. We also have better filesystems -- ever seen reiserfs and NTFS side-by-side trying to access lots of small files? It's lots of fun.

While a Windows-based system was initially designed to be controlled by an individual at the console clicking with a mouse, *nix-based systems are controlled in manners more condusive to automation. A skilled sysadmin can automate nearly every task he needs to do with greater ease than on Windows (yes, I know automation support is available there, but it sucks -- I've ported perl scripts for Apache user administration to work on IIS; they got a whoole lot more complicated and slower in the meantime).

Finally, the documentation depends on what you're trying to do. Frequently the man pages aren't the best source -- that's why there are info pages, HOWTOs, mailing lists and (of course) the actual code. Having to go to the source sucks, of course (it's happened to me very rarely), but it's better than not having any source to go to at all, no?

"Where is the standardization in their IDE"? Since when were Windows IDEs standardized? As for the windowing API, X is about as much a standard as one can get. The widget sets on top of it are admittedly quite varied, but many of them are much (much!) more fun to code for than either MFC or the win32 API.

Anyhow, if you want to continue ranting, just email me. The address given is real.

Cross-Platform Support

[Detritus]

The article talks about the possibility of cross-platform support for .NET. Didn't Microsoft also say that DCOM was a cross-platform standard? It was supposed to be ported to other operating systems. I've never seen it running on anything other than Windows.

dotnet

[gmp]

Here is a paper that I wrote about a month ago on this topic -- Microsoft .NET (an antitrust perspective)

---

gmp

Doomed to fail

[autocracy]

Look at Microsoft's plan from this point of view. You've got two typewriters (one called Star which represents StarOffice, and one called Word, which represents MS Office/Word). The Star typewriter doesn't cost anything to put in your house, and costs very little for a business to put into place. Meanwhile, the Word typewriter has to be rented every time you use it. It's like having a payphone in your house. Also, the Word typewriter doesn't support the Star typewriter's native format, while the Star typewriter supports both the Word and Star typewriter formats (wierd typewriters, eh?).

Now, I am treating the software like something physical (a typewriter), but it's essentially physical anyway (or at least tangible - you've got it or you don't). Tell me, do you want to have to rent a typewriter everytime you want to make a letter? I'm pretty sure your don't. I think that you can figure out the rest from here...

Now here's where the REAL fun begins: Microsoft has to not only convince consumers to use .NET software, but it's got to convince programmers to write .NET software - which has its own programming language.

The article that this story is in reference to also states that Microsoft is planning to use the .NET server software to boost Win 2K sales. The infers that .NET server software will only be made for the Win 2K platform. That leaves some people on the other side of the wall.

Frankly, I can't find any real pluses to this strategy, either for Microsoft or consumers. And despite what the article says about this move helping to preserve Microsoft in the face of a breakup, I doubt it. If the person heading up the application side of the newly broken empire is business-minded, they won't restrict the .NET system to the Windows OS, thus shooting the whole plan to sell the Win 2K OS for .NET server software in the heart. And of course, .NET won't work out for the reason's mentioned above. I guess the question now is what will be the next dominant Desktop OS? Will it be Linux, a BSD, or perhaps Mac OS X? We'll see...

CAP THAT KARMA!
Moderators: -1, nested, oldest first!