See also: last week's Back page page.

Linux Links of the Week

Linux Headquarters is, instead, oriented toward tutorial content. There are HOWTO-type documents on a number of topics, including an example-laden introduction to GTK+ programming.

Back to news sites, internet.com has finally launched Enterprise Linux Today, an offshoot of LinuxToday aimed at corporate readers.

Section Editor: Jon Corbet

This week in history

Anyway its up to the US citizens to kick their government in the right direction. "Representation of the people" usually only works when the representative is made firmly aware that there is a horde of the represented right behind him who are going to do serious damage if said representative doesnt do some representing of the people for a change.

IBM made its plans to to bundle Apache public, having finally satisfied its lawyers that the whole thing would work. ZDNet's Jesse Berst looked at the prospects for Linux:

Would you like to see the rug pulled out from under Microsoft? Here's how it could happen. IBM ships and supports Linux. Oracle does Linux versions of all its products. A consortium of top vendors picks a standard Linux interface and creates a compatibility logo.

Offhand, it looks like we have gone a long way toward satisfying his list.

Meanwhile, the development kernel was at 2.1.106ac4; there was an initial 2.0.35 prepatch out there on the stable side. Debian 2.0 beta was released. Adaptec saw the light and began to help Linux support its SCSI controllers.

One year ago (June 24, 1999 LWN), SuSE surprised the world by releasing its financial results - despite Red Hat's claim to bigness, SuSE was not at all far behind. Over 5000 people attended Linux Expo Paris. Eric Raymond spoke at Microsoft:

It was kind of amusing, really, fielding brickbats from testosterone-pumped twentysomethings for whom money and Microsoft's survival are so central that they have trouble grokking that anyone can truly think outside that box. On some subjects, their brains just shut down -- the style reminded me a lot of the anonymous cowards on Slashdot. (From the Linux Journal).

Ten European industrial leaders, including Linus Torvalds, worried about software patents. Bob Metcalfe predicted the death of the "Open Sores Movement."

The development kernel was 2.3.8 - it was a scary one to run, since massive changes to the I/O system occasionally corrupted file systems. The stable release was 2.2.10. Eric Raymond suggested that the EROS operating system should be the guide for Linux's future. HP announced a line of Linux workstations.

Letters to the editor

Date: Thu, 15 Jun 2000 16:32:17 -0400 (EDT)
From: Joe Klemmer <klemmerj@webtrek.com>
To: letters@lwn.net
Subject: Easier floppy access


	In the 6/15 issue of LWN there is a commentary about easy floppy
disk access.  I would like to point out a very nice little utility that
comes with the XFce desktop <http://www.xfce.org> called "xfdevmount".
This utility allows one to mount and open a file manager on the content of
a floppy or CD with one click.  There are other little gems like this in
XFce, too.  It's a very good desktop/window manager, too.

---
Sweater, n.:
        A garment worn by a child when its mother feels chilly.

From: Troy Baer <tbaer@columbus.rr.com>
Date: Fri, 16 Jun 2000 09:38:13 -0400 (EDT)
To: Richard Stallman <rms@gnu.org>
Cc: letters@lwn.net
Subject: Re: Floppy handling

Seen on http://lwn.net/2000/0615/a/rms-floppy.php3:
> Is there any possibility of making Linux handle file systems on
> floppies like MSDOS, so that there is no need to explicitly mount and
> unmount a floppy drive in order to access floppies through the file
> system?

This can be done with virtually any removable disk media with the
Linux autofs kernel-level auto-mounter; basically you need to set the
automounter up to unmount the drives after a very short period of
inactivity (~1-5 seconds).  I've got an example of how to configure
autofs to handle floppies, CDROMs, and Zip disks at
http://home.columbus.rr.com/tbaer/linux/autofs/.  It's not 100%
perfect (things like SAMBA will keep drives from unmounting), but it's
a start.

Hope this helps,
	--Troy
-- 
         Troy Baer, MS(AAE)         "My life's work has been to prompt
       tbaer@columbus.rr.com         others... and be forgotten."
http://home.columbus.rr.com/tbaer/  --Cyrano de Bergerac

Date: Sat, 17 Jun 2000 01:25:03 -0600 (MDT)
From: Richard Stallman <rms@gnu.org>
To: tbaer@columbus.rr.com
CC: letters@lwn.net
Subject: Re: Floppy handling

    This can be done with virtually any removable disk media with the
    Linux autofs kernel-level auto-mounter; basically you need to set the
    automounter up to unmount the drives after a very short period of
    inactivity (~1-5 seconds).

The goal job is to make the system continue in a reasonable way if the
user removes a floppy at any time and later inserts another one.

Whether the automounter does the job depends on the precise definition
of "inactivity" used by the automounter.  I fear that its definition
is based on the absence of any descriptors pointing to the floppy.  If
so, it would do the job some of the time, but won't do it reliably.

This feature is important enough for non-hacker users that it ought to
be done in a solid and reliable way.  If some processes have
descriptors pointing to the floppy at the time it is removed, they
probably have to lose somehow; the best way for them to lose is by
getting errors when they try to do any further I/O.  But the damage
should go no further than that!

