Why is I/O slow?

Clifford Heath wrote:

Anyhow, thanks to Radek for the advice, I’ve got 1.6.7 and the performance
of sysread seems comparable to read now.

Sorry, must have tested the wrong version somehow - read is still slow.

$ time ruby cat_read.rb /tmp/ten_megabytes > /dev/null
real 0m1.259s
user 0m1.210s
sys 0m0.050s
$ time ruby cat_sysread.rb /tmp/ten_megabytes > /dev/null
real 0m0.148s
user 0m0.080s
sys 0m0.060s

One thing I don’t get: my C program takes 65ms, but Perl
and /bin/cat take only 35ms. Perl and C programs follow.
BTW a larger buffer than 65K slows both down - cache size.

cat.pl

my $buf;
my $r;
while (sysread(STDIN, $buf, 65536) > 0)
{
print $buf
}

main()
{
int r;
char buf[65536];

    while ((r = read(0, buf, sizeof(buf))) > 0)
            write(1, buf, r);

}

Thoughts?

···


Clifford Heath

Hi,

···

In message “Re: Why is I/O slow?” on 02/06/21, Clifford Heath cjh_nospam@managesoft.com writes:

It’s due to stdio buffering.

But our tests on Linux with fread and glibc indicate that there is no
extra buffering happening. stdio is capable of buffering, but in this
case it isn’t actually buffering (it’s not possible to move A->B->C
as fast as A->C, from my argument about bandwidth). stdio libraries that
still do double copies must surely be rare now…?

“stdio” just doesn’t provide the way to distinguish buffered and
unbuffered input. And glibc does not exist everywhere. So I have to
do the job by myself, if I want to tweak the buffer. And I want to.

						matz.

Isn’t it sad that when good stuff is invented on Linux that we rush to make it
available on windows so that windows users never have any motivation to leave
that crap behind?

···

On Thursday 20 June 2002 10:10 pm, Mike Campbell wrote:

With respect, this doesn’t sound like a smart idea. The glibc folk have
spent vast effort making it fly, and you want to bypass it?

There are other systems out there that don’t have the luxury of glibc…

Austin Ziegler wrote:

Why not? It is, after all, dependent upon the presence of a
particular glibc – which I won’t have, since I do most of my Ruby
on Windows.

I certainly didn’t mean to start a Linux/Windows war - I make a living
selling apps for Windows (which I develop as much on Linux as I can).

The absolute requirement for portability of Ruby applications is
unquestioned. That doesn’t mean that Ruby, internally, must use
the same APIs everywhere. On Windows, that means it should use
OpenFileW and friends (not stdio), on Linux, glibc, and I could care
less what it uses elsewhere, as long as it’s the fastest possible
consistent with identical behaviour across platforms. I’ve been
writing cross-platform applications since 1981, and built a 100+
employee company by selling a cross-platform GUI tool of my own
design with a full-blown OO compiler/interpreter, all up nearly a
million lines non-commented of C++ code, and although that isn’t
what we do now, I think I know what I’m talking about.

I’m not crowing BTW; Ruby has given me more pure programming joy than
anything else in the last decade, and in twenty years it’s the only
software tool I wish I’d created myself! All praise to Matz!

But if anyone tells me I should put up with I/O that’s FIFTEEN TO
THIRTY TIMES slower than necessary so that they don’t have #ifdefs
in the source code of their interpreter, I will very rapidly tell
them where to get off. I’m sure that wasn’t what people seriously
thought though…

···


Clifford Heath

What about using setvbuf()? It’s part of the C standard, and can be
used to turn buffering on or off. The default buffering cannot be
known, but the buffer size and/or buffering method can be changed.

Paul

···

On Fri, Jun 21, 2002 at 05:13:40PM +0900, Yukihiro Matsumoto wrote:

“stdio” just doesn’t provide the way to distinguish buffered and
unbuffered input. And glibc does not exist everywhere. So I have to
do the job by myself, if I want to tweak the buffer. And I want to.

