[LWN Logo]
[LWN.net]

Sections:
 Main page
 Security
 Kernel
 Distributions
 Development
 Commerce
 Linux in the news
 Announcements
 Letters
All in one big page

See also: last week's Letters page.

Letters to the editor


Letters to the editor should be sent to letters@lwn.net. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them.

February 21, 2002

   
From:	 =?iso-8859-1?Q?J=F6rn?= Nettingsmeier <nettings@folkwang-hochschule.de>
To:	 letters@lwn.net
Subject: ALSA kernel integration
Date:	 Thu, 14 Feb 2002 11:30:29 +0100

hello lwn folks !


in this week's kernel section, you mention the integration of ALSA
into the kernel. you say

> ALSA will not immediately amaze Linux users with lots of new capabilities.

this is true if you only care for mail notification beeps and the
occasional splatch sounds while playing q3. otherwise, you will find
your audio subsystem has improved significantly:

* ALSA supports many cards that cannot be used with the current
  kernel drivers.

* ALSA provides far lower latencies than OSS possibly could.

* ALSA has a versatile sequencer with easily patchable MIDI
  connections.

* ALSA includes key features needed for professional audio
  applications, such as decent multi-channel support.


later, you mention

> [...] but quite a few applications also support the ALSA native API. 
> [linked to http://www.alsa-project.org/applications.php3] 

not your fault, but this page is woefully out-of-date. it still
mentions the deprecated pre-0.9.0 API and shows only a fraction of
the whole picture.

for professional audio applications using the ALSA library, check
out the following examples, among many others:

* the GLAME audio editor (http://glame.sourceforge.net).
  its filternetwork nicely shows latency behaviour, and since it
  supports both ALSA and OSS, you can compare. 

* the MusE sequencer (http://muse.seh.de)
  makes heavy use of the ALSA sequencer library.

* the ardour hd-recorder/daw (http://ardour.sourceforge.net).
  while not yet ready for the faint of heart, it stretches the ALSA
  API to the limit in terms of low-latency multichannel full-duplex
  operation.

most linux-based audio development nowadays concentrates on ALSA.
all the most widely used applications now provide native backends. 
and if you want to use multichannel hardware, there is no real 
way around ALSA anyway.


best wishes,

jörn


btw, if you're interested in using linux for audio, i'd like to
invite you to the linux-audio-user list at
http://www.linuxdj.com/audio/lad/user.php3. 
developers may want to check out linux-audio-dev at 
http://www.linuxdj.com/audio/lad/.

btw2, i'm not intending to bash OSS. it has served its purpose well, 
and without it, linux audio would still be stuck in the stone age.
   
From:	 Myrddin Ambrosius <imipak@yahoo.com>
To:	 letters@lwn.net
Subject: Assumptions in the Linux/Unix world
Date:	 Thu, 14 Feb 2002 06:34:43 -0800 (PST)

Dear editors,

  I am always amazed at the number of assumptions that
people make, in computing in general, but have
hitherto felt that Linux users generally knew more,
because they had the option of doing so.
  The Sync "scandal" is one case where I'm not so
sure. Sync has never flushed straight to disk. That's
one reason you generally called sync three times in
succession, when you needed to be absolutely sure.
This must be burned into the retinas and brains of
goodness-knows how many system admins, and yet it's
only now being discovered that, because of the way
hardware works, it's actually necessary for sync to
not "really" sync? Oh, goodness!
   Then, there's this thing about auditing from a
clean boot. Oh, wow. You mean, the machine has to be
in a known state, in order to reliably determine the
state of the system as a whole? I'd never have
guessed! That's like saying an observer is part of the
process of observing. Something the hard-science types
have been saying for a long time.
   Last, but by no means least, Sun's announcement
indicates they have discovered their own flawed
assumptions. Sun has fluctuated a lot, on Linux. At
one point, it was a way for them to keep users on old,
otherwise defunct Sun hardware, which at least kept
the hardware maintenance contracts going for a little.
Now, Sun are starting to edge towards the path IBM
have taken - seeing Linux as a serious server OS, with
a significant potential customer base. Enough so, that
it's worth their while to put money into it.
   I think it's time that manufacturers and coders
alike faced reality - assumptions are buggy logic. If
they work, it's by chance. Since you can't yet check
minds into CVS, the bugs are slightly harder to find,
but they're still bugs, and bugs need fixing.

Jonathan Day

   
From:	 Dan Stromberg <strombrg@nis.acs.uci.edu>
To:	 letters@lwn.net
Subject: sync
Date:	 Thu, 14 Feb 2002 12:30:38 -0800

What I heard was that sync was guaranteed to do two things:

1) Schedule all dirty buffers for being written to disk
2) Write all previously scheduled buffers to disk before returning

This means that just one sync isn't enough to get things written to
disk, but running it twice means the stuff written to the buffer cache
at the time of the first sync is committed to disk.

This seems to be partially responsible for the superstition that you
should always run sync three times: twice is necessary for portability;
thrice is one extra.

-- 
Dan Stromberg                                               UCI/NACS/DCS

   
From:	 "Jay R. Ashworth" <jra@baylink.com>
To:	 doc@searls.com
Subject: Real Networks
Date:	 Thu, 14 Feb 2002 10:55:46 -0500
Cc:	 letters@lwn.net

LWN linked your Linux Journal piece concerning RealNetworks, and
whether the train has left the station (*finally* picked up a copy of
the manifesto this week, BTW; better late tan never, I guess :-).

There's one item that I'm sure wasn't missing from your analysis, but
which you didn't seem to touch on in the article, and that's the Money.

As in "Follow The"?

One of the major things that has always annoyed *me* about RealPlayer,
and to which you allude, is that even on non-live streams, RP has
traditionally made it difficult, if not impossible, to *save* the
output of the stream -- and their .ram pointer file thing is another
level of indirection aimed at the same end.

But of course, these things aren't accidents.

Real's major selling point to *its customers* -- who are content
providers -- is "see?  We're doing our best to make it difficult for
your listeners to steal your stuff."

Forgetting who the *real* customer is is a common failing in this sort
of analysis -- the quintessential example, of course, being commercial
television.  People tend not to realize that TV networks are in the
business of selling *eyeballs* to *advertisers*, rather than programs
to viewers.  Better really is the enemy of good enough, at least in
that context.

This is why the RP Linux developer reached his pain threshhold, and
it's not at all uncommon -- it's my primary explanation to client why I
install Netscape 6.2 on their machines rather than IE: Microsoft isn't
*in* this for you.

Now, admittely, Netscape isn't either, but not being the monopoly
player (I figure, if the "yell it loudly enough and people will believe
it" approach works for them... >:-), they have to cater to their target
audience just a bit harder.  And, FWIW, Netscape 6.2 is ready for prime
time, a point I guess I should make, given the scathing review I wrote
of 6.0, which LWN was kind enough to publish.

In any event, it's a seachange for the content industry, and their
support of DMCA and SSSCA should make it perfectly clear that they're
going to take quite some time to get on the cluetrain, if indeed their
tickets are still valid.

Our Plans For World Domination...

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink                             RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 647 1274

   "If you don't have a dream; how're you gonna have a dream come true?"
     -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
   
From:	 "Mamading Ceesay" <mceesay@evangineer.force9.no.spam.co.uk>
To:	 <dps@io.stargate.co.uk>
Subject: EUCD - was Region coding---the truth vs. what is said
Date:	 Wed, 20 Feb 2002 20:26:43 -0000
Cc:	 <letters@lwn.net>

As you correctly noted in your email published in 
LWN <http://lwn.net/2002/0214/letters.php3> the 
DMCA does not apply in Europe. However the EUCD 
<http://uk.eurorights.org/issues/eucd/> is the 
european equivalent of the DMCA.  It will erode 
fair use rights in a similar manner, so EU citizens
have a cause for concern.

Regards,
Mamading Ceesay

"Don't worry about what anybody else is going to do. 
The best way to predict the future is to invent it."

-- Alan Kay

   
From:	 Mark Richards <m.richards@utoronto.ca>
To:	 letters@lwn.net
Subject: Re: Security Prespective
Date:	 Sun, 17 Feb 2002 12:38:16 -0500

I would just like to comment on Phil Cameron's letter to the editor in Feb 
14th's lwn.net.

Phil discusses several security updates that have no known exploits or have 
only theoretical exploits.  I think it is worth pointing out that just 
because a patch is issued, does not mean that all systems will be patched.  
Thus, even if a security hole has no known exploit, or such exploits are 
purely theoretical, if nobody applies the patch then the systems remain 
vulnerable, just waiting for someone to turn a theoretical exploit into a 
real one.

After all, wasn't there a linux work recently that exploited a really old NFS 
and LPR vulnerability?  And wasn't there a patch available to fix the 
vulnerability exploited by Code Red?  Yet these worms still caused real 
damage.

I think we must assume that any vulnerability is as dangerous as it could be 
in the most devastating attack possible, since given enough time someone can 
produce that attack.

Mark Richards
 

 

 
Eklektix, Inc. Linux powered! Copyright © 2002 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds