"Christopher E" <sensory.access@...> posted
below, on Fri, 12 May 2006 16:06:45 -0400:
>> Q: What is wrong with top posting, bottom quoting.
> I don't know what top posting is, so I am sorry if I am doing it. ok I
> may know what ist is but I am not sure. Is it when posting above a
> quoting area?
Yes. Altho the vast majorities of AOLer net newbies have pretty much
overwhelmed the traditionalists, the way most folks who've been on lists
and newsgroups for awhile prefer it is to quote the point you are replying
to (not the whole post, particularly if it's long, just the single point),
then type your reply within that context. Then if you have another point
to reply to, you quote it, and reply to it. The idea is that you never
quote a huge block (more than a page) at once (if you are replying to a
general point in a huge block, it's best to try summarizing it), so
there's always some of your reply visible, it's never a whole page of
quoted text. Of course, some folks have larger display pages than others,
but that's the idea.
What happens is that the effort of figuring out what point you are
replying to and editing the quote to that, often makes your reply clearer
than it would be otherwise. It's also much clearer what point you were
intending to reply to, than if you'd simply replied at the top and left
the entire multi-page multi-point previous post intact at the bottom.
This post was a good example of how to do it right. The previous post,
well, lets just say it made things frustrating for me, as I would have
liked to include a bit of the grandparent post as well, for context, and
the way it was, had I done that it would have been out of order and rather
more confusing to follow, so I just left it out.
>> Have you ensured that you have the latest gentoolkit? A version not long
>> ago had a bug that caused it to skip some stuff on amd64.
>> My current version (~arch): gentoolkit-0.2.2_pre4
> Yes I went and emerged it today with the accept keyword ~amd64 thing
> in my make.conf file. I am still waiting for the kdelibs ... to
> finish compiling as its taking for ever. it did the fist 8 depencies I
> would say much fast then the last one with would be the kdelibs ...
Good. It seems to be working better then. You must have had the bad one.
As for kdelibs, yes, it's a very big compile. If you think about it,
it's actually the equivalent of about 10-20 regular sized packages, all
rolled up into one, because they are all general KDE libraries assumed to
be on any KDE system by any KDE app, so they all have to be merged anyway,
and due to the interdependedness -- the build process builds part of one,
as necessary to build part of a second component, which is necessary to
build a third component, which is necessary to finish building the first
component. Thus, it'd be very difficult if not impossible to separate
them effectively, and since they are all needed anyway, they might as well
just be built together. So yes, it's a huge compile that takes quite some
time, but when you think of it as the roughly 20 regular packages all
rolled into one that it effectively is, it doesn't seem so bad, after all.
Of course, making all this worse is the fact that g++ works much harder to
compile C++ than gcc has to, to compile C. That's because it takes fewer
lines in C++ to program the same stuff, yet g++ compiles it to code of
roughly the same performance. If 10 lines of C++ does the same as 20
lines of C, resulting in native binary code of the same efficiency, then
g++ will have to work twice as hard to do it as the C compiler part of
gcc. That's why C++ based packages require so much more memory and time
for gcc/g++ to compile than C based packages. The tradeoff is basically
that it's easier to program in C++, making the programmer more efficient,
at the expense of making the compiler do all the work that the programmer
was able to skip.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
firstname.lastname@example.org mailing list