I was making a matrix of releases and features, one of which is “MUSL” (or alternatively uClibc) build for small fast secure operation. Usually those two alternative libraries are used for things like embedded systems or routers. Places where size matters rather a lot since they are often very starved for hardware. Many still use 16 bit chips and memory measured in megs.
There are a few desktop systems built with them too, but often that is “experimental”. One is Sabotage, that is a port of Linux From Scratch (LFS) using MUSL and with an abhorrence of the HFS (file system name space standard). As I’m rather fond of already knowing where things are located, moving them all around again on theoretical grounds (good though they may be) doesn’t excite me much… I may yet build Sabotage just to experience it, but learning yet another package manager and having yet another place where “everything you know is wrong” on name space is low on my ‘Oh Boy!’ list…
While digging around there, I found that Alpine Linux is already built on MUSL. Not only that, it has a hardened kernel build. They have a default “run from memory” mode and use OpenRC, not systemd. They have a port that runs on the Raspberry Pi. Since all of those are things I wanted, it is an obvious place to try.
From their “about” tab:
About
Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency.
Small
Alpine Linux is built around musl libc and busybox. This makes it smaller and more resource efficient than traditional GNU/Linux distributions. A container requires no more than 8 MB and a minimal installation to disk requires around 130 MB of storage. Not only do you get a fully-fledged Linux environment but a large selection of packages from the repository.
Binary packages are thinned out and split, giving you even more control over what you install, which in turn keeps your environment as small and efficient as possible.
Simple
Alpine Linux is a very simple distribution that will try to stay out of your way. It uses its own package manager called apk, the OpenRC init system, script driven set-ups and that’s it! This provides you with a simple, crystal-clear Linux environment without all the noise. You can then add on top of that just the packages you need for your project, so whether it’s building a home PVR, or an iSCSI storage controller, a wafer-thin mail server container, or a rock-solid embedded switch, nothing else will get in the way.
Secure
Alpine Linux was designed with security in mind. The kernel is patched with grsecurity/PaX out of the box, and all userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities.
Essentially, the first cluster of my goals for a linux. It would be far far easier to start from their base rather than redo all of that myself, and likely me doing it less well. They state that historically they had begun as a Gentoo fork (or copy), which was also a strong candidate for me too. All in all, highly promising.
So I installed it, following the directions here:
http://wiki.alpinelinux.org/wiki/Raspberry_Pi
The install is very fast and very easy. Essentially download a tarball of about 79 MB, extract it onto a Fat32 formatted SD card, stick that in the Pi and boot.
That’s it.
No, you don’t need to pay attention to Pi or Pi Model 2, it figures it out… Well, you need to use the right SD or micro-SD for your box…
I installed it on a crappy PNY 8 MB class 4 card (that failed to boot Raspbian…) since that was what I had empty. It booted and ran fine and fast.
There are some config steps you go through, listed on their page, but nothing particularly hard. The major thing was just how startlingly fast it was at booting, at handling packages, et everything. All this with a 200 ish MB memory footprint including running from a RAM disk!
If nothing else, it is a stellar proof of concept for a small fast secure distribution based on MUSL and with a hardened kernel.
The Bad
It has Yet Another Package Manager. Called “apk”. it is sort of like pacman and sort of like apt-get and sort of like… but seems to work well. Doing an “apk add FOO” on a few things was OK and very very fast. But really, we can’t standardize on one package manager name with optional flags?
The biggest issue for me was that the directions for Setting Up X and getting xfce desktop running didn’t work. Typing “startx” gave me a black screen and a locked up system (well, it might have been running, but with monitor, keyboard, and mouse out of action…) For further debugging, I’ll need to set up a second box so I can rsh into it to kill the X process when it locks the screen… Sigh.
OTOH, while I rate my desire to do debugging of X-windows problems slightly below tooth extractions, root canals, and playing on fire ant hills, it is a lot less work than starting a port from near scratch to end up debugging your own X-windows problems… At least some folks have gotten it to to work already on Alpine.
I found one chat log from late 2015 where one of the developers said, in response to someone relating troubles, “getting a desktop going in Alpine is a labor of love”…
In Conclusion
As it stands now, I’m very impressed with Alpine for its stated goal of headless and embedded systems. I will most likely covert my Pi B+ to it as my DNS and misc. server since it always runs headless anyway.
Over time, I’m slowly going to whack on it when there’s nothing immediate on the plate, to see if I can find the formula to make lxde or xfce or whatever desktop run.
However, at the present moment, it is too “user hostile” for setting up a desktop for use by the average Joe or Jane. Since one of my goals is a completely “cook book” install with as much as possible built locally from source code if desired, my present first target is unlikely to be Alpine. (But who knows, I might discover some simple PIBKAC error in the install and be all over it tomorrow…)
As of now, the most likely candidates are Slackware and LFS. LFS has a small lead since it has a CLFS version based on MUSL already running. Slackware comes with “distcc” already built and installed (!) so clearly has a head start in the area of “built to build”, but I’m still working on their build packages system (slackbuilds). It does a lot of ‘from source’ stuff, but it is all user driven with hand reconciliation of dependencies… Not a NOOBS kind of thing. LFS is “follow the cookbook” clean, though with fewer options and packages. Decisions decisions… More on that in another post later.
OK, enough on that. Alpine is impressive kit inside their stated domain, “needs work” on the desktop front. I’m gonna whack on it at medium low priority over time. IF it had a larger user base, it would be a simple web search, but as a low usage distro, especially on the Pi, that didn’t turn over much. So up to me, if slowly. Anyone else wants to “run out ahead”, feel free. I’m going to try a LFS build next and see how many months it takes ;-)
Musings from the Chiefio 
Found a very nice “how to set up XFCE” web page for Alpine here:
http://wiki.alpinelinux.org/wiki/XFCE_Setup
Unfortunately, attempts to follow it result in failure on “psmouse” module being missing, mdev? not being in the run level (fixed with rc-update add mdev) and “alpine-desktop” being missing.
So a couple of key bits were not downloaded or installed or whatever by the rpi install process and scripting. Sigh.
You would think folks had heard of Q.A. before…
Then again, it takes a certain amount of self control and tolerance to watch the same week long suite of test cases run doing exactly nothing, time after time after time, and adding new test cases for every bug patched, to see nothing happen again since it was patched… All for that day when “Stuff Happens” and the regression finds an old failure returned, though perhaps via a different mode…
OK, their product is way interesting, way fast, and likely a very good base to build from, for what I want to build, but their Q.A. and process suck (at least for the’ hobby’ Raspberry Pi). Got it.
Since sometimes these things improve all on their own, as other folks complain, submit patches, or just have time to work on that bit of the port, I’m going to leave Alpine on the Pi to sit and stew for a while. Later I’ll try again and see if it has improved.
I am going to try it on my x86 and AMD_64 boxes. Since it runs diskless, it could be ideal for the AMD_64 where the disk is failing, and since it is entirely different, might get past that Debian video driver hang on the x86 box… or not… The thesis being that the port is likely a whole lot more mature on the Intel Desktop class of machines, so I can go ahead and finish a gross evaluation of it there, while not fighting X-Wars_Part_348574638495743654985690 …. Have I mentioned that I really really hate X-windows install / config process?
Since one of my goals is a “from source” build that any old guy can do, releases that are more “hacker friendly only” don’t make that cut. Sure, I can likely make it go, but then every single release I’m back in that debug chair… With that in mind, the LFS process is next up. It is extraordinarily well documented, and all parts tested to work before it goes into their book. Just what I want for the “anyone can do it” requirement. Only downside, really, is that packages are likely to be fewer in number and older in release level… Security will be largely a “DIY” job too. A patching we will go, a patching we will go, hi ho the floppy-o, a patching we will go..
But, we’ll see. I’ve explored a variety of “build systems” and hope to get a posting up with a broad brush comment on them. Each has benefits and detriments, not the least of which is the learning load for each one (Gentoo being particularly feature rich, and thus, noob hostile). LFS has a build system consisting of “by hand using scripts”. This is to enable more hands on learning about Linux, but has the virtue of not a lot to learn about the build system itself. OTOH, you get to do it all, over a few days, to get to the point of having an X-windows to configure…
So that’s where I’m at now. On to LFS…
@EMSmith; It sounds like alpine or LFS might be the base you can build on. Solid, built in security and a small footprint are a real plus, specially something that lends it’s self to operating small devices. At some point you will have to jump off of that cliff and make things that work for for you, with your own phylosophy of operations.
Can’t believe X-Windows is still a pain in the rear. Back in the late 1980s I attemped to setup a 286-16box with Linux 0.9 something, with X-Windows. Looked cool but was no use to me as I needed to use MSDOS based programs and the 286 was far too slow to run them under emulation. Seems like every time I have had a usable box and installed dual boot, Microsoft would discover the insult and corrupt everything in it’s attempt to “fix” the problem.
After you “Blaze” the trail others will follow but for now I’ll watch. Getting too old to want to wander in the wilderness, and far too many “Leaders” want people to follow them off into dead ends of Eye Candy GUIs full of bloot and errors…pg
Thus my “rapid prototype” short exploration of choices before the leap…. Scouts and intel first, commit the ground troups last…
Part of the pondering is glibc vs musl, as some programs still are not patched to run under musl…. but it has better cleaner smaller less buggy higher security libs…
Well, what if you didn’t have to choose?
There are multilib builds for 32 bit and 64 bit, and a multiarch system for Debian….
CLFS64 is multilib…
So in theory I ought to be able to make a multilib that was base glibc so things just work, but musl for the bits that work with it… Eventually swapping to musl base and glibc for only those parts that need it…
More work, and debugging a pain, but more stuff working day one even if on glibc…
Needs two /lib paths and two tool chains, and …
But any code ought to work down one chain or the other…
I don’t think it breaks anything to run a musl library application on a glibc kernel, as long as both know where their libraries are located… System calls ought to be releases level specific, not lib…
Could start with static linked for the minor library, just to simplify things, and have default Make point only to the default libraries, so random minor makes don’t need multilib awareness…
Hmmmmm…….
Brilliant idea, or Royal Pain In The Donkey in the making?
I wish I had your patience and skill at sorting this stuff out. I have tried to go all linux several times and each time I got sick and tired of having most everything work out of the box except the one or two things that absolutely had to work for the system to be useful.
Working in IT operations in my day job I am like the mechanic who refuses to work on his car when he gets home. I just want a simple straight forward daily driver that runs when I need it and does not require divine intervention to get needed functionality working and some obscure poorly documented hack to get there from here.
If you succeed in building a high security, fast, low bloat setup that does the basics needed for daily browsing, I will be very grateful to you for your efforts.
I have lived on linux for a couple of years now (chromeos being a linux clone as is android) and had no issues with browsing, editing, or email. Gimp for images is workable, but the commands are obscure.
For “no work and no hassle” stand alone, Samsung Galaxy Note has been fine, as has ChromeOS as long as you are ok with Google watching over your shoulder and limited command depth…
For raw Linux, Ubuntu starts from the rich Debian base, then cleans it up (Mint being the better desktop version IMHO), while CentOS is RHEL made free and largely just works as it is used in major scientific data centers. IFF you must have MSWindows then run it on some other bit of hardware… but do run a Linux somewhere… (At $60 and a tv set it isn’t hard to run a Pi…).
I’ve come to really love how you can swap the chip and change os in the Pi. Put your home directory on a usb drive… and you are always at home as the os changes. Very useful for the “that thing missing” problem… I’m presently mostly running Arch, but wget was missing and not buildable… swap to Fedora in a minute and all was well… stuff downloaded to usb, then swap back.
That RasPi “toy” seems to be as close to the needs of the “Beer Can” computer concept as you can get. Change the chip as the need arises or swap out the computer if it dies. Cheap enough to throw away or demote to lessor jobs as needed.
Getting a software system to go with it is the thing that needs to be settled on so that the rest of us don’t have to wander through the jungle of competing software concepts. I only want to have to learn one more system, as I walk away from MSWindoz.
Did I tell you that yesterday morning I discovered that Microsoft remotely upgraded me to windows10 and my morning screen demanded I accept their terms of use! Took me an hour and a half to get rid of it and restore my system. Even Mozilla is getting into the act of embedding others software implants that later demand you accept them to to be able to operate your computer.
Soon I will HAVE to set up and get familiar with the RasPi equipment that I have been accumulating. If and when I get caught up with everything else on my plates. ;-) …pg
@P.G.:
There was a Windows 7 update that watches your level and updates you to the current new. Name was innocuous and nothing warned. There are web pages out there detailing the name. It must be removed or you will be in a Groundhog Day cycle of re-updating….
Part of why I always shut off automatic update.
IMHO, the Pi 2 makes a marginal but acceptable desktop, so the Pi 3 ought to be fine for most browsing and desktop use. Only WordPress editing with live spell check loop and full sceen video have been issues for me. Even there, the speed is acceptable and half sceen video OK. (Likely a NEON build system would fix video since that is what the NEON instruction set and hardware is for…)
Setting up a Pi is incredibly easier than Linux on a PC and vastly easier than a dual boot Windoze box. Especially for Berry Boot. Drop Berryboot on a default Fat32 formatted SD chip, boot it, click the OSs you want on it, go get coffee. When done, boot. To change OS, check a different one at boot time. To checkpoint backup, click the copy tab. To recover from a FUBAR, boot your last checkpoint or revert all the way to the initial install. All in a nice simple GUI panel.
It really is something you can do in about 5 minutes to set up and click load image…
I regularly tear down my setup for one reason or another and rebuild it as a new gizmo. Then putting it back is about 5 minutes if I’m slow. Swapping OS on a Berryboot chip is about one minute, swapping chips to other versions, about 2. Very liberating… (Like that article where I made it a router to the hotspot and routed the whole house through it while AT&T played with their wires). Now that $5 chip sits in a drawer ready to go anytime I want it.
While “on the road” I just plugged it into the tv in the room (for the Pi2 you really want an HDMI input TV). With a usb keyboard, mouse, hdmi TV and power, you plug together and are up in less than 5 minutes. With added wifi dongle (Edimax or some such worked fine) it was about 2 minutes more to be logging on to the wifi. Wicd under Debian was fairly easy.
It really is way easier than doing it on a PC the old way, and as the hardware is standardized, you don’t end up in Driver Hell because your video or usb chipset is “unusual”…
EMSmith; OK, you have shamed into it!. Went out to the shop and inventoried parts. Looks like my grandson was a busy boy last summer. We have 1- RasPi 1, as well as 4 – 1gig Quad Core model Bs, with 16GB Samsung microSDs. DogBone parts to stack them all and a SB wall wart that could drive them all. :-). No Idea as to what is on the microSDs as of yet. The Pi-1 has an unfinished install on it’s SD because I could not “see” the GUI on my old analog TV. Now I have a HDMI LCD display for this. I don’t need a fancy daily driver as This MS-7 Lenovo will serve that function. Maybe tonight, while I’m resting, I will attempt to fire up these things and see what the grandson has wrought…pg
Speaking as “any old guy” in Linux terms, I must say your interest in building “a “from source” build that any old guy can do” sounds perfect! Thanks in advance – it’s exactly what I need to watch somebody who knows what he’s doing at play. I’ll go through it a time or two until I get a better grasp of what’s going on before re-wrecking my own system ….
Not that my current Mint is bad, you understand, but it is systemd, so my OS must be changed before it can really be trusted.
Re Windows 7 updates, I read in the MSM a few days ago that MS “updated” their update reminder recently. It seems the new one regards clicking the red button as permission to “upgrade” your OS, rather than as telling it to “Go Away”. Sneaky. The more I hear the gladder I am to have given them the boot post-XP.
@P.G.:
Glad I could help! 8-)
You have more H.W. than I do!
@Steve C.:
I can’t stress enough how liberating it is to have a Pi model 2 with swapable mini-SD chips and Berryboot that lets you do check points.
I can change systems in about a minute via a chip swap, make a backup copy proir to trying something in about the same, and recover just as fast. I now have about 16 SD cards (“chips”) many with 4 to 6 OS installs on them. Makes playing sooo much more fun and easy!
To backup a chip to an external archive ( chip at, say, /dev/sdL where L is the drive letter, like a or b, call it b for now) and archive mounted at /archive/SDchips you just type:
dd if=/dev/sdb of=/archive/SDchips/chip_archive_name bs=1M
to resore it, swap
if for of.
That works for all chips, even berryboot ones, as it ia a direct binary dump of the chip.
For those where a bit of speed loss at run time is OK, Berryboot lets you do checkpoint saves of compressed state images to the chip itself. So “save an image”, boot the regular one and try something, don’t like it? Drop back to the last image. All very fast and easy. I now have one chip with Fedora, Debian, Puppy, Ubuntu Mate, all saved as “pristine”, post build script, workingcheckpoint, and currentworking versions. All nicely on a 16 GB class 10 chip that cost $10 at Best Buy.
So my best reccomendation is buy extra chips and enjoy the play space! Painless “try something” is here.
FWIW, as of now, Gentoo is looking like just too much the kit of parts with swiss army knife and directions in pidgin… I’ll get it sorted out, but can’t reccomend it to others. Arch is a bit “unfinished”, though fast. Alpine is way unfinished “work in progress” IMHO. Slackware a bit peculiar though mostly complete, but the build to completion is scattered. LFS is the most clear and direct and complete enough, but the workload very high. I have found a package manager for it, that with a bit of work and scripting may well make it best for “just say build” OR DIY the whole way, with hand holding docs.
Right now I’m doing a FreeBSD install and loving it! More on that when done… but the feel is like coming home where everything is where it ought to be and all the clothes in the closet fit. Right now unpacking their port collection. It automatically does the verification and patch updates to the ports.. ( “ports” are source build scripts and packages for additional programs). Yeah, I have to work out for myself how to get X windows running… but probably worth it…
Pingback: DNS Server on Pi Alpine Linux | Musings from the Chiefio