Feel free to use any part of it useful to you... certainly it would need adjusting to your requirements as its written as a right click in rox option.

Quote:

at least in its LASTUNIONRECORD entry since this is the one mainly used.

what is it used for with regard to an sfs loaded on the fly...ie for the current session only? Does puppy attempt to unload sfs in the union (I added this ...basically uses the unload part of the script here in a loop.)?

Quote:

As I have seen it (the SFS) is mounted by using its name and not in pup_roX directory. Is this what you meant about mounting a SFS on top of other layers - even than main one?

No .. that is to make it 6000000 times easier to find in order to unload (or browse for that matter)

The layer order is set by the format of the mount aufs command...compare to sfs_load. If a sfs is loaded under the main sfs then say it had a newer library for the app ...it would not be seen. If it needed to modify /etc/passwd (eg a web server with mysql) that would not be seen.

Quote:

- adding --use-pupro command (to load SFS Modules as usual)

what does this do?

Quote:

Adding also --unload command (obviously use)

you will notice I check if the sfs appears in the mount output and treats as an unload function if it does...also means a click and mounted sfs would be ignored too but thats a good thing...so automatic but easy to have it manually selected but perhaps keep the mount check.

By the way.... I tested a sfs in /root ... copied to ram and loaded...without ram space it just gave the 'unable to load message'

at least in its LASTUNIONRECORD entry since this is the one mainly used.

what is it used for with regard to an sfs loaded on the fly...ie for the current session only? Does puppy attempt to unload sfs in the union (I added this ...basically uses the unload part of the script here in a loop.)?

It's just the list of currently loaded SFS Modules - as far as I know.

In SFS P.L.U.S. this list is used for the SFS Unload GUI - I have created separate GUIs, because they are faster to show the SFS Modules as original sfs_load GUI is - especially when 427 SFS Modules are in one directory.

Quote:

Quote:

- adding --use-pupro command (to load SFS Modules as usual)

what does this do?

It mounts (should do then) the SFS Module then to a pup_ro directory.

Quote:

Quote:

Adding also --unload command (obviously use)

you will notice I check if the sfs appears in the mount output and treats as an unload function if it does...also means a click and mounted sfs would be ignored too but thats a good thing...so automatic but easy to have it manually selected but perhaps keep the mount check.

Yes, I know. But --unload would be option to unload SFS by a script command.

To check if it is loaded and then to unload is the old way of sfs_load. Newer version do use the --unload command, so the SFS is not mounted when -accidentally- trying to load again.

Quote:

By the way.... I tested a sfs in /root ... copied to ram and loaded...without ram space it just gave the 'unable to load message'

As far as i know, this doesn't work in sfs_load (<1.4??).

--

At a previous post:

Quote:

I suppose the discussion of a modular OS comes in as you did make lazy puppy so I/we tend to assume there is a bigger picture going on.

All discussion of a modular OS to design, is welcome in this here thread. What I meant, is: I'm sometimes interested in reading such, but I don't have all that knowledge to understand completely and/or to reply such postings. As it is my thread, I assume, if not especially addressed, a post would be addressed to me (and others of course) and therefor a poster would wait for a reply.

Just nobody should feel to be ignored, when I'm not replying to such posts.

Everything else related to A modular use of Puppy Linux is also welcome:

It's just the list of currently loaded SFS Modules - as far as I know.

ok... well using the sfs name does give a dead easy way to list loaded modules using ls or find... but then you have to deal with puppies way of doing things ie pup_ro(n).
my initrd has pup_ro1 , pup_ro2 and pup_rw, everything else is loaded on the fly to named folders in the same way so there is no distinction between loaded at boot and later on.
I am not a fan of lots of status text files scattered around.

Yes defining load and --unload would make sense for your system....simplifies the bash anyway.

So quite a bundle.

Is there an advantage of roxapps over .desktop files and the linux file system? That one loses me a little bit.

