ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   31 Aug 2001  15:53:05
 To : All
 Subject : URL: http://www.lwn.net/2001/0830/letters.php3
 -------------------------------------------------------------------------------- 
 

    [1][LWN Logo] 
    
                                [2]Click Here 
    [LWN.net]
    
    Sections:
     [3]Main page
     [4]Security
     [5]Kernel
     [6]Distributions
     [7]On the Desktop
     [8]Development
     [9]Commerce
     [10]Linux in the news
     [11]Announcements
     [12]Linux History
     Letters
    [13]All in one big page
    
    See also: [14]last week's Letters page.
    
 Letters to the editor
 
    Letters to the editor should be sent to [15]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.
    August 30, 2001
    
    
 From:    Garry Knight <garryknight@bigfoot.com>
 To:      letters@lwn.net
 Subject: Linux's birthday
 Date:    Thu, 23 Aug 2001 14:11:27 +0100
 
 Dear Sirs
 
 I see from your front page on Thursday 23 August that there's some
 controversy over exactly when Linux's first birthday will be. You quote
 August 25 and October 5 as possible candidates.
 
 On page 87 of Linus's autobiography, "Just for Fun", Linus himself says:
   "There's a protocol for numbering releases. It's psychological. When you
 think a version is truly ready to be released, you number it version 1.0.
 But before that, you number the earlier versions to indicate how much work
 you need to accomplish before getting to 1.0. With that in mind, the
 operating system I posted to the ftp site was numbered version 0.01. That
 tells everybody it's not ready for much.
   "And yes, I remember the date: September 17, 1991."
 
 Could this be a better candidate for a birthday?
 
 --
 Garry Knight
 garryknight@bigfoot.com  ICQ: 126351135
 Linux registered user 182025
 
    
 From:    "Robert A. Knop Jr." <rknop@pobox.com>
 To:      <letters@lwn.net>
 Subject: Sad about Source Forge Enterprise Edition
 Date:    Fri, 24 Aug 2001 10:26:34 -0500 (CDT)
 
 Before I say this, I must say that I don't fault VA Linux.
 
 However, seeing them going to selling proprietary extentions to an open
 source project makes me sad.  Not because I think that VA Linux has sold
 out or anything-- but because it's yet one more nail in the coffin of what
 I had hoped would be the software model of the future.  That model was
 much like FSF's: software would be free, and users (large and small)
 who wanted it would pay for maintainance and support.
 
 The argument always went something like, what if we're a large company,
 and we want to buy a lot of hardware and have it just work?  The answer
 was, buy your hardware from somebody like VA Linux, and then buy a support
 ocntract for all the software.  If you find that the support you're
 getting is unsatisfactory, the software is free, so you can find another
 company (say, Red Hat) to support your software installation.  You're not
 locked into mandatory support contracts forever more from one single
 monopoly.  Or, if you're a smaller site, find an outfit with a smaller
 plan, or hire a Linux Geek who will both support your installation as well
 as contribute back to the efforts of free software programmers (and,
 thusly, be enough in the community to draw on the de facto software
 support that comes from it).
 
 Alas, VA Linux, like Red Hat, was a sort of poster child for this.  They
 were a hardware vendor who sold hardware with (at least mostly) free
 software.  But now that model is gone, and to survive, they feel that they
 have to go selling and supporting proprietary software.
 
 As long as VA Linux does continue to support and contribute to the Open
 Source community as they do now, with things like Sourceforge and keeping
 Eric Raymond on staff, I won't fault them or bear ill will towards them.
 But their selling of proprietary extentions to the Sourceforge software
 does seem to be one more strike agains those of us who still want to think
 that the Free Software/Open Source model of software development is one
 that can work and that ultimately will be the best for everybody.
 
 -Rob
 
    
 From:    David.Kastrup@neuroinformatik.ruhr-uni-bochum.de
 To:      letters@lwn.net
 Subject: Stallman and things
 Date:    23 Aug 2001 11:59:39 +0200
 The problem of Stallman is that of many a great revolutionary: once
 the idea they have so painfully nurtured and fostered and kindled has
 finally caught on and is spreading like a wild fire, they cannot
 simply leave it to itself and restrain the urge to control what needed
 their care for a long time.  Sort of a children and parent problem.
 
 Stallman is no fool, but a bit out of touch with reality.  Apply the
 proper grain of salt when listening to him.  He has deserved it.
 
 --
 David Kastrup, Kriemhildstr. 15, 44793 Bochum
 Email: David.Kastrup@neuroinformatik.ruhr-uni-bochum.de
 
    
 From:    Kapil Hari Paranjape <kapil@imsc.ernet.in>
 To:      letters@lwn.net
 Subject: Freedom zero and all that
 Date:    Sat, 25 Aug 2001 12:41:23 +0530
 
 Dear LWN,
 
 I read with interest your editorial this week ("Let's beat up on
 Richard Stallman") and the articles by O'Reilly and the others.
 Of course this has led to another series of postings in various
 fora and the debate will rage on. Here is my 2 paise worth.
 
 1. RMS < FSF < GNU < GPL. But we are often guilty of equating them. In
    particular, each time RMS makes a statement that people object to
    they use it as an excuse to beat up on the FSF and sometimes the GPL
    as well. Of course, RMS himself is guilty of over-reaching on some
    of these inequalities...
 
 2. The GPL is about the user's freedom. What O'Reilly (and open
    source) is talking about is the developer's freedom. But the
    distinction between users and developers is a grayscale and not black
    and white. We all start as (l)users and (should) try to attain some
    sort of mastery. The GPL says that every developer *must* help a user
    in this by letting the user (a) use the program (b) study and adapt
    it (c) get friends involved in this ativity (d) carry on the work of
    developers that came before by helping others too.
 
 3. If developers grant themselves the "freedom"/"power" to stop
    helping users in this way *or* users grant themselves the right to
    expect "readymade" fixes from developers forever, it is only a
    matter of time before the division is created and made permanent.
 
 Unfortunately, O'Reilly's "freedom zero" is easily distorted into a
 freedom for developers such as in (3). The response from RMS/BMK also
 too easily interpreted to mean a user's "right to expect" as in (3).
 
 A cliche (actually the title of an Indian soap opera) may help!
 
         "Sans bhi kabhi bahu thi"
                 (A mother-in-law was also a daughter-in-law once).
 
 Kapil Paranjape.
 
    
 From:    Michael Alan Dorman <mdorman@debian.org>
 To:      letters@lwn.net
 Subject: Thanks for cutting through the rhetoric!
 Date:    23 Aug 2001 07:27:05 -0700
 
 Your "Should we be talking about freedom?" section on the Main Page of
 this week's issue is something that I would hope many people will read
 and remember and refer back to.
 
 Although I'm personally happy I work on "Debian GNU/Linux" rather than
 "Debian Linux"---I got started using GNU software before I started
 using Linux (heck before Linux existed), and I *do* think the GNU part
 is really important---it's a point on which reasonable people may
 disagree.
 
 The value of freedom, however, is one thing which I would hope people
 would recognize is essential and Richard Stallman is our conscience on
 this matter, with all that implies: an inability to compromise, a
 tendency to nag, and hundreds of other annoyances that one must,
 nevertheless, tolerate because he is also our benchmark---you may not
 share his values, but you always have a fixed, absolute point from
 which to navigate.
 
 I will, however, spare you with my jeremiad against Eric Raymond,
 including my analysis of why his response to Stallman and Kuhn is
 obviously slanted against them, and why I don't think Eric Raymond
 really cares deeply about any freedom other than that of gun
 ownership. :-)
 
 Mike.
 --
 "One does not write satire anymore; one merely tries to stay half a
 step ahead of reality." -- Jon Carroll
 
    
 From:    Stuart Thayer <thayer@scfn.thpl.lib.fl.us>
 To:      letters@lwn.net
 Subject: Eric Raymond
 Date:    Thu, 23 Aug 2001 13:14:16 -0400
 
 Folks:
 
         I think Eric Raymond's missive to Stallman and Riley bends
 backwards too far to be fair. Fairness is, most would agree,
 a noble thing. But he seems naive, at least for the sake of
 making his point, about American politics.
 
         There is a far greater chance of outlawing open source than
 outlawing proprietary software, so the power play isn't as
 equal as it may seem.
 
         U.S. politics is based on bribery. We don't call it that,
 of course; we call them campaign contributions. Even our
 illustrious Supreme Court tries to bamboozle us by calling
 them free speech, thus protected by the First Amendment. The
 U.S. may be the only country in the world where bribery
 enjoys constitutional protection.
 
         Owners of proprietary software, with their profits, are
 thus in a far better position to bribe U.S. lawmakers to
 make free software illegal than developers of free software,
 with few profits, are to persuade, cajole, jawbone, or
 otherwise plead -- with no monetary incentive -- lawmakers
 into making proprietary software illegal.
 
         I'll leave it to you to decide which poses the greater danger.
 
    
 From:    David Gibson <david@gibson.dropbear.id.au>
 To:      lwn@lwn.net
 Subject: Flerbage
 Date:    Wed, 29 Aug 2001 13:08:46 +1000
 Cc:      esr@thyrsus.com, rms@gnu.org
 
 The FSF's use of the word "freedom" might be confusing, but Eric
 Raymond's flerbage argument is certainly a straw man.
 
 Eric postulates that a law banning proprietary software has been
 passed.  Thus, he argues he could now be thrown in jail for offering
 people software under the same proprietary license as he did before
 the ban, which would indeed seriously diminish his flerbage.  But why
 on earth would anyone pass a law making it a jailable offence to offer
 a proprietary license, when all that is necessary to effectively "ban"
 proprietary licenses is to modify copyright law so that they are
 unenforceable[1].  Essentially Eric's argument assumes that it is
 possible to offer proprietary licenses, whereas the point of banning
 them would be to make it impossible, rather than to punish people
 merely for making the attempt.
 
 So let us suppose instead that proprietary software was "banned" in
 this much more sensible way.  Now, in such a world, I could go and
 offer software under a proprietary license to whomever I pleased.  Of
 course, whoever I did offer it to is quite likely to either a) laugh
 in my face, or b) take the software and then do whatever they please
 with it, since they know I can't enforce my license restrictions.
 Still, I'm not going to be dragged off to prison for it.  So, while
 this state of affairs might be unfortunate for me if I was planning to
 live off license sales, it hasn't affected my flerbage.
 
 Note that in the above I haven't actually touched on the issue of
 whether banning proprietary licenses would be a good idea or not.
 That's a much more subtle issue, and one that can't be decided on
 matters of flerbage alone.
 
 [1] Strictly there are two things which would have to be done - first
 make explicitly restrictive licenses unenforceable and second remove
 the built-in restrictions imposed by copyright [2].
 
 [2] Before anyone points out that this would probably also make the
 GPL unenforceable, that's strictly true, but irrelevant.  A ban on
 proprietary licensing would give many of the rights (e.g. unrestricted
 duplication and modification) that the GPL grants automatically and
 while someone could promulgate binaries but not sources to a formerly
 GPLed program, there would be little incentive to do so.
 
 --
 David Gibson                    | For every complex problem there is a
 david@gibson.dropbear.id.au     | solution which is simple, neat and
                                 | wrong.  -- H.L. Mencken
 [16]http://www.ozlabs.org/people/dgibson
    
 From:    zooko@zooko.com
 To:      lwn@lwn.net
 Subject: /dev/random silliness
 Date:    Thu, 23 Aug 2001 09:32:03 -0700
 Folks:
 
 The vast majority (perhaps all) of the people who use /dev/random to the
 exclusion of /dev/urandom in their crypto applications are doing so out of
 ignorance, and are not making their application any safer for their users.
 Assume that the random pool has been initialized with 160 bits which no
 attacker can guess.  (That assumption is the hard part, but if it is wrong then
 /dev/random can fail just as easily as /dev/urandom can.  Note that this
 implies that /dev/urandom *must* block or otherwise signal an exception if this
 precondition is not met.)
 
 Now for an attacker to guess the output of /dev/urandom he must accomplish one
 of the following:
 
 1. perform roughly 2^160 work (i.e. guess-and-check for all possible initial
    states)
 2. exploit a flaw in the cryptographic underpinings of the /dev/*randoms (e.g.
    SHA1)
 3. penetrate the computer and read the state of the random pool
 4. exploit a flaw in the code that implements the /dev/*randoms
 In practice, some combination of these might enable an attack, although
 obviously #1 will never happen, as long as the attacker is confined to using
 conventional (Turing machine) computers.
 Now my point is that /dev/random can fall to an attack like this just as easily
 as /dev/urandom can!  In fact, the added complexity of implementing the
 /dev/random behavior makes #4 *more* likely for /dev/random than for
 /dev/urandom.
 
 Not to mention that /dev/random's specification *requires* the applications
 that use it to become susceptible to a DoS attack by sucking down the "entropy
 estimate" count.
 Here's the real kicker: with the exception of a true One Time Pad, any
 application that uses /dev/*random is going to also use some cryptographic
 primitives like a block cipher, stream cipher, secure hash, public key
 cryptosystem etc., now each of *those* primitives themselves are susceptible to
 a massive, impossible brute-force attack (attack #1, above), just like
 /dev/urandom is!
 
 Therefore, there is absolutely no improvement in using /dev/random over
 /dev/urandom, and then feeding the results into a block cipher which is itself
 susceptible to an impossible (e.g. 2^128) brute force attack.
 The bottom line is: if you are not implementing a true One Time Pad that
 utilizes no cryptographic primitives -- it uses only XOR -- then you shouldn't
 be using /dev/random.  To do so opens you up to a DoS attack, and makes the
 security of your app depend on more complex code, but gives you no real-world
 improvement in security.
 Regards,
 
 Zooko
 
    
 From:    Leandro =?ISO-8859-15?Q?Guimar=E3es?= Faria Corsetti Dutra
          <leandrod@mac.com>
 To:      letters@lwn.net
 Subject: Kernel /dev/random entropy only adds to security worries
 Date:    Thu, 23 Aug 2001 16:03:00 -0300
 
 > Once again, nobody has ever gotten close to demonstrating an attack of
 > this nature, but if security people didn't worry they would have little to
 > do.
 
         It seems to me that it wasn't intentional, but this sentences sound to
 me like
 the author meant that security people had to worry about very improbable
 events in order to get occupied.  It sure can be construed like that, and
 that's certainly not true, as bad security practices almost everywhere already
 give them surely plenty of labor.
 --
   _
 / \ Leandro Guimaraes Faria Corsetti Dutra           +55 (11) 246 96 07
 \ / [17]http://homepage.mac.com./leandrod/     BRASIL    +55 (43) 322 89 71
   X  [18]http://tutoriald.sourceforge.net./     [19]mailto:lgcdutra@terra.com.b
 r
 / \ Campanha fita ASCII, contra correio HTML    [20]mailto:leandrod@mac.com
 
    
 From:    "Tom Poe" <tompoe@source.net>
 To:      <letters@lwn.net>
 Subject: RH and Proprietary Software Comment
 Date:    Thu, 23 Aug 2001 22:14:41 -0700
 
 Hello:  You mention the issue of proprietary software being written
 specifically for RH, this week.  You mentioned that there might be some
 straying from LSB by RH, which then would have the market move away from
 other distributions in order to have access to proprietary software written
 for Linux.
 
 My comment is, that such a path is going to be followed, only if the
 software is critical to a business.  If it's not critical, CFO's are going
 to have to have some other compelling reason to become vendor inmates once
 again, don't you think?
 
 Further, it's my humble opinion, that RH has already crossed the line into
 proprietaryville.  I can't help but feel they look like a duck, smell like a
 duck, talk like a duck, walk like a duck, and are a proprietary product at
 this point.  Maybe it's time they're called a duck/proprietary product, and
 need to be recategorized by Open Source folks, or whatever.  Tom
 
    
 From:    Robert Bihlmeyer <robbe@orcus.priv.at>
 To:      letters@lwn.net
 Subject: Debian and proprietary software
 Date:    24 Aug 2001 14:16:35 +0200
 
 > However, if a business chooses to run Debian and also chooses to use
 > a proprietary software product shouldn't this combination just work?
 
 Why should it? While Debian states that it supports its users even
 when they're running proprietory software, no claims are made that no
 work on the users's part will be required. Making proprietory software
 easy to run on Debian is certainly not a primary goal of the project.
 
 Debian developers and users may of course choose to make this their
 goal, and support it independently.
 
 > Should that business be forced to use a different distribution just
 > because it is tied to a third party product? This is a mode of
 > operation more reminiscent of certain proprietary operating systems
 > than of Linux.
 
 Oh, come on! What is Debian doing to /force/ its users to a different
 distribution? Certainly, some of them may be faced with the choice
 between easily installable proprietory software on the one hand, and
 whatever advantages one sees in Debian over, say, redhat.
 
 Debian is simply omitting a feature that many Debian users can do
 without, not actively prohibiting others from using it the way they
 like.
 
 Is redhat /forcing/ Sparc owner to Debian for not providing an
 appropriate port of their distro?
 
 Perhaps, what you really want to see is a distribution with the same
 technical featureset as Debian, but a different social agenda. Fine by
 me, but please let's make this a new distribution, not a future
 Debian.
 
 > World domination [...]
 
 ... is more reminiscent of certain proprietary operation system
 vendors, no?
 
 --
 Robbe
 
    
 From:    Leon Brooks <leon@cclinic.com.au>
 To:      letters@lwn.net
 Subject: Simple example of Unix flexibility
 Date:    Sun, 26 Aug 2001 13:47:16 +0800
 
 Many LWN readers will not need to delve into the guts of their
 systems to do what they want done, and may miss most of the goodness
 in their systems. Many similarly inclined non-LWN-readers may wonder
 what all the fuss is about with Linux, and with Unix and general, and
 why geeks get so hyped over it.
 
 I ran across a little example just now which shows how useful the
 flexibility of the Unix every-program-is-a-tool attitude can be.
 
 The problem: I have an ISO image of some Open Source software CDs in
 files on a hard disk, and I want to get them out and burn some copies
 onto CD-R media.
 
 The partition that the ISOs are in is ReiserFS format instead of
 the traditional Linux ext2. Windows users can think in terms of a
 Win2k partition instead of NT-4.0-level NTFS. the tools I have to
 achieve this with are an unlimited supply of Windows 9X boxes, one
 Mandrake Linux 8.0 box [ohso] which can read ReiserFS but can't be
 shut down to have a hard disk installed, and one RedHat Linux 7.1 box
 [archenland] which can't read ReiserFS and also can't be shut down to
 be taught how, but does have a CD burner. All on the same LAN.
 
 The solution, step by step (follow the bouncing ball):
 
   *  Plug the offending hard disk and a Linux Router Project (LRP)
      floppy into a random Windows 98 box [aravis].
 
   *  Boot aravis under Linux. LRP can't read ReiserFS either.
 
   *  From ohso, "ssh -x aravis 'cat /dev/hda5' >hda5.image" to copy
      the 2GB partition across the LAN from the LRP box.
 
   *  "mkdir 1; mount -t reiserfs hda5.image 1" to make a temporary
      directory and attach the local copy of the partition to it.
 
   *  "scp 1/*.iso archenland:" to copy the ISO images to the box
      with the burner.
 
   *  From archenland, "cdrecord dev=0,4,0 -eject -speed=6 first.iso"
      (and repeat for each ISO).
 
 If that had been a Windows-based problem, I would have had to go out
 and find a working machine that had an OS capable of reading the hard
 disk, and a CD burner. Else just cry into my peppermint tea (I'm a
 weird Aussie, I don't like beer). Did I mention that this is on a
 Sunday and in the middle of the Australian outback, 1400km from the
 city?
 
 A couple of things worth noting: I can burn those CDs in a machine
 several hundred meters away, securely and with no special software,
 and have a computer illiterate feed CD-R blanks for me as required;
 archenland is UW SCSI so can safely burn about 12-14 CDs at once;
 authors of newer Gnome and KDE packages tend to make them
 specialised rather than flexible - please don't; Microsoft have
 finally remembered that mounting is useful, and have implemented it
 for XP; Does anyone have a useful standalone version of NT, 2000, or
 XP that fits on one floppy?
 
 For those interested in LRP, I took the EigerStein2BETA image from
 [21]http://lrp.steinkuehler.net/, wrote an IDE-enabled kernel on it,
 added modules for all of the network cards used here, lost the DHCP,
 DNS and web packages, added sshd, made a key and lost keygen, added
 hdsupp. Hand-edited syslinux.cfg then used lrcfg to "backup" all
 packages and reboot to test. If anyone wants to host a copy of the
 finished product, just ask.
 
 This LRP floppy is used for recovering vital stuff from dead Windows
 boxes before reGhosting, and for quick network solutions (random box
 + extra LAN card + floppy == instant router, add another floppy for a
 proper webserver or the like). More powerful LRP-like bootable CDs
 are also available for machines that actually have CD drives.
 
 We hope that you enjoyed the show.
 
    
    
                                                                          
    
    [22]Eklektix, Inc. Linux powered! Copyright Л 2001 [23]Eklektix, Inc.,
    all rights reserved
    Linux (R) is a registered trademark of Linus Torvalds
 
 References
 
    1. http://lwn.net/
    2. http://ads.tucows.com/click.ng/pageid=pageid=132-000-001-001
    3. http://lwn.net/2001/0830/
    4. http://lwn.net/2001/0830/security.php3
    5. http://lwn.net/2001/0830/kernel.php3
    6. http://lwn.net/2001/0830/dists.php3
    7. http://lwn.net/2001/0830/desktop.php3
    8. http://lwn.net/2001/0830/devel.php3
    9. http://lwn.net/2001/0830/commerce.php3
   10. http://lwn.net/2001/0830/press.php3
   11. http://lwn.net/2001/0830/announce.php3
   12. http://lwn.net/2001/0830/history.php3
   13. http://lwn.net/2001/0830/bigpage.php3
   14. http://lwn.net/2001/0823/letters.php3
   15. mailto:letters@lwn.net
   16. http://www.ozlabs.org/people/dgibson
   17. http://homepage.mac.com/leandrod/
   18. http://tutoriald.sourceforge.net/
   19. mailto:lgcdutra@terra.com.br
   20. mailto:leandrod@mac.com
   21. http://lrp.steinkuehler.net/
   22. http://www.eklektix.com/
   23. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

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