On 4/21/06, Jim Gifford [EMAIL PROTECTED] wrote:
In CLFS, we create all the users and groups, this will solve all issues
if LFS will follow. It will also simplify the BLFS instructions to
adding users to the appropriate groups. It's a plus for all, eliminates
so of tedious work the BLFS has to
Joshua Murphy wrote:
Finally, from personal experience, I can say that most people who come
to LFS don't do it to have a small, clean, fast, and stable system
(which is part of what they get), but instead go through the book,
doing the build, to understand how and why it works, something you can
Jeremy Huntwork wrote:
Give them the basics, show them how to extend, warn about possible
pitfalls and provide an example. Doing this we're not leaving them with
a half-baked system, as some have said already - we're teaching them how
to complete the system themselves which is what LFS has
Hi
I made some changes to jhalfs to do more accurate disk usage and build time
measurements. Due that into the editor's guide there is no mention (yet)
about how to do that measurements, I implemented the next approach:
Disk usage is made in to steeps, a first du -skx $LFS before to unpack
On 4/24/06, M.Canales.es [EMAIL PROTECTED] wrote:
That should to work. But comparing the values obtained from my last jhalfs
build with the current ones in the book, the differences are abismal in some
cases. For example, for GCC-pass1 in the book we have:
Approximate build time: 4.4 SBU
M.Canales.es wrote these words on 04/24/06 14:40 CST:
Disk usage is made in to steeps, a first du -skx $LFS before to unpack the
package, and a second du -skx $LFS before to delete the sources and build
dirs (excluding in both cases the jhalfs dir to not measure build log files).
Sounds
El Lunes, 24 de Abril de 2006 22:03, Dan Nicholson escribió:
Approximate build time: 8 SBU
I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
Well, my time values can be smallest than yours due that I'm using an
HiperThreading enabled Intel CPU.
What I can't undestart
Dan Nicholson wrote these words on 04/24/06 15:03 CST:
On 4/24/06, M.Canales.es [EMAIL PROTECTED] wrote:
Approximate build time: 8 SBU
I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
And I'm smack dab in the middle between y'all.
[EMAIL PROTECTED]:
On 4/24/06, M.Canales.es [EMAIL PROTECTED] wrote:
El Lunes, 24 de Abril de 2006 22:03, Dan Nicholson escribió:
Approximate build time: 8 SBU
I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
Well, my time values can be smallest than yours due that I'm using an
Randy McMurchy wrote these words on 04/24/06 15:17 CST:
And I'm smack dab in the middle between y'all.
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 cat sbu.time
8.64 SBU
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 cat elapsed.time
real24m40.135s
user
Joshua Murphy wrote these words on 04/24/06 15:24 CST:
theoretically, be
within 3-4 of each other (between systems) at the worst.
In my opinion, it is much closer than that. Consistently. I'm at
less than 1 SBU difference between an Athlon 2400+ with 768mb RAM
and a 500mhz P3 with only 256mb.
El Lunes, 24 de Abril de 2006 22:10, Randy McMurchy escribió:
unpack additional packages (like libidn, bash-doc or vim-languages)
To me, this skews things badly. We've never ever counted unpacking
source tarballs before.
[EMAIL PROTECTED]:~/sources$ time { tar -xjf
El Lunes, 24 de Abril de 2006 22:25, Randy McMurchy escribió:
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 cat sbu.time
8.64 SBU
And on my doggy 500mhz P3, just recently built (20060322):
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.3-Pass1 cat sbu.time
9.38 SBU
M.Canales.es wrote these words on 04/24/06 15:32 CST:
Not so badly. From your other post I think that the hardware used to do the
builds has a bigger impact in the final values than the unpack of that small
packages ;-)
Good point. But I tend to think BLFS.
Now do the same thing for the
Randy McMurchy wrote these words on 04/22/06 12:45 CST:
We have GCC-3.3.6 in the book. This would probably be adequate, but
I'm wondering if we shouldn't add GCC-3.4.6 to the book,
I just couldn't get excited about adding another version of GCC to
the book. Instead, what I've decided to do,
M.Canales.es wrote:
What I can't undestart is that the book SBU values are smallest that
mine :-?
Have the SBU numbers been updated at all since 6.1 or 6.1.1? If not,
those book versions still use gcc 3.4. If gcc 4's bootstrap takes a lot
longer than gcc 3.4's did, then that could explain the
On 4/24/06, Bryan Kadzban [EMAIL PROTECTED] wrote:
Have the SBU numbers been updated at all since 6.1 or 6.1.1? If not,
those book versions still use gcc 3.4. If gcc 4's bootstrap takes a lot
longer than gcc 3.4's did, then that could explain the higher SBUs when
building gcc 4.
gcc-4
Dan Nicholson wrote:
The situation you describe doesn't seem like it would have that
drastic of an effect on more than a couple packages.
IIRC, it really only had an effect on the large packages (gcc, glibc,
etc.). And (again IIRC) it wasn't drastic; it was on the order of an
SBU or so.
So
Dan Nicholson wrote:
On 4/24/06, Randy McMurchy [EMAIL PROTECTED] wrote:
Randy McMurchy wrote these words on 04/22/06 12:45 CST:
We have GCC-3.3.6 in the book. This would probably be adequate, but
I'm wondering if we shouldn't add GCC-3.4.6 to the book,
I just couldn't get excited about
19 matches
Mail list logo
