Saluki, Puppy Remastered

Under development: PCMCIA, wireless, etc.
Message
Author
big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#21 Post by big_bass »

Hey Jeff ! (ttuuxxx)
I'm here as long as distro size matters,
as you know I used to maintain a small light derivative
because of the RAM (so even the old clunkers would work )and the standard complex method needed to remove pre installed packages
cleanly was a pain to sort out

and by you sticking to 214 X you see the need for this too

so yes an over all size of the iso is important

the build system and package management that I use allows you to remove pre installed packages and allows for an easy way to build the distro

note all the packages are going to get recompiled anyway whatever base Glib is used but my method dosent depend on woof or unleashed so you dont need to unravel that or modify it

basically just a text list of packages to be used or point it to a folder of packages
and a simple one line command cant get easier than that
thats the automatic way

there is also a GUI for the manual way with check boxes
for me now building with packages is the easier part

the part that takes the time is building all the packages
I have dragNdrop scripts to speed up the process

this is a method not a distro

the kernel makes the OS the packages make the distro
creative people make it happen in real time

Joe

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#22 Post by ttuuxxx »

big_bass wrote:Hey Jeff ! (ttuuxxx)
I'm here as long as distro size matters,
as you know I used to maintain a small light derivative
because of the RAM (so even the old clunkers would work )and the standard complex method needed to remove pre installed packages
cleanly was a pain to sort out

and by you sticking to 214 X you see the need for this too

so yes an over all size of the iso is important

the build system and package management that I use allows you to remove pre installed packages and allows for an easy way to build the distro

note all the packages are going to get recompiled anyway whatever base Glib is used but my method dosent depend on woof or unleashed so you dont need to unravel that or modify it

basically just a text list of packages to be used or point it to a folder of packages
and a simple one line command cant get easier than that
thats the automatic way

there is also a GUI for the manual way with check boxes
for me now building with packages is the easier part

the part that takes the time is building all the packages
I have dragNdrop scripts to speed up the process

this is a method not a distro

the kernel makes the OS the packages make the distro
creative people make it happen in real time

Joe
Hi Joe I like the sound of that, I'll look into it this week. We both kind of think alike when it comes to overall picture. I guess I have some reading to do. Thanks for the info/link :)
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#23 Post by technosaurus »

I've been working with goingnuts to develop Pup'nGo lately

