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.

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.

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.

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.

Damn it, Foxconn managed to ship a desktop motherboard that would produce junk ACPI data unless the OS identified itself as Windows on boot.

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.

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.

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.

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.

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.

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.

I hope you don't use web apps, ChromeOS or Android then.

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.

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.

Windows 10, never again.

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).

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.

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.

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.

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).

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)

>>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.

(And don't get me started on Web security, or rather lack thereof: security is not inherent to web apps"; DROP TABLES; --

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.

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.

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.

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'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 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).

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.

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.

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!

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.

ReactOS aims for WinNT series compatibility including hardware drivers. And those driver APIs haven't changed for a decade or more.

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.

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.

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 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.

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. :)

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.

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.

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.

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.

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 :)