SBC OS Choices & Opinions

Some notes on Slackware, Devuan, Armbian and other options for Single Board ARM Computers. SBCs.

Slackware

First off, Slackware does install easily and does work for basic browsing and office type stuff. It plays videos with sound fine too. I generally like the “old school familiar” nature of it.

That said, it is technically limited and things are just a bit too far out of date for tech work. Some are little things, like the “vi” editor (renamed “vim” in Linux but still launched with the ‘vi’ command). You can normally “yank” a set of lines into a buffer and spit them back out again. This is done with a “number of lines”, the “buffer name”, and the command to pull the lines. Then in another position in the file, you can stuff them back. Say you wanted to move 6 lines from one place to another. You could type: 6″ad or 6″ay (and least I think that’s what my fingers do… I’ve been using this editor for about 38 years and it happens in the brain stem now…) which says “Take 6 lines and using the register “a” delete them into that register” or in the case of ‘y’ yank a copy into that register. There’s a whole bunch of registers named by letter, but I’ve rarely used more than 3 at one time. Then you put your cursor where you want the lines to go and do: “ap which says take register “a” and put the contents here.

You can see why vi commands are called “terse” and also how much can be done with minimal keystrokes and mostly on the home row. It’s a very fast editor to use…

Well, the Slackware vi seems to work fine for ONE line, but you can’t give it a number of lines. OK, I still got the lines moved, but moving 20 lines that way is 20 times more work.

Similarly, the lack of mysql on the ARM port is an issue. There are some other bits that annoy just a little too much, too.

SO, Ok, what’s that mean for me and my usage?

There’s probably some “package” somewhere with a newer better “vi” and a working mysql. But that’s a layer of work that is otherwise not needed on other platforms. But I have a soft spot for Slackware. I’ve had it around in one form or another since about 1985? or so. So I’ll keep using it, on and off, on some computers. I do need to get a little better at managing and installing packages not in the install group. I want to keep up my skill level with it; especially as it is one of the few Non-SystemD(mented) distributions out there. So I’ll use it “sometimes”.

Devuan

For main line use, now that I’ve gotten Devuan 2.0 working on the XU4 (figured out what I was missing…), I’m going back to / sticking with Devuan.

I found the folks doing exotic ports to non-supported hardware. They have a LOT of other boards and chips they are using. Often via the same kind of thing I did. Find the dtb (device tree bundle) from some other distribution, match a kernel, add some modules and firmware; then graft on the Devuan Userland. I’m OK with that.

For most supported boards, and most folks, Devuan installs easily and works well. It is FAR easier to learn how to manage and add packages, do package builds, than Gentoo.

So, if it works, use Devuan. If it doesn’t, try the unsupported farm approach to roll your own. But what then?

Armbian

Frankly, I’m running Armbian on 3 of my SBCs. Even though it does have SystemD in it, they hide it well. Generally it just installs easily and runs well.

Only thing that bit me really hard with SystemD was that bug where an /etc/fstab entry with “noauto 0 0” that ought to cause No Bad Thing as it says “do not try to automatically mount this file system and do not do an fsck on it at boot time” caused systems to hang in the boot with a dead black screen IF the disk was not physically plugged in (mostly Ubuntu did this IIRC, but Debian too and maybe Armbian) and I thought the hardware was dead. I ALMOST tossed out 2 SBCs because of that. They lived in my junk box for a year before the 3rd board to do this had me catch clue. The Odroid N2 where I had 2 OS images installed, one on the uSD card, one on the mmc card, and when one failed, the other still worked. “Whack with the clue stick” happened then… and I recovered the 2 “dead” boards. So, avoid that, it will work; and:

Armbian works just fine for almost everything. Debian based, it has the simple software and package management of Debian. It is also a clean port, well matched to small hardware SBCs, and with plenty of polish done on rough bits (like that change of networking from eth0 to en{random junk MAC address stuff} that breaks network access on some systems. It just works on Armbian boot). It also does a nice hand holding install that sets your locale at first boot (something other releases have you fight with). So for “first bring up” of a board, I’ll tend to use Armbian. If no better OS presents itself, I’ll just leave it on the board until the better alternative comes along. As long as you aren’t doing a lot of stuff like moving disks around (fstab changes) or lots of systems admin stuff, you will mostly not know SystemD is there.

I’m presently (still) running Armbian on the Odroid N2 (since it is relatively new and not many ports to it exist, Odroid being a pain with signed boot loaders – but probably close to time to look again…), the Orange Pi One boards (since it’s the H3 processor and most folks seem to not care to support it, going for the H6 boards instead – but at about $15 for the board, nice as a little utility server thing…) and I’ve got a clean port of it to the Odroid XU4 that I use when I’ve managed to screw up my regular chips and need a recovery system ;-) The N2 came with Ubuntu on the mmc card, and it is still there. I’m set up to dual boot, so sometimes boot that one. I just find Ubuntu very fat and a bit aesthetically not my style. I mean, really, puke green everything? ;-)

But with my new Devuan skill at “mix and match” kernel/dtb/modules vs userland, well, I’m likely going to get Devuan 2.0 running on them, too. It looks like some folks have already done it in the ARM forum space.

What else?

Gentoo

Gentoo continues to be a technical PITA / Challenge for me. Yeah, I got it running on the XU4, but I’m still fighting “use” flags to get LXDE or XFCE to build / run. I’m going to keep on whacking at it, but lower priority, until I CAN make it “go”. Why? Because it is a great, efficient and up to date distribution that lets you do whatever you want, without SystemD (or with if you like). Also, source code being the method of build, you WILL have all the source code needed to make that OS forever. So as long term insurance, it is a thing I want to have. But it isn’t for anyone who does not have Systems Programmer chops. You ARE building the whole system from source code and you DO need to know what all the bits are doing and you MUST match the right dependencies on everything, by hand, with USE flags and all.

But it is a nice system once you get it to build ;-)

What Not?

What I’m not doing is Debian, Ubuntu, Red Hat (Fedora, whatever…), Raspbian, Puppy, etc. etc.

Why? Varies by system. For most of them, it is the presence of SystemD. It is “just wrong”. It also caused me several bits of gratuitous and unforgivable pain in trying to live with it for a few years. (Those mystery “dead” boards, for example).

For Debian, the Devuan derivative is everything Debian was without SystemD, so I’m just going to run Devuan and / or do the port of Devuan if possible.

Raspbian, as a Debian flavor, is in the same bucket as Debian. Why run it when a very nice Devuan port exists?

For Ubuntu, it is a Debian that’s been fattened up and somewhat junked up. Please, if you LOVE Ubuntu, I’m not calling you names are saying your kid is ugly. I like fast efficient light weight distributions without the distraction of things like animated desktops, translucent and active panels, things “snapping” to full screen if you drag to a margin, and such. Added “hand holdy” gui interfaces to administrative tasks just get in the way of my decades of knowing just what to edit and just what to type into the config file. Besides, there’s that green thing ;-) (I changed mine to blue… so yeah, I know you can do that ;-) Then, Canonical has been known to do things not so nice to user privacy like gather data from the Unity Desktop IIRC. I’m also more fond of stuff where I get control, not them.

Red Hat has become evil. They are pushing to change Linux into something they “own” in the sense of control. They have created and shoved down our collective throats all manner of bad ideas. SystemD just being the most recent and worst one. For a while, I was running CentOS, the data center oriented Scientific Programming oriented build of theirs, but the last few installs of it were obnoxious about insisting I MUST do things THEIR WAY. Down to file system layouts used and “security” features and more. Sorry, but just too corporate control freakish and with abuse of my first love “The Unix Way”. (Do one small thing, and do it very well.)

