I feel like I can speak from unique stand point as I saw everything from the inside.

ROS is a lot of things, but one thing it is NOT is production ready.

From what I can tell, not a lot in the process has changed since I left. I am sure a lot of things code wise have changed but not enough to make a marginal difference.

One of the biggest issues ROS faces is the lack of testers. Since it can't be used a production OS very few people will actually test it. When I was there, we had 2 dedicated testers. For a whole operating system, that will not cut it.

Another issue is with driver compatibility. While it is true that it runs good on emulated hardware, it has a long long way to go before actual Windows drivers let it run on actual hardware. One small thing in the driver can cause everything to stop working. And with only ~20 active developers at the time, there is a finite set of hardware that can be debugged on. Not to mention only 3-4 of the 20 developers were skilled enough to fix issues with device drivers.

ROS is also fighting uphill battle by chasing Windows when Windows has 100s of developers working on it. I left ROS and worked for Microsoft for two years so I also know how much faster MSFT is going then ROS. Though, even if they got to full XP compatibility it would be one of the most impressive feats I have ever seen of open source, I just don't see it happening anytime soon.

And finally, the last main issue with ROS is the developers itself. There was so few dedicated, we only had ~30 people with write permissions. Of those, only 15 were active. And those 15 were all working in their own area. I worked in shallow (read: non complex) Win32 API and user applications (cmd.exe, control panel, etc...). But everyone had their own section they were interested in and they worked at their own pace with little to no oversight. You either need focus/vision or resources to make real technical progress on a project this large. Without one of those you have no chance. And ROS didn't have either.

All that said, I loved working on ROS. It taught me how to write real code and I learned way more from working on ROS then I did getting my degree. The people on a personal level were great, and some of them were the most technically sound developers I have ever met. Sadly, a whole OS is being carried on their back.

They could probably set up some elaborate automated testing with something like the Phoronix Test Suite, or just a bunch of scripts.

ReactOS 0.3.13 is still in under heavy development (alpha stage) and is not ready for everyday use.

It's a tremendous amount of work to make a bug-compatible version of Windows. Of course, I can't argue with people and what they want to spend their time on, but I sure as heck wouldn't volunteer to work on a Windows clone. It seems a big waste of some really talented people's (and I'm certain they're quite talented; getting this far is a monumental feat) time.

As for your statement about Linux and Unix being better thats far from true. There are many areas where Windows doesn't compete at all with those systems, but its also completely true that Linux and Unix is completely rubbish at certain things Windows excels at.

Like most things you should choose the OS that meets your needs, and for most people using a Microsoft stack, with Microsoft trained users, using software aimed at Microsoft platforms then this could be the answer.

Proof will be in the pudding of course, these guys are far from ready at this point, and are approaching the hard part of a project.

I don't know how things are in other countries, but here in Russia if you are not using windows programs for accounting (namely 1C:Enterprise), you're going to have troubles converting them for the federal tax service. This is effectively a microsoft/1C monopoly since 1C:Enterprise only runs on windows stack (there has been some success with WINE, but it is not supported, of course). That is why lots of small businesses use pirated windows and could benefit from development of alternate windows compatible OS like ReactOS.

They may be approaching the hard part of the project, just as the desktop is becoming irrelevant. It's already too late. It was too late when they started, but it's really too late now.

"Like most things you should choose the OS that meets your needs, and for most people using a Microsoft stack, with Microsoft trained users, using software aimed at Microsoft platforms then this could be the answer."

I don't see how it could be. It is a clone of Windows XP (a ten year old operating system, no longer supported by Microsoft). It runs on less hardware, works with fewer Windows applications, and works less reliably, than a Linux system with WINE (which I also don't consider a useful substitute for Windows in the context you're speaking of, but it's better than ReactOS currently, and probably well into the future, since it has more active developers, more commercial support, and smaller more obtainable goals).

Again, I think ReactOS is a solution looking for a problem.

    >Well from an outsider look I'd say the problem is the 
    >majority of businesses are running Windows and have reasons 
    >not to move off Windows.

This is not a Bad Thing. I certainly would say that MS has used some nasty tactics to gain dominance, but more power to them if they provide value to customers.

Personally, I don't see the value in the ROS project. MS provides a product that people use on servers and that's fine. The ROS team's calories would be much better expended helping Linux improve.

    > its also completely true that Linux and Unix is completely rubbish 
    > at certain things Windows excels at.

Is this anything other than application support?

To name a few.

The Windows API is standardized? I suppose, but only because Microsoft is the only one who ships anything even close to a complete implementation of it. So it's standard on the one thing that ships it.

I won't speak to if libc or POSIX is better or worse, but if they're going to be called "simple", the argument can be made that that's the UNIX philosophy, and a more valid critique would be if they were not simple and didn't adhere to the UNIX philosophy. Both Windows and Linux's libc/POSIX are solid APIs and are standardized, and the latter is largely documented where they diverge.

Linux supports POSIX access control lists. I actually find the Windows ACL support to be extremely subpar: the command line utilities are tough to use from cmd.exe, and the GUI for handling ACLs is brutal, albeit functional. The getfacl and setfacl Linux utilities are not super fantastic either, but they are there.

What's the qualification for a "nicer" driver system, that isn't better driver support?

Windows effectively has user-installable drivers and Linux, for intents and purposes, does not. In fact, Windows has the equivalent of apt-get for drivers -- a central auto-updating repository. Comparably, Linux is a backwards wasteland when it comes to drivers and driver management.

And, I'm not sure I buy that Linux is a backwards wasteland on this front. It has more drivers than current Windows versions, and more of my hardware, particularly stuff that's more than two or three years old, Just Works in Linux. I usually have to go digging on the web to find drivers for at least a few devices on any particularly laptop or desktop machine when I install Windows. That's usually only the case for more advanced 3D drivers on Linux.

Windows does have a more stable ABI (the last change, I think was from XP to Vista), while Linux does not. This could be argued to be a point in Windows favor. When the ABI changes, a driver on Linux has to be recompiled. This was historically defended by Linus based on the fact that the majority of Windows crashes are caused by 3rd party drivers...and Linus wanted Linux to be as immune to those poorly made 3rd party drivers as possible by making it hard for them to exist. Drivers in Linux, generally speaking, would go across Linus' screen (or at least one of his lieutenants) at some point, making it possible to insure a high level of quality and consistency in anything that ended up in a position of being able to bring a Linux system down. Linux historically has extremely admirable reliability because of this (and other factors).

The trade-off is that 3rd parties, like hardware companies, cannot release a driver and forget about it. A driver for Linux released in binary-only form today will not be useful in a year or sometimes even a few months. But, that's also proven to be true for Windows now that Microsoft has changed the driver ABI and raised the barriers to building drivers for Windows. A Windows XP driver is useless on Windows 7, so vast swaths of previously Windows-compatible hardware is no longer usable with Windows.

Linux also has apt-get (or yum) for drivers. When you update your kernel, you update all of your drivers to the latest version. Since drivers are tiny and disks are big, there's little reason to have them all packaged up separately. And, Debian/Ubuntu and RHEL have methods of distributing drivers separately from the kernel in package form. It's just rarely used, since so many drivers are included in the kernel.

So, I have historically found Windows to have better driver support, and it is occasionally more convenient to get hardware running under Windows than Linux. But, the gap has shrunk remarkably in recent years (nVidia and ATI both provide pretty good drivers for Linux now, and Intel has for a very long time), and lately I'm more often frustrated by Windows than Linux, since I have some older hardware that was quite expensive that I'd rather not replace (multi-channel 24 bit Firewire audio interface, for instance) that no longer gets driver updates from the vendor. It goes both ways, and I don't believe it is as cut and dried as it was even a few years ago.

I don't know what this means. GUI integration with what?

"- Standardized and complete API going beyond simple libc and POSIX (which are quite long in the tooth now)"

Gnome provides a quite impressive and modern GUI API, and so does KDE. SQLite has a great database API. MySQL has a great database API. OpenGL is a great 3D API (admittedly lagging behind DirectX, since few games target OpenGL to push it forward). SDL is a solid media API. There are great APIs for big math, low-level system constructs (Boost, for instance), disk and data, media of many types, etc. There's a library for everything in a Linux system, probably three or four of them. Just because they are not from one vendor does not mean they don't exist, or that they aren't good.

To insist that Linux and Open Source operating systems play by the same rules as Microsoft is to stack the deck in favor of Microsoft and Windows. Luckily, Open Source can opt out of that system, and build awesome things without needing a central commander to determine what is and isn't available. Saying that libc and POSIX are the only standardized APIs on Linux is like limiting yourself to only using applications from Microsoft; thus removing nearly all of the reasons to choose Windows. I have conceded that Windows has vastly superior application support...unless you're willing to say that Windows only has a couple dozen applications, because no others come from Microsoft, you can't ask me to give Windows the nod on libraries because they don't all have a POSIX or standards body approval on them (Microsoft doesn't get outside standards approval for most of their APIs either, while we're on the subject). A modern Linux system has vastly broader and deeper API and library support in almost every area. You may prefer Windows APIs, which is fine, but a lot of folks prefer the Linux options, and there's definitely a lot more variety in the Linux world.

