KLV-Airedale-rc16 with Void Linux Kernel 6.1.25

[rockedge]

KLV-Airedale-rc16
Kennel Linux Void Airedale Release Candidate 16 803 MiB download size ↓
KLV-Airedale-rc16
SHA1-MD5.txt
Download from SOURCEFORGE

Complete system update/upgrade and outfitted with a Void Linux kernel 6.1.25_1 on 04/26/2023

Features full SAMBA support and managed by a modified for KLV Samba Simple Management GUI script, borrowed from F96-CE_4.

The team fine tuned login/logout with a long term solution utilizing the Void Linux service manager runit to fix a conflict after upgrades to the runit-void package added a service directory agetty-tty1 that conflicts with KLV's custom agetty-autologin-tty1 during logout/login causing difficulty in changing user. Adding a file called : /etc/sv/agetty-tty1/down instructs runit to disable the service which is persistent across reboots.

The initrd.gz and w_init are upgraded to version 7.0.1-rc1 which are constructed from the latest FirstRib skeleton-initrd.

Added the symlink gtk2dialog that targets the binary gtkdialog-8.5 which is compiled against GTK2 which gives access to either gtk2 or gtk3.

@fredx181 has repaired a bug in save2flash and modified swapper.sh to adapt for the /mnt/home device showing directly in Thunar and on the desktop. swapper.sh activates any swap partitions available to KLV-Airedale during system start.

From a suggestion by @wiak added in a modification to w_init that will display icons for /mnt/home partition in Thunar and on the desktop.

New and improved tuning of the /boot directory boot stanza's. improving the reliability of booting in QEMU, Ventoy and S2SG.

Improved and rebuilt initrd.qz including expanded support for SD cards.

Routine system update/upgrade. And wallpapers from @Sofiya are included, replacing some of the stock xfce4 backgrounds.

@wiak has again done more work improving the boot system menus and further improvement to the initrd.gz boot mechanisms :

The iso config file boot/grub/menu.lst is used to boot from cdrom using that internal to ISO provided menu.lst (i.e. he currently uses grub4dos for that purpose).
The ISO config file boot/grub/loopback.cfg is used (per usual) to provide the boot menu for SG2D
The ISO config file boot/grub/grub.cfg is used by Ventoy (but included no Ventoy compatible entries until my alterations below)

I have made some modifications to all of the above (though have left previous entries in place for later experimentation and possible modification or deletion).
In particular I have provided the ability when booting via SG2D or Ventoy of using the FR modes:

a. RAM0 for session changes in RAM only (i.e. no save persistence)
b. RAM2 save on demand mode back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
c. RAM2 save on demand mode back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'
d. Direct save (not in RAM) back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
e. Direct save (not in RAM) back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'

No editing of the presented SG2D or Ventoy boot menus will be required to achieve these most useful FR initrd modes. User just needs to put the KLV iso in BOOTISOS (or wherever it is put usually) and boot...

starting of the pulseaudio system for any user that is logged in has been fixed and improved. Thanks wiak, Sofiya and fredx181 for the exact steps.

Upgraded to a new version of @fredx181 's save2flash, and set LANG=en_US.UTF-8 in /etc/environment as default localization.

Thanks to @Sofiya for the poorercputemp and Display Control packages that also have been added to desktop.

• Grub4Dos is now included in the System menu. Making KLV-Airedale capable of setting up a boot-able device using GParted and Grub4Dos.

• CUPS starting as a service has been added and is working thanks to @rcrsn51 spotting missing components!

This is constructed from KLV-Airedale-beta27->rc1->rc2->rc3->rc4->rc4.1 and is equipped with a Void Linux kernel version 6.0.12_1 SMP PREEMPT_DYNAMIC constructed with @wiak 's scripts that will extract the Void Linux kernel for KLV. Also has had a system wide upgrade. Uses an initrd.gz based on the FirstRib skeleton initrd.gz constructed by the kernel/module creation script. Firmware SFS is from a woof-CE kernel-kit built huge 6.0.0-1 kernel.

KLV-Airedale-rc16 is just as at home on FAT32, NTFS prtitions as it is running from ext2/3/4 formatted partitions.

Also included is wiak's generate a set of boot stanzas script. fredx181's mksplash has a menu entry and the remaster script is installed.

