KLV-Airedale-alpha Released for Experimentation and Improvement by the Puppy community

[mikewalsh]

Now then:-

I'm pleased to report that JakeSFR's two magnificent archive utilities, UExtract & Packit, work perfectly here in KLV following a manual install of each.

I used Packit to create a tar.gz tarball of my Google_Chrome-portable. And then used UExtract to open it up again. Flawless. I use both of these a LOT, so I'm "tickled pink" (thank you Ken Dodd!) about this.

Of course, these both being packed as ROX-apps may be helping.....I can't say. What we really need is some way of converting .pets into whatever native package format Void uses. Any ideas what that is?

Or perhaps I could pack the pair of them as an SFS, since those seem to work nicely with KLV's overlayfs setup. I'll have a think about that.

Mike.

[rockedge]

@mikewalsh good report! Your long term testing and configuration adjustments are invaluable to the development of these distros. Can't find what's good or bad, buggy or not, by constantly booting into the next dev version. I am doing that mostly with a VirtualBox or QEMU machine until I feel like it is time to boot on a physical machine and continue on with that phase of construction. Different things happen to the same ISO when run on many different platforms. The virtual machines allow rapid testing of sweeping changes. Plus really big when debugging kernel panic or system lockup/freeze up.

Take your time and "mod" out, "Suppe Up" and customize, there is much to learn and ideas to see as the distro gets fine tuned and gets ready to go supersonic.

[mikewalsh]

UExtract v4.6 & PackIt! v1.22 - all-in-one SFS for KLV-Airedale

'Kay, gang.

What I've produced here is a combined SFS of both the above utilities from JakeSFR (these are the latest releases currently available). Because it's so small, I'm attaching it to this post.

These things work just as well in KLV as they do under Puppy, and I'm sure I can't be the only one who makes use of them. Anyways; hope some of you find this useful!

Mike.

[bigpup]

My SFS package of Uextract is smaller and I got it posted before you did.
viewtopic.php?p=45431#p45431

That is what I have been doing to get some of the more common Puppy programs installed.
Finding a pet package and converting it into a SFS package.

I wonder if one of the Puppy script programs, that converts different packages, could be re-coded, to convert a pet package, into a xbps package.
There are a bunch of different specific converters out there.
Pet to SFS
Deb to pet
Directory to pet
Directory to SFS
make a deb
etc.......

[rockedge]

@wiak Using @rufwoof 's scripts from earlier FirstRib / WeeDog development,
I am able to boot into w_changes=RAM0 ( mode RAM0) and manually run ./save.sh which will create 55changes.sfs, 56changes.sfs, 57changes.sfs...... sequentially each time ./save.sh is run.

Finally before shutdown run ./merge-changes then combines each existing XXchanges.sfs into a single 55changes.sfs, which will load at boot in place of a dynamic /upper_changes directory, providing persistence on demand (POD).

[bigpup]

I assume this OS is using xbps packages of programs, as the installable packaging.

There is suppose to be a program:
xbps create

The xbps-create utility creates XBPS binary packages from files stored in a directory.
The files must have correct permissions and location within this directory.
The behaviour of resulting package is changed by using multiple values in the options.

XBPS-CREATE(1) (General Commands Manual)
https://man.voidlinux.org/xbps-create.1

I wonder if you could extract the contents of a pet package into a directory.
Use xbps create to turn that directory into a xbps package of the program that was the pet package.

[rockedge]

@bigpup I think we might be able with xbps-src possibly to do this. Might need a helper / wrapper script to do the entire process.

get the PET, decompress it, convert it to xbps format. Maybe a separate script to do this is easier

Might as well try out the xbps-create tool and see what comes of it!

[bigpup]

I took a pet package and extracted it into a directory.

Used xbps-create to turn the directory into a xbps package.

It kept giving error about the name I was trying to call it.
Kept insisting it had to be named foo-1.0.1_1

