A desktop client for ZimaOS on Linux: files, photos, apps and device management.
This is the first release of the rewrite that is not an alpha. The old 0.9.x line still
exists and nothing was deleted.
Download: Release v2.0.0 — the rewrite, no longer an alpha · chicohaager/zima-linux-client · GitHub
cd ~/Downloads
B=https://github.com/chicohaager/zima-linux-client/releases/download/v2.0.0
wget $B/install.sh $B/SHA256SUMS-2.0.0.txt # always these two
wget $B/zima-linux-client_2.0.0_amd64.deb # Debian, Ubuntu, Zorin, Mint, Pop!_OS, PikaOS
wget $B/zima-linux-client-2.0.0.x86_64.rpm # Fedora, openSUSE, RHEL derivatives
wget $B/zima-linux-client-2.0.0.pacman # Arch, Manjaro
chmod +x install.sh && sudo ./install.sh
install.sh checks the checksum, picks the package that matches your distribution, installs it
with the right tool, and then measures whether the app can start: registration, install
layout, Chromium’s sandbox, CAP_NET_ADMIN for the bundled ZeroTier, AppArmor profile. It does
not launch anything — a check that opens a window is not a check. --check only looks and needs
no sudo, --repair fixes what is fixable, --uninstall removes.
x86_64 only. There is no arm64 build (see the bottom of this post) and no Flatpak.
If you take the AppImage: GitHub stores it as
ZimaOS.Client-2.0.0.AppImage— with a dot
where the filename has a space — whileSHA256SUMS-2.0.0.txtnames it with the space. So
sha256sum -csays “No such file or directory” for that one line. That looks like a tampered
download and is not; compare it by hand withsha256sum ZimaOS.Client-2.0.0.AppImageinstead.
The four packages verify normally. This has been true since the first alpha and will be fixed
at the source in the next build.
Both things reported here are fixed
Thanks to @editon96 for the report on PikaOS — both points turned out to be real bugs that
hit everyone, not just his setup.
1. Apps that opened as a blank white window
“when I try to use an app here it often are only White and dont open the app”
That was exactly right, and the cause was on our side: the window that opens an app’s web UI had
no failure path at all. It threw the result of the page load away and listened for nothing.
When an app could not be reached, Chromium rendered nothing and the window stayed white —
forever, with no message.
Reproduced against a real device, in the shipped Electron:
15 ms navigation starts
21 111 ms did-fail-load ERR_CONNECTION_REFUSED
90 047 ms window content is still "" <- a minute and a half later
Now: the window shows a “connecting” page immediately, and when the load fails it says which
app, which address and what the reason was, in your language. Same test after the fix, at 1.5
seconds instead of never:
<app name> did not answer
This app’s web interface could not be loaded.
http://<device>:<port>/
Reason: ERR_CONNECTION_REFUSED (-102)
The app may be stopped, or its port may not be reachable from this computer.
That does not make an unreachable app reachable — but it tells you what to look at instead of
leaving you with a white rectangle. If you see one of these, the message is worth reporting: it
now contains everything needed to find the cause.
2. “It says I need the Photos module but I don’t need it”
Also right, and it was said twice: once as a card in the Photos tab and once as a yellow
warning on the device screen — the second one sitting underneath a list that already had
“Photos module: not available on this device” as a plain row.
Both are gone. If your device has no ZimaOS Photos module, the Photos tab simply browses folders
(that works without the module, and so does photo backup), and the mode is stated once as a
small “Folder” badge. No nagging about a dependency you never wanted — plenty of people use
Immich or PhotoPrism instead, which is a perfectly good answer.
While fixing that, a second bug surfaced in the same tab: an empty folder or library showed
“Loading…” forever instead of saying it was empty. One of the two internal queries is always
switched off depending on the mode, and a switched-off query reports “pending” indefinitely — so
the honest empty state could never be reached. Fixed, in both modes.
What we did not do: move the Photos tab into the Files tab. The photo backup lives in that
tab and works without the Photos module, so removing it would quietly take a working feature
away from exactly the people who asked for it.
What was measured before this release went out
The deb, rpm and pacman packages are installed and started on nine distributions, in
containers, under Xvfb, as an ordinary user and with Chromium’s sandbox switched on — the
real artefact, installed into the real path:
| Distribution | Package | Result |
|---|---|---|
| Ubuntu 22.04 · 24.04 · 26.04 LTS | deb | window up, 51 CSS rules applied, 399 characters of visible text |
| Debian 12 · 13 (trixie) | deb | same |
| Fedora 41 · 44 | rpm | same |
| Arch Linux | pacman | same |
| openSUSE Tumbleweed | rpm | same |
9 of 9, no failures, no raw translation keys on screen.
Each row keeps the app’s own start-up report as the evidence: window up, stylesheet actually
applied, no raw translation key on screen. “The process did not exit non-zero” would not be
evidence of a window — we learned that the hard way when a container without any font produced a
perfectly green report over a blank screen.
Ubuntu 26.04, Debian 13 and Fedora 44 are new rows in this release. Until now the matrix stopped
at Ubuntu 24.04, Debian 12 and Fedora 41 — all superseded — so it was proving distributions
nobody installs fresh. Since most desktops out there are derivatives (Mint, Pop!_OS, Zorin,
PikaOS), keeping the base rows current is what actually covers them.
All five packages come from one build run of one commit, and a release gate checks that
before publishing — including “no artefact is older than the last code change” and “the build
claim names its commit”. This is the first release where that gate passes all eight checks.
What this release does not cover
Being straight about the gaps is more useful than a green checklist:
- No arm64. An arm64
.debbuilds, installs on aarch64 and the bundled ZeroTier runs there —
but nobody has ever seen the application start on arm64. It cannot be shown under emulation
(Chromium’s zygote dies oncloneinsideqemu-user), so it needs real hardware. This is a
settled decision, not a pending task: arm64 stays unpublished. - Debian SID / PikaOS is not fully proven. The package installs there cleanly and pulls the
correct libraries — that was measured — but no start was measured on SID itself. Debian 13 is
proven; SID sits beyond it. - Real hardware coverage is thin. The matrix runs in containers. On actual desktops this has
been used on Ubuntu 24.04, Zorin OS 18, and — from a third-party report — Fedora KDE. openSUSE
and Arch on real hardware, Wayland on more than one graphics driver, SELinux, and any keyring
other than GNOME’s are all unproven. - One open bug we have not solved. A tester on Fedora KDE reported an
HTTP 400in the
Photos tab. Its cause is still unmeasured. If you hit it, the client now names the rejected
directory in the message — that alone would make it decidable, so please post the message.
Every claim in the project’s documentation names the command or the measurement behind it. Where
something is unmeasured, it says so instead of sounding finished.
Reports are genuinely useful
Both fixes in this release came from two forum posts, not from our own testing. If something
looks wrong:
- the exact message on screen (the client is now much better at naming what failed and where),
- your distribution and version, X11 or Wayland,
- which package you installed.
Source, documentation and what has actually been measured: