Working on F96_4-radky5-CE to Finalize a Release Version

[rockedge]

Just had my Internet connection restored so back on track again. So far I have been running F96_4-radky5-CE fairly intensely and trying out things like QEMU, compiling and trying out different configuration combinations and packages.

I am having issues with pkg-cli and have not yet pinpointed the problem. Something to do in 0setup and the line : support/findpkges which produces a file not found error./ also all of the main distro repos are not being accessed by pkg-cli with only tahr, noarch, xenial being read.

Other than pkg-cli not working 100% every other function, application, tool/utility seems to be working well. Tested all this last week usb tethering from F96 to a mobile phone and using cellular data connection for Internet access. Also tried sharing through F96 and the rest of the LAN and that worked as well as far as my simple tests went.

Some last few steps and possible artwork to be finalized then the screenshots and installed packages list we'll need for a Distrowatch notification and to add to the download selections on the main puppylinux.com pages will need to be done and finished. Really close to a production release I feel......

[radky]

@rockedge

A final evaluation iso (radky6) is almost ready for upload, with additional adjustments and updates requested by the Puppy community.

If you or other users of pkg-cli can identify a proper fix, I'll include it in radky6.

Thanks for testing.

[mikeslr]

Hi radky,
Your F-96 is fast and able to use all the applications I need. The only problems I found with F96_4-radky5 is how you've used 'alphabet' drives and how nicOS Suites' Save2SFS interacts with them.

[But I just noticed that there's a Remaster application on the menu. I haven't used it. If it's the 'old' one there's a problem mentioned below.]

'alphabet' drives are those such as fdrv_fossapup_64_9.6.sfs and zdrv_fossapup_64_9.6.sfs. If located next to puppy_fossapup_64_9.6.sfs initrd will automatically copy them into RAM on boot-up. They make it possible to include libraries, files, applications and suites of applications and always have them available and without having to employ a SaveFile/Folder or having to remaster.

Using the 'old' remaster application was time consuming and prone to producing errors, especially if you want to 'bake-in' your settings and customizations. It was time consuming because at each stage the application stops and waits for user input. If you want to 'bake-in' your settings and customizations, during one stage you have to manually copy some/which? files/folders from your running /root and/or /etc folders into the 'build folder'. That manual intervention is prone to error. As you've included nicOS-Utility-Suite, it provides two Remaster Applications which do it better. Both work faster. One enables the user to make all decisions at the start, thereafter requiring no user intervention; the other only requires user intervention if settings and customizations are to be 'baked-in'. And even that can be avoided if used in combination with the Save2SFS application included in the Suite.

The Save2SFS application was originally designed to provide a substitute to creating a SaveFile/Folder. In its current configuration it will create either an adrv or a ydrv. In doing so, it will capture the contents of SaveFile/Folder, applications 'installed' but not yet Saved, and optionally the contents of existing adrv and ydrv. It also captures current customizations and settings. Having (re)created an adrv, you can run Save2SFS again and (re)create a ydrv; or vice versa. Requiring no user intervention, it works as fast as your computer will permit.

However, alphabet drives have an 'Achilles heel': Unlike SaveFile/Folders their content does not respond to 'Uninstall'. Unlike applications 'builtin' to puppy_fossapup64_9.6.sfs, it does not respond to 'remove builtins'. To remove anything from an adrv or ydrv requires removal from RAM's current content and running Save2SFS, or manually mounting, editing and rebuilding.

I use a ydrv to hold applications which I have no reason to believe will ever be updated or that I won’t ever not want to be immediately available. In my case, one such application is masterpdfeditor-4: a really great and light-weight PDF editor, it depends of Qt4 libs which are no longer available in easily accessed repositories.

Alphabet drives also permit using Puppys with this security feature: Either an adrv or a ydrv can be used as a substitute for a SaveFile/Folder. If I have to use my laptop from an insecure location, I can boot my Puppy from a USB-Key and after desktop has been reached, unplugged the Key. I can do that because I’ve included my choice of Web-browser (and any other desired web-facing applications) in the adrv whose content during boot-up has been copied into RAM.

Why adrv? Because the ‘merged in RAM system’ file-systems employs priorities. The highest is the current contents of RAM (including installed applications not yet Saved but after Restart-x). Just below that are the applications which have been Saved to a SaveFile/Folder. Next priority is given to the applications and contents of the adrv. Re-running Save2SFS, web-browsers in an adrv can be updated without changing any other aspect of one’s system.

