Foxtoo: Gentoo + musl C library on 100MHz Pentium laptop

The beginnings of Adélie Linux.

I haven’t yet finished up writing all the content I want to write about the process needed to get this working, but I do have a little teaser picture to share:

That is a Compaq LTE 5150 with a 100MHz Pentium CPU and 40 MB EDO RAM running Gentoo Linux! The kernel version is 4.2-rc1 (because I’m an incorrigible ricer), it was all built with GCC 4.9.3 and it is using the venerable musl C library instead of glibc. Boot up takes only about 15 seconds off the 5400 RPM laptop IDE disk, and once booted, the minimal kernel I have + bash use only about 3 MB of the 40 MB total.

It may not seem like a very useful thing to have done, but I had a lot of fun building it up, and I’ve ended up finding and closing various bugs in everything from procps to the kernel itself. So I feel that not only has this been a fun personal project across two weekends, but it has been productive for the entire community 🙂

Python 2 -> 3 upgrade: status update

More Python projects ported to Python 3.

This is a small update on my bringing packages in Gentoo to Python 3.

I haven’t had time to contribute as much to this effort as I had hoped, but I have successfully finished with two packages and the patches are now in the hands of upstream maintainers. I’ve been toying with the musl C library as an alternative to glibc (and I’ll be posting about my experiences with that later), which has distracted me a bit from Python 3 work.

app-misc/ca-certificates
Required a bit of effort. Debian #789753 filed. Maintainer seems happy enough with it, but it’s not in master yet.
dev-libs/evdev
This was simple enough; libevdev has had upstream support for Python 3 since 2013. Gentoo #553110 filed with a patch to update the ebuild accordingly. No response as of post time.

Musings: SSH key types, PayPal API documentation, and more

I have a few random musings to arf about today.

Sleep is miserable. I don’t know why I even bother pretending to have a schedule to myself. Between work demands, personal issues, and the fact that I tend to favour going to sleep around the 05:00 hour naturally, it’s impossible. Sure, I can hold a “normal person” schedule indefinitely… if I have no external factors. But my life is full of external factors that make it impossible. And there are some people in my life that try and make me feel guilty for not being able to hold a schedule. It feels miserable.

In other news, PayPal’s API documentation for their SetExpressCheckout call lies. They say the xsi:type for the SolutionType is “ebl:SolutionTypeType”, but I found out the hard way that passing that as the type causes a SOAP Fault (and leaks the API password and signature out in the error message)! The only way I can find to do it properly is to set xmlns=”urn:ebay:apis:eBLBaseComponents” on the SolutionType node and then set xsi:type=”SolutionTypeType” (no ebl: namespace). Then the API accepts it fine. Who knows why their systems do what they do.

I investigated making a new SSH key that would be stronger than my current one. Unfortunately, it doesn’t seem I really have a choice in the matter. The only common denominator is RSA, as shown in this matrix:

Key Type Mac OS X NetBSD Debian
RSA Yes Yes Yes
DSA Yes Yes Yes
ed25519 No No No
ECDSA No Yes Yes
SSH Version / OS Version 5.6 / 10.8.5 5.9 / 6.1.5/i386. 6.0 / 8.0 “Jessie”.

Note that the following systems supported all listed key types:

  • Gentoo 20150623
  • FreeBSD 10.1
  • OpenBSD 5.6
  • Alpine Linux 3.2
  • Windows 2000

Truly a sad day when a 16 year old Windows OS has more SSH key types available (via mingw) than Mac OS X, NetBSD, and Debian combined. Looks like I’m sticking with RSA keys for the foreseeable future.

Linux 4.1 kernel: Finally, a movement in the upwards direction

Playing around with the new Linux 4.1 kernel and some benchmarks on a MacBook Pro for comparison.

No musings yesterday because I was having quite a time getting Linux to play well. I spent yesterday configuring the rest of the kernel until around 21:00, when I started searching for and applying all the patches I wanted. Found a small bug in the CPU optimisation patch that Gentoo uses (via grsecurity); namely, it doesn’t enable P6_NOP for anything higher than a Core 2. I manually edited the patch and applied it.

I built the kernel, ran # emerge @module-rebuild, signed the newly built modules, and rebooted in to my new system… Or I would have, if it had been able to read the init RAM disk. Doing the Apple EFI dance to switch between 3.18 to rebuild and 4.1 to test was not my idea of a good time, but after a while, I found the issue. There’s something broken somewhere and it would not read XZ-compressed ones. I used my fallback algorithm, LZO (chosen because it’s free and very fast), and it booted right up. Only now, I couldn’t start KDE.

Typically, I start KDE by using $ X_SESSION=KDE-4 startx; I don’t use KDM or XDM because I regularly test breaking changes to i915 that may cause X to hardlock, rendering my laptop useless. This time, however, it complained ‘xterm: command not found’. Unsure why it was trying to load xterm, I checked around and I found no answer. I still haven’t figured this out. The workaround I’m using is $ XINITRC=/etc/X11/Sessions/KDE-4 xinit which acts the same as the old command, only it’s longer and less readable.

Then I had a world of i915 bugs that I will omit from my blog mainly because they were mostly configuration error and the ones that weren’t were resolved by re-merging media-libs/mesa.

After all of that was over, I checked on my wireless chip. Lo and behold, for the first time since I’ve started using draft-n wireless networking on Linux in 2009, it was actually associating successfully to a 5GHz 802.11n AP! The speed is only 150mbit/s; the chip supports 300mbit, so I am not sure why that is, but I am still happy to be finally untethered from my Ethernet cord!

Some benchmarks.

Running emerge -1 openssl

Kernel / Sched Wall Time System Time
3.18 / CFQ 5m 3s 59s
4.1 / CFQ 4m 57s 55s
4.1 / BFQ 4m 53s 52s

That’s a pretty nice win for BFQ, and a huge improvement over 3.18. Note this is all on the same hardware, on a fresh boot, with nothing in fscache.

Playing 720p MPEG-4 video in VLC

Kernel On-Die Temperature CPU % used
3.18 71° C 31.2%
4.1 63° C 46.3%

Each measurement was taken at 2 minutes into playing the video. Not sure why the CPU’s a bit more active, but wow, that temperature reduction is serious!

Overall, I am very, very happy with this upgrade. The Linux 4 series seems to be all about making things smoother, faster, and more battery-friendly. I’ll update later with a benchmark of battery life.

If you have a MacBook Pro from the 2011 era (or you’re just curious), you can view my config file online. Special thanks to Elly and Horst for guidance, patchsets, and keeping me company while I was going insane with menuconfig. 🙂