Another Jammy64pup

[mikeslr]

Hi jrb,

I know nothing about kernels so don't expect any feedback from me in that regard. Similarly, I'm not familiar with overlays. So will continue to use AUFS until I've figured out what I'd want in an OS using AUFS; then switch to whatever overlay kernel is recommended and see if using it can be just as productive. "A man's GOT to know his limitations", Dirty Harry Callahan. I do what I can.

What I can do is explore one of the reason's Barry K created woof: to enable to use of applications published by a Puppy's 'binary compatible' so as to avoid (a) the time and effort to create such applications from scratch; (b) their free-software on-line storage and maintenance requirements; and (c) the bandwidth expended to enable Users to download.

I mentioned that what currently JammyPup appeared to lack was a screen recorder. [MikeWalsh's portable build of Wiak's wex opened. But attempting configuration revealed a syntax error]. Further examination revealed that I had one which (a) appeared to work OOTB and (b) IMHO was the best. It was a VokoscreenNG AppImage. I consider it the best because of its user friendly GUI:

Vokoscreen's GUI.png (284.52 KiB) Viewed 4154 times

["Appeared" because the mic is 'X'd' out and I don't have one to test. Everything else works].
Unfortunately, I could not find the URL from which I downloaded the AppImage. Perhaps it's been withdrawn.
No matter. Vokoscreen is in Jammy64's repo. [Two versions; I chose the one whose name suggested the latest]. 38 debs. But PaDS quickly created an SFS. I mounted that, copied its contents into a folder, moved the /sbin folder into /usr, edited /usr/share/applications/desktop to point to an icon and have a Puppy-acceptable Category, then dir2sfs. Results in a 27 Mb SFS which (subject to the above noted question) runs OOTB.

p.s. The version of Take-a-gif available from Additional Software also works OOTB.

[Tippe]

Hi.

This Puppy Version has not installed anything very special, so why is it that big?

Thanks

[wiak]

Hi.

This Puppy Version has not installed anything very special, so why is it that big?

Thanks

Times have changed. Modern libs getting larger and more of them. New machines have new hardware interfaces so firmware supplied increasing so works with old and new machines. Mainstream distros range in size between 1.5GB and 3GB usually (depending also on compression used). Making a distro smaller always involves leaving something out and not worth leaving out anything that will be needed since installing later can mean uncompressed huge into save folder. Or portable app of some sort. Swings and roundabouts. Soon, small
, still useful distro will mean anything under 1GB compressed or use ancient distros with old firmware ok for old machines and old libs - but old machines die eventually so less and less of them over 12 years old... Some still use very old computers, but that's a tiny user base, so not worth dev effort ultimately.

However, the days of usb2 and less than 1GB usb sticks is also over really and 4GB RAM becomes low nowadays.

You can specially compile some bigger apps without some not wanted system-installed dependencies, which is okay but means app will have somewhat crippled functionality... limit to how far it is worth doing that.

Only major other approach is avoid mixed gtk and qt system, but if you avoid the likes of qt then programs like simple screen recorder can't be included. Careful app selection helps to not pull in more system libs as dependencies, and reduce duplication such as gtk3 or gtk4 only and drop Python2 if would otherwise be installed along with Python3.

Compare with EasyOS - much bigger compressed download but includes Libre office, Chromium, gimp and Inkscape. Problem still comes when you regularly need to upgrade Chromium... results in duplication and uncompressed into save folder.

Much better comparison would be with KLU-jamXFCE; very similar in compressed download size. Uncompressed KLU-jamXFCE a bit bigger since uses pretty much complete XFCE desktop environment and includes cherrytree hierarchical notepad out of the box and about 40 MiB of commandline utility apps I like to have by default. It is already slimmed down as far as would generally make sense really. Another Jammy64pup uses same upstream official Ubuntu repos, so very similar slimmed down size to be expected - been a long time since any Puppy distro was using own self-compiled apps.

[Tippe]

@wiak
Ok, I see. Thanks

However, there's something strange on that .iso, perhaps.

I tried to install Qjackctl.
After getting all the libs needed it refused to start by this message:

missing xcb plugin

