On the Desktop
Linux in the news
All in one big page
See also: last week's Letters page.
Letters to the editor should be sent to firstname.lastname@example.org. 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" <email@example.com> To: firstname.lastname@example.org 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 (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 - email@example.com computer support specialist department of drama and theatre http://www.drama.uga.edu/ ......
From: Patrick Spinler <firstname.lastname@example.org> To: email@example.com 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" <firstname.lastname@example.org> To: email@example.com 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 <firstname.lastname@example.org> GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/
From: John Goerzen <email@example.com> To: firstname.lastname@example.org 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 <email@example.com> www.complete.org Sr. Software Developer, Progeny Linux Systems, Inc. www.progenylinux.com #include <std_disclaimer.h> <firstname.lastname@example.org>
From: Herbert Thoma <email@example.com> To: firstname.lastname@example.org, GnuCash <email@example.com> 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: firstname.lastname@example.org www: http://www.iis.fhg.de/
From: dave mallery <email@example.com> To: <firstname.lastname@example.org> 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 <email@example.com> To: firstname.lastname@example.org 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 http://www.atd.ucar.edu/~vanandel/ Internet: email@example.com
From: Ketil Malde <firstname.lastname@example.org> To: email@example.com 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 <firstname.lastname@example.org> To: email@example.com 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 <firstname.lastname@example.org> To: email@example.com 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 firstname.lastname@example.org "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: email@example.com 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 avoiding 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." <firstname.lastname@example.org> To: <email@example.com> 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 firstname.lastname@example.org
From: "Richard Corfield" <email@example.com> To: firstname.lastname@example.org 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 <email@example.com> To: firstname.lastname@example.org Subject: About your article. Date: Wed, 20 Jun 2001 12:53:34 +0200 In the article 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 Växthuset email@example.com S-223 70 Lund, Sweden