My personal tricks to save settingsaren't a part of the Modular Concept.

I just linked this as an reply to nooby!

It is not relevant for this thread, because I can use this Modular Concept(and so the user does) also when using a personal storage file (save file).

Got it NOW?!?!?!

And by the way, just to keep you informed: there is no LazY Puppy Creators (as a multiple) - there is only one: ME.

You should have already know this, if you were able to read and to understand what currently reading.

And again: this here is not for LazY Puppy. Go complain in its EN Forum, if you would have anything to complain about it. Though, I doubt you would get any further answer from me.

This is my last reply to you in this here thread. To me, sorry I have to say this, you are now OUT!

mikeb wrote:

I suspect this notion comes from unionfs which slowed down considerably with only a few layers. I regularly have 20 to 40 sfs loaded by default and get no appreciable performance hit on pentium 3 machines which noticed the drag of the standard drive icons in puppy. I noticed mention of some problems with recent kernels and aufs ... not sure of the current situation as 2.6.33 is the newest I normally use.
I also have sfs as small as 200-300k in the set...one per app usually.

Yes, I usually also do have around 30 to 40 SFS Modules loaded, without any noticeable result to Operating Systems performance.

I have SFS Modules from 11KB up to 300+ MB. The funny thing I have noticed so far: time to laod an SFS seems not really to make a difference, if the SFS is sized in KB or even in MB.

That's why I've suspected that there must be a difference between loading an SFS at boot up and loading an SFS via sfs_load.

Quote:

On the other hand see what's happening in this thread.... not exactly productive when good ideas are getting lost but this is pretty typical and note very little activity in this forum alone reaches the main puppy releases.

Yeah, already noticed this. Though, there is no reasonable point for me to see, why this hasn't changed in those 10 Puppy Linux years.

oldyeller wrote:

If you load by the menu when needing a program, does it unload when it is closed? Are the SFS done automatically for loading and unloading and no need for SFS-load on the fly?

If the SFS's application is a real binary, I can freely define if the SFS should be unloaded after its application is exited. Please note the onformation at second post, and there especially read the thread of multi-session CD/DVD (my solution, created for 8-bit). For the use of the Modular Concept, how I do prefer and suggesting it, the use of sfs_load is needed!

This Modular Concept is built on top of sfs_load and all its pretty comfort would get lost immediately, if there wouldn't be shinobar's sfs_load. Though, I'm currently using a little modified version to be able to load SFS from different locations (and not only from boot partition or boot directory). I'm convince by now, I would be able to create this also for the use without shinobar's sfs_load. But why should I try so?

Quote:

How would you link to a Appdir or load more than 6 SFS?

To laod more than 6 SFS Modules (I assume, you do mean at boot up, when using a save file) also sfs_load can be used. Itself uses a file /etc/init.d/sfs_load for this.

While running the OS, shinobar's sfs_load generates mount point directories automatically for each SFS to load.

There is no need to link to AppDirs, because you can run them from every location you want to store it. But AppDirs aren't really a part of this here. It could be a nice addition, but I'm not an expert for this - still learning while doing some of this stuff (like the RoxApp Builder, which isn't a part of this here as well). If you want to know anything about AppDirs or RoxApps or Program Folders, go to RoxApp Builder thread in Puppy Projects Forum and do read my information over there. There are also some links to a few RoxApp Dirs for the use on un-unioned SFS Modules (I think, un-unioned means: not mounted to the pup_roX directories, instead mounted to /mnt or anywhere else)._________________LazY PuppyRSH's DNASARA B.

I think it was shinobars sfs load I looked at ..... as mentioned it or whatever it was did load to ram if there was enough space ...that would take longer the larger the file but the same would apply to one at boot.
If we are dealing with aufs itself I have noticed it can take a few seconds for files to propagate through the system when dealing with an sfs with thousands of files...the devx is a good example, but it probably takes longer for menus to sort out so its not a problem as such.

Just as an aside I am fiddling with the initrd at the moment and it takes 1.5 seconds to run the init script including loading a 94mb pup sfs to ram on a pentium 3.

Here's the module activate/deactivate script I have on puppy in use at the moment. I am a slob and should tart it up but it does the job.
Its in the right click rox menu and toggles load/unload.

I've mainly contributed by answering simple questions occasionally, but I've thought about this for awhile. I think to do what RSH is talking about, the first thing is to build an infrastructure that makes it accessible to mere mortals (as opposed to Woof, which is only accessible to real developers).

The first step is to produce a barebones main sfs file that only has what is necessary to install and run the system. Just the stuff to configure the hardware, a desktop, the Load SFS program, Remaster Script and Pupsaveconfig. That would be the base to allow creating a modular system. Pupsaveconfig lets you decide how to handle the save file. Load SFS lets you add modules to the system.

Then create another sfs that has setup utilities, including the PPM, Gparted, all the utilities to configure the desktop, all the utilities to create and edit pets and sfs files, etc etc. All the stuff to setup Puppy, as opposed to just use it.

Finally, you'd have a DevX sfs file that has the compiling tools just like it does now.

With these three pieces, you can then create sfs files to make a modular system, create pet files to install to save file (or use as a basis to remaster the main sfs file), use the PPM to install Ubuntu or Slackware packages to install to save file (or use to remaster the main sfs file), compile programs from the source etc.

It gives a lot of flexibility to create custom modular (or not modular) distributions without dealing with Woof.

If we are dealing with aufs itself I have noticed it can take a few seconds for files to propagate through the system when dealing with an sfs with thousands of files...the devx is a good example, but it probably takes longer for menus to sort out so its not a problem as such.

Yes.

As far as I know, shinobar's sfs_load is mounting an AUFS, to load SFS Modules. Also I have noticed a -sometimes- huge delay until the sfs_load GUI to execute an application from the currently loaded SFS appears on the screen. I have noticed also, this is dependent to the WM in use.

My experiences:

- JWM needs sometimes to be refreshed manually (though, it is fast)
- IceWM is also fast and I did never ever need to refresh it manually
- Openbox is really fast, even for a full menu like I do have over here (currently 821 .desktop files in /usr/share/applications)

BUT:

- when FbPanel is used as the panel for Openbox these 821 .desktop files (menu entries) resulting in an huge delay
- this huge delay is related to FbPanel itself
- the code, producing this issue is to be found in /usr/sbin/fixmenus

- responsible line is: [ `which variconlinks` ] && variconlinks #100404 for my fbpanel pkg
- this line creates a huge amount of icons from all over the running OS for the FbPanel to use

Currently I don't have any other WM/Panel installed, than Openbox and Tint2. If loading my LP2_WindowManagers.sfs Openbox (the OS) will use automatically FbPanel instead of tint2. Therefor I have modified /usr/sbin/fixmenus to execute refresh/rebuild of Openbox menu at first - before any else WM/Panel is refreshed/rebuild.

So, while FbPanel is stiil updating its icons, I can run any newly added application from Openbox menu immediately.

Also, I don't use sfs_load as it is supposed to use. I do use it only as back end script, since I have my own GUI to load/unload SFS Modules and all the menu entries already built into the OS. So, there is no need to run /usr/sbin/fixmenus when loading an SFS by the use of sfs_load in back end (console) mode. That's why shinobar has introduced option --skip-fixmenus in sfs_load version 1.9 and above. Especially for the use of the SFS P.L.U.S. RunScripts!

Code I usually do use, to load any SFS Module:

Code:

sfs_load --cli --skip-fixmenus --quiet "$LP2BDL/$SFS_file"

Code I usually do use, to unload any SFS Module:

Code:

sfs_load --unload --cli --skip-fixmenus --quiet "$LP2BDL/$SFS_file"

$LP2BDL is current boot directory, like: /mnt/sdd1/LazY
$SFS_file is the SFS Module to load, like LP2_WindowManagers.sfs

Quote:

Just as an aside I am fiddling with the initrd at the moment and it takes 1.5 seconds to run the init script including loading a 94mb pup sfs to ram on a pentium 3.

Mine is a bit slower than yours, since I've added some stuff to be able to load each SFS Module I want to load at boot up - just by an option to be placed in a boot menu entry in menu.lst (or even entered in console)

This

Code:

lpextsfs=LP2_XorgHigh.sfs

will load the XorgHigh automatically at boot up. It goes straight to where the zdrv.sfs usually goes: /intird/pup_z.

However, I really don't care about the speed of booting the OS, if it has been done in 20, 40 or even 60 seconds etc.pp. since I'm usually brushing my teeth, washing my face, entering the bathroom or pulling off my clothes when returning to home, at such boot times.

Quote:

Here's the module activate/deactivate script I have on puppy in use at the moment. I am a slob and should tart it up but it does the job.
Its in the right click rox menu and toggles load/unload.

Yes, I can load/unload SFS Modules by clicking it as well. Plus: I do have a Openbox menu Category (menu pipe), which offers to me all current loaded SFS Modules to be unloaded, when clicking its menu entry.

Sorry, but can't post an image at the moment, because I'm still using the MochiMoppelTest-called LazY Puppy 2.0.2-005 EN version by using the created save file - still works, but this version hasn't included above named Openbox feature._________________LazY PuppyRSH's DNASARA B.

I've mainly contributed by answering simple questions occasionally, but I've thought about this for awhile. I think to do what RSH is talking about, the first thing is to build an infrastructure that makes it accessible to mere mortals (as opposed to Woof, which is only accessible to real developers).

The first step is to produce a barebones main sfs file that only has what is necessary to install and run the system. Just the stuff to configure the hardware, a desktop, the Load SFS program, Remaster Script and Pupsaveconfig. That would be the base to allow creating a modular system. Pupsaveconfig lets you decide how to handle the save file. Load SFS lets you add modules to the system.

Then create another sfs that has setup utilities, including the PPM, Gparted, all the utilities to configure the desktop, all the utilities to create and edit pets and sfs files, etc etc. All the stuff to setup Puppy, as opposed to just use it.

Finally, you'd have a DevX sfs file that has the compiling tools just like it does now.

With these three pieces, you can then create sfs files to make a modular system, create pet files to install to save file (or use as a basis to remaster the main sfs file), use the PPM to install Ubuntu or Slackware packages to install to save file (or use to remaster the main sfs file), compile programs from the source etc.

It gives a lot of flexibility to create custom modular (or not modular) distributions without dealing with Woof.

Anyway, just a thought.

Hi.

This sounds like you could be the one to get involved in development of my latest version of the SFS P.L.U.S.!

Yes I notice fixmenus did some mad stuff making it slow..I hacked it down in lucid and dumped it a long time ago in the rest.
Xfce4 uses xdg desktop file handling so it just needs a trigger to refresh it when a module loads...at least the version on puppy does but its quick.

Hmm once upon a time '_525.sfs' on the end of an sfs would mean it would load at boot...no configs, no boot parameters...just add the file and done.
The simplicity of such a system was ok as a no brainer to get a modem module built before I knew anything about linux.

My speed point was that even with a bundle of modules there is only a few seconds involved....one reason is the usually contiguous nature of the sfs files. fast boots and shutdowns for that matter are more significant on anything battery powered....and for impatient users like me

Slax does things a little differently to puppy at boot.
It actually builds a bare union with ONLY the tmpfs for changes (or save file or folder) The modules themselves including the core system are all then loaded on-the-fly afterwards in the same manner as the finally booted system. Layer order is determined by the module naming order with say 001 at the bottom...zzz at the top so giving full control in that area. Does make for a very simple boot script....(the functions used are in a file which is common to the initrd and main system since they are identical) One other difference is there is one shared tmpfs for both modules and the read/write layer which does give a simpler picture of ram space usage. It also means there is no need to resize the tmpfs to fit in further modules and determining space left is easier. I tried sharing tmpfs on puppy and it worked but could not be done without moving certain union mount points so upsetting some scripts.

Dancytron...a build a bear puppy...like the slax live builder... always seemed like a good concept. Being modular the kernel can be a drop in too.

Hmm once upon a time '_525.sfs' on the end of an sfs would mean it would load at boot...no configs, no boot parameters...just add the file and done.

Nice option. Did never heard of that.

Sounds smarter to me than the so-called ADRV option made by jemimah (hm, can't remind the name of the OS, I think Carolina is a successor of it)

Quote:

My speed point was that even with a bundle of modules there is only a few seconds involved....one reason is the usually contiguous nature of the sfs files. fast boots and shutdowns for that matter are more significant on anything battery powered

Ok, I see.

I'm only using desktop computers. Do not own any other and don't want to.

Quote:

I tried sharing tmpfs on puppy and it worked but could not be done without moving certain union mount points so upsetting some scripts.

I doubt, I could do such things. So, seems that you are more an expert than I'm (of course I'm not).

However, I will try now to add to latest version of my SFS P.L.U.S. suggestion by mavrothal of ability to download SFS Modules at first boot (from CD) to be able to have some testings without to install the OS first.

I might be offline for a few days. Hopefully returning back to here exploring lots of new and interesting posts (maybe some more individual used solutions for a Modular Concept?).

mikeb; Yes, I think you`re right that running aufs is it`s main cpu/ram load.
Adding more layers after that probably doesn`t effect things as much.
Which makes it pretty usable for what RHS is talking about.

# RHS; What`s your opinion of a bare O.S. with only base apps., using app. modules only.?
Reduces download bandwidth, and users don`t have to ask how to delete unwanted apps.
Only a dev. or two are needed to maintain the O.S., but many app. builders are needed.
.

Doing it wrong can lead the the problem of incompatible shared libraries and the like.

Such would mostly be an (unsolvable) problem by using PET instead of SFS. Some of my LazY Puppy Systems have Jack Audio installed which conflicts with two of my VLC SFS Modules, because of different shared QT libraries

In the past, I have solved the library issue with scripts that set up links to stuff. It works out a lot like plugging and unplugging SFS. The programs can't be used at the same time when that is done.

I also can on some things get the source and do a compile with static linking. It makes the programs bigger but it can solve some shared library issues.

Since a pet is really just a TGZ archive, an "installer" could be made to create an SFS for each new thing you install as a pet so the SFS modularity method can be transparent to the user.

Version conflicts... the idea of building your apps on a base system so they will work is a valid one.... debian squeeze apps will work on debian squeeze.

Random packages built on random systems is the problem here and the desire to grab packages from the big boys who have a totally different build agenda.

The other way is to build on a system (the target one!!!!) that steps back a year or two.... much more likely to produce a universal result.... such as libreoffice do this. With puppy this probably makes the best sense as there are so many variations.

Static binaries... yes one approach ...again adopted by many builders especially games I find.... not just static binaries but statically linked libs so all is in one folder. The thoughts about the build system still apply...I cannot use most of the programs on portable linux as they are built on a recent ubuntu.

Building a system around rox is nice but hits the snag of what happens with a different desktop/window manager and file browser.

I think RSH is away for a few days so might be a while before he replies.

Amigo made a AppDir setup that compiles the app into a new AppDir. Very nice...
Source packages are easy to find, so my Virtual Apps package would go well with this.
It`s an empty AppDir except for scripts to download, compile, and setup. Very small.This arrangement will support all the variants ( OR, just have one O.S., not many ).
That... Or each app builder makes app packages, one for each variant type ( NOT good ).

>>> Sorry for straying from the modularity theme RSH.
.Last edited by sunburnt on Thu 07 Nov 2013, 03:01; edited 1 time in total

But, since Linus Torvald has had said: Talk is cheap, show me the code., there is always to do some work, to be able to show some code.

I want to show you the code, which still needs some work.

Doing long posts with facts and replying to replies takes a lot of time for me to do in EN. Really, you all can't imagine that from reading my posts.

Such time is often better used, when working on progress and/or suggestions.

Even such is hard for me to do, since I'm jumping from here to there, because each work on a new suggestion often offers new ideas to me, that also often have nothing to do with the suggestion to work on. It has just happened again!

However, lot's of new and interesting postings here. So, a short post is possible for me to do.

I have made some progress and therefor some good news to publish - maybe tomorrow (we'll see).

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