The time now is Mon 18 Jan 2021, 12:48
All times are UTC - 4 |
Author |
Message |
Iguleder

Joined: 11 Aug 2009 Posts: 2031 Location: Israel, somewhere in the beautiful desert
|
Posted: Wed 08 Sep 2010, 09:02 Post subject:
|
|
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
Gonna create those device nodes ... should work
_________________ My homepage
My GitHub profile
|
Back to top
|
|
 |
jemimah

Joined: 26 Aug 2009 Posts: 4309 Location: Tampa, FL
|
Posted: Wed 08 Sep 2010, 09:30 Post subject:
|
|
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?
|
Back to top
|
|
 |
jemimah

Joined: 26 Aug 2009 Posts: 4309 Location: Tampa, FL
|
Posted: Wed 08 Sep 2010, 09:34 Post subject:
|
|
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
|
Try a cpio archive - I think that should work.
|
Back to top
|
|
 |
technosaurus

Joined: 18 May 2008 Posts: 4878 Location: Blue Springs, MO
|
Posted: Wed 08 Sep 2010, 11:14 Post subject:
|
|
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 github repositories. I may eventually get around to updating my blogspot.
|
Back to top
|
|
 |
technosaurus

Joined: 18 May 2008 Posts: 4878 Location: Blue Springs, MO
|
Posted: Wed 08 Sep 2010, 11:37 Post subject:
|
|
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 github repositories. I may eventually get around to updating my blogspot.
|
Back to top
|
|
 |
Aitch

Joined: 04 Apr 2007 Posts: 6815 Location: Chatham, Kent, UK
|
Posted: Wed 08 Sep 2010, 12:21 Post subject:
|
|
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
|
Back to top
|
|
 |
technosaurus

Joined: 18 May 2008 Posts: 4878 Location: Blue Springs, MO
|
Posted: Wed 08 Sep 2010, 15:10 Post subject:
|
|
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)
_________________ Check out my github repositories. I may eventually get around to updating my blogspot.
|
Back to top
|
|
 |
jemimah

Joined: 26 Aug 2009 Posts: 4309 Location: Tampa, FL
|
Posted: Wed 08 Sep 2010, 15:36 Post subject:
|
|
Well I'm in for Technosaurus' plan if we can figure out a way to delegate tasks.
|
Back to top
|
|
 |
big_bass
Joined: 13 Aug 2007 Posts: 1742
|
Posted: Wed 08 Sep 2010, 22:24 Post subject:
|
|
Quote: | (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
|
Back to top
|
|
 |
Lobster
Official Crustacean

Joined: 04 May 2005 Posts: 15588 Location: Paradox Realm
|
Posted: Wed 08 Sep 2010, 23:45 Post subject:
|
|
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.2 Final
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html 
|
Back to top
|
|
 |
technosaurus

Joined: 18 May 2008 Posts: 4878 Location: Blue Springs, MO
|
Posted: Thu 09 Sep 2010, 02:42 Post subject:
|
|
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.
Description |
|

Download |
Filename |
busybox-1.17.2-minimp3.patch.gz |
Filesize |
21.96 KB |
Downloaded |
816 Time(s) |
_________________ Check out my github repositories. I may eventually get around to updating my blogspot.
|
Back to top
|
|
 |
Iguleder

Joined: 11 Aug 2009 Posts: 2031 Location: Israel, somewhere in the beautiful desert
|
Posted: Thu 09 Sep 2010, 03:58 Post subject:
|
|
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)
Description |
|

Download |
Filename |
loadsfs.gz |
Filesize |
935 Bytes |
Downloaded |
778 Time(s) |
_________________ My homepage
My GitHub profile
|
Back to top
|
|
 |
bigpup

Joined: 11 Oct 2009 Posts: 13981 Location: S.C. USA
|
Posted: Thu 09 Sep 2010, 09:22 Post subject:
|
|
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.
|
Back to top
|
|
 |
big_bass
Joined: 13 Aug 2007 Posts: 1742
|
Posted: Thu 09 Sep 2010, 09:54 Post subject:
|
|
technosaurus
Quote: | 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
Last edited by big_bass on Thu 09 Sep 2010, 10:02; edited 1 time in total
|
Back to top
|
|
 |
Aitch

Joined: 04 Apr 2007 Posts: 6815 Location: Chatham, Kent, UK
|
Posted: Thu 09 Sep 2010, 10:00 Post subject:
|
|
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
|
Back to top
|
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|