I don’t know how priorities are established. I suspect coding in initrd. But your inclusion of a bdrv potentially ‘threw a monkey-wrench’ into my prior method of operation. Previously, A ydrv could also be used to ‘capture’ the current operating system’s customizations and settings. [Transported to a different computer, Save2SFS>ydrv could be run again]. bdrv has a higher priority than ydrv. bdrv’s settings are ‘baked in’. Changes a User ‘captures’ in a ydrv that conflict with those in a bdrv will be ignored. Fortunately, you’ve only included one application, xfe, in bdrv. A User can change it’s settings with an adrv or SaveFile/Folder. But isn’t that kind-of a waste of a precious resource? Under AUFS there can only be a few ‘alphabet’ drives; while many applications can be installed or SFS-loaded. It is my understanding that to provide additional 'alphabet drives' initrd and/or distro-specs within initrd have be be modified.

You’ve located several applications in adrv. In addition to Palemoon, /var/packages show these:

5's adrv.png (49.85 KiB) Viewed 2272 times

In order to run F-96 ‘my-way’ I renamed it ydrv, then used Save2SFS > ydrv, after 'installing' applications I am unlikely to ever change/upgrade. Actually, I also mounted it, removed Palemoon and rebuilt it. Palemoon is an application with frequent updates. Your adrv contains several other applications which, if less frequently, have been recently updated and may be updated in the future. If continued as an ‘alphabet’ drive, wouldn’t naming it ydrv rather than adrv make life easier for Users?

There might actually be a better way to provide many applications. According to a recent post by dimkr, viewtopic.php?p=76501#p76501, in woofing a Puppy, “You can add quickpet to the rootfs-packages directory.” How you get applications into the repository quickpet accesses is something I don’t know. But if Quickpet can be used, it’s a much more user-flexible method to provide applications. Indeed, as quickpet does not require the presence of any web-browser, it could eliminate the need for the Puppy’s creator to provide one which the User may not want.

[fr-ke]

@radky
@mikeslr

+1
I use the 'alphabet' drives exactly the same way.

And would like to reserve adrv as a top drv as a replacement for the savefile.

The savfile overwrites all other layers. When it is deleted the original Puppy is there unchanged.
The next highest layer is adrv in most puppies.
I find the combination of adrv and savefile would have the advantage that the underlying OS could remain untouched and the changes could easily be reverted if something didn't work as it should.

[rockedge]

I added the bdrv in the first stages of F96 for demonstration purposes and I wanted to have a 2 pane file manager so the two fit together. The main test being how the bdrv interacts and performs in F96. I envisioned using it to add on tools and utilities that may not be desired by every user of F96 and could be removed from the boot stages and they would be fully removed from the system.

Maybe we look at creating manager GUI for dealing with the alphabet drives excluding the fdrv and zdrv as kernel core images and remain read-only.

[mikeslr]

I added the bdrv in the first stages of F96 for demonstration purposes and I wanted to have a 2 pane file manager so the two fit together. The main test being how the bdrv interacts and performs in F96. I envisioned using it to add on tools and utilities that may not be desired by every user of F96 and could be removed from the boot stages and they would be fully removed from the system.

Maybe we look at creating manager GUI for dealing with the alphabet drives excluding the fdrv and zdrv as kernel core images and remain read-only.

Actually, that's a good way to use bdrv. But I'd suggest applications which are less useful than xfe*. For example, how many people still need DVD/CD burners? Or for that matter, printers. I need a printer about once a year, about the same time as I think about setting up a local area network so I don't have to lug a USB-Key from my computer to my wife's which can be connected to the printer with a cable. A bdrv with those applications, renamed 0bdrv, could just sit there until needed; at which time it would be a name change and reboot away.

Changing an adrv to a ydrv is just a name change. Using Save2SFS, if bdrv is first changed to ydrv, a new ydrv could include both the current contents of adrv and bdrv. More problematic is the inclusion of palemoon in an adrv also containing other applications. Unless you're willing to also ditch those other applications, you can't easily remove of palemoon. And if you use it --as you're tempted to do-- it will have written config files to /root. It eventually will have to be updated. Config files and updates will a SaveFile/Folder or a new adrv or ydrv further complicating overall maintenance of a clean system.
I'd rather see it in the puppy_fossapup64_9.6.sfs where remove builtins could remove it if it weren't wanted; or its desktop's Exec= could be redirected to an easily updated, self-contained external portable.