After installing xcb it still refuses to start and still complains about missing the xcb plugin.
Without that plugin Qjackctl AND Qtractor refuses to start.
Perhaps some other programs will refuse to start also?

???

[mikeslr]

@Tippe, ditto what wiak wrote. Before reading it my thoughts were (a) zdrv and fdrv (drivers and firmware) have grown in order to handle the needs of far more computers; (b) the kernel has grown to some extent to manage those and deal with security issues; and (c) the included apps --'though bearing the same names-- are newer and larger to take advantage of the capabilities of newer hardware.
But I think you're using the wrong criteria for making a comparison. I specifically created a remastered Tahrpup64 to keep that 'overhead' low. https://www.forum.puppylinux.com/viewto ... 290#p72290. But if you read its thread you'll find my observations that it has its limitations, especially regarding the availability of current web-browsers. Also note, part of the reasons I abandoned the project was that there were many good Puppys as RAM efficient and peebee's 64bit Compatibility SFS --which functions under Tahrpup32, among others-- alleviated the risk that in the future in such RAM efficient old Puppys would not have internet access.

On old computers, incapable of running new and/or 64-bit operating systems, that solution or peebee's S15pup32 or dimkr's 32-bit VanillaDpup are more 'responsive'. Run from 'new' computers --with greater RAM and newer, more powerful CPUs-- S15pup64, F96 and Jammy64pup are --despite what may be greater size-- are more responsive than even their recent predecessors, Fossapup64_9.5 and various 64-bit Slackos. [I haven't recently worked with 64-bit VanillaDpup; but expect under dimkr's masterful development it compares well with the Puppys I mentioned].

The criteria for comparing operating systems are its capabilities and responsiveness.

About the xcb issue, I wonder if MikeWalsh's post here has any relevance? https://www.forum.puppylinux.com/viewto ... 27#p80627

[wiak]

The criteria for comparing operating systems are its capabilities and responsiveness.

Yes, that's the thing. Initial boot up RAM has grown significantly in size (even when limited by using less RAM using desktop environments and/or shutting down unwanted background services). However, as soon as you open up a couple of tabs on a modern browser the chances are the RAM being used shoots up to several times start up size anyway... Relative to that fact of life the matter is generally not very relevant therefore despite the often declared statistics. Puppy sfs files are all loaded into RAM prior to mounting by default anyway and left that way by most users it seems. Used to be that doing so increased responsiveness greatly - with modern SSD frugal installs and the way Linux caches what is loaded over time, I doubt much meaningful difference in responsiveness there either nowadays. I don't in fact find any distro I boot from even usb2 particularly unresponsive and if machine only has usb2 ports it must be pretty old and probably doesn't have much RAM to start with so can't afford to waste RAM by loading the sfs files of a modern Puppy into it anyway.

These changes in circumstances have had a big effect on this forum and its activity/projects - it used to be a really important challenge and necessity to strip a distro down such that it ran okay on the older hardware of fifteen years ago, but now we are spoilt for choice and that under 100MB iso challenge can only be met with the likes of tinycorelinux using tiny Xvesa and similar tricks that are not what most of us want for our main desktop. The challenge is more a fun thing now - back then it was actually required because of the low-resourced computers many of us could only afford... Now the likes of ten year old core2duo machines (some with low-power/low-wattage CPUs) with 2 or 4GB RAM are often found for free destined for landfill. Older machines tended to consume more electricity in the year (due to inefficient processors) such that their use has a negative effect on the environment and costs more per year in excess electricity usage than buying a secondhand newer model!

[jrb]

@wiak
Ok, I see. Thanks

However, there's something strange on that .iso, perhaps.

I tried to install Qjackctl.
After getting all the libs needed it refused to start by this message:

missing xcb plugin

After installing xcb it still refuses to start and still complains about missing the xcb plugin.
Without that plugin Qjackctl AND Qtractor refuses to start.
Perhaps some other programs will refuse to start also?

???

