|
|
Subscribe / Log in / New account

LWN.net Weekly Edition for April 3, 2003

The spread of "super-DMCA" bills

Much attention has been paid to copyright legislation at the U.S. Federal level. There is less awareness, however, of what is going on in state legislatures. In fact, something is going on: numerous states are considering (or have already passed) "super-DMCA" legislation based on a model law that is, according to Ed Felten, being circulated by the MPAA. This law has some unpleasant implications which are worth looking at.

Take, for example, the proposed law for LWN's home state of Colorado. The bill looks like a fairly mundane effort to (further) criminalize acts like the theft of cellular phone service. But, one of the acts criminalized is:

...to conceal or to assist another to conceal from any communication service provider, or from any lawful authority, the existence or place of origin or destination of any communication that utilizes a communication device;

Those who believe in freedom in general should certainly balk at a law which requires all communications to happen in the open. But this law also criminalizes many routine acts carried out by users of Linux systems (and computers in general):

  • Sending email over an encrypted connection.

  • Use of IP masquerading or network address translation. The DSL modems handed out by Colorado's alleged "communication service provider" would be illegal under this law. It would be interesting to ponder, actually, whether Qwest is guilty of "assisting another" to hide communication endpoints from itself.

  • Just about any sort of virtual private network technology would infringe the law. SSH tunneling, too, would be illegal.

And so on; the above list does not go near services like anonymous remailers or Freenet. It's a poor law, and deserves to be rejected. The Colorado version has already passed the state House, but the final debate in the Senate has been pushed back to April 7 as a result of expressions of concern from Colorado residents. You Colorado folks out there may want to add your voice; this page has the information you'll need. Residents of other states may want to have a look at Ed Felten's super-DMCA page to see the status of legislation in your state.

One might well ask what the MPAA's interest is in this law. It seems unlikely that Jack Valenti would be all that seriously disturbed by the theft of cellular telephone service. The most likely answer would seem to be in the MPAA's desire to crack down on peer-to-peer file sharing services. It is hard, after all, to shut down "pirates" if you cannot even find them. Rather than face the problem and come up with a better business model, the MPAA would rather just require us to carry out all our communications in the open. We should not allow them to do that.

Comments (15 posted)

A discussion with Keith Packard

The XFree86 project is important enough that the current discussions over how the project should be governed deserve continued attention. To that end, we had a conversation with Keith Packard, who was recently removed from the XFree86 core team as a result of his efforts to bring about a change in the project. Without further ado...

LWN: Could you describe the role you have played in XFree86 until now?

Since joining XFree86 a bit over three years ago, I've been working hard to rebuild X as a window system capable of supporting modern applications. Designed in 1987, X11 hasn't seen any significant architectural work in well over a decade, and it really shows.

Dirk Hohndel (while we were both at SuSE) encouraged me to build an extension that could expose the capabilities in modern graphics hardware to 2D applications, most notably anti-aliased graphics and image compositing. The Render extension is the result of that work.

This work was not done in a vacuum. Help from many people was critical in the design and implementation of all parts of the extension and supporting libraries. I've become deeply involved in KDE, Gnome, Mozilla and many other minor X projects. I've also been fortunate to have the assistance of people from the OpenGL community, the application community and one of the leading experts in computational geometry: Lyle Ramshaw.

LWN: Your "call for open governance" points out a few problems you see with the status quo. The first is "limited development resources" - XFree86 has a relatively small developer base for a project of its size. Why do you think that is, and what would you like to see done to change it?

Part of it is undeniably the steep learning curve for working within the X codebase; the project currently consists of more than 17 million lines of code, and a lot of the documentation necessary for writing device drivers is not available.

However, we cannot ignore the historical closed nature of XFree86 as another influence. Until I started at XFree86, the developer mailing lists and even the development version of the release in CVS was open only to people granted membership within the project, and such membership was granted only after demonstrating an ability to work with the code.

A certain amount of this was originally forced upon the project by the X.org contracts, but after the great licensing fiasco around X11R6, that reason disappeared and yet XFree86 remained a members-only project.

I pushed for changes in this policy, the result was a public CVS and some public mailing lists that I managed for quite some time. The old members-only developer mailing list remained, ostensibly for the purpose of discussions concerning non-public material, but in reality it was difficult to wean the existing members from a list not carrying traffic from new developers.

Another hurdle for new developers is the lack of any technical road-map for the project; releases are scheduled with no idea of what they will contain or even what people are working on. A new developer interested in helping out faces a difficult task in locating other developers even before attempting to learn the internals of the code. I attempted to suggest mechanisms to address this issue and was met with stiff opposition within the core team.

LWN: You cite slow release schedules; how is the XFree86 release schedule determined now? What would you change to speed it up?

The XFree86 release schedule is entirely determined by the availability of the release manager. Because XFree86 is released monolithically, minor driver updates like support for new versions of existing chips wait for the next release rather than being made available separately.

I would like to see each library, driver and application released individually. X has a history of strong interface specifications and this should be leveraged in the release process. Much like Gnome or KDE is done today, occasional packaged releases could be done that look much like the current releases but which would be built by collecting releases of the individual packages together rather than attempting a unified release process.

Separating the release schedule of each module would make frequent updates possible where necessary while not burdening the downstream maintainers with huge volumes of complete X releases; areas of rapid progress would see rapid releases while stable code could be released more slowly.

Possibly even more importantly, splitting the release into modules would permit each module to be separately maintained and replaced; the project would be able to effectively leverage many more people in the management of changes. Many other projects do this today to allow scaling beyond the ability of a single individual to incorporate changes into the project.

LWN: There are some interesting parallels with the kernel project, which also must manage large numbers of independent modules to provide support for the latest hardware and such. Splitting the kernel into multiple distributions is often suggested, but the idea never gets that far. The fear is that splitting the pieces apart will make it harder to keep the whole thing in sync, especially when APIs change. I take it you don't think that would be a problem with XFree86?

There are several interfaces within the current X architecture:
  • Protocol interfaces. These should be treated in much the same way as kernel/glibc interfaces where extrememly strong compatibility requirements ensure cross version interoperabilty.

  • Library interfaces. These are the same as the application/library interfaces present today and require the same level of interoperability as glibc versions do.

  • Driver interfaces. Because XFree86 encourages binary-only graphics card drivers, it should support that with strong binary compatibility guarantees. These are possible given the module loading mechanism in place, but are essentially untested by the development community as the whole system is built monolithically.

The only new interoperability requirement here is that the driver interface provide cross version compatibility, and this is already required to support binary graphics card drivers. Having it a regular part of the X environment will ensure that the interface is tested by all developers instead of only those few who produce the binary drivers.

LWN: Lack of cooperation: did GNOME and KDE approach XFree86 in search of cooperative development opportunities? How do you think XFree86 should work with the developer communities for X client projects?

I don't believe either KDE or Gnome have approached the XFree86 project as collective units, but individual developers from each project have interacted with XFree86 developers. One significant failing in X management today is the area of standardization. XFree86 plays little or no role in the maintenance of standards supported by the code, instead that role is left to the moribund X.org group. For KDE and Gnome, the result has been no progress in interoperability standards, most notably the inter-client communications conventions which form the basis for cooperation among applications, window managers and session managers.

KDE and Gnome ended up starting a new organization (freedesktop.org) to extend published X standards. Clearly, the responsibility for maintaining and extending that standard should lie within some X project, but the lack of a standards process within XFree86 has caused developers to take their ideas elsewhere.

X design must be done in a public venue with input from the projects layered on top. The current driver architecture within the server is a model of efficiency and performance when executing X protocol as presented by the x11perf benchmark. However, real applications take little advantage of that code as the X drawing model fits very poorly into modern graphical applications. X architecture should follow from application requirements, rather than benchmark racing.

One obvious first step is for X developers to start using modern applications; many key X developers wear the badge of 'twm' or 'fvwm' with pride. I switched to a mixture of KDE and Gnome desktops several years ago so that problems with those environments would be immediately evident as I changed code underneath them.

LWN: Opacity of the development process: is there anything there that a little documentation wouldn't solve? Is it matter of finding somebody to do that work, or is there a deeper problem which must be overcome.

Documentation about active projects and developers would help new contributors locate appropriate groups; splitting into many separate projects would limit the size of the codebase in which individual contributions could be made and publication of release schedules along with intended content would all help make the development process less opaque. Perhaps the most important thing of all would be an active participation by the key developers in conferences, mailing lists and IRC channels to make their contributions more visible and understandable.

LWN: There has been a lot of third-hand talk of what you were trying to do before the situation blew up, but not much from you personally. What were you trying to accomplish prior to your removal from the core team? Why do you think they responded in the way they did?

Over the last year or so, I have become convinced that XFree86 is headed for a success disaster -- widespread adoption of Linux on the desktop will cause a catastrophe for X development given the current lack of resources and inability to scale the project beyond its current bounds.

An urgent need to open up development and invite in new contributors while changing processes to make the existing contributors more effective seemed critical. I believed then that fixing the processes would avoid the impending disaster. However, my attempts to work within the existing structure have proven less than effective.

As I've attempted to open up the development process and prepare for a significant increase in Linux desktop deployments, I've run afoul of the current XFree86 leadership. My ability to contribute to the project was severely curtailed in stages, first administration of the public server, next permission to represent XFree86 to other groups, then administration of the public mailing lists, and finally CVS access.

I don't blame the current leadership for this problem; there are no guidelines or processes in place to deal with conflict in the development community. As the project has grown, it has failed to adapt to that growth by building formal structures necessary to govern a large and diverse group of people.

However, with my ability to effectively contribute severely restricted, I was forced to consider how to resolve the problems I faced. I discussed my dilemma both with members of the XFree86 core team and outside interests. I first learned that I was not alone in my views on XFree86 leadership; several prominent voices in the wider X community agreed with my assessment and encouraged me to find solutions.

The conclusions from this process were clear -- effective cooperation within the development community would require a government sanctioned by that community to run the X project as there was no other way to restore trust between the community and the leaders. The XFree86 by-laws provided no mechanism to force such a change on the project, and I was not sanguine that the XFree86 leaders would accept such change willingly, and hence I was forced to consider alternatives, even as I worked to find resolutions within the project.