While there are other methods for providing a web-browser for 'newbies' who might not already know of Puppy's many options, I don't think anyone has recently mentioned this possibility: include an ordinary SFS in the ISO.

-=-=-=-
* By the way, I really liked your settings (e.g. applications you chose xfe to open), which is why I used the above technique to create a ydrv.

[radky]

@mikeslr,

For testing purposes, I have removed the current adrv and bdrv, and the corresponding application now reside in a new ydrv. This required adjusting the location of several applications and associated configuration files, plus there are now two rox right-click packages -- one for the main sfs and one for the removable ydrv. If this approach is adopted, FP96 users will have the flexibility you requested for adrv and bdrv customization.

Perhaps a new bdrv could be used for the browser (easily updated or removed if the user chooses to do so). In this scenario, removing Palemoon would entail removing the bdrv plus a quick deletion of the browser launch file, moonchild directory and companion cache directory.

Concerning the default browser for FP96, this is always a point of discussion but I think most novice and intermediate users are interested in a general purpose browser that is functional and easily updated through the browser's menu option. Certainly, Palemoon of FP96 is not perfect, and is not your cup of tea, but other users may have similar issues with alternatives such as Firefox and Chrome based browsers. To be sure, browsers structured as portable apps are attractive options for intermediate to advanced users of Puppy Linux, but this option requires maintenance by the Puppy community. Please keep in mind, FP96 is an updated retro distro that has many new features provided by our Woof-CE devs, but it not cutting-edge in design or implementation. Hopefully, the final product will be useful at first boot, stable and easily maintained by novice users.

[amethyst]

@rockedge

Maybe we look at creating manager GUI for dealing with the alphabet drives excluding the fdrv and zdrv as kernel core images and remain read-only.

Good idea. Will be great to be able to decide which additional drives to load at bootup. This and having a lot of additional drives enabled could be extremely useful when you want to operate in RAM only mode with applications of your choice loaded as additional drives (and copied to RAM to make it possible). And to add - it's relatively easy to assign a specific name to an additional drive which could be useful. You could name them according to the application you want to load to make the selection process easy, eg. bdrv_Palemoon, cdrv_VLC, ddrv_Zoom, etc...

[amethyst]

@radky

Whatever additional drives are implemented, I would suggest that the adrv followed by the ydrv remain so in order of preference (other alphabetic letters can then follow ie. bdrv, cdrv. dddrv and so on). This will conform to the traditional Puppy order of preference which most users are used to and according to which some applications have already been produced (like some utilities in my suite). And whilst here on the topic - I don't know the present status of the adrv (which I believe contains most of Puppy applications). If it works like the "first" Fossa, I do not really see the point because it's not truly a modular system as it stands (I think which was the intention). In the present state, the contents of the adrv may as well be merged into the base sfs like with other traditional Puppys where the applications are builtin. If you want to use only one application available in the adrv, you have to load the whole adrv anyway. And my guess is that some applications in the adrv may use share libraries. So, to produce a genuine modular system will unfortunately require lots of work. My suggestion is to go the traditional route and include all the applications (apart from the browser and alternative windows manager perhaps) as builtin applications. The user can then "remove" applications temporary or permanently (with a remaster) with the scrpts that are already available.

[fr-ke]

I've been using "nicOS Utility Suite" for a long time (mainly Save2SFS).

I took up this topic because I saw that "nicOS Utility Suite" should be part of this distribution. So no .pet that I download to try. In my opinion, the nicOS utility suite should therefore function as comprehensively as possible.

If changes in bdrv are affected, Save2SFS doesn't work anymore!
Save2SFS only processes the content of adrv, ydrv and the save file.

If you haven't dealt with the layers in Puppy and their hierarchy, this can lead to much frustration and avoidance.

As far as I understand, in Fossapup the layer bdrv is loaded after ydrv and before adrv.
So bdrv overwrites ydrv.

E.g. an update of xfe using ".pet" would end up in the save file or in /initrd/mnt/tmpfs/pup_rw if no save file was created.
Converting this savefile to a ydrv using Save2SFS would cause the old version of xfe to be loaded. In the case of e.g. linked libraries to worse.

If @amethyst is willing (and has the time) to integrate bdrv into Save2SFS, the problem is solved.

