Okay so I just tried out the newer xlibre repo and re-made the system on a standard Devuan mini as before. A few issues:

1. Now the video artifacts are back whereas they were gone from yesterday's iso using the old repo. Not many programs on the mini to test it, but the Mate system monitor shows it clearly, lines appear randomly while changing tabs in it.

2. I still don't know why backports was mandatory, making the swap pulled NOTHING from it.

3. The amdgpu package would not install, it's listed in Synaptic with all the details now, but when you try to mark it for install a message pops up that while the listing is there, there's no actual package attached to it.

I do run AMD hardware, so I wonder if the above amdgpu package might fix the blinkies.

EDIT: Okay so it wants backports for 3 mesa packages:

1. mesa dev package, why it needs this I don't know, but it pulls in a metric-ton of other dev packages.

2. mesa vulkan, this one seemed okay to use the backports version.

3. mesa-libgallium, this is a complete dealbreaker, attempting to use the backports version made it want to uninstall the entirety of the Mate desktop, most of it's programs, and indeed also the entirety of xlibre and xorg packages remaining on the system. It literally breaks everything. Not even sure why this would be in backports, it seems destructive to excalibur.

Thank you @viptux for clarification, okay then, we'll go from there and see what's what.

3-18-2026 Updated version of the Xlibre Devuan-mate-mini-6 (excalibur).

Just uploaded an updated copy of this iso, as before it's identical to the standard version
with the exception of the use of Xlibre for display. This is new software and not official
Devuan packages (for now). And again this whole iso is not official Devuan. That being
said it's working nicely, the video artifacts from the last version months ago seem to be
all gone and I think it's using a little less ram too.

https://sourceforge.net/projects/vuu-do … -6-xlibre/

New iso up, just a maintenance update as Debian did a point release a couple days ago, so over 60 updates including a new kernel.

https://sourceforge.net/projects/vuu-do … te-mini-6/

EDIT1: Nope, error in sources.list dangit, got to run another one.

EDIT2: Okay, all good now, new iso up and looking slick! Turned out to be over 70 updates.

Cool, thanks for posting that, just logged on my SF and saw there was activity! Downloading now, I don't care what it is, i'm checking it out, Miyo is the most brilliant and prolific re-spinner i've ever seen in my own 17 year history of re-spinning.

Article about this subject out of Norway via the Register, the real gold is the video about halfway down the page, it's a must-watch IMO.

https://www.theregister.com/2026/03/06/ … ification/

Pretty sure that's not how that works, I believe it's there to stop the microcode from trying to update itself on every boot. But I could be wrong.

https://www.reddit.com/r/debian/comment … acklisted/

https://salsa.debian.org/kernel-team/li … config#L42

This is with the blacklist.conf file still in place:

root@devuan:/home/jack# dmesg | grep "microcode updated early to"
[    3.943872] microcode: microcode updated early to new patch_level=0x05000119

You can see it's been applied in early stage boot despite the blacklist file.

Don't believe everything AI tells you.

Can anyone confirm?

Essentially it's baked into initramfs alongside the other firmware, when you install new firmware the system runs update-initramfs and gens a new initrd.img, so the code is there and gets applied early in boot. The blacklist just stops subsequent attempts to update.

At least that's my understanding of it.

I have run Vuu-do on a machine from 2005 that has 1 gb of ram, and it runs fine. I run Devuan every day on a machine with a simple dual-core APU at 800 mhz with 4 gigs of ram and never have a problem.

But if you need translations you would need to look elsewhere as Vuu-do don't do that. Vanilla Devuan works great for that.

Thank you all for the kind words, but I need to apologize for my mini-meltdown that day, it's no excuse, but in my defense I will say that I have a very sick cat, and can't seem to to get a vet appointment at the place that's 30 miles from here, we talked to them on the phone and they kinda poo-poo'ed it saying she just has allergies, trying now to get an appt. at a more sophisticated vet but that's 100 miles away with a 30 day waiting list. And to boot that morning right before I woke up I had a dream where she died in my arms. That pretty much FUBAR'ed my whole day, and I should have known better than to get online, but I did and it did not turn out well. Mea culpa, sorry for the drama.

I wasn't poking fun at anyone, but yes I was bragging about my little scriptlet, and incredibly enough I am aware of dependencies (shocker huh?), which is why I know the program mentioned ALSO HAS DEPENDS, so yeah it's even larger than 29 mb which is what the package is listed at for installed size.

But sure, if you pull the cruft you mentioned out (which my app doesn't have or need), then maybe there is 4 mb of actual code. That's still 100 times larger than my little experiment. I'm sure it has some extra lovely features though that might be very handy.

What I made does the basic main task such things should do, it's tiny so there's a lot less to go wrong and it's easy to audit, and a good solid base if someone wanted to expand on it.

And damn, really toolkit bullshit?? Every gui program uses one toolkit or another, so that comment was nonsense. And no i'm not shoving all that QT crap into my system, GTK has issues but QT sucks too.

And wtf? You're on here usually giving people shit for complaining instead of doing something about it. And here I am trying to do something about it and you're giving me misery too?

Hell, you're probably right, I don't know why I bother. Maybe time for another break from linux for me.

Very nice! Love the low ram usage, but are you measuring that the old-school way or the legacy way (excluding buffers and cache)?

A reasonable assumption, my MO is exactly that kind of thing. But in doing research for this, it seemed like libsodium was the "gold standard" for this sort of thing, and their docs are actually not bad, relevant portion:
https://doc.libsodium.org/doc/quickstart

"One-shot encryption where everything fits in memory

    Create a secret key using crypto_secretbox_keygen().

    Create a nonce using randombytes_buf(nonce, sizeof nonce).

    Use crypto_secretbox_easy() to encrypt the message and send/store the resulting ciphertext along with the nonce. Unlike the key, the nonce doesn't have to be secret.

    Use crypto_secretbox_open_easy() to decrypt the ciphertext using the same key and nonce."

So I thought hell I can muddle through that, and it would be a real step above base64, lol.