Gregory's Server@eevee Tbh, at the same time, I'm feeling weirded out at the sudden explosion of competing methods to package Linux software "windows style" by bundling all the damn libraries and stuff right with the app instead of adapting to what's provided by the system.
Does it work? I guess yes.
But it just feels so... weird and "wait, this must be against the rules, right?", especially as it's not as polished as Mac bundles either.
|
Top-level
18 comments
 @Tvorsk @eevee I think the final straw for me was having to deal with bug reports from someone who kept running the application I ported to Linux natively through wine because they can't build it themselves for some reason and the debs I built didn't run on their slightly different Debian derivative @Tvorsk @eevee it doesn't run all that well on wine (it bundles ANGLE, so you go through ridiculous two layers of graphics translation before you hit Mesa) but I guess being able to run it at all, even like that, was preferable to them I eventually just stopped shipping debs entirely because it was taking far too much time, and let a contributor package a snap, which had none of these issues  @whitequark @Tvorsk @eevee As a long time Linux user....yep. apt, et. al are great for slow moving things, but absolutely awful for constantly changing software. @whitequark @Tvorsk "snaps work more broadly than third-party debs" is a far cry from "simply rely on wine" @eevee @Tvorsk the underlying problem is "Linux userspace keeps breaking its ABI". there are several ways to deal with it, including "bundle almost the entire userspace or literally all of it in some cases" (snap, AppImage) or "build against an ABI that doesn't break" (wine) I don't think anymore that shipping a relatively simple GUI application in a way that works and keeps working on a broad range of Linux systems is a task a single person can reasonably manage, which is a problem @eevee @Tvorsk (or the cursed thing I did with wasm that I mentioned earlier) my position on this issue is informed specifically by extensively using Linux and shipping Linux software. it is and will remain my primary system, and the fact that I, as a Linux developer, have an easier time shipping software to macOS and Windows is absurd.  @whitequark @eevee @Tvorsk I mean, there is definitely something very important to learn from the fact that people are so desperate for a stable ABI and environment that they think Win32 will do, actually. @whitequark @Tvorsk "bundle almost the entire userspace" is what half of windows software does anyway, and as you are pointing out there is infrastructure developing around doing it on linux, so i don't know why you're saying it like it's wildly unreasonable for an external binary release @whitequark @Tvorsk but also this thread was originally about video games which often do not have any native gui whatsoever @hierarchon @Tvorsk @whitequark that's a weird comparison since you can install multiple versions of an .so but not multiple versions of a python library  @eevee @Tvorsk @whitequark most distributions that I've used only let you install one version of a package; you can have libfoo3 and libfoo4, but that assumes breakage only happens on major version changes @eevee @Tvorsk I think it's perfectly reasonable for a binary release of software to bundle the entire userspace (and rely on the kernel's ABI and, probably, X11's stability). this has significant costs, such as "you may have to bundle nvidia's proprietary drivers and that's quite difficult" or "your software can't natively pick up wayland because you ship ancient libSDL and never update". or you could use WinAPI as your ABI, which doesn't have those issues, but has some of its own @whitequark @Tvorsk @eevee one day I will take out a Big Hammer and get vendored musl working for X and Wayland stuff |
@Tvorsk @eevee this usually happens as a result of getting an endless stream of bug reports that boil down to things like "Debian ships a version of libstdc++ that is completely broken and has been for years" and waste an incredible amount of time that could be spent on literally anything else
static linking is the older solution for this issue, but it doesn't work for GUI applications, so here we are