LinuxMusicians

I know LMMS checks for system libs, but if it cant find those it will use its own libs.

I love appimage versions.

merlyn wrote: ↑Thu Aug 04, 2022 12:48 pm One approach is the Debian approach of never updating anything if it can be avoided,

Ups, that is a totally wrong conclusion. Debain consist in branches, from old stable to sid. Debian sid is mostly up to date like arch is, and, is a rolling release. I use it now longer then 20 years, and if I wouldn't update my hardware, I would run the very first installation I've made, still, up to date.
On top, if you would see your work adapted into debian, your barrier is debian/sid. You've to ensure that your project works flawless with debian sid. Only then, when it get accepted in debian/sid it could go into testing and later on into stable.
(Don't mention the experimental debian branch here, as it only play a role during the freeze phase)

tramp wrote: ↑Thu Aug 04, 2022 1:23 pm Debian sid is mostly up to date like arch is, and, is a rolling release.

Why then is jeff complaining about software in the repos being out of date? He obviously isn't using sid. A rolling release of any sort would solve the problem of out-of-date software in the repos.

Furthermore, sid is marked as unstable. You wouldn't use it in a production environment.

erlkönig wrote: ↑Thu Aug 04, 2022 2:32 pm Furthermore, sid is marked as unstable. You wouldn't use it in a production environment.

Unstable in that context means that system library's could be updated, as well as applications. They are not bound to a stable release tag.
But, at least you self decide when doing a update and when not. So, when you are in the middle of a production, you be carefully before update your system, that's all. There is no diff to any other rolling release like arch.
As a developer, you may want to look ahead to ensure that your work not break within the next release of a stable distribution, so, in my opinion, best development platform is a rolling release. As far I remember that was what the opening post was about.
Try to tell developers to use a old stable distribution is like telling musicians not to use any instruments.

j_e_f_f_g wrote: ↑Wed Aug 03, 2022 2:35 am The amount of hassle getting linux music software working has gotten out of hand.

We need to reign in this monster. It needs to be more like MacOs and Windows in its ease of use.

The idea is good, but the devil is in details. MacOS and Windows are not one guy. They are massive companies, with money and status.
AVLinux is one guy, KXStudio is one guy. Even ubuntu studio is not a main project of Canonical.
Linux Audio have the advantage of Jack and Linux-RT, that can provide the best performance on theory, compared to the proprietary alternatives.
Currently, the biggest linux audio project is Debian Multimedia.
https://wiki.debian.org/DebianMultimedia

thetotalchaos wrote: ↑Thu Aug 04, 2022 6:58 pm ...
Currently, the biggest linux audio project is Debian Multimedia.
https://wiki.debian.org/DebianMultimedia

Do you have a comparison with others repos?

Kott wrote: ↑Thu Aug 04, 2022 10:24 pm

thetotalchaos wrote: ↑Thu Aug 04, 2022 6:58 pm ...
Currently, the biggest linux audio project is Debian Multimedia.
https://wiki.debian.org/DebianMultimedia

Do you have a comparison with others repos?

I don't, but the internet does.
https://salsa.debian.org/multimedia-team?page=1

thetotalchaos wrote: ↑Thu Aug 04, 2022 10:53 pm

Kott wrote: ↑Thu Aug 04, 2022 10:24 pm

thetotalchaos wrote: ↑Thu Aug 04, 2022 6:58 pm ...
Currently, the biggest linux audio project is Debian Multimedia.
https://wiki.debian.org/DebianMultimedia

Do you have a comparison with others repos?

I don't, but the internet does.
https://salsa.debian.org/multimedia-team?page=1

I'm aware of this repo, and it's not a comparison.
Simple question, how many lv2, vst(3), standalone effects/instruments it provides?

Once again, there are certain people completely missing the point, and instead arguing with their own straw man,

I'm not saying "Devs, don't release your source code. Release only a binary, and thereby force everyone to use some sort of lowest common denominator."

I'm saying "Devs, don't release only your source code, and expect distro makers and/or endusers to compile binaries. Nowadays, distro makers can't keep their repos uptodate with all the software out there. And most endusers either don't know how, or don't want to, compile software. Therefore. also include a binary, compiled on a minimal base standard that should make it runnable on most distros. This is needed to bridge the gap in enduser ease-of-use between Linux versus Windows and MacOS".

If you're a person whose knee-jerk reaction is to reply "I don't want to be forced to use that binary.", then stop posting in this thread. Because you just don't get it, and you're arguing with a straw man.

Now, there is some debate about the best way to produce linux binaries. The available choices are:

1) Keep the current trend of expecting every distro maintainer to sync to the latest version of your software in their repos. Or every enduser to compile your source code.

Does nothing to solve the ease-of-use gap, and ignores the reality that endusers overwhelmingly do not want to compile code, and distro maintainers can no longer keep their repos uptodate. Not a solution.

2) Use AppImage, Snap, Flatpack, or some sort of "container" technology that "tethers" a binary and its dependencies.

It works. But it's not ideal for production of real-time content like audio/video.

Unfortunately, this is where linux binaries are going. Expect more distro makers cutting back the selection of software in their repos, and instead forcing endusers to rely upon snap, flatpack, etc binaries for esoteric stuff like music production apps. If we don't get music devs to target testing/deployment of binaries to some minimum standard music base, then this is our future.

3) Get music devs to target testing/deployment of binaries to some minimum standard music base. Educate them about the need to include those binaries in their releases. And as an aside, get people who completely miss the point to stop trying to derail the effort.

4. Use OBS (or other build service) to produce packages for major distros.
5. Use GH Action for similar task, more flexible, but no repositories in result, just binaries.

Kott wrote: ↑Thu Aug 04, 2022 11:41 pm 4. Use OBS
5. Use GH Action

Stop right there. We don't need solutions from privately owned commercial entities, pay-for services, or the like. Start another thread if you want to discuss those.

suse, github, etc are irrelevant to what i proposed.

j_e_f_f_g wrote: ↑Fri Aug 05, 2022 12:26 am Stop right there.

I wont.

We don't need solutions from privately owned commercial entities, pay-for services, or the like. Start another thread if you want to discuss those.
suse, github, etc are irrelevant to what i proposed.

who "we"?

you're using internet and sourceforge for your programs, aint that the "privately owned entities"?

@j_e_f_f_g you seem out of your depth here. Missing your point and disagreeing with it are very different things unfortunately. This really does seem like a you problem. If you are using a distribution where you have to compile binaries regularly and you don't want to do that try another distribution. That's what Linux is all about, choice. I think most people like its versatility and community nature. Personally that's why I use it. When you have distributions maintantained by one person or a small group you have to make certain compromises. I would recommend you try manjaro, for me it's the one with the least compromises for music production. It's already doing everything you want. Every application you could want is available in the repositories with no compiling needed. The stock kernel is preemtable. You won't ever find any dependency issues because everything is available and up to date.

In short, you are trying to force what is essentially a LTS distribution to run software that is designed for more bleeding edge systems. Why? Just use a distribution that is already up to date. Developers shouldn't have to release software that's missing features that could be available to them with newer versions of the dependencies. Otherwise what's the point of releasing new versions?

Kott wrote: who "we"?

Context, man.

I'm talking to, and about, developers of linux music software. If the issue of making it easier for users to get music app binaries is to be improved, then devs are the ones to do it. Distro packagers are overtaxed and falling behind. Users lack the skills, and typically the inclination, to do it. The ball's in the devs' court.

you're using sourceforge for your programs

Not to create/test my binaries (which I provide). I do that myself.