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