Lindows made a splash in 2001-2002 and its purpose was to bridge the gap and offer proper support for Windows applications on Linux via a 'click and run' service.
After Microsoft sued them and they changed their name, the bubble was burst and when Ubuntu appeared its niche as a beginner distro ebbed away.
I was surprised to hear it was still alive via a Michael MJD video a month or two ago.
This is the first time I've heard of that [Ubuntu?] distro. Would be curious to hear how it's working out, from anyone using it as their daily driver, and how it compares to Mint etc. on the Linux side of things.
My mum was using it as a daily-driver for all your average user PC stuff. It was decent, easily to use and more user-friendly than Mint, IMO – until an update borked it completely, after two years of running. Unfortunately post-update-breakages is something that's typical of Ubuntu and most Ubuntu-based distros, so it's not really surprising [1]. I've since switched her to an immutable distro (Aurora [2]) and it's been rock solid.
That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do.
It can also be achieved with static linking and by shipping all needed library and using a shell script loader that sets LD_LIBRARY_PATH.
Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an older Debian/Fedora that ships the needed libraries to the packaging repositories and running apt/dnf should work in theory, although unfortunately might not in practice due to the general incompetence of programmers and distribution maintainers.
Win32 is obviously not appropriate for GNU/Linux applications, and you also have the same dependency problem here, with the same solution (ship a whole Wine prefix, or maybe ship a bunch of DLLs).
> That makes no sense: shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux, which is what flatpak/snap/appimage do.
True, but sad. The way to achieve compatibility on Linux is to distribute applications in the form of what are essentially tarballs of entire Linux systems. This is the "fuck it" solution.
Of course I suppose it's not unusual for Windows stuff to be statically linked or to ship every DLL with the installer "just in case." This is also a "fuck it" solution.
> to distribute applications in the form of what are essentially tarballs of entire Linux systems.
No so bad when Linux ran from a floppy with 2Mb of RAM. Sadly every library just got bigger and bigger without any practical way to generate a lighter application specific version.
If Linux userspace had libraries with stable ABI, you could just tar or zip binaries and they would work. You wouldn't need to bundle system layer. This is how you deploy server apps on Windows Server systems. You just unpack and they work.
It is not a packaging problem. It is a system design problem. Linux ecosystem simply isn't nice for binary distribution except the kernel, mostly.
Linux feels a bit different since the complete system is not controlled by a single vendor. You have multiple distributions with their own kernel versions, libc versions, library dependencies, etc.
Mac OS has solved this but that is obviously a single vendor. FreeBSD has decent backwards compatibility (through the -compat packages), but that is also a single vendor.
-compat packages exist on fedora-like systems too, usually allowing it older versions to run. I can't say how far back, but RHEL usually has current version
- 1 for -compat packages.
> Linux feels a bit different since the complete system is not controlled by a single vendor. You have multiple distributions with their own kernel versions, libc versions, library dependencies, etc.
No, AFAICS that can't be it. The problem is that all those libraries (libc and others?) change all the time, and aren't backwards-compatible with earlier versions of themselves. If they were backwards-compatible, you could just make sure to have the newest one any of your applications needs, and everything would work.
Packaging is “hard” but mobile and app stores do it.
They do it by having standards in the OS, partial containerization, and above all: applications are not installed “on” the OS. They are self contained. They are also jailed and interact via APIs that grant them permissions or allow them to do things by proxy. This doesn’t just help with security but also with modularity. There is no such thing as an “installer” really.
The idea of an app being installed at a bunch of locations across a system is something that really must die. It’s a legacy holdover from old PC and/or special snowflake Unix server days when there were just not many machines in the world and every one had its loving admin. Things were also less complex back then. It was easy for an admin or PC owner to stroll around the filesystem and see everything. Now even my Mac laptop has thousands of processes and a gigantic filesystem larger than a huge UNIX server in the 90s.
I can't think of a single thing that would kill the bit last of joy I take in computing more. If I woke up in such a world, I'd immediately look to reimplement Linux in an app and proceed to totally ignore the host OS.
> shipping all dependencies (e.g. shipping a container image) gives perfect binary compatibility on Linux
That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific.
In contrast, it’s impossible to run modern Windows without working Direct3D 11.0 because dwm.exe desktop compositor requires it. If a software consumes Direct3D 11.0 and doesn’t require any optional features (for example, FP64 math support in shaders is an optional feature, but sticking to the required set of features is not very limiting in practice unless you need to support very old GPUs which don’t implement feature level 11.0), will run on any modern Windows. Surprisingly, it will also run on Linux systems which support Wine: without Vulkan-capable GPU will be slow but should still work due to Lavapipe, which is a Linux equivalent of microsoft’s WARP they use on Windows computers without hardware 3D GPU.
Note that this also underlines that the post's premise of Windows having a simple stable ABI - win32 sure is stable, but that's not what applications are coded against anymore.
Sure, you can run a 20 year old app, but that is not the same as a current app still working in 20 years, or even 5.
> that's not what applications are coded against anymore
Not sure I follow. Sure, most modern programs are not using old-school WinAPI with GDI, but the stuff they added later is also rather stable. For example, the Chromium-based browser I’m looking at uses Direct3D 11 for graphics. It implements a few abstraction layers on top (ANGLE, Skia) but these are parts of the browser not the OS.
I view all that modern stuff like Direct3D, Direct2D, DirectWrite, Media Foundation as simply newer parts of the WinAPI. Pretty sure Microsoft will continue to support them for long time. For example, they can’t even deprecate the 23 years old DirectX 9 because still widely used, e.g. current version of Microsoft’s own WPF GUI framework relies on Direct3D 9 for graphics.
I agree. On Linux (and Mac really), new APIs replace old ones and old binaries stop working.
On Windows, new layers are applied over the old. There is DirectX 9-12. New binaries may use 12 but the ones still using 9 are perfectly happy. Things like .NET work the same. You can have multiple apps installed relying on different .NET versions.
It's not necessarily the same code, though. But COM is nice for a stable ABI like that - so long as you consistently version your interfaces, the apps can just QueryInterface for the old one they need and know that it's there, even if it's just a thin wrapper around the new stuff.
These are however the same on Linux - mesa may change, but what the app uses is OpenGL and GLX. A more modern app might use EGL instead of GLX, or have switched to Vulkan, but that doesn't break old code.
You can also run an old mesa from the time the app was built if it supports your newer hardware, but I'd rather consider that to be part of the platform the same way you'd consider the DirectX libraries to be part of windows.
Ah apologies, you're right - I was tired and read things wrong.
But I suspect "GL issues" (i.e., GL API stability) is being mixed together with e.g. mesa issues if mesa is being bundled inside the app/in a "flatpak SDK" instead of being treated as a system library akin to what you would do with DirectX.
Mesa contains your graphics driver and window system integrations, so when the system changes so must mesa change - but the ABI exposed to clients does not change, other than new features being added.
> Note that this also underlines that the post's premise of Windows having a simple stable ABI - win32 sure is stable, but that's not what applications are coded against anymore.
It's true, but this touches on another point they made: what apps code to is other dynamically linked libraries. The kind that wine (or other host environments) can provide, without needing to mess with the kernel.
That's what apps are supposed to code to. When it comes to games and especially anti-cheat that's not always the case though and so Wine does have to handle direct system calls, which needs support from the kernel (at least to not be unusably slow).
Win32 is quite extensive for an OS API. It covers the space from low-level stuff like syscalls and page allocation and all the way up to localization, simple media access and GUI. So everything from glibc, libsystemd, libpam to libalsa and egl on Linux side. And it is all stable.
Microsoft also provides quite good stability for DirectX and other extension APIs. You can still run old .Net apps without issues as long as they didn't pull a Hyrum's Law on you and depended on apparent behavior.
Sure, win32 contains GUI bits, but modern apps do not use those GUI bits.
OpenGL and Vulkan ABIs are also stable on Linux, provided by mesa. The post is pretty focused on the simplicity of win32 though, which is what I'm refuting as being as relevant today for new apps.
> As long as they didn't pull a Hyrum's Law on you
It is guaranteed that they "pull a Hyrum's Law", the question is just what apparent behavior they relied on.
> Sure, win32 contains GUI bits, but modern apps do not use those GUI bits.
Which is probably why so many "modern apps" look just like "modern" Web pages running on the desktop... i.e, why so many "modern apps" suck. They freaking should use those GUI bits.
Question, from an application developer's perspective: What is the implication in regards to cross-platform Vulkan applications? I.e., my 3D applications all use Vulkan, and they compile and just work on both Windows, and Ubuntu. Does this mean that on other or older distros, they might not work?
I don’t think the support depends on distros much, I think the main variable is hardware. If you have a desktop PC bought in the last ~5 years the support should be OK, for the hardware older than that the support is not guaranteed. GeForce GT 730 (launched in 2014) doesn’t support Vulkan, Intel only supports Vulkan on Windows starting from Skylake launched in 2015.
Then there’re quality issues. If you search internets for “Windows Vulkan issue” you’ll find many end users with crashing games, game developers with crashing game engines https://github.com/godotengine/godot/issues/100807 recommendations to update drivers or disable some Vulkan layers in registry, etc.
On Windows, Vulkan is simply not as reliable as D3D. The reasons include market share, D3D being a requirement to render the desktop, D3D runtime being a part of the OS supported by Microsoft (Vulkan relies solely on GPU vendors), and D3D being older (first version of VK spec released in 2016, D3D11 is from 2009).
Another thing, on Linux, the situation with Vulkan support is less than ideal for mobile and embedded systems. Some embedded ARM SoCs only support GLES 3.1 (which BTW is not too far from D3D 11.0 feature-wise) but not Vulkan.
Agree overall. Just want to point out that Vulkan works on Intel Haswell. I have a 2013 MacBook Air and a 2013 Mac Pro that both have Haswell. Linux kernel 6.14 actually includes an Haswell Vulkan update from Intel themselves.
> Does this mean that on other or older distros, they might not work
Yep exactly. While Vulkan API is well defined and mostly stable, there is no guarantee in Linux implementation will also be stable. Moreover Khronos graphics APIs only deal with the stuff after you allocated a buffer and did all the handshakes with the OS and GPU drivers. On Linux none of those have API / ABI / runtime configuration stability guarantees. Basically it works until only one of the libraries in the chain breaks the compatibility.
This is BS. Vulkan buffers are allocated with Vulkan functions. Window system integration is also provided by window-system specific Vulkan extensions just like it was with WGL/GLX/EGL etc. These are all well defined and stable.
That depends how you build you program and what other dependencies you pull in. But as far as Vulkan is concerned your program should run on any distro that is as least as new as the one you build on (talking about ABI, runtime requirements depend on hardware but don't depend on the system you build on).
This is FUD. There isn't a single real desktop Linux distribution without OpenGL support. The basic OpenGL API hasn't changed ever, it's just been extended. It has even more backwards compatibility than Direct3D. Sure you can deliberately build a distro with only Vulkan or GLES (a mobile API) if you want to be an ass but the same goes for Windows. Same for X11 - Xlib works everywhere even any Wayland-only distribution that gives a single crap about running binary distributed software.
Now GUI toolkits are more of an issue. That's annoying for some programs, many others do their own thing anyway.
glibc really doesn't want to be statically linked so if you go this route your option is to ship another libc. It does work but comes with its own problems— mostly revolving around nss.
And NSS defines how usernames are matched to uids, how DNS works, how localization works and so on. If you're changing libc you need to ship an entire distro as well since it will not use the system libraries of a glibc distro correctly.
> Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an older Debian/Fedora that ships the needed libraries to the packaging repositories and running apt/dnf should work in theory, although unfortunately might not in practice due to the general incompetence of programmers and distribution maintainers.
Got it. So everything is properly designed but somehow there's a lot of general incompetence preventing it from working. I'm pretty sure the principle of engineering design is to make things work in the face of incompetence by others.
And while glibc is backward compatible & that generally does work, glibc is NOT forward compatible which is a huge problem - it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on. Whereas on Mac & Windows it's pretty easy to build applications on my up-to-date system targeting older variants.
> And while glibc is backward compatible & that generally does work, glibc is NOT forward compatible which is a huge problem - it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on.
Isn’t this easily solved by building in a container? Something a lot of people do anyway - I do it all the time because it insulates the build from changes in the underlying build agents - if the CI team decides to upgrade the build agent OS to a new release next month or migrate them to a different distro, building in a container (mostly) isolates my build job from that change, doing it directly on the agents exposes it to them
> So everything is properly designed but somehow there's a lot of general incompetence preventing it from working.
But it is working, actually:
* If you update your distro with binaries from apt, yum, zypper etc. - they work.
* If you download statically-linked binaries - they work.
* If you download Snaps/Flatpak, they work.
> it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on.
Only if you want to distribute a dynamically-linked binary without its dependencies. And even then - you have to build with a toolchain for that distro, not with that distro itself.
> Only if you want to distribute a dynamically-linked binary
Even statically linked code tends to be dynamically linked against glibc. You’ve basically said “it works but only if you use the package manager in your OS”. In other words, it’s broken and hostile for commercial 3p binary distribution which explains the state of commercial 3p binary ecosystem on Linux (there’s more to it than just that, but being actively hostile to making it easy to distribute software to your platform is a compounding factor).
I really dislike snaps/flat pack as they’re distro specific and overkill if I’m statically linking and my only dynamic dependency is glibc.
As for being overkill, surely you can see the advantage of having a single uniform distribution format from the end user's perspective? Which, sure, might be overkill for your case (although app isolation isn't just about dependencies), but the important thing is that it is a working solution that you can use, and users only need to know how to install and manage them.
You have to install the flat pack runtime to begin with so that’s one obstacle for distribution. And it also doesn’t really isolate as much as you’d like to believe - eg dealing with audio will still be a mess because there’s like 4 different major audio interfaces. And now I have to host a flat pack repo and get the user to add my repo if it’s proprietary software. It’s really nowhere near as smooth and simple as on Windows/Mac/Android/ios.
The reason to host a repo regardless is to enable easy auto-updates - and I don't think you can call this bit "smooth and simple" on Windows and Mac, what with most apps each doing their own thing for updates. Unless you use the app store, but then that's exactly the same as repos...
Glibc is fantastically stable and backwards compatible in all the same ways , and I think you're overstating how backwards compatible windows is as well. Microsoft has the exact same dynamic library issues that Linux does via it's Microsoft Visual C++ distrubutables (as one example). Likewise, there's forwards compatibility issues on Windows as well (if you build a program in Windows 11 you'll have a hard time running that on windows XP/Vista for a huge number of reasons).
If you build a statically linked program with only glibc dynamically linked, and you do that on Linux from 2005,then that program should run exactly the same today on Linux. The same is true for Windows software.
Im pretty sure it’s safe to distribute Windows 11 built binaries to windows 7 and windows 10 if it’s a valid target set in Visual Studio. The c++ runtime is its own thing because of a combination of c++ BS (no stable runtime) and c++ isn’t an official part of Windows. It’s a developer tool they offer. But you can statically link the c++ runtime in which case you can build with the latest runtime on Windows 11 and distribute to an older Windows.
Linux is the only space where you have to literally do your build on an old snapshot of a distro with an old glibc so that you can distribute said software. If you’re in c++ land you’re in for a world of hurt because the version of the language is now constrained to whatever was available at the time that old distro from 5+ years ago snapshotted unless you build a newer compiler yourself from scratch. With Rust at least this is much easier since they build their toolchain on an old version of Linux and thus their binaries are similarly easily distributed and the latest Rust compiler is trivially easy to obtain on old Linux distros.
Source: I’m literally doing this today for my day job
You can also build a cross-compiler to target an older glibc, you are not limited to the distro-provided toolchain. This also allows to to use newer C++ features (with exceptions) as those mostly depend on the GCC version and not glibc version. Of course the supported range of glibc version varies with gcc version, just like visual studio doesn't support XP anymore - the difference is that if you are sufficiently motivated you can patch gcc.
Yeah maybe I should just be complaining that the Rust tool chain (or rather distros) should be including old versions of prebuilt glibc to link against?
Windows toolchain provides the import libraries to link with, and these are basically just tables mapping function names to indices in the DLL export table. So long as you don't actually use the new functions, an app linked against a modern Windows SDK will run just fine on old Windows, unlike the situation with glibc.
Almost - with glibc your code uses functions like memcpy but you end up linking against symbols like memcpy@GLIBC_2.14 which is the version of memcpy added in glibc 2.14 and which won't be present in older versions. Which symbol version your calls use depends on the glibc version you build against - generally it's the most recent version of that particular function. For the Win32 this is rarely the case and instead you have to explicitly opt in to newer functions with fixed semantics.
Still, to reliably target older Windows versions you need to tell your toolchain what to target. The Windows SDK also lets you specify the Windows version you want to target via WINVER / _WIN32_WINNT macros which make it harder to accidentally use unsupported functions. Similarly, the compilers and linkers for Windows have options to specify the minimum Windows version recorded in the final binary and which libraries to link against (classic win32 dlls or ucrt). Unfortunately there is no such mechanism to specify target version for glibc/gcc and you have you either build against older glibc versions or rely on third-party headers. Both solutions are workable and allow you to create binaries with a wide range of glibc version compatibility but they are not as ideal as direct support in the toolchain would be.
I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.
1. GNU libc is an exception in the world of compatibility.
2. You can't just dump a bunch of GTK libraries next to the binary and expect it to work. These libraries often expect very specific file system layouts.
That is solved by containerization (cgroups and namespaces), which is initially popularized by docker, which appeared about 12 years ago. And newer things like flatpak and snap are just bells and whistles over this.
In 2005 the hot new Windows technology was .NET Framework 1.1 or 2.0. You can't just dump Framework 1.1's libraries next to the binary and expect it to work either, it needs to be installed properly.
What are you talking about??? .NET never got abandoned! If anything its hit a very high bar now. Its one of the top frameworks to build an app across platforms.
They're referring to (I hope), the .NET Framework which is Windows-only and the last/latest version being 4.8. It should live a very long life, as Microsoft server infrastructure is built on it (SharePoint/Exchange).
The .NET Framework 1.x runtime is no longer supported, and the .NET Framework 2.0 runtime (used by v2.0-3.5 applications) won’t be supported after 2029. They are slowly abandoning support for old apps.
(Yes, if you fiddle with the config file they might work on the .NET 4.0 runtime. But that’s not something a typical user can/will do.)
It keeps classes for backward compatibility, not assemblies. Some code still didn't migrate from them to not cause gratuitous churn. Also it's web scale, because untyped collections can hold values of different types just like javascript.
We're clearly not living in the same universe here.
glibc backward compatibility is horrible.
Every. Single. Time. I try to use an old binary on a modern distro, it bombs, usually with some incomprehensible error message with GLIBC in all caps in it.
And these days, you can't even link glibc statically, when you try it barks at you with vehemence.
As a matter of fact, as pointed out in the article, this particular shortcoming of glibc completely negates the work done by Linus to keep userland backward compatible at all cost.
Please post actual issues encountered, including non-paraphrased errors instead of FUD.
And if you want to statically link your libc there is nothing forcing you to use glibc. You're only stuck with glibc (and even then you don't actually need to use any functions from it yourself) if you need dynamic linnking for e.g. OpenGL/Vulkan. Also, glibc wasn't designed for static linking even before they put in safeguards against that.
> NOTE: I am not against Apple or Microsoft. They have amazing engineers! I don't think they're being malicious. Rather, I think the incentives for these companies are improperly aligned.
Improperly aligned incentives? Who gets to say what that is?
Is it "improper" to maximize profit per their own board's guidelines?
I have a feeling OP has some predefined notion of nobility they expect people to somehow operate under.
> Is it "improper" to maximize profit per their own board's guidelines?
From the standpoint of the end user the incentives are improperly aligned. If they had made hammers they would have included licence agreements for their use with specific types of nails and actively prevented users from using competitor's nails. They also would have made sure yesterday's hammer would not be sufficient to hammer in today's nail, they would have added camera's to observe what the user was doing so as to sell 'targeted' advertising - during which the hammer would not strike any nails but would sing like the singing sword in Who Framed Roger Rabbit - and they would have made sure that no matter how agile the user was with his hammer the thing would never be 100% reliable.
Of course hammers are far less complex than computers and operating systems. Maybe this is because they're made by tool manufacturers and not by tech companies, maybe it is because they're old tech. A modern hammer is what Ford would have produced if he had listened to his customers who asked him for a faster horse so maybe there is a whole world of construction efficiency waiting for the Henry Ford of Hammersmiths. Or, maybe - probably - sometimes it is better to get that faster horse, that titanium hammer or that free software operating system which works for you and nobody else.
This would be an option if the Linux userland wasn't a mish-mash of unconnected developers with their own practices and release cadence. It's why we have LTS distros where the company will put in the massive amount of work to preserve binary compatibility.
But the trade-off is that the software you have in your repos will be really old. At the end your RHEL support cycle libs will be a decade out of date.
Like a lot of things in any OS it depends how far off the beaten track you go. I think there's a lot of gaming newcomers to linux where their main exposure for wine is via steam, which generally wraps things up for them and hides the details behind their launcher. If you need to go diving into the details for compatibility or you'd like to separate things out with prefixes then it's definitely much less polished and elegant, but I'd argue you could say the same thing about windows for compatibility with some old games or sites like PCGamingWiki.com would be a lot smaller as the combinations of windows (or DOS)+drivers+hardware over the years hasn't resulted in perfect consistent compatibility.
The article's main premise isn't bad, but it's full of weird technical inaccuracies.
At certain points he talks about syscalls, libc (I'm assuming glibc), PE vs. ELF, and an 'ABI'. Those are all different things, and IIUC all are fairly stable on Linux, what isn't stable is userspace libraries such as GTK and QT. So, what are we talking about?
There's also statements like this, which, I'm not a kernel developer but they sound a little to good to be true:
> A small modification to the "exec" family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
He goes on to talk about Gatekeeper (which you can disable), Recall (which is disabled by default), and signing in with a Microsoft account (which can be easily bypassed, though he linked an article saying they might remove it). He also talks about "scanning your computer for illegal files", I don't know what this is referring to, but the only thing I could find on Google was Apple's iCloud CSAM scanning thing. That's not on your computer, and it got so much backlash that it was cancelled.
There's plenty of stuff to criticize about these companies and their services without being dramatic, and the idea of Linux having more compatibility with Win32 via Wine isn't bad.
> > There's also statements like this, which, I'm not a kernel developer but they sound a little to good to be true:
> A small modification to the "exec" family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
That isn't "too good to be true", it's so good it is false – no kernel modification is required because the Linux kernel already supports this via binfmt_misc. You just need to configure it. And depending on how you installed Wine, you may find it has even already been configured for you.
So... this already exists. Valve already essentially sells this as a product. Folks know that, right? The Steam Deck is a linux box running wine executables as the native app environment. The fact that the money apps are all "games" doesn't change the technology.
How they do it is by shipping a franken-ubuntu14 as the "steam runtime" for native Linux games. Not a terrible solution but not exactly ideal for general purpose software where games mostly keep to themselves. Their work on Proton is amazing though.
- Steam Runtime: A set of common libraries Linux native games target for multi-distro compatibility, I believe this still uses Ubuntu as the upstream
- Steam OS: An arch based distro pre-configured to run Steam out of the box, used by the Steam Deck, comes with extra stuff like gamescope to smooth over various issues other distros have with VRR, HDR, etc.
No[1], but you can launch a windows executable natively, link against DLLs in a compatible way, thunk between 32 and 64 bit as needed, access the Linux filesystem, network and IPC environment using native APIs, integrate with things like .NET and msvc runtimes, access native-speed DirectX emulation, etc...
Yes, you'd have to buff and polish it. But "paint some chrome on it" is hardly much of a blog post.
[1] Actually, are you sure the answer is "no" here? I wouldn't be at all shocked if some enterprising geek had source on github implementing a MSI extractor and installer
> Imagine we made a new Linux distro. This distro would provide a desktop environment that looks close enough to Windows that a Windows user could use it without training. You could install and run Windows applications exactly as you do on Windows; no extra work needed.
Maybe we should fund ReactOS for end-user applications. Win32 is well established and isn't going anywhere. So why not take advantage of Microsoft's API design effort
People who like and need Windows apps, people who want to have an out of the box experience when running those apps, people who don't like the loss of performance when using Wine, people who generally like Windows but want to have an alternative in case that dislike where Microsoft is heading with Windows development.
That is a lot of people, me included. But since Windows experience is somehow still tolerable, there aren't many willing to invest time or money into ReactOS. There are no corporate sponsors since you don't make money from desktop OS-es unless you use them to sell expensive hardware like Apple did.
Someone like Valve could have sponsored it but they though they can reach their goals with Wine while spending much less money.
Another sponsor for ReactOS can be a state actor like China or EU, somebody with deep pockets who wants and needs to run Windows software but don't want their desktop to be under US control.
Any people who prefer Windows' primary design choices over Unix ones too.
> Another sponsor for ReactOS can be a state actor like China or EU, somebody with deep pockets who wants and needs to run Windows software but don't want their desktop to be under US control.
I would love to see EU to do this actually. Maybe we should pitch this as citizens.
ReactOS is too buggy to be used as a daily driver for your operating system, but it's awesome as Windows Kernel reference code. You want to know what a Kernel-mode function does? Ether read the documentation, or look at what ReactOS does. (Yes, leaked Windows code exists too, and it's even on freakin Microsoft-owned-Github of all places, but you can't legally look at that stuff!)
I played with ReactOS a few months ago in a virtual machine, and even in that relatively controlled environment it still crashed a lot.
I’ve been hoping that ReactOS would be the thing that truly murdered Microsoft Windows, but that really hasn’t happened; it seems like that’s happening via combination of a lot of applications moving to the browser and compatibility layers like Wine and Proton.
Linux has pretty good driver support nowadays, and outside of drivers Wine will have as good or better support for applications, so I am not completely sure what that says about the future of ReactOS.
I don't think a new distro is needed. Most commonly used windows apps can be made to work through wine, but the hacks used to make one app work can break others and vice versa. Similarly, everyone needs to play around with settings individually to get things to work. What works on one person's machine might not work on another's, because there's no consistency in, effectively, configuration.
The simplest solution, to me, is to just distribute containers (or some other sandbox) with wine in it, and the necessary shenanigans to get the windows program (just the one) working in the container, and just distribute that. Everyone gets the same artifact, and it always works. No more dicking around with wine settings, because it's baked in for whatever the software is.
Yes, this is tremendously space inefficient, so the next step would be a way of slimming wine down for container usage.
The only real barrier to this system is licensing and software anti patterns. You might have to do some dark magic to install the software in the container in the first place.
> Windows application submissions that are using Wine or any submissions that aren't native to Linux desktop and is using some emulation or translation layer will only be accepted if they are submitted officially by upstream with the intention of maintaining it in official capacity.
Although, I am curious why; they don't seem to have a general problem with unofficial packages, so I'm not sure why a translation layer makes any difference. It doesn't seem different than happening to use any other runtime (ex. nothing is said about Java or .net).
Probably because it's implicitly pirated. No one is sharing windows freeware this way, because there's no demand for it. It'll be MS Office, Photoshop, CAD, etc. -- stuff for which there's still no good OSS alternative, and for which the barrier to entry is high.
It would take a large organization with enough connections to cut through this. You'd probably need to cut a deal so you could distribute their software, and you'd need to provide a mechanism for users to be able to make purchases. Even then, there are various licensing challenges, because you would be distributing the same install, so thousands (or millions) of "installs" would effectively have the same serial or license number.
It's nontrivial, but the basic idea is straightforward and doable. The challenge is how windows software is distributed and licensed, not anything technical.
I am just thinking out loud. Wouldn't it be better then to just share the reproducible recipes similar to sharing Dockerfiles? For wine, specifically, it could be similar to just using FROM wine-1.23. As long as we keep the recipes maintained and "pinned" to their old dependencies.
I think this could work as a translation layer because containers already abstract away everything on syscall level.
There must be just a GUI for that, which can create multiple sandboxes easily, per application, and remember what you configured and installed there (and add it to the Winefile).
In regards to the sharing serials problem: You can easily diff the .reg file that wine adds there and if anything pops out in \\software, you can assume this is a custom field and offer it as an environment variable for the container?
They do cover that in
https://docs.flathub.org/docs/for-app-authors/requirements#l... , but I don't buy it in the general case because Windows isn't synonymous with proprietary isn't synonymous with non-redistributable licenses. Sure, I doubt there's a legal way to ship Microsoft Office on flathub, but there are plenty of shareware programs that I think would be fine (though IANAL, ofc) right up to FOSS that happens to target Windows. For instance, Notepad++ is GPLv3[0] and WINE platinum rating[1]; why shouldn't it be on flathub?
I don’t think it’s necessarily that either. They probably just want some guarantees that the app will keep working, instead of someone submitting 100s of wine apps and having them break eventually.
They're just trying to prioritize linux applications, without preventing developers who want to support linux through wine from doing so.
The key difference is that applications ran under wine will always have some subtle quirks and misbehaviors that break the usability, that can be worked around by the dev when given the chance to.
If you change a lot of things about a Linux system, then you're making a new distro.
Half of this incompatibility is because Linux is flexible, anyway. My system is different from your system, and did anyone test on both? If you want a more stable ABI then you need a more stable system.
You wouldn't have to change anything about the underlying system, which is the point. Containers work the same regardless of the underlying system, so they get around the various differences in everyone's individual machine. I use identical containers routinely on Fedora and Ubuntu systems at home without any issue, and I produce containers for RHEL and various other systems at work. Half the point of containers is eliminating the variability between dev systems and deployment.
Rather than everyone having to get the software working on their machine, you would get it working once in the container, and then just distribute that.
Containers work because your kernel is close to identical, and ship their own copy of everything else making them bloated, and incompatible at a user-mode level (no graphics drivers!). If my kernel was also very different from yours (which could just be a couple of kernel options or major versions) I'd need a virtual machine.
TIL. I'm gonna check this out. It's good to see that people are already working on this, because it's one of those things that, to me, just makes a lot of sense. You'd think that with the all of the layers of abstraction we have nowadays, it should be possible to run software on any underlying system in an ergonomic fashion, even if it's not necessarily efficient.
It's extremely efficient: cold starting Word from an old Office suite is much faster than starting Libreoffice. It also uses less RAM.
A few years ago I purchased a few shrink-wrapped Office on ebay for each of the versions Wine claimed to support best, tested then with wine32 and wine64, and concluded the "sweet spot" was Office 2010 in wine32 (it may have changed, as wine keep evolving)
Yes, it's 15 years old software, but it works flawlessly with Unicode xkb symbols! Since it doesn't have any network access, and each app is isolated in a different user id, I don't think it can cause any problem.
And Ii I can still use vim to do everything I need and take advantage of how it will not surprise me with any unwanted changes, I don't see why I couldn't use say an old version of Excel in the same way!
It is interesting seeing Office suites from the 90s and wondering what really needed improved.
Google Docs pioneering “auto saving” in the cloud is the only one I can think of.
A few months ago, I ran out of power (my mistake, I use full screen apps to avoid the distraction, so I didn't realize I was unplugged)
After plugging in and restarting Linux then the ancient version of Word I was using, I got a pleasant surprise: the "autosaved" version of the document I was editing, with nothing lost!
As for llm, Excel 2010 may not have been made for AI, but wine copy/paste and a few scripts work surprisingly well!
Autosave has been part of Excel for ages. I had it enabled back in the early 1990s with the version that was distributed alongside Word 6 as part of Office 4.3 (I don't remember the Excel version number).
Current Excel Autosave when used with ODSP is different -- changes are individually autosaved (change cell, autosave, format table, autosave). They're completely transparent to the end user.
So you're saying you're using Word 2010 and have no problem with files created recently? I find it surprising that modern word .docx is compatible with 15 year old Word
The modern Word suite’s basic format was introduced with Word 2010. So as long as the person who created the doc uses features that were previously present in Word 2010 they’d be fine.
Features from later versions will either not show up or show up as boxes
The auto-save in Google Docs is undoubtedly better, but it was possible to set an auto-save interval in minutes on Word 6.0 for Windows 3.1.
Back then, Word's auto-save updated the file that you were working on rather than creating a separate backup file. I liked that better, though there might have been a good reason for changing approaches in later versions of Word.
I always liked this idea; but wouldn't you run into issues with file permissions?
And if not, wouldn't that mean that the program in question would have access to all your files anyhow, removing the benefit of isolation?
When I'm using Office, the files come from a shared directory accessible as Z:
I use scripts to automate everything - including allowing wine to use Xwayland (because until I start the application I want, its userid is not allowed to show content on my display)
If you want to try using wine with different user ids, try to start with a directory in /tmp like /tmp/wine which is group writable, with your windows app and your user belonging to the same group.
I really like the idea of bottles. I wish there was a way to bundle that up into a distro and make it invisible to the user so I could setup my friends and family with it.
And if memory serves one of the important features of Proton is to control how each app is configured individually, precisely to let you do needed tweaks at a local level.
Less required in general or by the user? I sort of had it in my head that part of what Proton did was to just bundle all of those tweaks so you didn't have to think about it, but I haven't actually looked under the hood.
It's possible to use docker as a package manager. I worked jobs where did exactly that, because we needed to compile certain dependencies for our application, and it streamlined the whole process.
There's zero reason you couldn't create a small abstraction layer around docker so you can install "executables" that are really just launching within a container. I mean, isn't that the whole idea behind flatpak, snaps, and appimages?
The point is to leverage modern abstraction techniques so that people don't need to learn a new system.
You could distribute Wine as a Flatpak platform. Flatpaks are already containers that run the same on all distros. Making a Win32 base that works in this same way using the same tooling would not be difficult.
>I don't think a new distro is needed. Most commonly used windows apps can be made to work through wine
I think the idea is to provide a seamless Windows like experience so the user works exact how he expects to work under Windows. Without having to fiddle, modify configurations, wrestle with different settings. Just click and run.
Yes, which is what I mentioned in the rest of the post. You could distribute a container that has wine in it, with just the configuration necessary to get the software working in the container. It would be straightforward to write a thin abstraction layer that pulls the container (installation) and gives you an executable that you can double click on and launch.
An end user wouldn't need to modify configs or wrestle settings, because that's already done for you upstream. You just get an artifact that you can click and run. From the other posts, Proton and Steam Deck already do something similar, and this is also conceptually similar to the way AppImages, Flatpaks etc. work.
I'm not sure why there are so many naysayers. I've been having the same thought ever since the initial release of the steam deck and think it's a great idea.
In my vision no trace of Linux is discoverable by the user.
He is missing the point. Flatpak/Snap are not just an alternative way to ship binaries. They are way to isolate applications and what they can do. Landscape has moved from protecting the system or an user from another to protect the same user applications and their data from each other, specially for desktop environments. That is not even in the map for Windows, its security model and its applications. It is a big jump backwards.
Every Application should be it's own 'user' (sub user) while the login-user / manager should be the group leader of all those 'sub users' / 'agents'.
A change in security model from the 1970s/1980s might help with security and isolation. However that same security would also generally be a pain without really smooth management in the desktop environment / shell.
I want the opposite: id like a way to run the windows kernel, drivers and most low level OS stuff by windows, but with a Linux user Interface: Cinammon, apt and all the debian stuff.
I run Mint as my main OS, but hardware compatibility is still a headache in Linux for me.
I’ve never bought one of the dedicated Linux laptops, but I’ve had pretty good luck with AMD stuff.
My current laptop, Thinkpad P16s AMD Gen 2, was pretty straightforward to get working with NixOS. No special drivers, and everything, including WiFi and function buttons on the keyboard, worked fine without any kind of special concessions.
This was also the case for my last non-Mac, from 2017-2020, I got Ubuntu installed on there without many headaches, and it wasn’t a specific Linux laptop, though again it was AMD.
You can resurrect SFU and build a replacement GUI for Explorer. You can't get rid of Win32, but you can cover up most of it. Implementing a Personality would be the Windows-way of doing this as it is designed for just what you ask.
People always talk about this “I can run a 20 year .exe file” situation but when I tell you that I have never, in 30+ years, EVER had a need to run a 20+ year executable, it just makes me go… yeah, and?
Sure I believe backwards compatibility is a nice to have feature, but I have never, nor do I think I will ever, have a need to run 20-year-old software.
My experience is that a 20 year old exe file has a greater chance of running in wine than it would in windows, and a 20 year old Linux executable is going to fail because the shared libraries it depends on are unobtainable
20-year-old exe files can fail on both Windows and WINE if they touch something relatively obscure. It's easier to throw files at the problem under WINE though (you can just throw away the prefix if you break something). The single biggest mistake WINE makes is defaulting to a single shared prefix (and the second sin is similar - trying to integrate folders and menus naively).
20-year-old dynamic binaries on Linux can almost always work today; snapshot.debian.org has all the old libraries you'll ever need. The potential exception is if they touch something hardware-ish or that needs exclusive access, but this is still better than the situation on Windows.
20-year-old static binaries on Linux will fail surprisingly often, since there have been changes in filesystem and file layout.
To the extent binary distribution is "unstable" on Linux, it's because users aren't expected to just download random binaries from wherever, as is normal on Windows (and Mac, for that matter). Users are expected to either obtain binaries from their distro, or compile them from source. In either case, all of the issues about binary distribution being "unstable" are invisible to users. Which is the point. People who want the broken Windows software model can just..run Windows. The last thing any sane Linux user wants is to make Linux into Windows. I run Linux to avoid Windows.
explain to me why the HELL should i be limited to only running binaries that my distro vendor has deigned to provide, or jump through endless hoops to obtain and build source code (which by the way might not even be obtainable OR buildable). if i have a binary from 5, 10, 15 years ago i should just be able to fucking run it on my fucking computer.
> At least in a typical linux distro the binary is built by the distributing org, with some review of where the source comes from.
This "feature" falls apart for nonfree software, which most commercial apps are. You can use Spotify and Steam's PPA but will similarly have no idea what source was included in them.
> At least in a typical linux distro the binary is built by the distributing org
... which often patches upstream code in ways that upstream neither approves of nor wants to support. And then, when things break, the user can't go upstream, and the distro package maintainers simply don't have enough time to deal with all the user reports.
There are a lot of reasons to avoid Windows outside of package/software management.
Linux has appimage, it's already capable of running "loose" native executables like Windows does. Flatpak, Snap and Docker all break the "distro repository or compile from source" model. The primary method of playing video games is installing Steam and running Windows software inside a container. This purist vision you have of Linux doesn't exist.
Linux users? That is, people who use a device that runs Linux? Like Android?
Or you mean desktop Linux users, though there aren't "a lot" of those. There's the business/corpo/science deployments but I don't think we're talking about that, but rather specifically home use. So we're talking mostly enthusiasts. I'd imagine many of those and perhaps even most at least lightly game and Steam is effectively the default place to purchase games on Linux. Do you run anything in an emulator? Impure! Purge with fire!
The software repository+compile from source paradigm isn't "Linux", it's not even "desktop Linux". Linux can execute software in a myriad of different ways, what makes Linux Linux is that it's infinitely flexible.
Obviously, since that's what the article and this discussion is about.
> there aren't "a lot" of those
Depends on what you consider "a lot", I guess. The article that this discussion is talking about apparently thinks there are enough to make its proposal for "converting Linux to Windows" worth an effort.
> Obviously, since that's what the article and this discussion is about.
I was just making the point that Linux isn't any one thing, it's everything. You want an OS handles things the way you want? Well, you do, and others should be given the same privilege. It's silly to stamp your feet about certain implementations or features existing within the Linux ecosystem, the whole point of FOSS is that they can all exist.
> The article that this discussion is talking about apparently thinks there are enough to make its proposal for "converting Linux to Windows" worth an effort.
From the article:
"Imagine we made a new Linux distro. This distro would provide a desktop environment that looks close enough to Windows that a Windows user could use it without training."
It isn't proposed as a distro for people who use Linux, but for people who use Windows but may want to move to Linux. I was one of those people, I switched my gaming PC from Windows to EndevourOS last year, though I've been using various distros for the past 20 years on other devices. I switched because Windows is becoming a shit show. I know my way around Linux, I use Blender, Krita, Gimp, Inkscape and Reaper, all native apps, but sometimes I just want to install a Windows application since the functionality I require makes it's simply necessary. Dual booting is a massive hassle, VMs fuck up productivity workflows and while I can sometimes get it working with Wine it's a hassle. I might not use the proposed OS, but the components that would allow for seamless installation of Windows software? I'd love for those to exist.
> > > > Users are expected to either obtain binaries from their distro, or compile them from source.
> > > This purist vision you have of Linux doesn't exist.
> > It does on my computer, and I suspect on a lot of Linux users' computers.
> Linux users? That is, people who use a device that runs Linux? Like Android?
I'm fairly sure the overwhelming majority of Android users only use binaries from "their distro", i.e. from the Play Store.
> The software repository+compile from source paradigm isn't "Linux", it's not even "desktop Linux".
Hey, you were the first to drag Android into this. By your own measure, the overwhelming majority of "Linux" users follow exactly "the software repository+compile from source paradigm" (albeit the "+compile from source" term equals zero in their equation).
Speak for yourself. I have been using Linux for a decade and would want nothing more if standalone application setups like those in Windows became the norm of software distribution.
Centralized package management is a curse. Apps should be responsible for their own updates, not the OS.
> Apps should be responsible for their own updates, not the OS.
Distros are not quite "the OS". You don't need a distro to run Linux.
The role distros play as far as Linux applications are concerned is more like an app store in the Windows (or Mac) world. Of course Apple has locked down their smartphones that way basically since their inception, and their desktop OS has been becoming more and more like that. So has Windows.
If you mean, do we want desktop Linux to have distros, that ship sailed several decades ago. Yes, you don't need a distro to run Linux (as I said before), but most people who run Linux use one.
However, Linux distros, while they play an app store-like role, are still very different from the Windows or Mac app stores. First, they don't restrict what else you can install on the system; you don't have to jailbreak your Linux computer to install something that the distro doesn't package. Second, they don't insist that you set up an account and hand over your personal information, or nag you constantly if you don't do that.
OTOH I view application installation as a separate skill from $THING_THIS_APP_DOES.
So I would rather the app authors just focus on perfecting their apps, while said apps can then be packaged and distributed in bulk by different sets of people trained to handle those challenges.
What I very certainly do NOT want is:
* Apps automatically checking for updates on startup — since they can't check while they are off — leading to needlessly leaked data crossing the network about exactly when I'm starting up exactly which apps (since they dial home to predictable locations regardless of TLS usage)
* Apps constantly filling systray with their own bespoke updaters (and "accelerators" which just means the app is running 24/7 but minimized to tray ;P )
* App launches updater, updater window says "can't update because app is running". Close app, wait for update, now I have to go hunt down the document I had originally opened the app with. Next time an app launches an updater, I leave it on its splash screen and go to close the app.. naturally that also closes the updater since this time around the one is a sub-process of the other. (I recall earlier versions of Wireshark causing me much grief on these fronts, for example)
* More diverse attack surface area for hackers to infect my PC: instead of trying to juke a distro who has at least some experience and vested interest in defending against poisoning, just juke any single software author less specialized in distribution security and take over their distribution channel instead.
Great news, there's a distro called Slackware that eschews centralized package management (besides optionally delivering updates for preinstalled packages). It's been around for ~20 years before you started using Linux. If you'd like to rid yourself of the curse of centralized package management in favor of running "./configure && make && sudo make install" like a real man, you should give it a try.
Given that every OS is heading towards centralised application updates. Windows Store does that AFAIK. I am guessing MacOS's store does too. The major mobile OSes and its the only way almost all users install anything.
The big difference on those other OSes is that packaging is done by the original author, and they don't have to worry about things like distro release cycles (and package freezes etc).
Windows Store is most similar to Flathub in that regard.
What's up with all this "My 20 year old software still works!!!". Who actually runs unmaintained abandonware? I would rather prefer OS devs not wasting time maintaining legacy cruft and evolve with the times.
Is this sarcasm? Some of my favorite games are 20 years old. Windows is popular in a lot of manufacturing spaces because the equipment software doesn't get updated and only connects to old programs over 16 bit serial ports.
There's a whole world out there of legacy software that is happily churning along, and doesn't need to be updated.
457 comments
[ 2.5 ms ] story [ 326 ms ] threadhttps://www.linspirelinux.com/
After Microsoft sued them and they changed their name, the bubble was burst and when Ubuntu appeared its niche as a beginner distro ebbed away.
I was surprised to hear it was still alive via a Michael MJD video a month or two ago.
[1] https://ounapuu.ee/posts/2025/02/05/done-with-ubuntu/ [2] https://getaurora.dev/en
It can also be achieved with static linking and by shipping all needed library and using a shell script loader that sets LD_LIBRARY_PATH.
Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an older Debian/Fedora that ships the needed libraries to the packaging repositories and running apt/dnf should work in theory, although unfortunately might not in practice due to the general incompetence of programmers and distribution maintainers.
Win32 is obviously not appropriate for GNU/Linux applications, and you also have the same dependency problem here, with the same solution (ship a whole Wine prefix, or maybe ship a bunch of DLLs).
True, but sad. The way to achieve compatibility on Linux is to distribute applications in the form of what are essentially tarballs of entire Linux systems. This is the "fuck it" solution.
Of course I suppose it's not unusual for Windows stuff to be statically linked or to ship every DLL with the installer "just in case." This is also a "fuck it" solution.
No so bad when Linux ran from a floppy with 2Mb of RAM. Sadly every library just got bigger and bigger without any practical way to generate a lighter application specific version.
You can still have very tiny Linux with a relatively modern kernel on tiny m0 cores, and there's ELKS for 16-bit cores.
It is not a packaging problem. It is a system design problem. Linux ecosystem simply isn't nice for binary distribution except the kernel, mostly.
Mac OS has solved this but that is obviously a single vendor. FreeBSD has decent backwards compatibility (through the -compat packages), but that is also a single vendor.
That's also why I have the opinion that the world is worse off due to the fact that Linux "won" Unix wars.
No, AFAICS that can't be it. The problem is that all those libraries (libc and others?) change all the time, and aren't backwards-compatible with earlier versions of themselves. If they were backwards-compatible, you could just make sure to have the newest one any of your applications needs, and everything would work.
They do it by having standards in the OS, partial containerization, and above all: applications are not installed “on” the OS. They are self contained. They are also jailed and interact via APIs that grant them permissions or allow them to do things by proxy. This doesn’t just help with security but also with modularity. There is no such thing as an “installer” really.
The idea of an app being installed at a bunch of locations across a system is something that really must die. It’s a legacy holdover from old PC and/or special snowflake Unix server days when there were just not many machines in the world and every one had its loving admin. Things were also less complex back then. It was easy for an admin or PC owner to stroll around the filesystem and see everything. Now even my Mac laptop has thousands of processes and a gigantic filesystem larger than a huge UNIX server in the 90s.
That doesn’t work for GUI programs which use a hardware 3D GPU. Linux doesn’t have a universally available GPU API: some systems have GL, some have GLES, some have Vulkan, all 3 come in multiple versions of limited compatibility, and optional features many of them are vendor specific.
In contrast, it’s impossible to run modern Windows without working Direct3D 11.0 because dwm.exe desktop compositor requires it. If a software consumes Direct3D 11.0 and doesn’t require any optional features (for example, FP64 math support in shaders is an optional feature, but sticking to the required set of features is not very limiting in practice unless you need to support very old GPUs which don’t implement feature level 11.0), will run on any modern Windows. Surprisingly, it will also run on Linux systems which support Wine: without Vulkan-capable GPU will be slow but should still work due to Lavapipe, which is a Linux equivalent of microsoft’s WARP they use on Windows computers without hardware 3D GPU.
Sure, you can run a 20 year old app, but that is not the same as a current app still working in 20 years, or even 5.
Not sure I follow. Sure, most modern programs are not using old-school WinAPI with GDI, but the stuff they added later is also rather stable. For example, the Chromium-based browser I’m looking at uses Direct3D 11 for graphics. It implements a few abstraction layers on top (ANGLE, Skia) but these are parts of the browser not the OS.
I view all that modern stuff like Direct3D, Direct2D, DirectWrite, Media Foundation as simply newer parts of the WinAPI. Pretty sure Microsoft will continue to support them for long time. For example, they can’t even deprecate the 23 years old DirectX 9 because still widely used, e.g. current version of Microsoft’s own WPF GUI framework relies on Direct3D 9 for graphics.
On Windows, new layers are applied over the old. There is DirectX 9-12. New binaries may use 12 but the ones still using 9 are perfectly happy. Things like .NET work the same. You can have multiple apps installed relying on different .NET versions.
You can also run an old mesa from the time the app was built if it supports your newer hardware, but I'd rather consider that to be part of the platform the same way you'd consider the DirectX libraries to be part of windows.
An example from another comment: https://news.ycombinator.com/item?id=43519949
> I have flatpaks from several years ago that no longer work (Krita) due to some GL issues.
That’s an example of Linux GPU APIs being unstable in practice, and container images not helping to fix that.
But I suspect "GL issues" (i.e., GL API stability) is being mixed together with e.g. mesa issues if mesa is being bundled inside the app/in a "flatpak SDK" instead of being treated as a system library akin to what you would do with DirectX.
Mesa contains your graphics driver and window system integrations, so when the system changes so must mesa change - but the ABI exposed to clients does not change, other than new features being added.
I'm running Loki game binaries just fine today btw.
It's true, but this touches on another point they made: what apps code to is other dynamically linked libraries. The kind that wine (or other host environments) can provide, without needing to mess with the kernel.
Microsoft also provides quite good stability for DirectX and other extension APIs. You can still run old .Net apps without issues as long as they didn't pull a Hyrum's Law on you and depended on apparent behavior.
OpenGL and Vulkan ABIs are also stable on Linux, provided by mesa. The post is pretty focused on the simplicity of win32 though, which is what I'm refuting as being as relevant today for new apps.
> As long as they didn't pull a Hyrum's Law on you
It is guaranteed that they "pull a Hyrum's Law", the question is just what apparent behavior they relied on.
Which is probably why so many "modern apps" look just like "modern" Web pages running on the desktop... i.e, why so many "modern apps" suck. They freaking should use those GUI bits.
All Linuxes I'm familiar with run Mesa, which gives you OpenGL and Vulkan.
Then there’re quality issues. If you search internets for “Windows Vulkan issue” you’ll find many end users with crashing games, game developers with crashing game engines https://github.com/godotengine/godot/issues/100807 recommendations to update drivers or disable some Vulkan layers in registry, etc.
On Windows, Vulkan is simply not as reliable as D3D. The reasons include market share, D3D being a requirement to render the desktop, D3D runtime being a part of the OS supported by Microsoft (Vulkan relies solely on GPU vendors), and D3D being older (first version of VK spec released in 2016, D3D11 is from 2009).
Another thing, on Linux, the situation with Vulkan support is less than ideal for mobile and embedded systems. Some embedded ARM SoCs only support GLES 3.1 (which BTW is not too far from D3D 11.0 feature-wise) but not Vulkan.
Unless you are running Windows, in which case it doesn’t. Intel simply has not made a driver.
Yep exactly. While Vulkan API is well defined and mostly stable, there is no guarantee in Linux implementation will also be stable. Moreover Khronos graphics APIs only deal with the stuff after you allocated a buffer and did all the handshakes with the OS and GPU drivers. On Linux none of those have API / ABI / runtime configuration stability guarantees. Basically it works until only one of the libraries in the chain breaks the compatibility.
Now GUI toolkits are more of an issue. That's annoying for some programs, many others do their own thing anyway.
Got it. So everything is properly designed but somehow there's a lot of general incompetence preventing it from working. I'm pretty sure the principle of engineering design is to make things work in the face of incompetence by others.
And while glibc is backward compatible & that generally does work, glibc is NOT forward compatible which is a huge problem - it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on. Whereas on Mac & Windows it's pretty easy to build applications on my up-to-date system targeting older variants.
Isn’t this easily solved by building in a container? Something a lot of people do anyway - I do it all the time because it insulates the build from changes in the underlying build agents - if the CI team decides to upgrade the build agent OS to a new release next month or migrate them to a different distro, building in a container (mostly) isolates my build job from that change, doing it directly on the agents exposes it to them
But it is working, actually:
* If you update your distro with binaries from apt, yum, zypper etc. - they work.
* If you download statically-linked binaries - they work.
* If you download Snaps/Flatpak, they work.
> it means that you have to build on the oldest bistro you can find so that the built binaries actually work on arbitrary machines you try to run it on.
Only if you want to distribute a dynamically-linked binary without its dependencies. And even then - you have to build with a toolchain for that distro, not with that distro itself.
Even statically linked code tends to be dynamically linked against glibc. You’ve basically said “it works but only if you use the package manager in your OS”. In other words, it’s broken and hostile for commercial 3p binary distribution which explains the state of commercial 3p binary ecosystem on Linux (there’s more to it than just that, but being actively hostile to making it easy to distribute software to your platform is a compounding factor).
I really dislike snaps/flat pack as they’re distro specific and overkill if I’m statically linking and my only dynamic dependency is glibc.
As for being overkill, surely you can see the advantage of having a single uniform distribution format from the end user's perspective? Which, sure, might be overkill for your case (although app isolation isn't just about dependencies), but the important thing is that it is a working solution that you can use, and users only need to know how to install and manage them.
Only if you're using a distro that doesn't come with it preinstalled. But that doesn't make it distro-specific?
> And now I have to host a flat pack repo and get the user to add my repo if it’s proprietary software.
You don't have to do that, you can just give them a .flatpak file to install: https://docs.flatpak.org/en/latest/single-file-bundles.html
The reason to host a repo regardless is to enable easy auto-updates - and I don't think you can call this bit "smooth and simple" on Windows and Mac, what with most apps each doing their own thing for updates. Unless you use the app store, but then that's exactly the same as repos...
If you build a statically linked program with only glibc dynamically linked, and you do that on Linux from 2005,then that program should run exactly the same today on Linux. The same is true for Windows software.
Linux is the only space where you have to literally do your build on an old snapshot of a distro with an old glibc so that you can distribute said software. If you’re in c++ land you’re in for a world of hurt because the version of the language is now constrained to whatever was available at the time that old distro from 5+ years ago snapshotted unless you build a newer compiler yourself from scratch. With Rust at least this is much easier since they build their toolchain on an old version of Linux and thus their binaries are similarly easily distributed and the latest Rust compiler is trivially easy to obtain on old Linux distros.
Source: I’m literally doing this today for my day job
Still, to reliably target older Windows versions you need to tell your toolchain what to target. The Windows SDK also lets you specify the Windows version you want to target via WINVER / _WIN32_WINNT macros which make it harder to accidentally use unsupported functions. Similarly, the compilers and linkers for Windows have options to specify the minimum Windows version recorded in the final binary and which libraries to link against (classic win32 dlls or ucrt). Unfortunately there is no such mechanism to specify target version for glibc/gcc and you have you either build against older glibc versions or rely on third-party headers. Both solutions are workable and allow you to create binaries with a wide range of glibc version compatibility but they are not as ideal as direct support in the toolchain would be.
1. GNU libc is an exception in the world of compatibility.
2. You can't just dump a bunch of GTK libraries next to the binary and expect it to work. These libraries often expect very specific file system layouts.
(Yes, if you fiddle with the config file they might work on the .NET 4.0 runtime. But that’s not something a typical user can/will do.)
.NET 1.x tho, yeah.
For example, recently I tried to run Emacs' Appimage and it has a glib issue
https://github.com/probonopd/Emacs.AppImage/issues/22#issuec...
Glib is a library from the GTK project which offers utility functionality related to the GTK widget toolkit, while glibc is the GNU C Library.
Amusingly, these kinds of beyond-the-core libraries are the ones that have always caused problems for me, never actual core GNU C Library.
We're clearly not living in the same universe here.
glibc backward compatibility is horrible.
Every. Single. Time. I try to use an old binary on a modern distro, it bombs, usually with some incomprehensible error message with GLIBC in all caps in it.
And these days, you can't even link glibc statically, when you try it barks at you with vehemence.
As a matter of fact, as pointed out in the article, this particular shortcoming of glibc completely negates the work done by Linus to keep userland backward compatible at all cost.
Please post actual issues encountered, including non-paraphrased errors instead of FUD.
And if you want to statically link your libc there is nothing forcing you to use glibc. You're only stuck with glibc (and even then you don't actually need to use any functions from it yourself) if you need dynamic linnking for e.g. OpenGL/Vulkan. Also, glibc wasn't designed for static linking even before they put in safeguards against that.
Improperly aligned incentives? Who gets to say what that is?
Is it "improper" to maximize profit per their own board's guidelines?
I have a feeling OP has some predefined notion of nobility they expect people to somehow operate under.
From the standpoint of the end user the incentives are improperly aligned. If they had made hammers they would have included licence agreements for their use with specific types of nails and actively prevented users from using competitor's nails. They also would have made sure yesterday's hammer would not be sufficient to hammer in today's nail, they would have added camera's to observe what the user was doing so as to sell 'targeted' advertising - during which the hammer would not strike any nails but would sing like the singing sword in Who Framed Roger Rabbit - and they would have made sure that no matter how agile the user was with his hammer the thing would never be 100% reliable.
Of course hammers are far less complex than computers and operating systems. Maybe this is because they're made by tool manufacturers and not by tech companies, maybe it is because they're old tech. A modern hammer is what Ford would have produced if he had listened to his customers who asked him for a faster horse so maybe there is a whole world of construction efficiency waiting for the Henry Ford of Hammersmiths. Or, maybe - probably - sometimes it is better to get that faster horse, that titanium hammer or that free software operating system which works for you and nobody else.
Anything by Cory Doctorow usually is.
Anyone worth calling human.
> Is it "improper" to maximize profit per their own board's guidelines?
If to the exclusion of all else, then yes, wildly so.
> I have a feeling OP has some predefined notion of nobility they expect people to somehow operate under.
Having a set of values is what separates Man from (most of) the other animals.
HTH!
But the trade-off is that the software you have in your repos will be really old. At the end your RHEL support cycle libs will be a decade out of date.
Point still stands: fixing the situation with these libraries seems like less fuss than turning Linux into windows.
"We should"? Do you mean me? I have a ton of my own projects I'm busy with.
Why didn't you say "I should create..."? There's nothing stopping you implementing this if you think it's a good idea. Do the work yourself.
Are you high? There is nothing simple about Wine. It's at once a kludgy mess and a technical masterpiece, what it isn't is simple.
Seems easy to me
https://www.christopherspenn.com/2021/08/simple-is-not-easy/
At certain points he talks about syscalls, libc (I'm assuming glibc), PE vs. ELF, and an 'ABI'. Those are all different things, and IIUC all are fairly stable on Linux, what isn't stable is userspace libraries such as GTK and QT. So, what are we talking about?
There's also statements like this, which, I'm not a kernel developer but they sound a little to good to be true:
> A small modification to the "exec" family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
He goes on to talk about Gatekeeper (which you can disable), Recall (which is disabled by default), and signing in with a Microsoft account (which can be easily bypassed, though he linked an article saying they might remove it). He also talks about "scanning your computer for illegal files", I don't know what this is referring to, but the only thing I could find on Google was Apple's iCloud CSAM scanning thing. That's not on your computer, and it got so much backlash that it was cancelled.
There's plenty of stuff to criticize about these companies and their services without being dramatic, and the idea of Linux having more compatibility with Win32 via Wine isn't bad.
> A small modification to the "exec" family of system calls to dispatch on executble type would allow any Linux application to fork an exec a Windows application with no effort.
That isn't "too good to be true", it's so good it is false – no kernel modification is required because the Linux kernel already supports this via binfmt_misc. You just need to configure it. And depending on how you installed Wine, you may find it has even already been configured for you.
- Steam Runtime: A set of common libraries Linux native games target for multi-distro compatibility, I believe this still uses Ubuntu as the upstream
- Steam OS: An arch based distro pre-configured to run Steam out of the box, used by the Steam Deck, comes with extra stuff like gamescope to smooth over various issues other distros have with VRR, HDR, etc.
- Proton: Runs Windows games on Linux
Yes, you'd have to buff and polish it. But "paint some chrome on it" is hardly much of a blog post.
[1] Actually, are you sure the answer is "no" here? I wouldn't be at all shocked if some enterprising geek had source on github implementing a MSI extractor and installer
Why not use ReactOS?
People who like and need Windows apps, people who want to have an out of the box experience when running those apps, people who don't like the loss of performance when using Wine, people who generally like Windows but want to have an alternative in case that dislike where Microsoft is heading with Windows development.
That is a lot of people, me included. But since Windows experience is somehow still tolerable, there aren't many willing to invest time or money into ReactOS. There are no corporate sponsors since you don't make money from desktop OS-es unless you use them to sell expensive hardware like Apple did.
Someone like Valve could have sponsored it but they though they can reach their goals with Wine while spending much less money.
Another sponsor for ReactOS can be a state actor like China or EU, somebody with deep pockets who wants and needs to run Windows software but don't want their desktop to be under US control.
> Another sponsor for ReactOS can be a state actor like China or EU, somebody with deep pockets who wants and needs to run Windows software but don't want their desktop to be under US control.
I would love to see EU to do this actually. Maybe we should pitch this as citizens.
I’ve been hoping that ReactOS would be the thing that truly murdered Microsoft Windows, but that really hasn’t happened; it seems like that’s happening via combination of a lot of applications moving to the browser and compatibility layers like Wine and Proton.
Linux has pretty good driver support nowadays, and outside of drivers Wine will have as good or better support for applications, so I am not completely sure what that says about the future of ReactOS.
Some of the basic apps like Jetbrains it could barely run it. At best it was crashing frequently for me.
The simplest solution, to me, is to just distribute containers (or some other sandbox) with wine in it, and the necessary shenanigans to get the windows program (just the one) working in the container, and just distribute that. Everyone gets the same artifact, and it always works. No more dicking around with wine settings, because it's baked in for whatever the software is.
Yes, this is tremendously space inefficient, so the next step would be a way of slimming wine down for container usage.
The only real barrier to this system is licensing and software anti patterns. You might have to do some dark magic to install the software in the container in the first place.
> Windows application submissions that are using Wine or any submissions that aren't native to Linux desktop and is using some emulation or translation layer will only be accepted if they are submitted officially by upstream with the intention of maintaining it in official capacity.
Although, I am curious why; they don't seem to have a general problem with unofficial packages, so I'm not sure why a translation layer makes any difference. It doesn't seem different than happening to use any other runtime (ex. nothing is said about Java or .net).
It would take a large organization with enough connections to cut through this. You'd probably need to cut a deal so you could distribute their software, and you'd need to provide a mechanism for users to be able to make purchases. Even then, there are various licensing challenges, because you would be distributing the same install, so thousands (or millions) of "installs" would effectively have the same serial or license number.
It's nontrivial, but the basic idea is straightforward and doable. The challenge is how windows software is distributed and licensed, not anything technical.
I think this could work as a translation layer because containers already abstract away everything on syscall level.
There must be just a GUI for that, which can create multiple sandboxes easily, per application, and remember what you configured and installed there (and add it to the Winefile).
In regards to the sharing serials problem: You can easily diff the .reg file that wine adds there and if anything pops out in \\software, you can assume this is a custom field and offer it as an environment variable for the container?
[1] https://usebottles.com [2] https://github.com/bottlesdevs/programs/blob/main/Games%2Fit...
It doesn't have to be. Old software is cheap, even shrink wrapped ("new old stock")
[0] https://github.com/notepad-plus-plus/notepad-plus-plus/blob/... [1] https://appdb.winehq.org/objectManager.php?sClass=applicatio...
The key difference is that applications ran under wine will always have some subtle quirks and misbehaviors that break the usability, that can be worked around by the dev when given the chance to.
Half of this incompatibility is because Linux is flexible, anyway. My system is different from your system, and did anyone test on both? If you want a more stable ABI then you need a more stable system.
Rather than everyone having to get the software working on their machine, you would get it working once in the container, and then just distribute that.
https://support.codeweavers.com/en_US/2-getting-started/2-in...
I believe it started with Cedega, but I could be wrong. That's where I first recall encountering it.
A few years ago I purchased a few shrink-wrapped Office on ebay for each of the versions Wine claimed to support best, tested then with wine32 and wine64, and concluded the "sweet spot" was Office 2010 in wine32 (it may have changed, as wine keep evolving)
Yes, it's 15 years old software, but it works flawlessly with Unicode xkb symbols! Since it doesn't have any network access, and each app is isolated in a different user id, I don't think it can cause any problem.
And Ii I can still use vim to do everything I need and take advantage of how it will not surprise me with any unwanted changes, I don't see why I couldn't use say an old version of Excel in the same way!
Maybe not much?
A few months ago, I ran out of power (my mistake, I use full screen apps to avoid the distraction, so I didn't realize I was unplugged)
After plugging in and restarting Linux then the ancient version of Word I was using, I got a pleasant surprise: the "autosaved" version of the document I was editing, with nothing lost!
As for llm, Excel 2010 may not have been made for AI, but wine copy/paste and a few scripts work surprisingly well!
Word is similar.
Features from later versions will either not show up or show up as boxes
Back then, Word's auto-save updated the file that you were working on rather than creating a separate backup file. I liked that better, though there might have been a good reason for changing approaches in later versions of Word.
I always liked this idea; but wouldn't you run into issues with file permissions? And if not, wouldn't that mean that the program in question would have access to all your files anyhow, removing the benefit of isolation?
I use scripts to automate everything - including allowing wine to use Xwayland (because until I start the application I want, its userid is not allowed to show content on my display)
If you want to try using wine with different user ids, try to start with a directory in /tmp like /tmp/wine which is group writable, with your windows app and your user belonging to the same group.
> but the hacks used to make one app work can break others and vice versa
I think a lot of these problems could be avoided with a singular OS with the sole goal to support windows exes.
There's zero reason you couldn't create a small abstraction layer around docker so you can install "executables" that are really just launching within a container. I mean, isn't that the whole idea behind flatpak, snaps, and appimages?
The point is to leverage modern abstraction techniques so that people don't need to learn a new system.
It could even support running as a self contained application on Windows, with all needed DLLs provided.
I think the idea is to provide a seamless Windows like experience so the user works exact how he expects to work under Windows. Without having to fiddle, modify configurations, wrestle with different settings. Just click and run.
An end user wouldn't need to modify configs or wrestle settings, because that's already done for you upstream. You just get an artifact that you can click and run. From the other posts, Proton and Steam Deck already do something similar, and this is also conceptually similar to the way AppImages, Flatpaks etc. work.
How many missiles do you know that run Windows?
A change in security model from the 1970s/1980s might help with security and isolation. However that same security would also generally be a pain without really smooth management in the desktop environment / shell.
I run Mint as my main OS, but hardware compatibility is still a headache in Linux for me.
You might get lucky, but it sounds like you've not been lucky.
My current laptop, Thinkpad P16s AMD Gen 2, was pretty straightforward to get working with NixOS. No special drivers, and everything, including WiFi and function buttons on the keyboard, worked fine without any kind of special concessions.
This was also the case for my last non-Mac, from 2017-2020, I got Ubuntu installed on there without many headaches, and it wasn’t a specific Linux laptop, though again it was AMD.
Sure I believe backwards compatibility is a nice to have feature, but I have never, nor do I think I will ever, have a need to run 20-year-old software.
20-year-old exe files can fail on both Windows and WINE if they touch something relatively obscure. It's easier to throw files at the problem under WINE though (you can just throw away the prefix if you break something). The single biggest mistake WINE makes is defaulting to a single shared prefix (and the second sin is similar - trying to integrate folders and menus naively).
20-year-old dynamic binaries on Linux can almost always work today; snapshot.debian.org has all the old libraries you'll ever need. The potential exception is if they touch something hardware-ish or that needs exclusive access, but this is still better than the situation on Windows.
20-year-old static binaries on Linux will fail surprisingly often, since there have been changes in filesystem and file layout.
Yes there are modern ports, and newer versions, but these kind of retro games, and utilities, are used by many.
It's pretty funny to read a critisism of linux s/w distribution along the lines of the dificulty of distributing binaries.
This is one of the biggest security vulnerabilities of windows. 3rd parties distributing binary executables.
At least in a typical linux distro the binary is built by the distributing org, with some review of where the source comes from.
Downloading a windows app from the internet one has no idea what source is included in that binary.
I'm also not a fan of non-distro based systems such as flatpack. Again, I would prefer my binaries built by the distribution, or if need be, locally.
In fact this is the way 3rd party windoze executables are typically distributed.
Nobody's stopping you...
p.s. The above seems like a trolling reply, but I always play the straight man...
This "feature" falls apart for nonfree software, which most commercial apps are. You can use Spotify and Steam's PPA but will similarly have no idea what source was included in them.
... which often patches upstream code in ways that upstream neither approves of nor wants to support. And then, when things break, the user can't go upstream, and the distro package maintainers simply don't have enough time to deal with all the user reports.
Linux has appimage, it's already capable of running "loose" native executables like Windows does. Flatpak, Snap and Docker all break the "distro repository or compile from source" model. The primary method of playing video games is installing Steam and running Windows software inside a container. This purist vision you have of Linux doesn't exist.
It does on my computer, and I suspect on a lot of Linux users' computers.
Or you mean desktop Linux users, though there aren't "a lot" of those. There's the business/corpo/science deployments but I don't think we're talking about that, but rather specifically home use. So we're talking mostly enthusiasts. I'd imagine many of those and perhaps even most at least lightly game and Steam is effectively the default place to purchase games on Linux. Do you run anything in an emulator? Impure! Purge with fire!
The software repository+compile from source paradigm isn't "Linux", it's not even "desktop Linux". Linux can execute software in a myriad of different ways, what makes Linux Linux is that it's infinitely flexible.
Obviously, since that's what the article and this discussion is about.
> there aren't "a lot" of those
Depends on what you consider "a lot", I guess. The article that this discussion is talking about apparently thinks there are enough to make its proposal for "converting Linux to Windows" worth an effort.
I was just making the point that Linux isn't any one thing, it's everything. You want an OS handles things the way you want? Well, you do, and others should be given the same privilege. It's silly to stamp your feet about certain implementations or features existing within the Linux ecosystem, the whole point of FOSS is that they can all exist.
> The article that this discussion is talking about apparently thinks there are enough to make its proposal for "converting Linux to Windows" worth an effort.
From the article: "Imagine we made a new Linux distro. This distro would provide a desktop environment that looks close enough to Windows that a Windows user could use it without training."
It isn't proposed as a distro for people who use Linux, but for people who use Windows but may want to move to Linux. I was one of those people, I switched my gaming PC from Windows to EndevourOS last year, though I've been using various distros for the past 20 years on other devices. I switched because Windows is becoming a shit show. I know my way around Linux, I use Blender, Krita, Gimp, Inkscape and Reaper, all native apps, but sometimes I just want to install a Windows application since the functionality I require makes it's simply necessary. Dual booting is a massive hassle, VMs fuck up productivity workflows and while I can sometimes get it working with Wine it's a hassle. I might not use the proposed OS, but the components that would allow for seamless installation of Windows software? I'd love for those to exist.
> > > This purist vision you have of Linux doesn't exist.
> > It does on my computer, and I suspect on a lot of Linux users' computers.
> Linux users? That is, people who use a device that runs Linux? Like Android?
I'm fairly sure the overwhelming majority of Android users only use binaries from "their distro", i.e. from the Play Store.
> The software repository+compile from source paradigm isn't "Linux", it's not even "desktop Linux".
Hey, you were the first to drag Android into this. By your own measure, the overwhelming majority of "Linux" users follow exactly "the software repository+compile from source paradigm" (albeit the "+compile from source" term equals zero in their equation).
Centralized package management is a curse. Apps should be responsible for their own updates, not the OS.
Distros are not quite "the OS". You don't need a distro to run Linux.
The role distros play as far as Linux applications are concerned is more like an app store in the Windows (or Mac) world. Of course Apple has locked down their smartphones that way basically since their inception, and their desktop OS has been becoming more and more like that. So has Windows.
Is that where we want desktop Linux to go?
However, Linux distros, while they play an app store-like role, are still very different from the Windows or Mac app stores. First, they don't restrict what else you can install on the system; you don't have to jailbreak your Linux computer to install something that the distro doesn't package. Second, they don't insist that you set up an account and hand over your personal information, or nag you constantly if you don't do that.
So I would rather the app authors just focus on perfecting their apps, while said apps can then be packaged and distributed in bulk by different sets of people trained to handle those challenges.
What I very certainly do NOT want is:
* Apps automatically checking for updates on startup — since they can't check while they are off — leading to needlessly leaked data crossing the network about exactly when I'm starting up exactly which apps (since they dial home to predictable locations regardless of TLS usage)
* Apps constantly filling systray with their own bespoke updaters (and "accelerators" which just means the app is running 24/7 but minimized to tray ;P )
* App launches updater, updater window says "can't update because app is running". Close app, wait for update, now I have to go hunt down the document I had originally opened the app with. Next time an app launches an updater, I leave it on its splash screen and go to close the app.. naturally that also closes the updater since this time around the one is a sub-process of the other. (I recall earlier versions of Wireshark causing me much grief on these fronts, for example)
* More diverse attack surface area for hackers to infect my PC: instead of trying to juke a distro who has at least some experience and vested interest in defending against poisoning, just juke any single software author less specialized in distribution security and take over their distribution channel instead.
Windows Store is most similar to Flathub in that regard.
That's what billions of people do. :)
Businesses run the old stuff.
There's a whole world out there of legacy software that is happily churning along, and doesn't need to be updated.
Great game.
Personal computers are for persons. They don't view their use of their own systems through the lens of an imputed purity test.
> I would rather prefer OS devs not wasting time maintaining legacy cruft and evolve with the times.
Then don't support those who do with your dollars. I wouldn't be terribly surprised if the market shows it disagrees with you.
https://store.steampowered.com/app/7620/Railroad_Tycoon_II_P...
I return to that game for a few quick sessions every couple of months.