A vote for a modular use of Puppy Linux

[RSH]

Hi everybody!
Sorry, just a little question... Trying Lazy as live from usb.

Clicking on the top bar for internet it says that there isn't sfs for firefox.
Then it asks for download it, after accept this the download starts (from smokey01) and then it seems ok.
But after good download a message appears, saying that it isn't ok.

Then, with Puppy package manager I select firefox and in this way everything runs fine.

You do mean the message about different md5sum found.

This means not necessary the SFS wasn't ok. This is mostly a result of different dates of creating the RunScript and uploading the SFS Module (after editing it again without to create a new RunScript). The md5sum-file is stored inside the RunScript's directory and created only when creating a RunScript. Just try run the application again - should work, though!

However: please do post anything about issues in LazY Puppy in its thread. I'm trying to keep this here divided from LazY Puppy as far as possible - thanks.

Ok downloaded it, tried it but no sfs obtained perhaps the lack of DISTRO_FILE_PREFIX would be the reason.... something easily hacked or is there more to it?

@RSH
I tried the StandAlone-RunScript-RoxApp-Dir.tar.gz
Very impressive

Ok, so it doesn't work for mikeb, but it does for partsman.

@mikeb

Can you give more informationon what you did and what you mean by: perhaps the lack of DISTRO_FILE_PREFIX would be the reason.

So just to clarify the use of sfs files and RSH script box are not the modular idea here "just a little extra bonus" am i right ?

RSHs-ScriptBox was just an addition to give anyone an easy start for testings. Actually it is a rough cut-down of the version that I'm using here - and turned it into EN for this (mine is DE only).

The Modular Concept is basically the use of SFS Modules, but refined/improved as they download, load and run the application by a RunScript - using sfs_load in cli mode only.

The SFS P.L.U.S. development toolkit is to be found inside the RSHs-ScriptBox in its directory Module.

1. LP3_SFS_PLUS_3.sfs
2. LP3_SFS_PLUS-3.9.3-install.pet

These two are needed to build/edit SFS Modules, create RunScripts, adding dependencies to SFS Modules and many more. just do a right-click onto a SFS Module or a directory and look at the options (most of them do start with SFS P.L.U.S. - I think).

Note: this version 3.9.3 can not create those StandAlone-RunScript-RoxApp-Dirs - this is new in my current version 3.9.4.

When it is version 4.0.x I will publish this as a release. This will include then (hopefully) a short guide to the use of it.

[mikeb]

No bootconfig or distrospecs or my-roxapps.... so cannot really join in with the testing here....guess my puppies are not so puppy after all ....

Worry not

mike

[sunburnt]

