DHS 0.2.0 — applications travel too

The release that gives the product its name: applications travel too.

Added

• The application database, appdb/: 759 entries, one JSON file per application, embedded in
  the binary. For each: the identifiers under which winget, choco, scoop, pacman, the AUR, apt,
  dnf, zypper, apk, Flatpak and Snap know it, the display name in Apps & features, the
  configuration locations keyed the same way on every platform, how portable that configuration
  is, and the equivalents where the application does not exist. CC-BY-4.0, contributable by pull
  request; appdb/README.md is the guide, appdb/tools/validate.py the check.
• Detection of installed applications. Linux: the pacman, dpkg, apk, Flatpak and Snap
  databases are read directly, rpm is queried. Windows: the Uninstall registry keys, winget export, scoop and choco. Configuration is found where it lives, including inside Flatpak and
  Snap sandboxes.
• Configuration carried by application, under package roots apps/<id>/<key>, so a Firefox
  profile from %APPDATA% lands in ~/.mozilla/firefox. The manifest dhs/apps.json is an
  encrypted entry in the first volume.
• dhs plan: what would be installed here and through which manager, what is already here,
  what has no way to be installed, what has no version for this platform and which equivalent
  replaces it, what the database does not know, and where every configuration goes. Touches
  nothing.
• dhs install: runs exactly the commands plan showed, after one confirmation; a batch that
  fails is retried one package at a time so the report names what did not install.
• dhs restore places application configuration through the same plan and keeps the rest under
  ~/DHS-restored/apps/ with the reason; --only apps selects it.
• --no-apps on scan and backup; an Applications page in both graphical interfaces.
• Browser credential stores (logins.json, key4.db, Login Data) are treated as secrets.

Changed

• Unknown applications are reported only for packages that ship a desktop entry, and Windows
  redistributables and runtimes are left out; a Linux system's thousand libraries no longer bury
  the report.
• Binary size: 5.4 MiB on Linux, 5.6 MiB on Windows, database included.

Notes

• This is the first release not marked pre-release. The file core has been verified bit for bit
  on five Linux distributions and on Windows 11; the application side is covered by unit tests and
  the end-to-end script on Linux. Windows detection has been exercised only through its unit
  tests so far.
• Identifiers in the database were checked against Repology, winget-pkgs, Flathub and the Snap
  store where doubtful. A wrong name is found by someone who has the application installed;
  please report them.

DHS 0.1.3 — a native interface on Windows and Linux

A native interface on both platforms, and a defect that made wrong commands look right.

Still a pre-release, and it will stay one until the application database exists: matching your
programs across operating systems is the reason DHS exists, and that part is not written yet. What
is here is the file half, and that half is now tested on real Windows as well as Linux.

New: the Windows interface

dhs-gui.exe ships inside the Windows archives. Win32, drawn by hand, one portable executable
under 3 MiB that needs nothing installed, asks for no administrator rights and leaves nothing
running. Put it next to dhs.exe, on a stick if you like, and double-click.

It drives the same binary through --json, exactly as the GTK4 front end does on Linux, and holds
no rule of its own: every number and every warning on screen comes from the core. The palette and
the spacing are libadwaita's, so the two interfaces read as one program.

Why hand-drawn: a portable single file that looks current ruled out the alternatives. WinUI needs
the Windows App SDK, anything web-based drags in a runtime, and themed Win32 controls look like a
2009 utility however modern the theme. The details, including why GDI+ cannot be called from Go at
all, are in gui/windows/README.md.

Fixed: a mistyped flag exited successfully

Every command swallowed flag parse errors and returned success, so dhs scan --only foo printed
"flag provided but not defined" and then exited 0. Any script, any CI job and the interface itself
would have carried on as though the command had run. Parse errors now exit 2; --help still exits
0, because asking for help is not a failure.

It was found the embarrassing way: a wrong flag in the Windows test harness looked like three
consecutive clean runs.

Also

• install.ps1 is ASCII throughout: on a real console the ellipsis rendered as a bare full stop,
  which made the progress lines look truncated.
• The test suite now compiles the Windows interface. It sits behind a build tag, so go vet ./...
  on Linux never looked at it and it could have broken unnoticed.

Verified for this release

Thirteen checks, all green: formatting, go vet for Linux and for Windows, five builds including
both interfaces, the unit tests, the race detector and the end-to-end cycle.

On Windows 11 IoT Enterprise LTSC 24H2, driven over SSH: install, scan, backup with
verification, verify, list, a refused wrong passphrase, a dry run, a restore into an emptied
profile and a second restore over existing files. Every file came back identical bit for bit,
including a name with Romanian diacritics, a compressible duplicate pair and an incompressible one.
The second restore placed all of them beside the originals with the (DHS) suffix rather than
overwriting.

