Developer-driven software distribution is a bad idea, which is why I dislike things like Flatpak.

Having distro maintainers involved in the process and installing your software from a free software distribution like Debian or FreeBSD is a much better distribution of power. The packages can be tuned to suit their environment without the developer having to repackage it for every distro, and the distro maintainers can keep out anti-features like telemetry and advertising.

The middleman may seem annoying to developers, but embrace the model and it'll work for you. Landing packages in your favorite distro isn't actually that hard, and the rest of the distros will follow. If you're an end-user who wants to see some software available for your distro, look into packaging and volunteer - it's easy.

I get where you're coming from, but I don't agree on the middleman with you here, @sir.

The point of the distro is not to safeguard the user from upstream misfeatures. That's not why the distros arose in the first place. A software entry barrier is a mere byproduct.

Certain distros will go beyond providing you with the base system, true. I think Debian is the one which stores patches for upstream code when the publisher avoids addressing his users' demands.

Arch and Alpine will only recommend pristine upstream software, even if that introduces hostile functionality. The rationale is that, once the program is popular enough, not having it is a strike against the distro. And they can't go the Debian way either, for that will violate the design principles.

Offhandedly, it is simply a false claim that packaging software for your distro is easy as an entrant contributor. Sure, if you lack social credit, you can go the AUR way, but that is unsupported content and therefore can't be in any way considered part of software distribution. At which point we're back at square one, if users want to get the software, they'll have to ask the upstream.

@bugmenot I don't agree with any of this, except what distros were originally for - though not the implication that they need to still serve that original mission in order to be useful.

Arch tries for pristine upstream stuff, but Alpine is no stranger to patches when appropriate. No one is thinking about upstream software popularity's influence on downstream distro popularity, that has never been a problem for any distro.

And I also disagree that packaging is inaccessible. On Alpine at least, which is the distro I focus on, it's extremely easy.

@sir >though not the implication that they need to still serve that original mission in order to be useful.

I don't know what this actually means (what you're accusing me of) but I'm in favor of distros taking on tasks that help their users.

>On Alpine at least, which is the distro I focus on, it's extremely easy.

So a total stranger, can just get in touch with Alpine devs to package stuff that interests him? No vouching, no laundry lists, etc?

That is to say, I've known you primarily as an Arch user.

>No one is thinking about upstream software popularity's influence on downstream distro popularity

That doesn't apply to Web Browser packagers in general and distros, which strive to break free from proprietary software, will still package it in a separate repo making it clear it's only because users demand it.

@bugmenot you can make your own package trivially for Alpine, docs exist to help you and I'm sure you'd get help on IRC if you asked for it, and then sending it upstream is as easy as a gitlab MR or email to the appropriate mailing list.

I don't know what you're talking about with respect to web browsers.

@sir Help and IRC don't belong in the same sentence. At least that's my experience with any kind of IM. Self-help all the way!

Devs will package Web Browsers because users will complain if they're absent. Look at Arch's PKGBUILD for Firefox. It contains references to unique browsing trackers. Not cool they've to go to these lengths to be able to provide the software to their users.

@bugmenot oh, you can shove it, IRC is great and it's your own damn fault for not reaching out on it.

And it's very cool that Arch Linux is in a position to remove telemetry crapware from Firefox. That's the whole fucking point behind my argument.

Follow

@sir >And it's very cool that Arch Linux is in a position to remove telemetry crapware from Firefox. That's the whole fucking point behind my argument.

My point is they ain't doing that. They do the opposite.

>oh, you can shove it, IRC is great and it's your own damn fault for not reaching out on it.

That was your experience. A person with no credibility will find himself isolated on IRC.

Also, how Alpine deals with situational package contributors? Let's say a package breaks and the packager is nowhere to be found. Do they just strike it off the list and ban the (ir)responsible person?

@bugmenot IRC has nothing to do with credibility. If you ask your questions politely and wait patiently for an answer, you will get one. You're talking about some strange social credit system which simply doesn't exist.

As for absentee maintainers, packages may eventually be moved into the unmaintained repo, or another volunteer will jump in. The contributor is not banned for abandoning a package, yeesh, everyone understand that we've all got shit to do. There are tools for auditing the staleness of packages.

@sir Being genuflex and waiting for days didn't cut it for me. I usually got a few fleeting responses then silence. That being said, I am interested in obscure stuff, so YMMV.

I'll try Alpine even though I see a few roadblocks already. I respect their vision but it doesn't mean it's the right choice for everything.

@bugmenot @sir Welcome to the hackerspace. The rule of thumb for answers on IRC is whether the question was in the books. So you really have a point, why chat if you can just RTFM? BTW, if a project lacks concise docs on submission process but insists that you should ask around on IRC, it's an indicator that the community in question acts like a cult.

If you're exceptionally lucky, you might get insight on IRC. Usually it's reposted later on WWW. 1/2

@bugmenot @sir 2/2 E.g. git packfile format's documentation is an IRC channel excerpt. If anything, it's a strike against git. If you're looking for a personal VCS, I suggest Fossil as developers actually engage with the community on a tiny forum, the format documentation is better, etc. And I personally know Recoll's single developer as exceptionally accomodating, so you should consider helping him for nothing except being such a nice person among many douchebags.

@sir @bugmenot Opensource social credit system tends to be opaque and deniable. Once the project reaches a certain milestone or a critical threshold some aspects of it start to become more enshrined. No use digging our heads in the sand about that one.

I see reason behind excommunication process. The community was trusting you to be there when it breaks. You wasn't, so no one wants to deal with you anymore and waste their time. This also encourages maintainers to seek replacement for themselves

@interserver @bugmenot this is still such a wrong take. This simply is not how it works. And now you've described it as "denyable" so you can say whatever you want and dismiss anything I say to correct you.

@sir @bugmenot Show me someone in FOSS who openly admits to being partial. Human nature is incumbent. To be absolutely fair, opensource is much better than scene in that respect.

@interserver @sir Unfortunately, bans always imply some form of preemptive doxing to guard against returns under an alias. The merits sure are apparent to you, but I'm not in the least recognizant of your take as the proper solution.

@bugmenot @sir Fossil developers demand a fossil-scm.org/home/doc/trunk/ with the patch. If you aren't willing to be "doxed", you'll get no opportunity to contribute to opensource. Yeah, that sucks, but I was merely pointing out that projects will ban you for political reasons and I see no reason not to do that if you fail to show up for your duty.

@bugmenot @sir

Alpine solves this issue by allowing developers to do non-maintainer changes, which would be entirely non-controversial to fix a FTBFS issue.

@kaniini @bugmenot not just developers, but also anyone who can write the patch.

@sir @bugmenot as long as they can find someone to push it yeah. that's slightly more difficult.

@kaniini @bugmenot true, but it's much better now than it used to be.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!