UpFront

1. Number of minutes per day Britons spend watching TV: 148

2. Number of minutes per day Britons spend using the Net: 164

3. Millions of Weblogs as of March 9, 2006: 30.5

4. Millions of RSS feeds, worldwide: 70

5. Number of generations back that all humans have the same ancestors: 120

6. Trillions of dollars in the latest US federal budget: 2.8

7. US federal credit limit, in trillions of dollars: 9

8. Total billions of searches by Americans in January 2006: 5.48

9. Millions of households promised fiber broadband by 2006: 86

10. Promised symmetrical fiber performance in Mbps by 2006: 45

11. Average monthly dollar price promised for home fiber service by 2006: 50

12. Dollar prices for 100Mbps service found in Japan and Korea today: 40

13. Worldwide position of US in broadband deployment in 1996: 1

14. Worldwide position of US in broadband deployment in 2005: 16

15. Estimated billions of dollars lost to customers of failed US fiber deployments: 200

16. Estimated trillions of dollars lost to the US economy by failed fiber deployments: 5

17. Percentage of local authorities using Linux in the UK: 33

18. Percentage of local authorities using Linux in France: 71

19. Percentage of local authorities using Linux in Holland: 55

20. Percentage of local authorities using Linux in Germany: 68

1, 2: Guardian Unlimited, from a Google survey

3: Technorati

4: SocialText

5: Slate and Nature

6, 7: Washington Post

8: Center for Media Research

9–16: CAZITech, TeleTruth.org

17–20: John Dwyer in Industry (UK)

From Tom Limoncelli (an engineer with Google and co-author of Time Management for System Administrators) comes an enthusiastic welcome for Jifty, a Web application development framework. Tom says Jifty is “like a Ruby on Rails for Perl”. It comes from from Jesse Vincent, David Glasser and Alex Vandiver. Jesse will be familiar to fans of Request Tracker—an open-source CRM.

Find it at Jifty.org and CPAN.org.

Don't build your own kernel. It's a great way to waste a month of your time.

The main reason for using BSD is that you work at Yahoo. Otherwise, use Linux.

Premature optimization is the root of all evil.

—Cal Henderson, on building Flickr on Linux. Flickr is now owned by Yahoo, most of which runs on Yahoo's BSD (conferences.oreillynet.com/cs/et2006/view/e_sess/8068

REST is the Unix pipe of the net.

—Kevin Marks, on IRC at a conference

Daddy, you have a picture of the Internet on your shirt.

—Six-year-old daughter of Phil Windley, on his lap while he wore a Firefox shirt

Open source development violates almost all known management theories.

—Marletta Baba, Dean of the College of Social Sciences, Michigan State University (source: Greg Kroah-Hartman in www.kroah.com/linux/talks/oscon_2005_state_of_the_kernel)

Keep Your Exits Open: How Startups & Their Investors Can Minimize the Risk of Using Open Source Code

—Title of a Dow Jones Virtual Seminar on March 20, 2006

Make Business Fast, Easy and Risk-Free: What Free and Open Source Software Does to Liberate Free Markets

—Title of a virtual seminar proposed by Doc Searls to Dow Jones (Source: Andrew Leyden and Doc Searls)

Given Ruby's recent surge in popularity, linuxjournal.com is excited to bring readers The Gemcutters Shop (TGS), a new column that will focus on the Ruby community and a variety of Ruby programming topics. Regular linuxjournal.com author and active Ruby contributor Pat Eyler will show us how to develop skills related to Ruby programming, use libraries from Ruby's standard library, work with additional libraries and use applications written in or for Ruby.

Don't miss Pat's kick-off column, “Welcome to the Gemcutters Shop”, available at www.linuxjournal.com/article/8921. Upcoming columns will use code and case studies to demonstrate rcov, Rake, RubyGems, Mr. GUID and much more.

We're in the middle of tradeshow mania right now—pick a topic and a city, and we're pretty sure some sort of tech event is on its way. Use our Linux Industry Events calendar (www.linuxjournal.com/xstatic/community/events) to stay on top of all this year's tradeshows and conferences, from ISPCON Spring 2006 to the USENIX LISA Conference.

Do you have a great tutorial or how-to article you want to share with an eager audience? Are you looking to unveil your coding masterpiece or helpful tricks? Did you test drive the latest version of a top-three distro and want to tell us what you really think? We're always looking for interesting and unique article proposals. Send your ideas to webeditor@ssc.com.

With the imminent advent of version 3 of the GNU General Public License, the question naturally comes up whether Linux will continue to be licensed under version 2, or migrate to version 3. The answer seems to be that no migration will occur. Even if Linus Torvalds wanted to, he does not control the copyright of all the thousands upon thousands of code contributions that have gone into the kernel over the years, and only those copyright holders could authorize a license change for their own contributions. Although attempts to track down all the contributors and obtain permission have been made by optimistic souls, it is virtually impossible to do this. The GPL version 2 will be the Linux kernel license for the foreseeable future.

Meanwhile, more and more kernel variables and functions are being set to operate only with GPLed third-party drivers. The kernel can do this by testing any driver to see if it sets a variable indicating the license under which its code is released. If the license is the GPL, the kernel allows access to those restricted symbols. Otherwise, it's denied. This recently bit AVM, when Greg Kroah-Hartman restricted the USB subsystem to operate only with GPLed drivers. AVM always had released its own binary-only driver for its hardware, but this new change stopped it in its tracks. The change itself was reverted out of the kernel, although it did turn out that one reason Greg had implemented that change was because it has been possible for some time now to write USB drivers in user space with no loss of speed. Regardless, one result of this particular confrontation was for Greg to implement some logging infrastructure, so that symbols soon to be GPL-restricted would be clearly identified in the logs at runtime, and sysadmins on those systems could begin to make reasonable preparations for that change.

Willy Tarreau has begun gathering together useful 2.4 patches and making them available at a central location. In general, there has been an outcry among some users that without the even/odd development dichotomy, and with 2.4 virtually stationary, there is now no stable series that is still reasonably up to date with current features. Arguments by the kernel developers that distributions take care of kernel stability, and that the w.x.y.z tree was created specifically to address the issue of stability, are unconvincing for one key reason. Although it's true that those kernels may get good uptime, their behaviors are still potentially inconsistent from version to version—that is, the code base itself is unstable, making it difficult for user-space developers to create systems that behave reliably for the services they require. Although it seems clear to me that eventually kernel development will have to give stability first-class consideration, so far there is no real movement in that direction among the top developers. This may be one reason why Willy's foray back toward 2.4 maintenance has come about.

The IDE driver may be going away at some point in the medium future, as libata becomes more and more robust, and a more viable replacement for it. Alan Cox is confident that, although now is still not the time for a straightforward replacement, it is still the goal and the intention of ongoing libata development. It's important to bear in mind, when considering this, that the IDE nightmare cannot be ended simply by replacing one set of code with another. The IDE standards are still (and will continue to be) a horrible mess, and vendor interpretation and compliance with those standards is still (and will continue to be) extremely nuanced and difficult to support. So whatever the future of IDE may be, it will have to accommodate all the twists, turns, bumps and punctures endured in the past. Even if all future IDE hardware magically conformed to a single sane standard, it would be quite some time before we could abandon support for all the older hardware.

The Reiser 4 filesystem has not unexpectedly run into problems being accepted into the Linux kernel. After the most recent flame war, which had some developers throwing up their hands and saying they refused to give feedback on ReiserFS patches until Hans Reiser stopped attacking them, responses to ReiserFS posts on the mailing list have thinned out. Without the support of the kernel developers, the possibility of Reiser 4 going into the kernel becomes more problematic. Only the kernel developers fully grasp the requirements that any given patch must meet in order to be accepted into the tree. Without their guidance, Reiser 4 may have a hard time moving in the right direction. And as Reiser 4 development continues to diverge from the kernel proper, the patch that must ultimately be accepted into the kernel grows as well, adding much to the work required for final integration. Almost certainly Reiser 4 will make it into the kernel eventually, but probably not before its developers solve the technical and social issues that confront them.

At the Austin BarCamp in March 2006, I found myself sitting next to a guy with a large new laptop that seemed to be running some kind of Linux. Turned out his name was Matt Lawrence, his laptop was a new Dell Inspiron 9300, his job was systems administration and his Linux of choice was CentOS.

Matt Lawrence with his Dell Running CentOS

I asked him about it. Here are my notes, all quotes:

We'd appreciate hearing about your experiences with CentOS as well.