Upon learning of my discussions, the XFree86 leaders were angry that I could privately disagree with their leadership while publicly supporting the project itself. The result was that I was summarily removed from the core team and subjected to censure on public mailing lists and web sites.

LWN: Is it your intent to create a fork of the XFree86 code base?

My goal is to promote development of the X window system. Right now, I don't believe it is possible for me to effectively do this within the structure of the XFree86 project. I have asked that they seriously consider changes that I feel necessary to restore public confidence in the project leadership and provide an environment where people can work together on the technical challenges facing the window system even if their individual goals are not identical.

LWN: Do you see any signs that XFree86 may be moving toward a more open system? Or does the status quo look likely to remain for some time?

The XFree86 leaders have only publicly discussed minor procedural changes which don't address the fundamental questions of authority, trust and governance. I hope they seriously consider these underlying issues instead of making only superficial changes in the project.

I held a conference call last Thursday with representatives from many projects and representatives from the XFree86 core team to discuss these issues. I'll be publishing detailed minutes of that call soon, pending agreement from the participants. The messages from that call have been taken to the XFree86 leaders and I expect to hear back from them shortly.

LWN: In your opinion, what should be XFree86's highest development priorities?

The highest priority should be to create an environment where people are encouraged to participate to whatever extent they are able, and where these contributors feel ownership of their code and pride in the community in which they work.

Actual projects should, as always, be directed by the contributors themselves. Personally, I will be working on ensuring that X applications have the support they need within the window system to provide the best user experience possible, and that the window system is a good citizen in the overall Linux environment.

Comments (13 posted)

Page editor: Jonathan Corbet

Security

Brief items

I expect you to boot Linux, Mr. Bond

The posting on the xbox-saves site came out of the blue: a previously unknown person going by the name "habibi xbox" had figured out how to boot Linux on an unmodified Xbox game console. The scheme takes advantage of the fact that the game "007: Agent Under Fire" has a buffer overrun in its game restore code. All the evil agent from S.P.E.C.T.R.E. need do is dress up a malicious save file in suitably attractive attire, and 007 finds himself overrun by a hostile Linux bootloader. Not only is Mr. Bond unable to prevent World Domination this time around; he actually becomes an agent for the other side.

The Xbox, of course, is Microsoft's entry into the game console market. The hardware is very PC-like, but it is designed to not run software which has not been signed by the requisite private key. This feature gives Microsoft the power to say what can run on its hardware - and to extract a toll from anybody wishing to sell games for the Xbox platform. Not too many people have been surprised by the fact that Microsoft has not expressed great interest in signing a Linux bootloader to enable Linux to run on the Xbox.

Xbox linux has been possible for some time, as long as you're willing to open up the box and solder in a new chip. That works for hardcore hackers, but Aunt Tillie tends to balk at such things. The 007 exploit, while not requiring that the box be opened, is still not the most straightforward operation to carry out. But it is a step in the right direction.

The real significance of this exploit, however, is in what it says about trusted computing platforms in general. The hardware has been designed to run nothing but "trusted" software, but what happens when that software is subverted? At that point, the only thing to be done is to try to contain the damage. As long as the software remains insecure, the hardware will fall short of its "trusted" pretentions.

Consider that the software for a game console is a product with a short shelf life. Games have to make the bulk of their money over a period of a few months. So one cannot count on these games going through an extended security audit prior to being signed and distributed. Platforms like the Xbox are guaranteed to be running buggy software for the forseeable future.

Comments (2 posted)

New vulnerabilities

Ecartis/listar allows unathorized password change

Package(s):ecartis, listar CVE #(s):CAN-2003-0162
Created:March 27, 2003 Updated:April 2, 2003
Description: A problem has been discovered in ecartis, a mailing list manager, formerly known as listar. This vulnerability enables an attacker to reset the password of any user defined on the list server, including the list admins.
Alerts:
Debian DSA-271-1 ecartis 2003-03-27

Comments (none posted)

sendmail - buffer overrun

Package(s):sendmail CVE #(s):CAN-2003-0161
Created:March 31, 2003 Updated:April 30, 2003
Description: There is yet another buffer overrun in sendmail; this one was discovered by Michal Zalewski. From the CERT Advisory: "There is a vulnerability in sendmail that can be exploited to cause a denial-of-service condition and could allow a remote attacker to execute arbitrary code with the privileges of the sendmail daemon, typically root." Sendmail 8.12.9 was released with a fix for the problem.
Alerts:
Conectiva CLA-2003:614 sendmail 2003-04-04
Debian DSA-290-1 sendmail-wide 2003-04-17
Yellow Dog YDU-20030409-1 sendmail 2003-04-09
Conectiva CLA-2003:614 sendmail 2003-04-04
Debian DSA-278-2 sendmail 2003-04-04
Debian DSA-278-1 sendmail 2003-04-04
SCO Group CSSA-2003-016.0 sendmail 2003-04-03
Immunix IMNX-2003-7+-002-01 sendmail 2003-03-31
Mandrake MDKSA-2003:042 sendmail 2003-04-01
SuSE SuSE-SA:2003:023 sendmail, 2003-04-01
Red Hat RHSA-2003:120-01 sendmail 2003-03-31
Gentoo 200303-27 sendmail 2003-03-31
Slackware sl-1049038109 sendmail 2003-03-30
OpenPKG OpenPKG-SA-2003.027 sendmail 2003-03-30

Comments (none posted)

vsftpd: re-enable tcp_wrappers support

Package(s):vsftpd tcp_wrappers CVE #(s):CAN-2003-0135
Created:April 1, 2003 Updated:April 2, 2003
Description: In Red Hat Linux 9, the vsftpd FTP daemon switched from being run by xinetd to being run as a standalone service. In doing so, it was accidentally not compiled against tcp_wrappers.

Users of vsftpd who make use of tcp_wrappers features are advised to upgrade to these errata packages.

This issue only affects Red Hat Linux 9 boxed sets manufactured for distribution within the United States. The part numbers, which can be found on the bottom flap of the box, are RHF0120US and RHF0121US. Copies of Red Hat Linux 9 obtained through other means (such as from Red Hat Network, FTP, or international boxed sets) already contain the packages referenced by this erratum, and are not vulnerable to this issue.

Alerts:
Red Hat RHSA-2003:084-01 vsftpd 2003-04-01

Comments (none posted)

Resources

Linux Advisory Watch

The March 28 Linux Advisory Watch newsletter from LinuxSecurity.com is available.

Full Story (comments: none)

Page editor: Jonathan Corbet

Kernel development

Brief items

Kernel release status

The current development kernel is 2.5.66; there have been no development kernel releases since March 24.

Linus's BitKeeper repository is full of patches, however, including some loadable module tweaks, some softirq handling changes (fixing a bug where bottom halves could be run when interrupts are disabled), an improved scsi_debug module, a number of PCMCIA/Cardbus improvements, a new initcall_debug boot parameter for tracking down early boot crashes, an ACPI update, an NFS update, some IDE changes, an XFS update, a big x86-64 update, and numerous other cleanups and fixes.

The current stable kernel is 2.4.20; the last 2.4.21 prepatch was 2.4.21-pre6, released on March 26.

Comments (none posted)

Kernel development news

The USB Gadget driver framework

David Brownell has sent out an announcement regarding the availability of the new USB "gadget" API. The Linux kernel has long had support for USB host controllers - the subsystem which lets the kernel drive attached USB devices. But what if Linux is running inside the device itself? Implementing the USB protocol is a very different job when you're approaching it from the other end of the bus, and the current in-kernel USB implementation will not be particularly helpful.

Thus this announcement. The chosen terminology calls attached devices "gadgets," which need a gadget driver to make them work. (The USB standard, instead, calls gadgets "devices," but reusing the term "device driver" in this context would lead only to confusion). The new gadget implementation supports the NetChip 2280 controller, and comes with a couple of drivers: "gadget zero" (a skeleton example driver) and a network driver. There's also a dummy controller driver, allowing gadget development to be done in the absence of real hardware (and, perhaps, on a more friendly development platform).

The project has reached the point where it needs to get more people involved writing drivers. The substrate is there, so a lot of the hard decisions have been made, but the actual implementation for various hardware controllers and gadget classes is missing. This could be a fun area of development for people who would like to get into kernel programming.

Comments (6 posted)

A new set of IDE changes

Bartlomiej Zolnierkiewicz did a fair amount of IDE work during the Martin Dalecki period last year. He has been more quiet in recent times, however, leaving the current IDE cleanup effort to others. This week marked an end to that silence, however, as Bartlomiej surfaced with a significant set of IDE patches.

The first part, based on work originally by Suparna Bhattacharya, changes the way the block layer BIO structure and request structure work together. The BIO structure contains the pointers needed to keep track of which I/O transfers have been completed, and which have not. What is lacking, however, is any way of tracking which operations have been commenced. That tracking has traditionally been the driver's job.

The new "BIO traversal" patches change things by adding a new set of pointers which mark where the next I/O operation should begin. A new support function (with the unwieldy name process_that_request_first()) gives drivers a way to indicate that processing has begun on part of the request. Overall, it could be a useful infrastructure for drivers with relatively complicated request processing.

The real change, however, is a new set of IDE programmed I/O (PIO) handlers. One wouldn't think that PIO matters much, given that DMA operations are available. But, in fact, quite a few IDE drives still don't handle DMA well, and the Linux kernel tends to be very conservative about enabling DMA. Unless you've taken steps to change things, chances are that your IDE-based Linux system is running with programmed I/O. So the quality of the PIO handlers matters.

Bartlomiej's new PIO code simplifies (and clarifies) things considerably. It also uses the ATA taskfile mode of operation. The taskfile code has been broken for some time, with the result that it is disabled in 2.5 and was going to stay that way through the 2.6 release. After seeing the new PIO handlers, however, Alan Cox has changed his strategy: "Looks like the revised plan is 'pure taskfile for 2.6 care of Bartlomiej'".

IDE patches (after last year's IDE regime change) are treated with great care; they don't even make it into development kernels until the confidence level is quite high. So Bartlomiej's changes probably won't appear in the 2.5 mainstream for a little while yet. They should eventually get there, however, and the result will be an improved IDE subsystem for 2.6. (The full set of patches can be found in the "Patches and Updates" section, below.)

Comments (4 posted)

Driver porting

The end of the block layer series

The driver porting series this week features two articles on the management of request queues and structures. Those of you who are uninterested in the Linux block layer will be glad to know that these articles finish out the series on writing block drivers. We'll move on to some other, as yet undetermined, subject next week.

Comments (none posted)

Driver porting: Request Queues I

This article is part of the LWN Porting Drivers to 2.5 series.
The simple block driver example earlier in this series showed how to write the simplest possible request function. Most block drivers, however, will need greater control over how requests are built and processed. This article will get into the details of how request queues work, with an emphasis on what every driver writer needs to know to process requests. A second article looks at some of the more advanced features of request queues in 2.6.

Request queues

Request queues are represented by a pointer to struct request_queue or to the typedef request_queue_t, defined in <linux/blkdev.h>. One request queue can be shared across multiple physical drives, but the normal usage is to create a separate queue for each drive. Request queues must be allocated and initialized by the block subsystem; this allocation (and initialization) is done by:

    request_queue_t *blk_init_queue(request_fn_proc *request_fn,
				    spinlock_t *lock);

Here request_fn is the driver's function which will process requests, and lock is a spinlock which controls access to the queue. The return value is a pointer to the newly-allocated request queue if the initialization succeeded, or NULL otherwise. Since setting up a request queue requires memory allocation, failure is possible. A couple of other changes from 2.4 should be noted: a spinlock must be provided to control access to the queue (io_request_lock is no more), and there is no per-major "default" queue provided in 2.6.

When a driver is done with a request queue, it should pass it back to the system with:

    void blk_cleanup_queue(request_queue_t *q);

Note that neither of these functions is normally called if a "make request" function is being used (make request functions are covered in part II).

Basic request processing

The request function prototype has not changed from 2.4; it gets the request queue as its only parameter. The queue lock will be held when the request function is called.

All request handlers, from the simplest to the most complicated, will find the next request to process with:

    struct request *elv_next_request(request_queue_t *q);

The return value is the next request that should be processed, or NULL if the queue is empty. If you look through the kernel source, you will find references to blk_queue_empty() (or elv_queue_empty()), which tests the state of the queue. Use of this function in drivers is best avoided, however. In the future, it could be that a non-empty queue still has no requests that are ready to be processed.

In 2.4 and prior kernels, a block request contained one or more buffer heads with sectors to be transferred. In 2.6, a request contains a list of BIO structures instead. This list can be accessed via the bio member of the request structure, but the recommended way of iterating through a request's BIOs is instead:

    struct bio *bio;

    rq_for_each_bio(bio, req) {
        /* Process this BIO */
    }

Drivers which use this macro are less likely to break in the future. Do note, however, that many drivers will never need to iterate through the list of BIOs in this way; for DMA transfers, use bio_rq_map_sg() (described below) instead.

As your driver performs the transfers described by the BIO structures, it will need to update the kernel on its progress. Note that drivers should not call bio_endio() as transfers complete; the block layer will take care of that. Instead, the driver should call end_that_request_first(), which has a different prototype in 2.6:

    int end_that_request_first(struct request *req, int uptodate, 
			       int nsectors);

Here, req is the request being handled, uptodate is nonzero unless an error has occurred, and nsectors is the number of sectors which were transferred. This function will clean up as many BIO structures as are covered by the given number of sectors, and return nonzero if any BIOs remain to be transferred.

When the request is complete (end_that_request_first() returns zero), the driver should clean up the request. The cleanup task involves removing the request from the queue, then passing it to end_that_request_last(), which is unchanged from 2.4. Note that the queue lock must be held when calling both of these functions:

    void blkdev_dequeue_request(struct request *req);
    void end_that_request_last(struct request *req);

Note that the driver can dequeue the request at any time (as long as it keeps track of it, of course). Drivers which keep multiple requests in flight will need to dequeue each request as it is passed to the drive.

If your device does not have predictable timing behavior, your driver should contribute its timing information to the system's entropy pool. That is done with:

    void add_disk_randomness(struct gendisk *disk);

BIO walking

The "BIO walking" patch was added in 2.5.70. This patch adds some request queue fields and a new function to help complicated drivers keep track of where they are in a given request. Drivers using BIO walking will not use rq_for_each_bio(); instead, they rely upon the fact that the cbio field of the request structure refers to the current, unprocessed BIO, nr_cbio_segments tells how many segments remain to be processed in that BIO, and nr_cbio_sectors tells how many sectors are yet to be transferred. The macro:

    int blk_rq_idx(struct request *req)

returns the index of the next segment to process. If you need to access the current segment buffer directly (for programmed I/O, say), you may use:

    char *rq_map_buffer(struct request *req, unsigned long *flags);
    void rq_unmap_buffer(char *buffer, unsigned long flags);

These functions potentially deal with atomic kmaps, so the usual constraints apply: no sleeping while the mapping is in effect, and buffers must be mapped and unmapped in the same function.

When beginning I/O on a set of blocks from the request, your driver can update the current pointers with:

    int process_that_request_first(struct request *req, 
                                   unsigned int nr_sectors);

This function will update the various cbio values in the request, but does not signal completion (you still need end_that_request_first() for that). Use of process_that_request_first() is optional; your driver may call it if you would like the block subsystem to track your current position in the request for I/O submission independently from how much of the request has actually been completed.

Barrier requests

Requests will come off the request queue sorted into an order that should give good performance. Block drivers (and the devices they drive) are free to reorder those requests within reason, however. Drives which support features like tagged command queueing and write caching will often complete operations in an order different from that in which they received the requests. Most of the time, this reordering leads to improved performance and is a good thing.

At times, however, it is necessary to inhibit this reordering. The classic example is that of journaling filesystems, which must be able to force journal entries to the disk before the operations they describe. Reordering of requests can undermine the filesystem integrity that a journaling filesystem is trying to provide.

To meet the needs of higher-level layers, the concept of a "barrier request" has been added to the 2.6 kernel. Barrier requests are marked by the REQ_HARDBARRIER flag in the request structure flags field. When your driver encounters a barrier request, it must complete that request (and all that preceded it) before beginning any requests after the barrier request. "Complete," in this case, means that the data has been physically written to the disk platter - not just transferred to the drive.

Tweaking request queue parameters

The block subsystem contains a long list of functions which control how I/O requests are created for your driver. Here's a few of them.

Bounce buffer control: in 2.4, the block code assumed that devices could not perform DMA to or from high memory addresses. When I/O buffers were located in high memory, data would be copied to or from low-memory "bounce" buffers; the driver would then operate on the low-memory buffer. Most modern devices can handle (at a minimum) full 32-bit DMA addresses, or even 64-bit addresses. For now, 2.6 will still use bounce buffers for high-memory addresses. A driver can change that behavior with:

    void blk_queue_bounce_limit(request_queue_t *q, u64 dma_addr);

After this call, any buffer whose physical address is at or above dma_addr will be copied through a bounce buffer. The driver can provide any reasonable address, or one of BLK_BOUNCE_HIGH (bounce high memory pages, the default), BLK_BOUNCE_ANY (do not use bounce buffers at all), or BLK_BOUNCE_ISA (bounce anything above the ISA DMA threshold).

Request clustering control. The block subsystem works hard to coalesce adjacent requests for better performance. Most devices have limits, however, on how large those requests can be. A few functions have been provided to instruct the block subsystem on how not to create requests which must be split apart again.

    void blk_queue_max_sectors(request_queue_t *q, unsigned short max_sectors);
Sets the maximum number of sectors which may be transferred in a single request; default is 255. It is not possible to set the maximum below the number of sectors contained in one page.

    void blk_queue_max_phys_segments(request_queue_t *q,
                                     unsigned short max_segments);
    void blk_queue_max_hw_segments(request_queue_t *q,
                                   unsigned short max_segments);

The maximum number of discontiguous physical segments in a single request; this is the maximum size of a scatter/gather list that could be presented to the device. The first functions controls the number of distinct memory segments in the request; the second does the same, but it takes into account the remapping which can be performed by the system's I/O memory management unit (if any). The default for both is 128 segments.

    void blk_queue_max_segment_size(request_queue_t *q,
                                    unsigned int max_size);

The maximum size that any individual segment within a request can be. The default is 65536 bytes.

    void blk_queue_segment_boundary(request_queue_t *q,
                                    unsigned long mask);

Some devices cannot perform transfers which cross memory boundaries of a certain size. If your device is one of these, you should call blk_queue_segment_boundary() with a mask indicating where the boundary is. If, for example, your hardware has a hard time crossing 4MB boundaries, mask should be set to 0x3fffff. The default is 0xffffffff.

Finally, some devices have more esoteric restrictions on which requests may or may not be clustered together. For situations where the above parameters are insufficient, a block driver can specify a function which can examine (and pass judgement on) each proposed merge.

    typedef int (merge_bvec_fn) (request_queue_t *q, struct bio *bio,
                                 struct bio_vec *bvec);
    void blk_queue_merge_bvec(request_queue_t *q, merge_bvec_fn *fn);

Once the given fn is associated with this queue, it will be called every time a bio_vec entry bvec is being considered for addition to the given bio. It should return the number of bytes from bvec which can be added; zero should be returned if the new segment cannot be added at all. By default, there is no merge_bvec_fn.

Setting the hardware sector size. The old hardsect_size global array is gone and nobody misses it. Block drivers now inform the system of the underlying hardware's sector size with:

    void blk_queue_hardsect_size(request_queue_t *q, unsigned short size);

The default is the usual 512-byte sector. There is one other important change with regard to sector sizes: your driver will always see requests expressed in terms of 512-byte sectors, regardless of the hardware sector size. The block subsystem will not generate requests which go against the hardware sector size, but sector numbers and counts in requests are always in 512-byte units. This change was required as part of the new centralized partition remapping.

DMA support

Most block I/O requests will come down to one more more DMA operations. The 2.6 block layer provides a couple of functions designed to make the task of setting up DMA operations easier.

    void blk_queue_dma_alignment(request_queue_t *q, int mask);

This function sets a mask indicating what sort of memory alignment the hardware needs for DMA requests; the default is 511.

DMA operations to modern devices usually require the creation of a scatter/gather list of segments to be transferred. A block driver can create this "scatterlist" using the generic DMA support routines and the information found in the request. The block subsystem has made life a little easier, though. A simple call to:

    int blk_rq_map_sg(request_queue_t *q, struct request *rq,
                      struct scatterlist *sg);

will construct a scatterlist for the given request; the return value is the number of entries in the resulting list. This scatterlist can then be passed to pci_map_sg() or dma_map_sg() in preparation for the DMA operation.

Going on

The second part of the request queue article series looks at command preparation, tagged command queueing, and writing drivers which do without a request queue altogether.

Comments (1 posted)

Driver porting: Request Queues II

This article is part of the LWN Porting Drivers to 2.6 series.
This article continues the look at request queues in 2.6; if you've not read the first part in the request queue series, you may want to start there. Here we'll look at command pregeneration, tagged command queueing, and doing without a request queue altogether.

Command pregeneration

Traditionally, block drivers have prepared low-level hardware commands at the time a request is processed. There can be advantages to preparing commands at an earlier point, however. In 2.6, drivers which wish to prepare commands (or perform some other sort of processing) for requests before they hit the request function should set up a prep_rq_fn with this prototype:

    typedef int (prep_rq_fn) (request_queue_t *q, struct request *rq);

This function should perform preparatory work on the given request rq. The 2.6 request structure includes a 16-byte cmd field where a pregenerated command can be stored; rq->cmd_len should be set to the length of that command. The prep function should return BLKPREP_OK (process the request normally), BLKPREP_DEFER (which defers processing of the command for now), or BLKPREP_KILL (which terminates the request with a failure status).

To add your prep function to a request queue, call:

    void blk_queue_prep_rq(request_queue_t *q, prep_rq_fn *pfn);

The prep function is currently called out of elv_next_request() - immediately before the request is passed back to your driver. There is a possibility that, at some future point, the call to the prep function could happen earlier in the process.

Tagged command queueing

Tagged command queueing (TCQ) allows a block device to have multiple outstanding I/O requests, each identified by an integer "tag." TCQ can yield performance benefits; the drive generally knows best when it comes to figuring out which request should be serviced next. SCSI drivers in Linux have long supported TCQ, but each driver has included its own infrastructure for tag management. In 2.6, a simple tag management facility has been added to the block layer. The generic tag management code can make life easier, but it's important to understand how these functions interact with the request queue.

Drivers wishing to use tags should set things up with:

    int blk_queue_init_tags(request_queue_t *q, int depth,
                            struct blk_queue_tag *tags);

This call should be made after the queue has been initialized. Here, depth is the maximum number of tagged commands which can be outstanding at any given time. The tags argument is a pointer to a blk_queue_tag structure which will be used to track the outstanding tags. Normally you can pass tags as NULL, and the block subsystem will allocate and initialize the structure for you. If you wish to share a structure (and, thus, the tags it represents) with another device, however, you can pass a pointer to the blk_queue_tag structure in the first queue when initializing the second. This call performs memory allocation, and will return a negative error code if that allocation failed.

A call to:

    void blk_queue_free_tags(request_queue_t *q);

will clean up the TCQ infrastructure. This normally happens automatically when blk_cleanup_queue() is called, so drivers do not normally have to call blk_queue_free_tags() themselves.

To allocate a tag for a request, use:

    int blk_queue_start_tag(request_queue_t *q, struct request *rq);

This function will associate a tag number with the given request rq, storing it in rq->tag. The return value will be zero on success, or a nonzero value if there are no more tags available. This function will remove the request from the queue, so your driver must take care not to lose track of it - and to not try to dequeue the request itself. It is also necessary to hold the queue lock when calling blk_queue_start_tag().

blk_queue_start_tag() has been designed to work as the command prep function. If your driver would like to have tags automatically assigned, it can perform a call like:

    blk_queue_prep_rq(queue, blk_queue_start_tag);

And every request that comes from elv_next_request() will already have a tag associated with it.

If you need to know if a given request has a tag associated with it, use the macro blk_rq_tagged(rq). The return value will be nonzero if this request has been tagged.

When all transfers for a tagged request have been completed, the tag should be returned with:

    void blk_queue_end_tag(request_queue_t *q, struct request *rq);

Timing is important here: blk_queue_end_tag() must be called before end_that_request_last(), or unpleasant things will happen. Be sure to have the queue lock held when calling this function.

If you need to know which request is associated with a given tag, call:

    struct request *blk_queue_find_tag(request_queue_t *q, int tag);

The return value will be the request structure, or NULL if the given tag is not currently in use.

In the real world, things occasionally go wrong. If a drive (or the bus it is attached to) goes into an error state and must be reset, all outstanding tagged requests will be lost. In such a situation, the driver should call:

    void blk_queue_invalidate_tags(request_queue_t *q);

This call will return all outstanding tags to the pool, and the associated I/O requests will be returned to the request queue so that they can be restarted.

Doing without a request queue

Some devices have no real need for a request queue. In particular, truly random-access devices, such as memory technology devices or ramdisks, can process requests quickly and do not benefit from sorting and merging of requests. Drivers for such devices may achieve better performance by shorting out much of the request queue structure and handling requests directly as they are generated.

As in 2.4, this sort of driver can set up a "make request" function. First, however, the request queue must still be created. The queue will not be used to handle the actual requests, but it contains other infrastructure needed by the block subsystem. If your driver will use a make request function, it should first create the queue with blk_alloc_queue():

    request_queue_t *blk_alloc_queue(int gfp_mask);

The gfp_mask argument describes how the requisite memory should be allocated, as usual. Note that this call can fail.

Once you have a request queue, you can set up the make request function; the prototype for this function has changed a bit from 2.4, however:

    typedef int (make_request_fn) (request_queue_t *q, struct bio *bio);

If the make request function can arrange for the transfer(s) described in the given bio, it should do so and return zero. "Stacking" drivers can also redirect the bio by changing its bi_bdev field and returning nonzero; in this case the bio will then be dispatched to the new device's driver (this is as things were done in 2.4).

If the "make request" function performs the transfer itself, it is responsible for passing the BIO to bio_endio() when the transfer is complete. Note that the "make request" function is not called with the queue lock held.

To arrange for your driver's function to be called, use:

    void blk_queue_make_request(request_queue_t *q, 
                                make_request_fn *func);

If and when your driver shuts down, be sure to return the request queue to the system with:

    void blk_put_queue(request_queue_t *queue);

As of 2.6.0-test3, this function is just another name for blk_cleanup_queue(), but such things could always change in the future.

Comments (2 posted)

Patches and updates

Kernel trees

Martin J. Bligh 2.5.66-mjb1 ?
Martin J. Bligh 2.5.66-mjb2 ?
Andrew Morton 2.5.66-mm2 ?

Architecture-specific

Jeff Dike uml-patch-2.5.66-1 ?
Jeff Dike UML updates ?
Jeff Dike UML build updates ?
Antonino Daplas Getting the EDID block for x86 ?

Core kernel code

Development tools

Randy.Dunlap kmsgdump for 2.5.65/66 ?
Paul Larson 2.5.66-gcov ?
dan carpenter smatch results for 2.5.66 ?

Device drivers

Documentation

Filesystems and block I/O

Bartlomiej Zolnierkiewicz bio traversal 1/2 - core changes ?
Bartlomiej Zolnierkiewicz bio traversal 2/2 - documentation changes ?
Suparna Bhattacharya Filesystem aio rdwr patchset ?
Suparna Bhattacharya Filesystem aio rdwr patchset (1/4) ?
Suparna Bhattacharya Filesystem aio rdwr patchset (2/4) ?
Suparna Bhattacharya Filesystem aio rdwr patchset (3/4) ?
Suparna Bhattacharya Filesystem aio rdwr patchset (4/4) ?

Janitorial

Memory management

Matthew Dobson Memory Binding (0/1) ?
Matthew Dobson Memory Binding (1/1) ?

Networking

Security-related

Chris Wright 2.5.66-lsm1 ?

Benchmarks and bugs

Nick Piggin AS vs DL vs CFQ ?
Con Kolivas 2.5.66 with contest ?
Con Kolivas 2.5.66-mm1 with contest ?
Con Kolivas 2.5.66-mm2 with contest ?
rwhron@earthlink.net benchmarks on recent kernels ?

Miscellaneous

Page editor: Jonathan Corbet

Distributions

News and Editorials

Source Based Distributions, Part 1

[This article was contributed by Ladislav Bodnar]

One of the great advantages of open source software is the availability of its source code. This, combined with free compilers and interpreters, gives us a relatively painless way to compile open source applications into executable binary files, nicely tailored to our hardware. The idea has caught on and we have seen an emergence of several source-based Linux distributions over the last few years. Indications are that they are becoming increasingly popular, especially among computer aficionados and home users.

What makes one decide to use a source-based distribution, such as Gentoo or Sorcerer, over a more traditional binary distribution, such as Red Hat or Mandrake? These are the often cited advantages:

1. Speed. When you compile an application specifically for your hardware and with correct compiler flags, it should execute faster than an application that was compiled with more generic compiler flags to cover wide range of processor architectures. In the cases of large programs, e.g. KDE or OpenOffice, the increase in speed will be noticeable.

2. The freshness factor. The world of Linux is full of great software, and new releases are announced daily. If you use a binary distribution, you have to wait until binary packages for your distribution become available, which can take months. There is no such delay with source-based distributions - in most cases you will be able to run the latest version with all the great features within days of its release.

3. Painless software installation. Most source-based distributions provide a sophisticated infrastructure to download, configure, compile and install software (and its dependencies) with one simple command. In majority of cases this works surprisingly well. Have your heard people complaining how hard it is to install software on Linux? That's because they have never tried a source distribution.

4. No software restrictions. Source distributions have learned the art of by-passing restrictions imposed by vendors of useful, but proprietary software (such as the NVidia video drivers) or software illegal in certain countries (such as libdvdcss library for watching encrypted DVDs). Since they don't supply the actual software, only scripts that fetch the packages from the maintainers' web sites, they are not subjected to those restrictions. Most binary distributions are reluctant to include such software.

Before you decide that a source distribution is perfect for your needs, consider some of the disadvantages.

1. Long and tedious installation. Getting your machine from empty hard disk into a full graphical environment with all the latest applications will more than likely take several days, even with a broadband connection and a fast processor. With a binary distribution, the same can be achieved within an hour after inserting the installation CD.

2. High maintenance level. Because of continuous and never-ending software upgrades, things will break. An innocent looking new library version can cause havoc on your system, due to new bugs or incompatibilities with existing libraries. It can be frustrating to work on a system which regularly lets you down.

3. Stability issues. Source distributions are notoriously reluctant to declare their releases "stable" and many of them seem perpetually stuck in a "beta" or "release candidate" state. As such, they are not suitable for production servers and their use is generally limited to workstations.

4. Fast Internet connection. While broadband is not a requirement, very few people will have the patience to maintain a continuously evolving source distribution over a slow, dial-up connection.

There are four major and well-established source-based distributions: Gentoo Linux, Linux From Scratch, ROCK Linux and the Sorcerer group (which includes Sorcerer, Lunar Linux and Source Mage GNU/Linux). We will look at these in more detail in an upcoming issue of LWN.

Comments (10 posted)

Distribution News

Debian GNU/Linux

The April 1 edition of the Debian Weekly News is out. It looks at the Project Leader election, running Sid on a laptop, the Debian Desktop User's Guide, improvements in the new maintainer process ("it should now be possible to join the project within three days"), the possibility that Linux could be illegal to sell to minors in Germany, and quite a few other topics.

Here are the results from the 2003 Debian Project Leader election. The winner is Martin Michlmayr, who beat Moshe Zadka, Branden Robinson and (present Project Leader) Bdale Garbee for the post.

An announcement has gone out regarding Alioth, a SourceForge installation dedicated to the Debian Project. It's available to projects that are part of Debian itself, or which feature heavy involvement by a Debian developer.

Martin Michlmayr provides a few Bits from the next DPL, as he prepares for the coming year as DPL.

James Troup takes a look at some new sections in the Debian archive.

Comments (1 posted)

Gentoo Weekly Newsletter -- Volume 2, Issue 13

As you read through this week's edition of the Gentoo Weekly News, it might be useful to remember that this is April 1st, 2003 edition.

Full Story (comments: none)

The end for Red Hat Linux 6.2 and 7

Red Hat has sent out notification that versions 6.2 and 7 of Red Hat Linux have reached the end of their support periods. There will be no more updates (for security or other problems) for these distributions. "If you are looking for a Red Hat Linux distribution that has longer maintenance periods, check out Red Hat Enterprise Linux which offers lifecycles of 3+ years."

Full Story (comments: 18)

ROCK Linux approaches version 2.0

ROCK Linux is approaching it's version 2.0 release, currently planned for April or May. Prebuilt ISO images labeled 2.0-alpha of dRock, the desktop target for Rock, are now available.

Comments (none posted)

Now available: OpenPKG in a box!

The OpenPKG project announced the commercial availability of version 1.2 of its OpenPKG software product.

Full Story (comments: none)

Trustix Secure Linux

Trustix has released two bug fix advisories. A missing rmail script has been added to postfix and Fusion MPT device support has been added to the kernel.

Comments (none posted)

New Distributions

PlumpOS Released

PlumpOS is the successor to Clump/OS, a well-known openMosix-based clustering system. It seems that Peter Willis started out to port Clump/OS, with the assistance of its author Jean-David Marrow. Along the way, PlumpOS turned into a complete rewrite.

Full Story (comments: none)

Products from eQ France

eQ France has some interesting products, starting with Linux/Epia, possibly one of the fastest Linux distributions in the world. Linux/Epia is installed on Q Rey computers, and will be used in some upcoming PDA products.

Full Story (comments: none)

Minor distribution updates

Astaro Security Linux

Astaro Security Linux has released v4.002 with minor bugfixes. "Changes: This Up2Date fixes an SMTP Proxy problem with the email server from Microsoft or Lotus. It also fixes the Up2Date over HA procedure."

Comments (none posted)

College Linux

College Linux has released v2.1. This is the initial freshmeat announcement.

Comments (none posted)

KNOPPIX

KNOPPIX has released v3.2-2003-03-28 with major feature enhancements. "Changes: Software updates and fixes."

Comments (none posted)

MoviX2

MoviX2 has released v0.3.0pre2 with major feature enhancements. "Changes: This release upgrades MPlayer to 0.90rc3, adds back-complete OSS support and *exp* support for all USB devices to the kernel. The HW config files have been rearranged, all HD parts are now mounted by default, and all known filesystems are probed. The movix.pl script has been updated with VOP options, and a TV boot label. The OSS modules have been restored because of problems with the ALSA ones, and a few binaries, such as pump and matroxset have been added from MoviX. NVidia support has also been restored."

Comments (none posted)

NPACI Rocks Cluster

NPACI Rocks Cluster has released v2.3.2 with a revised BSD style License.

Comments (none posted)

PXES Linux Thin Client

PXES Linux Thin Client has released v0.5.1-35 with major feature enhancements. "Changes: This can be taken as a 0.5.2 pre-release. Some important changes were introduced, mainly the ability to select Xfree86 3.3.6 or Xfree86 4.3.0, depending on your needs. Creating "multi session" images containing more than one cliet session code is possible. The session used can be decided at run time. Look and feel have been improved as well. This is perhaps the last step towards the "universal image" fitting almost all clients."

Comments (none posted)

RxLinux

RxLinux has released v1.3.1 with minor bugfixes. "Changes: Some crucial libraries missing in version 1.3.0 have been added. Libraries not used by the base operating system have been bundled in a separate package that will be deployed under /usr/lib as needed. busybox has replaced most of the standard Unix commands."

Comments (none posted)

Server optimized Linux

Server optimized Linux has released a desktop branch at v0.2. "Changes: This version includes GNOME 1.4 and 2.2, KDE 3.1 with multimedia extensions, tons of KDE 3.1 applications, OpenOffice 1.0.2, MP3 encoders, PalmPilot utilities, the ImageMagick graphic tools, the Gaim AOL/ICQ/MSN client, Licq, Gimp 1.3.13, TeTeX, and Mozilla 1.3."

Comments (none posted)

Distribution reviews

Red Hat Linux 9 Technical Changes

Guru Labs provides a technical review of Red Hat Linux 9. For all those who asked for something more technical, this is it. "There were many changes between RHL7.3 and 8.0, for example, the use of root=LABEL=/ in the /boot/grub/grub.conf file, the replacement of Xconfigurator with the redhat-config-xfree86 program, and the new dhclient DHCP client daemon that skips trying to bring up interfaces that have no link. There are not nearly as many behavioral changes from RHL8.0 to RHL9, yet the ones that exist are significant." (Thanks to Greg Bailey)

Comments (none posted)

Personal Review of Mandrake 9.1 (OSNews)

A Windows user tries to download and install Mandrake Linux 9.1 in this OSNews article. "Hardware problems easily must be one of the most annoying and difficult things to work with in Linux. How do I get my Terminal Adapter and Bluetooth working? Looking at the GUI there is nothing that helps me here and browsing through the help I can't find anything helpful either. Of course, I could just open up a terminal window and type some clever phrases into it and I'm sure it would work, but that relies on two things, me knowing what to type and me knowing what's wrong. Neither of which I do know of course."

Comments (none posted)

Page editor: Rebecca Sobol

Development

The Analog Web Log Analyzer

Version 5.90beta1 of Analog, a web server log analysis program has been announced. [Analog] This version is the first beta release leading up to version 6. "The output functions have been completely rewritten, to allow new output styles to be added; there are two new output styles as a result, XHTML and XML; and the default style is now XHTML, instead of HTML." Version 5.90beta1 also includes new documentation.

This introduction is a good place to get an overview of how Analog works to mine information from an Apache web server log file. Analog is cross-platform, configurable, scalable, and open-source. It currently supports 31 languages. Analog also works with a number of helper applications.

To get an idea of what Analog can do, take a look at this example report. The developer claims that Analog is the most popular logfile analyser in the world.

A report can contain the following sections:

  • A general summary of activity.
  • A monthly bar-chart report.
  • A daily bar-chart summary.
  • A bar-chart summary of hourly activity.
  • A domain report that shows where traffic is coming from.
  • An organization report that lists the most active viewer domains.
  • A report of the most common search terms.
  • A listing of operating systems used by site visitors.
  • A web server status code listing.
  • Reports for file sizes and extensions.
  • A report that shows traffic to served directories.
  • A request report that lists served files.
By reading through this condensed information, it is possible to get a good idea of the traffic patterns at your web site. This helps in deciding which sections are worth the most effort to optimize.

One feature that is apparently not part of Analog is the ability to analyze the web server's error log file, a fair amount of useful information could be obtained that way. Analog is available for download here.

Comments (2 posted)

A new Mozilla roadmap

The Mozilla project has posted a new development roadmap that calls for some significant changes in the project. Among other things, the project will:
  • Shift its browser focus from the classic Mozilla browser to the newer Phoenix application.

  • Add emphasis to the development of the Minotaur mail component as a standalone application.

  • Rearrange the code "ownership" model. Cross-project CVS access will go away, in favor of "vigorously defended modules with strong leadership and clear delegation".

The current plans call for a stable 1.4 release in May, followed by 1.5 (which is when the big changes begin) in August.

Comments (12 posted)

System Applications

Audio Projects

Planet CCRMA Status Update

A new Change Log has been released from the Planet CCRMA Linux audio site. "Major repository update, repository version up to 2-0 (it had no version number before). Updated apt to version 0.5.5cnc4.1. Updated synaptic to version 0.32-1 (only for RedHat 8.0, 7.2 and 7.3 need newer core packages that I'm not going to try to build). The linux kernel is now version 2.4.20-4.ll.acpi. The alsa drivers are now version 0.9.2-4.cvs."

Comments (none posted)

Ogg Traffic

The March 31, 2003 edition of Ogg Traffic is available with the latest Ogg Vorbis audio compression software news. Discussion topics include: Status Updates, Tremor Improvements, Nero Ogg Vorbis plugin, New Software, and New (Experimental) Bitrate Peeler Available.

Comments (none posted)

Database Software

PostgreSQL Weekly News

The March 26 issue of the PostgreSQL Weekly News is out with the latest information from the PostgreSQL development team. "[The patches] range from minor tweaks to major changes, with one feature in particular that hasn't been hyped up a lot, but should get a lot of people excited. What? You guys don't get excited about database hacking...?"

Full Story (comments: none)

SAP DB Version 7.4.03.17 released

Version 7.4.03.17 of SAP DB is available. See the release info for a long list of changes.

Comments (1 posted)

Electronics

gEDA News

The latest news from the gEDA (GPL Electronic Design Automation) project includes a new development snapshot of the Icarus verilog electronic simulation language compiler.

Comments (none posted)

Mail Software

SpamCheck 1.0b1 Released (Milter)

The Milter site has an announcement for SpamCheck 1.0b1. "It's a pretty decent (IMHO) spam-filtering package which allows per-user configurations of which rules are active, per-user DNSBL rules (e.g., one user can use SPEWS, another can use SPEWS and MAPS, another just MAPS, and another have none, its completely configurable)."

Comments (none posted)

BSpam-0.5 released

Version 0.5 of the BSpam Perl-based probabilistic spam filter is available. "Major features include mime decoding, html parsing and whitespace compression to foil spammers who try to hide their content from filters. Version 0.5 includes improvements in tokenizing prices, and special marking of tokens in Content-Type headers to better handle chinese language spams."

Comments (none posted)

Medical Software

hl7d added to HL7 Toolkit

Sourceforge mentions a new Perl-based project: "This project aims at providing a Perl Toolkit for using the HL7 protocol (a data interchange protocol used in healthcare). The toolkit will consist of a number of Perl libraries and scripts for developing HL7 capable applications in Perl. An early version of the hl7 server has been added to the project. This is a forking server that uses the Net::HL7 module, and dispatches incoming HL7 messages to user defined plugins."

Comments (none posted)

Printing

OMNI version 0.9.0 released

Version 0.90 of the OMNI printer driver has been released. Changes include a switch from compiled device support to XML device support, a switch from DTD to XSD, bug fixes, and more.

Comments (none posted)

Web Site Development

KONTENTOR 2.0 Alpha 1 ready for download (ZopeMembers)

Zope Members News has an announcement for a new Zope-based content management framework, known as KONTENTOR. "The first public release of KONTENTOR 2.0, the Zope-based content management framework developed by iuveno AG, can be downloaded from the new KONTENTOR website, www.kontentor.de (in German)."

Comments (none posted)

Plone PoPoll released ! (ZopeMembers)

For those of you who need a web-based polling application, the PlonePoPoll content type has been announced for the Plone content management framework.

Comments (none posted)

ZAxisVideo v1.0 is out (ZopeMembers)

Version 1.0 of ZAxisVideo, a GPL licensed product that allows an Axis video server to be controlled from Zope, has been released.

Comments (none posted)

Zwiki 0.17.0 released (ZopeMembers)

Version 0.17.0 of ZWiki has been announced. The changes include: "simpler page ids, faster performance and better memory efficiency, new general-purpose page type including tracker and fit support, more robust parenting, skin improvements, preliminary stylesheet support, code cleanups, doctest no longer used."

Comments (none posted)

Miscellaneous

Red Carpet 2.0 preview release

Version 2.0 (preview release) of Red Carpet, a graphical software management tool for the RPM and dpkg package management systems, has been announced. "This new version features an all-new, native GTK+ 2.0-based user interface. Its new layout allows more powerful access to software management tasks like installing software from multiple channels and installing and removing software simultaneously. It aims to conform with the GNOME Human Interface Guidlines."

Comments (none posted)

Building an Address Book with OpenLDAP

Dustin Puryear shows how to work with OpenLDAP on O'Reilly. "Why is a centralized address book important, and how can it be used? For starters, I think just about every consultant has walked onto a site--even a large one--where everyone has contact information stored locally in their contact management software. What's wrong with that? Nothing, if you don't mind losing the ability to update contact information effortlessly across the entire company."

Comments (none posted)

Desktop Applications

Audio Applications

Ceres V0.38 released

Version 0.38 of Ceres is available. "Ceres is a simple program for displaying sonograms and for sound effects in the frequency domain."

Full Story (comments: none)

OZradio BETA 0.6 Released

Version 0.6 Beta of OZradio has been announced. "OZradio BETA 0.6 for bttv compatible Radio cards. Listen to FM Radio, Save up to 10 stations to programable buttons, On demand recording of radio, Programable recording of radio, Playback recorded radio, Auto Scan radio Frequencys, Volume control."

Comments (none posted)

CAD

Fifth release of PythonCAD now available. (GnomeDesktop)

FootNotes covers the latest release of PythonCAD. "The fifth release adds the first appearance of a global and user preferences file. Dimensions can now display endpoint markers like arrows and slashes, though the size these objects are displayed at is currently fixed. This limitation should be removed in one of the next two releases. The first implementation of leader lines has been added as well. This release also has many internal changes in preparation for adding hatching. There are also new methods for finding entities in a drawing. Finally, the usual assortment of bug fixes and code tweaks are included."

Comments (none posted)

Desktop Environments

George Staikos: A Quick Cost Analysis of Qt vs GTK

KDE.News has an analysis of some KDE and GNOME comparison issues. "Last week, CORBA-lover Michael Meeks released some slides that caused something of a stir amongst some in the KDE community. In his slide, Michael Meeks attempted to make the case for GNOME as the only viable desktop on Unix by directing the heat of his argument at the cost of Trolltech's Qt -- the wonderful cross-platform toolkit on which KDE is based -- for proprietary development. Rising up to the challenge, George Staikos has written a nice article that compares the cost of Qt vs GTK in the real world."

Comments (none posted)

GNOME Summary for March 29, 2003

Here's the latest GNOME Summary, with news about GNOME 2 API docs, Abiword, OpenOffice, and much more.

Full Story (comments: none)

KDE-CVS-Digest

The March 28, 2003 KDE-CVS-Digest has been published. "KBugBuster can now read most Bugzilla sites. The integration of Kafka (wysiwyg html editor) with Quanta begins. A new KSplash is introduced, KSpread gets some serious optimizations."

Comments (none posted)

XFree86 Project Launches Bugzilla Installation (MozillaZine)

MozillaZine reports on a new Bugzilla installation of XFree86. "foopy wrote in to tell us that The XFree86 Project, which produces an open-source implementation of the X Window System, has launched its own Bugzilla installation."

Comments (none posted)

Eel and Nautilus 2.2.3.1 released (GnomeDesktop)

Version 2.2.3.1 of Eel and Nautilus have been released. "This release continues the work on the UI bugs that make nautilus tougher to use. In particular we've focused on the list view, a long-neglected part of the nautilus family. Anybody using the list view on a regular basis should upgrade, we think you'll be pleased."

Comments (none posted)

Games

WorldForge Games Media Team Status Report

A new Media Team Status Report is available from the WorldForge game project. "In the first installment for the year, we present our recent accomplishments, things we are working on and things that you could do to help us. As a bonus, there is also the Do It Yourself Mushroom - Fun For The Whole Family!" Lots of fun eye candy is included.

Comments (none posted)

Pygame updates

New Python-based game software on the Pygame site includes: Tuxmathscrabble .1.5, Pyddr 0.6, and Beamblocks 0.

Comments (none posted)

Interoperability

Samba 3.0 alpha 23 available

A new alpha version of Samba has been released. Click below for full details. "The purpose of this alpha release is to get wider testing of the major new pieces of code in the current Samba 3.0 development tree. We have officially ceased development on the 2.2.x release of Samba and are concentrating on Samba 3.0. To reduce the time before the final Samba 3.0 release we need as many people as possible to start testing these alpha releases, and hopefully giving us some high quality feedback on what needs fixing."

Full Story (comments: none)

Wine Traffic #163

Issue #163 of Wine Traffic is out. Topics include: Interview Series Coming Soon, WineHQ Facelift, Wine Downloads At SourceForge, Making Wine Run With glibc 2.3, Wine & Services, Valgrind for Wine, Error Requiring 32/16 Bit DLL Combinations, and QEMU x86 Emulator.

Comments (none posted)

Office Applications

AbiWord Weekly News

Issue #137 of the AbiWord Weekly News is out, with the latest AbiWord word processor development news.

Comments (none posted)

GNUe Traffic #74

Issue #74 of GNUe Traffic has been published. Topics include: Support for images in GNUe Forms, GNUe Small Business and other free financials packages, Application Server development, GNUe Small Business, Sample apps for Application Server, Documenting how to write python triggers in Designer, and Freedom issues with Compiere.

Comments (none posted)

Web Browsers

Mozilla 1.4 alpha

The alpha release of Mozilla 1.4 is out. The release notes will tell you about all the new stuff in this release; the list includes 1000 bugfixes, a reworked bookmark manager, smooth scrolling, Composer improvements, and more.

Comments (none posted)

Independent Status Reports

The Mozilla Independent Status Reports are out. MozillaZine's summary lists: "The latest set of status reports includes updates from NeedleSearch, Consultants, Jabberzilla, MozQuake, UserGuide, Beonex, Gnusto, Blozom, Uzilla, Googlebar, StumbleUpon and mozdev."

Comments (none posted)

Miscellaneous

OpenSSH 3.6 released

OpenSSH 3.6 has just been released and will soon be found at a mirror near you. This version includes RSA blinding and other security inspired features.

OpenSSH version 3.6.1 was announced right afterwards, it fixes a bug caused by the "kex guesses" fix in version 3.6.

Full Story (comments: none)

Thorn v0.5.0 released

Version 0.5.0 of Thorn has been released. "Version 0.5.0 adds collaboration diagrams to Thorn's growing list of supported diagrams. Thorn is a UML diagramming tool, specifically designed for Open Source projects. The UML models are saved in XML format for easy internet transfers and publishing. Thorn supports scripting in JPython and uses the Xerces XML parser."

Comments (none posted)

Languages and Tools

Caml

Caml Weekly News

The March 25 to April 1, 2003 Caml Weekly News is out. Topics include New PXP mailing list, Recursive types and functors, OCaml performance, and Our shrinking Humps.

Full Story (comments: none)

Lisp

Jabberwocky 1.0 released

Version 1.0 of Jabberwocky, a LISP IDE, has been announced.

Full Story (comments: none)

Perl

This Week on perl5-porters

The March 24-30, 2003 edition of This Week on perl5-porters is out. "This week was a rather interesting week among the Perl 5 porters. Read about pattern matching extensions, CPAN distribution issues, and various bugs and problems."

Comments (none posted)

This week on Perl 6 (O'Reilly)

The March 30, 2003 edition of This week on Perl 6 is out with the latest Perl 6 news.

Comments (none posted)

PHP

PHP Weekly Summary

Topics on this week's PHP Weekly Summary include: "What is PHP 5?, Thread safety performance, Non-thread safe extensions, ICU extension, Timezone changes due to Tru64, Speeding Apache 2 up, socket_iovec_alloc segfault, Nested namespaces, 255 files bug under Solaris."

Comments (none posted)

Compiling and Enabling GD in PHP 4.3 (O'ReillyNet)

O'Reilly has an article on making GD work under PHP 4.3. "PHP 4.3 ships with a bundled version of the GD graphics library. Unfortunately, compiling it successfully can still be troublesome. Marco Tabini explains how to make PHP and GD play together nicely--no matter what you want to accomplish."

Comments (none posted)

Simple linear regression with PHP: Part 1 (IBM developerWorks)

Paul Meagher covers math under PHP on IBM DeveloperWorks. "A missing, but powerful, tool in the PHP arena is a language-based math library. In this two-part series, Paul Meagher hopes to inspire PHP developers to develop and implement a PHP-based math library by providing you with an example of how a library of analytic models might be developed."

Comments (none posted)

Python

Dr. Dobb's Python-URL!

The March 31, 2003 edition of Dr. Dobb's Python-URL! is out with the latest Python language news.

Full Story (comments: none)

Python in a Nutshell What's New in Python 2.3? (O'Reilly)

Alex Martelli explores Python 2.3 on O'Reilly. "Is it worth upgrading? You bet. With Python 2.3, you can expect typical Python code to run about 15 percent to 20 percent faster than it did with 2.2, since a lot of care has been devoted to optimization and fine-tuning."

Comments (none posted)

Ruby

The Ruby Weekly News

Topics on this week's Ruby Weekly News include: ruby-dev summary 19824-19877, ruby-dev summary 19878-19943, and Squawks of the Parrot.

New Ruby software includes: RubLog 0.8, GridFlow 0.7.1, FXRuby-1.0.21, mhttp, Ruby-MacX alpha, Ruby-MacX alpha, Ruby-GNOME2-0.4.0 binaries(Cygwin, Debian), tld.rb 0.11, RHDL-0.4.2 (Ruby HDL) an agile HDL, xml-simple 0.6.0, and Text::Format 0.62.

Comments (none posted)

Scheme

Scheme Weekly News

The March 31, 2003 edition of the Scheme Weekly News is out with the latest Scheme language news.

Full Story (comments: none)

Tcl/Tk

Dr. Dobb's Tcl-URL!

The January 31, 2003 edition of Dr. Dobb's Tcl-URL! is out with lots of Tcl/Tk development news.

Full Story (comments: none)

XML

XML Standards for Financial Services (O'Reilly)

Ayesha Malik explains the use of XML for performing financial transactions. "The ultimate goal of straight through processing is to replace the traditional phone and fax confirmations with a completely automated loop, from pre-trade communication and deal capture through to clearing and settlement. This involves automating the processes passing trade-related data between investment managers, brokers, clearing agencies, and custodians."

Comments (none posted)

XML and JavaScript in the Browser (O'Reilly)

John E. Simpson writes about the processing of XML with JavaScript on O'Reilly.

Comments (none posted)

Profilers

OProfile 0.5.2 has been released

Version 0.5.2 of OProfile, a system-wide profiler for Linux, has been announced.

Full Story (comments: none)

Miscellaneous

Anjuta 1.0.2 (Tagore) released

Version 1.0.2 of the Anjuta IDE has been announced.
The Anjuta team is pleased to announce the release of Anjuta 1.0.2. Anjuta is an IDE (Integrated Developmetn Environment) for C and C++ targetting the GNOME platform. The main highlight of this release is the advanced search/replace functionality. There have also been numerous smaller feature additions, updates and bug fixes.

Comments (none posted)

ECB 1.93 released

Sourceforge mentions the release of ECB 1.93: "ECB is a file/code browser for Emacs. It can be used to browse any type of file and supports parsing of Java, C, C++, Elisp and other types of source code. This release (1.93) includes bug fixes, layout enhancements and enhancements to tree-buffers."

Comments (none posted)

Page editor: Forrest Cook

Linux in the news

Recommended Reading

Open Source needs centralized PR, not development (NewsForge)

NewsForge is looking for a better way to find out about open source projects. "It happened again: A complaint was brought up on a free software email list I'm on about the lack of a certain type of open source program, but there are several healthy projects in that area I knew about, and other list members pointed out yet others. Why didn't we all know about all of them? And if we don't know, how can we expect potential corporate open source adopters, who aren't on "inner circle" Linux and open source email lists, to know what's available to them?"

Comments (12 posted)

Hacker cracks Xbox challenge (News.com)

News.com reports that an anonymous hacker cracked the Xbox. "The trick involves the "save/load game" function in the James Bond game "007: Agent Under Fire," which normally allows players to save a file recording their progress in the game to the Xbox's hard drive and later reload it. [Habibi-Xbox] found that by using one of several USB storage devices recognized by the Xbox, the "load game" screen can also be used to load other software, including compact versions of the Linux operating system."

Comments (20 posted)

How open source developers can get more U.S. government contracts (NewsForge)

NewsForge has some advice for those seeking to make open source sales to the U.S. government. "All open source developers, contractors, distributors, administrators (etc) should give the appearance of only caring about their sales revenue and aim to sell Open Source Software products, each containing only a few binary packages, for as much money as the purchasing budgets can afford. The FAR [Federal Acquisition Regulation] was designed for that behavior pattern, and helps government buyers efficiently talk to vendors who exhibit it."

Comments (1 posted)

Trade Shows and Conferences

Linux Audio Development: A Report from Karlsruhe (Linux Journal)

Linux Journal reports from the first Linux audio developers' conference in Germany. "Historically, the basic Linux sound system has been built on an API known most recently as OSS/Free. As of the 2.5 development series, the Linux kernel now officially deprecates the aging OSS/Free API and has replaced it with the Advanced Linux Sound Architecture (ALSA). ALSA provides a backwards-compatible layer for accommodating older applications designed for OSS/Free. But, its advanced API includes more interesting features, such as support for sound hardware from consumer-level sound cards to professional-grade digital audio boards, a fully modularized driver design, safe operation in SMP and threaded programming environments, and a user-space library (libasound) to simplify applications programming."

Comments (none posted)

Companies

Fujitsu preps Linux-based robot (Register)

The Register looks at a Linux powered robot from Fujitsu. "Fujitsu says it will release information about the droid's control systems and software to make the machine user-programmable. All you need are C/C++ coding skills, apparently. Indeed, HOAP stands for Humanoid Open Architecture Platform."

Comments (3 posted)

Oracle Pours Funds Into Linux App Development (TechWeb)

According to this TechWeb article Oracle plans to spend as much as $150 million this year to fuel third-party application development on Linux. "While Linux has made inroads in departmental servers and elsewhere, application availability remains a gaping hole. And most solution providers agree that applications drive technology buys."

Comments (1 posted)

Sun to drop its customized Linux (News.com)

News.com covers the demise of another Linux distribution, as Sun decides playing the field is better than rolling their own. "Sun Microsystems will phase out its customized Sun Linux and move instead to partnerships with Red Hat and other mainstream Linux companies, executives said Friday."

Comments (3 posted)

SuSE On Itanium To Support National Supercomputing Grid (TechWeb)

TechWeb covers SuSE Linux on Itanium 2 which will help to power the "TeraGrid". "SuSE estimated the value of the deal at several hundred thousand dollars. It's being done in partnership with IBM Global Services, which is deploying clusters of SuSE Linux systems at the four DTF sites."

Comments (none posted)

Business

Open source systems make business sense (ZDNet Au)

ZDNet Australia says open source is good business. "Business leaders trying to build empires are arguing with radicals trying to change the world, who in turn are cajoling project managers just trying to ship on time. I maintain that, politics aside, for most software projects, some level of openness makes good business sense." (Thanks to Con Zymaris)

Comments (4 posted)

Linux Adoption

Linux gains modestly in retail systems (News.com)

News.com looks at an IHL study which shows Linux gaining ground in retail systems. "The number of computerized cash registers using the Linux operating system grew by 185 percent in 2002, according to a study released Wednesday, but Linux still has only 4 percent of the overall market."

Comments (1 posted)

Linux On Desktop Not There Yet But Getting Close, Says Ellison (TechWeb)

TechWeb is carrying Oracle CEO Larry Ellison's comments on desktop Linux. "Regarding Linux on the desktop, Ellison said: 'Star Office is almost usable. It's getting close. I play with it, and it's not awful.'"

Comments (2 posted)

Interviews

Interview: Eric Raymond goes back to basics (IBM developerWorks)

IBM developerWorks interviews Eric Raymond. "Open source advocate Eric Raymond has been spending more time lately in front of the computer than in front of the crowds. He says he's backed off on the public speaking engagements, in part because the travel schedule was exhausting, but also because the need for a 24x7 open source advocate is just not what it once was. The open source revolution is "basically on course," he says; the enterprise has embraced Linux, and these days very few people now need to be convinced that the open source methodology can create best-of-breed software."

Comments (6 posted)

Miguel Interview, Part I (OSNews)

OSNews interviews Miguel de Icaza about Mono, .NET and dotGNU, Gnome and its relationship to KDE, and much more. "Mono would not be possible without the day-to-day work of hundreds of developers that make it happen. I suggest for those interested in a particular area in Mono, to check the ChangeLogs and the mailing list to identify the developer that has created this technology. Since Mono is a large community effort, I could not list the responsible developers on each section in the following answers as I would have liked to, because it would have taken me another week to reply."

Comments (2 posted)

Interview with Ove Kåven

Wine HQ features an interview with Wine developer Ove Kåven. "But on the Windows 3.11 machine, I had fun playing a MMORPG by Sierra, "The Realm", in my spare time. Then I thought, hmm, wouldn't it be nice if I could play this on the Linux machine, too? After considering it a bit, and finding the free time, I downloaded the Wine sources and started hacking. It took only a few weeks to get it to work, if I remember right. But by then, I was already hooked on the concept of Wine, and started trying to get Eudora to work, then Free Agent. Given that I had a level of experience with advanced Windows programming that few of the other contributors had at the time (and was able to fix the bugs that plagued Eudora and Free Agent), I soon decided to become a permanent member of the Wine team."

Comments (none posted)

Egoboo Developer Interview (O'ReillyNet)

O'Reilly features an interview with game developers Ben and Aaron Bishop. Having explored the world of Egoboo in Egoboo: The Cute Way to Dungeon Role Play, Howard Wen talks with Ben and Aaron Bishop, its lead developers, on portability and the hard lessons of game programming."

Comments (none posted)

The Suite Strategy of Konquering the Desktop (NewsFactor)

NewsFactor Network talks with KDE developers Ralf Nolden and David Faure as part of a report on the Linux Desktop. "When people talk about "the desktop" it is a kind of catch-all that describes all types of end-user situations. But quite a few segments exist within the "desktop" market, and they do not all share the same requirements."

Comments (none posted)

SuperVillain: He Has More Friends Now (Linux Journal)

Linux Journal talks with the creator of Ubergeek. "His name is Chris Hill and he describes himself as "an American living in London, England, originally hailing from Phoenix, Arizona." As for his day job, he says, "I'm a freelance web guy. I have my fingers in every pot. I host, design, manage projects and code. Mainly web sites for mid-sized corporations in the Southwest. I originally went to school for graphic design, but I've been into programming since I was young.""

Comments (none posted)

Resources

Linux Audio Musings

Dave Philips has updated his Linux Audio musings column for March/April, 2003. "The big news to report concerns the conference of Linux Audio Developers held at ZKM in Karlsruhe, Germany, from the 14th through the 17th of March. This conference was the first of its kind and must be considered a complete success." See the Sound and MIDI Software For Linux site for more information.

Comments (none posted)

The Ultimate Linux Box: A Case Study (Linux Journal)

The Linux Journal, once again, seeks to build the ultimate Linux box. It will be a multiple-article process this year; the first looks at cases. "This year the idea is to build a multimedia workstation. We want a dual-head video card, professional quality USB sound, the latest in serial ATA RAID storage, a DVD recorder, some serious horsepower to drive it all and, of course, a nice case."

Comments (none posted)

Reviews

What's New in Python 2.3? (O'ReillyNet)

Here is an O'ReillyNet article written by Python in a Nutshell author Alex Martelli. "Is it worth upgrading? You bet. With Python 2.3, you can expect typical Python code to run about 15 percent to 20 percent faster than it did with 2.2, since a lot of care has been devoted to optimization and fine-tuning."

Comments (none posted)

StarOffice beta hits the ground running (IT News)

The Australian IT News looks at new beta releases from OpenOffice.org and StarOffice. "OpenOffice.org 1.1 and StarOffice 6.1 include support for a variety of new data formats, including the increasingly ubiquitous Adobe Portable Document Format (PDF), Macromedia Flash, DocBook, several PDA Office file formats, flat XML and XHTML; and support for over 10 new languages."

Comments (none posted)

Miscellaneous

Gnome flaw threatens Linux users (News.com)

News.com reports on a vulnerability in the Eye of Gnome program. "A vulnerability in the default image viewer for one of the two major Linux desktop systems could allow an attacker to execute code on a computer running the Gnome software, security group Core Security Technologies said in an advisory on Friday."

Comments (3 posted)

California prison program offers Mandrake Linux to schools (DesktopLinux)

DesktopLinux.com covers a program that puts Mandrake Linux into California schools. "California schools can choose to have the Mandrake Linux desktop pre-installed on reconditioned computer systems from an inmate-run refurbishing program.The computers are made available to eligible schools for free by the TTFA."

Comments (none posted)

Computerworld articles about Linux

Here are two Computerworld articles about Linux, thanks to Peter Link.

Getting Started With Linux looks at some big businesses that have switched to Linux for their operations. "The good news: You can do almost anything on Linux that you can do on a mainframe or distributed systems. The bad news: It will require you to learn some new concepts and terminology."

In Some Linux Issues Are No Big Deal for Newbies the focus is on protecting business data on Linux systems. "Among the areas you don't have to sweat, say customers, analysts and vendors, are backup and restore tasks, clustering and fail-over."

Comments (2 posted)

Page editor: Forrest Cook

Announcements

Non-Commercial announcements

University of Buffalo faculty goes for open source

The University of Buffalo (New York) Faculty Senate has passed a resolution calling for the use of open source software and open file formats at the University. The resolution cites the needs for free information flow, privacy, and cost containment. "...open-source, or 'free' software provides an alternative to proprietary operating systems and application software that is robust, reliable and trustworthy, and provides a means for the University community to retain complete control of its computer hardware and software, and to retain the rights of Fair Use of information, and preserve the means to adapt computer systems to specific research and personal needs..." (Thanks to Dan Kegel).

Comments (3 posted)

FSF Announces Corporate Patronage Program

The Free Software Foundation announced its new Corporate Patronage Program. This follows the successful launch of its Associate Membership program.

Full Story (comments: 1)

Competition: Design a New Logo for KDE.org

KDE.News has announced a competition for a new KDE web site logo. "The KDE Web Team would like to announce a competition to design a new logo for the KDE.org website. The prize for the competition is the honour and satisfaction of having your work displayed on KDE.org and its subdomains, with full credit given for each use of the image. The competition will run over the course of a month and closes on April 30th, 2003."

Comments (none posted)

Commercial announcements

ActiveState & O'Reilly provide Safari Electronic Reference Library

ActiveState Corp. and O'Reilly & Associates have announced the launch of Safari Bookshelf, a leading technical reference library, now accessible within the redesigned ActiveState Programmer Network(TM) (ASPN) website.

Comments (none posted)

Linux Networx cluster renders "The Core"

In another example of how Linux systems appear to be taking over in the special effects field, Linux Networx has announced that one of its "Evolocity" clusters was used to perform the rendering in "The Core."

Full Story (comments: none)

Resources

Linux Audio Developers Conference slides and recordings

Slides and recordings are available from the recent Linux Audio Developers Conference. The slides are available here.

Full Story (comments: none)

LPI Level 1 Exams

The Linux Professional Institute has re-published its Level 1 exams.

Full Story (comments: none)

OpenOffice.org: Integration with GNOME

Michael Meeks has made his slide presentation on the integration of OpenOffice.org and the GNOME desktop available online.

Comments (none posted)

From CMF to Zope3, Lessons Learned (Presentation) (ZopeMembers)

A set of Zope related slides are available online. The slides were presented to the the 2003 Berlin Tagung, Deutschesprachlige Zope User Group

Comments (none posted)

ZConfig PyCon DC presentation online (ZopeMembers)

A paper and slides on ZConfig, a Python package which supports application configuration, are available. The material was presented at PyCon DC 2003.

Comments (none posted)

Upcoming Events

Plone Seminar - Apr 29 (ZopeMembers)

Zope Members News has an announcement for the first Plone Seminar Day, to be held in Paris, France on April 29. "IngeniWeb organizes a Plone Seminar in Paris, a whole day to discover and explore Zope/Plone, with the french experts, authors of books about Plone and Zope."

Comments (none posted)

GCC Developers Summit Announcements

A number of announcements have been posted for the GCC Developers Summit, to be held in Ottawa, Canada on May 25-27, 2003.

Full Story (comments: none)

LinuxUser and Developer Expo and Conference postponed

The LinuxUser & Developer Expo and Conference in Birmingham, England has been rescheduled for June 24-26, 2003.

Full Story (comments: none)

Events: April 3 - May 29, 2003

Date Event Location
April 3, 2003The UK Python Conference(Holiday Inn Oxford)Oxford, England
April 5, 2003Linux In Education Spring Conference(Grand Prairie High School)Grand Prairie, Texas
April 10 - 12, 2003MySQL Users Conference & Expo 2003(Doubletree Hotel)San Jose, California
April 13 - 17, 2003RSA Conference 2003(Moscone Center)San Francisco, CA
April 14 - 15, 2003Samba eXPerience 2003(Hotel Freizeit)Göttingen, Germany
April 15 - 16, 2003LinuxUser & Developer Expo 2003Birmingham, UK
April 22 - 26, 2003Embedded Systems Conference(ESC)(Moscone Convention Center)San Francisco, CA
April 22 - 25, 2003The O'Reilly Emerging Technology Conference(Westin, Santa Clara)Santa Clara, CA
April 23 - 25, 2003PHPCon East 2003(Park Central Hotel)New York, NY
April 28 - 30, 2003Real World Linux 2003(Metro Toronto Convention Centre)Toronto, Canada
May 3, 2003International Conference on Software Engineering 2003Portland, Oregon
May 8 - 9, 2003International PHP Conference, 2003Amsterdam, the Netherlands
May 11 - 14, 2003The International Symposium on High Performance Computing Systems and Applications(HPCS 2003)(Sherbrooke Delta Hotel)Quebec, Canada
May 11, 2003Yet Another Perl Conference, Israel(YAPC::Israel::2003)(C.R.I.)Haifa, Israel
May 15 - 16, 2003YAPC::Canada(Carleton University)Ottawa, Canada
May 25 - 27, 2003GCC Developer's SummitOttawa, Canada
May 28 - 30, 2003Open Source Content Management, 2003(OSCOM)(Harvard Law School)Cambridge, Mass

Comments (none posted)

Software announcements

This week's software announcements

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

Comments (none posted)

Page editor: Forrest Cook


Copyright © 2003, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds