ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   21 Jun 2001  17:12:28
 To : All
 Subject : URL: http://lwn.net/2001/0621/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.
    June 21, 2001
    
    
 From:    "nathan r. hruby" <nhruby@arches.uga.edu>
 To:      letters@lwn.net
 Subject: Error About trove
 Date:    Thu, 14 Jun 2001 10:22:41 -0400 (EDT)
 
 In the June 14th edition of LWN, on the "Linux History" page
 ([16]http://www.lwn.net/2001/0614/history.php3) you say:
 
 > Trove has not caught on in the way Eric might have liked, with one big
 > exception: SourceForge uses it.
 
 FreshmeatII now uses Trove as well for categorizing its entries.
 
 -n
 --
 ......
 nathan hruby - nhruby@arches.uga.edu
 computer support specialist
 department of drama and theatre
 [17]http://www.drama.uga.edu/
 ......
    
 From:    "Robert A. Knop Jr." <rknop@pobox.com>
 To:      <letters@lwn.net>
 Subject: GnuCash 1.6 & library dependencies
 Date:    Thu, 14 Jun 2001 06:59:35 -0700 (PDT)
 
 I understand the frusturation that you must feel trying to get GnuCash
 1.6.0 to work.  Fortunately for me, 1.4 serves my needs quite well, so I
 will stick with that for the forseeable future-- which is almost certainly
 when the next major revision of the distribution I use comes out.
 
 I had a similar but smaller-scale problem several months ago when I was
 trying to install lilypond on a mostly RH6.2-based system.  Lilypond
 required a newer version of the guile library-- which was fine, except
 that the dependencies in the RPMs were such that a couple of the *other*
 programs on the system would *not* work with the new guile packages.  In
 order to get the newer guile on my system, I ended up having to rebuild a
 number of other RPMs from source RPMs, and keep my rebuilt ones around to
 overwrite updates which I was automatically grabbing using scripts I'd
 written myself.  I hate to think what would have happened if I was using
 just a pre-canned update service, unless it had a way of letting me mark
 which things were *not* to be updated.
 
 When I upgraded to RedHat 7.1.  Then, at that point, installing lilypond
 1.4 became simple.  (I think I did have to rebuild it from the SRPM, but I
 didn't have to rebuild anything else, and the libraries with RH7.1 were
 sufficient.)
 
 There are a couple of lessons in this.  The first is, if you wait a little
 while, the major distributions will "catch up" with the newer libraries,
 and things will settle down and start working.  The second is, when the
 applications get "ahead" of the library installation for your system,
 most users who don't want to spend the trouble should just stick with the
 old version until their distribution catches up.
 
 It would be nice if applications only depended on "longstanding"
 versions of libraries (e.g. only Gnome 1.2, not Gnome 1.4).  However, free
 software is chaotic, and that's one of its advantages.  There is nobody
 keeping everything synchronized, and free software developers are
 perfectly free to build things that depend on development versions of
 libraries.  Most major applications tend to have *some* version packaged
 to work immediately with major distributions, either by the maker of the
 distribution, or by the writers of the application.  If a package for your
 distribution isn't available from the application writers, often you find
 it in the distribution itself, or in some add-on collection (such as
 RedHat's Rawhide).  It may not be the latest and greatest version of the
 application.  As long as we can wait the six months or so it takes a
 distribution to move forward, and don't need to run the latest version of
 (say) GnuCash within weeks of its release, things are not quite so dire as
 all of that.
 
 This might sound like fodder for Microsoftesque free-software bashing:
 "You can't even run the latest version of applications without being a
 system developer and capable of updating the libraries yourself!"  On the
 other hand, compare the rate of release of typical free software packages
 to the rate of release of typical closed-source commerical packages.  Free
 software keeps pace very well in terms of users really being able to
 use new version of things... it is just that the new version gets aired to
 the public a whole lot sooner, as opposed to closed-source commercial
 software where R&D departments sit on things waiting for the next release
 of Windows.
 
 -Rob Knop
 rknop@pobox.com
    
 From:    Patrick Spinler <spinler.patrick@mayo.edu>
 To:      letters@lwn.net
 Subject: An upcoming solution to Gnucash 1.6 dependancies
 Date:    Thu, 14 Jun 2001 10:03:55 -0500
 If you don't want to wait until the next vendor release from your
 distribution; The Gnucash core team plans a release of Gnucash 1.6 on CD
 that will install all it's needed libraries into a private area, thus
 allowing use of the new software without destroying your existing
 system.
 
 No date has yet been set for this release, however we are told to expect
 it "soon".
 
 -- Pat
 
 --
       This message does not represent the policies or positions
              of the Mayo Foundation or its subsidiaries.
   Patrick Spinler                       email:  Spinler.Patrick@Mayo.EDU
   Mayo Foundation                       phone:  507/284-9485
 
    
 From:    "Tom Cato Amundsen" <tca@gnu.org>
 To:      letters@lwn.net
 Subject: gnucash 1.6
 Date:    Thu, 14 Jun 2001 17:38:38 +0200
 
 Gnucash is only hard to install if you run the wrong OS.
 On debian unstable, I did
 
 apt-get install gnucash
 
 today, and all the correct libs are installed.
 --
 Tom Cato Amundsen <tca@gnu.org>
 GNU Solfege - free eartraining, [18]http://www.gnu.org/software/solfege/
 
    
 From:    John Goerzen <jgoerzen@complete.org>
 To:      letters@lwn.net
 Subject: Gnucash 1.6.0 is here
 Date:    14 Jun 2001 10:32:18 -0500
 
 LWN:
 
 Thank you for your article on Gnucash.  I maintain the package for
 Debian, and wanted to let you know that Debian's sid distribution does
 currently have all requisite packages for a Gnucash installation, and
 Gnucash 1.6.0 .debs already have been uploaded to Debian and should be
 installed in the archive soon.  People looking for an advance copy may
 find them here:
 
 gopher://quux.org/11/devel/debian/gnucash
 
 You should be able to install that on any current sid machine and just
 have it work.
 
 --
 John Goerzen <jgoerzen@complete.org>                       www.complete.org
 Sr. Software Developer, Progeny Linux Systems, Inc.    www.progenylinux.com
 #include <std_disclaimer.h>                     <jgoerzen@progenylinux.com>
 
    
 From:    Herbert Thoma <tma@iis.fhg.de>
 To:      letters@lwn.net, GnuCash <gnucash-devel@gnucash.org>
 Subject: LWN gnucash article
 Date:    Thu, 14 Jun 2001 17:27:55 +0200
 
 Hi,
 
 in your last front page you claim:
 "As of this writing, there is probably not a single distribution which, out of
 the box, provides that environment."
 
 SuSE 7.2 comes with everything that is required for GnuCash 1.6.
 
 (OK, I admit, SuSE 7.2 is out for no longer than 1 week ...)
 
 I'm a (not too active) GnuCash developer. And in spite of your
 article I still like LWN very much. But I do agree with the mail
 Bill Gribble sent to Jonathan Corbet.
 
 Regards,
  Herbert.
 --
 Herbert Thoma
 FhG-IIS A, Studio Department
 Am Weichselgarten 3, 91058 Erlangen, Germany
 Phone: +49-9131-776-323
 Fax:   +49-9131-776-399
 email: tma@iis.fhg.de
 www: [19]http://www.iis.fhg.de/
 
    
 From:    dave mallery <dmallery@cia-g.com>
 To:      <letters@lwn.net>
 Subject: dependency hell
 Date:    Thu, 14 Jun 2001 12:25:15 -0600 (MDT)
 
 hi
 
 i have been using linux daily since about 1997 and saw my first computer
 in about 1965.
 
 the feature on gnucash fingers a really major problem.  a working linux
 desktop is a beautiful thing, but the near impossibility of installing
 anything major kills it neatly.
 
 i just spent a week trying to get Corel Office  2000 to run on my r/h 7.1
 machine.  the initial problem is that it needs glibc2.1 or 2.0, not the
 2.2 that ships.  a backward compatibility problem.  just installing the
 compatability rpm did not solve it.  the install script shipped with the
 product does not work in this environment.  only a well hidden script
 pointed to by an e-mail (many day latency) from support would work.
 further problems showed up requiring another upgrade for libaps via an rpm
 from their site.  at this point, it will 'run' but is highly unstable and
 there are no more hints available.
 
 i had come to rely on their wordperfect 8 for a few years.  too bad.  the
 reason i don't just go to one of the free apps is that the fonts are few
 and they won't read my many hundred wp8 files.  (i have not checked star
 yet).
 
 the big fear in the back of my mind is that as i make changes to my 7.1
 install, i will either screw something up or unwittingly fork, making my
 system 'un-upgradable'! i have the same fear with a system on which i
 installed ximian.  once you diverge from the r/h installation (i subscribe
 to krud), you may find yourself in un-charted seas.
 
 i am a reasonably experienced user facing a wall of complexity.  this
 could rapidly become an insurmountable problem and needs some clever
 fixing at the system level.  i'd love to use gnucash.....
 
 dave
 --
 www.ramahcafe.com
 
 Dave Mallery
 Ramah Cafe
 3270 Hiway 53
 PO Box 520
 Ramah,  NM  87321
 
 no gates
   no windows...
 
 running GNU/Linux
 free at last!
 
 Linux is a trademark of Linus Torvalds
 
    
 From:    Joe Van Andel <vanandel@atd.ucar.edu>
 To:      letters@lwn.net
 Subject: shared library hell and library version numbers
 Date:    Fri, 15 Jun 2001 12:01:03 -0600
 
 The "gnucash 1.6 and the dependency nightmare" article didn't explain
 that some library developers are contributing to the problem by *not*
 changing the version number of libraries when incompatable changes are
 made.  In theory, if application X uses shared library Y.1.2, it should
 work with *any* version of library 1.1.2.  In practice, I find that two
 different releases of Redhat (for example) may contain shared libraries
 with the same version number, but incompatible contents.
 
 Clearly, if library developers "played by the rules", I could continue
 to use application X with shared library Y.1.2 while using application
 'Z' with shared library Y.1.3 .  That is, I wouldn't need to worry (as
 much) about breaking existing applications when I upgrade shared
 libraries if all library developers would consistently change the
 library version suffix when incompatible changes were made.
 
 There is some irony in the fact that Microsoft has been plagued by the
 same issue with Dynamically Linked Libraries (DLLs).  One source of
 instabililty in Microsoft Windows applications is that installing one
 application can break existing applications, because the "new"
 application installs its own version of DLLs that aren't compatible with
 the DLLs needed by an existing application.  Microsoft's solution for
 Windows 2000 is (so-called) "enhanced sharing" of DLLs.  Rather than
 applications being allowed to over-write the system DLLs provided by
 Microsoft, each application must install its own "private" copies of
 DLLs, which are stored with the application, rather than in the
 "shared", system directories.  As a result, at runtime, your system
 might have 3 different verions of XYZ.dll loaded into memory.
 
 As much as I dislike statically linking applications, unless library
 developers do a more consistent job with shared library version
 numbering, static linking may be necessary to improve application
 stability.
 --
 Joe VanAndel
 National Center for Atmospheric Research
 [20]http://www.atd.ucar.edu/~vanandel/
 Internet: vanandel@ucar.edu
 
    
 From:    Ketil Malde <ketil@ii.uib.no>
 To:      letters@lwn.net
 Subject: Executable stack and security
 Date:    14 Jun 2001 09:00:30 +0200
 While one may argue that disabling execution of the stack doesn't
 really fix the problem, I don't agree with labelling it "security
 through obscurity".
 
 STO is about maintaining security by hoping nobody finds out about
 your weaknesses.   Non-exec stack makes exploits more difficult, it's
 making the weakness a bit less weak.
 
 Calling this patch STO is, IMHO, a political statement, though
 from LWN it's probably unintentional.  The real argument against it, I
 think, is that those lazy, worthless bastards[*] maintaining libc and
 other code may not bother to fix their buffer overruns any more.
 
 -kzm
 
 PS: Yeah, and cut the Desktop page some slack, will you?  LWN *needs*
 desktop coverage, and I think it will sort itself out.  I guess
 (looking at the survey) we're a bunch of dweebs who'd like more of the
 hard tech stuff -- personally, I like the way the kernel page is done;
 first the current news, then a more in-depth look at some technical
 details.  How about some technical stuff about KParts, CORBA, XFree86
 4, etc?
 
 [*] Actually, I'm being ironic.  I think they'll continue to fix bugs,
 regardless of stack executability.
 --
 If I haven't seen further, it is by standing in the footprints of giants
 
    
 From:    Eric Smith <eric@brouhaha.com>
 To:      letters@lwn.net
 Subject: Non-executable segments are NOT an obscurity defense
 Date:    14 Jun 2001 21:39:41 -0000
 
 Gentlemen,
 
 In your 14-Jun-2001 issue, you write "non-executable segments is
 arguably an obscurity defense, because attacks exploiting overflow
 vulnerabilities that are stopped by non-executable segments can always
 be re-worked to be "return into libc" style attacks that bypass the
 non-executable segment by pointing directly at code in the code segment."
 
 That's like saying that putting a lock on my front door is an "obscurity
 defense" because an attacker can still pick the lock.  The failure to
 solve 100% of the problem and eliminate related attacks does not make
 it an "obscurity defense".
 
 If I put a lock on my front door, but the lock was designed to open
 without a key if someone whistles nearby, that *might* qualify as an
 "obscurity defense."
 
 Note that obscurity isn't inherently bad.  It is *depending* on
 obscurity of widely-distributed information that is bad, because you
 can't expect that the attacker doesn't have the necessary obscure
 information.
 
 Some amount of obscurity is almost always necessary for security.  For
 instance, having a password is an "obscurity defense," because you're
 counting on the attacker not knowing this obscure knowledge.  However,
 a password is a very small bit of knowledge that is ideally only known
 to one person.
 
 On the other hand, if a password system in a widely distributed piece of
 software had a fixed "back door" password coded into it, and we expected
 no one to find that, it would be a blatant case of "obscurity defense",
 because the knowledge could be (somewhat) easily obtained by anyone.
 
 Eric Smith
 
    
 From:    Christian Hellon <xian@lisardcage.fsnet.co.uk>
 To:      letters@lwn.net
 Subject: On the Desktop just hit the mark
 Date:    Thu, 14 Jun 2001 12:40:20 +0100 (GMT+01:00)
 
 I've watched the furore over the On the Desktop section for the last few
 weeks, and privately agreed with those who felt that the style wasn't really
 in keeping with the rest of LWN. However, I decided to wait and see; it's
 natural that an established author, accustomed to writing and achieving
 success in his own style, would take a while to find the "groove" that
 successfully combined that with the house style of the magazine he's just
 joined.
 
 It looks like I was right to wait a while before passing judgement. This
 week's column is spot on, continuing the trend of the last couple of weeks. A
 belated welcome to the team, Mr Hammel, and I look forward to reading On the
 Desktop for a good few years to come.
 --
 
 the desk lisard is at reply@lisardcage.fsnet.co.uk
 
 "i don't know why i'm crying, am i suspended in gaffa?"
 ____________________________________________________________
 Freeserve - get your free ISP service including web-mail at:
 www.freeserve.co.uk
    
 From:    "Alex Bennee" <Alex_Bennee@hotmail.com>
 To:      lwn@lwn.net
 Subject: On having plug in protocol stacks in the Linux Kernel
 Date:    Fri, 15 Jun 2001 10:38:42 +0100
 Dear LWN,
 
 I thought I would just point out why having this pluggable interface structure
 would be useful. I'm in the process of trying to convince my development area
 (we do embedded comms) to move from our existing RTOS's (where we suffer badly
 from vendor lock-in) to a linux kernel. However as is common in the comms world
 we do use 3rd party stacks to bring our time to market down. While the eventual
 hope would be to move away from such expensive 3rd party stacks pragmatism must
 be the order of the day. By the way the stacks we use are about 50/50 split
 between pure source or binary only.
 
 Of course anybody could "fork" the kernel or provide a patch for the standard
 kernel to add in such a feature but it would be a bit more of a pain to manage.
 Most proprietary OS's provide standard interfaces for 3rd party stacks to
 plug-in.  I think the kernel will suffer in the embedded world if such
 interfaces can't be kept in an open central way. I prefer a more pragmatic
 approach which allows for proprietary plugins but is not dogmatic about avoidin
 g
 the possibility of non "free" software working with the kernel. Also I think
 "crippling" a generic patch to only work with source-level linking is a rather
 pointless exercise.
 
 Regards,
 
 Alex.
    
 From:    "Robert A. Knop Jr." <rknop@panisse.lbl.gov>
 To:      <letters@lwn.net>
 Subject: FUD "forking" resopnse
 Date:    Fri, 15 Jun 2001 14:00:07 -0700 (PDT)
 
 A common piece of FUD about Linux and free software is that because it's
 not controlled by any one central authority, it may (and will and indeed
 been known in the past to) fork, causing confusion and balkanization for
 its users.  The plethora of Linux distributions available is often cited
 as an example; it is difficult for anybody to support Linux, the argument
 goes, because you don't know exactly which flavor of Linux your users are
 using.
 
 One might make the analogy to news sources.  Go to the supermarket and
 look around.  You are likely to find a number of different mainstream news
 sources: Time, Newsweek, the local newspaper, etc.  You will also find the
 National Enquirer, the Weekly World News, and other, er, less mainstream
 sources of news.  Freedom of the Press means that anybody who wants to and
 can afford to can put out a newspaper.  But, horrors!  Without a central
 authority controlling the news that gets to individuals, how are we to
 know which news source to listen to?  How are we to make heads or tails
 out of the reports in certain "news" sources that seem to contradict
 everything in other news sources?
 
 Obviously, this isn't a problem; indeed most people in the USA recognize
 that freedom of the press is one of the most important foundations of our
 society.  Some people believe the Weekly World News, but most people
 recognize it as a source of entertainment.  Based on track record, we
 learn which news sources to trust.  What's more, each individual can
 figure out for himself which news source is the one that is best for him.
 The plethora of distributions, the "forking" of news sources isn't a
 problem, it's an opportunity.  And, of course, the only way to "cure" this
 "forking" would be to elimiate freedom of the press.
 
 The analogies to free software are clear.  There are lots of
 distributions; there are only a few major distributions.  People will pick
 the ones that work best for them.  If code forks, people at large will
 figure out, and the information will get out, as to which branch(es) of
 the code are the ones to trust, and are the ones to pay attention to.
 It's just not a problem, any more than having lots of fun newspapers in
 the checkout line at the supermarket is a problem.
 
 -Rob Knop
 rknop@pobox.com
    
 From:    "Richard Corfield" <rjc1008@hotmail.com>
 To:      letters@lwn.net
 Subject: MS documents about Linux
 Date:    Mon, 18 Jun 2001 10:51:53 -0000
 
 I must admit, as a cancer patient, that I see nothing in common between
 Linux and cancer.
 
 I remember one thing I was told in my graduate training for a well known
 large computer company. You should never blatantly attack the competition as
 Microsoft are doing now. You can sell the benefits of your product, but to
 just insult the competition is seen as highly unprofessional and just gives
 a bad image. Hopefuly people are seeing through Microsoft's "in the
 interests of America" approach and seeing these attacks for what they are.
 
 The text of the "Linux in retail" document is laughable. Here it resulted in
 explosions of giggles. I wonder sometimes if someone could write a similar
 document about Microsoft, but the argument about "being professional" comes
 in, so perhaps better not. I imagine also that Microsoft's laywers would
 have a field day with it.
 
 Microsoft are sounding like the baby throwing the rattle out of the pram
 because it can't get what it wants. Lets hope that is how the computing
 public will see these blind attacks and think about discovering for
 themselves the real differences between Microsoft and Linux.
 
 - Richard
 
 If Linux is cancer, then I suppose Windows is like chemotherapy. I'm finding
 that chemo has the nastier side-effects. Now who wants chemo for something
 non-malignant like Linux?
 
    
 From:    Anders Holtsberg <anders.holtsberg@decuma.com>
 To:      lwn@lwn.net
 Subject: About your article.
 Date:    Wed, 20 Jun 2001 12:53:34 +0200
 
 In the article
 [21]http://www.linuxweeklynews.com/
 you cite a Microsoft document:
 
   Imagine how confusing it would be if Microsoft
   released 188 versions of Windows and multiple
   versions of the GUI, each with a slightly different
   functionality? Wouldn't that be confusing? Wouldn't
   it be extremely difficult to run an enterprise solution
   with confidence about your future and return on
   investment in Microsoft products? That is the exact
   scenario that Linux is presently in by having so
   many distributions.
 
 Your answer was:
 
   You read it here: choice is bad.
 
 I have another answer: What about Microsoft's number of versions?
 We run a network where we develop stuff for the chinese market.
 We have for example one machine with chinese Win2000. Does it
 work? No. Our company standard swedish MS-Word won't even run
 on it because it generates internal temporary file names with
 swedish characters in them and the chinese Win2000 refuses to
 accept it. Result: Microsoft Win2000 programs don't work on
 Microsoft Win2000 operating system. If Microsoft claims they
 cause no problems since they don't produce a bewildering number
 of different operating system versions, then they are lying.
 
 Anders Holtsberg
 
 ps. by the way: in the project I am heading we use Linux, Bash,
 Noweb, GCC, Icon, Gawk and Octave as core tools as well as
 Windows and Visual C++.
 --
 _______________________________________________________________
    Anders Holtsberg                  Decuma AB
    tel +46 709 596305                Ideon Vaexthuset
    anders.holtsberg@decuma.se        S-223 70 Lund, Sweden
 
    
    
                                                                          
    
    [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/0621/
    4. http://lwn.net/2001/0621/security.php3
    5. http://lwn.net/2001/0621/kernel.php3
    6. http://lwn.net/2001/0621/dists.php3
    7. http://lwn.net/2001/0621/desktop.php3
    8. http://lwn.net/2001/0621/devel.php3
    9. http://lwn.net/2001/0621/commerce.php3
   10. http://lwn.net/2001/0621/press.php3
   11. http://lwn.net/2001/0621/announce.php3
   12. http://lwn.net/2001/0621/history.php3
   13. http://lwn.net/2001/0621/bigpage.php3
   14. http://lwn.net/2001/0614/letters.php3
   15. mailto:letters@lwn.net
   16. http://www.lwn.net/2001/0614/history.php3
   17. http://www.drama.uga.edu/
   18. http://www.gnu.org/software/solfege/
   19. http://www.iis.fhg.de/
   20. http://www.atd.ucar.edu/~vanandel/
   21. http://www.linuxweeklynews.com/
   22. http://www.eklektix.com/
   23. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

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