See also: last week's Back page page.

Linux Links of the Week

Fscktris. Tired of waiting while your multi-Gigabyte disks run through an fsck upon reboot? Fscktris may be your answer! Now you can play a Tetris clone while your disks are being cleaned up. Note carefully, however, the caveats from Fscktris' web-page: "Fscktris should only be used if you really don't care about your data. Whilst I've had no problems with it, it comes with no guarantee of safety. This could hose your filesystem ! (although I would say it's unlikely :)".

The website formerly known as LiLAC. The website formerly known as LiLAC has been renamed MobiliX. The emphasis is on information related to Unix/Linux, laptops, PDAs, etc., though the Ecology-HOWTO and Medicine-HOWTO can also be found here.

Section Editor: Jon Corbet

This week in history

We have less specific information on the status of the Red Escolar project, since the Red Escolar News Page hasn't seen an update since June 28th. Fortunately, other pages on the site have been updated more recently, including the status page, which was updated yesterday. It still indicates implementation of the Red Escolar project is only moving forward in the San Luis Potos area.

Debian got congratulations on their port of Debian to the Netwinder two years ago. The Netwinder, however, has remained an infrequently used device, not quite living up to the promise we thought it had back then.

Corel announced its support for the Wine project, choosing it as a platform to bring their products to Linux and promising an infusion of new developers to the project as well. Two years later, the Wine project is finally approaching its first stable release. Meanwhile, of course, the financial state of Corel, and the recent large investment in Corel by Microsoft, have led to questions about Corel's possible future involvement, or lack thereof, both in Wine and in Linux.

One year ago (October 28th, 1999): To no one's surprise, licensing problems between Qt and the GPL were in the spotlight a year ago, with Corel's development as the catalyst. Corel liked using Qt for developing the software they added to the Corel Linux distribution, but their developers were much less likely to be aware of potential licensing conflicts when mixing the Qt with GPL'ed code from Debian. Of course, such problems have now been largely eliminated by the dual-licensing of Qt under the GPL, a possibility not even under discussion last year.

Last year, Comdex' standing policy of not admitting any person under the age of eighteen was under scrutiny, spawning much debate. The policy is no different at this year's Comdex. We have noticed other computer conferences, though, where such age restrictions have been removed.

Speaking of Comdex, Miguel de Icaza will be delivering one of the keynotes at Comdex this year, on Tuesday, November 14th. It was only a year ago that Miguel quit his day job in Mexico and moved to the United States. At that time, his new company Helix Code, Inc., was spoken of only in terms of "secret investors". Nowadays, they've hired a great deal of talent from the Gnome developer team and are in the process of figuring out how to make some money.

Letters to the editor

Date: Thu, 19 Oct 2000 22:56:34 -0600
From: Joe Brockmeier <jbrockmeier@earthlink.net>
To: lwn@lwn.net
Subject: Red Hat Editorial

Hey Guys,

Hope all is well at Linux Weekly News. 

Read the front page bit about the Red Hat release. I've got
to say, I think you're letting Red Hat off pretty easy. Red
Hat presents its software as being production-ready, and as
such it should be as production-ready as possible. Red Hat
is supposed to be the market-leader and as such they should
recognize that they're going to be a lot of people's first
distro. If they get a distribution that has serious bugs,
why should they consider Linux any better than Windows?

Most of the people who are going to find these bugs are not
going to understand them, and certainly won't appreciate being
part of the bug-cleaning crew. And, in their minds they're
not getting the benefits of free software - they paid good
money for it. 

Many long-time Linux users recogize that a .0 or .1 release
of Red Hat is going to have issues. But newcomers will not,
and this is not the time to be springing buggy software onto
newcomers to Linux. It's time Red Hat, and the other distros,
start releasing just one major release every year and make
the rest of them developer releases or updates. It's just not
good for retail or for end users who are not developers - a 
much larger percentage these days. 

Okay - enough tirade. Just my humble opinion.

Take care,

Zonker
-- 
Joe "Zonker" Brockmeier
jbrockmeier@earthlink.net
Zonker@Linux-Mag.com
Zonker@UserFriendly.org

Date: Thu, 19 Oct 2000 08:59:50 -0800
From: Arthur Corliss <corliss@odinicfoundation.org>
To: lwn@lwn.net
Subject: Red Hat's early software release

Greetings:

I wholeheartedly and emphatically disagree with your assesment of RH's action.
I agree that the glib issue was helped by them, but you're talking about
apples and oranges.  As I recall, glib was a *hell* of a lot more mature than
gcc 2.96 is when they did so, and so the end result were pure bug patches.
Gcc, on the other hand, has experimental features and methodologies that might
not make it into a stable release at all.  This isn't hastening adoption, this
is just ludicrous decision making, pure and simple.

One final thing that everyone seems to be forgetting:  screw what Red Hat
wants, doesn't the gcc project managers have any say about the inclusion?
Even *they* publically denounced the inclusion into a "stable" distribution
release.  RH obviously cares little about the maintianing developer's
recommendations.

So let's get this straight:  RH did no favours to anyone.  They included a
release *against* the wishes of the package maintainers, and foisted a product
onto the unsuspecting consumer that has experimental features that may even
make it incompatible with the *next* stable release.  This does *nothing* to
debug the product, it only makes RH users guinea pigs in the truest sense of
the phrase.  That's wrong.  Period.

Your endorsement of their actions is reprehensible.

That said, outside of your ridiculous editorial highlighted above, you have
one of the finest Linux e-rags out there, and I read you religiously.  Keep up
the good work.  ;-)

	--Arthur Corliss
	  Bolverk's Lair -- http://www.odinicfoundation.org/arthur/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

Date: Thu, 19 Oct 2000 10:36:23 +0200
From: Federico Di Gregorio <fog@mixadlive.com>
To: lwn@lwn.net
Subject: about this week editorial

hi,

	in your defense of redhat you compare gcc release with glibc2
release. there are big differences. when redhat released 5.0 debian
had already used the new libc for months. in unstable. and almost all
debian developers and *a lot* of other people run unstable (that is not
so much unstable, but that's a problem with debian slow release 
cycle...) so that library was not so much new or incompatible with
anything else.

	gcc was taken from *cvs* and released with a new version number
without ever worrying for compatibility with other linux systems. that's
different.

	another point is that using the userbase (the *paying* userbase)
as a testbad for broken products is a practice i can't approve. it
remainds me too much of M$ techniques of shipping broken software. the
should have a choice: stable software or over-the-edge-but-buggy one.

friendly,
federico
 
-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fog@mixadlive.com
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
  Put a GNOME on your desktop! [http://www.gnome.org]
                                      -- brought to you by One Line Spam

Date: Fri, 20 Oct 2000 21:37:10 +0000 (GMT)
From: Mike Fisk <mfisk@lanl.gov>
To: letters@lwn.net
Subject: Software testers needed

Back when everybody had to download and compile tarballs manually, we all
made implicit decisions about when we wanted to upgrade a package and if
we wanted to try a development, prerelease version or the latest stable
version.  Now that so many people just use whatever their favorite
distribution has seen fit to give them, there's less experimentation with
new versions --- unless that's what your distribution gives you.

I applaud distributions pushing the envelope with applications, but they
should advertise those distributions as being "tests", "developer
releases", "betas", etc.  As you state (in the lead article of the October
19th LWN), this is part of the open development process*.  But, I don't
care for Red Hat's eagerness to shrink-wrap these releases and advertise
them as a full release.  Microsoft and Apple will sell you test releases,
but they're clearly labelled as such and the stable versions are still on
the shelf.

People who want more reliability with Red Hat have learned to stay behind
the curve of new releases.  I think other development processes like the
Linux kernel and the Debian project achieve the same goals, but are more
up-front about it.  Many of us choose to track the development kernels or
Debian frozen/unstable trees in order to get the latest features in
exchange for being guinea pigs.

But these development versions are acknowledged as not necessarily being
the best choice for stability or usability.  For production systems, we
may choose to use stable releases.

From the IT perspective, having your staff track the unstable kernels and
distributions on their desktops or test systems also gives them
familiarity with new features before they show up on your production
systems.

*The increase in public betas of commercial software is evidence that the
need for wide exposure in testing isn't specific to open source.

-- 
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information

Date: Sat, 21 Oct 2000 12:29:27 +0200
From: Toon Moene <toon@moene.indiv.nluug.nl>
To: letters@lwn.net
Subject: When is the right time to release free software? 

Jon, Liz,

On this week's LWN Front Page you write:

> When is the right time to release free software? Red Hat has
> taken some grief recently for releasing development versions of the
> compiler and C library with Red Hat 7. One reason (of many) that has
> been put forward to explain this decision is that Red Hat is seeking
> to help stabilize the development of gcc 3.0 by increasing the
> development version's user base. By increasing the number of testers
> (also known as "users"), Red Hat 7 will flush out the remaining bugs
> and provide motivation for the gcc team to get 3.0 out there.

[ Note that I write the following as GNU Fortran maintainer, and
  do *not* speak for the GCC Steering Committee ]

Perhaps I can correct one misunderstanding from the start:  Red Hat did
not just "drop" a development *snapshot* of GCC into Red Hat 7 - they
took the 20000731 snapshot and applied a boatload of bug fixes to it
before they shipped it as Red Hat 7's system compiler.

In fact, this is not unlike the way the GCC team organises new
releases:  A CVS branch is made and is beaten on until we think we
ousted all known bugs.  Therefore there's no a-priori reason to assume
that Red Hat's GCC "2.96" is buggier than the official GCC releases.

Because the relevant bug fixes were "fed back" into the official GCC
development tree, it *did* help to flush out bugs, but in a different
way you foresee (although the effect you mention above will exist).

No, Red Hat's move is interesting in a different way:

*Nobody knew what they were doing until days before it happened*.

On the 23rd of September I sent the following note to the SC list:

> Listening to the rumor mill on the Internet, I get the impression that
> the (GNU/)Linux distribution according to Red Hat, version 7.0 - due
> early next week, will contain an (ammended) snapshot version of GCC
> 2.96.

> I do not oppose this move per se; however, due to the fact that the
> projected release time for GCC-3.0 was "end of the year", I also 
> didn't particularly take care of bundling related Fortran Frontend 
> updates that are interdependent.

In fact, what happened was (as became clear in hindsight) that the
snapshot on the 31st of July - which is the basis of Red Hat 7's system
compiler - was taken right in the middle of those updates I mention
above.

Now, fortunately, the damage is small - the (g77) compiler will crash if
you feed it both -g and -fdebug-kludge options when compiling Fortran
source with COMMON BLOCKs in it; at least it won't generate incorrect
code ...  Furthermore, four weeks after the release, apparently nobody
has run into this problem yet (at least I haven't seen a bug report
about it) ...

However, it could have been worse, and to come to the point of my
message:  It could have been avoided !

If Red Hat had communicated with the developers of GCC, this could
easily have been corrected by:

1. Red Hat waiting to take the "quiescent" snapshot that would be
   the basis for their system compiler.

2. Me working somewhat faster to meet their deadline.

3. Red Hat applying the changes _after_ taking the snapshot.

I sincerely hope that this non-communication was an unfortunate
incident, and won't happen again.  We volunteers in various free
software projects have to work with the information presented to us; if
someone just takes the work and runs, they get what they asked for ;-)

Perhaps it's good to stress again that I write this as my personal view
on the matter, in my function as GNU Fortran maintainer.

Cheers,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

From: "David C. Spaeth" <dspaeth@taskiss.com>
To: <lwn@lwn.net>
Subject: Thank you!
Date: Fri, 20 Oct 2000 23:36:05 -0500

You've summed up my opinion about Red Hat's 7 release more succinctly than I
ever could!  Thanks! I really appreciate Red Hat's efforts in reguard to
it's releases. With their work, my systems are steadily becoming more and
more able to assist me in managing UNIX systems (SCO, Linux, AIX, and
Solaris/SunOS) for my customers. I also run Linux on about 6 systems at
home...3 as only Linux, 3 as dual-boot (my kids lie StarCraft and Diablo
II). Thanks for not slamming Red Hat!

David Spaeth
Sr. SysAdmin
Taskiss.com

To: letters@lwn.net
Subject: Secure Deletion
Date: Sat, 21 Oct 2000 17:56:31 -0500
From: Christopher Browne <cbbrowne@hex.net>

The "File That Would Not Go Away" problem is indeed more of a problem
than people expect, and the "Oh, I'll Just Delete The File" thing
represents a perpetually misleading Deus Ex Machina in literature and
Television.  And the misunderstandings of Hollywood do not just fall
out of their ignorance; I don't think that the issue is, generally
speaking, well-understood even by those that should know better.

Just this week, the TV show "Dark Angel" trotted the situation out
where the hacker friend of the protaganist prevents the bad guys from
pulling her picture out of prison records by, at the last possible
moment, "deleting her record from the database."

COMPETENTLY RUN prison information systems are likely to be running a
journalling database system [any of the major names, Oracle, Informix,
DB/2, Sybase, Microsoft SQL Server, should do] for their database
needs.  The Bad Guy may react to this setback with a little less
fatalism:

  "Oh, well, let's just take the last cold backup, sitting on
   tape, along with the Oracle archive logs, continuously being dumped to
   tape as they are produced, and recover them to a duplicate system."

Keeping data ephemeral on systems intended to keep it persistent is
about as problematic as keeping data persistent on ephemeral systems.

The "most ephemeral" thing is data that sits in memory that will get
destroyed as soon as power goes off.  Mind you, that is misleading when:
 - RAM on my PalmPilot _isn't_ lost when I shut it off;
 - Data might get swapped out to disk

At the other end of the scale, databases tend to be characteristic of
the "least ephemeral thing;" transaction logs, if carefully backed up,
can't be deleted via anything a remote hacker might try to do.  After
all, if updates get dumped onto tape immediately, and the tape quite
quickly gets processed through, dropped into archives, it may become a
tremendously challenging thing to try to remove data.

This implies that the typical Hollywood scenario of "We'll have to
hack in to purge the records from the police files" represents so much
nonsense.  The last I heard, the RCMP was using Trusted Oracle for
such applications; I'm sure similar is true for many other police
forces.

The funniest relevant anecdote I've heard is of a payroll system where
they didn't want to have the high salaries of corporate executives
available to the computer systems staff.  Every couple weeks, an
executive assistant, entrusted with this data, would temporarily enter
the rates into the system, run cheques, carefully keeping them from
the eyes of the rest of the computer centre staff, and then remove the
salaries, leaving everyone none the wiser.  Or so they thought.  The
net result of the process was that the "fingerprints" of the executive
pay information was being recorded three or four EXTRA times since the
DBMS logged each modification.  Back to the drawing board...

Files fall somewhere in between in terms of robustness.  They are
certainly more "stable" than RAM, but are less so than a
transaction-logged DBMS.  Every time someone adds DBMS technology,
such as logging/journalling, to a filesystem, files become a little
more difficult to _comprehensively_ purge.

The answer may ultimately be to implement some sort of "Secure
Temporary File System" providing semantics to guarantee that files can
be securely deleted, where temporary files become _truly_ temporary.
--
cbbrowne@hex.net - <http://www.hex.net/~cbbrowne/linux.html>
"C++ is more of a rube-goldberg type thing full of high-voltages,
large chain-driven gears, sharp edges, exploding widgets, and spots to
get your fingers crushed. And because of it's complexity many (if not
most) of it's users don't know how it works, and can't tell ahead of
time what's going to cause them to loose an arm." -- Grant Edwards

Date: Thu, 19 Oct 2000 11:41:16 +0000
From: Oliver White <ojw@iinet.net.au>
To: strombrg@nis.acs.uci.edu, letters@lwn.net
Subject: RE: kde and gnome and pr and licensing