Puppy is a distribution I like and sometimes do run. But again it has a layer of “their way” in between me and the “edit the file to config” admin that’s built into my fingers. It also has a bit too much “crayola look” to the desktop for may tastes. It is very nice as a quick way to configure and set up an “appliance” as they have several specific build clusters you can just pick off a menu to do a particular job. It’s also very nice for folks new to Linux as an easy menu driven system installation / management. I’ve run it before sometimes, and I’ll run it again from time to time, but never much or for long. Frankly, a lot of the “puppy jokes” and jargon just wears on me too much. There’s a point where “cutesy” becomes treacley …

There are dozens, hundreds, of other distributions. Most of them derive from Debian, Red Hat, or Slackware; created as somewhat more full installations with particular sets of windows and applications already installed. Since I do my own choices for those things, I don’t feel the need to use their choices and then STILL have to roll my own selections into it. This, BTW, includes the various Ubuntu spins (Mint, etc.). It is just a Debian with an Ubuntu overlay with a particular set of package in it. So why go there if the package mix is not a feature to me? (It can, and is, a great feature for a lot of folks. If you love Ubuntu Mint, great! Use it. Enjoy it. It just isn’t for me.)

There are some others I’ll keep watching. Void, for example, has potential. Using a new C compiler (Clang instead of Gnu C) and using a new set of libraries (Musl) it could end up a lot faster, more secure, and cleaner. BUT, most of the new interesting ports are very PC / Intel focused. Very little ARM chip support. This makes a lot of sense, as you can treat Intel as mostly 1 build type (AMD64) or at most 2 (add x86); where the ARM world is dozens of different chips since any licensee can make special layouts. A startup with limited staff must focus on the largest market segment with the minimal labor cost to shipping. I get it. So I wait…

But that also means the biggest chunk of ALL the “other builds” either don’t work on ARM, or only work on one or two ARM boards, or have SystemD in them. So not useful for me on a heterogeneous cluster of variety ARM SBCs. I’ll still look them over from time to time, but it’s mostly, from my point of view, a wasteland of Intel Focus.

Honorable Mention for LFS

I have built Linux From Scratch on the Raspberry Pi (some years ago). It’s a nice project to get your Systems Programming skills up. It is fun to do. It is fulfilling. But… In order to get all the parts to play well together, they checkpoint at moments in time (for the book…). This means that when you want the latest and greatest “foo”, you are back in Dependency Hell and on your own. No package manager sorting it out for you (kind of like the Slackware philosophy… or wrastling Gentoo USE flags ;-)

I do recommend doing it at least once for any budding Systems Programmer Wannabe out there. But it is really more of an educational experience than it is a production system. If you are going to be building a production system for daily use, you might as well take on Slackware package dependency management, or get your Gentoo chops. Or just take the easier road and use Debian / Devuan / Armbian / Ubuntu and work your way up to it.

I’m glad someone is keeping alive the 1980s way of “everything from source from the creator”, but really, it’s likely better if you have a few people working as a team to make it all “just right” for a production system. That is, if you want to do anything production with it and beyond just learning. It’s like making your own car from parts in the garage. Yes, you can do it. Yes, lots of fun “kit cars” exist. But you are not going to crank out cars like Honda does it. It’s a fun hobby, but not a production operation.

In Conclusion

I’m going to push toward an All Devuan shop as much as possible. Doing a bastard mix integration of Devuan Userland with Armbian or Ubuntu derived kernel, dtb, modules, firmware as needed. This is “enough control” on “enough boards” to get a “big enough” homogeneous software environment on heterogeneous SBCs for a big build cluster / climate data processing station.

To the extent I can’t make Devuan “go”, some SBCs will run Armbian and the occasional Slackware.

Other stuff will be “played with” but not in use for “production” or as my “Daily Driver” system(s). Gentoo will be my major technical growth vehicle, but some effort will be on Slackware package management skills.

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits. Bookmark the permalink.

