On 22/10/2011 06:18 PM, Jim Henderson wrote:
> On Sat, 22 Oct 2011 10:59:06 +0100, Orchid XP v8 wrote:
>
>>> Which also is perfectly fine.  As I mentioned elsewhere, people tend
>>> now to learn how to find things rather than how to do things.
>>
>> The point being, *I* could do that myself. I was asking somebody else
>> hoping that they might know something I don't. Actually it seems most of
>> the guys in our IT department don't understand long words like
>> "registry" or "SCSI controller"...
>
> Sure, given your environment, they might do the same things you might
> do.  They also might search with search terms that return different
> results, though, so it's still not a bad thing.

My point here is that I generally don't bother asking other team members 
about problems, because they apparently know less about computers than I 
do. (As absurd as that is...)

Or maybe it's just that they're American, and they take the approach of 
"hey, I could spend hours trying to understand this small problem, or I 
could just hit it with a wrench until it works". I'm not sure.

>>    From what I've observed, compiling anything nontrivial that's written
>> in C takes hours and hours. And that's assuming it doesn't fail half way
>> through, demanding many hours of fruitless tweaking...

> "hours and hours"?  Really?  I compiled rockbox last night (alternative
> firmware for the iPod and other MP3 players).  Took about 15 minutes to
> build.

 From what I recall, compiling X11 took about 3 hours on my PC. 
Interestingly, compiling Firefox took way, way longer than that...

>> OK. So I see how that can work for a running process. I'm not sure how
>> it's possible from a memory dump.
>
> You have a piece of software that in effect emulates the processor state.
>
> A core dump is a machine state, containing everything the machine has at
> the time the core is taken.  (on *nix, it's a single process, but the
> same principles apply).

I was under the impression that a core dump is exactly that - a simple 
copy of what was in the machine's memory at the instant of the crash. 
This is insufficient data to generate any useful information. (For 
example, you wouldn't be able to fire up an emulation in a VM with just 
this data.)

Your answers seem to indicate that a core dump actually contains 
additional metadata which allows you to DO STUFF with the data. If 
that's true, it makes quite a difference. (Although without knowing 
exactly how the compiler transformed the original source code into 
machine code - or even what the original source code was - I still don't 
see how you'd get very far...)

>>> Yeah, because nobody on the planet can build POV-Ray or any other
>>> software package.  Ever.  It's just impossible. *sigh*
>>
>> Well presumably the POV-Ray developers have all the necessary tools,
>> libraries and build environment set up to do this. But trying to guess
>> what that is by following the build errors is a very time consuming and
>> difficult process.
>
> a) they've documented the required tools in order to build it.
>
> b) if there's an error, you're not on your own - there happen to be some
> experts here in these very forums who know how to build it and can help
> troubleshoot those issues.

I'm sure most developers have far better things to do than answer stupid 
questions from somebody who can't figure out the setup required to build 
their code.

>>> So you were a member in what, 1957?  ;)
>>
>> Yep, that's right. ;-) I may only have been a twinkle in my
>> grandfather's eye, but I was sure as heck a LUG member. :-P
>
> You do know what "sarcasm" is, don't you? ;)

Yes. Perhaps you missed mine? :-P

>> Where do I find that?
>
> http://www.susestudio.com .  It's free to use.

OK. I'll go take a look.

>>> I find it does depend on how one asks the question, too.
>>
>> Well, true. You do see a lot of posts in broken English saying something
>> hysterical about "we have major issue with we demand fix immediate, how
>> to be making printer to print again??!!!!! ugency!" It always surprises
>> me that anybody bothers replying to those.
>
> Well, actually, I don't see questions like that in the openSUSE forums.

I posit there are a couple of reasons for that.

1. There aren't as many people using OpenSUSE as there are using [insert 
any MS product name here].

2. Most people didn't pay actual money to use OpenSUSE.

3. There aren't as many people trying to use OpenSUSE to actually run a 
business with.

[Question: Can you actually do that? I mean, I presume the OpenSUSE 
license doesn't preclude commercial usage...?]

>> As I recall, the exact problem was that a certain printer *was* working,
>> and then on a particular day, that specific printer [and no other]
>> simple stopped working, for no defined reason. I was hoping to get some
>> troubleshooting tips... but I got nothing.
>
> Well, as I said above, troubleshooting is about figuring out what
> changed.  (Note that there's a difference between "what changed" and
> "what you changed" - you may not have changed anything, but something
> certainly changed, and we need to figure out what it was, ideally, in
> order to fix it).

Sure. That's the major difference between "it never worked" and "it used 
to work fine, but then it stopped". In the latter case, figuring out 
what changed is the top priority.

>> Still, it least it's *possible* to ask questions about MS products. How
>> many printer manufacturers offer any kind of product support of any
>> description? Exactly.
>
> If I determined the problem was caused by an HP driver update, you can
> bet I'd be on the phone to HP printer support.

HP have support??

>> Well, the first problem is that if I enable USB in VMware, the mouse
>> pointer doesn't work properly. If you move the mouse an inch, the
>> pointer moves an inch, but if you click, it clicks on something two
>> inches away. WTF? o_O
>
> Never seen that before, and I use VMware on openSUSE quite regularly
> (though not to run openSUSE, and not with the host as Windows).  Tools
> installed?  Using the VMware-supplied tools, or the OSS version of the
> tools?  What version of openSUSE?  What version of Windows?  What version
> of VMware?  The mouse is presumably a USB mouse, yes?  Etc, etc, etc -
> there are lots of questions to ask about this problem that help dig
> deeper into what the root cause is.

Literally, create a new VM, set it to boot from the ISO image of either 
the GNOME or KDE live CD downloaded from the website. If the VM has a 
USB controller, the mouse pointer and actual mouse focus are out of 
sync. Remove USB, and it works perfectly. That's pretty random. (It also 
fails the same way for Ubuntu, but works perfectly for every flavour of 
Windows...)

> My point isn't to answer the question here (this isn't the right venue),

Sure. I was just muttering really. Wasn't expecting you to actually come 
up with an answer right now. (This thread is long enough already...!)

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

Post a reply to this message