But if you’re agreeing that you don’t need to tweak the buffer with
glibc, then why don’t you just place an #ifdef macro for Linux around
that piece of code?

If using glibc makes sense in the cases that it’s available, why would
you not want to do so in such cases?

Ian

···

On Fri 21 Jun 2002 at 17:13:40 +0900, Yukihiro Matsumoto wrote:

“stdio” just doesn’t provide the way to distinguish buffered and
unbuffered input. And glibc does not exist everywhere. So I have to
do the job by myself, if I want to tweak the buffer. And I want to.


Ian Macdonald | Message will arrive in the mail. Destroy,
ian@caliban.org | before the FBI sees it.
>
>
>

No.

  1. The very first thing that I learned when doing computing for a
    living is “use the best tool for the job.” Despite the vitriol
    from some folks, there are times when Windows is not only the
    best tool for the job, but it’s the ONLY tool for the job.

  2. Windows stability has been increasing at least as fast as Linux
    usability over the last several years, if not faster. Linux (and
    most other unices) still suffers from the problem that there is
    no single unifying UI guideline set, so that while Windows
    programs look and feel – and perform – pretty much the same
    all over, every Linux GUI program is different. The learning
    curve for Windows programs is shallower because of the
    consistency.

  3. Windows isn’t the only platform out there which doesn’t use glibc
    by default. IMO, Matz is absolutely correct to emphasize
    portability over ‘The Linux Way’.

  4. I use both Linux and Windows boxen (and far prefer the Windows
    because there are problems with the Linux install that I have
    neither the inclination, the time or the expertise to solve), but
    for very different purposes. The fact that I can develop and test
    on Windows (my primary terminal/front-end OS) and then test and
    deploy on Linux with Perl, Python, or Ruby is of great benefit.
    Again, the right tool for the job – not Linux Everywhere.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.06.20 at 23.22.38

···

On Fri, 21 Jun 2002 12:16:24 +0900, Albert Wagner wrote:

On Thursday 20 June 2002 10:10 pm, Mike Campbell wrote:

With respect, this doesn’t sound like a smart idea. The glibc
folk have spent vast effort making it fly, and you want to
bypass it?
There are other systems out there that don’t have the luxury of
glibc…
Isn’t it sad that when good stuff is invented on Linux that we
rush to make it available on windows so that windows users never
have any motivation to leave that crap behind?

Occasionally, it’s not up to each individual user;
we have to use what we are given. </>

···

— Albert Wagner alwagner@tcac.net wrote:

On Thursday 20 June 2002 10:10 pm, Mike Campbell wrote:

With respect, this doesn’t sound like a smart idea. The glibc
folk have
spent vast effort making it fly, and you want to bypass it?

There are other systems out there that don’t have the luxury of
glibc…

Isn’t it sad that when good stuff is invented on Linux that we rush
to make it
available on windows so that windows users never have any
motivation to leave
that crap behind?

=====

Use your computer to help find a cure for cancer: Webspace nicht erreichbar

Yahoo IM: michael_s_campbell


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Hi,

···

In message “Re: Why is I/O slow?” on 02/06/21, Paul Brannan pbrannan@atdesk.com writes:

What about using setvbuf()? It’s part of the C standard, and can be
used to turn buffering on or off. The default buffering cannot be
known, but the buffer size and/or buffering method can be changed.

But, to avoid double copying we are talking, I think we need to know
how buffer is used, which is implementation dependent. If I am
missing something, tell me. It should be a good news.

						matz.

