F96_4-radky6-CE Perfomance Evaluation and Finalization

[amethyst]

@amethyst I can also provide the files contained in the ISO individually if needed. Let me know and I'll set it up.

A look into the audio setup will be undertaken as we progress to make sound system more versatile

Thanks, I'll check if I can succeed with downloading from Google Drive first.

[bigpup]

@mikeslr

That's probably a result of my recommendation to name of the 'included' 'additional' sfs to ydrv rather than adrv. That recommendation was made because of the 'stacking/priority' order and the way nicOS-Utility-Suite's Save2SFS module used to work. An adrv used to be copied into RAM last or, at any event, have 3rd highest priority in the 'merge-file-system' [only lower than changes currently in RAM not Saved, and changes Saved]. Amethyst's Save2SFS module used to be able to create or update an adrv.sfs without having it include the contents of the ydrv.sfs, but not vice-versa.. With the publisher issuing an adrv.sfs, the user either had to manually change its name to ydrv.sfs, or modify the adrv.sfs in order to have the user's preferences prevail.

@ Amethyst. Amethyst has since modified the Save2SFS module. But I'm confused by the change. TBA, I've been too busy to test the result of the change. When the Save2SFS module is called the following GUI appears:

Save2SFS.png
Save2SFS.png (24.78 KiB) Viewed 54 times

As you can see it offers to Save either to a ydrv or an adrv and also to 'Exclude existing adrv and ydrv'. I read that to be 'BOTH' without an option of Exclude one but not the other. But I could be wrong: there might be subsequent GUI that enables a User to select to exclude one but not the other. I created and have a ydrv which includes settings, customizations, and all applications I know will never be changed or need to be updated. My adrv, on the other hand, contains applications I frequently will need to update, e.g. web-browsers. In updating adrv I want to exclude ydrv, but not adrv. Perhaps, amethyst could post to the Utilities thread how to do that.

The utility suite (including the save2sfs tool) was last updated on 13/2/2022, so nothing has changed since.
Recommendation to use the save2sfs tool as is with this new Puppy. We assume that the user starts afresh:
1. This iso ships with a ydrv which contains the applications and it has the adrv and bdrv available as additional drives.
2. Keep the ydrv shipped with the distribution as is. The Save to ydrv AND the Exclude existing adrv and ydrv options of the tool becomes obsolete, don't use it.
3. Use the bdrv for applications you want to add (applications that are not installed) or load these applications as extra sfs 's.
4. Use the Save to adrv option of the tool to record your current changes and any future changes you want to save to an sfs file (adrv).
5. Using a save file or save folder is up to you. The Save to adrv option is there whenever you want to save your changes to an adrv. Whenever you do decide to use the tool to save your changes to an adrv, it will replace your old save file / folder and old adrv.

So this version of Puppy is no longer going to use the different drv.sfs's as they are suppose to be used?

This is the latest documentation from Woof-CE
https://github.com/puppylinux-woof-CE/w ... README.txt

[rockedge]

Being able to use the alphabet drives as they work in Fosspup64-9.5 I think will be possible. That's up to the user. What is going to be supplied as default in the ISO will be different.

@bigpup remember F96 is built from woof-CE is already has what comes in a woof-CE Puppy, there might be some rearrangement to meet new demands, but the overall function is only slightly modified.

[amethyst]

So this version of Puppy is no longer going to use the different drv.sfs's as they are suppose to be used?

tmpfs read-write
adrv...sfs read-only
ydrv...sfs read-only
puppy...sfs read-only
fdrv...sfs read-only
zdrv...sfs read-only

