Installing Laser

The repository is private, so the download goes through the GitHub CLI rather than a public URL. That is the whole prerequisite: gh installed, signed in, with access to the repository. There is no token to create, paste, or keep somewhere.

It is worth being precise about what this prerequisite is not. It belongs to the fetch, not to the application. Laser itself needs nothing on the machine — no Node, no npm, no coding agent, no runtime of any kind. It carries all of that inside the package. A machine that has never run any of it can install Laser and be finished.

Note the shape of the command: it writes the script to a file and then runs the file. Nothing is piped into a shell. The difference matters because it gives you a moment in which the thing about to run is sitting on disk in front of you, readable, before it runs. An install that streams straight into sh never offers that moment.

Two checks happen before the first byte is written anywhere it will stay. The download is compared against a checksum manifest, and the build provenance is verified. Only then does the installer begin placing files.

The order is the point. A verification that runs after the install has already half-finished tells you that something went wrong, which you would have found out anyway; a verification that runs first is the only kind that can prevent it.

The install writes into your home directory. It does not ask for root, and there is no point in the process where granting it would help. Nothing is placed in a system directory, nothing is registered with a service manager, and nothing about the machine outside your own account changes.

If the install is interrupted — a closed lid, a dropped connection, a second thought and a Ctrl-C — it rolls back. The failure mode of a half-written install is a machine in a state nobody designed, and the way to not have that state is to not leave it behind.

AppImage

Runs anywhere, without root. Statically linked, so it does not want libfuse2 — the dependency that makes most AppImages fail on a clean machine.

.deb

Debian, Ubuntu, and anything else that speaks dpkg.

.rpm

Fedora, RHEL, and the rest of the rpm world.

tar.gz

Everything else, and any situation where you would rather place the files yourself.

Each format is built for x86-64 and arm64. The installer picks the right one; the list exists for the cases where you would rather pick it yourself, or where something else — a configuration manager, an image build — is doing the placing.

Re-running the same line upgrades in place. It also tells you which version it moved from, which is the piece most upgrade paths leave out and the piece you want the moment something behaves differently than it did yesterday.

--uninstall removes exactly what the installer created. Not a directory it found and assumed was its own, not a configuration file that looked related — what it created. Anything you made, it asks about first.

This is a smaller promise than "clean uninstall" and a more useful one. It is easy to delete too much and call it thorough. The guarantee here is symmetry: the uninstall undoes the install, and stops.