Linux in the news
All in one big page
See also: last week's Back page page.
Fscktris. Tired of waiting while your multi-Gigabyte disks run through an fsck upon reboot? Fscktris may be your answer! Now you can play a Tetris clone while your disks are being cleaned up. Note carefully, however, the caveats from Fscktris' web-page: "Fscktris should only be used if you really don't care about your data. Whilst I've had no problems with it, it comes with no guarantee of safety. This could hose your filesystem ! (although I would say it's unlikely :)".
The website formerly known as LiLAC. The website formerly known as LiLAC has been renamed MobiliX. The emphasis is on information related to Unix/Linux, laptops, PDAs, etc., though the Ecology-HOWTO and Medicine-HOWTO can also be found here.
Section Editor: Jon Corbet
October 26, 2000
Two years ago (October 29th, 1998): The Red Escolar project, then called the "Scholar Net" project, was announced. This was a plan to install Linux throughout 140,000 schools in Mexico and was led by Arturo Espinosa. Nowadays, after gaining experience improving Gnome for the Red Escolar project, Arturo continues his work on Gnome in the United States, working for Helix Code.
We have less specific information on the status of the Red Escolar project, since the Red Escolar News Page hasn't seen an update since June 28th. Fortunately, other pages on the site have been updated more recently, including the status page, which was updated yesterday. It still indicates implementation of the Red Escolar project is only moving forward in the San Luis Potos area.
Debian got congratulations on their port of Debian to the Netwinder two years ago. The Netwinder, however, has remained an infrequently used device, not quite living up to the promise we thought it had back then.
Corel announced its support for the Wine project, choosing it as a platform to bring their products to Linux and promising an infusion of new developers to the project as well. Two years later, the Wine project is finally approaching its first stable release. Meanwhile, of course, the financial state of Corel, and the recent large investment in Corel by Microsoft, have led to questions about Corel's possible future involvement, or lack thereof, both in Wine and in Linux.
One year ago (October 28th, 1999): To no one's surprise, licensing problems between Qt and the GPL were in the spotlight a year ago, with Corel's development as the catalyst. Corel liked using Qt for developing the software they added to the Corel Linux distribution, but their developers were much less likely to be aware of potential licensing conflicts when mixing the Qt with GPL'ed code from Debian. Of course, such problems have now been largely eliminated by the dual-licensing of Qt under the GPL, a possibility not even under discussion last year.
Last year, Comdex' standing policy of not admitting any person under the age of eighteen was under scrutiny, spawning much debate. The policy is no different at this year's Comdex. We have noticed other computer conferences, though, where such age restrictions have been removed.
Speaking of Comdex, Miguel de Icaza will be delivering one of the keynotes at Comdex this year, on Tuesday, November 14th. It was only a year ago that Miguel quit his day job in Mexico and moved to the United States. At that time, his new company Helix Code, Inc., was spoken of only in terms of "secret investors". Nowadays, they've hired a great deal of talent from the Gnome developer team and are in the process of figuring out how to make some money.
Letters to the editor should be sent to email@example.com. 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.
Date: Thu, 19 Oct 2000 22:56:34 -0600 From: Joe Brockmeier <firstname.lastname@example.org> To: email@example.com Subject: Red Hat Editorial Hey Guys, Hope all is well at Linux Weekly News. Read the front page bit about the Red Hat release. I've got to say, I think you're letting Red Hat off pretty easy. Red Hat presents its software as being production-ready, and as such it should be as production-ready as possible. Red Hat is supposed to be the market-leader and as such they should recognize that they're going to be a lot of people's first distro. If they get a distribution that has serious bugs, why should they consider Linux any better than Windows? Most of the people who are going to find these bugs are not going to understand them, and certainly won't appreciate being part of the bug-cleaning crew. And, in their minds they're not getting the benefits of free software - they paid good money for it. Many long-time Linux users recogize that a .0 or .1 release of Red Hat is going to have issues. But newcomers will not, and this is not the time to be springing buggy software onto newcomers to Linux. It's time Red Hat, and the other distros, start releasing just one major release every year and make the rest of them developer releases or updates. It's just not good for retail or for end users who are not developers - a much larger percentage these days. Okay - enough tirade. Just my humble opinion. Take care, Zonker -- Joe "Zonker" Brockmeier firstname.lastname@example.org Zonker@Linux-Mag.com Zonker@UserFriendly.org
Date: Thu, 19 Oct 2000 08:59:50 -0800 From: Arthur Corliss <email@example.com> To: firstname.lastname@example.org Subject: Red Hat's early software release Greetings: I wholeheartedly and emphatically disagree with your assesment of RH's action. I agree that the glib issue was helped by them, but you're talking about apples and oranges. As I recall, glib was a *hell* of a lot more mature than gcc 2.96 is when they did so, and so the end result were pure bug patches. Gcc, on the other hand, has experimental features and methodologies that might not make it into a stable release at all. This isn't hastening adoption, this is just ludicrous decision making, pure and simple. One final thing that everyone seems to be forgetting: screw what Red Hat wants, doesn't the gcc project managers have any say about the inclusion? Even *they* publically denounced the inclusion into a "stable" distribution release. RH obviously cares little about the maintianing developer's recommendations. So let's get this straight: RH did no favours to anyone. They included a release *against* the wishes of the package maintainers, and foisted a product onto the unsuspecting consumer that has experimental features that may even make it incompatible with the *next* stable release. This does *nothing* to debug the product, it only makes RH users guinea pigs in the truest sense of the phrase. That's wrong. Period. Your endorsement of their actions is reprehensible. That said, outside of your ridiculous editorial highlighted above, you have one of the finest Linux e-rags out there, and I read you religiously. Keep up the good work. ;-) --Arthur Corliss Bolverk's Lair -- http://www.odinicfoundation.org/arthur/ "Live Free or Die, the Only Way to Live" -- NH State Motto
Date: Thu, 19 Oct 2000 10:36:23 +0200 From: Federico Di Gregorio <email@example.com> To: firstname.lastname@example.org Subject: about this week editorial hi, in your defense of redhat you compare gcc release with glibc2 release. there are big differences. when redhat released 5.0 debian had already used the new libc for months. in unstable. and almost all debian developers and *a lot* of other people run unstable (that is not so much unstable, but that's a problem with debian slow release cycle...) so that library was not so much new or incompatible with anything else. gcc was taken from *cvs* and released with a new version number without ever worrying for compatibility with other linux systems. that's different. another point is that using the userbase (the *paying* userbase) as a testbad for broken products is a practice i can't approve. it remainds me too much of M$ techniques of shipping broken software. the should have a choice: stable software or over-the-edge-but-buggy one. friendly, federico -- Federico Di Gregorio MIXAD LIVE System Programmer email@example.com Debian GNU/Linux Developer & Italian Press Contact firstname.lastname@example.org Put a GNOME on your desktop! [http://www.gnome.org] -- brought to you by One Line Spam
Date: Fri, 20 Oct 2000 21:37:10 +0000 (GMT) From: Mike Fisk <email@example.com> To: firstname.lastname@example.org Subject: Software testers needed Back when everybody had to download and compile tarballs manually, we all made implicit decisions about when we wanted to upgrade a package and if we wanted to try a development, prerelease version or the latest stable version. Now that so many people just use whatever their favorite distribution has seen fit to give them, there's less experimentation with new versions --- unless that's what your distribution gives you. I applaud distributions pushing the envelope with applications, but they should advertise those distributions as being "tests", "developer releases", "betas", etc. As you state (in the lead article of the October 19th LWN), this is part of the open development process*. But, I don't care for Red Hat's eagerness to shrink-wrap these releases and advertise them as a full release. Microsoft and Apple will sell you test releases, but they're clearly labelled as such and the stable versions are still on the shelf. People who want more reliability with Red Hat have learned to stay behind the curve of new releases. I think other development processes like the Linux kernel and the Debian project achieve the same goals, but are more up-front about it. Many of us choose to track the development kernels or Debian frozen/unstable trees in order to get the latest features in exchange for being guinea pigs. But these development versions are acknowledged as not necessarily being the best choice for stability or usability. For production systems, we may choose to use stable releases. From the IT perspective, having your staff track the unstable kernels and distributions on their desktops or test systems also gives them familiarity with new features before they show up on your production systems. *The increase in public betas of commercial software is evidence that the need for wide exposure in testing isn't specific to open source. -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information
Date: Sat, 21 Oct 2000 12:29:27 +0200 From: Toon Moene <email@example.com> To: firstname.lastname@example.org Subject: When is the right time to release free software? Jon, Liz, On this week's LWN Front Page you write: > When is the right time to release free software? Red Hat has > taken some grief recently for releasing development versions of the > compiler and C library with Red Hat 7. One reason (of many) that has > been put forward to explain this decision is that Red Hat is seeking > to help stabilize the development of gcc 3.0 by increasing the > development version's user base. By increasing the number of testers > (also known as "users"), Red Hat 7 will flush out the remaining bugs > and provide motivation for the gcc team to get 3.0 out there. [ Note that I write the following as GNU Fortran maintainer, and do *not* speak for the GCC Steering Committee ] Perhaps I can correct one misunderstanding from the start: Red Hat did not just "drop" a development *snapshot* of GCC into Red Hat 7 - they took the 20000731 snapshot and applied a boatload of bug fixes to it before they shipped it as Red Hat 7's system compiler. In fact, this is not unlike the way the GCC team organises new releases: A CVS branch is made and is beaten on until we think we ousted all known bugs. Therefore there's no a-priori reason to assume that Red Hat's GCC "2.96" is buggier than the official GCC releases. Because the relevant bug fixes were "fed back" into the official GCC development tree, it *did* help to flush out bugs, but in a different way you foresee (although the effect you mention above will exist). No, Red Hat's move is interesting in a different way: *Nobody knew what they were doing until days before it happened*. On the 23rd of September I sent the following note to the SC list: > Listening to the rumor mill on the Internet, I get the impression that > the (GNU/)Linux distribution according to Red Hat, version 7.0 - due > early next week, will contain an (ammended) snapshot version of GCC > 2.96. > I do not oppose this move per se; however, due to the fact that the > projected release time for GCC-3.0 was "end of the year", I also > didn't particularly take care of bundling related Fortran Frontend > updates that are interdependent. In fact, what happened was (as became clear in hindsight) that the snapshot on the 31st of July - which is the basis of Red Hat 7's system compiler - was taken right in the middle of those updates I mention above. Now, fortunately, the damage is small - the (g77) compiler will crash if you feed it both -g and -fdebug-kludge options when compiling Fortran source with COMMON BLOCKs in it; at least it won't generate incorrect code ... Furthermore, four weeks after the release, apparently nobody has run into this problem yet (at least I haven't seen a bug report about it) ... However, it could have been worse, and to come to the point of my message: It could have been avoided ! If Red Hat had communicated with the developers of GCC, this could easily have been corrected by: 1. Red Hat waiting to take the "quiescent" snapshot that would be the basis for their system compiler. 2. Me working somewhat faster to meet their deadline. 3. Red Hat applying the changes _after_ taking the snapshot. I sincerely hope that this non-communication was an unfortunate incident, and won't happen again. We volunteers in various free software projects have to work with the information presented to us; if someone just takes the work and runs, they get what they asked for ;-) Perhaps it's good to stress again that I write this as my personal view on the matter, in my function as GNU Fortran maintainer. Cheers, -- Toon Moene - mailto:email@example.com - phoneto: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
From: "David C. Spaeth" <firstname.lastname@example.org> To: <email@example.com> Subject: Thank you! Date: Fri, 20 Oct 2000 23:36:05 -0500 You've summed up my opinion about Red Hat's 7 release more succinctly than I ever could! Thanks! I really appreciate Red Hat's efforts in reguard to it's releases. With their work, my systems are steadily becoming more and more able to assist me in managing UNIX systems (SCO, Linux, AIX, and Solaris/SunOS) for my customers. I also run Linux on about 6 systems at home...3 as only Linux, 3 as dual-boot (my kids lie StarCraft and Diablo II). Thanks for not slamming Red Hat! David Spaeth Sr. SysAdmin Taskiss.com
To: firstname.lastname@example.org Subject: Secure Deletion Date: Sat, 21 Oct 2000 17:56:31 -0500 From: Christopher Browne <email@example.com> The "File That Would Not Go Away" problem is indeed more of a problem than people expect, and the "Oh, I'll Just Delete The File" thing represents a perpetually misleading Deus Ex Machina in literature and Television. And the misunderstandings of Hollywood do not just fall out of their ignorance; I don't think that the issue is, generally speaking, well-understood even by those that should know better. Just this week, the TV show "Dark Angel" trotted the situation out where the hacker friend of the protaganist prevents the bad guys from pulling her picture out of prison records by, at the last possible moment, "deleting her record from the database." COMPETENTLY RUN prison information systems are likely to be running a journalling database system [any of the major names, Oracle, Informix, DB/2, Sybase, Microsoft SQL Server, should do] for their database needs. The Bad Guy may react to this setback with a little less fatalism: "Oh, well, let's just take the last cold backup, sitting on tape, along with the Oracle archive logs, continuously being dumped to tape as they are produced, and recover them to a duplicate system." Keeping data ephemeral on systems intended to keep it persistent is about as problematic as keeping data persistent on ephemeral systems. The "most ephemeral" thing is data that sits in memory that will get destroyed as soon as power goes off. Mind you, that is misleading when: - RAM on my PalmPilot _isn't_ lost when I shut it off; - Data might get swapped out to disk At the other end of the scale, databases tend to be characteristic of the "least ephemeral thing;" transaction logs, if carefully backed up, can't be deleted via anything a remote hacker might try to do. After all, if updates get dumped onto tape immediately, and the tape quite quickly gets processed through, dropped into archives, it may become a tremendously challenging thing to try to remove data. This implies that the typical Hollywood scenario of "We'll have to hack in to purge the records from the police files" represents so much nonsense. The last I heard, the RCMP was using Trusted Oracle for such applications; I'm sure similar is true for many other police forces. The funniest relevant anecdote I've heard is of a payroll system where they didn't want to have the high salaries of corporate executives available to the computer systems staff. Every couple weeks, an executive assistant, entrusted with this data, would temporarily enter the rates into the system, run cheques, carefully keeping them from the eyes of the rest of the computer centre staff, and then remove the salaries, leaving everyone none the wiser. Or so they thought. The net result of the process was that the "fingerprints" of the executive pay information was being recorded three or four EXTRA times since the DBMS logged each modification. Back to the drawing board... Files fall somewhere in between in terms of robustness. They are certainly more "stable" than RAM, but are less so than a transaction-logged DBMS. Every time someone adds DBMS technology, such as logging/journalling, to a filesystem, files become a little more difficult to _comprehensively_ purge. The answer may ultimately be to implement some sort of "Secure Temporary File System" providing semantics to guarantee that files can be securely deleted, where temporary files become _truly_ temporary. -- firstname.lastname@example.org - <http://www.hex.net/~cbbrowne/linux.html> "C++ is more of a rube-goldberg type thing full of high-voltages, large chain-driven gears, sharp edges, exploding widgets, and spots to get your fingers crushed. And because of it's complexity many (if not most) of it's users don't know how it works, and can't tell ahead of time what's going to cause them to loose an arm." -- Grant Edwards
Date: Thu, 19 Oct 2000 11:41:16 +0000 From: Oliver White <email@example.com> To: firstname.lastname@example.org, email@example.com Subject: RE: kde and gnome and pr and licensing >KDE has fixed their license problem finally, but it's probably > (hopefully) too late for KDE to recover from Gnome getting the > critical mass of developers. Licencing is a major issue. However, there are several technical reasons that still keep developers from working with Gnome rather than KDE. The Gnome folk are, for the most part, 'Old School' hackers. They depend on Emacs, C and think diagrams are for the weak. This is all very well. However, there is a certain snobbishness towards people who want to develop in C++, using more modern (not necessarily better) techniques for communication like UML, and who'd like to use an Integrated Development Environment. As far as I can see, while KUML is comming along nicely, nobody is interested in developing a Gnome UML tool, though the potential to share code and resources early on is there. Support for C++ Gnome development is comming along quite slowly, and gIDE is a long way behind KDevelop. These cultural reasons, rather than reasons of idealism, are enforcing the divide between the KDE and Gnome projects, I can only hope that in future the choice will simply be based on which environment the developer prefers. -- Oliver White www.worldforge.org
Date: Sun, 22 Oct 2000 14:01:41 -0300 From: Horst von Brand <firstname.lastname@example.org> To: email@example.com Subject: Red Escolar (Re: Stop the colors already!) Peter Samuelson <firstname.lastname@example.org> said: [...] > So now, according to the LWN sidebars, we have the five mentioned above > plus Black Cat Linux, BluePoint Linux, White Dwarf Linux and Green Frog > Linux, not to mention the variations Darkstar Linux, Red Linux, Redmond > Linux, Think Blue Linux and the Red Escolar Project. Oh, and don't > forget the ones that incorporate the Red Hat name directly, like VA/Red > Hat and KRUD. "Red Escolar" is Spanish for "School Network", "red" is "network". No colors were harmed when naming this. -- Horst von Brand email@example.com Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Date: Sat, 21 Oct 2000 08:24:28 +1100 From: Tim Josling <firstname.lastname@example.org> To: email@example.com Subject: Undefined expressions in C "The hunt for undefined code. Here's one kind of problem that a new compiler can turn up. Most C programmers learn early on to avoid code like: a[i] = i++; The results of this kind of code are undefined; the array assignment could happen either before or after the value of i is incremented." The expression above, as no doubt many people have pointed out, is actually OK. Section 3.3 of the 1988 ANSI C standard says that you can only assign once to a variable in an expression. So for example i = i++ + 1; is not allowed because i gets assigned to twice. But a[i] = i++; is OK - i is only assigned to once, and the value used for the array subscript is the value before the auto-increment. Tim Josling
Date: Fri, 20 Oct 2000 15:42:41 +0100 From: John Winters <firstname.lastname@example.org> To: email@example.com Subject: Kernel development page - 2000-10-19 Hi there, At the risk of flogging a dead horse I'd just like to pick up on something said on your kernel development page this week: Quote============================ The hunt for undefined code. Here's one kind of problem that a new compiler can turn up. Most C programmers learn early on to avoid code like: a[i] = i++; The results of this kind of code are undefined; the array assignment could happen either before or after the value of i is incremented. End Quote======================== The final sentence is the problem. Yes, it's undefined but the last part gives more than a passing impression that the undefinition is confined to when the increment occurs. That's not true at all. The code simply has no meaning within the confines of the C language - you might get the result you expect; you might get a result consistent with the increment having happened before or after the assignment; you might get any behaviour at all. The classic defence of such code is, "I don't care whether the increment happens before or after. Either will do what I want." This alas fails because there's no guarantee that the increment will happen at all (or that the assignment will happen, or that the code will even compile). Apologies if you already know all this but even as a simplified explanation the quote above can lead to problems. Regards, John Winters -- John Winters. Wallingford, Oxon, England. The Linux Emporium - the source for Linux CDs in the UK See http://www.linuxemporium.co.uk/