On Linux, the .deb installs on Debian and Ubuntu, the .rpm on Fedora, Rocky and openSUSE, the
tarball runs on Alpine against musl, the AppImage runs without FUSE, and the AUR recipe builds
dhs-cli and dhs-gui on Arch with the test suite running inside check().

Install

Windows, in PowerShell:

irm https://dhs-suite.vercel.app/install.ps1 | iex

That installs the command-line tool. For the interface, take the Windows archive below: it holds
both executables. Verified with Defender's real-time protection on.

Linux: the .deb, the .rpm, the AppImage or the tarball. On Arch, dhs-cli and dhs-gui
build from the recipe in packaging/aur/.

sha256sum -c SHA256SUMS --ignore-missing

What is still missing

The application database, application detection and dhs plan. Until those exist, DHS moves your
files and settings but cannot tell you which of your programs has an equivalent on the system you
are moving to. Do not migrate anything you cannot afford to lose.

DHS 0.1.2 — deduplicated files restore correctly

This is a pre-release, and it fixes a data-integrity defect in the two before it.

Fixed

When two identical compressible files were backed up, the second one was written into the
package with no reference to the stored bytes. The package then verified as perfectly intact, and
restoring that single file failed with corrupt data and wrote nothing. Refusing to write was the
right behaviour, but the copy was gone from the package.

If you hold a package built with 0.1.0 or 0.1.1 and it contains duplicate files, rebuild it with
this version. dhs list <package> --all marks duplicates with (dup). A package with none is
unaffected.

The cause: a duplicate copied the original's block references at the moment it was added, but the
original's bytes were often still sitting in an open solid block, so the references that arrived
later reached the original alone. Files that are stored rather than compressed, images and other
incompressible data, were never affected, which is exactly why the test suite missed it: its only
duplicate fixture was a JPEG. The suite now covers a compressible duplicate and asserts the index
entry carries block references at all.

Found by running the Windows binary under Wine with two identical binary-class files. It is not a
Windows defect; a package written on Linux lost the same file.

Everything else

Unchanged from 0.1.1. The file core, scan backup verify list restore, is tested; the
application manifest and app detection are still not written. The Windows binary now has some
exposure through Wine, including a full backup and restore cycle, but it has still not run on real
Windows.

Install

Windows, in PowerShell:

irm https://dhs-suite.vercel.app/install.ps1 | iex

It picks the build for your processor, checks it against the sums published here, unpacks it under
your own profile and puts it on your PATH. No administrator rights and nothing left running.

Linux: take the .deb, the .rpm, the AppImage or the tarball below. On Arch, dhs-cli and
dhs-gui build from the recipe in packaging/aur/.

sha256sum -c SHA256SUMS --ignore-missing

Tested this release: the .deb installs on Debian and Ubuntu, the .rpm on Fedora, Rocky and
openSUSE, the tarball runs on Alpine against musl, the AppImage runs without FUSE, and both AUR
packages build and install on Arch.

DHS 0.1.1 — desktop integration, split AUR packages

⚠️ Superseded — do not use this release

This version writes a deduplicated copy of a compressible file with no reference to its
bytes. The package verifies as intact, and restoring that one file then fails and writes
nothing. Fixed in 0.1.2.

If you built a package with this version, check it with dhs list <package> --all: any entry
marked (dup) is affected. Rebuild the package with 0.1.2.

This is a pre-release. Do not use it for a real migration yet.

Since 0.1.1 changes packaging only, the tool behaves exactly as 0.1.0 did.

New in 0.1.1

• A desktop entry and icon for the GTK4 front end, so it can be installed as a real application
  rather than run from a checkout.
• An AUR recipe that publishes two packages from one push: dhs-cli (the tool) and
  dhs-gui (the front end, which depends on the CLI). See packaging/aur/.

The file core works and is tested. What makes DHS a migration tool rather than a backup tool, the
application database and app detection, is not written yet. The Windows binaries are
cross-compiled and have not been run on Windows.

What works

scan · backup · verify · list · restore

• Scans your home directory and tells you before writing anything how much the package will
  take at each compression level, and whether it fits on the drive you plugged in.
• Writes a package split into 3.5 GiB volumes, so it fits any filesystem, FAT32 included.
• Encrypts the whole package with a passphrase. Secrets, meaning SSH and GPG keys, browser
  passwords and cloud tokens, are excluded unless you ask for them, and get a second passphrase
  when you do.
• Restores without ever overwriting: an existing file stays, and the restored copy lands beside it
  with a (DHS) suffix. --dry-run shows the plan and writes nothing.
