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

Loss32: Let's Build a Win32/Linux

loss32.org

Post reply on HN
Print view View original

161–170 of 493 posts

Re: Loss32: Let's Build a Win32/Linux

#161

Post by freedomben »

Imustaskforhelp wrote: post #160
BirAdam wrote: post #123

Earlier quoted context omitted.

AppImage, theoretically, solves this problem (or FlatPak I guess). The issue would really be in getting people to package up dead/abandoned software.

https://zapps.app/ is another interesting thing in the space. AppImage have some issues/restrictions like it cant run on older linux than one it was compiled on, so people compile it on the oldest pc's and a little bit of more quirks AppImage are really good but zapps are good too, I had once tried to do something on top of zapp but shame that zapp went into the route of crypto ipfs or smth and then I don't really se…

Interesting. I've had a hell of a time building AppImages for my apps that work on Fedora 43. I've found bug reports of people with similar challenges, but it's bizarre because I use plenty of AppImages on F43 that work fine. I wonder if this might be a clue

Re: Loss32: Let's Build a Win32/Linux

#162

Post by yjftsjthsd-h »

scrivanodev wrote: post #149
BirAdam wrote: post #123

Earlier quoted context omitted.

AppImage, theoretically, solves this problem (or FlatPak I guess). The issue would really be in getting people to package up dead/abandoned software.

I can only speak for Flatpak, but I found its packaging workflow and restricted runtime terrible to work with. Lots of undocumented/hard to find behaviour and very painful to integrate with existing package managers (e.g. vcpkg).

Yeah, flatpak has some good ideas, and they're even mostly well executed, but once you start trying to build your own flatpaks or look under the hood there's a lot of "magic". (Examples: Where do runtimes come from? I couldn't find any docs other than a note that says to not worry about it because you should never ever try to make your own, and I couldn't even figure out the git repos that appear to create the official ones. How do you build software? Well, mostly you plug it into the existing buildsystems and hope that works, though I mostly resorted to `buildsystem: simple` and doing it by hand.) For bonus points, I'm pretty sure 1. flatpaks are actually pretty conceptually simple; the whole base is in /usr and the whole app is in /app and that's it, and 2. the whole thing could have been a thin wrapper over docker/podman like x11docker taken in a slightly different direction.

Re: Loss32: Let's Build a Win32/Linux

#163

Post by yjftsjthsd-h »

mainde wrote: post #82
mikkupikku wrote: post #33

Crazy how, thanks to Wine/Proton, Linux is now more compatible with old Windows games than Windows itself. There are a lot of games from the 90s and even the 00s that require jumping through a lot of hoops to run on Windows, but through Steam they're click-to-play on Linux.

It kinda works both ways, just yesterday I tried to play the Linux native version of 8bit.runner and it didn't work, I had to install the Windows (beta) version and run it through proton.

Funny story: I use Anki (the flashcard program), and I run it on my NixOS laptop. There is a NixOS/nixpkgs package for Anki. It doesn't work. You know how I run Anki, which has a native GNU/Linux version and even an actual nixpkgs package, on my GNU/Linux NixOS laptop? Yeah, I run AnkiDroid, the Android version, through Waydroid. Because the Android version works.

Re: Loss32: Let's Build a Win32/Linux

#165

Post by bruce511 »

realusername wrote: post #147
rep_lodsb wrote: post #129

Earlier quoted context omitted.

So every Linux distribution should compile and distribute packages for every single piece of open source software in existence , both the very newest stuff that was only released last week, and also everything from 30+ years ago, no matter how obscure. Because almost certainly someone out there will want to use it. And they should be able to, because that is the entire point of free software: user freedom.

Not sure if it's the right solution but it's a description of what happens right now in practice yes.

It also makes support more or less impossible.

Even if we ship as source, even if the user has the skills to build it, even if the make file supports every version of the kernel, plus all other material variety, plus who knows how many dependencies, what exactly am I supposed to do when a user reports;

"I followed your instructions and it doesn't run".

Linux Desktop fails because it's not 1 thing, it's 100 things. And to get anything to run reliably on 95 of them you need to be extremely competent.

Distribution as source fails because there are too many unknown, and dependent parts.

Distribution as binary containers (Docker et al) are popular because it gives the app a fighting chance. While at the same time being a really ugly hack.

Re: Loss32: Let's Build a Win32/Linux

#166

Post by microtonal »

ori_b wrote: post #79
senfiaj wrote: post #50

This might offend some people but even Linus Torvalds thinks that the ABI compatibility is not good enough in Linux distros, and this is one of the main reasons Linux is not popular on the desktop. https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s

To quote a friend; "Glibc is a waste of a perfectly good stable kernel ABI"

At least glibc uses versioned symbols. Hundreds of other widely-used open source libraries don't.

Re: Loss32: Let's Build a Win32/Linux

#167

Post by duped »

amelius wrote: post #97
duped wrote: post #65

Earlier quoted context omitted.

It's really just glibc

Can't we just freeze glibc, at least from an API version perspective?

The problem is not the APIs, it's symbol versions. You will routinely get loader errors when running software compiled against a newer glibc than what a system provides, even if the caller does not use any "new" APIs.

glibc-based toolchains are ultimately missing a GLIBC_MIN_DEPLOYMENT_TARGET definition that gets passed to the linker so it knows which minimum version of glibc your software supports, similar to how Apple's toolchain lets you target older MacOS from a newer toolchain.

Re: Loss32: Let's Build a Win32/Linux

#168

Post by Y_Y »

senfiaj wrote: post #126
dralley wrote: post #70

Earlier quoted context omitted.

While true in many respects (still), it's worth pointing out that this take is 12 years old.

Maybe it's better now in some distros. Not sure about other distros, but I don't like Ubuntu's Snap package. Snap packages typically start slower, use more RAM, require sudo privileges to install, and run in an isolated environment only on systems with AppArmour. Snap also tends to slow things some at boot and shutdown. People report issues like theming mismatches, permissions/file-access friction. Firefox theming co…

Ubuntu was getting too good so it had to snap half of its value out of existence.

You can still get firefox as a .deb though.

https://launchpad.net/~mozillateam/+archive/ubuntu/ppa

Re: Loss32: Let's Build a Win32/Linux

#169

Post by mook »

muth02446 wrote: post #118
amelius wrote: post #94

Earlier quoted context omitted.

You never ran into a GLIBC version problem?

Wasn't there also DLL hell on Windows? My understanding is that very old statically linked Linux images still run today because paraphrasing Linus: "we don't break user space".

Unfortunately you can't really statically link a GUI app.

Also, if you happened to have linked that image to a.out it wouldn't work if you're using a kernel from this year, but that's probably not the case ;)

Re: Loss32: Let's Build a Win32/Linux

#170

Post by dvdkon »

andrewf wrote: post #13

Starting with FreeBSD might be easier than starting with Debian then removing all the GNUisms. But perhaps not as much Type II fun.

I think Linux is the better choice for replacing the entire userland. From what I've seen, the BSDs don't have such an accessible userspace/kernelspace split. With some effort, on Linux you could probably just run an exe as your init.
Post reply on HN