I think wlak and mikesir have done an excellent job of explaining the bloat that has crept into the linux world over the last 5 or 10 years. If you do need a lightweight distro I have found ScPup32-21.04_plus2-T.iso and ScPup64-21.04_plus2-T.iso to be the most efficient modern OS's available. They are close enough to Slackware15.0 to use most of its software and use about 1/2 the ram of S15Pup. Peebee provides compatible up to date browsers and AlienBob and others provide most software you might need. You have to search for it though.

Getting back to Qjackctl, I know nothing about it but as I understand it usually a plugin is software that allows a program to implement another program and is provided by the first program, in this case Qjackctl. You might search online to see if anyone can provide that plugin.

Good Luck, J

[jrb]

I just have a few noobie questions to ask

I am using a USB flash drive and am unfamiliar with the current "Save" session settings.

Using FP95 (Pupsave 13), I was given the option to create a save file and to specify a filesize.
I notice now that once I created my initial save file I am not given any options ie save or not.
Is this option available to me?
If not, is there a way to create sequential Pupsave files? Allowing me to revert back to an older version if necessary.

For the applications that I do use and are not available via PPM.
Can I use previously compiled applications built in Fossapup64-95?
I am quite happy to rebuild them in Jammy64pup as there is a DevX supplied (yah!! )

Is this OS using PulseAudio?

Everything so far works well ......... I have Bluetooth support (finally ), browser supports audio playback and I do like the layout of the applications and choice. There are a number that I have never used before.

So I created a boot USB flash drive with f2StickPup, now on the Setup Menu, and got the behavior you are talking about. I had a look at the grub.cfg file on the vfat boot partician and found "pmedia=usbhd". When I changed that to "pmedia=ataflash" things reverted to normal puppy usb behavior, Save icon on the desktop, save option at shutdown or reboot. As for having multiple save files or folders, I just went in to the install directory and duplicated the first save file. After rebooting I had the normal choice of 0 for no savefile, 1 and 2 for the availabe savefiles.

[Jasper]

@mikeslr - I think a new thread for user contributed applications should be created once a final release has been provided. My thinking behind this is that the DevX appears to have changed upon each beta being released. @jrb unless it is simply renamed with no changes?

@jrb - thank you for answering my previous questions re cross platform applications & sound

I made the changes suggested for the grub configuration and also added another parameter pfix=nocopy

I still have the Pupsave folder and not a Pupsave file. However, when I choose to resize the save folder/file it gives me options which I am more than happy with plus the added bonus of it being incremental It allows me the flexibility of rolling back and I can easily delete the backup files I do not need or store them on a HDD/other media.

I downloaded/installed the latest offering D1 and it works for me, thank you all

[Jasper]

@jrb

I was going to add @ozsouth Spectre Microcode to my boot up options and saw this in the Grub.cf file.

Is the code integrated already?

Line 24 and below

[Clarity]

Tested bare-metal booting using SG2D USB. All is well in base system.

Tested booting in QEMU VM without issues. All is well in base system.

Code: Select all

qemu-system-x86_64 -enable-kvm -vga std -m 2G -smp 2 -device AC97 -net nic -net user -rtc base=localtime -name "JRB's distros via QEMU" -cdrom upup-22.04-jrb-D1.iso

SAMBA SFS has issues that I think may not be related to what will happen with its included in the WoofCE recipe building the complete system. The current issues may be related to how it will install via the current SFS vs what will happen when included in the recipe. Seems some of the links are of issue.

I will await my further testing as this distro progresses.

The base is swift and base system is stable in use, completely thru to session-saves. The behavior seems faster in the VM than in bare-metal although each is swift (merely a gut feel done at different times).

Nice!

[Clarity]

This was mentioned earlier in this thread. It is factual!

Yes, that's the thing. Initial boot up RAM has grown significantly in size (even when limited by using less RAM using desktop environments and/or shutting down unwanted background services).

.
I would like to add that todays size does NOT impact the distro desktop performance! I find this distro as fast as was seen in older Fossa and Bionic. I do not find removal of background services increasing or decreasing system's performance ... nor its behavior.

Same/better performance, update packages, stability, ... a plus!

Oh, others are accurate to point out the increases in ALL browsers with today's websites and internet changes over the past 3 years. This will ONLY INCREASE.