>KDE has fixed their license problem finally, but it's probably
> (hopefully) too late for KDE to recover from Gnome getting the
> critical mass of developers.

Licencing is a major issue. However, there are several technical reasons
that still keep developers from working with Gnome rather than KDE. The
Gnome folk are, for the most part, 'Old School' hackers. They depend on
Emacs, C and think diagrams are for the weak.

This is all very well. However, there is a certain snobbishness towards
people who want to develop in C++, using more modern (not necessarily
better) techniques for communication like UML, and who'd like to use an
Integrated Development Environment.

As far as I can see, while KUML is comming along nicely, nobody is
interested in developing a Gnome UML tool, though the potential to share
code and resources early on is there. Support for C++ Gnome development
is comming along quite slowly, and gIDE is a long way behind KDevelop.

These cultural reasons, rather than reasons of idealism, are enforcing
the divide between the KDE and Gnome projects, I can only hope that in
future the choice will simply be based on which environment the
developer prefers.

--
Oliver White
www.worldforge.org

Date: Sun, 22 Oct 2000 14:01:41 -0300
From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
To: letters@lwn.net
Subject: Red Escolar (Re: Stop the colors already!)

Peter Samuelson <peter@cadcamlab.org> said:

[...]

> So now, according to the LWN sidebars, we have the five mentioned above
> plus Black Cat Linux, BluePoint Linux, White Dwarf Linux and Green Frog
> Linux, not to mention the variations Darkstar Linux, Red Linux, Redmond
> Linux, Think Blue Linux and the Red Escolar Project.  Oh, and don't
> forget the ones that incorporate the Red Hat name directly, like VA/Red
> Hat and KRUD.

"Red Escolar" is Spanish for "School Network", "red" is "network". No
colors were harmed when naming this.
--
Horst von Brand
vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32
672616

Date: Sat, 21 Oct 2000 08:24:28 +1100
From: Tim Josling <tej@melbpc.org.au>
To: letters@lwn.net
Subject: Undefined expressions in C

"The hunt for undefined code. 

Here's one kind of problem that a new compiler can turn up. Most
C 
programmers learn early on to avoid code like: 

a[i] = i++;

The results of this kind of code are undefined; the array
assignment could happen either before or after the value of i is
incremented."

The expression above, as no doubt many people have pointed out,
is actually OK. Section 3.3 of the 1988 ANSI C standard says that
you can only assign once to a variable in an expression.  So for
example


i = i++ + 1;

is not allowed because i gets assigned to twice.

But 

a[i] = i++; 

is OK - i is only assigned to once, and the value used for the
array subscript is the value before the auto-increment.

Tim Josling

Date: Fri, 20 Oct 2000 15:42:41 +0100
From: John Winters <john@linuxemporium.co.uk>
To: lwn@lwn.net
Subject: Kernel development page - 2000-10-19

Hi there,

At the risk of flogging a dead horse I'd just like to pick up on
something said on your kernel development page this week:

Quote============================

The hunt for undefined code. Here's one kind of problem that a new
compiler can turn up. Most C programmers learn early on to avoid code
like: 

    a[i] = i++;

The results of this kind of code are undefined; the array assignment
could happen either before or after the value of i is incremented.

End Quote========================

The final sentence is the problem.  Yes, it's undefined but the last
part gives more than a passing impression that the undefinition is
confined to when the increment occurs.  That's not true at all.  The
code simply has no meaning within the confines of the C language - you
might get the result you expect; you might get a result consistent with
the increment having happened before or after the assignment; you might
get any behaviour at all.  The classic defence of such code is, "I don't
care whether the increment happens before or after.  Either will do what
I want."   This alas fails because there's no guarantee that the
increment will happen at all (or that the assignment will happen, or
that the code will even compile).

Apologies if you already know all this but even as a simplified
explanation the quote above can lead to problems.

Regards,
John Winters

-- 
John Winters.  Wallingford, Oxon, England.

The Linux Emporium - the source for Linux CDs in the UK
See http://www.linuxemporium.co.uk/