The X Window System, past and future

The Jargon File defines X as "An over-sized, over-featured, over-engineered and incredibly over-complicated window system developed at MIT and widely used on Unix systems." The Unix Hater's Handbook states: "X Windows [sic] is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed." The "fortune" program shipped with most Linux distributions contains six extended diatribes against X, with delightful tidbits like: "The trailing edge of software technology.", "The greatest productivity aid since typhoid.", "You'll envy the dead.", and "Making the world safe for competing window systems.". And those are just from the first of six. The last dig quoted above is interesting, though, when confronted with one little fact: there are no competing window systems.

Most LWN readers will be aware by now of the current dispute over the direction of the XFree86 project. The next article will look at what is going on there, but, first, it's worth taking a moment to look at the absolute monopoly that X holds on Linux (and Unix) desktops.

As free software projects go, X is one of the older ones. The first X release, built with support from the company then known as Digital Equipment Corporation, came out of MIT in 1984. By the time X10 was released, the window system was beginning to be widely used outside of MIT, but it was X11 (released on September 15, 1987 - you could order it on nine-track tape) that established X as the definitive Unix windowing environment. Several vendors, wanting to support the continued development of a vendor-neutral windowing system, formed the X Consortium to further support development in 1988. The Consortium eventually lost its relevance when the Unix vendors decided they wanted to start "differentiating" their window systems, and the XFree86 project became the real core of X11 development. That, of course, is how things stand today.

X11 is certainly one of the longest-lasting major releases in software history; more than fifteen years later the X11 protocol maintains backward compatibility, and there has never been an X12 release.

Since the early days, X has been the target of severe criticism. Attackers claim that it is over-engineered and bloated. Its absolute refusal to dictate policy (or even provide a standard window manager) has led to wildly incompatible interfaces on the same desktop. X requires applications to deal with too much information about the underlying hardware. The network-based client/server protocol is slow and has led to security problems. There is no way to load code into the server itself. The server doesn't even maintain window contents, forcing applications to deal with "expose" events. And so on. X, it is said, is "vacuumware," it sucks, but succeeded because there was nothing else out there.

The above criticisms are, beyond doubt, not entirely lacking in merit. But the fact remains that X is the only viable windowing system for Unix-like systems. It pushed aside numerous proprietary systems (SunView was halfway out the door before Sun officially switched) and established itself as the standard across an amazing range of systems from different vendors. If X were truly that bad, a viable competitor would certainly have arisen in the 15 years since X11R1 was released. The few attempts (your editor once had the unfortunate experience of trying to program a project under NeWS) have sunk without a trace.

Why has X been so successful? Here's a few possible reasons:

• X actually does pretty well at hiding hardware details for many applications. But the ability (and, occasionally, requirement) to deal with the hardware allowed the writing of applications that behaved optimally on a wide range of systems.

• The X client/server protocol was unique; it enabled the separation of applications from the desktop where their interfaces were displayed. If you were a system admin who suddenly could easily monitor several servers on one screen, or a scientific user who could run supercomputer visualizations from your desktop, this was a big deal.

• The refusal to set policy allowed a great deal of experimentation in user interface policies. Lots of bad ideas (i.e. tiling window managers, Motif) were tried and discarded without having been wired into the window system itself. Even now, X provides a platform where competing visions of the desktop can be implemented and tried out.

• The built-in extensibility of the X11 protocol has allowed it to evolve over time without breaking compatibility with older applications.

• It works, and has for a long time.

Of course, one should not forget the other important reason why X succeeded back in the 1980's: it was free software.

So now X dominates the non-Windows desktop. Given the extent to which some people criticize X, one would assume there would be a whole set of development projects working to replace it. The fact that X works well and the existence of a large set of existing X applications present a daunting challenge to any potential replacement, however. Without a compelling reason to change (and rock-solid X compatibility), users are likely to remain with X for quite some time into the future. So it is not surprising that free software projects working on X replacements are not easy to find. There just isn't that much of an itch to scratch.

One group that is trying, however, is the Fresco project (formerly known as "Berlin"). Fresco's approach differs from that of X in many ways: user interface policy will be wired into the window system itself; more advanced rendering will be supported by the server; the API will be based on vector operations and will be resolution-independent; CORBA will be used as the network transport; and the whole thing will be built with heavy use of threading in mind. Potential users will need to be patient; according to the web site, "Fresco is only useful for demos (really cool demos though :)". Fresco announced its second milestone release on March 4.

Someday a project like Fresco may well succeed in displacing X from our desktops. Someday. Meanwhile, X will remain one of the crucial components of free operating systems like Linux. So the current disagreements over the direction of the XFree86 project are important.

Comments (17 posted)

The Future of XFree86

[This article was contributed by Joe 'Zonker' Brockmeier]

Sometimes a good argument is necessary to get everything out in the open and to make a little progress. That seems to be the case with the current XFree86 controversy.

If you haven't been following it, the furor started when XFree86 developer Keith Packard was ousted from the Core Team. Apparently, Packard was trying to start a fork of the project without discussing the issue with other Core Team members first. After the dust had settled, somewhat, the XFree86 Project's board issued an open invitation to discuss "Any topics...from those related to administrative and management issues through to technical issues." In just eight days, more than 700 messages have been sent to the list. A lot of ideas have been thrown around, including a joint statement from the GNOME and KDE projects.

Packard has now made public some of his complaints with the current status of the XFree86 Project. His "A Call For Open Governance Of X Development" posits that there are a number of problems with development of XFree86. Specifically, Packard writes that XFree86 suffers from limited development resources, slow release schedules, a lack of cooperation with other projects and a lack of information on how to get involved with XFree86 development. Packard concludes that XFree86 needs to be a community-governed project.

The XFree86 Project has already responded to Packard's complaint that there is a lack of information on becoming a developer by adding a prominent link to the front page titled "How to become an XFree86 Developer." Short and to the point, it nevertheless provides some guidance for interested developers: "Get and build the latest XFree86 code from the CVS repository, subscribe to the XFree86 developer list (devel@XFree86.org) and participate."

David Wexelblat, one of the Core Team members, notes that the issue of infrequent releases, at least in terms of card support, is a non-issue:

David Dawes, head of the XFree86 Board of Directors and leader of the core team has committed to tagging regular snapshots, every two weeks, of the CVS trunk. This doesn't address the question of more frequent stable releases, but it should provide a way for more people to be involved in testing XFree86 and providing feedback.

Wexelblat also disagrees that XFree86 should be community-governed. "There is no reason to change the meritocracy, other than to work on promoting sufficient people through it, of sufficient skill/quality/integridy [sic] to get the work done." Rich Murphey, another member of the XFree86 board, agrees that "sweat equity" is the best way to have influence on the direction of the project. "Join devel, write code, join core. That's how it works...I don't see a more effective solution than that."

Both Packard and Wexelblat agree that XFree86 could benefit from additional resources. Wexelblat raises the issue of poor support for XFree86 by commercial companies:

Given the importance of XFree86 to the long-term success of Linux on the desktop, now might be a good time for some of the Linux companies to step up support for XFree86. It seems clear that, regardless of other changes, XFree86 development will remain a meritocracy. However, the attention now being focused on the project is likely to produce some long-term benefits despite the initial unpleasantness.

Comments (8 posted)

Quick LWN update

Time flies... it is now six months since LWN began the subscription experiment. How do we know? Many of you signed up for six-month subscriptions, and those are now expiring. If you are one of those, it's time to be thinking about renewing; remember that prepaid subscriptions of ten months or longer get a 10% discount.

LWN's subscribers are the only thing keeping this site on the net; we thank you for your support.

Comments (15 posted)

Relaxing with the XDR Vulnerability

[This article was contributed by Tom Owen]

A vulnerability in a library is unsettling. When the affected code is in glibc it seems like genuine grounds for alarm. Not only the library itself, but potentially every static-linked executable may need to be replaced or rebuilt, and it takes a very confident system administrator to swear to the link status of everything on the system.

These vulnerabilities do appear from time to time. Fortunately, it generally turns out that thought is a substitute for panicky rebuilds. The XDR vulnerability provides a handy example.

RPC (Remote Procedure Call) is an upper-layer network protocol developed by Sun as part of their vision of network-centric computing. Services offered via RPC appear to be simple functions which are called by applications; this system has been a key basis for many distributed applications, with NFS being the most famous. One obstacle to passing program data between hosts is the varying binary representation of basic data types like integers and floating point numbers. Ones-complement integers aren't much of a problem these days, but little and big endian byte orders are in use as are non-IEEE floating point formats. The solution used by Sun is for all hosts to convert data to and from a standard network representation; this representation is called "external data representation," or XDR.

The routines for XDR data conversion are included in glibc. One of these routines (xdr_array()) has a vulnerability where a crafted message can cause a buffer overflow. Finding out how much to worry about this vulnerability is really a matter of finding all of the uses of the XDR code in your system.

The place to start is with the new glibc itself. There's no good reason not to install this update -- it's insurance against changes in the future if nothing else. Another sensible precaution for any site is to ensure that RPC network traffic is stopped at the firewall. Running RPC across the public Internet is a fine security challenge, but not an obvious win. A complete block takes a bit of research as RPC ports sometimes vary from site to site, but blocking TCP and UDP for 111 (the portmapper) and 2049 (NFS) is a start. If RPC can't get in from outside then you won't be interpreting any external messages as XDR.

For many Linux sites RPC is needed to support NFS, or other services like NIS. That's the first stopping point -- all sites without NFS and without some other need for RPC-based services can stop now. Job done.

The next set of easy exits is for the bulk of those RPC and NFS sites.

