ReactOS 0.3.15 Released 252
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.'"
Re:Why aren't there more contributors to this proj (Score:3, Informative)
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.
Linux has worked wonderfully on my desktop for over 10 years.
Re:Why aren't there more contributors to this proj (Score:5, Informative)
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.
Re:Why aren't there more contributors to this proj (Score:4, Informative)
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 [dolezel.info]. I get the impression it's very much a work in progress, however.
Re:Why aren't there more contributors to this proj (Score:5, Informative)
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.
Re:Why aren't there more contributors to this proj (Score:5, Informative)
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.