Jemimah introduced in Saluki the ADRV sfs. An SFS that will mount in the union with the main puppy sfs which was used to hold applications. The idea being that could be easily replaced without affecting the core functions.
Her work was never made it into woof, so when Archpup wanted to go that way I adapted jemimah' s code for the more recent initrd that Archpup uses.
Then I took it one step further adding a YDRV, since Archpup people wanted a separate sfs for the Desktop/Window managers.

So here are a couple of patches for Woof2 ver:8fa56fa1c1d5fb12 (today's).
Ones adds the adrv and the other both adrv and ydrv.
Please also notice the additional mount-point folders that should be added in the initrd tree as indicated, as well as the required changes in DISTRO_SPECS.

Obviously the code could be expand to encompass the entire alphabet but without the woof changes to build the separate SFSs is not of much use .
Still I put it here since a modular puppy may not be such a bad idea. Could facilitate building the different versions of a puppy that become all the more often like "retro", "fat", "XFCE" etc, without the need to replace/rebuild the entire ISO.

I had also looked at Jemimas's way of doing it as I wanted similar with my Development Puppy qtpy, I have added further a d-drive for the Development tools \ apps SFS to mount into as they are quite a size (naturally) and do get regularly updated.

However, I was wondering how \ if we could force some of the apps to be added to the new SFS's instead of the savefile with a 'marker tickbox' in PPM, since there are a few decent sfs packaging apps out there now.

I was \ am also considering how to split the existing puppy system up so that /root lives on it's own partition \ savefile with the intention of having a common /root available across a number of puppy versions. The problem as far as I can see is how to deal with the 'differances' between the /root settings files. But I wonder how different it is nowadays other than the 'set' and 'menu' items.

However, I was wondering how \ if we could force some of the apps to be added to the new SFS's instead of the savefile with a 'marker tickbox' in PPM, since there are a few decent sfs packaging apps out there now.

The SFS is read only and you can not add things to it after is made.
However, you can define [a,d,y]drv is DISTRO_SPECS as, say Apps_mypuppy_123.sfs and then let the user or developer make the Apps_mypuppy_123.sfs with apps of their liking. That's what Archpup_13.2 is doing currently.
A down side is that these SFSs will load in RAM (if available) so you may need 1GB+ to take full advantage of this system.

scsijon wrote:

I was \ am also considering how to split the existing puppy system up so that /root lives on it's own partition \ savefile with the intention of having a common /root available across a number of puppy versions. The problem as far as I can see is how to deal with the 'differances' between the /root settings files. But I wonder how different it is nowadays other than the 'set' and 'menu' items.

I _think_ that the init script and snapmerge could be modified to use an additional "root_savefile" but I'm not sure if it worths the effort and the potential problems. Also I doubt about the benefits since unless you use very similar pupplets can be a source of problems.
If you have some settings you want to carry from pupplet to pupplet you can make an SFS to "load_on_the_fly" or just a tarball._________________Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too

However, I was wondering how \ if we could force some of the apps to be added to the new SFS's instead of the savefile with a 'marker tickbox' in PPM, since there are a few decent sfs packaging apps out there now.

The SFS is read only and you can not add things to it after is made.
However, you can define [a,d,y]drv is DISTRO_SPECS as, say Apps_mypuppy_123.sfs and then let the user or developer make the Apps_mypuppy_123.sfs with apps of their liking. That's what Archpup_13.2 is doing currently.
A down side is that these SFSs will load in RAM (if available) so you may need 1GB+ to take full advantage of this system.

I'm sure someone could hack the PPM to utilize the Edit-SFS package and give you that functionality... but honestly I'd think its a bad thing. One of the benefits of using a layered file system that we do, is if something causes a problem... its easy to reverse. Example, install a PET that uses a newer version of some core lib. If its a pet you can simply uninstall the pet, because the original lib is still in the base SFS package. If you edit the SFS by adding programs through the PPM, if you overwrite a important lib... you've just completely nuked your system.

If there are specific programs you use and know will work, you can always use the Edit-SFS package yourself to change the base SFS. But I think making this an option in the PPM is only going to cause more problems than it'd solve.

mavrothal, do you agree with that assement or do you have another opinion on it?_________________

However, I was wondering how \ if we could force some of the apps to be added to the new SFS's instead of the savefile with a 'marker tickbox' in PPM, since there are a few decent sfs packaging apps out there now.

The SFS is read only and you can not add things to it after is made.
However, you can define [a,d,y]drv is DISTRO_SPECS as, say Apps_mypuppy_123.sfs and then let the user or developer make the Apps_mypuppy_123.sfs with apps of their liking. That's what Archpup_13.2 is doing currently.
A down side is that these SFSs will load in RAM (if available) so you may need 1GB+ to take full advantage of this system.

I'm sure someone could hack the PPM to utilize the Edit-SFS package and give you that functionality... but honestly I'd think its a bad thing. One of the benefits of using a layered file system that we do, is if something causes a problem... its easy to reverse. Example, install a PET that uses a newer version of some core lib. If its a pet you can simply uninstall the pet, because the original lib is still in the base SFS package. If you edit the SFS by adding programs through the PPM, if you overwrite a important lib... you've just completely nuked your system.

If there are specific programs you use and know will work, you can always use the Edit-SFS package yourself to change the base SFS. But I think making this an option in the PPM is only going to cause more problems than it'd solve.

mavrothal, do you agree with that assement or do you have another opinion on it?

Given the current pet QA I do agree that is not a good idea to mess up the pristine state of the original SFSs.
An option could be to install new pets directly in an "additional_apps.sfs". If anything goes wrong you can always drop it and go to pristine state.
Theoretically after a new pet download/installation your "additional_apps.sfs" expands the new pet is/are added the original sfs gets backed-up and umounted and the new one squashed and mounted (so you have the previous version if something goes wrong)
I still find it unpractical though and I can hardly see the advantages over installing in the savefile.
If you eventually have a set of additional apps that you feel happy with you just remaster._________________Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too

First I have to say: I really like the idea of using SFS files instead of installing applications.

So, I run my LazY Puppy (by now Version 3.0.0, not published yet) from USB flash (and USB hdd) totally in RAM, no save file is used and all programs are coming as SFS file. There are SFS files in sizes of several 100 MB and also some of sizes in less KB - by now there are 334 SFS files in the LazY Puppy boot directory.

All these SFS files are loaded automatically by a RunScript, which can be created with right-click action on SFS files. The RunScripts are executed by a menu entry - just like as the program would have been installed (downloading the SFS directly to the boot directory from server smokey01.com is included).

LazY Puppy can load every SFS file directly at boot up (mounted like the zdrv SFS) just by giving the name of the SFS or by predefined boot menu entries in menu.lst, using predefined constants for the SFS Suites.

There is just one single PET to install for me - if I want to go online with my USB GPRS Modem!

BUT: I have to make sure all Data is saved outside LazY Puppy before shutting down the computer - each and every day.

That's why I have invented the Personal Data SFS in LazY Puppy 3.0.0. This can be loaded automatically at boot up (by boot option in menu.lst) and can also be saved automatically before shutting down the computer - selectable option in the shutdown-gui of LazY Puppy. If I'm saving the Personal Data SFS at shut down, an existing Personal Data SFS is renamed (date is added to the file name) before that!

Just by a right-click I can set files and directories to be added to the Personal Data SFS or to be removed from the Personal Data SFS.

Everything is temporary until I save the Personal Data SFS manually or at shut down.

The idea of puppies with 2-3 distinct SFSs instead of the usual monolithic one, has to do only with the ease of development/customization of a complete system/ISO.
Not with the philosophy of the puppy setup.

As mentioned, there are other distros to do that.

(sorry for the "loud" mark up. Just try to be clear)_________________Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too

I do not know Tiny Core Linux and I did never ever see one running or read any specific information about Tiny Core.

What I've found now by your presented links is totally new to me - however: I don't believe, that Tiny Core uses RunScripts to be able to do the following:

Clicking a GIMP Image (Gimp is not installed and there is no SFS file at local computer available), automatically downloading the SFS into the boot directory, automatically loading the SFS after download, automatically starting GIMP application and automatically loading the GIMP Image into GIMP - ready to edit by just a single click on a menu entry.

Tiny Core surely can NOT do this.

Sorry, but that's all and that's much more as I've ever seen in any Linux (there are not much, but some)

Thanks to this thread I've discovered and examined the adrv option of Saluki. Found it very useful and surely will try to add such feature to LazY Puppy. I've had a quick look at the init script in Saluki's initrd.gz - seems not to be too much code. _________________LazY Puppy Home
The new LazY Puppy Information Centre

Clicking a GIMP Image (Gimp is not installed and there is no SFS file at local computer available), automatically downloading the SFS into the boot directory, automatically loading the SFS after download, automatically starting GIMP application and automatically loading the GIMP Image into GIMP - ready to edit by just a single click on a menu entry.

This can be handy at times.
The reason that distros do not do that (ie download an SFS or package) for a missing MIME type/file extension, is that usually more than 1 app can handle a file.
Some distros (not tinycore) do provide a list of suggestions if a file can not be handle by the installed applications_________________Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too

Some distros (not tinycore) do provide a list of suggestions if a file can not be handle by the installed applications

Yes, this might be also a nice feature in LazY Puppy.

However...

I've tried to put in the "adrv"-option into LazY Puppy using the code taken from the Saluki initrd.gz. I did get the adrv sfs mounted in pup_a. All files where in the directory and I was able to open f.e. scripts in geany.

BUT, the sfs seems not to be mounted like to have the menu entries and to be able to execute the applications.

To me it seems like it is mounted to be able to grab some files off it, but not mounted to the "layered filesystem".

What am I doing wrong?

I did try this also using the exactly code for the zdrv modified to adrv - didn't work also.

Is there anything else I would have to do to get the adrv mounted like the main sfs is mounted (to be able to execute its applications from menu)?

I've tried to put in the "adrv"-option into LazY Puppy using the code taken from the Saluki initrd.gz. I did get the adrv sfs mounted in pup_a. All files where in the directory and I was able to open f.e. scripts in geany.

BUT, the sfs seems not to be mounted like to have the menu entries and to be able to execute the applications.

To me it seems like it is mounted to be able to grab some files off it, but not mounted to the "layered filesystem".

What am I doing wrong?

I did try this also using the exactly code for the zdrv modified to adrv - didn't work also.

Is there anything else I would have to do to get the adrv mounted like the main sfs is mounted (to be able to execute its applications from menu)?

Besides the changes in initrd/init you also need to have the mount points (folders) in initrd. Did you?
Did you also added the adrv to DISTRO_SPECS
If you want post or PM all the changes you have made in initrd, to take a look, (or compare with the patches above. There is both the adrv only and the adrv+ydrv patches. Did you look at them?...)_________________Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too

I did not add the adrv as DISTRO_ADRVSFS to DISTRO_SPECS - I do submit this from the grub bootmenu. The file is then in pup_a, I can see the files and I can open scripts in geany, so it is successfully submitted, but the .desktop files do not appear in the menu and none of the program runs.

No, I did not have a look into the above attached patches, because I'm not in woof. I just do remaster.

I did not add the DISTRO_ZDRVSFS to DISTRO_SPECS - I do submit this from the grub bootmenu. The file is then in pup_a, I can see the files and I can open scripts in geany, so it is successfully submitted, but the .desktop files do not appear in the menu and none of the program runs.

I'm afraid descriptions are not gong to do it.
You may want to post your init and the contents of your /initrd/tmp folder to see what are you doing exactly, during boot.
Also /tmp/xerrs.log can be informative (or maybe just run pdiag)_________________Kids all over the world go around with an XO laptop. They deserve one puppy (or many) too

Here is the init script from my LazY Puppy 3. Saluki code included - commented out, because it failed and I did try it with an code-copy of the zdrv code. I have made a lot of modifications also, so it's a bit more than a usual init script.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum