new KLU-jamXFCEbase 1.1 (620MiB) Ubuntu Jammy-based

[Grey]

Go on EasyOS thread and attack BarryK, or maybe FatDog,

@amethyst, grab a couple of beers and let's go to the FatDog section together We will "bother" and "terrorize" @jamesbond, he is not as gloomy and serious as wiak
@wiak That's it, I'm shutting up

[amethyst]

I think the name of the forum should change...but please ignore, I'm going off topic again (which seems to be a bit of a sensitive issue with some).

[wiak]

I think the name of the forum should change...but please ignore, I'm going off topic again (which seems to be a bit of a sensitive issue with some).

It is sensitive in the sense that I am the developer of KLU-jam and so I read this thread related to that and do my best to answer questions on this thread. The sensitivity, if you really want to frame the situation in that way, is that I am busy rebooting my machine every few minutes testing new dev work in KLU-jam getting ready as quickly as I can for rc2 release. I am too busy for the negativity of your completely off-post remarks. Lay off.

[wiak]

KLU-jam will continue to be developed no matter how despondent that makes any Puppy fan.

[amethyst]

I think the name of the forum should change...but please ignore, I'm going off topic again (which seems to be a bit of a sensitive issue with some).

It is sensitive in the sense that I am the developer of KLU-jam and so I read this thread related to that and do my best to answer questions on this thread. The sensitivity, if you really want to frame the situation in that way, is that I am busy rebooting my machine every few minutes testing new dev work in KLU-jam getting ready as quickly as I can for rc2 release. I am too busy for the negativity of your completely off-post remarks. Lay off.

It's a pity that you see my post as negative...but I''m off.

[rcrsn51]

Okay, so let's get this straight... This is the KLU-jam thread. It is nothing to do with Puppy Linux.

But its location in the top half of the forum gives it the appearance of having a closer connection to Puppy than those "other" distros at the bottom.

[wiak]

Stop invading a distros dev thread with forum structure complaints. KLV-Airedale thread been active for months yet none of these off-topic remarks pushed there? Rockedge designated KL distros as built out of multiple forum distro parts. I have contributed KLU-jam to be developed by any interested community members on that basis. I thus supplied it with FirstRib initrd, but with kernel, modules and firmware produced by Puppy's kernel kit. Other parts from other forum projects are also added or being added. That's why it is a Kennel Linux designated distro. Nothing to stop you building a KLD (Debian) starting with Porteus initrd if you want. Not that porteus initrd actually originated on this forum, by the way. I do wonder why KLU-jam arousing sudden concern when KLV-Airedale did not, but please take such off-topic worries about forum structure out of my KLU-jam development thread once and for all.

[rockedge]

But its location in the top half of the forum gives it the appearance of having a closer connection to Puppy than those "other" distros at the bottom.

I can put anything anywhere I want to. The only reason there aren't the same complaints against KLV-Airedale is because the critics realize that fact.
I had it stuck in far corner at first, but it is very very clear to me the real direction we're going. So why not put it up top?
You have a Puppy to replace it? Or we gonna spin in circles waiting for those replacements to arrive?

And here we have F96_4-radky6-CE as a distro that could be of real interest to the Linux users ready to go......but no. It's not this it's not that.....

Then go make "that" which I don't see happening anytime soon.

Turns out even the Puppy Master hasn't put much effort into Puppy Linux in years. And you wonder why the projects seem splintered?

[mikeslr]

I always wondered why the Comic Section wasn't on the front page of newspapers. Do you remember newspapers? Well the Comic Section was the only part I read. I got news from TV and the radio. That was depressing enough.

F-96 was ready for publication months ago. Even my posts were just nit-picking. Anyone can boot into Bionicpup gradually updated from its initial version 4 years ago and find something to complain about.

The Kennel Linux Section is where it is. Easy to find; easy to scan passed over if you're not interested.

[amethyst]

KLU-jam will continue to be developed no matter how despondent that makes any Puppy fan.

So develop it, nobody's stopping you or critisizing your work or other's work on here (I've mentioned this before). You are completely missing the point.

[wiak]

KLU-jam-rc2
576 MiB download size
Yes smaller than before (previous was 606MiB), but now actually with more xfce4 goodies included and now with autologin as root to XFCE desktop (can change to autologin as, for example, normal users spot or firstrib if you wish).
Download and some changes details per usual at first post of this thread.

Since it is smaller than before, it would still be smaller than some recent forum distros even with firefox installed yet a fully Ubuntu Jammy compatible multi-user distro with all FR initrd overlayfs RAM mode save on demand capabilities and up to 100 sfs addon or uncompressed directory layers in numeric layer order.

Uses slightly more RAM on initial boot than rc1 did, but that's because of the several extra xfce4 activated panel goodies. You can remove anything from the panel (or add more) at any time that suits you. However, the reality is KLU-jam uses much less RAM and CPU than most XFCE distros. Similar efficiency to KLV-Airedale.

NOTE: Set your timezone via StartMenu -> SetUp -> Timezone

EDIT: One really minor thing I forgot was to update the cherrytree note. Not worth doing for rc2. Once any bugs detected or whatever that warrants an rc3 release I'll endeavour to fix the cherrytree note at least a bit since wrongly says no autologin when of course there now is. I intend keeping base at around the above size whatever gets done to it (quite a bit smaller and even more resource-efficient probably - I again forgot to take out snapd... which isn't needed at all the way the distro is set up). I will likely release FE and CE larger editions (CE to mean both Community Edition and Chromium edition..., FE for Firefox Edition, which will be the smaller of these two - not sure what size it will be - I expect around 700MiB for these browser including versions too - will build a test FE iso tomorrow to see. I don't like Palemoon at all, so will avoid that even tho maybe smaller still).

[Sofiya]

[wiak]

KLU-jam-rc3 now released. See first post of thread for download links and details about Changes.

Now available:

Smaller base version, which doesn't include internet browser - so you can add your own to save persistence without update bloat:

548 MiB download size Yes smaller than before AGAIN (rc1 was 606MiB and rc2 576MiB), but still with same user apps and goodies installed.
KLU-jam-rc3.iso

or "FE" edition, which is the same except comes with full Firefox (currently version 109.0.1) pre-installed:

611 MiB download size
KLU-jamFE-rc3.iso

So even KLU-jamFE-rc3.iso is pretty small considering full Firefox browser included. However, base without Firefox has the advantage that upgrades to Firefox will overwrite old Firefox files in upper_changes rather than use addional space to that of any iso-internal version. Nevetheless, for the the likes of Virtual Machine use the browser-included release saves needing browser installation to save persistence.

Once these have been tested for some time, and any possible bugs sorted out, I may likely later release a KLU-jamCE (Chromium-browser pre-installed edition), which will be a bit larger than KLU-jamFE
I don't like Palemoon, despite it being maybe smaller, so forget that or load it as a portable sfs if you have such and want it... (but why???!). However, the smaller KLU-jam base release above is excellent choice for using one of the many portable browsers discussed/produced on this forum (though up to the portable app producers to make them work with KLU, KLV, and KLA; shouldn't be too difficult to arrange).

The updates seem to have fixed the Qemu dhcp issue - now connects for me to Qemu eth0 interface without issue (do NOT now install dhcpcd5 - not needed and would clash with existing dhcp client mechanism).
EDIT: Must have been a fluke boot. No, with Qemu I still needed dhclient eth0 trick - but do not install dhcpcd5 since I found that causes shutdown issues and dhcp running continuously in background).

Whilst the kernel/modules/firmware remains as before, there is a chance Ventoy boots will work for more computers since I fixed an accidental bug I had caused. Boots fine with Ventoy on my own computers anyway. However, if firmware is the issue for others, sorry...

We should really post some of these KL distros on Distrowatch too, but I'm not keen to attract too many downloads in case I get thrown off my Mega account for using too much bandwidth.
For the moment, if you want printing you'll have to install CUPS yourself (should be trivial). Later (maybe much later depending...) I'm likely to include it in the larger releases since I need it (sometimes) anyway. In terms of media space/bloat it is better to use slimmer base frugal install since updates, that might occur regularly, otherwise get written into savefolder such that the original old versions lie dead on the iso no longer used. That's why I feel adding own browser via apt is a good idea and/or employing a ready made AppImage or other form of portable.

[wiak]

I'm currently busy with a KLU-jamCE (here really meaning Chromium Edition) that I've now made an iso of (i.e. includes Chromium browser, currently ver 109.0.5414.119 with resulting iso size 645MiB).
I won't be publishing it for quite a while maybe since wanting to do some special developments to it first, however, anyone can take KLU-jam based edition and add Chromium to that (which is all I've done thus far).
With Chromium all the usual problems for running as root user occur (including reliable audio) so I'm looking into all the workarounds to really pin that down to my satisfaction in KJU-jamCE.

I'm thus taking this opportunity to concentrate on Pipewire, so am currently playing with that, with the idea to implement better network-wide audio/video via sockets and so on, which is what you really need to do if you want individual control of multi-user audio (rather than the generally not-recommended for desktops pulseaudio --system approach).

I'm very familiar, from my past, writing small Interprocess Communication Protocol (IPC) programs in C, involving the likes of local unix sockets and network stream (tcp) and datagram-based sockets (udp), and such sockets are fundamental to manipulating how pulseaudio and pipewire works. No doubt Google's later QUIC protocol will play a major role instead of tcp - I don't know if used via Pipewire or not as yet, or if it will be or can be); More generally, in May 2021, the IETF standardized QUIC in RFC 9000 according to Wikipedia so I'm interested to see what comes from that. Long presentation/tutorial about QUIC:
https://legacy.netdevconf.info/wiki/dok ... c-tutorial
https://blogs.cisco.com/cloud/building- ... ets-in-vpp

Regarding pipewire, it is clear to me that Fedora Workstation remains the best base distro for experimenting with latest pipewire-related developments (though I suppose a build out of Fedora Rawhide will do). See, for example:

https://blogs.gnome.org/uraeus/category/pipewire/

PipeWire & OBS Studio

In addition to doing a bunch of bug fixes and smaller improvements around audio in PipeWire, Wim Taymans has spent time recently working on getting the video side of PipeWire in shape. We decided to use OBS Studio as our ‘proof of concept’ application because there was already a decent set of patches from Georges Stavracas and Columbarius that Wim could build upon. Getting the Linux developer community to adopt PipeWire for video will be harder than it was for audio since we can not do a drop in replacement, instead it will require active porting by application developers. Unlike for audio where PipeWire provides a binary compatible implementation of the ALSA, PulesAudio and JACK apis we can not provide a re-implementation of the V4L API that can run transparently and reliably in place of the actual V4L2.

Aside from all these thoughts running about in my head, if anyone discovers any bugs or missing fundamental pieces in KLU-jam or KLU-jamFE please let me know so I can consider for fixing and/or later inclusion in future releases.

[wiak]

Decided to start experimenting with pipewire in KLU-jam (actually with Chromium Browser pre-installed KLU-jamCE) as autologin to spot user. I like things to at least work(!) early on, and as we know running as root desktop isn't intended by upstream design... All that run-as-spot stuff was driving me nuts and getting too much in the way when first I just want to basically experiment with replacing pulseaudio with pipewire...

Personally I have no problem running my distro as a normal user and doing admin from that lowly position!!! - learning how to adjust Linux permissions is just a basic piece of knowledge that is much easier than all the messing around trying to get some major facilities 'kind of' working from a root user desktop. I am no longer myself really a fan of root user desktop situation in these painful circumstances. Then again I've enjoyed using pulseaudio for years (when others here complained about it as complex bloat, which I don't find at all), and I similarly have long enjoyed the configuration ease of using systemd.. oops.

Well, I worked with sysVinit for decades so have no problem using that, and runit is similar to systemd and much better than sysVinit in terms of a logical easy to use init system, but some like living in old Linux past - not me. Developments generally happen for a good reason despite the fake news and conspiracy theories to the contrary.

[rockedge]

I switch to spot or weedog in KLV for periods of time to do certain tasks because it's easier and getting the unconventional run as root to work well is easier sometimes after seeing how it is supposed to work. Does that make any sense?

[wiak]

I switch to spot or weedog in KLV for periods of time to do certain tasks because it's easier and getting the unconventional run as root to work well is easier sometimes after seeing how it is supposed to work. Does that make any sense?

Indeed it does. Also part of the reason I am running as spot. Once I get things going from spot desktop situation it becomes an easier matter of trying to find workarounds to allow same as root desktop. But... having been using Zorin as business distro for over a year and logged in thus conventionally as a normal user, I do now wonder what is the problem with that for most people - I have no problem with normal user environment. Yes, older Ubuntu control-freak frontends were terrible, but nowadays I don't care if I'm running as a normal user - can do every admin task fine from there anyway now. So I wonder why all this punishing hack stuff just for the possibility of running as root on the desktop? Oh well, that is how this forum likes things - I'm just moaning really.

The fact is: everything pretty much works if logged in as normal user. I would have more time for other things were it not for flipping root desktop issues always. Yes, Puppy Linux distro was only really designed to run as root user and spot isn't proper normal user in that non-multi-user environment, so Puppy basically has to live with that growing problem. The issues will increase as Linux develops - one day it will not be worth the effort expanded on allowing system to run as root desktop IMO.

[wiak]

I have discovered that the way I have save2flash set up (or something...?), when I am desktop logged in as a normal user, pressing save2flash button appears to work. But... thereafter I cannot mount drives in Thunar. It fails to authenticate, and stays in that hopeless state (until below workaround).

I wasn't sure if the way save2flash would work for normal user the way I have it so testing was required. Clearly there is a problem... Workaround is to go back temporarily to root desktop and press save2flash button there. Then returning to say spot desktop the partitions become accessible in Thunar again. I think... I haven't tested this workaround much yet either.

Not sure of solution or when I'll get round to that. Unfortunately I am a bit ill for some reason at the moment so not doing much for now.

EDIT: NO. Workaround suggested no good either. For now I suggest never using save2flash from normal user. (Probably ok from commandline with sudo, but haven't tested yet).

[wiak]

I have discovered that the way I have save2flash set up (or something...?), when I am desktop logged in as a normal user, pressing save2flash button appears to work. But... thereafter I cannot mount drives in Thunar. It fails to authenticate, and stays in that hopeless state (until below workaround).

I've now made a normal frugal install of KLU-jamFE and even installed chromium-browser onto that whilst auto-logged in as spot and pressed the save on demand button at top of desktop and seemed to work fine this time. Yes, user spot needs to authenticate if trying to mount unmounted partition, but currently not seeing the issue again...

I'm not sure what is going on. The previous test was using a Ventoy boot with RAM2 back to Ventoy disk into Session folder there. Maybe no problem with normal frugal installs, but something about Ventoy save on demand?? Hopefully not the save2flash utility itself? Has anyone had any issues like I described on KLV or KLA or KLU? More testing as normal user using save2flash is required - I can't myself come to any conclusion sorry. Pity if an issue even with Ventoy only, but I could live with that - it certainly boots fine on my machine, but I'm worried about save2flash more generally since it is so critical and important, and also from normal desktop user, not just root.

Lastly I'm also worried in case my recent w_init change (making mount appear better via Thunar) could cause any issues. I don't think so, but you never know - the FR initrd does a lot of manipulations of layers and I could easily mess up by having forgotten some fine detail. Again, only help testing these situations likely to prove matters one way or the other.

[wiak]

Found another issue I don't know how to solve in KLU-jam: when screensaver comes on (as normal user anyway), no password works to get out of it. i.e. frozen on that screen.

https://bugs.launchpad.net/ubuntu/+sour ... ug/1875025

Temporary work around if caught out: Press Ctrl-Alt-f2 and login as root:root user and then ps aux | grep screen
and then kill -9 the xfce4-screensaver process and then Press Ctrl-Alt-f1 to return to normal GUI. Messy... but once back in GUI I opened Screensaver dialog and simply Disabled it altogether - hopefully I won't get locked out again! Wish I knew why spot password isn't getting out of screensaver though...

EDIT: I found this possible fix. The problem has certainly occurred to others on other xfce4 distros at least (EDIT2: wasn't a fix):

https://forum.xfce.org/viewtopic.php?id=13640

I hope that works - haven't tried it yet cos busy downloading an iso and don't want to break the system! Alternatively, for now, I will likely remove xfce4-screensaver to avoid lock outs altogether (or simply go to Lock screen tab and disable it).

Some suggest removal of xfce4-screensaver and use light-locker instead per here: https://forum.endeavouros.com/t/not-abl ... locks/5024
https://wiki.archlinux.org/title/Xfce#Lock_the_screen

[rockedge]

Ahhhhh the old screen saver trick!! Ran into this in KLV and it is a firmware is missing problem most likely. I will experiment!

[wiak]

Ahhhhh the old screen saver trick!! Ran into this in KLV and it is a firmware is missing problem most likely. I will experiment!

I was going to ask if same issue in KLV. Thought it might be related to us not using a display manager such as lightdm - thought that maybe needed for unlocking after screenlock, but I have no idea really. I'll just disable locking... but hope general screensaving works - otherwise I will try removing xfce4-screensaver and try light-locker instead (not sure if any better).

Regarding save2flash from spot desktop in normal frugal install - seems to be working fine with KLV-jamFE (Firefox Edition); maybe something wrong with my CE (Chromium jam build that I haven't released as yet anyway).

I do find an issue with Thunar failing to open mounts as spot even after entering spot password when asked. My workaround is to open Thunar as root (via sudo thunar in terminal) and then I can open any partition in there.

EDIT: re: disable lock screen wasn't itself enough, cos power management had setting lock screen when system goes to sleep under 'System' tab. I have now unchecked that and hope screen won't lock now. Will report back.
I remember now you having sceensaver issues but I don't remember the fix or maybe something you installed made it go away? I will remove screensaver altogether by default unless I find the reason I think. Though will temporary try light-locker as a substitute though I've heard can be issues with that too (aside from clash if also xscreensaver installed, which it isn't) - I still think they expect a display manager such as lightdm, but won't be installing that...

[rockedge]

@wiak Almost the entire time before using Fred's Debian derivative kernel build script this freeze kept occuring. I have one machine which happens to be my main dev machine (Dell PowerEdge server) which uses a MATOX graphics card. When the screensaver activated the only way to get back was a hard cold stop and reboot. Occured with the MATOX graphics while in a QEMU VM the same way on the same machine.

My temp workaround was to go into Settings->Windows manager tweaks and turn off the default compositor and start picom.
This does work. I tried turning off via Settings->Screensaver the lock screen and screensaver. I went as far as installing xscreesaver which running as a non root user did the screen blanking okay. This was always a drag to do because every test run of the OS I had to go shut off the screensaver blanking.

It is some conflict when the graphics drivers are not correctly chosen or missing that the screensaver blanking from XORG and the xfce4-screensaver are causing this. Once we went to the recent kernels from Debian then Void Linux, the problem stopped.

This freeze up I posted about earlier and I only experienced it with the MATOX graphics card.

Try shutting off the xfce4 compositor and start picom. Which graphics device is effected? Disable the xfce4 screensaver in the Settings

[wiak]

Yes, disabling lock screen in screensaver and then also going into Power Manager and unchecking lock screen on system going to sleep (both the power plugged in and not plugged in setting) stopped the screen locking. Saves having to do the ctrl-alt-f2 trick to login as root and then kill the xfce4-screensaver process. But... I'll try light-locker and if problems persist I plan to remove both by default.

Aside from these nuisance issues I'm enjoying KLU-jam (though actually using KLU-jamFE at the moment).

[rockedge]

@wiak I am using KLU-jamFE to start hacking away on

[fredx181]

For now I suggest never using save2flash from normal user. (Probably ok from commandline with sudo, but haven't tested yet)

It's required to run save2flash with sudo when logged in as spot, without sudo I got lots of errors on KLU (and perhaps then it could mess things up in the save, not sure though).

EDIT: New version of save2flash makes it run with sudo, see: https://forum.puppylinux.com/viewtopic. ... 229#p80229

[fredx181]

Here's a save2flash deb package for KLU .
It has latest changes, bugfix and has included systemd service for to display Save/NoSave dialog at shutdown (to be the same as in KLV-Airedale).
Install first dialog with apt, then dpkg -i save2flash_1.6.1_all.deb
But for some reason it needs a reboot to apply, to show the Save/NoSave dialog to appear at shutdown, so before rebooting it's needed to run save2flash manually (from X) to save the changes.

save2flash_1.6.1_all.deb.gz

Remove fake .gz

(4.56 KiB) Downloaded 184 times

To report about KLU: , I noticed lots of messages after installing something with apt:

Code: Select all

/usr/bin/mandb: fopen /var/cache/man/cs/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/da/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/de/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/es/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/fr/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/hu/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/id/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/it/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/ja/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/ko/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/nl/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/pl/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/pt/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/pt_BR/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/ru/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/sl/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/sv/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/tr/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/zh_CN/1996: Permission denied
/usr/bin/mandb: fopen /var/cache/man/zh_TW/1996: Permission denied
Scanning processes...                                                           
Scanning processor microcode...                                                 
Scanning linux images...                                                     

Failed to retrieve available kernel versions.

Failed to check for processor microcode upgrades.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries. 

Also, I'd suggest to make the default timezone UTC, not New Zealand, and the timezone selector is a bit of a PITA, have to scroll endlessly to get to "Europe/Amsterdam" , but no big deal for me though, I can just type it, but for newcomers it can be a pain.
Will do some more testing later (tested now rc-3)

[mikeslr]

Selecting time zone: I know it's nice to pick the one which id's yours specifically --e.g us/eastern-- but the original GUI had GMT+0 thru GMT-9 at the top. Very convenient for everyone especially during the initial setup.

[fredx181]

@wiak Here's deb package tzupdate including self-made scripts, perhaps nice to include (similar is in KLV-Airedale and DebianDog, haven't heard any complaints about it, on the other hand no positive replies too )
It needs internet connection and by using curl only (not depending on ntp) it checks automatically for your timezone and sets the date and time accordingly, will apply directly after install from what I tested.

tzupdate_1.1.6_all.deb.gz

Remove fake .gz

(8.08 KiB) Downloaded 217 times

[mikeslr]

Ignore if not relevant. I setup KLV-Airedale a couple weeks ago so don't recall if it had presented the annoyance I have with Puppys.

Long ago someone figured out how to set up this 1st run sequence: After connecting to internet via SNS setting up firewall is automatically triggered. [The same could be --but isn't-- done with frisbee, Network Wizard and now conman. But that it hasn't isn't what annoys me]. My annoyance is that after you've selected your time zone BUT before you configure wifi 1st run triggers a GUI which attempts to connect to the relevant Time Server. This will always fail if you're dependent on Wifi. If automatic at all, that GUI should be called after Wifi is configured and firewall set or declined.

In other words, if connecting to the relevant Time Server is to be automatically initiated, it should be precede by a test as to whether an internet connection exists.