Live data from Hacker News

Convert Linux to Windows

philipbohun.com

271–280 of 459 posts

Re: Convert Linux to Windows

#271
This problem is related to the fact that Linux distos typically dynamically link executables and don’t retain older versions of those libraries vs Windows which does.

It’s on of the many reasons Windows base install is so much heavier than a typical Linux base install.

The reason Windows retains older versions of executables while Linux doesn’t is because Windows doesn’t have a package manager like Linux distros. Ok, there’s now Windows Store plus a recent-ish CLI tool that was based on one of the many unofficial package managers, but traditionally the way to install Windows application was via manual downloads and installs. So those installers would typically come bundled with any shared libraries they’d need and often have those shared libraries in the application directory. Leading to lots of duplication of libraries.

You could easily do the same thing in Linux too but there’s less of a need because Linux distribution package managers are generally really good. But some 3rd party package managers do take this kind of approach, eg Nix, Snap, etc.

So it’s not that Linux is “unstable” but more that people have approached the same problem on Linux in a completely different way.

The fact that drag-and-drop installs work on macOS demonstrates that there isn’t really a UNIX-like limitation preventing Windows-style installs. It’s more that Linux distributions prefer a different method for application installation.

Re: Convert Linux to Windows

#272

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…

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.

There was Winepak (abandoned, sadly): https://winepak.github.io/

Re: Convert Linux to Windows

#273

> In Linux, you can make system calls directly... > In Windows, you do not make system calls directly, Instead, you dynamically link to libraries that make the system calls for you. Isn't the actual problem the glibc shared library since the Linux syscall interface is stable? (as promised by "don't break user space") - e.g. I would expect that I can take a 20 years old Linux binary which only does syscalls and run th…

Yeah the direct syscall interface isn't a problem because it's so stable. The problem is almost entirely glibc. If GCC simply had a flag --glibc-version=2.14 or whatever then 99% of the problems would be solved.

I tend to just compile on a really old distro to work around this. Tbf you need to do the same thing on Mac, it just isn't so much of an issue because Macs are easier to update.

The other side of the problem is that the whole Linux ecosystem is actively hostile to bundling dependencies and binary distribution in general, so it's not a surprise that it sucks so much.

Re: Convert Linux to Windows

#274
post #99
post #68

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 wa…

Thank you very much! I was about to post almost the same thing, so I'll reply to your post instead (and upvote): 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…

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

Re: Convert Linux to Windows

#275

> While the Linux syscalls themselves are very stable and reliable, the c library on top of them is not. Practically all of userland is based on libc, and therefore by proxy Linux itself has a binary compatibility problem. People who primarily use Linux often forget that Windows has the exact same problem. In the case of Windows libc is distributed as part of the Visual C++ runtime. Each version of Visual Studio has…

A big difference is that you can easily install an up-to-date MSVCRT. How do I upgrade glibc on RHEL 8? As far as I can tell you basically can't.

Re: Convert Linux to Windows

#276

Earlier quoted context omitted.

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.

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.

Re: Convert Linux to Windows

#277
> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. There's no guarantee that it will be able to run based off some update that has happened

IMHO, you just compare two different things. Traditional method of installing apps on Windows is packing all dynamic dependencies with it. While on linux dynamic dependencies are shared between apps. So, there is nothing surprising that when you change the dependencies of the app, it stops working.

There are few ways to solve this and your are free to choose:

- distribute the same as on Windows

- link statically

Re: Convert Linux to Windows

#278
post #43

Earlier quoted context omitted.

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 e…

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.

Re: Convert Linux to Windows

#279
post #155

Earlier quoted context omitted.

Is libc updates really the primary problem with the ABI breaks on Linux? Glibc isn't perfect but it has versioned symbols going back a long time now. My guess would be the problem is actually abandoned versions of other libraries (e.g. SDL1, old versions of gtk2?) and maybe a handful of other things.

Yeah, glibc is extremely stable and you can be sure that an app compiled against it now will work well into the future. People just completely ignore that fact based on hearsay, and that the removal of a unused symbol hashing table from the glibc binary broke a few anticheat systems that were attempting to parse it. Other libraries are the problem, usually. People are generally really good about changing the .so vers…

Everything is fine until it isn't when you run into mismatch like 64bit file offsets and time_t.

Re: Convert Linux to Windows

#280
post #38

Earlier quoted context omitted.

The most recent .NET Framework still keeps 1.1 assemblies for compatibility. And yep, .NET sucked and eventually got semi-abandoned.

This must be from an alternate timeline. There is no way to call what is currently going on with .net anything other than 0% abandoned.

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

Post reply on HN