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

>> 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.]
>
> If it was openSUSE, then it's
>
> /etc/init.d/SuSEfirewall2_setup stop; /etc/init.d/SuSEfirewall2_init stop

OK, I would literally never have guessed that. o_O

> And yes, if you had a package that wasn't in the standard repositories,
> malcolmlewis would likely build it for you using the build service,
> because it *doesn't* actually take hours/days to do so for someone versed
> in how OBS works.

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

>> OK, so how the heck does the debugger know which chunk of unformatted
>> data is the stack?
>
> Various and sundry registers contain that information.  The debugger can
> ask the kernel for information about that - after all, the kernel *must*
> know these things in order to actually execute the program.
>
> So finding these things out is a matter of asking the kernel what it
> knows about the running processes.

OK. So I see how that can work for a running process. I'm not sure how 
it's possible from a memory dump.

>> I don't follow. What do you mean by "structural elements"?
>
> A program follows a certain structure.  When compiled, a program stores
> variable data in a certain space, code in a certain space, and the
> references to those addresses are all known to the kernel, and a debugger
> can learn them by asking the kernel.

I thought the compiled binary is just a flat file containing a list of 
machine opcodes?

>> 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've used virtual machines and emulators, haven't you?  Similar
> principles are at play in a debugger.

Yeah, but a VM doesn't just save the contents of memory, it saves a 
whole bunch of metadata too.

>> 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.
>
> Sometimes managing packages on Windows also falls down.<shrug>

Windows doesn't really "manage" packages. It just runs installers and 
uninstallers, and keeps track of what's installed.

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

>> (I seem to recall POV-Ray doesn't comply with Debian's definition of
>> "free" either, so it's in non-free or something...)
>
> Right.  It's not GPL or under a OSI-approved license, which makes it "non-
> free" according to the FSF.  I gather that's supposed to change in POV-
> Ray 4.0, or it's planned to.

Does POV-Ray actually have more than 1 person working on it any more?

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

> So if you were a member of a LUG in 1957, it's possible, just possible,
> that things have changed since then.

My point is that you make it sound like I tried Linux for 10 minutes, 
couldn't figure it out, and just gave up. That isn't true. And my more 
recent interactions with the so-called "Linux community" haven't lead me 
to change my opinion.

>> 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...
>
> Just like a real machine.  Check out Studio, lots of customisation
> options there.

Where do I find that?

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

>>> 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.
>
> Then it might be worth generalising the question.  Try with a different
> kind of printer, if that doesn't work, then it's not that specific
> printer, but a more general issue.  If it does work, then it may be
> necessary to - instead of talking to Microsoft or MVPs about it - ask the
> printer manufacturer.

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.

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.

>> 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.
>
> Feel free to.  There are some existing discussions over on
> forums.opensuse.org about using VMware and openSUSE together.

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

No, wait - the *first* problem is that 50% of the time when I boot the 
live GNOME CD, the GNOME toolbar doesn't appear. And the other 50% of 
the time it does. Damned strange...

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

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
>  From what I recall, the manpage for Bash practically lists the entire 
> BNF grammar for the scripting language. Great if you're trying to 
> reimplement Bash for some reason, almost useless if you want to actually 
> LEARN HOW TO USE IT.

  You don't have to recall anything. All manpages can be found online with
a simple google search.

> A reference manual is no substitute for an introduction.

  Nobody every claimed that manpages are anything else than reference manuals.
Yet many unix users have learned to use most unix tools via their manpages.

-- 
                                                          - Warp

Post a reply to this message

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.

>>> 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.]
>>
>> If it was openSUSE, then it's
>>
>> /etc/init.d/SuSEfirewall2_setup stop; /etc/init.d/SuSEfirewall2_init
>> stop
> 
> OK, I would literally never have guessed that. o_O

That's a question that would have received a fast answer on OSF.

>> And yes, if you had a package that wasn't in the standard repositories,
>> malcolmlewis would likely build it for you using the build service,
>> because it *doesn't* actually take hours/days to do so for someone
>> versed in how OBS works.
> 
>  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...

Your observations are not accurate for those who have much more 
experience.  Malcolm is very good at what he does, and I don't think I've 
seen an instance where he's not been able to get a package to compile in 
OBS.

But what's more, he's willing to take the time to do stuff like this for 
those who take the time to ask.

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

>>> OK, so how the heck does the debugger know which chunk of unformatted
>>> data is the stack?
>>
>> Various and sundry registers contain that information.  The debugger
>> can ask the kernel for information about that - after all, the kernel
>> *must* know these things in order to actually execute the program.
>>
>> So finding these things out is a matter of asking the kernel what it
>> knows about the running processes.
> 
> 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).

Now, if you are working on a system live, you have this set of data about 
the process (call it 'set a').

If you're working from a coredump, you still have 'set a' about the 
process, and just need something that can do what a life debugger can do.

>> A program follows a certain structure.  When compiled, a program stores
>> variable data in a certain space, code in a certain space, and the
>> references to those addresses are all known to the kernel, and a
>> debugger can learn them by asking the kernel.
> 
> I thought the compiled binary is just a flat file containing a list of
> machine opcodes?

No.  It contains information about variables as well.  In fact, just this 
last week, I was working on documenting configuration file parameters for 
Linux binaries.   First step:  strip the symbolic information out of the 
file (function names and whatnot, since that's only used by the 
debugger).  Second step:  "strings exename > exename.strings"

Presto, all the strings - error messages and whatnot as well - in a text 
file.

Now, given that the parameters follow a particular format, just extract 
those from the output.  Then review with the developer and see which ones 
I need to document.  (In this instance, I'm not permitted to see the 
source code - obviously, if I did, that would be much easier, but this 
was actually pretty trivial to do).

Like I said, a compiled binary has a structure, it's not just 
instructions - it contains data as well.

>>> 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've used virtual machines and emulators, haven't you?  Similar
>> principles are at play in a debugger.
> 
> Yeah, but a VM doesn't just save the contents of memory, it saves a
> whole bunch of metadata too.

*Exactly*.  Programs contain metadata, and a debugger uses that metadata 
(as pulled from a coredump) to help you discover things about the program.

>>> 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.
>>
>> Sometimes managing packages on Windows also falls down.<shrug>
> 
> Windows doesn't really "manage" packages. It just runs installers and
> uninstallers, and keeps track of what's installed.

That does actually count as package management. ;)  Those installers 
know, for example, that .NET Framework 3.5 is required, and if it's not 
installed, they do something (some will install it, some will just fail 
and say "you need to install X").

>> 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 seem to recall POV-Ray doesn't comply with Debian's definition of
>>> "free" either, so it's in non-free or something...)
>>
>> Right.  It's not GPL or under a OSI-approved license, which makes it
>> "non- free" according to the FSF.  I gather that's supposed to change
>> in POV- Ray 4.0, or it's planned to.
> 
> Does POV-Ray actually have more than 1 person working on it any more?

Ask Warp.  Or Clipka.  Or Chris Cason.  Hmmm, there's 3. ;)

But to the original point, to convert it to a GPL license, they have to 
talk to those who contributed earlier code and get their permission (at 
least as I understand it).

>>> 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. (!!)
>>
>> 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? ;)

>> So if you were a member of a LUG in 1957, it's possible, just possible,
>> that things have changed since then.
> 
> My point is that you make it sound like I tried Linux for 10 minutes,
> couldn't figure it out, and just gave up. That isn't true. And my more
> recent interactions with the so-called "Linux community" haven't lead me
> to change my opinion.

I don't make it sound like that.  You do.  And I've told you how/where to 
go to get help the next time you try.

>>> 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...
>>
>> Just like a real machine.  Check out Studio, lots of customisation
>> options there.
> 
> Where do I find that?

http://www.susestudio.com .  It's free to use.

>>> 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.
>>
>> 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.  
Occasionally we have posters who assume we know everything about their 
system, but in general, they get asked for more information, sometimes 
with a joking comment about "my crystal ball seems to be broken, can you 
tell us more about your setup?"

It probably helps that in OSF, we have forums for non-English users so 
they can ask in their native language rather than having to try to write 
in a language they don't know that well.

But some of us also have years of experience in decyphering what someone 
posting in English - when it's not their native language - is asking.  
There are some constructs that are quite predictable.

Your sample, for example, parses as being asked by someone in India, 
especially "how to be making printer to print again?".

So what I'd do is tell them that if they want professional support, they 
might look into SUSE Linux Enterprise, where they can pick up the phone 
and call someone for assistance.  But if they don't want to do that, 
we'll do the best we can to help.  To do so, we need answers to the 
following questions:

1.  What version of openSUSE are you using?
2.  What is the make/model of the printer?
3.  If this was working in the past, what happened between the time the 
printer worked and the time it didn't?

(Question 3 is crucial - if something worked and then it didn't, 
*something* changed. Troubleshooting is about figuring out what it was 
that changed)

Yeah, I've done this a few times over the past 20 years. ;)

>>>> 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.
>>
>> Then it might be worth generalising the question.  Try with a different
>> kind of printer, if that doesn't work, then it's not that specific
>> printer, but a more general issue.  If it does work, then it may be
>> necessary to - instead of talking to Microsoft or MVPs about it - ask
>> the printer manufacturer.
> 
> 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).

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

>>> 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.
>>
>> Feel free to.  There are some existing discussions over on
>> forums.opensuse.org about using VMware and openSUSE together.
> 
> 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.

My point isn't to answer the question here (this isn't the right venue), 
but to show you that it's not just a question of:

"X is broken, how do I fix it?"

"Oh, you just need to splunge the flange, and then it'll work fine."

It sometimes is that simple, but IME it rarely is these days.

> No, wait - the *first* problem is that 50% of the time when I boot the
> live GNOME CD, the GNOME toolbar doesn't appear. And the other 50% of
> the time it does. Damned strange...

