ReactOS 0.4.4 Released(reactos.org)
reactos.org
ReactOS 0.4.4 Released
https://reactos.org/project-news/reactos-044-released
180 comments
I agree. I have tremendous respect for the devs of ReactOS.
What is the point?
Do you remember IBM's OS/2? It turns out that a lot of really important systems still rely on OS/2. ATMs, ticketing machines, industrial control systems. Stuff that still has plenty of lifespan left, but would be prohibitively expensive to replace from scratch. A company called eComStation produce an OS/2-compatible operating system, with full support for modern hardware. Their clients include Boeing, Fujitsu, Alstom and Siemens.
I know of many vitally important systems that are still running on DOS, Windows 3.1 and a variety of even more obsolete platforms. I expect that Windows XP will continue to be a significant platform for several decades. If ReactOS ever gets out of beta, it'll be a boon for huge numbers of users.
I know of many vitally important systems that are still running on DOS, Windows 3.1 and a variety of even more obsolete platforms. I expect that Windows XP will continue to be a significant platform for several decades. If ReactOS ever gets out of beta, it'll be a boon for huge numbers of users.
It is interesting what exactly does eComStation support. Is that really mission-critical or just rarely used processes that no one wants to upgrade. Given the size of 4 companies you mentioned, there is non-zero probability that they allow entire eComStation to exist as a rounding error.
Wow, great point.. I had never though about these sort of legacy systems potentially running React someday.
I can't speak for the developers, but the reason I appreciate it and projects like it is the journey they're on. The things they've learned about Windows and it's apps, the skills they've developed, the community they've built. That on it's own is worthy of respect even if it was not of practical value itself.
We are all on our own journey and learned personal and professional things and skills. Except that most of us do not chase an express train that has left ten years ago.
They're chasing Windows xp which is a train that is waiting for them.
Xp is an empty station, not a train. In few years most apps and hardware will be incompatible with or not fully functional under xp (they already are in half). I'm not attacking reactos as you could think. I'm pointing to obvious facts that have to be dealt with for success.
If we skip practical part, ReactOS is great as any big community-driven project, because driving a big project is hard.
If we skip practical part, ReactOS is great as any big community-driven project, because driving a big project is hard.
But how many companies will want a migration path from XP? More than you may think.
No (sane) company's migration path from XP is going to be to an open-source clone of XP developed by a small team, that offers them no guarantees whether it works, no support, and the possibility that development could stop at any time.
If there are no other options, they will. And investors may be willing to fund a company that can keep XP apps running long-term.
No sane company is still using Windows XP, given that support ended 3 years ago and development ended a decade ago.
Still being used in POS equipment and ATMs.
"XP embedded" is still supported and updated, afaik.
Until April 9, 2019 https://support.microsoft.com/en-us/help/18581/lifecycle-sup...
As someone who's been involved in the emulation and preservation community on the Apple II side of things, free and open source implementations of old operating systems continue to be useful for historical research, archiving of old software, etc. etc.
It could be a nice option to have for people stuck running really old legacy Windows software.
Especially if ReactOS is able to maintain Win32 compatibility for legacy applications while also receiving community support for security updates.
ReactOS in an invaluable resource when it comes to Windows internals and reverse engineering.
Support, education and FUN spring to mind!
There's 288 Linux distributions currently listed on DistroWatch, multiple DE, package managers, and yet, Windows is still dominating on desktop.
Having an open source clone of Windows makes perfect sense. Imagine if, after all those years, this project received more support from the open source community. Today we would have a free and open source OS that would be able to run Windows drivers and the Win32 apps people want to use. Adobe's stuff, AutoCAD, AbletonLive, games, MS Office, etc.
In the end, the average person doesn't care about operating systems. What they care about is their apps.
Having an open source clone of Windows makes perfect sense. Imagine if, after all those years, this project received more support from the open source community. Today we would have a free and open source OS that would be able to run Windows drivers and the Win32 apps people want to use. Adobe's stuff, AutoCAD, AbletonLive, games, MS Office, etc.
In the end, the average person doesn't care about operating systems. What they care about is their apps.
Windows 10 isn't too bad OS wise either though. I don't know, maybe I'm just too old now because I'm already tired typing about it. I still scratch my head when I see people developing non Windows apps on Windows. And I run Nix on everything. But I'd accept 'I like Windows more even if I could run my expensive industry specific software on Linux' without feeling the need to explain why they're wrong.
>Windows 10 isn't too bad OS wise either though.
On a fundamental technical level, windows 10 is a pretty finely tuned os.
On any other benchmark you might choose (privacy, invasiveness and advertising, user control, user experience, active user deception) windows has been going downhill for years.
On a fundamental technical level, windows 10 is a pretty finely tuned os.
On any other benchmark you might choose (privacy, invasiveness and advertising, user control, user experience, active user deception) windows has been going downhill for years.
You're missing the point about criticism of Windows 10.
Almost nobody could claim that it's a bad OS from a technical standpoint, though there are certainly significant improvements to be made. The real issue is lack of any semblance of privacy, user unfriendliness, and frankly the closed-down nature of it is never going to do it any favours.
In my view, apart from gaming, it has nothing going for it.
Almost nobody could claim that it's a bad OS from a technical standpoint, though there are certainly significant improvements to be made. The real issue is lack of any semblance of privacy, user unfriendliness, and frankly the closed-down nature of it is never going to do it any favours.
In my view, apart from gaming, it has nothing going for it.
>In my view, apart from gaming, it has nothing going for it.
What Windows has going for it is that it supports a lot of different desktop/laptop hardware very well.
macOS doesn't support a lot of hardware. Linux supports a lot of hardware but much of it not very well.
If I list my desired specs for a laptop or desktop and then go ahead and buy the one that best meets my criteria, chances are pretty high that Windows will run best on it.
I have been a Mac user for many years. I'm using a Mac mini right now. But if I had to replace it today I wouldn't know what to replace it with.
What Windows has going for it is that it supports a lot of different desktop/laptop hardware very well.
macOS doesn't support a lot of hardware. Linux supports a lot of hardware but much of it not very well.
If I list my desired specs for a laptop or desktop and then go ahead and buy the one that best meets my criteria, chances are pretty high that Windows will run best on it.
I have been a Mac user for many years. I'm using a Mac mini right now. But if I had to replace it today I wouldn't know what to replace it with.
> What Windows has going for it is that it supports a lot of different desktop/laptop hardware very well.
I don't think that's the case. It's not that Windows itself supports more hardware, but the fact that drivers for said hardware are built only for Windows. It could even be seen as a vicious cicle: 1) HW manufacturers create drivers for Windows because It's more popular; 2) Users use Windows because "It Just Works (TM)" and so userbase grows; 3) goto 1
> Linux supports a lot of hardware but much of it not very well.
Hence I think Linux supports more HW but driver support isn't as good.
I get what you're saying though.
I don't think that's the case. It's not that Windows itself supports more hardware, but the fact that drivers for said hardware are built only for Windows. It could even be seen as a vicious cicle: 1) HW manufacturers create drivers for Windows because It's more popular; 2) Users use Windows because "It Just Works (TM)" and so userbase grows; 3) goto 1
> Linux supports a lot of hardware but much of it not very well.
Hence I think Linux supports more HW but driver support isn't as good.
I get what you're saying though.
A lot of the crap in Linux hardware support comes borked hardware that under Windows is papered over by the OEM drivers.
Damn it, Foxconn managed to ship a desktop motherboard that would produce junk ACPI data unless the OS identified itself as Windows on boot.
Damn it, Foxconn managed to ship a desktop motherboard that would produce junk ACPI data unless the OS identified itself as Windows on boot.
There are other issues as well that to people who know how to use Linux are not issues. Take running a program for example, on Windows telling a user they need to open CMD and run a batch file to get a program to execute is insane. Yet that's fairly common even with modern Linux software.
For Linux to compete with Windows realistically for average computer users it needs to have a distro that is like macOS in that it's idiot proof. I should be able to sit someone down in front of a computer running it with no instructions and the OS should do the teaching without telling them to open a terminal and look at man pages.
For Linux to compete with Windows realistically for average computer users it needs to have a distro that is like macOS in that it's idiot proof. I should be able to sit someone down in front of a computer running it with no instructions and the OS should do the teaching without telling them to open a terminal and look at man pages.
I agree with you, but I don't think GNU/Linux can compete with Windows at that point. The things you wrote about should have been implemented in most distro years ago.
If you speak about this in /r/linux, the people there will tell you that "if people are not willing to learn how to use the terminal to install apps, then they're just lazy/too stupid". This is the kind of mentality we're dealing with and that's why there's 288 ditros without any chance of mass adoption.
If you speak about this in /r/linux, the people there will tell you that "if people are not willing to learn how to use the terminal to install apps, then they're just lazy/too stupid". This is the kind of mentality we're dealing with and that's why there's 288 ditros without any chance of mass adoption.
When they say the privacy issues of Windows I see a double standard. Android is, to my mind, equally "invasive" as Windows, if not more. Except the fact that Android's source code is open, they are pretty much same regarding end user experience. Yet every time Windows 10 is brought up people say privacy.
Yeah, I understand that Windows wasn't like this, so people can get upset about the recent changes Microsoft is pushing onto. On the other hand Android has been like that from the beginning, so there might not be much expectation. But still I don't care Windows-as-a-service because nowadays pretty much every software I use is provided like that. It's just that the OS becamse not an exception.
Yeah, I understand that Windows wasn't like this, so people can get upset about the recent changes Microsoft is pushing onto. On the other hand Android has been like that from the beginning, so there might not be much expectation. But still I don't care Windows-as-a-service because nowadays pretty much every software I use is provided like that. It's just that the OS becamse not an exception.
It isn't, as you can disable or replace parts of Android you don't like. With Windows you are stuck with whatever Microsoft decides.
The best place to put spyware into is closed source unauditable software.
On Windows the entire system and most well known applications are closed source, therefore not trustworthy, but on Android things are not that different: Android makes heavy use of closed source device drivers and so far any attempt to get a completely open system while keeping all the underlying iron useable has failed because most device manufacturers keep their hardware undocumented, save for Google and a few big players under NDA.
The point is that security is an OR: a chain whose strength depend on the weakest link; if one closed blob can contain a keylogger, having just one in an otherwise 100% open phone still makes the phone 100% potentially not secure.
On Windows the entire system and most well known applications are closed source, therefore not trustworthy, but on Android things are not that different: Android makes heavy use of closed source device drivers and so far any attempt to get a completely open system while keeping all the underlying iron useable has failed because most device manufacturers keep their hardware undocumented, save for Google and a few big players under NDA.
The point is that security is an OR: a chain whose strength depend on the weakest link; if one closed blob can contain a keylogger, having just one in an otherwise 100% open phone still makes the phone 100% potentially not secure.
By your definition, Linux is also insecure since it depends on closed source BIOS and closed source device firmwares, as well as closed source hardware.
Security is a process not a if/else choice, and Android is more secure than Windows because it is open source and you can replace Google parts. Good luck doing that on Windows.
Security is a process not a if/else choice, and Android is more secure than Windows because it is open source and you can replace Google parts. Good luck doing that on Windows.
The key is "potentially" and from whom the risk of exploitation comes from. Having one closed driver instead of 20 makes the system statistically a lot less prone to exploitation by the usual malware writers, but if a government or any entity with enough power wants to take advantage of that weak point to install say a keylogger, their chance of success is 100% like it would be on a system that depends on 20 closed blobs.
And yes, Linux (and BSD) is also potentially insecure (or less secure if you prefer), which is the reason why the same effort who brought us a lot of quality Open Source verifiable software now should be directed towards obtaining also Open Hardware. We need to build a culture as we did with Open Source software so that people will understand the importance and associated risks.
And yes, Linux (and BSD) is also potentially insecure (or less secure if you prefer), which is the reason why the same effort who brought us a lot of quality Open Source verifiable software now should be directed towards obtaining also Open Hardware. We need to build a culture as we did with Open Source software so that people will understand the importance and associated risks.
There is a very clear difference. The MSRP of Windows OS is over $100 or the Microsoft tax if you bought a Windows system. Secondly, you can turn off Google services when you setup an Android phone. Where is the option to turn off all Microsoft services and not have to interact with them at all?
but the proprietary nature of Windows 10 is the problem. Cost. Spyware. Security. ...
> Spyware. Security. ...
I hope you don't use web apps, ChromeOS or Android then.
I hope you don't use web apps, ChromeOS or Android then.
For web, I always have Privacy Badger + Ublock + ScriptSafe (which I selectively disable). For Android, Instead of StockRoms + GooglePlay I use Lineage + F-Droid (only open source apps). And on my ChromeOS labtop, I installed Parabola Linux (free-software-only version of Arch Linux).
How is that philosophically different than using Windows with Spybot Anti-beacon (or similar telemetry-blocker)?
You're critical of Windows for collecting data, but use other software that collects similar data, saying "that's fine I have 3rd-party privacy tools". These same tools have existed for Win10 since week 1.
You're critical of Windows for collecting data, but use other software that collects similar data, saying "that's fine I have 3rd-party privacy tools". These same tools have existed for Win10 since week 1.
> How is that philosophically different than using Windows
He has entirely FOSS stacks for his devices? Quite literally no proprietary code wherever possible?
They're not "3rd-party privacy tools" he's making a point of, outside of a browser which isn't what the complaint is about on Windows, since that is outside the bounds of OS-specific complaints, but he mentioned it nonetheless since you asked about it.
He has entirely FOSS stacks for his devices? Quite literally no proprietary code wherever possible?
They're not "3rd-party privacy tools" he's making a point of, outside of a browser which isn't what the complaint is about on Windows, since that is outside the bounds of OS-specific complaints, but he mentioned it nonetheless since you asked about it.
Regarding web, that is only partial security, as you cannot avoid everything that gets stored on the application servers.
I don't like the way Microsoft has lately begun treating both their devs and customers, but nevertheless they are a corporation - they have to someway make a profit - a business survives by adapting to their users and telemetry ("spyware") is data; data on which they (should) adapt to their user needs.
The fact that you can spell out the motivation of someone's shitty behavior doesn't elevate it above criticism!
Some time ago, I had a desktop PC with a mechanical HDD (capacity reasons), and I made a mistake of installing W10 on it. Very quickly I noticed that even on a fresh install, HDD was literally never idle, and that's after all updates. There's always some more crap MS wants to push out, or something wants to update, or reindex, and so on and on. Seriously, it interfered with my sleep in another room.
Windows 10, never again.
Windows 10, never again.
Did you ever run a profile to see what was going on? Or run ProcessMonitor to see what was using the disk etc.?
It could be the indexing service for files. There is the NTFS MFT which is used by tools such as Everything by "void tools", but Windows also has its own Windows Search (WSearch) service which indexes files and contents. I believe this is similar to the Indexing Service found on Windows XP that would give you hopeless results (duplicates between its database and the actual file system). This is meant to make Cortana be able to give you helpful results when you search for things like files locally.
I have found it to be slow to type something into the Start menu (just type), particularly compared to the results from Everything (mentioned above) or Apple's Spotlight. It is very odd because Microsoft has its own SQL Server division (and SQLite is free if they want to use that!) as well as embedded SQL Server for file-based database systems yet their start menu search is horribly slow so as to be useless (for me at least).
I recommend buying Windows Internals 6 volumes 1 & 2 to understand what is going on, at least under Windows 7. There are not versions released for Windows 10 yet (and will there ever be? It's a constantly moving target).
It could be the indexing service for files. There is the NTFS MFT which is used by tools such as Everything by "void tools", but Windows also has its own Windows Search (WSearch) service which indexes files and contents. I believe this is similar to the Indexing Service found on Windows XP that would give you hopeless results (duplicates between its database and the actual file system). This is meant to make Cortana be able to give you helpful results when you search for things like files locally.
I have found it to be slow to type something into the Start menu (just type), particularly compared to the results from Everything (mentioned above) or Apple's Spotlight. It is very odd because Microsoft has its own SQL Server division (and SQLite is free if they want to use that!) as well as embedded SQL Server for file-based database systems yet their start menu search is horribly slow so as to be useless (for me at least).
I recommend buying Windows Internals 6 volumes 1 & 2 to understand what is going on, at least under Windows 7. There are not versions released for Windows 10 yet (and will there ever be? It's a constantly moving target).
Yes, spent some time with Perfmon, as expected, it was due to various system components constantly finding some reason to update/install something I have no use for.
Moving Chrome profile to a RAM disk helped somewhat, as did turning off some icon update stupidity or something like that in hidden Chrome settings.
But as you mentioned, if even the Start menu is lagging, I have no patience and no desire to investigate further, this is it. So instead of buying some utilities to make windows less crappy, I've finally had enough and installed Ubuntu on that last PC. Just to think about it, I was an MCSE+I and MCDBA some time ago, now I only boot windows for games.
Moving Chrome profile to a RAM disk helped somewhat, as did turning off some icon update stupidity or something like that in hidden Chrome settings.
But as you mentioned, if even the Start menu is lagging, I have no patience and no desire to investigate further, this is it. So instead of buying some utilities to make windows less crappy, I've finally had enough and installed Ubuntu on that last PC. Just to think about it, I was an MCSE+I and MCDBA some time ago, now I only boot windows for games.
Similar experience. Win10 was really, really sluggish on my spinning rust drive. Problem went away with an SSD. Must be tuned for use on a solid state drive.
I would guess that would be the case for the most part these days... I don't think I'd want to use a modern OS on a spinning drive, at least for the OS/swap. Of course, linux (ubuntu) has its' own issues, like the 80+gb ~/.cache/upstart/unity.7.log file filling up the ssd every couple days (still haven't caught it when not full to be able to dig into, annoying all the same).
Though worst from MS on spinning drives has to be using Visual Studio on a web project (or node dev for that matter)... it's painful.
Though worst from MS on spinning drives has to be using Visual Studio on a web project (or node dev for that matter)... it's painful.
Is the desktop still a market worth dominating? It's relevant today, and will remain relevant, but in decreasing amounts. I think we're in a new era of thin clients and beefy *nix machine clusters again, and I think it will matter less and less what IT departments buy as long as they have a capable browser.
[deleted]
I think this would've been a good answer 6 years ago, but with tablet sales decreasing YoY and desktop/ laptop finally growing again, it might not be entirely accurate.
6 years ago we thought netbook thin clients paired with powerful backends would dominate. But here we are in 2017 - server side rendering of UI is waning while rich and robust client side interface applications are thriving.
I think that late 2000's/ early 2010's vision of local computing withering in the shade of cloud resources is over. It turns out people want fancy, fat UI -- and rendering that server side isn't a very good idea.
6 years ago we thought netbook thin clients paired with powerful backends would dominate. But here we are in 2017 - server side rendering of UI is waning while rich and robust client side interface applications are thriving.
I think that late 2000's/ early 2010's vision of local computing withering in the shade of cloud resources is over. It turns out people want fancy, fat UI -- and rendering that server side isn't a very good idea.
I can render fancy fat ui on my phone these days though, and keep all the buisiness logic in my server service I charge a monthly fee to run. I don't think thick clients are driving notebook sales, except that maybe we put more ram in chrome books than you would expect?
Idk, maybe I a sheltered in Silicon Valley, and I know that most of the buisiness world has a lot of legacy windows apps you need to run your buisiness, and if it ain't broke no one is changing it. But, for new apps, I don't see why you wouldn't do SAS. It will be a slow process for sure but I can't see what will reverse it, except for maybe widespread privacy concerns about the cloud.
Idk, maybe I a sheltered in Silicon Valley, and I know that most of the buisiness world has a lot of legacy windows apps you need to run your buisiness, and if it ain't broke no one is changing it. But, for new apps, I don't see why you wouldn't do SAS. It will be a slow process for sure but I can't see what will reverse it, except for maybe widespread privacy concerns about the cloud.
> robust client side interface applications are thriving.
But a huge amount of them use web technologies which are pretty much OS independent. I'm using Linux for 10 years now and I used to have trouble to work with others because they where all using Windows-only software (proprietary chat client, MS office, etc.) but it's less the case anymore because for many use-cases everybody uses web applications instead of native software.
> It turns out people want fancy, fat UI -- and rendering that server side isn't a very good idea.
That's why JavaScript is the dominant language out there. And with WASM comming, even what's currently out of reach of JavaScript will be doable on a web plateform (except high-end gaming maybe).
But a huge amount of them use web technologies which are pretty much OS independent. I'm using Linux for 10 years now and I used to have trouble to work with others because they where all using Windows-only software (proprietary chat client, MS office, etc.) but it's less the case anymore because for many use-cases everybody uses web applications instead of native software.
> It turns out people want fancy, fat UI -- and rendering that server side isn't a very good idea.
That's why JavaScript is the dominant language out there. And with WASM comming, even what's currently out of reach of JavaScript will be doable on a web plateform (except high-end gaming maybe).
That's very nice, but I feel that the price we're paying for running the Web-stack on top of normal application stack is atrocious, especially where a native, local application would be far more efficient. It works, yes; and I'm glad I'm not getting as many "Linux? Go away" issues these days; yet the bloat and latency of web-stack is something that remains largely unadressed in 2017.
Case in point: OSM editors. iD has very low barriers to entry: it's all in-browser, integrated with the website, nice rounded corners, and no dependencies - but it's slow and unable to keep up with edits > 500 nodes (because it's a memory hog built on a memory-hog JS framework running in a JS+DOM memory-hog virtual machine inside a memory-hog application). JOSM, on the other hand, is not quite native (Java being a memory hog of its own), but is capable to use persistent caching and relatively efficient memory structures. (I'm explicitly not comparing the feature set, which stems from different usecases or ease-of-use, which is somewhat subjective: this is in comparison of rudimentary editing operations)
Case in point: OSM editors. iD has very low barriers to entry: it's all in-browser, integrated with the website, nice rounded corners, and no dependencies - but it's slow and unable to keep up with edits > 500 nodes (because it's a memory hog built on a memory-hog JS framework running in a JS+DOM memory-hog virtual machine inside a memory-hog application). JOSM, on the other hand, is not quite native (Java being a memory hog of its own), but is capable to use persistent caching and relatively efficient memory structures. (I'm explicitly not comparing the feature set, which stems from different usecases or ease-of-use, which is somewhat subjective: this is in comparison of rudimentary editing operations)
With local apps there are issues of updates, security and platform lock-in. No such issues with web apps. And thanks to modern JS engines, web apps are now fast enough for most tasks.
>>but it's slow and unable to keep up with edits > 500 nodes
It is perfectly possible to build a fast JS app. The one in your example is not well optimized.
>>but it's slow and unable to keep up with edits > 500 nodes
It is perfectly possible to build a fast JS app. The one in your example is not well optimized.
It is also perfectly possible to build a clean PHP app. Yet, the overwhelming majority of PHP apps are piles of hacks and the overwhelming majority of JS apps are bloated behemoths, because those are languages that are sloppy or hungry (respectively) by default, these are the paths of their least resistance. With the current "ship it first, fix it maybe later, never pause to think it through" mentality, all you'll ever get is the default.
(And don't get me started on Web security, or rather lack thereof: security is not inherent to web apps"; DROP TABLES; --
(And don't get me started on Web security, or rather lack thereof: security is not inherent to web apps"; DROP TABLES; --
> With local apps there are issues of updates, security and platform lock-in. No such issues with web apps.
With web apps there are issues such as vendor lock-in of your data (like doing accounting in a webapp) try getting your data out.
Vendor updating to a new non functional version of their web app while you liked the old one.
Security issues because your data is now on the internet instead of on a local PC.
You are just trading one set of limitations for another and also removing your ability to address issues by yourself.
With web apps there are issues such as vendor lock-in of your data (like doing accounting in a webapp) try getting your data out.
Vendor updating to a new non functional version of their web app while you liked the old one.
Security issues because your data is now on the internet instead of on a local PC.
You are just trading one set of limitations for another and also removing your ability to address issues by yourself.
>>With web apps there are issues such as vendor lock-in of your data
You can use self-hosted web apps or a vendor that allows export of data. You can use a vendor that allows loading/saving data locally.
>>Security issues because your data is now on the internet instead of on a local PC.
The same is true for most local apps. How do you know they are not leaking your data?
>>Vendor updating to a new non functional version of their web app while you liked the old one.
True for local apps as well
>>You are just trading one set of limitations for another and also removing your ability to address issues by yourself.
There are always limitations, but web apps have less, which is why they are winning.
You can use self-hosted web apps or a vendor that allows export of data. You can use a vendor that allows loading/saving data locally.
>>Security issues because your data is now on the internet instead of on a local PC.
The same is true for most local apps. How do you know they are not leaking your data?
>>Vendor updating to a new non functional version of their web app while you liked the old one.
True for local apps as well
>>You are just trading one set of limitations for another and also removing your ability to address issues by yourself.
There are always limitations, but web apps have less, which is why they are winning.
Updating a local app is under your own control.
While self hosting webapps certainly is possible, this is not an option for the average user.
With a local app you can make it certain that it isn't leaking by not connecting it to the internet?
I guess we will have to agree to disagree on this as you are clearly looking at this from a different angle as I do.
While self hosting webapps certainly is possible, this is not an option for the average user.
With a local app you can make it certain that it isn't leaking by not connecting it to the internet?
I guess we will have to agree to disagree on this as you are clearly looking at this from a different angle as I do.
Well, now the lock in is at the server side instead... Google Docs anyone?
I see this argument often, but think about it this way: people use Electron style apps because they have no other real choice. If I had the same app written natively and another implementation based on Electron, I'd pick the native app every single time. It's developers who are pushing for JavaScript, not users.
> It's web developers who are pushing for JavaScript
Fixed that for you.
I am a developer, with UI experience going back to Amiga/Windows 3.x days, and will only touch Electron if forced by customers/employer to do so.
Fixed that for you.
I am a developer, with UI experience going back to Amiga/Windows 3.x days, and will only touch Electron if forced by customers/employer to do so.
I feel the same way about Electron, because I don't like shipping subpar applications to users.
I've found the development experience using TypeScript and React to be fairly pleasant, though. I know some people gripe about JSX/TSX, but it seems to me it's a lot like XAML - declarative XML that you can use to lay out your interface and hook up event handlers.
I've been enjoying the UWP, WPF, and macOS ports of React Native. They make it fairly easy to get up and running with something that'll let you share 80% of your code cross platform while still making it easy to write extensions with the native OS toolkit when needed. From what I've observed, RN desktop apps are much more CPU and memory efficient than Electron apps. In my mind, this is a much better way to create desktop applications using (mostly) web technology.
I've found the development experience using TypeScript and React to be fairly pleasant, though. I know some people gripe about JSX/TSX, but it seems to me it's a lot like XAML - declarative XML that you can use to lay out your interface and hook up event handlers.
I've been enjoying the UWP, WPF, and macOS ports of React Native. They make it fairly easy to get up and running with something that'll let you share 80% of your code cross platform while still making it easy to write extensions with the native OS toolkit when needed. From what I've observed, RN desktop apps are much more CPU and memory efficient than Electron apps. In my mind, this is a much better way to create desktop applications using (mostly) web technology.
> It's developers who are pushing for JavaScript, not users.
It's the business which is pushing for JavaScript: for most product nowadays you need to support both Windows and MacOS. Now you need to consider the following trade-off: do you want native apps at the expense of two code bases ? Or do you prefer a portable one at the expense of quality ?
In many cases the answer is a cleary the second option. Now you just have to chose which portable runtime you want: Java like it's 2000 or the web which is the current norm.
An hybrid approach is Qt since it wants to be a tool to build portable native apps, but in fact they are neither really native (the UI doesn't feel right) nor really portable (it often doesn't work out of the box).
It's the business which is pushing for JavaScript: for most product nowadays you need to support both Windows and MacOS. Now you need to consider the following trade-off: do you want native apps at the expense of two code bases ? Or do you prefer a portable one at the expense of quality ?
In many cases the answer is a cleary the second option. Now you just have to chose which portable runtime you want: Java like it's 2000 or the web which is the current norm.
An hybrid approach is Qt since it wants to be a tool to build portable native apps, but in fact they are neither really native (the UI doesn't feel right) nor really portable (it often doesn't work out of the box).
> but it's less the case anymore because for many use-cases everybody uses web applications instead of native software.
As a user, when given the option, I always use native.
And I know many that do the same, specially in mobile apps.
At work, when given the option, I rather produce native applications than web ones.
As a user, when given the option, I always use native.
And I know many that do the same, specially in mobile apps.
At work, when given the option, I rather produce native applications than web ones.
These things start off very slowly, and then tend to somewhat exponentially grow and improve over time.
Have a look at LibreOffice. StarOffice was open sourced in 2000 by Sun as OpenOffice.org and started somewhat slowly. By 2004 OpenOffice.org was making steady progress, and had captured quite a bit of market share.
Then the OpenOffice developers and Sun started stymying contributions, and eventually Michael Meeks setup Go-OO with a bunch of patches that made the program easier to use. Then Oracle bought Sun and really pissed off key external contributors so they forked the product and in 2011 The Document Foundation was formed to oversee LibreOffice development.
Since then OpenOffice.org has stagnated and withered on the vine, whereas LibreOffice has had entire swathes of old and cruddy code rewritten and each point release has not only got huge numbers of bugs fixed, but often new features - and often entire subsystems have been rewritten without the end user ever knowing.
So give it time - it's been just over 16 years since it the StarOffice source was opened to anyone. ReactOS has been around at least this long, and due to the nature of the project isn't quite as fast, but each time I read a new release it occurs to me that development is accelerating rather rapidly!
Have a look at LibreOffice. StarOffice was open sourced in 2000 by Sun as OpenOffice.org and started somewhat slowly. By 2004 OpenOffice.org was making steady progress, and had captured quite a bit of market share.
Then the OpenOffice developers and Sun started stymying contributions, and eventually Michael Meeks setup Go-OO with a bunch of patches that made the program easier to use. Then Oracle bought Sun and really pissed off key external contributors so they forked the product and in 2011 The Document Foundation was formed to oversee LibreOffice development.
Since then OpenOffice.org has stagnated and withered on the vine, whereas LibreOffice has had entire swathes of old and cruddy code rewritten and each point release has not only got huge numbers of bugs fixed, but often new features - and often entire subsystems have been rewritten without the end user ever knowing.
So give it time - it's been just over 16 years since it the StarOffice source was opened to anyone. ReactOS has been around at least this long, and due to the nature of the project isn't quite as fast, but each time I read a new release it occurs to me that development is accelerating rather rapidly!
The office suite market in general has been relatively stagnant over the last couple of decades. Sure there have been some noticeable advancements such as the introduction of ribbon bars and zipped XML documents replacing undocumented binary blobs. But feature MS Office reached a plateau in the late 90s so a significant amount of work since has been about user experience instead. Often just with pointless UI tweaks in the aim of milking their proverbial cash cow.
This has made it easier for open source competitors to catch up with Microsoft.
However compare that to operating system development - or to be more specific: reverse engineering undocumented APIs that receive updates every few years - and you have yourself a whole order of magnitude more difficult job to even just reach a usable parity let alone being a competitive alternative.
As quickly as ReactOS developers can reverse engineers Windows, Microsoft will progress their flagship OS. ReactOS is chasing a moving target in a way that LibreOffice is not.
Disclaimer: I'm not dismissing the developers efforts. I just don't agree with your statement that ReactOS will snowball in the same way that many other open source developments do.
This has made it easier for open source competitors to catch up with Microsoft.
However compare that to operating system development - or to be more specific: reverse engineering undocumented APIs that receive updates every few years - and you have yourself a whole order of magnitude more difficult job to even just reach a usable parity let alone being a competitive alternative.
As quickly as ReactOS developers can reverse engineers Windows, Microsoft will progress their flagship OS. ReactOS is chasing a moving target in a way that LibreOffice is not.
Disclaimer: I'm not dismissing the developers efforts. I just don't agree with your statement that ReactOS will snowball in the same way that many other open source developments do.
Windows subsystem stagnated since 2006. Win32 is on a standstill. All new efforts (Silverlight, UniversalRuntime, etc) are not very successful (and based on Win32 subsystem as well) and like a niche compared to the vast amount of WinAPI based applications. So Windows like Office are not a moving target like they used to be.
ReactOS aims for WinNT series compatibility including hardware drivers. And those driver APIs haven't changed for a decade or more.
ReactOS aims for WinNT series compatibility including hardware drivers. And those driver APIs haven't changed for a decade or more.
From an end user perspective Windows 10 might not appear any more advanced than it's predecessors, but the NT subsystem has still changed quite considerably since 2006 (that date range covers Vista, Windows 7, 8.* and 10).
There have also been massive changes to the way Windows handles networking and authentication protocols (Active directory, SMB, etc), changes to the the driver model, changes to the way POSIX support is handled, etc.
As much as you might dismiss some subsequent Microsoft technologies to be "not very successful", the fact remains that Microsoft are still always pushing new technologies and a not so insignificant number of developers do sometimes use these technologies which means, at some point, the ReactOS developers will either need to reverse engineer those technologies as well (assuming those libraries can't run natively on ReactOS already _and_ there's no legal restrictions preventing them from running on non-Microsoft endorsed platforms) or accept a lack of parity with Windows.
There have also been massive changes to the way Windows handles networking and authentication protocols (Active directory, SMB, etc), changes to the the driver model, changes to the way POSIX support is handled, etc.
As much as you might dismiss some subsequent Microsoft technologies to be "not very successful", the fact remains that Microsoft are still always pushing new technologies and a not so insignificant number of developers do sometimes use these technologies which means, at some point, the ReactOS developers will either need to reverse engineer those technologies as well (assuming those libraries can't run natively on ReactOS already _and_ there's no legal restrictions preventing them from running on non-Microsoft endorsed platforms) or accept a lack of parity with Windows.
Those changes didn't change the fundamental architectural basis of Windows. There are quite a few subsystems in the NT architecture, let's look at them in turn, but first have a look at the following diagram which I created years ago and hasn't changed terribly:
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#/me...
* the HAL - there have been changes here, but nothing so fundamental that can't be built upon
* kernel mode drivers - these have changed and new models keep getting released by Microsoft, but these rely on well defined interfaces and a lot of it is in the kernel mode driver framework (KMDF). A detailed history can be found here:
https://msdn.microsoft.com/windows/hardware/drivers/wdf/kmdf...
The user mode driver framework is similar.
I'm not going to go through the rest of the subsystems, you might want to review this document:
https://web.archive.org/web/20160113113554/http://research.m...
So... sure, things have changed over the years but they most certainly aren't radical enough to stall development of ReactOS.
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#/me...
* the HAL - there have been changes here, but nothing so fundamental that can't be built upon
* kernel mode drivers - these have changed and new models keep getting released by Microsoft, but these rely on well defined interfaces and a lot of it is in the kernel mode driver framework (KMDF). A detailed history can be found here:
https://msdn.microsoft.com/windows/hardware/drivers/wdf/kmdf...
The user mode driver framework is similar.
I'm not going to go through the rest of the subsystems, you might want to review this document:
https://web.archive.org/web/20160113113554/http://research.m...
So... sure, things have changed over the years but they most certainly aren't radical enough to stall development of ReactOS.
I didn't say stall the development of ReactOS. I said Windows is a moving target. And I also listed a bunch of interfaces that had changed specification in subsequent releases of Windows.
And I didn't say you said to stall development of ReactOS, I said that I don't think it would actually stall development :-)
ReactOS has a target of Windows Server 2003. If they decide to upgrade to a later operating system, I'm not quite sure I see that as a huge issue.
ReactOS has a target of Windows Server 2003. If they decide to upgrade to a later operating system, I'm not quite sure I see that as a huge issue.
"Microsoft are still always pushing new technologies"
And how much of it is actually needed? Considering only the actually useful parts of an OS, my impression is that Windows got saturated a long ago and the parts in later versions were just forced along in new versions due to reasons that have nothing to do with technological advance. My point is, ReactOS has only to become stable and reasonably good on real hardware to be successful. There is a lot of parts in the later Windows versions that only serve niches, thus being cruft for the bulk of users. Microsoft had to evolve this way due to its commercial nature, whereas ReactOS doesn't have to.
And how much of it is actually needed? Considering only the actually useful parts of an OS, my impression is that Windows got saturated a long ago and the parts in later versions were just forced along in new versions due to reasons that have nothing to do with technological advance. My point is, ReactOS has only to become stable and reasonably good on real hardware to be successful. There is a lot of parts in the later Windows versions that only serve niches, thus being cruft for the bulk of users. Microsoft had to evolve this way due to its commercial nature, whereas ReactOS doesn't have to.
It doesn't matter how much of the new tech is needed in Windows. It doesn't even matter if the tech is any good or not. What matters is if it's used by applications. If it is then ReactOS has to reverse engineer it if they want parity with Windows.
I don't get why people are pushing back on this point. It isn't a criticism of ReactOS. It's just a pragmatic result of writing a clone of another project that itself is constantly undergoing development.
This is why people more often talk about ReactOS being exciting in terms of supporting older software rather than new. Obviously if it ever got to the stage that it had parity with the latest releases of Windows then that would be amazing but the chances of that happening are miniscule.
I don't get why people are pushing back on this point. It isn't a criticism of ReactOS. It's just a pragmatic result of writing a clone of another project that itself is constantly undergoing development.
This is why people more often talk about ReactOS being exciting in terms of supporting older software rather than new. Obviously if it ever got to the stage that it had parity with the latest releases of Windows then that would be amazing but the chances of that happening are miniscule.
"It doesn't even matter if the tech is any good or not. ReactOS has to reverse engineer it if they want parity with Windows. It's just a pragmatic result of writing a clone of another project that itself is constantly undergoing development."
I think this is where you're making wrong assumptions. ReactOS is free and open-source, and from this comes choice. Even if the main project chooses to work on reimplementing marginal or even unwanted things, a fork is always an option. (A fork from an immature project like it still is doesn't make sense for now.) After all, it's known that people don't appreciate bloat. ReactOS wants parity with Windows 2003 and that is a manageable target. Bits from later Windows versions may be added for important applications but it hasn't have to be nor is necessarily wanted all that Microsoft pushed from Vista hitherto. ReactOS doesn't have to cover all that much, really.
Also, an important nitpeek: ReactOS doesn't reverse-engineer. It employs clean-room engineering.
I think this is where you're making wrong assumptions. ReactOS is free and open-source, and from this comes choice. Even if the main project chooses to work on reimplementing marginal or even unwanted things, a fork is always an option. (A fork from an immature project like it still is doesn't make sense for now.) After all, it's known that people don't appreciate bloat. ReactOS wants parity with Windows 2003 and that is a manageable target. Bits from later Windows versions may be added for important applications but it hasn't have to be nor is necessarily wanted all that Microsoft pushed from Vista hitherto. ReactOS doesn't have to cover all that much, really.
Also, an important nitpeek: ReactOS doesn't reverse-engineer. It employs clean-room engineering.
ReactOS is aiming for 2003 at the moment. A few years back it was 2000. Then previous versions of Windows before then. It's target has been upgraded every few years. I've been following and using ReactOS for about 15 years now. Trust me when I say I'm familiar with the project and what it's aims are and have been in the past.
Yeah you're right it's not reverse engineering in the technical sense. It's a lazy term to use because it sounds like the approximation of the process even though it's technically inaccurate. I should get out of that habit. :)
Yeah you're right it's not reverse engineering in the technical sense. It's a lazy term to use because it sounds like the approximation of the process even though it's technically inaccurate. I should get out of that habit. :)
It is my understanding that you already can run an impressive amount of Windows software (I think including MS Office) under Linux using Wine. That doesn't seem to help the popularity of Linux very much.
In Germany we have a saying, "Was der Bauer nicht kennt, frisst er nicht". Most people just don't care about operating systems, and hence they do not see the point in trying another system when the one they know works well enough for them.
A couple of years back, I set up my parents' notebook to dual boot either Windows 7 or Ubuntu 12.04. Despite the fact that both their printer and their (ancient) scanner worked out of the box (which did not work on Windows 7 at all), they have never used it.
A couple of years back, I set up my parents' notebook to dual boot either Windows 7 or Ubuntu 12.04. Despite the fact that both their printer and their (ancient) scanner worked out of the box (which did not work on Windows 7 at all), they have never used it.
Changing habits is hard, most people don't want do it useless they are forced to.
5 of 6 years ago, my mother's old computer died. All the new ones where running Windows 7 while she was used to XP.
I seized the opportunity to install Linux on here computer instead of Windows 7, and she was OK with that because she was going to be in a new environment anyway. She is now a proud Linux user for 5 or 6 years :)
5 of 6 years ago, my mother's old computer died. All the new ones where running Windows 7 while she was used to XP.
I seized the opportunity to install Linux on here computer instead of Windows 7, and she was OK with that because she was going to be in a new environment anyway. She is now a proud Linux user for 5 or 6 years :)
The only computer that runs windows in my house is my dual boot machine. My parents and my sister all have ubuntu distros, because 99% of the time they just need firefox and a text editor.
On the other end of the spectrum you have young people who equally do not care about the operating system, but do not have such strong ties to Windows. I was amazed that when I gave my Ubuntu laptop to children on our family meetings, they had absolutely no problem using it for anything they needed. It was mostly just browsing the web and watching YouTube, but the point is that it was not alien to them. If more cheap laptops shipped with Ubuntu pre-installed, the adoption could go up significantly.
Until their school ask them to produce a document in MS Office, or they want to play a game that is not available on Linux.
I installed Elementary OS on my niece's computer because she lost her Windows licence. 2-3 weeks after that, she told me her computer was "broken". The reason was that she tried to run some apps (win32) but of course it didn't worked.
I installed Elementary OS on my niece's computer because she lost her Windows licence. 2-3 weeks after that, she told me her computer was "broken". The reason was that she tried to run some apps (win32) but of course it didn't worked.
OpenOffice documents are compatible with MS Office (and I think OO can even save them in MS format, but I'm not sure of that.)
But if you only care about your apps, there's no real reason to run ReactOS. You'd also have to care about free or open source software.
Can't speak for the other stuff, but if you're not using wacky instrument drivers (I only have a pretty basic midi keyboard so I don't know what other instruments are like) Ableton Live 9 works like an absolute dream under Wine. I was shocked by how flawlessly it ran.
[deleted]
Wow - while looking at the changelog, I found that there's a working btrfs driver for Windows/ReactOS.
https://github.com/maharmstone/btrfs
Of course, Microsoft's driver signing changes make it a very expensive proposition to run on Windows 10, unfortunately.
https://github.com/maharmstone/btrfs
Of course, Microsoft's driver signing changes make it a very expensive proposition to run on Windows 10, unfortunately.
You could sign it yourself and install that certificate into your system. A certificate that will work for everyone would cost about $200/year, which I don't think is too unreasonable.
If the software is open source Microsoft should be good enough to have a pathway for people to get it out for free.
There's relatively cheap code signing [0] certificates specifically for open source.
There might be completely free alternatives too, not sure about that, but EUR 28 is not a lot.
[0] https://www.certum.eu/certum/cert,offer_en_open_source_cs.xm...
[1] http://stackoverflow.com/questions/1177552/code-signing-cert...
[0] https://www.certum.eu/certum/cert,offer_en_open_source_cs.xm...
[1] http://stackoverflow.com/questions/1177552/code-signing-cert...
I think you need an EV certificate from one of 5 providers to sign drivers that works on Windows 10 now.
Yes, you are correct. This has been enforced now since build 1607. So no way to get a driver signed cheaply anymore.
[0] https://blogs.msdn.microsoft.com/windows_hardware_certificat...
[0] https://blogs.msdn.microsoft.com/windows_hardware_certificat...
I think there is something about "getting the driver signed from the dashboard", seems like Microsoft will sign it if it passes WHQL certification. But it is really hard to find any coherent information about how it all works. Seems that everything is kept obscure if you are not a big hardware company. Something as simple as getting a list of which certificates that will work seems practically impossible. The only useful information seems to be from blog posts and forum discussions at osronline.
Of course malware authors don't care much about all this since they just find some old version of a driver with a known vulnerability, so the only it accomplishes is keeping a high barrier to entry.
Of course malware authors don't care much about all this since they just find some old version of a driver with a known vulnerability, so the only it accomplishes is keeping a high barrier to entry.
Microsoft still has some vestigial stupidity from their past culture. It would only help them if they opened up for open source projects like this.
I don't even think signing it with a trusted root certificate will work in this case.
Being able to install from USB Flash should be a top priority as CD's and DVDs are becoming less common and a lot of newer embedded boards (which would be a good target market) don't even have SATA or IDE connectors.
Windows Embedded versions (7 through 10) are impossible to get a licence for without jumping through a shit-tonne of hoops, paperwork and scrutiny (been there recently and its almost like Microsoft don't want your custom even when its genuine) so there is a market but more of us embedded people are moving to Linux so you need to be quick.
Anyway Watching with interest and keep up the progress
Windows Embedded versions (7 through 10) are impossible to get a licence for without jumping through a shit-tonne of hoops, paperwork and scrutiny (been there recently and its almost like Microsoft don't want your custom even when its genuine) so there is a market but more of us embedded people are moving to Linux so you need to be quick.
Anyway Watching with interest and keep up the progress
according to https://reactos.org/wiki/LiveUSB, installation from USB used to be possible, but some USB-stack rewrite commit broke it.
I'm surprised the project is still ongoing. Agree they cooperating with the wine team on their progression?
Yes, the relationship with WINE is described in this page from the ReactOS wiki: https://www.reactos.org/wiki/WINE
On a related note, the Arwinss subproject (which restructures ReactOS a bit to more closely match WINE's architecture) is pretty interesting: https://www.reactos.org/wiki/Arwinss
What does Microsoft think about the ReactOS effort? Looking at the gallery[0] the screenshots are pretty much indistinguishable from Windows 2000-ish (or XP with "Classic" theme) so I assumed they'd at least have something to say about that
[0] = https://reactos.org/gallery
[0] = https://reactos.org/gallery
ReactOS supports themes since before 0.4 series. The gallery is full of old screenshots.
Microsoft doesn't publicly show any signs of attention.
Microsoft doesn't publicly show any signs of attention.
It is certainly impressive that they've modernized their website and made it friendlier.
For a project like this it goes a long way towards staying relevant.
Just a few years ago it still looked like something I made for a school project with quick and dirty hacks in PHP in early 2000s.
Glad to see they took care of it.
For a project like this it goes a long way towards staying relevant.
Just a few years ago it still looked like something I made for a school project with quick and dirty hacks in PHP in early 2000s.
Glad to see they took care of it.
Would be interesting to implement a Linux compatibility layer on top of ReactOS -- just to get the benefit of using binary drivers supplied by manufacturers for Windows. Perhaps Wayland could run on top of ReactOS and benefit from native DirectX drivers?
Picking up coLinux would make sense.
The Linux Unified Kernel project had similar aims of providing binary compatibility for both Linux and Windows applications and drivers. The last release was in 2014.
http://www.longene.org/en/aboutproject.php
http://www.longene.org/en/aboutproject.php
Well, Virtualbox? The stack would still be open source...
This could be a PERFECT "gaming OS", with a little love. So tired of having to use Windows for my gaming machine.
Does this have anything to do with ReactJS or React Native?
No.
I can't quite put it to words, but there's something about this statement that makes me very sad.
I will try to help:
The first feeling that washes over you is a kind of despair that this question was asked at all, as even a cursory view of the information available in the OP, let alone a Google search, would immediately show the project is not related to ReactJS. You find it difficult to imagine the kind of mind that chooses to seek trivial answers from others rather than attempt to answer them on its own. This mind thinks nothing of wasting the time of others to satisfy its own meager curiosities. Surely, in this case, the time taken to ask the question takes almost as long as the research required to answer it.
However, you can't help but notice a deeper level of sadness swelling from below...
It's not merely that the question was trivial. For example, the question "What is this project for?" doesn't seem nearly as sad. Moreover, we notice that if ReactJS was an obscure or unpopular project then this user's question seems rather innocuous.
We see that your deeper sadness stems from the realization that this user is consumed and infatuated with the present trend in software development, whatever that may be. If he knew, he would not care that ReactOS predates ReactJS by nearly two decades. To this user, what exists now is better than what has ever existed before. After all, he imagines, every good idea and enlightened thinking in the history of computing has been brought to the present; these qualities are easily recognized by everyone and they naturally persist and become popular. Therefore, the popular projects are the best humanity has to offer both technically and philosophically. Likewise, obscure, small, or old projects have the opposite quality.
Learning of ReactOS for the first time, he is skeptical of how much of a "good idea" it could really be (surely he would have heard of it by now if it was worth knowing about). So, he attempts to establish the project's merit using the only method available to him: an appeal to popularity. Does this project relate to the current pinnacle of computing achievement, ReactJS? Being a React aficionado, he doesn't suspect it is related but decides to ask anyway just in case he missed something. He wants to know the answer, but ReactOS appears sufficiently unpopular (ie. irrelevant) as to not be worth any appreciable time or effort to discover it for himself. Besides, it is far more agreeable to his psyche that the crowd provide the answer.
There is a subtlety to the user's phrasing that enhances your sadness further. He does not wonder "is it related?" but rather "does this have anything to do with?". One gets the feeling that if only there were just the tiniest bit of relation to ReactJS then this user would be satisfied that ReactOS is indeed a worthy project.
There is a sense that this brand of thinking is 'shallow' or 'myopic'. That it is a brand of thinking that is destined to bring the industry to a state of perpetual mediocrity caused by the incessant following of trends instead of truth. That it is a brand of thinking that causes those under its influence to ignore the search for truth altogether as they are assured that truth is always provided for them, right here, in the present. And when real truth does arrive in those rare moments, it is a brand of thinking that renders it unrecognizable. This is troubling but it's not the sole cause of your depression now.
You are saddened because you know he is one of many.
The first feeling that washes over you is a kind of despair that this question was asked at all, as even a cursory view of the information available in the OP, let alone a Google search, would immediately show the project is not related to ReactJS. You find it difficult to imagine the kind of mind that chooses to seek trivial answers from others rather than attempt to answer them on its own. This mind thinks nothing of wasting the time of others to satisfy its own meager curiosities. Surely, in this case, the time taken to ask the question takes almost as long as the research required to answer it.
However, you can't help but notice a deeper level of sadness swelling from below...
It's not merely that the question was trivial. For example, the question "What is this project for?" doesn't seem nearly as sad. Moreover, we notice that if ReactJS was an obscure or unpopular project then this user's question seems rather innocuous.
We see that your deeper sadness stems from the realization that this user is consumed and infatuated with the present trend in software development, whatever that may be. If he knew, he would not care that ReactOS predates ReactJS by nearly two decades. To this user, what exists now is better than what has ever existed before. After all, he imagines, every good idea and enlightened thinking in the history of computing has been brought to the present; these qualities are easily recognized by everyone and they naturally persist and become popular. Therefore, the popular projects are the best humanity has to offer both technically and philosophically. Likewise, obscure, small, or old projects have the opposite quality.
Learning of ReactOS for the first time, he is skeptical of how much of a "good idea" it could really be (surely he would have heard of it by now if it was worth knowing about). So, he attempts to establish the project's merit using the only method available to him: an appeal to popularity. Does this project relate to the current pinnacle of computing achievement, ReactJS? Being a React aficionado, he doesn't suspect it is related but decides to ask anyway just in case he missed something. He wants to know the answer, but ReactOS appears sufficiently unpopular (ie. irrelevant) as to not be worth any appreciable time or effort to discover it for himself. Besides, it is far more agreeable to his psyche that the crowd provide the answer.
There is a subtlety to the user's phrasing that enhances your sadness further. He does not wonder "is it related?" but rather "does this have anything to do with?". One gets the feeling that if only there were just the tiniest bit of relation to ReactJS then this user would be satisfied that ReactOS is indeed a worthy project.
There is a sense that this brand of thinking is 'shallow' or 'myopic'. That it is a brand of thinking that is destined to bring the industry to a state of perpetual mediocrity caused by the incessant following of trends instead of truth. That it is a brand of thinking that causes those under its influence to ignore the search for truth altogether as they are assured that truth is always provided for them, right here, in the present. And when real truth does arrive in those rare moments, it is a brand of thinking that renders it unrecognizable. This is troubling but it's not the sole cause of your depression now.
You are saddened because you know he is one of many.
I am purely naive of this project and not of another project with a similar name. I thought ReactOS was newer than ReactJS due to the version number.
The analysis was entertaining, but over-speculative.
The analysis was entertaining, but over-speculative.
Perhaps: "My neck beard hurts"??? The guy had an honest question, no point in shunning him.
That doesn't have to be taken as derogatory or insulting. I can relate, I too find it somewhat sad. I don't think that's a problem with the people who don't know, but a systemic problem where cool and noteworthy things of the past are overshadowed by popular current things that share a similar name. Relevant or interesting history is all too quickly forgotten by the general populace.
As an aside, the most recent example of that I've come across, and much more relevant to current events (to US Americans, at least), was during the most recent Hardcore History podcast. It was pointed out that JFK won after he got a bunch of free press because of how photogenic his family was (which whether it was the reason he won or not probably helped quite a bit). Parallels weren't drawn to current events, but it's not like you need a political science degree to see them, which I found really interesting.
As an aside, the most recent example of that I've come across, and much more relevant to current events (to US Americans, at least), was during the most recent Hardcore History podcast. It was pointed out that JFK won after he got a bunch of free press because of how photogenic his family was (which whether it was the reason he won or not probably helped quite a bit). Parallels weren't drawn to current events, but it's not like you need a political science degree to see them, which I found really interesting.
What's wrong with a neck beard?
It runs on a million-year-old (or more) technology which is not developed agile (evolution is the opposite of agile, I would cautiously say?) and most importantly doesn't have a react.js renderer.
Sorry, I know this type of comments are shunned but I couldn't help myself at this point.
Sorry, I know this type of comments are shunned but I couldn't help myself at this point.
Evolution is incredibly agile, while intelligent design follows the waterfall model.
Since intelligent design presupposes that a design was in place before implementation, you'd need a watertight specification to know what you'll need to design. This is pretty much the definition of the waterfall model.
Once you've started with the implementation, you'd not be able to deviate from the spec. If you're God you'd never make an incomplete or incorrect spec, right? By definition that'd be impossible.
With evolution change is introduced iteratively. Each generation contains tweaks and updates, is exposed to a barrage of tests and if it's less adapted to the requirements it's disposed of unceremoniously in favor of a version more suitable. Due to its iterative nature evolution is also able to adapt quickly to changing requirements and good/beneficial features are taken over into the next iteration.
Since intelligent design presupposes that a design was in place before implementation, you'd need a watertight specification to know what you'll need to design. This is pretty much the definition of the waterfall model.
Once you've started with the implementation, you'd not be able to deviate from the spec. If you're God you'd never make an incomplete or incorrect spec, right? By definition that'd be impossible.
With evolution change is introduced iteratively. Each generation contains tweaks and updates, is exposed to a barrage of tests and if it's less adapted to the requirements it's disposed of unceremoniously in favor of a version more suitable. Due to its iterative nature evolution is also able to adapt quickly to changing requirements and good/beneficial features are taken over into the next iteration.
Just the name is similar; these folks are just trying to rewrite Windows, no JS involved.
To play devil's advocate: JS is involved, Microsoft's JScript[0] can be found in ReactOS: https://doxygen.reactos.org/dir_2f81209855df6dbf8ef5ef665906...
[0] https://en.wikipedia.org/wiki/JScript
[0] https://en.wikipedia.org/wiki/JScript
WinJS, on the other hand... You may just have given the Javascript folks an idea!
I would say the branding is similar too, an nucleus with electrons around it.
[deleted](1)
One is a serious, impressive undertaking and the other is a pile of javascript
So you are suggesting that React.js is not a serious, impressive undertaking?
[deleted]
Not in the same way ReactOS is.
What?! React.js has 8180 commits from 942 contributors now. I respect ReactOS guys probably more than most people but come on! Think about the value created! How do you define serious?
Being an operating system automatically puts a project automatically on a different level or do you have a thing against JavaScript?
Being an operating system automatically puts a project automatically on a different level or do you have a thing against JavaScript?
I feel sad that someone would think this. I don't blame you for writing it, many people are ignorant of not too distant software, but still bothers me somehow.
ReactOS is the saddest thing.
Why would anyone do this? For 13 years? Why?
Why would anyone do this? For 13 years? Why?
I for one think there's a _lack_ of serious OS efforts, optimized for various scenarios. I still miss the days of Amiga OS and its multimedia oriented design that gave it a huge lead in these areas on many contemporary competitors. The refreshing BeOS appeared but was unfortunately abandoned and while Haiku is interesting, I wish it had better traction and more attention from the public. :)
These days it's so much about only Windows, macOS, and Linux. And two of those are closed systems. Mobile devices are eating up more use cases by the day too, so I guess the golden era of desktop operating sytems are long passed. However, this sure makes me more sad than ReactOS being a thing!
These days it's so much about only Windows, macOS, and Linux. And two of those are closed systems. Mobile devices are eating up more use cases by the day too, so I guess the golden era of desktop operating sytems are long passed. However, this sure makes me more sad than ReactOS being a thing!
Operating systems are cool.
Just about every popular general purpose operating system is some variation on UNIX. That is sad, just like it would be sad if JavaScript, TypeScript and Coffescript were the only popular programming languages. The only difference in scenarios is that the OS is much more significant and critical than the programming language.
Windows is fundamentally different from Linux and UNIX. ReactOS is a clean room reimplementation of that, bringing NT's many excellent ideas to the open source community. That is a good thing, even if you never get to use it. Don't forget that, just like in every other part of life, different != bad.
Just about every popular general purpose operating system is some variation on UNIX. That is sad, just like it would be sad if JavaScript, TypeScript and Coffescript were the only popular programming languages. The only difference in scenarios is that the OS is much more significant and critical than the programming language.
Windows is fundamentally different from Linux and UNIX. ReactOS is a clean room reimplementation of that, bringing NT's many excellent ideas to the open source community. That is a good thing, even if you never get to use it. Don't forget that, just like in every other part of life, different != bad.
Agree, NT has many excellent ideas. But re-implementing it today seems silly. Are you going to have messages with take two integers only, then stick two 16-bit fields into second one? Look at these articles, do you think anyone should be implementing API like this in 21st century:
https://blogs.msdn.microsoft.com/oldnewthing/20070710-00/?p=... https://blogs.msdn.microsoft.com/oldnewthing/20120913-00/?p=...
I am all for variety. Hurd, L4 -- these are fundamentally different from Unix and very interesting. ReactOS? well if you enjoy debugging windows kernel drivers without source code...
https://blogs.msdn.microsoft.com/oldnewthing/20070710-00/?p=... https://blogs.msdn.microsoft.com/oldnewthing/20120913-00/?p=...
I am all for variety. Hurd, L4 -- these are fundamentally different from Unix and very interesting. ReactOS? well if you enjoy debugging windows kernel drivers without source code...
That's the Win32 executive subsystem, which is only a small (albeit important) part of Windows NT. The ReactOS project aims to get binary driver compatibility with Windows, amongst other things.
And yes, lots of people enjoy reverse engineering things like drivers.
And yes, lots of people enjoy reverse engineering things like drivers.
Just about every popular general purpose operating system is some variation on UNIX.
Including Windows 9x which is based on DOS which is based on Xenix which is based on Unix. I didn't learn this until a few years ago, and it always seems to shock people in tech conversations.
Including Windows 9x which is based on DOS which is based on Xenix which is based on Unix. I didn't learn this until a few years ago, and it always seems to shock people in tech conversations.
DOS isn't based on Xenix at all. It's a clone of CP/M, and CP/M was its own thing for 8-bit CPUs (and later 16-bit).
Whoops, Thank you for that. I think I misinterpreted this thread when it was new, and then never questioned it any further. https://news.ycombinator.com/item?id=7466952
I disagree, I applaud the effort even if in the current state few will use it.
Imagine a few decades from now, Windows has either transformed so much that it can no longer run certain things or it entirely disappears as a platform.
Something like ReactOS could become very useful to running legacy stuff or perhaps the code can be recycled for emulation/vm and legally offered for free. It can also be used on older hardware to bring back Windows applications/gaming, while also keeping it up to date.
Imagine a few decades from now, Windows has either transformed so much that it can no longer run certain things or it entirely disappears as a platform.
Something like ReactOS could become very useful to running legacy stuff or perhaps the code can be recycled for emulation/vm and legally offered for free. It can also be used on older hardware to bring back Windows applications/gaming, while also keeping it up to date.
Surely you would want to support Wine and not ReactOS?
The only advantage of ReactOS over WINE is that ReactOS has Windows 2003 compatible kernel. This means native Windows drivers, and faster emulation of some features.
However, a few decades from now, there will be no devices left which have Windows 2003 drivers. And hopefully CPUs will become faster, so Wine overhead will be negligible. And I doubt all the new devices will have ReactOS drivers.
Rather than keep going on ReactOS, I would much more prefer people making wine better.
The only advantage of ReactOS over WINE is that ReactOS has Windows 2003 compatible kernel. This means native Windows drivers, and faster emulation of some features.
However, a few decades from now, there will be no devices left which have Windows 2003 drivers. And hopefully CPUs will become faster, so Wine overhead will be negligible. And I doubt all the new devices will have ReactOS drivers.
Rather than keep going on ReactOS, I would much more prefer people making wine better.
You should look at the current state of Amiga, while emulation is possible there are only two Amiga like OSes (AmigaOS & MorphOS) and both are closed source/proprietary.
What am I saying is that having an open source OS for Windows, is a huge deal if you are interested in hardware preservation for the future.
Therefore in reply to the original post about the current endeavor being "sad" I would say that it is quite the opposite.
Wine is very important as well, but it is a completely different piece of software in my opinion.
What am I saying is that having an open source OS for Windows, is a huge deal if you are interested in hardware preservation for the future.
Therefore in reply to the original post about the current endeavor being "sad" I would say that it is quite the opposite.
Wine is very important as well, but it is a completely different piece of software in my opinion.
What about AROS?
I agree AROS is very much like AmigaOS 3.x and runs on multiplatforms including old Amiga 68K systems. It even has a Kickstart replacement ROM that is legal to use in Amiga emulators.
HaikuOS aims at BEOS compatibility and also works nicely.
ReactOS I've donated to them so they could reach their 4.x milestone.
If I was some rich billionare or a CEO I'd donate a million dollars to each alternative project.
HaikuOS aims at BEOS compatibility and also works nicely.
ReactOS I've donated to them so they could reach their 4.x milestone.
If I was some rich billionare or a CEO I'd donate a million dollars to each alternative project.
Interesting, I only recently started watching a few YouTubers regarding Amiga stuff, wasn't even aware that AROS existed.
Thanks for correcting me, looks like a pretty cool project will have to look more into it.
Link for anyone else wondering: https://en.wikipedia.org/wiki/AROS_Research_Operating_System
Thanks for correcting me, looks like a pretty cool project will have to look more into it.
Link for anyone else wondering: https://en.wikipedia.org/wiki/AROS_Research_Operating_System
It even runs on original Amiga hardware as well as on emulators and on PCs.
ReactOS and Wine share a lot of code, so supporting one will also support the other.
WINE cannot run most drivers.
Wine by its nature can not run drivers at all. Wine is an emulation platform for running applications. Drivers reside on a lower level and are the OS kernel's job. That is roughly what ReactOS does (and Wine can't) - provides a NT compatible kernel for the Windows drivers.
Windows is pretty focused on backwards compatibility. A large portion of their market comes from the fact that the latest version of Windows can still run 10-20 year old programs written for Windows 98, XP, etc.
This is only true for certain programs.
I've already run into many issues trying to run older software from Windows 98/XP days. For example certain older tools for Quake1 modding don't work properly on anything past Windows XP.
Even something like Photoshop CS2 has certain bugs running under Windows 7.
I've already run into many issues trying to run older software from Windows 98/XP days. For example certain older tools for Quake1 modding don't work properly on anything past Windows XP.
Even something like Photoshop CS2 has certain bugs running under Windows 7.
Don't forget old games. There many that simply don't work on Windoss 7/8/10 without many patchs.
But if you go a little further back, open source has the advantage: It's now easier to run 16-bit Windows programs under Wine on Linux or OS X than it is to run them on a modern Windows machine, and Microsoft has completely ceded the vintage gaming audience to DOSBox.
How can something that was released 13 years ago still be alpha and has 0.4.4 as the version?
I am curious what the story is, is this backed by some company? Was this almost abandoned along the way but picked up?
I am curious what the story is, is this backed by some company? Was this almost abandoned along the way but picked up?
It's a rather huge effort by a fairly small group of people not backed by any corporations [1]. They are aiming for bug-for-bug compatibility with Windows, including the driver model. One of the reasons for it taking so long, though, was it was discovered that a previous developer had written code garnered from disassembling pieces of the Windows kernel. Thus they had to perform a rather long process of auditing all of the code that had already been written to ensure that no Microsoft code was in the codebase.
[1] https://reactos.org/wiki/People_of_ReactOS
[1] https://reactos.org/wiki/People_of_ReactOS
The audit does seem to have been a setback but looks like it didn't take that long relative to the total development time:
https://en.wikipedia.org/wiki/ReactOS#Internal_audit
That is to say, I doubt they'd be running Aero Glass or UWP applications this month even if they hadn't lost time to the audit.
That is to say, I doubt they'd be running Aero Glass or UWP applications this month even if they hadn't lost time to the audit.
That audit was more than just a time stall. It affected the community. Being temporarily prevented from working on the project, many contributors oriented themselves elsewhere. Then there is also the friction caused by the rigor the team had to enforce on accepting new contributions further on. And that wasn't nowhere near the real damage for the project! The real thing was the reticence of serious backing/involvement from wealthy players' part, caused by the fear of something similar (but more serious). That audit can be (and for many was) taken just as a warning.
What a waste of time. ReactOS is illegal anyway. Microsoft must have a million patents on Windows technology, no way you could re-implement Windows without violating them.
Fact is the moment ReactOS becomes a threat to Microsoft's business interests they will sue it out of existence.
Even if you ignore the patents issue, any re-implementation of Windows will inevitably be full of code looking similar to the Microsoft one, even if the authors never looked at the Microsoft code. And as the recent Oculus court case has shown, such a similarity is all Microsoft needs to successfully sue them.
I like the idea of project but I would never contribute to it because of the reality above.
Fact is the moment ReactOS becomes a threat to Microsoft's business interests they will sue it out of existence.
Even if you ignore the patents issue, any re-implementation of Windows will inevitably be full of code looking similar to the Microsoft one, even if the authors never looked at the Microsoft code. And as the recent Oculus court case has shown, such a similarity is all Microsoft needs to successfully sue them.
I like the idea of project but I would never contribute to it because of the reality above.
It sounds like you're commenting within the context of the worst excesses of US IP law, but the project seems to be most closely tied with Germany and Russia. It's definitely not illegal everywhere.
And even within the US, ReactOS in its current state is perfectly safe: Microsoft has nothing to gain by suing them, but they would risk an extremely harmful precedent should they go to trial with their precious IP. Microsoft's patents and copyright FUD are effective tools against corporations, but not loosely organized collections of free software users.
And even within the US, ReactOS in its current state is perfectly safe: Microsoft has nothing to gain by suing them, but they would risk an extremely harmful precedent should they go to trial with their precious IP. Microsoft's patents and copyright FUD are effective tools against corporations, but not loosely organized collections of free software users.
Consider your statement against the fact that Microsoft are currently pushing a Linux subsystem in Windows.
They are doing what is basically a clean-room implementation of the Linux ABI to avoid the GPL.
What stops ReactOS doing the reverse? Microsoft have had 13 years to review the source code for ReactOS and haven't had a problem with it so far.
The only major issue arose internally:
> A claim was made on 17 January 2006, by now former developer Hartmut Birr on the ReactOS developers mailing list (ros-dev) that ReactOS contained code derived from disassembling Microsoft Windows. The code that Birr disputed involved the function BadStack in syscall.S. as well as other unspecified items. Comparing this function to disassembled binaries from Windows XP, Birr argued that the BadStack function was simply copy-pasted from Windows XP, given that they were identical. Alex Ionescu, the author of the code, asserted that while the Windows XP binary in question was indeed disassembled and studied, the code was not merely copy-pasted, but reimplemented; the reason why the functions were identical, Ionescu claimed, was because there was only one possible way to implement the function.[1]
[1]: https://en.wikipedia.org/wiki/ReactOS#Internal_audit
They are doing what is basically a clean-room implementation of the Linux ABI to avoid the GPL.
What stops ReactOS doing the reverse? Microsoft have had 13 years to review the source code for ReactOS and haven't had a problem with it so far.
The only major issue arose internally:
> A claim was made on 17 January 2006, by now former developer Hartmut Birr on the ReactOS developers mailing list (ros-dev) that ReactOS contained code derived from disassembling Microsoft Windows. The code that Birr disputed involved the function BadStack in syscall.S. as well as other unspecified items. Comparing this function to disassembled binaries from Windows XP, Birr argued that the BadStack function was simply copy-pasted from Windows XP, given that they were identical. Alex Ionescu, the author of the code, asserted that while the Windows XP binary in question was indeed disassembled and studied, the code was not merely copy-pasted, but reimplemented; the reason why the functions were identical, Ionescu claimed, was because there was only one possible way to implement the function.[1]
[1]: https://en.wikipedia.org/wiki/ReactOS#Internal_audit
As other posters mentioned, it is a long and complicated story.
It is a pity they did not get traction 10 years ago, when they could have competed with Vista.
Good to see that they are still around, though.
It is a pity they did not get traction 10 years ago, when they could have competed with Vista.
Good to see that they are still around, though.
Microsoft gets it wrong on OS releases roughly about just as often as they get it right. Vista was not a unique pony. Windows Me and Windows 8 also existed. Someday some Windows x will likely also repulse and annoy people.
Windows isn't used because it's necessarily good. Windows repulses on many levels as it is now. If ReactOS would work well on real hardware, I'd ditch Windows right away.
ReactOS is the work of about 100 contributors, most of whom are volunteers. Its goal is to be compatible with an operating system that is the work of thousands of paid programmers. It's amazing to me that ReactOS has progressed as far as it has given its resources.
Many of the comments here are saying they're surprised it's still alive, or that it's sad someone would work on it, or that it should have more features. You're all missing the point.