With the addition of a xfce4 desktop tiling configuration. A tip from wiak for configuring Tiling windows done with the Super (Windows) key and an up, down, left, right, home, pgup, pgdown or end key.

gxmessage in the default rootfs.

save2flash has been expanded to handle persistence on FAT32 and NTFS partitions.
The mksplash GUI utility to create splash notification banners.

The latest initrd.gz brings vFat and NTFS formatted partition support to KLV, allowing persistence on NTFS/vFat systems as well as the usual /ext2/ext3/ext4/swap support.

• included htop, Grub4Dos, CUPS

• created a symlink /root/spot with the target /home/spot

• Auto login cleaned up.

• includes also the logout logic provided by fredx181 gives true mulit-user support.

• replaced loop.cfg to the most recent modifications.

• Debian kernel 6.0.0-3-KLV SMP PREEMPT DYNAMIC is used.

• added gtkhash

Plus the other important improvements contributed by the KLV team.

Added @fredx181's save2flash utility that can be used when KLV is started in RAM2 mode to perform session saves on demand for persistence.
This is similar to PUPMODE13 in Puppy Linux.

fredx181's swap partition enable script includes the latest revisions and also added are the packages

• mime-add-1.0_0.noarch.xbps

• edit-sfs-1.0_0.noarch.xbps

KLV-Airedale-beta25 is able to load squash SFS packages on the fly or during the boot sequence.
Squash files and ISO images can be opened from the file manager and the read the contents.

• can run with rootfs, 01fimware and 00module SFS files as uncompressed directories.

• Also able to load compressed and/or decompressed directories,
  once a 2 digit prefix is added to the file name.

• It is possible to mix using compressed squash files and uncompressed directories.

Also can be downloaded from https://rockedge.org/kernels in ISO->Kennel_Linux->Airedale

[Clarity]

Preliminary tests booting without issues.

Code: Select all

qemu-system-x86_64 -enable-kvm -vga cirrus -m 2G -smp 2 -device ac97 -name 'KLV v16 on QEMU' -cdrom KLV-Airedale-rc16.iso

All subsystems tests are very quick and stable!

Excellent: This distro seems ready for movement from RC to GA.

+1

KLV v16 Pristine tesing.jpg (59.18 KiB) Viewed 2596 times

KLV v16 Pristine tesing2.jpg (34.33 KiB) Viewed 2585 times

[Clarity]

KLV v16 Pristine testing3.jpg (54.93 KiB) Viewed 2574 times

[Clarity]

The reports I have provided, above, should be discarded as inaccurate results!!!

The problem shown is NOT a KLV problem!!!

Turns out I have a new distro that is running its repo's QEMU that is caused for the network error seen in the VM.

I have reported the problem to its developer.

I do not have this network error condition on ANY of my other HOST rigs used for testing VMs now or in the past years of QEMU use. This is a first-ever condition.

BTW: 'tldr' installation proceeds without issue on the other HOSTS, as does all other network services in RC16.

KLV RC16 ISO file Pristine on my production HOST PC.jpg (139.35 KiB) Viewed 2558 times

[rockedge]

@Clarity I had forgotten to add in the SFS that contains the gtkdialog components so I have repackeded rc16 and it is uploaded and ready for download

[Clarity]

I have 3 boot scenarios enclosed. ALL scenarios for this testing is done within a VM (QEMU/KVM). Each is booted directly via RC16's ISO file. Understanding is asked for each.

1. Scenario #1 - Boot ISO file as if on CD device bare-metal
   Boots and run with NO issues. This is done merely by the following stanza with the ISO file.

   Code: Select all

   qemu-system-x86_64 -enable-kvm -vga cirrus -m 2G -smp 2 -device ac97 -name 'KLV rc16 on QEMU' -cdrom KLV-Airedale-rc16.iso # boot ISO file directly

2. Scenario #2 - Boot ISO file from bootable SG2D USB
   Boots and run with NO issues. Merely slightly slower as SG2D boots allowing SLK selection. Slightly slower on boot, but desktop run same as prior tests.

   Code: Select all

   qemu-system-x86_64 -enable-kvm -vga cirrus -m 2G -smp 2 -device ac97 -name 'KLV rc16 on SG2D USB in QEMU' -hda /dev/sdc # boot SG2D USB selecting the ISO file

   

   SG2D USB contents.jpg (24.33 KiB) Viewed 2519 times

   

   SG2D USB boot to desktop.jpg (15.7 KiB) Viewed 2519 times