Yes that is the stack order we are used to. They have added a bdrv to this distribution, which I gather follows the adrv directly in the stack order ("above" the ydrv).
I haven't downloaded or used this Fossa. My post was made with my understanding as what this iso contains,ie. interalia a ydrv containing the applications (a text file was even send to me upon request which indicated the applications included in the ydrv and these packages listed under ydrv_files in packages) . An adrv and bdrv envoked and available for the user to use as he/she wants. If they decide to add a browser seperately, my suggestion is to ship it with the iso as a bdrv (or add it to the ydrv which wouldn't be such a great idea). The fdrv and zdrv to be used as it has been used before. Quite frankly I don't care who decided what the adrv and bdrv contains or what it should be used for (I decide what I want to put in my adrv and bdrv). What is important, is the order of priority/ preference of the additional drives. As long as the adrv has top priority of the additional drives (top of the stack), I'm happy and so would be most users as they are used to for years. I've tried to give a solution with regards to the use of my application (whoever wants to use it) with this Puppy. I'm not going to change my applications (especially the Save2SFS tool) just for this Puppy, not everyone is using this Puppy. The specific tool is designed to save system changes to an additional drive to replace the save file / folder. Changes to the system (especially where system configurations are concerned) will obviously have to be saved to the additional drive which is top of the stack (to ensure that your system will work correctly afterwards) and that should be the adrv.

[bigpup]

What is being done by this Puppy version as it is right now.

It is using a ydrv.sfs to do what adrv.sfs is designed to do.

Because there is no adrv.sfs the ydrv.sfs is almost doing what the adrv does.

Except for these things:
1. with a bdrv.sfs it is not being placed in the filesystem stack directly below the save.
2. it is suppose to be used to override the contents of puppy...sfs.
3. Because there is no adrv.sfs (which is suppose to override the contents of all other sfs files).
Can the ydrv.sfs also override all sfs files?
4. If there is a adrv.sfs it will be placed directly under the save and above the ydrv.sfs in the stacked filesystem.
5. If an adrv.sfs has something that would replace something in the ydrv.sfs.
Should it have this power, which it will?

If the adrv.sfs is going to be an sfs that you have to make and make it the way you want it.
If you add a adrv.sfs with something in it. It is going to do basically what the save does, when something is added to the save.
Except it will also load everything in it into RAM.
Will not be able to remove anything without making a new adrv.sfs

What advantage is this not following the standard use of the drv.sfs providing???

All I see is it providing possible problems.
Unless this is using an initrd that is not the same one provided by Woof-CE.
This different initrd does not work the same way.

[dimkr]

If you unpack initrd.gz, replace the init script it with the current one on woof-CE (https://raw.githubusercontent.com/puppy ... nitrd/init) and re-pack it, you'll get this fix. This is the problem with manually edited builds, they can't be rebuilt automatically using the same woof-CE plus one fix.

[amethyst]

It is using a ydrv.sfs to do what adrv.sfs is designed to do.

Says who? This is the problem, people deciding for others what they think the specific additional drives should do. I say nonsense, use the additional drives as you wish for your purposes as long as the stack order is known. In my opinion only the base sfs, fdrv and zdrv should have specific use as have always been known. As far as I can see, the only issue now is the stack order of the added bdrv. I think it's okay that it follows the adrv directly in the stack (this would also be a sort of logical alphabetical order). I think dimkr's init has the bdrv at top of the stack as I understand it.

[bigpup]

says who?

The people that code for Woof-CE and the Puppy master 01micko.
They control the code that controls how Puppy Linux operates.

Because there needs to be some standard to how the drv.sfs are used.
So that code to run Puppy Linux can have some common way to work.

Again what is the advantage to not follow the standard way drv.sfs are used and work???

[rockedge]

This is the problem with manually edited builds, they can't be rebuilt automatically using the same woof-CE plus one fix.

Believe me when I tell you I completely understand this. I'm living it.
For that reason I've been following KLV development with the details added to the PLUG recipe so it can rebuild just like that just with another system.

So far those who know how to adjust woof-CE to do this are not helping and I DO NOT KNOW HOW to yet.
I couldn't agree more @dimkr that all of this in F96 needs to be translated to the Jammy recipe for woof-CE generation. I thought we are all past the idea of making F96 a true full woof-CE generated distro and focus on this goal is to polish the Jammy recipe.

So this reminder of the state of things is heard and shortcomings well documented, yet the facts remain the same.

For anyone listening I am running out of momentum and the inspiration to actually bring this project to it's goal of being released. @radky has jumped ship and now I am questioning the actual usefulness of F96 or what ever the community want's it named.

[amethyst]

The people that code for Woof-CE and the Puppy master 01micko.
They control the code that controls how Puppy Linux operates.

Because there needs to be some standard to how the drv.sfs are used.
So that code to run Puppy Linux can have some common way to work.

Again what is the advantage to not follow the standard way drv.sfs are used and work???

The base sfs, fdrv and zdrv should be the only drives which use are pre-defined and it has always been like this before. As mentioned, I'm only concerned about the additional drive's position in the stack, I use them as and for what I wish.

[bigpup]

Ok.

But you make your specific version of an operating system.
Best you could call it is Puppy Like.

Just like these:
EasyOS
Fatdog
The different Dog versions

[rockedge]

That's it I'm out. Project finished.

[amethyst]

Ok.

But you make your specific version of an operating system.
Best you could call it is Puppy Like.

Why it conforms to how Puppy has always operated? My own constructed initrd has the additional drives in this order: adrv > bdrv > cdrv > bla bla bla > ydrv > base > fdrv > zdrv

[rockedge]

@bigpup F96 conforms to how Puppy has always operated. It's built from woof-CE. F96 has manual polish and bug fixes.

Go stick with S15 and all the "real" Puppy's because as of now F96 is a proof-of-concept demonstration that has done it's job. Further dev by me is over.

[bigpup]

That's it I'm out. Project finished.

Why????????????

I thought this was going to be a release to post on Distrowatch as a new version of Puppy Linux?

Now you are going to call it a Puppy Like version?

[bigpup]

F96 is a proof-of-concept demonstration that has done it's job. Further dev by me is over.

What proff-of-concept?

[bigpup]

Ok.

But you make your specific version of an operating system.
Best you could call it is Puppy Like.

Why it conforms to how Puppy has always operated? My own constructed initrd has the additional drives in this order: adrv > bdrv > cdrv > bla bla bla > ydrv > base > fdrv > zdrv

We just do not agree with the need to follow the way the different drv.sfs are suppose to be used.
I already gave a link to the documentation at Woof-CE explaining what should be in the different drv.sfs's.

[rockedge]

@bigpup Don't know what to call it now. I was thinking of a distro to get us to a Jammypup.

Apparently only a distro that can be generated by woof-CE is a Puppy Linux. But guess what? I have made hundreds of woof-CE generated Pup's since Tahr and NOT ONE of them came out of the build like ANY of the distros that were actually released. Maybe dimkr's stuff does, but tahr, xenial, bionic definitly never built to the point of what everyone was using and called Puppy. I am trying to make a F96_5-radky6-CE that has Pkg2 working well but lack of focus has delayed it.

[amethyst]

Just as a matter of interest, this how I use my additional drives. I have a modular system (although I'm using older Puppys which has the applications builtin to the base sfs) with no save file /folder: adrv = changes to system (ie. configurations, etc.); bdrv = updated glibc; cdrv = updatedgtk ; ddrv, etc for applications that need to be loaded "above" the base sfs. I do not currently use a ydrv but it makes sense to me to put the applications of the distribution in a ydrv that was suggested with this Puppy.

[rockedge]

"proof-of-concept" is an excuse for an unfinished project being shelved.

[amethyst]

"proof-of-concept" is an excuse for an unfinished project being shelved.

I have not downloaded the unfinished project yet but does the iso as uploaded so far work as I think it would, ie. additional ydrv with distribution's applications, adrv followed by bdrv, followed by ydrv in the stack?

[rockedge]

@amethyst Yes it should. The ISO's will be available. If you have trouble downloading let me know and we can try a different arrangement and location.

F96_4-radky6-CE has the latest discussed alphabet drive mechanism.
KLV-Airedale-rc6.1.iso

[amethyst]

@amethyst Yes it should. The ISO's will be available. If you have trouble downloading let me know and we can try a different arrangement and location.

In that case, I do not see an issue with the order of the additional drives as is. Is there a reason why it shouldn't be kept this way?

[bigpup]

I really no longer know what is a real Puppy Linux OS.

The rules that are suppose to determine this seem to not be followed.

01micko, who is suppose to be the Puppy Master, and the one making the decisions.
Never posts on this forum.
Seems to only work on the code in Woof-CE and make decisions on if the submitted changes are put into the code.

I guess Puppy Linux is turning into a bunch of different operating systems, that do some things the same way.
Well they all boot a computer and provide a working desktop, with some programs, and are Linux based.

[rockedge]

I do not see an issue with the order of the additional drives as is. Is there a reason why it shouldn't be kept this way?

I do not see a problem either. I think the mechanism should remain because the flexibility is still there

[amethyst]

I do not see an issue with the order of the additional drives as is. Is there a reason why it shouldn't be kept this way?

I do not see a problem either. I think the mechanism should remain because the flexibility is still there

Okay so we agree that you can finish the project then (whilst bigpup is keeping himself busy with micko's text files).

[rockedge]

I guess Puppy Linux is turning into a bunch of different operating systems, that do some things the same way.

I think F96 works almost exactly the same way Slacko, Lucid, tahr, xenial, bionic, focal do. I seem to remember all kinds of changes between each one.

And as I will repeat again, show me one woof-CE generation that made exactly a distro that Bionic64-8 is or Fossapup64.

My communication with The Puppy Master is on Facebook of all places.

@amethyst don't think F96 will ever be a full woof-CE recipe.

We can get it to F96_5-radky6-CE with the replacement of Pkg with Pkg2 and with all of the mechanisms as they are now.

[amethyst]

So what building recipe are you using for KLV? Maybe we should just use other building scripts and move on from calling the result Puppy. Like using a a building script called Dogshit and name the resulting product Dogshit version 1, etc. Just think about all the cool names we can produce.

[rockedge]

So what building recipe are you using for KLV?

I use @wiak 's FirstRib build script that follow a PLUG file recipe which looks just like a shell script to build a rootfs and then using another script which extracts the Void Linux kernel and modules if used and builds a initrd.gz (initrd.img) for it. KLV was designed to also use Puppy Linux huge kernels or Debian derivative kernels as well as the actual Void Linux kernels. Updating kernels in KLV is right now a manual job.

The KLV scripts build distro's that use OverlayFS and not AUFS and what comes out of the scripts at this point still needs manual work to put together a finished boot-able ISO. It would be possible to do what you've suggested with some work on the PLUG recipe but the finished distro would be more like FIrstRib - KLV because of the differences. Our best strategy would be to continue to work with woof-CE. And finally get a grip on how to actually use it.

There is no getting around it, I'll have to learn how to woof to get all these good ideas now in F96 into a Jammy recipe to at least come close to a finished polished distro generated by woof-CE.

For now let's finish this one and bring to the goal line despite the shortcomings and once it's on the real Puppy Linux repos and listed on Distrowatch we can go all in on getting Jammypup as complete as possible.

bigpup could take a look at the missing F96 documentation needed for a release and write us some text. We all know much work there is left to do to create even the basic manuals and package + version list. Lot's of work to do on all the Puppy Linux documentation and tutorials.

We need to get bigpup and myself up to speed on Github submissions and pull requests so bigpup can get excited about the projects and contribute the important stuff

[amethyst]

Any reason why the building of Jammy can't be attempted right now (put that forward as the official Puppy), we have peebee already producing a 32-bit version. Use the init of this Puppy?