On Wed, Sep 12, 2012 at 1:09 PM, Joshua Murphy <poiso...@gmail.com> wrote:
> On Wed, Sep 12, 2012 at 11:15 AM, Michael Mol <mike...@gmail.com> wrote: > > On Wed, Sep 12, 2012 at 10:55 AM, Alan McKinnon <alan.mckin...@gmail.com > > > > wrote: > >> > >> On Wed, 12 Sep 2012 16:00:34 +0200 > >> Alex Schuster <wo...@wonkology.org> wrote: > >> > >> > Michael Mol writes: > >> > > >> > > On Wed, Sep 12, 2012 at 9:33 AM, Neil Bothwick <n...@digimed.co.uk > >> > > <mailto:n...@digimed.co.uk>> wrote: > >> > > >> > > Instead we get, try USE="-*" :P > >> > > > >> > > "Try MAKEOPTS='-j1'" > >> > > >> > Which in fact often helps... especially for me, I am using > >> > MAKEOPTS="-j --load=4", and I often experience build problems that > >> > are not reproducible with a fixed number of jobs, regardless how > >> > large. > >> > >> Yes indeed, and that one is good advice. > >> > >> Not every Makefile out there is safe for -j > 1, so running it as one > >> job is valid debugging. It's the correct thing to do with weird build > >> failures as it tests if a specific condition is true or not. > >> > > > > Yeah, except I've already gone that route, or otherwise ruled it out, > before > > I ask. That's why it's grating. (Even more grating when I have to spend > the > > time building a package again, just to convince someone that, no, it's > not > > MAKEOPTS that's the problem.) > > > > It's like "Have you tried turning it off and back on again". > > > <snip> > > And yet, for many who're in the daily job of working on other people's > systems, notably on-site, the first recommendation for many problems > is simply 'turn it off and back on again' because it does the trick > often enough to be worth it (and can avoid going out to the system > around 50% of the time, depending on the environment). Also, if you've > already gone that route, and ruled that out as a resolution, stating > as much generally tends to sidestep the initial few steps. > You know as well as I do that anyone who claims to have already turned something off and back on again is assumed to be merely trying to sidestep those questions without necessarily having performed those steps, or with having performed those steps in error; that's true 99% of the time. You're probably also familiar with putting users through the basic steps just to get yourself to a diagnostic baseline. I'm not saying I don't understand why people push traditional cleanup recipes before actually trying to understand the problem. As an advanced user, it's just one of those extremely frustrating things, along with: * RTFM (hey, I did!) * LMGTFY (hey, it's not like I didn't search for myself, first) * Did you try rebooting? (uh...) In reality, nobody believes you really did your homework, presuming that if you had, your problem would be solved. After all, it's entirely statistically probable you've got another mundane problem like 99% of everyone else. And since they don't believe you did your homework, they'll ask you to do it again. Generally speaking, I don't _get_ mundane problems on a Gentoo system. I'll probably have dug into the source code before I ask questions. The last time I had an issue on Gentoo where I needed assistance, it turned out to be a glibc bug. I must have gone through at least ten people who each had me poke at the usual suspects. I lost _months_ on some of my hardware because of this. One of those machines is still down, but only because the system had previously had a long enough uptime that boot-impacting-only hardware failures creeped in and slammed me when I went to reboot. But, really, this all boils down to a simple case: Sometimes the user really does know what he's doing. -- :wq
