Windows or Linux

[dpJudas]

XML is not the problem here, it's just a container.

Yes and no. It of course doesn't affect the fundamental design of msbuild and what you can technically do with it. But syntax very much matters the moment it is expected a human needs to manually adjust it. It has become such a pain for me to decrypt the syntax and its limited documentation that I've personally given up on using as a base for anything.

[Graf Zahl]

Microsoft's project files are actually editable. Apples are not, and they do not use XML.

[dpJudas]

I'm not trying to argue Apple's project files are good or superior at anything. They totally suck. We can pretty much agree on that. My point is just that the XML in msbuild makes it a nightmare to figure out how to actually make more advanced build files than what Visual Studio itself auto generates.

[Graf Zahl]

I've never tried that. All I ever needed to do was adding and removing entries outside the IDE. But it has been a long time since I did that. No need with something like CMake available.

[Matt]

First off, disclosure on the vast majority of my computer use, in descending order of frequency:
- Browsing the Web
- Playing music
- Word processing (most of which outside my day job is manual HTML on a plaintext editor)
- Modding GZDoom
- Playing games (mostly indie stuff, plus Doom/Freedoom and 2 AAA titles, both ported to Linux native, the oldest of which is almost 6 years old)
- Talking to people on instant messaging services (and I generally avoid audiovisual if at all possible, or switch to my phone if necessary)

My experience as a very non-techy person switching from Windows to Linux is that every time I need to set up something new it's a huge pain in the ass for a day or three, but each time it's happened I felt like I learned stuff that could actually be useful later, and if I don't it's because once I get it the way I want it's hella stable and I don't have to touch the thing again for years. With Windows I feel like every few weeks or months I'm going to get ambushed with something arbitrary and stupid (as per Martin's comments above).

That said, my experience with WINE has indeed been a crapshoot - mostly "Crap!" and "Shoot!".

As for ideology, most of us are probably working jobs that we only get paid for because of some horrible nasty thing we as a species would be a lot better off without. If I had my druthers about the stuff that if done right would cost me my job, I'd be on some very cushy welfare (for the sort of person who almost never pays more than $20 (2021 CAD) for a video game and spends 99% of his time on Doom mods anyway).

[Cacodemon345]

As someone who actually tried out Linux, macOS and the *BSDs, I would argue macOS does it the best regarding application usability. Executables for GUI applications aren't shipped out in a totally naked manner; they are encapsulated inside an .app folder and it generally takes only a copy operation to move an application into the system's Application folder. The frameworks system is actually very nice and they can be pre-bundled with the .app folder. ".app" folders also get a nice icon. There's none of those Flatpak/Snap installation bullcrap.

In contrast, executables for Linux and BSD applications are generally shipped out in a naked manner. All Linux/BSD desktop environments I have seen so far (excluding GNUstep) assume that every executable is naked and the general way of installing open-source applications is through the typical way of ./configure, make and make install.

There's also a helloSystem project that is based on FreeBSD which is made for macOS-to-FreeBSD immigrants. But I am not too sure if it will actually succeed.

[Rachael]

For what it's worth, container apps (i.e. Docker, Snap, FlatHub, etc) are meant to address the problem of Linux apps being shipped in a naked manner as you describe. They have issues of their own, but they're a far better solution than relying on system-specific packages and just hoping "everything works" (or, even worse, forcing the end-user without any choice of their own to fully compile every single application they touch, and each library that said application uses... what in the FUCK were the early Linux enthusiasts smoking when they thought that was the best way to interact with Linux?!?)

[Graf Zahl]

For what it's worth, container apps (i.e. Docker, Snap, FlatHub, etc) are meant to address the problem of Linux apps being shipped in a naked manner as you describe. They have issues of their own, but they're a far better solution than relying on system-specific packages and just hoping "everything works" (or, even worse, forcing the end-user without any choice of their own to fully compile every single application they touch, and each library that said application uses...

... and as it just so happened, we got another user having problems with that broken FluidSynth package that makes GZDoom break, but the Snap version worked for them.
These "naked" applications are a huge instability factor and it is for good reasons that no other widespread OS copies this idiotic way of installing apps.

Even on Windows it was once considered "efficient" to share DLLs but it didn't take long to realize that the easiest way to avoid this problem is not to share any non-system code at all.

what in the FUCK were the early Linux enthusiasts smoking when they thought that was the best way to interact with Linux?!?)