Hi mikeb; A true sfs file is a creature of the union. But they can be used without a union also.
There`s a few ways to make this work:
1 ) Custom compiling ( doesn`t work for all apps, some just don`t like it.).
2 ) A close cousin to it is modifing the exec. binary files so the paths are changed to relative.
....... If all apps were made with relative paths, they`d all be relocatable ( some don`t work also ).
3 ) A private union and chroot, this works very nicely and keeps the conf. files in the AppDir.
4 ) Making links and setting $PATH & $LD_LIB_PATH. Works very well, kinda messy to do.
5 ) A Junction link ( doesn`t exist for Linux ). It`s kinda like a half-way union without overhead.

RoxApp, or as they are called now... AppDir
They don`t have anything to do with desktop files which are just used for menus really.
My AppPkg makes links in /usr/share/applications to its desktop files, and for it`s icons also.

A union merges RO and RW file sys. because the Linux file tree wasn`t designed for this.
Relocatable apps don`t care where they are, in the Linux file tree, or a partition, or in ram.
For Puppy what this means is a small Save file ( no apps in it ), and no added union layers.

Working on a "Virtual AppPkg" Builder. I`ll post one. Made a Ubuntu mirrors selector gui.
.

Ok, I know I'm late. Wanted to post all the good news Yesterday, but real Life ... you know, just had to move some plannings etc.pp.

How ever, this has made me up to spend some time to do some further work on the concept of Modularity (which mostly to me is better spent that way, than to spent it to try to read and post on the forum) - and I can say: I have done a lot!

Currently I'm at work 26 Hours in a Row!

And it was/is worth every minute, that has been spent to this.

So, first to say: I've got some good news and also some bad news. And I assume you will -as usual- know the bad news at first.

Ok, here they are, the bad news:

- the packages have become bigger in size
- they are now too big to load the to the forum and send them by PM for doing some testings

And now the good news:

- the bad news are a part (a result) of those good news
- I have finshed the RoxApp Builder
- yes, I have made complete translations from DE to EN
- I will introduce (and include) the RoxApp Builder into SFS P.L.U.S. - actually already done
- I have made some testings successfully meanwhile using a bare Lucid 528-005, a bare Precise 5.7.1 and a bare Slacko 5.3
- all went well, just by a single left-click onto a RoxApp Directory Icon

I am currently packaging some applications and stuff together, to upload a full featured SFS P.L.U.S. including the RoxApp Builder, a resized (a little smaller) version of my RSHs-ScriptBox and a short tutorial how to install (actually just store on drive(s) the parts of the package, which is currently at 22 MB. It comes also with some portable Apps for Linux and Wine, to make the big picture of modularity really a big picture

Though, the SFS P.L.U.S. Install package is not needed to install, to use the package. Just run a fresh bare Puppy (best is Lucid for a first go and the most success of all the applications that comes with a RunScript, because of LazY Puppy is a Lucid Derivative).

Because I'm obviously unable to give anyone any idea of what am I talking about, working on and doing with LazY Puppy, I did decide, to upload the complete package. More on this some later...

Informative and IMHO important thread. I am happy to observe a spirit of inquiry and co-operation and hope it carries forward when it become necessary to create, in Barry K's absence, the next Pup.
And a special thanks to RSH for the links on the second post of this thread.
It is not my purpose to derail this thread, so if the following appears to be outside of RSH's interest please feel free to disregard it. However, I believe it is relevant both to question of modularity and the broader issue of design gcmartin raised.
I recall reading somewhere that RSH discovered RoxApps while creating his Puplet and realized their general utility for inclusion in other Pups. In a similar vein, I stumbled across what playdaz had referred to as Program Folders –he's since decided he didn't like that name, but I can't think of anything better-- and realized their general utility as alternatives to pets and SFSes. A Program Folder is an application together with all necessary libs and config files etc. contained in a folder EXTERNAL to Puppy: it can be anywhere, on any medium –CD/DVD's might have to be RW or Multiboot-- your computer has access to, linked to your operating system only by a couple kilobyte script which calls the application's executable. What can be more modular than that?
My experiments revealed that Program Folders more frugally --by as much as 45%-- utilize a computer's resources with the exception of storage. http://murga-linux.com/puppy/viewtopic.php?t=84457 than either pets or SFSes. I appreciate that each time I post something about Program Folders I arouse suspicions concerning pathological preoccupation or trolling. But with the cost (on ebay) for an 8 gb USB-Keys, a 100 gb IDE hard drive and a comparable “small” SATA drive under $15, I doubt that Program Folder's “disadvantage” is significant. So I wondered whether their failure to be mentioned on this thread might be an inadvertent omission rather than their being incompatible with AppDirs.
Some research revealed that they are not incompatible. The AppRun of an AppDir can be a binary, a wrapper script that calls on a binary elsewhere on the computer, an executable script, or even a symlink, though symlinks aren’t the preferred way to manage running applications in Rox. http://lucky13linux.wordpress.com/rox-rocks-ii-application-directories/. [I'll leave the mechanics of how to employ the script to call the executable of a Program Folder as the script used as the AppRun to another time or another person, especially as I haven't thought out how to transpose a Program Folder residing on an installation DVD/USB-Key onto a hard-drive in a user-friendly manner].
In a recent thread Pcman and SpaceFM were mentioned as having some advantages over Rox. AppDirs, however, are dependent upon Rox. [I tested the AppDir “Rox-Clock” by copying it into X-precise which substitutes Thunar for Rox as file-manager. The only thing clicking did was to open the directory]. So I wondered if it were possible to create an AppDir “effect” in the absence of Rox.
Googling revealed two methods. The first required that BASH be patched, and so is probably impracticle. But the second revealed a method used by Gobolinux, a now (I believe) defunct distro. Possibly, RSH and others may already be familiar with it. But I thought it might be helpful to those who weren't, especially for scripts Gobolinux used. To quickly understand what Gobolinux did, open the following review, http://linuxphilia.blogspot.com/2009/07/gobolinux-is-linux-distribution-i-heard.html, and scroll down to the section beginning with the word “Flagship.” A little below that you'll find an explanation of Gobolinux's file structure. Note in particular the contents of what Gobolinux put into the folders it named “Files”, “Programs” and “System”. The following is more detailed explanation of how GoboLinux was organized, including the scripts it used. http://www.gobolinux.org/?page=at_a_glance.
Of course, an easier way to obtain the benefits of either PCMan or SpaceFm may be to include them as a “secondary” File-Manager with Rox as the Primary, with perhaps some configuration so that for most user initiated file-management functions –copy, move, symlink etc.-- the secondary file-manager would be called. Regretfully, such configuration is beyond my current ability.

If the AppDirs are put in /mnt/home or where ever, are users expected to find and run them from there?
If a method is used to put an icon on the desktop, or a menu entry, then Rox itself is irrelevant I think. A link to the directory or to the wrapper-script/binary inside has the same effect.

I run Opera and Synfig (2D animation) as AppDirs, but Rox just saves me a click.

If your question was generated by my post, I apologize for any confusion. I wasn't suggesting that the AppDirs be place in mnt/home. AppDirs must remain within Puppy proper, either as part of the NameOfPuppy_VersionNumber.sfs included in the NameOfPuppy.iso or its remaster or as part of the "merged filesystem" if you are using a SaveFile. It is SFSes and Program Folders which are usually placed in /mnt/home. [You wouldn't want to locate a Program Folder within your SaveFile because --as in Full installs-- the files within it are NOT compressed. That is one of the reasons the use of Program Folders can reduce the use of RAM and/or CPU by up to 45%. On the other hand, the Program Folder equivalent of an 173 Mb SFS gz compressed requires over 500 mb of disk space].

But having re-read your question, I think you've made two false assumptions. The first is that RoxApps can be run when Rox is NOT the File-Manager. They can't. The second is that the purpose of this thread is to discuss his implementation of RoxApp, which it is not. The purpose of this thread is to discuss the benefits and detriments, issues and ideas in general relating to building Puppy in a modular fashion. As I understand it, RSH has developed an implementation, Rox App Builder, open for discussion and criticism here:
http://murga-linux.com/puppy/viewtopic.php?p=720483

mikesLrLast edited by mikeslr on Sun 10 Nov 2013, 21:36; edited 1 time in total

