Puppy Linux Discussion Forum

After seeing a few distros over the past months from Distrowatch and reviewing discussion of Linux in 2024, it seems to me there are 6 products that almost every major distro, OOTB, will achieve; as follows

• Pipewire

• Wayland

• WirePlumber

• QT6+

• GTK4+

• GRUB2 v12

Some speakers believe there will be no holdouts, while they feel the early adopters will have the least effortless implementations. They all predict X11 will be removed among many top 10 going forward to reduce their need to support X11 and its past.

AS I look over these directions, here, in various forum distros, I foresee a need for a functional graphical display program for Pipewire as it makes plain how the system and its apps are connected to deliver the multimedia experiences so common in today's world of electronics. Today, the leaders I see are Helvum and qpwgraph for this visualization task. Thus, for now, one or the other (developer's choice) should be included, built-in OOTB, in any forum distro(s) released for member use such that it allow them complete understanding of the NEW system interconnections for multimedia.

There seems to be some 'filler" on nvidia, nouveau, and the kernel changes. The push seems to be moving the timetable on this, early in 2024 to be consistent with minor Wayland needs.

This thread, probably should be posted elsewhere as KL distros are not the only forward thinking distros in the Puppyland kennel.

I don't know... I'm now on the big move so maybe just thinking 'ambitiously'... but...

I'm tempted to work on a build of Puppy - similar to traditional, but different. Not using FirstRib initrd, so not KL-approach, but using Puppy system scripts with a new design of initrd that learns a lot from FR. However, maybe best I don't, and leave Puppy to those that want to stick with 'as is', but slowly developed however they wish from there. But maybe at home or in-house will make something just for my own personal fun. So much to do though, so little time; I'd certainly be sorry to see Puppy grow so old and gnarled it becomes irrelevant eventually.

I'm tempted to work on a build of Puppy - similar to traditional, but different. Not using FirstRib initrd, so not KL-approach, but using Puppy system scripts with a new design of initrd that learns a lot from FR

I agree and would be onboard with this type of project.

However, maybe best I don't, and leave Puppy to those that want to stick with 'as is', but slowly developed however they wish from there.

Those days have to be left behind. Only way is redesign with all this good tech at it's core. It is the Puppy Linux philosophy we want to preserve. Look at automobiles.....the basic thing is the same...engine on a frame with 4 wheels and a steering wheel outfitted with brakes. But huge difference between a 1920 model and a 2024 model......in performance and materials used to build.

Actually first priority, once I get back into KL more deeply again will be to accumulate all the new/latest developments and get them onto FirstRib gitlab so easier to make consistent KL releases via the build system plugins. I have nothing against any and all users supplementing what becomes standardised/tested KL-utilities and so on, but nice to collect the latest and greatest and keep that resource up to date to optionally allow KL distro builders to include the most popular whilst knowing they can trust they are well tested and latest releases.

The other matter I see happening more this coming year is that we also take a closer interest in Puppy Linux distro development too with the idea that many of the techniques/scripts/methodologies we develop could also be useful in Puppy. We already have wd_multi as an example of that; I consider it very wasteful of dev time and talent to make utilities such that they cannot be used in other distros here without re-inventing the wheel. It is fine for members to have their favourite distros and use only those they prefer, but as a developer/build perspective I've always considered that a very narrow and wasteful way of improving distros featured on this forum. This is not a big organisation, hence KL happily uses whatever proves useful from any area of this forum and equally looks to provide utilities and ideas that will definitely at times prove useful elsewhere - the more compatible we can build such components the better so reducing/removing system-level barriers to such compatibility is IMO something to always consider and aim for.

@wiak With some tweaks and new additions a KLV-Airedale and KLV-Spectr PLUG files can be ready, and using the ideas from @Sofiya's scripts that build a complete KLV distro scripts we should be able to begin to add to the GitLab collection. I have a GitHub repo, but it does not have the latest versions.

The ability to add in configurations and polish using .xbps packages has proven to be a good method. By varying the choice of those types of .xbps packages can then in a pin-point fashion build the different specialized variants like those designed for audio workstations for example.

I'm still in very cramped temporary accommodation, but move to slightly better arrangement next week and should have reasonably reliable internet there.

Have a backlog of non-forum-related work keeping me busy for some time into the future, but in-between times I at least want to do a bit organising regarding above couple of posts.

Could you guys post known KL facilities (such as, of course, save2flash) that are being employed in different, but not yet all, KL distro offerings. I plan to make a shared spreadsheet we can keep updated with which KL distro offerings exists and with checkmarks showing which in-common utilities they contain (or might want to contain once we have time to implement further additions). Some of the more system-oriented utilities probably best offered, at latest release versions, in all KL distros for consistency of experience, so the spreadsheet will provide a quick glance view of everything in current state KL offerings. I know some people resist all things google, but in practice we use google sheets here a lot in business, so that's what I'll be using since I'm more familiar/efficient with that as an easily shareable editable cloud resource.

My view is that the likes of gitlab/github are best for keeping distro dev work up to date, but really nothing is more familiar and useful as a spreadsheet for flexible, easy to modify, very simple information sheet such as I describe. A fully-fledged database is good at other times, but not so accessible to most people; for me therefore I prefer simple spreadsheets for this purpose. In business we use large cloud accounting packages, which include sophisticated invoicing and more databases, but we nevertheless also supplement that with simple spreadsheet templates for quick information sharing purposes.

Anyway, main point of this post is to make a request for list of such primarily system-type utilities/facilities that KL distros now can provide; so many bits and pieces I can't myself reliably remember...

NOTE: Hard to work here though. Hot. Currently 29C (6pm) - high humidity so weather forecast says feels like 33 - they are not kidding; highest today 31C and was 26C just prior to sunrise... Do have in-room airconditioning, but that means like being in a refrigerator so the constant change of hot to freezing plays havoc with the respiratory system of my body... I try to keep temp at around 24C in the room so going in and out doesn't feel quite so significant.

@wiak
Latest save2flash for KLV is here: viewtopic.php?p=103651#p103651
For systems with systemd, e.g. KLA or KLU it's different as it needs also a systemd service file (and small other modification, if I remember well), (perhaps @Sofiya knows more).

fredx181 wrote: ↑Sat Mar 30, 2024 6:23 pm

@wiak
Latest save2flash for KLV is here: viewtopic.php?p=103651#p103651
For systems with systemd, e.g. KLA or KLU it's different as it needs also a systemd service file (and small other modification, if I remember well), (perhaps @Sofiya knows more).

for KLA I have this

save2flash used in KLV-Airedale and KLV-Spectr used by the PLUG script

Current version -> save2flash-1.7_1.noarch.xbps

previous version -> save2flash-1.6_1.noarch.xbps

GitHub repo for PLUG collection -> https://github.com/techrockedge/KLV-PLUGS

rockedge wrote: ↑Sat Mar 30, 2024 9:36 pm

save2flash used in KLV-Airedale and KLV-Spectr used by the PLUG script

Current version -> save2flash-1.7_1.noarch.xbps

previous version -> save2flash-1.6_1.noarch.xbps

GitHub repo for PLUG collection -> https://github.com/techrockedge/KLV-PLUGS

save2flash-1.8_1.noarch.xbps latest version viewtopic.php?p=103651#p103651

I checked and it is currently save2flash-1.8_1

Current version -> save2flash-1.8_1.noarch.xbps

previous version -> save2flash-1.7_1.noarch.xbps

old version -> save2flash-1.6_1.noarch.xbps

GitHub repo for PLUG collection -> https://github.com/techrockedge/KLV-PLUGS

Aside from that all important save2flash, I think there are various other 'utility apps' being used in different KL distro releases aren't there? For example, some have samba, others grub2config and I'm sure there are several other such that may be in Airedale or Hyperland but I haven't as yet included as fixed or optional in, for example, KLF, KLU, or KLA?

Also, is there any rollback utility (I think maybe @fredx181 made one?) being used somewhere? Maybe some other stuff I've forgotten about.

We also have @fredx181 symlink sfsload on fly utility, or the possibly to be preferred chroot mechanism he devised. I can't remember where these threads are.

Maybe there are also some audio or audio/video utilities or related that I've forgotten about altogether.

All these are things I'd like in shareable spreadsheet to show what is available to KL and which KL distros already have them.

@wiak
I think rockedge has added almost all custom made xbps packages here: https://rockedge.org/kernels/data/XBPS_packages/

Some others:

• Pipewire (included now in KLV (and probably in other KL's too)): viewtopic.php?p=98374#p98374

• Alternative SFS-load: viewtopic.php?t=8004

• GoogleDrive-Filemanager: viewtopic.php?t=10219

• Remaster: viewtopic.php?p=71341#p71341

• Simple python3 http server: viewtopic.php?t=7867

• Conkyclock: viewtopic.php?t=8536

• Pulse Capture Gui: viewtopic.php?t=9518

• Experiment with screener: viewtopic.php?t=9013

These are mostly my contributions, probably there should be more, also from others I think.
EDIT;

Also, is there any rollback utility (I think maybe @fredx181 made one?) being used somewhere?

I think you mean restore-sys script: viewtopic.php?p=103935#p103935

Thanks Fred, you have been making a lot of KL stuff during the year.

I still don't have much time for experimenting/dev work. But I am 'kind of' getting back into it. In particular, I'm ignoring my todo list, because I want to remind myself how my KL_full2fr mechanism works. Whilst I don't take any drugs, apart from my single dose of morning expresso coffee, it sometimes almost seems to myself that my brain must have been on drugs when I created KL_full2fr or at least I'm almost shocked that it works... However, I just tried it again, with my latest full install of Linux Mint, and, apart from a minor glitch (in the documentation) I am currently booted into my Linux Mint but as that very special full2frugal creation where the actual full install of Linux Mint remains exactly as it was (and thus remains bootable per normal full install) but also is bootable as frugal install, which is how I am using it right now... I really love this since has full KL power in this state. Note that unlike earlier weedogit-type creations, KL_full2fr does not at all involve installation iso of the likes of Linux Mint - i.e. it does not involve using the internal sfs rootfs of such distros - rather it uses the actual uncompressed full installed Linux Mint filesystem itself; that's why it is so useful (to me at least).

I have to re-study my own script though to get my head around how I managed this from the point of view of how the overlay filesystem is working with it. I know I later also managed to get this full2frugal working with KL/wd_multi arrangement, which is what I also want to do now (again) for my daily driver situation, but first I want to remind my brain how KL_full2frugal itself is actually managing to work...!... Anyway, it does. Of course, as I said back then, KL_full2fr should work on pretty much ANY already full-installed Linux distro; that could include a full install of a normal KL distro for example, though I've never actually yet tried running a KL distro in a full installed configuration, but no reason why not.

Without thinking of all the ramifications, I tend to suspect that a full-installed KL distro then run as a KL_full2frugal might be the most useful overall arrangement for the simple reason that it is trivial to upgrade a full installed distro, but KL_full2frugal then gives the result the full FR initrd frugal install advantages (except that in the special way I'm doing things a separate partition is then used for upper_changes work). Oh well, early days in my re-examination of KL_full2frugal, which I believe contains a lot of useful end information regarding how to make frugal installed distros work in the most powerful way, and even more so in conjunction with wd_multi configurations. Weird I suppose that I sometimes myself get lost in the complexity and power emanating from my own earlier work, but I do; like I say, though I wasn't at the time on drugs, the results even amaze myself such that I have to now re-understand how it all works... I think more useful implementations may well come out of that earlier KL_full2frugal (KL_full2fr) result and the theories behind it all that made it work.

The new 'trick' I wan't for KL_full2fr arrangement is that when using the result as a frugal install an upper_changes is of course created so I want to be able to later merge that back into the underlying actual full install root filesystem, which is effectively a re-master of the underlying full install itself. Weird idea I suppose, but once arranged in a user friendly seamless way the result would definitely be best of frugal combined with best of full install arrangements, being the best for anyone who likes to expeiment/do_dev_work whilst also keeping their distro fully up-to-date in all ways (new updated kernels and so on).

Of course, KL_full2fr methodology is very much related to how I made Pseudo Full Install with FirstRib/KL; KL_full2fr just took that a bit further to involve a full installed distro and all its parts in that one complete root filesystem. Actually the new Puppy experiments using a sort of PFI remind me, at least in simple description I read, very much of KL_full2fr, but using Puppy almost as the full install (rather than the likes of full Linux Mint or Zorin that I described), but I haven't studied that latest Puppy work so I don't really know if that is what is being done now in that new Pup initrd expermental arrangement; certainly sounds a bit like it to me.

EDIT: In case anyone else (and to remind myself of the issue) has the likes of a full installed Linux Mint (or Zorin or whatever) and tried a KL_full2fr per the instructions and script I provided, the one glitch was that the kernel didn't end up getting copied out of /boot of the full installed distro (in my case Linux Mint). Actually you don't need a copy of the kernel so you can easily fix the KL_full2fr simply by doing one of the following:

1. Copy the actual kernel out of /boot of the full installed Linux Mint to the /KL_full2fr directory and name it simply as vmlinuz
OR
2. Simply make a symlink from /KL_full2fr directory named 'vmlinuz' to the actual full install vmlinuz that is stored in /boot (of Linux Mint): That is:

cd /KL_full2fr
ln -s /boot/vmlinuz-whatever_version_it_is vmlinuz

I used 2. above just to prove to myself a symlink to the actual Linux Mint kernel would work fine in the KL_full2fr arrangement.

By the way, regarding my above post, if you do build a KL_full2fr, the latest initrd that includes the w_config save folder re-direction capability will be automatically installed.

It is important to understand the single limitation of KL_full2fr in comparison to normal KL distro installs that the savefolder must be held on a different partition to the underlying full installed distro and thus if using w_config to redirect where the save folder is located that caveat/limitation must still be borne in mind for KL_full2fr use.

Note also that a special/customised w_init is used for KL_full2fr (which is automatically installed by the KL_full2fr build/install script). I may one day/later merge the full2fr special arrangement into the default FR initrd, but for the moment I just use the normal (latest) FR initrd plus the special custom w_init to achieve the final KL_full2fr ability.

Well KL_full2fr has an issue when using with other than RAM0 mode. Yes, w_initconfig works to redirect upper_changes to other partition anywhere you want it (or can alternatively be done using w_changes/w_changes1 grub kernel line arguments), but issue is that upper_changes will include the swap file that, for example, Linux Mint full install uses by default - of course I don't want that!

Well, obviously need to either turn off swapfile usage in underneath full install (that's probably best actually) or perhaps can be made to work if any such swapfile was not the one used on main Linux Mint partition (I think? - still thinking about it - but, really, RAM2 should work fine as long as main Linux Mint full install is configured not to use swapfile - now I just need to see where that is done; probably obvious, but I'm not used to caring about swap files...).

Okay, I'll just disable it entirely in my main Linux Mint full install before using RAM2 mode in KL_full2fr variant. To do that, on running full install of Linux Mint (or whatever full installed distro you are working with) as root user just open /etc/fstab and comment out the line that includes /swap info (i.e. starts with /swapfile in Linux Mint case). Then it won't be used on boot either in Linux Mint full install or in KL_full2fr version... YES, that works fine. I'll refer to this post from main KL_full2fr main thread first post...

I was thinking that members in the KL arena 'might' want to have a "KL Theme" for its GRUB2 Menu.

Further, is it time to consider moving to just GRUB2 versus dev time to support multiple boot menu services? One less product to constantly maintain as we known the world constantly upgrades GRUB2 with timely needs in support of booting systems; this include security needs.

Not a request, rather this post is for dev consideration as KLs continue movement into its future.

Blast from the past... Spent a few hours doing some actual dev work on old weedogit script now named firstribit. Some early success getting it all to work again: posting right now from FirstRIbbed FR_EndeavourOS and with save2flash stuff in own layer of the overlay, so have EndeavourOS working fine in RAM2 mode

Thought there was a problem cos took ages getting to desktop on boot, but turned out EndeavourOS now using KDE Plasma6 instead of XFCE (at least the iso I aut o-fetched is) and this relatively old laptop was slow booting into that. Not releasing this alpha firstribit yet cos a few issues and lots of testing required, but main stuff still seems to work and I suspect multi-instance will work with it too.

If a KL experiment emerges with KDE v6.1+ and wayland I'm thinking this will become a long term distro. Reason: The among of attention and effort from the world's distro developers, now focused on Wayland and user-friendliness in the desktop experience. And there is a TON of efforts from everyone from the Linux core all the way thru to manufacturers like nVidia. Its an exciting time to be in Linux world, today.

KLs are already a head-start as it has produces great X11 when it started, but has jumped ahead in moving past that into pipewire+wayland to address audio video in support of multimedia for its future base subsystems. Many other linux distros of the world are far behind and KLs continues to move its community ahead of the pack.

Along with the dominant distros of the world, ARCH w/KDE v6+ has much efforts afoot, quietly for months. WOW!!

I must applaud the effort that @wiak and this community is doing to keep the Puppy Linux Discussion Forum at the forefront of user-friendly advanced distros technology via the many stable KLs presented over the past year. This resultant is an ENORMOUS body of work making user-life simple while providing platforms and packages useful for developers and those who test and support the KL distros presented to us.

KL's, I have found, are just plain 'stable' across the board, thus making it attractive to use. AND its ability for its ISO and its OOTB experience to be useful with little to no thought is one of the best experiences to get to desktop in the forum.

ITs tradition is EASY of use and feature rich in a stable platform has become its basis in its implementation and releases of the modern tools in the Linux industry.

KL-KDE v6.1+ is bringing a 'standard' nVidia solution into the fold that will ease users who have PCs with those video adapters. This "may" mean that extra steps to successfully use those will not be necessary as this propels into the future.

Any KL with wayland-KDE is going to attract a lot of attention from members and beyond.

This community looks very attractive and very bright going forward: Thus, a very BRIGHT Future, long term.

Clarity wrote: ↑Mon Jun 24, 2024 2:10 pm

KL-KDE v6.1+ is bringing a 'standard' nVidia solution into the fold that will ease users who have PCs with those video adapters. This "may" mean that extra steps to successfully use those will not be necessary as this propels into the future.

Any KL with wayland-KDE is going to attract a lot of attention from members and beyond.

Well it probably would, but KDE is that whole 'plasma' thing right? I don't follow tech news very closely, but that's what I remember. And not to be a prophet of doom or anything, but putting the latest KDE-wayland stuff in a KL I think would probably take the "stability" factor you speak of down a notch or two.

That's my gut on that. At least in the early stages. When KL's adopted pipewire, I think pipewire had a good 5 years of development. And maybe wayland is at that stage, since we've already got a couple distros running it, but maybe the big eye candy desktop implementations as they are now will need a lot of updating as they go. I've already run into this dynamic with Hyprland, as @Sofiya is grabbing the latest updates of Hyprland and testing and building iso's, it was necessary for me to roll back a couple versions.

So timing is important.

I think KL and pup developers could waste a lot of time constantly building in the latest unstable versions of desktop environments, when in fact there are other things that would greatly enhance the distros "user-friendliness," things like install, backup, multi-install interactive gui tools, and things of that nature.

Clarity wrote: ↑Sun Apr 14, 2024 2:30 pm

I was thinking that members in the KL arena 'might' want to have a "KL Theme" for its GRUB2 Menu.

Further, is it time to consider moving to just GRUB2 versus dev time to support multiple boot menu services? One less product to constantly maintain as we known the world constantly upgrades GRUB2 with timely needs in support of booting systems; this include security needs.

Not a request, rather this post is for dev consideration as KLs continue movement into its future.

Seems like this something you could do, because you use GRUB2 and all you have to do is build a theme and upload it.

And I don't see how having a working grub4dos in a KL takes away from also having GRUB2, or GRUB2 config, which I just used yesterday to make a VanillaDpup11 stick that boots legacy or EFI.

They aren't mutually exclusive.

geo_c wrote: ↑Mon Jun 24, 2024 2:36 pm

...
So timing is important. ...

Yes!

A desktop, whether Hyprland, KDE, GNOME or whatever addresses (or will so) your backup and other concerns in today's wayland world.

Enjoy, as I dont feel developers time is 'wasted' as not one that I am aware of advances things that become wasted. (Yes too, I know you dont mean that negatively, as you have been and continue to be a great contributor in this community)