Well, and there again, I'd be asking things like which version, what 
hardware, and similar things.

Jim

Post a reply to this message

On Sat, 22 Oct 2011 10:32:38 +0100, Orchid XP v8 wrote:

>>> Well, you know, that's what manpages do. They give you a terse
>>> reference to the bare essentials of what a tool does. That doesn't
>>> seem like much of an "assumption" to me.
>>
>> I learned to script in bash using the manpage.  That's not exactly a
>> terse one - again, hard to generalise about this kind of thing.
> 
>  From what I recall, the manpage for Bash practically lists the entire
> BNF grammar for the scripting language. Great if you're trying to
> reimplement Bash for some reason, almost useless if you want to actually
> LEARN HOW TO USE IT.

It is a comprehensive reference for the language, yes.  Learning how to 
use it is like learning how to use any programming language.

> A reference manual is no substitute for an introduction.

True, but I didn't need an introduction.  I suspect you wouldn't need an 
introduction to programming either, if you approached it the way I did.

In this particular instance, it was during a hands-on certification 
exam.  I worked out pseudocode for what I wanted the script to do, and 
then used the manpage to figure out the syntax.

Note that I wouldn't recommend that anyone try to learn a scripting 
language while taking a certification exam - I just happened to be in 
that situation, and while I was making a serious attempt at the exam (and 
I did pass, though not with full points for the script I wrote), I wasn't 
concerned about cost or having to take it again.  Most people would be.

Jim

Post a reply to this message

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

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

On 10/21/2011 15:29, Jim Henderson wrote:
>> over the web. I'm honestly not sure why they felt the need to add
>> support in firefox, but there you have it.
>
> Probably to avoid accusations of acting in a non-competitive manner or
> something like that.

I meant, I don't know what the support for firefox was, given that click 
once works in browsers without that plug-in.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

On 10/22/2011 2:32, Orchid XP v8 wrote:
> A reference manual is no substitute for an introduction.

I think it depends on how well organized things are in the documentation and 
in what you're trying to learn. Most of the programming langauges I learned, 
I learned by reading the reference manuals.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

>> A reference manual is no substitute for an introduction.
>
>    Nobody every claimed that manpages are anything else than reference manuals.
> Yet many unix users have learned to use most unix tools via their manpages.

So it's not an introduction, and yet it's how most users introduce 
themselves?

Now don't get me wrong. For something trivial like ln or cp, the 
reference manual is probably all you need. There's not much to learn, 
after all. But for something as complex as Bash, some examples and 
exposition would really help tremendously... I wasted literally *hours* 
trying to work out how the **** to execute the same command for every 
file in the current directory. In the end I was forced to do it by hand.

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

Post a reply to this message

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

It just urks me that I'm part of a team of so-called computer experts, 
and everybody's answer to everything is "did you try rebooting it?" Not 
"hey, let me engage my brain for 15 seconds and see if I can come up 
with a real answer", just "did you try rebooting it?"

And yes, being the only person in the team who works geographically 
isolated really puts the "me" in "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. ;)

Perhaps an analogy: Takings slightly to extremes, if a car engine broke 
down, I'd take the entire thing apart down to the component level to try 
to figure out what's wrong with it, while the Americans would just buy 
an entire new car and be done with it. Argue amongst yourselves which 
approach is better.

Of course, that's an exaggeration. But those guys do seem reluctant to 
throw any real thought power at the problem when you can just replace 
stuff and see if that fixes it. Maybe they're just busier than me... 
seems to be a cultural thing though.

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

No, this was on the same PC I'm using right now - AMD Athlon64 X2 4200+ 
2.2 GHz with 3 GB RAM.

> The only tool I used was a kernel debugger.
>
> And a bit of persistence. ;)

In my experience (which, again, is quite limited), it's extremely hard 
to figure out what disassembled code does without source code to compare 
to - and that's on the Motorola 68000 platform, which has sane machine 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
>
> Or perhaps you missed mine. :P

Ko fight!

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

Sure. But people who've paid money for something sometimes have this 
attitude of "this piece of crap you sold me isn't working - FIX IT!" 
Whereas most people who get something for free are a little less 
self-righteous about it. (Although not always, sadly...)

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

As I understand it, the only difference between that and the commercial 
version is the level of support involved.

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

Sure. That's the general idea of a free license. But some licenses are 
freer than others. And different distros have different ideas about 
that. (See, again, Debian classifying POV-Ray as non-free.)

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

Sure, but presumably they only *support* your products if you pay for an 
expensive support package?

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

The fact that I'm running from the standard ISO image of the live CD 
tells you it doesn't have any VM tools installed. (Unless there are any 
present on the disk itself.) I'll admit I forgot to include the version 
numbers.

> Computers don't tend to do things for "random" reasons.

This is why it disturbs me so when a computer does something for no 
apparent reason. Like booting the same VM multiple times, when it can 
have no record of what happened before, and yet seeing a different 
result each time...

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

Post a reply to this message