F96_4-radky6-CE Perfomance Evaluation and Finalization

[rockedge]

@bigpup I tried out the fixes for the missing strings in /root/.pkg/sources and /root/.pkg/sources-all for Pkg2-cli in a F96_4-radky5-CE again and it works very well and brings using Pkg back.

These additions are in now in F96_4-radky6-CE but I wanted to get my radky5 up to speed so I could run the setup Zoneminder scripts to see how it went. The scripts did finish and ZM was installed.

@Clarity I went ahead and compiled QEMU v7+ with F96_4-radky6-CE which I ran twice successfully (about 1.5 hours per build). It works but is missing the network capabilities. Strange but seems to be missing a runtime dependency that is not compiled into QEMU.

Otherwise 7+ is working and will boot ISO's

[radky]

@amethyst

The final iso can be configured according to consensus opinion of the Puppy Community, but that collective opinion must be clear at this point.

Currently, the upcoming radky7 iso is configured with the main Puppy SFS plus the applications-ydrv and browser-bdrv.

From my perspective, an all-purpose browser must be available in the iso at first boot (to satisfy most novice and intermediate users) and that browser should be capable of long-term service if the user so chooses, or until a replacement or supplemental browser is added at the user's discretion.

To be clear, are you proposing that we drop the concept of a replaceable browser-bdrv and move the default browser to the main Puppy SFS or to the applications-ydrv?

Concerning the modular design of FP96, the Puppy community should decide now before the next (and hopefully last) evaluation iso is released.

[fr-ke]

Just one question:
I looked at some puppies and didn't find any bdrv used.
Apparently it has only recently been loaded in init.
Would it be possible to name the additional module bdrv and load bdrv in order before ydrv?
In my opinion, that would be compatible with the previous puppies that used save2sfs.

Further layers could then be inserted without save2sfs having to be constantly modified.

edit:fixed initd to init

[amethyst]

@amethyst

The final iso can be configured according to consensus opinion of the Puppy Community, but that collective opinion must be clear at this point.

Currently, the upcoming radky7 iso is configured with the main Puppy SFS plus the applications-ydrv and browser-bdrv.

From my perspective, an all-purpose browser must be available in the iso at first boot (to satisfy most novice and intermediate users) and that browser should be capable of long-term service if the user so chooses, or until a replacement or supplemental browser is added at the user's discretion.

To be clear, are you proposing that we drop the concept of a replaceable browser-bdrv and move the default browser to the main Puppy SFS or to the applications-ydrv?

Concerning the modular design of FP96, the Puppy community should decide now before the next (and hopefully last) evaluation iso is released.

