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.
@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.
@sir Whats the issue with DBus?
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.
@lanodan What can we do about libnotify then? Are there alternative specs which dont require Dbus?
@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...
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.
@Paul devs on macOS get what's coming to them. Don't use shitty proprietary OSes.
@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.
@valhalla @sir A quick check of my Fedora 30 install shows there's 1, 250 `rubygem-*` packages available, out of 10,000 on rubygems.org. 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.
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.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!