EDIT: just saw your second post.

I have despised pkexec since I first saw it, broke my heart to see gksu go bye-bye. You should be able to use it the same way gksu was used, just a simple "gksu (program name)" for things that need authentication, but oh hell no doesn't work like that. Piece of crap.

My current workaround: A script that adds all the pkexec bulls**t necessary to make authentication happen. Called it "gksu.sh" so now I just use that the same way I used to use gksu, i.e. "gksu.sh (program-name)". This is especially helpful for file-manager extensions that I wrote a long time ago that used gksu.

# Script to convert gksu to pkexec for extensions already written
# without adding a lot of code to the .desktop command line.
# Usage: "gksu.sh [program]"

#!/bin/bash
if [ -z $1 ]; then
 echo -e "at least 1 argument required!\n" >> /dev/stderr
 exit 1
fi
COMMAND=$1
shift #shift first arg
for ARG in "$@"
do
 if [ -z "$ARGS" ]; then
  ARGS="$ARG"
 else
  ARGS="$ARGS $ARG"
 fi 
done
ARGS=\'$ARGS\'
eval pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $COMMAND $ARGS
exit 0

Nice! But don't you need to make a xorg.conf if you install the Nvidia drivers? Been years since I ran an Nvidia machine.

Another easy way to identify your chip is to install nvidia-detect then run that in terminal, it will also attempt to suggest what packages you might need to install for your chip.

Well I guess every DE is different and I don't know what you're using, but currently in my Mate install of daedalus, it's in the menu.
system>>preferences>>hardware>>sound, and the GUI that pops up has a little checkbox at the bottom for enabling system sounds.

Wow, I needed more coffee before I read this thread. Lotsa stuff...

FWIW IMHO best protocol:

1. Gparted: setup partitions
2. Devuan: Install normally and let system set normal permissions.

"But I want system to see other partitions including USB devices and let me open/read/use them with just a click from the user"

3. Then open /usr/share/polkit-1/actions/org.freedesktop.Udisks2.policy and edit accordingly. Settings will persist.

If I recall correctly, all I did this go-round, was:
Netinstall devuan 5 with core Mate desktop
Uninstall Pulseaudio, it demanded I install Pipewire in it's stead, I did so.
Then I uninstalled Pipewire, it didn't complain.
Added some extra packages for ALSA, alsamixer-gui to get mixer, and libasound equalizer package to get EQ, etc.

Mate works fine without anything but Alsa, and so does Openbox.

It's kind of freaky. Something's not right with something. The size of the data on the partition i'm concerned with is not in question, it's straight-up 2 gigs, no reason why it would squash much larger, the excalibur install is unquestionably smaller.

In fact it's blowing my mind, I just pulled out a ton more of stuff that was left in after the upgrade, old versions of libraries and binaries for things. Important stuff too. And now system size down to 1.9 gigs, same system in daedalus is 2.4.

The 6.12.6-amd64 kernel is listed at 109 mb in excalibur. The previous kernel I used in daedalus is listed at 408. WTH?

Kinda at a loss here...

Seems like something is getting rolled in to squashfs that should be excluded.

Off-topic: Getting a hella delay during boot right after "waiting for /dev to be populated".

Vuu-do 5.02 openbox mini and max versions compressed with zstd instead of xz for faster decompression during live sessions. 1st versions for testing. Results on older hardware tested so far are faster boot, faster program loading/opening and less lag time on first open, and faster install from liveUSB session. YMMV.

https://sourceforge.net/projects/vuu-do … do-5-zstd/

Running right now on a Corsair 32 gb stick several years old, but looks pretty much the same as the ones they sell now at wally world where I got it. Ran an iso of the Vuu-do max using zstd, came out as expected about 10% larger at 1.1 gb.

This usb is smoking the hard-drive, it boots so much faster, and here's the thing that's blowing my mind and making me super happy: Even when I load it all to ram it's still faster than the HD boot.

I looked up specs on this very stick and tests showed an average 22 mbs read and a 10 mbs write. But when I load it to ram I can watch it loading the largest file (squashfs) and it's loading at 30 mbs. The HD on this old machine usually runs around 35-45 in practice, so loading from usb is only about 10-30% slower, but it's loading 3 times the data.

It's compressed data, but zstd decompresses it 13 times faster than xz does.  I didn't have time for a smoke or to make a cup of coffee before it booted.

Procedure I followed:

Add entry to /etc/refractasnapshot.conf, enable, and comment out others. mksq_opt="-comp zstd -Xcompression-level 22"  Run iso.

Run Gparted on usb stick: new partition table, two new primary partitions both fat32, first slightly larger than iso with boot flag, second rest of stick labeled "DATA".

Refracta2usb: option iso2 findiso, install syslinux, edit boot menu to add toram and failsafe entries and remove others, syslinux boot splash ugly, replaced with boot splash from onboard isolinux that I made. Syslinux highlight color, also ugly, changed that.

@fsmithred you gotta try this, you're gonna love it.

Okay, posting now from an iso I just made using zstd, the Vuu-do openbox mini, running off a stick (usb 2) that I loaded Chromium into during this live-session. Totally worked to make a useable iso. Command I posted above and tried first error'ed out, I should have been paying more attention to the mksquashfs man page than the zstd man page. Thankfully the Refracta-snapshot log showed me not only the error of my ways but also how to fix it:

mksq_opt="-comp zstd -Xcompression-level 22"

All done on my Compaq CQ-58 circa 2012, amd dual-core APU @ 1.0 ghz.

In practice on the mini iso, 2.4 gigs unpacked, the highest level of compression for zstd made an iso about 10% larger than xz -Xbcj x86 did.

651 mb vs 712 mb.

The next part is subjective, I don't have a stopwatch to check small intervals. But after loading the iso to a USB, and using the regular boot option, NOT load-to-ram, the boot time was faster, the lag times when opening the menu and programs practically disappeared and it was easily as fast as I normally get loading the whole thing to ram. Fast as hell.

And after bootup before running anything, I was at 479 mb of total ram use as opposed to the 1.14 gigs when I loaded the system entirely to ram. The task manager showed actual usage by the services running at about 300 mb.

Obviously I need to do a whole lot more testing, and get some actual timing for things, I could have some confirmation-bias.

But, impressions:

1. zstd most definitely does not compress as small as xz when doing an iso. About a 10% difference.
2. The bottleneck of using an optical disc (CD in this case) is too much for this to make a difference.
3. A liveUSB2 though has about 5 times faster transfer speed than my disc-drive, and in practice it's still a small bottleneck, but most programs like the file manager, text-editor, terminal etc. are pretty small, and get transferred fast enough, and de-compressed noticeably faster than xz does.
4. I should be able to run an iso that's a gig in size on a liveUSB stick, and actually use it with only a gig of ram since it doesn't all need to get loaded and the speed doesn't suffer as a result of not loading it all to ram.

Fun stuff, gotta go do some more testing!

@kapqa, well i'm using gnlug instead of the main deb.devuan.org, but in it there is no "testing-security" or "testing-updates" files and so no release files either. None in the excalibur section, nor in the "testing" section which is in a different section than excalibur but I assume is mostly the same files.

So that may be why you're getting an error.

Also I don't think using the "testing" repo is the same exact thing as using the excalibur repo. I've loaded the testing before just to look at what's available, but haven't peeked at excalibur. I could be wrong.

In addition to the AMD firmware package, I also have the microcode package, don't know if that makes a difference in this case though.

One last question about snapshot. I noticed zstd is in the list quoted above, is it possible to use that for compression in snapshot?

My thinking may be way off base here, but was reading up on different compression methods and noticed that while it won't compress quite as small as xz, that it's decompression speeds are several orders of magnitude faster.

Use case scenario for that, that i'm interested in, is on a liveUSB, after it boots there is a lag time when you first open the menu or any programs, after that it's cached and plenty fast, but was just wondering if zstd would cut down that lag time.

Again, on a modern fast machine probably never notice, but on the 10-12 year old low-spec machines I typically have to deal with it seems like it might help?

ETA: I know the real bottleneck is going to be transfer speed from usb 2, but just looking for small speed tweaks here.