Gentoo Archives: gentoo-user

From: Michael Mol <mikemol@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Gentoo is the best linux distro
Date: Wed, 12 Sep 2012 17:29:32
Message-Id: CA+czFiDDz1-fWiAhM6o5zXZwsR32vAXA-sOKZmmRTdW7MBZnyQ@mail.gmail.com
In Reply to: Re: [gentoo-user] Gentoo is the best linux distro by Joshua Murphy
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