Dynamic linking has its downside, but like most good ideas, its disadvantages turn out to be the same as its benefits. For certain, dynamic linking means that a working system can be silently wrecked by installing an application with an incompatible version of some library. But that same feature gets us out of trouble here -- if ever there was a library to link dynamically, glibc -- stable and ubiquitous -- is it.

Distributors that have published fixes are typically offering the updated library itself and perhaps some NFS daemons. Since most applications use dynamic linking with glibc, replacing that library is sufficient to close the vulnerability. For most sites, updating glibc is all that is required.

Everybody left counts as a programmer or a builder. Programmers will know whether they have a problem. The rest of us -- call us naive builders -- are the ones with the problem. It's here that we have to fall back on the safe course. If we truly can't tell whether we're using the XDR functions or static linking then, finally, it's time to rebuild and reinstall our applications.

Comments (3 posted)

bonsai: multiple vulnerabilites

Package(s):	bonsai	CVE #(s):	CAN-2003-0152 CAN-2003-0153 CAN-2003-0154 CAN-2003-0155
Created:	March 21, 2003	Updated:	March 26, 2003
Description:	Remi Perrot fixed several security related bugs in bonsai, the Mozilla CVS query tool by web interface. Vulnerabilities include arbitrary code execution, cross-site scripting and access to configuration parameters. The Common Vulnerabilities and Exposures project identifies the following problems: CAN-2003-0152 - Remote execution of arbitrary commands as www-data CAN-2003-0153 - Absolute path disclosure CAN-2003-0154 - Cross site scriptiong attacks CAN-2003-0155 - Unauthenticated access to parameters page
Alerts:	Debian DSA-265-1 bonsai 2003-03-21

Comments (none posted)

delegate - remote code execution vulnerability

Package(s):	delegate	CVE #(s):
Created:	March 20, 2003	Updated:	March 26, 2003
Description:	According to a SNS security advisory, a remote code execution vulnerability exists in the application level gateway DeleGate version 8.4.0 and earlier. Fetching a large robots.txt file through DeleGate HTTP proxy could result in a buffer overflow.
Alerts:	OpenPKG OpenPKG-SA-2003.023 delegate 2003-03-19

Comments (none posted)

evolution: multiple vulnerabilities

Package(s):	Evolution	CVE #(s):	CAN-2003-0128 CAN-2003-0129 CAN-2003-0130
Created:	March 21, 2003	Updated:	May 14, 2003
Description:	Multiple vulnerabilities have been found in Ximian's Evolution Mail User Agent, according to this CoreLabs advisory. "Three vulnerabilities were found that could lead to various forms of exploitation ranging from denying to users the ability to read email, provoke system unstability, bypassing security context checks for email content and possibly execution of arbitrary commands on vulnerable systems." Ximian Evolution is a personal and workgroup information management solution for Linux and UNIX-based systems. The software integrates email, calendaring, meeting scheduling, contact management, and task lists, in one application.
Alerts:	Conectiva CLA-2003:648 evolution 2003-05-14 Mandrake MDKSA-2003:045 evolution 2003-04-15 Yellow Dog YDU-20030409-2 evolution 2003-04-09 Red Hat RHSA-2003:108-03 evolution 2003-03-31 Red Hat RHSA-2003:108-02 evolution 2003-03-24 Gentoo 200303-18 evolution 2003-03-21 Red Hat RHSA-2003:108-01 Evolution 2003-03-21

Comments (1 posted)

glibc: integer overflow in the xdrmem_getbytes() function

Package(s):	glibc krb5 dietlibc	CVE #(s):	CAN-2003-0028
Created:	March 21, 2003	Updated:	May 27, 2003
Description:	An integer overflow in the xdrmem_getbytes() function, and possibly other functions, of XDR (external data representation) libraries derived from SunRPC, including libnsl, libc, and glibc, allows remote attackers to execute arbitrary code via certain integer values in length fields See CAN-2003-0028 and CERT advisory CA-2003-10 for more information.
Alerts:	SuSE SuSE-SA:2003:027 glibc 2003-05-26 Slackware ssa:2003-141-03 glibc 2003-05-22 Conectiva CLA-2003:639 krb5 2003-05-05 Conectiva CLA-2003:633 glibc 2003-04-30 Immunix IMNX-2003-7+-009-01 glibc 2003-04-14 Debian DSA-282-1 glibc 2003-04-09 Gentoo 200303-29 dietlibc 2003-03-31 Debian DSA-272-1 dietlibc 2003-03-28 Trustix 2003-0014 glibc 2003-03-26 Mandrake MDKSA-2003:037 glibc 2003-03-25 Gentoo 200303-22 glibc 2003-03-25 Debian DSA-266-1 krb5 2003-03-17 Red Hat RHSA-2003:089-00 glibc 2003-03-19 Sorcerer SORCERER2003-03-20-2 glibc 2003-03-20 Sorcerer SORCERER2003-03-20-1 krb5 2003-03-20 EnGarde ESA-20030321-010 glibc 2003-03-21 SCO Group CSSA-2003-013.0 XDR/RPC 2003-03-19

Comments (3 posted)

ircii: buffer overflow vulnerability

Package(s):	ircii	CVE #(s):
Created:	March 20, 2003	Updated:	April 22, 2003
Description:	Timo Sirainen audited ircII based clients (see this Bugtraq post) and found some buffer overflow vulnerabilities in ircii-20020912.
Alerts:	Debian DSA-291-1 ircii 2003-04-22 Gentoo 200303-21 bitchx 2003-03-24 OpenPKG OpenPKG-SA-2003.024 ircii 2003-03-19

Comments (none posted)

kerberos - cryptographic weakness

Package(s):	kerberos, heimdal, openafs	CVE #(s):	CAN-2003-0138 CAN-2003-0139
Created:	March 26, 2003	Updated:	May 27, 2003
Description:	Version 4 of the Kerberos protocol contains a cryptographic weakness which enables a chosen-plaintext attack. A suitably equipped attacker can impersonate any principal in the realm. Another weakness allows the creation of false Kerberos tickets. Given the weaknesses in the cryptography, cross-realm authentication cannot be performed in a secure way. OpenAFS kaserver implements version 4 of the Kerberos protocol, and therefore is also vulnerable.
Alerts:	Gentoo 200305-09 heimdal 2003-05-27 Debian DSA-269-2 heimdal 2003-04-09 Immunix IMNX-2003-7+-007-01 Kerberos 5 2003-04-07 Red Hat RHSA-2003:091-01 krb5 2003-04-02 Mandrake MDKSA-2003:043 krb5 2003-04-01 Gentoo 200303-28 krb5 2003-03-31 Gentoo 200303-26 openafs 2003-03-30 Debian DSA-273-1 krb4 2003-03-28 Red Hat RHSA-2003:051-01 krb5 2003-03-26 Debian DSA-269-1 heimdal 2003-03-26

Comments (none posted)

mutt: buffer overflow in IMAP client code

Package(s):	mutt	CVE #(s):	CAN-2003-0140
Created:	March 21, 2003	Updated:	April 22, 2003
Description:	Core Security Technologies has found a remotely exploitable buffer overflow in mutt's IMAP client code. This Bugtraq post contains additional information. The problem has been fixed in Mutt 1.4.1 (stable) and 1.5.4 (unstable).
Alerts:	Conectiva CLA-2003:630 balsa 2003-04-22 Conectiva CLA-2003:626 mutt 2003-04-14 Debian DSA-274-2 mutt 2003-04-07 Red Hat RHSA-2003:109-03 balsa 2003-04-03 Mandrake MDKSA-2003:041 mutt 2003-04-01 Slackware sl-1049141887 mutt 2003-03-31 Slackware sl-1049038131 mutt 2003-03-30 Debian DSA-274-1 mutt 2003-03-28 Debian DSA-268-1 mutt 2003-03-25 Gentoo 200303-19 mutt 2003-03-22 SuSE SuSE-SA:2003:020 mutt 2003-03-24 OpenPKG OpenPKG-SA-2003.025 mutt 2003-03-20

Comments (none posted)

CERT Quarterly Summary

CERT has sent out its quarterly summary listing the vulnerabilities that it sees being most frequently exploited. Along with a number of Windows issues, this summary lists the sendmail buffer overflow, the Samba vulnerability, and the CVS and SSH bugs.

Full Story (comments: none)

Stopping DDOS Attacks (Linux Journal)

The Linux Journal has an article on dealing with distributed denial of service attacks. "What about getting the Feds involved? In the GRC.com case I mentioned above, the FBI was totally uninterested. Of course, this case occurred in May 2001. It seems that the new Department of Homeland Security is somewhat more interested in such things. Then again, this is the same outfit that sat on the recent Sendmail vulnerability for two+ months. Hackers everywhere are justifiably skeptical."

Comments (none posted)

DEF CON 0x0b call for papers

The call for papers for DEF CON 0x0b has gone out. "We are also continuing to improve speaker quality. It is no longer enough to have green hair and an attitude."

Full Story (comments: none)

Kernel release status

The current development kernel is 2.5.66, which came out on March 24. This large patch contains a great many small fixes. It also has some more IDE changes, some ext3 performance improvements, the 32-bit dev_t preparatory patches (see last week's Kernel Page and below), more devfs chopping, the new sys_epoll() API (covered briefly here two weeks ago), a big framebuffer update, an ALSA update, and an XFS update. See Linus's announcement or the long-format changelog for the details.

Linus's BitKeeper repository contains an XFS update, a USB update, and a number of architecture updates (ARM, SPARC64, x86-64, PPC64).

The current prepatch from Alan Cox is 2.5.65-ac3, which adds another set of small fixes.

The current stable kernel is 2.4.20; Marcelo tried to catch us by releasing 2.4.21-pre6 late on Wednesday, but we're on to him. This release contains many fixes of course (including a large set from the -ac tree and the ptrace() fix) and some architecture updates. The first 2.4.21 release candidate is apparently coming soon.

There has been some significant disagreement over whether 2.4.21 should be rushed out with the fix for the ptrace() vulnerability. Numerous people, it is said, run kernels obtained from kernel.org, but do not follow the mailing list closely enough to pick up needed security patches. Rather than leave those people vulnerable, a new release (containing, perhaps, only the security fix) should be made available as soon as possible. On the other side, it is argued that distributors have made patched kernels available, and anybody who is concerned can patch their kernels themselves.

The apparent resolution is that there will not be an expedited 2.4.21 release with the fix. Certainly no such kernel has been released; Marcelo has been completely silent on the matter.

Comments (11 posted)

Toward a larger dev_t

The 2.5.66 kernel includes Andries Brouwer's patches clearing the path for an expansion of the dev_t device number type. A small number of problems have been found, but the changes are working for most people. Andrew Morton has gone a little further and actually changed dev_t to 32-bits in his -mm tree; predictably, the number of problems found there has been a little higher. As a whole, though, the transition appears to be going relatively smoothly.

Badari Pulavarty decided that it was time to play with the possibilities of a larger device number type; he posted this patch which makes the SCSI disk driver make full use of the expanded minor number range. Testing with 4000 virtual disks, with 50 real drives at the end of the range, worked - for the most part. Some scaling problems did turn up, however.

The most significant one appears to be in the request queue mechanism. When the kernel wants to issue a block I/O request, the block subsystem needs to be able to set it up quickly. In particular, memory allocations are best avoided at that point; it's possible that the system is out of memory and the kernel is doing I/O in an attempt to free up some space. Trying to allocate memory at that point can lead to deadlocks. So the block subsystem sets aside a number of pre-allocated request structures for every request queue (and there is typically one request queue for each physical drive in the system). That number varies depending on the amount of memory on the system; it can be as low as 32, and as high as 256. Request structures run about 144 bytes each. So, if one assumes that a system hosting 4000 disks really should be equipped with a fair amount of memory, the block subsystem will set aside about a million request structures, at a cost of about 150MB. And that is just the beginning; the deadline I/O scheduler augments each request structure with a separate deadline_rq structure. Other overheads exist as well.

The end result is that, when the number of disks gets large, a great deal of memory (which must all be in the low memory zone on 32-bit processors) gets tied up in request queues. As Andrew Morton pointed out, with 4000 disks, enough request structures have been allocated to represent 200GB of current I/O requests. That, perhaps, is a bit more than is really needed in most situations.

The solution, as hacked up by Jens Axboe, is to go to a more dynamic scheme for the allocation of request structures. The mempool mechanism is used to keep an absolute minimum number of request structures available for each queue; all the rest are allocated as needed and freed afterwards. This patch will probably go through a few more iterations, but the immediate scalability problem has been addressed.

Meanwhile, not everybody is entirely happy with the direction of the dev_t changes for char devices. In particular, Roman Zippel, who has apparently given up on getting the module changes backed out, has now posted a series of patches backing out the char device changes and substituting his approach. That approach includes maintaining the (currently unused) char device hashing scheme and getting rid of the new register_chrdev_region() function. There is, he claims, no particular need to split char minor number ranges into regions, as there is with block devices. Roman's patches have created some discussion, but there does not appear to be a great deal of pressure for a change in direction at this time.

There has also been a bit of discussion on how big the new dev_t should be. The plan has been to expand it to 32 bits; 12 for the major number, and 20 for the minor number. That is the way Linus has wanted to do it, but he recently has made noises about being open to the idea of making dev_t even larger. If dev_t were to go to 64 bits, with 32 each for major and minor numbers, there would be little need to worry about running out of device numbers for some time into the future. This decision may not be made for a while; once the work to support the dev_t expansion has been done, setting it to one size or another is a relatively simple task.

Comments (6 posted)

Various short topics

Discussion on linux-kernel this week touched on a number of topics that, while worth a mention, don't necessarily justify a full article of their own. Here's a few of them:

Deprecating the .gz format. Peter Anvin would like to get rid of the .gz files on kernel.org. The bzip2 format has been around for quite some time and is far more space efficient; it would seem that eliminating the older format would be relatively uncontroversial. Such is not the case, however; users protested that the bzip2 format is slower, is not supported on Windows, and so on. The end result is that the gzip files will remain for some time yet.

kbugs.org is now showing over 1400 potential bugs found with the rapidly-evolving smatch system. A number of these are real, and fixes are beginning to find their way into the mainline kernel.

The Stanford Checker team has also been posting errors; the latest set points out places where kernel code is directly dereferencing user-supplied pointers. That kind of mistake can lead to all kinds of problems, of course, including security issues. The discussion led to a suggestion that the kernel use a different type for user-space pointers, so that this kind error could be caught directly by the compiler. The idea makes some sense; kernel code currently does not formally distinguish between user-space, kernel-space, and physical address pointers. Clarifying the difference between them could catch a lot of mistakes. This sort of change seems unlikely at this point in 2.5, however.

The object-based reverse mapping VM patch was covered here back in February. The object-based rmap code does not work with anonymous memory (memory which is not mapped to a file somewhere), however, meaning that this memory must still be managed with PTE chains. Hugh Dickins has posted a new set of patches which extend the object-based approach to anonymous memory as well. The patch was included in the -mm tree for a while, and seems to work without trouble. The only problem is: it doesn't actually help performance very much. Most anonymous memory only shows up in one page table, so its PTE chain overhead is essentially zero. So this patch has been dropped, though useful pieces of it may eventually find their way into the tree.

The IDE todo list has been posted by Alan Cox. This list is important in that it affects most Linux users; it also documents some of the remaining tasks to be done on the way to a 2.6 release. There's a few drivers needing thorough audits (and some that don't work at all yet), more hotplug work, documentation, and a number of other tasks yet to be done.

SMP overhead and rwlocks. Andrew Morton has noted that a simple write test takes twice as long on an SMP system as on a uniprocessor system. The culprit, of course, is the extra locking overhead. Reader-writer locks (rwlocks) have been singled out as particular problem; it turns out that they are slower than regular spinlocks, and they tend to mask problems where locks are simply being held for too long. There is a chance that rwlocks will be removed before 2.6 comes out.

Comments (1 posted)

Driver porting: the BIO structure

This article is part of the LWN Porting Drivers to 2.6 series.

The block layer in 2.4 (and prior) kernels was organized around the buffer head data structure. The limits of buffer heads have long been clear, however. It is hard to create a truly high-performance block I/O subsystem when the underlying buffer head structure forces each I/O request to be split into 512-byte chunks. So one of the first items on the 2.5 block "todo" list was the creation of a way to represent block I/O requests that supported higher performance and greater flexibility. The result was the new BIO structure.

BIO basics

As with most real-world code, the BIO structure incorporates a fair number of tricky details. The core of the structure (as defined in <linux/bio.h>) is not that complicated, however; it is as appears in the diagram to the right. The BIO structure itself contains the usual collection of housekeeping information, along with a pointer (bi_io_vec) pointing to an array of bio_vec structures. This array represents the (possibly multiple) segments which make up this I/O request. There is also an index (bi_idx) giving an offset into the bi_io_vec array; we'll get into its use shortly.

The bio_vec structure itself has a simple definition:

    struct bio_vec {
	struct page	*bv_page;
	unsigned int	bv_len;
	unsigned int	bv_offset;
    };

As is increasingly the case with internal kernel data structures, the BIO now tracks data buffers using struct page pointers. There are some implications of this change for driver writers:

• Data buffers for block transfers can be anywhere - kernel or user space. The driver author need not be concerned about the ultimate source or destination of the data.

• These buffers could be in high memory, unless the driver author has explicitly requested that bounce buffers be used (Request Queues I covers how to do that). The driver author cannot count on the existence of a kernel-space mapping for the buffer unless one has been created explicitly.

• More than ever, block I/O operations are scatter/gather operations, with data coming from multiple, dispersed buffers.

At first glance, the BIO structure may seem more difficult to work with than the old buffer head, which provided a nice kernel virtual address for a single chunk of data. Working with BIOs is not hard, however.

Getting request information from a BIO

A driver author could use the information above (along with the other BIO fields) to get the needed information out of the structure without too much trouble. As a general rule, however, direct access to the bio_vec array is discouraged. A set of accessor routines has been provided which hides the details of how the BIO structure works and eases access to that structure. Use of these routines will make the driver author's job easier, and, with luck, will enable a driver to keep working in the face of future block I/O changes.

So how does one get request information from the BIO structure? The beginning sector for the entire BIO is in the bi_sector field - there is no accessor function for that. The total size of the operation is in bi_size (in bytes). One can also get the total size in sectors with:

    bio_sectors(struct bio *bio);

The function (macro, actually):

    int bio_data_dir(struct bio *bio);

returns either READ or WRITE, depending on what type of operation is encapsulated by this BIO.

Almost everything else requires working through the bio_vec array. The encouraged way of doing that is to use the special bio_for_each_segment macro:

    int segno;
    struct bio_vec *bvec;

    bio_for_each_segment(bvec, bio, segno) {
	/* Do something with this segment */
    }

Within the loop, the integer variable segno will be the current index into the array, and bvec will point to the current bio_vec structure. Usually the driver programmer need not use either variable; instead, a new set of macros is available for use within this sort of loop:

struct page *bio_page(struct bio *bio)

Returns a pointer to the current page structure.

int bio_offset(struct bio *bio)

Returns the offset within the current page for this operation. Block I/O operations are often page-aligned, but that is not always the case.

int bio_cur_sectors(struct bio *bio)

