1 |
On Wed, Sep 12, 2012 at 1:09 PM, Joshua Murphy <poisonbl@×××××.com> wrote: |
2 |
|
3 |
> On Wed, Sep 12, 2012 at 11:15 AM, Michael Mol <mikemol@×××××.com> wrote: |
4 |
> > On Wed, Sep 12, 2012 at 10:55 AM, Alan McKinnon <alan.mckinnon@×××××.com |
5 |
> > |
6 |
> > wrote: |
7 |
> >> |
8 |
> >> On Wed, 12 Sep 2012 16:00:34 +0200 |
9 |
> >> Alex Schuster <wonko@×××××××××.org> wrote: |
10 |
> >> |
11 |
> >> > Michael Mol writes: |
12 |
> >> > |
13 |
> >> > > On Wed, Sep 12, 2012 at 9:33 AM, Neil Bothwick <neil@××××××××××.uk |
14 |
> >> > > <mailto:neil@××××××××××.uk>> wrote: |
15 |
> >> > |
16 |
> >> > > Instead we get, try USE="-*" :P |
17 |
> >> > > |
18 |
> >> > > "Try MAKEOPTS='-j1'" |
19 |
> >> > |
20 |
> >> > Which in fact often helps... especially for me, I am using |
21 |
> >> > MAKEOPTS="-j --load=4", and I often experience build problems that |
22 |
> >> > are not reproducible with a fixed number of jobs, regardless how |
23 |
> >> > large. |
24 |
> >> |
25 |
> >> Yes indeed, and that one is good advice. |
26 |
> >> |
27 |
> >> Not every Makefile out there is safe for -j > 1, so running it as one |
28 |
> >> job is valid debugging. It's the correct thing to do with weird build |
29 |
> >> failures as it tests if a specific condition is true or not. |
30 |
> >> |
31 |
> > |
32 |
> > Yeah, except I've already gone that route, or otherwise ruled it out, |
33 |
> before |
34 |
> > I ask. That's why it's grating. (Even more grating when I have to spend |
35 |
> the |
36 |
> > time building a package again, just to convince someone that, no, it's |
37 |
> not |
38 |
> > MAKEOPTS that's the problem.) |
39 |
> > |
40 |
> > It's like "Have you tried turning it off and back on again". |
41 |
> > |
42 |
> <snip> |
43 |
> |
44 |
> And yet, for many who're in the daily job of working on other people's |
45 |
> systems, notably on-site, the first recommendation for many problems |
46 |
> is simply 'turn it off and back on again' because it does the trick |
47 |
> often enough to be worth it (and can avoid going out to the system |
48 |
> around 50% of the time, depending on the environment). Also, if you've |
49 |
> already gone that route, and ruled that out as a resolution, stating |
50 |
> as much generally tends to sidestep the initial few steps. |
51 |
> |
52 |
|
53 |
You know as well as I do that anyone who claims to have already turned |
54 |
something off and back on again is assumed to be merely trying to sidestep |
55 |
those questions without necessarily having performed those steps, or with |
56 |
having performed those steps in error; that's true 99% of the time. |
57 |
|
58 |
You're probably also familiar with putting users through the basic steps |
59 |
just to get yourself to a diagnostic baseline. |
60 |
|
61 |
I'm not saying I don't understand why people push traditional cleanup |
62 |
recipes before actually trying to understand the problem. As an advanced |
63 |
user, it's just one of those extremely frustrating things, along with: |
64 |
|
65 |
* RTFM (hey, I did!) |
66 |
* LMGTFY (hey, it's not like I didn't search for myself, first) |
67 |
* Did you try rebooting? (uh...) |
68 |
|
69 |
In reality, nobody believes you really did your homework, presuming that if |
70 |
you had, your problem would be solved. After all, it's entirely |
71 |
statistically probable you've got another mundane problem like 99% of |
72 |
everyone else. And since they don't believe you did your homework, they'll |
73 |
ask you to do it again. |
74 |
|
75 |
Generally speaking, I don't _get_ mundane problems on a Gentoo system. I'll |
76 |
probably have dug into the source code before I ask questions. The last |
77 |
time I had an issue on Gentoo where I needed assistance, it turned out to |
78 |
be a glibc bug. I must have gone through at least ten people who each had |
79 |
me poke at the usual suspects. I lost _months_ on some of my hardware |
80 |
because of this. One of those machines is still down, but only because the |
81 |
system had previously had a long enough uptime that boot-impacting-only |
82 |
hardware failures creeped in and slammed me when I went to reboot. |
83 |
|
84 |
But, really, this all boils down to a simple case: Sometimes the user |
85 |
really does know what he's doing. |
86 |
|
87 |
-- |
88 |
:wq |