On Sat, Jun 22, 2002 at 02:26:15AM +0900, Ian Macdonald muttered…
: On Fri 21 Jun 2002 at 17:13:40 +0900, Yukihiro Matsumoto wrote:
:
: > “stdio” just doesn’t provide the way to distinguish buffered and
: > unbuffered input. And glibc does not exist everywhere. So I have to
: > do the job by myself, if I want to tweak the buffer. And I want to.
:
: But if you’re agreeing that you don’t need to tweak the buffer with
: glibc, then why don’t you just place an #ifdef macro for Linux around
: that piece of code?
:
: If using glibc makes sense in the cases that it’s available, why would
: you not want to do so in such cases?

Because it makes debugging easier? Trust me, going just down one route
to solve a problem in a cross platform way can provide enough issues, let
alone having multiple paths depending on a strange array compile options.

If you need something specialist either a) dont use the tool you have
chosen, or b) write a native module, it’s not hard [as you found out
with the password code you wrote].

The most stright forward way is to provide a general solution to the
general problem and then start worrying about the corner cases that
only a fraction of the users have issues with. And if you want tight
control over buffering [as matz stated he does] the easiest way to do
it is to implement it himself touching the real world as little as
possible until necessary [eg. flushing that buffer].

Just my 2pence

Regards,

Chris

···


Chris Ross (boris) chris@darkrock.co.uk | ctr@ferite.org
http://www.darkrock.co.uk | http://www.ferite.org
"I dont suffer from insanity - I enjoy every minute of it…"

Hi,

“stdio” just doesn’t provide the way to distinguish buffered and
unbuffered input. And glibc does not exist everywhere. So I have to
do the job by myself, if I want to tweak the buffer. And I want to.

But if you’re agreeing that you don’t need to tweak the buffer with
glibc, then why don’t you just place an #ifdef macro for Linux around
that piece of code?

I don’t know (yet) whether I don’t need to tweak the buffer with
glibc. I’ve just told glibc fread(3) does not do double copy. And I
need to tweak the buffer for other reasons anyway.

If using glibc makes sense in the cases that it’s available, why would
you not want to do so in such cases?

If glibc does provide all I need. But unfortunately, I don’t think so.

Maybe I misunderstand something. If somebody knows the way to improve
the IO performance using portable stdio and #ifdef’ed glibc features,
tell me.

						matz.
···

In message “Re: Why is I/O slow?” on 02/06/22, Ian Macdonald ian@caliban.org writes:

  • Austin Ziegler (austin@halostatue.ca) [020620 22:34]:
  1. The very first thing that I learned when doing computing for a
    living is “use the best tool for the job.” Despite the vitriol
    from some folks, there are times when Windows is not only the
    best tool for the job, but it’s the ONLY tool for the job.

Agreed, at least on the ONLY part. Having been Windows free since ~97,
and almost Linux free for ~ a year (go FreeBSD(!)) I’ve noticed that,
while I do occasionally recommend a Windows installation for a customer,
the only factors motivating in that direction these days are:

1 - momentum: "you have so many Windows machines already that
    there's no point muddying the water; you might want to undertake
    a /serious/ TCO study in the future, however"

2 - specific application(s): customer's business depends for the
    time-being on a number of Windows only applications specific to
    their industry.  Fortunately this is actually rare and the list
    grows smaller daily (and no, office software doesn't count,
    gimme a break).
  1. Windows stability has been increasing at least as fast as Linux
    usability over the last several years, if not faster. Linux (and
    most other unices) still suffers from the problem that there is
    no single unifying UI guideline set, so that while Windows
    programs look and feel – and perform – pretty much the same
    all over, every Linux GUI program is different. The learning
    curve for Windows programs is shallower because of the
    consistency.

Consistent BAD interface is not a plus. The interfaces on all
mainstream operating systems are bad these days, free *nixen even more
so, but improving (and experimenting – it was amusing to see the
“innovative” XP taking tips from GNOME). Basic functionality for non-
point-and-drool-spinning-banana-watching types on Windows is still
abysmally low.

  1. Windows isn’t the only platform out there which doesn’t use glibc
    by default. IMO, Matz is absolutely correct to emphasize
    portability over ‘The Linux Way’.