Of course a partition fsck at boot could be done for Puppy ( Why hasn`t it? ).

Rather that a Save file, a Save partition would be a much better idea.
Puppy had an option for this, but I`m not sure if it`s still there.

A dir on a partition could be used also, and is a much simpler way of doing it.
But being as the whole partition would need to be fsck, a large partition would take awhile.

For folks that insist on WinBlows with NTFS partitions, a Save file is the only thing that`ll work.
.

[gyro]

A dir on a partition could be used also, and is a much simpler way of doing it.

For those with frugal installs on a linux partition, using a "save directory" in place of a "save file" would be a very neat way to go.

gyro

[mikeb]

For those with frugal installs on a linux partition, using a "save directory" in place of a "save file" would be a very neat way to go.

Added this option several years ago and yes its works nicely. Was pretty simple and mainly involved the use of a bind mount.

I added it after using nimblex/slax's save folder option and having a full partition for temp storage is so much easier. Stilll have the same save folder created 5 years ago

I believe puppies pfix=fsck option does do partitions....since I have pups loading to ram along with the save I just manually fsck occasionally since nothing is mounted at boot though it could be automated in the rc.sysinit like for a full install rather than hacking the initrd.

archive/sfs save is no problem on ntfs....whether ntfs is a problem is another matter The improvements in hard drives seem to offset the weaknesses of FAT.

mike

[RSH]

No bootconfig or distrospecs or my-roxapps.... so cannot really join in with the testing here....guess my puppies are not so puppy after all ....

Worry not

mike

Ok, I see.

Meanwhile I've had a look into a puppy 4.1.0, which doesn't come with DISTRO_SPECS, so I'm trying to create a function that will create a temporary DISTRO_SPECS file for the use of this.

Could you please post content of your file: /etc/rc.d/PUPSTATE (taken from the running OS)?

Thanks

[mikeb]

No need if it complicates what you are doing but here you are

Code: Select all

PUPMODE=6
PDEV1='hda3'
DEV1FS='ext2'
PUPSFS='pup_415.sfs'
PUPSAVE='ext2,hda3,/415_archive.sfs'
#these directories are unionfs layers in /initrd...
SAVE_LAYER=''
PUP_LAYER='/pup_ro2'

mike

[mikeb]

Actually scratch that... 4 won't work with sfs 4 .

Instead I ran my Lucid which behaved a bit better.
It gave an error message at first but then did download the program.... it then downloaded java. It mounted sda3 and created a modules folder and added the first sfs to it and mounted it to pup_ro4. The java sfs never did and I could not find it. So closer..

here are distrospecs (comments removed) , or whats left of it and the pupstate

Code: Select all

DISTRO_NAME='Lucid Puppy'
DISTRO_VERSION=525
DISTRO_MINOR_VERSION=00
DISTRO_BINARY_COMPAT='ubuntu'
DISTRO_FILE_PREFIX='lupu'
DISTRO_COMPAT_VERSION='lucid'
DISTRO_KERNEL_PET='linux_kernel-2.6.33.2-tickless_smp_patched-L3.pet'
DISTRO_IDSTRING='l525130426141631'
DISTRO_PUPPYSFS='pup_525.sfs'

Code: Select all

PUPMODE=6
PDEV1='sda3'
DEV1FS='ext2'
PUPSFS='pup_525.sfs'
PUPSAVE='ext2,sda3,/525_archive.sfs'
#these directories are unionfs layers in /initrd...
SAVE_LAYER=''
PUP_LAYER='/pup_ro2'

Out of interest i went back to 4 , activated the converted sfs to ram along with java 1u6 and the program ran ok from its menu entry albeit slowly which is not surprising.

Just as an aside I have mounted sfs over the internet but its not recommended ... but less nuttily we have mounted sfs via the LAN/NFS and they run just fine.

mike

[RSH]

It gave an error message at first but then did download the program.... it then downloaded java. It mounted sda3 and created a modules folder and added the first sfs to it and mounted it to pup_ro4. The java sfs never did and I could not find it.

PUPSAVE='ext2,sda3,/525_archive.sfs'

The use of 525_archive.sfs defined as the PUPSAVE of course was the reason for this. When a save file is in use, sfs_load tries to move/copy the SFS Modules. So, the java might have been copied to a black hole etc.pp.

When no save file is in use, sfs_load doesn't move the SFS Modules.

Oh, better saying here: lazy_sfs_load, because this one is used and it is modified to not to copy the SFS Module when no save file is in use.

I was not able to modify this also for the use of a save file - until now!

So, there are some good news.

The trick was: PSUBDIR has to be redirected inside of sfs_load to the directory used for the storage of the SFS Modules.

Also I have wrote a script, that will generate a temp DISTRO_SPECS if it is not existing.

Here is my DISTRO_SPECS (comments and LazY Puppy additions removed):

Code: Select all

DISTRO_NAME='LazY Puppy'
DISTRO_VERSION='300'
DISTRO_MINOR_VERSION=00
DISTRO_BINARY_COMPAT='ubuntu'
DISTRO_FILE_PREFIX='RSHsLP3'
DISTRO_COMPAT_VERSION='lucid'
DISTRO_KERNEL_PET='linux_kernel-2.6.33.2-tickless_smp_patched-L3.pet'
DISTRO_IDSTRING='R300131123060322'
DISTRO_PUPPYSFS='RSHsLP3_300.sfs'
DISTRO_ZDRVSFS='RSHsLP3_Extension.sfs'

and here is the generated temp DISTRO_SPECS (original moved to /root/Desktop):

Code: Select all

DISTRO_NAME='RSHsLP3 Puppy'
DISTRO_FILE_PREFIX='RSHsLP3'
DISTRO_VERSION='300'
DISTRO_PUPPYSFS='RSHsLP3_300.sfs'
DISTRO_ZDRVSFS='zR30026332.sfs'
DISTRO_KERNEL_PET='linux_kernel-2.6.33.2.pet'
DISTRO_IDSTRING='R300131125211432'

This is build by the use of data of /etc/rc.d/PUPSTATE.

I will now build two small SFS Modules just for doing some testings and to keep its download sizes small.

Also I will build squashfs 3 version files for this for doing some testings in older puppies.

The previous one (JWildFire & Java) is now removed.

[mikeb]

Ok....

well I can test pfix=ram if that helps but i assume you want to deal with all the variations that are present in puppy though mine are a bit different I try to keep them as compatible as possible. There are pups from 2.14x through to current in common use so thats a large base to try and cover.. I have a variety up to and including Lucid.

I noticed you did not load sfs to ram ...is that intentional or just for testing?

mike

[RSH]

I noticed you did not load sfs to ram ...is that intentional or just for testing?

Hm, don't know, what you mean.

The SFS Modules are loaded by sfs_load (modified version) in cli mode.

Can you explain a bit more what you do mean and also how you have noticed that the SFS is not loaded to RAM, please?

[mikeb]

Ok well the sfs was saved to a folder modules on sda3 and mounted from there. If loaded to ram I would expect to find it in /initrd/mnt/tmpfs or similar. I only mentioned it as loading to ram was mentioned in earlier posts so wondered if you intended to do so.

mike

[RSH]

Ok.

So, if sda3 is your boot directory then it was intended to be saved in that directory and loaded from there.

If sda3 was the drive that you have had entered into the file download_dir_temp, then it was intended to be saved in that directory and loaded from there.

The RunScript uses this directory in its definitions.

Change these two entries:

Code: Select all

DISPLAYRUNOVERRIDE="Module"
DISPLAYRUNOVERRIDELPBPLOPT="true"

to false and it should download to the boot directory and loaded from there.

Though, I don't know if the SFS will load into RAM after this...

Attached a new Standalone RunScript RoxApp Directory for some testings. I could not test running it when booting from CD. Anything else seems to work - even if there is no DISTRO_SPECS file existing.

EDIT:

I did try to upload a version for SquashFS-3 files, but when trying to download I did get a 403 Error about wrong permissions. Don't know how to fix this for SquashFS-3 version files. So, currently no option to test this for older puppies.

[RSH]

Currently running from CD booting.

Above attached .tar.gz file again updated.

Seems to work fine also when booting from CD.

SFS Modules are now able to unload by right-click-option.

Dependent SFS Module unloads as well.

Over here, so far...

[mikeb]

OK was having too much fun in windows but eventually reset to test in Lucid.

Ok seems like all worked and ran with save loaded.

Main file and dependency downloaded to modules on sda3 (was unmounted for test) ...they ran and gave the messages.
Both items appeared in the menu (under utility) and the right click unload option worked.

mike

[RSH]

OK was having too much fun in windows but eventually reset to test in Lucid.

Please, explain: how was this ---> having too much fun in windows <--- possible?

Ok seems like all worked and ran with save loaded.

Main file and dependency downloaded to modules on sda3 (was unmounted for test) ...they ran and gave the messages.
Both items appeared in the menu (under utility) and the right click unload option worked.

mike

Cool.

Looks like, I'm entering now a point of development where it would be useful to start writing a documentation or at least a quick guide.

[mikeb]

Well a bundle of fun pile of creative and play software.

In this case we have train fever and are making our own layouts with tunnels to make some sort of underground network.
The progarm does actually run quite well in wine but not the editor.

Space exploration, flying, mountain truck driving, rollar coasters.... there's a general escapism theme going on I think
Some nice music software too and video. Generally native is a better deal or the only option.
Actually the oddest one is a windows file recovery program for ext2/3...works really well from those sysinternals guys and a hell of a lot easier than debugfs.

Anyway you went of topic

So are you basically making an sfs handler that appears to the user as a more standard package manager which can access software online or locally with dependancy checking as would be expected..... is that a rough description?

mike

mike

[RSH]

Ok.

Just could not remember me having such fun in Windows like I do in Puppy.

Maybe I should reboot it?

So are you basically making an sfs handler that appears to the user as a more standard package manager which can access software online or locally with dependancy checking as would be expected..... is that a rough description?

I'm not sure, if I do understand you the right way.



- making an sfs handler

Yeah, basically it is an SFS handler - somehow.

But I do see it more in way like a SFS development kit.

It can be used by users just for the use of local SFS Modules - private use/development somehow.

But it can also be used as a complete development kit by developers of Operating Systems to provide a still small OS with lots of additional applications coming as SFS Modules.

Though, SFS Modules have their limitations, but I'm sure -of course- it's the much smarter way to provide additional applications for an OS. Once a SFS Module is build for the OS there is no future hassle like is so much when installing .pet files.

Since the SFS P.L.U.S. can handle conflicting SFS Modules one can use applications that never will work, when installing them. The SFS Modules converted to SFS P.L.U.S. Format doesn't have only option to load dependent SFS Modules automatically. They can also unload conflicting SFS Modules (when loaded) before loading the wanted SFS Module.

The RunScripts -as you have seen- can be provided built in to the OS and also as Standalone RunScript RoxApp Directory.

So, the user could test additional applications by providing those Standalone RunScript RoxApp Directory. From those SFS Modules, the user wants to use and to keep them, the user can create easily RunScripts in batch mode to be included into the OS - then just do a remaster.

Hundreds of Megabytes of Software added by some KB scripts added to the OS.
Usable out of the box, without a save file etc.pp. usw.usf. ... ... ...



- appears to the user as a more standard package manager which can access software online or locally with dependancy checking as would be expected

No, not really a package manager - as it would be meant by the Puppy Package Manager.

Yes, it can and is supposed to access software online and/or locally.

Dependency checking not like the dependency check for installed packages. If there are dependent SFS Modules needed for its main SFS Module, these dependent SFS Modules has to be defined manually when creating the main SFS Module (eg. JWildFire and Java). Such defined dependent SFS Modules are checked, searched, downloaded and loaded automatically.

So, no hassle for a user to search for a needed Java, Python or what ever.

Such dependent SFS Module -of course- can include just some libraries or what ever is needed to run the application and should not appear in the main SFS Module or in the OS. The developer is completely free to set this up as he/she wants - even to put the Java into the JWildFire SFS Module.

I do prefer to create dependent SFS Modules to be loaded automatically, because several SFS Modules might need equal dependent SFS Modules - like Java.

Most of my Java applications have Java 1.7update13 defined as the dependent SFS Module, which is then loaded just once.

---

This SFS P.L.U.S. SFS Development Kit will be provided like RSHs ScriptBox was offered here for some testings: as a RoxApp Application Directory that will prepare the current used OS for the use of this SFS P.L.U.S. SFS Development Kit just by a single click onto the RoxApp Application Directory.

[sunburnt]

I posted a Virtual AppPkg of koulaxizis`s Firefox-23 on his thread at the bottom:

http://www.murga-linux.com/puppy/viewto ... 761#739761

The download size is 250 bytes.! No-install no-union like RoxApps.


# Also posted a wget Xdialog progress download utility:

http://www.murga-linux.com/puppy/viewto ... 768#739768
.

[mikeb]

Ah ok so more for package builders... just wanted to claiify as the thread had strayed quite a bit at one point.

So from a users point of view they simply would get a large range of sfs to choose from with built in dependancy handling and easy user interface.

Shame puppy removed the load without a save ability... means people like you have to write workaround scripts. I had a dead easy time loading the devx to build a modem driver many years ago and wine for that matter just by placing a file on a drive .... even as a noob it was straightforward. But you have to workaround the status quo and I sympathise though from my perspective it all seems a little crazy. Its not what you do I have a problem with its why you are having to do it but anyway back to the plot.

Your system sounds like what the slax 7 dev was aiming at as they had a problem with user built packages conflicting and they were trying to establish some form of regulation to make the pieces fit together properly. The puppy way seems to have been to resort to using someone elses distro repositories which has its own problems and of course not a sfs in sight (unless they used slax packages of course..I have). As mentioned before, puppy packages need to be built for puppy and your work hopefully will help in that direction.

I notice Lucid is being taken up again and their quick pet was always popular... perhaps playdayz and rewin might be interested in what you are doing since to me it might fit in well with thier design philosophy.

regards

Mike