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.

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.

(I also dislike Flatpak for being a massive fucking bloat)

(and also because dbus)
(basically, fuck flatpak)

@sir hi welcome to Inedo's entire business model (everything sucks and is unsafe, let's try to make it suck marginally less and be slightly safer)

@sir Caution shitpost: Everything should be writtin in reverse Polish notation for the lols.

@nifker @sir I've written a bunch of code which uses DBus. I actually like what it's trying to do, but:

1. The C API is just sooo tedious. It feels like it was written by a machine, for machines.
2. It's super easy to miss important events. This is harder to explain briefly, but essentially, any time I've written code using DBus, I've found that my program gets out of sync with the DBus service because I missed a case, and the documentation isn't very good.

@nifker @sir 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)

@lanodan @sir And if we run it in kernel-space or is it not possible?

@nifker @sir Kernel isn't some magical beast you're just pushing the problems under the carpet.
@nifker @sir Learning about Inter-Process-Communication / Data sharing mechanisms that have been tested over the years and proven to be working well? (they all have been present on Unix-likes for decades)

I'm quite fond of sockets as a replacement but they aren't the only thing present in the wild.

@lanodan What can we do about libnotify then? Are there alternative specs which dont require Dbus?

@nifker For stuff like libnotify there is multiple ways but I think I would have it maintain a socket in XDG_RUNTIME_DIR, like wayland does, this has the limit that only one daemon can be easily maintained per user.

As for the protocol, I think the same structure as libnotify or web notifications could be used but not sure how they look like, otherwise some other standard, XML would probably be a good start because of it's good extensibility with fallback.

@sir 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 ;)

@sir 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).

@sir 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.

@Paul 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

@Paul 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

@sir 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...

@sir 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.

@Paul yep, just be patient, or use a distro which moves faster, or use custom package repos to fill in the gaps

@sir 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...

@Paul @sir
Why's using a VM for dev a horrible experience? I mean, it can eat some RAM from your machine but other than that, you just ssh into it and develop the same way you'd develop on prod.
Also, with VMs you can have shared folders, so you can edit code on the host and only run the buildsystem and application on the VM.

@Wolf480pl @Paul @sir
I'm forced to VNC into a VM for work actually. It's not as horrid as I thought it would be, and means I can work from anywhere and not have to worry about network permission shenanigans. The latency is there, but it's not in-your-face. About as bad as Android lmao. So hey: you can set up a VM on a server to dev on and take it with you.
@Wolf480pl @sir @Paul
*presses run* wait you weren't supposed to have any files to work on yet /what did you just do/

@Paul devs on macOS get what's coming to them. Don't use shitty proprietary OSes.


Counterpoint: Linux is borderline unusable to me unless I use recent KDE.

I cannot use Braille (my fingers aren't sensitive enough), and screen readers for Linux are functionally a joke. KDE has UI scaling that actually works.

And distros have for years turned off X's own full-screen zoom feature, instead preferring to make people use whatever their compositor provides, if it even has such.

(Gnome used to be pretty decent for accessibility, back in the GTK+ 2 days. Then Gnome 3 happened and suddenly the only themes available are the default and a shitty high-contrast one that isn't adaptable to user needs. And they don't provide a theme switcher or tooling to make your own themes.)


@Paul @sir Nix has official support for the walled garden. Not sure if it has importers tho.

@grainloom @sir @Paul 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.
@grainloom @sir @Paul 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.
@Paul @sir 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.

@valhalla @sir 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.

@Paul @sir 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.

@Paul @valhalla @sir 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.

@valhalla @sir 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.

@Paul @valhalla there is no way that there are 10,000 ruby gems which are worth more than the bytes they take up on disk

@sir @valhalla 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

@Paul @valhalla this is more indicative of the ruby community being terrible than of distros being wrong.

@Paul @valhalla @sir I believe that Fedora Ruby is planning to do Rails 6 for Fedora 32, though you could also ask and help make it happen...

@Paul @sir
Look into Guix. It makes importing language specific packages relatively painless, and dependency conflicts are basically nonexistant, because you only ever actually install what is absolutely needed, everything else is referenced through the store.
As a user, I absolutely loathe how npm/luarocks/etc try to install things globally. Yes, per-user installs still count as global.

@sir 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.

@cagatayy spoken like a dev who's annoyed that distros hold them accountable

@sir 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.

Sign in to participate in the conversation

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