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

Orchid XP v8 <voi### [at] devnull> wrote:
> >> 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.

  I didn't say unix users have learned *all* tools via their manpages.
I just said it's the case with many (or even most) tools.

  (As for that particular problem, it's "for F in *; do echo $F; done",
or if you are using zsh, you can also write "for F (*) echo $F".)

-- 
                                                          - Warp

Post a reply to this message

On 23/10/2011 10:48 AM, Warp wrote:

>    I didn't say unix users have learned *all* tools via their manpages.
> I just said it's the case with many (or even most) tools.

YOU didn't, no. But Jim seemed to be strongly hinting at it.

>    (As for that particular problem, it's "for F in *; do echo $F; done",
> or if you are using zsh, you can also write "for F (*) echo $F".)

Just a few lines of example code could have helped me figure this out in 
a few minutes instead of several hours. (And this must surely be a VFAQ 
for shell scripting; it's just about the simplest task you could 
possibly want to script!)

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

Post a reply to this message

On 10/23/2011 1:57, Orchid XP v8 wrote:
> For something trivial like ln or cp,

No. You still have to understand how the file system works and how the 
command line works in order to use them. That's just something you've 
already learned tho.  Come from a DOS or mainframe background and ask "what 
are all these slashes? What's a mount point? Why doesn't it tell me the type 
of the file? How do I set a password or encryption key on this file?"

However, that's all in the man pages too.

http://linux.die.net/man/1/intro

http://linux.die.net/man/2/intro

...

Altho I will say, compared to actual AT&T UNIX, the linux intro man pages 
suck hard.  Not really surprising, given you're *supposed* to have read the 
source code for the kernel. ;-)

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

Post a reply to this message

On 10/23/2011 1:57, Orchid XP v8 wrote:
> **** to execute the same command for every file in the current directory. In

http://stackoverflow.com/questions/2640374/bash-map-equivalent-run-command-on-each-file

Geez, dude. Third hit on google even uses the same words a Haskell 
programmer would use. :-)  It *is* a FAQ. FAQs aren't in man pages. Deal 
with it. :-)


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

Post a reply to this message

On 23/10/2011 05:03 PM, Darren New wrote:
> On 10/23/2011 1:57, Orchid XP v8 wrote:
>> **** to execute the same command for every file in the current
>> directory. In
>
> Geez, dude. Third hit on google

Yes, because the Internet is always accessible. Oh, wait...

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

Post a reply to this message