ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   03 Mar 2002  15:39:47
 To : All
 Subject : URL: http://www.lwn.net/2002/0221/letters.php3
 -------------------------------------------------------------------------------- 
 

    [1][LWN Logo] [No ads right now]
    [LWN.net]
 
    Sections:
     [2]Main page
     [3]Security
     [4]Kernel
     [5]Distributions
     [6]Development
     [7]Commerce
     [8]Linux in the news
     [9]Announcements
     Letters
    [10]All in one big page
 
    See also: [11]last week's Letters page.
 
 Letters to the editor
 
    Letters to the editor should be sent to [12]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 [13]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 ([14]http://glame.sourceforge.net).
   its filternetwork nicely shows latency behaviour, and since it
   supports both ALSA and OSS, you can compare.
 
 * the MusE sequencer ([15]http://muse.seh.de)
   makes heavy use of the ALSA sequencer library.
 
 * the ardour hd-recorder/daw ([16]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,
 
 joern
 btw, if you're interested in using linux for audio, i'd like to
 invite you to the linux-audio-user list at
 [17]http://www.linuxdj.com/audio/lad/user.php3.
 developers may want to check out linux-audio-dev at
 [18]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        [19]http://baylink.pitas.com             +1 727 647 1
 274
 
    "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 <[20]http://lwn.net/2002/0214/letters.php3> the
 DMCA does not apply in Europe. However the EUCD
 <[21]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
    [22]Eklektix, Inc. Linux powered! Copyright Л 2002 [23]Eklektix, Inc.,
    all rights reserved
    Linux (R) is a registered trademark of Linus Torvalds
 
 References
 
    1. http://lwn.net/
    2. http://lwn.net/2002/0221/
    3. http://lwn.net/2002/0221/security.php3
    4. http://lwn.net/2002/0221/kernel.php3
    5. http://lwn.net/2002/0221/dists.php3
    6. http://lwn.net/2002/0221/devel.php3
    7. http://lwn.net/2002/0221/commerce.php3
    8. http://lwn.net/2002/0221/press.php3
    9. http://lwn.net/2002/0221/announce.php3
   10. http://lwn.net/2002/0221/bigpage.php3
   11. http://lwn.net/2002/0214/letters.php3
   12. mailto:letters@lwn.net
   13. http://www.alsa-project.org/applications.php3]
   14. http://glame.sourceforge.net/
   15. http://muse.seh.de/
   16. http://ardour.sourceforge.net/
   17. http://www.linuxdj.com/audio/lad/user.php3
   18. http://www.linuxdj.com/audio/lad/
   19. http://baylink.pitas.com/
   20. http://lwn.net/2002/0214/letters.php3
   21. http://uk.eurorights.org/issues/eucd/
   22. http://www.eklektix.com/
   23. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор