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