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?
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.
Give me Classic Slashdot or give me death!
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.
Don't know about you, but I've been using Linux exclusively since 2007, and it is on a desktop computer. Personally I've been pretty happy with it! Can't afford to buy Photoshop, MS Office and all the rest, so I use what is available in the Repository and seem to get by pretty well!
And that's different from a Linux framebuffer driver how?
It's obsolete, due to virtualization.
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.
I applaud what the ReactOS guys are doing and wish them the best of luck, but on the other hand I believe they have chosen a very difficult path.
Linux is free software, which means that you can inspect the source code and prevent it from crashing the kernel.
He means a relevant number of desktops, not three chucklefucks in their basement.
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, and I don't have anywhere near the level of systems programming experience needed to start it.
I can't stand the interface of OSX; it's even worse than Windows 8, and everything is in the wrong place and none of the shortcuts and gestures wired into my brain and fingertips work right. But with a compatibility layer on Linux, the apps could be run while allowing the desktop to be customized fully.
One thing that is absolutely non-negotiable, though, is that the font rendering needs to be fixed. In its current state, it's uttterly atrocious, the worst I've ever seen on any OS. The Microsoft core fonts expect aggressive hinting and snapping to the pixel grid, and Linux doesn't want to cooperate.
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.
And AutoCAD and Photoshop are the easy ones. They have a wide audience and it's generally understood, at least in a broad sense, what they're supposed to do and why it's important. Good luck rewriting a million different industry-specific niche applications for Linux. Better luck finding the coders willing to volunteer on obscure projects that neither they nor anyone outside the industry in question cares about.
Ok boss, I need a few million bucks to have some guys write a replacement for this $5000 a year software. Or did you want me to just buy windows 8 and the software?
You use the word "rapid" to describe Windows' deteriorating use. Tell me, on a scale of "Watching grass grow," to "Why did the snail cross the road?" just how rapid are we talking here?
I'm not about to argue that Win8 is anything but a train wreck, but claiming that Windows' position in business is rapidly changing is a bit.. well.. dead wrong... Sure Win8 isn't being adopted in droves as MS might like, but of all of the WinXP-Win7 users who *aren't* upgrading [sic] to Win8, I don't imagine terribly many of them are jumping ship and moving to Linux or Mac. Some yes, but I doubt it's more than background noise on the stats.
Even if Microsoft didn't see a single new Windows license this year, their market share isn't in any immediate danger. (And by "new license," I mean an actual new person who wasn't using Windows before. Replacing an existing Winbox with a new one and paying the Microsoft tax or changing the installed Windows version on an existing machine doesn't effect the overall number of people using Windows and buying software to run on it.)
And perhaps worth nothing, this relatively MS-positive post was brought to you by a Mac user...
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 ?
Back in the 1990's I was really excited about this project. I really hated how Microsoft had a strangle hold on the entire industry and there was no sign that it was going to change anytime soon. This project was promising in that it really offered a possible solution. But they're about 13 years too late. Far too little progress has been made. Microsoft has already been knocked off of its pedestal and now there are viable alternatives that consumers are embracing. Specifically, MacOS, IOS, and Android devices. Linux is still a niche for desktops. And the browser is really the thing that killed Microsoft more than anything else.
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
But there are limits on what ReactOS can do - and pretty serious ones. For one, it can't use NTFS w/o violating Microsoft patents, so fat chance seeing a modern filesystem on it.
I have previously suggested that the project be split into 2 or 3 parts - one win64, another win32 and a third win16. Have the win64 project aim at Windows 7, and target 4GB of RAM. Have the win32 aim at XP, and target 256MB of RAM and above, and for the win16, try something like a 16-bit thunked version of it. The goal of the win32 & win16 would be older boxes, and it should aim at being compatible w/ any win32 drivers, be it XP, NT, 2000 and so on for the win32 spin, and w/ Windows 95 for the win16 version of it.
But to those who've been claiming that ReactOS has a moving target, no it doesn't. Already, most people are finding Windows 7 good enough, but Microsoft wants to take us to 8. So here, a 64-bit ReactOS would be perfect.
Oh, and some long term suggestions (for an OS that's taken eons to develop that make it the envy of HURD). Make the user interfaces of all the versions that Windows ever had, and make them selectable regardless of which OS is underneath. In other words, a win64 version of the OS could have the classic NT 3.5 interface, or a win16 version of the OS could have the XP interface - just the same way Linux guys can pick DEs. In other words, decouple the user interface from the underlying OS, so that people can pick & choose the best of all worlds.
The other thing I'd suggest - some of the modern OS features, such as IPv6 support - make them available to all the OSs. Also, they could take NTFS, make the 32-bit file system 64-bit, and then make that the file system for the OSs. That could enable them to sidestep the patent issues, and things like it. Also, I'd like it to be ported to some other CPUs other than just Intel - not just ARM, but MIPS and PPC as well.
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.
Because using Windows requires you to buy Photoshop and Microsoft Office? Since when?
The catch-up argument no longer holds. The current project is aimed at XP, and once it's done, they'd have a mature win32 OS that can address all x86 boxes. If they do a follow-on project that is aimed at Windows 7 and uses win64, that's all they'll have to do. There won't need to be a Windows 8 based OS - Windows 7 will be good enough. So future libraries that Microsoft introduces will be irrelevant.
The legal hurdles can be real, though, but since this project points out that it does not use any MS source code but just their published specs, they have nothing to fear there. The parts that are patented and blocked, such as NTFS, they're not doing.. But the project does have good reasons to work, but first, they need to properly staff that operation, give themselves deadlines and stop treating it like they have all the time in the world.
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!
The kernel was designed with security and multiuser in mind, but the ui and apis on top of that were not and thus neither were a large number of applications. You have a lot of areas where things were obviously kludged in at the wrong level and are thus easily circumvented, eg see group policies such as command prompt restrictions.
The security model may well be more sophisticated, but more complexity is NOT a good thing. There is a reason why the vast majority of linux users do not use selinux, and that is because the overhead of learning and maintaining it outweighs the benefits in most cases.
A simple security model suffices for most use cases, is easy for people to understand and likely to be used effectively...
A complex security model either gets in the way (and thus people find ways to circumvent it like running as admin) or the complexity causes people to make mistakes when configuring it (often because its too complex to understand) and thus introducing new holes.
Look at the way services are run as unprivileged users... On unix you just setuid(), which is simple and seemingly insecure... On windows you must "authenticate" as that user, which means storing the user's password on the system. End result? Either programs don't bother, and run as system, or they leave a password easily obtainable from the system (which may be valid on other hosts, especially if your using a domain user).
Similarly, many of the windows networking protocols let you authenticate with the password hash, as such the hash is the equivalent of plaintext so the passwords are effectively stored as plaintext on the host. Compromise one host, grab hashes, attack other hosts.
You can also extract plain text passwords of currently logged in users from memory...
So overall the linux security model is MUCH better... You have a simple model that the vast majority of users can easily understand and use effectively, and a complex model that can be used for those specialised niche cases.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It has no chance of dethroning Windows. Zero. Zip. Nada.
Look, no one will ever be as good at being Microsoft as Microsoft is. ReactOS may be eventually be 99 44/100 % Windows compatible. It may look like Windows, feel like Windows, and act like Windows almost all the time--but it won't be Windows. And sooner or later, anyone running it will run into some instance where Windows does this but ReactOS does that. Now, when this happens (when, not if) developers will say, "That's interesting, we should fix that." But regular users will think, "Serves me right for trying to use this cheap knockoff. Guess I'll just get the real thing." And if anyone asks them about their experience with ReactOS, that's pretty what they'll say.
That's exactly why Linux failed to replace UNIX. A knockoff can never succeed.
A knockoff that's competing with a family of OSes that aren't 100% compatible with each other at the source level, that run on machines that are typically more expensive than the primary class of machines on which the knockoffs run and that don't even have the same instruction sets as each other (so that binary compatibility is out of the question), and on which a lot of the software is either open-source or written in-house so that it can be compiled and run on the knockoff, could succeed.
A knockoff that's competing with a single OS that has a ~90% market share and that has a huge collection of binary-only packaged applications that might depend (explicitly or implicitly) not only on documented behavior but also on undocumented behavior is a different story.
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
Why should anyone care about making an open source Windows now, anyway?
Because Windows owns the business world, most of the power-user world, and most of the PC gamer world. If you want OSS to make any inroads on the business desktop or with gamers, it has to run their software on their terms. And that means Windows binary compatibility.
Which is why we have WINE -- we want binary compatibility, not the ability to load up an entire OS that looks like Windows 95 and behaves like Windows XP.
IMO, WINE got it right; it provides a compile target for developers who don't want to re-develop for Linux, and a runtime wrapper for developers who don't even want a Linux build. Plus, WINE itself is platform agnostic, so it'll run on any POSIX compliant OS (read: almost every OS that isn't Windows, and even Windows for that matter), providing binary compatibility to everyone, not just the adopters of a particular distribution.
Of course, WINE and ReactOS have an interesting co-dependant relationship; ReactOS is a great platform for testing stuff out before it gets rolled into WINE, and that's the reason I'm very happy it's still around (even after the whole source integrity issue a few years back).
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
Wine is binary-compatible with many Windows applications. ReactOS aims to be binary-compatible with both applications and drivers. This way, printers with no CUPS driver and scanners with no SANE driver will still work.
Windows RT doesn't run legacy Windows software. It doesn't have an x86 emulator. Nor does it even allow developers of desktop applications to recompile them for ARM; the only desktop applications for RT are IE and Office.
But the user would still see ExFAT and NTFS formatted removable media failing to mount.
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.
I think the point here is that the design isn't broken because you *can* do so. The system will still be functional enough to allow someone with the right knowledge to fix it (remotely if need be) and in situations where this matters, people with the right knowledge are a phone call away and would not need to move to fix it.
If a linux box has a borked gconf, some dude across the world can make it magically boot a few minutes later. Not to mention that the user can only bork *his own gconf*.
If a windows box has a borked registry, you need a human with some level of technical skill at the computer or to pay extra to have some sort of lights-out management built into the computer which is no excuse for poor design.
Mind the frickin' laser...
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.
Absolutely not. Read this and understand it (first link I found that was useful): http://www.cs.rochester.edu/u/cli/research/switch.pdf
From the summary: "In general, the indirect cost of context switch ranges from several microseconds to more than one thousand microseconds for our workload."
If you can skip that "several microseconds to more than one thousand microseconds" blip, you will get MUCH better performance. That is why graphics drivers are in the kernel and why you can NOT say that you can ever get high performance user space graphics drivers (under current architectures).
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
Not to mention everyone is ignoring the elephant in the room, the reason why Linux has never stood a chance...Windows software.
There is ALWAYS some "must have" piece of software that Linux doesn't have any alternative to or the alternative is poor, and as long as that is the case you can just give it up. the FOSS community has acted like all you need is a browser and Office but even my little old lady customers have software that they simply won't do without, and its pretty damned obvious by now that Linux is NEVER gonna get enough marketshare in its current form to get all that software ported, its just not gonna happen.
So if the FOSS community really and truly wants the world using a FOSS OS? Then get behind ReactOS, because that is pretty much the only shot you have of dethroning Windows on the desktop. Hell you make it stable so "update foo broke my drivers" or even better if supporting windows drivers isn't a problem I'll be happy to stock my shelves with ReactOS boxes and laptops, and I bet I'm far from alone. I really get damned sick of the FOSSie faction saying I don't want Linux to succeed or that I'm working for MSFT...do you have ANY idea how badly they fuck us system builders over? The OEMs get Windows cheap enough they can pay for the cost in trialware, us system builders have to pay the same price the average Joe pays and it fucking sucks. Don't you think I'd rather sell systems without that high as hell cost of Windows dragging like a boat anchor behind it? I'd even be happy to pay say $20 a pop for each copy of ReactOS, sure beats the wallet raping i get from MSFT.
So c'mon FOSS community, get behind ReactOS. You get the code you are always wanting, we system builders get an OS that doesn't bleed us dry, the consumers get an OS that runs what they want to run, hell you could even have a dialog box pop up pointing out a FOSS alternative to this or that software when the user first goes to install if you want to wean them off of non FOSS, its a win/win for everybody.
ACs don't waste your time replying, your posts are never seen by me.