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

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

No.

I'm just on duty.

Quote:

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._________________LazY PuppyRSH's DNASARA B.

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

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:

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.

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.

Quote:

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!!!)

Quote:

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

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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

Quote:

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!

Quote:

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.

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.

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

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.

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

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.

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.

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