(old)Puppy Linux Discussion Forum

Flash wrote:Would you guys like me to move this thread to Cutting Edge? Or maybe Projects? It seems to have gone far beyond a mere suggestion.

sunburnt wrote:Blubb_fallo ? ...Other wise this thread seems to be waining...

Sorry ... yes, please, move it wherever you deem appropriate! I'm quite busy currently, barely manage to keep track of the exciting news regarding a more modular Puppy.

Even though the limit of 5 mounts per UnionFS is a bit disappointing (I wasn't aware of that!), I do think Puppy should make use of those possibilities.

(Btw, Barry mentioned that UnionFS crashed when he tried to flush the ramdisk, so it looks like we have to live with pretty W98-ish reboots for memory recovery for now. Does aufs allow flushing, as opposed to mere copying, to lower layers?)

To do at least something, I tried to create an sfs that would add instant iso launching capability to rox, just like I've set it up for my main system. Unfortunately, I didn't even get anywhere near squash making, since vmplayer obstinately refused to play with my Puppy.

Anyway, my silence is in no way desinterest. I would like to participate and contribute more, but I can't at the moment. Especially to sunburnt: please, go on - those GUI's are a great idea! I think, such a well thought out, evident way of providing essential information that otherwise would require studying neverending manpages (including lots of syntactic ballast) would be a substantial progress, in terms of usability by non-techies.

blubbo; Search for my xfilemount app., it mounts ISO SFS 2FS 3FS etc.

I have Grafpup booting with aufs now. In the process I found that it can be built after the fact as a module, without recompiling the kernel. So it might be possible to create a new initrd.gz for others to try it out in Puppy.

What I haven't done yet is to see whether it will have any effect on adding and removing union branches while running. I will get around to testing shortly.

Nathan

I hope, I hope, I hope!
This could be a cornerstone for Puppy...

Barry's adding LANboot & Samba and maybe NFS to boot-ability!

I suggest Puppy have one CORE.SFS , one SPECIAL_HARDWARE.SFS , one SOFTWARE.SFS, one LANGUAGE.SFS.

CORE.SFS contains all necessary and core part of puppy,including hardware support.It must be standard Puppy.
SPECIAL_HARDWARE.SFS is for some special hardware and some notebooks.Puppy fans can make this for specific PC or Notebook.
SOFTWARE.SFS contains more softwares the user needs.Users can make this himself or save files in pup_save.3fs.
LANGUAGE.SFS is for different language support.Puppy fans who speak the same language can make this together.

And the USB Puppy or CD Puppy should contain some parts of QEMU-PUPPY.

sunburnt wrote:blubbo; Search for my xfilemount app., it mounts ISO SFS 2FS 3FS etc.

Oh I am aware of your xfilemount. It's yet another cute tool that eases daily puppy life - thanks!

I was talking about launching (as opposed to mounting) any bootable cd image inside puppy with just a click. I can do that in my main system, and it's quite convenient.

sccat wrote:I suggest Puppy have one CORE.SFS , one SPECIAL_HARDWARE.SFS , one SOFTWARE.SFS, one LANGUAGE.SFS.

This suggestion looks similar to what has become amishs grand unified puppy concept. In principle I also think, that's the way to go. However, I'd prefer a set of many small modules over three or four bulk add-ons. There's a good chance you often need some (varying) small part of a big package. If you have to load it all, quite some potential is wasted.

With fine-grained modularity and group selectors as sketched at thread start, the fine tuning can still be optional. There's no need to bother yourself with detailled choices when you don't want to - just select "INTERNET APPS", or even "SOFTWARE", and it's there. The difference is, you can also pick modules or subgroups out of such a group instead, according to your real needs.

Of course, the maximal count of union mounts is crucial therefor, so it may be more of a long-term goal.

Nathan F wrote:I have Grafpup booting with aufs now. In the process I found that it can be built after the fact as a module, without recompiling the kernel. So it might be possible to create a new initrd.gz for others to try it out in Puppy. Nathan

That's great news. I guess we'll get to know soon whether aufs indeed provides advantages.

sccat & blubb_fallo; I don't know if you've been party to the many posts that that
have occured regarding the subject of a modular Puppy.
As UnionFS only unions 5 file system structures, there's obvious limits to this.
Hopefully AUFS will union more, but it takes cpu power to be fast enough.

Amish, others, & I talkied a length on this, I concluded this setup for it:

The kernel, image file, & a "boot sfs" file are the the core, same as Puppy is now.
Words like; core, base, & main have been used for the boot sfs file, but boot is
just what it does, X & the WM are in the boot sfs file, so it can't be removed.
Currently the SAVE file takes 1 union spot & the boot sfs file takes another = 2.
That leaves 3 spots in the union for extra sfs file swapping, not many at all... huh?
So the extra sfs files need to be more comprehensive than your thinking.
I suggested that they be made as groups of "like apps.", Games, Office, Dev., etc.
Then swapping is simply a matter of what you need to do, 3 groups isn't bad.
Addons like modules, languages, etc. bulk Puppy up, so a web repository is best.
If new hardware's installed, then boot Puppy auto. downloads the modules.
Same for library dependancies (auto.), languages (manual), & other parts.
Installing normal packges is important, like the items above all of this needs
to be integrated into Puppy, so a "make SFS file" utility is needed to do this.
So making custom SFS files is an easy way to tailor a custom Puppy version.

sunburnt wrote:sccat & blubb_fallo; I don't know if you've been party to the many posts that that
have occured regarding the subject of a modular Puppy.
As UnionFS only unions 5 file system structures, there's obvious limits to this.
Hopefully AUFS will union more, but it takes cpu power to be fast enough.

Amish, others, & I talkied a length on this, I concluded this setup for it:

The kernel, image file, & a "boot sfs" file are the the core, same as Puppy is now.
Words like; core, base, & main have been used for the boot sfs file, but boot is
just what it does, X & the WM are in the boot sfs file, so it can't be removed.
Currently the SAVE file takes 1 union spot & the boot sfs file takes another = 2.
That leaves 3 spots in the union for extra sfs file swapping, not many at all... huh?
So the extra sfs files need to be more comprehensive than your thinking.
I suggested that they be made as groups of "like apps.", Games, Office, Dev., etc.
Then swapping is simply a matter of what you need to do, 3 groups isn't bad.
Addons like modules, languages, etc. bulk Puppy up, so a web repository is best.
If new hardware's installed, then boot Puppy auto. downloads the modules.
Same for library dependancies (auto.), languages (manual), & other parts.
Installing normal packges is important, like the items above all of this needs
to be integrated into Puppy, so a "make SFS file" utility is needed to do this.
So making custom SFS files is an easy way to tailor a custom Puppy version.

Thanks for your reply。
I didn't know so much before.

http://www.murga-linux.com/puppy/viewto ... 607#103607
This is a set of files to get aufs working in Puppy, for testing whether it will enable swapping union branches on the fly.

Nathan

Thanks Nathan for the effort on your part!
I think Barry's watching this & maybe will implement it once proven.
Terry