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

411–420 of 459 posts

Re: Convert Linux to Windows

#411

Post by [deleted] »

Dwedit wrote: post #128
lucasoshiro wrote: post #29

> 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. Why not use ReactOS?

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

[deleted]

Re: Convert Linux to Windows

#412

Post by scheeseman486 »

pdonis wrote: post #341
scheeseman486 wrote: post #160

Earlier quoted context omitted.

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

> you mean desktop Linux users 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.

Re: Convert Linux to Windows

#413

Post by musicale »

okanat wrote: post #402
feelamee wrote: post #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 app…

You don't need to bundle anything from the system layer on Windows programs distributed as binaries. On Linux there is no proper separation of system libraries or optional libraries, everything could be both and there are no API / ABI guarantees. So "just bundle your dependencies" simply doesn't work. You cannot bundle Mesa, libwayland or GTK but you cannot fully depend them not breaking compatibility either. On Wind…

I am sure this is true. But I seem to have had good results building static executables and libraries for C/C++ with cmake (which presumably passes -static to clang/gcc). golang also seems to be able to create static executables for my use cases.

Unless static linking/relinking is extremely costly, it seems unnecessary to use shared libraries in a top-level docker image (for example), since you have to rebuild the image anyway if anything changes.

Of course if you have a static executable, then you might be able to simplify - or avoid - things like docker images or various kinds of complicated application packaging.

Re: Convert Linux to Windows

#414

Post by int_19h »

vlovich123 wrote: post #348
int_19h wrote: post #260

Earlier quoted context omitted.

Flatpaks aren't distro specific. 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…

> You have to install the flat pack runtime to begin with so that’s one obstacle for distribution.

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

Re: Convert Linux to Windows

#415

Post by IshKebab »

DrFalkyn wrote: post #380
IshKebab wrote: post #275

Earlier quoted context omitted.

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.

Linux is based around OSS, so the answer would be to recompile from source. Falling that, run inside a container

Both terrible answers.

Re: Convert Linux to Windows

#416

Post by rini17 »

jchw wrote: post #368
rini17 wrote: post #279

Earlier quoted context omitted.

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

Good news if you're serious: You can now have a single glibc that supports programs compiled with and without -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64.

So this is non issue you say?

https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-tra...

Re: Convert Linux to Windows

#417

Post by GoblinSlayer »

int_19h wrote: post #258
GoblinSlayer wrote: post #227

Earlier quoted context omitted.

Windows toolchain (even gnu) just provides old libraries to link with. This should work the same on linux, and AFAIK zig does just that.

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.

The situation with glibc is the same, you only depend on functions you use.

Re: Convert Linux to Windows

#418

Post by arghwhat »

Const-me wrote: post #356
arghwhat wrote: post #343

Earlier quoted context omitted.

Apologies, but "I heard that..." is not an example.

The phrase you quoted is not from the comment I linked; you’ve quoted from a response. Here’s the comment I have linked above: > 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.

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.

Re: Convert Linux to Windows

#419

Post by account42 »

feelamee wrote: post #382
rendaw wrote: post #364

Earlier quoted context omitted.

I think it's not quite simple though. For one, I think the opengl driver situation is complex, where I hear you need userland per-hardware libraries which basically require dynamic linking. From that perspective windows binaries are the de-facto most stable way of releasing games on linux. I'm not sure about linux syscall ABI stability either, or maybe other things that live in the kernel?

> I think the opengl driver situation is complex, where I hear you need userland per-hardware libraries which basically require dynamic linking Yes. OpenGL driver is loading dynamically, but.. Are you sure that there are any problems with OpenGL ABI stability? I have never hear about breaking changes in it

The OpenGL ABI is extremely stable but OpenGL drivers (especially the open source ones) also use other libraries which distros like to link dynamically. This can cause problems if you ship different versions of the same libraries with your program. This includes statically linked libraries if you did not build them correctly and your executable still exports the library symbols. Not insurmountable problems but still thinks that inexperienced Linux developers can mess up.

Re: Convert Linux to Windows

#420

Post by Gormo »

csdvrx wrote: post #135
pbohun wrote: post #122

Earlier quoted context omitted.

This is great! Someone else mentioned binfmt_misc. I didn't know about that.

The next step is to isolate the Windows applications: you could use different WINEPREFIX, but I think the better way is to do it like android: one "user" per application. It's not just to prevent applications to read other applications files, but also to firewall each application individually For example, if you don't want the application you've mapped to user id 1001 to have any networking, use iptables with '-m own…

> It's not just to prevent applications to read other applications files, but also to firewall each application individually

Why would one want to prevent applications from reading other applications' files?

We're talking about running desktop applications designed for an OS that isn't built around any concept of application isolation, and for which using a common filesystem is a primary mechanism of interoperability.

Post reply on HN