3. Scenario #3 - Boot ISO file from bootable Ventoy USB
   Will not boot directly from the Ventoy menu NOR from Ventoy selecting SG2D then selecting KLV. Abends on either approach via the Ventoy USB.

   Code: Select all

   qemu-system-x86_64 -enable-kvm -vga cirrus -m 2G -smp 2 -device ac97 -name 'KLV rc16 on Ventoy USB in QEMU' -hda /dev/sdd # boot Ventoy USB selecting the ISO file

Ventoy USB fails to desktop.jpg (55.22 KiB) Viewed 2519 times

[Clarity]

The SG2D USB stick is 1GB while the Ventoy USB is an old 2GB stick. If anyone wants to download either for their own test verifications, I can make available.

[wiak]

Don't have much time for testing, but downloaded and installed onto my usb Ventory stick (has that all important label: "Ventoy" for the partition BOOTISOS directory is on and also has a "Sessions" folder on there). My usb Ventoy arrangement booted rc16 without any problems; I used save on demand RAM2 mode to Ventoy "Sessions" and that is working fine. I'm posting from it right now.

Only issue I have with KLV-Airedale is that it has always booted a bit slow for me. Despite thinking runit is a nice init system I can't help but wonder if it is a bit slow compared to systemd. KLA distros all boot up much faster, but once booted doesn't really matter which I'm using - all are fine.

[wiak]

I like that KLV is so full-featured though. One day I hope my own KL variants can catch up with that, but not just now. One thing I think should be worked on soon for all KL releases is a move to Pipewire now though. I'd keep using XFCE though, so no wayland right now - we certainly don't want to move to GNOME for the sakes of using wayland, and alternatives are pretty weak. I really like XFCE, though Openbox/Tint2 can be configured to work pretty much as good, as we know.

[rockedge]

@wiak

One thing I think should be worked on soon for all KL releases is a move to Pipewire now though.

Agreed that a transition to Pipewire will be a move that must be taken. Wayland is another situation and perhaps going back to the PLUG instructions we can generate a set of experimental KL's using both technologies.

I'd keep using XFCE though, so no wayland right now

With XFCE4 performing well and being quite the competitor when compared to some other desktop types, I would imagine that the XFCE4 dev's are looking at integration of Wayland and Pipewire.

Right now both XFCE4 and the OpenBox/Tint2 desktop are really good options and solid in Kennel Linux. We'll be keeping an weather eye out on the horizon.

I booted an early WeeDog64-Void-xfce4 still using a huge Puppy Linux kernel and it boots like lightning. Also KLV-Airedale-alpha's booted faster than it does now.
On QEMU or VirtualBox KLV will still boot rather quickly but I notice on different bare metal machine's that it is a bit slower than had been and some machines faster than others. Though once booted there is no more slow. Did see on a setup though where Firefox began to slow to a crawl and the mouse was hesitant when moved though have not pinned down a real cause as to why this occurs on this particular setup.

At some point rcXX will be KLV-Airedale-1.0 stable.............when is it a production version?

[Clarity]

@wiak thanks for your observation and testing. I wonder if I could offer my Ventoy USB to you for:

1. recreation of my findings on your end

2. testing booting a USB within a VM to recreate

If so PM me. Or if there is a way I can obtain copy of your USB for test on my end. The information captured or observe may prove useful somehow.

Note: All of the tests, above, were run in VMs. I will test bare-metal later tonight. It appears my bare-metals are different from you, as, I keep ALL of my Persistence on the system's drive...not on USB (for obvious reasons). I do knot and have never placed Persistence on any other mdia than the system drive. Yet I boot all distros via their ISO files using either Ventoy or SG2D as I test with both from time to dime. I test via VMs as its too easy and fast to do so. Then, move to test using bare-metal when I'm considering review of a problem or looking to prep for production use.

@rockedge, this project is a beauty in its scope and the collaboration of community who have inspired and made KL.

If a newer project starts for to create a current technology KL, I agree that

• Pipewire

• Wayland

• GTK4

must be OOTB consideration that will attract younger users (and others too) to this KL family in the forum.

I was recently reviewing notes from nVidia where it appears their management specifically targeted their Linux effort at Wayland. Recent reports from them is that their current releases are 'completely onboard' with Wayland and Linux while the nVidia community should expect very little from them on the older Linux technology (X11).