Yes. Yes! A thousand times yes! Portability is the take home lesson
and I agree with you wholeheartedly.

  1. I use both Linux and Windows boxen (and far prefer the Windows
    because there are problems with the Linux install that I have
    neither the inclination, the time or the expertise to solve), but
    for very different purposes. The fact that I can develop and test
    on Windows (my primary terminal/front-end OS) and then test and
    deploy on Linux with Perl, Python, or Ruby is of great benefit.
    Again, the right tool for the job – not Linux Everywhere.

For a few years (among other things) I developed for deployments on NT
systems without ever touching an NT system. Perl on Linux, Perl on
Solaris, Perl on AIX. Had our guy 1500 miles away drop the applications
onto the server at the customer’s place and it Just Worked. I dearly
want Ruby to stay the same way.

I personally quit using Linux (though there are still some boxes here
and elsewhere quietly humming away in closets doing dirty work) due to
administration headaches. I’ve used, maintained, and developed on Linux
from Slackware floppy distros (nearly a decade ago) to Debian to RH and
Mandrake. I was searching for the perfect combination of hardware
support, software support, ease of use, and maintainability. Eventually
I just threw up my hands and gave up on Linux because I wanted to Get
Something Done.

Having used Windows and Macintosh systems for years I knew there was no
way for me to accomplish 1% of what I need to do there (though I admit
that OS/X was tempting) [0]. Having used a barn full of proprietary
*nixen including SunOS/Solaris, AIX, HP/UX, NeXTStep (still running on
the box behind me), SysV, SCO, and even A/UX as well as the
non-proprietary {Free,Net,Open}BSD; I ended up back at FreeBSD after a
5-year hiatus.

Now I Get Things Done.

[0] I have yet to see that version of Windows that can run 70+ virtual
desktops (with instantaneous navigation) over multiple heads, while
simultaneously running 30-40 terminals, 5 different GUI browsers, a
heavy compilation session, 5 mutts, a web server, a database, a
jukebox, and multiple securely logged in remote users doing their
things on a PII-400 w/256MB RAM. Much less while heavily using NFS.
Much less without breaking stride. Much less without costing $1.
Much less with the source for every program on the disk /on the
disk/ (another complaint about Linux – sure it’s open source but
how many people actually have the source to say, ‘ps’ sitting on
their drive?). I can’t imagine going back to paying for software
without source that doesn’t do virtual desktops and doesn’t have ssh
support ready on install. Yuck.

Rick

···


http://www.rickbradley.com MUPRN: 859 (83F/88F)
> a victim. They are
random email haiku | all JUST friends. I have given
> up my playful ways.

  1. The very first thing that I learned when doing computing for a
    living is “use the best tool for the job.”

I couldn’t agree more.

Despite the vitriol from some folks, there are times when Windows
is not only the best tool for the job, but it’s the ONLY tool for
the job.

True, but those cases are relatively rare these days, especially if
you’re talking about server deployment.

  1. Windows stability has been increasing at least as fast as Linux
    usability over the last several years, if not faster.

I’m not completely sure what you mean by stability, but I would have
to disagree strongly.

Security is a large part of stability, and Windows is unparalleled in
its absysmal record in this regard. Just look at the track record of
IIS on the server side or the virus propagation mechanisms known as
Outlook and Office on the application side.

Stability =~ uptime, but admins and users alike suffer untold
unproductive hours because of the poor design and quality of Windows
tools.

As for the issue of Linux usability, this can mean many things. To me,
it means a powerful shell such as bash or zsh, a powerful, tunable
kernel capable of handling a heavily loaded system, a powerful
programming environment, the ability to get at the very heart of the
system, and not requiring a reboot every time I change an IP address,
install a driver, or sneeze loudly.

To my mind, thus, Linux is an order of magnitude more usable than
Windows, which to me is just a fun gaming platform and an easy tool
for beginners to get to grips with, in much the same way that Logo
used to be a good introduction to programming languages for children.

Linux (and most other unices) still suffers from the problem that
there is no single unifying UI guideline set, so that while
Windows programs look and feel – and perform – pretty much the
same all over, every Linux GUI program is different.

So you get flexibility and choice at the expense of consistency. Some
would argue this is a preferable state of affairs. How could having
the imposition of a single UI ever be construed as an advantage,
unless you needed the absolute certainty of always finding the same
configuration wherever you happened to go?

The learning curve for Windows programs is shallower because of
the consistency.

But once the learning curve levels off, so does the productivity
curve.

A new computer user will be productive on Windows more quickly than
one on Linux, but after a relatively short period of time, the Linux
user will catch up and overtake the Windows user.

Windows is beginner-friendly, whereas more powerful systems are
user-friendly. Since people are experienced users for longer than they
are beginning users, it’s hard to recommend Windows in most
circumstances.

  1. Windows isn’t the only platform out there which doesn’t use glibc
    by default. IMO, Matz is absolutely correct to emphasize
    portability over ‘The Linux Way’.

Agreed.

  1. I use both Linux and Windows boxen (and far prefer the Windows
    because there are problems with the Linux install that I have
    neither the inclination, the time or the expertise to solve), but
    for very different purposes. The fact that I can develop and test
    on Windows (my primary terminal/front-end OS) and then test and
    deploy on Linux with Perl, Python, or Ruby is of great benefit.
    Again, the right tool for the job – not Linux Everywhere.

Yes, being able to write once and deploy everywhere is great. If only
more things in computerland were as cross-platform and ubiquitous as
good scripting languages.

Ian

···

On Fri 21 Jun 2002 at 12:31:30 +0900, Austin Ziegler wrote:

Ian Macdonald | Money is better than poverty, if only for
ian@caliban.org | financial reasons.
>
>

> > Isn't it sad that when good stuff is invented on Linux that we > > rush to make it available on windows so that windows users never > > have any motivation to leave that crap behind? > > No. > > 1. The very first thing that I learned when doing computing for a > living is "use the best tool for the job."

The only argument that you offer below for windows as “the best tool” is a
“shallow” learning curve and a simple installation.

Despite the vitriol from some folks,

The vitriol is aimed as MS as a predatory corporation that has wreaked havoc
on competitors with monopolistic business practices.

there are times when Windows is not only the
best tool for the job, but it’s the ONLY tool for the job.

It is the only tool for the job when the decisions as to what to purchase are
made by technically illiterate suits.

  1. Windows stability has been increasing at least as fast as Linux
    usability over the last several years, if not faster.

Comparing stability of one with usability of another is comparing apples and
oranges. Besides, I see no increase in windows stability, simply change for
the sake of selling the same functionality over and over again.

Linux (and
most other unices) still suffers from the problem that there is
no single unifying UI guideline set, so that while Windows
programs look and feel – and perform – pretty much the same
all over, every Linux GUI program is different.

No options vs. several options is hardly an advantage, except to the very
lazy.

The learning curve for Windows programs is shallower because of the
consistency.

Pick a single linux GUI and you also have consistency. Again, lack of options
is hardly an advantage.

  1. Windows isn’t the only platform out there which doesn’t use glibc
    by default. IMO, Matz is absolutely correct to emphasize
    portability over ‘The Linux Way’.

And IMO, this is wrong.

  1. I use both Linux and Windows boxen (and far prefer the Windows
    because there are problems with the Linux install that I have
    neither the inclination, the time or the expertise to solve),

Yes. If you are used to windows installations, the great range of options
available in any flavor of *nix is a daunting task.

but
for very different purposes. The fact that I can develop and test
on Windows (my primary terminal/front-end OS) and then test and
deploy on Linux with Perl, Python, or Ruby is of great benefit.

But without the technical expertise to even install a *nix system, how can
your “portable” application really be optimal for a target *nix system. And
you are obviously not talking about GUI applications, but text only.

Again, the right tool for the job – not Linux Everywhere.

Bah!

···

On Thursday 20 June 2002 10:31 pm, Austin Ziegler wrote:

On Fri, 21 Jun 2002 12:16:24 +0900, Albert Wagner wrote:

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.06.20 at 23.22.38

> Occasionally, it's not up to each individual user; > we have to use what we are given.

I know. That’s why it’s sad.

···

On Friday 21 June 2002 09:27 am, Michael Campbell wrote:

=====

On Sat, Jun 22, 2002 at 02:26:15AM +0900, Ian Macdonald muttered…
[…]

If using glibc makes sense in the cases that it’s available, why
would you not want to do so in such cases?
[…]
The most stright forward way is to provide a general solution to
the general problem and then start worrying about the corner cases
that only a fraction of the users have issues with. And if you
want tight control over buffering [as matz stated he does] the
easiest way to do it is to implement it himself touching the real
world as little as possible until necessary [eg. flushing that
buffer].

Would it not be possible to make it something that is a compile-time
option, though? That is, by default, Ruby compiles with the default
implementation, but a configure/compile-option can cause it to use
glibc implementations instead?

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.06.21 at 14.53.48

···

On Sat, 22 Jun 2002 03:06:20 +0900, Chris Ross wrote:

On Sat, Jun 22, 2002 at 02:26:15AM +0900, Ian Macdonald muttered…

Because it makes debugging easier? Trust me, going just down one route
to solve a problem in a cross platform way can provide enough issues, let
alone having multiple paths depending on a strange array compile
options.

It doesn’t need to be an option. Just have autoconf detect the
presence of glibc and build accordingly.

And if you want tight control over buffering [as matz stated he
does] the easiest way to do it is to implement it himself touching
the real world as little as possible until necessary [eg. flushing
that buffer].

Sure, that’s a valid approach, too. I guess I just don’t see the
benefit of not using the resources of the OS when they equate with
what you’re trying to do on a given platform.

It’s a small point, though. I would not actually expect I/O to be as
fast when running a scripted application, so I’m not dissatisfied with
Ruby’s performance in any way.

Ian

···

On Sat 22 Jun 2002 at 03:06:20 +0900, Chris Ross wrote:

Ian Macdonald | Who does not love wine, women, and song,
ian@caliban.org | Remains a fool his whole life long. –
> Johann Heinrich Voss
>
>

Consistent BAD interface is not a plus. The interfaces on all
mainstream operating systems are bad these days, free *nixen even more
so, but improving

I disagree. Who’s to say what the ideal is?

‘Intuitive’ is a very relative concept. UNIX and the X Window System
offer me a choice of Window managers, one or two of which are smartly
enough designed and customisable enough that they can be finely tuned
to my needs, thus enabling a high degree of productivity.

At a lower level, command line interfaces enable me to be vastly more
productive than point-and-click file managers ever could, yet the CLI
is thought by the masses to be outmoded and inefficient.

A well configured command-line shell with clever aliases, functions,
programmable completion and smart key bindings knocks spots off an
interface that is operated by sliding a chunk of plastic over a pad
and clicking buttons. At least, that’s what suits me.

Interfaces are a very personal thing. One style of interface may suit
more people than another, but for the minority who work better with
the other type, that is absolutely the best choice for them.

I personally quit using Linux (though there are still some boxes here
and elsewhere quietly humming away in closets doing dirty work) due to
administration headaches.

Together with the other sysadmins where I work, we administer 20,000
Linux boxes in production and I really couldn’t imagine running
anything else on them :slight_smile:

It just goes to show how subjective this whole topic really is.

I’ve used, maintained, and developed on Linux from Slackware floppy
distros (nearly a decade ago) to Debian to RH and Mandrake. I was
searching for the perfect combination of hardware support, software
support, ease of use, and maintainability. Eventually I just threw
up my hands and gave up on Linux because I wanted to Get Something
Done.

I think the trick is to take the bits of those systems that you like
and then tweak things until they’re just as you want them. I don’t
know what your needs are, but it seems hard for me to imagine that
there wasn’t a way for you to get what you needed from such a vast
range of distributions.

Having used a barn full of proprietary *nixen including
SunOS/Solaris, AIX, HP/UX, NeXTStep (still running on the box behind
me), SysV, SCO, and even A/UX as well as the non-proprietary
{Free,Net,Open}BSD; I ended up back at FreeBSD after a 5-year
hiatus.

The key point here is that you ended up with a system for which the
source is supplied. That’s the most important factor in this
discussion. The rest is just details.

Personally, I feel much the same way about purely BSD derived systems
as you do about Linux: they’re nice to toy with, but I feel hampered
in my work.

Much less with the source for every program on the disk /on the
disk/ (another complaint about Linux -- sure it's open source but
how many people actually have the source to say, 'ps' sitting on
their drive?).

The fact that people generally don’t put it on their systems is hardly
an argument against Linux, though, is it? The source is widely
available, as source RPMs, tar files, whatever, and it’s trivial to
install.

I’ll avoid listing my qualms with FreeBSD and similar systems, since I
think it would detract from the main point that I wish to convey here,
which is that interfaces are a matter of taste and personal
experience.

I can't imagine going back to paying for software
without source that doesn't do virtual desktops and doesn't have ssh
support ready on install.  Yuck.

Nor can I, especially in my work. Source level changes are a frequent
necessity, both at the kernel and user-space level. Being tied into
someone else’s idea of how the software should behave is just not an
option.

Ian

···

On Fri 21 Jun 2002 at 13:15:08 +0900, Rick Bradley wrote:

Ian Macdonald | Motto of the Electrical Engineer: Working
ian@caliban.org | computer hardware is a lot like an erect
> penis: it stays up as long as you don’t
> fuck with it.
>

Ian Macdonald wrote:

Windows is beginner-friendly, whereas more powerful systems are
user-friendly. Since people are experienced users for longer than they
are beginning users, …

Not most people I know! My observation is that very few people learn
even to take advantage of the power offered by a Windows machine (e.g.
batch files, Word macros, right-clicking, the command line) much less
the power offered by Linux.

Paul Prescod

Despite the vitriol from some folks, there are times when Windows
is not only the best tool for the job, but it’s the ONLY tool for
the job.
True, but those cases are relatively rare these days, especially
if you’re talking about server deployment.

Deployment, yes. Development, no. In my Previous Life ™, I did a
lot of database design and development. There is nothing
comparable to ERStudio for ER diagramming … and it’s Windows only.
There are other programs where the Windows version is superior to
the xplatform versions, and the xplatform versions aren’t available
for Linux in any case (UML modeling programs, as an example). Add to
this that I can work perfectly fine with gvim in Windows and either
use Samba or an FTP session to put my development files on the Unix
box – and easily be able to cut/paste the code into documents and
emails with a reasonable certainty that (except for gvim) the user
interface is going to be consistent – I choose to use Windows as my
primary coding box.

  1. Windows stability has been increasing at least as fast as
    Linux usability over the last several years, if not faster.
    I’m not completely sure what you mean by stability, but I would
    have to disagree strongly.

I mean lack of crashes. I will grant you the security part, but I
also note that we’re discussing slightly different angles here –
I’m speaking primarily from an end-user perspective. There’s no way
that I’d ever choose Windows as a server solution unless I had no
choice (application compatibility, for example).

Stability =~ uptime, but admins and users alike suffer untold
unproductive hours because of the poor design and quality of
Windows tools.

