F96_4-radky6-CE Perfomance Evaluation and Finalization

[rockedge]

With the continued support and contributions by the members of the Puppy Linux community F96_4-radky6-CE is in the rigorous testing phase and by all accounts is living up to and exceeding expectations.

This brings us to the point where the production name of the distro will be pressed into service.
F96_4-CE_radky6.iso

FP96 Community Edition and it's polish and efficiency are the result of work behind the scenes by members of the Puppy Linux community and forums. This distro has been produced from start to finish in a most timely manner by the excellent participation especially by those mentioned by @radky and myself, with contributions of time testing, presenting ideas and methods and some tips from real life system usage out there "in the wild"

Now it is time to gather documentation of the installed packages and utilities and a summary of FP96-CE with screenshots. We'll need a packet put together that meets the requirements of Distrowatch, Uploaded to the mainline Puppy Linux distro release repository and changes to puppylinux.com (GitHub pages) to supply the links for downloading the ISO, Devx and kernel sources if needed.

Perhaps @bigpup and @wizard can conjure up some of the text needed and keep a look out that what I write is factual. Their work is evident in much if not all of the Puppy Linux README First section of the forum.

I have run some of the more tricky installations of some pretty resource heavy packages covering web servers, databases, Zoneminder, opencv and Darknet. These installed and worked using Pkg2-cli and the PPM to manage it.

Continued evolution of the modular design will keep on in the forefront as the production release hits the streets, and this community looks to the future Puppy Linux distro's that will be the S15 and FP96-CE successors

[peebee]

A hopefully helpful comment about the name.......

FP does not really give much clues about what this Pup is all about - and 96 makes me think it is 1996 vintage.....

Why not FossaPup64CE-9.6 or maybe FocalPup64CE-23.01 for the .iso and fp96ce for the sfs components?

I can help with uploading to ibiblio and changing the webpages when you are ready to go.

Cheers!

p.s. the "build recipe" really needs to be lodged on GitHub as well.....

[dimkr]

p.s. the "build recipe" really needs to be lodged on GitHub as well.....

There must be some recipe first. All the manual customization needs to be scripted somehow

[rockedge]

@peebee The name I put out is only a beginning proposal, and I like either FossaPup64CE-9.6 or FocalPup64CE-23.01. Both are long names and my first instinct was to shorten it although both these names are much more informative overall. I agree that the components could use FP96 or FP9.6 to keep those names compact. A slightly different look -> FossaPup64-9.6-CE or FocalPup64-23.01-CE

@dimkr That is the main bottleneck right now, translating the customization's and the additional package choices into a working woof-CE recipe.
My lack of expertise in manipulating woof-CE enough to successfully integrate the code and configurations from F96_4-radky6-CE will be a real slow down.
Perhaps a set of scripts that perform the customizations post woof-CE generation of Fossapup64-9.6 would be easier.

Though the ultimate goal is to have woof-CE be able to build the same distro that F96_4-radky6-CE is now

Would the easier road to take be modifying the existing Fossapup64 recipe or use it as a start for a entirely new one?

[dimkr]

Would the easier road to take be modifying the existing Fossapup64 recipe or use it as a start for a entirely new one?

I think the first option is easier. focal64 is a pretty messy recipe even before these manual modifications and it takes a lot of work to build a fully reproducible Puppy with zero unused libraries, especially if it uses many manually-built .pet packages with unknown dependencies.

However, I still think that this time should be spent on bringing all these modifications to jammy64 instead. It's in pretty good shape now but lacks all the small things, like the extra right-click menu items.

[rockedge]

.....this time should be spent on bringing all these modifications to jammy64 instead. It's in pretty good shape now but lacks all the small things, like the extra right-click menu items.

I totally agree that most importantly we look forward utilizing the technology, mechanisms and polish now in F96 and apply them to the latest builds of Jammy via a woof-CE recipe and woof-CE has the ability to build Jammypup's consistently. F96 is the bridge and prototype for the next generation of Puppy Linux.

Now with Jammy in a clean and ready state work on finalizing a recipe that will build one with all of the goodies and work will begin shortly on learning how. Starting with some tests on a local fork and branch.

F96 is meant to just be made available to bridge the gap until Jammy's can be woof-CE generated. I believe the current radky6 version will be that solid relevant distro. Long term maintenance not needed because JammyPup-CE is the actual goal and beyond.