12 Responses to SBC OS Choices & Opinions

  1. Simon Derricutt says:

    Thanks EM. These days I want the machine to just work and to not have to mess around or to learn different ways to do what my fingers have been doing without needing much effort, so mostly I’ve been just installing some mainstream Linux on an x86 box. Some of the stuff I do still needs some form of Windoze, too, rather than Wine, so I’ve needed to dual-boot for a long time to get access to Windoze when I can’t find a Linux version that works sufficiently well.

    As such, this potted comparison saves me a lot of time in going through the various offerings myself, and points me in the right direction. I’ve been trying to remember when I first installed Slackware on my machine, since it was the first Linux version I tried, somewhere in the early 90s I think. Bit of a hassle at the time getting the X configuration file matched up to what I actually was using, and no real hand-holding on getting all the .rc files sorted, either.

    With Gentoo, though you’ll have the sources “for ever”, you need the compiler that matches those sources too, so you could still have difficulty if you didn’t already have a machine running that vintage of OS. In computing, all stuff has a half-life, and suffers from some sort of bit-rot. Use it or lose it…. Given the rate of hardware change, also, getting it to work on newer kit would likely need new drivers and maybe even adjustments for the machine code used by the target machine, since of course that’s been evolving too and you might end up with something like a graphics processor with a huge number of cores. Possibly, therefore, the selling-point of Gentoo isn’t as valid as they suggest. It’s just a purist idea that will likely be negated by the reality of future changes in the way things happen in hardware. I know there’s a new memory architecture coming along soon that will speed things up a lot, but I don’t expect the old device drivers will just run that without modification/rewrite.

    The main advantage of Linux is that it can’t be remotely disabled, whereas Windoze, Android, and the Apple OS can be. The advantage of having the source-code is that you can check it for exploits, but with that sort of size of code I suspect very few end-users will do that, but instead trust the (unpaid) programmers to have checked their bit of it. That remote control problem is also a reason to use ARM at the moment rather than Intel or AMD, but in reality there could be *something* secretly inserted in an ARM chip and you’d never know until someone found it. Maybe an undocumented instruction code that opens up a can of worms. Even the old Z80 chip had an officially undocumented code that allowed you to use the IY register as two separately-addressable 8-bit registers. I even used that in one bit of code because, though that cost an extra microsecond, it was cheaper than a push/pop.

    Though I’ve personally had few problems with either System D or with the Windoze Registry, the principle of them is wrong in that it gives a wide attack front that is more easily corrupted and needs a lot of maintenance (even though we don’t see that happening). Nicer to not have either kludge, and to a small thing well. Looks like Devuan is in my future.

  2. hubersn says:

    You promised “OS”, but it was just the usual Linux distribution rundown. Seems to be all the “alternatives” we get these days.

  3. E.M.Smith says:

    @hubersn:

    OS is Operating System. Linux distributions ARE Operating Systems.

    Unless you are running Intel PC hardware, your OS choices are almost entirely Linux. Android, btw, is a Linux kernel but replaces the GNU Userland, so still a Linux. AFAIK, Plan 9 is the other non-Linux ouf there, but on very limited plarforms. Micro$oft Windows has tried to make it in the ARM world, but mostly failed. (And I refuse to run it anyway.)

    So basically, there isn’t any non-Linux OS worth mention, AFAIK.

    @Simon:

    That was the idea. Summarize my recent (year?) of wandering in the desert….

    On Intel hardware, Devuan is slick, easy, robust and reliable. I’m running it on one AND64 box and one x86, IIRC. It is the #1 choice, IMHO.

    Right behind that, I’d put Void in the “investigate” hopper. A year ago it installed easy and was damn fast while theoretically more secure. Musl libraries and other hardening. I really liked it, but no ARM version, so I figured it would be a while for me… https://voidlinux.org

    The Void (Linux) distribution
    Void is a general purpose operating system, based on the monolithic Linux kernel. Its package system allows you to quickly install, update and remove software; software is provided in binary packages or can be built directly from sources with the help of the XBPS source packages collection.

    It is available for a variety of platforms. Software packages can be built natively or cross compiled through the XBPS source packages collection.

    Follow us on Twitter, visit the #voidlinux IRC channel on irc.freenode.net, and join the Void Linux subreddit.

    Visit the Void build server console for package build status updates.

    Contribute to the Void Linux project by adding and updating packages and extending the documentation. More information can be found in the Handbook.
    […]
    LibreSSL
    We were the first distribution to switch to LibreSSL by default, replacing OpenSSL.

    Due to the Heartbleed fiasco, we believe that the OpenBSD project has qualified and pro-active developers to provide a more secure alternative.

    Stable rolling release
    Void focuses on stability, rather than on being bleeding-edge. Install once, update routinely and safely.

    Thanks to our continuous build system, new software is built into binary packages as soon as the changes are pushed to the void-packages repository.

    runit
    We use runit as the init system and service supervisor.

    runit is a simple and effective approach to initialize the system with reliable service supervision. Refer to the Void Handbook for an introduction.

  4. Mordineus says:

    Can I mention that there are some other viable options out there? The BSDs are still very viable. FreeBSD, OpenBSD even NetBSD all have their place.

    Oh and none of them use SystemD. :)

  5. E.M.Smith says:

    Gee.. more Void ARM images now:
    https://voidlinux.org/download/#download-ready-to-boot-images-for-arm

    Download ready to boot images for ARM
    There are ready to boot images for several ARM devices. These images can be written onto an SD card (i.e. using dd) and they allow you to have a ready to boot system. These images are prepared for 2GB SD cards. Alternatively, use the rootfs tarballs if you want to customize the partitions and filesystems.

    These images are named void-DEVICE[-musl]-BUILD_DATE.img.xz, where

    DEVICE is the device for which the image was built, which can be:
    beaglebone: BeagleBone/BeagleBone Black (ARMv7, hard float)
    cubieboard2: Cubieboard2 (ARMv7, hard float)
    odroid-c2: Odroid U2/U3 (ARMv7, hard float)
    rpi: Raspberry Pi and Raspberry Pi Zero (ARMv6, hard float)
    rpi2: Raspberry Pi 2 (ARMv7, hard float)
    rpi3: Raspberry Pi 3 (AARCH64, hard float)
    usbarmory: USB Armory (ARMv7, hard float)
    -musl is optional and indicates that the image uses the musl libc instead of glibc

    I think I’m going to try the RPi or C2 images. It also lists U2 and U3 so maybe all three?

    I’m happy with Devuan, but as an investigation instead of Gentoo… maybe.

  6. E.M.Smith says:

    @Mordineus:

    OMG! I left out the BSDs! (My first *Nix Love of all time…)

    I have both FreeBSD and NetBSD working to various degrees on various boards. My only real complaint about them is that they are sometimes a bit of a PITA to get a windows environment going and that the boards supported are more sporadic.

    OK, my position on the BSDs:

    IF they worked across a wider number of my SBCs, and were a bit easier to get going with X, I’d likely be running them everywhere. I’m a little more partial to FreeBSD, but NetBSD seems fine too. I’ve not run OpenBSD much so don’t have strong opinions about it.

    In my “wander in the desert” I did load both FreeBSD and NetBSD on a couple of BSDs. Generally found them a bit too obtuse for Noobs to use (though fine for me ;-) and the only reason I’m not using it Right Now for this posting is that it didn’t run on most of my boards, or was a PITA to get windows going on the ones I used most. They also don’t support EXT3 or EXT4 file systems, so I’d have to convert about 40 TB of disk space ;-) (Or just put most of it on an NFS file server ;-)

    How could I forget the BSDs… Must be the wine from last night ;-)

  7. E.M.Smith says:

    Oh, and FWIW, I’m moving about 62 GB of system images from one USB 3.0 disk to another USB 3.0 disk using the RockPro64. It is going a lot slower than I remember it going on the XU4.

    At this point, my suspicions is that Slackware is not very efficient for disk transfers on this hardware. I suppose it is possible it is a hardware limit, but…

    So sometime or other I’m going to do a Disk Speed Benchmark on the various HW / SW combos.

    I’m just going to let this one run to completion, but it is a LOT slower than the XU4 under Devuan I think…

  8. Steven Fraser says:

    @EM: You are probably aware, but I will say anyway… IBM owns Red Hat… assume accordingly.

  9. E.M.Smith says:

    well, about 19 hour later… the file move ended. That’s a pathetic 9/10 of a MB / Second.

    That’s horrible.

    OK, I’m going to do some speed tests with the “mv” command that I used for this, as well as tar and dd, and from SD card to disk as well as disk to disk. Just to figure out where the blockage happens. SD lets me go from the SD slot to the USB 3.0 port (so I can see if it is some kind of contention issue with 2 disks in USB ports), different commands will show if it is the mv command that’s just daft. Etc.

    But, at this point, using the RockPro64 with Slackware for handling large data volumes looks hobbled. Add in that the vi editor is a bit crippled and it just isn’t useful for my kind of day to day systems work. Now I’m concerned that overall USB speed might have problems. Sigh.

    Oh Well… It does OK with a browser and running videos… but a Raspberry Pi M3 does OK and a Pi M4 ought to be great… so “go figure”.

    Oh, and I do have an alternative OS chips (Armbian IIRC) so I can do a straight up OS A/B compare on data moves too.

  10. E.M.Smith says:

    Make a smaller test blob:

    bash-5.0$ dd if=/dev/zero of=TESTMB bs=1K count=100000
    100000+0 records in
    100000+0 records out
    102400000 bytes (102 MB, 98 MiB) copied, 1.35876 s, 75.4 MB/s
    

    Where can I move it?

    102400000 bytes (102 MB, 98 MiB) copied, 1.35876 s, 75.4 MB/s
    bash-5.0$ df
    Filesystem      1K-blocks       Used  Available Use% Mounted on
    /dev/root        14269840    8764516    5488940  62% /
    devtmpfs          1017376          0    1017376   0% /dev
    tmpfs               32768        480      32288   2% /run
    shm               1017952      64116     953836   7% /dev/shm
    cgroup_root          8192          0       8192   0% /sys/fs/cgroup
    tmpfs             2097152         12    2097140   1% /tmp
    /dev/sda12      103081248   16580196   81258172  17% /SG2/home
    /dev/sda14     1757578792  112597564 1555694676   7% /SG2/ext
    /dev/sdc1      7749328292 5342902780 2015829112  73% /Arc/ext
    

    So /SG2 is a 2 GB Seagate, /Arc is an 8 GB archive WD MyBook, /tmp is a memory resident compressed tmpfs, and / is the uSD card in that slot.

    First I’ll do a “dd” and compare that to a “mv”.

    bash-5.0$ pwd
    /Arc/ext/System_Backups/XU4
    bash-5.0$ time dd bs=10M if=TESTMB of=/tmp/TESTMB
    9+1 records in
    9+1 records out
    102400000 bytes (102 MB, 98 MiB) copied, 0.391533 s, 262 MB/s
    
    real	0m0.414s
    user	0m0.012s
    sys	0m0.400s
    

    Well, it looks like reading the USB 3.0 disk isn’t the problem ;-) 262 MB/s is nice.

    bash-5.0$ time dd bs=10M of=/SG2/ext/TESTMB if=/tmp/TESTMB
    9+1 records in
    9+1 records out
    102400000 bytes (102 MB, 98 MiB) copied, 2.11453 s, 48.4 MB/s
    
    real	0m2.350s
    user	0m0.004s
    sys	0m0.992s
    

    Writing to USB disk is a bit slower, but 48 MB/s is still about what I’d expect.

    A “mv” to /tmp is about the same speed as the dd was:

    bash-5.0$ time mv /SG2/ext/TESTMB /tmp/TESTMB 
    
    real	0m0.498s
    user	0m0.016s
    sys	0m0.416s
    bash-5.0$ ls -l /SG2/ext/TESTMB /tmp/TESTMB
    ls: cannot access '/SG2/ext/TESTMB': No such file or directory
    -rw-r--r-- 1 ems ems 102400000 Oct 17 18:06 /tmp/TESTMB
    

    Copy “cp” is almost as fast:

    bash-5.0$ time cp /tmp/TESTMB /SG2/ext
    
    real	0m0.688s
    user	0m0.008s
    sys	0m0.672s
    

    And a move?

    bash-5.0$ time mv /SG2/ext/TESTMB /Arc/ext/JUNK/
    
    real	0m0.904s
    user	0m0.012s
    sys	0m0.860s
    

    Well a move between two real disks is slower, but it looks like I need a bigger test case to make the problem show up strongly. At this size, and having just one file, there’s only one inode to hold in memory and all the blocks locations can be memory resident too.

    My speculation at this point is that “mv” is less efficient, and likely does more moves of little bits where there’s more lookups of block addresses, so really really big files might cause more “seek on the disk” activity as it moved between inode location trees and picking up data blocks.

    But it will take a bigger test case and longer testing to check that. So something for later.

  11. E.M.Smith says:

    Slackware on the RockPro64 seems to have some kind of scheduler or memory management issue. I’ve had it lock up a couple of times. This was one was after opening just a few more tabs of YouTube videos. Far less than in other Linux distributions.

    So it starts getting slow. Like it is waiting for swap or something, but swap isn’t doing much (almost nothing at all on swap). Then you pop another tab open, maybe the 12th? and it just goes to dead halt on the display and mouse. You can’t move the cursor, clicking doesn’t do anything, and it has active panels like ‘htop’ fail to display the stuff you know must be changing.

    I didn’t try logging in remotely with ssh. I was trying to post a time relevant comment so just moved to a different machine in another room. Then came back and this was still hung, so just power-failed it.

    I’ve had this happen a few times, mostly with browser load. But this, along with the other problems, has moved me off of Slackware (at least on this hardware). I don’t know that it’s worth my time trying to “fix it”. Armbian “just works” so I’m back on an Armbian install from about a year ago (and got to update it ;-)

    Now I need to decide just how much I care about further characterizing the mv speed issue and lock-up issue. I’m tending toward “not at all”.

    FWIW, I’ve downloaded the Void Linux install images for the 3 Pi generations that I have, the Odroid C2, and the Generic Tarballs for v7 and v8. When I’m bored “some day” I’ll try tossing a copy of it on one of my SBCs and see what it’s like these days. I’m especially interested in the smaller, and supposedly both faster and more secure, musl based libraries. (Though note that they said “locales” was not yet working in them… so I guess everything is just forced to one place / kb layout?) It does have glibc library versions and I nabbed both, so can compare.

    For now, I’m mostly looking at just using an Armbian base image (for kernel, kernel modules, dtb, firmware, etc. perhaps headers) and layering on a Devuan Userland. (As I did for the XU4 already.) Given that the Forum has folks who have done this for the major SBCs I have that are not already on the supported list, it means I can get to a uniform distribution / level across the majority of my hardware. And one that I really like. Just “Some assembly required”…

    I’ll keep sporadically “poking the bear” of Distro Hopping to check out what else is going on; but I really want to get things all updated and in sync and get back to a nice distcc build environment with a working sql / python for data munging. I think the best way to do that is a uniform Devuan code base. I can already get there on all the Pi boards, the Odroids, and with some work, the Rock64 / Pine64 / RockPro64 set.

    The implication of this being that, once again, Slackware goes back in the ice box for a while…

Anything to say?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.