Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Convert Linux to Windows

philipbohun.com

Post reply on HN
Print view View original

31–40 of 459 posts

Re: Convert Linux to Windows

#31

Post by Spivak »

pizlonator wrote: post #12

Seems like it would be easier to identify and fix cases of ABI compat breakage in the Linux userland than to convert Linux to Windows.

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.

Re: Convert Linux to Windows

#32

Post by grandiego »

api wrote: post #10
devit wrote: post #5

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

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

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

Re: Convert Linux to Windows

#33

Post by Spivak »

ajross wrote: post #24

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.

Re: Convert Linux to Windows

#35

Post by coderenegade »

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.

Re: Convert Linux to Windows

#37

Post by nine_k »

coderenegade wrote: post #35

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…

Flatpak could work better because it already knows how to factor out common parts, so it could bring in only one (or just few) version of Wine.

Re: Convert Linux to Windows

#38

Post by cyberax »

mappu wrote: post #22
cyberax wrote: post #9

Earlier quoted context omitted.

There are few issues: 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.

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.

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

Re: Convert Linux to Windows

#39

Post by cyberax »

kccqzy wrote: post #15
cyberax wrote: post #9

Earlier quoted context omitted.

There are few issues: 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.

I have flatpaks from several years ago that no longer work (Krita) due to some GL issues.

Re: Convert Linux to Windows

#40

Post by dwattttt »

arghwhat wrote: post #20
Const-me wrote: post #14

Earlier quoted context omitted.

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

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.

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

Post reply on HN