[bigpup]

People are starting to not do this in naming a Puppy iso..

About the name for the iso

A long time ago it was decided to name a Puppy iso only using lowercase letters.

Why?

When you try to write the name to do a search or tell someone about it.
You do not need to remember what letter is a uppercase letter or which ones are lowercase.

Especially if you are doing something with the iso in a command line.

Remember, Linux is case sensitive in identifying names of stuff.
A file named Something is not the same file named something.
They are two completely different files.
.

[bigpup]

This is something that was fixed, but it seems to be still a problem with USB drives.
I seem to remember it was working good with a 10 sec. wait time.
but this post about S15Pup64 says had it set to 5 sec.

the boot process, not waiting long enough, for slow USB drives to fully power up, and be fully functional, by the computers bios.

Not sure if this affects this F96_4-radiky6-CE

But something to check.

See this topic with the fix for it.
viewtopic.php?t=7680

The fix is here:
viewtopic.php?p=76864#p76864

[rockedge]

People are starting to not do this in naming a Puppy iso..

The production release ISO will be lowercase characters. We are aware of the Linux case sensitivity though modern search engines should be able to find the distro. Try this string in a Google search : puppy linux f96

[thinkpadfreak]

F96 is meant to just be made available to bridge the gap until Jammy's can be woof-CE generated.

There is one thing I would like to point out again.

On recent puppies we cannot use IME with Chrome 102 or later. It is only on Fossapup64 9.5 and Jammypup64 9.7b / 9.8 by Grey that we can use IME with Chrome.

Chrome is partly responsible for this issue, because it seems that Chrome has changed the interface related to IME at version 102. But other distributions than Puppy seem to comply with the new interface.
It is frustrating to think how fossapup64 9.5 and Jammypup64 9.7b / 9.8 are different from other recent puppies.

Unfortunately, I am an average user, and cannot think of what makes the difference. I would like developers of puppy to make much of this issue.

[fr-ke]

F96_4-radky6-CE is very successful in its entirety. congratulations
The ability to load .sfs makes puppy super modular for me.
I see sense in big applications, mainly embedding browsers in a modular way.
However, the splitting up of Puppy also causes problems.
If I leave out ydrv, it's no longer a puppy for me. Just my personal opinion.

As @amethyst already mentioned, packing a lot of functions that I can either omit or use as a whole takes away a lot of flexibility when remastering.
Especially since the applications summarized in ydrv are the ones most likely to be deleted before a remaster.
One of puppys strengths has always been the ability to customize it with a remaster. For me, this also includes being able to cleanly delete functions.

What should a newbie think who calls "remove buildin packages" and finds out that it only partially works.
What should a newbie think who leaves out the ydrv module and has to find out by trial and error which "RightClick functions" still work.

I think this form of modularity should be reconsidered.

WoofCe is far beyond my skills, but I think integrating a "split" puppy increases the effort.

Possibly just the view of an old stubborn fool rebelling against new things.

[bigpup]

People are starting to not do this in naming a Puppy iso..

The production release ISO will be lowercase characters. We are aware of the Linux case sensitivity though modern search engines should be able to find the distro. Try this string in a Google search : puppy linux f96

Still have all the different search functions built into different Puppy specific programs that are still case sensitive with name letters.

[rockedge]

Isn't pFind case insenstive by default? A check box for case sensitive exists in the options so I assume only when checked is pFind case sensitive.

[radky]

@puppy community

If the Puppy community prefers the original non-modular infrastructure for fossapup64-96 CE, please make your opinion known collectively at this time and I can release one final evaluation iso with all ydrv applications blended into the Puppy SFS. In this scenario, there will be the main Puppy SFS plus the modular browser-drv, but there will be no default adrv or ydrv.

Thank you

[wizard]

@radky

If the Puppy community prefers the original non-modular infrastructure

I vote keep it modular.

Thanks
wizard

[rockedge]

@radky I vote for the modular design.

We can not allow ourselves to fall into "decided a long time ago" sentiment and block good ideas and practices.. This is now that was then.
F96 is intended to be an advancement of Puppy Linux technology and changes to the design must occur to insure some compatibility with the rest of the Linux world and operating systems overall.