I think that we’d find that users suffer untold unproductive hours
because of the poor design and quality of end-user Unix tools (e.g.,
OpenOffice.org – it crashed four times on me yesterday) and the
feature level isn’t quite up to Office standards. (OpenOffice.org,
as an example, doesn’t offer a variable number of user property tags
– and that picks on a very simple thing that I use often.)

As for the issue of Linux usability, this can mean many things.
[…]

Absolutely. I disagree about the ‘powerful programming environment’;
I find that most Windows IDEs (even VS, sadly) are superior to any
extant Linux IDE excepting Kylix, and in most cases, I find an IDE
to be preferable to the alternative. It is, however, a functional
environment, and one can get the job done without too much trouble.

Linux (and most other unices) still suffers from the problem that
there is no single unifying UI guideline set, so that while
Windows programs look and feel – and perform – pretty much the
same all over, every Linux GUI program is different.
So you get flexibility and choice at the expense of consistency.
Some would argue this is a preferable state of affairs. How could
having the imposition of a single UI ever be construed as an
advantage, unless you needed the absolute certainty of always
finding the same configuration wherever you happened to go?

Some would not understand HCI and learning curves. Quick: how do you
copy a block of text in any given X-Windows program? Quick: how do
you copy a block of text between two X-Windows programs? X is nice
in that it gives the select as a ‘standard’ behaviour, but some of
the new desktops seem to break that (as well as the middle-button
paste). The ONLY programs I use regularly that does not follow
standard Windows convention on this matter are gvim (and I could
configure it to do this) and cmd.exe (the DOS shell). This isn’t a
matter of ‘flexibility and choice over consistency’ – it’s simple
usability.

Similarly, menu placement – barring the difference between Mac and
Windows (top-menu vs. window-menu) – is much more consistent there
than in X-Windows programs.

I will, however, guarantee you that I have significant flexibility
and choice even with my Windows desktop – to the point that while
certain things that should ALWAYS work the same (e.g., copy/paste)
do so, others (which don’t matter flexibility-wise) don’t quite
necessarily do so. I’ve been asked, from time to time, whether I’m
actually running Linux, and if so, how I’m running this (obviously
Windows-only) program…

The learning curve for Windows programs is shallower because of
the consistency.
But once the learning curve levels off, so does the productivity
curve.

Not true. The productivity curve depends on the tasks at hand, and
not on the learning curve.

A new computer user will be productive on Windows more quickly
than one on Linux, but after a relatively short period of time,
the Linux user will catch up and overtake the Windows user.

Again, not true. The average office user will be more productive
with Office than they will with KOffice. They will be more
productive with most Windows email clients than they will with most
Unixy email clients (KMail and the GNOME one exempted).

Windows is beginner-friendly, whereas more powerful systems are
user-friendly. Since people are experienced users for longer than
they are beginning users, it’s hard to recommend Windows in most
circumstances.

Sorry, but it depends on the task at hand. This is why I’m not able
to agree with your statement that it’s ‘hard to recommend Windows’.
The reality is that most people don’t want – or NEED – to worry
about administration tasks or development tasks or server stuff or
… They just want to plug in their webcam and go. I’m not saying
that Windows is BEST for this – but Windows is better for the vast
majority of users who don’t want to have to configure jack squat.

  1. I use both Linux and Windows boxen (and far prefer the Windows
    because there are problems with the Linux install that I have
    neither the inclination, the time or the expertise to solve), but
    for very different purposes. The fact that I can develop and test
    on Windows (my primary terminal/front-end OS) and then test and
    deploy on Linux with Perl, Python, or Ruby is of great benefit.
    Again, the right tool for the job – not Linux Everywhere.
    Yes, being able to write once and deploy everywhere is great. If
    only more things in computerland were as cross-platform and
    ubiquitous as good scripting languages.

I’ll agree with that.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.06.21 at 08.54.42

···

On Fri, 21 Jun 2002 14:49:01 +0900, Ian Macdonald wrote:

On Fri 21 Jun 2002 at 12:31:30 +0900, Austin Ziegler wrote: