LWN.net Weekly Edition for July 15, 2010

Free software in production use on Ben Franklin Day

The Journal Register Company (JRC) owns newspapers around the United States, and like many print media companies is looking to adapt its business and news-gathering models for the Internet era. On July 4th, 18 of JRC's papers published print and online editions using a "free" and "open" workflow, in homage to the Independence Day holiday. Dubbed the Ben Franklin Project, the effort combined crowdsourcing, interactive news gathering, and free software.

JRC's Vice President of Content Jon Cooper provided an overview of the processes used by the various papers, including letting citizens suggest story ideas and improvements, posting story budgets, incorporating interactive online content, and using social media tools to gather news, not just to publicize it. That dimension focused mostly on engaging the local community with the newsroom staff, in a sense opening the process of producing the news. Of more interest to LWN readers, perhaps, was the decision to only use a free toolchain to produce the final product.

Slashdot picked up a blog post from one of the papers, The Saratogian, which outlined the use of the desktop publishing tool Scribus, the SeaShore image editor (a Mac OS X raster editor based originally on GIMP code), WordPress, and Google Docs. The story submitter and several commenters seemed to come away from the post with the impression that the newspaper found the software not-ready-for-prime-time, latching on to a quote four paragraphs in that said: "The proprietary software is designed to be efficient, reliable and relatively fast for the task of producing a daily newspaper. The free substitutes, not so much."

Scribus and other free software applications

When you look at the reports of all of the participating papers and JRC itself, however, it is clear that the above comment is not to be taken too seriously. All eighteen participating papers published their Scribus-built editions on time, and with positive results.

To be sure, a few encountered trouble along the way. The Delaware County Times live-blogged page layout, noting at one point that the program was crashing whenever the editor attempted to import a particular image, and mentioning the time involved in finding specific fonts, but the staff ultimately finished the issue. The Saratogian noted that the most time-consuming process was reproducing the paper's page templates in Scribus. But the New Haven Register, Oneida Dispatch, the Daily Local News, the other papers, and JRC management reported that the experiment was a success.

The papers spent a month prior to Ben Franklin Day training staff on Scribus, both with the official documentation and with third-party online tutorials. Editor Jack Kramer of the New Haven Register said that the staff adapted to Scribus "pretty quickly," but that, although the documentation was important, what proved more important were the in-house training and support groups that the paper formed, which worked together and "perfected the program usage."

Karl Sickafus of the Daily Local called Scribus "arguably, the single most valuable find of the Ben Franklin project" and wrote that his staff even went so far as to write custom scripts to import content from the paper's database directly into Scribus. He then speculated that such a system could easily replace the proprietary ad tracking, advertising, and editorial systems JRC uses today.

Kramer and several of the other editors mentioned using both GIMP and SeaShore for image editing, though Kramer noted that his photo editor was not "totally satisfied" with SeaShore. All of the participating papers published their content to a mirror site running Wordpress in addition to their regular web site. In an interesting footnote, the Slashdot debate veered into an argument over the oft-cited issue that the name "The Gimp" (though the project uses "GIMP" these days) is off-putting or offensive, and drives potential users away without even trying it. When asked whether anyone at the New Haven Register was bothered by the name, Kramer replied simply "not at all."

Google Docs and other missing pieces

Some of the papers (such as The Morning Sun) used Open Office for story writing, but Google Docs was widespread. Predictably, in the Slashdot story and in several of the comment threads on the individual newspaper sites, free software advocates took issue with the decision to use Google Docs in a "free software" experiment, noting accurately that the tool is not open source or free software.

Indeed, several of the papers blur the line between "free to use" and "software freedom," a mistake certainly not limited to this particular field. An anonymous New Haven Register staffer provided more background on that decision in a comment on the paper's blog, saying "We ordinarily write our stories in a content-management system that costs money for us to use, and its purpose is to manage content for the print edition only — not our website."

Because it was used to replace a content management system (CMS), presumably the critical feature of Google Docs was collaborative editing in this case, so the lack of it in the other open source tools led to Google Docs adoption. That includes WordPress, which the papers used to publish their online editions. Although multi-user editing is possible in WordPress, the newsrooms evidently found it lacking. The newsroom-oriented CMS Campsite may simply have been overlooked.

It is also interesting to note what other free-to-use proprietary applications were selected; this is real-world feedback that the open source community should take note of. Most of the papers used existing social networks like Facebook and Twitter to solicit feedback from the local community. Almost all used video, but chose proprietary video editing and hosting tools. Finally, though the papers used SeaShore to edit photographs, it appears that none used a free raw conversion tool — perhaps because, as SeaShore indicates, the photo staff is equipped with Mac OS X, for which the free raw converters do not provide regular builds.

News for tomorrow

Having read all of the available accounts of open source's performance on Ben Franklin Day (some papers have yet to publish results online), Scribus and the other applications seem to have performed well. What happens next is the challenge. Sickafus observed:

He advocates devoting financial resources that would be spent on proprietary content management and ad systems instead to adapting open source solutions. Reporter Ron Nurwisah recommends essentially the same thing, looking at the cost of dozens of licenses for Adobe products. Neither position would surprise long-time free software advocates; still, it is refreshing to witness an industry realize the potential of open source software.

JRC has kept its Ben Franklin Project WordPress site active since July 4th, posting discussions on where the company needs to go next, and exploring other open source applications. In addition, Cooper recently wrote to the Scribus mailing list to initiate a dialog with the development team about what the papers had learned. There is still no official announcement from any of the papers about the permanent addition of open source to their newsrooms. Based on the results so far, though, an announcement like that may not be all that far off.

[ Our thanks to Jay R. Ashworth for pointing us in the direction of this topic. ]

Comments (5 posted)

A guide to successful FOSS conference presentations

We just wrapped up the Ohio LinuxFest call for presentations, so pitching presentations is on my mind. Regional, volunteer-run conferences are not only a good way for people without a travel budget to see some big names in open source, they're also a way for first-time or inexperienced speakers to hone their presentation skills. Regional conferences also provide an excellent forum to educate users about your favorite project or topic.

But competition for speaking slots can be fierce. Established conferences like SCALE, Ohio LinuxFest, and others receive many more proposals than available slots. For example, the 2010 call for presentations for Ohio LinuxFest received about 120 proposals for less than 30 speaking slots. Some of the talks for regional conferences will quickly go to experienced speakers who have presented at the show before and/or have established a name for themselves as a topic expert and competent presenter. But most presentation committees for community shows also try to select local talent who are new to presenting, and those slots will go to the speakers with the best proposals.

Pitching your Proposal

"Submit early and often" is a good rule of thumb. Speakers should develop at least two presentation ideas, and submit them as early as possible — certainly well before the deadline. It's usually a bad idea to wait until the last minute to submit a proposal. In some cases, the committee takes note of which talks come in early. Even if that isn't the case, waiting until right before the deadline usually means that the proposal you submit will not be of the same quality as a proposal developed over the space of a few days. Submitting multiple talks boosts your chances if the committee likes you as a speaker, but doesn't like one of your topics or has to choose between you and another speaker who submitted a similar topic.

Presentation titles should be descriptive, short, and ideally something that will grab the attention of the presentation committee. A title like "Improving Kernel Contributions" is good, but "Anatomy of a Failure" was likely to garner more attention.

No matter how good the presentation title, the abstract has to live up to it, provide the committee with enough information to understand what the talk is about, and convince them that you'll put in the preparation time. There's little confidence that a prospective speaker who submits a one-sentence proposal is going to put in the time necessary to deliver a really excellent talk. And that is the goal of any good presentation committee: filling the schedule with talks that are not merely adequate, but ones that are excellent.

An excellent abstract explains what the topic is, the scope of the talk, and what the audience will learn during the presentation. The last is particularly important. Many submissions merely describe the topic, but the best submissions explain what the audience will gain from attending the talk.

Most calls for presentations will also seek a biography. Writing a biography is often an unpleasant exercise, but it's the best opportunity to show the presentation committee that you are actually the right person to present a given topic. Or not. If two people submit an "Introduction to Fedora" presentation, one of them being Paul Frields, guess who's most likely to be awarded the slot? This is another reason to think hard about your topic, pitch more than one idea, and try to choose something unique.

Feel free to contact the chair of the presentation committee if they're listed on the Web site and you need clarification on what the committee is looking for.

Preparing the Talk

Don't make the mistake of starting with slides when preparing a presentation. In fact, you probably shouldn't be at the computer at all when preparing the first draft of your presentation. Instead of firing up OpenOffice.org Impress or creating slides using LaTeX's Beamer class, grab a stack of index cards and head off to somewhere quiet.

For most presentations, you should have an introduction that describes what the audience will learn and the key ideas or information you want to impart. For a standard 60-minute slot, you should focus on no more than three to five major ideas.

Once you've mocked up your talk on paper, then it's time to start preparing slides. Use whatever tool you're most comfortable with but avoid writing out the entire talk on your slides. Your audience is not there to read your presentation, they're there to watch and hear you. Many presenters tend to cram slides with information and then stand in front of the audience reading the slides. This is a sure sign of a talk that will put the audience to sleep. If your audience can glean as much information from the slides as your actual presentation, you're not doing your job as a presenter.

With some exceptions, such as highly technical talks that require code examples or other supporting text, your slides should be uncluttered and only contain the basic ideas of what you're saying. Slides exist to support the speaker, not the other way around.

Also, a word of advice about technical problems. Come prepared to give your talk with no slides at all. If your laptop fails, the projector dies, or any other audio/visual catastrophe occurs, you should be able to give a talk with no slides at all. The best bet is to have index cards or a bulleted list of ideas that you can use to refresh your memory if showing the slides fails for some reason. Again, if by the day of your presentation you're not ready to do the presentation sans slides, you have failed to prepare adequately.

This is a lesson I learned the hard way at FOSDEM. Giving a talk on openSUSE, I was too used to referring to the slides and not comfortable giving the talk extemporaneously — despite knowing the topic cold. The projector and sound system developed a major glitch, so I was forced to work with no slides. I gave a substandard talk because I didn't have adequate paper backup and hadn't practiced the talk enough. Max Spevack followed my talk and had the same A/V problems that I had, but was able to do a fine talk using his notes. That was the last time I walked into a room to present without being fully prepared to give a talk with no slides at all.

The more practice you have, the better. Don't simply read through slides at the computer. Stand up and practice delivering your presentation out loud, preferably while looking at a mirror. If you have a willing audience, practice in front of them. Focus on making eye contact, smiling, and speaking at a slower pace than usual.

Remember that people are far more likely to remember the overall tone of the talk and general topics than details. If you're hoping to impart every detail of developing with Django in 60 minutes, you'll probably fail. Emphasize a few key concepts that you'd want attendees to remember, and focus on delivering an enjoyable presentation.

Timing is extremely important. Practice the timing so that you have enough material to fit the time, minus time for questions and answers, and no more. A common mistake is to show up with far more material than is possible to present in the time allotted. This not only robs the audience of the chance to ask questions, but also means you probably won't do a good job of presenting all of the material.

Presenting

The other reason to practice extensively is to calm your nerves. Most people find public speaking unsettling to some degree, but knowing the presentation (and topic) backwards and forwards goes a long way towards making public speaking more comfortable. See Scott Berkun's Confessions of a Public Speaker for some excellent anecdotes and rationale why people find public speaking so uncomfortable, as well as expansive advice on improving speaking skills.

It's important to remember that most audiences are friendly and wish to see a good talk. They do not expect you to be a great entertainer or to exhibit unnatural brilliance. Focus on making eye contact, speak slowly, and pause from time to time to gather your thoughts. Don't be afraid of a moment or two of silence.

Do be conversational and vary your tone; try to engage the audience. Don't be afraid to ask questions, as it's a good idea to try to get the audience to focus on you rather than the slides or (worse) their cell phones and laptops.

Giving a good presentation is not rocket science, or even kernel development. It is, however, a fair amount of work. Expect to spend at least ten to fifteen hours developing and practicing a good presentation. If it's your first, you might want to put in even more time.

This might sound like a lot of work for an hour in front of an audience, but it's well worth it. You'll find that you learn a great deal about a topic, even one you're an expert in, by preparing to deliver a presentation.

Comments (27 posted)

Author interview: UNIX and Linux System Administration Handbook

One of the best references for Linux and UNIX system administrators over the years has been the "Handbooks" (either Linux Administration Handbook (LAH) or UNIX System Administration Handbook (USAH) at various points). But the last edition was published in 2000 (as USAH), and included information on then-current Red Hat Linux 6.2 and FreeBSD 3.4. A new, updated version, UNIX and Linux System Administration Handbook, Fourth Edition (ULSAH), is due out any day now, and the principal authors, Evi Nemeth, Garth Snyder, Trent R. Hein, and Ben Whaley, agreed to answer some questions for LWN readers. Below are their answers on the book, the impact of Linux, the future for UNIX and Linux, and more.

LWN: Could you all please introduce yourselves? What are you working on when you're not writing system administration books?

LWN: The new version of the Linux Administration Handbook is on its way. When can we expect it, and what are you most excited about in this edition?

LWN: What led to the decision to combine the UNIX and Linux versions of the book?

LWN: A lot of old-time Unix folks were taken by surprise when Linux hit the scene. You've seen a lot of Unix variants come and go; what, do you think, accounts for the way that Linux has been able to displace Unix in so many settings?

LWN: What do you think is the future of "true" Unix?

LWN: Is the success of Linux a good thing? Or would we be better off now if some version of Unix had established itself more strongly in the open-source era?

