Linux Foundation Weblogs

Open Voices: Open Voices Interview with Mitchell Baker, Mozilla

lfblogs@linux-foundation.org — Wed, 20 Aug 2008 03:55:49 +0000

The fifth Open Voices podcast installation features a conversation with Mozilla Chairman, Mitchell Baker, and the Linux Foundation Executive Director, Jim Zemlin. Baker admits that Mozilla’s open source strategy was in direct reaction to market and competitive pressures and calls out Microsoft for illegal activities. As one of the first software projects to “open source” its technology, she explains how the Mozilla Foundation navigated community, licensing and growth issues. Baker also shares her opinions on the motivations and ingredients involved in mass collaboration, specifically around the Mozilla and other open source projects.

To view the transcript, click here.

The fifth Open Voices podcast installation features a conversation with Mozilla Chairman, Mitchell Baker, and the Linux Foundation Executive Director, Jim Zemlin. Baker admits that Mozillarsquo;s open source strategy was in direct reaction to market and competitive pressures and calls out Microsoft for illegal activities. As one of the first software projects to ldquo;open sourcerdquo; its technology, she explains how the Mozilla Foundation navigated community, licensing and growth issues. Baker also shares her opinions on the motivations and ingredients involved in mass collaboration, specifically around the Mozilla and other open source projects. To view the transcript, click here.

Jeff Licquia: Standards and Conversations, Part 1

jeff+blog@licquia.org (Jeff Licquia) — Mon, 18 Aug 2008 19:53:21 +0000

So it looks like the project I’ve been laboring on has been getting some attention:

Ever thought it was difficult to write software for Linux? For multiple distros? InternetNews reports that the LSB is making a push for their next release (due out later this year) that should help make all that much easier.

They even link to our project status page. Cool!

Of course, good publicity invites criticism. This time, there seem to be two themes. William Pitcock seems to have the most succinct summary:

To put things simply, the LSB sucks. Here’s why:

The LSB spec depends on RPM. I mean, come on. Seriously. Why do they need to require a specific package manager? If package handling is really required, then why not create a simple package format that can be converted on demand into the system package format? Or why care about packages at all?

The LSB spec invents things without consulting distros. Like the whole init scripts thing. But that’s not as bad as depending on RPM or requiring a specific layout.

(See also Scott James Remnant.)

Let’s take this one part at a time. Today’s topic: packaging.

Part of William’s problem may be that he doesn’t understand the spec. The LSB doesn’t require a specific package manager, or a specific package format. It doesn’t even require that the distribution be set up using package management at all!

The spec only requires that LSB-compliant software be distributed so that any LSB-compliant distribution can install it. That could be tarballs with POSIX-compliant install scripts, an LSB-compliant install binary, a shar archive, a Python script with embedded base64 binaries, whatever. One of the options allowed is an RPM package, with a number of restrictions.

The restrictions are key, because they effectively define a subset of RPM that acts as, to quote William again:

…a simple package format that can be converted on demand into the system package format…

The difference being, of course, that we didn’t reinvent the wheel and create our own; we used a popular format as the basis for ours.

Scott raises another concern:

While much of the LSB can be hacked into a different distribution through compatibility layers and tools, such as alien, what ISV or other vendor wants to provide a support contract against a distribution that has such kludges?

I’m not sure if he’s referring specifically to packaging or to the standard in general. As regards packaging: the reason we specify a strict subset is because we can test that subset, and we’ve tailored it to the needs of tools such as alien. The theory goes that alien isn’t a kludge when it comes to LSB packages.

But, as already mentioned, if vendors aren’t comfortable with supporting RPM, they have a number of other options. As it turns out, most of them are doing just that; the feedback we’re getting from most ISVs is that packaging (whether LSB-subset RPM, full RPM, or Debian) is just not worth the effort.

Coming up: part 2…

Amanda McPherson: The End Of the OS As We Know It

Fri, 15 Aug 2008 22:45:22 +0000

So the bloggers over at ZDNet have once again proclaimed the end of the operating system. Larry Dignan says:

The operating system may be losing its luster. In fact, you could argue that the operating system–Linux, OS X and Windows–will become an application that just happens to boot first. And hardware vendors are on to the OS’s diminishing importance.

He goes on to say:

My working theory: The OS is being slowly downplayed as hardware vendors and Web developers grab more control over the user experience. The OS will never be totally irrelevant, but it will be increasingly less important. It’ll be plumbing. Simply put, the OS is being squeezed between hardware vendors that are cooking up their own applications to handle key tasks and the so-called Webtop, which will deliver programs through the browser.

I actually agree with much of what Larry says, even though I think the title and some of the points are too broad. Is the OS going away if people primarily use applications via a browser? Absolutely not. The OS remains: it’s only people’s legacy understanding of what an OS is that goes away. For instance, to my generation of computer users our experience with a computer was an experience with the OS. It was Windows, it was DOS, it was Apple’s, it was Linux. To my niece’s generation (age 14), their experience (except with gaming) is defined increasingly by the browser. Or by their cell phone.

As the traditional experience of the OS becomes less important, the value of a bloated OS with an incumbent advantage becomes less important. I have used both Linux and Windows and honestly when it comes to getting my work done, I find very little differences. Why? Because I use hosted applications via a browser. I use Word Press, Flickr, Google Apps, Gmail, online money management, online banking and so on. I don’t use native applications. The performance and experience of Linux in that case, is quite superior since it loads faster, performs better and gives me more flexibility. (It also doesn’t come pre-loaded with tons of crap-ware from AOL, security vendors and the like.)

Just because the OS becomes less visible, does that mean the OS goes away? How can it when software still needs to control hardware. You still need a kernel, you still need a scheduler. You can’t virtualize thin air. Plumbing is vitally important. (Just visit a third world country without it. Sanitation is the backbone of civilization.)

Is there a shift in the important of features required in an OS? Yes — see my points above. If the OS role has changed, I’m not so willing to pay the monopoly premium for Windows if native apps aren’t quite as important. (See the rise of the eeePC.) The ability for an OS to be flexible, to be customized by hardware vendors, by niche vendors who want to customize an OS for a specific audience: all of this becomes much more important. And all of this points to Linux. Desktops themselves are changing. They are becoming more like smart phones (or simply becoming phones). Those vendors want a customizable, modular OS they can brand with their own brand and not have to pay for the privilege to do so. This is why you are seeing the increase in Linux across mini-pcs, phones and embedded computing.

It’s funny to hear about the end of the OS when in fact, an OS or a component of it, like the Linux kernel, is in more and more places: it’s in your LCD TV, it’s in your car, it’s in your Tivo, it’s in your wristwatch. For something that is about to die, it sure is thriving.

There is a shift going on. There is a migration of margin in software sales, there is a migration of user attention from the OS to what you can do with the OS. But don’t forget there has to be an OS running all those apps people are accessing through a browser. See my list above — Google, Amazon, Ebay, Flickr, Facebook — all running Linux. In the history of evolution, those species most adaptable survive and thrive.

Andy Updegrove: ISO/IEC Reject OOXML Appeals, paving way to publication

Fri, 15 Aug 2008 19:57:44 +0000

ISO and IEC have announced the rejection of the four appeals submitted by the National Bodies of Brazil, India, South Africa and Venezuela, as earlier recommended by the Secretaries General of each of the two standards organizations. to their respective management boards not to give the appeals further consideration.

This paves the way for the as-adopted version of OOXML, now called IS0/IEC DIS 29500, Information technology - Office Open XML, to proceed to publication. That version is substantially different than the current implementation of OOXML in Office 2007, and its text has still not been publicly released by ISO/IEC. According to a joint press release, publication “is expected to take place within the next few weeks on completion of final processing of the document.” Intriguingly, the press release goes on to say, “and subject to no further appeals against the decision.

Read the rest

Michael Dolan: How to participate in the Linux kernel development process/community

Thu, 14 Aug 2008 19:41:18 +0000

There’s a great book published over at the Linux Foundation that helps developers who are interested in participating in Linux kernel development and the process for contributing. This is a great resource and is probably one of the most difficult “cultural” and procedural issues for new, aspiring kernel hackers. I think it’s absolutely fantastic the kernel community itself has published a guide on how to participate. This will help significantly as the developer community has scaled already to a very large number of participants.

The LF should publish a PDF version… I’ll send them a suggestion. One other suggestion would be about how a developer should work with their internal legal team to get permission for submitting code. Perhaps we’ll see that in version 2.0.

Oh, and of course it’s free (as in beer) - until O’Reilly buys the rights ;-)

http://ldn.linuxfoundation.org/book/how-participate-linux-community

Andy Updegrove: A Big Day in Court for the FOSS Community

Wed, 13 Aug 2008 22:06:11 +0000

Today those who believe in free content and free and open source software won a major victory in court. The underlying facts, and counsel, were hardly major figures on the commercial landscape: the open source software at issue had been developed for model train buffs under an infrequently used free and open source license, and the attorney was young and inexperienced. But as often happens, a small case between small parties can have huge implications. And decisions that may make good strategic sense to the parties can also have disastrous consequences for those that are not in the same situation.

But as often happens, an insignificant case between small parties can have huge implications. And decisions that may make good strategic sense to the parties can also have disastrous consequences for those that are not in the same situation.

The case in question is called Jacobsen v. Katzer. It’s been going on for awhile, and a lot of people have spent a lot of time behind the scenes helping make sure that it came out the right way. So for those of you who have not been following this case for the last few years, I’ll try to distill briefly why this decision is so important, and why people are so pleased.

Read the rest of the story

Amanda McPherson: Kernel Etiquette: A Guide on How to Participate

Wed, 13 Aug 2008 17:04:59 +0000

At the last Linux Foundation Collaboration Summit, the late Joe Barr wrote up this exchange on day one of the conference:

The summit’s first panel yesterday, a State of Linux Roundtable, was made up entirely of Linux kernel hackers. During the Q&A session that followed, a gentleman from Nortel introduced himself and told the panel that Nortel was running Linux on one of its switches, and it worked just fine, but the company had to make a number of patches to the kernel to get it to work. He wondered how Nortel could get its patches into the mainstream kernel.

While I was pleased the kernel panel helped him with his request, I know that approach doesn’t scale. Not every developer can attend our Summits face-to-face after all. This wasn’t the first time I had heard this call for help: in Japan, in Korea, in Taiwan, in the US and elsewhere, I frequently am asked: “How do I participate in the Linux community? What can I do to increase my chances for inclusion in mainline?”

This illustrates that for an open and thriving community, the kernel development process can still be daunting for many new participants, even highly technical and sophisticated ones. Although participation in Linux is growing steadily (over 1,000 developers from over 100 companies per kernel release) I knew we could do better.

So over beers that night, Jon Corbet, executive editor of LWN.net, and I sketched out a plan to change this. The result is a 30-page guide on exactly how to participate in the Linux kernel community. I think this material is a first of a kind and of the highest quality, not surprising since Jon wrote it. Jon is not only the Linux “chief meteorologist” he’s also its “Emily Post.” (Sorry Jon!) In this guide, he has chronicled exactly how the kernel development process works, why companies and developers would benefit from mainlining their code and common pitfalls along the way.

Why is this important to release now? As Linux use expands to new areas like mobile and sub-notebooks, it’s even more important to reach out to these new participants and make it as easy as possible to participate. The strength of Linux is its community. With this guide and the other help we can provide (like our Summits) we hope to encourage even more individuals and companies to participate. Please let me or Jon know if you have feedback on this work, or better yet, leave a comment on the LDN.

Ted Tso: Fast ext4 fsck times

Fri, 08 Aug 2008 23:33:43 +0000

This wasn’t one of the things we were explicitly engineering for when were designing the features that would go into ext4, but one of the things which we’ve found as a pleasant surprise is how much more quickly ext4 filesystems can be checked. Ric Wheeler reported some really good fsck times that were over ten times better than ext3 using filesystems generated using what was admittedly a very artificial/synthetic benchmark. During the past six weeks, though, I’ve been using ext4 on my laptop, and I’ve seen very similar results.

This past week, while at LinuxWorld, I’ve been wowing people with the following demonstration. Using an LVM snapshot, I ran e2fsck on the root filesystem on my laptop. So using a 128 gigabyte filesystem, on a laptop drive, this is what people who got to see my demo saw:

