>>> When I'm giving technical interviews, you might recall, I ask questions
>>> I know the candidate doesn't stand a chance of asking.  The reason I do
>>> this is to find out how they learn beyond their current skill.
>>
>> That's kind of evil. I'm not sure how somebody sitting in an interview
>> chair is supposed to solve a problem right there on the spot. I mean,
>> it's not like they can go away and look stuff up...
>
> I don't ask them to solve it.  I ask *how* they would solve it, and what
> resources they would use.

Well, OK... but since the only possible answer is "I would go read the 
manual and/or search Google", that doesn't seem like a particularly 
searching question.

Either that or I just failed to get hired - again...

>> If I wanted to know how to live forever, I wouldn't bother posting a
>> question in an online forum. You know why? Because... it's...
>> impossible. It's not that I don't know how, it's that IT CANNOT BE DONE.
>
> But if you want to know how to configure Apache on Linux, *that is NOT
> impossible*.

Sure. You just need to read through the manual for a while. The question 
at hand was "is it possible to make the package manager do what you 
want?" To which the answer is "no, not really".

> So why wouldn't you bother asking a question in an online forum in that
> instance?

IME, if you ask anything more complicated than "why doesn't Flash 
work?", either nobody understands the question, or nobody has the 
answer. Most likely you'll just get no reply at all. Or maybe one reply 
from a guy who doesn't speak English well. None of which helps fix the 
problem...

>> So hypothetically it's *possible* to
>> work around any given distro's poor dependency management. Does that
>> mean I actually want to go to such extremes? Not really, no.
>
> And you *don't have to*.  So, what you're saying is that if you want to
> figure something out, you try the absolute most difficult way of doing
> it, and then declare it impossible?
>
> Why not try the *easiest* way to do it, and if it doesn't make sense, ask
> a few questions so you can learn?

The problem is pretty simple: The package manager tracks dependencies on 
a rather coarse level. (In some instances. Sometimes it's fine, 
sometimes it's less than ideal.) Either you just put up with it, or you 
bypass the package manager, which is stupendously difficult.

I'm not sure what you think there is to "learn" here. It's not like I 
don't know why the problem exists or what causes it.

>> I still don't get how you can take megabytes of unformatted raw binary
>> and glean anything remotely useful from it, but hey. Apparently there's
>> some kind of black magic that makes this possible...
>
> It's called education.  It's also not unformatted - the format of a stack
> dump is known, you just need to know how to interpret it.

How do you know which part is the stack? How do you know which parts are 
code and which parts are data? How do you know where in the program the 
processor was executing?

You say "the format of a stack dump is known", except that... no, it 
isn't. The stack holds whatever arbitrary data the program decides to 
write to it. Without knowing how the program works, how can you get 
anything useful out of that?

> Straw man alert.  Learning to read a stack dump is not like punching a
> brick wall.  Learning to configure apache is not like punching a brick
> wall.  Learning how to use Linux is - you guessed it - NOT LIKE PUNCHING
> A FRIGGING BRICK WALL!
>
> Stop drawing false equivalencies.

My point being, if you're trying to do something that's clearly 
infeasible, do you continue trying to do it? Or do you go try some other 
approach?

>> If you try something, and it doesn't work, you can keep trying it over
>> and over again, or you can try something else. Which option is the most
>> rational?
>
> Neither - asking for help is the most rational option if it's something
> you think is important enough to try to learn in the first place.

And if "asking for help" is the thing that isn't working?

>> Package managers track package dependencies. Packaging teams write those
>> dependencies. Sometimes their structure is a little coarse. What more is
>> there to learn?
>
> That "sometimes" doesn't mean "always", for a start.

Sure. I didn't say it *never* works right. I said that sometimes it 
doesn't, and then it's a real pain to deal with.

> It isn't always a
> question of packaging, for example - it can be a question of what
> components are compiled together into a single library.

Every distro manages their stuff in a slightly different way. I seem to 
recall that if you installed POV-Ray under Debian, it used to insist on 
installing PVM, because the Debian POV-Ray package was a heavily 
modified PVM-patch of the official POV-Ray sources or something weird 
like that. (I presume this has been fixed now...)

> The OSS model actually doesn't mean that "anyone can contribute", but
> rather that those who demonstrate skills can.  They don't call it a
> 'meritocracy' for nothing. :)

Actually I've never heard anybody call it that, but sure, whatever.

People say "if you want something fixed, file a bug report". IME, this 
achieves next to nothing. Last time I filed a bug against something on 
Linux, a got one or two replies from the dev team, and then I heard 
nothing for THREE YEARS, and then I got an email saying they think 
they've fixed it and could I test it? I mean, I stopped using that 
package and that distro two years ago... like I *care* anymore!

> If you've never committed code to the kernel, Linus isn't likely to let
> you rewrite an entire subsystem to suit your needs.  But if you write
> patches/fixes for known bugs and your code is good, yes, you can get into
> the team that does the work.

I've submitted patches to product documentation. Like, literally, all 
somebody has to do is check that my DocBook markup is sane, and that the 
few paragraphs I've changed are factually correct, and then hit "merge". 
They HAVE the patch right there. I've done all the work of finding the 
right source files, filling in the right info, and so forth, so all the 
busy dev team has to do it hit a button instead of spending five minutes 
writing the stuff themselves.

It still took 6 months for the changes to get applied. Just because 
that's how long it took for my patch to be looked at. I guess since it 
was only documentation, it was low priority. (Compared to patches for 
stuff that are actually stopping people doing stuff...)

All I'm saying, people say "well it's open source, if you don't like it, 
you can fix it". Erm, no. No you can't. Unless you're very fortunate.

>> Of course, initially Linux was a total PITA to set up and actually use.
>
> At the time it came out, maybe 10 years ago for that matter (half it's
> life), that was true.  It's much less true now.

Sure. I thought I wrote that somewhere...

There's an old joke that "Ubuntu" is an African word meaning "I can't 
install Debian". And, let's face it, the first time I tried to install 
Debian, it was a highly complex process. Today things are much simpler; 
often you can run Linux without even /bothering/ to install it. Heck, 
sometimes you don't even need to reboot...

> Which is why there's a community to help you out when you have issues.

In my experience, the "community" is absolutely useless.

> I installed openSUSE 12.1 Beta 1 on my laptop.  The video went all
> wonky.  What did I do?  I posted a question on the openSUSE forums (where
> I'm staff) and asked if anyone else had seen the issue.  Turns out
> there's a bug submitted for it, and in a more recent kernel being tested,
> it's supposed to be fixed now.
>
> So, I asked a question and learned (a) that it's a known issue, (b) it's
> being worked on, and (c) a fix has probably been committed that I can
> test out.
>
> So when I have a chance, I'm going to try that fix and report back
> whether it worked or not.
>
> What I *didn't* do was just declare "it's hopeless to get this to work"
> and give up.
>
> See how that works?

Now, see, I would have just assumed "It's a beta. It's not supposed to 
actually work. Obviously there's nothing I can do about this. I should 
go try a different version or something." Because, let's face it, I know 
nothing about how device drivers work in Linux, and if the masterminds 
who put SUSE together couldn't get this right, there's no way in hell 
that *I* can possibly fix it. So that's the end of that.

>> Over time, however, I came to realise that Linux doesn't actually seem
>> to be much more efficient than Windows. That used to be one of the big
>> things people talked about: you can run Linux on a 283 with 16MB RAM,
>> and it WORKS, and it WORK WELL. Try doing that with Windows! But you
>> know what? It's a long time since I've seen a distro that can still do
>> that.
>
> Puppy Linux, Damn Small Linux...there are a few left, but yes, most
> kernel developers have moved on from providing 286 support, because
> there's not much call for it.

Most of them seem to start at 386 and up. (Having recently looked at the 
IA32 reference manuals, I now understand why...)

I don't suppose you happen to know of a distro that's particularly 
optimised for running in a VM?

>> Essentially, things have evolved to the point where you can compare
>> Windows and Linux, and see that each of them actually have merits
>> compared to the other. And the point we're currently arguing about is
>> one of them. On Windows, you just *install* stuff, and it works. Under
>> Linux, you try to install stuff, and mostly it just works... except when
>> it doesn't. And then all hell breaks lose.
>
> And when it doesn't work on Windows or Linux, one asks questions to get
> help.

Getting help for Windows is roughly as difficult as getting help for 
Linux. If you ask a question, typically an MSVP will point you to a KB 
article. This may or may not be relevant to what you actually asked, and 
may or may not actually fix your problem. If it does fix it, it usually 
works great. If there isn't a KB article about your specific issue... 
good luck!

> And I would debate "all hell breaks loose" with Linux when it doesn't.
> When it doesn't, it doesn't.  Usually (for me) on the rare occasions it
> happens, it's a missing dependency, and that's pretty easy to figure out
> these days.

So you've never had the package manager try to replace glibc and utterly 
break your install to the point where you have to replace the entire OS?

Or you mean you've learned what I learned: if it mentions touching 
glibc, abort the operation. (?)

> Well, it irritates several of us when you say "it's f-ing impossible!@!!@!
> @!!" when in fact it's not, and you just haven't asked for help.

It irritates me when people say something is possible when it damned 
well isn't. :-P

> There's *always* someone with more experience.  In the Linux community,
> most of those with more experience are more than happy to help those with
> less, but in order to get that help, you have to ASK for it.

Like I said, when I ask, nobody helps.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message