![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Orchid XP v8
Subject: Re: Is this the end of the world as we know it?
Date: 19 Oct 2011 17:21:34
Message: <4e9f3f5e$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Orchid XP v8
Subject: Re: Is this the end of the world as we know it?
Date: 19 Oct 2011 17:30:17
Message: <4e9f4169$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Right. Well knowing what the command switches are isn't going to help me
>> configure Apache, is it?
>
> Yes, it won't. But if you want to configure apache, you read the Apache
> documentation.
...which will only tell you how to do it via the configuration file
interface which you keep insisting it isn't necessary to touch.
> Or if you've got the yast http module installed, you can try yast2 http-
> server longhelp for command-line help.
Which presumable again just tells you about command switches, not how to
configure Apache using YaST.
>> If somebody told you that the Earth is in fact flat, would you take the
>> time to sit down and have a rational conversation with them? Or would
>> you just be like "psssh, yeah RIGHT! Bye..."
>
> So, to carry the analogy out, you believe the "Earth is flat" and you're
> not willing to be convinced otherwise?
More like you keep insisting that the Earth is flat, and then act all
surprised when I don't immediately believe you.
> Um, nobody's saying that. What I'm saying is that if you ask questions
> on relevant forums, you can actually get help to configure it and learn
> how it works.
I know how it works - not very well. (In varing degrees, anyway.) What's
to ask?
> Unless you'd rather just bitch about how impossible everything is.
Let's be clear about this: I said that package management can be a pain
sometimes. WHICH IS TRUE. I didn't say it was *impossible* to install
anything. I just said sometimes it's very difficult to make it do the
correct thing.
I pointed out a small deficiency in a piece of software, and everybody
is like "no, you're just too stupid to work it correctly". As if no
software ever has deficiencies...
> But you seem to enjoy learning new things. Which means more than just
> reading books and websites - occasionally it means talking to people who
> know more about the topic than you do.
>
> See how that works?
Reading documentation can be quite enlightening - or not. It depends on
how good the documentation is. IME, asking people is almost always an
utter waste of time.
> When I pointed out that, hey, there are some tools (some of which are in
> fact standardised across different distributions) that mean you *don't*
> have to edit text files, you responded with incredulity.
The standard Unix philosophy is that programs are controlled mainly via
the command line and via textual configuration files. Does every single
piece of software available for Linux follow this model? No. Do the vast
majority of them follow this model? Yes.
> My point is that while hard-core *nix utilities do tend to be that way,
> it's a mistake to think that that's the *only* way Linux programs are
> created - as a front-end to some cryptic CLI interface.
OK, fair enough.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 10/19/2011 12:17, Jim Henderson wrote:
> But even in conversation, it's difficult to make a point when the
> criteria for the point is constantly changing.
I intended it more as "yes, you're right in this instance, but I was
thinking about that situation instead."
> Never heard of ClickOnce.
I bet you did, if you heard the crap about MS installing "without asking"
extensions to support it in firefox. :-)
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jim Henderson
Subject: Re: Is this the end of the world as we know it?
Date: 19 Oct 2011 21:30:25
Message: <4e9f79b1$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 19 Oct 2011 14:58:58 -0700, Darren New wrote:
> On 10/19/2011 12:17, Jim Henderson wrote:
>> But even in conversation, it's difficult to make a point when the
>> criteria for the point is constantly changing.
>
> I intended it more as "yes, you're right in this instance, but I was
> thinking about that situation instead."
Oh, I see. :) That's what I get for being overtired for the past week
(last week I ended up at a conference working - but it was a good way to
network - and this week I'm doing some additional contract work writing
some documentation for some low-level Linux kernel stuff).
>> Never heard of ClickOnce.
>
> I bet you did, if you heard the crap about MS installing "without
> asking" extensions to support it in firefox. :-)
Ah, *that* thing. I hadn't heard it called that, just heard about the MS
extensions being installed without the user being asked. :)
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jim Henderson
Subject: Re: Is this the end of the world as we know it?
Date: 19 Oct 2011 21:30:53
Message: <4e9f79cd$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 19 Oct 2011 21:50:49 +0100, Orchid XP v8 wrote:
>>> No! You jailbroke your Apple and put Linux on it. 8-)
>>
>> And then Apple sued me into oblivion. ;)
>
> I've heard good things about Oblivion...
I hear it's rent/mortgage free. ;)
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jim Henderson
Subject: Re: Is this the end of the world as we know it?
Date: 19 Oct 2011 21:37:28
Message: <4e9f7b58$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 19 Oct 2011 22:30:13 +0100, Orchid XP v8 wrote:
>>> Right. Well knowing what the command switches are isn't going to help
>>> me configure Apache, is it?
>>
>> Yes, it won't. But if you want to configure apache, you read the
>> Apache documentation.
>
> ...which will only tell you how to do it via the configuration file
> interface which you keep insisting it isn't necessary to touch.
Which is why you use the HELP button.
>> Or if you've got the yast http module installed, you can try yast2
>> http- server longhelp for command-line help.
>
> Which presumable again just tells you about command switches, not how to
> configure Apache using YaST.
Try it. It's more than that, again, pay attention to those who actually
have used it instead of making assumptions and then declaring those
assumptions to be true, regardless of how true you believe them to be.
BTW, you do know the world is not in fact flat, right? Just checking. ;)
>>> If somebody told you that the Earth is in fact flat, would you take
>>> the time to sit down and have a rational conversation with them? Or
>>> would you just be like "psssh, yeah RIGHT! Bye..."
>>
>> So, to carry the analogy out, you believe the "Earth is flat" and
>> you're not willing to be convinced otherwise?
>
> More like you keep insisting that the Earth is flat, and then act all
> surprised when I don't immediately believe you.
Except that I'm telling you the Earth is round, and you're insisting that
it's flat. (Your ideas are not based on current implementation; if they
were, you'd see that they're incorrect).
>> Um, nobody's saying that. What I'm saying is that if you ask questions
>> on relevant forums, you can actually get help to configure it and learn
>> how it works.
>
> I know how it works - not very well. (In varing degrees, anyway.) What's
> to ask?
*sigh*
You don't know how it works. You have an opinion about how well it
works. How well it works != how it works.
>> Unless you'd rather just bitch about how impossible everything is.
>
> Let's be clear about this: I said that package management can be a pain
> sometimes. WHICH IS TRUE. I didn't say it was *impossible* to install
> anything. I just said sometimes it's very difficult to make it do the
> correct thing.
>
> I pointed out a small deficiency in a piece of software, and everybody
> is like "no, you're just too stupid to work it correctly". As if no
> software ever has deficiencies...
Yes, package management can be a pain sometimes. But you've also claimed
that it's impossible to learn how to manage apache using YaST. It isn't,
as evidenced by the thousands of people who *do just that*.
>> But you seem to enjoy learning new things. Which means more than just
>> reading books and websites - occasionally it means talking to people
>> who know more about the topic than you do.
>>
>> See how that works?
>
> Reading documentation can be quite enlightening - or not. It depends on
> how good the documentation is. IME, asking people is almost always an
> utter waste of time.
Yeah, again, because I've only spent 20 years answering questions on
online forums, and I *love* wasting my time.
I accept that your experience has not been so good. I'm telling you it
isn't always that way and that you could certainly try over in the
openSUSE forums when you have questions about openSUSE. I tell you this
because we have a significant number of users who *have* received help
and *have* been able to make things work after being told how to use the
software.
You continuing to deny that you could ever possibly get help in an online
forum by asking questions, when you're told that there is a place you can
ask questions and generally people are VERY HAPPY when they get
answers....well, it's just silly.
Your experience can change, but only if you continue to try asking
questions. Giving up because you've had little to no success in the past
isn't ever going to get you out of that rut.
Just like searching for a job - if you stop searching, nobody's ever
going to offer you something better.
>> When I pointed out that, hey, there are some tools (some of which are
>> in fact standardised across different distributions) that mean you
>> *don't* have to edit text files, you responded with incredulity.
>
> The standard Unix philosophy is that programs are controlled mainly via
> the command line and via textual configuration files. Does every single
> piece of software available for Linux follow this model? No. Do the vast
> majority of them follow this model? Yes.
*No*. That's my point. Low level system stuff, yes; end-user
applications DO NOT DO THIS.
>> My point is that while hard-core *nix utilities do tend to be that way,
>> it's a mistake to think that that's the *only* way Linux programs are
>> created - as a front-end to some cryptic CLI interface.
>
> OK, fair enough.
*Finally*, I think we're making progress. ;)
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jim Henderson
Subject: Re: Is this the end of the world as we know it?
Date: 19 Oct 2011 22:10:10
Message: <4e9f8302@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Wed, 19 Oct 2011 22:21:31 +0100, Orchid XP v8 wrote:
>>>> 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...
That is a legitimate answer. It isn't the only answer, though - because
one could ask people with more experience. They could get in touch with
teammates who know the systems better, or with people they know from
other companies. They could ask at a user group meeting (if it's not a
critical system-down issue, obviously - waiting until your next LUG
meeting isn't really good if the users can't work).
Point is, there are many options.
>>> 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".
The answer is "it depends on what you want to make the package manager
do".
And if I want to know how to configure a specific aspect of Apache, say,
enabling PHP5 on it, I look at the relevant Apache docs, compare to
what's in YaST or Webmin, and if it doesn't make sense, I ask a question.
While waiting for an answer to the question, I continue to research.
>> 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...
*sigh*
Again, because of course, I have enjoyed wasting 20 years of my life
helping people in online forums.
Yes, your experience varies from mine. I'm telling you that it needn't
be that way.
I had a problem with openSUSE 12.1's support of the Radeon X300 video
controller in my laptop. I asked a question. I got an answer that
pointed me to a bug indicating a known issue. I got a follow-up answer
that a newer kernel seems to have fixed it, and asked if anyone could
confirm.
This evening, I got an answer from someone saying that one issue seems to
be fixed, but there's still some video corruption, indicating it's not
completely solved.
But it's being worked on, and I'm learning more about what's going on
with the issue.
Now, did I waste my time? You tell me. Remember that it's beta and the
fix is in progress, though, before you answer that question.
>>> 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.
It's not really that difficult to "bypass" the package manager, but it
can create more problems for you. (rpm -ihv --nodeps is one way to
bypass; download the source and compile is another. The first is easier,
but may lead to a non-working package. The latter may uncover some
dependency conflicts in library versions etc.)
But if you're having difficulty with dependency resolution, you ask a
question about it and then perhaps someone builds the package for you.
I hear you laughing. Don't. We've got a guy over in the openSUSE forums
who does this for people who need a package built for their installation
if there's no pre-built RPM available. His user ID is malcolmlewis, and
he's been happy to do this for anyone who asks.
He uses the Open Build Service (build.opensuse.org), which incidentally,
can build packages not just for openSUSE, but for many distributions -
including Debian, Ubuntu, Redhat, CentOS, SUSE Linux Enterprise,
openSUSE, and probably a few others.
> 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.
You don't know how to deal with it. That's what there is to learn; you
think you just have to live with it, but you don't always have to do that.
>>> 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?
The debugger tells you those things, especially if you are in a live
kernel debugging session.
> 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?
Well, yes, it is. Because you have structural elements from the software
known to the debugger. You frequently have symbolic debug information
available to you. You may refuse to believe this, but I know it from
having *actually done it*.
The CPU "knows" how to process the instructions, and it knows what the
data is that's going through it. It "knows" what functions it's running,
what the call stack is, and how to return to the previous functions.
A kernel debugger just gives you the tools to ask the CPU what it's doing
in a particular stack frame.
It really *isn't* rocket science.
>> 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 it is clearly infeasible, then how come so many people actually
succeed at using it?
>>> 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?
Then ask for help asking for help. Posit - a user opens a bug in
bugzilla, but doesn't know what information is useful to the developer.
You can either open the bug and say "I don't know what would be useful to
help debug this, if you tell me what and how to get it, I'll get that
information for you", you've just asked how to ask for help.
Have you read Eric Raymond's essay on "asking questions the intelligent
way"? (I believe that's the title). It's a very good overview on how to
get help in online forums, mailing lists, IRC, whatever.
For example, ESR says (quite truthfully) that if you ask someone to read
the manual to you, you're not likely to get help. If you say "I've read
the manual on this, and am having trouble parsing it", you're more likely
to get help. If you don't assume an outcome ("I'm having trouble with my
video resolution and think it's due to microfractures on my motherboard,
how do I repair those motherboard problems") but say something like "I'm
having video problems, here is what my video controller is, operating
system and release, and drivers - and here is what I've tried so far",
you're likely to get help.
>>> 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.
So if it's being a pain, ask if that's normal, and if it isn't, then
there's a problem to fix. If it is in that instance, then you know it's
expected behaviour.
You seem to be saying "it's a pain" and assuming that it's expected to be
that way. There may actually be an underlying problem that needs to be
fixed that would make it less of a pain for you. But you'd rather
complain, apparently, that it's a pain.
That's what's frustrating me in this conversation.
>> 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...)
It may have been. Or you could install povray from the sources or a
binary package here. Then you get the latest version that Chris & team
have put together, and you don't have to deal with the Debian dependency
issues.
>> 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.
Well, look up the term - you'll learn more about how patching actually
works in many OSS projects.
Some projects do tend towards more monolithic management (where one
person leads and codes), but larger projects do tend towards the idea
that you can contribute if you prove yourself.
> 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!
Sometimes that happens. It depends on the severity of the bug and how
frequently it happens or is reported.
A bug that one person once saw a couple years ago but nobody else has
reported an issue with isn't likely to get attention.
A video problem (like my radeon driver bug) affects lots of people and
clearly is a serious issue. It's actually getting attention right now
before the oS 12.1 release.
>> 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...)
Doc is a lower priority, which isn't a good thing - but it's also
necessary for doc patches to be reviewed for accuracy.
> 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.
You can always write a patch for the code you're running and submit it
upstream. If it works for you as you've patched it, you've done what you
should. If you distribute the code with your patch, you have to make
your patch available (if it's GPL'ed code that you're modifying), but if
you don't distribute it, you're not actually legally required to
distribute your patch, and you can certainly run the code on your own
system with your own customisations.
So yes, you can fix it if you don't like it. The dev team also isn't
obligated to accept your patch, but that doesn't mean your patch can't be
used in your system and that you can't share it independently of their
code distribution.
>>> 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...
I've heard that joke before. It's a good one. (says the openSUSE guy) ;)
>> Which is why there's a community to help you out when you have issues.
>
> In my experience, the "community" is absolutely useless.
I can't see that you've asked any questions in the openSUSE or SUSE
communities about your upgrade woes. Seems there's an avenue that you
haven't looked at. So I'm not sure how you can say the openSUSE
community is useless, as you haven't tried it.
>> 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.
I don't know much about how device drivers work either, but there's a
reason betas are released publicly. So people can try them and report
issues they have so they can get fixed before release.
It's not about you or me being able to fix a radeon driver issue. It's
about being able to say "hey, this doesn't work" and having someone look
at it. Something like this video issue, I asked because if it's more
than just my lowly X300 card, it's an important issue to get addressed.
If it were just my system, I'd probably still raise an issue because the
same driver on the 2.6.xx kernel in 11.4 works flawlessly. 12.1 uses the
new 3.1 kernel, so it's probably a kernel driver issue, and that's
something that the openSUSE folks will report upstream to the kernel dev
team (if they're not actually on the kernel dev team already).
Point is, if you use it and don't report the problem, unless someone else
has the issue and reports it, it's guaranteed not to get looked at.
>>> 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...)
There are some pretty significant differences, yes.
> I don't suppose you happen to know of a distro that's particularly
> optimised for running in a VM?
Depends on what you want to do with it. Custom SUSE builds done in
Studio can be built as a VMDK or OVM (I think is the extension) format
for use in virtual environments.
>>> 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!
The Microsoft MVPs generally do a good job answering questions in the
Microsoft forums, from what I've seen.
Of course, going in there and saying "this piece of crap just sucks and
doesn't work right" isn't likely to get you an answer, either.
>> 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?
Nope, I haven't. Because when I update using the package manager, it
tells me what is going to need to change because of the glibc update/
change, and if it's not acceptable to me, I refuse the update.
> Or you mean you've learned what I learned: if it mentions touching
> glibc, abort the operation. (?)
It means look at the possible effects.
>> 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
Except that it *is*, otherwise, how is it that millions of people use
Linux every single stinking day?
>> 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.
Come over to the openSUSE forums and ask for help when you're next using
openSUSE. You'll *probably* be pleasantly surprised.
If you don't ask, you're *guaranteed* not to get any help.
It's like the old joke about playing the lottery - you have to play to
win. Except the odds of getting a useful answer on a Linux forum are
far, *FAR* better than the odds of winning the lottery.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 10/19/2011 18:30, Jim Henderson wrote:
> Oh, I see. :) That's what I get for being overtired for the past week
Yeah, no problem. Lots of people *try* to turn conversations into debates.
Certainly I'm not going to mind that you thought I was doing that. :-)
> Ah, *that* thing. I hadn't heard it called that, just heard about the MS
> extensions being installed without the user being asked. :)
Yeah. It's their package manager for applications you install and update
over the web. I'm honestly not sure why they felt the need to add support in
firefox, but there you have it.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 10/19/2011 12:04, Jim Henderson wrote:
> Well, sure, you'd have to put them someplace where IIS won't look at it.
> With Apache, the same holds true - if you want to put it someplace where
> Apache won't care, don't put it in /etc/apache2. :)
Does Apache load all configuration files in /etc/apache2? I thought there
were like include directives or something.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>> 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...
>
> That is a legitimate answer. It isn't the only answer, though - because
> one could ask people with more experience. They could get in touch with
> teammates who know the systems better, or with people they know from
> other companies. They could ask at a user group meeting (if it's not a
> critical system-down issue, obviously - waiting until your next LUG
> meeting isn't really good if the users can't work).
>
> Point is, there are many options.
I keep forgetting that other people actually work in teams.
If I were to ask someone from my team for a solution, their first answer
would be "did you try rebooting it?", followed by "hold on, let me check
Google..."
> Yes, your experience varies from mine. I'm telling you that it needn't
> be that way.
Well, like I say, short of spending 10 years using Linux and seeing if
anything is different this time, there's not really any way for me to
verify your claim objectively. Either I believe you or I don't.
> Now, did I waste my time? You tell me. Remember that it's beta and the
> fix is in progress, though, before you answer that question.
Now, again, I wouldn't have even attempted to use a beta version in the
first place. (But then, that's why they label it as beta. If you don't
want the risk, you don't use it. If the risk is acceptable, you try it
out...)
> But if you're having difficulty with dependency resolution, you ask a
> question about it and then perhaps someone builds the package for you.
I couldn't get anybody to tell me the command name to turn off the
firewall [which would have taken then 3 to 4 seconds], and you expect
that somebody is going to build a custom package just for me? [Which
would presumably take several hours if not days.]
Can you see why I might be reluctant to believe this?
>> 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?
>
> The debugger tells you those things, especially if you are in a live
> kernel debugging session.
OK, so how the heck does the debugger know which chunk of unformatted
data is the stack?
>> 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?
>
> Well, yes, it is. Because you have structural elements from the software
> known to the debugger.
I don't follow. What do you mean by "structural elements"?
> A kernel debugger just gives you the tools to ask the CPU what it's doing
> in a particular stack frame.
Wait - you mean the debugger can actually see what the processor is
doing, not just what's in memory?
I can see how that might be possible for a live debugger session. (I
mean, assuming the debugger can take over control of the CPU somehow.)
I'm not sure how that would be possible for a raw memory dump.
> You seem to be saying "it's a pain" and assuming that it's expected to be
> that way. There may actually be an underlying problem that needs to be
> fixed that would make it less of a pain for you. But you'd rather
> complain, apparently, that it's a pain.
>
> That's what's frustrating me in this conversation.
Managing packages in Linux has *always* been a pain. It's gradually
improved over the years, but sometimes it still falls down. What I can't
figure out is why you seem to be denying that there's anything wrong
with it.
>> 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...)
>
> It may have been. Or you could install povray from the sources or a
> binary package here. Then you get the latest version that Chris& team
> have put together, and you don't have to deal with the Debian dependency
> issues.
I would have presumed that building POV-Ray from source would simply be
intractably difficult. It would probably be simpler to find a binary
package from somewhere else and try to convince that to install somehow.
Regardless, hopefully Debian fixed this particular stupidity long ago.
(I seem to recall POV-Ray doesn't comply with Debian's definition of
"free" either, so it's in non-free or something...)
>> 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!
>
> Sometimes that happens. It depends on the severity of the bug and how
> frequently it happens or is reported.
>
> A bug that one person once saw a couple years ago but nobody else has
> reported an issue with isn't likely to get attention.
In fairness, looking back at the ticket, the actual issue was that
such-and-such a package doesn't work properly on AMD64. The issue
presumably was upstream (i.e., it isn't Gentoo's fault that SmartEiffel
doesn't run correctly on AMD64). That probably doesn't help. Plus I
doubt SmartEiffel is insanely popular.
>> 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.
>
> You can always write a patch for the code you're running and submit it
> upstream.
> So yes, you can fix it if you don't like it.
Not if you don't speak C you can't. :-P
>> 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.
>
> I've heard that joke before. It's a good one. (says the openSUSE guy) ;)
Heh. Made me chuckle when I first heard it.
I still think dselect is horrid! >_<
>>> Which is why there's a community to help you out when you have issues.
>>
>> In my experience, the "community" is absolutely useless.
>
> I can't see that you've asked any questions in the openSUSE or SUSE
> communities about your upgrade woes.
I didn't mean any specific Linux community. I just offhandedly meant
"every one that I've tried".
Did you know I used to be a member of the local Linux User Group? Went
to all the physical meetings and everything. I even brought my Amiga
1200 with me, running Debian "potato". I was rather surprised that this
turned out to be *drastically* slower than AmigaOS. Like, it took 20
minutes for GNOME to start. (!!)
The guys in the LUG were very friendly and everything. It's just that
they never had the slightest clue how to fix my problems, or even where
to start looking. Every suggestion I got from them always started with
"man" followed by a command name...
>> 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.
>
> I don't know much about how device drivers work either, but there's a
> reason betas are released publicly. So people can try them and report
> issues they have so they can get fixed before release.
> Point is, if you use it and don't report the problem, unless someone else
> has the issue and reports it, it's guaranteed not to get looked at.
Again, if a video driver for a very common video card doesn't work, I
would assume this has already been reported multiple times over.
>> Most of them seem to start at 386 and up. (Having recently looked at the
>> IA32 reference manuals, I now understand why...)
>
> There are some pretty significant differences, yes.
Virtual memory being the big one...
>> I don't suppose you happen to know of a distro that's particularly
>> optimised for running in a VM?
>
> Depends on what you want to do with it. Custom SUSE builds done in
> Studio can be built as a VMDK or OVM (I think is the extension) format
> for use in virtual environments.
I'm thinking more about the fact that if you do a default install of
[any distro you care to mention], it installs power management
utilities, firmware updates, scanner and webcame capture software, and
all sorts of other hardware-related stuff which is simply useless on a
VM. So first you have to wait for all this lot to download, and then you
have to spend time uninstalling it again.
I'm just wondering if anybody has packaged up a set of stuff more
appropriate to running a VM. But yeah, I guess it's going to vary
depending on what you want the VM for...
>> 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!
>
> The Microsoft MVPs generally do a good job answering questions in the
> Microsoft forums, from what I've seen.
Some of the stuff written my MVPs is quite enlightening. For example, I
once found [and will probably never find again] a website dedicated to
MS Word glitches. It actually explains several interesting points which
aren't mentioned in the documentation anywhere. Very useful stuff.
Replies to specific issues that I desperately want to fix tend to be
less helpful. It seems the experts have no more idea what to try than I
do. (Of course, with most of these things there's always the potential
for the problem being some 3rd party software that a Microsoft expert
isn't going to know anything about...)
> Of course, going in there and saying "this piece of crap just sucks and
> doesn't work right" isn't likely to get you an answer, either.
Sure. But "this one specific printer doesn't print through Terminal
Services" got me little to no replies either.
>> 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?
>
> Nope, I haven't.
That's pretty impressive.
>>> 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
>
> Except that it *is*, otherwise, how is it that millions of people use
> Linux every single stinking day?
I didn't say it's impossible to use Linux. Heck *I* do that! I said in
certain situations it's impossible to make the package manager do what
you want.
>> Like I said, when I ask, nobody helps.
>
> Come over to the openSUSE forums and ask for help when you're next using
> openSUSE. You'll *probably* be pleasantly surprised.
As it happens, I've just upgraded my work PC, and I was just about to
set up a couple of Linux VMs. One of them will probably be OpenSUSE. I
may or may not be able to get VMware Tools to work on it... so I may
have to take you up on that one.
(OTOH, I'm not looking forward to setting up yet *another* account on
yet *another* forum... Like I don't have enough of those yet!)
> It's like the old joke about playing the lottery - you have to play to
> win.
Except that if you don't play, the probability of winning is zero, and
if you do play, the probability of winning is so close to zero as to be
effectively zero for all practical purposes.
Can you tell why I don't play the lottery?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |