See also: last week's Back page page.

Linux links of the week

A new Linux-specific search engine has popped up at 1stLinuxSearch.com.

Letters to the editor

Date: 11 Feb 99 00:20:22 PST
From: Ken Engel <kenengel@netscape.net>
To: editor@lwn.net
Subject: Untapped markets

In response to your observation of the paucity of cheap Linux desktop
offerings:

I want the world to know that I, for one, would grab a sub$1000 Linux PC
faster than NT boots up, if an OEM steps up to the plate.

And even sooner, I would get a reasonably priced Linux PowerPC or ARM or
Alpha desktop.  

C'mon, guys!!

Ken Engel

Date: Thu, 11 Feb 1999 13:24:35 -0500
From: Eric Lee Green <eric@linux-hw.com>
To: editor@lwn.net
Subject: Why Linux VARS don't do much low end stuff

Basically, economies of scale. Compaq buys motherboards in quantity
1,000 for about 2/3rds the price of what a Linux VAR would pay. Compaq
buys processors in quantity 1,000 for about 80% of the price that a
Linux VAR would pay. The savings they get at the low end from
economies of scale go across the board -- basically, for components of
equal quality to Compaq's or Dell's, today's Linux VARs will pay
anywhere from 10% to 33% more for the component.

On the other hand, in the server market Compaq doesn't have the
advantage of scale. Thus we can sell for $20,000 a machine that Compaq
sells for $35,000 because our labor costs are lower, our manufacturing
costs are lower (believe me, getting Linux to run on a high-end server
is a LOT easier than getting Windows NT to run on a high-end server!),
and standardized "white box" components mean that we don't pay the
huge R&D costs that are a pittance on a run of 100,000 desktop
machines, but which add up to a hunk of change for low-volume server
machines.

Thus expect Linux VARs to continue scrambling for the middle and
middle-upper end of the server market. Without huge infusions of
venture capital to buy their way onto the shelves at Best Buy (and
thus be able to churn out tens of thousands of machines and take
advantage of economies of scale), they just can't compete at the low
end. Not at a 10% to 33% price disadvantage on components alone.

[Disclaimer: I *DEFINITELY* do not speak for Linux Hardware Solutions.] 
--
Eric Lee Green         eric@linux-hw.com     http://www.linux-hw.com/~eric
 "Linux represents a best-of-breed UNIX, that is trusted in mission
  critical applications..."   --  internal Microsoft memo

Date: Fri, 12 Feb 1999 23:32:37 -0600
From: Jeff Licquia <jeff@luci.org>
To: editor@lwn.net
Subject: Module Interface Compatibility

As a sysadmin with little kernel hacking experience, I thought I should
weigh in on this debate.  I think Linus is right.

It seems that one of the enduring fallacies of the proprietary world is
some sort of "ownership" feeling about the operating system.  Perhaps it
is bred from the monopoly position Microsoft currently owns.  Wherever
it comes from, it seems that ISVs who do anything interesting to feel
that they have to patch the operating system to do it.

The results are such curses as the various DiskMangler programs (Disk
Manager, EZDrive, etc.), which sought to solve a problem in MS-DOS's
ability to access large drives by patching the OS in very scary ways.  I
don't need to get into the problems that caused; I'm sure anyone with
lots of experience with them is shuddering right now.

If they were willing to do this without source access to the OS, imagine
what they'll do with source.

I'd much rather encourage people to avoid patching the kernel (for
that's what a module does) for their own proprietary gains.  Or, better
yet, release source for their patches.  Or roll the proprietary stuff
into a userland daemon of some kind, interfacing to the kernel with an
open-source module that hooks into the userland daemon.  Or something.

By not guaranteeing the module interface, Linus effectively discourages
this.  By forcing those few vendors of proprietary modules to recompile
for a new kernel interface once in a while, Linus is also forcing
vendors to actually look at their code every so often and make sure it's
still needed and still makes sense with the general turn of Linux.

From: "chyung g choi" <cgchoi@hotmail.com>
To: editor@lwn.net
Subject: [News] Using linux without installation??
Date: Fri, 05 Feb 1999 19:04:28 PST


 Hi there.
 This is Chyung Choi from South Korea.
 Recently I developed new distribution form of linux.
 I put the name "EASYLinux-kr". I found German company
 put the name easylinux and I put -kr in the end of name.
 One can use linux as CD-ROM as well as installed form 
 on hard disk. Therefore beginner can use it quickly.
 One can use it as demo and rescue and education material.
 I am more than happy to answer any questions
 My homepage is "http://www.netian.com/~cgchoi"

 Thank you for reading.

 Chyung Choi


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Thu, 11 Feb 1999 21:41:25 +0100
From: Andi Kleen <ak@muc.de>
To: cph@martigny.ai.mit.edu
Subject: Re: Structure vs purism


You wrote:

> I've written a fair amount of code in Pascal, and I can
> say from experience that I missed the goto statement when programming
> in that language; at least C _has_ a goto statement, and I use it when
> I think it is appropriate.

It is hard to believe that you did that without noticing that Pascal has 
a (although inconvenient) goto statement - at least all versions of Pascal
I used had and I'm pretty sure that Wirth's original definition had it too.

-Andi

-- 
This is like TV. I don't like TV.

From: David Kastrup <dak@neuroinformatik.ruhr-uni-bochum.de>
Date: Thu, 11 Feb 1999 13:10:41 +0100 (MET)
To: editor@lwn.net
Subject: Goto followup


For your information: Pascal *does* have "goto" and did from the
start.  Better check up the documentations you have been using.

Yes, you have to declare any "goto" labels you want to be using in
advance.  But what of that if it's really needed?

Most commonly the necessity for "goto" arises for structured leaving
of scopes.  C at least offers "break" and "continue" for the innermost
scope, but beyond that it's "goto" or the obfuscated use of flags and
stuff.

Perl has very nice multi-level "break" and "continue" constructs, so
hardly ever needs a "goto" when doing properly structured programming.

"Goto" has got its worst reputation from Fortran's arithmetic if, a
three-way goto.  And of course, from other "if"s that only offered
gotos as targets.  In many cases, programmers would not interrupt the
flow of the not-taken branch by jumping to the end of the taken
branch, so the code for a true "if" tended to accumulate somewhere at
the end of the program, giving the dreaded spaghetti code.  If anybody
should be allowed to produce spaghetti for efficiency, it is to be the
compiler, not the programmer.

For this reason, structured "if"s and other control structures have
helped to get rid of "goto" where it was causing problems without end.
It is still a good idea to avoid uncalled-for "goto"s whenever possible.
It takes a skilled programmer to know precisely when a "goto" is indeed
in need.  For that reason, it is a good idea to tell newbies to not
use it.  Only after you know all the ways of avoiding it and their
consequences are you in a qualified situation for judging when it is
better to use it than not.

David Kastrup                                     Phone: +49-234-700-5570
Email: dak@neuroinformatik.ruhr-uni-bochum.de       Fax: +49-234-709-4209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany

Date: Thu, 11 Feb 1999 14:23:40 +0300 (EET)
From: George Bronnikov <goga@bronnikov.mccme.ru>
To: cph@martigny.ai.mit.edu
Subject: Re: Structure vs purism

I want to reply to your letter published in the latest issue of LWN.
While I tend to agree that gotos are sometimes tolerable, the posting
has a number of technical errors:

1. Pascal does have a goto statement. Read the standard
(unfortunately, I don't have a copy at hand to give an exact
reference).

2. Scheme has other iterating constructs besides tail recursion: read
the standard (the do construct, section 4.2.4 of R5RS).

It is true, however, that the constructs mentioned are not used
widely; in fact, they are considered bad style in both languages.

3. The 'expressive power' of a language is not that easy to define. It
is a proven fact that you can reformulate any program that uses gotos
by using only 'normal' iterating constructs like ifs and loops. In
fact, if the initial program was written in a style that Dijkstra et
al. fought with in the late 60-ies, the result of de-goto-ifying will
usually even look and read better.

3. Tail recursion is not simply 'goto with arguments': it is a highly
restricted version of goto, which only allows gotos to the beginning
of the function.  Thus it also reduces 'expressive power'; it just
happens to do that in a way that does not cut out interesting cases.

By the way, Scheme happens to be my favourite language as well.

	George Bronnikov

Date: Thu, 11 Feb 1999 10:44:24 -0500 (EST)
From: cph@martigny.ai.mit.edu (Chris Hanson)
To: goga@bronnikov.mccme.ru
Subject: Structure vs purism

   Date: Thu, 11 Feb 1999 14:23:40 +0300 (EET)
   From: George Bronnikov <goga@bronnikov.mccme.ru>

   I want to reply to your letter published in the latest issue of
   LWN.  While I tend to agree that gotos are sometimes tolerable,
   the posting has a number of technical errors:

   1. Pascal does have a goto statement. Read the standard
   (unfortunately, I don't have a copy at hand to give an exact
   reference).

I guess the version I used back in the 80s (HP Pascal for the HP 9836)
was broken; it didn't have goto.

   2. Scheme has other iterating constructs besides tail recursion:
   read the standard (the do construct, section 4.2.4 of R5RS).

Those other iterating constructs are all defined as patterns of
iterative procedure calls, and in practice are implemented as macros
that expand into those patterns.  So I stand by this statement.  (And
you don't need to quote references to Scheme's standard -- I'm one of
the authors.)

   3. The 'expressive power' of a language is not that easy to define.
   It is a proven fact that you can reformulate any program that uses
   gotos by using only 'normal' iterating constructs like ifs and
   loops. In fact, if the initial program was written in a style that
   Dijkstra et al. fought with in the late 60-ies, the result of
   de-goto-ifying will usually even look and read better.

Nevertheless, I still claim that not using goto eliminates some of the
expressive power, at least in the case of C.  The problem I usually
run into is that "break" only exits the innermost construct, and
there's no way to specify that you want to get out of multiple
constructs.  So it's necessary to either kludge around this using
flags, or to use goto and say what you mean.  Theoretically, I can
imagine a language that doesn't have this problem, but C isn't it.

There are other situations in which goto is useful, but that's the
primary one.

When I say "expressive power", this is the kind of thing I mean: if
you can say something that _directly_ conveys your intent, the
language is more expressive than one in which you must do so
indirectly.  Perhaps I am misusing the term.

   3. Tail recursion is not simply 'goto with arguments': it is a
   highly restricted version of goto, which only allows gotos to the
   beginning of the function.  Thus it also reduces 'expressive
   power'; it just happens to do that in a way that does not cut out
   interesting cases.

Yes, you're right about that.  My mistake.