If one wants a more traditional Puppy Linux please use S15 or Friendly-Fossa. F96 is the prototype for ideas that will go into Jammy's that can be repeatedly built by woof-CE and looks forward past 2023. Also F96 most likely will never have a finished woof-CE recipe and will remain a one-of-kind distro to bridge the gap until work progresses on the Jammypup64 woof-CE recipe and a version is ready that has all of the features F96 offers.

I also vote that we begin finalization for a release. Last few loose ends, create a package list, screenshots and a summary of the system and get it out there. Let's continue the discussions of ideas while we figure out how to translate all of the great contributions and @radky 's hard work and attention to detail to the Jammypup64-CE project.

[Marv]

F96_4-radky6-CE is very successful in its entirety. congratulations
The ability to load .sfs makes puppy super modular for me.
I see sense in big applications, mainly embedding browsers in a modular way.
However, the splitting up of Puppy also causes problems.
If I leave out ydrv, it's no longer a puppy for me. Just my personal opinion.

As @amethyst already mentioned, packing a lot of functions that I can either omit or use as a whole takes away a lot of flexibility when remastering.
Especially since the applications summarized in ydrv are the ones most likely to be deleted before a remaster.
One of puppys strengths has always been the ability to customize it with a remaster. For me, this also includes being able to cleanly delete functions.

What should a newbie think who calls "remove buildin packages" and finds out that it only partially works.
What should a newbie think who leaves out the ydrv module and has to find out by trial and error which "RightClick functions" still work.

I think this form of modularity should be reconsidered.

WoofCe is far beyond my skills, but I think integrating a "split" puppy increases the effort.

Possibly just the view of an old stubborn fool rebelling against new things.

I'll weigh in on the side of modularity. We'll never all agree exactly on what belongs in the main sfs and what in the supplemental sfs but OOTB the supplemental and the starter browser are loaded for newcomers and the modularization makes customization far easier once some experience is gained. The main sfs in @666philb s' fossapup was a bit lean IMO, I had to add quite a bit in my ydrvs (CUPS a particular pain), and the main sfs in fp64_CE is just a skosh chubby but really quite functional as a lean daily. I checked and other than my personal taste/customizations and PCManFM I added only 4 programs, galculator, lxtask, pupmd5sum, and mtpaint to my working ydrv. Not bad! If I miss something, usually quick to add. That ydrv now weighs in at 7.9 MiB and that's with no savefile or folder.

I admit to not having used remaster in quite a while. I generally got 'cleaner' and more maintainable pups leaving the main sfs intact and manually rolling custom supplemental drives and have pretty much stuck to that approach.

Having CUPS in the main sfs is near essential, thanks, and having Abiword in the supplemental or not present at all also so IMO. Abiword single-handedly generated the most complaints from my users before I replaced it with LibOffice, followed by those generated when the world passed by a built in browser. That's fairly easily fixed with a sfs based or portable browser update.

Discussion, not criticism.

another old'n

Edit: 5 programs added to my ydrv, not 4. I forgot Pup-Sysinfo.

[mikeslr]

I also weigh in on keeping it modular, especially now that ydrv, rather than adrv, holds most of the additional applications. I'll add this. I withdraw my objection to locating a web-browser in bdrv. Even if Save2SFS isn't modified, bdrv is easy to work with. As previously noted if not wanted it can be deleted or renamed. Renaming it can also accommodates modifying it. Just temporarily rename it adrv and use Save2SFS. Save2SFS can be configured to either create or modify adrv without having it include the contents of ydrv. It can also modify ydrv without having the new version include the contents of an existing adrv. [? And IIRC Save2SFS ignores the contents of bdrv?]. Once a modified adrv is created it can be renamed bdrv.

I worked with woof a couple weeks ago so by now things are hazy. But IIRC it makes use of a folder on github from which pre-built pets can be obtained to include in the Puppy being woofed. All of the Right-Click modifications I worked on are 'agnostic'. They are simply 'config' files to be employed by rox. Originally created to 'flesh-out' VanillaDpup, they have functioned under all versions of Fossapup, S15 and every other Puppy I've installed them into. That's also been my experience with all radky's 'pupmates' and any other application I mentioned here, https://www.forum.puppylinux.com/viewto ... 514#p69514

If my recollection about woof is correct, transitioning from a User modified ISO to one entirely woof-built may be only slightly more complicated than uploading the necessary pets to the proper folder on github in that the 'build-recipe' will call for the use of those pets.

[fr-ke]

As for my personal usage, I agree with @Marv. I make my own ydrv with the few programs I need in addition to the main sfs.