I think it is best to eliminate caching on floppies, and prohibit mmap
on floppies, so as to make floppies more reliable for their most
common use--file transfer and archiving.

Date: Fri, 16 Jun 2000 16:04:26 +0530 (IST)
From: Atul Chitnis <achitnis@exocore.com>
To: letters@lwn.net
Subject: RedHat's Update policy

To put it mildly - I am appalled at RedHat's lack of seriousness when it
comes to updating critical components.

By now, everyone and his uncle has heard about the pre 2.2.16 kernel bug.
And every distro under the sun has issued kernel updates. Every distro,
that is, except RedHat. 

Instead, there are minor bug fixes and even a couple of security fixes for
emacs, but people who have paid good money for RedHat's boxed sets are
left out there in the cold - insecure as hell because they cannot update
their kernel.

Sure, the average Joe Tux will scream "so roll your own kernel", but in
the corporate world (that redHat addresses) things don;t always work that
way.

When is RedHat going to wake up? After the first publicised break-in into
a server?

I mean, how difficult can it be for RedHat to quietly build kernel RPMs
based on 2.2.16 and ship them?

Bah! Boo! Hiss!

Atul Chitnis

--------------------------------------------------------
Atul Chitnis       | achitnis@exocore.com (PGP:6011BCB8)
Exocore Consulting | http://www.exocore.com
Bangalore, India   | +91(80)3440397 Fax +91(80)3341137
--------------------------------------------------------          

Date: Tue, 20 Jun 2000 17:22:16 +0100
From: Steve Emms <sde@linuxlinks.com>
To: lwn@lwn.net
Subject: Who controls the Linux Media ?

