On Sat, 22 Oct 2011 20:30:03 +0100, Orchid XP v8 wrote:

>> 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...)

Well, I don't think it's absurd, because you do quite well when you apply 
yourself.  Being isolated also makes it difficult to become part of a 
coherent team.

> 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.

Ahem.  You do realise that even though I spell things as those in England 
do, I am in fact American, yes?  Broad brush strokes aren't going to do 
you any favours. ;)

>>>    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...

Of course, times have in fact changed, as has hardware.  I remember 
building GCC back in the early 90's on a Sparc 2 system.  It took (IIRC) 
3 compilation cycles, and could take about that long.

So it sounds to me like you're either stuck back in 1990, or you're still 
using an 8088 to compile with.

>>> 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.)

It depends on if the core is from a complete system or not.  *nix core 
files tend to be for a single program (or process).

But what's in memory includes vital information about the machine state.  
There is certainly sufficient information if you know how to parse it.

Again, trust me - I've actually *done* this to resolve problems.  If 
there was not sufficient information, it would be impossible.  The fact 
that I and thousands of other people with the knowledge to do this should 
in fact cast sufficient doubt on it being "impossible".

> 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...)

Now we're getting somewhere.

Let's take an example.

Several years ago (almost 20 years ago, in fact), I "broke" a utility 
used for editing a database used to store identity data.  The utility was 
(and is) designed for use by experienced support engineers with specific 
training on the utility, and that utility is not given to the public.

How'd I do it?

With a kernel debugger.

I single-stepped through the machine code, using symbolic information 
available to the kernel debugger, and determined exactly how it worked - 
and in so doing, determined how to extract the password used to protect 
the tool (it was a very poor scheme that has since been changed) and how 
to bypass the time-bombing logic.

The only tool I used was a kernel debugger.

And a bit of persistence. ;)

>>>> 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.

You'd be surprised.  Again, been doing this for 20 years.  Would you 
believe, for example, that *the* Linux kernel driver guy (Greg Kroah-
Hartmann) answers questions in one of the openSUSE forums?

These forums, BTW, are not for developers - generally the developers 
don't visit them.  But Greg takes the time to come out and talk to people 
and answer questions about the openSUSE "rolling upgrade" release (called 
'Tumbleweed').

>>>> 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

Or 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 was sure I'd mentioned it before. :)

>>>> 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].

Perhaps, but then again, I explained the primary reason is because we 
have avenues for those for whom English is not their primary language.

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

That doesn't actually matter at all.  People using it, whether they paid 
money for it or not, are going to want help.  And they get it.

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

Actually, quite a few do.  I often am surprised to hear how many actually 
do use the free version to run a business on.

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

The GPL certainly doesn't forbid it.  Linux - and openSUSE is just a 
Linux distribution - certainly can be used for profit.

That's kinda the point of "Free Software" - you're free to do with it 
what you want.  That's the context of "Free" here - not necessarily "at 
no cost" (gratis), but "libre".

>>> 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.

Exactly.  So online forums such as OSF are there to help people with less 
experience leverage the experience of those with more experience to 
narrow down the problem.

>>> 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??

Of course they do.  They produce products that are used by professionals 
and consumers alike.  Kinda hard to sell stuff if you don't provide 
people with a way to get help when things don't work.

What's more, HP does (or used to) provide support centres for a number of 
other companies - I remember Novell used to use HP for front-line support 
for their products at one time.

>>> 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...)

So you've basically just described the problem in exactly the same way 
that you did initially.  When clarifying questions are asked, that's so 
the problem can be drilled down into.

Computers don't tend to do things for "random" reasons.  They do them for 
a specific reason.  The trick is in figuring out why it's doing what you 
told it to instead of what you want it to do.

>> 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...!)

It certainly is.

But as I said, there are those who can answer questions like that, and a 
hell of a lot of people donate their time to help others with problems.

Jim

Post a reply to this message