Skip to main content


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.

2 people reshared this

This is also why I don't like developer-driven language-specific software repositories like PyPI and npm, Chrome and Firefox extensions, and so on, which unsurprisingly have constant problems with malware.

federico3 reshared this.

Caution shitpost: Everything should be writtin in reverse Polish notation for the lols.
(I also dislike Flatpak for being a massive fucking bloat)
(and also because dbus)
(basically, fuck flatpak)
Whats the issue with DBus?
unreliable message passing protocol which relies on one crashable user-level daemon with no security/access-control that everyone wants to use for very important stuff? (try a "pkill dbus" on your typical Gnu/Linux desktop/phone/… and see if it even recovers)
And if we run it in kernel-space or is it not possible?
oh my god please don't mention kdbus
god I hate pypi as an end user... Even using repository installed ansible on a redhat machine you still have to periodically hit your head against a wall because a bunch of the pypi packages required to use the azure modules are the wrong version or have dependency conflicts with rpm based python packages...

And this is the official way described in the ansible docs...

$ pip install 'ansible[azure]'
>The middleman may seem annoying to developers

which is a good thing ;)
To be fair many of those problems can just as easily crop-up in distributions. Not to mention if the distro packager isn't involved upstream they can easily screw-up implementing the app (just look at the horrible job Ubuntu did with PulseAudio back in the day).
as a Ruby app developer, it seems odd to me that I would find Ruby gems in the Fedora package manager. As a Ruby gem maintainer, I wouldn't want to burden distro maintainers every time I release a new version.

Do distro package managers even have features like version pinning? Seems like the repos are stuck with the major version that was out when the distro was released, and in a fast-moving world like web app development, you'd be hamstrung to old gem or npm versions.
this comment betrays a lot of ignorance, and I don't have the time to address it all, so I'll just clarify that basically all of your assumptions here are wrong
in short all of these problems are things that maintainers have thought about and/or are illustrative of problems with the ruby community more so than with distros
fully aware of my ignorance, just remarking that relying on my package manager is so far out of my experience as a web developer (and every fellow dev at every place I've ever worked since 2000), I find it surprising that it's even an option. Every 5 years or so when I look into it, it seems completely untenable, all the "happy path" tooling would have to be discarded and something new written. Doesn't help that 99% off Ruby/JS devs use MacOS...
for example, if I want my app to support a new provider in omniauth that's only available on newer versions of the gem, I'm just stuck for months or years until Centos 7 or Ubuntu 18.04 do their next LTS so I can grab the next major version? I'm genuinely curious here.
yep, just be patient, or use a distro which moves faster, or use custom package repos to fill in the gaps
what about all the other devs on the team that use MacOS? Homebrew is even worse of a package manager than bundler or yarn, when compared to dnf or apt. They're just expected to use a VM for local dev? I gotta say, using a VM for dev is a horrible experience...
devs on macOS get what's coming to them. Don't use shitty proprietary OSes.
Nix has official support for the walled garden. Not sure if it has importers tho.
@Rain 🚱 @Drew DeVault @Paul Sadauskas Nix works great on MacOS, it's my main package source for non-Mac-y things there.

I have zero need for macports or fink these days, and get only a handful of Cocoa things from Homebrew, or actually mostly from Homebrew Cask.
@Rain 🚱 @Drew DeVault @Paul Sadauskas The importer situation on Nix is pretty bad. Every new language reinvents the wheel and code reuse is low because the documentation is sparse.

When I can create the time to work on racket2nix again, I hope to generalize a few things and reduce the fragmentation, but I can't say which year that would be.
As a (python) developer and a distro maintainer.

In many cases, upgrading a package to a new version isn't a big deal: most of the time is taken by giving a quick review of the code to check that upstream hasn't gone insane :) and then it's a matter of running a few commands to upgrade the package and run tests to check that everything is still working. This is especially true for packages that release relatively often and don't change everything from one release to the next, of course, but many python modules are like that, and I supposed ruby gems are too?

As for version pinning, yes, with stable distributions you are basically pinned to the version available when the distro was released and get no new features, but you do get security fixes (when possible, and when the maintainer gets to know that there is a need for one). On the other hand, it also means that you can be sure that your software will not break until the next *predictable* distribution release.

It is true that as a developer I tend to work on things that are supposed to be maintained for years with minimal developer effort (because there isn't a developer working full-time on them), so I'm especially uncomfortable with the common web approach where you have to either rewrite your code every other month to keep it working with your dependencies or keep it stuck on the version that was out when you wrote the code even if it has known security vulnerabilities.
I think the python distro situation is very different from ruby as well, since so much distro tooling is written in python as well, while there's very little ruby. Maintainers understandably focus on python more than ruby, so the packages in ruby are going to be fewer and more out-of-date.
The distro tooling only influences the availability of those modules that are specific to distro work: on pypi there are lots of packages that are not available inside distributions, some of which are indeed quite useful. I don't have numbers, I just have the experience that finding a module that does what you need and is not in debian is not that unusual (and in a handful of cases it wasn't in debian until I needed it).