Why can't the browser be included in the ydrv or included as a normal extra sfs file (in which case there should just be clear instructions how to load the extra sfs file? Why do we want the browser to be loaded at startup anyway, to read the html help files? If the latter is the case I suggest the help files are presented in another format (pdf comes to mind). I really do think it's important that both the adrv and bdrv are available for users to use as they please especially given their higher preference/priority in aufs. Otherwise just adapt the init and make more additional drives available (I've done this years ago already but hardly ever actually use it to be fair). Make a cdrv for the browser or load it as an exra sfs (even at boot up time like having a script in the Startup folder: sfs_load -c -q PathAndNameOfBrowser.sfs).

[fr-ke]

I've been using Puppy for years without a savefile.
I'm not a security expert, but compared to what I see in my environment, a save file moved to the adrv (everything newly installed beforehand) seems safe enough for me to carry out my e-banking.
So I think reserving one or two of the top read only layers for the end user is a good argument for using puppy.
Please reserve at least one.

[amethyst]

Just one question:
I looked at some puppies and didn't find any bdrv used.
Apparently it has only recently been loaded in init.
Would it be possible to name the additional module bdrv and load bdrv in order before ydrv?
In my opinion, that would be compatible with the previous puppies that used save2sfs.

Further layers could then be inserted without save2sfs having to be constantly modified.

edit:fixed initd to init

This suggestion about the preference of the bdrv has been made before. However, it seems that it has already been decided that the bdrv has higher priority than the ydrv. This will confuse most puppy users especially those who have been using a ydrv before but there you go....

[Marv]

I've been using Puppy for years without a savefile.
I'm not a security expert, but compared to what I see in my environment, a save file moved to the adrv (everything newly installed beforehand) seems safe enough for me to carry out my e-banking.
So I think reserving one or two of the top read only layers for the end user is a good argument for using puppy.
Please reserve at least one.

I'll hit what seems? to be the middle here. Supplemental programs on ydrv, adrv reserved for users, serviceable browser -Palemoon is fine- in bdrv and loaded by default for new users. For me, what goes in what drv is not paramount, but an all-in-one sfs approach is a major PITA. Minor additions to my supplemental ydrv are far easier than prying Abiword/browser etc. out of a single sfs.

[fr-ke]

@Marv
As I said before, I don't need the ydrv.

On the other hand, puppy advertises with its flexibility.
I do believe that many users have taken the opportunity to customize puppy according to their own wishes.
From this point of view, it is a big limitation if I can only take or leave umpteen programs as a whole. Especially where these programs (on the surface) make up the majority.

I think the browser as a module is a good idea, a real module in my eyes.

I have no idea how many layers are possible. If modularity is the future maybe not enough - otherwise one extra for the browser.

[geo_c]

I'm going to throw this out there just because I've been thinking about it, not being a developer or truly understanding overlay, aufs, etc, just ignore it if it's completely impractical.

Would it be possible to include an sfs, or bdrv of one of mike's updateable portable browsers where the file structure of the sfs resides in something like /mnt? If the new user decided to use it and update it, the updates would be stored in the pupsave /mnt directory presumably. If they ever unloaded the sfs or bdrv, those updates would still be there and need to be removed, but perhaps a script could take care of that.

That way the browser can be used permanently and updated, but it can also be removed. Also if the pupsave was reverted, it would go back to an early state, but running update again would bring it up to date.

The reason I say portable as opposed to a convential sfs, is that all the update files would be centralized in one location in the pupsave as opposed to various places in the system like /root/.config etc.

[rockedge]

Where can I find the kernel sources SFS for 6.0.12-FP??

[radky]

Where can I find the kernel sources SFS for 6.0.12-FP??

Menu -> Setup -> quickpet fossa -> Useful tab -> kernel src

[Geek3579]

And on a different tack...

I have been using the ydrv for LXDE meant for Fossapup64 in a version of frugally installed F96 and it seems to work well. I presume that it is perfectly acceptable to use this as F96 is, as I see it, a Fossapup64 derivative.

Please confirm.

[rockedge]

@Geek3579 Confirmed.

That's the true strength of Puppy Linux....if it works it's correct.

[Clarity]

... I set time to local, not UTC. ....

For most every OS you would boot on that PC, (or any for that fact), your would be better served by using UTC. ... in all cases

[Clarity]

... From my perspective, an all-purpose browser must be available in the iso at first boot ...

I concur that this SHOULD be standard in all released distros. I also concur that having it in main is preferable. for all worldly users use.

Users can continue to modify their PUPs as they see fit outside of the developer's releases.

Happy New Year, EVERYONE!

[radky]

Concerning the many comments about the proposed modular design of FP96 -- your thoughts and recommendations are very much appreciated.

Unfortunately, I don't see a way to fully address the expectations of all users.

As stated previously, from my perspective, novice and intermediate users will anticipate a functional desktop with standard features at first boot, which means a general-purpose browser and useful baseline applications should be immediately available. Experienced users may prefer a minimal 'build-your-own' desktop but I think the novice user will simply move on to the next available distro if the initial desktop experience is not favorable.

The default FP96 desktop could be achieved by the traditional all-inclusive Puppy SFS that users may optionally deconstruct and remaster to their satisfaction, but there is great flexibility in a modular system with removable or replaceable (x)drvs. In the latter case, an unwanted browser-drv or applications-drv is easily deleted and subsequently replaced with preferred applications configured in a new personalized (x)drv, sfs, portable application, or by conventional installation. Within seconds the user can convert from a full-featured desktop to one with only essential constituents, and from this base a personalized desktop is easily constructed. Adjusting the init to support additional (x)drvs is fine for experimental or personal use, but FP96 will support and utilize the adrv, bdrv and ydrv nomenclature and preferential loading as currently defined by the Woof-CE init.

To address the sometimes conflicting preferences our users may have for FP96, perhaps the most tenable approach is to retain the current modular design and enhance the main Puppy SFS with additional essential applications which will provide the baseline functionality expected by most Puppy users even if the applications-ydrv is not used. Currently, for the next iso release, I have moved the following apps from the yrdrv to the main SFS: mtpaint, qpdfview, galculator, lxtask Pup-Sysinfo, pupMd5sum. Are there other 'essential' applications for the main SFS ???

Adjusting the base SFS will provide an array of applications similar to the current official s15Pup (and greater than currently available in vanilla dpup of Woof-CE). However, the main SFS of FP96 will not include some legacy applications such as abiword or gnumeric since users often prefer alternate applications (ex: LibreOffice). In this scenario, the default applications-ydrv of FP96 will still provide a relatively comprehensive collection of supplemental applications to augment the main Puppy SFS. Even so, the ydrv is optional and the user can simply remove it (or replace with a customized version). Same for the browser-bdrv.

After six weeks, the development of FP96 is nearing completion. Time and resources are not available to continue this process indefinitely, and dramatically changing the distro infrastructure is not an option at this time. Rockedge began this project to update a retro Puppy with many new enhancements provided by our Woof-CE devs. As such, FP96 is simply an intermediate release which will showcase some of the functionality of the next-generation of Puppy Linux - such as JammyPup.

Currently, our Woof-CE devs are producing a new breed of Puppy containing a few baseline applications (even fewer than the main SFS of FP96), with the assumption that users will build a customized distro by installing preferred applications via the apt package manager. This will be an attractive option for many users, particularly for those who prefer a base distro without the usual complement of applications that some would consider non-essential.

My plan is to provide one additional pre-release iso (radky-7).

[amethyst]

Include ALL the extremely small applications and essentials that are currently in your ydrv on the main sfs, I would suggest (many of them are mere scripts anyway). Bigger applications like Abiword and Gnumeric can be in the ydrv. Applications like Gparted, Packit and Uextract are essentials in my view and should be in the main sfs if it is not already.

[Clarity]

... perhaps the most tenable approach is to retain the current modular design and enhance the main Puppy SFS with additional essential applications which will provide the baseline functionality expected by most Puppy users ...

Seems one good option for any PUP developer as it give great OOTB ability while allowing users to extend appropriately to their delight(s) in the main PUP SFS; as well as the Xdrv(s) folders to match their needs.

Developers present us with stable functional base system via their main sfs choices while users tailor based upon their chosen methods to match THEIR needs.

Although, I have not seen a document that prescribes what a base PUP 'should' entail, most PUPs contain the same programs (maybe not the same versions) across the WoofCE spectrum. The primary noticeable difference is developer choices in WM, Package-managing, and browsers that differ in the distros they deliver us. I still feel that modularity is ONLY important to me as a feature to how to manage change additions to the base system. There 'may' be some benefit in boot-times, but, AGAIN, for me that is unimportant as most current PUPs/DOGs boot reasonably fast, some with progress notifications, no matter whether Xdrv folders are present with content or not. My interest is stability, desktop performance, and persistence.

For developers, I HOPE they design favoring what is best for them to produce such that their distros do not introduce any complexity(s) that would impede their own ability to diagnose issue where they arise. Thus, in this distro's case a main PUP SFS, with Xdrv folders for users, meets that need, I think.

Keep up the good work!

[dellus]

@ Clarity: Sorry I have mixed you up with amethyst.
I still use Windows XP in parallel, so I prefer Windows compatibility. Also maybe important for newbies / Windows refugees, who otherwise might be turned off if their clock is messed up.
When searching in the forum UTC vs local I found:
dimkr: .. applications started after login. The default hardware clock mode is local time, not UTC - that's Puppy's tradition and what Windows uses. Some early 9.2.x users asked for UTC ...
wiak: ... pups I am running. As long as I untick the "Hardware clock set to UTC" checkbox then the boot continues without messing up my BIOS RTC. Seems most Pups follow mswindows lead by using local time in bios. Most other Linux prefer utc... Internet time syncing often ...

[Clarity]

Thanks @dellus for your post.

In my cases over the past 3 decades for all of the OSes I boot from time to time, my PCs are set to UTC. Even if I have new PCs installation, I continue UTC and do understand that I 'may' need to update a system to know to use UTC as the clock base. I have not seen any clock related issues with my PCs from any OS, thus far.

I do appreciate the finding of you and other developer-members and will continue to follow progress.

[geo_c]

Thanks @dellus for your post.

In my cases over the past 3 decades for all of the OSes I boot from time to time, my PCs are set to UTC.

I have in the last couple years set all my computers to UTC, I just find it's reliably consistent. But if windows is local, that's a non-sequitur.

For newbies who haven't really given clocks much thought, it can be pretty confusing as to how to achieve consistent clock results in puppy. Took me awhile to get the system settings protocol figured out.

[fr-ke]

It's not clear to me if F64-2 is primarily aimed at experienced users or less experienced and novice users.
Experienced users know the structure of Puppy.
For experienced users it is easier to install a few programs than to uninstall a large number of programs to have a clear menu.

Newcomers see Puppy as a whole and are offered the opportunity to choose from a number of partially redundant programs, remove the unnecessary part and remaster to create an individual Puppy.
Since a large part of the programs eligible for removal are currently planned as a module that can only be accepted or opted out as a whole, in many cases the removal of specific programs would not be offered and presumably as errors are noticed.
I would therefore avoid offering a lot of programs which can only be accepted or rejected in their entirety. In addition, where it is not clear at a glance which ones they are.

My suggestion:
Everything but Abiword, Gnumeric and the browser goes in the main sfs.
(An old-school puppy with two and more programs for anything and everything.)

Abiword and Gnumeric (with the alternative of e.g. LibreOffice) in one module to show the potential of a modular puppy.

The same goes for the browser.

The advantage would be that removing built-in programs and remastering would work as before.

The modules would be more understandable. I don't know if there is a solution for the bdrv yet, but I think nicOS utility suite would largely work as well.

Otherwise I would remove the menu item "remove built-in programs" and nicOS utility suite.
Although ironic that the first Puppy built into the nicOS utility suite would not fully work.

[bigpup]

+1

The original Fossapup64 9.5 is offered in several setups.

-----------------------------------------------------------------------------------------------------------------
This differs from usual pups by being more modular, sort of a two pups in one. Rather than just the main puppy.sfs and zdrv.sfs (kernel) there's also the puppys fdrv & adrv utility. So say for instance you just want a bare bones system, you can remove the adrv and get a small 180mb puppy. it can go even smaller if you use tahrpups firmware in the fdrv to something nearing 150mb. You could even compile a new smaller kernel for the zdrv and go even smaller.
--------------------------------------------------------------------------------
what the different drvs.sfs give you: .....

puppy_fossapup64_9.5.sfs 97mb
a basic system that boots to desktop. no dri drivers, no apps apart from dillo, urxvt & leafpad

adrv_fossapup_9.5.sfs 229mb
this will give you a regular puppy, abiword, mtpaint palemoon etc

fdrv_fossapup64_9.5.sfs 40mb
this is the firmware separated from the kernel and is easy to edit and change

zdrv_fossapup64_9.5.sfs 27mb
this is the kernel and can easily be changed with change_kernels

note that the puppy.sfs requires a zdrv.sfs & fdrv.sfs, the adrv requires the puppy.sfs,zdrv.sfs & fdrv.sfs.

I really do not remember anyone posting about splitting up what they actually installed.

I tried a few different setups and found most of the time you really want the full fdrv and adrv.

Plus:
note that the puppy.sfs requires a zdrv.sfs & fdrv.sfs, the adrv requires the puppy.sfs,zdrv.sfs & fdrv.sfs

Also if you put a bunch of programs into a specific xdrv.sfs then you are choosing what programs people will want.
Good luck with that!
People complain about what is in the normal adrv.sfs

What is in a adrv.sfs, has been determined by years of releasing Puppy versions, and what people reported as what they wanted for programs, to be able to use from the start.

If you think a web browser is not needed from the start.
Then tell me how you are going to access the internet, to get to a place you can download a better browser from?

Offering different programs as sfs packages, you can load or unload, to me is a better way to go.
LibreOffice
OpenOffice
Zoom
Different browsers
etc.......

Having a bunch of different programs, as sfs packages, in a directory in the Puppy repository, at ibiblio.org.
now that would be something to have!
http://distro.ibiblio.org/puppylinux/

[amethyst]

There seems to be lots of talk about the Save2SFS application of my utility suite. Maybe it will be a good time and place just to mention a few things.
The aim of the application is and was always to assist users who wants to work with a read-only system only. The idea was then to get rid of your existing save file or folder and package the contents thereof into a read-only sfs file. The existing ydrv and adrv are/were available for this. We know that most Puppy users use a save file/ folder and in many cases these save files are huge in size because many users have installed huge or lots of applications. So given this scenario, the thinking was to firstly save all your changes up to date to a ydrv which would basically leave you in a similar position as after a remaster but with the difference that your base sfs stays the same and all your changes are now in a read-only ydrv which has preference to your base sfs. So then the question was how to operate your Puppy from that point on. Since your ydrv would probably be huge, it would not make sense to update it frequently as this will take time. So in comes the adrv to save your changes from that point on. When you get to the stage where your adrv with new changes get too big to update quickly the ydrv procedure can be run again to bring your system up to date again as with a remaster. The application has 2 main options:
1. To save to a ydrv - this will bring your system up to date with all changes ever made, saved to a new ydrv. This will include: contents of any existing save file/folder (which it will replace), the contents of any existing ydrv (which it will replace), the contents of any existing adrv (which it will replace) and any changes to the system during the current session. So after this operation you will once again only have the base sfs and the new ydrv.
2. To save to an adrv - This will capture the contents of any existing save file /folder (which it will replace), the contents of any existing adrv (which it will replace) and any changes during the current session. Note that the contents of any existing ydrv will not be included. The idea is to keep the adrv very small and use it for quickly saving small system changes like configurations. My adrv is normally about 6MB in size and takes 5 seconds to update whenever I want.

I have never installed big stuff but have always used extra sfs files which are loaded whenever I want to use a big application (or lately some portables which are not "inside" the operating system). In my case I only use an adrv to save configurations and perhaps some very tiny installs like scripts and so on and of course I do not have a save file/folder. I don't operate with a ydrv either as it has never been necessary to save big system changes to it (like envisaged in the discussion above).

[Marv]

I really do not remember anyone posting about splitting up what they actually installed.

I tried a few different setups and found most of the time you really want the full fdrv and adrv.

Plus:
note that the puppy.sfs requires a zdrv.sfs & fdrv.sfs, the adrv requires the puppy.sfs,zdrv.sfs & fdrv.sfs

If you think a web browser is not needed from the start.
Then tell me how you are going to access the internet, to get to a place you can download a better browser from?

Lowering the case a bit, seems to me that having a starter browser in one of the xdrvs which is automatically loaded at first boot isn't 'having no browser' and is easy to maintain or remove.

I've been splitting -and posting- since the additional drives became available in initrd. All of my ubuntu flavored pups since ArtfulPup have been ydrv driven, no savefile or adrive loaded -and with recent kernels, no fdrv either- . My ydrv contents were posted in the FP64 discussion thread. It weighs in at 7.9 MiB. One of puppys' goals was as I recall, small size, and modularization makes it much easier to achieve that goal for those of us who still aspire. Browsers in particular are bloatware, but sharing one portable among 5 or 6 pups cuts the share per pup back to a more reasonable size.

not preaching, just commenting,

Edited once: grammar

[rockedge]

@amethyst I completely understand. With KLV-Airedale the same strategy different method.

[bigpup]

All of my ubuntu flavored pups since ArtfulPup have been ydrv driven, no savefile or adrive loaded -and with recent kernels, no fdrv either

So you are only changing the name used for the xdrv.sfs from adrv to ydrv.

Never had an issue, with stuff needing to load at very beginning, not being there, because adrv loads before ydrv?
Well, if you have no adrv, I guess that would not be an issue.

Doing away with the feature of having a fdrv that could be updated to a newer one.
Which I recently had to do to get needed firmware for a very new WIFI hardware.
Also needing to compile a driver the kernel did not have.

So you are not able to boot not using a save, so if something you install, is bad and keeping it from booting, you can still boot?

Not having a save, that loads into the file system, but not into RAM.
Drops the feature that the save is not taking up RAM space, when booted.
A save file or folder could be a very large size with stuff used very little.

But If I understand you.
The ydrv can get bigger and bigger and will always totally load into RAM.

How you put together a Puppy version for your specific hardware is fine for you.

But a Puppy release has to consider how it will work in all possible computers and their hardware.

If needing a fix to get it working on the hardware how you going to do the fix.
Like I just needed the firmware and driver the Puppy version did not have.
A newer fdrv.sfs had the needed firmware.
The needed kernel driver had to be added by putting it in the save, so when booted the save loads the needed driver.
Now try to explain to someone new to Puppy how to do this.
.

[radky]

Rockedge's original vision for FP96 was an updated ubuntu-based Puppy that would bridge the gap until JammyPup32 and JammyPup64 were ready for release. That day is very near now as next-generation Woof-CE Pups are evolving nicely and will soon supersede the current retro Pups, including FP96. As for me, it is time to step aside. I no longer have interest in repeatedly changing the FP96 format one day, only to see requests to change the format yet again the next day. I extend my appreciation to Rockedge for his never-ending enthusiasm and dedication to Puppy Linux, and to the Puppy community for supporting the early stages of this project. Going forward, I'm sure Rockedge will make good decisions concerning the constituent format of FP96.

[rockedge]

@radky We're leaving it at F96_4-radky6-CE, that is what I have been saying several times already. It already does everything they want. Everyone needs to remember that individual customization is up to themselves and we are providing a solid really nice foundation to start with.

We are going to clean up the last details, produce the package and versions list, a summary and a screenshot. Then I will request that the ISO be uploaded to the puppy repo. That's it as I see it. I said starting 4 or 5 pages ago several times this is ready and is hours away from a report to Distrowatch.

No more discussion about the format. It is staying as is because the goals were met. The present F96_4-radky6-CE is really an excellent distro for the task of holding the fort until Jammy arrives.

I will begin an entire new topic dealing with the future Jammy's meanwhile the world can enjoy radky's master craftsmanship. On this new topic the community can go nuts discussing the alphabet drives.

From the bridge the orders are: hold course and full speed ahead.

Do not let the noise distract you now when we are so close to releasing this beauty of a distro.

Everyone MUST remember the origin of this operation is time pressure and Distrowatch. Happy New Year. I'm not doing this alone.

[retiredt00]

Haly New Year
I'm not quite sure but it would appear that the 6.0.12-FP kernel in radky-6 is build with gcc 11.2.0/libc-2.33 while the devx has GCC 9.4.0/libc-2.31.
As a result drivers can not compile against this kernel in radky-6 because of an objtool error.
Maybe I'm doing some other mistake but did anyone compile any drivers in radky 6 with the 6.0.12-FP kernel?