I can of agree the focus to make Linux easy to use is not exactly on the right things. There is a bit too much of a “make a GUI of everything”. Which is not wrong per say, but should not be the goal. More a mean to an end.

I disagree that users won’t do stuff on their own. They will, but they will allocate very little time to it, on average, especially when compared to a tech savy person. And that’s just because their computer is a tool.And if they cannot make their tool work for what they want to do, they’ll find another way. Or deem it impossible.

I think distro must make mundane tasks such as system maintenance hands off. As an opt-in option not to upset power user. But things such as updates, full system update, disk space reclaiming, … should have a single “do the right thing without being asked to” toggle. Things a bit more complicated such as printing/scanning document should be more context aware. A bit like on smartphone where, if you have a document open, you can select print and, if no printer is configured, you have the option to add one there and then.

Immutable distro have made good progress on that front IMO. But we still need better integration between applications and the Desktop Environment for things like printing, sharing and so on. I’m hopeful though. Generally speaking, things are moving in that direction. Even if we can argue flapak and snap are a step backward with regards to the integration of the DE, this is also an opportunity to formalize some form of protocol with the DE.

It’s not directly related to the torrent or its content no. It’s more related to the potential bugs in Transmission that might be exploited to propagate viruses.

Since Transmission has to exchange data with un-trusted parties, before knowing whether the data is relevant to the torrent you are downloading, anyone could exploit bugs that exist in the parsing of these messages.

So running Transmission as a dedicated user limits what an attacker may have access to once they take control of Transmission through the exploit of known or unknown bugs.

Obviously, this user need to have many restriction in place as to prevent the attacker from installing malware permanently on the machine. And when you copy over data that has been downloaded by Transmission, you’d have to make sure it has not been tampered with by the attacker in an attempt to get access to the data available to your real account.

If you just use transmission occasionally, not on a server, I would not bother with it. Either use the flatpak version for some sandboxing and similar security guarantees as having a dedicated user running Transmission, or use an up to date version (the one from your distro should be fine) and don’t leave it running when you do not need to.

the common practice is to relax the dependencies

I found this a bit disturbing

I find that funny that, since this is rust, this is now an issue.

I have not dwelved in packaging in a long while, but I remember that this was already the case for C programs. You need to link against libfoo? It better work with the one the distribution ship with. What do you mean you have not tested all distributions? You better have some tests to catch those elusive ABI/API breakage. And then, you have to rely on user reported errors to figure out that there is an issue.

On one hand, the package maintainer tend to take full ownership and will investigate issues that look like integration issue themselves. On the other hand, your program is in a buggy or non-working state until that’s sorted.

And the usual solutions are frown upon. Vendoring the dependencies or static linking? Are you crazy? You’re not the one paying for bandwidth and storage. Which is a valid concern, but that just mean we reached a stalemate.

Which is now being broken by

• slower moving C/C++ projects (though the newer C++ standards did some waves a few years back) which means that even Debian is likely to have a “recent” enough version of your dependencies.
• flatpack and the likes, which are vendoring everything and the kitchen sink
• newer languages that static link by default (and some distributions being OK with it)

In other words, we never figured out a proper solution for C projects that will link with a different minor than the one the developer tested.

Well, /rant I guess. The point I’m raising does not seem to be the only one, and maybe far from the main one, for which bcachefs-tools is now orphaned. But I’ve seen very dubious arguments to try and push back against rust adoption. I feel like people have forgotten where we came from. And while there is no reason to go back per say, any new language that integrate this deep into the system will face similar challenges.