ReactOS 0.4.14
reactos.org
reactos.org
I'm not criticizing their work or passion, au contraire, it's a spectacular effort the developers are doing, developing an OS with the same API than Windows 2000 from scratch. For me they are giants.
A long time ago, the ReactOS devs gave an example of someone consulting the ReactOS code to understand how some component of the Windows API worked.
Legally they can't copy source code from windows, so they have to do something called block box reverse engineering.
That just means they can't look at the code, but they can try to copy exactly how the code works. This is for legal/copyright reasons.
It's really impressive so far. Windows is a complicated beast that has been built up since the early 90's without much old functionality being thrown out.
https://habr.com/ru/company/reactos/blog/513804/#comment_219...
https://habr.com/ru/company/reactos/blog/303618/comments/#co...
https://habr.com/ru/company/reactos/blog/164225/comments/#co...
https://habr.com/ru/post/208614/comments/#comment_7183314
https://uk.wikipedia.org/wiki/%D0%A4%D1%83%D1%80%D1%88%D0%B5...
https://habr.com/ru/post/208614/comments/#comment_7183314
Where did you find/remember this from?
ReactOS writeups on Habr are always an entertaining read, similar in nature to console emulator change blogs. Over the years, you just remember the often mentioned cash register anecdote.
I find history fascinating, and I have soft spot for retro/vintage technology, so I got to see and touch some interesting stuff. One customer was doing an upgrade in 2015(!!!) from Windows NT 4.0 to Windows XP (!!!). They could not go further, because they were dependent on some piece of hardware whose vendor had gone out of business, leaving behind device drivers that would not work on any Windows after XP.
For this kind of customer, I think, the prospect of an operating system where those device drivers would continue to work while also supporting more recent hardware would be very attractive.
Industrial installations apparently have lifetimes that are far longer than what even "enterprise" operating systems offer, and replacing that Windows NT 4.0 box with a Windows 7 box (let's not even think of anything more recent) is a huge challenge just from the technical perspective. But it gets a lot more hairy when things like certification and compliance to legal requirements come into play, where you cannot just upgrade a box from Windows XP to Windows 10, because then you lose your certification, and re-certifying the installation is a costly and (I assume) tedious procedure.
TL;DR: I believe there could be pretty lucrative market for ReactOS in industrial applications. It would require a fair amount of up-front capital to get going, but if you can provide support for large-scale industrial customer to keep their systems running for twenty or forty years, there has got to be a lot of money in it.
Of course the fact that a company that no longer exists can't support such a configuration doesn't matter because they aren't there anymore to care about any of it.
We expect minimum 20 years from PLCs, and unless parts become unavailable or failures too frequent we would generally go 30 years before replacement.
The PLCs are great, it’s the damned computers and their operating systems that keep needlessly changing our working system.
So we virtualize and air gap.
That's my gripe these days, long term used to be 20+ years. You can still get DL400 series PLC's from Automation Direct (rebranded Koyo) which are from the 90's. Now I see many embedded micros and processors advertised with 10 year long term supply. To me long term is around 20 or more years, basically someones career span. And dont get me started on all this industry 4.0 PC based control crap. Not everything needs millions of lines of Linux kernel to turn a few io points on or off. And the bloated systems that these platforms utilize is nauseating.
If I was the company though I would make sure that them providing the new source would be part of that $20k though or an agreement that when he no longer offers his services personally, regardless of whether he sells the company or not, that he will also release the source code to them if they are unable to negotiate for it upfront.
I think that would be fair and fulfill both parties concerns.
I personally prefer open sourced solutions as well, but in business that just isn't always practical.
I got into free software relatively early in my life and it was like watching a parody film before the original.
Heck I think there's a lot of value in an emulator for old device drivers. Who cares what the source was when you just execute the black box in a highly regulated sandbox? (Note doesn't work for some medical software). I think medicine and astro / aero are the few places that would require full decompilation of an original driver.
In most cases, the limiting factors for lifespan were: 1) Inability to get replacement hardware 2) Inability to find anyone who can understand the source code.
There's really no way around issue #1. Having the software source doesn't really help that much because most of the time they'll use "migrations" every 10-15 years to rewrite the code using updated understanding of how they want the plant to work. Kicking off a SCADA upgrade is used as a wonderful convenient excuse to drive a lot of meetings/paperwork processes to define "How can we improve safety, improve reliability, make life easier for the human operators, etc?"
Nowadays, the thing time-limiting many SCADA installations are licensing for Windows LTSB and PLC/DCS vendor software. Often times newer versions will require new Dell/HPE servers for compatibility. It's expensive, but also not expensive enough to focus on changing.
The main point is that while licensing artificially limits "longevity" of a machine, closed-source does not. Instead, unavailable replacement hardware limits "longevity" more than "closed source" does.
Just look at the price of used serial consoles with Sixel support.
Some hardware can be replaced by software... but not all of it.
I really love the nostalgia this kind of hardware stirs in me, but I am glad I do not have to deal with that kind of trouble. (A few years ago, I read on another forum about an IT guy getting a call on the weekend from a desparate customer looking for an HDD using some standard that predates non-S-ATA... MFM, I think?)
As the biggest vector for malware is not an insecure operating system but user negligency (e.g. by opening malicious attachments in e-mails), it is advisable to have anti-malware software on every machine, regardless of the operating system.
- [0] - https://9to5mac.com/2021/07/19/zero-click-imessage-exploit/
It is also the kind of bugs that tend to get fixed fast once they are discovered.
The biggest attack vector has for many years been user negligence like randomly opening email attachments, following strange links or just click yes on any pop up.
If a system security can be compromised just by clicking strange links and clicking "yes" to pop-ups, then the system is to blame, not the user.
This is victim blaming. Windows have been teaching users to install from third parties since 90's, added auto-run features to removable media, hid files extensions making it difficult to detect files that could do harm, took a decade to implement processes isolation, never added a good package manager and spent years making fun of FLOSS.
Windows users may have a twisted view about security. I personally heard a few of them saying things like "linux is safe because nobody uses it" or "you MUST use an anti-virus". They may sound naive of negligent but in fact, they were carefully trained for decades to behave that way.
EDIT: For people enlightening me about the other ways to install or run binaries on MacOS: thanks for the info! I have really little experience with MacOS, but my GF uses a MacBook and I know it is not as easy to be used in deceptive ways as Windows is. So, considering the other ways to install or run apps on MacOS, to they run the app inside a sandbox? Do they need the user to type a password? Do they run with limited permissions? Do they need explicitly working around notarization to run?
Apps shipped in a .pkg do need to be installed, though. But from an user standpoint the process is almost identical to a Windows installer wizard.
That's wrong. There are multiple ways to distribute/install/run arbitrary programs on a macOS machine:
- Opening a .dmg disk image file and moving the application inside to /Applications will "install" the application
- Opening a .dmg disk image file and directly running the application inside will immediately run it with the current user's permission
- Extracting a .zip archive will yield the application's directory in wherever the zip file is, ready to execute by clicking on it
- Clicking on a .pkg installer will install the program to the path the user chooses (usually /Applications)
- Clicking on a .pkg installer will allow the installer (after a confirmation prompt) to run a "pre-installation" script - Zoom infamously uses that to ease the installation process (https://www.reddit.com/r/programming/comments/ft3ai3/zoom_us...)
The last option is particularly dangerous since users in the admin group usually have passwordless sudo configured, which means that running the pre-installation script in a .pkg gives that script root permissions!
I don’t think that’s true. It’s not on by default in macOS, and to turn it on you have to edit /etc/sudoers which isn’t commonly done on macOS (since sudo permissions can be managed via the checkbox in System Preferences).
in this instance ReactOS is more secure than windows from the era it's replicating thanks to it's software center
? Installing directly from the source instead of from an intermediary is good, not bad. Walled garden and 1P-only app stores are worse than the problems they fix.
> added auto-run features to removable media
Imagine computers just working. Who would want that.
Seriously, Microsoft has a lot to be criticized for, but none of the things in your comment make the list.
How many users did actually install directly from the source and not from a highly visible third party download page that collected and repackaged many programs with some drive by downloads involving adware? I remember falling for that a few times in my youth and even sites like Sourceforge hosting the projects directly ended up hijacking installers for a time.
> Imagine computers just working. Who would want that.
The fix was to pop up a window and asking if you want it to run. Nothing broken about that. Auto running software on an OS where everyone is sys admin by default is not a good idea.
Edit: three responses, zero examples of checks an actual user would do. Two references to the Sony rootkit, which was resolved after intense press by Sony removing the rootkit unconditionally, not by giving the users a choice, because everybody knows users would have clicked yes.
https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...
Want the computer to do something, tell it to it. Inserting a physical media doesn't means you want adware automatically installed.
Then you have Sony which abused auto run to install a rootkit on PCs as part of its copy protection.
How do you expect a normal user to verify the contents of a CD?
If an "autorun" system is implemented, and on by default, MSDs become a hefty vector for circulating malware - it takes little to foresee it. This happened - and out of a really bad idea: "connecting a device" is in general not to be interpreted as "wanting to run software".
About instead the «normal/actual user» (though I do not understand how it is relevant), well, if said user connected a MSD, a data container, and were prompted that some code "wanted" to be executed, the user is supposed to react in terms of "WTF?!". Exceptional classes of cases can be managed - but really, the advantage of avoiding opening the device filesystem and starting an executable is less than negligible. When such behaviour is desired, a system should be specialized for that whole framework (and should revolve around the design concept of "trusting software").
It explores many vulnerabilities: auto-run, hidden extensions, no protection to running not signed binaries, links that are not simple filesystem links…
Windows evolved in a time when solutions for usability problems did not consider security. Now, in the name of compatibility, these vulnerabilities had to be maintained and users were trained to believe that was the right way to do things.
This gave windows users a reputation of being negligent, but most are not. They were trained like dogs to behave like that.
And a lot of vendors that should have been trustworthy ended up taking advantage of it by sneaking unwanted software in with the good stuff. Off the top of my head, Adobe did this. There was a glorious time in the 90s and early oughts where seemingly everything was trying so install another toolbar into IE...
There is plenty here to be critical of.
Linux distributions like Debian barely make the cut for technical users, folks who are used to going to forums and finding alternative packages. Even so, Linux packaging is filled with drama, contradictory standards, alternate sources required for specialized applications, and occasionally downright bad decisions (like shipping insecure CAs). The only way to scale such a model to normal users is the way Apple and Google have done it on their mobile platforms, and frankly, those stores still have a fair amount of malware in them (Android especially - it's sandboxing that is actually useful here, not a package manager) and come with pretty massive anti-competitive downsides.
And some users liked the toolbars. Just like some users like Facebook. Toolbars aren't actually the problem - it's the way they slurp up your data - it's not a problem that needs a technical solution, more of a user education solution (just like Facebook).
GNOME software and similar software are quite close to that.
Flatpak looks reasonably well curated for now.
Most Linux distributions fit for desktop use ship with an "app store" presentation so I think accessibility has been addressed.
>? Installing directly from the source instead of from an intermediary is good, not bad. Walled gard en and 1P-only app stores are worse than the probl ems they fix.
Consider package managers. Debian repos are full o f wonderful useful ad-free FLOSS.
> > added auto-run features to removable media
> Imagine computers just working. Who would want t hat.
Answered on another reply.
> Seriously, Microsoft has a lot to be criticized for, but none of the things in your comment make t he list.
People believing it is part of the reasons of wind ows security flaws. As I said, you was carefully t rained to believe it.
Please try not to be rude. I have decades of experience on Linux. I'm giving my good faith opinion. You won't get far in life by assuming those who disagree with you have been duped / trained into their disagreement.
See my other comment - Debian's packaging is just ok, not good, and it only manages to be sufficient because its users are highly technical and can work around breakage. It also is an ecosystem that is several orders of magnitude smaller and thus easier.
So hopefully ReactOS, while implementing Win2k, includes the XPSP2 mitigations?
XP SP2 had the firewall enabled by default in 2001, which blocked incoming SMB protocol requests and other related ports by default ("file and printer sharing" exception checkbox.)
Additionally, a security patch for Blaster was released July 16 2003. Blaster itself showed up August 11 2003, so you had almost an entire month to evaluate the security patch.
So in order to be affected by Blaster they had to 1. enable sharing of folders on client machines (connecting to servers does not require this firewall exception.) and 2. fail to apply a security patch for a wormable exploit in a timely fashion.
That's not wide-open, that's (if they have control of client machines) IT department failure to act responsibly.
I remember, around 2003, laptops getting infected just by getting connected to the Internet. It can be appropriate to use the expression «a wide-open door for malware».
2. I’m pretty that I’ve got it wrong and it was Sasser, not Blaster.
And how pray tell do those malicious emails take over a system if an insecure OS isn’t at fault too?
When it has, fewer services are running at startup.
Generally, it doesn't copy the atrocious early security default configs that were later changed.
Don't believe it ships with an old browser or email client, so ~60% of potential issues gone right there.
> ReactOS looks-like Windows
But even Windows does not look like Windows anymore.
I wonder how much of the newer Wine gaming stuff could be used for ReactOS
I assume it's because of the backward compatibility. But it also would be because of the fact that to implement 5.2 APIs, they need XDDM. Skipping right from 5.2 to 6.2 would cause a non operational state for a long time due to lack of APIs implemented and the WDDM. Windows 2000 had about 1400 full time devs and 800 full time testers. And ReactOS probably have 10-20 active contributors maybe. I don't know the numbers but there is a huge difference. And I can understand the requirements of an incremental development approach.