KLV To-Do List

[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.

[wiak]

Tonight been mucking around reminding myself how to use Qemu. I don't use the likes of Aqemu; I prefer just using commandline (and taking appropriate notes in my cherrytree notebook).

Actually, I was also doing a Clarity type trick booting Ventoy physical usb stick via Qemu too; not really so much point to that for me though since can just instead boot the isos it contains directly.

My Ventoy stick does have a special third partition that I labelled "Persistence" as I documented elsewhere

viewtopic.php?p=101793#p101793

and so (with nothing to do with Ventoy) that proves useful to me in direct Qemu boot of the likes of KLA-XFCEpodman where I use boot -d to boot the KLA iso image but also attach the physical usb stick (as a -device format=raw) that has that "Persistence" partition, which immediately allows me to use the Qemu boot menu choice for RAM2 save on demand mode to Persistence partition. I'm also playing with Ctrl-Alt-2 to enter qemu monitor for experiments with usb pass-through techniques in already running Qemu vm.

Using the physical usb stick along with the iso image is pretty handy. Qemu is really nice to the extent that Ventoy is a bit irrelevant for me really. Still, nice to have that Ventoy usb stick that also has that Persistence partition for general RAM2 save on demand usage in Qemu (without using Ventoy itself - though using Ventoy as boot usb from Qemu also working fine though for that we do need the exFAT support and appropriate Ventoy-related grub.cfg and so on in iso/boot/grub).

[Clarity]

For me, I test the Ventoy stick to get a lead on what would/does happen when booting on bare-metal. Useful from that standpoint.

Your test pattern is great in that using the stick containing ISO files, you:

• can path to the ISO file directly on that USB in a QEMU stanza
  OR

• you can boot the bootable USB stick in a QEMU stanza

to validate behavior knowing what to expect or look-for when using the USB and/or on bare-metal. Faster results by using QEMU. And I can test multiple VMs simultaneously on the desktop while the host allow productive work as well.

Its win-win.

In my case, I handle my persistence differently as I want the VM to appear physically as close to bare-metal as possible. Since, on bare-metal, I keep Persistence on bare-metal's system drive versus on a USB (for very obvious reasons). So, on QEMU, I boot the USB and use a 2nd drive in the stanza. That 2nd drive is labeled "Persistence" with a Sessions folder used to mimic how I do things on bare-metal. All of my save-sessions for every distro that provides persistence is kept in that same Sessions folder...everywhere.

I have tested this arrangement on QEMU in its default BIOS VM as well as QEMU in a UEFI VM. This mimics a PC with a system drive booting from either of the 2 boot launchers; namely Ventoy or SG2D USB.

QEMU with "boot D" in its stanza is the same as booting a bare-metal with a DVD used to boot the PC.

This parallels what you are doing.

[Clarity]

This post just reminded me of a test case setup PC that I need to resurrect as it was useful.

I had a test PC that I had been using for several years. But is died around the beginning of the summer and I never replaced it.

This is the pertinent piece of that test machine.
I think it was @mistfire, IIRC, that helped me with the script (the script, too, was lost when I discarded that PC). The script was used to create a RAM disk. I had imaged that RAM disk from a bootable Ventoy USB.

I would download a ISO file, load it onto the Ventoy RAM disk and boot accessing it in a QEMU VM. This reduces the turn-around time for a given test ENORMOUSLY because the ram disk is SO MUCH FASTER than the physical USB sticks. This way, the wait to copy the downloaded ISO file in order to test using a physical USB was shortened by copying to the ram disk versus physical USB. I perceived (not measured) a faster boot of the ram-disk version than the USB as well. AND, most importantly, it gave a quick reasonable expectation of what would happen if a "real" Ventoy USB was used to boot a VM OR a bare-metal.

Just another effort on my part to keep up with what developers do in their efforts to test scenarios using QEMU. This effort made me a little more productive by reducing time and reducing efforts for testing. All of my stanzas are saved as they are basically standardize for my test cases.

P.S. I run a VM on my production host that is used for all Internet browsing. File transfer for information gathered in the VM is via the OOTB samba to/from the host. Thus NO installations on any kind is necessary for this host-VM information pathway. Every major OS/distro comes with SMB (Linux/Unix uses SAMBA) built-in making this all-to-simple use available. This completes the integration requirement for info movement needed. I use a virtual desktop with the VM running full-screen in one of the host's virt-desktops. This allows the appearance ... rather ... 'use' of 2 PCs on the same display's access; one real and the other real-virtual. This production arrangement has NO CPU overhead...just the RAM designation in the QEMU stanza. "Idle utilization" remains the same with or without the VM running. VM desktop behavior is the same instantaneous as the host desktop.

In my past, another test case was running 2 different releases of a given distro to ascertain if a misbehavior I was witnessing was the same in a prior release. This is great to spin-up a VM with a current distro and a 2nd spin-up of a prior release to compare, side-by-side onscreen, a behavior.

In summary, I use this arrangement because I get the real allusion of having multiple PCs on the same desktop's display.

This is where use of my TV is now beneficial on these old eyes with so many things on the real estate it allows to presents.

[wiak]

I don't know much about Qemu really. I dabble with it too rarely, trying many things, but then after not using it for ages, I forget most everything all over again.

It would be nice if it were possible to boot an underlying Windows installation on Qemu whilst I am booted into Linux... Trouble would be, I imagine, that the virtual machine will not be recognised as the actual hardware machine by Windows so registration won't work(?). It would be so useful on dual boot machine like mine, not to bother separately having to dual-boot, but instead run the Windows system as a virtual machine. Well... I suppose I could use the likes of Virtual box, running it under booted Windows, and with my Linux system the one being run as a virtual machine... but I don't want to be directly booted into Windows.

One reason this is suddenly on my mind is that I'm getting a replacement new laptop (well, business is...) and though not fast in terms of the likes of gaming, it again has loads of RAM and tons of nvme SSD space so running virtual machines makes lots of sense with it (rather than my dual-booting and risking to mess up the actual business-related purpose of the machine...

However, I have zero time at the moment anyway (can type fast enough so this post doesn't hurt), but March will come sooner than I'll be ready for and sometime then I will be back doing FirstRib/KL work.

[rockedge]

@wiak I have several versions of Windows running in both QEMU and VirtualBox. Yes the registration mechanism for Windows works on both types of virtual machine.

It is really convenient to work with Windows in a QEMU machine using the VNC to display and see it with Tigervncviewer.

I use WinXP still mostly in the VM's that do not need any registration. Might be some Win7 models around these days that are opened but I do have a couple of valid Win7 versions with the keys that I could use but WinXP still runs what I use it for.

[rockedge]

Going to begin experimenting with JACK audio server on our KLV variants. This would be really top self stuff.

I also have been building in lots more support for sound cards and devices in the latest full real time kernels for Puppy Linux and KLV. This will need some testing though.

Also will try JACK on a wayland KLV especially on @Sofiya 's latest works of art.

[Clarity]

Hi @wiak , I have installed multiple Windows, at times, under QEMU for over a decade. So far, issues. The important thing to concern is how you structure your QEMU definition to mimic a "real" PC. There are several ways to do this.

If I can offer an insight that you and others might benefit in QEMU use, its that you keep a library of the definitions that you use with comments of both the type PC it is defined with each QEMU stanza. Remember, QEMU stanza merely is defining a mimic of a "real" PC. Thusly it contains everything from type of UEFI/BIOS, video card, audio card, LAN structure, and storage devices.

If this is for a home 'production' system for permanent development or other use, I would suggest Linux Virt-Mgr (aka 'libvirt') as this is the best screen GUI for KVM systems (QEMU). It is fabulous and makes plain what is happening on which virtual PC and each individual definitions of its hardware (virtual) layout. And it does a lot of the QEMU (cli) heavy lifting for user understanding and use.

It would probably be a mainstay in Puppyland, until recently, many members were not into virtual machines or use of such. (The KL community is currently the best and appears to be the most understanding of VMs and Linux's KVM benefit in its efficient use of the real PC's hardware.)

In fact, I would think that this year, 2024, is going to be a breakout year for KLs as it appears to be headed as the front-runner for the modern Linux technology with the several very good things it has going for it.

[Clarity]

Hi @rockedge I will follow your work as there has been discussions I've seen recently in this area of Pipewire use.

I ask, to be consistent with your efforts, that you install the QPWGraph package. Reason, it looks simple enough to make sense of what the PC is doing and what is connected. And it leads to an expanded knowledge for experienced and new users alike.

As a developer, it could be helpful in tests you (and others) would engage to readily see what you've attempted in real time.

Have you seen it? Anyone else in KLs community, please provide feedback on value of these kind of assisting technology and any other products like this. It has an advantage that we can visually see results toward speeding resolutions in a system's multimedia use. "Wireplumber", maybe, as RECOMMENDED by Arch in their Wiki.

Those reviewing this post, might appreciate this Arch Wiki Pipewire page...especially just the 1st 3 paragraphs-sentences.