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


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

· Tootle for Mastodon · 1 · 0 · 1

@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.
Sign in to participate in the conversation

A Mastodon instance for Rubyists & friends