ReactOS
reactos.org
reactos.org
That said... I firmly believe there is a place for ReactOS. Eventually, XP will fail to run on new hardware, and when that happens a lot of great software will die also. Having ReactOS around means we can continually target new hardware, but still remain XP compatible.
Personally, I view software like I do books. We can read books written 100s of years ago, but we struggle to run 10 year old software. This has to change, else we'll endlessly repeat ourselves rewriting the same programs over and over again.
Wholeheartedly agreed and it's also why I have so much respect for Microsoft and the backwards compatibility they've achieved in Windows.
Thats usually the case in company driven projects but not necessarily in community driven open source projects.
If you would be the project lead and a person comes to you and tells you that he would like to create a newer modern theme. If you tell him/her no and that he/she should work on something completely different i wouldn't be surprised if you would never see him/her again.
Doing this is ok. We are also rewriting the same books all over again. Knowledge is forgotten and reinvented and rediscovered. You see this in computer science and programming all the time, but also in other fields. Rather than the programs themselves, preserving the concepts and learnings is much more important. Don’t get me wrong, I think vintage computing is great, but we shouldn’t necessarily solve todays problems with it.
It has the same problems: the historical context is imperfect and very tedious to understand (for those who even try). Reinventing the wheel is always easier, cognitively (perhaps while being vaguely cognizant of how there was a Roman Republic that fell to dictatorship that then fractured into hundreds of apocalyptic Christian fiefdoms and how there was an incident with this thing called Therac-25 [and maybe crystallizing that cognizance in proper government standards for medical software]).
Also, since the bottleneck is brain bandwidth, it's not helpful that old code is written in old languages which were formulated in a time where the most salient bottleneck was memory/processing speed.
No because most knowledge is tacit in nature. Things needs to be practised to be really understood. We're not living in the matrix where you can upload knowledge into your brain, you need to actually practise something to understand how it works.
Not to mention that all knowledge is contextual and dependent on its environment. Doing the same things over again in a different environment may yield different results, old failures, through tiny changes may turn out to actually work now. That's what makes constant experimentation and repetition necessary to rebuilt robust systems.
that's why markets are more effective than central planning, and why evolution is the most robust mechanism on earth. Having twenty companies build the same product is more wasteful than having one committee do it, but only competition, incremental change, and reinvention really are able to explore the entire space.
These will most likely never see another printing, granted. But generalizing across all books published this way, I'm sure this situation will actually arise in the future.
To the ReactOS devs: what's the deal with the last couple years of GSOC projects? Why is there little to no work going on to improve compatibilty?
Why are you asking this here in the HN comments section? Maybe communicate directly to them through a means of contact on their page. Why "grill" them on their progress? Maybe go invest in the project yourself.
This just comes off as lazy criticisms. It's not like GSOC is your money, nor does Google "make it rain" with their stipend.
There are a qute a lot of pretty ideas https://reactos.org/wiki/Google_Summer_of_Code_2020_Ideas
The problem is in lack of students ^)
This is why a versioning system is being implemented right now to allow applications targeting NT 6.x to use newer DLLs/APIs not available under Windows XP. Check e.g. this recent PR from a few days ago for details: https://github.com/reactos/reactos/pull/3239
Fuck yeah! That's a solid engineering decision.
Thanks for the response and keep up the extremely impressive work!
Personally I'd be more interested in ReactOS as a way to run current software without microsoft, as I think they have really started behaving unacceptably with windows 10.
You're not wrong. However I think that the appeal of ReactOS (in part, and if it was more stable) is that it's currently updated and (in theory) can be secured against modern threats; so you'd be able to put it on a network -which would be masochistic to do with Server 2003 at this point.
I could also be modified to run modern Firefox, chrome, etc which 2003 cannot.
If a company buys a red team test, a Windows XP machine without networking has a different threat model than one with.
Also, Wine on Linux might be better option if its just one incompatible application (with or without networking).
In short I would say both (or rather, all three) have their place.
I agree with you, and I think that using WINE on Linux probably gives you more options than using ReactOS.
But in terms of what is appealing about Reactos is that (in theory) you'd have the option of modifying it, and it being (again -in theory) compatible with 2k3 server so that putting it on a networked vm could be an option.
I can't think of a use case for it, and I'm not sure that there's a compelling amount of ~17 year old hardware needing drivers -but it still has it's appeal (IMO).
But by and large you are right -most of the time it's better to either use a supported windows version or to use WINE on Linux.
Unless you're talking about running it on a computer that's not networked, it's already impossible to run XP safely. But Windows is really good about backwards compatibility--what XP software is there that doesn't run on Windows 10?
https://www.win-raid.com/t4035f45-Windows-XP-Bit-and-Server-...
After i have found this, i m not sure that xp will ever die
Do we? Virtualization and emulation usually sort this out. 8- and 16-bit console games are a good example of this.
There are a great number of games that cannot be played by most 16-bit and 8-bit console emulators. The Famicon disk system, for instance, is a real struggle to get working right.
90s machines are dying off rapidly, and hardware is becoming very very scarce. Much DOS software, for instance, requires very specific hardware timing and behaviors that is either not known about or still emulated wrongly. Worse, some emulations simply don't exist or are very difficult to get working (see also 3DFX Voodoo3 8-bit paletted textures).
2010 machines are next on the chopping block. Though tose systems may be easier to deal with hardware wise, emulation will still be a challenge.
I'm not sure, but I believe that both support the 3DFX Voodoo (not sure if just "VooDoo" or "Voodoo3").
It's a volunteer project. Be the compatibility initiative you want to see in the world.
Data is more akin to the knowledge in books.
As long as we can read 100 year old data sets we will be fine.
Truly important software will adopt new technologies while old technologies will fade away.
There aren’t many 100 year old roads that exist without being regularly rebuilt. Surely none with any regular usage.
Example: https://reactos.org/project-news/victor-perevertkin-hired-fu...
Donate if you have some spare dollars https://reactos.org/donate/
Apply for a job if you are a C\C++ developer https://reactos.org/contributing/#paid-jobs
But it seems that an Oracle win would mean you couldn't implement any interfaces compatible with another piece of software without a license.
We should introduce you to Oracle. This is exactly what they do. They audit their own customers in a very hostile way.
Never underestimate a company in decline, as they grasp for ways to increase revenues and profits for shareholders (or founders)
Android isn't fair use, is a massive commercial endeavour, and has obliterated the value of mobile Java, while breaking interoperability with Java. Oracle winning the case will not be kind to stolen platforms by tech giants.
https://en.wikipedia.org/wiki/Fair_use#U.S._fair_use_factors is a really good read for the basic understanding of how fair use should be applied. Factor four is what we're discussing here, which the Supreme Court labeled the "most important" factor.
This is true. However, bear in mind, Google argued that 1. APIs weren't copyrightable and 2. that if they were, their usage was fair. In this ten year court nightmare, they've lost fair use and of course, are likely about to lose on copyrightability.
If the Supreme Court rules for Oracle, Android is copyright-infringing, it's already failed on the fair use claim. But most non-commercial projects would still have a fairly compelling case for fair use.
Note that your "copied a book" analogy is poor for a bunch of reasons: Chapter headlines... are copyrightable. (Though the "amount of work copied" is a fair use pillar, so it's possible to lift chapter headlines fairly.) And it fails to account for the functional nature of APIs which is under debate for copyrightability.
You mean was copyright-infringing. Harmony was dropped years ago, and Android has been rebased onto Oracle's own anointed, conflict-free codebase.
And you dodged the previous question where the commenter was asking for an honest assessment of mobile Java. You responded to a question that wasn't answered by talking about being unable to undo the past—which only makes sense if they had been pressing you for an answer to what would happen if Google called it a wrap on Android today, but that wasn't the question. Which brings us to another thing.
People who complain about Google's use of the Java APIs can't seem to get their arguments straight. That includes Gosling + the subset of the Sun/Oracle fan club who sat on the stand during trial + and the perennial commenters who parrot the same talking points on Hacker News. They (you) all complain about Android ripping off Java (to the tune of a multi-billion dollar copyright infringement lawsuit), but invariably the argument comes around to the real thing that's bothering them and which they try to wrap up in a bunch of claims about infringement—and what's actually got everyone (besides the money grubbers) fuming is the intentional incompatibility—in other words, that Android didn't copy enough! You wanna try squaring that circle? Which brings us to another another thing.
Android today is now based on the "proper" codebase, as mentioned above. How? Because it's open source. And it's been open source the whole time. It uses a different open source license, but it's open source nonetheless. Which means no one actually ever needed to get Sun or Oracle's permission to do anything. All the incompatibilities of Android? There's nothing that keeps the same breaking changes from being made in our hypothetical world where Android used the blessed license instead of the one from their preferred implementation. That difference does not suddenly force the hand of Google—or anyone—to keep dragging around Oracle/Sun's failed attempt at a mobile platform and maintaining compatibility with it.* It's GPL. Modifications are allowed. So reset from the beginning, bypass the Harmony detour, and everything still plays out exactly the same. Sun's platform still starts off where it was the whole time, in the gutter, and in that vacuum, Android becomes a thing, with incompatible APIs and all. And Oracle's infringement angle now disappears completely. Even if you're deluded enough to tell yourself that the platform Sun cooked up had a real shot (it didn't) before Google "obliterated" them, the market looks the same as it does today in favor of Android. So how much of those imaginary losses are actually the result of any infringement? I'll fill in the blank: the answer is none.
* Which is another thing...
Assuming google did a perfect cleanroom implementation of parts of Java and they lose this case then it can be assumed that cleanroom implementations offer no protection against copyright claims.
A lot of non-commercial projects get shot down by companies for copyright infringements. Being non-commercial won't protect you either.
My position is that it doesn't really change things all that much, with losses by Android probably mostly picked up by Apple or Symbian or webOS or Windows Phone but the trajectory to smartphones and away from J2ME stuff largely the same. The sense of how much Android actually "mattered" in this sense goes right to the "effect on the market" prong.
As for the broader case, both the copyrightability and fair use claims have been presented to the Supreme Court here. The temptation from the outside looking in is to think/hope/dread that the court will just resolve these questions once and for all, but they often prefer to resolve cases on narrower grounds, where available. Google spent a lot of time arguing for, and would be perfectly fine with, a simple remand based on the Federal Circuit's standard of review of the jury's fair use verdict.
So, if ReactOS ever becomes useful, it will be illegal to use it for commercial purposes?
The first thing to understand about fair use is that it applies to copyright infringement, so first, someone has to complain about the infringement and then you utilize fair use as a defense. And second, that fair use has some guidelines/rules to test whether or not fair use should apply, but they are open to some interpretation.
So it wouldn't be "illegal" to commercialize ReactOS... but it'd probably make it a lot harder for ReactOS to use fair use as a shield going forward, because it would weaken their case on one of the pillars of the fair use test.
Unfortunately I think some lower courts have some messed up decisions or companies are trying to bully others with threats of suit. For example, some medical coding systems have copyrighted codes that are claimed to require a license and you can not install a system to cooperate with these. Except... this has already been decided, and you can.
That's not true though the reality is even worse. Patents have a limited term of 20 years.
If they win this case it is based on copyright law which has significantly longer terms. Currently that's valid until 70 years after the death of the content creator.
It's not like Oracle designed Java, and then Google stole it. Java was supposed to be open. It was designed for this intent. Oracle bought it to destroy everything Java was supposed to be, and to prey on anyone who used Java for what it was designed to do.
When you can no longer innovate, you litigate.
There's two questions up in the air with the case:
1. Whether or not you can claim copyright over the name of a function plus the combination of it's input types (an "API"). 2. Whether or not copying APIs can constitute fair use in the context of building a new platform using an existing language.
The first one is likely the case generally; you can claim ownership over "structure, sequence, and organization" just as well as Flame can claim ownership over a descending minor ostanato with a specific timbre. Imagine if Microsoft decided to do an end run around the GPL by copying all of Linux's header files and just writing new implementations. (Wait, isn't that how we got BSD?) This is sort of like the computer science equivalent of tracing over someone else's art, and we probably should have some protection to prevent that.
However, Java's APIs aren't just internal implementation details. They were made public to other developers specifically so that they would write programs that used them. Google argues that this makes them "methods of operation", which can't be copyrighted. If Microsoft makes Microsoft Excel accept macros from LibreOffice Calc by copying their menu bar shortcuts, that isn't protected and Microsoft is free to do that. (This has been adjudicated in court back in the 80s and is relevant precedent for the SCOTUS case.)
The fair use question is a fallback argument if the court rules that copyright ownership applies to API declarations. This requires application of a four-factors test. Notably, Google argued that Android needed to be compatible with Java APIs, and that such activities should be fair use. Oracle counters that Android's implementation of those APIs were out of date and incompatible, so that fair use shouldn't apply.
This also means that the Google/Oracle case might be ruled so narrowly that it doesn't affect WINE or ReactOS, or it could allow one and prohibit the other. After all, WINE is very narrowly focused on making Windows programs run on Linux, while ReactOS is trying to replace Windows entirely. One of the four fair use factors is the "market usurpation factor": what happens to the market for licenses if we allow people to do this under fair use and not pay for a license. If Win32 declarations can be considered copyrighted, then we could run into a situation where WINE using them to run Windows apps on Linux is NOT usurpation, but ReactOS using them to rewrite Windows IS.
Not to mention GNU was made in the same way as ReactOS, but against UNIX rather than Windows. I have no idea if the people who own the corpse of the people who bought out Novell would be able to assert a copyright claim, though, as most UNIX APIs were standardized under POSIX. Android also largely doesn't use those APIs (just the Linux kernel itself) and they'd be ironically safe from an SCO-style attack in this scenario.
Full disclosure: I am one of the developers of Ruffle (Free Software WASM/Rust Flash Player reimplementation) and I'm extremely paranoid of the project getting shut down by Adobe or HARMAN (the latter bought Adobe AIR). Ergo, I very much have material interest in the outcome of this case.
Same could be applied to any public interface. Header files, system calls, standard library, hardware version, language version, network interface.
Linux and WINE replaces Windows entirely. Looks like a lot of fans wait exactly that, not ReactOS.
Another API implementation is compatibility layer for authors who heavily invested in the platform. They are the reason platform is successful. Car dealerships investment is protected.
Very curious to see how far it's come for practical usage.
It's still alpha, so it's pretty rough, and a lot of things don't work so well.
That said, it's a wonderful project and I will continue to follow it and hope it continues to progress.
it's been in alpha for 24 years
Patience is good. Persistence is good. Something that is rare in today landscape.
I like the ReactOS idea, but I think it will take decades to be compatible enough - and I'm even talking about enough.
If the objective was to run obsolete software, I personally had to distribute resources, I'd just do assign them to Wine. It's surely much more productive to make software compatible on a per-case basis, rather than writing a whole operating system with the objective of being compatible.
It has been under development for decades. That is more than twice the time it took to develop Windows 95. I've tried ReactOS a few times over the years, and it has never worked for me.
I know of two specific examples of ReactOS code that as of a couple years ago were identical with Windows code. There are likely other instances pointing to a non-clean-room implementation.
Cool; if they're specific then you ought to be able to cite them for the rest of us.
What I'm wondering is if you just chanced upon a submission that wasn't actually accepted into the tree at any point?
Perhaps because it literally says:
>/* This part was copied from Windows source /
> / We should obfuscate this somehow? */
And looks sketchy as hell?
I'm not part of their project (just a fan) and my knowledge of git/github is shaky at best -but that's the way it looks from where I'm standing.
Also, I'm not seeing the original windows source code itself; only a comment.
(Or was, last time I tried a couple of years ago.)
I think they should go for rock solid stable first. Then people could build on it. It's perfect for embedded, Point-of-Sale etc where the vendor want to keep their codebase untouched but hop off the Microsoft bandwagon.
My impression is that most of the work on the project is motivated by interest in learning about OSs, rather than demand from real use-cases.
If the problem had strong enough demand from real use-cases, I presume it would be stable by now.
I get further with it each time, but there's still a lot of huge stumbling blocks (no SMP, for instance) that keeps me from using it for very long.
But I need PT a few times a year, so I'll keep trying.
I can also state that compared to version 0.4.7 (the first one I tried, iirc), the current non-nightly build 0.4.13 ran way more smoothly for me, at least on the GUI side. Issues with mouse stalling are gone, etc.
The "EPIC WIN!" threads on the ROS forum [1, 2] are fun to follow. Based on that, the OS seems to be quite usable for a range of cases.
I also liked the "What's the point?" threads [3, 4]. My respect to the developers for taking the time and patience to explain.
All in all, I keep hoping and installing new versions. I like how clean the system feels -- or, maybe this is the case with many systems when you don't bother to add Internet connectivity. Without wifi, every OS feels quiet and calm.
Greetings to ROS devs!
1: https://reactos.org/forum/viewtopic.php?f=2&t=10972&start=12...
2: https://reactos.org/forum/viewtopic.php?f=2&t=20185
3: https://reactos.org/forum/viewtopic.php?f=2&t=19782&start=60
4: https://reactos.org/forum/viewtopic.php?f=2&t=20031&start=30
Filling a bug-report is the important first step to have your software working in ReactOS
Pro Tools, at least in its early versions, tends to show its moods even on a well-tuned Windows system. So I was almost sure that it won't run in ROS out of the box. I was actually surprised to see it installing so smoothly. My guess is that the driver for the audio interface (Mbox 2) needs some attention.
There's also more to audio than mixing (simple mixing was done on G3/G4, come on), when you take all the effects and filters, so to offload that reasonably you'd need an audio card with, say, an FPGA.
Why? HDMI comes from the graphics card with video and audio.
Also I'm pretty sure a graphics card can handle audio effects in real time. 44k samples per second per channel is going to take a lot less than running complex shaders on 240 million pixels per second.
Then again, the fact that it exists just makes me feel good in ways I don't completely understand.
I'd love to see it advance far enough that one could drop in the open source code from Microsoft in it and run it. I doubt that'll happen any time in the next 20 years, however ...
0.4.14 is on its lats phase of preparation
[1]https://reactos.org/wiki/Build_Environment
former MS kernel engineer saying that in no way is is possible its not using stolen MS code.
Wouldn't Ubuntu+ Wine be a better combo for most ?
ReactOS is still in alpha, it's a very unfinished operating system. On the plus side, there's a lot of low-hanging fruits to attack if you want to work on a operating system, especially if the Windows NT design intrigues you.
It's perfectly fine if this is effectively ' we did it to prove we could ' thing. I've heard of React OS before and it's been in development for such a long time.
> There is currently no other operating system that implements the kernel architecture design of MS Windows NT™ so if you are unhappy with the direction or goal of Windows there is little real alternative. ReactOS was started as a “clone” of Windows NT to alleviate this situation. To demonstrate the concept of o/s cloning, GNU/Linux is the best for comparison here: Linux was started as a “clone” of Minix and Unix, eventually going on to be a Unix replacement.
...
> Linux+Wine is never going to be a complete replacement for a full Windows system. It's not only because of Linux (despite some user-friendly Linux distributions out there) and not only because many users might find a transition to Linux/BSD difficult but it is largely due to design and implementation decisions of Linux and Wine architectures which prevent 100% compatibility.
You aren't the audience, in other words.
The situation is a little bit comparable to Hercules, the IBM mainframe emulator (although not quite the same – Hercules is of course a hardware emulator, ReactOS is an operating system clone). You can use Hercules to run z/OS, but not legally, IBM only licenses z/OS to run on IBM's own hardware, or authorised proprietary emulators that cost $$$$. Thankfully though, IBM doesn't appear interested in suing hobbyists – IBM treats the hobbyist community as if they don't exist. But, try building a business on Hercules, as the company TurboHercules SAS did, and IBM's lawyers will start sending nasty letters to you.
To be exact they aim for compatibility with Server 2003.