I tried to install the xbps package using OctoXBPS
File->Install locale package...
It tried to install, but got error.
The package is not listed in the xbps repositories, so it is not going to get installed.

I am not that good at using terminal commands to do anything.
Maybe there is an optional command in xbps-install to get around this error.

Oh well, it kind of worked.
.
.

[wiak]

@wiak Using @rufwoof 's scripts from earlier FirstRib / WeeDog development,
I am able to boot into w_changes=RAM0 ( mode RAM0) and manually run ./save.sh which will create 55changes.sfs, 56changes.sfs, 57changes.sfs...... sequentially each time ./save.sh is run.

Finally before shutdown run ./merge-changes then combines each existing XXchanges.sfs into a single 55changes.sfs, which will load at boot in place of a dynamic /upper_changes directory, providing persistence on demand (POD).

Yes, I have a copy of these scripts user1111 wrote about three years ago, and briefly experimented with them some months ago actually. As far as I recall the save.sh script is fine and straightforward; afterall, in RAM0 mode the whole session appears as /mnt/layers/RAM/upper_changes and saving that session simply involves saving that RAM/upper_changes back to highest chosen number for NNupper_changes, ready for next run. However, there was something about the merge script that didn't seem correct to me - been a while since I looked at that but I have a feeling it didn't handle the overlayfs-type 'whiteout' char files, but maybe I'm wrong and all is fine. I'd have to look at it again.