Pipewire: Should KL adopt, I ask if it considers the diagramming utility(s) that will make it easy for users to see how Pipewire is 'WIRED' to our subsystem and application components. This is an important utility making it easy for anyone to diagnose concerns when an app using audio is misbehaving.

Wayland: Its a decade old project that every monitor/TV manufacturer have contributed to since its outset in Linux. They are onboard as are world developers. It has matured while various presentation subsystems are rapidly moving to for past 3-4 years. This includes the work done by WoofCE developers.

GTK4: The hand-writing for this has been on the wall for several years. It is clearly understood and today, all of the mainstreams have solved this so that it is behind them allowing them to focus on other things.

All of these technologies, today, have reached levels of stability and maturity that each supersedes the capabilities of their past brethrens.

I DO RECOGNIZE that neither of these are small leaps in current collective knowledge in the KL community, but it doesn't hurt to have targeted goals for KL's next level of growth and the benefit to use that growth brings in its ease of use.

Just some ideas...nothing more.

[Clarity]

I've just tested each USB on bare-metal. ALL tests worked booting to desktop; namely

1. SG2D USB rc16 ISO file directly to desktop

2. Ventoy USB rc16 ISO file directly to desktop

3. Ventoy USB, launching SG2D ISO file to launch KL ISO file to desktop

#3 is a 'failsafe' that I have and use. It is employed when a WoofCE PUP doesn't boot via Ventoy. In the past, all of WoofCE PUPs have booted from SG2D. Thus, its presence is a backup should the distro run into problems in Ventoy boot. This has been used by me for several years since Ventoy v23.

My Ventoy partition contains.jpg (12.7 KiB) Viewed 2481 times

Just an update of KL ISO file booting on bare-metal testing vs testing in VMs.

I am not sure but I am now curious WHY?

The difference: VMs are tested with ONLY the USBs and NO other discs present. While bare-metal have Persistence and other files on system disks including other ISO files-folders as well as USBs.

[Clarity]

Spoke TOO SOON. That test was done using the USB sticks on the 'newest' (decade old) Intel (i5) PC I have.

Yet using my older test PCs, I am hitting the same problem on bare-metal as originally reported when booting KL with the USB sticks in the VMs.

I am trying as best I can, to understand what KL sees in these BIOS that causes the bootup to Abend on some old PC configurations and not on others???

It does NOT stop at a GRUB prompt allowing me to run a 'debugsave' capture files that might suggest the problem. It just boots and Abends.

Thus I am looking for something common that I can share & report.

Has anyone else tried booting their own SG2D or Ventoy USB using the stanza I've provided? That stanza should create a reproduction of the same VM I use (and will indicate what one could see when booting on bare-metal for older PCs.

My production rig that I run my VM tests on using this QEMU version

Code: Select all

root# qemu-system-x86_64 --version
QEMU emulator version 7.1.50 (v7.1.0-1-g93fac696d2)
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

The VM stanza was reported with my initial report.

[geo_c]

Excellent: This distro seems ready for movement from RC to GA.

I don't know what GA stands for, but I'm still running RC-13 and don't have any plans to upgrade at this point unless something really big is added. KLV-airedale has become my indespensible go-to daily driver, and RC-13 is doing really swell for me.

In other words, I've considered this distro polished and ready to go for months now!

I just installed all my favorite command line apps and panels in F96 because it's a really nice running OS also. My next project is KLA-Xfce. I'd like to get KLV-OT2 crankin' full steam also, but there just isn't enough time in the day, and I really use these OS's for work, so I can't be booting and polishiing 5 distros everyday, though I would of course like to.

So I was planning to make a nice topic around the idea of culling OS's and making them comparable operationally, that is give a little demo of how make a fossapup with Cairo dock functionally idenitcal to KLV with an Xfce deskbar and a fossapup9.5 or F96 with a Rox panel for instance.

I'm also curious to get the Xfce-fusilli F96 into service, but like I say, too much to keep on top of!

My new topic is going to be something along the lines of: So many puppies and Kennel-Linuxes, and so little time.

[wiak]

I'm also curious to get the Xfce-fusilli F96 into service, but like I say, too much to keep on top of!

My new topic is going to be something along the lines of: So many puppies and Kennel-Linuxes, and so little time.

