v2.0.0-alpha.4 — it does not connect on its own
Pre-releaseFourth alpha of the rewrite. The 0.9.x line lives on main; nothing there was deleted.
All five packages below were built in one run on 2026-08-10 from the build inputs of commit
4fd04b3. npm run verify:release passes all eight checks against them — including "artefacts
come from one run" and "build claims name their commit", so the version number on these files
stands for exactly one payload.
What changed since alpha.3
The client no longer connects on its own. A saved device is reached when you press
Connect, and not before. At start-up nothing reaches out: no session restore, no device list
query, no tunnel.
This is a correction of the previous two builds. The complaint was that stored connections
should not be re-established by themselves — and the first attempt at it only made the automatic
restore smarter (it measured the stored paths instead of guessing one) while leaving the
automatic part in place. Measuring the wrong thing well is still the wrong thing.
Why it matters beyond taste: an unasked-for restore reaches out over whichever tunnel happened
to be stored. Opening a ZeroTier road costs a network join that can take over the machine's DNS,
and using a stored Tailscale address assumes you wanted that link up right now. Which network you
are on is your decision, not the application's.
Pressing Connect on a saved device tries the stored token first — that is what "connect"
means for a device you have used before — and only shows the sign-in form when there is no stored
secret, or it no longer works.
A screen that contradicted itself. After a session went away, the overview kept rendering
storage figures and the Restart / Power-off buttons from the last successful fetch, while its own
sub-queries each put up "Please sign in." Reported from a real desktop with a screenshot showing
both at once. The overview now follows the live session state; offering to power off a machine
there is no session for is worse than useless.
What changed since alpha.1
A stored path is measured, not trusted. Every stored path that needs no tunnel is probed at
once and the fastest answer wins — measured on 2026-08-10 on a machine in the same LAN as its
device: over the stored Tailscale path 3 of 16 requests succeeded, over the LAN address 16 of 16
in 2–6 ms, while tailscale status reported active; direct throughout.
Your device is recognised at an address nobody stored — offered, never adopted, with the
address named ("Is this your device?").
Error messages arrive with their values. alpha.2 rendered … hat geantwortet ({{paths}})
instead of the addresses it tried.
Install
install.sh is the recommended way: it compares the checksum, installs with the right tool for
your distribution, and then measures whether the application can start at all — package
registered, binary in place, Chromium sandbox usable, CAP_NET_ADMIN granted to the bundled
ZeroTier, AppArmor profile in place. It does not launch anything: a check that opens a window is
not a check.
Download the installer, the checksums, and the one package for your distribution:
cd ~/Downloads
B=https://github.com/chicohaager/zima-linux-client/releases/download/v2.0.0-alpha.4
# always these two
wget $B/install.sh $B/SHA256SUMS-2.0.0-alpha.4.txt
# then exactly one of these
wget $B/zima-linux-client_2.0.0-alpha.4_amd64.deb # Debian, Ubuntu, Zorin, Mint, Pop!_OS
wget $B/zima-linux-client-2.0.0-alpha.4.x86_64.rpm # Fedora, openSUSE, RHEL derivatives
wget $B/zima-linux-client-2.0.0-alpha.4.pacman # Arch, Manjaro
chmod +x install.sh
sudo ./install.shOther invocations: ./install.sh --check inspects an existing installation and needs no sudo ·
sudo ./install.sh --repair fixes what is fixable · sudo ./install.sh --uninstall.
It exits 0 when everything it measured is in order and 1 when the application will not run as
installed — in that case please send the whole output.
Upgrading from an earlier alpha: install over it, the package manager replaces it. Your stored
devices and sessions are kept — but the client will now wait for you to press Connect.
Or by hand
sha256sum -c SHA256SUMS-2.0.0-alpha.4.txt # must say OK for the file you downloaded
# Debian / Ubuntu / Zorin — give apt an absolute path, or prefix a relative one with ./
sudo apt install ~/Downloads/zima-linux-client_2.0.0-alpha.4_amd64.deb
# Fedora
sudo dnf install ./zima-linux-client-2.0.0-alpha.4.x86_64.rpm
# openSUSE — the package is unsigned, hence the two flags
sudo zypper --no-gpg-checks install --allow-unsigned-rpm ./zima-linux-client-2.0.0-alpha.4.x86_64.rpm
# Arch
sudo pacman -U ./zima-linux-client-2.0.0-alpha.4.pacmanAppImage — no installation, nothing is registered, and none of the permissions above are set:
chmod +x ZimaOS.Client-2.0.0-alpha.4.AppImage
./ZimaOS.Client-2.0.0-alpha.4.AppImageThe Remote-ID route needs CAP_NET_ADMIN on the bundled ZeroTier, which only the post-install
script of deb/rpm/pacman can grant. From the AppImage that route will not work.
Which file
| File | For |
|---|---|
zima-linux-client_2.0.0-alpha.4_amd64.deb |
Debian, Ubuntu, Zorin, Linux Mint, Pop!_OS … |
zima-linux-client-2.0.0-alpha.4.x86_64.rpm |
Fedora, openSUSE, RHEL derivatives |
zima-linux-client-2.0.0-alpha.4.pacman |
Arch, Manjaro |
ZimaOS.Client-2.0.0-alpha.4.AppImage |
anything else — no installation |
zima-linux-client-2.0.0-alpha.4.tar.gz |
unpack and run |
x86_64 only. There is nothing for ARM: an arm64 package has not been built and would be
untested. Nothing is signed.
What has been measured, and what has not
- 275 unit tests, four end-to-end flows in a real window against a recorded device, and gates
for build output, translations (289 keys × 28 languages at 100 %) and privacy all pass. - "Does not connect on its own" is guarded by a negative test: mount the hook, let every
timer run, and assert the IPC channels were never touched. Positive control: putting the
automatic restore back turns exactly that test red. - Checked on a real desktop with THIS build (Zorin OS 18): the client comes up with the
device list and no session — nothing reached out on its own — and after connecting over the
Remote-ID route the session stood, with files, photos and apps working and all nine features
reported available against 38 gateway routes. - The Connect button on a saved device was exercised too, on the same desktop: pressing it
restored the session from the stored token — no password asked — reopened the ZeroTier road for
the saved Remote-ID path, and landed on the overview with the session valid for another 179
minutes. Both remote routes (ZeroTier, Tailscale) were used on a real desktop with the alpha.3
code. - The seven-distribution matrix was NOT repeated for these files. It last ran on 2026-08-09
against an earlier payload — Ubuntu 22.04 and 24.04, Debian 12, Fedora 41, Arch, openSUSE
Tumbleweed under Xvfb, plus Zorin OS 18.1 on a real desktop. The packaging did not change
since; the application code did. - None of that is the same as "it runs on your machine".
install.shdeliberately does not
open a window, so a green check says the application can start, not that it did. - The post-install script was read out of the built
.deb, not out of the source, and
contains both the stock electron-builder template (update-alternatives,chrome-sandbox
mode, AppArmor profile) and the ZeroTier capability grant.
Known rough edges
- Wayland with the
vmwgfxdriver: Electron 43 dies with a SIGSEGV, so the client relaunches
itself under X11. Whether that fallback fires correctly on other drivers — or needlessly — is
unmeasured.echo $XDG_SESSION_TYPEtells you which session you are on. - Ubuntu 24.04 and derivatives: the package depends on
libasound2t64 | libasound2in that
order on purpose. The bare namelibasound2resolves to an OSS compatibility shim on 24.04,
which installs cleanly and then fails at startup on a missing symbol. N: … not sandboxed … as user '_apt'duringapt installis a note, not an error: home
directories are750, so apt's unprivileged helper cannot reach the file and apt reads it as
root instead. Installing from/tmpavoids the note; nothing else changes.- ZeroTier is bundled; Tailscale is only detected when it is already on the machine and is
never operated by the client. - The "Is this your device?" card has been seen rendering once, on one desktop. Whether the
button then adds the path correctly on a machine that is not the author's is unverified. - How a session can disappear mid-use is not yet understood. The stored session is only
cleared by signing out, removing the device, or restarting the app — a dying tunnel does not
clear it. A report with~/.config/zima-linux-client/logs/main.logwould settle it.
Please report anything that goes wrong — including the output of install.sh, which records the
environment. A start failure with no window and no message is the most valuable report of all.