What am I computing with these days?
ARM64 never lived up to the hype, Intel Atom is showing its age. But, finally, System76 is shipping free/open firmware. And now I'm mining DERO.
Background: Libreboot, ThinkPads, and all that.
Back at the end of 2017, I was fairly satisfied with my ThinkPad x200 running Freeslack 14.2 and Libreboot. It served my needs, was \"fully free\", had a disabled \"Intel Management Engine", and was actually a nice machine on top of all that. Then, in January of 2018, the first of many transient execution vulnerabilities were discovered for most Intel and AMD processors, with only a few exceptions. The Core 2 Duo processor that I had in the x200 was certainly on the vulnerable list. At the time, a full fix involved loading new microcode, which would come in the form of a binary blob (for machines that are new enough, anyway), and is something that the Libreboot project was inherently opposed to (at least, at the time it was). That meant that my liberated x200 would not be fully patched from these new flaws, at least not immediately. And thus, the bubble of illusion surrounding my \"perfect computer" was popped. My obsessive-compulsive mind was on the hunt for a new, better, \"perfect" computer.
More issues with Libreboot and the general free-firmware philosophy.
I was already becoming disillusioned with the Libreboot approach, which basically amounts to retro-fitting hardware with firmware it was never designed to run in the first place. I was flashing ThinkPads and selling them on Ebay as alternatives to the ThinkPenguin offerings of the day. Only later did I read the part about making sure to fully upgrade your proprietary firmware BEFORE flashing Libreboot, otherwise you would get stuck with a less-than-latest EC Firmware with no way to upgrade it easily, without flashing back to the proprietary firmware. This was unsettling, to say the least. It left a lot of computers in a less-than-updated-and-unable-to-update state. Flashing back to the proprietary firmware was never as easy as it sounded. I think they have improved on this, and the microcode loading, since then. However, this all exposed a deeper flaw in the thinking. These computers are FULL of proprietary blob firmware! Just because you remove a few binary blobs here and there, does not mean you are running a fully free computer by any means. In fact, you're fighting a losing battle since every year, the computer manufacturers include more and more proprietary firmware and make the operation of the computer depend more and more on this firmware. Unless you are buying from manufacturers who specifically avoid this from day one, you will only have an illusion of freedom, at best. I'd rather support hardware vendors that are at least aware of this in some form, than ones that are in the race to embed more and more proprietary blobs into the hardware and are oblivious to the topic of firmware freedom.
Spectre/Meltdown, the gift that keeps on giving.
The first plan was to shift to processors that were known to be immune to speculative execution vulnerabilities. In such a case, the microcode updates would not be necessary. I started slowly building a collection of supposedly-immune devices.
-Intel Atom(e.g.ASUS EeePC):
I have had more of these than I can count. I currently have an ASUS EeePC 1025c, with a modded BIOS to allow for 64-bit instructions, since the quad-core N2600 Atoms are 64-bit capable (as are most, actually). I also have a Dell Latitude 2100 with an Atom N270 that is dual core and strictly 32-bit. It's actually amazing what that computer can do if you're not in a hurry, not doing any virtualization, or need high end 3D graphics. Pretty much everything else is fair game if you're patient enough. All Intel Atom processors that I've tested pass the spectre-meltdown checker script with all green boxes.
~
-Transmeta Crusoe(e.g.Compaq TC1000):
This machine was as frustrating as it was fascinating. The emulated instruction set was basically a Pentium/MMX (i586+mmx) compatible CPU. Firefox would not launch, and neither would KDE nor Xfce. It did not pass the spectre-meltdown checker completely, but I am unsure if the script's database is correct with boutique vendors such as Transmeta. All in all, it was a fun machine and I kind of miss it.
~
-VIA C7(e.g.HP 2533t):
This was an old-school solid-state laptop, no moving parts whatsoever. I was running a slimmed-down Slackware on it with much satisfaction until it just stopped booting one day. I think it finally overheated, possibly? Like the Transmeta Crusoe, this also did not fully pass the spectre-meltdown checker script, but I still wonder about the accuracy on such old fringe CPUs. This was a very nice machine to use and will be missed.
~
-ARM64 A53(e.g.Pinebook,Rock64):
I had several of these, including the OG 1080p Pinebook (non -Pro). It sucked as much as it was awesome. The 2GB of RAM was very limiting, as was the keyboard. The trackpad was atrocious, the screen was amateurish, and the construction was laughable. Still though, a fully solid-state ARM64-based laptop is a thing of beauty, no matter how poorly it is implemented. I also had a bunch of similar development boards. The best seemed to be the Rock64, which wound up being the most solid implementation of A53 that I ever tried. In the end, I gave up on ARM-based boards for several reasons. The development ecosystem is not nearly as healthy, and the boards mostly need proprietary blobs to even boot, which makes having generic distro images almost worthless. I'd rather mess around with old 32-bit hardware than try to force a working experience out of ARM boards. The progress is there, but they're just not up to speed for day-to-day use. And, I hate smartphones, for the record, so I don't count those at all. All of the A53-based systems fully passed the spectre-meltdown-checker script with all green bars. So, at least they're reliable on that level.
Alas....
The Spectre-Meltdown issue never really got solved, unless you are okay with using only super slow computers. The current set of mitigations for flawed chips make faster newer computers only slightly slower (if you're able to implement them correctly with microcode loading, firmware updates, etc), so there's no reason to run only the old stuff, unless you're trying to prevent future vulnerabilities that have not yet been discovered or disclosed. Even so, the Asus 1025c is still kicking butt. I can do a Zoom call (one way, participating in a webinar without talking or turn on video)! I'd rather use Jitsi than Zoom any day, but it has become the benchmark post-2020 that separates serious computers from hobby/toy computers. If you can't Zoom on it post 2020, it's not a serious computer, or at least it's a single-purpose server-type computer or something like that. Not a general laptop you'd use for work, that's for sure.
My \"work machine" has proprietary blobby firmware: Lenovo ThinkPad Yoga S1. It does what I need it to do to earn a living, which none of the others are able to do. I'm currently in the market for an upgrade, although this machine has served me well, despite the loads I have put on it over the years. I still use the ASUS EeePC 1025c for various things, and I am about to switch over to the Dell Latitude 2100 as my daily driver.
Open Firmware: once a dream, now a reality!
Open Firmware has never been more exciting! I've got my eye on a System76 Galago (>= gen5). If/when I wind up with an extra 200 DERO (or the equivalent thereof in USD), I'll probably get a second-hand one and an external drawing tablet for work stuff [insert tutoring blog post link here later]. But until then, low-end old-school laptops are doing just fine.
DERO CPU Mining - one CPU, one vote (sort of...)
DERO mining is CPU-friendly. Seems to optionally use some rare CPU flags that only exist on some 10th, 11th, and 12th gen Intel Core chips, as well as a limited number of Pentium and Celeron chips. Here is a list of Intel CPUs that would be interesting to try to mine DERO with, using the AstroBWT.
- Celeron N5095 (SHA)Celeron N4500 (SHA)Celeron N4505 (SHA)Celeron N5100 (SHA)Celeron N5105 (SHA)Celeron 6600HE (AVX-512)
- i3 Core (AVX-512)Core i3-1005G1Core i3-1000G1Core i3-1000G4Core i3-1000NG4Core i3-1115G4Core i3-1125G4Core i3-1115G4ECore i3-1115GRECore i3-1110G4Core i3-1120G4
- Core i5-1038NG7 (SHA / AVX-512)Core i5-1035G1 (SHA / AVX-512)Core i5-1035G4 (SHA / AVX-512)Core i5-1035G7 (SHA / AVX-512)Core i5-1030G4 (SHA / AVX-512)Core i5-1030G7 (SHA / AVX-512)Core i5-1030NG7 (SHA / AVX-512)Core i5-11400 (SHA / AVX-512)Core i5-11400F (SHA / AVX-512)Core i5-11500 (SHA / AVX-512)Core i5-11600 (SHA / AVX-512)Core i5-11600K (SHA / AVX-512)Core i5-11600KF (SHA / AVX-512)Core i5-11400T (SHA / AVX-512)Core i5-11500T (SHA / AVX-512)Core i5-11600T (SHA / AVX-512)Core i5-11260H (SHA / AVX-512)Core i5-11400H (SHA / AVX-512)Core i5-11500H (SHA / AVX-512)Core i5-11500HE (SHA / AVX-512)Core i5-11300H (SHA / AVX-512)Core i5-11320H (SHA / AVX-512)Core i5-1135G7 (SHA / AVX-512)Core i5-1145G7 (SHA / AVX-512)Core i5-1155G7 (SHA / AVX-512)Core i5-1145G7E (SHA / AVX-512)Core i5-1145GRE (SHA / AVX-512)Core i5-1130G7 (SHA / AVX-512)Core i5-1140G7 (SHA / AVX-512)Core i5-12400 (SHA / AVX-512)Core i5-12400F (SHA / AVX-512)Core i5-12490F (SHA / AVX-512)Core i5-12500 (SHA / AVX-512)Core i5-12600 (SHA / AVX-512)Core i5-12600K (SHA / AVX-512)Core i5-12600KF (SHA / AVX-512)Core i5-12500T (SHA / AVX-512)Core i5-12500E (SHA / AVX-512)Core i5-12500TE (SHA / AVX-512)Core i5-12450HX (SHA)Core i5-12600HX (SHA)Core i5-12450H (SHA)Core i5-12500H (SHA)Core i5-12600H (SHA)Core i5-12600HE (SHA)Core i5-1240P (SHA)Core i5-1250P (SHA)Core i5-1250PE (SHA)
- i7 Core (AVX-512)
To test this out, I obtained a mostly broken HP 14m-dw0023dx laptop with a Core i5-1035G1 CPU. I was able to get it work just long enough to see that it was only mining around 2.2 KH/s at best, which is not quite as fast as the 2.9 KH/s I'm already getting out of a 4th gen Core i5-4570 in an old Mac that was gifted to me. The HP laptop now reports memory issues and will not boot. I might just have to part it out on eBay to try to get my $60 investment back.
In the end, hardware instruction sets (SHA, AVX512) didn't speed up the mining at all, which seems to be mostly dependent on cache size, as one would expect with an \"egalitarian" mining algorithm. Therefore, desktop processors should in general out-mine laptop processors just because of the trends in cache size on each type of machine, and this agrees with my observations up to this point. The next idea is to look around for \"lots" of old desktops being sold on eBay for next-to-nothing, and build a fleet of dedicated miners out of old library desktops or something along those lines. If/when that day comes, it will deserve a blog post of its very own.