I'm saddened a little bit to see stuff like theming has been built. I was hoping that ReactOS would stick with the Windows 2000 look and feel. I also think that with the limited resources they have, the project team would be better focusing on improving compatibility, over shiny desktop effects.
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.
Maybe the people who did the theming stuff aren't the ones that would working on compatibility issues.
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.
I think virtual machines are the best way to keep old software around. I have one for 32 bit stuff that's over 15 years old and making something of a comeback.
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.
>I think virtual machines are the best way to keep old software around.
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.
>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.
> else we'll endlessly repeat ourselves rewriting the same programs over and over 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.
Knowledge being lost and reinvented is a bug, not a feature. Some lessons have been paid-for in blood (like the Therac 25, if you're looking at software development). There is value in understanding how things work and what knowledge came from specific lessons, but starting over again simply invites making the same mistakes all over. I wish we could aspire to be better than that.
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.
Isn't this kind of like wishing that we could apply the lessons of the fallen Roman Republic to present-day America?
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.
I wish we'd just try to do better. It won't be perfect, and it'll probably never even be good. The worldview that espouses an inevitable loss of the products of human toil fills me with crushing sadness. Why bother doing anything then?
The equation is different with video games, but I generally agree with you on everything else. There isn't much value in using Word Perfect 5.1 today beyond historical preservation.
My mother edited four or five academic books on Word Perfect 5.1, and the easiest way to generate offset copy for them would be to boot it up and print them again on an HP LaserJet 4000, just like last time.
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.
I think I wasn't very clear in my comment. I think that for things like Word Perfect 5.1, the better solution for longevity would be new open source software that recreates it's functionality in a non-hardware dependent manner. Your mother being able to open Word Perfect files in LibreOffice and print them out with the correct formatting on a modern printer would be easier (and more useful) than relying on the original hardware and software.
> 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.
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?
agreed that most software can be made to run, but not all of them. The other issue is drivers, old drivers won't work on Windows 10 but will on reactOS
As an avid collector of vintage hardware and one who runs a YouTube channel dedicated to teaching people about how the hardware works, and how to actually use it, I can say confidently that yes, we definitely struggle.
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.
It's really saddening if you've been following the project for years. They had some good progress back when the Russian government got interested in ReactOS, but lately they seem to just be doing webdev stuff not directly related to improving ReactOS.
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?
ReactOS dev here. As of today, compatibility is primarily hampered by the fact that many applications don't run under Windows XP anymore.
We don't want to change the entire OS target to something newer than NT 5.2 (XP/Server 2003) at this point. Let's better stabilize on one target than chasing a moving target forever.
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
>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.
it's not just a matter of software, but also being compatible with drivers. Some old equipment that requires a specific window xp software but also a driver that doesn't work on current versions of windows.
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.