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