Linux also has way more awesome and plentiful mobile APIs than Windows. Windows isn't even a contender in this space.

"- Access control lists"

Nope.

"- Nicer driver system and better driver support"

I disagree with the "nicer driver system" assertion, but even when we just take it to mean "better support for the most modern hardware", ReactOS doesn't replicate it, anyway. Driver support in ReactOS is vastly worse than driver support in any modern Linux distribution, which is mentioned in the article, where it discusses running ReactOS on virtual hardware, and the problems that come when running it on real hardware. ReactOS is also currently trying to replicate Windows XP. Drivers are no longer coming out for XP for the most modern gear, and new drivers don't work with XP, so even when they reach perfection in ReactOS and it can load all XP drivers flawlessly, they will still have much worse driver support than Linux.

I'll also mention that I lately have more problems with drivers on Windows than I do on Linux. I have a handful of older USB and Firewire devices that simply won't work with the latest version of Windows because the manufacturer isn't making new drivers, but continue to work fine on modern Linux versions. From my current perspective, Linux has much better hardware driver support...though if I were buying new hardware, I might have to check the web to be sure there's a decent driver for the hardware I want to buy.

But, this is all just a bunch of random Windows/Linux fanboy ranting about random ancillary stuff.

UNIX is a superior design at its core. The simple beauty of it is a thing of wonder. Windows, and its creaking DOS underpinnings (C:\, really? we still have C:\?), is a horrorshow by contrast. I made my assertion above based on the belief that anyone who understands both systems couldn't possibly come to the conclusion that Windows is the better OS. It may have more and better applications (it definitely does). It may have more and better drivers (debatable at this point). It may even have a few features that are better than the Linux equivalent (definitely, and the reverse is also true).

But, the Windows OS...the soul of the thing, particularly from the perspective of a software developer, is so obviously inferior to Linux or UNIX that I have a hard time even comprehending an argument to the contrary. This is a limitation on my part, I guess. I just can't comprehend a mind that thinks so differently from my own.

No, he means aside from applications, such as the games you mentioned.

Have you got an example?

I've built and maintained a Python distribution for Windows (Python Enthought Edition, which is used pretty widely in scientific computing environments) that had to work alongside other versions, and I also maintained a Linux version for RHEL/CentOS/Fedora. I would choose a Linux deployment every time. Not because I didn't know how to make it work on Windows; I did, and it did work quite well. But, because of how awful the whole process was.

There isn't even a standard mechanism for third party package updates on a Windows system. How stupid is that? Everybody has to roll their own updater if they want to provide automatic updates on Windows. It's like living in the stone age. Might as well hand out floppy disks.

And in contrast, the slightest annoyance on Windows confirms my worst feelings about Windows, and I give up quickly in disguest. For whatever (illusory) reason, Linux comes across as logical and an interesting puzzle that is worth the time invested, whereas Windows comes across as arbitrary and makes me feel like I've wasted my time.

Yes, it's a double standard but what can I say. At least with Linux, you can drill down as far as you want (and with Windows, I feel that I can't but it's partially a case of "Why should I bother, I can't see the source.")

> it's partially a case of "Why should I bother, I can't see the source."

I used to think this too.

Then I noticed that my Ubuntu 10.04 machine exhibits hard-lock like symptoms anytime I make -j. I know approximately what the problem is: the kernel scheduler isn't giving enough time to the UI while it does this, but, even with source, it isn't something I can fix trivially. Just reading the source and seeing where it happens doesn't do anything to make me feel better. It shouldn't ever happen. Period.

Try upgrading to the latest version of Linux (or just upgrade your entire Ubuntu distribution). This problem was fixed by a tweak to the scheduler that creates a scheduling group for each pseudoterminal. For that matter, you probably shouldn't use make -j anyway, since AIUI it just forks until it can't anymore, and doesn't pay any attention to how much RAM gcc/g++ is using. I use make -j [ncpus] instead, which is very nearly optimal (and is optimal with the BFS scheduler).

http://www.reactos.org/en/news_page_67.html

It contains much more information.

I expect Win32 MFC, ATL etc., will live on forever in some form, but Windows 8 sounds like it will be a break hard towards the future, in an even stronger way than the move from Win32 / MFC to .NET was.

http://www.computerworld.com/s/article/9219680/Windows_8_des...