SoylentNews is people
SoylentNews
posted by
n1
on Wednesday October 21 2015, @09:08PM
from the we-put-a-man-on-the-moon,-but-we-wont-do-that dept.
from the we-put-a-man-on-the-moon,-but-we-wont-do-that dept.
Microsoft's telemetry features in Windows 10 are a privacy advocate's nightmare. Now that Microsoft is trying to back port these "features" into existing versions of Windows, it seems like many of us have no future upgrade path. Sure there is Linux, but I have some older Windows software that I still want to use. ReactOS is still out there, but does not look like there have been any updates in a while.
Does the Soylent community believe it is possible to get this project going full steam to producing a useable alternative for existing Windows users?
This discussion has been archived.
No new comments can be posted.
Ask Soylent: Can We Turn ReactOS into a Viable Alternative to Windows 10?
|
Log In/Create an Account
| Top
| 111 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
If the thunder don't get you, then the lightning will.
(Score: 1) by tftp on Friday October 23 2015, @12:35AM
I do think that if privacy-minded people invest some (not a lot) of effort in ReactOS, they can make it run all the legacy stuff
I don't quite agree. Windows was developed by thousands of coders over 20+ years. It has mountains of legacy code. All that code sits there and sometimes gets called by this or that application. It works on Windows. But it would be all but impossible to make it work on a clone of Windows without having access to the Windows sources and to the sources of the application that does not work.
Such a problem is resolved in the industry by cooperation of MS programmers (who have access to their code) and the ISV programmers (who see theirs.) As ReactOS people are neither of them, and as none of the two above mentioned groups is really interested to help them, you simply have to reverse engineer everything. This is extremely laborious. In many instances it would be technically easier and cheaper to rewrite the necessary Windows application from scratch to run it natively on Linux. As that is rarely done, you can imagine that an even larger effort is not going to happen. Most of software development is a long, boring slog, especially if you are coding taxation algorithms for this year for all 57 states and all counties, not forgetting municipalities which have their own rules - and all the source rules change every year.
Sometimes, though, the technical advantage of rewriting, say, Quicken, is not relevant at all because the new software will not have access to the APIs of all major banks. Then you have to use what you have to use. As I mentioned elsewhere, Windows Embedded might be a suitable platform for running single purpose software installs. (It runs well in a VM.) Another option is to develop a special firewall for Windows 10 (a hardware box that is based on some board with two network interfaces) that reliably isolates Windows 10 from the Internet, but allows select traffic if your QuickBooks or SolidWorks require it. The box would have to be pretty smart, and filter DNS and ICMP and everything else in between that could be used to spy on you.
Naturally, the best way to deal with this problem is to apply customer's pressure to the likes of Autodesk and Adobe, so that they produce their software for Linux. For that to happen Windows 10 must become a real disaster. I do not foresee that happening, as most people out there are oblivious to the facts of spying. They will not mount the necessary boycott. Geeks in corporations will not be able to do much either, as the business requires use of software every day and every hour and every minute, and you cannot tell 10,000 workers that their payroll is not coming because you have a dispute with Microsoft. If you do that, the dispute with MS will immediately become one of your least concerns. At best the boss will tell you to airgap the box - which is just as safe as keeping samples of live Ebola virus in a jar on a top shelf in the lab. Any mistake in cabling, and all these boxes will happily dump gigabytes of the accumulated spy logs into MS's servers faster than you can realize what just happened.
(Score: 1) by massa on Saturday October 24 2015, @03:22PM
Naturally, the best way to deal with this problem is to apply customer's pressure to the likes of Autodesk and Adobe,
but those are not the _real_ problem. The real problem is the tonnes of Win32 VB, Delphi, etc programs internally developed. Where I work we do have two hundred different Win32 executables, all developed in-house, with a small (currently 20) and _aging_ team of devs. The only way you rewrite one of the pieces is when technology gets _really_ in the way (we partially rewrote a dozen or so of those executables when we migrated from Office 97 to BrOffice in 2006) and you just don't have the resources to rewrite them all.
(Score: 1) by tftp on Saturday October 24 2015, @04:18PM
The real problem is the tonnes of Win32 VB, Delphi, etc programs internally developed. Where I work we do have two hundred different Win32 executables, all developed in-house
This is only a problem in relatively large companies. In this one we do not have much of in-house developed code. What we have is written by me and can be ported, if necessary. The problem is that there is nothing on Linux that compares to WPF and .NET in convenience for RAD that would make it appealing to developers with new projects. The GTK# is perhaps the best candidate... but it still trails far behind in most aspects, and development with it will cost more money up front. Data binding alone is a huge time saver.
(Score: 1) by massa on Monday October 26 2015, @11:53PM
We are not a really big shop (3000 employees). The next generation of software that is being produced in house are java web applications and js-rich apps with java webservices backends.
(Score: 1) by tftp on Tuesday October 27 2015, @12:29AM
Your company is 100 times as large as my company. You can accept somewhat higher costs of Java Web applications, as they are balanced by easier deployment and higher portability - which matters, as you have many users. For us it is more practical for now to write the cheapest applications and just use a few PCs that run them locally.