And the majority of python developers tend to just get everything from pypi because it's convenient, like developers in other languages do with their own repos.
openSUSE would like to disagree with you. Most of its tooling is in C++ and Ruby. They have a massive collection of gems. Fedora is a pretty close second despite having little Ruby software written by the community.
A quick check of my Fedora 30 install shows there's 1, 250 `rubygem-*` packages available, out of 10,000 on The current version of the single most popular gem, `rails` in the distro is 5.2.3, and 5.2.4 was released Nov 27. Rails 6 was released back in August. Our main production app has 318 gem dependencies, 137 are available in Fedora 30, and 37 are the version we need.
there is no way that there are 10,000 ruby gems which are worth more than the bytes they take up on disk

federico3 reshared this.

of course not, including some of mine. But there's more than 1200, since that only covers a third of what's needed for even a comparitively small app like ours
this is more indicative of the ruby community being terrible than of distros being wrong.

federico3 reshared this.

I believe that Fedora Ruby is planning to do Rails 6 for Fedora 32, though you could also ask and help make it happen...
One of the major features of Flatpak is using container technology to make sure no matter the distro, the package is running in the same environment as the developer's machine, so there is no need to "tune for the environment."
For the anti-feature point, if you have problems with the source, you should fork it, not pretend you are distributing the app while in reality you are distributing something else.
spoken like a dev who's annoyed that distros hold them accountable

federico3 reshared this.

spoken like a person who does not have a real answer
Seriously, I don't maintain any apps. Even if your reply was in good faith, it is incorrect.
Second, it was clear in my first reply: just fork it. It will "hold me accountable." Who is not accountable is the maintainer who changes the code while not changing the brand. The one who should be accountable for the resulting errors is the maintainer but often the user does not know because the downstream is using the upstream's brand.
Hate to bang the Guix/Nix pan all the time (no i don't) but what you want is reproducable packages/environments, not containers.
nix people are like the homeless guy on the street corner ranting about the clinton administration in 2019
Well, it's a much more usable rolling release distro than any other I've tried. Guix, that is. Nix's tools could be better.
And its developers aren't elitists who joke about mentally ill homeless people.
Call me when another distro gets an equivalent of `guix environment`.
oh, shove off, it was a joke. NixOS is for FP elitists, that's why I don't like it. It's way too complicated for way too little gain. I'll take 90% the stability for 10% the complexity any day of the week.
NixOS maybe, but Guix is not that complicated, nor are its developers or users FP elitists. But even Nix solved some very real problems that establishes package managers of the time failed to address.
only true if you accept the "problems" it solves as such
As someone who had pacman fuck up their bootloader due to a power outage, I welcomed anything that makes updates atomic. And being able to have conflicting versions of packages is also nice.
I agree on the first point, but not the second.
It also makes parametric packages easy to work with. And the functional purity means you can provide binary caches for package variants. Undeclared dependencies not affecting build output is quite useful.
I am familiar with these package managers, and I stand by considering these things antifeatures
Ah well. I think most people will like them.
on the contrary, the average person doesn't give two shits about these things. To most people, Linux == Ubuntu
I'm very much a Guix advocate. We're developing an upstream distribution, based on this (still young), but in my opinion, fantastic package manager. That being said, I have to agree with Drew. For the majority, Linux = Ubuntu. Most people don't care about the technical details, or reproducible environments - nobody would be using Windows, or MacOS if that was the case. People want beautiful, no-brainer software, that helps them accomplish stuff without reading a manual.
I kinda agree with this but if someone's doing web development and have already installed a language specific package manager, then using Guix or Nix shouldn't be that hard for them and if they wanna distribute things with Flatpak and absolutely refuse to write a proper package instead, then I'd prefer guix pack instead of a blob that who knows what generated.
@Rain 🚱 @Çağatay Yiğit Şahin @Drew DeVault @Franz Geffke The major difference between language-specific package managers and guix/nix is that the former generally:

- Work out of the box on Windows
- Are installable by non-root in an arbitrary location

I believe that at least one of buck/pants/bazel do this to some extent already today for some languages.

I hope we can one day have a guix-lite that while giving up on some features of full guix can fulfill the above two requirements and make cross-language deps normal rather than fringe, and stop new languages from inventing the 847th wheel.

And, of course, it should fit well with guix-full so that a real guix can benefit from the packaging work done for devs.
@Rain 🚱 @Çağatay Yiğit Şahin @Drew DeVault @Franz Geffke Cool! So both Nix and Guix support PRoot. It's a bit awkward, but it checks the box.

Still need to cover all those Python devs on Windows. But maybe all of them will be on Linux on Windows sooner or later.
RPM is working on rootless support, and there's a port of RPM with DNF to Windows in progress by the Midipix folks. I'm working on bringing it to macOS myself.
@Neal Gompa (ニール・ゴンパ) :fedora: dnf on Windows using minipix? Now I've heard everything. :-)

I hope Windows doesn't become a usable development platform before most of the devs have moved to Linux already.
Strictly speaking, the average person doesn't even know about Ubuntu. I would guess more people have heard about Android running on something called Linux (even if it isn't 100% true)
> I'll take 90% the stability for 10% the complexity any day of the week.

Yeah, me too if it's reducing complexity by 90% in return for reducing stability by 10%.

Out of curiosity, how much increased complexity (if any) would you accept for 10% more stability?

(Not that I have any idea how to measure either in practice…)
once a system reaches a practical threshold of stability, I will not take anything but slight increases in complexity to push the number further up. In the bootloader case, it's hardly difficult to boot up from your recovery disk and fix it the once in a blue moon it happens
I know it has been a long time but I didn't have a chance to look to Nix/Guix documentation until today. I wrote something with my limited understanding of Nix/Guix (and actually Flatpak too) that may be useful to compare:
remember how arch maintainers refused to add vscode to their repos because of their "electron apps must use system-wide /usr/bin/electron" policy. Microsoft (of all companies) ended up fixing this issue, and look at this package now:

nothing binary at all, has electron as its dependency. I can't imagine such stuff in flatpak ecosystem.
this is a good thing, to be clear
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.
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.
>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.
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.
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.
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.
>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?
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.
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.
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
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.
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.
Alpine solves this issue by allowing developers to do non-maintainer changes, which would be entirely non-controversial to fix a FTBFS issue.
not just developers, but also anyone who can write the patch.
as long as they can find someone to push it yeah. that's slightly more difficult.
true, but it's much better now than it used to be.
mailing lists are far better at help than IRC; while yes, such projects have mailing lists too, saying that IRC is great when asynchronous communications such as mailing lists are generaliy better (especially since they tend to be archived, unlike IRC, and easier to search in any case)
On Debian (the distro I know best) anybody can prepare a package and submit it for inclusion into the distribution: it will then be reviewed by debian developers who will (usually) suggest a number of fixes to bring the package up to the high standards of the distribution and then, if those have been applied, one of those developers will sponsor the package in the distribution.

People must be willing to actually maintain the package and not just submit it once and then disappear, and I admit that there are areas where it's easy to find a sponsor and other where there may be none (software written in languages few people know, and/or targeting very specific use-cases).

This is however a well-established and generally nicely working way for somebody that is completely unknown to start getting social credit and eventually become a debian developer themselves.

(terminology note: because of decades of history, debian developers aren't simply people who work on debian, but it's the term for people with access to debian infrastructure and systemwide package upload permissions (the latter unless they are non-uploading debian developers). debian maintainers aren't those who maintain packages, but people with limited upload permissions, usually as a temporary step on the way to become developers. Yes, it is confusing. That's what you get when a project grows and changes with time.)
Debian's process seems to resemble open source development model. Arch is somewhat different, your options are either a third-party repo or applying for a TU status. I suspect the third way is to ask a TU to "adopt" your package, though I'm not aware of any willing to take on someone else's burdens.

If the goal is to package Node programs and their deps like @sir suggests instead of defaulting on npm, I can imagine being in for a lot of frustration trying to convince Debian's maintainers to accept all this mess one by one.
Flatpak is complementary to distro packages
I’ve done quite a bit of packaging as a Debian developer, and inside Amazon (yes, the company uses OS packages), as a SuSE and HPE employee.

It is sad to see how uncooperative upstream developers can be, mostly due to myths around software lifecycle and the needs of end users.

Most software in the world is developed -> built -> distributed -> integrated -> deployed & mantained -> used by 4 to 6 different individuals/entities. Often different organizations.
Software distributed with shorter “chains” is the minority and the majority of software and hardware deployed in the world lives for many years.

Unfortunately there’s some disconnect between these lifecycles and the ones known by the most vocal crowd of developers on the Internet.
Compile-time and run-time dependencies should be unbundled from sources to allow maintainers and system engineers to update components independently.

Software should be modular where reasonable: allow disabling ancillary features and remove dependencies

Backward compatibility is important: hard dependencies on libraries released a week ago are painful; hard breaks on ABI/API/etc are more painful.
Gentler deprecation and upgrade paths are preferred.
One vital need operating system package repositories fill in my opinion is to keep the riff-raff, the unmantained toy projects written for educational purposes and forgotten about, out. And indexing them so apps can ask you to install the software they need, I wish more browsers did this!

I've read an anti-opensource article which in large part seemed more to be against these uncurated repos.

Why do people think computers have solved this problem? They're doing a poor job!
ahhwww good that someone is speaking that out lout!
counter argument: fedora strips out patent-encumbered codecs from audacious, leading to an MP3 player which until very recently didn't play MP3s on fedora without jumping through additional hoops.
counter-counter argument: fedora users can suck it

Drew DeVault reshared this.

mp3 still has patents?
@Martijn Braam @Drew DeVault @hacking for the moonrabbit

> the MP3 technology became patent-free in the United States on 16 April 2017 [ . . . ]‌ As a result, many free and open-source software projects, such as the Fedora operating system, have decided to start shipping MP3 support by default,_ownership_and_legislation
counter-counter-argument: fedora users can be sure that the distribution they get is safe to use in any environment, without risking being sued by malicious entities for patent infringment.

The problem here are software patents, not the distributions.

This website uses cookies to recognize revisiting and logged in users. You accept the usage of these cookies by continue browsing this website.