Live data from Hacker News

Convert Linux to Windows

philipbohun.com

341–350 of 459 posts

Re: Convert Linux to Windows

#341
post #130

Earlier quoted context omitted.

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

Re: Convert Linux to Windows

#342

The suckless project gave us stali linux, a statically compiled linux distribution. Doesn't static compilation solve quite a few of the problems states here? https://sta.li/

Yes. It’s the same reason AppImage could work — if the licensing allows for the all libraries to be included in the image, because the Linux syscall interface is generally stable. “We do not break userspace”

AppImages have a few problems. Ever seen how much dependencies you need installed to execute an AppImage?

You also need to be in an environment where you can create FUSE filesystems. And iirc the reference implementation requires the deprecates fuse2 library to work.

Snaps, Flatpaks, AppImages and static linking are all solutions to a real problem. But I don't think AppImages are an especially good solution.

I talked a bit with Richard Brown about supporting AppImages in Aeon, the OpenSUSE immutable distro. But he believed the base system would need far too much dependencies specifically to support the AppImage runtime including deprecated fuse2 support.

Re: Convert Linux to Windows

#343

Earlier quoted context omitted.

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

> These are however the same on Linux .. that doesn't break old code An example from another comment: https://news.ycombinator.com/item?id=43519949

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

Re: Convert Linux to Windows

#344
> MacOS has a feature called Gatekeeper, which limits what software you can run on your Mac to only those applications that Apple approves

This is a lie. Gatekeeper in no way limits the software you can run. It presents an easier experience to launch software downloaded from a browser if the developer chose to submit it to apple for a malware scan.

Re: Convert Linux to Windows

#345

Earlier quoted context omitted.

While the Java implementation is suboptimal, there is really no need for it to be that way. I think the ideal way to go about it would be to run the compiler optimisations and whatnot then generate something semantically similar to C89 as output. Then you invoke a simple compiler with few optimisations on the target machine the first time the program is run, and cache the results somewhere. On all subsequent runs, yo…

Do you know any software that does that?

Sadly not. Wasm is attempting something similar, but it lacks certain things that would be important for this (the to specify in one module a type of unknown size and then query its size in another module at link time).

Re: Convert Linux to Windows

#346
post #307

Earlier quoted context omitted.

You could say the same about container images for server apps. (Packaging is hard.)

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

I agree. Though it helps that Apple (NeXT, really) got it right with their .app directory format, even outside the app store.

Re: Convert Linux to Windows

#347
post #281
post #6

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.

I hit quirks with glib semi-regularly (~1/year) For example, recently I tried to run Emacs' Appimage and it has a glib issue https://github.com/probonopd/Emacs.AppImage/issues/22#issuec...

glibc, not glib. That's a different library.

Re: Convert Linux to Windows

#348

Earlier quoted context omitted.

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

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 Windows/Mac/Android/ios.

Re: Convert Linux to Windows

#349
post #128

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

> but you can't legally look at that stuff!

Hi, it's me, Mr Hair Splitting: to the best of my knowledge it's not illegal to read the source, but it would be illegal to use the source in your own application because you didn't author it or have a license to it

That's actually why the Wine and ReactOS folks want to disqualify folks who have read the source for fear they would inadvertently "borrow" implementation ideas, versus being able to explain to a judge how they, themselves, came up with the implementation. The key point is that Wine and ReactOS merely disqualify someone, not imprison or fine them

Re: Convert Linux to Windows

#350

> Try doing the same with a Linux binary that's just a year old. I do that all the time. Just link to a static glibc or musl.

I really want to statically link OpenGL and Vulkan for exactly this purpose, but neither use a wire protocol (unlike X11 or Wayland). The whole "loading library" scheme feels like hazing for any beginner graphics programmer on top of the already complex graphics APIs.
Post reply on HN