Whilst I wait for my complete FreeBSD Ports rebuild to finishIn typical vishwin fashion where I let the post rot before I muster effort to finish writing, I introduce, hopefully, an excuse to write on this blog more regularly. And not in a New Year's resolution manner, because many of us know how well those go…
Welcome to Open Source Despatches, where I try to talk about not-the-most-public happenings in my open source world. As in, not formal releases, not public comments on bug trackers, patch submissions, etc. But maybe some of the public-facing stuff gets included for context.
Before I continue with this first episode, I think we need to address the elephant in the roomcabin: what the hell is a DankPad?
The DankPad
The DankPad is my colloquial name for my new-to-me ThinkPad X13 Gen 2 AMD. Not sorry to disappoint.
 |
| my active ThinkPad fleet as of Winter Field Day: W550s on left, X13 Gen 2 AMD (DankPad) on right |
My ThinkPad W550s has been my primary machine through thick and thin since 2015. However, despite being a certified Ultrabook (ie thin-and-light, laugh out loud), the 15-inch form factor has gotten more cumbersome to carry around when I need to do so. Even with the machine this one replaced, I have always had a need for a smaller form factor secondary machine to both carry around and distribute processing loads. Thin doesn't cut it; the other dimensions matter more.
In 2022, Micro Center apparently got a boatload, spread across all their stores, of Evolve III Maestro netbooks (you read that right), initially retailing at $89 but later dropping to $59 a pop. At least within my circles, JonathanD jumped on early in the year to see how far he could go with them, particularly with running Linux and amateur radio applications. He eventually reported in two blog posts, but the initial vibes over IRC were good enough that jedijf got a fleet to play, break, learn.
Field Day comes around, he brings his entire Evolve fleet (amongst all the other stuff he brings) and invites me to get FreeBSD running on one.
 |
| trying to remember how to manually ZFS-on-root on a flash drive before Field Day ended |
It's one thing to run an operating system from a removable disk (big up Damn Small Linux, my first Linux distribution I ever used), it's another to run from the internal disk, or in the Evolve's case, the 4 GB eMMC.
 |
| get in bitches, we're going to the toy store |
I officially had to call this the meme laptop when I brought it around. See how far I could go with FreeBSD on it, which resulted in a wiki page. All for $59.
 |
| the early stages of getting Cinnamon set up |
Fast forward to September 2023 (IRC log dated 18 October 2023):
[08:18:25] <vishwin> welp looks like my evolve is properly dead [08:18:37] <vishwin> "incurable" boot looping... [08:44:37] <JonathanD> :( [08:54:25] <vishwin> jawn won't stay on past a few seconds, power button doesn't take any input, just powers itself on and off anymore [09:02:20] * waltman pours one out [09:02:46] <waltman> vishwin: Fortunately you can switch over to one of the other 5 you bought, right? :) [09:03:28] <JonathanD> all mine are still going strong. [09:04:36] <waltman> Having it die right before OKT POTA is unfortunate. [09:04:42] <vishwin> it was actually dead last month
I sure as hell got my meme's worth of $59 outta that jawn. However, that made me down a small form factor machine, so back to just the W550s, again, cumbersome to carry around too often (and I was bringing it around a lot during the intervening period).
January 2024 comes around and I see a good deal on a refurbished X13 Gen 2 AMD. Low key, I'd been waiting for an opportunity to acquire an AMD machine, especially a Ryzen. Done.
 |
| eventually the stickers are getting transferred over |
It is a little bigger at 13 inches compared to the Evolve's 11.6 inches, but this is practically a rounding error. Did I mention this is my first AMD machine in…12 years?
 |
