On Sun, 23 Oct 2011 10:20:30 +0100, Orchid XP v8 wrote:

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

That's a Windows answer to most problems, sadly.  That's not necessarily 
a function of your teammates or their nationality, it's the way Microsoft 
has trained people to "troubleshoot".

> And yes, being the only person in the team who works geographically
> isolated really puts the "me" in "team".

Of course I agree with that.  It can be done, but it takes effort on 
everyone's part, and it seems that your teammates don't think of you as 
part of the team or try to include you.

Finding another job would probably be a good way to do this, but you seem 
to lack the flexibility to make a change - you're rooted to a place and 
are unwilling to relocate, even if the money is far, far better.

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

Your American colleagues, perhaps.  I have family members who actually 
work on cars and would be more than happy to tear a car apart to find out 
what's wrong with it. ;)

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

No, it's not particularly cultural.  Just the type of people they've 
hired in your company's US organisation.

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

What else was the system doing?  I've got a similar system, and I'm sure 
it would compile FF faster than that if nothing else was using the 
system.  If I were watching a video or streaming it to my PS3, I'd expect 
it to be slower.

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

Well, like I said, my experience is somewhat greater than yours.  It's 
not a trivial thing to do, but when I actually did get the source code to 
the program I debugged, I checked, and my guess was right.

Similarly, you can analyse source code to see what call stacks are - have 
a look at source navigator (snavigator) for a tool to do that.  It's a 
very good tool for analysing complex source code - and looking at call 
stacks (and correlating them in a debugger to the code itself).

>>>> You do know what "sarcasm" is, don't you? ;)
>>>
>>> Yes. Perhaps you missed mine? :-P
>>
>> Or perhaps you missed mine. :P
> 
> Ko fight!

I win. ;)

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

You really haven't spent a lot of time in the Linux community, it would 
seem.  Users of Linux really don't care if it isn't working, they get 
just as vocal (if not moreso for some reason) about some things not being 
fixed.  There are quite a few who feel they're entitled to be listened to 
*because* the developers "volunteer" their time.

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

There's that and testing of patches.  The "maintenance" that you get from 
SUSE for the enterprise editions includes tested configurations and 
hardware certification for operation.

Granted, the openSUSE project just announced "openQA", a testing suite 
that provides a similar level of testing of patches that you'd get from a 
commercial distribution, at least as I understand it.

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

But not when it comes to the GPL.  The kernel and many of the utilities 
and programs that make up a distribution also are.  I can't arbitrarily 
decide that you can't have access to it because I want to charge you for 
my particular collection.

That's why Ximian was able to redistribute RedHat's patches back in the 
early 2000's and RedHat couldn't really do anything about it.

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

It depends on the product.  You might look into it (there's no reason for 
me to do so for you, you can navigate the HP site as well as I can).

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

"Standard ISO image of the live CD" doesn't tell me which one (there are 
at least two for openSUSE).  I'd have to look, but the hardware detection 
may well see that it's in a VM and run the GPL'ed VMware tools (I'd have 
to look).

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

That can mean there's a hardware issue (e.g, bad memory), or in the 
program that's running in the VM there's a memory leak or some other 
oddity.

Jim

Post a reply to this message