w_changes=RAM1 mode is almost identical to RAM0 mode in that whole session ends up being in /mnt/layers/RAM/upper_changes, but the last upper_changes folder that was on external media first gets completely copied into that /mnt/layers/RAM/upper_changes structure but again saving it is all you need to do at the end of use. I use an rsync script for that (though you don't want to save back some stuff such as caches), which I'll upload for you. Disadvantage of that w_changes=RAM1 method is that it uses up RAM (since simply copies previous external media upper_changes into RAM prior to using - but that is not such a problem if using with a relatively small external media upper_changes folder of course. Advantage is that saving back is just as simple as for RAM0 mode. The bit I have never decided is what not to save back...

Finally, the most usual way of doing this kind of thing, is to use the previous external media upper_changes, but via an overlayfs read-only top layer (so not wasting RAM by actually copying it in) and the writable upper_changes is the very very top layer of the overlay, being /mnt/layers/RAM/upper_changes. That's what w_changes=RAM2 mode does (I think that is probably equivalent to Puppy's Pupmode 13, though I'm not sure since I haven't studied that, and also like DebianDog's changes=EXIT mode.) So big potential RAM saving in practical use. Disadvantage is that you can't simply save back /mnt/layers/RAM/upper_changes, but instead have to rsync it with an already existing external media upper_changes folder. And you also have to consider what effect the whiteout char files might have on save result - I'm not too sure if they are a problem in practice or not - I actually seem to get by using a simple single line rsync script for that (being using that for some months), but... that is imperfect since again shouldn't be saving back the likes of cache files. As I've mentioned elsewhere, fredx181 uses a more complicated rsync script in the overlayfs Bullseye DebianDog variant, which does seek out whiteout char files and adjust what is saved accordingly. A modified version of that to match the directory names being used in KLV-airedale would do the job I'm sure.

Actually, fredx181 provided a WDL remaster script at one point, which seemed to work fine, and I think that is the better way of getting rid of all the NNupper_changes layers when a user wants everything merged - i.e. remastering is really just a matter of re-writing back the whole live filesystem and recreating the firstrib_rootfs with that. So, I'd say forget that merge.sh script (unless tested as okay for sure, which I feel it isn't) but instead rely on remaster when wanted; I'll search for the post Fred's remaster script is posted in.

[wiak]

For the moment, I feel you should stick with default save to media persistence until all other distro assembly matters (right-click menu actions and so on) are all polished up to beta stage and beyond. The w_changes=RAM modes are just nice extras, that can be made to work appropriately later IMO. i.e. not a priority at this stage and could be a distraction to the main process of reaching a beta release stage or better. Personally I'd leave these RAM modes till last, nice though they are to have.

[mikewalsh]

My SFS package of Uextract is smaller and I got it posted before you did.
viewtopic.php?p=45431#p45431

Umm......'kay.

Yours is one app. Mine contains two..... (*shrug*)

I can't see it much matters who builds stuff at the end of the day. The main thing is that the community knows that certain things work OK in Airedale, and that those of us who like packaging software don't mind sharing...

Mike.

[wiak]

@wiak :-

Ah, okay; fair enough. It's no big deal; I have my XVidcap-portable package working, plus vokoscreen which I installed with xbps.....but I just like WeX, y'know? It's incredibly versatile (the more so since Fred re-compiled it all together with that ffmpeg package into a single binary.) And being able to add the webcam feed if wanted just adds the "cherry on the top", as it were.....

In the KLV-Yeti (openbox/tint2/pcmanfm), I'm (very slowly) working on I'm purposively avoiding Qt libs in the core distro (easy enough to install with xbps/vpm later of course). Partly because of that, and because I like to include audio/video/webcam recording as a tiny addition, I'm including weX, Precord, scrot (actually scrox with symlink as scrot since scrox just scrot with an extra needed by weX), and fredx181's animated git maker gifenc-sel. After recording a video or screencast with weX (which can as you say include an embedded webcam video image in screencast) there is a button in weX big config window that allows you to immediately call up gifenc-sel to make animated gif of the video (and/or to play the video in mpv, parole, or vlc depending what's installed). Only issue with it is that the big config screen isn't scaling properly (so its big...); I think cos using gtkdialog GTK+3 in the distro, but I don't know - just cosmetic in practice since still works...).

Basically, I think it is nice to include audio/video/webcam/screencast/scrot-screencapture out-of-the-box in distro download. I don't know if rockedge wants to use the same or alternatives, but the option is there.

Anyway, the way I'm packaging it (for use by my KLV-Yeti build plugin) is as a downloadable simple tar.xz, which I'm storing on gitlab weedoglinux site (as you'll see from the below install_wex.sh script contents). The same also works on KLV-airedale; just installed and been using it on alpha5 version... (all the binaries, wex, precord, gifenc-sel etc, get auto-stored into /usr/local/bin so as not to conflict with official Void packages at all, not that they would anyway...). The version of ffmpeg installed in KLV-airedale by default is already perfectly fine for use with wex.

If you wish to have working wex and so on, therefore, just run the attached install_wex.sh script (remove the dummy tar and make executable before use) and, assuming you have a working internet connection, that should install all the required parts for you. Note that weX/scrox required libgiblib, which isn't installed currently on KLV-airedale, so that install_wex.sh script also installs that using xbps. Note that all of these wee apps expect a simple terminal such as xterm or rxvt on the system, which isn't in KLV-airedale at this stage. The install_wex.sh script there also installs an extremely small variant of rxvt called mrxvt. If you already have xterm or rxvt or urxvt, for example, then you should modify the install_wex.sh script accordingly but mrxvt is quite a nice little rxvt with tab support. DISCLAIMER: I don't think this will break your KLV-airedale installation, but I guarantee nothing so use at your own risk (can't see what damage it could do though...). Nothing installed will conflict with xbps database (which simply won't know about wex/precord existence...) so should all be fine. wex, precord, and gifenc will also all auto-appear in the distro Start Menu -> Multimedia section. I usually test from terminal first time round, but don't need to. If anything does go wrong, running wex and/or precord again should force it to reset its configuration files such that it should work thereafter, but I had no such issues anyway.

NOTE WELL: You will need to adjust your RECORD Capture controls; I used alsamixer F4, but I guess pavucontrol will allow the same - note that I've included the "pulse" device /etc/alsa/conf.d fix I discussed a few posts above so that both wex and precord can find pulseaudio device "pulse" and not need to use the likes of plughw:0.0 direct alsa drive. i.e. "pulse" AUDIODEVICE set as the default and should work without further thought... As explained earlier, the fix for that was just a missing symlink in that /etc/alsa/conf.d directory

If you prefer to run the commands in the install_wex.sh script line by line manually, here are the short contents of the attached script:

Code: Select all

xbps-install -Sy giblib mrxvt  # you don't need mrxvt if you already have xterm, uxterm, rxvt, urxvt, or aterm
mkdir -p /etc/alsa/conf.d
ln -s /usr/share/alsa/alsa.conf.d/50-pulseaudio.conf /etc/alsa/conf.d/50-pulseaudio.conf  # pulseaudio 'pulse' DEVICE name fix
cd / && wget -c https://gitlab.com/weedog/weedoglinux/-/raw/master/build_resources/wex_scrox64_gifenc_precord.tar.xz -O /wex.tar.xz
tar xJf /wex.tar.xz && rm /wex.tar.xz

NOTE WELL: the wex.tar.xz package is only a very small install (around 200 kilobytes uncompressed) so gives a lot of bangs for the bucks.

[mikewalsh]

@wiak :-

Gawd, I see what you mean about the main config GUI. It's humungous...!

(I've got a 1920x1080 screen here, and it near as dammit fills that up. Mind you, at least it's easily readable; I tend to run with a larger than usual font, and in the Puppies the config UI often looks very cramped, and squashed together.)

I'll have a play with it later, and experiment with recording audio. Cheers, Will.

Mike.

[rockedge]

@wiak I agree, it is fun to test it out but the RAM modes but the mechanisms that work with them will involve much more study and development. Now back to business. I am still having this odd display lockup caused by xfce4-screensaver on one machine I test and develop on. I need to look more at the Xorg screen blank routines and what conflicts there are.

Otherwise I have been loading different SFS and trying out different configurations. Interested in the idea of converting a PET into xbps format with xbps-create, which @bigpup pointed out. Which tests show will work, but needs lots of refinement

Test with Dropbear PET I made some time ago -> https://rockedge.org/kernels/data/PET/B ... x86_64.pet

Code: Select all

root# xbps-create -A noarch -n foo-1.0_1 -s SSH dropbear-2019.78-x86_64 
foo-1.0_1: adding `./usr/local/share/man/man8/dropbear.8' ...
foo-1.0_1: adding `./usr/local/share/man/man1/dropbearkey.1' ...
foo-1.0_1: adding `./usr/local/share/man/man1/dropbearconvert.1' ...
foo-1.0_1: adding `./usr/local/share/man/man1/dbclient.1' ...
foo-1.0_1: adding `./usr/local/sbin/dropbear' ...
foo-1.0_1: adding `./usr/local/bin/dropbearkey' ...root# xbps-create -A noarch -n foo-1.0_1 -s SSH dropbear-2019.78-x86_64 
foo-1.0_1: adding `./usr/local/share/man/man8/dropbear.8' ...
foo-1.0_1: adding `./usr/local/share/man/man1/dropbearkey.1' ...
foo-1.0_1: adding `./usr/local/share/man/man1/dropbearconvert.1' ...
foo-1.0_1: adding `./usr/local/share/man/man1/dbclient.1' ...
foo-1.0_1: adding `./usr/local/sbin/dropbear' ...
foo-1.0_1: adding `./usr/local/bin/dropbearkey' ...
foo-1.0_1: adding `./usr/local/bin/dropbearconvert' ...
foo-1.0_1: adding `./usr/local/bin/dbclient' ...
foo-1.0_1: adding `./pet.specs' ...
foo-1.0_1: binary package created successfully (foo-1.0_1.noarch.xbps)
foo-1.0_1: adding `./usr/local/bin/dropbearconvert' ...
foo-1.0_1: adding `./usr/local/bin/dbclient' ...
foo-1.0_1: adding `./pet.specs' ...
foo-1.0_1: binary package created successfully (foo-1.0_1.noarch.xbps)

@bigpup I went ahead and just used the foo name, we'll figure that out later, but I managed to make the xbps and register it as a repo but no install so far. Something with my syntax perhaps?

Code: Select all

root# ls
dropbear-2019.78-x86_64  foo-1.0_1.noarch.xbps
root# xbps-rindex -a /root/Build/dropbear-2019.78-x86_64.pet.extracted/foo-1.0_1.noarch.xbps  
index: added `foo-1.0_1' (noarch).
index: 1 packages registered.

But then:

Code: Select all

xbps-install -R /root/Build/dropbear-2019.78-x86_64.pet.extracted foo-1.0_1.noarch.xbps
Package 'foo-1.0_1.noarch.xbps' not found in repository pool.

Otherwise this PET when installed manually works really well in KLV-Airedale
_

[mikewalsh]

Right, gang.

Couple more Airedale SFS packages for y'all:-

JakeSFR's TakeAShot 1.15, & Fred's marvellous adaptation of it into TakeAGIF 2.0.

Both working fine. Just one fly in the ointment; the 'Preview' button at the end doesn't do anything.....I guess because in Puppy it uses Viewnior by default? Don't know. I've scanned through the script, but I can't see where it calls an image viewer; someone with better scripting ability will probably spot it immediately.

Apart from that, though, both work a treat. I've attached them to the bottom of this post if anyone's interested.

Mike.

[rockedge]

@mikewalsh Nice!

We could always install viewnior OR try a symlink called viewnior that targets ristretto

Code: Select all

xbps-install -Sy viewnior

and see if "preview" works.

[esos]

Alpha6 looks good.
No problem here
frugal or booting fromiso with persistent.

Ok with gimp, brave, firefox

Just libreoffice sfs package wont automount after reboot.

[rockedge]

@esos Thanks for the report. Are you loading the SFS at boot?

This is a system I am testing on. The 2 digit number in attached to the front of a SFS file name, it will load in sequence according to what number is assigned.

Screenshot.jpg (34.49 KiB) Viewed 988 times

Try assigning a number to the name of the libreoffice sfs like 70libreoffice.sfs for example. Then reboot and libreoffice sfs should be loaded and ready to go. Using Load_SFS doesn't persist across boots I don't think. The SFS's loaded via Load_SFS should be Deactivated before reboot/shutdown.

[rockedge]

@wiak before returning to alpha6 for further improvement and refinement, this is what KLV running in RAM0 mode using the 2 scripts only very slightly modified. So when merge runs it creates the combined sfs's into 55changes.sfs.

Screenshot_2021-12-26_19-02-32.png (67.01 KiB) Viewed 980 times

Screenshot_2021-12-26_19-02-48.png (345.29 KiB) Viewed 981 times

Screenshot_2021-12-26_19-04-14.png (61.02 KiB) Viewed 981 times

/upper_changes is completely empty

[wiak]

@wiak :-

Gawd, I see what you mean about the main config GUI. It's humungous...!

(I've got a 1920x1080 screen here, and it near as dammit fills that up. Mind you, at least it's easily readable; I tend to run with a larger than usual font, and in the Puppies the config UI often looks very cramped, and squashed together.)

I'll have a play with it later, and experiment with recording audio. Cheers, Will.

Yes, glad to see it is not just on my machine. I was very surprised gtkdialog width code wasn't working. The actual audio/video/screencast/webcam functionality works fine though. No issues with Precord GUI funnily enough, so may be an easy fix. I'll look into it one day and build a new GUI (or hopefully find a quicker fix since I have gtkdialog pseudo XML stuff).

[mikewalsh]

@rockedge :-

@mikewalsh Nice!

We could always install viewnior OR try a symlink called viewnior that targets ristretto

Code: Select all

xbps-install -Sy viewnior

and see if "preview" works.

Cracked it. After a wee bit of head-scratching, it suddenly occurred to me; many things are set to defaults - in Puppy - by the scripts in /usr/local/bin, and a lot of apps are written to target/make use of the 'default' applications.

So I've put a wee script - defaultimageviewer - in /usr/local/bin, and set it to open Ristretto:-

Code: Select all

#!/bin/sh
#
# Launch default image viewer
#
exec "/usr/bin/ristretto" $@

.....and now the 'Preview' button in the final window of Take a Shot & Take A GIF does what's expected of it. Obvious, really, considering they were written for Puppy originally.

This will be worth putting in place, especially if we're going to convert other Puppy apps for Airedale. Bound to be summat else written to target the default image viewer, sooner or later...

----------------------------------------------

With regard to "loading" SFSs mid-session, I find it's best to put them in alongside all the other SFSs in the first place - in my case, /mnt/sdc1/KLV-test. That way, you can load them straight away, and because of their location, they're automatically loaded at the next & subsequent boots. It's worth taking the slight extra effort to locate them correctly to begin with.

Works for me, anyroad. (I haven't tried loading them from just 'anywhere', but I'll take your word they won't persist if you do that...)

Mike.

[wiak]

Working on the wex config screen scaling error - almost got it fixed; actually I have... just need to reassemble a couple of sections of gtkdialog yucky xml gui description code then I'll post fixed tar.gz so install_wex.sh installs the fixed version. Should be ready in a few hours (busy working on my water supply again...).

[wiak]

Working on the wex config screen scaling error - almost got it fixed; actually I have... just need to reassemble a couple of sections of gtkdialog yucky xml gui description code then I'll post fixed tar.gz so install_wex.sh installs the fixed version. Should be ready in a few hours (busy working on my water supply again...).

gtkdialog seems to be limiting how minimum the horizontal width request size can be (to 160 pixels maybe??? - weX previously sometimes asked for max 40 pixel width for some entry boxes). Hence weX gtkdialog hugely wide. I would have to study github gtkdialog code for anything been changed for some reason or other. On quick check, without recompiling and testing, the only thing I wonder is this change that was made (something to do with 'wayland' needs): https://github.com/puppylinux-woof-CE/g ... 57cd1eae29

Anyway, I'll work with what we have just now and limit the wex config screen overall width some other way.

[wiak]

@mikewalsh Okay, per my immediately previous post I have now 'fixed' weX config GUI so it is not quite so big. It's bigger than it was designed and used to be, but maybe better anyway for those with sore eyes. Truth is that latest gtkdialog is not allowing width-requests for input boxes lower than about 160 pixels, which is far too high in my opinion (160 is pretty big...). I don't know if just a result of GTK+3 variant or if source code changes done by someone up at its Puppy github site have spoiled scaling (maybe for the sake of something wayland, but I am just guessing based on one push I noticed - I don't have time to get back into gtkdialog coding again so just living with it anyway - it's okay this size on my machine; however window and text width-request settings definitely being ignored to some extent in recent gtkdialog upstream code... so expect other gtkdialog apps to look a bit strange at times I think).

To use the 'fixed' scaled version of weX, should just be a matter of re-running the install_wex.sh script I uploaded already (that doesn't need changed since it just auto-downloads the fixed version I alreay uploaded to my gitlab site).

Ok, I'm biased, but considering its small size addition, but capability, I thoroughly recommend including wex/precord/scrot/gifenc (animated gif) addition in KLV iso downloads since gives lots of extra facility out of the box in a couple of hundred kilobytes.

cheers wiak.

[Clarity]

... ... Basically, I think it is nice to include audio/video/webcam/screencast/scrot-screencapture out-of-the-box in distro download. I don't know if @rockedge wants to use the same or alternatives, but the option is there. ...

For a local PC use, this seems reasonable and simple. And, its addition into the ISO seems meager, in appearance.

Looking forward to the progress this distro is providing to us Puppy forum distro users.

[fredx181]

Hi All, nice to see this development, e.g. sharing SFS's etc..

Did some more testing of Sfs-load "on the fly" (using symlinks) and noticed:

If an .sfs contains e.g. /sbin, /lib as true directories, the files inside will NOT merge into the system.
This is because KLV has "merged-usr",(all binaries and libraries in /usr/bin /usr/lib and /sbin /lib are symlinks).
To avoid this problem, the binaries should be in /usr/bin or/and /usr/local/bin and libs in /usr/lib inside the .sfs.
(or build the system without merged-usr, Debian's debootstrap has such option --no-merged-usr, don't know about Void).

Also I tested loading an .sfs at boot containing /sbin (not symlink) and got a kernel panic (which makes sense to me).

[rockedge]

Good information on some of the issues to avoid building SFS's or adapting existing SFS's to operate in the KLV environment.

@wiak I plan on adding weX into the KLV-Airedale base. It's just such a powerful tool that being installed in the base version makes lots of sense.

[mikewalsh]

Redesign time again.

I wanted something more like what I'm used to (yeah, I know; I'm an old fart, "stuck in the groove"..! ) So I did what I could, within the limitations of the XFCE desktop; one area where JWM/Rox is "king' as far as I'm concerned is in its ability to fine-tune placement of items, literally to the pixel.

[Click to enlarge:-]

I couldn't find an Airedale icon. So, I've made do with the best-looking icon I could find.....believe it or not, that is supposed to be a Shina Ibu sitting in that there "button". Looks good, though, don't it?

Onwards & upwards.....

------------------------------------------------

One wee bit of info for anyone who's interested; as expected, the Tixati torrent client runs flawlessly here in 'Airedale', especially if you make sure to snag the 'portable' version from the main website. Frankly, I'd've been extremely surprised if it hadn't, since this is one of those apps that just seems to run absolutely anywhere. This is actually just like the Textmaker-portable; as Mochi found out, the portable is exactly the same as the 'standard' install, with the addition of a small, specifically-named text file. If the app encounters this text-file during start-up, it keeps itself self-contained, and writes everything back inside its own directory.

This text-file doesn't even have to contain anything; it's just the existence of the file-name that triggers the behaviour.

The portable contains both 64- and 32-bit binaries for not just Linux, but also Windows within, so it's good for sharing remotely between multiple Puppies of either architecture, and even with MyCrudSoft's juggernaut if you can't bring yourself to abandon it for good. You CAN send the binary direct to the desktop, but it looks a bit messy.....easy enough to bang a .desktop file together for a 'proper' launcher.

Me, I just download it, swap the Linux binaries over, & discard the M$ ones.... (*shrug*)

You can find Tixati here:-

https://tixati.com/

Currently @ v2.8.7.

Mike.

[wiak]

Redesign time again.

I wanted something more like what I'm used to (yeah, I know; I'm an old fart, "stuck in the groove"..! )

It is probably just to do with what I'm used to, but funnily enough I don't like the way standard XFCE desktop 'looks' either (thought the XFCE operation and utilities are great).
Your redesign looks extremely functional and straighforward as well as attractive.
In practice, however, it can be extremely difficult to 'script' a desktop's appearance at build time (and there are already so many technical concerns to script at that time) so in practice it makes sense to stick close to standard XFCE desktop at the release iso stage and leave it up to users to customise to their preferences. What can be useful if script can be provided that automates a new desktop look and feel, but like I say, that is often not easy to arrange. The nearest we often see are various 'theming' utilities.

[bigpup]

Do not want to look back at earlier posts, to see where this was.

Someone posted that SFS load did not remember loaded choices on reboot.

I find that to be true, but I have one SFS that is getting loaded at every boot.
It is a SFS of Pale Moon browser.
I do have it selected as the default browser.
Maybe something about being default browser is making it be loaded between boots.

I changed my install of KLV-Airedale to alpha 6.
I used the save directory from the old alpha 5 install. (sorry i am not in KLV-Airedale right now ,so not sure what that directory is called)
Everything seems to be as it should be that is in this directory.
Stuff I installed in alpha 5 is still there.

Just wanted to report this while I remembered it.
Not home right now and typing on one of those evil Windows machines.