See also: last week's Back page page.

Linux links of the week

Section Editor: Jon Corbet

Letters to the editor

Date: Wed, 09 Jun 1999 22:41:49 -0400
From: William Hoffman <whoffman@erols.com>
To: letters@lwn.net
Subject: This is the lynchpin

in your enumeration of the challenges facing the RedHat IPO and the
Linux community as a whole:

"The GNU General Public License (GPL) might not be enforceable. This
concern arises mostly because the GPL has never been tested in court."

It's a coin-flip which way a conservative Supreme Court would go on the
GPL. On the one hand, numerous powerful vested interests (MS only the
first and most visible among them) would like to be freed from this
turbulent priest. On the other hand, capital thrives on innovation that
leads to lower costs and higher profits, and big software users are
jazzed about Linux's MCI potential against Microsoft's obnoxious Ma Bell
status. Either way, though, the game will be decided only partly in the
marketplace. It may take years to settle the issue. But it is the
Supreme Court, I believe, that will deal the last card.

Linux supporters are not helpless in this. The more hardware and
software vendors who actively (i.e., $$$) support GPL alternatives, the
harder it will be for the court to uproot them. All protestations of
obiesance to constitutional principle and the beauties of equal justice
aside, when the day of decision arrives the Supreme Court almost always
decides in favor of _net profit_. The longer GPL proponents can stall
that day, the better the odds are in their favor. Yet I fear that in the
rush to recruit corporate sponsors and formulate standards that will
allow newbies like me to play Half Life on their laptops, the importance
of this somewhat abstract yet absolutely crucial legal underpinning may
be lost. And we will have to wait another generation before a similarly
promising new model of collaborative property relations develops to
challenge the hitherto dominant form, which appears increasingly likely
ultimately to lead only to monopoly, ruin and decay.

William Hoffman
 whoffman@erols.com

Date: Thu, 3 Jun 1999 09:07:54 +0200 (CEST)
From: Helge Kreutzmann <kreutzm@itp.uni-hannover.de>
To: letters@lwn.net
Subject: RH 6.0 pricing

Dear Editor !

One point you missed in your editorial of the June 3rd issue regarding
RH's pricing are the international customers. Until 5.2 RH was priced
simmilar to e.g. SuSE, making it an alternative choice. Since online
time is expensive (at least here in Germany) many bought the CD set as
downloading is not a real option.

RH's new strategy hinders its market acceptance: The $80 set has no
extra value, as long distance calles into the US are too expensive as
well (and would have to be done in inconvenient times as were are
several hours off US time zones); having to order directly from RH the
$40 set is also inconvenient (because of the exchange, you probably
need a credit card etc.).

The conclusion can only be for non-US-customers: reconsider using RH.
While Alpha users (like me) now have serveral choices I do feel sorry
for the sparc users.

My $0.02 worth

 Regards

       Helge Kreutzmann


            Vote against spam: http://www.politik-digital.de/spam/

Is your penguin 64 bit ?  -->   http://www.stud.uni-hannover.de/~helgek
               Helge.Kreutzmann@stud.uni-hannover.de
                     kreutzm@itp.uni-hannover.de

Date: Sat, 05 Jun 1999 07:17:32 -0600
From: Jeffery Cann <jccann@home.com>
To: letters@lwn.net
Subject: The future of Red Hat?

Read on Lwn in 1999:

   The end result is that consumers of the system will not be all that
   put out. Even $80 is not a huge price to pay for a quality
   operating system.

Read on Lwn in 2000:

   The end result is that consumers of the system will not be all that
   put out. Even $160 is not a huge price to pay for a quality
   operating system.

Read on Lwn in 2001:

   The end result is that consumers of the system will not be all that
   put out. Even $320 is not a huge price to pay for a quality 
   operating system.

Read on Lwn in 2002:

   The end result is that consumers of the system will not be all that
   put out. Even $640 is not a huge price to pay for a quality
   operating system.


I find it interesting that the opinion is that "... consumers of the
system will not be all that put out."  I'm put out.  I'll pay $80 for
Red Hat's (buggy) distribution when hell freezes over.

Jeffery Cann
jccann@home.com

From: Decklin Foster <decklin@home.com>
Date: Mon, 7 Jun 1999 18:06:12 -0400
To: letters@lwn.net
Subject: Red Hat Core is still GPLed

> Resellers of Linux, however, have more to worry about. Companies
> like the Linux Mall, Linux System Labs and others, which certainly
> played a role in making Red Hat the successful company that it is,
> are now finding themselves squeezed on Red Hat's expensive
> distribution. Evidently Red Hat's reseller price is so high that a
> number of these companies are selling it at a loss.  Simultaneously
> they are finding themselves undercut by Red Hat itself, which is
> offering a cheaper version that they can not sell.

What's the point? Red Hat is GPLed, as it always has been -- there's
no way that Red Hat can keep people from copying/selling their
distribution unless they make everything they contributed proprietary
(not likely). A cursory scan of LSL's site shows that they are still
selling the GPL cd (I switched to FTPing Debian over my cable modem a
while ago, so I haven't really been keeping up) -- and the pre-order
is $0.00.

While I don't use Red Hat myself, I don't like to see people feeding
the big fear that they're going to be the new Microsoft or something
(I have never worried about this, and anyone who does out to try out
Debian for a minute on a spare machine.) Please try to be a little
more objective.

Date: Thu, 3 Jun 1999 10:51:57 +0300 (GMT)
From: Roberto Alsina <ralsina@unl.edu.ar>
To: editor@lwn.net
Subject: Re: KDE wars


I just can't believe that Nathan Myers is suggesting that the solution
for a theoretical problem (namespace pollution by Qt's signal/slot/emits)
is to make it a practical problem.

I mean: currently there is no problem with that, since it does not
collide with anything, and he proposes to actually *make* it collide.

He is proposing to make the possible problems happen!

That's so weird I can't even start to understand it.

 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  ralsina@unl.edu.ar
 (_Y_.)' ._   ) `._`.  " -.-'   Centro de Telematica
  _..`-'_..-_/ /-'_.'           Universidad Nacional del Litoral
(l)-'' ((i).' ((!.'             Santa Fe - Argentina
                                KDE Developer (MFCH)
An opinion you can't give reasons for is not an opinion worth having (I)

Date: Thu, 03 Jun 1999 10:58:26 +0100
From: Derek <derek at fortstar dot demon dot co dot uk>
To: letters@lwn.net
Subject: KDE Wars

I was more than a little surprised by the attitude taken by Nathan
Myers in his letter to last week's LWN where he criticises Troll Tech
for it's use of non standard directives in it's C++ Qt library.

Firstly, this is a Troll Tech/Qt issue, not a KDE one. The KDE team
are users of Troll Tech's product, and while they have an indirect say
in what goes into it, they are not really in a position to start
redefining Troll Tech's macros in the KDE source. Such action is bound
to break things in both existing and future releases of code. Pointing
the finger at the KDE developers and crying "arrogance" is unfair.

While I agree that Troll Tech could have chosen less contentious names
for their macros, anybody who writes library or header code is, by
definition, claiming a part of the namespace. Troll Tech's claim to
the 'emit' macro is no less valid than, as a random example,
'GTK_TOOLBAR_TEXT'. If I want to use that string in one of my
programs, I can't, but that's hardly a major problem. Besides that,
Troll Tech aren't claiming to have extended C++. The 'emit' macro, for
example, is defined as empty. It's just a cue for the person reading
the program, or, in some cases, the Meta Object Compiler which Qt uses
as a compilation tool.

My real problem with Nathan's argument is his assertion that other
software developers should deliberately attempt to use these macro's
names in other contexts in order to hobble the ability of users to use
KDE and other Qt related software. What sort of attitude is that to
adopt in the free software community? Flame wars about which products
are better, and which is the way forward are all very well, but this
sort of thing is just plain nasty.

One thing which the KDE/GNOME war has shown is that the open source
community can be an ungrateful lot. Troll Tech have donated a huge
amount of work to us, but because they are trying to make a living out
of their product as well, they get massive amounts of grief from those
in ivory towers.

Qt-2.0 is due out soon, and since a lot of work is being done on
rewriting Qt based software for it, this might be a good opportunity
in order to rename those macros to something a little less
contentious.  Anyone who feels strongly enough about the issue should
make their feelings felt to Troll Tech, who might be responsive if
their header files are causing genuine problems.

In the meantime, deliberately trying to sabotage any software which
depends on the Qt library is the sort of action which takes open
source software backwards in leaps and bounds.

Derek Fountain
Southampton, England

Date: Sun, 06 Jun 1999 23:55:05 -0400 (EDT)
From: Bill Soudan <wes0472@osfmail.isc.rit.edu>
Subject: A new KDE war?
To: editor@lwn.net, ncm@cantrip.org


I read Nathan Myers's short note on "KDE Wars" as appeared in the June
3, 1999 edition of Linux Weekly News.  Normally I am fairly laid back
about the KDE vs. GNOME situation, however, this article in particular
caught my eye right away.  Is the author trying to start a new war
here?

>From his note:

> The solution remaining for the rest of us is to assert our right to
> these names by using them freely, in header files of other
> libraries, as formal argument names, struct member names,
> member-function names, and as local variables in inline functions:

>  inline int do_stuff(int signals) { int slots; ...

> We can also insert "#undef signals", etc., directives.  Eventually,
> as they find it increasingly difficult to build programs that rely
> on useful non-KDE libraries, the KDE developers will be forced to
> give up their claimed monopoly on those names, and begin to act as
> responsible members of the cooperative software development
> community.

While the author may have a valid point, deliberately writing code
with the pointed purpose of breaking Qt and KDE seems to be the wrong
way to go about this issue.  As a Qt programmer myself, I would gladly
argue Qt's signal/slot mechanism is so well integrated into the
language that it is worth losing three relatively obscure keywords.
Futhermore, there are many other toolkits and applications that claim
more than three generic macro keywords.  When was the last time the
author browsed /usr/X11R6/include/X.h?  Would he code a library with
the express purpose of breaking X applications by including:

   inline int DoStuff(bool Above) { int CurrentTime; ...

I would think not, if he desired his library to be useful.

Finally, would you really think of yourself as a "responsible member
of the cooperative software development community" writing this type
of code?  If yes, please take on the other problem toolkits in
addition to Qt.

Bill Soudan
wes0472@rit.edu

Date: Mon, 7 Jun 1999 13:33:20 -0700 (PDT)
From: Nathan Myers <ncm@best.com>
To: wes0472@osfmail.isc.rit.edu
Subject: Re: A new KDE war?

Bill Soudan <wes0472@rit.edu> wrote:
 
> I read Nathan Myers's short note on "KDE Wars" as appeared in the
> June 3, 1999 edition of Linux Weekly News. ... Is the author trying
> to start a new war here?

No.  I would like nothing better than for Qt or KDE to fix their
broken headers.
 
> ... When was the last time the author browsed /usr/X11R6/include/X.h? 

The macros defined in X.h are a problem, but they are an old and
well-known problem.  The presence of old problems does not excuse
introducing new ones.  Rather, we should know better, given the
example.

The correct solution, as for all problems of this nature, is to rename
the macros according to the industry-wide convention: all upper-case,
and scoped by a library-identifying prefix.  If this has been done in
the first place, as it is done routinely in well-behaved libraries,
this exchange would not be necessary.  If Troll Tech and KDE refuse to
fix their own problems, they can expect continuing conflict.

Using the names "emits", "signals", and "slots" in other libraries
(e.g. the Linux kernel headers!) helps preserve our right to use those
names, just as exercising our constitutional rights helps to preserve
our freedom.

Nathan Myers
ncm@cantrip.org