(old)Puppy Linux Discussion Forum

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.

Lived in france for a while so understand that one....
but you managed to troll batter effectively hopefully leaving a quiet productive thread..

I developed my systems some moons ago and have solid frameworks that just get the odd update now and then but happy to throw in my experiences and anything else that might be useful.

@sunburnt ... updated mut this week (ext4 and stripped out all the logging/debug stuff),...thought the sources were lost... the busybox of drive handling ... added it to the initrd too. Puppy lacks c programmers and I am not one either but some functions are better handled in binaries.

Hijack over

Ok we await your needs, questions, statements, tap dancing, jokes RSH but we are not groupies

mike

sunburnt wrote:Good to hear from you RSH, I was worried you`d become discussed with your thread.

No.

I'm just on duty.

If my idea of Virtual Packages interests you, you should see what I have done.
Current work is on a general purpose world mirrors GUI for the Virtual Apps.

Of course, I am interested.

Some of this probably could be used to refine/extend the RoxApp Builder.

mikeb wrote:Ok we await your needs, questions, statements, tap dancing, jokes RSH but we are not groupies

Ah, Ok.

So, stay tuned is like a saying to groupies?

I think, I remember me knowing this saying from the old days, back when I was a child and listening to a few GB/US Radio Stations. Germany was split/divided then and also occupied by the US/GB/FR allies (Western Germany).

Aahhh, I should remind my saying: to not to start any off topic discussion...

Ok, I'm still at work. After finishing it I'll have to "fix" my bicycle, which means, to make it ready for the use at winter times. This might take a day as well. I think I'm ready to turn back to here with all good news to offer, on Saturday.

After finishing it I'll have to "fix" my bicycle, which means, to make it ready for the use at winter times.

hmm no tread on the tyres, not smooth chain, boot lets in water and velcro on snow hats.... yes must get busy too...

Mike

RSH; What RoxApp Builder are you referring to? Your`s, or maybe amigo`s?
I`d like to see it`s method of app. enabling, and it`s arrangement of RoxApp structure ( if any...).

Can you give us a short hint of what project/code you`re working on? An app. package setup?

Modularity: Most simpler apps., and bigger ones that work well as AppDir can be that way.
This simplifies adding/removing the apps. as no sfs_load is needed, and fewer union layers.
Organize: Make uncooperative apps as SFS files, and bundle the ones with common deps.

mikeb; I seem to recall mut from Puppy`s earlier days. Replaced by pmount or hotpup?
My latest is staring at Xwindow, and, Xlib, XCB programming examples.
Want to make base window with all common needed events and methods to draw on.
Like many (technosaurus) I`m sick of GTK+ and want a new tool kit, and a common api.
.

Yeah, a short reply is possible.

Currently I'm working on SFS P.L.U.S. Version 4 - (3.8.9 at the moment).

Adding option based on mavrothal's suggestion to download SFS Modules to specific location, at first use of a Puppy (when using from CD, since one can't download to CD, which then is the LP2BDL - boot directory (usually it loads from and downloads to this location)).

Also, mikeb mentioned something about ROX or RoxApps and other WMs like XFCE, e17 etc.

All Programs/Functions of SFS P.L.U.S. are easily to be used by right-click action, which will only work in a Rox Filer Window. They can be used also from a menu entry, but this will add 25 entries to the setup menu (or was it utilities?).

So, I'm working on a GUI to be able to execute/use all SFS P.L.U.S. Programs/Functions from within this GUI. Will reduce added menu entries down to 1 - if needed or wanted!

Since I'm able to use the SFS P.L.U.S. Suite to create RunScripts from:

- SFS Modules
- Portable Linux Applications
- Portable Wine Applications
- Wine Installation Packages (Forum Utilities - LazY WInstND - paused - for further information, if interested)

and so, I felt in love with the idea of creating RunScripts from RoxApps.

RoxApp Builder: I did refer to the RoxApp Builder (forum Puppy Projects) of mine - did not know, there was any other.

Perhaps try loading a sfs on the fly with a 32 line script in a fraction of a second ..easy and fits in with standard linux structure...its fun...or just load a bundle of you favourite apps at boot time.

Actually I was referring to mut2 the backend daemon for low cpu monitoring of all drives and related functions....saves a hell of a lot of scripting. (and cpu time) ...probepart/probedisk/guess_fstype/probepci/usb insertion notifier and more all in one multicall binary.... basically left in mid air when jesse left the world of puppy so never had such as ext4 added but that was done to guess_fstype which is one of the sub apps so easy to update.

If you want an overall picture of such as this thread is about...imagine slacko or precise but with the performance of puppy 2, rock solid save behaviour and a no brainer , no breakages package system.... you could even drop in a new kernel in a flash.

mike

Ok Guys.

I might be somewhat like the:

Chief Executive Officer of LazY Puppy Software Group

and therefor I' might be as well the:

Project-Leader/-Manager/-Maintainer of SFS P.L.U.S. Suite Development Team.

But, as you all know:

- all the above Groups and Teams are just an assembly of a single person
- better saying: of a single old man, still being a Linux newbie

Really, I can't handle with and do know almost nothing about stuff like:

- mut, mut2 (mikeb)
- self contained SCM extensions (mavrothal)
- PVR or NAS System (gcmartin)
- SLAX (simargl5)
- 64bit Systems and PCs (gcmartin)
- Puppies like: 2.02, 2.12, 4.12 (mikeb)
- Woof (or Woof2) (dancytron)

etc.pp.

Though, I've read the postings, it makes me believe, it would take me another one or two years to get behind all such things.

However: I have almost finished my work and so, I can spend some time to make a reply to some postings, before I'll go to sleep.

Ok, at first the HUGE post by gcmartin.

gcmartin wrote:I have run primarily from Live media.

Usually I prefer to use installations to USB flash drive. At my home workstation I do mainly use USB HD. I have a swap partition at home, but not on the USB flash drives in use.

I fully understand what you propose. But, the world since I started using Puppyland distros has changed. Back then I had some tiny 1990s systems. Today, most of my hardware is pre-2006 PCs and a couple of old X2 desktop and 1 64bit Atom.

The my computer's main board is from 2007 (date of buying it) - anything else like graphics, sounds etc. is much older (still using a sound blaster audio card from year 2000!!!)

As a user, I have no need for understanding of whether a system is modular or not. Most of us look for stability and functionality.

This is also my main point for an Operating System. I don't care, how the GUIs do look (old-fashioned or outdated).

I think that as we discuss system design(s), we should discuss them in their merit. For example, in the many many years that I have been in IT corporations and in OS development design, we discuss, plan and implement a system design based upon the goals we set. I have worked with implementations that use rollin-rollout (this is what modular design systems do) as well as with systems which use subsystem that are ever-present.

Yes, this might be some sort of discussion related to system designs, but it was not intended to be such. I don't want to design a new system and I also don't want to produce a new ISO etc.pp.

The point is: a modular use of Puppy Linux.

It is not: create a modular based Puppy Linux OS.

Yes, Puppy Linux is copyrighted by Barry Kauler and only his work is called/named Puppy Linux. But to me, this all is Puppy Linux - no matter, what/how the OS is named to.

Mainly my intention is to make most of the Puppy Linux users, members and developers able to use the modular concept of SFS P.L.U.S. -based on LazY Puppy's modular concept- for their own projects, operating systems and ISOs to publish.

I'm really not interested in:

- producing/developing a new operating system (except for my own needs)
- what a new operating system should be based on (I don't care, if: slacko, ubuntu, debian - just not interested in)
- and so, I don't want to spend too much time for discussions about system designs etc.pp.

An objective must discuss and maybe demonstrate how its design selection resolves and addresses the functionality needed.

The modular concept of LazY Puppy 2.0.2-005 already demonstrates this. But this concept used has now evolved so, one won't get the whole picture of it by now.

Posting ISO sizes in an effort to show that it somehow has deprived functionality should not be an approach that we use to justify a directional movement.

Sorry. Just did now know, how to make a start and how to show this in any different way. To me it just was the best way to start.

Further, most often times, I have seen the idea for modularity done at the application level. The internal operations of a full-on versus a modular application are vastly different. It is here where modularity really shines. Reason: All elements of the application need not be present until the user hits a selection for the functionality that the user needs. This is done with the knowledge that the user MUST wait while the appl manager does a rollin-rollout as necessary.

The application level is currently the one and only level, where I'm able to do some work for a modular concept. The user always has to wait until the application starts and appears on the screen. Even Firefox is not immediately usable when installed.

After the SFS Module is loaded, I can not see any difference in speed, compared to installed version - first two versions of LazY Puppy has had Firefox installed.

Since I don't, should I call them bloat because of that? If I like 98% of what's in a distro I select, should I write the author to tell him that the 2% is bloat (or any percentages)? I thnk you see the point. In my cases that 2% has not been seen to have any impact on my systems behavior. Its just NOT used.

Ok. But 150 MB Libre Office in an 630 MB ISO, of course is a lot of more than 2%. I will call this bloated - especially, if built in and when discovering a new version after having a reboot the very next day!

dancytron wrote:I'd be happy to do some testing and give feedback. I'm not sure if I'd be any help doing actual development.

What I'm actually needing is some testings with feedback, improvement of English language files used. I doubt anyone else could develop SFS P.L.U.S. and its components without studying it in all its details.

sunburnt wrote:# 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.

I don't mind if the OS is a bare OS, when "bare" doesn't mean: it will miss all its mainly needed libraries for the apps. I have seen this in some Precise derivatives, like LxPup. For SFS Modules that worked out of the box in Pecise, I have had to install some libraries to get the application to run in LxPup (one example to remind was Audacity 2.0.0).

It should be pretty well set up related to libraries.

Moose On The Loose wrote: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.

Exactly such issues I have noticed on the use of my RoxApp Bulder when using .Rox4fs type (just a renamed SFS Module). But to me it seems to be only relevant when using a save file - so, I don't even care on that (currently).

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.

I think, this would be the best way in general!

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.

SFS P.L.U.S. already can turn each PET package into an SFS Module including creating of a RunScript for immediate use/test - just by right-clicking the PET package. The PET installer in LazY Puppy 2.0.2-005 offers a option to create a SFS Module instead of installing the PET package. This function will be available in SFS P.L.U.S. 4 as well!

Batch mode as well, directories containing PET AND DEB packages also!

sunburnt wrote:Yeah, most portable apps I`ve tried are not so portable.

Yes, confirmed. I did try a lot from a Portable Linux Applications WebPage. Some did work, some doesn't. Some did work after adding libraries or stuff like Python, Java etc.pp.

That's why I did create the RunScript Builder for portable Linux Applications. It can define SFS Modules as a dependent SFS to the portable Linux Application, which then is loaded first - right before executing the portable Linux Application.

Ubuntu is bloated, but size isn`t important ( ask your girl friend Laughing )

Yes, one can also use his 10 Modules on both of hands!

mikeb wrote:Perhaps try loading a sfs on the fly with a 32 line script in a fraction of a second

Could be solved possibly using a 10 line script - or even less.

But I'm not on size - neither for applications nor for scripts. I'm on comfort of use and setup. You can't produce a 32 line script, that offers SFS Module to load (also to download from web, if not locally existing), all needed dependent SFS Modules to load (also to download from web, if not locally existing), doing a md5sum check automatically after downloading, executing the application and sending a file to it - all for the use from a single click on a menu entry or a desktop icon.

No, you can't!

---

Ok, that's enough for now. More details on Saturday.

---

Attached: Screenshot of my Openbox Menu Pipe for the loaded SFS Modules (to be unloaded, when clicked)
The funny thing is: Openbox removes the underline "_" from SFS Modules Name - the names usually begin with "LP2_", but it somehow doesn't effect its use.

Menu Path to LP2_PupSnap-1.6.3_Scrot-0.8_32Bit-l528.sfs would be (in EN):
->Welcome -> Manage Modules -> Loaded -> LP2PupSnap-1.6.3_Scrot-0.8_32Bit-l528.sfs

Apologies for straying .... especially as most of my last comments were aimed at sunburnt which would just confuse matters. (ie mut2 and how well a sfs based system can work)

Actually the aim of posting the script was to a
show how little is needed compared to sfs_load to actually do the job..those 32 lines load and unload and decide which to do, In other words could in some way contribute to your sfs plus script.

and more importantly how to load modules ON TOP of the other modules including the core so there are no hacks needed to deal with needed elements being hidden in the union.

My reference to earlier pups is simply because most of my development was done there and techniques from such still apply...plus there have been some good methods lost...eg sfs naming to auto load. Also SLAX gets a mention for the same reason..it contains very useful techniques.

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.

This thread did become quite hectic which has been a lot for you to wade through (in EN!)...perhaps you need a clean start with specific aims ... this topic does tend to invite general comments

here to try and help

Mike

Installing a sfs is simpler than a pet
mount and extract to /

a pet has to be extracted and then the resultant folder copied to / ..messy and uses double the space temporarily.

So well worth having a sfs install to full/save if wanted.. 3 line jobbie .. this also encourages having apps in sfs format only.

Additionally dependancy checking can be done without extracting anything... more non destructive testing.

Finally having 3 install systems seems a little excessive especially as one depends on having a particular file manager present.

mike

Actually the aim of posting the script was to a
show how little is needed compared to sfs_load to actually do the job..those 32 lines load and unload and decide which to do, In other words could in some way contribute to your sfs plus script.

Do you refer to this script?
http://murga-linux.com/puppy/viewtopic. ... 894#734894
Will check this out.

Somehow I have missed this...

Do you refer to this script?

yes.... was a busy thread at the time.

I don't think mount now shows the aufs layer like it used to and did not find a way of doing so..that option is set in the kernel though can be overridden by a parameter when loading aufs.ko if i remember correctly...example
Order is top on the left...bottom on the right

mike

Ok, this looks interesting.

Maybe I can use this for a special purpose.

Could you add a some code to check size of SFS Module/available RAM to make sure it (the SFS) will fit into free RAM space?

Could you add a some code to check size of SFS Module/available RAM to make sure it (the SFS) will fit into free RAM space?

Can I ?...I definately should . The other missing test is if the sfs is in the unionfs ..eg /root...

I'm testing an initrd so will do it later hopefully.

mike

edit...the question that comes to mind is what would be a figure for 'enough ram' ... otherwise I would probably use the same calculation the initrd uses since determining truly free ram from free is not often helpful I find.
This would allow sfs to ram to the same amount as would be determined at boot.

Ok a quick but hopefully not to dirty virsion that resizes the tmpfs if needed too (merging tmpfs was a way to avoid that) and loads to ram if enough space.

If the module unloads (some like devex will not) then its removed from the tmpfs too.

tmpfs is dynamic so making it the max the system is able to handle while leaving working ram should be ok.

One step at a time...left out puppy filesystem check.

mike

edit...actually for an sfs in the unionfs.... if there is ram space it would get copied to there anyway...and if it remains where it is the union mount would fail... so a check would only be informative.

Hi mikeb.

Yes!

This is pretty cool. I don't know, why I've had missed this. It could have helped me to save three hours of work at yesterday evening, when I tried to get sfs_load to not to copy the downloaded SFS Module to the boot partition.

No success at all!

But with your script, it works out of the box. Just needed to modify a RunScript for a quick test.

Had to remove the sfs_load commands:

--cli --skip-fixmenus --quiet

for that quick test.

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?

I have some thoughts about it and would like to invite you (and your script) to be a part of SFS P.L.U.S. development - by improving the your script for a use in SFS P.L.U.S. and its RunScripts and also for compatibility to sfs_load.

Parts of this:

- adding the --cli command (currently just as a dummy)
- adding the --skip-fixmenus command (as it is used in sfs_load, to not to run fixmenus after loading the SFS Module)
- adding the --quiet command (to load/unload SFS Modules without to show any information about loading/unloading)

and, to make it special and to possibly to build an alternative to sfs_load (smaller with some special features, but controllable by CLI commands)

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

Also, loaded SFS Modules should appear in /etc/rc.d/BOOTCONFIG - at least in its LASTUNIONRECORD entry since this is the one mainly used.
Edit:

Adding also --unload command (obviously use)

Ah good...its something I have been meaning finish off for ages.

Ok some answers/questions.

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.

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.)?

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.

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

what does this do?

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'

Your other commands like --fixmenu option will be easy to add.

Ok thats it for now

mike

Feel free to use any part of it useful to you

Ah, I feared this already.

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.

- 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.

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.

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:

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:

- suggestions
- just thoughts
- links to topics found on the forum
- private solutions
- scripts

etc.pp.

So we can have an overview of things related to a modular use - theoretically and practically.

My part would be -and is actually- the use of SFS Modules and therefor the SFS P.L.U.S. Suite, which currently offers 25 applications for the use on SFS, PET and DEB files.

This comes in an about 500 KB sized SFS Module.

This Module is not needed to be included in any OS to publish.

To use its results fully comfortable, a PET package about currently 120 KB in size is just needed to built in.

So, it could be used fully by users (turned into a PET -by SFS PLUS Suite- and installed) or partly by developers (just installing the needed basic functions).

The applications:

- Dependencies Adder - adding dependent SFS Modules to the main SFS Module
- Dependencies Combiner - combines the main SFS Module with its dependent SFS Modules
- SFS Unloader 1 (all) - unload all SFS Modules
- SFS P.L.U.S. Remaster Suite - an easy remaster function just to add new RunScripts to the OS
- Configuration and Data SFS Module (included, but tricky (the config))
- Mount point increase - increasing mount points in 36-er steps
- PET to SFS - converts a PET package to SFS P.L.U.S. SFS Module and builds a RunScript
- PET and DEB combiner - combines PET and DEB files into a single SFS Module
- SFS Module Tester - builds a symple RunScript for locally testing of a SFS Module
- SFS-Edit - edit SFS Modules - modified pizzasgood's version - can re-build GZ and XZ compression (if the OS is able to do so)
- SFS Unloader 2 - unload SFS Modules from GUI - selectable
- SFS Loader - modified shinobar's version - extra GUI to select Modules to load or unload
- SFS Convert - converts SFS Modules to SFS P.L.U.S. format - SFS is ready for the use of SFS dependencies then
- RunScript Menu - a GUI offering all installed RunScrips
- RunScript Patcher - patch easily execute-parameters of RunScripts - single and multiple
- RunScript Builder - the MEAN thing of all - builds the RunScripts from SFS Modules
- RunScript Builder for portable Linux applications
- RunScript Builder for portable Wine applications
- RunScript Builder for installations in Wine
- SFS P.L.U.S. Suite GUI - a GUI for the easiest use of SFS P.L.U.S. Suite

SFS P.L.U.S. Suite comes as RoxApp!

I just have to sort some things for the install package.

Over all it is ready now for testings - so, where are the testers?

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.

I am sure there are dormant testers...best put a file up to test

mike

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.
.

Hi mikeb and sunburnt!

So, there we are, the Three Musketeers of Modularity!

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

- the SFS P.L.U.S. SFS is 888 KB
- the SFS P.L.U.S. Install package is 142 KB

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...

I will be back!
(T2)

RSH