LWN: If you could command the Linux development community to do one thing that would make life easier for system administrators, what would it be?

LWN: The world is now full of Linux users and administrators who have never touched a traditional Unix machine. What lesson from Unix do these folks risk missing in a Linux-only world?

LWN: The world is also full of energetic new developers for whom open source has always just been part of the environment. These developers will be creating our next generation of systems. What kind of operating systems do you hope they will build, and what advice would you offer them on their way?

LWN: Anything else you would like to say to LWN's readers?

We would like to thank Evi, Garth, Trent, and Ben for taking the time to answer our questions.

Comments (19 posted)

Page editor: Jake Edge

Security

An interesting DNSSEC amplification

A recent report clearly demonstrates that computer security is not exempt from the "law of unintended consequences". As DNSSEC (Domain Name System Security Extensions) is rolled out, we will likely see various kinds of unanticipated problems in that system which is meant to secure the internet name resolution process. One of the concerns about DNSSEC has always been the amount of additional traffic it would generate, as well as the processing burden on DNS servers—both of those came into play here.

The report from Cisco reads a bit like a detective story. A particular DNS server saw a sudden 2-3x increase in its traffic, which at first glance appeared to be some kind of denial of service (DoS) attack. Further investigation showed that the query rate jumped from tens of queries per second (qps) to around 3000 qps. Because it was a DNSSEC signed zone, each query required two responses—a key resource record (DNSKEY RR) and a signature RR (RRSIG RR)—totaling more than 1K in size. That led to response traffic of 35 megabits per second (3000+ queries x 1K+ bytes).

When a small amount of data can be sent that generates a much larger response, there is an "amplification" effect going on. That means that an attacker can use much less of a resource, bandwidth say, than the victim must use to respond. So, a small bandwidth investment, spread out over a large number of attackers (in a DDoS, distributed DoS), can easily cause a victim to generate more traffic than it can handle. Because DNS typically uses UDP to eliminate the connection establishment overhead of TCP, it also makes it easier for attackers, as they don't need to use state-tracking resources on their end. These kinds of amplification attacks are well-known for the existing DNS. It is also understood that DNSSEC adds other amplification possibilities, but those known cases were not the cause of the problem that Cisco investigated.

In analyzing the data from this event, it was determined that a very small fraction of clients (1,000 out of 500,000-1,000,000 daily unique clients) were making repeated queries for the same DNSKEY RR. It could have been from some kind of bug in certain DNS clients, but because the event was so sudden, it suggested that there was some kind of "external trigger". An obvious trigger would be a change to the DNS information being served and that was in fact the case: the cryptographic keys had been changed on the day of the traffic increase.

Normally, a key rollover is handled by keeping both keys around for an overlap period and signing resource records with both keys during that time. Either key can be used to verify the signature during the overlap, and eventually the old key can be deprecated and then removed. Keys are signed by a parent server's key (i.e. example.com's key is signed by the .com server's key), all the way up to the key used to sign the root keys. Today, those root keys are often stored locally by the client as "Trust Anchor". If a client cannot verify a signature with a key that it has in its cache, it will request a new key from the parent, because it assumes the key has changed.

Before it requests a key from the parent, though, it re-requests the key from the server it is talking to, because it assumes that it is getting bogus responses from some kind of attack. If it really were an attack, that would be the right response, but if there were some misconfiguration on the part of the client, it would just make the problem worse. It turns out that some clients were distributed with a static set of Trust Anchors. Once those keys were rolled over, those clients were out of date and could no longer resolve names associated with those parts of the DNS hierarchy.

But, the amplification turns out to be quite a bit larger than just a handful of retries for an affected server. When a client cannot verify a signature, it will do a depth-first search of the alternative name servers, querying each server to try to find keys that it can use. There are 14 .com name servers, and potentially several name servers for example.com. This leads to a combinatorial explosion of sorts, where a query for a single host name (test.example.com for example) in a simple configuration (two example.com name servers) leads to 844 separate queries.

Other, much worse, scenarios are described in the report. It is interesting that perfectly reasonable behavior by clients who have ended up with outdated information can lead to such a huge increase in the traffic that DNS servers, especially the root servers, may have to handle. The conclusion from the Cisco report is certainly eye-opening:

The last paragraph is particularly worrisome. One would guess that a few years down the road, most clients will be DNSSEC-equipped. And most will be in the hands of users who know nothing about key rollover, amplification, DoS, or, for that matter, DNS or DNSSEC. It will be up to the vendors and distributors to ensure that the "forget" part of "set and forget" doesn't happen. It is not hard to envision some kind of nasty apocalypse lurking for DNSSEC if that's not the case.

Comments (10 posted)

Brief items

Quotes of the week

-- David Woodhouse

-- Bruce Schneier on the "internet kill switch"

Comments (1 posted)

New vulnerabilities

abrt: unnecessary setuid

Package(s):	abrt	CVE #(s):
Created:	July 8, 2010	Updated:	July 14, 2010
Description:	From the MeeGo advisory: The file /usr/libexec/abrt-hook-python is setuid as the abrt user. As there is no explicit reason to be setuid as the abrt user, this violates best known practices for security; specifically by not using the principles of least privilege and unintentionally expanding the attackable surface area of MeeGo.
Alerts:	MeeGo MeeGo-SA-10:03 2010-07-07

Comments (none posted)

cups: multiple vulnerabilities

Package(s):	cups	CVE #(s):	CVE-2010-2431 CVE-2010-2432
Created:	July 8, 2010	Updated:	October 10, 2011
Description:	From the Pardus advisory: CVE-2010-2431: The cupsFileOpen function in CUPS before 1.4.4 allows local users, with lp group membership, to overwrite arbitrary files via a symlink attack on the (1) /var/cache/cups/remote.cache or (2) /var/cache/cups/job.cache file. CVE-2010-2432: The cupsDoAuthentication function in auth.c in the client in CUPS before 1.4.4, when HAVE_GSSAPI is omitted, does not properly handle a demand for authorization, which allows remote CUPS servers to cause a denial of service (infinite loop) via HTTP_UNAUTHORIZED responses.
Alerts:	Mandriva MDVSA-2011:146 2011-10-11 Debian DSA-2176-1 2011-03-02 Mandriva MDVSA-2010:234 2010-11-15 Mandriva MDVSA-2010:232 2010-11-15 CentOS CESA-2010:0811 2010-11-01 Red Hat RHSA-2010:0811-01 2010-10-28 Pardus 2010-95 2010-07-08 Gentoo 201207-10 2012-07-09

Comments (none posted)

ghostscript: multiple vulnerabilities

Package(s):	ghostscript	CVE #(s):	CVE-2009-4270 CVE-2009-4897 CVE-2010-1628
Created:	July 14, 2010	Updated:	August 19, 2010
Description:	From the Ubuntu advisory: David Srbecky discovered that Ghostscript incorrectly handled debug logging. If a user or automated system were tricked into opening a crafted PDF file, an attacker could cause a denial of service or execute arbitrary code with privileges of the user invoking the program. (CVE-2009-4270) It was discovered that Ghostscript incorrectly handled certain malformed files. If a user or automated system were tricked into opening a crafted Postscript or PDF file, an attacker could cause a denial of service or execute arbitrary code with privileges of the user invoking the program. (CVE-2009-4897) Dan Rosenberg discovered that Ghostscript incorrectly handled certain recursive Postscript files. If a user or automated system were tricked into opening a crafted Postscript file, an attacker could cause a denial of service or execute arbitrary code with privileges of the user invoking the program. (CVE-2010-1628)
Alerts:	Debian DSA-2093-1 2010-08-19 SUSE SUSE-SR:2010:015 2010-08-17 Fedora FEDORA-2010-11376 2010-07-23 Fedora FEDORA-2010-11325 2010-07-23 SUSE SUSE-SR:2010:014 2010-08-02 Pardus 2010-101 2010-08-02 openSUSE openSUSE-SU-2010:0425-2 2010-08-02 Debian DSA-2080-1 2010-08-01 openSUSE openSUSE-SU-2010:0425-1 2010-07-23 Mandriva MDVSA-2010:136 2010-07-15 Mandriva MDVSA-2010:135 2010-07-15 Mandriva MDVSA-2010:134 2010-07-15 Ubuntu USN-961-1 2010-07-13

Comments (none posted)

gnomine: unnecessary setgid

Package(s):	gnomine	CVE #(s):
Created:	July 8, 2010	Updated:	July 15, 2010
Description:	From the MeeGo advisory: The /usr/bin/gnomine binary is setgid for the games group. There is no explicit reason to be setgid and this violates best known practices for security; specifically by not using the prinicples of least privilege and unintentionally expanding the attackable surface area of MeeGo.
Alerts:	MeeGo MeeGo-SA-10:09 2010-07-07

Comments (2 posted)

gv: multiple vulnerabilities

Package(s):	gv	CVE #(s):	CVE-2010-2055 CVE-2010-2056
Created:	July 9, 2010	Updated:	February 6, 2012
Description:	From the Red Hat bugzilla: a deficiency in the way gv handled temporary file creation, when used for opening Portable Document Format (PDF) files. A local attacker could use this flaw to conduct symlink attacks, potentially leading to denial of service (un-athorized overwrite of file content). (CVE-2010-2056) From the Red Hat bugzilla: A security flaw was found in the way gs handled its initialization: 1, certain files in current working directory were honored at startup, 2, explicit use of "-P-" command line option, did not prevent ghostscript from execution of PostScript commands, contained within "gs_init.ps" file. A local attacker could use this flaw to execute arbitrary PostScript commands, if the victim was tricked into opening a PostScript file in the directory of attacker's intent. (CVE-2010-2055)
Alerts:	MeeGo MeeGo-SA-10:35 2010-11-03 Mandriva MDVSA-2010:159 2010-08-23 SUSE SUSE-SR:2010:014 2010-08-02 openSUSE openSUSE-SU-2010:0425-2 2010-08-02 openSUSE openSUSE-SU-2010:0451-1 2010-08-02 Fedora FEDORA-2010-14633 2010-09-15 Fedora FEDORA-2010-14640 2010-09-15 openSUSE openSUSE-SU-2010:0425-1 2010-07-23 Fedora FEDORA-2010-10642 2010-07-01 Fedora FEDORA-2010-10660 2010-07-01 Red Hat RHSA-2012:0095-01 2012-02-02 CentOS CESA-2012:0095 2012-02-03 CentOS CESA-2012:0095 2012-02-03 Scientific Linux SL-ghos-20120203 2012-02-03 Oracle ELSA-2012-0095 2012-02-03 Oracle ELSA-2012-0096 2012-02-03 Oracle ELSA-2012-0095 2012-02-03

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel kernel-pae	CVE #(s):	CVE-2010-1641 CVE-2010-2071 CVE-2010-2066
Created:	July 8, 2010	Updated:	March 8, 2011
Description:	From the Pardus advisory: CVE-2010-1641: The do_gfs2_set_flags function in fs/gfs2/file.c in the Linux kernel before 2.6.34-git10 does not verify the ownership of a file, which allows local users to bypass intended access restrictions via a SETFLAGS ioctl request. CVE-2010-2071: The btrfs_xattr_set_acl function in fs/btrfs/acl.c in btrfs in the Linux kernel 2.6.34 and earlier does not check file ownership before setting an ACL, which allows local users to bypass file permissions by setting arbitrary ACLs, as demonstrated using setfacl. CVE-2010-2066: If the donor file is an append-only file, we should not allow the operation to proceed, lest we end up overwriting the contents of an append-only file.
Alerts:	Ubuntu USN-1083-1 2011-03-03 Ubuntu USN-1074-2 2011-02-28 Ubuntu USN-1074-1 2011-02-25 MeeGo MeeGo-SA-10:38 2010-10-09 Fedora FEDORA-2010-18983 2010-12-17 openSUSE openSUSE-SU-2010:0664-1 2010-09-23 Fedora FEDORA-2010-14235 2010-09-08 CentOS CESA-2010:0610 2010-08-11 Red Hat RHSA-2010:0610-01 2010-08-10 openSUSE openSUSE-SU-2010:0481-1 2010-08-09 Ubuntu USN-966-1 2010-08-04 Fedora FEDORA-2010-11412 2010-07-27 SUSE SUSE-SA:2010:033 2010-08-02 Ubuntu USN-1000-1 2010-10-19 Fedora FEDORA-2010-10876 2010-07-07 Fedora FEDORA-2010-10880 2010-07-07 Pardus 2010-94 2010-07-08 SUSE SUSE-SA:2010:031 2010-07-20 openSUSE openSUSE-SU-2010:0397-1 2010-07-19 CentOS CESA-2010:0504 2010-07-02

