Clients on Linux

What the distributions package

The distributions package these clients under names that tell you which half you are installing. The desktop package draws a window; the package whose name ends in nox, daemon or a bare d runs with no display and is driven over a local web interface or a command line. Debian and Ubuntu use apt, Arch uses pacman, Fedora uses dnf, and Linux Mint and Kali follow their Debian and Ubuntu parents, so these names carry across a far wider set of systems than three rows suggest.

Installing any of them is one command, such as apt install qbittorrent on Ubuntu or Debian, pacman -S qbittorrent on Arch, or dnf install qbittorrent on Fedora, and the headless build is the same command with the nox package name. Nothing is downloaded by hand, and updates arrive with the system. The transfer that follows behaves as How a transfer works describes, and the client is the one the qBittorrent page covers, only without a window if you asked for nox.

What Linux does to a transfer

Linux acts on a transfer through ownership first, which is the largest difference from a Mac or a Windows machine. A daemon package installs a system user of its own, and Transmission's Debian package is the clearest example: the daemon runs as its own account, so every completed file is owned by that account and the person at the desktop cannot move or delete it until group membership or the daemon's umask says otherwise. Nothing is broken; the file simply is not yours.

Sandboxing acts second. A client installed as a Flatpak or a Snap sees only the folders it has been granted, so a save path on a second disk is refused until the permission is added from outside the program, through a portal prompt or a permissions editor. Third, the file system: ext4 and btrfs are case sensitive, so a torrent holding two names that differ only in capitalization writes out cleanly here and fails on macOS, while a transfer saved onto a mounted NTFS or exFAT volume takes that mount's fixed ownership and loses its permission bits. Fourth, the service manager: systemd starts a daemon at boot when its unit is enabled, but a unit running under your own user account stops at logout unless lingering is switched on for that account.

Where a Linux build comes from

A Linux build comes from the distribution's repository, the official channel on this platform in a way that has no equivalent on Windows or macOS: the package is signed with the distribution's key and updated by the same command that updates the kernel. The project publishes source, and some also publish a Flatpak or an AppImage, but the repository is the normal answer.

Arch is the case worth stating plainly. The official Arch repositories carry qBittorrent, Transmission and Deluge, and installing from them is no different from any other distribution. The Arch User Repository is not those repositories: it carries build recipes submitted by users, each a script that runs on your machine to fetch and compile something, and it is not reviewed the way the repositories are. Ubuntu's personal package archives and third party Flatpak remotes sit in the same category, where the publisher is somebody other than the distribution.

What goes wrong first on Linux

• The daemon's own user owns the finished files, and the desktop session cannot rename, move or delete them.
• A sandboxed build cannot write to the chosen save path, and the transfer errors the first time a piece is ready to be written.
• The headless client's web interface listens on the local machine only, so a browser on another computer on the same network reaches nothing until the client is told to listen more widely.
• The daemon's configuration file is edited while the daemon is running, and the daemon rewrites the file from memory when it stops, discarding the edit; Transmission's daemon is the classic example, and the fix is to stop it first.
• A desktop machine suspends on idle, and every transfer shows stalled until it wakes and finds peers again.

What Linux cannot do

Linux cannot promise that the packaged client matches the project's current release. A stable distribution freezes versions and backports fixes, so a setting described in the project's own notes may not exist in the build apt installed, which is a deliberate property of the distribution rather than a fault. A confined package cannot be argued into writing outside its grant from inside the client's settings, because the grant is held by the sandbox and changed elsewhere. A daemon cannot ask you anything, so a step that would raise a dialog must be configured in advance. And Linux cannot make a router forward a port any more than the other platforms can, so a client here reports itself firewalled under exactly the same conditions, with the safety framing that Is it safe? sets out unchanged.

The first torrent most Linux users run

The first torrent most Linux users run is a distribution image, because the distributions publish their installer files by BitTorrent alongside a direct download. Debian, Ubuntu, Arch, Fedora and Linux Mint all do it, and the reason is the reason the protocol exists: a release day sends the same large ISO to an enormous number of people at once, and every downloader who stays connected becomes a source for the next, which is what The swarm describes.

Two details make this the cleanest example of the technology. The distribution publishes a checksum file next to the image, so verifying the finished ISO against it proves the file is the one the project built, which is the integrity idea the protocol applies piece by piece. And the swarm around a fresh release is unusually healthy, so a reader who has only seen slow transfers gets to watch what a well seeded one looks like. Staying connected afterward costs upload bandwidth and nothing else.