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