Is there opposition to:
using a gcc-4.5.1 based devx derived from aboriginal
building a minimal base (see Pup'nGo) to remaster from, using a woof supported distro (including a from scratch repository...)
switch to tar.xz based packages (xz and lzma are now in busybox)
I think we have a lot of aquired knowledge of things like "the last version of libXYZ that didn't depend on libABC" or have a patch that removes said dependencies, so I am fine with not necessarily using the latest packages (Pango-1.24.5 for instance is better than more recent versions that pull in libstdc++)

oh and since autotools and waf are so pitiful we should probably build it in stages - adding dependencies one at a time. Start with only gtk2 and add dependencies only when the configure script begs for them and even after a hack it still won't build
So ncurses ./configure has --without-cxx-binding but never tests either "is g++ installed on the host" or "does the host cc support c++". So it runs 8 gazillion probes, none of which is "disable c++ support", even though it has an option to do so manually.

Meanwhile, the distcc autoconf probes for python (and won't build python extensions if it's not in the $PATH), but does _not_ have any command line way to --disable-python. Because consistent behavior out of autoconf is anathema.


some significant events that come to mind since 4.X:
  • Rob Landley's 1.0 recently releaseed aboriginal linux (formerly firmware linux)
    - good base for both rebuilding busybox etc... against static uclibc and for cross compiling with gnulibc in qemu
    gnash-0.8.8 finally came out last week - looks promising
    size of libflashplayer has nearly doubled in size and dependencies,
    however adobe now offers restricted access to flash-lite source
    pango switched to using C++ for freetype after 1.24.X (pulls in libstdc++)
    gtk2-2.20 added gobject-introspection requirement
    gtk2-2.22 will use cairo only as backend and separate gdk-pixbuf again (as it is in gtk-1.x)
    firefox/seamonkey now support using more system libs
    webkitgtk and chromium are now competitors to gecko and opera has some new stuff too
    xserver has added libpciacess as dependency
    Our community has patched many gnome dependent apps for gtk2 only
    Zigbert has pushed the envelope of gtkdialog
    Slitaz arrived on scene @30MB also utilizing some gtkdialog tricks
    goingnuts -hacked the puppy desktop down to <8mb iso
    after 4 years, vala is nearing a 1.0 release
    gtk3 is "coming soon"
    gcc has added whole program optimization using objects
    pcmanfm2 is doing well & could surpass Rox-filer
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#24 Post by big_bass »

as for the name Puppy 6
hmmm
being straight forward and open
I dont think that what I am doing lends itself to fit in with current development
as to be compatible with anything you could build with woof
or label puppy 6

so what does that mean ?



what is my goal is to build a distro

I thought about this long and hard and decided that going back to some
standard linux way with packages and a package management tool

would be understood by others that have built distros from packages
such as slackware, , arch , debian and others

more or less is can it be built another way?
and the answer is yes

is that the best answer for puppy ?
I dont think so but it works for me

and I have learned more going that path
without so called going with the flow


even a dead fish can float on down the river
but it takes a live fish to swim up stream


I do want to build from scratch is anyone else thinking about that?
it would be fun
something all contained in packages that I can or anyone else can keep updated
with just basic linux knowledge

*TXZ shows what has been done not in theory but in practice
there is still a long way to go but Im getting closer
and having fun in the process

Joe

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#25 Post by ttuuxxx »

big_bass wrote:as for the name Puppy 6
hmmm
being straight forward and open

I do want to build from scratch is anyone else thinking about that?
it would be fun
something all contained in packages that I can or anyone else can keep updated
with just basic linux knowledge

Joe
I'm willing to lend a hand to build from scratch. Any Idea where to start?
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#26 Post by Lobster »

Ttuuxxx

This is a good beginning
the smallest

Pup'nGo

Try that. Release an ISO and devx
see if it works
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
8-bit
Posts: 3406
Joined: Wed 04 Apr 2007, 03:37
Location: Oregon

#27 Post by 8-bit »

Lobster wrote:Ttuuxxx

This is a good beginning
the smallest

Pup'nGo

Try that. Release an ISO and devx
see if it works
What I would like to see is something like Pup'nGO that had an automatic network setup so as to be able to download the packages to install or install them on the fiy after a download.
Then add an automatic remaster that one could automatically make an ISO that contained the packages one wanted in a personalized ISO with option to burn it.
I have tried using the Remaster that is included with Puppy and the last one that worked for me was an early offering by Dougal.
The current one has me jumping through hoops trying to get it to make a remastered ISO containing all installed packages.

What I really do not want to see is a rash of remastered ISO's based on Puppy 6 being offered for download.
That is to say one where someone prefers one web browser over another or one audio/video player over another and calls it a new version to share.
We have a very large litter of Puppys already.

The main thing here is that the initrd.gz and vmlinuz files would stay the same in the remasters and only the pup6.sfs file would get modified with inclusion of the added packages.
That means any configuration files that would be specific to a users PC would be left out of the remaster.

My 2 cents worth....

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#28 Post by Iguleder »

Already started my own "from scratch" build. Still missing some things, like burning utilities and wireless stuff.

Got a full base already, atm it boots with my good ol' 2.6.33.4 with BFS and lots of fun performance patches, still need to compile 2.6.35.4 for it. All compiled manually with march=i486 and mtune=i686, O2 for all packages except O3 for compression and archiving stuff, plus OpenSSL.

These packages are 80% of the devx and most "core" stuff, plus my favorite console applications. The real pain is getting X to work. I'll try to compile X and things like GTK maybe ... it's the second time I attempt to do that manually.

The minimum kernel it supports is 2.6.32, glibc is compiled against the 2.6.32.21-libre1 headers. Very small ... libc-2.12.1.so is 1.7 MB compared to about 9 MB with GCC 4.4.4 and glibc 2.11.2, my previous build. That's before stripping.

I'm working on my own distro, so even if nobody needs this, I have a use for it ... I'm also building a tool that builds my distro from Ubuntu packages instead of my home-made ones :wink:
alsa_lib-1.0.23
alsa_plugins-1.0.23
alsa_utils-1.0.23
aria2-1.10.2
aspell-0.60.6
aspell_en-6.0
autoconf-2.67
automake-1.11.1
bash-4.1.007
binutils-2.20.1
bison-2.4.3
busybox-1.17.2
bzip2-1.0.5
calcurse-2.8
centerim-4.22.9
clex-4.5
coreutils-8.5
curl-7.21.1
diffutils-3.0
e2fsprogs-1.41.12
elinks-0.11.7
expat-2.0.1
file-5.04
findutils-4.4.2
flac-1.2.1
flex-2.5.35
gawk-3.1.8
gcc-4.5.1
gdbm-1.8.3
gettext-0.18.1.1
glibc-2.12.1
gmp-5.0.1
gnutls-2.8.6
grep-2.6.3
groff-1.20.1
grub-1.98
gzip-1.4
htop-0.8.3
iana_etc-2.30
inetutils-1.8
iproute2-2.6.35
kbd-1.15.2
kernel_headers-2.6.32.21-libre1
less-436
lftp-4.0.10
libgcrypt-1.4.6
libgpg_error-1.9
libid3tag-0.15.1b
libmad-0.15.1b
libogg-1.2.0
libsamplerate-0.1.7
libsigc++-2.2.8
libsndfile-1.0.21
libtasn1-2.7
libtool-2.2.10
libtorrent-0.12.6
libvorbis-1.3.1
libxml2-2.7.7
lynx-2.8.7
m4-1.4.15
make-3.82
man_db-2.5.7
man_pages-3.26
moc-2.4.4
module_init_tools-3.12
mpc-0.8.2
mpfr-3.0.0
nano-2.2.5
ncurses-5.7
openssl-1.0.0a
patch-2.6.1
perl-5.12.1
pkg_config-0.25
procps-3.2.8
psmisc-22.12
python-2.7
readline-6.1.002
rtorrent-0.8.6
screen-4.0.3
sed-4.2.1
speex-1.2rc1
squashfs_tools-4.0
tar-1.23
texinfo-4.13a
udev-162
util_linux_ng-2.18
vim-7.3.3
weechat-0.3.3
wget-1.12
xz-4.999.9beta
zlib-1.2.5
I can upload this thing ... anyone interested? It's not that big ... my previous build was about 650 MB uncompressed, but after stripping and mksquashfs'ation it was around 150 MB :P

Maybe I'll upload an alpha image of my distro, can be useful to build a base Puppy with LFS or something, once we have the right packages we can lie to Woof these are raw T2 packages, should work.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#29 Post by ttuuxxx »

Iguleder wrote:Already started my own "from scratch" build. mksquashfs'ation it was around 150 MB :P
That's a nice start but, It should be around 110-120MB, 150MB is too large for a default pre-alpha
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#30 Post by Aitch »

8 bit

Sounds a bit like my request for a network booting option in grub, in new puppies

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

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

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

If anyone can get it to run on Arm, PowerPC or PS3 and do clustering, so much the better :wink: :lol:

Edit: Note Arm Kernel Kautobuild http://armlinux.simtec.co.uk/kautobuild/

http://www.denx.de/wiki/U-Boot/WebHome

http://www.embeddedarm.com/software/arm ... loader.php

http://www.linux-arm.org/LinuxBootLoader/WebHome

Anyone getting close?

Aitch :)
Last edited by Aitch on Wed 08 Sep 2010, 13:26, edited 1 time in total.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#31 Post by Iguleder »

ttuuxxx wrote: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 :lol:

Gonna create those device nodes ... should work :)
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#32 Post by jemimah »

Aitch wrote: 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?

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#33 Post by jemimah »

Iguleder wrote: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 :lol:
Try a cpio archive - I think that should work.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#34 Post by 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)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#35 Post by technosaurus »

jemimah wrote: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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#36 Post by 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 :)

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#37 Post by 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)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#38 Post by jemimah »

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

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#39 Post by 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

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#40 Post by 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
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

Post Reply