On Wed, 19 Oct 2011 22:30:13 +0100, Orchid XP v8 wrote:

>>> Right. Well knowing what the command switches are isn't going to help
>>> me configure Apache, is it?
>>
>> Yes, it won't.  But if you want to configure apache, you read the
>> Apache documentation.
> 
> ...which will only tell you how to do it via the configuration file
> interface which you keep insisting it isn't necessary to touch.

Which is why you use the HELP button.

>> Or if you've got the yast http module installed, you can try yast2
>> http- server longhelp for command-line help.
> 
> Which presumable again just tells you about command switches, not how to
> configure Apache using YaST.

Try it.  It's more than that, again, pay attention to those who actually 
have used it instead of making assumptions and then declaring those 
assumptions to be true, regardless of how true you believe them to be.

BTW, you do know the world is not in fact flat, right?  Just checking. ;)

>>> If somebody told you that the Earth is in fact flat, would you take
>>> the time to sit down and have a rational conversation with them? Or
>>> would you just be like "psssh, yeah RIGHT! Bye..."
>>
>> So, to carry the analogy out, you believe the "Earth is flat" and
>> you're not willing to be convinced otherwise?
> 
> More like you keep insisting that the Earth is flat, and then act all
> surprised when I don't immediately believe you.

Except that I'm telling you the Earth is round, and you're insisting that 
it's flat.  (Your ideas are not based on current implementation; if they 
were, you'd see that they're incorrect).

>> Um, nobody's saying that.  What I'm saying is that if you ask questions
>> on relevant forums, you can actually get help to configure it and learn
>> how it works.
> 
> I know how it works - not very well. (In varing degrees, anyway.) What's
> to ask?

*sigh*

You don't know how it works.  You have an opinion about how well it 
works.  How well it works != how it works.

>> Unless you'd rather just bitch about how impossible everything is.
> 
> Let's be clear about this: I said that package management can be a pain
> sometimes. WHICH IS TRUE. I didn't say it was *impossible* to install
> anything. I just said sometimes it's very difficult to make it do the
> correct thing.
> 
> I pointed out a small deficiency in a piece of software, and everybody
> is like "no, you're just too stupid to work it correctly". As if no
> software ever has deficiencies...

Yes, package management can be a pain sometimes.  But you've also claimed 
that it's impossible to learn how to manage apache using YaST.  It isn't, 
as evidenced by the thousands of people who *do just that*.

>> But you seem to enjoy learning new things.  Which means more than just
>> reading books and websites - occasionally it means talking to people
>> who know more about the topic than you do.
>>
>> See how that works?
> 
> Reading documentation can be quite enlightening - or not. It depends on
> how good the documentation is. IME, asking people is almost always an
> utter waste of time.

Yeah, again, because I've only spent 20 years answering questions on 
online forums, and I *love* wasting my time.

I accept that your experience has not been so good.  I'm telling you it 
isn't always that way and that you could certainly try over in the 
openSUSE forums when you have questions about openSUSE.  I tell you this 
because we have a significant number of users who *have* received help 
and *have* been able to make things work after being told how to use the 
software.

You continuing to deny that you could ever possibly get help in an online 
forum by asking questions, when you're told that there is a place you can 
ask questions and generally people are VERY HAPPY when they get 
answers....well, it's just silly.

Your experience can change, but only if you continue to try asking 
questions.  Giving up because you've had little to no success in the past 
isn't ever going to get you out of that rut.

Just like searching for a job - if you stop searching, nobody's ever 
going to offer you something better.

>> When I pointed out that, hey, there are some tools (some of which are
>> in fact standardised across different distributions) that mean you
>> *don't* have to edit text files, you responded with incredulity.
> 
> The standard Unix philosophy is that programs are controlled mainly via
> the command line and via textual configuration files. Does every single
> piece of software available for Linux follow this model? No. Do the vast
> majority of them follow this model? Yes.

*No*.  That's my point.  Low level system stuff, yes; end-user 
applications DO NOT DO THIS.

>> My point is that while hard-core *nix utilities do tend to be that way,
>> it's a mistake to think that that's the *only* way Linux programs are
>> created - as a front-end to some cryptic CLI interface.
> 
> OK, fair enough.

*Finally*, I think we're making progress. ;)

Jim

Post a reply to this message

On Wed, 19 Oct 2011 22:21:31 +0100, Orchid XP v8 wrote:

>>>> When I'm giving technical interviews, you might recall, I ask
>>>> questions I know the candidate doesn't stand a chance of asking.  The
>>>> reason I do this is to find out how they learn beyond their current
>>>> skill.
>>>
>>> That's kind of evil. I'm not sure how somebody sitting in an interview
>>> chair is supposed to solve a problem right there on the spot. I mean,
>>> it's not like they can go away and look stuff up...
>>
>> I don't ask them to solve it.  I ask *how* they would solve it, and
>> what resources they would use.
> 
> Well, OK... but since the only possible answer is "I would go read the
> manual and/or search Google", that doesn't seem like a particularly
> searching question.
> 
> Either that or I just failed to get hired - again...

That is a legitimate answer.  It isn't the only answer, though - because 
one could ask people with more experience.  They could get in touch with 
teammates who know the systems better, or with people they know from 
other companies.  They could ask at a user group meeting (if it's not a 
critical system-down issue, obviously - waiting until your next LUG 
meeting isn't really good if the users can't work).

Point is, there are many options.

>>> If I wanted to know how to live forever, I wouldn't bother posting a
>>> question in an online forum. You know why? Because... it's...
>>> impossible. It's not that I don't know how, it's that IT CANNOT BE
>>> DONE.
>>
>> But if you want to know how to configure Apache on Linux, *that is NOT
>> impossible*.
> 
> Sure. You just need to read through the manual for a while. The question
> at hand was "is it possible to make the package manager do what you
> want?" To which the answer is "no, not really".

The answer is "it depends on what you want to make the package manager 
do".

And if I want to know how to configure a specific aspect of Apache, say, 
enabling PHP5 on it, I look at the relevant Apache docs, compare to 
what's in YaST or Webmin, and if it doesn't make sense, I ask a question.

While waiting for an answer to the question, I continue to research.

>> So why wouldn't you bother asking a question in an online forum in that
>> instance?
> 
> IME, if you ask anything more complicated than "why doesn't Flash
> work?", either nobody understands the question, or nobody has the
> answer. Most likely you'll just get no reply at all. Or maybe one reply
> from a guy who doesn't speak English well. None of which helps fix the
> problem...

*sigh*

Again, because of course, I have enjoyed wasting 20 years of my life 
helping people in online forums.

Yes, your experience varies from mine.  I'm telling you that it needn't 
be that way.

I had a problem with openSUSE 12.1's support of the Radeon X300 video 
controller in my laptop.  I asked a question.  I got an answer that 
pointed me to a bug indicating a known issue.  I got a follow-up answer 
that a newer kernel seems to have fixed it, and asked if anyone could 
confirm.

This evening, I got an answer from someone saying that one issue seems to 
be fixed, but there's still some video corruption, indicating it's not 
completely solved.

But it's being worked on, and I'm learning more about what's going on 
with the issue.

Now, did I waste my time?  You tell me.  Remember that it's beta and the 
fix is in progress, though, before you answer that question.

>>> So hypothetically it's *possible* to
>>> work around any given distro's poor dependency management. Does that
>>> mean I actually want to go to such extremes? Not really, no.
>>
>> And you *don't have to*.  So, what you're saying is that if you want to
>> figure something out, you try the absolute most difficult way of doing
>> it, and then declare it impossible?
>>
>> Why not try the *easiest* way to do it, and if it doesn't make sense,
>> ask a few questions so you can learn?
> 
> The problem is pretty simple: The package manager tracks dependencies on
> a rather coarse level. (In some instances. Sometimes it's fine,
> sometimes it's less than ideal.) Either you just put up with it, or you
> bypass the package manager, which is stupendously difficult.

It's not really that difficult to "bypass" the package manager, but it 
can create more problems for you.  (rpm -ihv --nodeps is one way to 
bypass; download the source and compile is another.  The first is easier, 
but may lead to a non-working package.  The latter may uncover some 
dependency conflicts in library versions etc.)

But if you're having difficulty with dependency resolution, you ask a 
question about it and then perhaps someone builds the package for you.

I hear you laughing.  Don't.  We've got a guy over in the openSUSE forums 
who does this for people who need a package built for their installation 
if there's no pre-built RPM available.  His user ID is malcolmlewis, and 
he's been happy to do this for anyone who asks.

He uses the Open Build Service (build.opensuse.org), which incidentally, 
can build packages not just for openSUSE, but for many distributions - 
including Debian, Ubuntu, Redhat, CentOS, SUSE Linux Enterprise, 
openSUSE, and probably a few others.

> I'm not sure what you think there is to "learn" here. It's not like I
> don't know why the problem exists or what causes it.

You don't know how to deal with it.  That's what there is to learn; you 
think you just have to live with it, but you don't always have to do that.

>>> I still don't get how you can take megabytes of unformatted raw binary
>>> and glean anything remotely useful from it, but hey. Apparently
>>> there's some kind of black magic that makes this possible...
>>
>> It's called education.  It's also not unformatted - the format of a
>> stack dump is known, you just need to know how to interpret it.
> 
> How do you know which part is the stack? How do you know which parts are
> code and which parts are data? How do you know where in the program the
> processor was executing?

The debugger tells you those things, especially if you are in a live 
kernel debugging session.

> You say "the format of a stack dump is known", except that... no, it
> isn't. The stack holds whatever arbitrary data the program decides to
> write to it. Without knowing how the program works, how can you get
> anything useful out of that?

Well, yes, it is.  Because you have structural elements from the software 
known to the debugger.  You frequently have symbolic debug information 
available to you.  You may refuse to believe this, but I know it from 
having *actually done it*.

The CPU "knows" how to process the instructions, and it knows what the 
data is that's going through it.  It "knows" what functions it's running, 
what the call stack is, and how to return to the previous functions.

A kernel debugger just gives you the tools to ask the CPU what it's doing 
in a particular stack frame.

It really *isn't* rocket science.

>> Straw man alert.  Learning to read a stack dump is not like punching a
>> brick wall.  Learning to configure apache is not like punching a brick
>> wall.  Learning how to use Linux is - you guessed it - NOT LIKE
>> PUNCHING A FRIGGING BRICK WALL!
>>
>> Stop drawing false equivalencies.
> 
> My point being, if you're trying to do something that's clearly
> infeasible, do you continue trying to do it? Or do you go try some other
> approach?

If it is clearly infeasible, then how come so many people actually 
succeed at using it?

>>> If you try something, and it doesn't work, you can keep trying it over
>>> and over again, or you can try something else. Which option is the
>>> most rational?
>>
>> Neither - asking for help is the most rational option if it's something
>> you think is important enough to try to learn in the first place.
> 
> And if "asking for help" is the thing that isn't working?

Then ask for help asking for help.  Posit - a user opens a bug in 
bugzilla, but doesn't know what information is useful to the developer.  
You can either open the bug and say "I don't know what would be useful to 
help debug this, if you tell me what and how to get it, I'll get that 
information for you", you've just asked how to ask for help.

Have you read Eric Raymond's essay on "asking questions the intelligent 
way"?  (I believe that's the title).  It's a very good overview on how to 
get help in online forums, mailing lists, IRC, whatever.

For example, ESR says (quite truthfully) that if you ask someone to read 
the manual to you, you're not likely to get help.  If you say "I've read 
the manual on this, and am having trouble parsing it", you're more likely 
to get help.  If you don't assume an outcome ("I'm having trouble with my 
video resolution and think it's due to microfractures on my motherboard, 
how do I repair those motherboard problems") but say something like "I'm 
having video problems, here is what my video controller is, operating 
system and release, and drivers - and here is what I've tried so far", 
you're likely to get help.

>>> Package managers track package dependencies. Packaging teams write
>>> those dependencies. Sometimes their structure is a little coarse. What
>>> more is there to learn?
>>
>> That "sometimes" doesn't mean "always", for a start.
> 
> Sure. I didn't say it *never* works right. I said that sometimes it
> doesn't, and then it's a real pain to deal with.

So if it's being a pain, ask if that's normal, and if it isn't, then 
there's a problem to fix.  If it is in that instance, then you know it's 
expected behaviour.

You seem to be saying "it's a pain" and assuming that it's expected to be 
that way.  There may actually be an underlying problem that needs to be 
fixed that would make it less of a pain for you.  But you'd rather 
complain, apparently, that it's a pain.

That's what's frustrating me in this conversation.

>> It isn't always a
>> question of packaging, for example - it can be a question of what
>> components are compiled together into a single library.
> 
> Every distro manages their stuff in a slightly different way. I seem to
> recall that if you installed POV-Ray under Debian, it used to insist on
> installing PVM, because the Debian POV-Ray package was a heavily
> modified PVM-patch of the official POV-Ray sources or something weird
> like that. (I presume this has been fixed now...)

It may have been.  Or you could install povray from the sources or a 
binary package here.  Then you get the latest version that Chris & team 
have put together, and you don't have to deal with the Debian dependency 
issues.

>> The OSS model actually doesn't mean that "anyone can contribute", but
>> rather that those who demonstrate skills can.  They don't call it a
>> 'meritocracy' for nothing. :)
> 
> Actually I've never heard anybody call it that, but sure, whatever.

Well, look up the term - you'll learn more about how patching actually 
works in many OSS projects.

Some projects do tend towards more monolithic management (where one 
person leads and codes), but larger projects do tend towards the idea 
that you can contribute if you prove yourself.

> People say "if you want something fixed, file a bug report". IME, this
> achieves next to nothing. Last time I filed a bug against something on
> Linux, a got one or two replies from the dev team, and then I heard
> nothing for THREE YEARS, and then I got an email saying they think
> they've fixed it and could I test it? I mean, I stopped using that
> package and that distro two years ago... like I *care* anymore!

Sometimes that happens.  It depends on the severity of the bug and how 
frequently it happens or is reported.

A bug that one person once saw a couple years ago but nobody else has 
reported an issue with isn't likely to get attention.

A video problem (like my radeon driver bug) affects lots of people and 
clearly is a serious issue.  It's actually getting attention right now 
before the oS 12.1 release.

>> If you've never committed code to the kernel, Linus isn't likely to let
>> you rewrite an entire subsystem to suit your needs.  But if you write
>> patches/fixes for known bugs and your code is good, yes, you can get
>> into the team that does the work.
> 
> I've submitted patches to product documentation. Like, literally, all
> somebody has to do is check that my DocBook markup is sane, and that the
> few paragraphs I've changed are factually correct, and then hit "merge".
> They HAVE the patch right there. I've done all the work of finding the
> right source files, filling in the right info, and so forth, so all the
> busy dev team has to do it hit a button instead of spending five minutes
> writing the stuff themselves.
> 
> It still took 6 months for the changes to get applied. Just because
> that's how long it took for my patch to be looked at. I guess since it
> was only documentation, it was low priority. (Compared to patches for
> stuff that are actually stopping people doing stuff...)

Doc is a lower priority, which isn't a good thing - but it's also 
necessary for doc patches to be reviewed for accuracy.

> All I'm saying, people say "well it's open source, if you don't like it,
> you can fix it". Erm, no. No you can't. Unless you're very fortunate.

You can always write a patch for the code you're running and submit it 
upstream.  If it works for you as you've patched it, you've done what you 
should.  If you distribute the code with your patch, you have to make 
your patch available (if it's GPL'ed code that you're modifying), but if 
you don't distribute it, you're not actually legally required to 
distribute your patch, and you can certainly run the code on your own 
system with your own customisations.

So yes, you can fix it if you don't like it.  The dev team also isn't 
obligated to accept your patch, but that doesn't mean your patch can't be 
used in your system and that you can't share it independently of their 
code distribution.

>>> Of course, initially Linux was a total PITA to set up and actually
>>> use.
>>
>> At the time it came out, maybe 10 years ago for that matter (half it's
>> life), that was true.  It's much less true now.
> 
> Sure. I thought I wrote that somewhere...
> 
> There's an old joke that "Ubuntu" is an African word meaning "I can't
> install Debian". And, let's face it, the first time I tried to install
> Debian, it was a highly complex process. Today things are much simpler;
> often you can run Linux without even /bothering/ to install it. Heck,
> sometimes you don't even need to reboot...

I've heard that joke before.  It's a good one.  (says the openSUSE guy) ;)

>> Which is why there's a community to help you out when you have issues.
> 
> In my experience, the "community" is absolutely useless.

I can't see that you've asked any questions in the openSUSE or SUSE 
communities about your upgrade woes.  Seems there's an avenue that you 
haven't looked at.  So I'm not sure how you can say the openSUSE 
community is useless, as you haven't tried it.

>> I installed openSUSE 12.1 Beta 1 on my laptop.  The video went all
>> wonky.  What did I do?  I posted a question on the openSUSE forums
>> (where I'm staff) and asked if anyone else had seen the issue.  Turns
>> out there's a bug submitted for it, and in a more recent kernel being
>> tested, it's supposed to be fixed now.
>>
>> So, I asked a question and learned (a) that it's a known issue, (b)
>> it's being worked on, and (c) a fix has probably been committed that I
>> can test out.
>>
>> So when I have a chance, I'm going to try that fix and report back
>> whether it worked or not.
>>
>> What I *didn't* do was just declare "it's hopeless to get this to work"
>> and give up.
>>
>> See how that works?
> 
> Now, see, I would have just assumed "It's a beta. It's not supposed to
> actually work. Obviously there's nothing I can do about this. I should
> go try a different version or something." Because, let's face it, I know
> nothing about how device drivers work in Linux, and if the masterminds
> who put SUSE together couldn't get this right, there's no way in hell
> that *I* can possibly fix it. So that's the end of that.

I don't know much about how device drivers work either, but there's a 
reason betas are released publicly.  So people can try them and report 
issues they have so they can get fixed before release.

It's not about you or me being able to fix a radeon driver issue.  It's 
about being able to say "hey, this doesn't work" and having someone look 
at it.  Something like this video issue, I asked because if it's more 
than just my lowly X300 card, it's an important issue to get addressed.

If it were just my system, I'd probably still raise an issue because the 
same driver on the 2.6.xx kernel in 11.4 works flawlessly.  12.1 uses the 
new 3.1 kernel, so it's probably a kernel driver issue, and that's 
something that the openSUSE folks will report upstream to the kernel dev 
team (if they're not actually on the kernel dev team already).

Point is, if you use it and don't report the problem, unless someone else 
has the issue and reports it, it's guaranteed not to get looked at.

>>> Over time, however, I came to realise that Linux doesn't actually seem
>>> to be much more efficient than Windows. That used to be one of the big
>>> things people talked about: you can run Linux on a 283 with 16MB RAM,
>>> and it WORKS, and it WORK WELL. Try doing that with Windows! But you
>>> know what? It's a long time since I've seen a distro that can still do
>>> that.
>>
>> Puppy Linux, Damn Small Linux...there are a few left, but yes, most
>> kernel developers have moved on from providing 286 support, because
>> there's not much call for it.
> 
> Most of them seem to start at 386 and up. (Having recently looked at the
> IA32 reference manuals, I now understand why...)

There are some pretty significant differences, yes.

> I don't suppose you happen to know of a distro that's particularly
> optimised for running in a VM?

Depends on what you want to do with it.  Custom SUSE builds done in 
Studio can be built as a VMDK or OVM (I think is the extension) format 
for use in virtual environments.

>>> Essentially, things have evolved to the point where you can compare
>>> Windows and Linux, and see that each of them actually have merits
>>> compared to the other. And the point we're currently arguing about is
>>> one of them. On Windows, you just *install* stuff, and it works. Under
>>> Linux, you try to install stuff, and mostly it just works... except
>>> when it doesn't. And then all hell breaks lose.
>>
>> And when it doesn't work on Windows or Linux, one asks questions to get
>> help.
> 
> Getting help for Windows is roughly as difficult as getting help for
> Linux. If you ask a question, typically an MSVP will point you to a KB
> article. This may or may not be relevant to what you actually asked, and
> may or may not actually fix your problem. If it does fix it, it usually
> works great. If there isn't a KB article about your specific issue...
> good luck!

The Microsoft MVPs generally do a good job answering questions in the 
Microsoft forums, from what I've seen.

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.

>> And I would debate "all hell breaks loose" with Linux when it doesn't.
>> When it doesn't, it doesn't.  Usually (for me) on the rare occasions it
>> happens, it's a missing dependency, and that's pretty easy to figure
>> out these days.
> 
> So you've never had the package manager try to replace glibc and utterly
> break your install to the point where you have to replace the entire OS?

Nope, I haven't.  Because when I update using the package manager, it 
tells me what is going to need to change because of the glibc update/
change, and if it's not acceptable to me, I refuse the update.

> Or you mean you've learned what I learned: if it mentions touching
> glibc, abort the operation. (?)

It means look at the possible effects.

>> Well, it irritates several of us when you say "it's f-ing
>> impossible!@!!@! @!!" when in fact it's not, and you just haven't asked
>> for help.
> 
> It irritates me when people say something is possible when it damned
> well isn't. :-P

Except that it *is*, otherwise, how is it that millions of people use 
Linux every single stinking day?

>> There's *always* someone with more experience.  In the Linux community,
>> most of those with more experience are more than happy to help those
>> with less, but in order to get that help, you have to ASK for it.
> 
> Like I said, when I ask, nobody helps.

Come over to the openSUSE forums and ask for help when you're next using 
openSUSE.  You'll *probably* be pleasantly surprised.

If you don't ask, you're *guaranteed* not to get any help.

It's like the old joke about playing the lottery - you have to play to 
win.  Except the odds of getting a useful answer on a Linux forum are 
far, *FAR* better than the odds of winning the lottery.

Jim

Post a reply to this message

On 10/19/2011 18:30, Jim Henderson wrote:
> Oh, I see. :)  That's what I get for being overtired for the past week

Yeah, no problem. Lots of people *try* to turn conversations into debates. 
Certainly I'm not going to mind that you thought I was doing that. :-)

> Ah, *that* thing.  I hadn't heard it called that, just heard about the MS
> extensions being installed without the user being asked. :)

Yeah. It's their package manager for applications you install and update 
over the web. I'm honestly not sure why they felt the need to add support in 
firefox, but there you have it.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 10/19/2011 12:04, Jim Henderson wrote:
> Well, sure, you'd have to put them someplace where IIS won't look at it.
> With Apache, the same holds true - if you want to put it someplace where
> Apache won't care, don't put it in /etc/apache2. :)

Does Apache load all configuration files in /etc/apache2? I thought there 
were like include directives or something.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

>>> I don't ask them to solve it.  I ask *how* they would solve it, and
>>> what resources they would use.
>>
>> Well, OK... but since the only possible answer is "I would go read the
>> manual and/or search Google", that doesn't seem like a particularly
>> searching question.
>>
>> Either that or I just failed to get hired - again...
>
> That is a legitimate answer.  It isn't the only answer, though - because
> one could ask people with more experience.  They could get in touch with
> teammates who know the systems better, or with people they know from
> other companies.  They could ask at a user group meeting (if it's not a
> critical system-down issue, obviously - waiting until your next LUG
> meeting isn't really good if the users can't work).
>
> Point is, there are many options.

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

> Yes, your experience varies from mine.  I'm telling you that it needn't
> be that way.

Well, like I say, short of spending 10 years using Linux and seeing if 
anything is different this time, there's not really any way for me to 
verify your claim objectively. Either I believe you or I don't.

> Now, did I waste my time?  You tell me.  Remember that it's beta and the
> fix is in progress, though, before you answer that question.

Now, again, I wouldn't have even attempted to use a beta version in the 
first place. (But then, that's why they label it as beta. If you don't 
want the risk, you don't use it. If the risk is acceptable, you try it 
out...)

> But if you're having difficulty with dependency resolution, you ask a
> question about it and then perhaps someone builds the package for you.

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

Can you see why I might be reluctant to believe this?

>> How do you know which part is the stack? How do you know which parts are
>> code and which parts are data? How do you know where in the program the
>> processor was executing?
>
> The debugger tells you those things, especially if you are in a live
> kernel debugging session.

OK, so how the heck does the debugger know which chunk of unformatted 
data is the stack?

>> You say "the format of a stack dump is known", except that... no, it
>> isn't. The stack holds whatever arbitrary data the program decides to
>> write to it. Without knowing how the program works, how can you get
>> anything useful out of that?
>
> Well, yes, it is.  Because you have structural elements from the software
> known to the debugger.

I don't follow. What do you mean by "structural elements"?

> A kernel debugger just gives you the tools to ask the CPU what it's doing
> in a particular stack frame.

Wait - you mean the debugger can actually see what the processor is 
doing, not just what's in memory?

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 seem to be saying "it's a pain" and assuming that it's expected to be
> that way.  There may actually be an underlying problem that needs to be
> fixed that would make it less of a pain for you.  But you'd rather
> complain, apparently, that it's a pain.
>
> That's what's frustrating me in this conversation.

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.

>> Every distro manages their stuff in a slightly different way. I seem to
>> recall that if you installed POV-Ray under Debian, it used to insist on
>> installing PVM, because the Debian POV-Ray package was a heavily
>> modified PVM-patch of the official POV-Ray sources or something weird
>> like that. (I presume this has been fixed now...)
>
> It may have been.  Or you could install povray from the sources or a
> binary package here.  Then you get the latest version that Chris&  team
> have put together, and you don't have to deal with the Debian dependency
> issues.

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.

Regardless, hopefully Debian fixed this particular stupidity long ago. 
(I seem to recall POV-Ray doesn't comply with Debian's definition of 
"free" either, so it's in non-free or something...)

>> People say "if you want something fixed, file a bug report". IME, this
>> achieves next to nothing. Last time I filed a bug against something on
>> Linux, a got one or two replies from the dev team, and then I heard
>> nothing for THREE YEARS, and then I got an email saying they think
>> they've fixed it and could I test it? I mean, I stopped using that
>> package and that distro two years ago... like I *care* anymore!
>
> Sometimes that happens.  It depends on the severity of the bug and how
> frequently it happens or is reported.
>
> A bug that one person once saw a couple years ago but nobody else has
> reported an issue with isn't likely to get attention.

In fairness, looking back at the ticket, the actual issue was that 
such-and-such a package doesn't work properly on AMD64. The issue 
presumably was upstream (i.e., it isn't Gentoo's fault that SmartEiffel 
doesn't run correctly on AMD64). That probably doesn't help. Plus I 
doubt SmartEiffel is insanely popular.

>> All I'm saying, people say "well it's open source, if you don't like it,
>> you can fix it". Erm, no. No you can't. Unless you're very fortunate.
>
> You can always write a patch for the code you're running and submit it
> upstream.

> So yes, you can fix it if you don't like it.

Not if you don't speak C you can't. :-P

>> There's an old joke that "Ubuntu" is an African word meaning "I can't
>> install Debian". And, let's face it, the first time I tried to install
>> Debian, it was a highly complex process.
>
> I've heard that joke before.  It's a good one.  (says the openSUSE guy) ;)

Heh. Made me chuckle when I first heard it.

I still think dselect is horrid! >_<

>>> Which is why there's a community to help you out when you have issues.
>>
>> In my experience, the "community" is absolutely useless.
>
> I can't see that you've asked any questions in the openSUSE or SUSE
> communities about your upgrade woes.

I didn't mean any specific Linux community. I just offhandedly meant 
"every one that I've tried".

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

The guys in the LUG were very friendly and everything. It's just that 
they never had the slightest clue how to fix my problems, or even where 
to start looking. Every suggestion I got from them always started with 
"man" followed by a command name...

>> Now, see, I would have just assumed "It's a beta. It's not supposed to
>> actually work. Obviously there's nothing I can do about this. I should
>> go try a different version or something." Because, let's face it, I know
>> nothing about how device drivers work in Linux, and if the masterminds
>> who put SUSE together couldn't get this right, there's no way in hell
>> that *I* can possibly fix it. So that's the end of that.
>
> I don't know much about how device drivers work either, but there's a
> reason betas are released publicly.  So people can try them and report
> issues they have so they can get fixed before release.

> Point is, if you use it and don't report the problem, unless someone else
> has the issue and reports it, it's guaranteed not to get looked at.

Again, if a video driver for a very common video card doesn't work, I 
would assume this has already been reported multiple times over.

>> Most of them seem to start at 386 and up. (Having recently looked at the
>> IA32 reference manuals, I now understand why...)
>
> There are some pretty significant differences, yes.

Virtual memory being the big one...

>> I don't suppose you happen to know of a distro that's particularly
>> optimised for running in a VM?
>
> Depends on what you want to do with it.  Custom SUSE builds done in
> Studio can be built as a VMDK or OVM (I think is the extension) format
> for use in virtual environments.

I'm thinking more about the fact that if you do a default install of 
[any distro you care to mention], it installs power management 
utilities, firmware updates, scanner and webcame capture software, and 
all sorts of other hardware-related stuff which is simply useless on a 
VM. So first you have to wait for all this lot to download, and then you 
have to spend time uninstalling it again.

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

>> Getting help for Windows is roughly as difficult as getting help for
>> Linux. If you ask a question, typically an MSVP will point you to a KB
>> article. This may or may not be relevant to what you actually asked, and
>> may or may not actually fix your problem. If it does fix it, it usually
>> works great. If there isn't a KB article about your specific issue...
>> good luck!
>
> The Microsoft MVPs generally do a good job answering questions in the
> Microsoft forums, from what I've seen.

Some of the stuff written my MVPs is quite enlightening. For example, I 
once found [and will probably never find again] a website dedicated to 
MS Word glitches. It actually explains several interesting points which 
aren't mentioned in the documentation anywhere. Very useful stuff.

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. (Of course, with most of these things there's always the potential 
for the problem being some 3rd party software that a Microsoft expert 
isn't going to know anything about...)

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

>> So you've never had the package manager try to replace glibc and utterly
>> break your install to the point where you have to replace the entire OS?
>
> Nope, I haven't.

That's pretty impressive.

>>> Well, it irritates several of us when you say "it's f-ing
>>> impossible!@!!@! @!!" when in fact it's not, and you just haven't asked
>>> for help.
>>
>> It irritates me when people say something is possible when it damned
>> well isn't. :-P
>
> Except that it *is*, otherwise, how is it that millions of people use
> Linux every single stinking day?

I didn't say it's impossible to use Linux. Heck *I* do that! I said in 
certain situations it's impossible to make the package manager do what 
you want.

>> Like I said, when I ask, nobody helps.
>
> Come over to the openSUSE forums and ask for help when you're next using
> openSUSE.  You'll *probably* be pleasantly surprised.

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.

(OTOH, I'm not looking forward to setting up yet *another* account on 
yet *another* forum... Like I don't have enough of those yet!)

> It's like the old joke about playing the lottery - you have to play to
> win.

Except that if you don't play, the probability of winning is zero, and 
if you do play, the probability of winning is so close to zero as to be 
effectively zero for all practical purposes.

Can you tell why I don't play the lottery?

Post a reply to this message

>>> Or if you've got the yast http module installed, you can try yast2
>>> http- server longhelp for command-line help.
>>
>> Which presumable again just tells you about command switches, not how to
>> configure Apache using YaST.
>
> Try it.

Not easily feasible. I don't have access to a SUSE box right this minute.

> It's more than that, again, pay attention to those who actually
> have used it instead of making assumptions and then declaring those
> assumptions to be true, regardless of how true you believe them to be.

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.

> BTW, you do know the world is not in fact flat, right?  Just checking. ;)

The Earth *is* flat. Oh, it isn't flat in *Euclidian* geometry, true 
enough. But in elliptic geometry? It's flat. Or flattish, anyway...

> I accept that your experience has not been so good.  I'm telling you it
> isn't always that way and that you could certainly try over in the
> openSUSE forums when you have questions about openSUSE.

OK, well like I say, I'm about to try to set up a new OpenSUSE 
installation. If it doesn't work out, I'll give it a try.

> Just like searching for a job - if you stop searching, nobody's ever
> going to offer you something better.

Clearly I'm searching in the wrong places. You know, given that I never 
find anything worth even applying for... I still need to look at that, 
actually.

Post a reply to this message

On 10/20/2011 2:18, Invisible wrote:
>> Try it.
>
> Not easily feasible. I don't have access to a SUSE box right this minute.

http://lmgtfy.com/?q=man+yast2&l=1

Sorry, but you really needed the lmgtfy this time. :-)

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

While true in this case, actually running Yast gives you a very nice and 
comprehensible interface.

> Clearly I'm searching in the wrong places. You know, given that I never find
> anything worth even applying for... I still need to look at that, actually.

Did you apply to google?  Send me your contact info, and I'll push it into 
the process here to get you a call.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

> Sorry, but you really needed the lmgtfy this time. :-)

Darren used to say "Google is your friend".

Now we say "Google is your employer". :-P

>> Clearly I'm searching in the wrong places. You know, given that I
>> never find
>> anything worth even applying for... I still need to look at that,
>> actually.
>
> Did you apply to google? Send me your contact info, and I'll push it
> into the process here to get you a call.

If I apply, am I going to have to commute to London?

If yes, then there's really no point applying. If they'd let me work 
remotely, than I'd totally be interested...

(Not that it's impossible for me to travel to London. I just don't want 
to do it on a daily basis.)

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

Post a reply to this message

On 10/20/2011 13:00, Orchid XP v8 wrote:
>> Sorry, but you really needed the lmgtfy this time. :-)
>
> Darren used to say "Google is your friend".
>
> Now we say "Google is your employer". :-P

OK, now *that* is going in my .signature at some point.

>> Did you apply to google? Send me your contact info, and I'll push it
>> into the process here to get you a call.
>
> If I apply, am I going to have to commute to London?

You would have to work that out with them. They'd probably pay to relocate you.

> If yes, then there's really no point applying. If they'd let me work
> remotely, than I'd totally be interested...

I don't know about England, but in the USA, that tends not to be common.

That said, why the hell are you so resistant to even talking about applying? 
Why are you asking me for all the reasons you shouldn't even bother to apply 
to one of the most desirable tech companies around when someone on the 
inside is offering to get your resume to the top of the pile? Do you think 
if you interview they're going to *make* you work there?

You know, this is probably one of the few places where your employer might 
pay you to work in Haskell. :-)

> (Not that it's impossible for me to travel to London. I just don't want to
> do it on a daily basis.)

Sure. I live 75 miles from where I work, and until I got that straightened 
out, it was pretty annoying commuting every day. There's still enough people 
here that commute to the next city over that we run 3 vans every day.

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

Post a reply to this message

>> Darren used to say "Google is your friend".
>>
>> Now we say "Google is your employer". :-P
>
> OK, now *that* is going in my .signature at some point.

Do you have any idea how long I've been waiting to say that? ;-)

>> If yes, then there's really no point applying. If they'd let me work
>> remotely, than I'd totally be interested...
>
> I don't know about England, but in the USA, that tends not to be common.

Mmm, that's what I figured. Oh well...

> That said, why the hell are you so resistant to even talking about
> applying? Why are you asking me for all the reasons you shouldn't even
> bother to apply to one of the most desirable tech companies around when
> someone on the inside is offering to get your resume to the top of the
> pile? Do you think if you interview they're going to *make* you work there?

I'd just feel kinda bad about making them go to all the trouble of 
interviewing me, going through a long elaborate selection process, 
finally getting a job offer, and then after all that saying "oh, you 
want me to work in London? OK, forget it, I'm not interested", and them 
being all like "WTF? Why did you even apply?!" I'd feel like I wasted 
everybody's time.

> You know, this is probably one of the few places where your employer
> might pay you to work in Haskell. :-)

Yeah, maybe. Or perhaps look after some other piece of their 
infrastructure. I'm easy. (You may have noticed.)

>> (Not that it's impossible for me to travel to London. I just don't
>> want to do it on a daily basis.)
>
> Sure. I live 75 miles from where I work, and until I got that
> straightened out, it was pretty annoying commuting every day. There's
> still enough people here that commute to the next city over that we run
> 3 vans every day.

I currently commute 40 miles a day. But in the opposite direction to all 
the rush hour traffic, which is nice.

It's impossible to commute to London by car. (Well, no, it's 
theoretically possible, but you'd be insane to try.) More to the point, 
I absolutely hate London, so unless they're going to pay me 10x what I 
get now, it wouldn't be worth it.

Post a reply to this message

On 10/21/2011 1:09, Invisible wrote:
> I'd just feel kinda bad about making them go to all the trouble of
> interviewing me, going through a long elaborate selection process, finally
> getting a job offer, and then after all that saying "oh, you want me to work
> in London? OK, forget it, I'm not interested", and them being all like "WTF?
> Why did you even apply?!" I'd feel like I wasted everybody's time.

What if they said "We'll give you $150,000 more each year to move to London"?

> It's impossible to commute to London by car. (Well, no, it's theoretically
> possible, but you'd be insane to try.) More to the point, I absolutely hate
> London, so unless they're going to pay me 10x what I get now, it wouldn't be
> worth it.

Can it hurt to try? Trust me, you'd not be wasting anyone's time. If nothing 
else, if you're 100% dead set against setting foot in london, tell the 
interviewer that. I have no idea where all the offices are.

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

Post a reply to this message

On Thu, 20 Oct 2011 10:18:07 +0100, Invisible wrote:

>>>> Or if you've got the yast http module installed, you can try yast2
>>>> http- server longhelp for command-line help.
>>>
>>> Which presumable again just tells you about command switches, not how
>>> to configure Apache using YaST.
>>
>> Try it.
> 
> Not easily feasible. I don't have access to a SUSE box right this
> minute.

Well, I did mean the next time the opportunity presents itself.

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

>> I accept that your experience has not been so good.  I'm telling you it
>> isn't always that way and that you could certainly try over in the
>> openSUSE forums when you have questions about openSUSE.
> 
> OK, well like I say, I'm about to try to set up a new OpenSUSE
> installation. If it doesn't work out, I'll give it a try.

That's all I'm saying. :)

>> Just like searching for a job - if you stop searching, nobody's ever
>> going to offer you something better.
> 
> Clearly I'm searching in the wrong places. You know, given that I never
> find anything worth even applying for... I still need to look at that,
> actually.

Well, I happen to be in a similar boat.  The trick is not to care about 
the offers you don't get (and yes, that is hard - I've had a couple 
places I really wanted to find work at that didn't work out for various 
reasons), but to get to the one that *does* offer it to you.

5 months and counting for me.  At least I've found some short-term 
contract work to do.

Jim

Post a reply to this message

On Fri, 21 Oct 2011 09:09:34 +0100, Invisible wrote:

> It's impossible to commute to London by car. (Well, no, it's
> theoretically possible, but you'd be insane to try.) More to the point,
> I absolutely hate London, so unless they're going to pay me 10x what I
> get now, it wouldn't be worth it.

I know perfectly sane people who have done (and IIRC currently do) 
exactly that.

Jim

Post a reply to this message

On Wed, 19 Oct 2011 21:48:38 -0700, Darren New wrote:

> On 10/19/2011 12:04, Jim Henderson wrote:
>> Well, sure, you'd have to put them someplace where IIS won't look at
>> it. With Apache, the same holds true - if you want to put it someplace
>> where Apache won't care, don't put it in /etc/apache2. :)
> 
> Does Apache load all configuration files in /etc/apache2? I thought
> there were like include directives or something.

Honestly I don't know - the newer versions use a conf.d directory that 
load everything with a .conf extension in that directory, regardless of 
name.  That seems to be becoming more common (indeed, I'm contracting to 
do some documentation for a company that's got daemons that are being 
converted to work in this manner).

Jim

Post a reply to this message

On Wed, 19 Oct 2011 21:08:19 -0700, Darren New wrote:

> On 10/19/2011 18:30, Jim Henderson wrote:
>> Oh, I see. :)  That's what I get for being overtired for the past week
> 
> Yeah, no problem. Lots of people *try* to turn conversations into
> debates. Certainly I'm not going to mind that you thought I was doing
> that. :-)

LOL

>> Ah, *that* thing.  I hadn't heard it called that, just heard about the
>> MS extensions being installed without the user being asked. :)
> 
> Yeah. It's their package manager for applications you install and update
> 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.

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> 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.

  Ever checked zsh's manpage(s)? It's actually divided into 16 man pages,
each dealing with a subset of the features, and most of them aren't exactly
short (for example the manpage for 'zshexpn' is over 1900 lines long).

-- 
                                                          - Warp

Post a reply to this message

On Thu, 20 Oct 2011 10:11:22 +0100, Invisible wrote:

>>> Either that or I just failed to get hired - again...
>>
>> That is a legitimate answer.  It isn't the only answer, though -
>> because one could ask people with more experience.  They could get in
>> touch with teammates who know the systems better, or with people they
>> know from other companies.  They could ask at a user group meeting (if
>> it's not a critical system-down issue, obviously - waiting until your
>> next LUG meeting isn't really good if the users can't work).
>>
>> Point is, there are many options.
> 
> 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.

>> Yes, your experience varies from mine.  I'm telling you that it needn't
>> be that way.
> 
> Well, like I say, short of spending 10 years using Linux and seeing if
> anything is different this time, there's not really any way for me to
> verify your claim objectively. Either I believe you or I don't.

Well, if you don't believe me, then you're telling me my experience 
didn't happen.  So I'd suggest belief is the appropriate course of 
action. ;)

>> Now, did I waste my time?  You tell me.  Remember that it's beta and
>> the fix is in progress, though, before you answer that question.
> 
> Now, again, I wouldn't have even attempted to use a beta version in the
> first place. (But then, that's why they label it as beta. If you don't
> want the risk, you don't use it. If the risk is acceptable, you try it
> out...)

Right.

>> But if you're having difficulty with dependency resolution, you ask a
>> question about it and then perhaps someone builds the package for you.
> 
> 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

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.

> Can you see why I might be reluctant to believe this?

I can see that you might be reluctant to believe this, yes - but your 
stubbornness about it is approaching legendary levels.

>>> How do you know which part is the stack? How do you know which parts
>>> are code and which parts are data? How do you know where in the
>>> program the processor was executing?
>>
>> The debugger tells you those things, especially if you are in a live
>> kernel debugging session.
> 
> 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.

>>> You say "the format of a stack dump is known", except that... no, it
>>> isn't. The stack holds whatever arbitrary data the program decides to
>>> write to it. Without knowing how the program works, how can you get
>>> anything useful out of that?
>>
>> Well, yes, it is.  Because you have structural elements from the
>> software known to the debugger.
> 
> 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.

>> A kernel debugger just gives you the tools to ask the CPU what it's
>> doing in a particular stack frame.
> 
> Wait - you mean the debugger can actually see what the processor is
> doing, not just what's in memory?

Yes.  A debugger can even execute instructions one by one (on the 
processor) to do single-step debugging.

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

>> You seem to be saying "it's a pain" and assuming that it's expected to
>> be that way.  There may actually be an underlying problem that needs to
>> be fixed that would make it less of a pain for you.  But you'd rather
>> complain, apparently, that it's a pain.
>>
>> That's what's frustrating me in this conversation.
> 
> 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>

I've not said "there's nothing wrong with it" - there's *always* room for 
improvement.  What I have said is "it's not as bad as you make it out to 
be", which is true.

