KLV To-Do List

[wiak]

But what if you want to try wayland with Fedora? Well easiest is just to do same as in my above post, but instead of:

dnf group install XFCE

do:

dnf group install GNOME

since Fedora uses Wayland with that...

Actually, I'm in it right now (5 min after being in XFCE build...) and it runs very nicely on this laptop of mine. I don't myself like GNOME user interface though - maybe I'm old fashioned, but still prefer XFCE style (i.e. a bit like Windows 7 look and feel really). But fun playing with GNOME and probably best current environment to test out Wayland apps. Fedora also does have group for Sway (Wayland using too):

dnf group list --hidden | grep Sway

and install it therefore with:

sudo dnf group install "Sway Window Manager"

but Sway needs fair bit more work to get it all going...

[wiak]

My kid just came over and said XFCE, pointing to the Desktop background squiggly image (see my desktop post above with the attached image).

viewtopic.php?p=95950#p95950y

(You can't really see it in that cropped image, but you will if you look closely at that whole desktop background provided as option by XFCE).

And sure enough, there amongst the squiggles are the distorted repeated letters: xfce

[rockedge]

There it is plain as day....... Now I see it clearly but without the hint no way

[rockedge]

Using the same basic plug file to build a KLF except running a JWM desktop as demonstrated in a Xnest instance set as DISPLAY=:1 started with

Code: Select all

xhost +
Xnest :1
export DISPLAY=:1

Screenshot(49).jpg (39.06 KiB) Viewed 12479 times

using the chroot mount and umount scripts with the freshly built fristrib_rootfs in a Xnest instance as display :1 is very handy for configuration of a desktop because of the ability to directly read+write to and from the uncompressed firstrib_rootfs and see the results and effects of an install or configuration running immediately.

[wiak]

So this is just a minor matter I've thought about for a while.

Back in early 2019 when I was simply building firstrib_rootfs (had no FR initrd) and then running it under a chroot on host system I also created the script mount_chroot.sh and clean up script umount_chroot.sh

But for a long time I've been wondering why I hadn't just combined the two back then such that after exit from the chroot the clean up routine simply runs; that's what I do in similar scripts afterall...

I wondered if there might be a good reason I wanted to keep them separate, and certainly when something goes wrong it has proved useful at times to have a separate umount_chroot script. But, overall, it is more convenient not to have to run a second script...

Finally today, I decided to also therefore make a single/combined variant called mount_chroot_umount.sh

As expected it seems to work and saves that double script usage pattern. Hopefully there is no great reason I have forgotten about. I doubt it; I probably just never got round to making a combined version.

If you want it, you can download it in usual fashion:

Code: Select all

# Utility mount_chroot_umount.sh: mount_chroot and umount_chroot scripts combined
wget -c https://gitlab.com/firstrib/firstrib/-/raw/master/latest/build_system/mount_chroot_umount.sh && chmod +x mount_chroot_umount.sh

If I am not thinking straight and something very wrong with the combined script, please let me know! - some days are like that...

[williwaw]

if you open a terminal and then at some point run ./mount_chroot and do some stuff...
then forgetfully or accidentily close the terminal, what happens to the chroot?
should you open a new terminal and run ./mount_chroot to do some more stuff, have you created two chroots?

how do you clean up the chroot/or both chroots? does umount clean up all chroots?

[wiak]

if you open a terminal and then at some point run ./mount_chroot and do some stuff...
then forgetfully or accidentily close the terminal, what happens to the chroot?
should you open a new terminal and run ./mount_chroot to do some more stuff, have you created two chroots?

how do you clean up the chroot/or both chroots? does umount clean up all chroots?

If you accidentally close terminal, just open it again and do ./umount_chroot.sh <dir_name>
That should clean up what you forgot.
You can check if cleaned up using simple 'mount' command on its own. If you see the chroot mounts still active you know you didn't clean them up.
If you use ./mount_chroot.sh twice, I'm not sure what happens then; I have never done that! but imagine just takes you back inside the chroot since mount binds already active so on exit just ./umount_chroot them again.

But maybe this is why it is better to use that new script: ./mount_chroot_umount.sh <dirname>
since it ends by cleaning up once you exit (but of course if you accidentally close terminal, you better open new one and ./umount_chroot.sh <dirname>
Maybe that's why I kept separate mount_chroot and umount_chroot scripts; I can't remember.

[rockedge]

if you open a terminal and then at some point run ./mount_chroot and do some stuff...
then forgetfully or accidentally close the terminal

I do this al the time! Like wiak posted, going back and running the umount script will clean it up. I have even used the mount again first to see what state the chroot 'ed rootfs is in at that moment.

I found it's pretty robust and tolerant of forgetting to umount and going back to fix it

[wiak]

@rockedge

I'm in KLV-Airedale just now.

I have a question... What was the reason for that sleep 5 in /usr/local/bin/start-up script?

I commented it out and don't see to have any issues and nice to shave that annoying 5 seconds off the boot-up time. However I haven't tested for long and perhaps I'm missing an effect I don't know about?

[rockedge]

@wiak the sleep 5 was a workaround for some timing issue with starting pulseaudio from a script in /root/Startup that may not exist anymore. I just have not tested whether or not it is still needed. There was intermittent failures of the pulseaudio daemon starting on some systems because of devices still settling down that we countered by the adding the pause. I'll remove it as well and see what the effects are that I can find.

[geo_c]

@wiak the sleep 5 was a workaround for some timing issue with starting pulseaudio from a script in /root/Startup that may not exist anymore.

I can tell you that my version of KLV-spectr-RT has some issues with pulseaudio starting correctly. I normally find myself starting it from time after discovering it's not running. When I start it, it works however.

[wiak]

Despite the fact I have no time to do so... I'm currently (at this exact moment) doing some dev work on KLV sway release. Reason is simple: I want to use Sway as my main desktop for next few months since I liked my early play with it. Basically I'm inspired by all the new tiling wm work, but also want to work in Wayland, so Sway is the one for me.

However, I need more utils and functions available so fits my usual work practices; of course if this proves to be taking more than a day... I'll give up on that for now...

[wiak]

Sway stuff pretty much all found now. I just need to include it all in next build plugin.

The other thing I'm looking into is better AppImage handling because I believe that is one of the best ways to keep distros small and share big apps; basically I don't feel that sfs-load-on-the-fly is worth any time of effort. I don't like snap and am not convinced by Flatpak at the moment; perhaps my mind will change on these but I still enjoy using the occasional AppImage, which though large are very convenient and when shared with multiple distros their size is fine for me (and overall not larger than snap or flatpak anyway as far as I know). Main thing I want in this AppImage regard, however, is a flexible elsewhere maintained AppImage manager and I've found one that I'm currently about to evaluate:

https://github.com/ivan-hc/AM-application-manager

Maybe even more useful: https://github.com/ivan-hc/AppMan

Whilst home-grown portable type constructs have been very useful to many over the years, we are not getting any younger, there are other pieces of dev work everyone could use more time to involve themselves in (FirstRib plug building, for example! ), and maintenance of large app addons is so important we'd need a whole team working on that if we relied on forum members; better to 'outsource' that kind of work IMO.

What programs can be installed
AM installs/removes/updates/manages only standalone programs, ie those programs that can be run from a single directory in which they are contained (where $PROGRAM is the name of the application, AM installs them always into a dedicated folder named /opt/$PROGRAM).

These programs are taken:

from official sources (see Firefox, Thunderbird, Blender, NodeJS, Chromium Latest...);
from official .deb packages (see Brave, Vivaldi, Google Chrome...);
from the repositories and official sites of individual developers (if an archive is not available, an official AppImage is used, see Libreoffice, OnlyOffice);
from tar archives of other GNU/Linux distributions (see Chromium, Chromium Ungoogled...);
from AUR or other Arch Linux-related sources (see Palemoon, Spotify, WhatsApp...);
from AppImage recipes to be compiled with pkg2appimage and appimagetool (see Anydesk, qBittorrent, Dropbox, all the games from the "KDE Games" suite...);
from unofficial repositories of developers external to the project concerned (most of the time they are programs in AppImage format), but only if an official release is not available (see the various WINE, Zoom, VLC, GIMP...).
"AM" can even create Firefox profiles to run as webapps (as an alternative to the countless Electron-based apps/AppImages)!

Interestingly (useful I feel), note well:

NOTE: "AM" consider AppImage not to be a priority format, but only a fallback, because if a program is already made available in a bundle by the main developer, "AM" will prefer it. Some examples are given by Firefox, Thunderbird, NodeJS, Blender, Chromium Latest, SuperTuxKart... they are all programs provided in bundle, no other kind of package manager is really needed for them.

EDIT: AM (AppImage Manager) proving to be very easy to install and use. Great so far. It's BRILLIANT thus far - simple to use:

Code: Select all

am -h  # for usage help

am -l  # (small L for List available apps) and use / to search for appname

am -i <appname>  # to install under /opt/am hierarchy

Over 1800 AppImages available via AM:

YOU HAVE INSTALLED 2 APPLICATIONS OUT OF 1802 AVAILABLE

LIST OF THE 1802 APPLICATIONS AVAILABLE IN THE 'AM' REPOSITORY:
...
◆ librecad : 2D CAD program written in C++11 using the Qt framework.
◆ libreoffice : Free and open source Office suite (choose a version).
◆ libreoffice-fresh-full-help : Office suite (includes manuals).
◆ libreoffice-fresh-full : Office suite (latest, includes all languages).
◆ libreoffice-fresh-standard-help : Office suite (includes manuals).
◆ libreoffice-fresh-standard : Office suite (latest, european languages only).
◆ libreoffice-still-full-help : Office suite (includes manuals).
◆ libreoffice-still-full : Office suite (stable, includes all languages).
◆ libreoffice-still-standard-help : Office suite (includes manuals).
◆ libreoffice-still-standard : Office suite (stable, european languages only).
◆ librepcb : Design Schematics and PCBs.
◆ libresprite : Animated sprite editor & pixel art tool.
◆ librewolf : Firefox-based Web Browser focused on privacy, security, freedom.
...

Code: Select all

root@mcewanw-HP-ProBook-430-G8-Notebook-PC:/opt# du -hs am
236K	am
root@mcewanw-HP-ProBook-430-G8-Notebook-PC:/opt# du -hs cherrytree
105M	cherrytree
root@mcewanw-HP-ProBook-430-G8-Notebook-PC:/opt# du -hs chromium
145M	chromium
root@mcewanw-HP-ProBook-430-G8-Notebook-PC:/opt# du -hs ferdium
140M	ferdium
root@mcewanw-HP-ProBook-430-G8-Notebook-PC:/opt# du -hs firefox
230M	firefox
root@mcewanw-HP-ProBook-430-G8-Notebook-PC:/opt# du -hs libreoffice
317M	libreoffice
root@mcewanw-HP-ProBook-430-G8-Notebook-PC:/opt#

I'll likely modify the operation of AM for my particular use though, or more likely write short 'helper' script. I want the am installed stuff to end up in a folder accessible by all my installs rather in /opt/am of one particular distro (though could use symlinks to there of course, but would have to move the am-desktop files from /usr/share/applications and also the symlinks maybe from /usr/local/bin to wherever I want everything.

An alternative (that can probably be used in parallel if wanted?): https://github.com/TheAssassin/AppImageLauncher
Regarding AppImage upgrading, see also: https://appimage.github.io/AppImageUpdate/

AppImageUpdate updates AppImages based on the update information embedded in AppImages

@BarryK also has an AppImage/Flatpak manager he created/uses in EasyOS: https://forum.puppylinux.com/viewtopic. ... 665#p92665
Comparison: https://forum.puppylinux.com/viewtopic. ... 04#p100004

[wiak]

I wish I wasn't so non-computing busy these days because there is so much I need to do.

Make no mistake, most users of Linux benefit from using and understanding permissions, for example, re files and directories. In education, learning that level of system admin is essential, so you need multi-user support and most often the likes of PAM.

But it doesn't end there. Fortunately, base upstream installs tend to sort most of that out, particularly with desktop environments like XFCE. However, as I painfully encounter, the likes of sway for Wayland tends to need more expertise. In particular, we need to understand a bit more about udev, dbus, polkit, and for filemanager expected operation, a general understanding of udisks2. Each of these involve configuration, sometimes beyond the provided defaults, to get the likes of auto-mounting to work, whether logged in as a regular user or as root.

On this forum, people tend to pick up 'tricks' and create workaround scripts like run-as-spot, but sometimes the technology workarounds used are not the best, or may introduce other serious issues. At other times we google search for tips and tricks, but a huge percentage of such are out of date. In the end there is no better alternative to learning the basics of what is current now along with finding out what is now old and obsolete. Hence I myself am concentrating on learning more about dbus, polkit, and udisks2, for example, rather than endlessly trying Google search tips hoping that some will still work... And of course, some understanding of systems is necessary for most distros nowadays, but I'd say, dbus, polkit, and udisk2 configuration becomes essential overall. No accident these would be considered essential for distro-inclusion/study in any tertiary education Linux admin course.

Well, once such config work is accurately done in any f_plug, then less-experienced distro creators can more simply use such extracts as patterns and code templates, which is a useful characteristic of FirstRib build methodology.

[wiak]

Finally, after some ridiculously long days, found a way of logging in to Sway/Wayland desktop as regular user spot and then being able to get gvfs working. Problem became getting it also working with root (actually I had already found out a method but it slipped from my brain until I thought of it again...).

So now I have key combinations for starting up pcmanfm as user root and similarly geany as user root.

Aside from usual 'dangers' I will have to check that I do not accidentally change spot file/dir permissions while modifying matters as user root

However, at least gvfs is also working for auto-mounting now with pcmanfm as user root (from spot-user desktop). This may not sound much of an achievement, but was actually somewhat tricky (involving polkit-1) - easy once I knew how though...

Overall, I expect the way I have this working in a fashion that is useful to me is not in fact the best. That will have to wait, but I expect to publish a new, more complete, KLV_WaylandSway distro soonish, which will include the plugin lines required for the polkit-1 and dbus run scenarios. I'm taking a break just now though and still have to put the final f_plug altogether, which will take a while since I keep missing little bits out by accident...

I do now favour AppImages for larger files, but will probably include firefox in the plug-build for convenience at the moment (in practice I nearly always use chromium so will include AppImage Manager (am) ready and working to install AppImage of chromium for the system (and similarly using AppImage for Libreoffice).

Oh, forgot... I still have to configure Waybar, which I've installed but never tried as yet (just getting by for now with simplistic swaybar).

[wiak]

Amazing this Wayland stuff.

I included labwc in my Sway build (was only a tiny few MB extra). So I decided to run it in Sway... and got it to start up sakura terminal inside it, and also xfce4-panel...

Isn't using much CPU on this machine at all... Around 99.5% idle and firefox running too as attached screenshot show. I'm posting from it right now.

Forgot to also run Waybar. Top bar is just the basic sway-bar, but, being as I am, I actually prefer that and don't like transparency and similar mad(dening) effects. I kind of like this system - no frills at all; only things important to me personally is being able to open terminals, file manager, editor and browser conveniently as either regular user (spot here) or root. I'll leave polish and jingles and themes to others.

The reason I like basic/simple is that I'm lazy and can't be bothered having to configure systems. I'll leave that kind of thing up to Sofiya!

Middle tiled in Sway panel below is actually the labwc window with sakura terminal running inside it.

Used 'grim' for the quick screenshot.

Note the wee somewhat insecure 'trick' in my .bashrc:

Code: Select all

# to run app from spot as root user: gks waylandapp
gks () { xhost +si:localuser:root; sudo -H "$@"; xhost -si:localuser:root; }

Yes, xhost can be used like that with Wayland. Sometimes you can just use: sudo -HE wayland_program, and other tricks involving env commands can allow running as root from regular user desktop too (despite Wayland intended overall for not running GUI apps as root user...). For example, in my current sway config I'm playing with:

Code: Select all

bindsym $mod+Shift+f exec 'sudo env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY"  XDG_RUNTIME_DIR=/user/run/0 dbus-run-session -- pcmanfm'

[geo_c]

That looks nice!

I really like these tiling window managers. Bspwm looks way nicer than Xfce (at least the way @Sofiya configured it)

It seems to me that the colors are more pure, and the font rendering is more crisp. Add to that the ease of opening apps and sizing them, which is mostly automatic. Makes for a great workflow.

If we get this sway/wayland and eventually pipewire going then we're looking at the fastest and leanest multi-instance, frugal, multi-user, cutting edge desktop environment. Of course if someone is looking for the KDE heavy animation desktop, that's another matter which I personally have no interest in.

[williwaw]

I expect to publish a new, more complete, KLV_WaylandSway distro soonish, which will include the plugin lines required for the polkit-1 and dbus run scenarios. I'm taking a break just now............

Thanks for working on wayland.
Looking forward to the plug. Earlier, I was looking at some other plugs with gvfs, and wondering where and how each of the plug components fit int to the overall design. The commenting in plugs is appreciated and is a useful method to document your work.

[wiak]

Most of you guys might find the following interesting (and more so since we could drive its root filesystem with FR initrd and turn it into a KL with all the usual utility apps):

https://github.com/axyl-os/axyl-iso

My only concern is that it has been 10 months since anything done to it, but then again, it is using Arch Linux so a rolling-release distro anyway so can update its root filesystem prior to KL/FirstRibbing it. However, reading github "issues" suggests has been 'abandoned' but ways to update most of it are suggested so a fork of the github repo could be resurrected, and specially since we have fair bit of experience with tiling wm setups here. Great thing about tiling is that its managers tend to be all quite small so pretty easy to make multi-wm-capable distro without much at all in the way of excessive bloat. I imagine different variants have their own strong-points; i3, for example, doesn't see to have autotiling support (though Sway does).

Unfortunately, for me anyway, it says on its github release page:

What To Look Forward To?

Wayland WMs coming soon! Wayland dev has been permanently halted.

I wonder why; anyway we could add that ourselves. Perhaps something to do with Nvidia support since maybe still problems there (I don't have that graphics card).

[geo_c]

Unfortunately, for me anyway, it says on its github release page:

What To Look Forward To?

Wayland WMs coming soon! Wayland dev has been permanently halted.

I wonder why; anyway we could add that ourselves. Perhaps something to do with Nvidia support since maybe still problems there (I don't have that graphics card).

Seems to me that if you packaged an iso that creates a KL-multi-instance boot, it would be possible to have one system under the hood and a separate layer in each instance for the window manager, thereby allowing to have installs of all the window managers to choose at boot rather than simply choosing one at install.

So I guess what I'm suggesiting is no window manager in the main install folder, and have a pre-configured window manager layer in each instance.

Along that line of thinking, perhaps a tweaked FR_minimal-void script could be the base system with no window manager in the root fs, and then the window managers could be setup in separate plugs to create an additional layer that would reside in each in instance. Something like that.

Of course, they would all have unique upper_changes and therefore would not share file changes, unless some directories were symlinked to a shared location. So installing new applications would require doing it for every instance.

[wiak]

Unfortunately, for me anyway, it says on its github release page:

What To Look Forward To?

Wayland WMs coming soon! Wayland dev has been permanently halted.

I wonder why; anyway we could add that ourselves. Perhaps something to do with Nvidia support since maybe still problems there (I don't have that graphics card).

Seems to me that if you packaged an iso that creates a KL-multi-instance boot, it would be possible to have one system under the hood and a separate layer in each instance for the window manager, thereby allowing to have installs of all the window managers to choose at boot rather than simply choosing one at install.

Well that's perfectly correct and a best-use sort of scenario for KL_multi_instance arrangement, and overall very low resource cost too - just different instance upper_changes and even then there can be additional symlink sharing of some parts of that; as long as each instance package manager database not 'broken', but generally that could be easy since one instances pkg manager database knows nothing about the others so effectively can use bits from other instances with individual instance not having a clue about it, which is fine!

[wiak]

I'm looking into an alternative Sway config. The website makes it look like a distro, but actually it is mainly a config that relies on an already base distro build, with Void Linux being one of its targets. That makes it potentially almost immediately useful in a special SwayOS KL/FirstRib build. Interestingly it involves a fair amount of compiling of useful Sway-usable extras, but the provided setup-void.sh script does all that so that much is easy. I don't have it going yet, and may need to produce a cut-down Sway (actually maybe just a slightly modded version of the KL_mini Sway I produced). Here is the SwayOS site, that also contains links to its github:

https://swayos.github.io/

Being no expert at all in Sway/Wayland configuration, assuming this SwayOS config is done well, it could be a very interesting build. It is a bit huge as supplied, so I'm hoping I can later extract only the main config material and the now compiled (by the script extras). Maybe later when I have more time though, or someone else might like to try it.

Overall, even as things stand, I'm really hooked on Sway now and see me sticking with it in practice for a while now.

Well... my first quick swayOS on top of KLV_SwayBASE has only partially worked. All the apps are there, but the configs aren't working in a pretty way. I need to study it all better, and maybe end up just extracting the parts I want for a later build...

Ah, it is closer to working as intended than I thought. Just some issue with exec apps from sway config not starting up for some reason, so waybar wasn't appearing. Manually starting it and I start to see the results...
Just rebooted and waybar is now appearing. It has some launchers on it next to the clock but just dark squares at the moment so something not quite right, but probably close to what the config author intended. So far I prefer my own config but some nice tricks I can learn from this one, particularly the waybar launchers, but I need to get their icons to show to be useful. Probably simple.

[wiak]

Though owncloud references were using correct latest FR initrd fetches, I have now however updated the likes of FRmake_initrd.sh to use initrd-latest.sh version stored at same site in order to avoid any possible future problems. You do need to always use/fetch core FR scripts only from gitlab firstrib site though rather than backup copies of your own, which could well become out of date.

wget -c https://gitlab.com/firstrib/firstrib/-/ ... -latest.gz -O initrd.gz # FR skeleton initrd

# Some useful FirstRib utilities in case you want to modify the initrd or the 07firstrib_rootfs
# All these utilities have a --help option
wget -c https://gitlab.com/firstrib/firstrib/-/ ... grubconfig && chmod +x wd_grubconfig # When run finds correct grub menu stanza for your system
wget -c https://gitlab.com/firstrib/firstrib/-/ ... itrd_gz.sh && chmod +x modify_initrd_gz.sh # For 'experts' to modify initrd.gz
wget -c https://gitlab.com/firstrib/firstrib/-/ ... _chroot.sh && chmod +x mount_chroot.sh # To enter rootfs in a chroot
wget -c https://gitlab.com/firstrib/firstrib/-/ ... _chroot.sh && chmod +x umount_chroot.sh # to 'clean up mounts used by above mount_chroot.sh'
wget -c https://gitlab.com/firstrib/firstrib/-/ ... _umount.sh && chmod +x mount_chroot_umount.sh # combined mount and umount chroot...

# FRmake_initrd.sh and dependencies
# for when you want to make a special FR initrd for official non-hugekernels
# (i.e. the resulting initrd uses Tomas M method of slimming number of necessary boot modules and then including them in the FR initrd created)
wget -c https://gitlab.com/firstrib/firstrib/-/ ... _initrd.sh
wget -c https://gitlab.com/firstrib/firstrib/-/ ... trd_dep.sh

# and kernel extract optional helper program (which tries but doesn't always find the kernel)
# Note that I haven't used this in a long time so forget most about it; I usually extract kernel manually when building like that
wget -c https://gitlab.com/firstrib/firstrib/-/ ... _kernel.sh

# If you use either of the following (e.g. in your KLgtkdialog_filemnt addon sfs) make sure you are using latest as below:
wget -c https://gitlab.com/firstrib/firstrib/-/ ... m/wd_mount
wget -c https://gitlab.com/firstrib/firstrib/-/ ... m/wiakwifi

Please let me know if you stumble across any errors. Though you cannot prove this nowadays, I am human and not AI (and you couldn't trust AI anyway).

[wiak]

Made slight (almost irrelevant just now maybe) tweak to the FR initrd (so now version 702rc2); added f2fs FR initrd modprobe support for non-huge-kernels and modified FRmake_initrd_deps.sh accordingly to include that too. Whether booting is possible by grub2 from f2fs seems to depend how the format is used though - apparently extra_attr flag to allow useful features messes with grub boot, but just what I read so don't know for sure. Anyway, the facility is included in case useful and only relevant when non-huge-kernel used.

[Clarity]

I have 12 KLs on each of 2 of my 32GB USBs I have. One of the bootable USB is Ventoy v1.071 whose VEntoy partition is formatted ext2, while the other is Ventoy v1.0.96 formatted as exFAT.

I'm expecting to report tomorrow on the results of using these 2 USBs booting each of the ISOs. The Ventoy distros contain some WoofCE ISO files as well for testing on each USB. Lastly each USB also has an SG2D ISO available to be used to test each ISO for booted on it as well.

I currently have 12 KL distros:

Code: Select all

root# ls KL*
KLA-OT2baseCE-2.9.iso     KLV-Airedale-RT.iso    KLV-BspwmCE-1.5.iso
KLA-XFCEpodman-1.1.iso    KLV-Airedale-sr6.iso   KLV-Spectr-beta3.iso
KLF-Rawhide-CE-1.2.iso    KLV-AwesomeCE-1.3.iso  KLV-Spectr-RT.iso
KLU-jam-XFCEbase-1.1.iso  KLV-awesome-RT.iso     KLV_SwayBASE-002rc4.iso

This combines to over 50 tests for KL and WoofCE ISO files to be in the report. The report will address booting the USBs on one of the Intel platforms I have.

I will report on desktop operation should I run into problems in desktop use for each ISO that boots; iff something obvious is seen.

[wiak]

This combines to over 50 tests for KL and WoofCE ISO files to be in the report. The report will address booting the USBs on one of the Intel platforms I have.

I will report on desktop operation should I run into problems in desktop use for each ISO that boots; iff something obvious is seen.

We know that some KL distros will currently not boot even from Ventoy formatted ext2, and I've indicated the ones that will boot from Ventoy formatted as exFAT. The booting to desktop can easily be fixed via grub.cfg alteration and inclusion of exFAT kernel driver support (which is needed for KL distros, anyway, to boot from exFAT Ventoy stick).

However, it is rarely enough to simply be able to boot to desktop. Most everyone later wants to save configs and often install new apps; therefore, the key test is whether save persistence works with suitable "Persistence" LABELLED partition for that purpose. The same would go for Puppy Linux distros - some may well boot easily enough to desktop, but main check would be: does save persistence work; if not, then not much use really.

This is the problem with Ventoy being touted as the most convenient for new users mechanism; that would only be true if it always worked with all distros, but as has often been shown that is so difficult to ensure that it tends to be a poor recommendation since failure results in user frustration. Normal frugal install almost always can be made to successfully boot and not with much effort either; key thing for simplicity and likely success is always to install to a Linux formatted partition (normal frugal install to exFAT is only going to work if suitable savefile used; the generally more convenient save folder simply won't work there).

So, whilst I find Ventoy useful myself (since I take care to make sure I can boot my own KL creations with it, and with exFAT) I actually think it is not a good beginner system at all (and I really don't like SGD2 at all - the complexity that involves in its menus is never for a new user).

Could Ventoy be a good new user system?; yes, if both the Ventoy stick and the distro designers carefully arranged matters to work it would be; but in practice persistence with Ventoy is at best very hit or miss and that situation is not improving over time. But anyway, that is the key test: does save persistence work? If not; best to just leave Ventoy for those who know how to get the best out of it - it is certainly not a trivial way to achieve successful boot at all - and that's a fact that is well known and demonstrated time and time again.

I've nothing against Ventoy; it is a good idea, and has uses for me, but chances of all forum distros working with it (including persistence) is flaky at best. It is certainly one way of quickly getting a (somewhat strange) grub2 booting usb stick, but again not the best.

An example of the problem recommending Ventoy causes: you recently recommended it as sure fire easy way to boot KL-Spectrum distro to Gnimmelf only to later discover it wasn't in fact able to boot that distro (it was worth a try, but no more than that and confused matters somewhat overall I feel). That kind of situation causes a lot of time-wasting and Ventoy is not famous for its save persistence likelihood (without expert knowledge and lots of fiddling around); Ventoy proves at time to be a bit of a trap when what worked no longer does.

My feeling, therefore, is that it is good to have a couple of howto docs or whatever on Ventoy as a solution that 'may' prove useful to some, and I myself certainly try to make it function reasonably well with distros I create. But otherwise, pushing Ventoy as the do everything always working solution, every time someone has a problem booting, is just meaningless and misleading in practice. What could be, simply isn't, and it has been around for years, and save persistence is simply not that easy to achieve except in designed for normal frugal installation; and that is how things are likely to remain overall.

But tests using Ventoy are useful. Indeed recently your Ventoy report accidentally resulted in my finding a nothing-to-do-with-Ventoy major issue regarding old FR initrd being used. However, I truly doubt such reports will change much about Ventoy distro support over all; main thing is certainly to test save persistence - booting without that is near irrelevant except for casual desktop checks. Overall though it remains much more important to ensure normal frugal booting is achievable and to help others manage that, and second comes Qemu usage since that is main way aside from bare-metal booting that most testing is actually done. Despite your opinion, Clarity, normal frugal installation is always going to much easier to achieve than Ventoy with save persistence - the whole way of doing that could be streamlined to make it easier still; only problem is grub2 installation (which is the one advantage Ventoy really comes with). Puppy Linux does have grub2 installation methods, but I certainly don't want to have to install Fossapup every time I simply want grub2 on my usb stick (first thing I have to do is usually then delete Fossapup - shouldn't be necessary to actually install it along with the grub2 configuration).

The likes of exFAT support (to a certain extent) and f2fs is important more generally however, so good that you have focussed our attention on these I think.

[rockedge]

Seems exFAT is a Microsoft - Apple format....... Unfortunately the usage case being predominant with pre-formatted USB flash drives.

My 3D printer can only see exFAT formatted USB drives which is odd because the embedded operating system is Linux based.

[Clarity]

Both of you are expressing what I have been watching over the past 6 years. Started when one of my TV using AndroidTV (now old) formatted a USB for its use as exFAT.

The forum distros could keep pace with industry as the industry intends to address as many people as it can; same objective we have as we want new users to come-in and hopefully contribute to inprovements along with member growth for distro and use validations.

I agree with all of what each of you are sharing.

[fredx181]

The forum distros could keep pace with industry as the industry intends to address as many people as it can; same objective we have as we want new users to come-in and hopefully contribute to inprovements along with member growth for distro and use validations.

Perhaps better to ignore some (or most) of the new shiny changes that the industry has and keep seeing Linux as being different from the 'mainstream' , which has some limitations of course to cope with, and live with it.
Just a thought, perhaps more idealistic than realistic

[Clarity]

Actually, I said

The forum distros could keep pace ...

when I should have said "The forum does keep pace ..."

This is obvious as the forum responds appropriately and continually to keep its offering current.