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 editorLetters 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 | ||
|