A report from SCALE 2008

Escaping the cold for 70 degree days in Los Angeles might be a reason for some—Colorado-based LWN Editors for example—but it clearly is not the reason that most folks choose to attend Southern California Linux Expo (SCALE). Many of the approximately 1400 attendees already live in the region, so it is the speakers, participants, and the expo floor that bring them in. I attended the sixth annual SCALE (SCALE 6x), just held, February 8-10 and it didn't take me very long to see why it continues to grow and prosper.

SCALE is a three day event, with two main conference days on Saturday and Sunday and a set of mini-conferences running in parallel on Friday. Each mini-conference covers a focused topic of interest to the community, with this year's topics examining Women in Open Source (WIOS), Open Source Software in Education (OSSIE), and Demonstrating Open Source Healthcare Solutions (DOHCS). It was a full day as each had eight or more hour-long sessions.

Allison Randal kicked off the WIOS track with a presentation aimed at encouraging more women to give presentations at conferences. Her talk, "The Art of Conference Presentations", was not particularly gender specific, of course. It covered the process of proposing, creating and giving talks to conferences. Randall's advice was cogent, from avoiding "cute" titles to establishing credibility via your biography without feeling like you are bragging. Her most important point was to not wait around until you are the perfect speaker, but to go out and start speaking; your voice and style will come with practice.

Over in the OSSIE track, Dan Anderson related his experiences teaching computer science concepts to middle and high school students over the last fourteen years. His approach is to use computing as a bridge between math, science, and technology. He discussed the process of creating, or trying to create, a stable curriculum in the face of rapid technological change. Because the hardware, operating systems, and languages all change quickly, his courses need to focus on concepts that are not specific to any of those. Over the years he has taught, the language used in the advanced placement course—dictated by the state CollegeBoard company—has gone from Pascal, through C++, and now uses Java, with some rumblings being heard about moving to Python. As he points out, "much of what a High School student learns about technology will be outdated by the time they graduate from college".

He uses How to Design Programs as the core text for his courses. It uses a graphical programming environment called DrScheme, which is based on Scheme, that allows different subsets of the language to be used based on the skill level of the student. Anderson has integrated various peripherals, like cameras and audio equipment, into the environment so that students can interact with the real world in interesting ways. His students work on projects like voice authentication and computer vision; this year's project is to recognize tic-tac-toe as drawn on a white board.

Other topics from OSSIE included a tutorial introduction to the moodle content management system (CMS) for online learning. Much like other CMS projects, moodle allows the creation of websites with various kinds of content—audio, video, images, and text—but organized as a course. It provides a framework and philosophy to guide the development of online classes. Students access the content via the web, completing tasks, taking quizzes, and participating in forums and chats with other students.

Charles Edge (no relation) spoke about the challenges of implementing directory services for educational institutions. One problem is that the term "directory services" cover a large amount of ground, from tracking users (both employees and students) to allowing single sign-on (SSO) into multiple machines and services throughout the school. The biggest challenge can be handling the sheer numbers of people to be tracked. Open source solutions do exist, OpenLDAP for storing the information, Kerberos for single sign-on and Simple Authentication and Security Layer (SASL) for extending the reach of the SSO into other services, but it is complex to configure and administer. For scalability and robustness in large installations, Edge suggests Microsoft's Active Directory, which was not a particularly popular opinion with the open source oriented audience.

The first day closed with a WIOS panel discussion, where six of the women presenting or showing at the conference discussed the issues facing women in open source. The discussion was informal and wide-ranging with a great deal of audience participation. Audience members asked questions as well as offered opinions and theories on why the participation of women is low and what can be done to make things better. No real conclusions were reached, as is usual for discussions of this topic; it is one of the more puzzling attributes of the free/open source community.

The animated and amusing Ubuntu community manager Jono Bacon gave a rousing keynote to start things off on Saturday. He tried to ensure that everyone was awake by leading a greeting in multiple languages (including Klingon). His main point was to describe the responsibilities of the various "factions" that jockey to determine the future of open source software—companies, distributions, and communities—trying to show that each has an important role. In fact, it is up to all constituents to ensure that the greater Linux ecosystem thrives and that each group works well with the others. It was all pretty much "motherhood and apple pie" stuff, but well described and illustrated—all with Chuck Norris to keep track of the score. Bacon did provide the quote of the show when he said that free software was "started by a guy with a beard who was pissed off at a printer".

Saturday was also the first day that the expo floor was open. Some 80 booths were there, representing companies large and small as well as lots of free software projects. One of the more interesting booths contained a working simulator of a 747 cockpit. All of the instruments were driven from a realtime Linux box and the FlightGear flight simulator was used to generate the cockpit window view. The two machines communicated over the network and various laptops were able to view the flight from other perspectives by getting updates from the simulator. It was rather impressive.

The linuxastronomy.org project was also on hand with their telescope prototype. The telescope will be controlled via a Linux machine allowing it to be pointed at locations as specified by users. A Linux desktop application will send locations to the telescope over the internet, allowing it to be remotely controlled so that it can be installed in a mountaintop or other location with (relatively) little light pollution and good viewing conditions. In addition, the project was demonstrating many of the free astronomy programs available for Linux.

A mobile audio studio product, Indamixx, did not have a booth, but could be seen all over the show. The company loaned two of the UMPC-based devices to the conference which were used to do podcasts of interviews with speakers and attendees. The device runs Linux with Audacity and ardour along with other free software. The company has tweaked things to make it all work well and be easy to use on the device. It looks to be quite capable as well as easily portable.

In another interesting talk, David Maxwell of Coverity gave an update on their project to scan free software for security holes. The US Department of Homeland Security gave Coverity a grant to work with free software projects to use the Coverity Prevent static code analysis tool (once known as the "Stanford Checker") on the code. The scan project has found over 7,000 defects in around a hundred free software projects since its inception. Maxwell is the Open Source Strategist for Coverity; he is looking for more projects to participate. He is encouraging any free/open source software project to get in touch with him to get signed up for the program.

Projects that join get their code scanned with a report being generated on the Coverity website for project members to view. The projects can then fix any of the issues that are actually bugs, mark others as "not a bug", and resubmit the code. The Coverity system will check the latest code out of their source code repository and check it again. Once all issues that the tool finds are handled, the project can move up to a higher "rung on the scan ladder" which will allow them to be scanned by more recent versions of the Coverity tool.

Bdale Garbee had perhaps the geekiest talk of the show on Saturday afternoon with "Open Avionics for Model Rockets". Garbee gave an overview of the hobby, which has gone far beyond the Estes rockets that many of us dabbled with in our youth. These rockets can go to 10,000 feet and above; just how high they go is one of the questions that led folks to start outfitting them with instruments. Deploying the recovery system—typically a parachute—at apogee is very desirable and a barometric sensor with a little bit of logic tied to the ejection charge can do just that. Unfortunately, all of the commercially available options for these systems are completely closed; even the protocol to talk to the device is not released by the manufacturers.

Garbee decided to once again combine one of his hobbies with open source to design and build an open device. Both the hardware and software will be released under free licenses (GPL and Open Hardware License); he had version 0.1 of the hardware (missing the accelerometer due to a problem in the board layout) with him at the show. The AltusMetrum system also has an onboard barometric sensor and will be able to support things like GPS devices and radio transmitters—so that lost rockets do not stay lost. Garbee expects to flight test the board and design version 0.2 of the hardware over the coming months.

Sunday's keynote, by Stormy Peters of OpenLogic was entitled "Would you do it again for free?". Peters looked at whether external rewards, usually money, affect the motivation of open source developers; in particular, if the pay stops, will the project work stop as well? She cited four separate "studies" (including two that weren't intended as studies) that seemed to show that adding a reward, or penalty, can sometimes have a counter-intuitive effect (see an entry in her weblog for more information).

Peters came to no firm conclusions about what the long-term effects of paying open source developers would be, but there are some mitigating factors that seem to provide hope that developers would continue if the paychecks stopped. When a payment or reward is in line with expectations for doing a particular task, it is much less demotivating. Also, if the payment is for working on the project, not tied to a specific goal or milestone, it is also less of a problem. Both of those are typically the case with folks who are paid—40% of open source developers are, according to Peters—for their work in the community.

After a last wander through the show floor, I was able to catch a few minutes of the talk given by Ken Gilmer and Angel Roman of Bug Labs describing their modular embedded Linux gadget building system. The system consists of a core module along with various plug-in devices: camera, motion detector, GPS, etc. that can be combined into a single Java programmable device. Many additional peripheral modules are planned. The software that runs on the device is free and Bug Labs has a community site to share application code; they are clearly hoping that they can foster a community of users and developers.

As can be seen, SCALE offers a wide variety of technical content in a well organized and fun conference. It has grown beyond the capacity of the Airport Westin where it has been held for the last few years; expect a new, bigger venue somewhere in LA next year. Over the last few years, SCALE has drawn from more areas of the southwest US in moving from a small, local conference to a regional one. If things continue, in another few years it may grow into a national conference; one can only hope that if that happens, it will continue to be as well run and interesting as it is today.

Comments (12 posted)

LCA: Two talks on the state of X

Keith Packard is a fixture at Linux-related events, so it was no surprise to see him turn up at LCA. His talk covered X at a relatively high, feature-oriented level. There is a lot going on with X, to say the least. Keith started, though, with the announcement that Intel had released complete documentation for some of its video chips - a welcome move, beyond any doubt.

There are a lot of things that X.org is shooting for in the near future. The desktop should be fully composited, allowing software layers to provide all sorts of interesting effects. There should be no tearing (the briefly inconsistent windows which result from partial updates). We need integrated 2D and 3D graphics - a goal which is complicated by the fact that the 2D and 3D APIs do not talk to each other. A flicker-free boot (where the X server starts early and never restarts) is on most distributors' wishlist. Other desired features include fast and secure user switching, "hotplug everywhere," reduced power consumption, and a reduction in the (massive) amount of code which runs with root privileges.

So where do things stand now? 2D graphics and textured video work well. Overlaid video (where video data is sent directly to the frame buffer - a performance technique used by some video playback applications) does not work with compositing, though. 3D graphics does not always work that well either; Keith put up the classic example of glxgears running while the window manager is doing the "desktops on a cube" routine - the 3D application runs outside of the normal composite mechanism and so cannot be rotated with all the other windows.

On the tearing front, only 3D graphics supports no-tearing operations now. Avoiding tearing is really just a matter of waiting for the video retrace before making changes, but the 2D API lacks support for that.

The integration of APIs is an area requiring some work still. One problem is that Xv (video) output cannot be drawn offscreen - again, a problem for compositing. Some applications still use overlays, which really just have no place on the contemporary desktop. It is impossible to do 3D graphics to or from pixmaps, which defeats any attempt to pass graphical data between the 2D and 3D APIs. On the other side, 2D operations do not support textures.

Fast user switching can involve switching between virtual terminals, which is "painful." Only one user session can be running 3D graphics at a time, which is a big limitation. On the hotplug front, there are some limitations on how the framebuffer is handled. In particular, the X server cannot resize the framebuffer, and it can only associate one framebuffer with the graphics processor. Some GPUs have maximum line widths, so the one-framebuffer issue limits the maximum size of the internal desktop.

With regard to power usage: Keith noted that using framebuffer compression in the Intel driver saves 1/2 watt of power. But there are a number of things to be fixed yet. 2D graphics busy-waits on the GPU, meaning that a graphics-intensive program can peg the system's CPU, even though the GPU is doing all of the real work. But the GPU could be doing more as well; for example, video playback does most of the decoding, rescaling, and color conversion in the CPU. But contemporary graphics processors can do all of that work - they can, for example, take the bit stream directly from a DVD and display it. The GPU requires less power than the CPU, so shifting that work over would be good for power consumption as well as system responsiveness.

Having summarized the state of the art, Keith turned his attention to the future. There is quite a bit of work being done in a number of areas - and not being done in others - which leads toward a better X for everybody. On the 3D compositing front, what's needed is to eliminate the "shared back buffers" used for 3D rendering so that the rendered output can be handled like any other graphical data. Eliminating tearing requires providing the ability to synchronize with the vertical retrace operation in the graphics card. The core mechanism to do this is already there in the form of the X Sync extension. But, says Keith, nobody is working on bringing all of this together at the moment. Getting rid of boot-time flickering, instead, is a matter of getting the X server properly set up sufficiently early in the process. That's mostly a distributor's job.

To further integrate APIs, one thing which must be done is to get rid of overlays and to allow all graphical operations (including Xv operations) to draw into pixmaps. There is a need for some 3D extensions to create a channel between GLX and pixmaps.

Supporting fast user switching means adding the ability to work with multiple DRM master. Framebuffer resizing, instead, means moving completely over to the EXA acceleration architecture and finishing the transition to the TTM memory manager. In the process, it may become necessary to break all existing DRI applications, unfortunately. And multiple framebuffer support is the objective of a project called "shatter," which will allow screens to be split across framebuffers.

Improving the power consumption means getting rid of the busy-waiting with 2D graphics (Keith say the answer is simple: "block"). The XvMC protocol should be extended beyond MPEG; in particular, it needs work to be able to properly support HDTV. All of this stuff is currently happening.

Finally, on the security issue, Keith noted the ongoing work to move graphical mode setting into the kernel. That will eliminate the need for the server to directly access the hardware - at least, when DRM-based 2D graphics are being done. In that case, it will become possible to run the X server as "nobody," eliminating all privilege. There are few people who would argue against the idea of taking root privileges away from a massive program like the X server.

In a separate talk, Dave Airlie covered the state of Linux graphics at a lower level - support for graphics adapters. He, too, talked about moving graphical mode setting into the kernel, bringing an end to a longstanding "legacy issue" and turning the X server into just a rendering system. That will reduce security problems and help with other nagging issues (graphical boot, suspend and resume) as well.

Mode setting is the biggest area of work at the moment. Beyond that, the graphics developers are working on getting TTM into the kernel; this will give them a much better handle on what is happening with graphics memory. Then, graphics drivers are slowly being reworked around the Gallium3D architecture. This will improve and simplify these drivers significantly, but "it's going to be a while" before this work is ready. The upcoming DRI2 work will improve buffering and fix the "glxgears on a cube" problem.

Moving on to graphics adapters: AMD/ATI has, of course, begun the process of releasing documentation for its hardware. This happened in an interesting way, though: AMD went to SUSE in order to get a driver developed ahead of the documentation release; the result was the "radeonhd" driver. Meanwhile, the Avivo project, which had been reverse-engineering ATI cards, had made significant progress toward a working driver. Dave took that work and the AMD documentation to create the improved "radeon" driver. So now there are two competing projects writing drivers for ATI adapters. Dave noted that code is moving in both directions, though, so it is not a complete duplication of work. (As an aside, from what your editor has heard, most observers expect the radeon driver to win out in the end).

The ATI R500 architecture is a logical addition to the earlier (supported) chipsets, so R500 support will come relatively quickly. R600, instead, is a totally new processor, so R600 owners will be "in for a wait" before a working driver is available.

Intel has, says Dave, implemented the "perfect solution": it develops free drivers for its own hardware. These drivers are generally well done and well documented. Intel is "doing it right."

NVIDIA, of course, is not doing it right. The Nouveau driver is coming along, now, with 5-6 developers working on it. Dave had an RandR implementation in a state of half-completion for some time; he finally decided that he would not be able to push it forward and merged it into the mainline repository. Since then, others have run with it and RandR support is moving forward quickly. It was, he says, a classic example of why it is good to get the code out there early, whether or not it is "ready." Performance is starting to get good, to the point that NVIDIA suddenly added some new acceleration improvements to its binary-only driver. Dave is still hoping that NVIDIA might yet release some documents - if it happens by next year, he says, he'll stand in front of the room and dance a jig.

Comments (69 posted)

Ten-year timeline part 5: Not just SCO

During this period, the business of Linux was relatively quiet - not that many acquisitions, but not many failures either. But quite a bit was happening around legal issues, copyright enforcement, and more...

• October 10, 2002: BitKeeper flames return as the non-compete clause in its license comes to light. The sendmail source distribution is trojaned.

BitKeeper flames were a more-or-less constant feature in those days, but BitKeeper became an established part of the kernel development process anyway. In the October 10, 2002 edition, your editor wrote: "If Larry McVoy (or his board of directors) wakes up hung over one morning and decides to end free access to BitKeeper, the show is over." That was, unfortunately, an example of your editor's crystal ball working rather better than usual.

The trojaning of sendmail was the first of a few such incidents. It looked like a scary trend for a while, but, in fact, the frequency of this kind of attack has dropped quite a bit in the intervening years.

• October 31, 2002: the first cryptographic code is finally merged into the Linux kernel. The first Reiser4 snapshot is posted.

• December 19, 2002: The Creative Commons project is launched. ElcomSoft (Dmitry Sklyarov's employer) is acquitted of DMCA violation charges. Kernel developers start to complain that the 2.5 feature freeze is thawing.

• January 16, 2003: The U.S. Supreme Court decides in favor of unlimited copyright term extensions. MandrakeSoft enters bankruptcy. The SCO Group starts making noises about its "Unix IP."

• January 30, 2003: SCO forms SCOSource and makes rather more dire noises about Linux.

By this point, there was a certain amount of discomfort over the direction SCO was taking. But nobody had any clue of just how weird it would actually get.

• February 6, 2003: The MS-SQL worm infects the net - in about 15 minutes. LWN begins its porting drivers to 2.6 series.

Remember the days of disruptive worms? MS-SQL was one of the scariest, in that it did most of its propagation in just a few minutes. We don't see to many worms like that anymore; contemporary crackers prefer to turn systems into zombies and rent them out.

• March 13, 2003: The SCO Group files a $1 billion lawsuit against IBM.

And so it began, with SCO telling the world that the Linux community could not possibly have achieved what it did unless the work had been stolen by IBM.

For the remainder of this retrospective, your editor will attempt to keep the number of SCO-related entries to a minimum. It has been quite an experience to go back and reread all of those McBride/Enderle/Boies/DiDio/Lyons/etc. quotes, and it is tempting to put them all here. But that temptation will be resisted; those who want to relive that bit of bizarre history in more detail can read the LWN pages directly or dig through the considerable resources at Groklaw.

SCO is about as scary as Y2K now, but, in 2003, the SCO suit was a frightening event. To many of us it seemed possible that, maybe, one out of thousands of developers might have slipped something improper into the kernel code base. And, in any case, we were under attack by a company with millions of dollars to burn and a loud-mouthed CEO. The whole thing cost us a lot of time and anxiety - and, for those most directly involved - money.

Nonetheless, your editor will reiterate his claim that, overall, the SCO attack has been good for us. We needed to improve our legal defenses; as Linux grew, there could be no doubt that people would attempt to use the legal system to grab a piece of the pie. In SCO we had an arrogant assailant with no substance; we were attacked by a clown. We got the ability to straighten up our processes, arrange better legal help, and prove that our code is clean without the inconvenience of facing a complaint with a bit of legitimacy. The community is now close to immune from copyright-based attack, and is much better poised to deal with similar attackers (patent trolls, for example) who could still do us some serious damage.

• March 27, 2003: Keith Packard is kicked out of the XFree86 core team. Red Hat Linux 9 - the last Red Hat Linux release - is announced.

• May 15, 2003: SCO suspends Linux sales and sends a warning letter to 1500 Linux users.

• May 22, 2003: The GNU and Ghostscript projects part ways. Microsoft buys a $10 million Unix license from SCO.

• May 29, 2003: Novell claims that it, not SCO, owns Unix. Kernel developers get upset about the fact that there has been no 2.4 kernel release for six months. The 2.5 kernel gets a reworked char device layer, IDE tagged command queueing support and the USB gadget subsystem - seven months into the 2.5 feature freeze. The city of Munich decides to move to Linux.

Novell's claim was clearly significant at the time, though it fell below the radar again for several months. In the end, of course, this was the factor which killed SCO. That is convenient, but almost unfortunate too: there would have been value in seeing the substance of SCO's claims demolished in court.

In these days of fast releases, it is interesting to consider that, for the first half of 2003, there were no stable kernel releases at all.

• June 19, 2003: Linus Torvalds moves to OSDL. The kernel gets a massively reworked ext3 filesystem - eight months into the feature freeze. SCO raises its claim for damages to $3 billion and "terminates" IBM's AIX license. Software patents return to the European Parliament.

• July 10, 2003: Andrew Morton moves to OSDL.

OSDL was often controversial in the Linux community, but nobody doubted that providing a home for developers like Linus and Andrew was a good thing. Until now, neither had held a job where working on Linux was their primary duty.

Meanwhile, few suspected how big the software patent battle in Europe would become - or that the anti-patent side would emerge victorious (for now).

• July 17, 2003: The 2.6.0-test1 kernel is released; it includes the new anticipatory disk I/O scheduler. Slackware celebrates its 10th anniversary. The Mozilla Foundation is created.

• July 24, 2003: Red Hat gets out of the boxed distribution business. Mozilla starts requesting donations from users.

Selling Linux in boxes was how Red Hat got going, so the end of that business was a clear sign that things had changed. The separation of Mozilla and AOL (which had bought Netscape) was a little scary at the time; it seemed that the project could fade away before the Mozilla browser became truly ready and that it was an Internet Explorer future for all of us. Things were a little lean at Mozilla for a while. Now that Mozilla is bringing in tens of millions of dollars every year, the idea that it once sought donations is amusing.

• August 7, 2003: Novell acquires Ximian. Red Hat files suit against SCO. SCO offers the "intellectual property license for Linux." SELinux is merged for the 2.6.0-test3 kernel.

• August 21, 2003: SCO shows some "copied code."

SCO, remember, "encrypted" its slides of "copied" code by switching them to a Greek font - a scheme which the community, somehow, managed to overcome. The code in question was straight from ancient Unix; it had been contributed by SGI, and had already been removed by the time it was revealed. After this, nobody worried that SCO might come up with the "millions of lines" of code that, it said, it could prove it owned.

• September 25, 2003: The Fedora project launches. Software patents pass in the European Parliament. Sun's Jonathan Schwartz says "We do not believe that Linux plays a role on the server. Period."

• October 16, 2003: Under pressure from the FSF and others, LinkSys releases source for its WRT54G routers.

Fedora started with all kinds of talk about what a community-oriented project it would be. The reality was rather slower in coming, but is beginning to be visible now. Meanwhile, Fedora was a useful (and used) distribution from the outset.

The LinkSys settlement was the result of a long battle. It was an important early GPL enforcement action which led to the creation of a number of distributions created for the sole purpose of doing interesting things on LinkSys routers. The ironic result is that LinkSys almost certainly sold quite a few more units than it would have if it had continued to hold on to the code.

• October 23, 2003: SCO gets $50 million from BayStar.

• November 6, 2003: Novell acquires SUSE. A fight erupts over the "Linux Gazette" name.

• December 24, 2003: SCO claims ownership of the Unix ABI. The 2.6.0 kernel is released. Red Hat acquires Sistina. The Mozilla Foundation asks for more donations.

2.6.0 took almost exactly three years after 2.4.0 came out. For the few developers who had observed the 2.4 feature freezes, their code - which could be four years old at this point - was only now making it into an official mainline release. It was not yet understood at this point, but, once 2.6.0 came out, the "new kernel development model" started to take shape. Never again would we go years between major stable releases.

• January 22, 2004: SCO files its "slander of title" suit against Novell. Linus gets dunked.

• January 29, 2004: UnitedLinux dies a quiet death. SCO sends a letter to the U.S. Congress. Version 2 of the Apache License is adopted.

• February 5, 2004: XFree86 leader David Dawes changes the project's license.

There had been trouble in XFree86 for a long time, but the license change brought it all to a head. This was the move which killed XFree86, led to the creation of the revitalized X.org, and, eventually, brought life back to X development.

• February 12, 2004: The Grumpy Editor makes his debut.

The first Grumpy Editor article was never intended to be the beginning of a series; your editor was simply grumpy that the Galeon browser had gone the route of many early GNOME 2.x applications: less configurability, fewer features, and worse performance. The persona proved popular with readers, though, and the Grumpy Editor has been making irregular appearances on LWN ever since.

• February 19, 2004: The Netfilter team settles its first GPL enforcement action in Europe.

• February 26, 2004: X11 development moves to the freedesktop.org project. MandrakeSoft is ordered by a French court to stop using the "Mandrake" name.

• March 4, 2004: SCO sues AutoZone and DaimlerChrysler. EV1Servers.Net buys an expensive SCO license - a move they certainly still regret. FreeS/WAN shuts down.

The attack on Linux users had been long foreshadowed - and feared. Regardless of the validity of its claims, SCO could certainly make life hard for Linux by attacking those who use it. The attacks were so laughable, though, that they had no appreciable effect, even in the short term.

• March 11, 2004: The Anderer memo surfaces, tying SCO to Microsoft. The tenth anniversary of the green card spam.

• March 18, 2004: Open Source Risk Management launches. MandrakeSoft files its plan to exit bankruptcy.

For those who don't remember, OSRM was a scheme to sell insurance against legal attacks to users of free software. But, by this point, nobody was all that worried about SCO, and OSRM never did take off. On the other hand, MandrakeSoft did succeed in getting out of bankruptcy and is still with us.

• March 25, 2004: BitMover claims that the pace of kernel development has doubled as a result of the adoption of BitKeeper.

This installment started with BitKeeper, and will end there. For all the complaints about BitKeeper and its associated "don't piss off Larry" license, few could contest the claim that kernel development was proceeding at a much faster pace. We needed a tool like that. To this day, it remains discouraging that we were not able to develop a distributed revision control system for ourselves until Larry McVoy and BitMover showed the way. If there was ever an itch in need of scratching, this was it.

The next installment (which will most likely appear two weeks from now) will start with April, 2004 and come fairly close to the present. Stay tuned.

Comments (4 posted)

Eee PC security or lack thereof

The Eee PC has garnered a lot of press for its small form factor, low weight, and solid-state disk, but it has also made a poor showing with security researchers. RISE Security released a report on the security of the Eee last week, showing that it can be subverted ("rooted") right out of the box from ASUS. Unfortunately, it is even worse than that as, even after updating an Eee using the standard mechanism, the hole is not patched.

The vulnerability identified by RISE is in the Samba daemon (smbd), version 3.0.24, which is installed and runs on stock Eee PCs. The vulnerability, CVE-2007-2446 was identified and patched last May, so the Eee is shipping with a version of Samba known to be vulnerable to an arbitrary code execution flaw for nine months or so. In itself, that is not completely surprising.

When hardware vendors install a distribution—or commercial OS like Windows—they tend to install the latest released version, which is likely to be out of date with respect to security issues. A vendor installing Fedora 8 or Debian etch today will be behind on countless security updates. But, unlike the Samba problem discovered on the Eee, updates do exist in the standard places. If the new user updates their system immediately, there is a fairly small window of vulnerability.

Unfortunately for Eee owners, the modified Xandros distribution that comes with it does not yet have an update for Samba. This leaves all Eee PCs vulnerable to being rooted by anyone on the same network. Since the Eee is meant as a mobile device, it likely spends a lot of its time connected to various public networks, especially wireless networks. The Eee makes an interesting target for attackers because it very well might have authentication information for banks or brokerages as well as other private or confidential files.

Some have seriously downplayed the threat but it is clear they don't understand it:

Sales of the Eee last year was around 300,000 units; large enough to be an attractive target for the malicious. Because there is not an update to close the hole, Eee users have to rely on other means to protect themselves. This eeeuser.com comment thread provides some of the better advice for dealing with the problem. Removing the Samba package seems to be the simplest, but fairly heavy handed, way to avoid the hole—but many folks need a working Samba. There is no way to disable Samba from the Eee GUI which is the way most owners plan to interact with the machine. This whole incident makes it seem like ASUS (and perhaps Xandros) are not terribly interested in the security of the machines that they sell.

There is a larger issue here. When the normal means of getting security patches comes from the same medium that is also the biggest security threat, there will always be windows of vulnerability. Even if hardware vendors diligently update the distribution they install, there is still some shelf-life and shipping time where security updates can be released. Various studies have shown that there may not be enough time to download patches before an unpatched system succumbs to an attack.

It is a difficult problem to solve completely. Any solution must be very straightforward and consistent so that unsophisticated users can be trained to do it as a matter of course. News about security issues needs to get more widespread attention as well, so that those same users know when the procedure needs to be followed. Firewalls and other network protections only go so far if the machine needs to reach out to the internet to pick up its updates.

If distributions provided some kind of blob (tar file, .deb, .rpm, etc.) that contained all of the security updates since the release, users could grab that from a different (presumably patched or not vulnerable) machine, put it on a USB stick or some other removable media and get it to the new machine. A utility provided by the distribution could then process that blob to apply all the relevant patches—all while the vulnerable machine stayed off the net. As the world domination plan continues, threats against Linux will become more commonplace; we need to try and ensure that users, especially the unsophisticated ones, can be secure in their choice of Linux.

Comments (22 posted)

Multi-threaded OpenSSH

Comments (24 posted)

clamav: arbitrary code execution

Comments (1 posted)

Doomsday: multiple vulnerabilities

Comments (none posted)

duplicity: password disclosure

Comments (1 posted)

firefox: multiple vulnerabilities

Comments (2 posted)

firefox: multiple vulnerabilities

Comments (none posted)

glib2: buffer overflow

Comments (none posted)

gnumeric: arbitrary code execution

Comments (none posted)

gnumeric: integer overflow and signedness errors

Comments (none posted)

java: multiple vulnerabilities

Comments (none posted)

kernel: insufficient range checks

Comments (none posted)

kernel: local root privilege escalation

Comments (1 posted)

kernel: memory access violation

Comments (none posted)

mailman: cross-site scripting

Comments (none posted)

moin: file overwrite via crafted cookie

Comments (none posted)

mozilla: multiple vulnerabilities

Here are the details from the Slackware 12.0 ChangeLog:
+--------------------------+
patches/packages/mozilla-firefox-2.0.0.12-i686-1.tgz:
  Upgraded to firefox-2.0.0.12.
  This upgrade fixes some more security bugs.
  For more information, see:
    http://www.mozilla.org/projects/security/known-vulnerabil...
  (* Security fix *)
patches/packages/seamonkey-1.1.8-i486-1_slack12.0.tgz:
  Upgraded to seamonkey-1.1.8.
  This upgrade fixes some more security bugs.
  For more information, see:
    http://www.mozilla.org/projects/security/known-vulnerabil...
  (* Security fix *)
+--------------------------+

Comments (none posted)

mplayer: multiple vulnerabilities

Comments (none posted)

netpbm: buffer overflow

Comments (none posted)

openldap: denial of service

Comments (none posted)

openldap: denial of service

Comments (none posted)

phpbb2: multiple vulnerabilities

Comments (none posted)

SDL_image: buffer overflows

Comments (none posted)

tk: buffer overflow

Comments (none posted)

tomcat: multiple vulnerabilities

Comments (none posted)

wml: multiple file overwrite vulnerabilities

Comments (none posted)

wordpress: remote editing via unknown vectors

Comments (none posted)

Kernel release status

As of this writing, a few dozen small fixes have gone into the mainline git repository since the -rc1 release.

The current stable 2.6 kernel is 2.6.24.2, released on February 10. This update contains a single patch fixing the vmsplice() vulnerability. 2.6.24.1 was released - with a rather longer list of fixes - on February 8.

For older kernels: 2.6.23.16 and 2.6.22.18 both come out on February 10; they, too, contain the vmsplice() fix. 2.6.23.15 was released on February 8 with a few dozen fixes. And 2.6.22.17, also with quite a few fixes, came out on February 6.

Comments (1 posted)

Quotes of the week

Comments (none posted)

Before the 2.6.25 merge window closed...

User-visible changes include:

• There are new drivers for SC2681/SC2691-based serial ports, Dallas DS1511 timekeeping chips, AT91sam9 realtime clock devices, Compaq ASIC3 multi-function chips, Cell Broadband Engine memory controllers, Marvell MV64x60 memory controllers, PA Semi PWRficient NAND flash interfaces, Marvell Orion NAND flash controllers, Freescale eLBC NAND flash controllers, Sharp Zaurus SL-6000x keyboards, Fujitsu Lifebook Application Panel buttons, IPWireless 3G UMTS PCMCIA cards, intelligent storage device enclosures, Winbond W83L786NG and W83L786NR sensor chips, Texas Instruments ADS7828 12-bit 8-channel ADC devices, and Sony MemoryStick cards.

• Also added are updated video drivers for Radeon R500 chipsets (2D acceleration is now supported) and Intel i915 chipsets (suspend and resume now work properly).

• Several more obsolete OSS audio drivers have been removed. The old mxser driver has also been removed in favor of mxser_new, now called simply "mxser."

• File descriptors returned by inotify_init() now support signal-based (using SIGIO) I/O. There is also a new notification event (IN_ATTRIB) sent when the link count of a watched file changes.

• The mac80211 (formerly Devicescape) wireless subsystem is no longer marked "experimental."

• The memory use controller for containers has been merged. This controller was described in this LWN article, but the patch has evolved somewhat since then and the details have changed. Some documentation can be found in Documentation/controllers/memory.txt.

• ACPI thermal regulation support has been added; see Documentation/thermal/sysfs-api.txt for details on how it works. The ACPI code also now supports the Windows Management Instrumentation interface, and uses that support to make recent Acer laptops work.

• ACPI now provides support for users who want to override their system's Differentiated System Description Table (DSDT).

• The XFS filesystem now supports the fallocate() system call.

• ATA-over-Ethernet (AoE) now properly supports devices with multiple network interfaces (and, thus, multiple paths to the host).

• Support for the MN10300 architecture (little-endian mode only) has been added.

• Support for a.out binaries has been removed from the ELF loader. Pure a.out systems will still work, though.

• Disk I/O statistics (as seen in /proc/diskstats and under /sys/block) have been augmented with more information about request merging and I/O wait time.

• The S390 architecture now implements dynamic page tables - processes will use 2-, 3-, or 4-level page tables depending on the size of their address space.

• The ext4 "in development" flag has been added; mounting an ext4 filesystem will now require an explicit "I know this might explode" option.

Changes visible to kernel developers include:

• Many nopage() methods have been replaced by the newer fault() API; the near-term plan is to remove nopage() altogether. See this article for a description of the new way of "page not present" handling.

• This cycle has also seen a bit of a reinvigoration of the long-stalled project to eliminate the big kernel lock. A number of BKL-removal patches have been merged, with more certainly to come.

• A generic resource counter mechanism was merged as part of the memory controller patch set; see <linux/res_counter.h> for the details.

• reserve_bootmem() has a new flags parameter. Most callers will set it to BOOTMEM_DEFAULT; the kdump code, though, uses BOOTMEM_EXCLUSIVE to ensure that it is the only one to touch the memory.

• Most architectures now have support for cmpxchg64() and cmpxchg_local().

• There is a new set of string functions:

      extern int strict_strtoul(const char *string, unsigned int base, 
                                unsigned long *result);
      extern int strict_strtol(const char *string, unsigned int base,
      	       		     long *result);
      extern int strict_strtoull(const char *string, unsigned int base,
                                 unsigned long long *result);
      extern int strict_strtoll(const char *string, unsigned int base,
                                long long *result);
  

  These functions convert the given strings to various forms of long values, but they will return an error status if the given string value, as a whole, does not represent a proper integer value. These functions are now used in the parsing of kernel parameters.

At this point, the merging of features is done (though there has been a bit of pushing for one or two things to slip in) and the stabilization period begins. With luck, that process will go a little more quickly than it did with 2.6.24.

Comments (7 posted)

linux-next and patch management process

It started with the announcement of the linux-next tree. This tree, to be maintained by Stephen Rothwell, is intended to be a gathering point for the patches which are planned to be merged in the next development cycle. So, since we are currently in the 2.6.25 cycle, linux-next will accumulate patches for 2.6.26. The idea is to solve the patch integration issues there and reduce the demands on Andrew Morton's time.

The question which was immediately raised was this: how do we deal with big API changes which require changes in multiple subsystems? These changes are already problematic, often requiring maintainers to rework their trees in the middle of the merge window. Trying to integrate such changes earlier, in a separate tree, could bring a new set of problems. There will be a lot of conflicts between patches done before and after the API change, and somebody is going to have to put the pieces back together again. Andrew does some of that now, but the problem is big enough that not even Andrew can solve it all the time. The bidirectional SCSI patches merged for 2.6.25 were held up as an example; that change required coordinated SCSI and block layer patches, and it never was possible to get the whole thing working in -mm.

Arjan van de Ven asserted that the only way to make large API changes work is to merge them first, at the beginning of the merge window. The merged patch would fix all in-tree users of the changed API, as is the usual rule. Maintainers of all other trees could then merge with the updated mainline, fixing any new code which might be affected by the API change. This is, essentially, the approach which was taken for the big device model changes in 2.6.25; they hit the mainline at the beginning of the merge window, then everybody else got to adapt to the new way of doing things.

Greg Kroah-Hartman worries that this approach is not sufficient, especially when live trees are being merged. If an API change in one tree forces a change to a separate tree, the coordination issues just get hard. Keeping the secondary changes in the primary tree risks conflicts with patches in the proper subsystem tree. Patches which reach across trees are also, increasingly, being discouraged as making life harder for everybody. But the fixup patch will not apply to its nominal subsystem tree as long as the API change itself is not there. In the -mm tree, this sort of problem is glued together by a series of fixup patches maintained by Andrew; Greg says that the linux-next tree would need something similar.

David Miller's suggestion was to resolve this sort of conflict through frequent rebasing of the -next tree. Rebasing is an operation (supported by git and other code management tools) which takes a set of patches against one tree and does what's required to make them apply to a different version of the tree. It can be quite useful for maintaining patches against a moving target - which kernel trees tend to be. David talked about how he rebases his (networking subsystem) trees frequently as a way of eliminating conflicts with the mainline and, in the process, cleaning some cruft out of the development history.

It turns out, though, that this frequent rebasing is not popular with the developers who are downstream of David. Rebasing the tree forces all downstream contributors to do the same thing, and to deal with any merge conflicts that result. It makes it much harder to prepare trees which can be pulled upstream and creates extra work.

This was where Linus jumped into the conversation and expressed his dislike of rebasing. He echoed the complaints from downstream developers that a constantly-rebased tree is hard to prepare patches against. It also confuses the development history, making changes to other developers' patches in silent ways. After somebody's patch set has been rebased, it is no longer the patches that were sent. So, says Linus:

It is about here that Andrew Morton commented that git does not appear to be matching entirely well with the way that kernel developers work. Some of the solution may be found in tools more oriented toward the management of patch queues - such as quilt. There may be a renewed push to get more quilt-like functionality built into git (along the lines of the stacked git project) in the near future.

Linus is also not entirely pleased with how the integration of patches only happens in the mainline:

His suggestion is that a separate git tree should be created to contain a large API change - and nothing else. Affected subsystem maintainers could then merge that tree and develop against the result. In the end, all of the pieces should merge nicely in the mainline.

This approach raises a number of interesting issues. The API-change tree has to be agreed upon by everybody, and it must be quite stable - lots of changes at that level will create downstream trouble. There must also be a high degree of confidence that this API-change tree will, in fact, get merged into the mainline; should Linus balk, everybody else's trees will no longer be applicable to the mainline. Replacing the current "tree of trees" patch flow with something messier could create a number of coordination issues. And there are fears that a mainline tree built from this process would fail to build in many of its intermediate states, which would make tools like "git bisect" much harder to use. Even so, it could be part of the long-term solution.

Linus also took the opportunity to complain about large-scale API changes in general:

He also stated that the costs of big API changes are high enough that we should, more often, stay with older interfaces, even if they are not as good as they could be. Others disagreed, claiming that Linux must continue to evolve if it is to stay alive and relevant.

The rate of change seems unlikely to fall in the near future. There may be some changes to how big changes are done, though. As suggested by Ted Ts'o, more changes could be done by creating entirely new interfaces rather than breaking old ones. With Ted's scheme, the old interface would be marked "deprecated" at the beginning of the merge window. Developers would then have the entire development cycle to adjust to the change, and the deprecated interface would be removed before the final release.

There is resistance to this approach, based on the observation that getting rid of deprecated interfaces tends to be harder than one would expect. But, still, it is a relatively painless way of making changes. The current transition (in the memory management area) from the nopage() VMA operation to fault() is an example of how it can work. Nick Piggin has been slowly changing in-tree users with the eventual goal of removing nopage() altogether. For now, though, both interfaces coexist in the tree and nothing has been broken.

Like the kernel itself, its development process is undergoing constant change and (hopefully) improvement. As the development community and the rate of change continues to grow, the process will have to adjust accordingly. What changes come out of this discussion remain to be seen. But it's worth noting that Andrew Morton fears that the biggest problem - regressions and bugs - will be relatively unaffected.

Comments (none posted)

vmsplice(): the making of a local root exploit

The splice() system call, remember, is a mechanism for creating data flow plumbing within the kernel. It can be used to join two file descriptors; the kernel will then read data from one of those descriptors and write it to the other in the most efficient way possible. So one can write a trivial file copy program which opens the source and destination files, then splices the two together. The vmsplice() variant connects a file descriptor (which must be a pipe) to a region of user memory; it is in this system call that the problems came to be.

The first step in understanding this vulnerability is that, in fact, it is three separate bugs. When the word of this problem first came out, it was thought to only affect 2.6.23 and 2.6.24 kernels. Changes to the vmsplice() code had caused the omission of a couple of important permissions checks. In particular, if the application had requested that vmsplice() move the contents of a pipe into a range of memory, the kernel didn't check whether that application had the right to write to that memory. So the exploit could simply write a code snippet of its choice into a pipe, then ask the kernel to copy it into a piece of kernel memory. Think of it as a quick-and-easy rootkit installation mechanism.

If the application is, instead, splicing a memory range into a pipe, the kernel must, first, read in one or more iovec structures describing that memory range. The 2.6.23 vmsplice() changes omitted a check on whether the purported iovec structures were in readable memory. This looks more like an information disclosure vulnerability than anything else - though, as we will see, it can be hard to tell sometimes.

These two vulnerabilities (CVE-2008-0009 and CVE-2008-0010) were patched in the 2.6.23.15 and 2.6.24.1 kernel updates, released on February 8.

On February 10, Niki Denev pointed out that the kernel appeared to be still vulnerable after the fix. In fact, the vulnerability was the result of a different problem - and it is a much worse one, in that kernels all the way back to 2.6.17 are affected. At this point, a large proportion of running Linux systems are vulnerable. This one has been fixed in the 2.6.22.18, 2.6.23.16, and 2.6.24.2 kernels, also released on the 10th. At this point, with luck, all of these bugs have been firmly stomped - though, now, we need to see a lot of distributor updates.

The problem, once again, is in the memory-to-pipe implementation. The function get_iovec_page_array() is charged with finding a set of struct page pointers corresponding to the array of iovec structures passed in by the calling application. Those pointers are stored in this array:

    struct page *pages[PIPE_BUFFERS];

Where PIPE_BUFFERS happens to be 16. In order to avoid overflowing this array, get_iovec_page_array() does the following check:

    npages = (off + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
    if (npages > PIPE_BUFFERS - buffers)
	npages = PIPE_BUFFERS - buffers;

Here, off is the offset into the first page of the memory to be transferred, len is the length passed in by the application, and buffers is the current index into the pages array.

Now, if we turn our attention to the exploit code for a moment, we see it setting up a number of memory areas with mmap(); some of that setup is not necessary for the exploit to work, as it turns out. At the end, the code does this (edited slightly):

    iov.iov_base = map_addr;
    iov.iov_len  = ULONG_MAX;
    vmsplice(pi[1], &iov, 1, 0);

The map_addr address points to one of the areas created with mmap() which, crucially, is significantly more than PIPE_BUFFERS pages long. And the length is passed through as the largest possible unsigned long value.

Now let's go back to fs/splice.c, where the vmsplice() implementation lives. We note that, prior to the fix, the kernel did not check whether the memory area pointed to by the iovec structure was readable by the calling process. Once again, this looks like an information disclosure vulnerability - the process could cause any bit of kernel memory to be written to the pipe, from which it could be read. But the exploit code is, in fact, passing in a valid pointer - it's just the length which is clearly absurd.

Looking back at the code which calculates npages, we see something interesting:

    npages = (off + len + PAGE_SIZE - 1) >> PAGE_SHIFT;
    if (npages > PIPE_BUFFERS - buffers)
	npages = PIPE_BUFFERS - buffers;

Since len will be ULONG_MAX when the exploit runs, the addition will cause an integer overflow - with the effect that npages is calculated to be zero. Which, one would think, would cause no pages to be examined at all. Except that there is an unfortunate interaction with another part of the kernel.

Once npages has been calculated, the next line of code looks like this:

    error = get_user_pages(current, current->mm,
		       	   (unsigned long) base, npages, 0, 0,
		       	   &pages[buffers], NULL);

get_user_pages() is the core memory management function used to pin a set of user-space pages into memory and locate their struct page pointers. While the npages variable passed as an argument is an unsigned quantity, the prototype for get_user_pages() declares it as a simple int called len. And, to complete the evil, this function processes pages in a do {} while(); loop which ends thusly:

	len--;
    } while (len && start < vma->vm_end);

So, if get_user_pages() is passed with a len argument of zero, it will pass through the mapping loop once, decrement len to a negative number, then continue faulting in pages until it hits an address which lacks a valid mapping. At that point it will stop and return. But, by then, it may have stored far more entries into the pages array than the caller had allocated space for.

The practical result in this case is that get_user_pages() faults in (and stores struct page pointers for) the entire region mapped by the exploit code. That region (by design) has more than PIPE_BUFFERS pages - in fact, it has three times that many, so 48 pointers get stored into a 16-pointer array. And this turns the failure to read-verify the source array into a buffer overflow vulnerability within the kernel. Once that is in place, it is a relatively straightforward exercise for any suitably 31337 hacker to cause the kernel to jump into the code of his or her choice. Game over. (Update: as a linux-kernel reader pointed out, the story is a little more complicated still at this point; this is an unusual sort of buffer overflow attack).

The fix which was applied simply checks the address range that the application is trying to splice into the pipe. Since a range of length ULONG_MAX is unlikely to be valid, the vulnerability is closed - as are any potential information disclosure problems.

This vulnerability is a clear example of how a seemingly read-only vulnerability can be escalated into something rather more severe. It also shows what can happen when certain types of sloppiness find their way into the code - if get_user_pages() is asked to get zero pages, that's how many it should do. Your editor is working on a patch to clean that up a bit. Meanwhile, everybody should ensure that they are running current kernels with the vulnerability closed.

Comments (91 posted)

Autodownloading considered harmful

It did not take long for others to point out the "autodownloader" facility shipped with the Fedora games spin now. This tool is needed to make certain games work where the game is free software, but it needs proprietary data to provide the full experience. Games like Quake3 and Rise of the Triad fit this description. With autodownloader, these games can be shipped with Fedora and the proprietary data will be fetched automatically on the destination machine. This scenario does not seem all that different than downloading a proprietary application like Google Earth and installing it.

The difference, as seen by the Fedora camp, is that autodownloader can only obtain data, not code. The fact that much of that data may, in fact, be code which is fed to a virtual machine within the game is sort of glossed over. In the discussion, it was also suggested that games requiring autodownloader should come with enough free data to be minimally usable, though that does not seem to have been enforced with great vigor. Alan Cox's suggestion that the real test should be "is it possible to create free data for this game?" makes some sense, but that is not the operative rule now.

Such a discussion cannot go on long, though, before somebody brings up the real sore point: CodecBuddy. This time, it was Hans de Goede who raised the issue:

According to Hans, there is no point in discussing autodownloader as long as CodecBuddy remains in the repository.

Outgoing Fedora leader Max Spevack is trying to organize a discussion aimed at reaching some sort of clarity on these issues. Christopher Blizzard had an interesting idea: hand more of the decisions about (and responsibility for) the shipping of problematic code to the upstream projects. The Miro project was held up as an example. Christopher's proposal has some echoes of the disintermediation of distributions discussion which was covered here last week. When it comes to patent-encumbered codecs, distributions like Fedora would happily accept disintermediation.

In the absence of a real solution to the patent problem, some sort of disintermediation may be the only workable answer for distributions like Fedora. They may not be willing to ship the code, but others are. So it's mostly just a matter of making the connection between those repositories and the users as straightforward and painless as possible. Spending time with search engines to find useful programs or data may build character, but it does not help create a useful or pleasurable Linux user experience.

Comments (2 posted)

Nexenta Core Platform 1.0 released

Full Story (comments: 11)

OpenSolaris Developer Preview 2 Available

Full Story (comments: none)

The Fedora 8 Xfce Spin

Full Story (comments: 3)

Fedora 9 Alpha Jigdo

Full Story (comments: none)

Fedora 8 20080204 Re-Spin

Full Story (comments: none)

Bits of the gnome 1.x removal effort

Full Story (comments: none)

UTF-8 manual pages

Full Story (comments: none)

Tcl/Tk release goals

Full Story (comments: none)

Fedora Board Recap 2008-FEB-06

Full Story (comments: none)

SuSE Linux Enterprise Server 8 enters Extended Maintenance

Full Story (comments: 3)

Fedora Weekly News Issue 119

Full Story (comments: none)

OpenSUSE Weekly News/9

Comments (none posted)

PCLOS Magazine #18

Comments (none posted)

Ubuntu Weekly Newsletter #77

Full Story (comments: none)

DistroWatch Weekly, Issue 239

Comments (none posted)

Extremadura 2008 Debian Work Meetings

Full Story (comments: none)

Ubuntu Developer Week

Full Story (comments: none)

Vector Linux 5.9: Light, fast Slackware-based distro (TuxMachines)

Comments (none posted)

The Chandler Project moves forward

The Chandler Project is a small-group collaboration application that is being produced by the non-profit Open Source Applications Foundation (OSAF). OSAF was founded by Mitchell Kapor. The foundation's History document reveals some background information. The project has been under development for a number of years. Version 0.1 of Chandler was announced in April, 2003.

From the Chandler FAQ entry on What is Chandler?

Chandler provides an all-inclusive view of personal information, it can operate on notes, email, tasks, appointments, events, contacts, documents and additional personal resources. The Chandler Desktop application provides a single user interface with the ability to enter, view, search, group and share all of the supported types of information. The software is cross-platform, it currently runs on the Linux, Windows and Macintosh platforms. The Chandler software is being distributed under version 2.0 of the Apache Software License.

The Chandler features document explains how the project is arranged:

The FeatureList document covers the Chandler capabilities in more detail, some screenshots are included. OSAF provides free access to the Chandler Hub, information there is available to any user with an account and a web browser. The Chandler Server provides a central store for locally managed information. There are some demo movies that show Chandler in action, some of the basic Chandler concepts and terms are explained:

Two new releases were recently announced, Chandler Desktop 0.7.4 and Chandler Server 0.12.0. The new Chandler Desktop change summary says: "The 0.7.4 release adds a Tip of the day feature and a German translation contributed by a user. The triage status behavior was improved to be more useful. There have been dozens of bug fixes across the application, as well as fixes to the build and testing infrastructures." The new Chandler Server change summary says: "This release supports a standalone WAR form of Cosmo ready to drop in to an existing Tomcat installation. A security issue allowing unauthorized access when a collection had been shared was fixed. A number of smaller bugs have also been fixed for Unicode usernames, error logging, and the calendar web UI."

Chandler is in an active phase of development. The software has evolved from an interesting concept to a functioning system in recent years. Organizations and individuals who have a need for some advanced management and communications capabilities should be able to find some benefits from using Chandler.

Comments (13 posted)

rsplib 2.4.0 beta4 released

Full Story (comments: none)

pgDesigner 1.2.0 released

Comments (none posted)

Postgres Weekly News

Full Story (comments: none)

SQLite 3.5.6 released

Comments (none posted)

OpenNMS: 1.3.10 Released (SourceForge)

Comments (none posted)

OpenSwing: 1.4.6 released (SourceForge)

Comments (none posted)

Ardour 2.3 released

Comments (none posted)

CLAM 1.2 released

Full Story (comments: none)

Chandler Desktop 0.7.4 released

Full Story (comments: none)

Chandler Server 0.12.0 released

Full Story (comments: none)

GNOME Software Announcements

• Accerciser 1.1.91 (code cleanup and translation work)
• Anjuta 2.3.4 (bug fixes and translation work)
• cheese 2.21.91 (new features, bug fixes and translation work)
• Clutter 0.5.6 (new features and bug fixes)
• Deskbar-Applet 2.21.91 (bug fixes and translation work)
• Devhelp 0.19 (bug fixes and translation work)
• Empathy 0.21.9 (new features, bug fixes and translation work)
• Evince 2.21.91 (bug fixes and translation work)
• Eye of GNOME 2.21.90 (bug fixes, documentation and translation work)
• gcalctool 5.21.91 (bug fixes and translation work)
• gdl 0.7.9 (documentation and translation work)
• GLib 2.14.6 (bug fixes and translation work)
• GLib 2.15.5 (new features and translation work)
• glibmm 2.15.4 (new features)
• glibmm 2.15.5 (bug fix)
• gnome-applets 2.21.91 (new features, bug fixes and translation work)
• gnome-build 0.2.2 (bug fixes and translation work)
• gnome-games 2.21.91 (new features, bug fixes, documentation and translation work)
• gnome-keyring 2.21.91 (new features, bug fixes and translation work)
• Gnome-schedule 2.0.2 (bug fixes)
• gnome-settings-daemon 2.21.91 (new features and bug fixes)
• GTK+ 2.12.8 (new features, bug fixes and translation work)
• Gtk2-Perl 2.21.91 (new features, bug fixes and documentation work)
• Hotwire 0.710 (new features and bug fixes)
• metacity 2.21.8 (new features, bug fixes and translation work)
• mousetweaks 2.21.91 (new features, bug fixes and translation work)
• Orca 2.21.91 (new features, bug fixes and translation work)
• PyClutter 0.5.2 (bug fixes and code cleanup)
• Tomboy 0.9.6 (bug fixes and translation work)

Comments (none posted)

KDE Software Announcements

• AmarokPidgin 0.1.8 (new features and bug fixes)
• Convert 2 Video MP4 1.0 (initial release)
• Kate Gtags 1.3 (new features)
• kmando 1.5 (new features and bug fixes)
• kmando 1.6 (new feature)
• KMediaFactory 0.6.0 (new features and code cleanup)
• Manslide 1.9.11 (new features, bug fixes and translation work)
• Manslide 1.9.12 (new features and code cleanup)
• Manslide 1.9.13 (new features, bug fixes and translation work)
• Soprano 2.0.1 (bug fixes)

Comments (none posted)

Xorg Software Announcements

• xf86-input-acecad 1.2.2 (bug fixes)
• xf86-video-intel 2.2.0.90 (new features and bug fixes)
• xsel 1.1.0 (new features and bug fixes)

Comments (none posted)

StorYBook: Version 0.4.2 released (SourceForge)

Comments (none posted)

gEDA/gaf 1.4 released

Comments (none posted)

Wine 0.9.55 released

Comments (none posted)

Claws Mail 3.3.0 announced

Comments (none posted)

Open Movie Editor 0.0.20080209 released

Comments (none posted)

Mozilla Links Newsletter

Full Story (comments: none)

SANE-Backends 1.0.19 released

Comments (none posted)

LLVM 2.2 released

Full Story (comments: 15)

Caml Weekly News

Full Story (comments: none)

Perl is now Y2038 safe (use Perl)

Comments (none posted)

This Week on perl5-porters (use Perl)

Comments (none posted)

Zend Weekly Summary

Comments (none posted)

libLASi 1.1.0 is released

Full Story (comments: none)

Python-URL! - weekly Python news and links

Full Story (comments: none)

Tcl-URL! - weekly Tcl news and links

Full Story (comments: none)

RNV: 1.7.10 released (SourceForge)

Comments (none posted)

MicroNova YUZU 20080211 released (SourceForge)

Comments (none posted)

GIT 1.5.4.1 announced

Full Story (comments: none)

Yet Another Language Compiler: Stable version released (SourceForge)

Comments (none posted)

Interview with Nicholas Reville About Miro and Open Media, by Sean Daly (Groklaw)

Comments (none posted)

DNS Inventor Warns of Next Big Threat (Dark Reading)

Comments (24 posted)

LiMo Muddies the Mobile Linux Waters (PC Magazine)

Comments (none posted)

Zvents releases open-source cluster database (LinuxWorld)

Comments (none posted)

Linux, we have a PR problem (ITnews)

Comments (19 posted)

Interview: Mark "Markey" Kretschmann (Not the Gentoo Weekly News)

Comments (79 posted)

Interview with Michael Shiloh of OpenMoko (SCALE)

Comments (4 posted)

Virtualization in Linux: A Review of Four Software Choices (Techthrob.com)

Comments (21 posted)

A "state of open source" message from Bruce Perens

Comments (none posted)

Misys to release Open Source Code at SCALE

Comments (none posted)

Novell announces SiteScape acquisition

Comments (none posted)

Purple Labs announces sub-$100 LiMo feature phone

Full Story (comments: none)

STMicroelectronics' Nomadik multimedia processor adds Linux and Trolltech application environment

Comments (none posted)

SYSOPENDIGIA releases source code of its 3G Linux smartphone

Comments (4 posted)

Trolltech announces support for mobile touch screens Devices

Full Story (comments: none)

Trolltech's Qt WebKit Integration brings Web 2.0 services to mobile phones

Full Story (comments: none)

Vimicro launches Vinno-III open mobile platform

Comments (none posted)

Ajax: The Definitive Guide -- New from O'Reilly

Full Story (comments: none)

Rails for PHP Developers--New from Pragmatic Bookshelf

Full Story (comments: none)

Wicked Cool PHP--New from No Starch Press

Full Story (comments: none)

AMD's open GPU documentation site

Comments (18 posted)

FSFE Newsletter

Full Story (comments: none)

DreamWorks wins an award for its innovative use of Linux (c|net)

Comments (5 posted)

Minutes for GNOME Foundation directors meeting

Full Story (comments: none)

Perl 6 Design Meeting Minutes (use Perl)

Comments (none posted)

January PSF board meeting minutes are available

Full Story (comments: none)

CMG'08 Conference call for papers and presentations

Comments (none posted)

Meet the KDevelop Crowd (KDE.News)

Comments (none posted)

Northern California installfest for schools

Comments (none posted)

Events: February 21, 2008 to April 21, 2008

If your event does not appear here, please tell us about it.