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.

Show thread

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

Show thread

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

Show thread

@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 When I say the documentation isn't very good, I mean that it's for the most part your usual doxygen-style auto-generated reference. Auto-generated references are great and super useful, but they're not what you need when you're trying to understand how the system works and how you can create your own thing on top of the system from scratch.

@mort So you mean they are missing proper code examples and more explanation about the background and stuff?

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