On Tue, 18 Oct 2011 09:04:49 +0100, Stephen wrote:

> On 18/10/2011 4:47 AM, Jim Henderson wrote:
>>>> >>  I think you've just got my Halloween costume selected.;)
>>>> >>
>>>> >>
>>> >  OMG A six foot guising penguin. I bet you won’t be dooking for
>>> >  Apples. ;-)
>> I wouldn't take that bet.;)
> No! You jailbroke your Apple and put Linux on it. 8-)

And then Apple sued me into oblivion. ;)

Jim

Post a reply to this message

On Tue, 18 Oct 2011 10:29:40 +0100, Invisible wrote:

>>>>> Wait - YaST has documentation?
>>>>
>>>> Um, yes.  man yast for starters.
>>>
>>> Surely that just tells you the command name and what switches it has?
>>
>> TRY IT.
>>
>> That *is* in fact what documentation is, though, so yes - it has
>> documentation, and it's included in the man page.
> 
> 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.

Or if you've got the yast http module installed, you can try yast2 http-
server longhelp for command-line help.

Or in interactive mode, you would click the "Help" button.

Similarly, reading a book about how to use OS/2 isn't going to tell me 
how to use OS/400.  You have to read *relevant* documentation.

>>> You're assuming that I'm just doing it wrong, and not that it's
>>> actually a poorly designed system.
>>
>> I'm assuming you can be taught.  You seem to have an aptitude for
>> learning, but you also seem to think that if you believe something is
>> impossible, then it damned well is impossible - and nothing anyone says
>> is going to change your mind.
> 
> 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?

> Likewise, if you use a piece of software and it's clunky and awkward to
> use, and somebody else is all like "it's divine and perfect and flawless
> in every way, you're just using it wrong", are you likely to investigate
> what they're saying?

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.

Unless you'd rather just bitch about how impossible everything is.

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?

>>> In my experience:
>>>
>>> 1. The user-friendly front-ends tend to be quite fragile. If something
>>> breaks, you still need to go edit the underlying text file by hand.
>>
>> My experience with the supposed 'fragility' of those tools is
>> different. <shrug>   Maybe 10 years ago it was, but not today.
> 
> Well, I suppose short of me spending the next 10 years using Linux all
> day, there's not much we can do to resolve this particular point.

You could try asking some questions!

>> Or you use Webmin, which actually *does* (a) work the same regardless
>> of distribution, and (b) can manage the services on multiple
>> distributions.
>>
>> I mean really - I used it to manage configuration on SunOS, exactly the
>> same way I used it on RedHat and SUSE.
>>
>> But of course, you want to believe that doing so is impossible, so I
>> must've imagined it, right?
> 
> Like I said, the normal way to configure Linux applications is via
> exiting textual configuration files. I never said it was "impossible" to
> do it any other way. I just said that that is the main cultural focus.
> Which is different from the cultural focus on Windows. That's all I was
> trying to say. Sheesh...

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.

As if my experience in doing so was actually invalid or something.  Or 
that I was lying, or that I had invented it in order to make you feel 
foolish.

I assure you that *none* of those are the case.

>>> I haven't seen much "evidence to the contrary". The entire Unix
>>> philosophy seems to revolve around doing everything from the command
>>> line.
>>
>> If you haven't seen much evidence to the contrary, you haven't been
>> looking.  Really, you haven't.  I talk to Linux developers fairly
>> regularly, and to application developers on occasion who work on OSS
>> applications for Linux.  Banshee isn't just a front-end to CLI tools.
>> Neither is F-Spot.  Neither is Photivo.  Neither is OpenOffice. 
>> Neither is [...] - the list goes on and on and on and on and on and on
>> and ON.
> 
> OK. So I've actually heard of one of the items on that list. I'll give
> you that.

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.

More and more Linux programs (especially end-user programs) are not front-
ends to CLI tools but are programs in their own right.

Oh, GIMP - another Linux tool that's not a GUI front-end to cryptic CLI 
tools.

Banshee - Mono-based music player
F-Spot - Mono-based photo management tool
Photivo - photo manipulation software
OpenOffice - Office productivity suite
GIMP - Image manipulation program

>> As I recall, it was seen as an appropriate punishment.
> 
>> As I recall, they have a specific release of Windows for the EU that
>> allows IE to be removed (completely, IIRC).
> 
> My spider-sense says something about Windows Media Player... I guess I'd
> have to spend a few hours Googling it to find the real answer.

Yeah, there might've been something about WMP as well.  I didn't follow 
it that closely.

Jim

Post a reply to this message

On Mon, 17 Oct 2011 20:57:08 -0700, Darren New wrote:

> On 10/17/2011 16:29, Jim Henderson wrote:
>> On Sun, 16 Oct 2011 20:31:06 -0700, Darren New wrote:
>>
>>> On 10/16/2011 20:18, Jim Henderson wrote:
>>>> I cited a counterexample, and you changed the criteria.
>>>
>>> Yes. I clarified.  Why, are we keeping score?
>>
>> Not much point, just hard to debate when the criteria keep changing.
> 
> I wasn't aware either of us was trying to convince the other of any
> particular point. I thought it was a conversation, not a debate. :-)

That's fair. :)

But even in conversation, it's difficult to make a point when the 
criteria for the point is constantly changing.

>>> My point is that in spite of how I'm interpreting your claims, Windows
>>> does indeed have "software management elements" in their OS and
>>> supporting software.
>>
>> I never said that they didn't have "software management elements" in
>> the OS and supporting software.  I'm talking about those elements in a
>> software distribution system.
> 
> Windows Update and ClickOnce don't count? :-)

Never heard of ClickOnce.  Windows Update is typically for kernel-level 
stuff or MS-specific stuff, not third party software.

Jim

Post a reply to this message

On Tue, 18 Oct 2011 10:20:58 +0100, Invisible wrote:

>> "I don't know of anybody who's using it yet."
>>
>> I'm using it.  In a VM.  So there's one. ;)
> 
> There's always one. ;-)
> 
> No, seriously. I'm not saying nobody on Earth is using it. I'm sure
> people are. I just said that not /many/ people are using it yet. I
> imagine that will gradually change over time.

Every new PC that ships with Windows ships with it.  While some 
manufacturers are dropping PC lines, they still make enough money selling 
kit.

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

It's real-life.  If a system is down, the candidate will need to actually 
fix it and leverage what resources are available to them.  If I recommend 
someone be hired, I don't want them to freeze when a system goes down and 
they're the only one available to fix it.  I want them to be resourceful, 
and that's something you have to figure out before you make an offer.

Hiring people is expensive.  Hiring the wrong person is much *more* 
expensive.

>> You seem to think there's no point in asking questions to learn more.
>> That's troubling.  You *have* the ability to learn, and you seek out
>> information when it suits you.  But at the same time, you declare
>> something as "impossible"
> 
> 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*.  Clearly.  People have done it.  A significant portion of 
the web's web servers actually run that configuration.

So why wouldn't you bother asking a question in an online forum in that 
instance?

> Now with software we're dealing with somewhat less absolute quantities.
> I gather that if you read Linux From Scratch, it actually directs you to
> where you can download the source code for an entire Linux/GNU system
> and compile just the parts you want from source. YOU do the dependency
> management by hand, and in theory you can alter the source code to
> remove dependencies you don't want. 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?

>> (remember the discussion we had a couple years ago about debugging a
>> kernel?  You uncategorically declared it was impossible to do so, and I
>> told you that I had actually *done* so myself, but you still refused to
>> believe it was possible to use a kernel debugger to get anything useful
>> out of a crash).
> 
> 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.

That's what I've done - I've learned how to interpret the data I'm 
looking at in a kernel debugger.  It's not actually a pipe of /dev/
urandom, it actually does have a logical structure that can be learned.  
I know.  I did learn it for that particular platform.

>> You need to revise your view on that kind of thing and admit that you
>> don't know *everything*, but that there are people who know *more* than
>> you do and that you could *learn* from them.
> 
> The greatest knowledge is in knowing that you know nothing.

The greatest knowledge is in knowing that you can learn something.

> On the other hand, if you punch a brick wall with your fist, it hurts. A
> lot! Now do you assume you're just doing it wrong, and go ask an online
> forum how to do it "right"? Or do you just stop punching walls? I know
> which one I'd go for... I guess that makes me ignorant then.

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 limited experience is that when you ask for help, you get no reply.
>>> Or you get a few replies from people who don't really know how to help
>>> you, but they try to offer you some kind of useful information anyway.
>>
>> Your experience is limited; you need to gain more experience.
> 
> 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.

> (I guess it's a question of degree, of course. If you give up at the
> first try, you'd never get anywhere. Then again, if you keep doing
> something that clearly doesn't work, you're also not going to get
> anywhere...)

Yes, which is why you ask questions of people with more experience.  Do 
you sense a common theme here yet? ;)

>>> What's to understand? Dependencies are tracked at a fairly coarse
>>> level. It is what it is. Just live with it...
>>
>> So, there's absolutely nothing more you can learn about dependency
>> tracking in Linux?
> 
> 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.  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.

>> Some dependencies are very coarse, yes.  Some are not.  Your
>> assumption, based on a high level understanding, is incomplete - and
>> you certainly *could* ask for more information about it and possibly
>> even contribute to making it better.
> 
> IME, although the open source development model means that theoretically
> anyone can contribute to improving the product, in practise this doesn't
> work. It's extremely rare for submitting a bug report to actually result
> in a fix. [That's assuming the problem is even strictly speaking a "bug"
> and not merely a "hey, maybe if the system looked more like THIS it
> might be better".] Actually contributing code is usually a practical
> impossibility, for various reasons.

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

> I'm sure somebody somewhere is committing code. But for most of us, it's
> just not an option.

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.

Again, "meritocracy".  One's ability to contribute is directly relative 
to the merit of one's contributions, and to do so, you have to start 
small.

>> Or at least understand it better, instead of parroting an explanation
>> that the MS-fanbois just love.
> 
> The irony is, I used to be the biggest Microsoft hater ever. I was used
> to using AmigaOS, an operating system which ACTUALLY WORKS PROPERLY.
> Compared to that, everything to come out of Redmond seemed like the
> biggest pile of junk ever. And then along comes Linux. It's based on
> tried and tested technology. It has powerful tools. It has uptimes
> measured in decades. It's faster and more efficient. It sounded so
> exciting!
> 
> Of course, initially Linux was a total PITA to set up and actually use.
> You needed to know all sorts of exotic technical details about your PC
> in order to get it to install. Making X11 work was basically a hopeless
> task.

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, though one can run into 
problems.  Which is why there's a community to help you out when you have 
issues.

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?

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

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

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.

> I'm not saying the entire Linux system sucks. I'm saying one specific
> aspect of it is annoyingly difficult. And yet, everybody is yelling at
> me like I'm some noob who installed Linux, tried it for ten minutes, and
> couldn't figure out what the A: drive is called now so I gave it. It's
> not LIKE that AT ALL. And it irritates me when people tell me I don't
> know what I'm talking about...

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.

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.

Jim

Post a reply to this message

>> No! You jailbroke your Apple and put Linux on it. 8-)
>
> And then Apple sued me into oblivion. ;)

I've heard good things about Oblivion...

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

Post a reply to this message

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

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

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

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

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.

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

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?

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

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

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

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

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!

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

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.

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

> Which is why there's a community to help you out when you have issues.

In my experience, the "community" is absolutely useless.

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

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

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

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

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

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

> 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

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

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

Post a reply to this message

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

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

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

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

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

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

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

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

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

Post a reply to this message

On 10/19/2011 12:17, Jim Henderson wrote:
> But even in conversation, it's difficult to make a point when the
> criteria for the point is constantly changing.

I intended it more as "yes, you're right in this instance, but I was 
thinking about that situation instead."

> Never heard of ClickOnce.

I bet you did, if you heard the crap about MS installing "without asking" 
extensions to support it in firefox. :-)

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

Post a reply to this message

On Wed, 19 Oct 2011 14:58:58 -0700, Darren New wrote:

> On 10/19/2011 12:17, Jim Henderson wrote:
>> But even in conversation, it's difficult to make a point when the
>> criteria for the point is constantly changing.
> 
> I intended it more as "yes, you're right in this instance, but I was
> thinking about that situation instead."

Oh, I see. :)  That's what I get for being overtired for the past week 
(last week I ended up at a conference working - but it was a good way to 
network - and this week I'm doing some additional contract work writing 
some documentation for some low-level Linux kernel stuff).

>> Never heard of ClickOnce.
> 
> I bet you did, if you heard the crap about MS installing "without
> asking" extensions to support it in firefox. :-)

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

Jim

Post a reply to this message

On Wed, 19 Oct 2011 21:50:49 +0100, Orchid XP v8 wrote:

>>> No! You jailbroke your Apple and put Linux on it. 8-)
>>
>> And then Apple sued me into oblivion. ;)
> 
> I've heard good things about Oblivion...

I hear it's rent/mortgage free. ;)

Jim

Post a reply to this message