>>> Every distro manages their stuff in a slightly different way. I seem
>>> to recall that if you installed POV-Ray under Debian, it used to
>>> insist on installing PVM, because the Debian POV-Ray package was a
>>> heavily modified PVM-patch of the official POV-Ray sources or
>>> something weird like that. (I presume this has been fixed now...)
>>
>> It may have been.  Or you could install povray from the sources or a
>> binary package here.  Then you get the latest version that Chris&  team
>> have put together, and you don't have to deal with the Debian
>> dependency issues.
> 
> 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*

> Regardless, hopefully Debian fixed this particular stupidity long ago.
> (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.

>> Sometimes that happens.  It depends on the severity of the bug and how
>> frequently it happens or is reported.
>>
>> A bug that one person once saw a couple years ago but nobody else has
>> reported an issue with isn't likely to get attention.
> 
> In fairness, looking back at the ticket, the actual issue was that
> such-and-such a package doesn't work properly on AMD64. The issue
> presumably was upstream (i.e., it isn't Gentoo's fault that SmartEiffel
> doesn't run correctly on AMD64). That probably doesn't help. Plus I
> doubt SmartEiffel is insanely popular.

Now you're understanding it.

>>> All I'm saying, people say "well it's open source, if you don't like
>>> it, you can fix it". Erm, no. No you can't. Unless you're very
>>> fortunate.
>>
>> You can always write a patch for the code you're running and submit it
>> upstream.
> 
>> So yes, you can fix it if you don't like it.
> 
> Not if you don't speak C you can't. :-P

You're missing the point, but I gather you know what I'm saying.

>>>> Which is why there's a community to help you out when you have
>>>> issues.
>>>
>>> In my experience, the "community" is absolutely useless.
>>
>> I can't see that you've asked any questions in the openSUSE or SUSE
>> communities about your upgrade woes.
> 
> I didn't mean any specific Linux community. I just offhandedly meant
> "every one that I've tried".

You've not tried the ones I'm in, and my experience in those communities 
has been quite good.

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

> The guys in the LUG were very friendly and everything. It's just that
> they never had the slightest clue how to fix my problems, or even where
> to start looking. Every suggestion I got from them always started with
> "man" followed by a command name...

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

Note that "1957" is actually facetious - I do know Linux is only 20 years 
old. ;)

>> Point is, if you use it and don't report the problem, unless someone
>> else has the issue and reports it, it's guaranteed not to get looked
>> at.
> 
> Again, if a video driver for a very common video card doesn't work, I
> would assume this has already been reported multiple times over.

But worth asking just in case it's a problem unique to your setup.  
That's why I asked.  If it wasn't reported, I would have reported it and 
provided information to help debug it.

As it happens, the bug has now been closed as fixed - so I get to try 
again this weekend if time permits. :)

>>> I don't suppose you happen to know of a distro that's particularly
>>> optimised for running in a VM?
>>
>> Depends on what you want to do with it.  Custom SUSE builds done in
>> Studio can be built as a VMDK or OVM (I think is the extension) format
>> for use in virtual environments.
> 
> I'm thinking more about the fact that if you do a default install of
> [any distro you care to mention], it installs power management
> utilities, firmware updates, scanner and webcame capture software, and
> all sorts of other hardware-related stuff which is simply useless on a
> VM. So first you have to wait for all this lot to download, and then you
> have to spend time uninstalling it again.
> 
> 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.

> Some of the stuff written my MVPs is quite enlightening. For example, I
> once found [and will probably never find again] a website dedicated to
> MS Word glitches. It actually explains several interesting points which
> aren't mentioned in the documentation anywhere. Very useful stuff.

Yep.

> 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. (Of course, with most of these things there's always the potential
> for the problem being some 3rd party software that a Microsoft expert
> isn't going to know anything about...)

I find it does depend on how one asks the question, too.

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

>>> So you've never had the package manager try to replace glibc and
>>> utterly break your install to the point where you have to replace the
>>> entire OS?
>>
>> Nope, I haven't.
> 
> That's pretty impressive.

I've only been doing Linux for 10-15 years or so. ;)

>>>> Well, it irritates several of us when you say "it's f-ing
>>>> impossible!@!!@! @!!" when in fact it's not, and you just haven't
>>>> asked for help.
>>>
>>> It irritates me when people say something is possible when it damned
>>> well isn't. :-P
>>
>> Except that it *is*, otherwise, how is it that millions of people use
>> Linux every single stinking day?
> 
> I didn't say it's impossible to use Linux. Heck *I* do that! I said in
> certain situations it's impossible to make the package manager do what
> you want.

And those millions of people using Linux don't use package management?  
No, actually, they do.  So we've come full circle.

>>> Like I said, when I ask, nobody helps.
>>
>> Come over to the openSUSE forums and ask for help when you're next
>> using openSUSE.  You'll *probably* be pleasantly surprised.
> 
> 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.

> (OTOH, I'm not looking forward to setting up yet *another* account on
> yet *another* forum... Like I don't have enough of those yet!)

One thing I've wanted to push for is using openID for authentication on 
OSF.  Not sure if vBulletin can support that, though - but if you post 
using NNTP, you'll find it's just a matter of pointing at 
forums.opensuse.org:119 and pulling a list of newsgroups.

>> It's like the old joke about playing the lottery - you have to play to
>> win.
> 
> Except that if you don't play, the probability of winning is zero, and
> if you do play, the probability of winning is so close to zero as to be
> effectively zero for all practical purposes.

Of course, that's why I added the bit that you didn't quote. ;)

> Can you tell why I don't play the lottery?

Same reason I don't.  Well, that, and there's no lottery in Utah. ;)

Jim

Post a reply to this message

On Fri, 21 Oct 2011 18:42:05 -0400, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> 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.
> 
>   Ever checked zsh's manpage(s)? It's actually divided into 16 man
>   pages,
> each dealing with a subset of the features, and most of them aren't
> exactly short (for example the manpage for 'zshexpn' is over 1900 lines
> long).

I haven't looked at it myself, but it doesn't surprise me that there are 
manpages that have a lot of documentation in them.

Jim

Post a reply to this message

On 10/21/2011 3:29 PM, Jim Henderson wrote:
> On Wed, 19 Oct 2011 21:08:19 -0700, Darren New wrote:
>
>> On 10/19/2011 18:30, Jim Henderson wrote:
>>> Oh, I see. :)  That's what I get for being overtired for the past week
>>
>> Yeah, no problem. Lots of people *try* to turn conversations into
>> debates. Certainly I'm not going to mind that you thought I was doing
>> that. :-)
>
> LOL
>
>>> Ah, *that* thing.  I hadn't heard it called that, just heard about the
>>> MS extensions being installed without the user being asked. :)
>>
>> Yeah. It's their package manager for applications you install and update
>> 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.
>
> Jim
Snort.. Yeah, which is I suppose why those things are usually "disabled" 
automatically by Firefox, as a) security threats, and b) prone to cause 
instability. lol

Post a reply to this message

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

A reference manual is no substitute for an introduction.

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

Post a reply to this message

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

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

On 10/23/2011 9:15, Orchid XP v8 wrote:
> 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...

If you're in charge of administrating networks, then the answer ought to be 
"yes, yes it is."

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

Post a reply to this message

On Sun, 23 Oct 2011 11:44:55 +0100, Orchid XP v8 wrote:

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

No, I didn't say that, nor did I hint at that.  I was relating my own 
experience.

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

for name [ [ in [ word ... ] ] ; ] do list ; done

That's in the man page.

To find a specific example, in my case, I'd grep through existing scripts 
on the system, starting with the init scripts.

For example, in /etc/init.d/boot, I found:

for i in ${bootrc}/S${rex}*; do

In order to parse this, one needs to understand how variable expansion 
takes place, but that's covered in the man page.

Jim

Post a reply to this message

On Sat, 22 Oct 2011 17:18:10 -0700, Darren New wrote:

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

OIC

Post a reply to this message

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

On 23/10/2011 7:01 PM, Jim Henderson wrote:
>> 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".
>

It's not just a computer solution. I have often asked people to do a 
power off reset on other equipment. It gives time to think and you never 
know the problem might just go away. ;-)

-- 
Regards
     Stephen

Post a reply to this message

On Sun, 23 Oct 2011 19:19:49 +0100, Stephen wrote:

> On 23/10/2011 7:01 PM, Jim Henderson wrote:
>>> 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".
>>
>>
> It's not just a computer solution. I have often asked people to do a
> power off reset on other equipment. It gives time to think and you never
> know the problem might just go away. ;-)

That's certainly true.  I know some who work on helpdesks who suggest it 
to buy time to research the issue.  Not always a good idea, though, 
because if the problem doesn't come back, then you have to wait for the 
next incidence in order to try to address it. :)

Jim

Post a reply to this message

>>>     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.
>
> No, I didn't say that, nor did I hint at that.  I was relating my own
> experience.

So saying "I learned everything I know about Unix just by reading the 
manpages" doesn't count as "strongly hinting that manpages are all you 
need"?

>> 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!)
>
> for name [ [ in [ word ... ] ] ; ] do list ; done
>
> That's in the man page.

Uh... why does that need three nested levels of brackets?

Actually, suddenly I'm not sure I want to know the answer...

> To find a specific example, in my case, I'd grep through existing scripts
> on the system, starting with the init scripts.

Presumably to do that I'd have to already know how to run grep over 
every file in a directory. :-P (Not to mention knowing how to operate 
grep - it's highly non-trivial, after all - as well as how to determine 
which files are Bash scripts...)

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

Post a reply to this message

On 23/10/2011 05:57 PM, Darren New wrote:
> On 10/23/2011 9:15, Orchid XP v8 wrote:
>> 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...
>
> If you're in charge of administrating networks, then the answer ought to
> be "yes, yes it is."

I was trying to set this up on my home PC. :-P

But even so, if I'm trying to figure out why the Internet isn't working, 
and I need to run some tool to help me do that, the last thing I want is 
to say "how do I work this tool? Oh, let me just Google it..."

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

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> But even so, if I'm trying to figure out why the Internet isn't working, 
> and I need to run some tool to help me do that, the last thing I want is 
> to say "how do I work this tool? Oh, let me just Google it..."

  You use your phone to google it.

-- 
                                                          - Warp

Post a reply to this message

On Sun, 23 Oct 2011 21:03:17 +0100, Orchid XP v8 wrote:

> On 23/10/2011 05:57 PM, Darren New wrote:
>> On 10/23/2011 9:15, Orchid XP v8 wrote:
>>> 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...
>>
>> If you're in charge of administrating networks, then the answer ought
>> to be "yes, yes it is."
> 
> I was trying to set this up on my home PC. :-P
> 
> But even so, if I'm trying to figure out why the Internet isn't working,
> and I need to run some tool to help me do that, the last thing I want is
> to say "how do I work this tool? Oh, let me just Google it..."

Libraries.  Smart phones.  Dual-boot configurations.

We've been over this before. ;)

Jim

Post a reply to this message

On Sun, 23 Oct 2011 21:01:55 +0100, Orchid XP v8 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.
>>
>> No, I didn't say that, nor did I hint at that.  I was relating my own
>> experience.
> 
> So saying "I learned everything I know about Unix just by reading the
> manpages" doesn't count as "strongly hinting that manpages are all you
> need"?

There's a difference between "I did this" and "everybody does this".  I !
= everbody.

I also had experience with various forms of Unix from my past, so I 
didn't need the introductory stuff, because I just adapted what I already 
knew.

>>> 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!)
>>
>> for name [ [ in [ word ... ] ] ; ] do list ; done
>>
>> That's in the man page.
> 
> Uh... why does that need three nested levels of brackets?

You're the one who pointed out that it's BNF formatting (though I'm not 
sure that's explicitly the case).

> Actually, suddenly I'm not sure I want to know the answer...
> 
>> To find a specific example, in my case, I'd grep through existing
>> scripts on the system, starting with the init scripts.
> 
> Presumably to do that I'd have to already know how to run grep over
> every file in a directory. :-P (Not to mention knowing how to operate
> grep - it's highly non-trivial, after all - as well as how to determine
> which files are Bash scripts...)

man grep gives you the information you need to use grep.

In my case:

grep -ri for /etc/init.d | less

The /etc/init.d scripts have the benefit of being exclusively bash 
scripts.  But if you want to know if it is, you just look for:

#!/bin/bash

as the first line of the script.

Jim

Post a reply to this message

On 23/10/2011 09:13 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>> But even so, if I'm trying to figure out why the Internet isn't working,
>> and I need to run some tool to help me do that, the last thing I want is
>> to say "how do I work this tool? Oh, let me just Google it..."
>
>    You use your phone to google it.

Who the hell has internet access from a telephone?!

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

Post a reply to this message

>>>>> Geez, dude. Third hit on google
>>>>
>>>> Yes, because the Internet is always accessible. Oh, wait...
>>>
>>> If you're in charge of administrating networks, then the answer ought
>>> to be "yes, yes it is."
>>
>> I was trying to set this up on my home PC. :-P
>
> Libraries.  Smart phones.  Dual-boot configurations.
>
> We've been over this before. ;)

I guess I just reject the idea that you should ever need to use Google 
to figure out how software works. It should be in the manual. :-P

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

Post a reply to this message

On Sun, 23 Oct 2011 21:44:51 +0100, Orchid XP v8 wrote:

> On 23/10/2011 09:13 PM, Warp wrote:
>> Orchid XP v8<voi### [at] devnull>  wrote:
>>> But even so, if I'm trying to figure out why the Internet isn't
>>> working, and I need to run some tool to help me do that, the last
>>> thing I want is to say "how do I work this tool? Oh, let me just
>>> Google it..."
>>
>>    You use your phone to google it.
> 
> Who the hell has internet access from a telephone?!

Anyone with a smartphone.

Jim

Post a reply to this message

On Sun, 23 Oct 2011 21:45:32 +0100, Orchid XP v8 wrote:

>>>>>> Geez, dude. Third hit on google
>>>>>
>>>>> Yes, because the Internet is always accessible. Oh, wait...
>>>>
>>>> If you're in charge of administrating networks, then the answer ought
>>>> to be "yes, yes it is."
>>>
>>> I was trying to set this up on my home PC. :-P
>>
>> Libraries.  Smart phones.  Dual-boot configurations.
>>
>> We've been over this before. ;)
> 
> I guess I just reject the idea that you should ever need to use Google
> to figure out how software works. It should be in the manual. :-P

It is in the manual.  The manual in Linux is called the man pages (or the 
info pages). :P

Jim

Post a reply to this message