@CapitalB @bonifartius suckless assumes every user is a computer scientist and thus not scalable or reasonable.

@icedquinn
> to paraphrase deming, a slightly different building code in every state does more to damage mass production than a universal tariff

sure, but mass production is also about simplifying things by reducing parts.

i can get why people like the result, but the way it's done is bad and will create harder problems in the future.

it's not limited to computers. it's like this for many things that aren't extremely simple. washing machines! what was wrong with turning the mechanic program knob and pushing the mechanic "on/off" button? worked fine and was repairable, much like software was compiled with relative ease.

i know no one who uses washing machine control apps (which will cease function in 3 years anyway, because the manufacturer turns off the cloud..).

@bonifartius how is targeting flatpak bad though?

@icedquinn it isn't inherently bad, it removes the need to think much about dependencies which apparently most people view as invitation for "just another lib bro". which then turns the whole thing into "runs exclusively on flatpak" because something of the dependency tree will always be missing.

something missing is easy to solve when it's only half a dozen libraries, just package them as well. if it's in the hundreds, things get ugly very fast.

@icedquinn @bonifartius

You have a good point but I don't want to use it. We have native package managers

@verita84 @bonifartius well that's fine, you are free to take up reboxing the product to appease your local bikeshedders.

@verita84 @bonifartius i have personally dealt with trying to do such a thing with some music software on void / alpine.

such issues i've run in to are things like
- we don't like how that project wrote their build scripts, please rewrite upstreams build scripts to appease us
- someone else is already working on that package (hasn't updated in months, no updates on approvals or rejection)
- we don't like the way you marked that CPU as a non-supported target, please change it to a case statement. update: unrelated maintainer doesn't like that you approved the case statement, please rewrite the script to use an if/else*
- no sorry that requires .NET which we will never approve because we don't approve of the bootstrap requirements of the C# compiler

* this is the issue where i started referring to all upstreams as bikeshedders because their change requirements were literally pointless

@icedquinn @bonifartius

Linux does need some standards. I complained about fragmentation for many years. I don't even care what package manager they choose, just make some standard s at this point

@verita84 @bonifartius writing your own package manager is like the right of passage of distros. same as how everyone used to write their own window manager.

while i dislike RHEL and freedesktop overall, flatpak does work.

@icedquinn @verita84 @bonifartius that sounds maddening!

@hazlin @verita84 @bonifartius it is now imagine doing it N times.

there's a reason nobody cares and you get maybe centos and ubuntu as targets from corporate software.

even foss software there is typically a home distro the dev lives on and the rest of the packaging is contributed.

the deming allegory absolutey fits here.

@icedquinn @bonifartius don't package it for 20 distros, instead you use a standard, decent build system, list your dependencies clearly, package it for one distro, the one you use (or no distro if you don't use any)

then people that want your software in their distro will package it

flatpaks are fine as basically another distro to target, but the problem comes when upstream assumes flatpak is all that is valid to use and use that as an excuse to have a shit build system, and then screams about how everyone trying to package it for their distro is wrong and should use the dev-approved flatpak instead

@navi @bonifartius i basically said something similar to this; people are free to repackage locally. just don't expect upstream to do it because we have more important things to do than care about your policing of esac/fi statements in bash.

the build system is always bad, though. that's been a universal law in gamedev since forever.

@icedquinn @bonifartius as long as you don't act in bad faith towards packagers, it'll all good

it's often that distro packagers find bugs and even open PRs to fix them (considering it's foss) -- packaging non foss is usually not allowed tho so for games that's usually the big problem

and meson is the only decent build system of the bunch :)

@navi @bonifartius meson gets a solid F grade from me because they don't let you control builddir and the ticket for this was wontfixed.

as someone who had to build LV2 plugins, i was not able to port them to this system.

@icedquinn what do you mean "control the build dir"?

@navi meson has strong opinions about how output artifacts should be placed esp around the config.h file that it generates.

i tried to have a project compile some audio code in 2-3 different output formats but meson would not allow me to do both. LV2 requires a very specific layout and naming structure and to accomplish it would require tampering with meson in ways that made it unable to also write the non-LV2 version

@navi there are arguments to be made that i could have a post-build step that copies and renames things to the right format. and i could have done that. it would then re-add having a task runner to the project to actually do that and we're now back in to "the build system is always shit."

i had a similar problem with please.build where it wants so badly to be a hermetic build engine that it struggles in places where i knowingly do wish to inject concerns from the outside world in to it (such as the current git revision the build belongs to.)

@icedquinn hmm, i can't exactly understand the issue but rn my brain is exhausted

i'll try to look up LV2 tomorrow or smth

@navi its a very niche issue. i remember there was a ticket about it because someone else was having a related issue where their build path needed to meet very specific external requirements, and it was wontfixed as meson does what it wants fuck you.

if outside constraints aren't slamming against meson's opinions its quite decent.

@navi @bonifartius my current favorites are basically
- tup
- please.build
- knit*
- honorable mention to redo, but i don't use it

knit is basically plan 9 mk wrapped in a small amount of lua. i don't know that the lua actually helps, but its easy to build anywhere go runs.

both tup and knit support exporting to a non-parallel bash script to appease build servers. knit also supports exporting a ninja file if for some reason you don't trust its internal engine of the same. tup monitors the system to infer all dependencies, so all i have to do is tell it `spoopy.nim |> nim c spoopy.nim |> spoopy` and with no further help or language specifics infers everything that includes along the way and i never touch shit again.

please comes with too much premade but you can bypass most of it. its like bazel on a diet, or buck if it was useful.

@nanook i don't ask anyone to compile for my platform. compiling is what distributions do. i ask to not make this extra hard to do so out of laziness.

"works on my machine" used to be a joke made about shitware, now people think it's good practice.

i can compile stuff from the 90s with a few patches, i don't expect i'll be able to use flatpaks in five years. flatpak will be replaced with the next reinvented wheel by then.