Slashdot Mirror
ReactOS 0.3.15 Released
Beardydog writes "From the ReactOS.org bulletin, 'The ReactOS project is proud to announce the release of version 0.3.15. A culmination of over a year of development, 0.3.15 incorporates several architectural enhancements to create a more compatible and conformant implementation of the NT architecture. Perhaps the most user visible enhancement is initial support for USB devices, both storage and input.'"
ReactOS is a project to build a free, open-source clone of Windows, compatible with both drivers and userspace software. Why on earth hasn't this received more support from the OSS community? It's the only realistic chance of dethroning MS from the desktop in favor of an open alternative. Linux is fine for servers, portable devices, and embedded systems, but trying to stick it on the desktop is a foolish dream that has failed for over 10 years.
In what way is it broken by design?
You have no desire to run Windows until the moment you get a job in an industry whose standard applications are unavailable for GNU/Linux and rated "garbage" in Wine AppDB.
You're missing the point of ReactOS. It's like Wine, except actually an OS. If one day Windows bites the dust you can have this project for any legacy code, if you really needed to run something, and it could be patched and maintained forever. To be fair, yes this is a hobby OS, but to say that with disdain diminishes the value of a hobby.
Good luck creating a replacement for AutoCAD or for the parts of Adobe Photoshop that GIMP doesn't replace using only hobbyist labor.
Linux is free software, which means that you can inspect the source code and prevent it from crashing the kernel.
The graphic routines reside in kernel space?
An absolute necessity for performance reasons. They tried doing it in userspace in NT4 and it just couldn't keep up.
the drivers can kill the kernel?
Windows 7 moved a lot of drivers to userspace. Yes, some code will still be run in the kernel. Some code is run in the kernel on Linux. The solution is for that code to be written well, not to give up and pretend that kernel mode doesn't exist.
The registry gets a lot of hate, but I don't see how it is worse than the alternative, which is tons of different .ini files (or equivalent) for each application and setting. At least on Windows, it's generally understood that settings should be exposed in some way in the GUI and that for all but the most advanced features, saying "go edit the registry" isn't really a good solution. On Linux, forcing users to manually edit config files is routine.
Well yes, but at the same time I only use Windows for one thing nowadays: running it in a virtual machine under Linux so I can run 3 programs that have no equivalent under Linux. If those programs work under ReactOS, I'll use that in a heartbeat. They must understand that beacuse the provide an already made VM among the downloads.
Non-Linux Penguins ?
To be fair, yes this is a hobby OS, but to say that with disdain diminishes the value of a hobby.
Nice point. Amateur means "one who loves" (literally), it should never be disparaging to be called an amateur. Hobbyists are "amateurs" by definition. All the great Renaissance thinkers were amateurs across a wide range of fields, but often to great depth. Hence we owe much of modern thinking to amateurs.
The registry gets a lot of hate
Yeah. And then those same people who keep hating windows registry go and implement the same thing for Gnome, in a even more crappy way than windows did.
Gnome is, AFAIC, the current bane of Linux.
morcego
Actually, many Windows drivers now run in user-space where they don't even need to context switch, while Linux runs many drivers in the kernel space.
And its entire life, started as a single-user system, means the whole damn thing is broken as far as multi-user goes.
That was only true of Win9x, and the last version of that was discontinued about 10 years ago. Windows NT (which includes 2K, XP, Vista, 7, and 8) was built from the ground up as a modern, multi-user OS with full support for security built in. In fact, the NT security model is slightly more sophisticated than the Unix model (though not as good as SE Linux). Both do share the same flaw: from a security POV, the program is the user and can do whatever the user wants. This is something Android got right, granting permissions on a per-app rather than per-user basis.
A lot of people ignored the NT security provisions up through XP by running as admin all the time, but UAC mostly killed that. People hated it, but it gave the developers a much needed kick in the butt to stop breaking stuff by requiring root.
I concur. Insofar as the registry removes the need for a metric crapton of config files, I am in favor of it, but it stops there. The manner in which they implemented it and documented it has turned it from something potentially useful into something even worse than 200 config files.
If they had done it right, they could have standardized good practices, and even allowed for the creation of useful configuration management utilities. Since they didn't do it right, it's just a pile of confusing and useless crap that you can't avoid.
If there was a compatibility layer to run OSX applications on Linux, that might actually be a viable option. OSX has most of the big things people want: MS Office, Adobe Photoshop and friends, AutoCAD, etc. Conceivably, such a compatibility layer could be easier to write, debug, and maintain than WINE, since there is a lot less legacy baggage (and the underlying architecture is much closer to what Linux expects). But I am not aware of any such project so far
Well, there's the Darling project. I get the impression it's very much a work in progress, however.
You are not forced to edit config files any more often than windows forces you to make manual registry changes...
The primary reason that technical people will choose to edit config files instead of using the gui is because it's much easier to explain in either a textual (website, forums) or vocal method. Telling someone to transcribe what you're talking about is infinitely easier than trying to explain over the phone how to navigate a gui, and in a textual medium you can even include examples which the user can cut/paste.
Also text based config files usually have comments where you can explain why you made a change, or where the authors of the program can explain what settings do and give examples. The registry has nothing like this.
Text based configs are also very easy to back up and store in a revision control system, that way you can roll back changes, see what/when changes were made etc.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Linux has a macro kernel... all the drivers are part of the kernel and run in kernel in kernel space...
Linux is currently a mix of macro (monolithic) and micro kernel concepts. Not all drivers run in kernel space. I'm sure you were remembering the old Linus vs. Tannenbaum disagreement when you wrote that one.
Regardless, the focus of this discussing is graphic routines which, except for a few proprietary cases (most notably, nVidia), run in userspace. Which is one of the problems people have with the proprietary nvidia driver (another is it not being free, but w/e).
So, anyway, not ALL drivers are part of the kernel, more and more are moving out of it as time goes by. But yes, many drivers still are. Our Minix legacy.
morcego
Careful with those arguments! They're antiques!
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Hummm, what?!?! You know it is the same computer, right? If it is killing performance, then the scheduler is fucked. Another proof windows is broken.
Nope. The problem is with the cost of a context swap. When usual kernel code executes, the code still executes in the context of the current process. There is no MMU context swap, just some registers get saved to stack, and the protection level is changed. When you run it in a separate process, you not only to invoke the scheduler (which isn't invoked when you merely do a syscall), you have to swap out the entire MMU context. This is very expensive, and only gets relatively more expensive compared to running code with more advanced processors.
A successful API design takes a mixture of software design and pedagogy.
The code that managed context swapping is part of the scheduler, at least on Linux. Yes, it can be costly, which is why it needs to be implemented correctly, and why you keep getting alternative schedulers (not as often as you once did, it was crazy back in early 2.0). There is classic problem with Intel-HT and Postgresql that caused context swapping for database I/O to be extracostly, as you probably recall. And it can be done correctly, as was proven in this case, and then again for Oracle.
It is absolutely possible to have high performance userspace graphics, as was proven with some of the more up-to-date drivers. I think it was ATI that first did it, by the way. The trick is to keep as much as possible in userspace, but that requires a change in mentality for developers.
morcego
If he keeps coming up with terms like "chucklefucks" I heartily encourage him to stay under whatever rock he's stuck under. That was worth reading this entire flamewar thread right there.