Just an idea: The distribution is limited to the lower layers and from a certain layer hierarchy, the nicOS utility suite intervenes.
(When bdrv wasn't in use, that was ydrv and adrv)

The lower layers are changed e.g. by remastering and the upper layers by e.g. Save2SFS.
Everything with applications included in the distribution and (at least in idea) well separated.

The most important thing at the end: I really appreciate the amount of work behind it and am grateful to be able to use Puppy.

[fr-ke]

ooops, a few posts behind.
Sorry for that.

[bigpup]

See if this fixes pkg-cli

Look in /root/.pkg/sources

It needs to have this in it:

Code: Select all

focal-main|deb|Packages-ubuntu-focal-main|http://archive.ubuntu.com/ubuntu/||||focal-universe noarch common64 tahr64 xenial64 focal-main focal-multiverse fossa64 
focal-multiverse|deb|Packages-ubuntu-focal-multiverse|http://archive.ubuntu.com/ubuntu/|http://mirrors.kernel.org/ubuntu/|ftp.osuosl.org/pub/ubuntu/||noarch common64 tahr64 xenial64 focal-main focal-universe
focal-universe|deb|Packages-ubuntu-focal-universe|http://archive.ubuntu.com/ubuntu/|http://mirrors.kernel.org/ubuntu/|ftp.osuosl.org/pub/ubuntu/||noarch common64 tahr64 xenial64 focal-main focal-multiverse

You probably already have this, but if not it too needs to be there:

Code: Select all

fossa64|pet|Packages-puppy-fossa64-official|http://distro.ibiblio.org/puppylinux/pet_packages-fossa64/||||noarch common64 tahr64 xenial64 focal-main focal-universe focal-multiverse

In /root/.pkg/sources-all

It needs to have this:

Code: Select all

fossa64|pet|Packages-puppy-fossa64-official|http://distro.ibiblio.org/puppylinux/pet_packages-fossa64/||||noarch common64 tahr64 xenial64 focal-main focal-universe focal-multiverse
focal-main|deb|Packages-ubuntu-focal-main|http://archive.ubuntu.com/ubuntu/|http://mirrors.kernel.org/ubuntu/|ftp.osuosl.org/pub/ubuntu/||noarch common64 tahr64 xenial64 focal-universe focal-multiverse
focal-universe|deb|Packages-ubuntu-focal-universe|http://archive.ubuntu.com/ubuntu/|http://mirrors.kernel.org/ubuntu/|ftp.osuosl.org/pub/ubuntu/||noarch common64 tahr64 xenial64 focal-main focal-multiverse
focal-multiverse|deb|Packages-ubuntu-focal-multiverse|http://archive.ubuntu.com/ubuntu/|http://mirrors.kernel.org/ubuntu/|ftp.osuosl.org/pub/ubuntu/||noarch common64 tahr64 xenial64 focal-main focal-universe

[Marv]

@mikeslr,

For testing purposes, I have removed the current adrv and bdrv, and the corresponding application now reside in a new ydrv. This required adjusting the location of several applications and associated configuration files, plus there are now two rox right-click packages -- one for the main sfs and one for the removable ydrv. If this approach is adopted, FP96 users will have the flexibility you requested for adrv and bdrv customization.

Perhaps a new bdrv could be used for the browser (easily updated or removed if the user chooses to do so). In this scenario, removing Palemoon would entail removing the bdrv plus a quick deletion of the browser launch file, moonchild directory and companion cache directory.

I can work with any of the drive allocations but as a long-time ydrv user prefer that the adrv be the developers home for applications that are not in the main sfs, with the 'new' bdrv for a starter browser perhaps.

I only started to test F64 at radky4 and it's shockingly polished! Couldn't help playing and at this point it's good as a daily.

I am currently running F64 with no adrv, bdrv, savefile, or fdrv (my wifi cards are all kernel-supported). I have PCManFM, a few apps I need -some were in the adrv-, jwm setup and a jwmdesk-proof theme and panel backup scheme, my printer setup, my configs and symlinks to portables (browsers, LibreOffice, Master PDF Editor, Sylpheed etc.). Total size of that ydrv currently is 7.6 MiB. For adding or changing small things in it, I keep an expanded copy on my data drive with a symlink to it on the desktop. Add, recompress, and move to the boot partition. For major changes I have added the ability to simply enable/disable the request to create a savefile when running in pupmode 5. That way, bigger additions can be moved into the ydrv using a fresh small savefile. Faster to do than explain...

It's kind of a follow-on to how I ran fossapup64 9.5 for a couple of users but those were LXDE'd while this remains JWM. Runs like a top, I haven't yet broken it yet, and if I do, a reboot and it's good to go. I've run it as a bdrv and it works as expected but as an old dog I like my ydrvs.

Again, all in all, F64_9.6_CE_radky is shockingly polished,

Thanks,

Edited once for grammar.

[mikeslr]

I previously mentioned just including a 'regular' SFS in the ISO as a possible solution to the 'gotta have a web-browser'. So I 'built' one if you're interested. You can download it from here, https://www.mediafire.com/file/se6uko8s ... 6.sfs/file. If I understand the relationship between ISOs and their 'burning' applications --e.g. rufus>USB-Key, BurnCDCC >CD/DVD-- whatever is included in the ISO will be burned to the selected media.

The application is palemoon as an SFS. As soon as the Puppy is, itself, burnt to media, the palemoon.sfs will be immediately available, albeit, the user will have to file-browse to that media, Right-Click the palemoon.sfs and select SFS-Load and click a couple of 'OK's'.

The version of Palemoon provided is MikeWalsh's portable located in the /opt folder in the SFS so when loaded occupying the /opt folder in RAM in the 'merge file system'. It is not a 'bare-bones' web-browser. The profile it has already includes several addons I've found useful to have, but a PITA to have to install. It's open Window provides links to several URLs often likely to be wanted.

Palemoon's GUI.png (74.53 KiB) Viewed 2190 times

One of them is to free Youtube Music which may come in handy for testing and configuring audio. The trade-off is that palemoon with this configuration requires more RAM. That shouldn't be a problem if the User has enough RAM to run F-96. The User, of coarse, is free to change the configuration. But first read the following.

SFS loading the application will create entries on the Menu. You can, of course, use it as is for as long as you want. But keep in mind that updates and changes in add-ons or configuration will be written to /opt in RAM, from which it would then be written into SaveFiles/Folders or 'alphabet' drives.

SFS-(un)load will remove the application, but not those changes. If done after making changes and creating a SaveFile, the vestigial palemoon folder in /opt would have to be deleted.

The advantage of providing palemoon this way is that immediately after SFS-loading palemoon the entire folder can be copied from /opt onto storage media. [Open two rox windows: one to opt, the other to your choice of storage media, optimally wherever your SaveFile/Folder will be located. Left-Press, Hold, then drag the palemoon folder from /opt into the other window and select Copy.] Palemoon can be started from there by left-clicking the LAUNCH script within the palemoon folder. Any changes will be written to its included profile folder; nothing into RAM potentially to be written to Saves or alphabet drives.

MikeWalsh's included Menu-Add script should not be used until after a SaveFile/Folder is created. But if it was no great harm is done: it creates a link to what Puppy 'saw' as a partition having one 'designation' and a Save will change that 'designation'. After a Save has been created running Menu-Remove then Menu-Add will set things right.

[geo_c]

@mikeslr

Would actually including the standalone portable in the top directory of the .iso with a link to it built into F-96 be impractical or impossible?

edit: I guess it would in that the puppy installer wouldn't automatically copy it.

[mikeslr]

@mikeslr

Would actually including the standalone portable in the top directory of the .iso with a link to it built into F-96 be impractical or impossible?

edit: I guess it would in that the puppy installer wouldn't automatically copy it.

I wasn't thinking about puppy installer which a User would only have if (s)he already had a functioning Puppy which already provided a web-browser by some means --perhaps this-- which could be used to obtain any other web-browser from the Additional Software Section, including MikeWalsh's palemoon portable. Rather, I was thinking about an escapee from Windows or other Linuxes.

The SFS take up no more room than providing one as an 'alphabet' SFS; leaves that resource for use with applications requiring no or infrequent updates; and once no longer needed can be unloaded from RAM and deleted from storage.

Actually, now that I've thought more about it, perhaps an even better method would just to include the palemoon folder [extracted from the downloaded tar.gz] in the ISO. No mess, no bother: just file-browse into it to start it via the LAUNCH script; perhaps later move it to a more suitable location. I must be slowing down. Should have thought of that before.

[geo_c]

I wasn't thinking about puppy installer which a User would only have if (s)he already had a functioning Puppy

Well, no, you're thinking correctly. I wasn't thinking about a windows install. I was thinking that someone might download the iso and boot it either USB or CD rom. Then if the portable directory was available a link in F-96 to the launch script should do the job. That won't work on an ntfs partition though. So there I think the sfs would be the right way to go.

[Clarity]

Browsers are a THORNY" forum discussion in distros from Puppyland and beyond. ALL users today REQUIRE them.WE, all, know this.

Developers have a preference for their personal reasons and they build their distros to that end and the benefiting objective. I agree and support any developer doing this as it is part of their signatue offering for OUR use of their distro. But this is NOT the topic of this post.

This post is a suggestion for developer thought: It allows the continuing approach for the developers while achieving a benefit overall to users of PUP/DOG distros.

I have seen such in Puppyland already. It is in @fatdog and in another forum distro (cant remember which) where the desktop's Menu>INternet has an entry which when clicked pops a Window allowing the user to ;select' additional Browsers of choice. IIRC one of these is actually smart enough to know which window browser offering is already installed and thus does not show that browser's icon for choice...showing only offerings for ones NOT installed already. Clever!

I wonder if the developer-user community would benefit for a 'normal' WoofCE PUP to have such a similar entry such that whatever browser is NOTthe selection process installed to be offered for users where users can choose from the same offering once running the distro.

If so, this could be a PUP/DOG standard offering and maybe will lower the constant browser discussion we continue to have.

I know, this post does NOT address ALL issues that arise around browsers, but it does address the selection such that it has a more universal approach for users to add browsers to their PUP-DOG distro.

This suggestion is ONLY addressing the selection process to become easy no matter which new forum distro is selected. Thus new/experienced users will always see the same offer no matter the forum distro chosen. As such with this common offering in the Menu of all PUPs, the browser requests will diminish as the same ability to add a browser is the same across forum distros.

There is another attention-getter which is NOT covered by this small low-priority concern. This attention-getter has nothing to do with distro selection. And it is purposely left OUT of this post suggestion. For the practical purpose of that attention-getter as there are so many members who have devised their own ways AND PREFERNCES of handling additions to their PUPs/DOGs.

Their desires in that realm is important to each, but is out of the scope of this post for a browser assistant addressed in this post.

Again, this is a LOW priority but important item, IMHO as today's PUPs/DOGS become easier and easier for user use without need for forum support. Everything done to achieve that, makes this forum so attractive in its many offerings. Also, the ease of use component affords that users who choose these offereings will 'STAY" as active members helping PUP-DOG maturity.

For consideration only

[rockedge]

as a long-time ydrv user prefer that the adrv be the developers home for applications that are not in the main sfs, with the 'new' bdrv for a starter browser perhaps

I like the idea that the bdrv_fossapup64_9.6.sfs could contain the "starter" browser to have available. Making it easy to remove the browser by renaming it to No-bdrv_fossapup64_9.6.sfs or replacing or removing it from a frugal installation. At any time the bdrv can be modified by the unsquash->copy->edit->squash method to add several browsers or have a variety of bdrv's to meet the needs of the user.

[mikeslr]

I wasn't thinking about puppy installer which a User would only have if (s)he already had a functioning Puppy

Well, no, you're thinking correctly. I wasn't thinking about a windows install. I was thinking that someone might download the iso and boot it either USB or CD rom. Then if the portable directory was available a link in F-96 to the launch script should do the job. That won't work on an ntfs partition though. So there I think the sfs would be the right way to go.

Actually, geo_c, your post got me curious enough to not make assumptions. I'm posting using palemoon portable from an ntfs partition having clicked the LAUNCH script. I have no reason to doubt that the same could be done from a Fat32 partition. What I think won't work is the Menu-Add script which writes symbolic links. My flaky memory suggests that script to non-Linux partitions work, but symbolic links don't.

I'll see if I can hunt up a USB-Key formatted Fat32 and a Puppy which doesn't already have palemoon.

Edit: Well, what do you know. I'm posting from F-96 using palemoon portable on a fat32 partition of USB-Key having started it via a listing on the Menu created by MikeWalsh's Menu-Add script.
What worked was extracting the tar.gz on the Fat32 partition, then moving the palemoon folder out of the palemoon-extracted folder. What didn't work was trying to move the palemoon folder on the ntfs partition to the USB-Key. That generated 'one error'. What error I don't know and didn't think worth the effort to find out.
So I don't really know what limitations exist when ntfs and/or fat32 partitions are used.

[wizard]

@mikeslr

I wasn't thinking about puppy installer which a User would only have if (s)he already had a functioning Puppy

You also have the case where the user has booted from CD or a tool like Ventoy and attempts to install to a USB or internal drive. Puppy installers, and some others, will not copy over the "extra files". Complications concerning where the files are located and how to link to them also come into play. As you have discovered, portable apps are not going to work correctly unless on a ext partition or in a savefile. The issues are generally related to symlinks since fat32 and ntfs do not understand Linux links.

wizard

[mikeslr]

as a long-time ydrv user prefer that the adrv be the developers home for applications that are not in the main sfs, with the 'new' bdrv for a starter browser perhaps

I like the idea that the bdrv_fossapup64_9.6.sfs could contain the "starter" browser to have available. Making it easy to remove the browser by renaming it to No-bdrv_fossapup64_9.6.sfs or replacing or removing it from a frugal installation. At any time the bdrv can be modified by the unsquash->copy->edit->squash method to add several browsers or have a variety of bdrv's to meet the needs of the user.

When an application which will require frequent updates is located in a READ-ONLY container unnecessary complications are created when there are alternatives. I'm not speaking theoretically. For a couple of years I've used adrv.sfs for that purpose on the laptop I take out of my home.

The availability of bdrv reminds me of a line from 'His Girl Friday', https://www.imdb.com/title/tt0032599/. Rosalind Russell, a newspaper reporter, is tasked with interviewing a not particularly bright convict, Williams*, awaiting execution for the murder of a policeman. He hadn't known the policeman and had never previously been in trouble, but somehow got hold of the policeman's pistol. In her report she writes something to the effect, "Williams understood that guns were produced to be used and now that he had one he had to use it."

bdrv can serve a useful purpose if (a) it has lower priority than ydrv and adrv and/or (b) Save2SFS has been modified so that the contents of bdrv can be managed without a great deal of human intervention. Neither of those conditions currently exist. By now it should go without saying that I don't have the scripting skill necessary to effect such changes.

-=-=---
* played by John Qualen.

[rockedge]

See if this fixes pkg-cli

Look in /root/.pkg/sources

I copied to both source and source-all and I am watching a script install Zoneminder using pkg2...so far pkg updated cleanly and is running error free....

Screenshot(3).jpg (90.49 KiB) Viewed 2186 times

It seems to be running after those strings were copied into the /root/.pkg/sources, /root/.pkg/sources-all

@radky It appears that Pkg-cli (pkg2 fork) is working as expected using @bigpup 's information

[geo_c]

@mikeslr

What if it was just a simple sfs. But instead of putting it in the top directory of the iso or install, it's in a folder called something like /fossapup64.9.5/sfs-extras

Then a script could be launched from the menu that moves the sfs to the top directory so that it will be loaded at boot, and also loads it during that run. The script could be "load-browser'

A script could also unload browser-sfs, or an instruction to run the sfs utility included. If it was an unload-browser script, it could move the sfs back to the sfs-extras folder.

That way if someone ran the pup installer and they were used to the browser sfs being mounted, it would be copied because it would be in the top directory. If not, then the browser doesn't get included in the install.

Just brainstorming.

[amethyst]

@mikeslr
It depends what the bdrv contains. If it only contains a browser it shouldn't have an effect on the workings of the Save2SFS application which you are worried about (even if it has priority over the ydrv). I have however made the suggestion that this Puppy conforms to "the natural evolution of Puppy" where the ydrv follows the adrv directly in order of priority as most of us are used to (and has preference to any other added additional drives). Anyways - most Puppy users use a save file/folder to save changes so the order of the additional drives becomes less important. BTW - Read your private messages, I've answered the message you have sent me.

[rockedge]

Rigorous test of Pkg2-cli used in two scripts that installs mariadb-client, ,mariadb-server, PHP7.4 and modules and Zoneminder.

The first test run with small modifications to the install scripts to update them and the result ->

Screenshot(6).jpg (35.82 KiB) Viewed 2159 times

Zoneminder is running smoothly on F96_4-radky5-CE and the install was mostly straightforward. I used the existing Hiawatha web server with PHP7.4 added in.

[fr-ke]

grub2config does not recognize the boot partition.
It might have something to do with the NVMe attached drive.

FrugalPup v20, on the other hand, works.

I deleted the internal SSD using GParted and created a Fat32 and an ext4 partition.
SecureBoot is off. UEFI and LegacyBoot in Bios is on.

On a 2nd laptop (with an SSD connected via sata) grub2config works fine.

[ozsouth]

@fr-ke - re- your NVMe drive. Seems that they may need vmd running for access. As the stock 6.0.9 kernel config has it as a module (not builtin), you may wish to try (at own risk) editing your grub config to contain (just before the linux/kernel line): insmod vmd

[fr-ke]

@ozsouth thanks, putting insmod vmd didn't change anything.

vmd seems to be loaded

# modprobe vmd --first-time
modprobe: ERROR: could not insert 'vmd': Module already in kernel
# lsmod | grep vmd
#

the script 'frugalpup-bootfiles' does the job on the other hand.

Maybe something is wrong with the script 'grub2config'?

[radky]

New F96_4-radky6 iso

https://www.smokey01.com/radky/Testing/ ... radky6.iso

MD5:c63aa04e88a261e0f85f3f30a25e9f52
SHA1:4eeb96015d5c68c21b75bae510a4b4b7e73ce5ba

Changelog:

• Add tldr-bash-client for helpful usage parameters and examples of terminal commands. (thanks Clarity and Jasper)
• Add Xournal++ for notes and PDF annotation
• Add LADSPA Pulseaudio Equalizer and swh-plugins (thanks Sofiya)
• Adjust Conky configuration file (conkyrc) to disregard non-enabled network interfaces (thanks wizard)
• Adjust Picom GUI and configuration options
• Adjust GUI and functions of Simple GTK Radio
• Adjust PupControl default applications to those specifically available in FP96
• Adjust color, contrast and theming of tray notification icons
• Adjust builtin wallpaper selections to minimize mismatch of jwm and rox rendering of small svg background images
• Remove current adrv and bdrv (replace with new browser-bdrv and application-ydrv). See Note below. (thanks mikeslr, fr-ke, amethyst, Marv)
• Remove from /var/packages/builtin_files all zero-length files associated with applications installed in the Puppy bdrv and ydrv (thanks fr-ke)
• Remove unused files and folders of prior iso builds
• Remove superfluous suffix from Exec line of .desktop files when adding tray launch buttons (thanks esos)
• Update Pale Moon browser to v31.4.2
• Update Pkg package manager to Pkg2 (mistfire's fork of scottman's pkg application)
• Update Pkg2 source files to support FP96 package repositories (thanks bigpup)

Note: The prior adrv and bdrv of FP96 are now combined in a single (optional) application-ydrv which contains a comprehensive suite of supplemental applications. Hopefully, the programs and utilities of the ydrv will provide a useful and substantial desktop environment for novice users who are transitioning from the Windows desktop. However, to address those who may prefer their own suite of applications, the new default ydrv is fully modular and completely optional. If you wish, boot without the ydrv (or create a personalized ydrv) and add your preferred applications for a customized iteration of FP96. Even without the ydrv, FP96 boots to a fully functional desktop (not a minimal desktop, but available menu applications are limited).

Additionally, the new browser-bdrv provides a modular solution for those who prefer the flexibility provided by alternate browsers. Although Pale Moon is the default general-purpose FP96 browser, you can easily remove it by deleting the palemoon bdrv and two usage directories: /root/.moonchild productions and /root/.cache/moonchild productions. If Pale Moon has updated internally, you may also remove the saved /opt/palemoon directory. Subsequently, you can add a replacement browser by a variety of installation options such as a new browser-bdrv, load-on-the-fly standard SFS, portable self-contained package, or by conventional direct installation of an archive package. To ease the transition to an alternate browser, FP96 has a new menu item which provides a quick link to available browsers supported by the Puppy community (Menu -> Internet -> Browsers).

Granted, no single implementation of (x)drv usage will satisfy everyone, but this proposed modular configuration provides each user with a familiar desktop and functional browser at first boot. Once on board, the curious or enterprising user can easily remove or replace the default browser-bdrv and/or application-ydrv, or even add a personalized adrv for ultimate control of the FP96 desktop. Since the proposed bdrv is for browsers only, there should be no conflict with the functions of the nicOS Utility Suite.

Since the infrastructure of this release has changed significantly, a fresh install of FP96 is suggested for testing.

Thanks

PupMates
https://www.smokey01.com/radky/PupMates.html