The colors are dark and calming and easy on the eyes, i've done a ton of research into color theory (I used to own a small custom paint contracting business), and I chose the colors for Vuu-do to be easy on the eyes and on the brain as well.

The skulls and the font for wallpaper (Zombified) are just pure whimsy based on the pronunciation of Vuu-do.

I'm a headbanger from waaaay back in the day, so that's some of my influence.

Also a former #! user and that's where I started really liking darker themes and Openbox, and the very first Miyolinux that I tried and based Vuu-do on, also had dark wallpaper and colors. The current Vuu-do wallpaper in fact was originally Miyo wallpaper that I modded, and that's why I still use it, as it has historical and sentimental value to me.

In any case, wallpaper is usually the very first thing people change on any linux distro upon install, so it's a moot point, I set Vuu-do up with very little onboard in the way of themes to start with, as I expect people will want to use their own. The whole thing is set-up to be easily customizable in the MIYO spirit. You'll find notes from me in all kinds of places, explaining how to easily change things.

^^^band-aids man. The update _should_ fix the wound itself.

The errors come from a glib/gio file that was changed at some point, hardcoded in and no way gnome was gonna take it back. So the Mate guys had to patch Caja. But Debian still has the unpatched 1.26.3 version in both trixie and sid, but they are moving 1.26.4 in hopefully soon, there are some other libraries that need to be pushed as well to enable the new version, we may see a lot of new Mate packages come down the pipe.

ETA: Thank you Mike Gabriel at Debian, we do appreciate it!

Well they closed the bug on me already, response indicated they will be pushing the 1.26.4 caja package sometime hopefully sooner than later. As soon as I see it i'll mark this one solved.

"Just delete the file and don't ever turn your machine off" is also not a great answer my friend.

In any case, I don't even blame Mate/Caja for the issue in the first place, as fanderal pointed out earlier this seems like typical gnome-f***ery once again. Break GTK yet again and call it a feature and everybody else has to scramble to figure out fixes and workarounds.

Debian needs to update Mate, they just literally swapped from a working version in bookworm to a broken one in trixie. I'd file a bug report but they pretty much ignored the last one I filed. Filed anyway.

No doubt, that's why i'm messing with it, it's a nasty bug.

And anyway, was hoping we'd be moving up to mate 1.28 or at least 1.27 in Devuan 6.

Thank you Altoid for that link!!!

That is EXACTLY what i'm experiencing, read through that link and others. Basic problem seems to be in Caja. And it's nasty, it will literally build to 100's of mb's if you select and then hover over that file, and pretty much any other file. It really is a critical error because it could build up bad enough unattended to do some damage.

In current daedalus Caja is version 1.26.1 and does not have this issue, in excalibur it's version 1.26.3 which seems to be particularly bad, and documentation seems to say they fixed the issue in 1.26.4 and later.

Need a .deb of Caja 1.26.4 to test....

ETA: Found one at the opensuse build service, testing here shortly.

FYI not only does trixie still have the 1.26.3 package, but so does sid. Pretty far behind...

Doesn't fix the problem but I do have a way to stop the alsa errors at boot, the error claims that it can't find the alsa_restore_go definition in the 90-alsa-restore.rules file in /usr/lib/udev/rules.d/ but, the definition is clearly in that file, seems like a syntax error somewhere.

Workaround to stop boot errors: Create a 90-alsa-restore.rules file in /etc/udev/rules.d/
content:

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $attr{device/number}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $attr{device/number}"

LABEL="alsa_restore_end"

And here's the /usr/lib/udev/rules.d/90-alsa-restore.rules file from excalibur currently if anyone can take a look and maybe see an issue:

# do not edit this file, it will be overwritten on update

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

ENV{ALSA_CARD_NUMBER}="$attr{device/number}"

# mark HDA analog card; HDMI/DP card does not have capture devices
DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"

# check for ACP hardware
TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp6x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp63-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp-pdm-dmic", GOTO="alsa_hda_analog"
GOTO="alsa_restore_std"

LABEL="alsa_hda_analog"
# restore configuration for profile with combined cards (HDA + digital mic)
TEST!="/run/udev/alsa-hda-analog-card", GOTO="alsa_restore_std"
IMPORT{program}="/usr/bin/cat /run/udev/alsa-hda-analog-card"
ENV{ALSA_CARD_HDA_ANALOG}!="", ENV{ALSA_CARD_NUMBER}="$env{ALSA_CARD_HDA_ANALOG}"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $env{ALSA_CARD_NUMBER}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $env{ALSA_CARD_NUMBER}"

LABEL="alsa_restore_end"

From another forum, don't know if pertinent here:

I have an appimage of FF esr on the 2005 machine (64-bit) with just one gig of ram, it will run one tab just fine, even up to 2-3 tabs, but if I open anymore or try to open another app while the browser is open, it bogs down and gets all swappy.

Wondering if the 32 bit version of FF would be any lighter on ram? Most 32 bit apps are.

Yeah the browser is the only fly in the ointment, otherwise i'd just make an updated 32 bit from that repo, with all the apps somebody might could use offline, I mean it all works fine, it's just the browser from that time that's not going to work right and may have bad security issues.

Re: security; I don't know that much about appimages, just the basics, but isn't an appimage already partially sandboxed? Especially if it's in userspace with no root privileges?

I'm aware of tiny-core, have messed with it a lot over the years. I don't want to use it. I want to make this thing using Devuan.

@RRQ- Security is probably not even much of an issue for people who might use this, I started to just update the 32-bit system I already have with a 32-bit appimage of a browser, but then I started wondering about making the whole thing more secure and of course live-CD/DVD/USB popped into my head and that would probably be the simplest and most secure. But many old machines won't boot from USB, and having to rely on an old optical drive to boot and run every day may not pan out well in the end.

I've had multiple people ask me to build a new 32-bit Vuu-do, and I have some 32 bit machines down at the library and a printer-scanner i'd like to resurrect.

I'm not targeting anything below 512 mb of ram, that's for stuff like Tiny-core.

Oh i'm aware, I used to be a user, actually have some isos still around here somewhere. But I think what i'm proposing is different, Puppy is all read-only with the potential for a persistence file, no real difference from a live-usb.