| getting here took longer than it should have |
The DankPad came with some Chinese no-name 256 GB NVMe SSD pre-loaded with Windows 10. I knew this would be insufficient capacity for the ZFS boot environments and other crap like source code I would load on here, especially considering this only takes a single internal disk, so the first order of business was to install a higher capacity SSD. But I needed to have the machine in hand to buy the correct new SSD, so that took a few days after I received the machine and built my first FreeBSD images for it. In the meantime, I attempted to put FreeBSD on the "stock" SSD, multiple times, to errors on first boot. I guess Windows stuff wasn't completely blown away from that SSD, but no harm no foul considering the new SSD. However, this did confirm that only UEFI boot on GPT works; all legacy MBR-based boot is off the table. Don't bother setting up both on the disk, you'd be wasting space.
This is also the first machine I own with a graphical BIOS. I guess nothing new for x86 machines released this decade, as all the Dell Optiplex 7010s I imaged for a now-completed contract had graphical BIOSes, but my last owned machine vintage is 2015 (the W550s). In the BIOS, there is a sleep state option, set to "Windows" by default but has a "Linux" option. Apparently these are bad labelling for selecting the warm suspend state presented to the operating system: "Windows" is S0ix whereas "Linux" is S3. Even though FreeBSD-CURRENT gets ACPICA updates into the base system fairly regularly, we still don't support S0ix. We don't even support S4 (hibernate) "unless S4BIOS is available" according to acpi(4). Need to play around with this a bit more, when I can carve some time when I don't need stuff running on it, but in the meantime no warm suspend for now. (The meme laptop never warm suspended under my tutelage.)
Built-in sound output generally works. Dolby Audio speaker system, however, Laugh Out Loud. Built-in microphone audio input is dodgy at best, even after adjusting mixer(8) and other userspace utilities from Ports. Built-in webcam doesn't appear to work with webcamd, at least derived from the Linux kernel version webcamd is on. No Discord voice/video calls with this machine anytime soon, unless I connect (supported) USB webcams and audio inputs. hselasky@ did all the work with webcamd and other USB class devices, but unfortunately he became another tragic victim of 2023; may he rest in peace.
Otherwise the DankPad is a major upgrade from the meme laptop and a great addition to my fleet. Zen 3 Ryzen has been worth every bit of money I dropped on it. I could use this to build all my ports and then some if I didn't already have an HP air fryer (HP ProLiant DL380 gen 7) for this role, but I do build the FreeBSD base system for this machine on this machine. With 12 threads, the first time building an entire world (everything but the kernel, configure files in /etc and release media/images) took 4060 seconds. In comparison, the HP air fryer took 3336 seconds with 24 threads and a few more LLVM machine targets. Only about a ten-minute difference which is impressive.
FreeBSD ports behind the scene
This is the part where I try to shed some light on why certain things I work on in FreeBSD Ports seem like they can take forever for no reason.
First, I'm actually being slowed down, erm crippled, by another large undertaking in the tree: mass realignment of man page locations. Because the package interiors have changed, we need to bump the revision number, as shown:
[00:00:11] Deleting libidn-1.38.pkg: new version: 1.38_1 [00:00:13] Deleting lynx-2.8.9.1_1,1.pkg: missing dependency: libidn-1.38
The revision number bumping doesn't seem like a big deal, but when your package dependency metadata consist of all = instead of >=, everything that depends on the bumped package has to get rebuilt just to "correct" the metadata. For some heavy ports, this means the whole hog gets recompiled and such. Port Makefiles hardly have this kind of specificity; only the resulting package metadata end up like this. There is work in progress (not by me) to relax this. But in the meantime, every little bump can be costly on productivity, so I try to take every precaution to avoid them, until package metadata is relaxed.
One casualty from this and general tree churn is getting setuptools-scm updated. Not only updated, but the official name changed ever so slightly to use a hyphen rather than an underscore (both are equivalent in Python package metadata), so good to ensure we follow suit. Every so often, gotta rebase these changes on top of the tree as other stuff gets committed. Then everything has to get tested for build breakages at the very least.
Two more things are still being dogfooded: libxml2 2.12 and webkitgtk 2.42. The latter requires a change in our base system's copy and configuration of the libc++ API in order to build at all, let alone run. Otherwise, much of the work consisted of consolidating into one port three flavours depending on library combinations. Meanwhile libxml2 2.12 introduced some major API breakages even with a configure option, to be enabled in the port by default, to enable parts of the legacy API. Before getting there, still need to test an update to a consumer, libxslt, to make sure it behaves with the current libxml version in our tree (I don't see any obvious problems but this could be a jinx). After that I will offer the libxml2 update for wider testing.
any final words?
That's it for now. This post is long enough as it is, brain dumping without any coherency whatsoever. Plus this has been delayed for time. Some choice happenings, details and flames were omitted since I want to be done with this one already, but…more will be revealed.