Its size is now 27 MB, but don't be scared on this size. It is just this big, because of some portable applications for Wine and Linux are included, to give you the most comfortable way possible, to have an easy start with that.

- directory 'Module' goes to boot partition (NOT directory!)
- directory 'My-Files' goes to boot partition also
- directory 'PortableApplications' goes to boot partition as well
- directory 'RoxApp-Application-Starters' containes some application starters,
- - that shall be used for an example, to show the re-build of such a RoxApp
- - no matter, where to store these - use !!!partition in EXT format!!!

- LP3_ScriptBox_Icons.sfs (Icons for RSHs ScriptBox)
- LP3_SFS_PLUS-3.9.3-install.pet (needs only to be installd, when the OS
- - shall be enabled to use the SFS P.L.U.S. RunScripts without the use of
- - LP3_SFS_PLUS_3.sfs)

- RunScripts for SFS Modules (currently 545) and portable Applications for
- - Linux (1) and some for the use in Wine (17)
- - it uses 'LP2_WineCorelSuite' from LazY Puppy, which is not available to
- - download - just use the (to be) renamed 'LP2_Wine.sfs' for this

Beside this there are some portable applications for Linux, Wine and also some
applications to install in Wine (use 'LazY WInstND' for this). Inside directory
'My-Files' are also some directories and files placed. When you want to change
any of the directories names, please edit its name in file 'lped' as well!!!

For SFS P.L.U.S. Suite and for the use of 'RSHs-ScriptBox' above listed file,
'/mnt/boot-partition-here/lped' is needed. For a published OS, that just uses
pre-build RunScript (created and included into the OS by the developer), only
'LP3_SFS_PLUS-3.9.3-install.pet' needs to be installed (ca. 142 KB). For simply
a daily use, do not install anything ---> read more below!

#################################
# How to use this at first start:
#################################

If everything is setup as described above and a fresh clean Puppy has been
successfully booted from boot partition, just open parallel partition 1 and
execute a single left-click onto the RSHs-ScriptBox RoxApp Directory Icon.

That's it!

Ready for use!

Have Fun with that...

RSH

Note: you can use 'RSHs-ScriptBox' and modify it for your own needs. I will not
make any further updates to 'RSHs-ScriptBox'. Only updates of 'SFS P.L.U.S.
Suite' and 'RoxApp Builder' will take place from time to time (if necessary
or evolved somehow).

'RSHs ScriptBox' has found its place inside this package just to show, what
anyone easily can build for his own needs, by using 'SFS P.L.U.S. Suite' and
the 'RoxApp Builder'.

It gives a small impression of what I have setup over here. Currently I do use
a OS of 130 MB in size, plus -setup in a way as it is shown herein- some extra
Software of 11,247 MB - the biggest pool is SFS Modules!

To use the RoxApps included in the Modularity-Package, download its related SFS File from my repository at smokey01.com/RSH/ and store it to /mnt/your-boot-partition/Module - the RoxApps do need the SFS at this location, because all they use is a symbolic link to the SFS._________________LazY PuppyRSH's DNASARA B.

Puppy linux is my daily use. But I do not like pupsave. If I not use pupsave, boot comes long time. (Sorry my English). I do modular things in my slacko that can be load from 5.5 and 5.6 (fresh frugal).
I interested to Tiny Core Linux system(fast boot). They fully modular, like Pupngo. This post is from tiny core linux 5.x. I can load inkscape.sfs from slacko repo, and copy their dependencies from slacko.sfs. (Just rename inkscape.sfs to inkscape.tcz, and cp dependencies).
Because I'm not DEVs, I wait a Dev person who can make puppified Tiny Core Linux. Your Lazzy Puppy is something like similar. (Sorry if wrong).

RSH`s modular LazyPup is movement in the right direction for Puppy. But a solitary movement.

It takes time for people to test new ways, so some patience and waiting is needed on the part of the dev.

I have used RoxApp in the past, and it's been used in Puppy circa version 1+, so I can say that I like it, but I still have to find time to test what RSH has done here._________________Puppy user since Oct 2004. Want FreeOffice? Get the sfs (English only).

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