71–80 of 235 posts
Earlier quoted context omitted.
even with snaps or whatever that thing ubuntu has?
Not everyone is on Ubuntu. I currently have eight VMs each with different distros. Mostly it's for testing library compatability on install and input weirdness. That's a lot of testing.
The Linux Mint experience of the author is strange. I was able to install with no problems on three very different machines (Dell Inspiron, HP Laptop (forgot the model, it's my daughter's) and an assembled game PC featuring 4 Monitors). The only qualm I have with it: For fear of data loss I decided against full disk encryption (the installation procedure asks for it) in expectation that one can switch after installat…
There was an interesting thread on Reddit [1] the other day which did a breakdown of the state of gaming in terms of native games and games that can be run easily via Steam Play (aka 'Proton', Valve's in-built WINE+DXVK layer). The results were quite interesting and, as one of the replies pointed out in another breakdown, Linux now competes with (and in some ways beats) gaming on macOS in terms of size of catalogue.…
Earlier quoted context omitted.
> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions If you don't want to worry about the glibc version on your users' machines, you can just ship your dynamic linker and use it to run your executable in your wrapper script (you do have one, right?). Why's that so hard?
It's not hard, it's just stupid that the platform has such a remarkable lack of consistency that you can't rely on anything but the kernel ABI.
Until one day it just stops working... won't boot, logs you out immediately after logging in, random UI components become corrupted etc.
At this point I always end up thinking... Well I've got reboot into Windows now anyway so why bother sifting through Stack Overflow for hours trying to fix Ubuntu.
Earlier quoted context omitted.
Not everyone is on Ubuntu. I currently have eight VMs each with different distros. Mostly it's for testing library compatability on install and input weirdness. That's a lot of testing.
Snaps work on other Linux distros, not just Ubuntu. There is also Flatpak which may work even better. You should do your research.
From what I understand about Snap, the only difference is that that the One True Repo is installed by default.
AppImage is another option he could consider, which requires no repos or additional installs, just flipping the execute bit on the AppImage file. Unfortunately even that is spotty because there is no standard set of libraries to rely on like there is on other platforms, so he'd pretty much have to include everything from glibc up to be safe.
Glad that Ubuntu works well for the author, but I've used Ubuntu on and off for a good 5+ years, and could fill a book with small things that just don't work quite right, and cumulatively makes it feel like I'm fighting the computer instead of working with it. As a brief taste: * No trackpad swipe gestures (plus many more subtle trackpad issues) * Pre-Wayland the only way to attach a second screen at a different DPI…
Glad that Ubuntu works well for the author, but I've used Ubuntu on and off for a good 5+ years, and could fill a book with small things that just don't work quite right, and cumulatively makes it feel like I'm fighting the computer instead of working with it. As a brief taste: * No trackpad swipe gestures (plus many more subtle trackpad issues) * Pre-Wayland the only way to attach a second screen at a different DPI…
* "Supported" ubuntu was so old that neither Chrome nor Firefox would update
* Latest ubuntu constantly toggled the backlight at 30fps (yes, really).
* They didn't provide a driver package, instead they provided a utility to bake drivers into install media. Naturally, it didn't work, the documentation described a significantly different version.
* All these problems were well-represented in forlorn solutionless forum / stack overflow threads.
Earlier quoted context omitted.
> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions If you don't want to worry about the glibc version on your users' machines, you can just ship your dynamic linker and use it to run your executable in your wrapper script (you do have one, right?). Why's that so hard?
It's not hard, it's just stupid that the platform has such a remarkable lack of consistency that you can't rely on anything but the kernel ABI.
Having said that, I strongly prefer Linux's explicit shared object search paths and very user-friendly dynamic linker to Window's implicit search scheme (aka the DLL hell). If that means I need to add my dynamic linker along with a couple lines of wrapper script so my binaries work, so be it.
And, you can even avoid the wrapper script if you can make sure your stuff is always installed to a standard location (eg. /opt/yourcompany) and you pass -Wl,rpath to your linker (at compile time) but I really don't see the point.
Earlier quoted context omitted.
> It's still a PITA to deploy a compiled app on Linux with unclear glibc versions If you don't want to worry about the glibc version on your users' machines, you can just ship your dynamic linker and use it to run your executable in your wrapper script (you do have one, right?). Why's that so hard?
It's not hard, it's just stupid that the platform has such a remarkable lack of consistency that you can't rely on anything but the kernel ABI.