e2fsck 1.41.0 (10-Jul-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 1: Memory used: 3440k/12060k (3311k/130k), time: 17.82/ 5.52/ 1.11
Pass 1: I/O read: 233MB, write: 0MB, rate: 13.08MB/s
Pass 2: Checking directory structure
Pass 2: Memory used: 3440k/13476k (3311k/130k), time: 41.47/ 2.16/ 3.30
Pass 2: I/O read: 274MB, write: 0MB, rate: 6.61MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 3440k/14504k (3311k/130k), time: 59.88/ 7.75/ 4.42
Pass 3: Memory used: 3440k/13476k (3311k/130k), time:  0.04/ 0.02/ 0.01
Pass 3: I/O read: 1MB, write: 0MB, rate: 27.38MB/s
Pass 4: Checking reference counts
Pass 4: Memory used: 3440k/6848k (3310k/131k), time:  0.25/ 0.24/ 0.00
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Pass 5: Memory used: 3440k/5820k (3310k/131k), time:  3.13/ 1.85/ 0.10
Pass 5: I/O read: 5MB, write: 0MB, rate: 1.60MB/s

  779726 inodes used (9.30%)
       1 non-contiguous inode (0.0%)
         # of inodes with ind/dind/tind blocks: 719/712/712
22706429 blocks used (67.67%)
       0 bad blocks
       4 large files

  673584 regular files
   58903 directories
    1304 character device files
    4575 block device files
      11 fifos
    1818 links
   41336 symbolic links (32871 fast symbolic links)
       4 sockets
--------
  781535 files
Memory used: 3440k/5820k (3376k/65k), time: 63.35/ 9.86/ 4.54
I/O read: 511MB, write: 1MB, rate: 8.07MB/s

How does this compare against ext3? To answer that, I copied my entire ext4 file system to an equivalently sized partition formatted for use with ext3. This comparison is a little unfair since the ext4 file system has six weeks of aging on it, where as the ext3 filesystem was a fresh copy, so the directories are a bit more optimized. That probably explains the slightly better times in pass 2 for the ext3 file system. Still, it was no contest; the ext4 file system was almost seven times faster to check using e2fsck compared to the ext3 file system. Fsck on an ext4 filesystem is fast!

Comparison of e2fsck times on an 128GB partition
Pass	ext3					ext4
	time (s)			I/O		time (s)			I/O
	real	user	system	MB read	MB/s	real	user	system	MB read	MB/s
1	382.63	18.06	14.99	2376	6.21	17.82	5.52	1.11	233	13.08
2	31.76	1.76	2.13	303	9.54	41.47	2.16	3.3	274	6.61
3	0.03	0.01	0	1	31	0.04	0.02	0.01	1	27.38
4	0.2	0.2	0	0	0	0.25	0.24	0	0	0
5	9.86	1.26	0.22	5	0.51	3.13	1.85	0.1	5	1.6
Total	424.81	21.36	17.34	2685	6.32	63.35	9.86	4.54	511	8.07

Andy Updegrove: Linux World 2008/Streets of San Francisco

Fri, 08 Aug 2008 07:26:50 +0000

The latest edition of Linux World ground to a halt in San Francisco today. I made it into town just last night for a VIP party hosted by the Linux Foundation where I caught up with lots of the true believer friends (developers, journalists and corporate supporters), and for the Board meeting today. The LF board meeting today was productive, though (a highlight was a walk around the Linux Developers Network Site we brought live today, as well as the new Linux Application Checker that Steven J. Vaughn-Nichols immediately pronounced to be a “killer development tool.”

Some things never change, although some things never change in ways that are fresher than others. Linux World was Linux World, or so I heard from all that attended. I tried to scan the agenda, and on a reasonably fast hotel connection it took forever to load, what with all the dynamic content and fancy graphics.

Read the rest here

Linux Standard Base: The New Linux Developer Network

Thu, 07 Aug 2008 18:46:24 +0000

Let’s take a trip down Memory Lane, shall we?

Back when we were still the Free Standards Group and OSDL, the FSG side of the house was hard at work on a developer portal that would help new Linux developers learn what they needed to write applications for Linux. We eventually did a release, but it didn’t have many of the features we wanted, and integration with the tools we provide in the LSB was spotty and hard to use. One thing led to another; the merger happened, and for a while, we were busy with lots of other important things, and the LDN fell by the wayside.

I’m glad to report that’s changed.

We’ve hired a new guy to run the LDN, Brian Proffitt. He’s been hard at work since the moment he started, asking lots of questions and building a new infrastructure in an amazing amount of time. And now, you can see the results of his initial work.

This is only the beginning. If you’ve been following the LSB 4 developments, you’ve probably noticed that much of the work involves bringing up-to-date results and the latest information about the Linux platform to developers as they’re working. In future phases, we hope to hook those tools into the LDN, so developers can have up-to-the-minute information without requiring every-minute releases.

Go check it out.