Arch is minimal in the sense that the default system consists of very little. If you install nothing but the base metapackage, you won't get a usable system out of it at all. The purpose of Arch is to fill out a complete, working system by making your own choices. If you follow the installation guide, then you start out with base, linux, and linux-firmware. Base is a metapackages that consists of archlinux-keyring, bash, bzip2, coreutils, file, filesystem, findutils, gawk, gcc-libs, gettext, glibc, grep, gzip, iproute2, iputils, licenses, pacman, pciutils, procps-ng, psmisc, sed, shadow, systemd, systemd-sysvcompat, tar, util-linux, xz.
To get a fully-working system, you'd also need a bootloader, but Arch doesn't prescribe what that has to be. Alpine is mostly going to give you these same thing in terms of available CLI utilities, but rather than being based on GNU libc and GNU coreutils, it's based on musl and busybox. The init system is OpenRC rather than systemd. And it has a default bootloader, which is syslinux.
This makes Alpine more "minimal" in the sense of a minimal installation taking up less disk space, because musl, busybox, and OpenRC are smaller in the literal sense of the binary files consume less disk space than glibc, GNU coreutils, and systemd. Busybox also comes with ash (I think actually dash) as the default shell, which smaller than bash.
I have no idea if the apk package manager is smaller than pacman. They're both smaller than what you'd get out of a Debian or Redhat descended system.
Personally, I think it's a bit misleading to call either of these more minimal than the other. The functionality, feature set, list of available utilities is pretty much the same. Alpine is just giving you smaller files, though note that using a musl-based system presents a lot of difficulty because a fair amount of software Linux users expect and are familiar with isn't really POSIX-compliant and only works with GNU C.
Alpine can do both, actually; a "sys" install does a traditional root filesystem, but Alpine also can run... I think a ro root with a single rw overlay with all added packages(?)
Debian is not minimal at all, it emphasizes compatibility over all else.
There are many custom scripts to wrap around systemd so you can still use old style commands. Apt is pretty slow (and again packages come with custom scripts) and stuff like apt-xapian-index will just gobble up all your CPU if you are on a slow system.
Debian has many scripts to automate things for a nice experience, but it's certainly not minimal.
I think "vanilla" is perfect term for it. Most of the software is just vanilla compile + whatever it is needed to play nicely with rest of the system.
Most defaults are sensible and close to what app itself provides, again with exceptions to play nicely with rest of the system.
Most packages also come with bunch of recommended ones that extend functionality which means a bit extra space used, but just
APT::Install-Recommends "0";
fixes that (I'd recommend that for servers but not for desktops unless you're seriously space constrained).
And most important thing is that upgrade works. I installed my desktop in ~2008 and just upgraded across the ages, the install older than every single component in my machine.
> There are many custom scripts to wrap around systemd so you can still use old style commands.
That's just not breaking old stuff, minimal doesn't really need to mean "just breaks your old scripts that worked fine up until now".
And it's kinda required for transitionary period, some packages still use /etc/init.d/* to start for example and AFAIK Debian still haven't said "systemd is the only way forward" which means many packages provide both /etc/init.d/* for SysV boot and /lib/systemd/system/* for Systemd boot.
> and stuff like apt-xapian-index will just gobble up all your CPU if you are on a slow system
How is tool that's not even in standard install relevant to anything?
Alpine base rootfs is just a few megabytes, while Arch is like 100-200MB. I usually encounter Alpine in Docker containers when people want to wrap just one specific service and have save space on things that are not essential for it (it would be wasteful to ship your 20MB app in a 200MB Arch/Debian container).
I didn't know Alpine was useful as a working machine though.
A Debian Slim Docker image is 20MiB, and in my experience by the time you install all the dependencies of your app in an Alpine image, it’s bigger than the equivalent based on Debian Slim.
> A Debian Slim Docker image is 20MiB, and in my experience by the time you install all the dependencies of your app in an Alpine image, it’s bigger than the equivalent based on Debian Slim.
This is true, also while Alpine is an excellent base image, some people have run into troubles with musl/busybox and prefer to use Debian/Ubuntu or whatever else they're familiar with as their container base.
Then again, I kind of went in the opposite direction and use Ubuntu as the base for all of my container images and install software "the normal way": for example, getting OpenJDK through apt as I would on a server with Ansible, or for my local dev machine, without any of the fanciful optimizations or clever hacks to keep the file sizes down.
The downside of this is that my base images are multiple hundreds of MB in size (even after cleaning apt cache in the same step as doing the install, to avoid adding that to the layers), but on the bright side that hardly matters because I use the same base images for all of my containers so only the changes for that particular image need to be transferred through the network and like 40-80% of the layers remain consistent: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo...
It's not "optimal" from a size perspective, but it's delightfully simple and approachable.
It works fine on older machines. setup-xorg after the installing process, add a light WM such as wmaker or jwm for parent commenter's pentium II and he/she is done.
Also are you suggesting that Debian netinstall is not minimal?