• Verifies SHA-256 on the way in and again before committing each file on the way out. A file that
  does not verify is not written.
• Survives interruption: the package says it is incomplete rather than looking valid.

Every command takes --json. DHS_LANG=ro switches the messages to Romanian.

Tested

Unit tests, the race detector, and a full backup-and-restore cycle compared byte for byte. The
restore was exercised on Arch, Fedora, Debian, openSUSE Tumbleweed and Alpine, with every file
identical bit for bit on all five. The .deb was installed on Debian and the .rpm on Fedora,
each in a clean container, and the binary ran from both.

Which file to take

You are on	Take
Debian, Ubuntu, Mint	dhs_0.1.1_amd64.deb (or arm64)
Fedora, RHEL, openSUSE	dhs-0.1.1-1.x86_64.rpm (or aarch64)
Any Linux, nothing installed	DHS-0.1.1-x86_64.AppImage, or the linux tarball
Arch	dhs-cli and dhs-gui from the AUR recipe in packaging/aur/
Windows	dhs_0.1.1_windows_amd64.zip (untested, see above)
Building it yourself	dhs-0.1.1-source.tar.gz

The AppImage runs the command-line tool without installing anything:

chmod +x DHS-0.1.1-x86_64.AppImage
./DHS-0.1.1-x86_64.AppImage scan --dest /run/media/you/SSD

Verifying what you downloaded

sha256sum -c SHA256SUMS --ignore-missing

Not in this release

The application manifest, application detection, dhs plan, and any translation of complex
configurations. Windows support is compiled but unverified. There is no graphical interface in the
packages; a GTK4 prototype lives in gui/linux/ and drives this same binary over --json.

Roughly 4 MiB per binary, no runtime to install, no background process, no network call, no
telemetry, no AI.

DHS 0.1.0 — first pre-release

⚠️ Superseded — do not use this release

This version writes a deduplicated copy of a compressible file with no reference to its
bytes. The package verifies as intact, and restoring that one file then fails and writes
nothing. Fixed in 0.1.2.

If you built a package with this version, check it with dhs list <package> --all: any entry
marked (dup) is affected. Rebuild the package with 0.1.2.

This is a pre-release. Do not use it for a real migration yet.

The file core works and is tested. What makes DHS a migration tool rather than a backup tool, the
application database and app detection, is not written yet. The Windows binaries are
cross-compiled and have not been run on Windows.

What works

scan · backup · verify · list · restore

• Scans your home directory and tells you before writing anything how much the package will
  take at each compression level, and whether it fits on the drive you plugged in.
• Writes a package split into 3.5 GiB volumes, so it fits any filesystem, FAT32 included.
• Encrypts the whole package with a passphrase. Secrets, meaning SSH and GPG keys, browser
  passwords and cloud tokens, are excluded unless you ask for them, and get a second passphrase
  when you do.
• Restores without ever overwriting: an existing file stays, and the restored copy lands beside it
  with a (DHS) suffix. --dry-run shows the plan and writes nothing.
• Verifies SHA-256 on the way in and again before committing each file on the way out. A file that
  does not verify is not written.
• Survives interruption: the package says it is incomplete rather than looking valid.

Every command takes --json. DHS_LANG=ro switches the messages to Romanian.

Tested

Unit tests, the race detector, and a full backup-and-restore cycle compared byte for byte. The
restore was exercised on Arch, Fedora, Debian, openSUSE Tumbleweed and Alpine, with every file
identical bit for bit on all five. The .deb was installed on Debian and the .rpm on Fedora,
each in a clean container, and the binary ran from both.

Which file to take

You are on	Take
Debian, Ubuntu, Mint	dhs_0.1.0_amd64.deb (or arm64)
Fedora, RHEL, openSUSE	dhs-0.1.0-1.x86_64.rpm (or aarch64)
Any Linux, nothing installed	DHS-0.1.0-x86_64.AppImage, or the linux tarball
Arch	build from the AUR recipe in packaging/aur/
Windows	dhs_0.1.0_windows_amd64.zip (untested, see above)
Building it yourself	dhs-0.1.0-source.tar.gz

The AppImage runs the command-line tool without installing anything:

chmod +x DHS-0.1.0-x86_64.AppImage
./DHS-0.1.0-x86_64.AppImage scan --dest /run/media/you/SSD

Verifying what you downloaded

sha256sum -c SHA256SUMS --ignore-missing

Not in this release

The application manifest, application detection, dhs plan, and any translation of complex
configurations. Windows support is compiled but unverified. There is no graphical interface in the
packages; a GTK4 prototype lives in gui/linux/ and drives this same binary over --json.

Roughly 4 MiB per binary, no runtime to install, no background process, no network call, no
telemetry, no AI.