(old)Puppy Linux Discussion Forum

Here is my basic overview of the plan I have come up with.

Start a very minimal desktop that is Lenny compatible... try to get it down to about 5-10MB using Kernel 2.6.29+, busybox, minimal X, JWM

Use parts of Barry's woof scripts to build sfs modules for each package (or set of packages). Up to 255 are supported now (Certain packages will need a small modification that I will explain in a minute)

For programs with executables we would need to set up a small script that mounts its sfs and any dependencies, then executes the program. This can be done by giving the mount/run script the same name as the executable, but putting it in the lowest level of the "PATH" so that it is only mounted on first run. (If we wanted to get really inventive with resources we could even unmount the sfs when the program closes, but this may cause problems with shared library sfs when multiple programs are running that require it)

For packages without executables (libraries, docs...) we would simply need to add a script with the same name as its loader script to the sfs that does nothing, but is higher in the hierachy of "PATH"

I would recommend shifting the order of execution of many things to background after jwm (in XVESA) is loaded and use an sfs module that contains xorg to mount and run the xorg wizard from the desktop if one so chooses.

Much of the sfs loading could be integrated into a build script that would make basic assumptions based on the package name ... lib* *DEV, *DOC and *NLS would get the non executable treatment and others would assume that the base package name was the same as the executable (for building the sfs and mount script) and each mount script would be based on dependencies.

A compromise alternative would be to have an extra couple of sfs files that would make up the traditional default puppy packages that would be loaded after JWM. Then use the build scripts to make sfs modules other packages and dependencies not contained in the default sfs modules after referencing a "packages.list" type of file to exclude already installed packages.

This would give us the boot speed of TCL, the package base of Debian (or Slackware, Ubuntu or Arch), the flexibility of woof, the modularity of Puppy and expandability of SLAX

This is just a rough idea at the moment. I am undecided on doing each package as a module (maybe 255 is not enough)

Hi Techno

Sounds cool

I sometimes wonder if my brain has a few less connections than yours

You seem to consistently come up with some very imaginative projects

How long before we see a totally independent, TechnoOS, I wonder?

Good luck with it....

Aitch

also on the drawing board is to bring back the zdrv.sfs and come up with a script that will cut down the zdrv to only include the modules needed by the user's hardware (Mandriva started doing this in 2009.0) If memory serves me correctly Barry played around with this in 4.1 development

Sounds a flexible build, which I like very much.

As far as I can tell, the problem with zdrv.sfs is that it has to be mounted before use, and this imposes limitations. What is not yet done is a script to remove unneeded drivers from pup.sfs.

I've already started on a version a few days back using woof and debian, My idea is make a min version and build a regular puppy non-debian around it, I don't like the extra libs etc, I fine the new package manager unstable, its crashed a few times, etc. I'll just rip apart a pet package manager in 4 series maybe 3, remove the repo parts, and have it so it installs, uninstalls, checks/rechecks for missing libs and thats about it. Packages I can compile and advertise in the forum, most don't use the repo much because puppy comes this 70% of it anyways.
ttuuxxx

If this is a dumb idea, please just say so, I won't feel insulted. What if apps were compiled statically? One could have a completely self-contained gimp.sfs, firefox.sfs, openoffice.sfs (now that's a scary one), etc...

Its not dumb at all - I have been playing with static builds quite a bit lately. I am compiling a lot of things static these days - especially those stubborn packages that have dependencies that almost nothing else requires. It actually decreases the total size when you dont have to include the shared libraries. For other programs though that use pretty standard/common libraries its better to compile shared.

Update: ... been thinking about static builds and woof... if we did a static build of the basic X + jwm using uclibc we could also use the woof scripts to download a package and all of its dependencies into a single sfs so that extra packages would include all dependencies and could therefore be from a variety of supported distros

other distro of interest is gobo linux where each package goes in its own package directory and uses symlinks to /usr/... etc

Hey techno,
Im actually building somethign similiar, but still am learning along the way. If you have the commitment, im looking for a core group to work with. This is not exactly what you talked about, but more. I've made mention to barry and others about the endeavor, but have not had any serious commitments to help, this is not puppy, nor woof, nor anything else out there actually. (although Many aspects of BarryK and others within the linux community's work will be included...and recognized to the best of my and my teams abilty.)

Your suggestion is one facet of a much larger project im now working on. Let me know if you might feel fearless.

technosaurus,

i posted about a project called PdaXrom-ng
http://wiki.pdaxrom.org/index.php/Main_Page

http://www.murga-linux.com/puppy/viewtopic.php?t=41365

i believe it uses uclibc and is ported to x86, ppc, pcc 64, arm, mips. and is a 60meg distro, based on debain. might help get puppy/woof on different architectures, and still keep it lightweight. might be worth looking at.

Fix

Thanks for the link, have posted it here, for Puppy's PPC developer, Powerpup

http://murga-linux.com/puppy/viewtopic.php?p=300395

Techno, [or ttuuxxx, anyone else?] powerpup needs help with static builds, if you can give any tips?

Thanks

Aitch

ooops this one is old but the text is as if from the future. This still is a good thing is it not?

original thread Posted: Thu 30 Apr 2009

nooby wrote:This still is a good thing is it not?

I thought so, nooby, and hoped it might be part of techno's input to saluki or 5.3 or whatever

however the attention seems to be in egos at the moment, with puppyite/bernie and jonyo vying for the title....'most posts with no real substance for puppy's future'

glad you gave it a bump, nooby

techno....?

Aitch

might consider keeping your inane thoughts to yourself
substance? gimme a break

Aitch wrote:

nooby wrote:This still is a good thing is it not?

I thought so, nooby, and hoped it might be part of techno's input to saluki or 5.3 or whatever

however the attention seems to be in egos at the moment, with puppyite/bernie and jonyo vying for the title....'most posts with no real substance for puppy's future'

glad you gave it a bump, nooby

techno....?

Aitch

So I'll bump it again.
Puppy -- a light weight user-friendly distro, having security because its "core" functions are initiated from a compressed file, --compromised SaveFile: delete it and create another in 5 minutes or less-- that will boot from any medium, CD, DVD, USB-Key, SD Card. In short, having a combination of advantages like no other distro.
Add Amigo's recommendation that it be a T2 Build and/or that packages be built using his Src2pkg http://www.murga-linux.com/puppy/viewtopic.php?t=64337 Add my recommendation that its included apps be limited to a few apps everyone needs for daily use, such as Abiword with spell check and thesaurus, a text editor, mtpaintsnapshot or equivalent, a "Quick Pet Routine" to install the user's choice of web-browser, and PPM to download pets, SFSes and compressed "Program Folders.".. All other applications are Static Build SFS, loaded or unloaded as wanted and needed; or static built "Program Folders" --therefore portables-- whose necessary libs, and the cache they use are outside the SaveFile, brought into "play" via pets which just install into the SaveFile the necessary symlinks, scripts, icons and desktop files needed for menu entries..
The apps from other distros -- only when retro-fitting them for Puppy is easier than building them via Src2pkg. Ideas from other distros: anytime.

mikesLr

Mike that sounds good to me. I use SFS-Exec made by seaside, it still lack some error checking or needs to lack them to say fast. Anyway works superfast and easy to use loading sfs and then unloading them on the fly and no waiting at all and no rebooting or anything. So handy.

So hope that Techno still consider this idea of his.

Thanks Aitch.

i had made a similar program based loosely on jrb's sfs linker ... basically it parsed the .desktop files on the sfs and executed the Exec= line or brought up a menu in the case of multiple .desktop files on an sfs ... last I recall there was an error for ayttm due to having unnecessary quotes

technosaurus wrote:i had made a similar program based loosely on jrb's sfs linker ... basically it parsed the .desktop files on the sfs and executed the Exec= line or brought up a menu in the case of multiple .desktop files on an sfs ... last I recall there was an error for ayttm due to having unnecessary quotes

I'll throw a few strange ideas in here just to add to the confusion:

****
It would be nice if the ISO image could have multiple kernel versions and sfs files that contained drivers for all sorts of hardware and a whole lot of stuff like that. As it boots, it could select the version that is intended for this sort of machine.

****

It would make some sense to split the save file into more than one part. The automatically selected stuff should be kept in a list so that during the first shutdown, the user can be asked about only saving just what is needed for this machine onto the hard disk or saving all the sfs files etc.

****

I have made open office work by having it actually live on a memory stick and using ln -s commands to like to it. This means it would not be compressed. We could instead mount a compressed version via a loopback and then make the links. This would allow OO to only really use up the space of the links.

When you want to run OO, it would be a script that does the links etc and then runs the main body of it.

As long as the kernel, initramfs and zdrv match it isn't a problem ...in other words the pup*.sfs can be independent