Live data from Hacker News

Convert Linux to Windows

philipbohun.com

41–50 of 459 posts

Re: Convert Linux to Windows

#41

> We also already have a simple way to run Windows applications, Wine. 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.

Depends. Proton and CrossOver are dead easy, especially for the supported apps.

Re: Convert Linux to Windows

#42
post #33
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.

Wait, isn't Steam OS Arch based now?

Re: Convert Linux to Windows

#43

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…

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.

Re: Convert Linux to Windows

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

Re: Convert Linux to Windows

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

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

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?

Re: Convert Linux to Windows

#46

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…

The concept of containers for Windows applications running in WINE is called "bottles."

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.

Re: Convert Linux to Windows

#47

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…

At this point nobody is going to learn a new system. People already know how to write and package exes which is the whole point.

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

Re: Convert Linux to Windows

#48
post #33

Earlier quoted context omitted.

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.

Wait, isn't Steam OS Arch based now?

There is three things here:

- 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

Re: Convert Linux to Windows

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

Steam OS is clearly not what the blog is proposing, I can't just pop over the desktop mode and install Firefox via a MSI.

Re: Convert Linux to Windows

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

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

Post reply on HN