Comments (1 posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2010-2478 CVE-2010-2495
Created:	July 9, 2010	Updated:	March 28, 2011
Description:	From the Red Hat bugzilla: On a 32-bit machine, info.rule_cnt >= 0x40000000 leads to integer overflow and the buffer may be smaller than needed. Since ETHTOOL_GRXCLSRLALL is unprivileged, this can presumably be used for at least denial of service. (CVE-2010-2478) From the Red Hat bugzilla: When transmitting L2TP frames, we derive the outgoing interface's UDP checksum hardware assist capabilities from the tunnel dst dev. This can sometimes be NULL, especially when routing protocols are used and routing changes occur. This patch just checks for NULL dst or dev pointers when checking for netdev hardware assist features. (CVE-2010-2495)
Alerts:	Ubuntu USN-1093-1 2011-03-25 Ubuntu USN-1083-1 2011-03-03 Ubuntu USN-1074-2 2011-02-28 Ubuntu USN-1074-1 2011-02-25 Fedora FEDORA-2010-18983 2010-12-17 openSUSE openSUSE-SU-2010:0664-1 2010-09-23 SUSE SUSE-SA:2010:040 2010-09-13 Fedora FEDORA-2010-14235 2010-09-08 Ubuntu USN-1000-1 2010-10-19 Pardus 2010-112 2010-08-12 SUSE SUSE-SA:2010:033 2010-08-02 Fedora FEDORA-2010-10880 2010-07-07 Fedora FEDORA-2010-10876 2010-07-07

Comments (none posted)

libmikmod: arbitrary code execution

Package(s):	libmikmod	CVE #(s):	CVE-2009-3996
Created:	July 8, 2010	Updated:	October 11, 2010
Description:	From the MeeGo advisory: Heap-based buffer overflow in IN_MOD.DLL (aka the Module Decoder Plug-in) in Winamp before 5.57, and libmikmod 3.1.12, might allow remote attackers to execute arbitrary code via an Ultratracker file.
Alerts:	Ubuntu USN-995-1 2010-09-29 Red Hat RHSA-2010:0720-01 2010-09-28 Fedora FEDORA-2010-13702 2010-08-30 CentOS CESA-2010:0720 2010-10-10 CentOS CESA-2010:0720 2010-09-29 CentOS CESA-2010:0720 2010-09-29 Mandriva MDVSA-2010:151 2010-08-16 Debian DSA-2071-1 2010-07-14 MeeGo MeeGo-SA-10:04 2010-07-07

Comments (none posted)

libtiff: denial of service

Package(s):	libtiff	CVE #(s):	CVE-2010-2598
Created:	July 8, 2010	Updated:	March 15, 2011
Description:	From the Red Hat advisory: An input validation flaw was discovered in libtiff. An attacker could use this flaw to create a specially-crafted TIFF file that, when opened, would cause an application linked against libtiff to crash. (CVE-2010-2598)
Alerts:	Ubuntu USN-1085-2 2011-03-15 Ubuntu USN-1085-1 2011-03-07 CentOS CESA-2010:0520 2010-08-16 Red Hat RHSA-2010:0520-01 2010-07-08

Comments (none posted)

libtiff: multiple denial of service flaws

Package(s):	libtiff	CVE #(s):	CVE-2010-2481 CVE-2010-2483 CVE-2010-2595 CVE-2010-2597
Created:	July 8, 2010	Updated:	March 15, 2011
Description:	From the Red Hat advisory: Multiple input validation flaws were discovered in libtiff. An attacker could use these flaws to create a specially-crafted TIFF file that, when opened, would cause an application linked against libtiff to crash. (CVE-2010-2481, CVE-2010-2483, CVE-2010-2595, CVE-2010-2597)
Alerts:	Ubuntu USN-1085-2 2011-03-15 Ubuntu USN-1085-1 2011-03-07 MeeGo MeeGo-SA-10:27 2010-09-03 MeeGo MeeGo-SA-10:34 2010-10-09 rPath rPSA-2010-0064-1 2010-10-17 Mandriva MDVSA-2010:146 2010-08-06 Mandriva MDVSA-2010:145 2010-08-06 CentOS CESA-2010:0519 2010-07-14 CentOS CESA-2010:0519 2010-07-21 Red Hat RHSA-2010:0519-01 2010-07-08 Gentoo 201209-02 2012-09-23 Debian DSA-2552-1 2012-09-26

Comments (none posted)

opera: multiple vulnerabilities

Package(s):	opera	CVE #(s):	CVE-2010-0653 CVE-2010-1993
Created:	July 14, 2010	Updated:	August 2, 2010
Description:	From the openSUSE advisory: CVE-2010-0653: Opera permits cross-origin loading of CSS style sheets even when the style sheet download has an incorrect MIME type and the style sheet document is malformed, which allows remote HTTP servers to obtain sensitive information via a crafted document. CVE-2010-1993: Opera 9.52 does not properly handle an IFRAME element with a mailto: URL in its SRC attribute, which allows remote attackers to cause a denial of service (resource consumption) via an HTML document with many IFRAME elements.
Alerts:	SUSE SUSE-SR:2010:014 2010-08-02 openSUSE openSUSE-SU-2010:0422-1 2010-07-22 openSUSE openSUSE-SU-2010:0370-1 2010-07-14 openSUSE openSUSE-SU-2010:0368-1 2010-07-14 Gentoo 201206-03 2012-06-15

Comments (none posted)

pam: local root privilege escalation

Package(s):	pam	CVE #(s):	CVE-2010-0832
Created:	July 8, 2010	Updated:	October 26, 2010
Description:	From the Ubuntu advisory: Denis Excoffier discovered that the PAM MOTD module in Ubuntu did not correctly handle path permissions when creating user file stamps. A local attacker could exploit this to gain root privilieges.
Alerts:	Ubuntu USN-959-2 2010-10-25 Ubuntu USN-959-1 2010-07-07

Comments (none posted)

python-cjson: denial of service

Package(s):	python-cjson	CVE #(s):	CVE-2010-1666
Created:	July 12, 2010	Updated:	July 21, 2010
Description:	From the Debian advisory: Matt Giuca discovered a buffer overflow in python-cjson, a fast JSON encoder/decoder for Python. This allows a remote attacker to cause a denial of service (application crash) through a specially-crafted Python script.
Alerts:	Fedora FEDORA-2010-10728 2010-07-06 Fedora FEDORA-2010-10710 2010-07-06 Debian DSA-2068-1 2010-07-11

Comments (none posted)

python-mako: cross-site scripting

Package(s):	python-mako	CVE #(s):	CVE-2010-2480
Created:	July 8, 2010	Updated:	September 29, 2010
Description:	From the Fedora advisory: Fix potential single-quoting XSS vulnerability.
Alerts:	Ubuntu USN-996-1 2010-09-29 SUSE SUSE-SR:2010:014 2010-08-02 openSUSE openSUSE-SU-2010:0383-1 2010-07-16 openSUSE openSUSE-SU-2010:0418-1 2010-07-22 Fedora FEDORA-2010-10544 2010-06-29 Fedora FEDORA-2010-10540 2010-06-29

Comments (none posted)

qt: multiple vulnerabilities

Package(s):	qt webkit	CVE #(s):	CVE-2009-2841 CVE-2010-1766 CVE-2010-1772 CVE-2010-1773
Created:	July 13, 2010	Updated:	March 2, 2011
Description:	From the Red Hat bugzilla: A security flaw was found in the way WebKit used to handle media elements (audio and video tags). A remote attacker could provide a specially-crafted document, requesting loading of sub-resources (such as remote URLs), which would be normally disallowed by the callback function(s). (CVE-2009-2841) From the Red Hat bugzilla: An off by one memory corruption issue exists in WebSocketHandshake::readServerHandshake(). This issue is addressed by improved bounds checking. (CVE-2010-1766) From the Red Hat bugzilla: A use after free issue exists in WebKit's handling of geolocation events. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved handing of geolocation events. (CVE-2010-1772) From the Red Hat bugzilla: An off by one memory read out of bounds issue exists in WebKit's handling of HTML lists. Visiting a maliciously crafted website may lead to an unexpected application termination or the disclosure of the contents of memory. This issue is addressed through improved bounds checking. (CVE-2010-1773)
Alerts:	Mandriva MDVSA-2011:039 2011-03-02 SUSE SUSE-SR:2011:002 2011-01-25 MeeGo MeeGo-SA-10:22 2010-09-03 openSUSE openSUSE-SU-2011:0024-1 2011-01-12 MeeGo MeeGo-SA-10:37 2010-10-09 Fedora FEDORA-2010-14419 2010-09-10 Fedora FEDORA-2010-14409 2010-09-10 Ubuntu USN-1006-1 2010-10-19 SUSE SUSE-SR:2010:015 2010-08-17 Pardus 2010-106 2010-08-11 openSUSE openSUSE-SU-2010:0458-1 2010-08-02 Fedora FEDORA-2010-11011 2010-07-13 Fedora FEDORA-2010-11020 2010-07-13

Comments (none posted)

scsi-target-utils: denial of service

Package(s):	scsi-target-utils	CVE #(s):	CVE-2010-2221
Created:	July 8, 2010	Updated:	June 21, 2011
Description:	From the Red Hat advisory: Multiple buffer overflow flaws were found in scsi-target-utils' tgtd daemon. A remote attacker could trigger these flaws by sending a carefully-crafted Internet Storage Name Service (iSNS) request, causing the tgtd daemon to crash. (CVE-2010-2221)
Alerts:	Ubuntu USN-1156-1 2011-06-21 SUSE SUSE-SR:2010:017 2010-09-21 openSUSE openSUSE-SU-2010:0608-1 2010-09-14 openSUSE openSUSE-SU-2010:0604-1 2010-09-13 CentOS CESA-2010:0518 2010-07-14 Mandriva MDVSA-2010:131 2010-07-12 Red Hat RHSA-2010:0518-01 2010-07-08

Comments (none posted)

w3m: man-in-the-middle attack

Package(s):	w3m	CVE #(s):	CVE-2010-2074
Created:	July 9, 2010	Updated:	October 19, 2012
Description:	From the CVE entry: istream.c in w3m 0.5.2 and possibly other versions, when ssl_verify_server is enabled, does not properly handle a '\0' character in a domain name in the (1) subject's Common Name or (2) Subject Alternative Name field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.
Alerts:	Ubuntu USN-967-1 2010-08-09 SUSE SUSE-SR:2010:014 2010-08-02 CentOS CESA-2010:0565 2010-07-27 Red Hat RHSA-2010:0565-01 2010-07-27 openSUSE openSUSE-SU-2010:0393-1 2010-07-19 Fedora FEDORA-2010-10250 2010-06-22 Fedora FEDORA-2010-10369 2010-06-24 Gentoo 201210-01 2012-10-18

Comments (none posted)

znc: denial of service

Package(s):	znc	CVE #(s):	CVE-2010-2448
Created:	July 12, 2010	Updated:	July 14, 2010
Description:	From the Debian advisory: It was discovered that znc, an IRC bouncer, is vulnerable to denial of service attacks via a NULL pointer dereference when traffic statistics are requested while there is an unauthenticated connection.
Alerts:	Debian DSA-2069-1 2010-07-11

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The current development kernel is 2.6.35-rc5, released on July 12. "And I merged the ARM defconfig minimization thing, which isn't the final word on the whole defconfig issue, but since it removes almost 200 _thousand_ lines of ARM defconfig noise, it's a pretty big deal." We looked at the ARM defconfig issue a few weeks back, and Linus has pulled from Uwe Kleine-König's tree that provides a starting point for the defconfig cleanup. The short-form changelog is appended to the announcement, and all the details are available in the full changelog.

Five stable kernels were released on July 5: 2.6.27.48, 2.6.31.14, 2.6.32.16, 2.6.33.6, and 2.6.34.1.

Comments (none posted)

Quotes of the week

-- Andrew Morton

-- Matthew Garrett gives an overview of the world of Linux power management

Comments (none posted)

Kernel development news

Kernel development statistics for 2.6.35

In the tradition of summarizing the statistics of the Linux kernel releases before the actual release of the kernel version itself, here is a summary of what has happened in the Linux kernel tree over the past few months.

This kernel release has seen 9460 changesets from about 1145 different developers so far. This continues the trend over the past few kernel releases for the size of both the changes as well as the development community as can be seen in this table:

Kernel	Patches	Devs
2.6.29	11,600	1170
2.6.30	11,700	1130
2.6.31	10,600	1150
2.6.32	10,800	1230
2.6.33	10,500	1150
2.6.34	9,100	1110
2.6.35	9,460	1145

Perhaps our years of increasing developer activity — getting more developers per release and more changes per release — has finally reached a plateau. If so, that is not a bad thing, as a number of us were wondering what the limits of our community were going to be. At around 10 thousand changes per release, that limit is indeed quite high, so there is no need to be concerned, as the Linux kernel is still, by far, the most active software development project the world has ever seen.

In looking at the individual developers, the quantity and size of contributions is still quite large:

Most active 2.6.35 developers

By changesets Mauro Carvalho Chehab 228 2.3% Dan Carpenter 135 1.3% Greg Kroah-Hartman 134 1.3% Arnaldo Carvalho de Melo 121 1.2% Johannes Berg 105 1.0% Ben Dooks 98 1.0% Julia Lawall 96 1.0% Hans Verkuil 92 0.9% Alexander Graf 84 0.8% Eric Dumazet 82 0.8% Peter Zijlstra 79 0.8% Paul Mundt 79 0.8% Johan Hovold 75 0.7% Tejun Heo 74 0.7% Stephen Hemminger 74 0.7% Mark Brown 71 0.7% Sage Weil 70 0.7% Alex Deucher 68 0.7% Randy Dunlap 67 0.7% Frederic Weisbecker 66 0.7%

By changed lines Uwe Kleine-König 194249 18.5% Ralph Campbell 53250 5.1% Greg Kroah-Hartman 31714 3.0% Stepan Moskovchenko 30037 2.9% Arnaud Patard 28783 2.7% Mauro Carvalho Chehab 27902 2.7% Eliot Blennerhassett 18490 1.8% Luis R. Rodriguez 16555 1.6% Daniel Mack 16176 1.5% Bob Beers 11703 1.1% Jason Wessel 10502 1.0% Viresh KUMAR 10499 1.0% Barry Song 10116 1.0% James Chapman 9645 0.9% Steve Wise 9580 0.9% Sjur Braendeland 8775 0.8% Alex Deucher 7721 0.7% Jassi Brar 7554 0.7% Sujith 7544 0.7% Giridhar Malavali 6867 0.7%

Uwe Kleine-König, who works for Pengutronix, dominates the "changed lines" list due to one patch that Linus just pulled for the 2.5.35-rc5 release that deleted almost all of the ARM default config files. Linus responded when Uwe posted his patch with:

Other than that major cleanup, the majority of the work was in drivers. Ralph Campbell did a lot of Infiniband driver work, I did a lot of cleanup on some staging drivers, and Stepan Moskovchenko and Arnaud Patard contributed new drivers to the staging tree. Mauro Carvalho Chehab contributed lots of Video for Linux driver work — rounding out the top 6 contributors by lines of code changed.

Continuing the view that this kernel is much like previous ones, 177 different employers were found to have contributed to the 2.6.35 kernel release:

Most active 2.6.35 employers

By changesets (None) 1429 14.2% Red Hat 1185 11.8% (Unknown) 904 9.0% Intel 637 6.3% Novell 559 5.6% IBM 295 2.9% Nokia 253 2.5% (Consultant) 215 2.1% Atheros Communications 175 1.7% AMD 173 1.7% Oracle 169 1.7% Samsung 163 1.6% Texas Instruments 162 1.6% (Academia) 140 1.4% Fujitsu 138 1.4% Google 122 1.2% Renesas Technology 102 1.0% Analog Devices 98 1.0% Simtec 96 1.0% NTT 93 0.9%

By lines changed Pengutronix 195175 18.6% Red Hat 82334 7.8% (None) 79313 7.6% (Unknown) 72426 6.9% QLogic 72131 6.9% Novell 49651 4.7% Intel 47260 4.5% Code Aurora Forum 40081 3.8% Mandriva 29105 2.8% Atheros Communications 29055 2.8% Samsung 25817 2.5% ST Ericsson 20463 2.0% Analog Devices 18889 1.8% AudioScience Inc. 18545 1.8% caiaq 16194 1.5% Nokia 14891 1.4% Texas Instruments 14864 1.4% (Consultant) 14209 1.4% IBM 12235 1.2% ST Microelectronics 11728 1.1%

But enough of the normal way of looking at the kernel as a whole body. Let's try something different this time, and break the contributions down by the different functional areas of the kernel.

The kernel is a bit strange in that it is a mature body of code that still changes quite frequently and throughout the whole body of code. It is not just drivers that are changing, but the "core" kernel as well. That is pretty unusual for a mature code base. The core kernel code — those files that all architectures and users use no matter what their configuration is — comprises 5% of the kernel (by lines of code), and you will find that 5% of the total kernel changes happen in that code. Here is the raw number of changes for the "core" kernel files for the 2.6.35-rc5 release.

Action	Lines	% of all changes
Added	27,550	4.50%
Deleted	7,450	1.90%
Modified	6,847	4.93%

Note that the percent deleted are a bit off because of the huge defconfig delete by Uwe as described above.

So, if the changes are made in a uniform way across the kernel, does that mean that the same companies contribute in a uniform way as well, or do some contribute more to one area than another?

I've broken the kernel files down into six different categories:

• core : This includes the files in the init, block, ipc, kernel, lib, mm, and virt subdirectories.
• drivers : This includes the files in the crypto, drivers, sound, security, include/acpi, include/crypto, include/drm, include/media, include/mtd, include/pcmcia, include/rdma, include/rxrpc, include/scsi, include/sound, and include/video subdirectories.
• filesystems : This includes the files in the fs subdirectory.
• networking : This includes the files in the net and include/net subdirectories.
• architecture-specific : This includes the files in the arch, include/xen, include/math-emu, and include/asm-generic subdirectories.
• miscellaneous : This includes all of the rest of the files not included in the above categories.

Based on these categories, the size of the 2.6.35 kernel is as follows:

Category	% Lines
Core	4.37%
Drivers	57.06%
Filesystems	7.21%
Networking	5.03%
Arch-specific	21.92%
Miscellaneous	4.43%

Here are the top companies contributing to the different areas of the kernel:

Most active 2.6.35 employers (core)
By changesets Red Hat 218 16.5% (None) 148 11.2% IBM 66 5.0% Novell 60 4.5% Intel 59 4.5% (Unknown) 57 4.3% Fujitsu 33 2.5% Google 30 2.3% Wind River 22 1.7% Oracle 22 1.7% Nokia 22 1.7% (Consultant) 22 1.7%	By lines changed Wind River 9535 25.4% Red Hat 6277 16.7% Novell 2385 6.4% (None) 2074 5.5% IBM 2064 5.5% Intel 1480 3.9% Fujitsu 1431 3.8% Google 1417 3.8% VirtualLogix Inc. 992 2.6% ST Ericsson 957 2.6% caiaq 707 1.9% (Unknown) 614 1.6%

The companies contributing to the core kernel files are not surprising. These companies have all contributed to Linux for a long time, and it is part of their core strategy. Wind River has a high number of lines changed due to all of the KGDB work that Jason Wessel has been doing in getting that codebase cleaned up and merged into the main kernel tree.

Most active 2.6.35 employers (drivers)
By changesets (None) 1022 18.1% (Unknown) 678 12.0% Red Hat 528 9.4% Intel 499 8.9% Novell 336 6.0% Nokia 199 3.5% Atheros Communications 165 2.9% (Academia) 94 1.7% IBM 86 1.5% QLogic 86 1.5%	By lines changed QLogic 72122 12.2% (None) 61356 10.4% (Unknown) 60802 10.3% Red Hat 47204 8.0% Intel 39891 6.7% Novell 36951 6.2% Code Aurora Forum 34888 5.9% Mandriva 28867 4.9% Atheros Communications 28844 4.9% AudioScience Inc. 18535 3.1%

Because the drivers make up over 50% of the overall size of the kernel, the contributions here track the overall company statistics very closely. The company AudioScience Inc. sneaks onto the list of changes due to all of the work that Eliot Blennerhassett has been doing on the asihpi sound driver.

Most active 2.6.35 employers (filesystems)
By changesets Red Hat 134 15.9% Oracle 77 9.1% New Dream Network 76 9.0% Novell 76 9.0% (Unknown) 73 8.7% (None) 58 6.9% NetApp 42 5.0% Parallels 39 4.6% IBM 23 2.7% Univ. of Michigan CITI 23 2.7%	By lines changed Oracle 7194 24.2% Red Hat 6392 21.5% Novell 3989 13.4% (Unknown) 3081 10.4% (None) 2024 6.8% New Dream Network 1423 4.8% NetApp 897 3.0% Google 857 2.9% Parallels 687 2.3% (Consultant) 546 1.8%

Filesystem contributions, like drivers, match up with the different company strengths. New Dream Network might not be a familiar name to a lot of people, but their development on the Ceph filesystem pushed it into the list of top contributors. The University of Michigan did a lot of NFS work, bringing that organization into the top ten.

Most active 2.6.35 employers (networking)
By changesets SFR 74 9.6% (Consultant) 73 9.5% Red Hat 72 9.3% (None) 67 8.7% ProFUSION 55 7.1% Intel 45 5.8% Astaro 35 4.5% Vyatta 34 4.4% (Unknown) 34 4.4% Oracle 20 2.6% ST Ericsson 20 2.6% Univ. of Michigan CITI 20 2.6%	By lines changed Katalix Systems 9213 24.2% ST Ericsson 8003 21.0% (Consultant) 3691 9.7% Univ. of Michigan CITI 2334 6.1% Astaro 1956 5.1% Red Hat 1882 4.9% Intel 1607 4.2% SFR 1555 4.1% ProFUSION 1065 2.8% (None) 1060 2.8% (Unknown) 1035 2.7%

Like the filesystem list, networking also shows the University of Michigan's large contributions as well as many of the other common Linux companies. But here a number of not-so-familiar companies start showing up.

SFR is a French mobile phone company, and contributed lots of changes all through the networking core. ProFUSION is an embedded development company that did a lot of Bluetooth development for this kernel release. Katalix Systems is another embedded development company and they contributed a lot of l2tp changes. Astaro is a networking security company that contributed a number of netfilter changes.

Most active 2.6.35 employers (architecture-specific)
By changesets Red Hat 146 7.2% (None) 143 7.0% IBM 120 5.9% Novell 109 5.4% Samsung 100 4.9% Texas Instruments 94 4.6% AMD 90 4.4% Simtec 85 4.2% (Unknown) 75 3.7% (Consultant) 73 3.6%	By lines changed Pengutronix 194211 60.5% Samsung 15341 4.8% ST Microelectronics 10038 3.1% (None) 8338 2.6% Red Hat 7981 2.5% (Consultant) 6695 2.1% IBM 6064 1.9% Novell 5973 1.9% Code Aurora Forum 5114 1.6% Analog Devices 4345 1.4%

With the architecture-specific files taking up the second largest chunk of code in the kernel, the list of contributing companies is closer to the list of overall contributors as well, with more hardware companies showing that they contribute a lot of development to get Linux working properly on their specific processors.

Most active 2.6.35 employers (miscellaneous)
By changesets Red Hat 206 26.9% (None) 110 14.4% (Unknown) 35 4.6% Novell 28 3.7% Intel 27 3.5% IBM 18 2.4% Fujitsu 16 2.1% Google 15 2.0% Wind River 9 1.2% (Academia) 9 1.2% Vyatta 9 1.2%	By lines changed Red Hat 12772 34.0% Broadcom 6082 16.2% (None) 5156 13.7% (Unknown) 2757 7.3% Intel 2212 5.9% (Academia) 1850 4.9% Samsung 769 2.1% Wind River 593 1.6% Fujitsu 592 1.6% Nokia 532 1.4% IBM 499 1.3%

The rest of the various kernel files that don't fall into any other major category show that Red Hat has done a lot of work on the userspace performance monitoring tools that are bundled with the Linux kernel.

As for overall trends in the different categories, Red Hat shows that they completely dominate all areas of developing the Linux kernel when it comes to the number of contributions. No other company shows up in the top ten contributors for all categories like they do. But, by breaking out the kernel contributions in different areas of the kernel, we see that a number of different companies are large contributors in different, important areas. Normally these contributions get drowned out by the larger contributors, but the more specialized contributors are just as important to advancing the Linux kernel.

Comments (15 posted)

A brief history of union mounts

Several weeks ago, I mentioned on my blog that I planned to move out of programming in the near future. A few days later I received this email from a kernel hacker friend:

How long has union mounts existed without going into the mainline Linux kernel? Well, to put it in a human perspective, if you'd been born the same year as the first Linux implementation of union mounts, you'd be writing your college application essays right now. Werner Almsberger began work on the Inheriting File System, one of the early ancestors of Linux union mounts, in 1993 - 17 years ago!

Background

A union mount does the opposite of a normal mount: Instead of hiding the namespace of the file system covered by the new mount, it shows a combination of the namespaces of the unioned file systems. Some use cases include a writable live CD/DVD-based system (without a complicated mess of symbolic links, bind mounts, and writable directories), and a shared base file system used by multiple clients. For an extremely detailed review of unioning file systems in general, see the LWN series:

• Unioning file systems: Architecture, features, and design

• Unioning file systems: Union directories and mounts

• Unioning file systems: unionfs and aufs

This article will provide a high-level overview of various implementations of union mounts from the original 1993 Inheriting File System through the present day VFS-based union mount implementation and plans for near-term development. We deliberately leave aside unionfs, aufs, and other non-VFS implementations of unioning, in large part because the probability of merging a non-VFS unioning file system into mainline appears to be even lower than that of a VFS-based solution.

readdir() redux

Throughout this article, we will place special emphasis on the evolution of readdir(), since historically it has been the greatest stumbling block for any implementation of union mounts. A summary from the first article in the LWN unioning file systems series:

Union mounts development time line

As mentioned earlier, one of the first implementations of a unioning was the Inheriting File System. In a pattern to be repeated by many future developers, Werner quickly became disenchanted with the complexity of the implementation of IFS and stopped working on it, suggesting that future developers try a mixed user/kernel implementation instead:

Many other kernel developers agreed with Werner. One of Linus Torvalds' earliest recorded NAKs of a kernel-based union file system came in 1996:

In 1998, Werner updated his IFS page to suggest working on a unioning file system as a good academic research topic:

Around 2003 - 2004, Jan Blunck took up the gauntlet Werner threw down and began working on union mounts for his thesis. The union mount implementation Jan produced lay dormant until 2007, when discussion about merging unionfs into mainline triggered renewed interest in a VFS-based version of unioning. At that point, Bharata B. Rao took the lead and began working with Jan Blunck on a new version of union mounts. Bharata and Jan posted several versions in 2007.

The first version posted in April 2007 used Jan's original strategy of keeping two pointers in the dentry for each directory, one pointing to the directory below this dentry's in the union stack, and one to the dentry of the topmost directory. The drawback to this implementation is that each file system can only be in one union stack at a time, since dentries are shared between all mounts of the same underlying file system.

The second version posted in May 2007 implemented yet another minor variation on in-kernel readdir(), this time using per file pointer cookies. From the patch set's documentation:

In June 2007, Bharata and Jan posted a third version with an important and novel change to the way union stacks are formed. They replaced the in-dentry links to the topmost and lower directories with an external structure of pointers to (vfsmount, dentry) pairs. For the first time, a file system could be part of more than one union mount. From the patch set's documentation:

In July 2007, Jan posted a fourth version with some relatively minor changes to the way whiteouts were implemented, among a few other things. Jan says, "I'm able to compile the kernel with this patches applied on a 3 layer union mount with the [separate] layers bind mounted to different locations. I haven't done any performance tests since I think there is a more important topic ahead: better readdir() support."

In December 2007, Bharata B. Rao posted a fifth version that implemented another in-kernel version of readdir():

However, this approach had multiple problems, including excessive use of kernel memory to cache directory entries and to keep the mapping of indices to dentries.

readdir() continued to be a stumbling block, and union mounts development slowed down for most of 2008. In April 2008, Nagabhushan BS implemented and posted a version of union mounts with most of the readdir() logic moved to glibc. "I went through Bharata's RFC post on glibc based Union Mount readdir solution (http://lkml.org/lkml/2008/3/11/34) and have come up with patches against glibc to implement the same."

However, moving the complexity to user space wasn't the panacea everyone had hoped for. The glibc maintainers had many objections, the kernel interface was an obvious kludge (returning whiteouts for "." to signal a unioned directory), and no one could figure out how to handle NFS sanely.

In November 2008, Miklos Szeredi posted a simplified version of union mounts that implemented readdir() in the kernel.

This implementation only worked for file systems that return a simple increasing offset in the d_off field for readdir(). So ext2 worked, but any file system with a modern directory hashing scheme did not.

In early 2009, I started to get interested in union mounts. I talked to several groups inside Red Hat and asked them what they needed most from file systems. I heard the same story over and over: "We really really need a unioning file system, but for some reason no one at Red Hat will support unionfs..." I did some research on the available implementations and decided to go to work on Jan Blunck's union mount patch set.

In May 2009, Jan Blunck and I posted a version of union mounts that implemented in-kernel readdir() using a new concept: the fallthru directory entry. The basic idea is that the first time readdir() is called on a directory, the visible directory entries from all the underlying directories are copied up to the topmost directory as fallthru directory entries. This eliminated all the problems I knew of in previous readdir() implementations, but required the topmost file system to always be read-write. This implementation also was limited to only two layers: one read-only file system overlaid with one read-write file system because we were concerned with lock ordering problems.

In October 2009, I posted a version of union mounts that implemented some of the more difficult system calls, such as truncate(), pivot_root(), and rename(). However, implementing chmod() and other system calls that modified files without opening them turned out to be fairly difficult with the current code base. We thought the hard part was copying up file data in open(), rename, and link(), but it turned out they were somewhat easier to implement because they already looked up the parent directory of the file to be altered. For union mounts, we need the parent directory's dentry and vfsmount in order to create a new version of the file in the topmost level of the union file system if necessary. open(), rename, and link() also needed the parent directory in order to create new directory entries, so we just reused the parent in the union mount in-kernel copyup code. But system calls like chmod() that only alter existing files did not bother to lookup the parent directory's path, only the target. Regretfully, I decided to start on a major rewrite.

In March 2010, I posted a rewrite of the pathname lookup mechanism for union mounts, taking into account Al Viro's recent VFS cleanups and removing a great deal of unnecessary code duplication.

In May 2010, I posted the first version of union mounts that implemented nearly all file related system calls correctly. The four exceptions were fchmod(), fchown(), fsetxattr(), and futimensat(), which will fail on read-only file descriptors. (UNIX is full of surprises; none of the VFS experts I talked to knew that these system calls would succeed on a read-only fd.)

The central primitive in this version is a function called user_path_nd(). It is a combination of user_path(), which looks up a pathname and returns the corresponding dentry and vfsmount, and user_path_parent(), which looks up the parent directory of the file or directory given by the pathname and returns the struct nameidata for the parent. (struct nameidata is too complex to describe in full here, but suffice to say it is usually needed to create an entry in a directory.) user_path_nd() returns both the parent's nameidata and the child's path. Once we have both these pieces of information, we can do an in-kernel copyup of a file in chmod() or any other system call that modifies a file. Unfortunately, user_path_nd() is also the weakest point in this version of union mounts: it's racy, inefficient, and copies up files even if the system call fails.

The day after I posted that version, I flew to North Carolina for a long-anticipated in-person code review with Al Viro. We spent three days in his office painfully reviewing the entire union mount implementation. Al immediately figured out how to delete a third of the code I'd spent the last year carefully massaging, and then outlined how to rewrite the other two-thirds of the code more elegantly, including user_path_nd(). As a result of this code review marathon, Linux has a feature-complete implementation of union mounts that has undergone a full code review by the Linux VFS maintainer for the first time. Of course, the resulting todo list is long and complex, and some problems may turn out to be insoluble, but it's an important step forward.

The biggest design change Al suggested was to move the head of the union stack back into the dentry, while keeping the rest of the union stack in a singly linked list of struct union_dir's allocated external to the dentries for the read-only parts of the union stack. This combines the speed and elegance of Jan Blunck's original design using in-dentry pointers to the union stack, with the flexibility of Bharata B. Rao's (vfsmount, dentry) pairs, which allow file systems to be part of many read-only layers. This change removed the entire union stack hash table and the associated lookup logic and shrunk the union_dir struct from 7 members to 2. I posted this hybrid linked list version on June 15, 2010.

Most recently, on June 25th, 2010, I posted a version that implemented submounts in the read-only layers, as well as allowed more than two read-only layers again. Then I went on a two week vacation - the longest vacation I've had since I started working on union mounts - and tried to forget everything I knew about it.

Future Work

The next step is to implement the remainder of Al Viro's review comments. The last big-ticket item is rewriting user_path_nd() and the in-kernel file copyup boilerplate. After that, it's back for another round of code review from Al and the other VFS maintainers. The 2010 Linux Storage and File Systems workshop is in early August. With luck we can hash out any remaining architectural problems face-to-face at the workshop and possibly merge union mounts into mainline before it's old enough to vote. Or it might languish for another 17 years outside the kernel. Such are the vicissitudes of Linux kernel development.

Acknowledgments: I want to extend special thanks to the following people: Kevin Roderick, who provided moral support, Tim Bowen, who gave me a free day at the Spoke6 co-working space while I worked on this article, and, of course, Jake Edge, whose editorial suggestions were, as usual, right on.

Comments (19 posted)

The USB composite framework

Linux is widely used in mobile devices, which should not come as a surprise. It is a powerful and versatile system, and one of its strengths is its support for USB devices of all kinds. That includes "gadgets" — devices that act as USB slaves — like USB flash drives (i.e. pendrives). The USB composite framework makes writing drivers for these kinds of devices relatively easy.

As users keep more data on their mobile devices, the demand for interoperability with desktop computers increases. No one wants to buy a special cable or a "docking station" just to copy a few photos. What users want is to connect the device via a USB cable and get it working out of the box. Linux can give that to them.

Have you ever wondered how this actually works? What happens behind the scenes when a USB connection is established? Better yet, have you wondered how to write a USB gadget for your new and shiny embedded evaluation board?

In this article, I will try to shed some light on that topic.

USB overview

The Universal Serial Bus (or USB) standard defines a master-slave communication protocol. This means that there is one control entity (a master or a host), which decides who can transmit data through the wire. The other entities (slaves, devices, or gadgets) must obey and respond to the host's requests. Slaves do not communicate with each other. A host is usually a desktop computer, while the gadgets are devices such as mice, keyboards, phones, printers, etc.

People are used to seeing Linux systems in the master or host role on a USB bus. But the Linux USB stack also provides support for the slave or gadget role — the device at the other end of the wire. For example, when one connects a pendrive to a Linux host, it handles it with a usb-storage driver. However, if we had a Linux machine with a USB Device Controller (or UDC), we could run Alan Stern's File Storage Gadget (or FSG). FSG is, as its name implies, a gadget driver which implements the USB mass storage device class (or UMC). That would allow the machine in question to act as a USB drive (aka pendrive).

When a device is connected, an enumeration process begins. During this process, the device is assigned a unique 7-bit identifier used for addressing. As a consequence, up to 127 slaves (including hubs) can be connected to a single host.

Communication is based on logical pipes which join the master with one of a slave's endpoints (or EPs). There can be up to 16 endpoints (numbered from 0 to 15) on a device. Endpoint zero (or EP0) is reserved for setup requests (eg. a query for descriptors, request to set a particular configuration, etc.).

Pipes are unidirectional (one-way) and data can go to (via an IN endpoint) or from (via an OUT endpoint) the host. (It is important to remember that from a slave's point of view, an IN endpoint is the one it writes to and an OUT endpoint is the one it reads from.) There are also four transfer modes: bulk, isochronous, interrupt, and control.

Endpoints are grouped into interfaces which are then grouped into configurations. Different configurations may contain different interfaces, as well as have different power demands. All that information is saved in various descriptors requested by the host during enumeration. One can see them using the lsusb tool. Here is the stripped-down (and annotated) output for a Kingston pendrive:

    Bus 001 Device 004: ID 0951:1614 Kingston Technology
    Device Descriptor:
      idVendor           0x0951 Kingston Technology
      idProduct          0x1614
      bNumConfigurations      1     [only one configuration]
      Configuration Descriptor:     [the first and only config]
        bNumInterfaces          1    [only one interface]
        MaxPower              200mA
        Interface Descriptor:        [the first and only intf.]
          bNumEndpoints           2   [two endpoints]
          bInterfaceClass         8 Mass Storage
          bInterfaceSubClass      6 SCSI
          bInterfaceProtocol     80 Bulk (Zip)
          Endpoint Descriptor:        [the first endpoint]
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            2
              Transfer Type            Bulk
              Usage Type               Data
          Endpoint Descriptor:        [the second endpoint]
            bEndpointAddress     0x02  EP 2 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Usage Type               Data

After the host receives the descriptors and learns what kind of a gadget has been connected, it can choose a configuration to be used and start communicating. At most one configuration can be active at a time.

Linux USB composite framework

There is, however, another module that implements UMC: my Mass Storage Gadget (or MSG). The obvious question is, why there are two drivers that seem to do the very same thing. This has something to do with the Linux USB composite framework.

The "old way" of creating gadgets is to get the specification and implement everything as a single, monolithic module. Gadget Zero, File Storage Gadget, and GadgetFS are examples of such gadgets.

This approach has two rather big disadvantages:

• many of the common USB functionalities (core device setup requests on EP0) have to be implemented in each and every module; and
• it can be tricky to combine the code from several gadgets into a new gadget with combined functionality.

For those reasons, David Brownell came up with the composite framework which has two advantages over the old approach:

• all of the core USB requests are implemented by the framework; and
• a single functionality or a USB composite function is developed separately from other functions as well as from the USB bus logic that is not directly related to this function. Later, such functions are combined using the composite function to form a composite gadget.

From a composite gadget's perspective, a device has some functions grouped into configurations. One function may be present in any number of configurations. Each function may have several interfaces and other descriptors but that is transparent to the kernel module.

Put on top of the "raw" USB descriptors structure, a USB composite function can be regarded as an abstraction for a group of interfaces.

That is another excellent property of the framework — most implementation details are hidden "under the hood" and one does not need to think about them when developing a gadget. Instead of thinking about endpoints and interfaces, one thinks about functions. Therefore, FSG is a gadget developed in the "old way", whereas MSG is a composite gadget which uses only one composite function — the Mass Storage Function (or MSF). As a matter of fact, MSF has been created from FSG to allow for the creation of more complicated drivers that would have UMC as part of their functionality.

Overall driver structure

In this article, I will try to explain how to create a mass storage composite gadget. It is in the kernel already, but let's forget that FSG and MSG exist for a moment.

What is great about Linux, is that a lot has already been done and one can get results with relatively little effort. As such, I will show how to create a working driver using MSF and some "composite glue".

I will start with the structure of the module, while skipping the details of the Mass Storage Function. The first step is to define a device descriptor. It stores some basic information about the gadget:

    static struct usb_device_descriptor msg_dev_desc = {
    	.bLength =		sizeof msg_dev_desc,
    	.bDescriptorType =	USB_DT_DEVICE,
    	.bcdUSB =		cpu_to_le16(0x0200),
    	.idVendor =		cpu_to_le16(FSG_VENDOR_ID),
    	.idProduct =		cpu_to_le16(FSG_PRODUCT_ID),
    };

The usb_device_descriptor structure has some more fields but they are not required or not important for our module. What has been set is:

bLength and bDescriptorType

A standard fields each descriptor has.

bsdUSB

The version of USB specification the device supports encoded in BCD (so 0x200 means 2.00).

idVendor and idProduct

Each device must have a unique vendor and product identifier pair. To avoid collisions, companies (vendors) can buy a vendor ID which gives them a namespace of 65536 product IDs to use. NetChip has donated some product IDs to the Linux community. Later, the Linux Foundation got the whole vendor ID for use with Linux. FSG_VENDOR_ID is actually NetChip's vendor ID and, along with FSG_PRODUCT_ID, that is what FSG uses.

The next step is to define an USB configuration which will be provided by the driver. It is described by a usb_configuration structure which, among other things, points to a bind callback function. Its purpose is to bind all USB composite functions to the configuration. Usually, it is a simple function, as most of the job is done prior to its invocation.

Put together it looks as follows:

    static struct usb_configuration msg_config = {
    	.label			= "Linux Mass Storage",
    	.bind			= msg_do_config,
    	.bConfigurationValue	= 1,
    	.bmAttributes		= USB_CONFIG_ATT_SELFPOWER,
    };

    static int __ref msg_do_config(struct usb_configuration *c)
    {
    	return fsg_add(c->cdev, c, &msg_fsg_common);
    }

The msg_config object specifies a label (used for debug messages), the bind callback, configuration's number (each configuration must have a unique, non-zero number), and indicates that the device is self powered. All that the msg_bind does is bind the MSF to the configuration.

That definition is then used by the msg_bind() function, which is a callback to set up composite functions, prepare descriptors, add all configurations supported by the device, etc.:

    static int __ref msg_bind(struct usb_composite_dev *cdev)
    {
    	int ret;

    	ret = msg_fsg_init(cdev);
    	if (ret < 0)
    		return ret;

    	ret = usb_add_config(cdev, &msg_config);
    	if (ret >= 0)
    		set_bit(0, &msg_registered);
    	fsg_common_put(&msg_fsg_common);
    	return ret;
    }

The msg_bind() function does the following: initializes the Mass Storage Function, adds the previously defined configuration to the USB device, and (at the end) puts the msg_fsg_common object. . If everything succeeds, it sets the msg_registered flag so it is recorded that the gadget has been registered and initialized.

With all of the above, a composite device can be defined. For this purpose, the usb_composite_driver structure is used. Besides specifying the name, it points to the device descriptors and the bind callback:

    static struct usb_composite_driver msg_device = {
    	.name		= "g_my_mass_storage",
    	.dev		= &msg_dev_desc,
    	.bind		= msg_bind,
    };

At this point, all that is left are the init and exit module functions:

    static int __init msg_init(void)
    {
    	return usb_composite_register(&msg_device);
    }

    static void msg_exit(void)
    {
    	if (test_and_clear_bit(0, &msg_registered))
    		usb_composite_unregister(&msg_device);
    }

They use the usb_composite_register() and usb_composite_unregister() functions to register and unregister the device. The msg_registered variable is used to ensure the device is unregistered only once.

To sum things up:

• A composite device (msg_device) is registered when in msg_init() when the module loads.
• It has a device bind callback (msg_bind()) that initializes MSF and adds configuration to the gadget.
• The configuration (msg_config) has its own bind callback (msg_do_config()), which binds MSF to the configuration.
• The really hard work is done inside the MSF.

Mass Storage Function

With the big picture in mind, lets get into the finer details: the inner workings of the Mass Storage Function. There are a couple of things to watch out for when dealing with it.

First of all, because MSF can be bound to several configurations, it needs to share some data between the instances and at the same time store information specific for each configuration. The fsg_common structure is used for shared data. An instance of this structure needs to be initialized prior to binding MSF.

Because the common object is used by several MSF instances, it has no single owner thus a reference counter is needed to decide when it can be destroyed. That's the reason for the fsg_common_put() call at the end of msg_bind() function.

Closely connected with the fsg_common structure is a worker thread which MSF uses to handle all the host's requests. When a fsg_common object is created, a thread is started as well. It terminates either when the fsg_common object is destroyed or when it is killed with an INT, TERM, or KILL signal. In the latter case, the fsg_common object may still exist even after worker's death. Whatever reason, when thread exits a thread_exits callback is invoked.

It is important to note that a signal may terminate the worker thread, but why would one want to do that? The reason is simple. As long as MSF is holding any open files, the filesystems which those files belong to cannot be unmounted. That is bad news for a shutdown script.

What Alan Stern came up with in FSG, is to close all backing files when the worker thread receives an INT, TERM, or KILL signal. Because MSF is to be used with various composite gadgets, rather than hardcoding that behavior a callback has been introduced.

The last thing to note is that MSF is customizable. The UMC specification allows for a single device to have several logical units (sometimes called LUNs, which is strictly speaking incorrect since LUN stands for Logical Unit Number). Each logical unit may be read-only or read-write, may emulate a CD-ROM or disk drive, and may be removable or not.

All of this configuration must be specified when the fsg_common structure is initialized. The fsg_config structure is used for exactly that purpose. In most cases, a module author does not want to fill it themselves, but rather let a user of the module decide the settings.

To make it as easy as possible, an fsg_module_parameters structure and an FSG_MODULE_PARAMETERS() macro are provided by the MSF. The former stores user-supplied arguments, whereas the latter defines several module parameters.

Having an fsg_module_parameters object, one may use fsg_config_from_params() followed by fsg_common_init() to create an fsg_common object. Alternatively, fsg_common_from_params() can be used which merges the call to the other two functions.

Here is how it all works when put together:

    static struct fsg_module_parameters msg_mod_data = { .stall = 1 };
    FSG_MODULE_PARAMETERS(/* no prefix */, msg_mod_data);

    static struct fsg_common msg_fsg_common;

    static int msg_thread_exits(struct fsg_common *common)
    {
    	msg_exit();
    	return 0;
    }

    static int msg_fsg_init(struct usb_composite_dev *cdev)
    {
    	struct fsg_config config;
    	struct fsg_common *retp;

    	fsg_config_from_params(&config, &msg_mod_data);

    	config.thread_exits = msg_thread_exits;

    	retp = fsg_common_init(&msg_fsg_common, cdev, &config);
    	return IS_ERR(retp) ? PTR_ERR(retp) : 0;
    }

The msg_exit() function has been chosen as MSF's thread_exits callback. Since MSF is nonoperational after the thread has exited, there is no need to keep the composite device registered, instead the gadget is unregistered.

At this point, it should become obvious why the msg_registered flag is being used. Since usb_composite_unregister() can be called from two different places, a mechanism to guarantee that it will be called only once is needed — atomic bit operations are perfect for such tasks.

And that would be it. We are done. One can grab the full source code and start playing with it.

The beauty of the composite framework is that all the really hard stuff has been already written. One can write devices and experiment with different configurations without deep knowledge of the USB specification or the Linux gadget API. At the same time, it is a perfect introduction to some more serious USB programming.

Running

To use the gadget, one needs to provide a disk image that will act as a real USB device to the USB host. Using dd on the device is perfect for creating one:

    # dd if=/dev/zero of=disk.img bs=1M count=64

With disk image in place, the module can be loaded:

    # insmod g_my_mass.ko file=$PWD/disk.img

Connecting the device to the host should produce several messages in the host system log, among others:

    usb 1-4.4: new high speed USB device using ehci_hcd and address 8
    usb 1-4.4: New USB device found, idVendor=0525, idProduct=a4a5
    usb-storage: device scan complete
    sd 6:0:0:0: [sdb] Attached SCSI removable disk
    sd 6:0:0:0: [sdb] 131072 512-byte logical blocks: (67.1 MB/64.0 MiB)
     sdb: unknown partition table

All that is left is creating a partition with a filesystem and starting using the pendrive:

    # fdisk /dev/sdb
    ...
    # dmesg -c
    sd 6:0:0:0: [sdb] Assuming drive cache: write through
     sdb: sdb1

    # mkfs.vfat /dev/sdb1
    mkfs.vfat 3.0.9 (31 Jan 2010)
    # mount /dev/sdb1 /mnt/
    # touch /mnt/foo
    # umount /mnt

As has been shown, the gadget works like a charm.

Conclusion

The Linux USB composite framework provides a way to add USB devices in a fairly straightforward way. Before the composite framework came along, developers needed to implement all USB requests for each gadget they wanted to add to the system. The framework handles basic USB requests and separates each USB composite function, which allows gadget authors to think in terms of functions rather than low-level interfaces and communication handling.

As one might guess, this article just scratches the surface of what the composite framework can do. The driver that was shown is a single-configuration, single-function gadget, so the advantages over non-composite gadgets is not readily apparent. A future article may look at drivers for more powerful gadgets using the composite framework.

Comments (12 posted)

Patches and updates

Kernel trees

• Linus Torvalds: Linux 2.6.35-rc5 . (July 13, 2010)

• Thomas Gleixner: 2.6.33.6-rt26 . (July 14, 2010)

Build system

• Stephen Rothwell: kbuild: Enable building defconfigs from Kconfig files . (July 14, 2010)

• Grant Likely: Kconfig: Enable Kconfig fragments to be used for defconfig . (July 14, 2010)

Core kernel code

• Mathieu Desnoyers: Generic Ring Buffer Library . (July 12, 2010)

Development tools

• Srikar Dronamraju: Uprobes Patches: . (July 12, 2010)

• Peter Zijlstra: perf pmu interface changes -v3 . (July 12, 2010)

Device drivers

• Arjan van de Ven: pm: Add runtime PM statistics to sysfs . (July 12, 2010)

• Arnd Bergmann: further BKL removal . (July 12, 2010)

Documentation

• Michael Kerrisk: man-pages-3.25 is released . (July 14, 2010)

Filesystems and block I/O

• Munehiro Ikeda: blkiocg async support . (July 12, 2010)

• Aneesh Kumar K.V: Generic name to handle and open by handle syscalls . (July 12, 2010)

• Arnd Bergmann: block: BKL removal, version 4 . (July 12, 2010)

• Arnd Bergmann: VFS: turn no_llseek into the default . (July 12, 2010)

• Yehuda Sadeh: ceph-rbd: ceph RADOS block device . (July 12, 2010)

• Vivek Goyal: cfq-iosched: Implement cfq group idling . (July 12, 2010)

• David Howells: Add a dentry op to handle automounting rather than abusing follow_link . (July 14, 2010)

Memory management

• FUJITA Tomonori: unify dma_get_cache_alignment implementations . (July 12, 2010)

• Nathan Fontenot: De-couple sysfs memory directories from memory sections . (July 12, 2010)

• Xiaotian Feng: [RFC] swap over nfs -v21 . (July 14, 2010)

Networking

• Michael S. Tsirkin: netfilter: add CHECKSUM target . (July 12, 2010)

• Simon Horman: IPVS full NAT support + netfilter 'ipvs' match support . (July 12, 2010)

Architecture-specific

• Pekka Enberg: x86: Early-boot serial I/O support . (July 12, 2010)

• Tejun Heo: x86-64: software IRQ masking and handling . (July 12, 2010)

• Stephen Rothwell: powerpc: reduce the size of the defconfigs . (July 14, 2010)

• Yinghai Lu: Use memblock with x86 . (July 14, 2010)

Security-related

• David P. Quigley: Labeled-NFS: Security Label support in NFSv4 . (July 12, 2010)

Page editor: Jake Edge

Distributions

Linux on PowerPC

Until not so long ago, your author's main computer was a PowerPC machine, but the number of Linux distributions that officially support this platform is diminishing year by year. So is it still viable to run Linux on a PowerPC computer these days? We'll explore the options, which are roughly subdivided into three categories: PowerPC ports of Linux distributions, PowerPC-specific Linux distributions, and PowerPC ports of non-Linux free operating systems (the BSDs).

When Apple still sold Macs based on the PowerPC processor, the architecture was relatively well supported by mainstream Linux distributions. In 2010, PowerPC seems to have fallen off the radar. The number one reason is that there are currently not many PowerPC systems for desktop users on the market. For a time, Terra Soft Solutions sold PowerPC-based workstations, such as the YDL PowerStation, but the product has been discontinued after Fixstars Solutions acquired the company. Another popular PowerPC system for Linux users was the PlayStation 3, but Sony removed Linux support in April of this year. So, at this point, there doesn't seem to be a mainstream PowerPC desktop system you can buy. Luckily, owners of used Macs and other PowerPC systems are not left out in the cold, as they can still run free operating systems.

The Power of the community

Ubuntu supported the PowerPC platform officially until version 6.10 ("Edgy Eft"). From 7.04 on, it has still been available, but as a community port. In February 2007, Matt Zimmerman explained the decision in the ubuntu-announce mailing list:

At the moment, Canonical has still one supported PowerPC release: the server edition of Ubuntu 6.06 LTS, which will be supported on PowerPC until June 2011. The Ubuntu community picked up PowerPC maintenance for the other releases, and interested users can still download ISO images for the 7.10 through 10.04 releases in the ports section of the main Ubuntu mirror. Ubuntu's wiki contains a FAQ and a list of known issues for PowerPC users, although the information is slightly outdated.

OpenSUSE dropped official support for PowerPC in its 11.2 release in November 2009. This was done rather quietly: openSUSE 11.2 was released on November 12 without repositories and ISO files for PowerPC, but without any official word that PowerPC support had been removed. After a bug report, Novell's Michael Loeffler gave the official response:

This essentially made the openSUSE PowerPC port a community effort. Stephan Kulow clarified what this required from the community:

More than half a year later, no one seems to have picked up development and maintenance of the PowerPC port. OpenSUSE has still a POWER@SUSE wiki page with some general information. This page states that Novell is still planning a PowerPC port for SUSE Linux Enterprise Server. OpenSUSE users can discuss PowerPC-related matters in the opensuse-ppc mailing list, but, not surprisingly, discussions died out this year.

More recently, Fedora 13 dropped official PowerPC support. More specifically, PowerPC has been moved to Fedora's secondary architectures, which means that a build failure on the PowerPC platform doesn't hold back a Fedora release. Moreover, neither Fedora nor Red Hat provide hosting space or build servers for secondary architectures.

In a response to a user's outcry, Red Hat's Tom Callaway explained the reason of the move to the secondary architectures:

In short, it's up to the community to maintain the PowerPC port of Fedora if they want it to continue, but so far they don't seem to have the necessary infrastructure. More information can be found on the fedora-ppc mailing list.

Other Linux distributions with a PowerPC port

So among the Linux distributions that dropped official PowerPC support, only Ubuntu has managed to keep it alive as a community effort. But there are still a handful of distributions with "official" PowerPC support. The most important among them is Debian. This is actually the Linux distribution that your author has been running on his PowerMac G5 for years after he ditched Mac OS X. As can be seen on the debian-powerpc mailing list, there's still a lot of activity going on in Debian PPC land.

The Debian PowerPC port began in 1997 and was first officially released with Debian GNU/Linux 2.2 ("Potato"). A completely 64-bit environment doesn't exist, though. On 64-bit processors such as the G5, Debian PPC uses a 64-bit kernel with 32-bit user space. This is because the 64-bit PowerPC processors have no "32-bit mode" like the Intel 64/AMD64 architecture. Hence, 64-bit PowerPC programs that do not need 64-bit mathematical functions will run somewhat slower than their 32-bit counterparts because 64-bit pointers and long integers consume twice as much memory, fill the CPU cache faster, and thus need more frequent memory accesses. There is, however, a Debian PPC64 port in development, offering a complete 64-bit user space for those that want it.

Gentoo Linux also has a PowerPC port, both for 32 and 64 bits. The most recent ISO image is from October 2009, while the most recent stage3 file (the Gentoo base system tarball) is from May. As can be expected from Gentoo, the project has an extensive PPC handbook and FAQ. Users that get into trouble can find help on the gentoo-ppc-users mailing list.

While Arch Linux is focused on the i686 and x86-64 architectures, there is a separate spin-off project for PowerPC machines: Arch Linux PPC. The port offers a 32-bit user space, but it has various kernels for 64-bit machines. The most recent release for which an ISO file can be downloaded is 2010.02.26 with a 2.6.33 kernel. In addition, Arch Linux PPC has a special install guide for PowerPC machines.

CRUX has the same approach: the distribution is focused on the i686 architecture, but some users wanted a PowerPC port and just made it happen: CRUX PPC. Note, however, that the team is small and development is slow. The latest release is CRUX PPC 2.6 and it dates from January. There are both 32-bit and 64-bit ISO images available. In the same style as Gentoo, CRUX PPC has an extensive handbook and FAQ, as well as a cruxppc mailing list, but it is not very active.

Another general-purpose Linux distribution that supports PowerPC is T2 SDE. The project has a small but dedicated community, and the PowerPC (32-bit and 64-bit) platform is well supported. The main developer René Rebe is using it on some of his machines. Users that want to install T2 SDE on their Mac can download the recently released minimal ISO images for T2 SDE 8.0 or build the ISO file themselves. T2 SDE is not an easy-to-use Linux distribution (it's comparable to Gentoo Linux), but your author has been testing it for some time on his PowerMac G5 and was interested by the clean source-based approach.

Yellow Dog Linux (YDL), a Linux distribution specifically developed for the PowerPC architecture, closes out the list. It is based on CentOS and uses Enlightenment as its default desktop environment, although GNOME and KDE can also be installed. Before Apple's transition to the Intel architecture, Terra Soft Solutions was the only company licensed by Apple to resell Apple computers with Linux pre-installed, so it has a history with PowerPC machines.

The latest version is 6.2, released in June 2009. Users can download a big DVD ISO image from one of the mirrors. There is a list of supported hardware, which also includes non-Apple PowerPC machines, a lot of documentation about the installation and configuration, and some HOWTOs about various topics. Meanwhile, Terra Soft Solutions has been acquired by Fixstars, which refocused its Linux distribution on high performance computing and GPU systems. So, while YDL 6.2 still supports PowerPC-based Apple machines, it's main target is now the Sony PlayStation 3 and IBM pSeries platforms.

The Power to serve

For users that don't mind leaving the Linux ecosystem, there are some other options in the BSD world. FreeBSD, OpenBSD and NetBSD all have a PowerPC port, and most of the supported software is the same as on a Linux distribution, so for most practical purposes it doesn't matter if you're running Linux or BSD.

NetBSD (the operating system with the motto "Of course it runs NetBSD") has different ports for various Power PC systems: ofppc, macppc, evbppc, mvmeppc, bebox, sandpoint, and amigappc. The relevant port for Mac Users is of course macppc, which was introduced in NetBSD 1.4.

There is a complete list of supported hardware by the NetBSD/macppc port, and there is an extensive FAQ, which includes a list of supported peripherals. The installation procedure for NetBSD/macppc is documented well to help users get NetBSD on their Mac. As for mailing lists, issues specific to NetBSD on Apple's PowerPC machines are discussed on the port-macppc mailing list, while port-powerpc is about issues relevant to all PowerPC-based NetBSD ports.

The OpenBSD/powerpc port initially supported Motorola computers, but later refocused on Apple hardware, based on code from the NetBSD/macppc port. For OpenBSD 3.0 it was renamed to OpenBSD/macppc. Support for the 64-bit G5 processor (with a 32-bit user space) was added in OpenBSD 3.9. The port's web page has an extensive list of supported hardware and peripherals, and it lists some caveats: sleep/suspend on laptops is not supported, Bluetooth and FireWire are not supported, and SATA doesn't work yet on PowerMac G5 and Xserve G5 systems. The latest OpenBSD/macppc 4.7 release has some installation instructions and users can discuss their problems on the ppc mailing list of OpenBSD.

Last but not least, FreeBSD officially supports the PowerPC port since version 7.0, although it's still a Tier 2 platform. This means that FreeBSD's security officer, release engineers, and toolchain maintainers don't fully support it yet. Nathan Whitehorn has published some installation instructions, and users can discuss matters in the freebsd-ppc mailing list.

Since FreeBSD 8.0, the PowerMac G5 and iMac G5 are supported, and the upcoming 8.1 release also supports the Xserve G5 and the late 2005 model of the PowerMac G5. Previous PowerPC Macs are already supported since version 7.0. There are some caveats, however: the current 32-bit PPC port only supports 2 GB of RAM, and 64-bit PPC support (with support for more RAM) will only be appearing in FreeBSD 9.

Conclusion

While at first sight PowerPC seems to be a dying platform, there's actually still a lot of choice for users that want to run a free operating system on their aged Mac. In the last 10 years, your author has prolonged the life of two PowerPC-based Macs by swapping Mac OS X for a Linux distribution: one time Gentoo Linux, the other time Debian. These are also the two distributions that seem to have the best PowerPC support while still being all-round enough and having a community that is big enough to be of any help. For more adventurous users, there are a lot of other options, with the source-based T2 SDE or NetBSD as notable examples.

Comments (26 posted)

New Releases

Mandriva Linux 2010 Spring released

Mandriva has announced the release of Mandriva Linux 2010 Spring. It contains various recent free software packages (KDE 4.4.3, GNOME 2.30.1, Firefox 3.6.6, and Xorg Server 1.7.7 for example), and has some unique features including: "'Smart Desktop', a unique technology, which offers dynamic access to all files by labelling them and grading photos, documents, emails and videos whilst safeguarding personal data through a customised approach. Ginkgo, the new graphical interface for managing data semantics, can create and explore the links between their personal data such as mails, documents, files, Web pages".

Comments (none posted)

MeeGo 1.0 update for Netbooks

The first update for the Netbook experience of MeeGo v1.0 has been released. It includes an update to kernel 2.6.33.5, faster detection of USB storage devices, improved 3D performances, fixes to the web browser and email client, and more. "Many of you were quick to install our recent release of MeeGo v1.0 on your netbook. We appreciate all of the community help from those of you who tested our release and filed bugs. In fact, this update has over 100 bug fixes and is recommended for all users running MeeGo 1.0 for Netbooks." Click below for the full announcement.

Full Story (comments: 10)

Lunar Linux 1.6.5-rc1

Lunar Linux has announced the first release candidate for Lunar Linux 1.6.5. ISO images are available for i686 and x86-64. "While news and updates on our main site may have been next to nil we assure you that the wheels have been turning behind the scenes. The Lunar team have been busy keeping the modules up to date. The new ISO is also a proof that we are still in the game. Come on and help us test 1.6.5-rc1 and don't be afraid to give us suggestions on how to make Lunar even better!"

Full Story (comments: none)

Distribution News

Ubuntu family

Minutes from the Ubuntu Technical Board meeting

Click below for the minutes from the June 29, 2010 meeting of the Ubuntu Technical Board.

Full Story (comments: none)

New Distributions

FemtoLinux

FemtoLinux is a new distribution optimized for real-time embedded systems. It aims to have a low system call and interrupt-to-application latency and overhead, achieved by allowing critical Linux applications to run in kernel mode. It is currently available for ARM with MIPS and PowerPC ports in the works.

Full Story (comments: none)

New Linux OS REMnux Designed For Reverse Engineering Malware (threat post)

Threat post introduces a new distribution called REMnux. "A security expert has released a stripped-down Ubuntu distribution designed specifically for reverse-engineering malware. The OS, called REMnux, includes a slew of popular malware-analysis, network monitoring and memory forensics tools the comprise a very powerful environment for taking apart malicious code."

Comments (none posted)

Newsletters and articles of interest

Distribution newsletters

• CentOS Pulse #1005 (July 10)
• Debian Project News (July 12)
• DistroWatch Weekly, Issue 362 (July 12)
• Fedora Weekly News Issue 233 (July 7)
• openSUSE Weekly News #131 (July 10)
• Ubuntu Weekly Newsletter, Issue 201 (July 10)

Comments (1 posted)

Mandriva Linux avoids bankruptcy; we test the new version (ars technica)

Ars technica takes a look at Mandriva 2010 Spring. "The OS ships with KDE 4.4.3 and version 2.6.33.5 of the Linux kernel. Mandriva has its own custom user interface theme that is used across both KDE and GNOME, and its default KDE configuration deviates from that of upstream KDE. It uses a Folder View containment as the default activity and it has a conventional application menu instead of KDE's Kickoff menu. These changes are intended to make KDE 4 feel more like the classic user experience of the KDE 3.5.x series."

Comments (2 posted)

OpenSolaris governing board threatens dissolution (The H)

The H reports that the OpenSolaris governing board (OGB) is considering dissolution and may relinquish control of OpenSolaris to Oracle. "At yesterday's OGB meeting, Simon Phipps, previously Sun's 'Open Source Evangelist', stated that collaboration between Oracle and the OpenSolaris community was just not happening. In his opinion, in its present form, the community no longer serves a useful purpose."

Comments (114 posted)

Spotlight on Linux: Pardus Linux 2009.2 (Linux Journal)

Susan Linton takes a look at Pardus Linux. "Pardus hails from Turkey, so at first boot of either image the user will find themselves faced with the Turkish language. But have no fear, F2 brings up the language selector where one can choose English. Pardus is developed by the Scientific & Technological Research Council of Turkey, an advisory office to the Turkish government, which is probably why this distribution feels so professionally done. Original tools and graphics appear throughout giving Pardus a very consistent look and feel."

Comments (none posted)

Page editor: Rebecca Sobol

Development

Python's Mercurial migration

Big projects switching to a distributed version control system (DVCS) is pretty common occurrence these days, but it is not always easy or straightforward. Guido van Rossum first announced that Python would move to Mercurial (aka Hg) in March 2009, but the project is still using Subversion (aka svn) more than a year later. While the conversion is still in the works, the schedule for the switch is still up in the air. Recent discussions have pushed it back until sometime later this year, or possibly early next year.

There appear to be a number of different things that got in the way of adopting Hg, but clearly the biggest has been problems with how it handled end-of-line (EOL) conventions. As described by Brett Cannon, the Python folks were under the impression that Hg had ways to handle EOL conventions that would make it act like Subversion's svn:eol setting. When that turned not to be the case, it set the conversion back.

Efforts were made to design a Mercurial extension—which is written in Python after all—that would "do the right thing" for line-endings on Windows, Linux, and Mac OS X, while not making a mess of binary files. That culminated in an EOL Extension that was released as part of Mercurial 1.5.4 in June of this year. Some of the time it took to get from a design to a working, released extension can be blamed on Mercurial hacker Martin Geisler's PhD work, which is something of a recurring theme.

Cannon, who did much of the work in evaluating Git, Bazaar, and Mercurial before Python chose a DVCS, was delayed shortly after the decision by work on his PhD. That led Dirkjan Ochtman to step in and write Python Enhancement Proposal (PEP) 385, which describes the migration path from svn to Hg. Now Ochtman is unavailable to work on the transition until some time in August due to work on his Master's thesis.

It is a tad amusing to note that projects might be best-served by contributors who either already have advanced degrees or have decided not to pursue them, but that, of course, is a trivialization. There does seem to be a lack of people interested in making the transition, at least in any hurried fashion, or perhaps there is a lack of pressure to make the change from the development community side. In some ways, it would seem that Mercurial has moved into the "nice to have, but not required" bucket, at least for now.

The timing of making a change to a different VCS can be tricky. There are lots of dependencies for ongoing release efforts and the like. The unavailability of Cannon and Ochtman led Martin v. Löwis to put out a call for volunteers. "If nobody volunteers, I propose that we release 3.2 from Subversion, and reconsider Mercurial migration next year." The first alpha of 3.2 is scheduled for early August, while the final release is planned for January of next year. Waiting until after 3.2 would likely mean that the Hg transition will have taken Python around two years.

Some folks did volunteer, and there was talk of releasing the first 3.2 alpha from svn, with later releases coming out of Hg, but no firm decision seems to have been made. There is also some resistance to phasing out svn. Anatoly Techtonik is concerned about moving away:

But Stephen J. Turnbull disagrees with that assessment. The transition was planned because it would make developers' lives easier:

Turnbull notes that a "new proponent and supporting cast" are actively being sought for the transition. In addition, he is optimistic about the timing:

At this point, it is in the hands of the Python team. Before the completion of the EOL Extension, it was relatively easy to find other things to work on while awaiting the extension. Now that the ball is firmly back in their court, the importance of Mercurial to the Python hackers will likely become more clear. If the team is unable to find the time to make that switch, it is by no means the end of the world, it is just an indicator that many are fairly comfortable with their current workflow.

That may be a little surprising to some, but each project has its own way of working and some are more suited to a DVCS development style than others. Python has always been fairly rigorous in its processes, with PEPs for all major—and many minor—decisions, and a pretty conservative development style. Moving unhurriedly to switch to Mercurial may fit in with that just fine.

Comments (2 posted)

Brief items

Quote of the week

-- Guido van Rossum

Comments (22 posted)

App Inventor for Android

Google has introduced App Inventor for Android. It's still in closed beta, but you can request access through the website. "To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app's behavior." (Thanks to Keith Edmunds)

Comments (13 posted)

Campsite 3.4

Campsite 3.4 has been released. "Campsite, the free, open source, multilingual content management system for news websites has been released in version 3.4 and features over fifty bug fixes and improvements. Building upon the stability and security improvements in June's 3.3.6 release, this latest version includes dramatically improved search options (both internally and for external search engines), a clean up of the graphical interface (new-look icons and admin interface) and easier installation." LWN looked at Campsite in March 2009.

Full Story (comments: none)

Announcing FOSSology 1.2.0 Release

The FOSSology Project has announced the release of FOSSology 1.2.0. "FOSSology is a Free Open Source Software (FOSS) project built around an open and modular architecture for analyzing software. Existing modules include license analysis, meta data extraction, Copyright/URL/email scanner, RPM and Debian package analysis, and MIME type identification. This open source software tool analyzes a given set of software packages, and reports items such as the software licenses used by these packages."

Full Story (comments: none)

GNOME 2.31.5 unstable release

The GNOME 2.31.5 development release is available. "2.31.5 is out and features a lot of modules ported to GTK+ 3; oh sure there are bugs, and disabled features, but 1) this is temporary, and 2) this should be seen as an opportunity for sleepless nights in The Hague. Isn't it a wonderful world?"

Full Story (comments: none)

GNOME Shell 2.31.5 released

GNOME Shell 2.31.5 is now available. "Note: This release changes the GTK+ dependency to the GTK+ 3.0 development series. Mutter must now be built with the --with-gtk=3.0 option to work correctly with GNOME Shell."

Full Story (comments: none)

GTK+ 2.21.5 released

GTK+ 2.21.5 is the latest stable release of GTK+. "GTK+ 2.22 is planned to be the last stable GTK+ 2.x release, to be released in parallel with GTK+ 3. It will not receive major feature work beyond API additions that are required to facilitate porting to GTK+ 3."

Full Story (comments: none)

GTK+ 2.90.5 released

GTK+ 2.90.5, a development release leading toward 3.0, is now available. "GTK+ 3 will be parallel installable with GTK+ 2.x, and this release has been prepared to test this by renaming all .pc files, libraries, include paths, and so forth, to include a '3.0' component."

Full Story (comments: none)

KDE SC 4.5 RC2 Out

KDE has announced the second release candidate of the upcoming KDE Software Compilation 4.5. "The final version will be available in August 2010 and this RC is intended for testers and early adopters who can help by finding and reporting bugs. It will also interest those who want an early look at what is coming to their desktops and netbooks this summer."

Comments (1 posted)

libguestfs 1.4.0

libguestfs 1.4.0 is a major new release of libguestfs. "libguestfs is a library and a set of tools for accessing and modifying disk images and virtual machines. You can use this for viewing and editing files inside guests, scripting changes to VMs, monitoring disk used/free statistics, P2V, V2V, performing partial backups, cloning VMs, and much more."

Full Story (comments: none)

SeaMonkey 2.1 Alpha 2

SeaMonkey 2.1 Alpha 2 is available for testing. "Please note that this pre-release version is still intended for developers and testers only. As always, we appreciate any feedback you may have and encourage users to help us by filing bugs."

Full Story (comments: none)

Newsletters and articles

This week's newsletters

• Caml Weekly News (July 13)

Comments (none posted)

Page editor: Rebecca Sobol

Announcements

Non-Commercial announcements

Python Software Foundation is sponsoring sprints

The Python Software Foundation has put out a call for requests for funding assistance for coding sprints. Up to $250 is available for each sprint, and more information can be found on the Python sprints blog or by clicking below for the full announcement. "Whether you call them Sprints, Hackfests, Hack-a-thons, or any other name, they're a great way to hang out with like-minded developers and work on common code. Sprints are an unbeatable way to build friendships and contacts that will last for years to come, and they're a great way to learn about something new if you're just starting out. [...] The Python Software Foundation has set aside funds to be distributed to world-wide sprint efforts. We're anticipating 2-3 events per month focused on covering topics to help the entire community".

Full Story (comments: 1)

KDE e.V. Quarterly Reports Relaunched

KDE.News looks at the relaunch of KDE e.V. quarterly reports. "KDE e.V. is the legal body which holds our finances and represents the project in a range of issues. Our Quarterly Reports have restarted with a special bumper issue covering 2009 Q2 to 2010 Q1. It covers the many sprints which e.V. organises for our contributors to get together in person with their KDE teams. It also covers events e.V. has helped KDE to attend and the working groups it oversees."

Comments (none posted)

Articles of interest

Open Source Hardware Definition released, first Open Hardware Summit

BoingBoing covers the launch of the "Open Source Hardware Definition" and the announcement of the first Open Hardware Summit. "Open Source Hardware (OSHW) is a term for tangible artifacts -- machines, devices, or other physical things -- whose design has been released to the public in such a way that anyone can make, modify, distribute, and use those things. This definition is intended to help provide guidelines for the development and evaluation of licenses for Open Source Hardware."

Comments (22 posted)

Multi-Touch Sugar on XO-1.75 ARM Laptop Coming Soon (OLPC News)

OLPC News reports on news of the XO-1.75 laptop. The article mostly quotes from an email by Chris Ball of OLPC, in which he mentions a touchscreen for XO-1.75 and continuing to use Fedora as the distribution, even though the new hardware is ARM-based. In addition, Sugar will get multitouch: "We've begun working on modifications to Sugar to enable touchscreen and multitouch use (the XO-1.75 will have a touchscreen, as will future OLPC tablets based on its design), and we'll continue to do so. The first outcome from this work is Sayamindu Dasgupta's port of the Meego Virtual Keyboard to Sugar".

Comments (23 posted)

Supposed 'Proof' Of SCO's Infringement Claims Against Linux Seem Lacking (Techdirt)

In what should come as no surprise to most folks, the alleged "proof" of SCO's infringement claims, as recently posted by SCO lawyer Kevin McBride—Darl's brother—is weak, at best. Techdirt takes a look and is unimpressed. "If you look through the files, you don't have to be a programmer to start questioning the copyright claims. Most of the lines are not direct copies at all, and seem to be on really, really, really basic functions -- the type of thing that just about anyone would program to create that functionality. In other words, it's difficult to see how there would be any copyright on that code at all, since it was hardly original or requiring any form of creativity. Others in the Slashdot comments point out that some of the code appears to have originated in BSD code, outside of what SCO was claiming it held rights to, and others suggest at least parts of the code came from a separate third party. Furthermore, even looking through the files it's difficult to find many cases where you could even claim 'cut-and-paste copying' as was alleged." Much (all?) of it seems like the same stuff that was debunked back in 2003.

Comments (14 posted)

Weir: ISO/IEC JTC1 Revises Directives, Addresses OOXML Abuses

On his blog, Rob Weir looks at changes to the ISO standardization process, that would eliminate some of the abuses that were seen in the OOXML standardization effort. In 2007 and 2008, Microsoft pushed its office document format (OOXML) through the ISO fast track process, which allowed it to become a second ISO standard—the first was Open Document Format (ODF). "On July 1st, 2010 a new set of rules (directives) took effect in ISO/IEC JTC1 including new processing and voting rules for JTC1 Fast Track submissions. If these rules had been in effect back in 2007, OOXML would have died after its initial ballot." (Thanks to Martin Jeppesen.)

Comments (12 posted)

New Books

Ubuntu for Non-Geeks, Fourth Edition--New from No Starch Press

"Ubuntu for Non-Geeks", 4th Edition, is available from No Starch Press.

Full Story (comments: none)

MySQL High Availability--New from O'Reilly

"MySQL High Availability", Tools for Building Robust Data Centers, is available from O'Reilly.

Full Story (comments: none)

JavaScript Cookbook--New from O'Reilly

"JavaScript Cookbook", Programming the Web, is available from O'Reilly.

Full Story (comments: none)

Event Reports

Ruby on Rails Community Shines at RailsConf 2010

O'Reilly Media takes a look at last June's Ruby on Rails conference. "Chairs Chad Fowler and Ben Scofield created a program that highlighted the vibrant and expanding nature of the Rails community itself. While the exploration of Rails 3 attracted many, the conference explored many other areas of the Rails landscape. Featured speakers at RailsConf 2010 included Michael Feathers of Object Mentor, Inc., David Heinemeier Hansson of 37signals, Yehuda Katz of Engine Yard, Inc., Bob Martin of Object Mentor, Inc., Derek Sivers of Thoughts, Ltd., and Gary Vaynerchuk of VaynerMedia."

Full Story (comments: none)

Calls for Presentations

Linux Plumbers Conference call for working session submissions now open

The Linux Plumbers Conference (LPC) has opened up its call for the submission of working session topics that would become part of the "micro-conferences" that make up LPC. Each micro-conference has a number of related working sessions centered around a particular topic (Power Management, Virtualization, Mono, Desktop, Tracing, and so on) and is a half-day in length. "The topics that will actually have working sessions scheduled at the LPC will depend on the submissions to the microconference and on the ability of its respective community to organize a successful working session; see the "Responsibilities of a working session leader" page on the LPC wiki for more details." LPC will be held in Cambridge, Massachusetts November 3-5.

Comments (none posted)

Kiwi PyCon 2010 Call for Participation

Kiwi PyCon will be held in Paihia/Waitangi in the Bay of Islands November 20-21, 2010. Proposals are due by August 2, 2010.

Full Story (comments: none)

DeepSec 2010 - Call for Papers

DeepSec In-Depth Security Conference 2010 will be held in Vienna, Austria, November 23-26, 2010. The call for papers closes July 31, 2010. "Additionally we call for [submission] from young security researchers of 21 years and younger for exhibits of their own research during the conference."

Full Story (comments: none)

Upcoming Events

Events: July 22, 2010 to September 20, 2010

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
July 17 July 24	EuroPython 2010: The European Python Conference	Birmingham, United Kingdom
July 19 July 23	O'Reilly Open Source Convention	Portland, Oregon, USA
July 21 July 24	11th International Free Software Forum	Porto Alegre, Brazil
July 22 July 23	ArchCon 2010	Toronto, Ontario, Canada
July 22 July 25	Haxo-Green SummerCamp 2010	Dudelange, Luxembourg
July 24 July 30	Gnome Users And Developers European Conference	The Hague, The Netherlands
July 25 July 31	Debian Camp @ DebConf10	New York City, USA
July 31 August 1	PyOhio	Columbus, Ohio, USA
August 1 August 7	DebConf10	New York, NY, USA
August 4 August 6	YAPC::Europe 2010 - The Renaissance of Perl	Pisa, Italy
August 7 August 8	Debian MiniConf in India	Pune, India
August 9	Linux Security Summit 2010	Boston, MA, USA
August 9 August 10	KVM Forum 2010	Boston, MA, USA
August 10 August 12	LinuxCon	Boston, USA
August 13	Debian Day Costa Rica	Desamparados, Costa Rica
August 14	Summercamp 2010	Ottawa, Canada
August 14 August 15	Conference for Open Source Coders, Users and Promoters	Taipei, Taiwan
August 21 August 22	Free and Open Source Software Conference	St. Augustin, Germany
August 23 August 27	European DrupalCon	Copenhagen, Denmark
August 28	PyTexas 2010	Waco, TX, USA
August 31 September 1	LinuxCon Brazil 2010	São Paulo, Brazil
August 31 September 3	OOoCon 2010	Budapest, Hungary
September 6 September 9	Free and Open Source Software for Geospatial Conference	Barcelona, Spain
September 7 September 9	DjangoCon US 2010	Portland, OR, USA
September 8 September 10	CouchCamp: CouchDB summer camp	Petaluma, CA, United States
September 10 September 12	Ohio Linux Fest	Columbus, Ohio, USA
September 11	Open Tech 2010	London, UK
September 13 September 15	Open Source Singapore Pacific-Asia Conference	Sydney, Australia
September 16 September 17	Magnolia-CMS	Basel, Switzerland
September 16 September 17	3rd International Conference FOSS Sea 2010	Odessa, Ukraine
September 16 September 18	X Developers' Summit	Toulouse, France
September 17 September 18	FrOSCamp	Zürich, Switzerland
September 17 September 19	Italian Debian/Ubuntu Community Conference 2010	Perugia, Italy
September 18	Software Freedom Day 2010	Everywhere, Everywhere
September 18 September 19	WordCamp Portland	Portland, OR, USA

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

Page editor: Rebecca Sobol