As most of you already know, I'm using my several LazY Puppy Systems strictly modular and without the use of a save file.

In my humble opinion there is too many postings on the forum, about problems with the use of a save file (Help, my save file is filling up, can't use XXX after installing YYY etc.pp.) followed by lots of pages of instructions, how to "fix" such.

This is boring and of course it doesn't really help to make people willing and able to change from Windows (or any other Linux OS) to Puppy Linux and to become a Puppy Linux Newcomer.

That's why I want to make a vote for a modular use of Puppy Linux and to compare some (still available) Puppy Linux Operating Systems with some of my modular LazY Puppy Operating Systems.

I will use for this: Studio 1337, Vincent van Puppy and the Lucid 5.2.8 (no Plus, no Libre, just the basic version).

- offers two versions of SFS P.L.U.S. (extracted from LazY Puppy for almost any other Puppy, except FatDog)
- offers lots of information for the use of this
- plus some (one or two) update files (please, read the thread carefully)

Modularity Package - was for testings only, now removed,is now SARA B.
- completely new written, based on the Ideas of SFS P.L.U.S. and RoxApp Builder
- needs and uses only what's already installed in a Puppy Linux

Skript by mikeb
- a small but useful script to load SFS Modules without the use of sfs_load
- ability to load SFS Modules on top of the pup_ro layers
- - as well as on top of the main layer
- - pretty cool (imho)

That's all for now ...

... but there's some more. Just need to search and to find...

If anyone finds something that might fit into the Modularity Concept, please post a link here, or send a PM. I will include such information into this post.

As most of you already know, I'm using my several LazY Puppy Systems strictly modular and without the use of a save file.

I am typing this from a full install of 528.

Making things modular and make them a lot more reliable if done correctly. Doing it wrong can lead the the problem of incompatible shared libraries and the like.

When we make a modular system, it would be nice if a lot of the modules could live on the CD so that network access is not needed to plug things in when needed. I see no reason that a largish number of SFS or pet files could not be on the CD.

Modules should be able to be plugged in when needed and unplugged when not 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.

My main LazY Puppy (4, 130 MB) doesn't have Jack Audio installed. So, I'm able to use each of the three VLC SFS Modules I do own - just have to choose one. At least I'm able to do so, after unloading the Jack Audio SFS.

Also I can use Openshot and KDenLive, which will never work, when both are installed - just have to choose one (and possibly unloading the conflicting one, which can be done automatically by the SFS P.L.U.S. RunScripts - just need to define once the conflicting SFS for that).

I have some SFS Module that needs different versions of QT, which then is defined as dependent SFS and loads automatically. I can use all of them - just need to choose one (and possibly unloading ... ... ... ).

You can't do such by using PET and -as far as I know- full installs.

starhawk wrote:

If I may ask, what made you choose my pudgy Pup for your experiments...?

Also: what the ___ did I do right this time?

Like Studio 13.37, by its size, it was a good example, to show the difference of an OS with lots of huge applications installed, compared to an OS, that has just some RunScripts installed, to load SFS files and execute its application automatically.

I don't know, what you did "right this time", but I'm sure, you did nothing wrong with that Puppy.

Though, by using the modular concept, you could have been able to give a smaller OS to the users - including all Vincent-Work-Needed-Applications. This would have made users with less RAM computers able to use Vincent van Puppy as well. And those users surely don't need Libre Office installed when they just want to work on a picture using the GIMP.

Packages like Libre-Open-OrWhatElse-Office and/or Browser packages should not be installed by default, because: once you shut down the computer and rebooting it, there is a new version of the Office Suite or Browser package.

oldyeller wrote:

What do you mean by modular and how is this done? This is new to me, so explain!

Modular just means: to use SFS files. Each SFS is a Module containing an application. Modular use means: load an application (its Module) only when needed to work with. Keeps the OS small and therefor offers a lot of free RAM for the application in use.

Why to have 150 MB Office Suite plus 30-40 MB Browser package installed, when just wanting to use the GIMP?_________________LazY PuppyRSH's DNASARA B.

Hi everybody!
I'm curious about this concept and the I'll try Lazy.
Sorry for this, but I would have just one question.
What will be the change in terms of stress on usb mem stick install?
I mean, I've seen a lot of suggestion and similar things to the aim of limit the useless read write cycle, so this absence of save file does change anything?
Once again, I apologize for the question if it will be too newbie

As most of you already know, I'm using my several LazY Puppy Systems strictly modular and without the use of a save file.
In my humble opinion there is too many postings on the forum, about problems with the use of a save file

My humble question: If having no save file is part of the "strictly modular" concept. then how and where are personal settings saved? I need the nag screen at startup (quick setup) only once, not every time I boot. When I choose one of the 3 window managers included in Lazy, I want Lazy to remember my choice. I want Lazy to remember preference setting I made to Gimp even after I unload the application. How do I do that without a save file?

inoxidabile wrote:

What will be the change in terms of stress on usb mem stick install?

Less stress as nothing will be saved. Everything runs in RAM. I assume that depending on your use case you can even remove the stick like you can remove a live CD after booting.

So the Save file is not needed for modularity as he`s running with no Save file.
But as mikeb states: The Save file is also a module.

# Suggestion: No-install apps. can overcome the library conflict problems.
And they can also contain the Save ( settings ) portion of an app., SFS can`t do this.
This way if you copy the app., the settings go with it and are not lost.
And no Save file is needed ( at least for the apps. ).

Strictly SFS files can`t completely overcome library conflicts as files overshadow each other..
And strictly Pet packages ( normal loose files ) can`t do anything about the problem.
But both of these package types can be "patched" to use unique libraries with a wrapper script.
At least SFS files don`t take up the Save file space like Pet packages do.

I downloaded Mint Linux at 900+ MB. WOW... What a waste of bandwidth.!
I use very little of what Puppy has in it, and some folks call it bloated.!

# I agree completely with RSH`s view that apps. should be Add/Remove modules.

# A small modular O.S. so the user gets exactly what he wants and no extra crap.
.

As far as I can see the LayZ ISOs do not have any modules/applications so they must be downloaded to be used, which is OK I guess.
What I find less convenient is that module installation can not be done with "live" boots.
You may want to provide a really big ISO with the SFS extension included that will allow the "live" and also "off line" use of the OS. At least to go with the "no savefile" theme _________________== Here is how to solve yourLinux problems fast ==

Firstly, I want to begin by apologizing for I have NEVER installed a PUP on any storage media .... ever!. I have run primarily from Live media.

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.

I do NOT have any PC with less than 1GB RAM. I am NOT the norm for this community, but, I can say that what you share about issues with savefile as you point out, I have missed many/most all of them.

The savefiles on the Live media are stored in a modular fashion.

Here's the dilemma
If you are a non-developer, Puppy Linux (and most every desktop distro) is the one for you, IMHO. 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. I do not lift the covers to see whether my RAM is full or not as I run with a SWAP partition and allow Linux to spread its wings and manage its flight.

I had a FATDOG vintage 5xx that ran non-stop for over a year. I rarely if ever boot the systems I use for production. I have installed PETs and in most every case, I have NOT rebooted the running system to begin use. Further, no PET that I am aware of has produced a detrimental behavior in the system, even if I uninstall PETs for newer ones.

That being said, 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. These approach are vastly different in thought and planned operations.

The value is NOT whether or not it is modular but whether it meets or exceeds objective. An objective must discuss and maybe demonstrate how its design selection resolves and addresses the functionality needed.

Over the past 40 years this has been an item of debate. But, each time, the intellectual of us have measured and shown corporations which of the findings best meet the results needed.

Modularity should NOT be an emotional discussion. 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. We can, though, discuss how to make successful modular implementations where a rollin-rollout system's operation will be a more beneficial approach to stable and responsive system operations versus any current method in use, today.

If the fact is that tools can be constructed to better assist problem determination is existent or easily achieved in a modular system design, than what exist currently, then this too can be a good point of interest for additional modular efforts.

Please understand that the audience for modular OS approaches is the Puppy developers. For us testers, we need some valid methods to measure to show the true merits of a modular design.

One other problem is when I've seen members post that because of an application's size, it is good or bad. When viewing this, I have sometimes seen where posting are structured to support the one element the user needed and as such disregard all/most of what the larger application may bring to the table for its users.

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.

In an OS's operations, many of its subsystems are present, but sit idle until some system event wakes them. These RAM resident subsystems intend to give the system and the user(s) the greatest possible experience or the frequency of their use demands this, or ...

One other member of the Puppy community has been working with JamesBond on a system implementation where SFS would be expanded at startup time and the compression-decompression would never occur in system operations. This has merit in the systems performance. On most 64bit systems this is a non-issue because of the amount of RAM that usually comes with the system. Thus instead of RAM-Swap sitting around unused, this is how performance increases to the user can occur over and above a normal system operations. In cases like this, users would only see "lightning-fast" speed while not knowing what caused it. Nor would anyone care.

One of the primary reasons some of us use a fully feature PUP is that it negates the need to install anything for the utility functions we will use. For example, I don't use my office tools all the time. 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.

For some, especially with the selections that Distrowatch provides us, we can choose any of the 100s of Linuxes which most nearly meet our needs. I can have a forensics or a PVR or a NAS or system for noting my musical score directly from an instrument, or a .... This, is just what the distro developers do for us in Puppyland. And for many users, here, we will use your distros because of the functionality it provides for the task(s) we need.

Is is hoped that there may be some value in this insight._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

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