There is not enough time in the day to strike off even a small portion of most people's lists of things they would like to do or achieve.
I often state bluntly that, on the whole, I make little or no attempt to create for others; rather, I have matters I want to do or achieve on my todo list and eventually I find the time to creating what I want for my own wishes. That involves not only research regarding howto do things, but lots of failed experiments prior to anything being created.

As Albert Einstein apparently said: “Any man who reads too much and uses his own brain too little falls into lazy habits of thinking.”

Once I've made something I 'usually' release a copy into the wild for others to use, develop, or benefit from. I also sometimes write a fair amount explaining details of how what I produced works and via build system or other processes how to expand it. Reason for that is that I too then benefit from the additional work of others and can further sometimes refine or add to their work.

What I don't care at all about usually is 'ideas' from others who have simply been reading and then trying to get so-called 'developers' to implement their wishes. It is not as if I cannot and do not read enough myself already. My own natural inclination is 'usually' to ignore the ideas of others - if they want something what I want from them is that they first implement some version of what they want themselves. I am happy to then help if they run into difficulties, but I often won't bother implementing simply someone's views of what they would like incorporated unless I myself have the same desire. I don't mean to be selfish in that attitude, I simply have other priorities that I myself want and with greater urgency. I do want pipewire, so next time I get busy on FirstRib front I'll likely start using that - however, that is really a trivial matter overall. With Wayland I am in no hurry - it is well-known that the XFCE team is working on Wayland implementations of that, and I can wait. I can and have already played with Wayland using simple Wayland-compatible DMs and apps, but overall I won't waste my time trying to get ahead of XFCE team who will do a far better implementation of a Wayland system than I ever would. Really I concern myself with only two components: 1. FirstRib initrd (which is most important part of my contributions), and 2. FirstRib plugin-based build system (if that breaks, as it sometimes does due to url changes, then I fix that, and maybe... 3. A new improved version of Weedogit (now called FirstRibIt) since that proves very handy for turning most all major mainstream distros into FirstRib overlayfs frugal installs, which can be extremely convenient.

I note that some on here read "a lot" and then spout a lot about what they would like to see added. Frankly I go deaf. I am already aware of what they spout about. Indeed, I read too much too - and that does make me less creative, not more... Fortunately, just now, till near the end of this year I have no time available to read much or create much, but when I come back to FirstRib work what I will do will be items on my own todo list for sure, and not answering the wishes of others (unless their wishes happen to be on my own list). Some matters I really don't care about. Samba, for example, I never use here - though I may well incorporate it in later releases (albeit low on my priority) for the simple reason is that someone else has actually done the work; I would never do it if the 'idea' was simply 'wanted' - I want help from people who do their best trying to implement ideas and create things - I don't want "ideas and wishes" alone. Pay my a lot of money and I might implement something 'wished for', but otherwise I am deaf for the huge todo list reasons already stated.

I don't care therefore about implementing Wayland variant, and certainly don't care at all about having to do anything related to GTK4 (that comes from upstream repos once the upstream distro decides to implement it - nothing at all we need to do really - much the same goes for Wayland - and Pipewire really, which is just a matter of installing it instead of Pulseaudio).

Anyway, my message to keen KL supporters is: yes, testing is useful to determine bugs (which always exist somewhere...), but listing items you want included is irrelevant waste of your time. But attempting to "implement" something is highly respected (whether you succeed or fail); my personal inclination then would be to support your efforts whether the technology is particularly interesting to me personally or not. I respect those who make genuine efforts to create; stop reading, start doing, would be my suggestion for those who want to support KL. Stop simply 'pushing' for things 'wanted' - that is a turn off and I hate even reading such posts frankly. In fact I do less, and move away from development when posts start becoming like that. I know some facilities have been worked on fallowing such pushing for inclusion type posts - in a way I think that is a pity since such creations act as a reward for something that shouldn't be encouraged here. We can all read. The suggestion that others don't 'think' about technology or need to be 'made aware' comes across as arrogance - we don't need 'advice' - most all forum members are wiser and far more generally aware of what is 'out there and happening' than such posters assume. Stop such posts - or we who do develop or try to create or implement or build, or whatever, will go away! No-one, I'm sure, is at all interested in being pushed by the views or opinions of others - that is not contribution at all. We generally all know what is out there. Hardly anyone on this forum doesn't read about technology. We don't need it regurgitated. A forum like this benefits from those who try to CREATE. I find it frustrating when so many make statements such as 'that kind of work is above my punching weight'; that is rubbish - the only way to learn (and properly contribute) is to TRY. I really respect those who try to learn a bit programming and are not afraid to try... that's worth supporting, but demands for including things. Nah. Helps no-one. In fact I may not include some items asked for simply because I resent supporting demands - that is a fact, so stop reading and damanding as if all-wise about what should be included (those who simply do that) and start 'doing' if you want my support and thanks.

Sorry if my feeling insult anyone, but frankly, it becomes very painful to hear demands and opinions about what 'should or must be' included - I have no time for such posts. Not talking about anything you say geo_c; most all of your posts are very useful feedback and encouraging.

[Clarity]

Hi @geo_c

... I don't know what GA stands for...

It stands for "General Availability" for products that move from research-test phases to release for production use.

Its a development acronym and is spoken to by @bigpup on the forum for quite some time. Most recent he helps with the development phases here.(Opps, I cannot find @bigpup's post's link explaining. It may have moved from where I thought I saw it.)

Hope this helps.

[Clarity]

Hi @geo_c. Your efforts have been most informative on this forum section as well as in the forum, at large. Thanks.

Just an idea that could reduce your workload and make life a little bit easier in both management and testing you might do with the various KLs and F96s.

There are lots of members who like the joy of moving files around after downloading ISO file. I DONT! Movement is unproductive for me. Especially since I know this doesn't have to be, to enjoy the full experience of almost EVERY distro released on this forum since 2019. Knowing this. my life is merely 1+ minute download and running on its desktop with the full experience of the developer's vision of their distros. And it is 'frugal' for every practical term.

Have you considered, either an SG2D/Ventoy USB stick containing a "BOOTISOS" folder that just has ISO/IMG files?

If so, not only will it reduce your efforts with the ISO file management, but will give you simple access should you use QEMU or other VM launchers.

The USB can be of use in testing in a VM as well as booting directly on a real PC (bare-metal).

For me, just today with latest KL's i am testing, it took me 1.5 min to download and boot the KL to desktop, while my production PC is running...uninterrupted. And, if necessary, I can run several VMs at the same time with various KL's and F96 never interrupting the workloads running/used on the production host.

Really very simple for me. If you are already using this advantage, nevermind this post. Anyone/everyone on the KL team is aware of use of what this post suggest and will help should there be any questions in either setup or use. ... as will I.

Hope this is helpful.

[wiak]

And most of all...

We don't want or need at all those who position themselves as some kind of 'Manager-role', which is not a creating and doing role at all.

If you are like me, you have enough of such 'manager-types' in our employment life. It was painful - most of these guys (even if we eventually also had some such roles) were just a lot of irrelevant noise. Even if some 'managers' were good, really, forget it... no 'managers' here please (and that includes myself - I leave everyone to do whatever they wish and great when what they do, whatever it is, proves useful). Encouragement is great; pretending to manage what developers should or might do is to me a discourse that will make me retire from open-source since I can't be bothered with such 'organisers' any more - I want to collaborate with people who try to implement and create, not with people who read a lot and treat others as if they read nothing. So the 'just an idea, no pressure, just making you aware' sort of post should be BANNED in my opinion. I hate such posts - waste of space and time. Please avoid and get in spirit of proper open-source collaboration - this is not a team for you or me or anyone to pretend to Manage. A team that works well together turns out able to manage itself without obvious 'leaders' of any sort. I've been working with rockedge for several years now, and no management per se has been involved - things just happen when people put in actual creative effort. That's my Christmas message, and it is only just past Easter yet.

Fact is, I myself appreciate some of the posts of everyone who ever posts in this KL area, but I really can't stand some of the stuff posted, the way it is posted, to the extend that it is not only time pressure that has been keeping me away from here. I just can't stand that kind of post, which seems to be increasing in frequency. Please stop all that 'just for your information' JUNK!

[geo_c]

Have you considered, either an SG2D/Ventoy USB stick containing a "BOOTISOS" folder that just has ISO/IMG files?

Hope this is helpful.

Well yes, I have run SG2D sticks with a good 10+ OS's booting. That works great for booting OS's, and booting them and testing isn't really a problem at all.

What I'm talking about is actually using them, personalizing the look and feel, loading them with my favorite applications, and maintaining all the iterations of the persistence saves, etc.

Say with KLV-airedale, I have a 20 upper_changes deep system now, loaded with applicatons, tweaks, scripts, a completely powerful system. Same goes for fossapup64_9.5, F96, and jackalpup.

The time crunch involves doing the same with other OS's like KLV-xfce, vanilladpup, etc. I of course want all my OS's to have EVERYTHING that the others have. Nice launcher bars, all the applications and file managers, customized icons/themes.

That all takes time. In other words I have too many bootable OS's already. USING them all for work and fun is the challenge.

So that's why I take some effort to explore how to use Rox panels across the board, in all OS's, which can be copied into the /root/.config/rox-sourceforge directory and things of that nature.

[Clarity]

Hi @geo_c. Thanks for the understanding.

My setup does not meet the same objectives you have.

@wiak posted a way to uniquely 'name' each KL's changes on my Persistence Drive in its Sessions folder that was a great plus for my use of each KL variety. So in the sessions folder, within it, I keep Airdatle in one, KLU, in another, OT2CE in another, etc. ... This folder, "Sessions", also contains my FATDOG sessions, my WoofCE sessions, Deb-DOG sessions, etc.

This reduces ALL of my forum distro use to

1. a bootable USB with ALL ISO files in its 'BOOTISOS' folder,

2. and the Persistence system drive's "Sessions" folder.

My housekeeping is simple, intact, and complete.

This is just a note of my use case for managing all of the KL's I use. Everything forum distro related, from boot to shutdown, in within these 2 folders....only.

[geo_c]

Hi @geo_c. Thanks for the understanding.

My setup does not meet the same objectives you have.

Yes, what I'm doing is building incremental systems of upper_changes so that as I fiddle with applications and frameworks, those changes can be easily undone if undesirable, also it makes changes transferable from machine to machine simply by naming the most recent upper_changes to a numbered one and copying.

This also allows me to identify unacceptable bloat by examining the individually numbered upper_changes, for instance when I installed flatpak in KLV-airedale, then decided it wasn't worth the overhead, I simply rolled back one number.

The bottom line there is that as I add to the system in terms of applications and system updates, I can easily see when and where they were added. My KLV-airdale is small in its base iso files, but rather large in reality as the total upper_changes folders are over 10GB.

I like to have these systems installed to hardrives on laptops, so it's not simply a matter of booting isos from a central external drive for me. I have KLV-airedale installed on 5 separate laptops, and plan to add it to at least a couple more.

Basically I can run a system wide update, change my desktop around, install some applications, rename the upper_changes to a numbered one, copy it to my USB installs, and then copy it to other devices. The same could be done with iso booting, but a newly updated iso on an old unupdated upper_changes would be problematic. In my scenario, I can update all the installs by updating the root fs in one install and copying those rootfs's and updated upper_changes to the other installs. So it's about equal in the end, in terms of copying new releases and keeping them coherent with the persistent saves.

If I was booting all the machines from one external drive that would be different of course. But I am a fan of having all kinds of backup copies everywhere and anywhere. 3 of my computers plugged in could suffer a lightening strike, and I'd still have the same system on a few machines that are sitting in their carrying bags. Or I could mess up my current persistent saves with buggy application installs and tinkering, and still have a few good copies to grab elsewhere.

If you knew me and the hours I keep, you would completely understand my logic!

Of course there are a lot of ways to achieve the same end.

[Sofiya]

Hi @geo_c. Thanks for the understanding.

My setup does not meet the same objectives you have.

Yes, what I'm doing is building incremental systems of upper_changes so that as I fiddle with applications and frameworks, those changes can be easily undone if undesirable, also it makes changes transferable from machine to machine simply by naming the most recent upper_changes to a numbered one and copying.

@geo_c ,Maybe you will be interested.
geany color-schemes - https://github.com/codebrainz/geany-themes Geany - https://github.com/geany/geany-themes/t ... creenshots

[geo_c]

@geo_c ,Maybe you will be interested.
geany color-schemes - https://github.com/codebrainz/geany-themes Geany - https://github.com/geany/geany-themes/t ... creenshots

I have the themes directory for a few years now, and when I set up a new desktop one of the first things I do is copy the directory of these geany themes to /root/.config/geany/colorschemes

Because I'm not a fan of white backgrounds in my applications. You could probably tell from my screenshots.

And because the different color coding for file types is very helpful when editing files.