Venturing beyond the default OS on Raspberry Pi 5 The Raspberry Pi 5 is a capable little desktop computer, and some alternative distros give you more choices than the default Pi OS. Although we suspect that most Raspberry Pi owners probably simply run the default OS, there are capable alternatives out there and some of them bring advantages over the Pi's native distro. The …
[Author here]
> There are also the specialist distributions such as OSMC for media servers.
Sure there are. My internet radio, which I built myself in lockdown, from a used Pi 3 and a 2nd hand touchscreen, uses one.
(Confession: I can't remember which. I mainly used it for playing BBC 6music in Prague. Now I am back in the British Isles, I just bought a 2nd hand DAB alarm clock and a 2nd hand DAB transistor radio for the office.)
You can use a Pi 4 as a desktop but it requires some patience. The Pi 5, OTOH, is pretty usable as a general-purpose computer. I am just not wildly fond of Raspbian. I prefer Xfce to LXDE, and I preferred LXDE to the Wayland thing in PiOS 5.
I used to run Lubuntu on my first Pi 3, but there is no current Lubuntu for the Pi. (And I don't like LXQt much: broken vertical taskbars.)
So I wanted to try a couple of ready-rolled Xfce distros.
And here we are.
> When it comes to copying onto a card from Linux dd works just fine.
Yeah yeah yeah. "_Real_ programmers use a magnetized needle and a steady hand!"
https://xkcd.com/378/
Go you. Have fun.
I do too sometimes. Over Yule, mildly hungover, working on one of my old laptops, I got 1 letter wrong in the device name and nuked my home partition, with about 2 years' work in a hobby project that, as a result, did not get released in #doscember.
(The drive device names change when booted from USB. >_< )
(P.S. Yes I have backups, but they predated the work in recent days at that point.)
Life's too short. A friendly GUI wrapper makes things not only easier but safer.
Type '#' followed by the destructive command, proof read carefully in case you any words out then home, delete, enter.
That is nothing like good enough for commands that trash entire drives. 'mount' will tell you what is mounted where. 'ls -l /dev/disk/by-label/' will convert persistent names to device names that change after each power cycle/hotplug.
Next go back in time and give all your partitions names with dosfslabel, e2label and so on. The good news is you can now use persistent names that differ by more than a single letter. The bad news is nothing will boot any more because you changed the names. /etc/fstab understands LABEL= for device names. /boot/firmware/cmdline.txt understands root=LABEL=... When the kernel gets upgraded apt has a record of the previous root=... and regenerates /boot/firmware/cmdline.txt with it to foul up the next reboot. Fix that in /etc/default/raspi-firmware
It is still possible to point GUI image editers at the wrong device. Some of them may do some checks to spot if they are aimed in an obviously bad direction. I worry that the authors of such software are not as paranoid as me, that their detection logic has not been tested on installations customised the way I change them and that when they fix some problem it will make the software do something that surprises me next time.
The wonderful thing about command line software is that if anyone proposes a change in behaviour a hord of rabid grey beards waving clue bats will shout 'That will break my scripts' until the proposer takes cover in a deep cave blocked by a cave in.
> ls -l /dev/disk/by-label
Holy cow. I do everything by partition label but I had never seen that snippet. THANKS.
Also, GRUB does not "do" partition labels. I edited /etc/grub.d/10_linux and where it sets LINUX_ROOT_DEVICE, I added
LINUX_ROOT_DEVICE=LABEL="`e2label ${GRUB_DEVICE_BOOT}`"
(YMMV for non-Debian-derived distros)
>> When it comes to copying onto a card from Linux dd works just fine.
[snipped]
> ... I do too sometimes. ... I got 1 letter wrong in the device name and nuked my home partition, with about 2 years' work in a hobby project that, as a result, did not get released in #doscember....
>...A friendly GUI wrapper makes things not only easier but safer...
I fail to see how the GUI is safer or easier.
How is clicking on the item in a list off by one any different or safer than typing in the wrong letter? at least when typing most letters next to each other in the alphabet are NOT next to each other on a keyboard
Jo user has been told that the command line is scary and should never be used, the GUI is always better.
Now it just so happens that Jo user was told this by someone selling a product with a GUI
Sorry Just wrong
GUI or Command line can both be good or bad. For every poor command line you offer I am sure I can find a GUI based thing that is just as bad.
"I fail to see how the GUI is safer or easier."
Haha, fail to see -- interesting choice of words. I use the command line for repetitive actions, but I'm here to offer a defense of the GUI.
If your drop-down list offers two device names differing only by a single letter, then you will *see* them both. And even if hung over, at least one of your brain cells will fire off a thought, which one do I want?
Whereas the command line is more like Colossal Cave, you only *see* what you already know. So either you remember all your device names, or you remember the syntax for listing them, or, oh fuck it, just do it!
The GUI is also likely to include addition data, such as a label or mount point, scraped from whichever parts of /proc, /sys and whatever else we're up to now that linux has vomited it out to.
So GUIs are especially helpful when the system they're protecting you from is intractible and lets you, for example, nuke a partition which is actively mounted.
[Author here]
> Debian includes all the common GUI environments in its standard repo
It does. But that does not remove the one it comes with, and the tools that one comes with.
I don't want any other desktops than the one I have chosen and am using. I don't want 6 text editors, 3 system monitors, 4 calculators, 16 image viewers, etc. I want one, the best one that fits in with my environment. That's the job of a distro builder: pick the best for me, so I don't have to.
Removing this stuff from an installed environment is hazardous. One additional dependency and you remove something critical and the system fails. Been there, done that, many many times.
So, remove the packages you don’t want. Simples!
Having choice is harmless: switching desktop environments is as easy as logging out and logging in again. Give the alternatives a try!
> Removing this stuff from an installed environment is hazardous. One additional
> dependency and you remove something critical and the system fails.
Were you doing forced removals or something stupid like that? Because by default the package manager will refuse to remove something if something else that you are not explicitly removing depends on it.
I have not tried Debian on a 5 yet but here is the nasty surprise if you are used to Raspian:
I use a USB to SDHC bridge, install the image with dd, partition, resize2fs the root partition, mount up and restore a bunch of config files from backups.
I use a real swap partition and its existence prevents Raspian from resizing the root partition itself. Debian works differently. It looks for free space at the end of the SDHC card, finds the space I leave so the wear leveling code has plenty to work with and resizes the root partition over and including the swap partition. Things go down hill from there.
I took me a while to find out what was going on from the boot code in the initrd. I should have read the fantastic manual as it is clearly documented in the Debian Image for Pi documentation. Derivative distributions may use the same do-not-resize detector. Once I got that sorted Debian works fine.
[Author here]
> The Debian Installer offers a “guided” option, where it looks at the existing partitions on all devices and lets you tell it what to use for what, what to use without formatting, and what not to use at all.
Not on an SBC it doesn't, no.
You don't boot from a removable medium and run an installer. That is not how the majority of Arm systems work.
How they work is: you write the installed OS to disk, then you boot the computer from it. It may run a first-time-setup tool and ask a few questions, but what's in that image is what you get.
Which is why it's very important that said image includes all the essentials, and ideally, _nothing more._
It is of course not easy to work out an agreed set of "essentials". That's why there are multiple distros.
More to the point, that's why Ubuntu did so well, in ways Debian folks still can't understand.
Debian says: here are all the bits, choose what you want. If you don't know what you want, go learn.
Ubuntu said: we're the experts and we've picked the best bits for you. All you need, nothing you don't. Ready to run. Enjoy.
And it was free. Other companies had done this and charged for it, but Ubuntu gave it away for nothing.
That is why today there are about 3 Ubuntu users for every Debian user, even though Debian is the most widely-used family of distros by far.
(This is in the West. I suspect but cannot prove that in China, there may be another 10x as many users – maybe more, maybe less – but I think they're mostly using Debian and Ubuntu as well. Some were on CentOS Linux derivatives and it's not yet clear where they will move to.)
> You don't boot from a removable medium and run an installer. That is not how the majority of Arm systems work.
Indeed, and more's the pity. I look forward to the day (maybe?) when more (any?) Linux and BSD Arm distributions have proper installers rather than 'dd' or what have you.
For one thing, I'd like to be able to install my own OS, with my own choices (packages, partitions, etc), without having to build my own image from scratch every time I want to change something. Someone else's curated image isn't necessarily fit for (my) purpose.
There's also the matter of automation or (mostly) hands-off installs. Kickstart, Jumpstart, FAI and so on. Basically the ability to script the native installer to make those aforementioned choices.
And it'd be nice to be able to install the OS without removing the sysdisk, temporarily installing it somewhere, writing the OS image, putting it back in the chassis.
Obviously there are ways to streamline or help out with all these situations, but it's still essentially working around the lack of an installer like the x86 platforms have.
"Ubuntu said: we're the experts and we've picked the best bits for you. All you need, nothing you don't. Ready to run. Enjoy."
For some definition of "best bits", yes.
Your point is well-made, though; essentially that marketing often wins out over technology.
I suspect your other point, intended or not, is that lots of people don't want to think, or choose. That's fine, thankfully there are options for the rest of us, even if 3:1 people don't care.
I bought a pair of Pi 4 last year. One plays music through its jack socket to the hifi (so no upgrades to Pi 5 for that one) and displays on the 4k television. The other has no display and runs my cameras and alarm.
Being a systemd-hater, I installed Devuan on both, although there is no official distro release. (There are unofficial images.) It looks as though MX might have been a more supported option.
I played with MX a little after your review a while back (cheers for that!), and liked it well enough. This was on a desktop system in the lab, so a nice big monitor and keyboard. Thing is, MX is almost *too* pretty. :-)
I think it would've grown on me more if I'd used it longer, but I'm already using (or migrations underway to) Debian servers and Debian+XFCE for desktop/laptop; so while I enjoyed the MX experiment, there's also something to be said for a little consistency in the environment.
That said, I wonder: how does MX get on as a server? I expect it's fine, being in the Debian tree.
I have to admit, the lack of systemD is attractive, perhaps moreso than the pretty parts of the MX desktop. I've made my uncomfortable peace with systemD, which is to say I've learned to drive it well enough for my needs (essentially the 'chkconfig' -ish functions), and disabled the creeping features (timesyncd, resolved, etc.) wherever they don't suit me.
But I can't help the nagging feeling I'm pushing a rock up hill, merely delaying the inevitable squishing when systemD has some new module or unit which you can't turn off.
Seems like MX should stack up much like Debian as a server, but I haven't actually tried it. Perhaps it's worth an investigation after a few more server migrations. If MX is enough of a "drop-in replacement" for Debian server, that's another plus for it.
Do you have a DACpro board? I've just added one to my Pi4, and only just started playing with it. Sounds great so far. Now I just need a bigger SD card, and then I can stick my entire music collection (even in FLAC format) into a reasonably high-fidelity portable jukebox machine the size of a pack of butter, ready to plug into any audio system!
Installing either OpenBSD or FreeBSD is not as hard as what seems to be the general perception out there.
The hardest part might be to make physical install media if needed. In the OpenBSD case, once you have done the "boot bsd.rd" (or simply waited out the short countdown) bit, you only need to come up with a hostname. The rest is basically pressing Enter at any prompt. Basically, the defaults make sense.
For the FreeBSD part, I must admit my last brush with the FreeBSD installer was when I needed to check something while writing a piece on my M2 MacBookAir. Installing FreeBSD/arm64 in a qemu vm was quick and straightforward. Again, mostly pressing Enter at the prompts.
If you don't want to sacrifice your Pi just yet, both OpenBSD and FreeBSD (or for that matter NetBSD) should install and run well on anything reasonable x86-ish you would have lying around.
I like the BSDs for their "seriousness" when compared to the Linux more "bazaar" atmosphere, but have had issues with device drivers, especially for WiFi (on x86) and graphics (x86 and Sun SPARC). The graphical backends to GNU Octave were particularly challenging to get along with iirc. I wonder how that works on Raspberry Pi 5 (is its HW currently somewhat "exotic" to the BSDs?). As suggested in the OP, an ElReg evaluation of the situation could be quite welcome IMHO!
It's still very much a "work in progress" after a quick perusal of the FreeBSD Forums.
Ignore the first few snarky posts, (which is a bit unusual for those forums). Lots of links to patches, hints and clues to get stuff working, but seems to far from "mainstream ready". In fact according to the "official" FreeBSD Pi Wiki, the Pi 4 isn't fully supported yet, notably WiFi and audio "not supported" and the Pi 5 doen't even get a mention.
I don't think it's at the stage to make it worthy of a review yet, still at the tinkering stage, and based on the apparent Pi 4 hardware support, FreeBSD on Pi 5 won't be ready for a long while yet :-)
> Installing either OpenBSD or FreeBSD is not as hard as what seems to be the general perception out there.
Agreed for OpenBSD on a Pi 4, happily running OpenBSD 7.4 here.
But since the article is about Pi 5…
> The more adventurous among us might be tempted to try something like OpenBSD/arm64 (https://www.openbsd.org/arm64.html)
Pi5? Too adventurous for me. Not supported for 7.4, but I expect people with the right skills are working on it in current.
I tend to agree: the BSD installers aren't as "pretty" as the Linux full-blown GUI installers (though comparable to Debian's regular installer IME), but to me they're pretty simple to use. Fairly single-tracked, you can back up a bit if you change your mind, the choices aren't overwhelming (ymmv), and if you're familiar at all with installing computers you can probably accept the defaults and end up with a bootable system.
However, I suspect for some people the perceived difficulty in installing a BSD isn't interacting with the installer itself; rather it's how (or what?) to configure the BSD after it's installed.
Now yes, I expect some folks find parts of the installer daunting, my guess is disk partitioning is the likely usual culprit for folks who don't do it often, or ever.
But after the bits are on the sysdisk, I imagine the experimenting distro-hopper might look at a typical BSD and just think "now what?"
A big chunk of that is probably because "there's nothing to click". And thus the perception that BSD is for servers and people who are comfortable with (even prefer) the commandline.
So my advice to people considering a new OS is give some thought to what you want to do with it before you even download the installation media.
Yes, we have HDMI Audio working on GhostBSD-Arm64 for Raspberry Pi 4B 8Gb or 4Gb or 2Gb. You can play YouTube Videos on your HDMI TV screen without using Headphones. You can build your own FreeBSD kernel from source /usr/src and add these same patch files. https://ghostbsd-arm64.blogspot.com/2024/01/hdmi-audio-sound-patches-into-ghostbsd.html
I posted URL links for those that are interested to read more information about FreeBSD.org/where RPI Arm64 image
https://ghostbsd-arm64.blogspot.com/2023/12/how-to-install-ghostbsd-arm64-into-usb.
html
https://ghostbsd-arm64.blogspot.com/2023/12/zfs-boot-on-root-setup-for-usb-ssd.html
https://twitter.com/l_finster34982
https://bsdnow.tv/545 HDMI Audio sound patches into GhostBSD source code, My blog mentioned in http://BSDnow.tv #545 podcast 12:10-17:05
https://ghostbsd-arm64.blogspot.com/2024/01/hdmi-audio-sound-patches-into-ghostbsd.html?sc=1707523557050#c7947451479546182814 Blog post mentioned in BSDNow #545
https://t.me/c/1228836331/2448 my blog comment
mentioned in Arm Open Source comment. Enjoy
https://forums.FreeBSD.org/threads/raspberry-pi-5-status.91406/post-642889
You can boot FreeBSD on the Pi 5 with: https://github.com/worproject/rpi5-uefi
Display, USB and SD work out-of-the-box.
I just gave that a go and was pleasantly surprised how easy it was.
Downloaded the most recent FreeBSD 15 aarch64 RPI image
Put it onto a microSD card (I used the Raspberry Pi Imager on my mac, but I assume that dd would do the same)
Tried booting that, didn't work, as expected
Got out a USB flash drive, download the firmware image from the rpi5-uefi githib repo (the zip file from the link below "2. Download the firmware image")
Extracted the 3 files from the zip file to the USB drive
Plugged in the USB drive and booted.
Presto, FreeBSD.
OK, no ethernet, no wifi, fan at full speed.
https://forums.FreeBSD.org/threads/raspberry-pi-5-status.91406/post-641494 Raspberry Pi 5 Status post
https://forums.freebsd.org/forums/embedded.11/ FreeBSD Embedded Forums posts
https://forums.raspberrypi.com/viewforum.php?f=85 FreeBSD Operating System on Raspberry Pi forums posts
https://forums.raspberrypi.com/viewtopic.php?t=343233 My Entry about booting FreeBSD on Raspberry Pi 4B hardware.
IME FreeBSD support is pretty solid on rpi4, but whether you decide to try it depends largely on what you want to use it for.
E.g. I ran FreeBSD 13 on my rpi4 as a small server: DNS, SMTP, NTP, and that was about it. Because my out-of-band management uses serial consoles, I also installed a Serial HAT and it worked well enough for most things. There's an annoying problem with stray chars sometimes popping up during reboot (possibly a u-boot problem), which the FreeBSD loader interprets as an interrupt and waits for you to tell it to carry on. But aside from that, for actual serial console troubleshooting and maintenance activities, it was fine.
OTOH if you're looking to play with fun projects, e.g. hosting a camera or acting as the remote control brains in some LEGO kit you've built or something, Linux may still be a better option for rpi. Especially if wireless is part of your plan: afaik the rpi4 wireless is not supported yet.
Most distros are grim. Their "base" install is basically just a random smattering of packages and whatever cruft they pull in as arbitrary dependencies.
Basically grab the Raspberry Pi OS kernel (vmlinuz, /lib/firemware /lib/modules) and use something like dnf or debootstrap (minbase) to bootstrap your own install. This attempts to keep the general GNU clutter to a minimum.
It still feels like a random mess though. UNIX definitely has the edge here in that the shite that is on disk is *meant* to be there.
Since mx Linux was mentioned here a couple of times, I just want to note that I've been checking out mx Linux kde (for a full size PC), since the recent kde neon rollout of plasma 6 has shaken my trust some in neon, such that I'm holding off on updating my main PCs (upgrade to 6 included in updates presented as recommended security updates on the User Edition, not the Testing, Unstable or Dev editions, caused malfunctions and gui issues (on my testing PC), some of which were quickly corrected). I've installed MX Linux kde on a test machine. Light usage was pretty uneventful for about a week, but then the panel started disappearing from my desktop. I do like that mx includes a newer version of Timeshift than is available in the repo used by kde neon. MX Linux has a dev identified as anticapilista, and I may not be able to get comfortable using mx Linux to do work for clients who are pursuing capitalistic endeavors. Didn't want to distro-hop after 4 years with neon, but looking for insurance.
[Author here]
Yup, my Pi 400 mainly runs RISC OS Direct. It's a shame that it can't use the other CPU cores, although the rumour is that wifi support is in fact coming soon.
Years ago, I proposed a hack for SMP support: port RISC OS to run inside Xen. Run a master copy in dom0, and then you can multiple other "worker" instances under the master one. Needs some cleverness in communications between them, and the worker instances must cope with being run in arbitrary-sized windows... but hey, how hard could it be? :-D
With regards using the Raspberry Pi imager with other operating systems, I've used it with Ubuntu on a Pi4 for a number of years no problems at all. You just pick Ubuntu as the OS you want to install and it will download and install it on the card for you. About a dozen different versions of Ubuntu are available for the Pi, and they were one of the very earliest of alternative OSes available for it.
The imager also offers Apertis (some sort of Debian based embedded OS) and Risc OS Pi. These are in addition to the various versions of Raspberry Pi OS and application specific OSs (games, media, etc.).
I've used Ubuntu for some years as a server OS for testing ARM software that I have written. It's always worked just fine. I originally picked Ubuntu because there wasn't an official 64 bit version of Raspberry Pi OS at that time, but there was one for Ubuntu.
I also have a spare SD card set up with a desktop version of Ubuntu that I used for a backup in case my PC died. During the pandemic I relied on it for a few days while waiting for a spare part for my PC, and found that a Pi4 was adequate for normal desktop use provided I wasn't trying to watch full screen video over Youtube. The latter issue appears to have been due to GPU limitations on the Pi4. Ubuntu desktop (Gnome) apps though worked just fine, and I didn't notice any difference from using an x86 PC aside from that the Pi booted up much faster than any PC that I've seen.
If your Pi has 8GB of RAM (I haven't tested with 4GB), I don't see any technical reason to use a cut down GUI as opposed to standard (Gnome based) Ubuntu GUI. The Raspberry Pi OS doesn't seem any faster than standard Ubuntu in terms of GUI performance. Of course if you want to play around with other things then there's nothing wrong with that.
> I don't see any technical reason to use a cut down GUI as opposed to standard (Gnome based) Ubuntu GUI.
OK, two things here.
Firstly, I strenously object to that grossly unfair and inaccurate "cut down GUI" nonsense. There is nothing "cut down" about Xfce, or indeed Budgie, MATE, or multiple others. They are not "cut down". You have your history back-asswards.
Xfce is older than KDE, which is itself older than GNOME.
These other desktops are not "cut down". They are older, better-written, more functional, more flexible, and in general better. They are smaller because of tighter code.
Setting aside my professional hat for a moment: in fact, the reverse is true.
GNOME 3 totally rebooted the project, partly out of a desire to be less Microsoft-like and partly due to a -- largely failed -- effort to build a version for touchscreen devices.
GNOME Shell is largely unlike older versions, is less customisable, has less standard UI, less functionality, less theming support, and indeed, less of pretty much anything useful -- except code. There is a lot of that, because they rewrote the entire damned shebang in smegging Javascript, possibly the worst possible choice of language. Then they reimplemented every separate accessory and supplementary app they could, because it's Red Hat sponsored project, and as such, it rejects everything that was Not Invented Here.
I want by UI fast, responsive, and I also want it small, so it leaves more resources for *my apps,* thank you. For that, on Unix, I want it in a compiled language that generates native code, not some gigantic interpreted blob that that a JIT engine desperately tries to make quicker.
[*wanders off grumbling "'cut down' my backside... bloody whippersnappers"*]
P.S. You're missing the point about the imager, as well. I am talking about OSes it doesn't know about and cannot download for you: so, pointing it to `.img` files you downloaded yourself.
You're using a lot of words to simply object to me calling the Raspberry Pi OS GUI "cut down". It's based on a modified LXDE, the latter of which is specifically designed for low RAM usage. This was selected in order to run adequately on a 1GB Pi.
I made no mention of Xfce, Budgie, MATE, or KDE, because I haven't tried any of those on a Raspberry Pi. I can't speak about Xfce as I'm not as familiar with it, but Budgie, MATE, or KDE are not designed for low RAM usage so I don't know why you would think I was even referring to them by implication. They are all relatively similar to Gnome in terms of features and size.
If you like any of those better than Gnome, then that's fine. The point which was being made is that if anyone is using an 8GB Pi (I haven't tried a 4GB model), then there is no technical reason why an OS which uses Gnome can't be on the list of options. The Pi seems to have the horsepower to run it just fine.
Someone else will have to speak with respect to Xfce, Budgie, MATE, or KDE, because I haven't tried any of them on my Raspberry Pi hardware. Someone else again will have to speak with respect to the 4GB models, as I don't have one and so haven't tested them.
My previous comments have been based on my experience running Ubuntu on a Pi4. I recently acquired a Pi5. After my previous post on this subject I was inspired to install Ubuntu 23.10 on a spare SD card (using the Raspberry Pi imager) and try it in the Pi5. It ran fine, with good graphics performance running the standard Ubuntu version of Gnome.
I also tried playing a Youtube video on full screen (1920 x 1080) and it ran just fine, with no glitches or visible dropped frames.
To reiterate my point, whatever Linux OS you decide to run, the Raspberry Pi 5 with 8GB of RAM will likely have more than enough CPU and GPU performance to run nearly any mainstream Linux distro which has a Raspberry Pi ARM version, and it will be indistinguishable from running it on an x86 PC.
If you're experimenting with other OS'es on a Pi5, you may also be the type that has bought an NVMe HAT to use an NVMe drive. If you do, make sure you use a very recent kernel or Raspbian (which uses a 6.1 kernel). It seems the 6.5 kernel has a bug which meant that drives were not getting enumerated and initialised correctly at boot time.
Symptoms are that when booting Raspbian from an SD card the NVMe drive was recognised, but (until earlier this week), booting Ubuntu 23.10 and your drive was not recognised. Ubuntu 23.10 with the latest kernel finally got the fix, but some of the other distros listed here may not (yet) have it.
The "out of the box experience" should always be a spartan desktop and certainly not be denigrated because that's what you get. After all, if I want go buy a new office desk, I don't want it covered with other peoples shit. I want to put my shit on it, where I want it and when I want it, not have to start by tidying it up and dumping someone else's choice of shit :-)
Forcing a "look and feel" and the same specific icons/gadgets/tools on every users desktop in a "one size fits all" mode of thinking with minimal user choice is what we get from MS, Apple and every "smart" phone maker out there! :-p
EL9 wiki.almalinux.org installs and runs on an 8G Pi5. Have to fiddle with images and sd cards but after installing on a usb ssd drive AL9 arm works about the same as installing AL9 x86_64 on a lower end or older x86 notebook.
Useful if you work with (RH)EL or everything else is EL.
I haven't had a chance to really test the Pi5 AL9 install as I have been replacing Cent0S and RHEL installs with AL8.9. Decided to run any RHEL developer installs in VMs as required.
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
