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