Hardware shortcomings

[moonwalkers]

I measure performance these days by the only yardstick that matters to me, i.e., how long I have to wait for something to happen when I strike a key,, open a window, etc.  From that standpoint, this little notebook boots faster and opens major software packages like Firefox, Libreoffice, Gimp, etc. faster than  the HP.  It may not be a Cray, but it's certainly running efficiently.  I could care less about gaming or pushing a CPU to near-meltdown.  In every day use this is a very good USER.  And I am not without experience, having actually punched paper tape on a 1970 HP 21MX mainframe and programmed a similar vintage Teas Instruments evaluation board to run an astronomical telescope.  My only complaint, really, is the primitive and arcane methods needed to load and boot another OS.  I am no fan of KDE windowing but I am running it out of fear oif bricking the system.  Job 1 should be the establishment of one, or a series, of Bioses which present the same hooks to a uniform bootloaders which relieve me of the need to read tea leaves or hire the local Santeria priest to sacrifice a goat so I can load what I want to run. I remember well, from my days as a sysop/lan/IS security manager that DEC, for the Alpha, and HP for PA RISC accomplished this 30+ years ago.  I'd do it myself, but bluntly, I haven't the talent to attempt it.

I'm glad for you that by your measure of performance PBP outperforms your HP. If only it was applicable everywhere to everyone, then we'd have a computing revolution with Pine64 taking over HP, Dell, Lenovo and others and the whole world. In reality, there are enough people like myself who still need lots and lots of (local) raw CPU (and GPGPU) power for the work we do, something PBP still lacks for all its achievements.

As to the rest - the lack of unified firmware is not a failing that's unique to PBP. Hopefully we'll start seeing manufacturers universally adopt Arm SystemReady specs soon to make situation easier, but when it comes specifically to PBP until then - by now the u-boot firmware that works with PBP (and is a de-facto standard in ARM space) is available in most major distros out there, installation methods are well documented, and you can switch window managers without affecting any of the hardware abstraction layers - it's just a matter of installing the appropriate packages and selecting the appropriate session in your display manager (if you use one, otherwise - adjust your ~/.xinitrc). As to "primitive and arcane" - apologies, but that sure gave me a good laugh, comparing it to BIOS that starts and keeps all CPUs (even 64-bit ones) in 16-bit segmented real mode and is a left-over from MS-DOS predecessor CP/M, and as a boot method simply loads and executes whatever code is available in the first sector (512 bytes) of the boot block device, making it a great fun exercise trying to recover an OS that's no longer booting for whatever reason just because the code in those 512 bytes (minus partition table) is somehow incorrect but cannot be easily examined directly. Frankly, I'd rather take u-boot with it booting kernel directly from the FS using a plain-text configuration file on the very same FS volume, and the ability to install it on removable media like microSD card instead of having to dance around with switching ROM chips on live motherboards to recover from bad BIOS update.