As such, we should understand the fact as well, such that in some cases, RAM will need to be added to accommodate. In years ago, I worked with a half-dozen simultaneous open sites. Today, I find that sometimes I am working with 4-5 time as many in a normal capacity. This is the new normal for many of us as our PCs are capable of accommodating. Thus lifestyles in how we use our systems is a contributor to increased RAM demands.

Finally, ISO or IMG size is NOT reflective of performance. It is merely the shipping container...not the behavior.

[dimkr]

On old computers, incapable of running new and/or 64-bit operating systems, that solution or peebee's S15pup32 or dimkr's 32-bit VanillaDpup are more 'responsive'. Run from 'new' computers --with greater RAM and newer, more powerful CPUs-- S15pup64, F96 and Jammy64pup are --despite what may be greater size-- are more responsive than even their recent predecessors, Fossapup64_9.5 and various 64-bit Slackos. [I haven't recently worked with 64-bit VanillaDpup; but expect under dimkr's masterful development it compares well with the Puppys I mentioned].

Small ISO size doesn't mean better performance. It's a fallacy. Take jammy64, recompress every SFS with xz and you'll gain ~10% reduction in size but everything will feel much slower unless your computer is relatively new.

Let's take an extreme example. Vanilla Dpup includes drivers for GPU-accelerated video decoding among other things (including translations) that increase its ISO size to the 750-900 MB range. A very "bloated" Puppy indeed. On some computers, RAM consumption is lower compared to any "official" Puppy (thanks to the kernel configuration, libramsaver and other things), but even in computers where this "bloated" Puppy consumes more RAM (for example, because Bluetooth audio works and Blueman is running), the difference is tiny. However, it still feels snappier on most computers: zstd decompression is less taxing on the CPU, Bluetooth audio is less choppy and latency is lower, etc'.

