Saluki, Puppy Remastered

[Iguleder]

That's a nice start but, It should be around 110-120MB, 150MB is too large for a default pre-alpha
ttuuxxx

I guess you haven't read the whole message. This is 90% of the core stuff, including the stuff that go to the devx, with locales and everything. Most of these files belong to the devx ... I guess I could produce a 30-40 MB ISO from just the applications and the libraries.

At the moment I'm trying to produce a working alpha ISO of my distro with these ... it had a severe bug with udev, I found out it's impossible to put device nodes in a tar archive to move them between computers ... I took a look at /dev and it seems it's empty

Gonna create those device nodes ... should work

[jemimah]

Devs, any interest?.....Puppy from scratch/Pup'n'Go + network download to self construct a Pup for your own hardware.....nice n fast/small ....add what you want by SFS using sfs linker, or similar

It's called TinyCore. Why reinvent the wheel?

[jemimah]

I found out it's impossible to put device nodes in a tar archive to move them between computers ... I took a look at /dev and it seems it's empty

Try a cpio archive - I think that should work.

[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]

It's called TinyCore. Why reinvent the wheel?

I had considered the same thing but:
A. I prefer running as root since my OS is usually in RAM anyways.
B. Their forum and package policies are a pain.
C. No unionfs/aufs (but they do a fair job of working around it)
D. Its fairly polluted with "ugly" fltk and imlib programs (microcore is a bit better)

On the other hand I have used their tcz packages (same as sfs v4) to supplement packages that aren't in ppm, and I see no reason why we shouldn't borrow their tcz linker code to use for sfs linking, maybe some other goodies too. Microcore could still be a base I guess, some kind of blend between it and Pup'nGo.

[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/resource ... 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]

(tracking changes, avoiding the "build guru")

thats the main reason I chose pkgtools to be the package management
to build a distro the binaries could be compiled for any source


since slackwares package manager is the oldest around
and most used ,understood and tested and plain easy to use

one large advantage is no automatic dependency resolving
which will bloat and break the system

I did a re write of the front end of pkgtools to allow dependency checking on all of the pre installed packages or any new package installed (it also works in X since I re wrote it in Xdialog)

since people always complain about dependency checking
that no longer is an issue

this removes the guru only one person that understands how to build remove and install packages cleanly

because it was well documented long before I ever used it


I really agree to following linux standards as close as possible
whenever possible to keep things transparent to all

later you just point people to a website that has packages
that were tested to work

the advantage here is no built in hardcoded
package site info it is dynamic and can be quickly updated and modified in minutes


I believe some compromises are expected to gain the agreement of a team
as far as what Glibc to use and which kernel will be used
this can be a start point of who agrees
other kernels could be compiled later


one example is I used the 2.6.27.7 kernel because of the lzm and aufs and squashfs patches
were specially made for that kernel

*since a using a live cd requires a more careful selection of the kernel



Joe

[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

I wanted to start off with the latest version of busybox with all patches

I do agree that having a correctly configured busybox is needed

@technosaurus I will welcome all your apps if you provide sources or links
to the configure options used there are just a few of us that plan to build
we have to start out well documented and have the ability to repeat the final outcome of any app compiled from the get go


I am a bit uncomfortable thinking about adding a CLI mp3 player code to the first 2800 lines to an app as critical as busybox ( I tend to be a bit conservative with things nothing personal )



that may be needed for some micro embedded system
but not required for a light weight fully functional distro
since most people will use VLC,Mplayer,gxine ,Xmmms ,xhippo and others

**thanks in advance for posting the sources / config options
hmm that gave me a thought could we have another thread for packages
offered to the source build it would be much easier to locate stuff as we go
all in one place

Joe

[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

[big_bass]

Iguleder

I just noticed today that you have an interest in package management
you wrote code for a thingy manager interesting

I spent a lot of time writing a GUI front end to slackwares pkgtools
and it is 100% compatible on the official slackware or on TXZ pup
called slaxer_pkg_tools2.2
http://pastebin.com/kYUcMhSx


Joe

[jemimah]

How old of a computer is it reasonable to try to support? At what point do we give up on older hardware?

[Aitch]

LOL Good call, jemimah

However it's not the failure rate on a lot of my old hardware that bothers me....it's the electricity bill!

Old scsi server boxes run wonderfully but you can almost cook on 'em, they need loadsa room, and damn, they're noisy

Anyone know what happened to Ted dog and his T2 cross compile efforts?

Anyone get a VIA 8505/Eken M001 iPad clone running puppy?....Android's running away with it, atm

They'd be a bit more economical, I suppose....and they're less than $100

http://www.alibaba.com/trade/search?Sea ... t_en&fsb=y

Aitch

[technosaurus]

@bigbass
I compiled busybox to include the config options. Just run

Code: Select all

bbconfig >my_dot_config

The patch to add minimp3 is already attached in my previous post (and I posted the patch to the busybox mail list)

I understand your point about people using full media players, but I think that at least during development, it is a good idea to have a method of testing that all your piece/parts work including sound, especially if we are going to have a minimal base install. (I do have a separate build of minimp3 though and it is only ~31kb) It would suck to be weeks/months into development and figure out that sound was broken. I'm not 100% sure, but I think that the busybox beep applet uses the pc speaker, so it wouldn't be a good test.

Re:pkgtools - do you have a good reference for putting the build info in the proper format ... and does it work with Amigo's src2pkg?

[dejan555]

Puppy from scratch sounds good. I support that.
If you go that way I will surely join testing.