I have a good idea about that, and it is very clear that the core group of Linux users still hasn't learned a bit, but that's what happens if you let your actions be driven by ideology alone - such people will never accept the flaws in their way of thinking and make the necessary adjustments - they'd rather run into the next wall at full speed and still go on on their merry way afterward and repeat their mistakes over and over again.

[Cacodemon345]

Linux container solutions still falls short of Apple/NeXT's app container solution; they still have more complicated setup procedures whereas macOS's app container solution generally is a mere matter of copying over the ".app" folder to Applications.

Flatpak, as it stands, still requires the process of adding the repository if it isn't found in the main FlatHub repository by chance. A separate install command it also needed. And you can even get problems when dealing with Flatpak packages, such as the Qt theme being wrong.
Docker seems to require such a procedure too. And the application support is still experimental.
Snap seems to be worse with fucktons of loop devices.
AppImage I am familiar with but seems to be some sort of "statically link everything" solution so it wouldn't work well in regards to patching of security vulnerabilities.

(or, even worse, forcing the end-user without any choice of their own to fully compile every single application they touch, and each library that said application uses... what in the FUCK were the early Linux enthusiasts smoking when they thought that was the best way to interact with Linux?!?)

*cough* NetBSD *cough*.

[Graf Zahl]

AppImage I am familiar with but seems to be some sort of "statically link everything" solution so it wouldn't work well in regards to patching of security vulnerabilities.

All these packagers "statically link everything".
You only have two choices here:

1. Statically link everything so each application is well encapsulated at the drawback of having to do separate updates for security vulnerabilities.
2. Dynamically link everything at the cost of living in a house of cards where some broken revision of an infrequently updated library can break countless applications at will.

Your choice what's the lesser evil. I'd go with #1 at any time.

(or, even worse, forcing the end-user without any choice of their own to fully compile every single application they touch, and each library that said application uses... what in the FUCK were the early Linux enthusiasts smoking when they thought that was the best way to interact with Linux?!?)

*cough* NetBSD *cough*.

It's actually a Unix thing these newer variants just copied verbatim. In the bad old days you had so many differing CPU architectures that it was the only way to distribute software for these systems. What tends to be forgotten is that in the original environment Unix got used in this was far less of an issue than it is now.

[Kappes Buur]

Thank you everyone for your comments.

Some years back I had an installation of SuSE 6.1 on a computer, long defunct by now, but that did not go so well for one reason or another.

It seems that most people switched to Linux (yes I meant that not Unix) because of some misadventure with Windows. My experience with Windows (from 3.1 to 10) over the years has been a positive affair. The free upgrade from 7 to 10, which is still available, went smoothly and I still like 10. From your comments I do not see any advantage switching to Linux, all the programs I use and rely on give no problems. Ergo I stick with Windows.

Thanks again for enlightening me.

[Cacodemon345]

All these packagers "statically link everything".
You only have two choices here:

1. Statically link everything so each application is well encapsulated at the drawback of having to do separate updates for security vulnerabilities.
2. Dynamically link everything at the cost of living in a house of cards where some broken revision of an infrequently updated library can break countless applications at will.

Your choice what's the lesser evil. I'd go with #1 at any time.

My "statically link everything" point was intended to refer to how AppImage "statically links everything" in any executables produced with this technology, as in the executable is not a dynamic one. Certainly doing so is a dream for the DRM-loving game publishers since it would make it harder to patch such executables. And applications can be partially statically linked with the libraries.

Flatpak and other app containers I believe packages the libraries dynamically linked with the application, but I need to check that later.

[iBrokeMyAss]

Neither OS, use templeOS
Literally God's operating system

[Enjay]

Well, if God is using that OS to run the universe, I have several critical bug reports to make.