I tried some right click options. Some work without the ydrv module, some don't.

isomaster-iso.editor does not work without the ydrv module
Graphical Disk Map 0.8.1 does not work without the ydrv module
Packit runs in version V1.15 without ydrv instead of v.1.23 with ydrv
UExtract without ydrv v3.32 with v4.10

[tosim]

FWIW: I also weigh in on keeping it modular, AND, thanks extended to all who worked on this.

[Clarity]

This leads to a question of interest: If the main is feature complete and 'all' of the other Xdvr's are present yet empty, would this be sufficient to accommodate all users?(The "X" in Xdrv means the additions of the prefix to the multiple ?drv.sfs users would use.)

This, then, leaves the developer to build only the main with the understanding that user customization(s) would populate the other Xdrv.

I am not leaning either way as it doesn't seem to impact system's behavior...only the booting element.

Just some consideration.
Edit: explaining what the X reference means

[Marv]

A late thought on balance of modules. I think pupMd5sum and Pup-Sysinfo deserve a spot at the table in the main sfs. Tiny and I think pretty core. Can't see a thing I'd omit there.

[dellus]

Time setting issue:
Dell Dimension 5150 (pre uefi)
When booting from iso with sg2d and setting local time at start up, it shows wrong time, 1 hour earlier than it should. My time zone is Europe, Berlin. Sometimes for an instant it first shows the right time but immediately changes to one hour earlier.
When I then reboot (with out saving to a save file/folder) to installed Windows or a frugal puppy install then the pc will show the wrong early time, so the built in clock time has been changed.
The same happens if I don't make any local settings at all and accept the defaults, as I may just be testing the os.
But, in the first case, if I correct the wrong time manually after booting, after rebooting to Windows or a frugal pup all is fine.
With Fossapup 9.5 or S15pup there is no such issue.
Maybe it is intended this way, I report it to prevent it creeping into the final if it is a bug.

[Clarity]

Hi @dellus
ON pristine boots, are you setting time via 'local' or 'UTC' in "Firstrun"? This affect what PCs remembers for its clock-time.

('m sure you know, but I think what you share is that some PUPs on pristine respect the PC clock while other resets the clock on booting new-fresh. (true/false?)

[thinkpadfreak]

On recent puppies we cannot use IME with Chrome 102 or later. It is only on Fossapup64 9.5 and Jammypup64 9.7b / 9.8 by Grey that we can use IME with Chrome.

F96_4-radky6-CE is not an exception. While fossapup64 9.5 complies with Chrome 102 or later, fossapup64 9.6 does not. This is a kind of regression. Today Chrome is a browser many sites recommends, whether we like it or not. People who use IME will be worried if they cannot use IME with Chrome.

I wonder why discussions go on without paying attention to this issue.

[rockedge]

I wonder why discussions go on without paying attention to this issue.

Are you kidding? I've been experimenting with this and Chrome, which I dislike immensely, to find a solution for IME / Chrome integration.

As a matter of fact I have been looking into the fix since you first mentioned it. You can relax now.

[thinkpadfreak]

I've been experimenting with this and Chrome

I am sorry I didn't know that, because it did not appear from discussions in the forum that experiments were going on.

I can do without Chrome, but some people may leave from Puppy just because they cannot use IME with Chrome.

Edit:
If fossapup64 9.5 and Jammypup64 9.7b /9.8 are built with woof-CE, it is strange that such a difference should appear.

[amethyst]

I suggest the following:
1. Keep the current "semi" modular structure.
2. All additional applications presented in a ydrv (this already seems to be the way of course).
3. The adrv and bdrv envoked and available for use by the user (which it is already) but that no applications are included in an adrv or bdrv with the distribution's ISO (in fact no adrv or bdrv sfs 's shipped with the ISO).

Once we have consensus or decided on the above, I can update some of my utilities and release a new updated utility suite.

[dellus]

@ amethyst:
I set time to local, not UTC.
If it's not an issue to other users, then nevermind. As fossapup 9.5 and s15pup behave differently I thought it might be considered as a bug.

[fr-ke]

@amethyst wrote

3. The adrv and bdrv envoked and available for use by the user (which it is already) but that no applications are included in an adrv or bdrv with the distribution's ISO (in fact no adrv or bdrv sfs 's shipped with the ISO).

I think that would be an excellent and clean solution.