Puppy Linux Discussion Forum

[Iguleder]

[jemimah]

[jemimah]

[technosaurus]

I for one would rather start with a clean base and properly optimize compiles and choose optional dependencies from the onset.

Here are 7 basic points that I think matter during planning:

1.
For the initial first pass run I would recommend compiling with no optional dependencies selected, and here is my reasoning:
autotools and waf will use pkg-config to select which packages to link against
pkg-config spits out every library that the probed library was linked with
extra unnecessary packages will be linked and show up as a dependency even if not used
the --as-needed flag usually mitigates this as far as run time but not always work and it will still fail to start if the lib doesn't exist
but if you compile a binary against a minimal library and then go back and recompile the library with more features it will typically still work with either version of the library

2.
Certain libraries are almost never linked directly and are just needed as a dependency - these should be compiled directly in for better size and speed... for instance libXau and libXdmcp are needed for libX11, but I have only found one program that needed anything in them that wasn't required by libX11 and static linking it didn't noticably increase the binary size.

3.
Some programs use large libraries with many dependencies to do just one or two things that can be closely mimicked in other ways <should I post a wiki entry?>. Furthermore dependencies tend to creep into projects that were formerly lean for a number of reasons that one could write an entire PhD dissertation about. We have a large collection of knowledge on this subject and have identified many projects down to the minor version or specific commit and/or patched the existing tree. Yad/zenity, pango, Xorg-7.3+ and glipper-lite come to mind.

4.
The linker is smarter than we are (but auto**** is not). Really ... replace an occurence of `pkg-config --libs gtk-x11-2.0` (which spits out about 10 libs and lib locations multiple times in succession) with simply -lgtk-x11-2.0. The build will likely be smaller and load faster. This is one reason many puppy sources contain their own custom build scripts.

5.
Sometimes bigger is smaller. For example if you have 10 daemons running in the background that call sleep from busybox, it will load the entire busybox binary and take over 1Mb of RAM per daemon, whereas if you add an additional static copy of sleep, you can save 10+Mb of RAM and another 10Mb or so if it can run using a small static dash. This goes for pretty much any daemonized process such as cupsd, udevd, inotify* .
The ram and startup time savings far outweigh the minimal added binary size.

6.
-Os, -O2 and -O3 are only a small percentage of compiler/linker optimizations. See the pet packaging 100/101 link in my signature for more details, but my point is that only using standard flags can cost up to 50% size and significant performance.

7.
The second pass builds should be compared to the first pass for size and dependencies as an 1D10T check to see if anything creeped in unwantedly (some circular dependent packages will grow intentionally? for instance cairo's svg backend needs rsvg which depends on cairo)

[technosaurus]

[Aitch]

Techno

I think jrb's linker uses TCs code already, and does TCZ and SFS linking

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

[In case you missed it]

I certainly favour Puppy's own dev code to TCs

A new small fast puppy, that'll allow package [and driver?] customising and update would really be something IMO

Network boot and mesh networking would be pure luxury bonus

Also see coreboot http://www.murga-linux.com/puppy/viewtopic.php?t=59515

Aitch

[technosaurus]

I don't want to forget license compliance. Here is a useful guide that addresses some of the concerns that we may face (tracking changes, avoiding the "build guru")

http://www.softwarefreedom.org/resources/2008/compliance-guide.html

I like the idea of separating the source tree by license.

@Aitch - jrb had the sfs linker working before TC switched to the .tcz format, but he added it after I posted some converted tcz files as sfs, so that the packages could stay up to date. The last remaining problem I can think of with it is symlinking of symlinks where the actual file being linked to is not in the sfs/tcz but is expected to be in the main sfs (these just need to be copied - the .so file symlinks in the devx for example)

[jemimah]

Well I'm in for Technosaurus' plan if we can figure out a way to delegate tasks.

[big_bass]

[Lobster]

Puppy testers and developers are straining at the leash . . .

Whoever provides a minimal iso and devx to remaster from will have started something . . .

I will add the download location here

http://puppylinux.org/wikka/Puppy6

[technosaurus]

I wanted to start off with the latest version of busybox with all patches - I finally figured out how to add an applet properly so I added a small mp3 player to test it out. Compiled against glibc for now -- spent too much time figuring out how to busybox an applet.

[Iguleder]

Here's my SFS linker, from my own distro. Just read the code ... it's very easy to understand. I use it with 100+ SFS extensions.

It's very very easy to implement something similar for Puppy ... just a script that checks how many SFSs you have, if you have more than 8 it uses linking instead of layers.

btw: this WILL ruin your system, Puppy is not supposed to do things this way. Don't use it unless you know what you're doing.

(a gzipped Bash script)

[bigpup]

I see a need to make two versions.
One with the latest kernel and bleeding edge programs for newer computers. Multicore, high end video cards, etc.
One for old computers that do not seem to be supported by the newer kernel's.
Several times, people trying to use Lucid Puppy 5.1.1 on older hardware, are finding they need to go back to older version of Puppy to get them to work.

[big_bass]

technosaurus

[Aitch]

I would agree with bigpup

Does anyone else notice there were 'milestone' versions of stable/working Puppy, e.g. 1.09, 2.14R1.01, NOP, 4.12, 4.31 ....

Even ttuuxxx's 2.14X doesn't run on some old hardware that 214R101 [my fallback] runs on, and look at the work he's put into that!

We need a new milestone, and I feel it spawning

Aitch