The number of sectors to transfer for this bio_vec.

char *bio_data(struct bio *bio)

Returns the kernel virtual address for the data buffer. Note that this address will only exist if the buffer is not in high memory.

char *bvec_kmap_irq(struct bio_vec *bvec, unsigned long *flags)

This function returns a kernel virtual address which can be used to access the data buffer pointed to by the given bio_vec entry; it also disables interrupts and returns an atomic kmap - so the driver should not sleep until bvec_kunmap_irq() has been called. Note that the flags argument is a pointer value, which is a departure for the usual convention for macros which disable interrupts.

void bvec_kunmap_irq(char *buffer, unsigned long *flags);

Undo a mapping which was created with bvec_kmap_irq().

char *bio_kmap_irq(struct bio *bio, unsigned long *flags);

This function is a wrapper around bvec_kmap_irq(); it returns a mapping for the current bio_vec entry in the given bio. There is, of course, a corresponding bio_kunmap_irq().

char *__bio_kmap_atomic(struct bio *bio, int i, enum km_type type)

Use kmap_atomic() to obtain a kernel virtual address for the i^th buffer in the bio; the kmap slot designated by type will be used.

void __bio_kunmap_atomic(char *addr, enum km_type type)

Return a kernel virtual address obtained with __bio_kmap_atomic().

A little detail which is worth noting: all of bio_data(), bvec_kmap_irq(), and bio_kmap_irq() add the segment offset (bio_offset(bio)) to the address before returning it. It is tempting to add the offset separately, but that is an error which leads to weird problems. Trust me.

Completing I/O

Given the information from the BIO, each block driver should be able to arrange a transfer to or from its particular device. Note that a helper function (blk_rq_map_sg()) exists which makes it easy to set up DMA scatter/gather lists from a block request; we'll get into that when we look at request queue management.

When the operation is complete, the driver must inform the block subsystem of that fact. That is done with bio_endio():

    void bio_endio(struct bio *bio, unsigned int nbytes, int error);

Here, bio is the BIO of interest, nbytes is the number of bytes actually transferred, and error indicates the status of the operation; it should be zero for a successful transfer, and a negative error code otherwise.

Other BIO details

The bi_private field in the BIO structure is not used by the block subsystem, and is available for the owner of the structure to use. Drivers do not own BIOs passed in to their request function and should not touch bi_private there. If your driver creates its own BIO structures (using the functions listed below, usually), then the bi_private field in those BIOs is available to it.

As mentioned above, the bi_idx BIO field is an index into the bi_io_vec array. This index is maintained for a couple of reasons. One is that it can be used to keep track of partially-complete operations. But this field (along with bi_vcnt, which says how many bio_vec entries are to be processed) can also be used to split a BIO into multiple chunks. Using this facility, a RAID or volume manager driver can "clone" a BIO into multiple structures all pointing at different parts of the bio_vec array. The operation is quick and efficient, and allows a large operation to be quickly dispatched across a number of physical drives.

To clone a BIO in this way, use:

    struct bio *bio_clone(struct bio *bio, int gfp_mask);

bio_clone() creates a second BIO pointing to the same bio_vec array as the original. This function uses the given gfp_mask when allocating memory.

BIO structures contain reference counts; the structure is released when the reference count hits zero. Drivers normally need not manipulate BIO reference counts, but, should the need arise, functions exist in the usual form:

    void bio_get(struct bio *bio);
    void bio_put(struct bio *bio);

Numerous other functions exist for working with BIO structures; most of the functions not covered here are involved with creating BIOs. More information can be found in <linux/bio.h> and block/biodoc.txt in the kernel documentation directory.

Comments (18 posted)

The Significance of Red Hat Linux 9

[This article was contributed by Ladislav Bodnar]

The announcement from Red Hat about the upcoming release of Red Hat Linux 9 has caught many by surprise. In the past, Red Hat, Inc has stubbornly refused to pre-announce any release, whether final or development, giving all who inquired the usual "released when ready" talk. The version number was also unexpected as many had thought that this release would be labeled 8.1 rather than 9.

At first glance these changes might seem insignificant. But a closer look reveals that there are reasons why they come into effect at this point in time and some of these changes will have substantial impact on enterprises.

Firstly, let's look at the significance of that "9". Of all Linux distributions out there, Red Hat is the only one that maintains a technically and logically justified versioning scheme, as opposed to a scheme driven by marketing. Historically, Red Hat only increased the major version number if the new release broke binary compatibility with the previous one. The binary compatibility was, to a large extent, defined by the the glibc library and if we look at the last few years' worth of releases, we will see that Red Hat 6 series shipped with glibc 2.1.x, Red Hat 7 series with glibc 2.2.x and Red Hat 8.0 with a pre-release version of glibc 2.3.

Red Hat 9 will ship with glibc 2.3.2. However, there is something else that breaks the binary compatibility in this case and that something is called NPTL (Native POSIX Thread Library). What is NPTL? A comprehensive white paper (in PDF format) explains all the technical details, but in layman's terms, NPTL is a much improved new library for threading of processes which takes into account capabilities of modern processors. This library, developed by Red Hat, is designed to replace the existing library written back in 1996. (See also LWN's coverage of NTPL from last September).

As a result of introducing NPTL, many applications compatible with previous Red Hat releases will no longer work on Red Hat Linux 9. Some of the implications are explained in this mailing list post. The poster (Red Hat's Matt Wilson) also points out another interesting fact: the Enterprise Linux series of products has freed the company to put newer technology into the base "Red Hat Linux" distribution. Red Hat Linux is starting to look like the final proving ground before software moves into the (more stable) Enterprise distributions.

Also note the missing ".0" from the version number. This has possibly something to do with market perception (whether it is correct or not is a different matter) that x.0 releases are generally buggy and unsuitable for deployment on servers. Whatever the meaning, this is not a new tactic for Red Hat; Red Hat Linux 7 also lacked a ".0".

The quick succession of major number releases was noted by many Red Hat Certified Engineers (RHCE). Up until now the validity of the rather pricey, but highly valued RHCE certificates was limited to two major releases. Red Hat was quick to react with a policy change: "The validity period for all RHCEs and RHCTs is now officially pegged to the release of the Enterprise product commercially available at the time certification was earned, and certification shall be current until after one (1) major release of the Enterprise product." More details are available here.

All these changes, together with the recently announced restrictions on free access to Red Hat Networks and reduction of support periods are designed with one goal in mind: to increase Red Hat's revenue. Despite some voices of criticism, one cannot blame the company. Red Hat Linux has become the dominant Linux OS on servers and there are possibly thousands of enterprises around the world that use Red Hat's products without ever paying a single cent to Red Hat. The time has come to collect the toll.

As Red Hat tightens the screws, the small and medium enterprises with limited IT budgets -- especially in the current economic climate -- are the ones that are being affected and might even re-evaluate their needs. But do they have alternatives? After all, there are so many Linux distributions, so why use Red Hat? The awful truth is that, for many customers, the alternatives are not particularly appealing. Mandrake and SuSE, despite their ranges of enterprise products, are still perceived as distributions for desktops. Slackware's total lack of interest and ability to market and provide commercial support for their otherwise excellent server product leaves it as a viable choice only for experienced Linux enthusiasts, rather than medium-skilled system administrators. The only other alternative is Debian. But for Debian to make inroads into server rooms, corporations would have to learn to live with a product made by volunteers in their spare time, without any commercial interests. And that's something that is unlikely to happen on a large scale.

Comments (16 posted)

Debian GNU/Linux

The March 25 issue of the Debian Weekly News is out; it looks at the Project Leader election, Trusted Debian, live filesystem CDs, and several other topics.

Debian Planet looks at the Debian Desktop User's Guide, a project to bring up-to-date and effective documentation to new Debian users.

In this Linux Journal article, the author installs and configures Debian's sid (unstable) on his laptop. "Debian has a reputation for being difficult to install. Although this is not necessarily true, Debian's installer is a far cry from the fully automated installers of distributions such as Mandrake and Red Hat. However, there is a benefit to your extra labor: much more control of how the system is laid out, which packages are installed and which kernel features are enabled or disabled. This gives you the freedom to have a system completely tailored to your specific needs."

Debian Planet covers MiniWoody, a modified and updated version of the Debian Woody 3.0 release in order to fit on the confines of a 180MB CD.

A new version of Debian Developer's Packages Overview has been announced. The new version fixes most of the opened bugs and provides many new features.

Comments (none posted)

Mandrake Linux

MandrakeSoft has announced the release of Mandrake Linux 9.1. There's lots of new stuff, of course, including yet another simplified graphical installer, the "MandrakeGalaxy" theme, Apache 2, and more.

The ext2/ext3 partition format in Mandrake Linux 9.1 is not compatible with older Mandrake Linux releases, so new packages are available for some older distributions so that, for example, a 9.0 system can mount a 9.1-formatted ext2 or ext3 partition.

Comments (none posted)

Red Hat Linux 9 announced

Members of the Red Hat Network have been notified that they will be able to download Red Hat Linux 9 ISOs beginning March 31, 2003. The new version should be in stores the week after that.

Comments (18 posted)

SuSE Linux Ships its First Server Product for Intel Itanium 2 Processors

SuSE Linux Enterprise Server 8 for the Intel Itanium Processor Family will be available by the end of March and has been choosen to drive parts of the scientific computing system "TeraGrid" accessible to thousands of scientists across the USA.

Full Story (comments: none)

Gentoo Weekly Newsletter -- Volume 2, Issue 12

The Gentoo Weekly Newsletter for the week of March 24, 2003 is out. Topics this week: How to become a Gentoo developer; Changes in the way Gentoo Linux supports CFLAGS; and errata from last week's issue.

Full Story (comments: none)

Desktop/LX Deluxe Garners Highly Commended Award from PCW Magazine

The Lycoris Team recieved a 'Highly Commended' award from Personal Computer World Magazine for Desktop/LX. PCW gave Desktop/LX Deluxe a four out of five star overall rating and called the operating system "easy to install, accessible and well configured."

Full Story (comments: none)

GNU-Darwin anti-war blackout continues

GNU Darwin has blacked out its home page in protest of a U.S. invasion of Iraq. Paradoxically they have experienced a surge in subscription proceeds and CDR sales.

Full Story (comments: none)

Damn Small Linux

Damn Small Linux is a business card size (50MB) Linux distribution based on Knoppix. Despite its miniscule size it strives to have a functional and easy to use desktop. The initial freshmeat announcement for version 0.1 was released March 19, 2003.

Comments (none posted)

LinuxConsole

LinuxConsole is live Linux CD that can be used to plays games, music, videos, browse the Web, disks, burn CDs and more.

Full Story (comments: none)

CRUX

CRUX has released v1.1 with minor feature enhancements. "Changes: Basic support for IPv6 was added. A kernel ptrace security patch was added. Pkgconfig and freetype2 packages were added. About 50 other packages were updated, such as XFree86 4.3, Glibc 2.3.2, GCC 3.2.2, and Mozilla 1.3."

Comments (none posted)

DeLi Linux

DeLi Linux has released v0.2 with minor bugfixes. "Changes: Kernel 2.2.25 has been added, and some bugfixes in the base package were made. There is a slightl reorganization of the base package. Some packages were upgraded, such as dillo 0.7 and GNU Ghostscript 7.05."

Comments (none posted)

KNOPPIX

KNOPPIX has released v3.2-2003-03-21 with major feature enhancements. "Changes: The Samba, Mozilla, IceWM, larswm, Kismet, Evolution, fontconfig, gnome-pilot, cpuburn, dvd+rw-tools, and OpenOffice packages were updated. KDE 3.1 was included, bugfixes were made, and some of the older games and packages were cleaned up."

Comments (none posted)

LinuxInstall.org

The LinuxInstall.org Project has released v3.0rc2. "Changes: This release features the 2.4.18-27.8.0 kernel with NTFS support, 31 security updates, Mozilla 1.3.0, Evolution 1.2.3, the complete set of Red Hat 8.0 manuals in HTML, Acrobat Reader 5.06 with a Mozilla plugin, Real Player 8.0 with a Mozilla plugin, Flash Player 6.0.79 with a Mozilla plugin, the Microsoft TrueType Core Fonts for Web, Xmms 1.2.7, Xine 0.9.19 with libdvdcss, and a dual-boot configuration with NTFS/FAT32 support."

Comments (none posted)

OpenNA Linux

OpenNA Linux has released RC2 with major feature enhancements. "Changes: This version is devoted to bugfixes, improvements, and general polish of the upcoming major 1.0 stable release."

Comments (none posted)

VectorLinux

VectorLinux has released v3.2 of its SOHO development branch with major feature enhancements. "Changes: This release updates to Vector Linux 3.2 base. There is a brand new auto installer that configures all hardware without user intervention. All applications have been updated to the latest versions including KDE-3.1, Ximian Evolution, GNUCash, OpenOffice, XMMS, Phoenix, and Opera."

Comments (none posted)

Warewulf

Warewulf has released v1.10 with minor feature enhancements. "Changes: This release adds support in dhcp-build for PXE/Etherbooting (/etc/warewulf/node.conf now takes an additional configuration item "pxeboot" to support this), support in dhcp-build for node-specific Warewulf RAMDISK boot images (the node.conf parameter is "bootimg", and it overrides the default; this is just the first stage, and it has not been documented yet), and support for SWAP monitoring. The output of "wwmon" and "wwstat" has been modified."

Comments (none posted)

Webfish Linux

Webfish Linux has released v1.0pre1 with major feature enhancements. "Changes: This release incorporates new packages such as glibc-2.2.5 and gcc-3.2.2."

Comments (none posted)

Red Hat Linux 9 - World's First Look at Shrike (OSNews)

OSNews reviews Red Hat Linux 9. "So what's different about it? Well, for starters (pun intended) the start menu is now far better arranged than the clumsy bloated mess in Red Hat Linux 8.0. It's now clearly laid out and there is even a handy 'recent documents' shortcut called 'open recent' on the menu. Nothing new to Windows users but it's nice to finally see it in Red Hat Linux. Once again, Gnome is the default DE and Bluecurve is the default theme so overall it looks remarkably similar to Red Hat Linux 8.0."

Comments (none posted)

OpenOffice.org 1.1 beta released

Version 1.1 beta of the OpenOffice office suite has been released.

Some of the more important new capabilities include:

• New import/export formats including PDF, Macromedia Flash, DocBook, XML.
• Support for Complex Text Layout and vertical languages.
• Better Java integration including big speed improvements.
• Accessibility support throughout the suite.
• Support for add-on components.
• Preliminary support for recovering damaged files.
• MySQL data source support.
• Better online help information.

This long list of changes details many other new features. OpenOffice is doing a good job of closing in on the capabilities of Microsoft Office, this release should help to make Linux a stronger desktop contender.

Comments (none posted)

ALSA 0.9.2 released

Version 0.9.2 of the ALSA driver, library and utils packages have been released. A number of bug fixes have been included.

Full Story (comments: none)

PyJack 0.1 Released

The initial release of PyJack, version 0.1, is available. "This is a Python module which provides an interface to the Jack Audio Server. It is possible to access the Jack graph to manipulate port connections, monitor graph change events, and to perform soft-realtime audio capture and playback using Numeric Python arrays."

Full Story (comments: none)

Ogg Traffic

The March 24, 2003 edition of Ogg Traffic is available with the latest Ogg Vorbis audio compression software news. Discussion topics include: Status Updates, Speex goes 1.0, Xiph.org goes 501(c)3, and New Icecast2 Binary for Win32.

Comments (none posted)

Speex 1.0 released

Version 1.0 of the Speex audio codec has been released. See the announcement for the whole story.

Comments (none posted)

omniORB 4.0.1 and omniORBpy 2.1 released

New versions of omniORB and omniOrbpy, the high performance CORBA ORB for C++ and Python, have been released. Change information is in the source code.

Comments (none posted)

MySQL 4.0.12 declared stable

Version 4.0.12 of the MySQL database is available for download. "MySQL Version 4.0.12 has been declared stable for production use in March 2003. This means that only bugfixes are done for the 4.0 release series, and only critical bugfixes for the older 3.23 series." Thanks to Bryan Henderson.

See the release announcement for more information.

Comments (none posted)

Linux in Education Report

Issue #92 of the Linux in Education Report is out. Topics include: developing educational boards for GCompris, the first Schoolforge IRC meeting, OpenStudio's progress, a web based reading game, an essay on Software Engineering with Linux, the Site@School content management system, and more.

Comments (none posted)

gerbv 0.13 released

Version 0.13 of gerbv, the Gerber file viewer has been released by the gEDA project. This is a bug fix release, see the announcement for details.

Comments (none posted)

Mozilla Minotaur Project Formally Launched (MozillaZine)

MozillaZine covers the release of Mozilla Minotaur. "In a newsgroup posting, Scott MacGregor has formally announced the launch of Minotaur, a project to create a stand-alone mail client based on the Mozilla suite's Mail & Newsgroups component."

Comments (none posted)

Foomatic 3.0.0beta2 released

Version 3.0.0beta2 of the Foomatic printer support database has been released. "This will be the last beta release before the final release of Foomatic 3.0.0 in around two weeks (at least not later than first of May). This release does not contain any major new features; it mainly fixes bugs and improves the Adobe-compliance of the generated PPD files."

Comments (none posted)

Analog 5.32 released

Version 5.32 of the Analog web server log file analyzer is available. The changes include recognition of the Safari and Camino browsers, a new logformat specification, and more.

Comments (none posted)

Quixote 0.6 beta 5 available

In the march toward version 0.6, version 0.6 beta 5 of the Quixote web application framework has been released.

Comments (none posted)

ZConfig 1.0 released

Version 1.0 of Zconfig, a Zope configuration library, is available. "ZConfig's model is very different from the model support by the ConfigParser module found in Python's standard library, and is more suitable to configuration-intensive applications."

Full Story (comments: none)

Squeezing SOAP (IBM developerWorks)

Brian D Goodman covers the use of GZIP and SOAP on IBM's developerWorks. "GZIP encoding over HTTP is pretty much old school. "Been there, done that" is the attitude of most. However, if you have been working with a few of the current SOAP implementations, you'll find that they don't take advantage of it. While knowing they will eventually come around, if you are building real world Web service solutions and want a performance boost, GZIP is for you."

Comments (none posted)

heartbeat 1.0.2 released

Version 1.0.2 of heartbeat has been released by the High-Availability Linux Project. "This release contains a number of minor bug fixes, and is compatible with Red Hat 8.0."

Full Story (comments: none)

Audacity 1.1.3 released

Version 1.1.3 of the Audacity multi-platform sound editor is available. "This version adds a gain and pan control to every track, supports high-quality resampling, and has many other new features and bug fixes." See the release notes for details.

Comments (none posted)

ecasound 2.2.2 released

Version 2.2.2 of Ecasound, a multi-track audio processing utility, has been released. "A new native Python implementation of the ECI API has been added to the package. Ecasound.el (ecasound-emacs) has been updated to version 0.8.2. Oggs and mp3s can be now streamed directly from network. Author information is now visible in the LADSPA plugin descriptions. Changes in ALSA-0.9 support improve usability of ecasound with the new ALSA dmix PCM plugin." Some important bug fixes are also included.

Full Story (comments: none)

galan-0.2.14 released

Version 0.2-14 of galan has been announced. "galan is another modular synthesizer. It supports sub patches like pd and jmax. But has separation of mesh and Controls. It also supports OpenGL Scene Graphs which can be controlled by your audio data, the sequencers etc..."

Full Story (comments: none)

Hydrogen 0.7.6 available

Version 0.7.6 of Hydrogen, a Gnu/Linux drum machine, is available.

Full Story (comments: none)

Wave Composer Not Toilet (wcnt)

A new modular audio synthesis program known by the amusing name of Wave Composer Not Toilet (wcnt), is available. "Wav Composer Not Toilet is another modular synthesis program, but unlike many others does not work in real time at all. wcnt gives you sequencing, sampling, and synthesis without the need for fast hardware, although a little patience is required!"

Full Story (comments: none)

Bonobo support for Vim (GnomeDesktop)

A developer patch of the Vim editor for bonobo has been announced. "Take a look at the project page".

Comments (none posted)

KDE 3.1.1: It's not Odd at all! ;-)

KDE.News reports on the release of KDE 3.1.1, the first maintenance release of the KDE 3.1 release series.

Comments (1 posted)

KDE-CVS-Digest for March 21, 2003

The March 21, 2003 edition of the KDE-CVS-Digest is out. "KDE 3.1.1 released, a WYSIWYG mode for Quanta, many bugfixes in KMail, KWin, Kicker and Konqueror."

Comments (none posted)

KDE Accessibility 1.0 is Here + Interview

KDE.News reports on the release of the first stable version of the KDE Accessibility module, which includes the KMagnifier, KMouseTool, and KMouth accessibility aids.

Comments (none posted)

Gnome and KDE viewpoint on the future of the X Window System (GnomeDesktop)

A group of developers from both the GNOME and KDE projects comment on the future of the X Window System. "We acknowledge the dedication of the XFree86 project in providing us a free and innovative implementation of the X11 industry standard, something we benefit from on a daily basis. Therefore, we want to share our joint point of view with the community."

Comments (9 posted)

Sawfish 1.3 Released

Version 1.3 of the Sawfish (formerly Sawmill) window manager has been announced.

New features in this version include:

• Implementation of the EMWH "show desktop" mode.
• Changes to client window gravity when reparenting windows.
• Support for the EWMH SKIP_TASKBAR' state.
• New muliple properties for window history keys.
• Multi-thread awareness for more placement modes.
• Updated language translations.
• Lots of bug fixes including GTK 2.2 compilation support.

Sawfish 1.3 is available for download here.

Comments (none posted)

GNOME-games, the future and maintainership (GnomeDesktop)

Ross Burton writes about his progress on gnome-games 2.4.0. "I have started to prune the games for gnome-games 2.4.0, the first development release 2.3.0 was just released with gnibbles, gnobots2, iagno2 and xbill removed."

Comments (none posted)

GIMP 1.3.13 Released (GnomeDesktop)

The FootNotes site has an announcement for version 1.3.13 of the development release of the GIMP, a powerful graphical manipulation program.

Comments (none posted)

wine20030318 available

Version 20030318 of Wine has been announced. Changes include direct sound improvements, support for file locking, progress on the kernel/ntdll separation, and bug fixes.

Comments (none posted)

Wine Weekly News

Issue #162 of the Wine Weekly News is out. Topics include: Wine-20030318, File Locking, .NET Success, DPRINTF to TRACE Conversion, Finding DLL Imports, and Completely Broken Test App.

Comments (1 posted)

AbiWord 1.1.4 released. (GnomeDesktop)

FootNotes has an announcement for the release of AbiWord version 1.1.4. "This version of AbiWord is basically feature complete for the final 2.0. It offers substantial new features and tons of bug fixes over 1.1.3.

Comments (none posted)

AbiWord Weekly News

Issue #136 of the AbiWord Weekly News is out, with the latest AbiWord word processor development news. "Smell that? It's the sweet sent of Wisconsin Maple Syrup and a new release cycle! The latest stable that's just come out, 1.0.5, is about to be joined by a new developers' build, 1.1.4. The Latest Releases page will be updated with information for both on the evening of 1.1.4's release (probably by 6pm CT Sunday). Large portions of the on-list discussions focus on the two releases while commits focus towards bug squashing."

Comments (none posted)

Balsa-2.0.10 and Balsa-1.4.3 released (GnomeDesktop)

Two new versions of the Balsa email client have been released. "Balsa team would like to officially announce balsa-2.0.10 and balsa-1.4.3 releases. Both releases are available at balsa.gnome.org. balsa-1.4.3 is based on GNOME1 libraries. balsa-2.0.10 is a GNOME2 port.

Comments (none posted)

Evolution 1.2.3 Released (GnomeDesktop)

GnomeDesktop reports on the release of Ximian Evolution 1.2.3. This update includes some security related bug fixes.

See the release notes for additional details.

Comments (none posted)

GNOME Ticker 0.4 released (GnomeDesktop)

Footnotes has the announcement for the initial release of GNOME Ticker, a stock market ticker application.

Comments (none posted)

Caml Weekly News

The March 25, 2003 edition of the Caml Weekly News is available with the latest Caml language news.

Full Story (comments: none)

Java Swing: Menus and Toolbars, Part 7 (O'ReillyNet)

O'Reilly is running part 7 in the series on Java Swing. "In the final part of this book excerpt series on Swing menus and toolbars from Java Swing, 2nd Edition, learn how to use toolbars."

Comments (none posted)

Taming your Tomcat: Filtering tricks for Tomcat 5 (IBM developerWorks)

Sing Li shows how to work with Tomcat 5 on IBM's developerWorks. "The new Tomcat 5 server takes filters to a new level of deployment flexibility. Tomcat 5's support for the upcoming Servlet 2.4 and JSP 2.0 specifications gives filter writers a new way to integrate and deploy these flexible components -- tapping directly into the request dispatcher's operations. In this article, Sing Li takes you on a guided tour of the new enhancement and gives you some hands-on training. See how Tomcat 5 can benefit Web application frameworks and lead ultimately to the design of maintainable high-performance systems."

Comments (none posted)

SBCL 0.7.14 released

SBCL (Steel Bank Common Lisp) version 0.7.14 is available. "This version provides a better implementation of SXHASH on simple bit vectors, no longer ignores type declarations for special variables, and fixes a number of bugs and other issues."

Full Story (comments: none)

This Week on perl5-porters (use Perl)

The March 17-23, 2003 edition of This Week on perl5-porters is out. "Read on for the short notes I've taken about all those recent developments -- pack(), FETCH()es, threads port, et al."

Comments (none posted)

PHP Weekly Summary

Topics on this week's PHP Weekly Summary include: 64 bit issues, continued, Undocumented .ini options, superglobals with Zend Engine 2, htmlentities() Cyrillic support, error docref, and ICU extension.

Comments (none posted)

Dr. Dobb's Python-URL!

The Dr. Dobb's Python-URL for March 24, 2003 is available, with weekly news and links for the Python community.

Full Story (comments: none)

Ruby-GNOME2-0.4.0 is released! (GnomeDesktop)

Version 0.4.0 of Ruby-GNOME2, the Ruby language bindings for GNOME 2 has been released. "The biggest additions includes Win32 support, support for more Gtk widgets, and the usual set of bug-fixes."

Comments (none posted)

The Ruby Weekly News

Topics on this week's Ruby Weekly News include: Ruby Tutorial v0.3, Strong advantages over Python, XML too hard (YAML opportunity?), and lots of new Ruby software.

Comments (none posted)

Dr. Dobb's Tcl-URL!

The March 24, 2003 edition of Dr. Dobb's Tcl-URL! is available with the latest Tcl/Tk development news.

Full Story (comments: none)

An XML Hero Reconsiders? (O'Reilly)

Kendall Grant Clark looks at whether XML is too difficult on O'Reilly. "In a recent weblog entry, one which has been picked up by Slashdot, Bray asks whether XML has become too hard for programmers. Faced with writing code "to process arbitrary incoming XML", Bray confesses that the experience was "irritating, time-consuming, and error-prone" -- quite an admission from someone as instrumental in the creation of XML as Bray. The point here -- before someone accuses me of hero worship -- isn't that Tim Bray is always right. He isn't. The point is that when Tim Bray starts talking about XML's problems, it makes sense for the XML development community to pay some attention."

Comments (none posted)

XMLTP/L, XMLTP Light (Linux Journal)

Linux Journal looks at XMLTP Light. "XMLTP/L, or XMLTP Light, is a lightweight RPC protocol that uses XML to encode the stream of data. XMLTP/L has been designed to do fast RPC calls over an intranet, within an enterprise. More specifically, the first purpose of XMLTP/L is to forward transactions (RPCs) to a database server. But, it also can be used to do method calls to any server that follows the common RPC technique introduced by XML-RPC and older client/server protocols."

Comments (none posted)

The Road to XHTML 2.0: MIME Types (O'Reilly)

Mark Pilgrim writes about the migration to XHMTL 2.0 on O'Reilly. "Now here's a dirty little secret: browsers aren't actually treating your XHTML as XML. Your validated, correctly DOCTYPE'd, completely standards compliant XHTML markup is being treated as if it were still HTML with a few weird slashes in places they don't belong.
Why? The answer is MIME types."

Comments (none posted)

Gnome C++ development with Gtkmm2 (DevChannel)

DevChannel has an article on the C++ wrapper libraries for the GNOME C framework. "There are many powerful tools and libraries available to take advantage of the GNU Network Object Modeling Environment(GNOME). This article will introduce the C++ wrapper libraries for the GNOME foundation's GNOME C framework. In this article, the term Gtkmm should be taken to mean the entire family of libraries that make up Gtkmm/Gnomemm."

Comments (none posted)

Space-Based Programming (O'Reilly)

Bernhard Angerer introduces space-based programming on O'Reilly. "'Space-based programming' heralds a new way of building distributed applications. The dominant methods of distributed programming are based on remote procedure calls (RPC), most notably embodied in the technologies CORBA, EJB, and COM/DCOM. Space architecture supplies a surprisingly compact model that completely replaces the RPC paradigm. Its inherent, minimalistic approach predisposes it to a wide range of applications while endowing it with the advantages of modularity, scalability, and source code economy."

Comments (none posted)

Hacker says he leaked info on Unix flaw (News.com)

News.com reports that a hacker claims to have stolen three unreleased security advisories from a corporate computer and posted them to a public mailing list. "The online vandal, who uses the monicker "Hack4Life," said Wednesday that he stole advisories detailing flaws in a common set of Unix code, the Kerberos authentication system and some implementations of encryption for Web sites. He claims to have stolen them from a firm that had been working with the Computer Emergency Response Team (CERT) Coordination Center, a clearinghouse for security information."

Comments (5 posted)

XFree86 dust-up questions X11 model (Register)

Here's the Register's take on the split in the XFree86 project. "Key Linux kernel developer Alan Cox agreed that the project needed a wake-up call, but didn't think a splinter project by Packard could cause too much harm: "X has to evolve, X has to do cool stuff, X has to let people break stuff, X has to delegate trust to driver maintainers far more," he wrote. "To me it doesn't matter if Keith and friends spin off an "Xperimental" or XFree itself changes, but that change is vital to the future of X11.""

Comments (16 posted)

Open Source in Government Conference Wrapup (NewsForge)

NewsForge covers the recent "Open Standards/Open Source for National and Local eGovernment Programs in the U.S. and EU" conference held in Washington DC last week. "One GSA (General Services Administration) representative felt that this conference's primary benefit was that it showed him he was not alone; that there was more open source being used in more places within the federal government than he had thought. Not only that, he said he learned some helpful tricks from some of the sessions and -- best of all -- hooked up with several people from other agencies whose needs are similar to his, with whom he can cooperate on several projects, thereby increasing development and deployment efficiency even more."

Comments (none posted)

Intel plans Linux support for Centrino (News.com)

News.com reports on Intel's plans to support Linux on Centrino. "Although the Linux support software for Centrino is working at Intel's labs, it hasn't been fully tested and full completion of the project hinges on the timing of requirements from computer makers, company spokesman Scott McLaughlin said Monday."

Comments (7 posted)

Lindows CEO attacks Intel's Centrino Linux lockout (Register)

The Register looks into allegations made by Lindows.com CEO Michael Robertson. "Intel is going through a major internal struggle over desktop Linux, and the pro-Microsoft marketing droids are currently winning, according to Lindows.com CEO Michael Robertson. As evidence, Robertson puts forward the lack of Linux support for Centrino, the mysterious blocking of his company's request to participate in an Intel roadshow, and the last minute pullout of Intel speakers at his Desktop Linux Summit earlier this year."

Comments (24 posted)

Red Hat slips into the red (News.com)

News.com looks at Red Hat's quarterly results and prospects for the near future. "Even though [Red Hat Linux 9] will boost Red Hat revenue, the company's attention will remain on the premium product, Chief Executive Matthew Szulik said in an interview. 'You're not going to see any aggressive promotion with it,' he said. Advertising and promotion might increase sales, but it also increases expenses 'in a business that is not that interesting to the company,' Szulik said."

Comments (2 posted)

A provincial German town drops Microsoft for Linux (Boston.com)

Boston.com looks at the German city of Schwaebisch Hall, which is switching over to Linux. "The open-source software can be freely copied by the more than 400 new Linux users employed by Schwaebisch Hall, which is encouraging them to copy the software on their work computers for home use... By year's end Schwaebisch Hall, working with Nuremberg-based SuSE and IBM Germany, will have switched all 300 desktop computers and 15 servers recording tax payments, business licenses and library checkout records." (Thanks to Ashwin N.)

Comments (none posted)

Linux lines up its best shot (vnunet)

Vnunet thinks the Linux revolution is still a long ways off. "There is no shortage of pundits who believe that Linux is taking off. IDC, Gartner, Aberdeen and the Robert Francis Group all predict a massive upsurge in the employment of Linux, at some stage soon. That said, whenever analysts agree on something, they are usually wrong."

Comments (6 posted)

Public to chime in on copyright law (News.com)

News.com reports that the Library of Congress' Copyright Office will hold a series of public hearings to decide what changes, if any, should be made to the section of the DMCA that restricts bypassing copy-protection schemes. "Anyone with strong feelings about the DMCA, one way or another, may submit a request by Apr. 1 to testify during the public forums, the Copyright Office said in its announcement. The hearing dates in the U.S. capital will be Apr. 11, Apr. 15 and May 2. The dates and locations in California have not been set yet."

Comments (none posted)

Ten Security Checks for PHP, Part 1 (O'ReillyNet)

O'ReillyNet looks into building a secure web site with PHP. "It is extremely easy to write applications that contain unintentional security holes. This is demonstrated by the range of common web applications, including PHPMyAdmin, PHPShop and FreeTrade, that have contained major security holes. The source code is often required to identify these holes, but it is common to make the source code of these applications available to the public. This article provides five steps to help identify or avoid such security holes in applications written using PHP."

Comments (none posted)

Time for Users to Start Testing 2.5 (Linux Journal)

Linux Journal looks at the 2.5 Linux kernel. "A lot of people ask me, "When do you think the 2.6 kernel will be released?" My response to that question usually is, "Well, how well is the 2.5 kernel working for you?" Inevitably, during the resulting conversation where I plead with the person to please at least run the kernel once on their hardware, they respond with one of the following reasons why they have not tried 2.5:"

Comments (15 posted)

Red Hat liberates low-end Linux (News.com)

News.com looks at the upcoming Red Hat 9 release. "The Raleigh, N.C.-based company has just completed splitting its product line in two: the slow-changing premium Red Hat Enterprise Linux version for businesses and the free Red Hat Linux version for enthusiasts. Establishing the RHEL option for conservative customers freed up Red Hat to accept more flexibility with the RHL line, said Matt Wilson, manager of Red Hat's base operating system, in an interview Tuesday."

Comments (6 posted)

Mozilla Tightens Up (eWeek)

eWeek evaluates Mozilla version 1.3. "Mozilla 1.3 also includes a demonstration of a capability, code-named Midas, that will be supported in future versions of the browser. Midas lets Web developers add rich-text editable controls to pages using standard script commands. We found this feature interesting but were not sure why it was included--there are already standards-based ways to do basically the same thing across all browsers."

Comments (none posted)

An update on RTLinux (LinuxDevices)

LinuxDevices.com delves into RTLinux. "The RTLinux dual-kernel operating system was first introduced back in 1995. Today, RTLinux is well known worldwide as a means to gain "hard real-time" performance from a Linux-based system environment. In this article, Victor Yodaiken, Michael Barabanov, and Cort Dougan -- three key figures in the creation, evolution, and maintenance of RTLinux -- summarize the state of RTLinux eight years later."

Comments (none posted)

Too cool for secure code (Register)

Jon Lasser takes programmers to task for insecure software in The Register. "It would be nice if we could expect that our programmers would act more like airline pilots than fighter pilots: that they acknowledge, and accept, the responsibility that they take for the well-being of others. Until they take this step, I doubt that the quality and security of the code that we all rely on will improve."

Comments (18 posted)

ActiveState and O'Reilly join up

ActiveState and O'Reilly have announced a deal wherein O'Reilly's "Safari Bookshelf" will be bundled with ActiveState's Programmer Network offerings.

Full Story (comments: none)

Dell and Oracle power Louisiana's state-of-the-art justice system in Baton Rouge

Dell and Oracle have announced that they will be providing Linux systems for Louisiana's Nineteenth Judicial District Court, to be used for providing real-time access to public records.

Full Story (comments: none)

Hitachi Announces Strategic Partnership with Codehost Inc. (LinuxMedNews)

Hitachi and Codehost, Inc have announced a Linux-related partnership. "The Hitachi Internet Platform Business Unit, a part of Hitachi, Ltd. (NYSE: HIT) and Linux software developer Codehost, Inc. today announced a software development agreement for wireless tablets running the Linux operating system."

Comments (none posted)

Record number of students in IBM's Second Linux Scholar Challenge

The Indian Institute of Technology (IIT) in Delhi, India has been named the top winner of IBM's Second Linux Scholar Challenge. The university has been awarded a 16-node IBM eServer(tm) xSeries(tm) cluster running Linux. IIT received the highest overall average score among student winners from the 646 universities that enrolled in the challenge.

Full Story (comments: none)

JBoss Group distributes profits to developers

The JBoss Group has sent out a press release stating that it has distributed some of its profits to 37 developers who have contributed code to JBoss. "The Compensation Plan is our way of rewarding the open source JBoss developers, whether or not they work for JBoss Group, giving them a stake in the company's future, as well as offering them cash awards based on annual profit-sharing".

Comments (none posted)

MySQL Version 4.0 Dubbed ''Production''; MySQL AB Confirms Version 4.0.12 Ready for all Application Areas

MySQL AB has sent out a press release stating that MySQL 4.0.12 is "ready for any MySQL deployment." "Even though proven development releases of 4.0 have been out for well over a year, we know that many MySQL users have been waiting for it to go production before upgrading. Now that it's been thoroughly tested by thousands of users, with no major bugs having been found in many months, we are confident that version 4.0 can be used reliably in any MySQL implementation..."

Comments (none posted)

Red Hat Linux hard at work

Here are two press releases showing wins for Red Hat. The first is from RackSaver, which has provided a BladeRack system to the Mars Space Flight Facility at Arizona State University. The Mars Space Flight Facility's new BladeRack is a 50-node, dual AMD 2000+ processor-powered system, running Red Hat Linux Version 7.3.

Dell and Oracle announced the delivery of integrated solutions to Louisiana's Nineteenth Judicial District Court. These Dell servers run Oracle9i Database with Real Application Clusters and Oracle9i Application Server on Red Hat Linux Advanced Server.

Comments (7 posted)

Red Hat's fourth-quarter results

Red Hat, Inc. has announced its fourth-quarter results. The bottom line is that the company essentially broke even on $25.9 million in revenue. The release also notes that Red Hat has now sold 16,500 "Red Hat Enterprise Linux AS" subscriptions, and shipped 5,000 copies of the new enterprise workstation product.

Comments (3 posted)

Linux gives your phone a voice!

Looking for a new phone? Zultys Technologies announced immediate availability of its ZIP 4x4 IP phone. "The ZIP 4x4 is built 100 percent on open technologies and runs on a highly stable real time Linux operating system. It is compatible with any IP telephony system using SIP (Session Initiation Protocol), with support for advanced features such as line-rate Ethernet switching, voice encryption, and five-way conferencing."

Full Story (comments: 1)

Wing IDE 1.1.9 Released (ZopeMembers)

Zope Members News has an announcement for version 1.1.9 of the Wing IDE for Python. "Wing IDE is a commercial development environment for the Python programming language. Wing's powerful editor, source browser, and graphical debugger speed Zope-based software development."

Comments (none posted)

The UK Python Conference 2003

The UK Python Conference 2003 will be held in Oxford, England on April 2 and 3, 2003. Guido van Rossum will deliver the keynote speech.

Full Story (comments: none)

Tcl/Tk Conference CFP

A Call For Papers has gone out for the 10th annual Tcl/Tk conference. The event will be held from July 29 to Aug 2, 2003, papers are due in by May 15.

Full Story (comments: none)

Linux in Education Spring Conference

The Linux in Education Spring Conference will be held on April 5, 2003 in Grand Prairie, Texas.

Comments (none posted)

Minutes of the mozilla.org Staff Meeting (MozillaZine)

MozillaZine has posted the minutes of the March 19, 2003 mozilla.org staff meeting.

Comments (none posted)

O'Reilly Open Source Convention registration opens

Registration has started for the O'Reilly Open Source Convention, which will be happening July 7 to 11 in Portland, Oregon.

Full Story (comments: none)

Mark-Jason Dominus coming to Washington, DC Perl M (use Perl)

Use Perl mentions that Mark-Jason Dominus will give a talk at the American Geophysical Union in Washington, D.C. on April 8.

Comments (none posted)

Zope3 UK Sprint (ZopeMembers)

The Zope 3 Sprint has been announced. The event will take place at the University of Bristol, England from April 12-15, 2003.

Comments (none posted)

Events: March 27 - May 22, 2003

Date	Event	Location
March 27 - 28, 2003	PyCon DC 2003	(George Washington University)Washington DC
March 29, 2003	First Hungarian PHP Conference	Budapest, Hungary
March 31 - April 2, 2003	2nd USENIX Conference on File and Storage Technologies(FAST '03)	(Cathedral Hill Hotel)San Francisco, CA
April 2 - 3, 2003	The UK Python Conference	(Holiday Inn Oxford)Oxford, England
April 5, 2003	Linux In Education Spring Conference	(Grand Prairie High School)Grand Prairie, Texas
April 10 - 12, 2003	MySQL Users Conference & Expo 2003	(Doubletree Hotel)San Jose, California
April 13 - 17, 2003	RSA Conference 2003	(Moscone Center)San Francisco, CA
April 14 - 15, 2003	Samba eXPerience 2003	(Hotel Freizeit)Göttingen, Germany
April 15 - 16, 2003	LinuxUser & Developer Expo 2003	Birmingham, UK
April 22 - 26, 2003	Embedded Systems Conference(ESC)	(Moscone Convention Center)San Francisco, CA
April 22 - 25, 2003	The O'Reilly Emerging Technology Conference	(Westin, Santa Clara)Santa Clara, CA
April 23 - 25, 2003	PHPCon East 2003	(Park Central Hotel)New York, NY
April 28 - 30, 2003	Real World Linux 2003	(Metro Toronto Convention Centre)Toronto, Canada
May 3, 2003	International Conference on Software Engineering 2003	Portland, Oregon
May 8 - 9, 2003	International PHP Conference, 2003	Amsterdam, the Netherlands
May 11 - 14, 2003	The International Symposium on High Performance Computing Systems and Applications(HPCS 2003)	(Sherbrooke Delta Hotel)Quebec, Canada
May 11, 2003	Yet Another Perl Conference, Israel(YAPC::Israel::2003)	(C.R.I.)Haifa, Israel
May 15 - 16, 2003	YAPC::Canada	(Carleton University)Ottawa, Canada

Comments (none posted)

This week's software announcements

Here are the software announcements, courtesy of Freshmeat.net. They are available in two formats:

• Sorted alphabetically,
• Sorted by license.

Comments (none posted)

XFree86 needs a Fork

From:		anandsr@hss.hns.com
To:		letters@lwn.net
Subject:		XFree86 needs a Fork
Date:		Sat, 22 Mar 2003 12:17:28 +0530

 
 
Hi,
 
I don't know anything about the development of XF86. But after reading just
a little bit of material I can realize that that is what is required. I am
surprised that nobody did it for so long. Kudos to Keith Packard for taking
the plunge, I hope he succeeds in revitalizing X, under whatever name he
brings it out.
 
I think you don't need any more reasons for a fork than Mike Harris's diary,
http://www.advogato.org/person/mharris/diary.html?start=5
 
In the Open Source World a project is only successful if it can attract a
large no. of developers. The larger the pool of developers the larger the
project. It doesn't matter how many users you have, because they do not
contribute. If they did they would be developers. Xfree86 has a meagre 250
developers, and only 14 are allowed to make a change after reviewing.
This is pathetically low for a project of XF86 size. This can only mean two
things, you don't even need to know anything else for this conclusion.
 
1) Current Development model of XF86 sucks and it sucks really really hard.
2) Current Developers aren't accepting outside help. They either think they
are the best and nobody can do a better job than themselves, or they think
that allowing other people in will reduce their importance. The first shows
a psychological problem the other is a measure of incompetence.
 
If 2) wasn't true 1) would have been solved. So there is a distinct necessity
of creating a fork.
 
The best thing about Open Source Projects is that if the current developers
are not doing justice to a project then you have the option to fork.
 
I hope Keith will be able to pool in a large no. of developers and hopefully
they will be able to move ahead of current XF86 within a short time.
 
I also desperately need a properly working driver for my i830M chipset, which
is not working even after almost 2 years of updates.
 
thanks,
-anandsr
 

Comments (3 posted)

Alternatives to Red Hat Update

From:		Alex Hornby <alex@hornby.org.uk>
To:		letters@lwn.net
Subject:		Alternatives to Red Hat Update
Date:		26 Mar 2003 11:09:16 +0000

Hi,
 
With the recent changes to red hat's update and support policy it may be
useful to draw readers attention to alternative methods of auto applying
updates to red hat systems.
 
Many people will already be familiar with Ximian's Red Carpet tool.
However, whilst this is free to use as a client, to publish software via
this mechanism one needs an agreement with Ximian.
 
One alternative which hasn't recieved as much attention is apt for rpm,
which I obtained from http://freshrpms.net/apt/ . This provides debian
style auto updates for red hat users. In addition to the command line
there is a gtk 2 GUI for apt called Synaptic available on the same site
which provides an alternative to red-carpet or the up2date tool.
 
The main advantages of apt for rpm I have found are:
 
* Free as in beer _and_ free of hassle. No registrations required.
 
* Open backend - anyone can put up an apt repository. This has two main
benefits:
 
* I've successfully done kernel upgrades using apt - something
red-carpet seems to baulk at.
 
* Software developers can set up their own apt site. For an example of
this in action see: http://gstreamer.net/releases/redhat/ . This is not
the case for people wishing to distribute by Red Hat up2date or Ximian
red-carpet.
 
* Not dependant on the fate of any one commercial entity. (e.g. what
happens to the red-carpet backend if Ximian goes under or has a change
of corporate policy)
 
The only disadvantage I can see is that apt4rpm and synaptic are not
installed by default by Red Hat (a problem they share with red-carpet).
 
Regards,
Alex Hornby.
 
PS Whilst on the subject of updates, I've found that rpm 4.1.1 from
ftp://ftp.rpm.org/pub/rpm/test-4.1.1 seems to cure the "rpm locks up"
problem I and others have been having with RedHat 8.0
 
--
Alex Hornby | See http://www.hornby.org.uk/

Comments (5 posted)

Why aren't we calling SCO names?

From:		"Arthur Torrey (no spam please!)" <atorrey@cybercom.net>
To:		letters@lwn.net
Subject:		Why aren't we calling SCO names?
Date:		Thu, 20 Mar 2003 22:27:56 -0500

  As a mild side note on the SCO lawsuit, I'm surprised that nobody seems to
have started calling SCO funny names the way folks do MicroShaft... My
girlfriend is a principle software engineer who has been in the business for
over 20 years. One of her first jobs involved doing development on SCO boxes,
and she said they were commonly reffered to back then as "Spoiled Child
Operations" - In light of the current events, the name seems due for a
revival...
 
  ART

Comments (2 posted)