jammy64 has most of the goodies in Vanilla Dpup, therefore size and performance characteristics are similar. (VA drivers and extra fonts are notable omissions, they're big.)

(A 64-bit Puppy is almost guaranteed to feel faster on the same hardware, unless you're really running low on RAM. This is true even on my Eee PC 1001PX, with its single-core CPU. If I remember correctly, the 64-bit variant of Vanilla Dpup 9.3.x eats only 20-30 MB more of RAM, which is not enough to justify the worse performance and the smaller range of compatible packages in a 32-bit Puppy. I'd recommend jammy64 if you want an up-to-date, Ubuntu-based Puppy, even if your hardware is old and slow, as long as it's x86_64 capable.)

[mikeslr]

Jasper, "I still have the Pupsave folder and not a Pupsave file. However, when I choose to resize the save folder/file it gives me options which I am more than happy with plus the added bonus of it being incremental It allows me the flexibility of rolling back and I can easily delete the backup files I do not need or store them on a HDD/other media."

There are a couple of other options. I used to mistakenly think that a SaveFile was compressed so added a level of security. Now that I know it isn't I only use SaveFolders except in the rare instance my Puppys can't access a Linux partition. Employing nicOS-Utility-Suite's Save2SFS module to create a y-or-adrv to capture settings and include essential applications I sometimes boot pfix=ram and have a separate menu.lsting or grub.cfg stanza to do so.
Having booted pfix=RAM, I can Right-Click a SaveFolder and select 'duplicate' (giving the duplicate a different name). On reboot (without pfix=ram) the choice of both SaveFolders --and none-- will be offered. I can then experiment without jeopardizing my functional SaveFolder.

But a SaveFolder is just an ordinary folder with a special name. So under Jammy64pup you can also create a 'blank' SaveFolder by just Right-Clicking an empty space, selecting New Directory and naming it, for example, upupsave-experiment1. [Not sure why the SaveFolder so created doesn't display the default icon for SaveFolders. But AFAICT, it functions properly. I'm posting from Jammy64pup with such SaveFolder and it has preserved my settings and changes].

[Jasper]

@mikeslr

Thank you for the tips and explanation.

But a SaveFolder is just an ordinary folder with a special name. So under Jammy64pup you can also create a 'blank' SaveFolder by just Right-Clicking an empty space, selecting New Directory and naming it, for example, upupsave-experiment1

This seems like the easiest option to implement

[Jasper]

As @jrb is uploading the files to Google Drive, here is a small Perl script that might be useful to use for downloading. These have to be shareable links.

For the latest update v2.1 with-resume change permissions that allow it to be executable

Thanks to @wiak

https://github.com/circulosmeos/gdown.p ... master.zip

This is the original link to the file:

Code: Select all

https://drive.google.com/file/d/1Pqp7teRZTlFvIwZ49cIRGi5G-NOJ-RZR/view?usp=sharing

Edit the url and then simply add the name of the file you are downloading

Usage in terminal:

Code: Select all

./gdown.pl https://drive.google.com/file/d/1Pqp7teRZTlFvIwZ49cIRGi5G-NOJ-RZR upup-22.04-jrb-D1.iso

[wiak]

As @jrb is uploading the files to Google Drive, here is a small Perl script that might be useful to use for downloading.

Nice program, Jasper! But you can also get a resume download version from developer circulosmeos's original github site: https://github.com/circulosmeos/gdown.pl

Surprised it still works though since hasn't been actively developed for years and thought Gdrive would have changed like Youtube API keeps doing...

[dimkr]

@jrb @Marv Do you still have access to /tmp/bootinit.log after the boot failure with 5.15.85? Let's fix this so we can use an up to date kernel.

[Marv]

@dimkr I didn't have the original log but I redid the failure. 4GB USB2 flashdrive. It was set up already in jammypup64 D1 with one of the 'one step installers', sorry I don't remember which. Checked the boot with the 6.0.12 FP kernel on the stick, OK. Substituted the 5.15.85 kernel on the stick. Failure with the debugsave output attached, true gz. The grub.cfg from the stick is also attached, false gz. Does this help any?

The bootinit.log is:

Code: Select all

0: PMEDIA=usbflash PDRV=1585-0958 PSUBDIR=/JammyPupB_USB pfix=fsck,fsckp
1: PDRV= P_BP_ID=1585-0958 P_BP_FN=
2: ONE_PART= ONE_FN= ONE_MP=
Partition 1585-0958 not found.
6: ONE_PART=1585-0958 ONE_TRY_FN= PDRV=

[dimkr]

Does this help any?

Yes, thanks. I'll see what causes the boot failure and fix this.

[jrb]

@jrb @Marv Do you still have access to /tmp/bootinit.log after the boot failure with 5.15.85? Let's fix this so we can use an up to date kernel.

It only fails when I try to boot with UEFI usbflashdrives, one f2fs the other ext3. Boots nicely from the harddrive on my UEFI machine and also boots on my 3 BIOS machines, however on one of them if I have more than one savefolder it freezes at choosing one.

See attached photo:

Edit: Frozen at this point and requires hard reboot.

boot failure

kernel-5.15.85_on_UEFI_usb.jpg (59.38 KiB) Viewed 4176 times

[jrb]

Solved

@dimkr - other odd behavior, possibly related? On my wifes Sony Vaio laptop, ath9k wifi, connman does not find any wifi networks unless I use the savefile from another machine with rtl8xxx wifi. Then it finds mine and 2 of my neighbors using the ath9k drivers. Identical modules loaded. Have tried a few other kernels. The only one I have tried that gets around this is 4.19.23 from Bionic64. Not critical but certainly a stopper for newbies.

[jrb]

SAMBA SFS has issues that I think may not be related to what will happen with its included in the WoofCE recipe building the complete system.

I uploaded the SFS so we could iron out the bugs before including it in the ISO. Please itemize any problems you have encountered.

[jrb]

@dimkr

I switched kernels on the latest flashdrive to kernel-modules-6.1.12-kernel-kit.sfs, which I think is still the latest WoofCE Bookworm kernel. Hooray! it booted up no problem. So I switched to that kernel on my harddrive, wouldn't boot.

In fact, I was wrong. While trying to copy the boot error message, it was looking for xhci_pci_renesas, I actually let it go for the for the full 60sec pause. It then continued the boot successfully and preformed normally. I couldn't detect anything not working. (60 seconds seems to take forever.)

Also has the Sony Vaio connman problem mentioned above.

[Marv]

@dimkr - other odd behavior, possibly related? On my wifes Sony Vaio laptop, ath9k wifi, connman does not find any wifi networks unless I use the savefile from another machine with rtl8xxx wifi. Then it finds mine and 2 of my neighbors using the ath9k drivers. Identical modules loaded. Have tried a few other kernels. The only one I have tried that gets around this is 4.19.23 from Bionic64. Not critical but certainly a stopper for newbies.

That is odd. All of my laptops except 1 are ath9k -by design- For quite a while now, certainly 5.15.xx kernels and up, the ath9k is kernel supported so I need no fdrv at all. On the one outlier with an intel wifi card I just carry that firmware in my ydrv. I have used SNS, PeasyWifi, and connman with those kernels over a number of pups and the ath9k just works. I don't blacklist or do anything special except clean the relevant udev rules, SNS configuration, or connman wifi configuration (depends on pup) in the savefile or ydrv if I am moving machine to machine or kernel to kernel. In jammypup, the connman wifi configuration files are in /var/lib/connman..

Code: Select all

▶—— Network Devices ——◀

Ethernet device [0200]      Intel Corporation 82579LM Gigabit Network Connection (Lewisville) [8086:1502] (rev 04)
• Kernel Driver             e1000e
• Memory Used               292.00 KB
• Path                      /lib/modules/5.15.85/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
• Description               Intel(R) PRO/1000 Network Driver
                           
Network device [0280]       Qualcomm Atheros AR9287 Wireless Network Adapter (PCI-Express) [168c:002e] (rev 01)
• Kernel Driver             ath9k
• Memory Used               208.00 KB
• Path                      /lib/modules/5.15.85/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko
• Description               Support for Atheros 802.11n wireless LAN cards.

@jrb A thought... Try booting the Viao without the fdrv.

[jrb]

@dimkr - other odd behavior, possibly related? On my wifes Sony Vaio laptop, ath9k wifi, connman does not find any wifi networks unless I use the savefile from another machine with rtl8xxx wifi. Then it finds mine and 2 of my neighbors using the ath9k drivers. Identical modules loaded. Have tried a few other kernels. The only one I have tried that gets around this is 4.19.23 from Bionic64. Not critical but certainly a stopper for newbies.

@dimkr @Marv
Found an easy fix to the Sony Vaio connman problem. Inserted:

Code: Select all

/etc/init.d/connman restart

at the top of /usr/bin/connman-gtk. Probably could have put

Code: Select all

sleep 2

in /etc/init.d/connman but this seemed more reliable.

[Clarity]

RETRACTED...Some statements are badly worded and could be viewed inaccurately.

[Jasper]

@jrb @Marv Do you still have access to /tmp/bootinit.log after the boot failure with 5.15.85? Let's fix this so we can use an up to date kernel.

@dimkr when you made this comment are you looking at moving forwards to 5.15.85 or is there a possibility for the latest 5.15.104 (longterm) ?

Either way the upgrade will be welcome

[dimkr]

@Jasper https://github.com/puppylinux-woof-CE/w ... kernel.yml rebuilds the Ubuntu 22.04 kernel source with slight Puppy configuration adjustments (https://github.com/puppylinux-woof-CE/w ... figs/jammy) once a month. You'll get 5.15.104 once this update is pushed to Ubuntu 22.04.

[dimkr]

It only fails when I try to boot with UEFI usbflashdrives, one f2fs the other ext3.

Did you boot with pdrv=line2dd8442? Are you sure this is the partition label?

I see that kernel support for F2FS, ext3 and EFI partition tables is enabled.

EDIT:

I see this diff between the jammy64 kernel and the dpup kernel, will fix:

Code: Select all

-CONFIG_USB_STORAGE_REALTEK=y
-CONFIG_USB_STORAGE=y
-CONFIG_USB_UAS=y

EDIT 2: nope, this is not it. Looked at the wrong kernel configuration file.

EDIT 3: @jrb please try https://github.com/puppylinux-woof-CE/w ... 4519481350 once the build finishes. It aligns the USB-related configuration options in jammy64 with bookworm, and these two are the only difference:

Code: Select all

CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PCI_RENESAS=y