LinuxMusicians

All are imperfect, I like AppImages personally, quick, easy, self-contained and deleted and updated very easily without any system-wide disturbance.. tried a couple of FlatPaks and hated the system intrusions, Know nothing of Snap as I'm not a 'buntu User but it sounds like Flatpak made worse..

merlyn wrote: ↑Tue Sep 06, 2022 2:50 pm I think the tendency is that after a few years of using Linux, users will end up on a rolling release.

nils wrote: ↑Tue Sep 06, 2022 4:54 pm All converges to Archlinux with just system packages.

That, or you get comfortable and switch to Linux Mint

Their take on Snap: (See Snap section) https://blog.linuxmint.com/?p=3906

In Linux Mint 20, APT will forbid snapd from getting installed.
You’ll still be able to install it yourself and we’ll document this in the release notes, but by default APT won’t allow repository packages from doing this on your behalf.

That is downright evil, and yet another reason I'll never touch ubuntu again - and will advise the same to anyone else. It's an open door to malware

noedig wrote: ↑Wed Sep 07, 2022 5:49 am [...]
[Linux Mint's] take on Snap: (See Snap section) https://blog.linuxmint.com/?p=3906

In Linux Mint 20, APT will forbid snapd from getting installed. You’ll still be able to install it yourself and we’ll document this in the release notes, but by default APT won’t allow repository packages from doing this on your behalf.

Thank you for that link! It explains more on how Ubuntu uses Snap than Ubuntu does. A very interesting qoute from that article:

[...] in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. [...]

Bloody hell, those Ubuntu boys are at it again. I thought they learned their lesson with the "Unity" desktop environment that nobody wanted and only was installed in Ubuntu. Since nobody used it nobody on forums knew how to handle that monstrosity. Made me switch to Mint. Had I known this Ubuntu 20.04 LTS Snap SnAFU then I'd never switched back.

Working in IT, I'm used to toy with containers.
Of the five systems mentioned I'm only familiar with Snap and Docker but I can add LXC, Podman and Singularity in the bag.

They are everywhere in IT for the simple reason that they make things simple and efficient provided that you have a certain level of expertise (that I don't have (yet)).
For a dev they are a blessing, for a home user/linux beginner they ease things a lot but for an intermediate/advanced user-consumer they are a burden, specially for those who carefully setup and fine-tune their system as us here do.

As written above, Ubuntu are shoving snaps under the hood and this is a really crappy thing. For that reason alone Linux Mint is worth a try.
If waiting for a new release is impossible and containers are a no-go, a rolling distro like Arch is a good solution.

Nevertheless, containers are here for a long time and can do great things so if you have time, read about them and maybe try to use them for what they are best for like a private Nextcloud or Rocket.Chat server

We have two problems that these technologies are trying to overcome. Most of you know this stuff already, but for those who don't here's a quick explanation:

1. Because of the very nature of Linux, and the whole freedom philosophy, instead of a single OS, Linux is in fact currently 600+ similar distributions of separate OSes that are colloquially called Linux-- or for the the FSF hardcores, GNU/Linux. While there are similarities enough to make many things work, there is always going to be differences enough to dissuade proprietary source code development such as freeware or commercial software.

2. The key problem here is package conflicts and dependency hell. As a result, instead of compiling for each and every distro, developers generally compile for the most popular distro or possibly the top distros with DEB files or sometimes RPMs. An alternative solution used is to package binaries as a tar.gz or a zip with a install script that places the binaries--if not that, then they use manual (Readme) instructions stating where to manually place the binaries. And, even with all that, it was still likely compiled for just one distro (Ubuntu). Few developers truly "support" it outside of Ubuntu. They label it "experimental" with an "all sales final disclaimer" and instructions to "try before buying".

The linux community has tried over and over to resolve this problem. The linux hardcore neckbeards have screamed that the right way to solve the problem is to come up with a common base standard of shared libraries. The Linux Standards base was created and then failed. Others have had other suggestions that didn't work. For 20+ years this problem has been talked about and complained about with no true solution. Many came to the belief that this problem is never going to be resolved, and we'll always have incompatible distros, and we need to just accept it and just move on.

So, understanding that this common standard between Linux distros is unlikely to ever happen, "Plan B" was implemented--Flatpak, Snap, AppImage, etc. It's not ideal solution, but we must remember that another, better solution hasn't yet been found, and a common base has failed and the problems have existed for 20+ years. One possible solution that comes to mind would be something like an expanded build service like openSUSE's OBS. Otherwise, Plan B is what he have.

Now, remember, this is just for proprietary code. This problem doesn't exist with open source where everything can be compiled specifically for the target OS. But for proprietary, there does not appear to be a better solution.

None of the sandboxed package formats (for lack of a better name) is perfect. I flat out don't like Snaps. I like Flatpak and Appimage, but each of these formats have their own problems, and aren't quite ready for music production with the host and client concept. However, interestingly enough, there is some proof of concept that some of this works with Flatpak:

https://fediverse.blog/~/TheVostronixBl ... 0%3D%20Fun

I don't know if plugins work with Appimage or not (packaged or unpackaged). Virtualization (with I/O passthrough) and compatibility layer options are not perfect but possible alternatives: Docker, Podman, Virtualbox, WINE, KVR/QEMU, etc. But they too are less than ideal.

Over all, as far as proprietary source software goes, there doesn't yet exist a perfect solution, but it's likely the only solution that will ever come. It will be interesting to see which format succeeds where the others fail. But without some solution to proprietary source software, developers will never mass develop commercial software on the Linux platform like they do on Windows or Apple. We need to be thinking about this and keeping our minds a little more open.

I agree with you, audiojunkie. But I do want to emphasize that a "standard base" does work... for the Microsoft and Apple ecosystems (and even for Google's Android ecosystem, which is not quite as "cohesive" as the former two). But it requires a very strongly influential, and ambitiously active standards body (or controlling entity), which linux does not have. Certainly the folks who did the LSB (Linux Standard Base) are not such a strong example.

Nevertheless, Linux audio is such a small group of devs/consumers at this time, that I think it would be quite feasible to establish a "standard music base" without requiring the existence of a centralized standards body. That's why I suggested it.

Will enough people realize the benefit of it, and help attain that goal? Even though I suggested it, and believe in its potential, I recognize that there are too many linux folks who don't know what they're talking about, and yet seem to have an intractable opinion on whatever is being discussed. These people will derail anything given the opportunity, with truly misguided, irrelevant strawman arguments. So even I don't consider it likely to happen. But I still favor the concept.

Anyway, it looks like flatpack it is. Everyone get ready for yet another packaging scheme that will make old instructions/tutorials/solutions no longer work, and will require you to install/learn yet another reinvention of the wheel (this time even more complicated, and likely be the straw on the camel's back that forces you to finally surrender to systemD whether you like it or not). This is your future, folks. Lie in the bed you made.

One issue I have with flatpak and snap is the huge runtimes that need to be installed before being able to use a single application. Something like .NET or Java, an operating system within an operating system.
Appimage is different in that it packages dependencies inside its own self-contained package which is ok for a small number of packages but impossible to base a whole system on.
None of these containerised application systems effectively integrate into the operating system as a whole.

Audiojunkie wrote: ↑Sat Sep 10, 2022 1:31 am [...]
Now, remember, this is just for proprietary code. This problem doesn't exist with open source where everything can be compiled specifically for the target OS. But for proprietary, there does not appear to be a better solution.
[...]

I agree with your reply. However, in my experience open source software is sometimes also distributed as such a "sandboxed packaged app". This is because distributions that are a few years old (but still supported like Ubuntu LTS) will not run the latest version of certain software. Some apps must be compiled against the latest libraries that are not available for said distro. Which brings us back to another argument that's been brought up here: that darned lack of backwards compatibility of libraries in Linux. We can learn something from Windows here.

And it brings me back to a pet peeve of mine: why oh why do developers always want to use libraries that are brand new and therefore not back compatible? If you link your application to slightly older, but very stable and able, libraries then there's no problem. Sometimes we Linuxers have to upgrade our distro to a minor version to run a necessary update.


P.S. I think that every Linux application in the whole wide world must run in Debian Stable. That distro is, well, stable! And Debian doesn't upgrade it's distro every year: a Debian Stable installation will last you a long time. Too bad that Stable has software that all but deprecated at the moment of release, but that's another story...

Linuxmusician01 wrote: why do developers always want to use libraries that are brand new and therefore not back compatible?

Most likely, bug fixes.

that darned lack of backwards compatibility of libraries in Linux.

There you have it. You've identified Linux's biggest problem (well, besides the tendency to reinvent the wheel, in ways that don't yield enough benefit).

The issue of handling backward compatibility is actually a simple one. But the problem is that, in order for it to work, it must be handled by the developers ("upstream" in linux parlance). But Linux does it the wrong way, and instead leaves it up to distro maintainers ("downstream") to resolve incompatibilities. So linux can't solve the "dependency hell" problem the correct way, and must instead resort to having every executable "self-host" (be combined/distributed with) compatible versions of all its libraries.

The correct way to handle this is:

When a developer creates a new, backwardly incompatible version of his lib, he MUST officially designate a new filename for the .so binary. For example, if his version 0 is "libmystuff_0.so" then the new version must be something like "libmystuff_1.so". This renaming must NOT be left up to the distro maintainers. They must not be allowed to take a version of that lib and either rename it, or create a symlink to a different version. The binary filename for a given version must be syncronized across all distros.

If other devs want to use this new version, then they must make any needed mods to their sources, and recompile their software. Distro maintainers should not take it upon themselves to update older software to use this new version by creating a symlink to it, nor recompile the old software to use a new incompatible version. Old software should continue using the old version, even if it's feasible that the old software could work with the new version.

If a new version of the library is 100% backward compatible, then the filename must not be changed. Distro maintainers must NOT be allowed to distinguish a new version from older versions via the filname. They should be using a different method for keeping track of what version they're distributing. That should be the reason d'etre for a distro maintainer ("making sure all the required libs are distributed for the included software" -- not "updating software to use the latest version of libs").

j_e_f_f_g wrote: ↑Sun Sep 11, 2022 2:23 am

Linuxmusician01 wrote: why do developers always want to use libraries that are brand new and therefore not back compatible?

Most likely, bug fixes.

I always thought that it's because they've updated their development computer to the latest distro. It's very good practice to use the most bug free libraries, but IMHO most "updates" (be it software, hardware or technology in general like smart phones) add nothing important or fix anything important. It's always minor. Most people don't bother checking what the update actually fixes and blindly click on "update" out of fear. Only out of fear. I've worked on Helpdesks and believe me: many, many, many problems arise out of unnecessary "updates".

While i agree none of those projects are perfect, I think it's important research&development progress.

Part of what makes this hard is that we are trying to reconcile conflicting goals: on the one hand it's silly when each application comes with its own copy of each library, on the other hand sometimes you *want* to ship an application with 'this library but actually with this slight patch' or 'that library but actually a really recent development version'.

Similarly, on the one hand you want everything to seamlessly work together out of the box, and on the other hand keep programs isolated so malware in one application doesn't immediately give you all the 'keys to the castle' of your other projects.

The problems are magnified when you want to run proprietary software: it's hard for a proprietary software vendor to create packages that match the available libraries on all distro's, and I sure don't want to give unaudited proprietary code access to my secrets.

Looking at duplication first: I think the solution here is that there is still a role for distro's to provide a consistent set of packages that are known to work well together. The 'image' technology should make sure different images that contain overlapping libraries work efficiently, and the distro should ship a collection of packages that maximizes the amount of overlap. Want to run a (possibly-proprietary) package from a 3rd-party? That's fine, but be prepared there will be less overlap with the rest of your system. Sure, we need better and more transparent ways to rebuild the packages instead of shipping generic 'black boxes' - one step at a time.

Then isolation: the author of the article this thread complains images require too many permissions. Yes, sure, I agree - but let's compare with the status quo: applications right now are not sandboxed at all! The possibility to sandbox them is already a huge improvement, even if we still have much to do to make sure sufficiently fine-grained and flexible permissions are possible so we don't need to give applications too many of them.

Are we there yet? Not by a long shot. But I think it's important that we keep exploring, since the 'traditional' distro approach isn't where it's at either.

For everyone following along since the beginning of this thread, I think it’s only fair that we look at both sides of the issue.

Below, I am posting a direct rebuttal to the OPs original article. It might be helpful to go back and read the original article first, before reading the rebuttal.

My point is that if we are all looking for a solution to the proprietary software on Linux problem, we need to know all sides of the issue. Currently, I’m liking Flatpak.

https://theevilskeleton.gitlab.io/2022/ ... uture.html

Developers having the latest and greatest kit is a trap. Their customers (mostly) don't want to keep changing stuff, and probably can't afford to, so the developer is potentially throwing business away. By all means use modern fast kit for work, but test on older kit to keep yourself relevant.

@folderol says

By all means use modern fast kit for work, but test on older kit to keep yourself relevant.

I would extend that sentiment to emphasize that building binary releases should be done using "older kit," preferably the set of libraries / headers which are shipped by the "oldest" LTS release available across the broad spectrum of distros. If an app cannot run at all on such an old release (as opposed to "won't be as performant" or "won't run as well", or even "feature X will be broken"), then documenting the minimum versions of all dependencies is the only alternative (and a much worse one).

The only way to ensure that "stray" newer dependencies don't creep into binary releases is to automate building and testing them using the "old stable" profile, using some form of CI/CD.