I run LinuxLinks.com (http://www.linuxlinks.com) - a linux
portal and recently we added a personalised calendar service to our web
site. We submitted an article to LinuxToday (owned by internet.com) and it
was published only to be pulled almost immediately. The reason given was
that website enhancements are no longer news. However a similar service
offered by another website was published. And who owns that website ? Why
internet.com of course.

OK, this calendar isn't state of the art - but it is a free service and it
does complement the existing facilities on the site. And sure, it is up to
LinuxToday what they think is newsworthy and so post. But wait a minute, 
this sort of thing has made the news before - linuxstart announced a similar 
calendar service - take a look at

http://linuxtoday.com/news_story.php3?ltsn=1999-07-13-015-10-PR

What's the difference ? Well, Linuxstart are owned by internet.com

This opens up a number of questions about how we judge the news we read.
Linux is becoming big business and there are vested interests. Web sites are
merging and being taken over by large conglomerates. Who determines the
impartiality of the news we read ? Who determines what is news and what is
advertising ?

LinuxToday is one of the major daily linux newsites and they determine that
enhancements to major Linux websites like LinuxLinks is not important. But
LinuxLinks is independent - it isn't owned by internet.com and it isn't
owned by VA Linux. Is it and sites like it being penalised because they
don't have a monopoly in the Linux media ? And is this really in the spirit
of the Linux movement ?

Steve Emms
LinuxLinks.com

Date: Sun, 18 Jun 2000 01:45:42 -0400
To: letters@lwn.net
Subject: Embedded source code
From: Zygo Blaxell <zblaxell@feedme.hungrycats.org>

I almost entirely disagree with a recent LWN letter to the editor...

>From: Bret Indrelee <breti@ancor.com>To: lwn@lwn.net
>Subject: Embedded source code

=2E..

>Some devices have design requirements and operating ranges that they
>depend on software to enforce. If it is open source, what are the legal
>issues? If someone changes the embedded code in a device and it causes a
>fault, whom is at fault?

Certainly this is not an argument against building a device that happens
to have open or free source code.  Just because the device is based on
open-source or free software, you as a consumer are not required to
actually modify it yourself--and you accept full responsibility if you do,
just as you would with a proprietary device.

Note that there's nothing about an open-source embedded device that
suddenly means that anyone can go hacking it.  The device may have
read-only software memory, for example, which prevents the software from
being upgraded on any given device.  The software would be "open source"
in the sense that it would be possible to build and program a new device
with the same or modified software.  This is actually a desirable feature
on a lot of embedded devices--you want their program memory to remain
intact even after power failures and minor accidents, and the easiest,
cheapest, lowest-power way to do that is with some kind of ROM.

Embedded devices thankfully do not have to adhere to the PC model where
everything is totally controlled by a single CPU, where software is
permitted to do anything it wants to do and time it wants to do it.
Custom hardware, particularly in a physically distributed system of
several independent microcontrollers, can build in some real
compartmentalization into the design.  This design technique tends to
have some nice beneficial side-effects, because robustness, reliability,
and security are sometimes made so easy to achieve that they actually
occur by accident.

>Do you really want someone hacking their car's engine control or ABS
>system? These are embedded systems.

The problem with this statement is its implied, but not stated, conclusion:
because some embedded systems are safety-critical, no embedded systems
should be open source.  Compare that statement with this one:

	"Do you really want some bank teller hacking their database
	or telecommunications systems?	These are desktop PC systems.
	Software for desktop PC's should therefore not be open source."

Both statements are not just flawed; they're absurd.

>An embedded system isn't supposed to be a computer. It is supposed to be
>a widget that performs a specialized task.=20

This is becoming less and less true.  Embedded systems, like all other
electronics, are becoming more and more complex, with less and less
marketable lifetime (which means less development and testing time).

One way to solve this is to build a generic device out of commodity
parts and customize or upgrade it later with software--this also leads
directly to cheaper devices if the parts become sufficiently popular.

The ultimate conclusion of this trend is that there will be more and
more devices that don't know what their purpose in life is until seconds
before they are asked to fulfill it for the first time.  These devices
will be everywhere.  The software inside them will be everywhere.

That software will begin to move around too.  I already own a printer
which can program a Java- and Javascript-enabled web browser to speak
its proprietary UDP-based administrative command language.  It's not a
platform-independent printer driver or anything, but it's a tentative step
in that direction.

Software will be everywhere--it's therefore important that it be done
right.  Since we can't expect vendors to start doing real engineering
any time soon (and we can't expect consumers to fork over the cash
to pay for it any time soon either), it would seem that the only way
to achieve quality embedded control software is to have the source code
handy so that the inevitable defects can be quickly and cheaply corrected
by the people who actually have to support them.

I recall statements made 20 years ago, by people who believed that
microcontrollers were not supposed to be used as CPU's for "real"
computers.  The only people who survived making that mistake were the
people who got out of the way before the PC revolution destroyed most
of what was the established computer industry at the time.

I hope that open-source and free software advocates realize that there
is an opportunity here that can neither be ignored nor avoided.

>The manufacturer of a DVD
>player doesn't provide a complete schematic to the buyer, why should
>they be expected to provide source code?

The last stand-alone stereo system I bought came with a complete schematic
on the last three pages of the user manual.  OK, admittedly, I bought
the machine in 1988; however, I did actually use the schematic once
or twice and found it was reasonably complete, although not entirely
accurate.  As far as I can tell, most consumer AV equipment used to come
with complete schematics as a matter of course; it's only in the last
ten years or so that I've noticed that the schematics are missing.

Of course, the schematics are in fact still available:  you just have to
order the appropriate service manual from the manufacturer.  I've done
this once or twice, but I've more often looked over the shoulders of
the occasional technician as he performed warranty service on my devices,
simply because they happen to have the things lying around the office...

Unfortunately, most modern systems are just a few ASIC's stuck on a board,
and you usually don't get much information about the ASIC's beyond what
you need to know to figure out if a misbehaving machine is cheaper to
replace than to fix.

I really do miss having this basic level of information available about
the devices that surround me.  The DVD CCA's snake-oil pseudo-cryptography
that they sell to sucker customers like the MPAA would not survive in
the marketplace if consumers were unwilling to accept not having access
to real technical information about their devices.

To: letters@lwn.net
Subject: Pointless Invective (Re: BSD license (Re: letter from Anand Srivastava))
From: Ray Jones <rjones@pobox.com>
Date: 19 Jun 2000 13:16:13 -0400

I'm not sure how the recent letter from John Adelsberger made it past
LWN's editorial filters.  It's true that BSD and GPL both have faults
when viewed from the other point of view.  It's useful to remember
this, and be reminded that each is based on different goals.  Healthy
discussions of the differences can serve to enlighten and help people
to choose the license that best matches their personal beliefs and
goals.  Unfortunately, Mr. Adelsberger's letter failed to add
constructively to the dialogue.

Attributing to the FSF (via the GPL) the goal of "enslaving
programmers everywhere" goes a bit beyond the pale.  This is obviously
not even remotely true.  Mr. Adelsberger also makes a spurious leap of
logic, equating the products of programmers' efforts with their time,
and therefore their lives, which under the GPL would be free for the
taking.

The fallacy here is easily seen by replacing "programmers" with
"mathematicians," and "products" with "theorems."  I find it
interesting to consider a mathematician trying to keep others from
publishing work based on his or her prior papers, and claiming that
others were stealing his or her "life."

Admittedly, the mathematician/theorem analogy is only that, and
shouldn't be strained too far.  I do feel, however, that the
comparison of theorems and programs is not too far off.  Certainly if
you take them as similar, then the ideas espoused by the FSF and
contained in the GPL become more natural.

If programs (and other forms of information) are more similar to
theorems than, for example, loaves of bread, then the idea of a
"propertyless information age" is far less odd than the idea of an
"information-as-property based age."  Just because we've elevated
information to a concrete form of property via national and
international legislation does not necessarily mean that that this
philosophy is fundamentally correct.  The FSF actively opposes this
trend (in my view), while the BSD seems more agnostic towards it.

I heartily support discussions (even angry ones) of the relative
merits and reasons for using GPL versus BSD licenses.  To keep such
discussions from devolving into shrill and contentless flaming,
however, we should avoid the sort of baseless accusations and
mischaracterizations that Mr. Adelsberger employs.

Full disclosure: I tend to prefer the GPL.  I've tried to write the
above from a license-independent standpoint.

Thouis Jones