Minimal, systemd-free Alpine Linux releases version 3.16 Version 3.16.0 of Alpine Linux is out – one of the most significant of the many lightweight distros. Version 3.16.0 is worth a look, especially if you want to broaden your skills. Alpine is interesting because it's not just another me-too distro. It bucks a lot of the trends in modern Linux, and while it's not the easiest to …
Who said unix? Many OS could boot in seconds, Qnx could, I believe 10 years ago they were showing off cold boot in less than a second on atom.
I saw an Amiga fully boot from cold in about 4 seconds in 1990.
There is really no excuse in the “well they were way more basic” hardware is magnitudes faster now and to boot, they shouldn’t be any more complicated, we’re not talking about the software you run afterwards we’re talking about an interface to launch that software. It should be basic. That the “ultra minimal cut back” OS is so far from being that basic is the problem. To defend something taking so long to boot is nuts to me. Would you defend a Game taking 30s to display every frame because oh well it’s complex, and it’s doing loads of stuff?
How often, when starting a game, does it either say it's loading something and make you wait or have an unusually high resource usage while displaying the initial menu (and on occasion other ways of artificially stretching the time from clicking the icon to being able to play to give it time) because it's doing that as you select options? Things take a while to load, verify, and make available for fast access. Games have to load a lot of assets into memory to get that speed. The OS has a similar requirement to run stuff quickly once it's turned on, and thus it spends more time preparing that.
As for older machines, they were indeed doing less when they started, which is important, but as you don't like that argument, they were also using techniques that you can use here as well. In many cases, their OSes were on ROM chips with some caching for the initial state, and you can do that with modern OSes by saving memory contents to disk and restoring them. It's more fragile if things have changed, but it will speed up the process of booting. Most Linux installations don't bother doing that because starting the components from scratch isn't that hard. The boot process also includes a bunch of stuff for hardware management which older computers didn't bother with.
I partially agree.
1 minute is indeed quite slow for a PC that powerful. It was a Core 2 Duo! I remember when these things were trendy because they were in the newer mac minis. Many are 64-bit and they are dual core. I still use my trusty Thinkpad x61 with the core2duo and it boots OpenBSD in ~12 seconds which is a platform that doesn't even focus on boot speed.
However computers in the 80s were much simpler than Linux. Heck going a little later to DOS and that barely needed to boot anything.
"Rebooting from cold on a relatively new computer should take seconds (or even 1 second),"
It is not clear what exactly the "under a minute" referred to - did this include BIOS/UEFI initialisation/"POST" time? I suspect so.
What did (the installed) Alpine boot from? Perhaps the author was booting off a (slow) USB stick?
It is likely the author did a run-from-ram install of Alpine (rather than a run-from-disk) and that is likely to be slower due to having to load the OS from squashfs and unpack it into a ram-based tmpfs.
Alpine in general is actually *very* quick to boot.
Basically there's insufficient data available to analyse/understand the "under a minute" phrase.
[Author here]
I did specify what I was using, but apparently I should have been clearer.
I said:
«
We installed the 32-bit edition on one of the oldest machines we had to hand, a Thinkpad W500 with a Core 2 Duo CPU and a mere 100GB mechanical hard disk.
»
And
«
a 14-year-old laptop, the result was fast and responsive, and boots from cold in well under a minute.
»
I though that was specific enough. Apparently not. My apologies.
It's an old machine. I've tried Win7, Win10, Ubuntu Unity, Pop!_OS and several other distros on it. Linux normally takes a couple of minutes, and Windows longer, to boot on it.
As I said, the machine is from the start of the Credit Crunch. That, for clarity, was 2008. And as I also said, this is with a slow, small, spinning hard disk, not an SSD.
That is a cold boot, from switched off to the desktop.
Also, as I said, the x86-64 edition failed to boot from Ventoy. So this is the 32-bit edition, meaning it is limited to 3-and-a-bit gig of RAM. The machine has 8GB, the max it can take.
Additional info: the machine's discrete nVidia GPU was turned off in the BIOS, because the laptop's cooling fans are intermittently unreliable, so I wanted it to run as cool as possible. It's using the Intel GPU in the Centrino 2 chipset.
"and a mere 100GB mechanical hard disk"
So you did a "Sys mode" (aka run-from-disk) install rather than a "Data mode" (run-from-ram but mount disk for data) or a run-from-ram install?
Sys mode is basically the same as a traditional Linux installation.
"That is a cold boot, from switched off to the desktop."
Ok, so I assume that a large percentage of the "under a minute" boot time was not actually Alpine's own boottime (e.g. it was mainly the BIOS or UEFI initialising, HDD spin-up etc).
"the x86-64 edition failed to boot from Ventoy"
I've never used Ventoy so can't comment on what might have happened in 64bit mode.
Can you clarify if the machine boots in 64bit mode using UEFI or BIOS (includes "CSM" mode in UEFI)?
> So you did a "Sys mode"
Yes, it is a "sys mode" install.
> I assume that a large percentage
Some of that time is in the BIOS, sure. A large percentage? I am not timing this with a stopwatch, but no.
I used to benchmark computers for a living as part of my role as Labs Manager at PC Pro magazine. It is not a trivial process and requires repeated runs and so on to get any validity at all.
I do not do this for the Reg, which does not regularly publish group tests and so on.
What I am trying to convey here is that this distro boots very close to instantaneously in a VM on even my relatively old Core i7 work laptop. It is so quick it would be hard to measure. So, I put it on the oldest slowest PC I have to hand, fitted with the oldest slowest HDD I have to hand, and it boots quicker than Ubuntu does from SSD on a quad-core i7.
This is not intended to be a precise measurement, because without baselines for comparison and so on, precise measurements are [a] almost impossible and [b] meaningless.
Benchmarking its _performance_ would, I am sure, give fairly similar times to any other Linux, because Linux is Linux. It has the same kernel as any other modern distro.
All I am trying to illustrate here is that it starts very quickly. It is not intended to be a benchmark.
I have tried other lightweight cut-down distros on some elderly kit, including AntiX, MX Linux, Void Linux, and Raspberry Pi OS x86, which remains my go-to lightweight Linux.
I do have an older slower laptop: it's a dual-core 32-bit Atom. But it does not have onboard Ethernet, and Alpine does not detect its wifi. So I could not install it on that machine; that is why I noted in the review that I recommend using an Ethernet cable.
So I used the next-slowest.
> Can you clarify if the machine boots in 64bit mode using UEFI or BIOS (includes "CSM" mode in UEFI)?
You are trying to overthink this.
It is a 14YO Core 2 Duo. It does not *have* UEFI. PCs generally did not have UEFI 1½ decades ago.
(I think that in 2008, the only x86-64 kit with UEFI was from Apple. My oldest Intel Mac is from 2009 and is running macOS 10.13 happily.)
It's a BIOS. And as I said in the article, in testing, 64-bit Alpine would not boot. So I used the 32-bit version, which does.
Alpine is an ultra stripped down distro, perfect for learning how Linux functions at the core as an O/S without all that chuff in bigger more fancy distros. Alpine is also perfect for firing up dozens of VMs as it's so low resource, I've had 27 Alpine Docker containers running simultaneously on a bog standard 32GB laptop when I needed to test some simple scaling code.
Alpine is a genuinely useful distro rather than just another overfed clone of Debian or the RH core.
As I said in the article: this OS *is* the underlying Linux used by Docker.
Yes, other container systems are available.
But if you want to run Linux containers on a non-Linux host OS, you need a Linux distro underneath.
You cannot run Linux containers without a Linux kernel. On macOS and on Windows, Docker Desktop runs a Linux distro in a VM, then runs containers in that.
That Linux is Alpine Linux.
The question of what container runtime you use is a red herring: the container runtime has to run on a Linux kernel in order to run Linux containers. Therefore, non-Linux-based OSes need to run a Linux in a VM as the parent of the Linux containers.
You may never see it if you are using Ubuntu containers or openSUSE containers or Fedora containers or $DISTRO containers, but there must be one there.
And Docker uses Alpine. That's why I was interested to try the latest Alpine standalone.
Although it is a relatively niche distro, thousands of Docker users are using it, possibly unwittingly.
If you run Podman, or Swarm or Mesos or K3s or whatever, you still need a Linux.
At a guess:
1. No systemd
2. Minimal-ish resource requirements in this day and age
3. Minimal packages installed
4. Quicker than setting up/compiling Gentoo from scratch
5. No systemd
6. Why not?
If I were still working in non-Windows shop, this sounds like the sort of distro I'd want for servers. It sounds a lot like the old CentOS server "distro". The lack of glibc might be a bitch sometimes, though.
It's good for embedded applications. The documentation goes through how to do installations in applications where you don't have a conventional disk to boot from.
It's also compiled so it will run on older generations of x86 chip, including ones which won't run on most 32 bit distros because they require certain features or instructions which older x86 chips don't have.
-> if you want to broaden your skills
Broadening skills is a good thing and I encourage it. My opinion: we learn more from when things go wrong than when they go right. I am in favour of skilled Linux (or UNIX generally) users.
-> Alpine is interesting because it's not just another me-too distro
I prefer the term YALD to "another me-too distro".
-> being unusually small and simple
That is a good thing. Far too many YALDs are complex and bloated. They are near copies of each other excepting a few insignificant bells and whistles. Alpine is a worthy distro.
It's horses for courses.
Some people want to broaden their skills, explore new avenues and try out new things.
This distro looks like it will fill their needs nicely.
25 years ago I was that person, tired of all the Windows nonsense I was excited to discover Linux. I bought a copy of Red Hat 5 and I was away. New things to learn and new ways of getting things done.
That was then. Now I am retired and Linux is just a tool I use to get to places I want to go to. Computing is no longer a job or a hobby. Nowadays I want things to "just work" so I'll stick to PCLinuxOS. It works, is simple to use and configure so I'll let those people looking for a challenge have a look at Alpine.
Isn't it a wonderful thing that we have a choice when choosing a distro that we can usually find one that we feel comfortable with?
I wholehaertedly agree with your story. I used to use Linux because I liked the challenge and the possibilities to learn and configure things the exact way I wanted.
Now I use Linux because I cannot be arsed to fiddle around with the fsck'ing registry and all the glithces we have in our company laptops (Windows) - yeah, they work, and our service desk guys and gals are great and quick and helpful, but some things remain a hassle (well, they are nagging me, but not enought to really care all that much, it is not my machine, not my responsibility, and I have a dev environment I can access remotely where I call the shots).
I use Devuan and .... uhm... Mint and... I would have to look that up... on my home machines. I'll throw Alpine on the ancient netbook, I think, that plays my music through my stereo system (non-"audiophile") and give it a spin. (yes, I still enjoy some challenges on non-productive systems).
For people asking "why?" the answer is that unless you run a lot of containers/VMs then this is not for you.
Sure you can run it as your daily distro with a desktop, but to do so is missing the point. It's the perfect starting point for minimal containers to your applications, cloud or otherwise.
"For people asking "why?" the answer is that unless you run a lot of containers/VMs then this is not for you."
That statement is misleading. Alpine is a good lightweight Linux distro if you want to run servers, whether acting as a Container/VM host or as a DNS/DHCP/file server etc.
To date Alpine has not targetted desktop use, rather its original direction was for "servers". In more recent times it has become synonymous with Docker containers, but again that was not its original direction.
This new release has added installer support for graphical desktops, so don't (yet) expect a polished desktop distro.
Uhh, no. The linked Wiki page is far superior to the "user handbook", version 0.1a, that appears under the "docs" link on the project main page. But it is still confusing.
So they have two distinctly different installation guides.
Then there is "Tutorials and Howtos". Most are of half-decent quality. One mystery is: why does a page about Alpine and UEFI Support Status appear in the "post-install" section? Seems a bit late in the game.
I think Alpine is good for containers, and much less good for anything else. For example, trying to port mangl manpage viewer took several days of exploring the apk installation options. There doesn't seem to be a dependency tree that links everything with one or two installs.
I'm spoiled by OpenBSD -- for documentation quality, installation quality, and system correctness.
Thank you for one of the better articles about Alpine Linux that I have seen.
Wifi is supposed to work and even if it is not very polished, the setup script is supposed to detect your wifi interface (wlan0 for example) and let you connect via wifi. I suspect that in this case the hardware was from a time where wifi driver was often not open source. It worked fine with raspberry pi last time I tried.
The issue that you could not log in due to home directory was missing surprised me. I am pretty sure that the home directory is created. So I think what happened was that you didn’t install it to disk, and then rebooted it. In that case home will be missing. To avoid that you could do: `lbu add /home` before the `lbu commit`. But you could also have avoided the reboot by simply running `openrc` after setup -desktop to start the services.
I had a look at the missing icons and the problem seems to be that adwaita-icon-theme-42 removed some icons. It looks like they were supposed to be shipped with gtk3, but apparently that doesn't happens, so we will need to find some solution for this. (Thank you gnome for that)
Will try fix both issues for 3.16.1 release.
A neat trick to test alpine without disk, directly from network in qemu:
qemu-system-x86_64 -m 2048 -enable-kvm -serial stdio -cdrom https://dl-cdn.alpinelinux.org/alpine/v3.16/releases/x86_64/alpine-virt-3.16.0-x86_64.iso
After login, run `setup-alpine -q && setup-desktop && openrc`
I installed 3.16 shortly after it came out, replacing an existing 3.15 installation. I use the "standard" ISO.
I tried an in-place upgrade from 3.15 to 3.16 which mostly worked but would for some reason not install a working pip (python).
I gave up on that and tried a fresh install. That kept getting stuck because when I tried to create a user (following the setup-alipine script) it would refuse saying that it wouldn't let me because the user already existed (I was creating the same user as was in the previous install).
I finally just re-formatted the disk using the disk setup script, which I believe is setup-disk.
I then ran setup-alpine again and was able to create the user. However, it didn't create a user directory for that user. I had to create that manually and set the appropriate permission bits manually.
I have gone through the installation process probably two dozen times now in order to get working systems for both 3.15 and 3.16.
I am using it on an old x86 32 bit system with a hard drive. I normally use it as a headless system accessing it by ssh. I plug in a monitor and keyboard for setup. The CPU does not support later x86 instructions, so for example 32 bit Debian will not run on it (the installer complains about a missing CMOV instruction). Alpine does run and this is the reason that I persisted with it.
The installation script has good and bad points. The good point is that it limits the number of options.
The bad points are that it's often not clear what is being asked and there isn't any way of going back and changing an option once you have made a selection.
The selection of mirrors is a complete train wreck. Most of the list scrolls off the top of the screen before you have a chance to see it. I always have to just pick "fastest" and then go back and edit the file manually after installation if I'm not happy with the choice it made.
I was never able to get through an installation in one go. The networking configuration would always seem to fail somehow and the process would stop due to a lack of network connection. I would then figure out how to get the network running and run through configuration again to get through the final steps.
I'm satisfied with the Debian text based installer. You might want to have a look at that for a guide. The Ubuntu server installer is also good guide.
What might be particularly useful is some way of doing a headless install which inserts a configuration file into the ISO so you just create and edit the file, run a script to insert it into the ISO (or build a new ISO), boot from that, and the configuration script reads the file and does what it needs to do based on that. The Raspberry Pi imaging program does this for its images (which are not ISOs). This would be useful for people setting up headless systems where they don't want to have to drag out an extra monitor to set it up.
I believe the setup system has some sort of way of creating a "replay" file, but that assumes you already have a working system that you want to duplicate. It doesn't help if you don't have that.
> Thank you for one of the better articles about Alpine Linux that I have seen.
Oh, thank you for saying so! I appreciate that. :-)
> Wifi is supposed to work and even if it is not very polished, the setup script is supposed to detect your wifi interface (wlan0 for example) and let you connect via wifi.
Aha! OK, I did not try this way. I will make some different boot medium, without Ventoy, and try again.
This page:
https://wiki.alpinelinux.org/wiki/Wi-Fi
... suggested to me I had to get Wifi working _before_ `setup-alpine`. I must have misunderstood.
> I suspect that in this case the hardware was from a time where wifi driver was often not open source.
I tried on a Sony Vaio P, a 32-bit Atom sub-netbook [sic] with no onboard Ethernet. `ip a` did not show a `wlan0` interface, and I do not know how to load firmware from the boot disk.
> The issue that you could not log in due to home directory was missing surprised me.
This was repeatable in 32-bit on bare metal and 64-bit in VirtualBox. I could log in from X.org as root, but a graphical login faile, with no visible error, just instant re-appearance of the display manager and login dialog.
Logging in from a vconsole worked fine, displayed an error about a missing home directory, and left me in the root directory. So, I logged in as root, made `/home/lproven`, did a `chmod lproven:lproven /home/lproven`, and tried again, and GUI login worked fine, on both bare metal and in a VM.
> I had a look at the missing icons and the problem seems to be that adwaita-icon-theme-42 removed some icons.
Aha! Well, adwaita has broken other things for other distros as well.
> so we will need to find some solution for this.
It is merely cosmetic, but yes, it was visible.
> (Thank you gnome for that)
I have met the core GNOME team and discussed this sort of issue.
They do not seem to really care that other desktops use their libraries; indeed they seemed barely aware that there _were_ other desktops, except for KDE. :-(
Be warned that if you are actually using containers like they were intended to be used, in a high performance environment, relying on Alpine will cause problems for you (it did for us and in a very non-obvious way). The reason is that the principal author of musl chose to deliberately exclude TCP queries in DNS (which the RFC allows for small environments):
https://twitter.com/RichFelker/status/994629330130161664
If you aren't using more than 15 containers in your microservice, it will work fine. If you have an autoscaling group, it's trivially easy to blow past that limit even in relatively low traffic cases.
This is one of the most refreshing articles seen in a long time, by someone who obviously knows (a) what he is doing, and (b) what he is talking about---and who is a hard worker and a good writer, to boot!.
Most writers of this calibre have long since given up---and disappeared---because of the "move fast and break things" mentality and modus operandi of most ALL of the current crop of crap---filled with regressions and incompatibilities with even the last "offering"--- 'offered' by what are considered to be "the mainstream" Linux distros---driven, of course, by the 'no-nothings' whose only metric---and mantra-- is "If it ain't the newest, it can't be any good"---with a good dash of "bigger is always better" thrown in.
(Bug reports? Get serious. Most all major AND minor Linus distro houses are too busy working on the NEXT greatest biggest, fastest, most feature-filled distro to pay ANY attention. "Bug Reports" are now handled via the simple expedient of "IGNORE". Almost NO Linux distro house has the incentive, will, nor the desire to do Q-A or validation-testing any more; there's simply not time.)
Here's hoping we see a lot more from you, Mr. Proven.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
