Note that the Microsoft way tends to lead to another monoculture and to vendor lock-in. I'd say "of course, the same applies to the products of every other corporation", except that in my experience, everyone is using Windows on the PC.
Probably because I'm not a hacker from the 70s, when I discovered Linux (note a BSD variant would also have worked, had I known about them) it was a breath of fresh air in the ubiquitous monoculture that was Windows.
I run multiple monitors and multiple drives in my desktop, and generally one of those two things will lead me to pain when it comes to installation, or an upgrade cycle with the OS. I really don't like playing with my desktop for a half a day to get it running again when I'm trying to get work done.
Given, it's a lot better today than in years past, I just haven't had it in me to go to Linux for a month, only to have an update break something that will take hours to fix. That just doesn't happen as much in OSX or Windows.
I kind of wish one desktop platform would come to true prominence in Linux, and I care less about which one, as any one... then that one can get a lot better. I don't even mind gnome 3 or unity so much. I just want something that will keep working right through a few upgrade cycles... opposed to where I really consider not running updates on my desktop.
My last attempt at Linux for a primary OS was about a year and a half ago. I tend to get the bug to try it out every couple years. Eventually, I hit a wall a week or few weeks in that I just don't have time/patience to deal with.
PC-BSD was also a really nice option, but the limited VM options and support for current hardware really killed that for me. I think BSD fits my mindset better, but Linux has become more ubiquitous.
Either way, I would love to see a truly great desktop Linux platform for me. A power user and programmer who likes to tinker with stuff, but wants something that has an ok ui, that gets regular updates without issue. Most of the time, when I did update, it was more for something I wanted to play with other than the main OS.
Also PC-BSD is working on a BSD-specific desktop called Lumina. It's at an early stage of development so not yet clear how well it will compete with established DEs.
It will be interesting to see how far Linux goes with Wayland, said to be a replacement for X. If X becomes deprecated on Linux, probably BSDs won't travel that path and stick with X, which means X development will be more or less up to the BSD projects. Just my speculation about these things.
What I'm waiting for most is completion of FreeBSD UEFI support, including Secure Boot. Once that's available it should make dual-booting FreeBSD+Windows much easier--a great option to have.
It will be cool to see what happens in the next couple years though.
I tend to simplistically reduce this choice between:
- Everything is a file (the unix way); and
- Everything is an object (the windows way)
Both choices have the potential for great results. In practice, however, the documentation and composability in the everything is a file paradigm has shown to produce better results. Unix ecosystems are more alive; it is easier to replace system parts and create operating systems out of your own choice of replaceable layers. The monolithic nature of Windows is a reflection on the failure of the object oriented approach to operating system interfaces.
Mind you, I don't think it is an intrinsic fault. It may be that it's a fault of this implementation of an OO operating system.
This is the main reason I dislike what the Gnome folks are pushing down Linux's throat. The Gnome way is, today, at odds with the Unix way.
> It may be that it's a fault of this implementation of an OO operating system.
I'm not convinced it's just this implementation. When everything's an object, there's additional overhead as a programmer trying to use the API.
File based API - Open a file using the same 'open' call you've always used, and then call 'read' or 'write' (or even 'ioctl') on the file descriptor. Call 'close' when done. There may be multiple files you need to access to get the particular behavior you want.
Object based API - Browse around the docs until you find that particular subsystem's API. Read a bunch. Finally instantiate the object you need. Set all of the objects various properties. Call CreateObject(object, options). Wait, go back and create a options object. Set all of the properties on that object as well. Try that until you figure out you needed to call CreateObjectEx instead. Hit your head on the desk for a couple hours until you figure out that you also need to call RunObject, and that one of the parameters on the options object was set wrong.
As a programmer, the file-based API is just a layer of indirection to make things easier, and shouldn't be considered a limiting factor.
Then again, there's this article about Event Tracing on Windows, that makes me think it's just this iteration of OO-based operating system, and a better designed API would do us all a favor.
Until you start doing IPC between processes, IOCTL, heavy graphics programming and there goes the abstraction.
- You can do anything you want with anything (objects)
- You have a discrete set of file operations. (files)
Though, I hate the "paradox of choice" and I think I am saying it reduces to that. :(
* data accesses (read),
* data mutations (write, trunc),
* metadata accesses (readdir, closedir, stat, statfs, readlink),
* metadata mutations (creat, mkdir, link (and symlink), unlink, rmdir),
* interaction contexts (open, close, opendir, closedir),
* namespaces (mount, umount).
I would argue that any object (OS-level or otherwise) can be represented as a filesystem. The advantage of doing so is that the client interface stays the same in all cases. I think it's this constraint on the interface that makes file operations and filesystems so appealing in the long run.
Very similar to the REST versus SOAP/whatever paradigm. Neither one should be more capable than the other. In fact, REST should be the more restrictive choice. Right?
Plan9 window manager is not an example of performance.
For data in /scenegraph/, SceneGraph_fs would accept well-formatted writes to a node's files as a means to update the node in the scene--for example, to translate the node, you would write a new matrix to the object's positional matrix file (the write() would return EPERM if the matrix was malformatted). To create or modify an object atomically, you could describe it under /tmp/ in SceneGraph_fs, and rename() it into place. You could manage lights and lighting data in the same way.
Of course, the graphics card interfacing happens in filesystem implementation. But, the application interacts with the scenegraph as a filesystem, not as an object.
I wouldn't say there is a "Windows way", considering that current Windows is actually a system composed of several different layered components:
1) The NT kernel (which is pretty nicely designed) its own ideas of what "objects" are and all the ObXXX functions.
2) Win32 which is a horrible mess from the Windows 3.1 days and maybe earlier.
3) COM and flavors, which actually came later with its own brand of objects.
4) The .NET framework.
It doesn't seem to me that "Windows objects" are really unified in spirit and design across all these components (not to mention that Win32 isn't object-oriented at all).
As to "a bunch of nice ideas", I'd suggest you take a look at the concepts that Plan 9 from Bell Labs brings to the table. The everything is a file concept there is something I wish would have taken over the more classic approach to devices, networking, etc. Want to open a remote shell on another server? Easy as opening a file handle. Accessing the CPU and running programs? Same story. Now if you call that just a nice idea, I rest my case ;-)
Microsoft even explored some of those concepts in their research OSes like Singularity and Midori. There has to be something about those ideas that they appeal even to MS, that's just my view though.
We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
We're still wrapping our heads around decades-old ideas. We can be sure software development is finally a mature field when we're unflinchingly using 100+-year-old constructs because they've withstood the test of time.
One of my favorite fields, DSP, leans on math from around the turn of the 20th century. Far from shameful, I consider that a win for mathematics.
What is Windows doing differently than UNIX monolithic kernels? Drivers and filesystems run in NT kernel space.
- Exposing an OO ABI (COM, WinRT)
- Moving beyond C for systems programming (C++, .NET Native, Sing#)
- Experimenting with new OS architectures (Singularity, Drawbridge)
- Continue the multimedia OS culture of Atari ST, Amiga systems
Not sure this matters given the extreme low-level nature of kernel and driver coding. Certainly not enough to warrant a rewrite, which I guess is a result of Microsoft more or less dropping support for modern C in their compiler by not even supporting C99 fully.
>Experimenting with new OS architectures
Certainly Singularity was an interesting experiment, sadly and typical of Microsoft mentality, once they ruled it out for production use and passed it off for others to play with, they chose to do so under such a restrictive license (shared source) that no one will do something interesting with it.
As for drawbridge, the same ideas regarding sandboxing are being worked on in the Linux camp, and from what I understand also in solutions like Capsicum on FreeBSD, from the looks of it, *NIX is way ahead of Microsoft in this area.
>Continue the multimedia OS culture of Atari ST, Amiga systems
Not sure what you mean here unless you are talking about coming with a GUI out-of-the-box ?
Your typical current Linux distro is more of a 'multimedia OS' than Atari ST or Amiga ever was (owned them both), which includes BeOS, the one which actually carried that moniker.
To add on to what a previous commenter said, Plan 9 is proof that Unix's nice ideas are more than a few. In fact, the ultimate irony is that some of the most fascinating OS design has emerged from being more Unix than Unix itself.
Plan 9 has also become pretty much the only breath of fresh air from an architectural standpoint in Linux, what with procfs and all.
I seriously doubt I could use such abstractions for high performance 3D computing.
lol
The proof you could have an workstation OS written in a GC enabled systems programming language.
I cherish Microsoft for its work in Windows, it is the only mainstream OS that can save us from UNIX monoculture.
Yes, UNIX has a bunch of nice ideas, but that is all.