[aklug] Re: Slackware says "I told you so!"

On 02/27/11 13:53, Arthur Corliss wrote:
> On Sat, 26 Feb 2011, Christopher Howard wrote:
>
>> I enjoyed the article. Another way to put it: If you understand how
>> something works, you are going to be better working with it. Unix forces
>> you to understand how it works, so you will be able to accomplish more
>> and better things with it than you would with operating systems that
>> take the opposite approach.
>>
>> However, it didn't address more fundamental issues: Is it necessarily a
>> good thing for a person to be required to learn how his software works
>> in order to benefit from it? For example: a person drives a car to work
>> every day, but he doesn't understand how internal combustion engines
>> work. Does that necessarily mean he is dumb? Maybe it just isn't his
>> area of expertise. Maybe he doesn't have the time to learn how cars work.
>
> I think you missed the point of the article. It's not whether it's
> necessary to understand internal combustion to drive a car, it's whether
> you're going to be more successful getting on the road again once the car
> breaks down in the middle of nowhere.
>

Yeah, you're right. Sorry. :)

>> You imply vim is "superior" to pico, nano, et cetera. But your unstated
>> assumption was that "superior" means "I can accomplish a whole lot more
>> with it than with other editors because I know what I'm doing." But when
>> my buddy at work has to spend 20 minutes looking through a Linux
>> reference book to figure out how to edit two lines in a config file
>> using vim, it doesn't seem very "superior" to him.
>
> :-) You also seem to misunderstand my vi(m) jab. Yes, it is my personal
> choice, but spurring on a decades old debate which has long devolved into
> silliness is done more for good natured entertainment than rabid dogmatism.
>

Heh... I guess sometimes it is hard to tell the difference in a mailing
list post.

> That said, I can easily play pedagogue still. Whether your buddy knows how
> to drive a stick shift has no bearing on whether it's more expedient to
> walk
> a hundred miles or drive it. Technical superiority is independent of
> learning curve. Resource utilization is easy to measure. Number of
> keystrokes needed for mass edits can be easily measured. Whether an editor
> is a standard that is *always* available and whether or one is only
> occasionally present is easily measured. In short, it matters not one iota
> whether your buddy finds something easy/intuitive/whatever, it only matters
> what the raw functionality is capable of, should one put in the effort to
> become proficient in it.

Here, you conveniently define "raw functionality" to fit only within the
confines of your concerns. "Resource utilization". "Number of keystrokes
for mass edits". "Universal availability".

These might be all well and important for your particular brand of
system admin. But Joe Smo out there might not care about any of things.
He can spend six weeks becoming proficient at vim but it is just a waste
of his time.

But if he finds that he can proofread a document three times as fast
using gedit, than as far as his needs are concerned, gedit is superior
to vim.

Furthermore, you say "technical superiority is independent of learning
curve". But the history of technological development doesn't bear that
out. What about Ruby? What about Perl? What about Udev? KDE? Gnome libs?
CMS? (I could go on.) In the real world, at every step of the way,
people are making technical decisions where learning time, integration
with familiar methods and technologies, and ease-of-use, are critical
factors. And those concerns are often the driving motivation in the
development of new technologies.

>
>> My answer to my own question is: yes, ultimately it is always better to
>> thoroughly understand any framework you use. But getting from point A to
>> point B is a bit more challenging in the real world. Which is why, last
>> time I checked, Ubuntu is still more popular than Slackware and Gentoo
>> combined, even though they are clearly "superior" distros.
>
> :-) You make my arguments for me. In the spirit of the article: what is
> the *average* diagnostic skill level of Ubuntu users versus the average
> Slack user? To make a more finer point on it (especially for those of
> us hiring prospective UNIX admins) who would you rather have on staff
> when a server goes down: an Ubuntu user or a Slack user? If, as a
> generalization, it can be held as true that Slack users have deeper
> knowledge of system internals than the other, your choice is rather clear.
>

Okay, provided we confine the discussion to diagnostic skill level of
Unix systems. Now, we might still have an interesting discussion about
who would be the better choice if we were programming a new video game
or file manager.

> None of this, however, is meant as an insult to the overwhelming Ubuntu
> hordes on this list. From personal experience I can vouch that one's
> preference for distributions is an unreliable indicator of one's expertise.
> We have some very good hackers on this list which are Ubuntu advocates,
> probably one for every distro out there. Using an "easy to use"
> distribution is not an inhibitor to greater learning. But it still has to
> be noted that while easy distros don't prevent you from learning, others do
> damned near demand it if you want to get anything done. And that can be a
> powerful incentive.
>

I agree with that. It's one of the reasons I use Gentoo.

> The funny part of your last sentence is that Slack/Ubuntu/whatever *aren't*
> superior to one another. It can be debated that perhaps one favors a more
> personally desireable default configuration, but that's all too subjective.
> Especially when you consider that for the core OS all the distributions are
> 90% identical. It's the *same* software.
>
> Just goes to show that there's always more than one way to skin a
> cat... no
> offense to the LOLcat devoutees out there. ;-)
>
> --Arthur Corliss
> Live Free or Die
>

-- 
frigidcode.com
theologia.indicium.us
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.