hpr-knowledge-base/hpr_transcripts/hpr3728.txt

Episode: 3728
Title: HPR3728: Pinebook Pro review
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3728/hpr3728.mp3
Transcribed: 2025-10-25 04:44:08

---

This is Hacker Public Radio Episode 3,728 for Wednesday the 16th of November 2022.
Today's show is entitled Pine Book Pro Review.
It is hosted by Bynars C and is about 49 minutes long.
It carries an explicit flag.
The summary is I talk about the Pine Book Pro and breaking various other armed devices.
Hey guys, it's been a while.
It's been about long enough that I remembered I should record a Hacker Public Radio episode.
I've had a few things in the dock for a while, but not a recording day.
So this might be a one episode recording day or a many episode recording day.
I'll have to see how I feel after doing one.
This episode is about the Pine Book Pro.
I do a review on it.
So first I'm going to talk about motivations behind buying a Pine Book Pro.
Some initial hardware and software impressions.
I then jump into some technical stuff about flashing bootloaders, operating system support.
Then after that I do a little bit of performance benchmarking to compare the Pine Book Pro to other hardware we might be more familiar with.
I then will talk about ultimately what I'm using the Pine Book Pro for now.
Then I talk about open hardware a little bit at the end.
So let's jump right into it.
Why the Pine Book Pro?
Lately I've been thinking a lot about power consumption when it comes to computing.
Sort of intuitively I know that arm devices don't pull as much power as a big iron AMD 64.
I've never tested this.
It's just from reading the power supply.
And seeing, oh this thing will fail at 15 watts.
Obviously, you know, there has been a lot more than 15 watts because if it does the power supply fails.
And then you look at the big power supply on your Pentium 4 machine.
And it's like, how is this thing even capable of pulling this many watts without starting a house fire?
So there's a couple of examples I have laid out in the show notes.
So at least my big AMD 64 laptops might think pad X220 and think pad T490.
Their power supply will fail at 65 watts.
So that means that most they can pull 65 watts.
A small arm single board computer system on a chip, however you want to call it.
A lot of those will have power supplies that fail at 15 watts.
But I've seen some people who've actually plugged in a power monitor.
And like the Raspberry Pi, for example, is only pulling five watts.
It's not even close to 15.
Android phones, somewhere around 18 watts is a number that I've had for a while.
I'm not sure if it's accurate.
Of course, this varies when you have the fast charging thing where the phone communicates with the charger.
And can variably change how much electricity it's getting sent.
And then my last big example, my Pentium 4 machine, it pulls 250 watts before the power supply fails.
These numbers are fairly easy to find.
You can look on your power supply for a maximum output value.
This is the point where the power supply fails.
So we can almost assume that that's the maximum power draw because if the power supply fails,
then it can't draw any more power, right?
Of course, this is DC output and not AC output.
And anyone who knows anything about electricity knows that converting back and forth between AC and DC is lossy or expensive.
But these values are useful as a general estimate.
I think earlier this year or last year, I wrote something and I have a link for it in the show notes.
I wrote a thing on my website about power consumption and calculating how much does it cost to leave my Pentium 4 machine plugged in and running?
And is it cheaper to just not leave my Pentium 4 machine plugged in and running so I can save hundreds of dollars on electricity and buy something more efficient?
Sort of that type of line of thinking is what I wrote about.
So back to the Pinebook Pro, my goal and all of this was to find a self-contained computer that runs a Unix or Linux.
It doesn't take much power to run.
It's not what I call sort of a consumption rectangle, which is a smartphone, right?
It's actually a useful tool.
It can be charged from both AC power, right, pushing the power through a rectifier or
charged from DC power without having to push all that through and inverter.
Sort of if you're on the mains power, you don't have to worry about power consumption.
But if you're running off of a big battery or like the alternator in your car, not having to push that power through an inverter means that you don't drain your car battery and now your car won't start.
So charging from existing stored power was probably the most novel consideration I've ever had.
I think a lot of these other requirements were kind of a given.
So a few obvious solutions come to my mind.
Raspberry Pi 4, it's not self-contained.
And using a Pi top in a public space, a Pi top is sort of a DIY laptop that you build with a Raspberry Pi.
Using a Pi top in a public space is a good way to get the bomb squad called on you.
A Beaglebone Black is also good, but it's not self-contained and it's not nearly popular enough for a lot of operating systems to support it.
And the last example, the Pine Book Pro is self-contained and it's supported by some of the operating systems that I like to rent.
So the Pine Book Pro is an obvious choice.
It's an open hardware or a laptop.
You can charge it via a barrel cable or a USB-C cable.
I think USB-C charging is very useful because it means I can choose between charging from the mains where efficiency and losses acceptable or charging from a DC source.
For example, the little deal that plugs into the cigarette lighter in your car where a lot of loss and efficiency is unacceptable.
So the actual use case, the actual use case is what computer can I run off of an old car battery or the alternator in my car without burning up all of the power by pushing it through an inverter.
I'll revisit this use case later.
I'm going to keep the final conclusion time.
So some initial notes immediately upon opening the Pine Book Pro.
I took these notes. They're largely unedited.
I want to be honest on my first impression. So my impression on shipping.
I was worried about DHL dropping my package out of the plane. They shipped it through DHL.
I was worried about DHL leaving my package in the rain or having one of the employees using it as a soccer ball or having it get stuck in customs.
But ultimately it arrived safely and was packaged well.
That is something unusual, typically when I've ordered things that have shipped through DHL from China.
They come to my house either broken or the package appears to have been kicked out of a plane drug through the mud, taken to hell and back.
But I was surprised this time. That's something I noticed. DHL didn't absolutely destroy this package. That is unusual.
And inside the package, the Pine Book Pro was packaged with two boxes.
And then within a padded envelope, within another padded envelope.
This was surprising to me that it didn't arrive broken.
So my initial hardware impressions. The touchpad sucks and trackpad scrolling sucks.
In quotes or in parentheses, I have it's probably just KDE.
Installing synaptic strivers allegedly fix this problem.
The keyboard is comfortable, clicky and full-size despite being a chocolate keyboard.
I didn't like that the control and function keys are backwards compared to a thinkpad.
I like the thinkpad keyboard layout. I like how the control and function keys are positioned on a thinkpad keyboard.
So it's kind of unusual and strange for me when those things are swapped.
Shift plus enter seems to type a capital M character.
My muscle memory and keycording was broken, but it appears to be a fundamental design flaw with KDE.
The Pine Book Pro is passively cooled, so it gets a bit warm.
The display is a sharp IPS display. It was almost a two-high resolution for my eyes.
It's 1920 by 1080 instead of 1366 by 768.
That's another thing I can fix and software, you know, increasing the font size.
Enabling and disabling the mic Wi-Fi in camera through the keyboard is confusing.
And it does not perform the kill switch by a hot plugging like how you would expect.
So my example here is on a thinkpad X220, there is a switch on the side that you can flip and it disconnects the wireless card.
It's hot plugging the wireless card. That doesn't seem to work on the Pine Book Pro, so you have to restart the system or things become unstable.
The charger comes with both US and EU prongs, so that's something kind of cool.
My software impression is it's Manjaro, so I have a frowny face. It's KDE, so I have a frowny face.
It comes with MPV, so there's a smiley face. It has blues instead of Bluetooth D, so that's a frowny face.
I like Bluetooth D. It's way more reliable in my anecdotal experience.
It comes with firewall D instead of UFW, so I put a heart there because that's something I like a lot.
It's more than just a smile. The standard installation does not come with VIM, VI, or ED, so it's completely useless and unusable.
This is the stock operating system I'm talking about now. The stock operating system is Manjaro.
For those of you who don't know, Manjaro is sort of one of those distributions based on a distribution, based on a distribution.
The ultimate upstream is ARCH for Manjaro.
The Firefox configuration uses Google as the default sort of engine. That's not something I like.
And then a couple of sort of funny ones I have here. It didn't come with Red Hat Enterprise Linux 7, so obviously I hate it.
It didn't come with any form of BSD, so obviously I hate it. These are more lighthearted ones.
And then the last one is also sort of humorous. My terminal color scheme is one of the worst I have seen in my life.
My next available free day here are some more largely unedited notes. I still don't like Manjaro. I still don't like Pac-Man.
On the default Manjaro installation, the Manjaro-Arm-Flashr tool seems to be able to create SD cards that boot.
On the Pinebook Pro, this is useful for the insurance policy.
When I was updating, there was lots of network IO and the wireless card seemed to stutter a little bit.
And my last note for software is I can't boot another operating system using the stock firmware.
I read somewhere that you have to flash the SPI Flash. From everything I know and understand, SPI Flash is just fancy armguide terminology for NVRAM.
Although this is incorrect, you can actually, there is a dip switch on the mainboard.
You can flip that dip switch. It disables the internal EMMC storage, and now the Pinebook Pro will boot from an SD card.
But in order to install to the EMMC storage, you have to flip the dip switch back on, but you have to restart it to flip the dip switch back on.
So you kind of do need to flash a better SPI Flash.
You need better stuff on your NVRAM to make it easier and more hacker friendly.
Additionally, my mainboard looks slightly different than the mainboard on the wiki, but the components are in generally the same location.
So some technical stuff, upgrading the you boot on storage devices.
So it seems like the Pinebook Pro has three possible locations for the bootloader.
NVRAM, right? This is the weird SPI Flash thing.
EMMC, and from an SD card, the boot process is something like load the bootloader from NVRAM.
I query the storage device. If the storage device has its own bootloader chain load that, either wise, use the bootloader from NVRAM.
It really seems like a lot of you boot soup, but upgrading the bootloader on the storage device seems to marginally increase stability.
So how you do this from the stock Menjaro image is you run the following commands.
Sudo Pac-Man Dash Capital S, why you you? Sudo Pac-Man Dash Capital S, you boot Dash Pinebook Pro, and then we're going to run some disk destroyer commands.
Sudo DD, IF equals slash boot slash IDBloader.img, OF equals slash dev slash MMCBLK2 seek equals 64, CLNV equals no trunk, comma F sync, and then the next disk destroyer command Sudo DD, IF equals slash boot slash you boot dot ITB.
OF equals slash dev slash MMCBLK2 seek equals 16384, CONV equals no trunk, comma F sync, and then finally we have to sync the disk Sudo sync.
The seek options are required, I think it's because we have to put these bootloaders and these bootloader files and very specific spots.
The system, the hardware can figure out where they're at, and additionally you have to run a sync command.
This is something that you might not have to do if you've ever ran a DD to, for example, a USB flash drive, and that's because this is all flash storage.
So EMMC is just a fancy SD card, right? And SD cards and EMMC oftentimes they will say that they've finished writing files before they haven't.
So you have to run a sync command to make sure that all of that stuff has been flushed to the drive.
And then finally the last command is a Sudo reboot to reboot the system.
You can also flash Uboot externally, so this is my section on flashing Uboot externally and buying more stuff.
I found some Fedora specific instructions that are actually just PineBook Pro specific, I have a link to them in the show notes.
It's basically instructions on how to flash the PineBook Pro using the Uboot and IDB. Is it IDB or ITB? I think it's the ITB from Fedora.
When I flashed this one, the screen, the display was showing in Uboot. Every time a kernel would load, the built-in display would flash with random garbled nonsense.
Which was kind of fun when you try a different operating system, you get different garbled nonsense when you boot the system. That's kind of fun, I think.
The keyboard didn't work with Uboot, but the system would boot from an SD card.
Sort of a weird thing is the system would always try to boot from EMMC once before it would boot from an SD card and then after you got it to boot from an SD card, it would always boot from an SD card until you removed it.
Armbian and that BSD seemed to boot just fine from the SD card, and then I kept an SD card with the Stock Minger image as an insurance policy.
Because the keyboard does not work in Uboot, I ordered the Pine64 serial cable, this is serial over 3.5mm audio jack.
Hopefully so that I can fix it in the future. The system still boots automatically, but I'd like to be able to pass options to my bootloader to do things like enter single user mode, run FSCK at boot time, change kernel versions, change boot options, etc.
That's kind of something that I like to be able to do.
The next section, operating system support, I will not use ARCH, you cannot force me, you cannot coerce me, you cannot even bribe me, I will use anything other than ARCH as long as it's not a bun too.
That was the thought I had when I was fighting with Menjaro.
The next paragraph I started, sadly BSD is not super duper easy on the PineBook Pro like most other single board computers, but I've never stepped down from a challenge.
Even more sad than OBSD is there's no plan 9 ported to the PineBook Pro, what am I going to do without plan 9?
So sort of some philosophy and extra running a distro based on a distro based on a distro based on ARCH is the antithesis of my computing philosophy, luckily enough.
There's a big list of operating systems that run on the PineBook Pro, I have a link to that in the show notes.
Most of these are actually distros based on distros based on distros, but not all of them.
I think open BSD instantly appeals to me, but there's no support for graphical TTYs yet.
So you have to do the installation over serial, no support for graphical TTYs is a non-starter for me.
What are you going to do when X fails? You can't do anything, right? That's kind of a thing that I'm not going to want to deal with.
Net BSD also appeals to me, but it currently doesn't have Wi-Fi in the 9.x version, only in the dash current version.
Sort of the issue with dash current releases of any operating system is that, well your Wi-Fi might work, but everything else is unstable and crashing all the time.
So it's almost more useful to just not have Wi-Fi if you really want to run this thing.
There's a wide selection of usable software, so take your pick.
I then have links to the official Manjaro images with a variety of desktop environments.
It actually took me a while to find these. They don't have pine 64 images on their website, only on a GitHub, but it is an official GitHub account.
So I left a link here for anyone who is looking for them because you either lost or corrupted your insurance policy SD card.
And then I have an image, sort of Google Android boot loops, making fun of the, I guess, food product with a similar name.
And then my comment is Android boot loops. It's essentially if you've ever played with flashing custom ROMs to an Android phone.
You know that you have a very high chance of getting into some condition where you have unescapable boot loops.
This is my experience trying to boot these various operating systems from an SD card.
I almost even when I was trying these different operating systems, I thought to myself, wow, this is just like every time I thought I'd bricked an Android phone and then turned out I actually did brick an Android phone because I flashed the rug big.
So just a fun, a funny image I've included. My next section is on installing NetBSD. I decided to go with NetBSD because I haven't used it a lot, but it's kind of fun.
NetBSD seemed to work just fine, but 9.x doesn't ship the Broadcom drivers. The drivers are present in the dash current branch, but the issue with the dash current branch is that it's not entirely stable.
And also the boot loader does not come with the system. So you have to download U-boot and an AR-64 build of NetBSD. You can get the U-boot from package source and the ARM image from the NetBSD website.
So to get around the no Wi-Fi issue, you can use a USB to Wi-Fi dongle. I use an atheros AR-9271. This is in the show notes. This dongle has been very reliable for me, except that I just recently broke the USB part off of the board, so now it's completely broken.
But over the last couple of years, it has worked with every single hardware and software configuration I've traded with. So if you need a Wi-Fi dongle, I recommend this one.
And then to get around the RJ45 port, I use a USB to RJ45 adapter. I have an ASICS, ASIX, AX88772. This ASICS dongle is U-Green branded. I'm not sure if that matters at all.
Both of these dongle seem to work with every operating system and hardware configuration I've tried them with.
ARM is kind of strange, so we have to boot from an SD card, running any operating system in my case in NetBSD.
In order to burn an image to the internal storage, so you have to do this from a separate machine.
Or from the Pinebrook Pro itself, I just do it on a separate machine because I have way more and way more bandwidth on a separate machine that isn't trying to push network over USB.
So some commands, the sections of commands, the options past the DD are in fact very important.
So I W get the NetBSD image, W get the U-boot for the Pinebrook Pro, a tarball from package source. I unzip the image, unzip the U-boot.
I unmount dev SDX. I typically use dev SDX in examples because most people don't have enough drives plugged in that they're going to accidentally copy and paste something in ruin.
Device they don't have plugged in.
Then you DD, your ARM64.image to your flash drive.
The DD options I use status equals progress, comv equals fsync, bs equals one meg.
And then I run a pseudo-sync, and then I do another DD.
This is for the bootloader stuff. Output is dev, my flash drive.
C equals 64, comv equals sync status equals progress.
I run another pseudo-sync, and then I eject the drive.
And then to install NetBSD to the internal EMMC.
The process is similar, but NetBSD's versions of DD take slightly different arguments.
The options past are important.
So I download the image using FTP, I unzip the image, I DD the image, options, comv equals sync, bs equals one meg.
Pay attention to which devices you're running the DD command on.
In the first example, I was using a Linux host in the second example.
I'm using a BSD host.
So for example on Linux, dev, sda on NetBSD, that's dev, rl, od.
Right, different devices. I run a sync.
I install Packaging and install the Uboot-PineBook-Pro, which contains the Uboot stuff.
IDD that, I sync in Reboot.
There are a couple more desktop-centric things I did after booting from EMMC.
I changed the root password, I disable PostFix.
I did enable XDM, although I say XDM equals no in my example, probably from yanking and putting in VIM.
And then installing Packaging and a couple of packages.
The rest of this is on NetBSD specific.
I've avoided getting into a lot of specifics because after basically getting a base operating system,
the same as any other NetBSD installation with slide variations.
So here's the performance benchmark.
So the PineBook-Pro has six CPU cores.
It has two fast cores and four slow cores.
I'll talk more about that in a second, and it comes with four gigabytes of RAM.
The CPU is fairly slow, but it's entirely usable.
On large procedural jobs like software compilation, it's painful, but for concurrent jobs, it seems to be fine.
So I did some compiler performance using the time command.
As expected, the PineBook-Pro is slower when it comes to software compilation than a standard AMD 64 machine.
Something that surprised me, NetBSD was actually significantly slower than a standard, or I guess, default Manjaro installation.
I think this is probably due to the fact that the Linux kernel might know how to handle a system with multiple CPUs that have varying speeds better than NetBSD.
Despite the fact that NetBSD seems to do just fine on systems with.
Many cores, you know, the entirety of SDF.org runs on NetBSD.
It can't be that bad.
I think it's largely an ARM plus weird CPU configuration thing.
So to test sequential jobs, I compiled Plan 9 port.
I have a link to Plan 9 port in the show notes.
Plan 9 port is a lot of utilities from Plan 9 ported to a posixion environment.
I chose Plan 9 port because it's fairly large, but it's very portable.
The compilation is largely sequential.
It invokes many standard shell utilities.
It involves extra pre-process or steps to convert Plan 9 to something a standard Unix compiler like GCC or Clank can understand.
On my T490, it has an 8th Gen Core i8.
I wrote Core i8. I'll have to change it. It should be Core i7.
I don't think they make a Core i8.
So the Core i7 has four cores, eight threads. It runs at 4.8 GHz.
I have a V-Pro model for maximum thermal output.
Real-time, it compiled in four minutes.
On my ThinkPad X220, that's a second-generation Core i5.
It has two cores, four threads, runs at 2.6 GHz.
It has V-Pro also for maximum thermal output.
I'm compiled in about four minutes.
So on the PineBook Pro, it has two GHz cores and four 1.5 GHz cores.
I may or may not have written this backwards.
Nope, I wrote it right, too fast for slow.
Yep, so two GHz cores and four 1.5 GHz cores.
The PineBook Pro has no CPU fan for maximum thermal output.
This one's running the Stock Minjaro Image. It compiled Plan 9 in 22 minutes.
On the PineBook Pro running NetBSD, it compiled Plan 9 port in 60 minutes.
I then compiled Vim because Vim can be built in parallel as using the Dash J flag.
You can build Vim in parallel without causing any issues in contrast to Plan 9 port
where essentially you're bootstrapping an entire operating system.
So you can't, or I guess an operating system compatibility layer,
so you can't really build those things concurrently
because the thing you build next depends on the thing you build previously.
So I use the Make option Make Dash J7.
This will run seven concurrent jobs, compiler jobs.
As far as I'm concerned, I think number of CPU cores plus one is a fairly safe option to pass.
That's what I always ran when I ran Gen 2.
So it's safe enough, I guess, on my Core i8.
Why did I have Core i8 in the show notes? I'm going to have to fix that.
On the Core i7, it took 27 seconds to build Vim.
On the Core i5, with Make Dash J7, it took 77 seconds.
And yes, I do understand that the more jobs you add,
doesn't mean the faster it compiles because eventually you reach marginal returns
and even start to get like anti-returns.
I can't remember the word for it, but concurrent processing only goes so far.
Eventually you run too many processes concurrently
and now they're fighting for resources instead of just trying to optimize
however many resources you have.
So it took 77 seconds.
On the Pinebook Pro running Manjaro, same flag, Make Dash J7,
it took 220 seconds.
There's almost four minutes.
On the Pinebook Pro running Net BSD, same flag, Make Dash J7,
it took 319 seconds to build Vim.
So those are just some benchmarks you can sort of figure out what's faster,
what's slower, some hardware you might be familiar with,
and then I compared Manjaro.
The idea behind comparing Manjaro and Net BSD performance
is largely because I found it interesting that there was such a difference.
On Net BSD it took almost three times longer to build Plan 9 port
and it took 100 seconds longer to build Vim.
That was just really interesting to me.
I did then did some web browser testing.
This is probably snake oil, but I thought I'd test the web browsers anyway
because Pinebook Pro has similar hardware specifications
to the adware subsidized crop tops sold by Google.
So I thought it'd be a good idea to compare web browser performance
on my systems as well.
I don't have one of these Google adware subsidized crop tops,
but as far as I remember,
they're just like...
I'm trying to... I think Chrome OS is...
it's not Android, it's...
I think it's based on Gallium OS,
which is based on Gen 2 Linux.
But as far as I can remember,
the few times in my life I've used one of these
adware subsidized Google crop tops.
They've been really unpleasant to use.
That's why I don't own one is because I tried one once and I said,
this is the worst computer I have ever touched in my life.
Not only is the software difficult to use,
but the keyboard is also uncomfortable on the trackpad sucks.
Why would I buy this?
So I found a website that has browser benchmarks.
It's browserbench.org.
They're probably snake oil,
but running JavaScript tests is a good way to perform...
how good a browser on a specific type of hardware is.
I then chose their JetStream 2 test.
The description for JetStream 2
is that it is a JavaScript and WebAssembly benchmarks suite focused
on the most advanced web applications.
It rewards browsers that start out quickly, execute code quickly,
and run smoothly.
For more information, read the in-depth analysis.
Bigger scores are better.
I did all of these tests in Firefox.
I don't use any of the other browsers
because they're not really standards compliant and they break things.
And I think...
Also, I don't like the idea of using a Google browser really at all.
So I just use Firefox everywhere.
On my ThinkPad T490, it got a score of 79.5.
On my ThinkPad X220, it got a score of 40.
And then on the PineBook Pro running Manjaro, it got a score of 19.
I think this is what you would also expect from the compiler tests.
ThinkPad T490 is the fastest.
X220 is somewhere in between.
And then the PineBook Pro is unbearably slow.
Like I said, I don't have...
In my notes, I wrote ChromeSumption.
I don't have a ChromeSumption book to test against.
So all I can say is that a PineBook Pro is slower than a Workhorse AMD64 machine
when it comes to interpreting JavaScript.
And it totally browsing the web on a PineBook Pro actually wasn't that bad.
I think that's largely because the types of websites I go to
are either no JavaScript or very minimal JavaScript.
So it really wasn't that bad.
And then here's my conclusion section.
So I say, did the PineBook Pro fulfill its needs?
My intended use case was a Unix machine that I can charge from an existing
battery source or an alternator.
This immediately invokes ideas of, why would I even need
why if I support NetBSD is fine?
Ultimately, what happened?
Like many Android phones, I have destroyed.
I ended up flashing a bad image to the SPI Flash Chip.
Remember, this is just ArmHipster terminology for NVRAM.
And I cannot get the system to boot or even show signs of life.
I attempted to enter Masqueram mode to reflash the SPI.
But I remain unsuccessful.
There are still a few other things I might try.
And I think I'll record a follow-up episode if I ever get this functional again.
So I didn't exactly have an opportunity to test this and this machine
in the environment I got it for.
But I had a lot of fun before I bricked it.
Just like every Android phone I've ever bricked, it's fun.
It's fun until you brick it.
Again, this is a place for future updates.
I then ask, who's the PineBook Pro 4?
And all caps, hackers.
I think obviously the types of people who are interested in Pine64 devices
and similar single board computers.
We already own a computer.
If not, our computer hoarders.
So I think it's unlikely that the PineBook Pro will become anyone's primary computer.
But that doesn't mean it's useless, I think.
The entire point of arm single board computers is to have fun and to learn something.
So why not have fun and learn something?
My advice, don't flash your SPI if you wanted to work as advertised.
That is a mistake I made.
Flashing bad things to bad places.
I think all but two of my Android phones are functional.
I think we all have a whole drawer full of phones.
Most of mine are bricked and non-functional.
But I had fun in the process.
And if I'm not using it anyway, might as well try something fun.
So I have some final thoughts about open hardware.
I think oftentimes before purchasing freedom-centric hardware,
I search for reviews so that I can correctly set my expectations.
Oftentimes, I think these reviews are very epidermal.
That means they're not even really skin deep reviews.
I think the reviewers are consumers reviewing products for a consumer audience.
Not really hackers making sort of in-depth reviews for a hacker audience.
I think these type of reviews frustrate me.
But sometimes I think a lot of the fundamental flaws of the product seem to shine through the lack of thoroughness by these reviewers.
I think a lot of the general negativity that comes out of these reviews on open hardware seems to stem from unrealistic expectations.
I think a lot of this is because the community seems to over-hype many of these devices out of ignorance.
They'll sort of say things like, oh yeah, the freedom device is the proprietary alternative killer.
It's the end all be all device that will usher in the year of the Linux dollar device category.
I say dollar device category because it's a variable, right?
The year of the Linux smart light bulb or whatever else.
The year of the Linux phone, the year of the Linux toaster, so on and so forth.
I think it seems like the high expectations fall flat when confronted with the reality of open hardware.
Either it's way too experimental or it's way too expensive.
It seems like many of these devices are lacking both developer time and users who are not only enthusiastic but also knowledgeable.
I think there are also some pitfalls of mobile Linux and Unix that includes bad power management, difficulty hot plugging wireless chipsets, graphical interfaces trying to cope with the fact they don't have a physical keyboard.
There's still a lot of work to be done and I think as for users, it always seems like a lot of the most enthusiastic users, right? The loudest users.
They always have some sort of expectation that the open hardware device or the Linux device will have one to one feature parity with the proprietary device.
I think it's either that the loudest users are the ones we hear or that we sort of have selective hearing and we only want to hear sort of these utopian dreams of a free software open hardware future.
I think really my prime example of this conflict between expectations in reality is sort of Linux smartphones.
I'm not talking about Android and I'm talking about smartphones that run a non-Android Linux like post market OS or something like that.
Or one of those GNOME mobile shells on top of a Linux. I think with the exception of that weird one that has weird licensing that's kind of proprietary.
I think with the exception of Sailfish OS.
I think it doesn't really help the image of open hardware or even setting user expectations correctly.
When a lot of these Linux smartphones, especially the ones we've seen over the years, have been advertised as a viable Android competitor if not replacement instead of anything other than what they actually are.
Which is an armboard attached to a touchscreen with a modem.
I oftentimes ask myself, you know, what is open-sourced worth? How much money am I willing to throw at an idea that I like?
I think money thrown at an idea that I like is better than money that I throw at an idea that I don't like.
In many cases, it seems like open hardware devices are more expensive than their proprietary counterparts for a few reasons.
I think the two largest reasons are that a lot of these open devices are small batch manufacturing.
It's more expensive to manufacture only a couple. They typically have some lower bound and then it becomes cheaper as you reach different tiers of how many models are going to manufacture.
And I think the second reason is that a lot of open hardware isn't subsidized by pre-installed adware.
And in fact, even even free software, open-sourced software. It's not installed by pre-installed adware.
Sort of in the case of nearly every device that comes with proprietary software, it also comes pre-loaded with adware.
Android is a really good example of this. If you've ever used a Samsung Android phone, you're constantly getting push notifications for advertisements from Samsung.
If you've ever used a Microsoft device, you're constantly getting notifications about the latest Microsoft subscription thing.
That's not a thing we see in the free software world. We don't subsidize our operating systems by selling advertisements and pushing them through push notifications.
I think what is open source worth? I think open source is definitely worth a few extra dollars, a few extra hours of manual configuration, a few extra paper cuts.
And I think it's definitely rewarding because I have a clean conscience knowing that I didn't, again, pay for another Windows license that I will never, ever use, and I will never, ever, ever get a refund for.
I think open source is worth investing in because the improvements I'll be at slow.
They have a wider impact on sort of the ecosystem than just buying a laptop with Linux pre-installed.
So there are my thoughts on open hardware. I have some future project ideas.
Something with the Raspberry Pi, I crossed that out. I guess since I crossed it out in my notes and I don't want to uncross it out, I'll have to record that short little snippet.
Another idea, NetBSD in depth, I think one that I might have another host on for, the host that I was previously, guest previously for, because I told them this idea and they liked it.
This future idea, why is my lightbulb running Android? Another Internet of Terror ideas. I chose the term Internet of Terror, sort of inspired by Richard Stolman's Internet of Stings idea, except I think Internet of Terror is better because the acronym still turns into IOT instead of IOS.
Although maybe IOS is an Internet of Terror device.
Not my last idea, it's sort of something a little bit strange.
I thought about turning a router into a general purpose computing device. Probably a MIPS router because where the heck else can I find a MIPS CPU at a reasonable price?
I thought this is kind of a fun idea. Might as well do something novel instead of just do another thing with another ARM board that a bunch of people have done before a thousand times.
Anyway, thanks for listening. Hopefully you enjoyed this show. If you've ever thought about recording a podcast, hacker public radio. It's a good place. Lots of good people, lots of good shows, and we'd be glad to hear your voice.
If you have any questions or comments, you can always email me.
I think my email address is in the hacker public radio thing, although they have some obfuscation techniques.
Or leave a comment. Leaving comments is always good because comments are encouragement.
And also comments allow me to sort of get a third person perspective and figure out where I might be wrong, and adjust my understanding of things accordingly.
Again, thanks for listening to hacker public radio. I am your host, Ben RC. And that's all I have for today. Thanks.
You have been listening to Hacker Public Radio at hackerpublicradio.org. Today's show was contributed by a HBR listener like yourself.
If you ever thought of recording a podcast, then click on our contribute link to find out how easy it really is.
Hosting for HBR has been kindly provided by an honesthost.com, the internet archive, and our sync.net.
On the Sadois status, today's show is released under Creative Commons, Attribution, 4.0 International License.