Mohammed Sameer's Online Aggregator

linux kernel monkey log - Wed, 22/10/2008 - 6:45pm

A while ago I talked about piping all of my bash commands to twitter.com. I've kind of stopped doing that now, after I maxed out at over 14000 updates in about 2 weeks, but it was fun while it lasted.

But in order to do this kind of thing nicely, I ended up writing a command line program to make it easier. Some people have noticed it at times, by poking around in my kernel.org home directory, so I might as well announce the thing publicly.

So, consider this an announcement of the tool, bti. It allows you to send tweets to twitter.com or identi.ca directly from the command line from any Linux machine. It probably works on other systems as well, but you will have to tweak the Makefile yourself.

The latest version can always be found here.

The development for the tool is done in git, and the tree can be found on the ever-awesome github.com in this repository.

linux kernel monkey log - Wed, 24/09/2008 - 3:17pm

As many people have pointed out to me, the posting of the Linux Plumbers Conference keynote on Google Video makes it kind of hard to watch using "free" software. So I tried to work out how to convert the original file to .OGG format.

And I failed.

So, any hints? Someone did this last time around for me for my talk at Google, which can be seen in the fancy new "media" directory on kernel.org right here. I'll be glad to put up the keynote talk, and some other videos that I have of talks if I can get them converted.

linux kernel monkey log - Mon, 22/09/2008 - 5:11pm

It was nice to see the large response from my Linux Plumbers Conference talk, and there seems to be a few common themes of questions about the talk that I figured I'd clear up here.

I have seen the video of the talk, and the video team from the Linux Plumbers Conference is working to put it up online somewhere, hopefully soon. I'll link to it when it is available.

First off, my numbers for the binutils development was completely WRONG. Kees and I sat down and tried to figure out exactly why I didn't count his valid contribution, and it turned out that binutils puts a ChangeLog into each subdirectory, the top-level one is not the summary of all of the individual parts of the project. So I apologize about that one, Canonical really did have one binutils patch in the past 3 years. Not that this really affects any of the main points of my talk though...

All of the other numbers for the other projects are still correct, from what I can tell. If anyone thinks I got them wrong, please let me know and I will be glad to review them. Feel free to review the changelog and svn and git trees of the different projects if want to verify.

One main question that I saw a lot, and was even asked about during my talk, was "what about Canonical's work on the desktop/Gnome/KDE"? I really don't know if they have contributed a lot of effort back upstream on these projects, that wasn't my point here.

Remember, this was given at the Linux Plumbers Conference a gathering of developers of the low-level plumbing of Linux. This wasn't a group of desktop developers, so remember the audience that this was addressed to please.

If Canonical has contributed a lot to Gnome/KDE, that's great, I'm sure someone will post the numbers soon to verify this. Either way, please remember that this was not the audience that I was addressing.

I sat down with Matt the day after my talk, as he described, and hopefully the Canonical kernel developers will work to become more of a valid part of the community, which is what I am sincerely hopeing will happen here.

Oh, and Amanda, I have given this very same kind of talk to Amazon, a number of months ago, as well as many other companies over the past 1 1/2 years, so it's not like I am ignoring them at all.

And this response brings me back to my main point of my talk, which most people seem to have missed as they were upset at me pointing out Canonical's lack of upstream contributions. And that point was, and still is:

The market right now is just too good for individual developers who have experience in writing open source software for Linux, especially the low-level plumbing of Linux, to waste their time working for companies who do not allow them to contribute back, if they want to.

This was a developer conference. I am a developer, talking as myself only, and not as a representative of any company (note the total lack of any corporate branding on my slides), to other developers who I totally respect and want to see be as happy in their day-job as I am in mine.

I would like to point out that lwn.net's summary of the talk did get this correct, which was great to see.

Hopefully this helps clear things up, if not, let me know and I'll be glad to address it.

linux kernel monkey log - Thu, 18/09/2008 - 5:44am

I was honored to give the opening keynote of the first Linux Plumbers Conference this year in Portland, Oregon. Here's the slides and text of my talk (well, the text is what I intended to say, the actual words that came out probably sounded a bit different.)

I'll comment later on a few things that I've noticed people bringing up, but I figured it would be good to get the text and slides out for everyone to be able to see first.

The talk was recorded, and I'll provide a link to it when it is available so you can compare it to what I have below.

If you want to link directly to this talk, please use this link.

See more ...

linux kernel monkey log - Mon, 23/06/2008 - 4:59am

As part of the Linux Foundation Technical board, we confront the issue of closed source Linux kernel modules all the time, and we wanted to do something that could be seen as a general "public statement" about them that is easy to understand and point to when people have questions.

So, after working on this for a while, and asking some of the other major contributors and maintainers of the kernel, what we have is below.

There is also a site that contains a link to a statement from the Linux Foundation about this topic, as well as some more descriptions and background information, and a copy of the full statement as well.

I've also put a pretty pdf version here in case people want to print it out.

If there are any kernel developers who want to add their names to this statement, please let me know by private email and I will be glad to add it.

See more ...

linux kernel monkey log - Thu, 19/06/2008 - 12:29am

The Linux Plumbers Conference has announced that registration is now open, and the call for papers has also gone out.

This conference was created by a bunch of Linux people living in Portland, Oregon with the goal of having a technical conference in the US that deals with the low-level "plumbing" issues relating to the whole Linux system. This includes the kernel, udev, HAL, dbus, xorg, pulse audio, and other related things.

It's a non-profit conference, with all of the money raised for it from registration fees and sponserships going directly into the conference itself to try to provide a good experience.

I'm running one of the "microconference" tracks dealing with the fun around the Linux kernel/userspace interface issues. If you are interested in presenting a talk about this issue, be sure to let me know.

linux kernel monkey log - Wed, 11/06/2008 - 11:31pm

Ever since my talk at OLS last year about the Linux kernel development community and the companies involved, I've been traveling around, giving the talk in one form or another to lots of different companies and community groups.

Last week I gave the talk at Google, and they kindly recorded it and put it up for everyone to see.

So, if you're curious about the current state of the Linux kernel when it comes to how fast it is going, who is doing the work, who is sponsoring the work, and why that matters to your company, sit back and enjoy the talk.

Oh, the slides are right here if you really want to see them. Without the context of the talk they really don't mean that much, but people seem to always want to see them.

I also did an interview for linux-magazin.de a month or so ago, and that is also online now as well.

Maybe now I will no longer have to travel around so much...

linux kernel monkey log - Tue, 10/06/2008 - 8:16pm

Yes, yet-another-linux-kernel-patch-set.

This one is for code that is good enough to build and run, but not good enough to get merged into the main kernel.org tree just yet.

See the announcement for more details if you are interested in adding patches to this tree, or in finding new kernel projects to work on.

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm

FreedomHEC was a lot of fun. Don wrote up a good summary of what happened, if you are interested.

Next year should be better, as hopefully more people who went to WinHEC will have enough advance notice to be able to attend (a common problem from a lot of people I talked to who really wanted to attend.)

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm

Tim Witham somehow convinced me to participate in the Penguin Bowl at Linux World Expo, which forced me to actually attend LWE for the first time (my previous attempts to go there was always stopped due to them rejecting my talk proposals.) Man, what a zoo. If there was ever anyone doubting that big business loves Linux, they should have just seen all the huge booths, and loads of marketing people milling around.

Linux is real in a big way. Pretty scary if you stop to think about it...

So I hung out and manned the Gentoo booth for a few hours (as I'm now their kernel package maintainer for I seem to be a glutton for punishment...) That was fun. The booth was set up and run very professionally, which was in sharp contrast to some of the other booths in the .org section. It's nice to see that Gentoo has some good people with very good people, development, and organizational skills.

Then off to the attend the Penguin Bowl. It was me, Andrew Morton, and Tim (current CTO of OSDL) against 3 Apple FreeBSD people (Jordan Hubbard, Stuart Cheshire, and someone else who's name I don't remember, sorry.)

We held our own for the whole game, but the other team was almost always just ahead of us. It came down to the last round, in which each team had one minute to list as many filesystems in the Linux kernel as they could, and write them down on a big piece of paper.

We were 250 points behind, and every answer was worth 500 points. After one minute was up, we had to step away from the paper and the judges tallied them up.

The other team had 14 filesystems listed.

We had 15.

Our last item on the list was devfs.

So yes, devfs won me a beautiful glass penguin trophy.
The irony of it all...

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm

A notice just went out to the ols-announce mailing list that said:

This year we have one tutorial with limited attendance that people will need to sign up for in advance. Greg Kroah-Hartman will be doing a tutorial where you Write a Real, Working Linux Driver and there are 30 spaces for participants.

The tutorial also has a hardware cost for the USB device for which you will be writing a driver of $40 CAD. Please bring it with you to the tutorial.

Please see the requirement of the attendees as listed here.

If you want to reserve a space, please send me an email.

I think the tutorial is going to be scheduled on the second day of the conference, in the morning, but as the schedule is not finalized, I can not be sure.

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm

Jeremy, no, this does not seem to be an anomaly, or just a "one time miscommunication" unfortunately. See my older comments about the issues that I and others currently have with OSDL.

Currently they seem to be still ignoring us, as nothing has changed (yeah, lots of talk, but no real actions...) But, we have a slot on the board meeting in January to discuss our point-of-view, so we are not giving up yet.

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm

Oh joy, I'm one of the 20 people that SCO wants to dispose. And yet I don't work for IBM anymore. I have a feeling this is going to get messy real fast with too many lawyers getting involved, ugh.

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm
Two udev releases in three days, not bad.

Also, finally created a stupid udev webpage at the urging of some people who felt that a program isn't "real" unless it has a web page. I think the fact that all Linux distros ship udev makes it real enough...

Also lots of fun with my kernel trees. I respun my PCI tree, it's holding about 75 patches. My USB tree has over 150 patches, and I don't even want to look at the I2C and Driver Core trees to count them. 2.6.9 better come out soon, I'm getting way too far off of mainline for comfort.

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm
More patch queue flushing.

Then attacked the __iomem marking. Got the PCI core and the PCI hotplug drivers fixed up. The USB host controller drivers are pretty much seriously messed up in this regard, as they treat a __u32 as a iomem address, which I don't think is really portable, but for some reason is working. I'll let those driver authors figure it out on their own...

Tried to add some type safety to the kobject event code, but gcc doesn't seem to check enumerated type values at compile time (or at run time for that matter.) Doesn't even matter if I make it a typedef. Oh well, maybe I'll dig into sparse one of these days to see if I can add that kind of support to it.

Despite the lack of checking I released a patch that made things a bit safer (we now specify a type of event, instead of a raw string.) This should help us keep any major typos from accidentally becoming the kernel<->userspace interface like a lot of people are worried about.

Need to get a new version of the hotplug scripts out the door, they are really starting to bother me at times (and I've been ignoring the gentoo bug reports for them, unfortunately)

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm

At OLS this year, I mentioned about the persistent device naming scheme that Kay demoed. This is now implemented in three distros (OpenSUSE, Gentoo, and Debian) for people to play around with (maybe four, haven't looked at Red Hat rawhide in a while.) So, if you want to see how this is solved for Linux, try one of those distros out and look at /dev/disk:

$ tree /dev/disk/
/dev/disk/
|-- by-id
|   |-- ata-TOSHIBA_MK4018GAP_23388192T -> ../../hda
|   |-- ata-TOSHIBA_MK4018GAP_23388192T-part1 -> ../../hda1
|   |-- ata-TOSHIBA_MK4018GAP_23388192T-part2 -> ../../hda2
|   |-- ata-TOSHIBA_MK4018GAP_23388192T-part3 -> ../../hda3
|   |-- ata-TOSHIBA_MK4018GAP_23388192T-part4 -> ../../hda4
|   |-- usb-Generic_USB_Flash_Drive_200506062389 -> ../../sdd
|   |-- usb-Generic_USB_Flash_Drive_200506062389-part1 -> ../../sdd1
|   |-- usb-Lexar_Media_Inc._CF_20030128160726900 -> ../../sdb
|   |-- usb-Lexar_Media_Inc._CF_20030128160726900-part1 -> ../../sdb1
|   |-- usb-Lexar_Media_Inc._SD.MS_20030128160726900 -> ../../sdc
|   `-- usb-Lexar_Media_Inc._SM.xD_20030128160726900 -> ../../sda
|-- by-label
|   |-- 1YET57WW -> ../../sdd1
|   |-- EOS_DIGITAL -> ../../sdb1
|   `-- home -> ../../hda4
|-- by-path
|   |-- pci-0000:00:0f.0-ide-0:0 -> ../../hda
|   |-- pci-0000:00:0f.0-ide-0:0-part1 -> ../../hda1
|   |-- pci-0000:00:0f.0-ide-0:0-part2 -> ../../hda2
|   |-- pci-0000:00:0f.0-ide-0:0-part3 -> ../../hda3
|   |-- pci-0000:00:0f.0-ide-0:0-part4 -> ../../hda4
|   |-- usb-0x05dc-0xb18d:0:0:0 -> ../../sda
|   |-- usb-0x05dc-0xb18d:0:0:1 -> ../../sdb
|   |-- usb-0x05dc-0xb18d:0:0:1-part1 -> ../../sdb1
|   |-- usb-0x05dc-0xb18d:0:0:2 -> ../../sdc
|   |-- usb-0x1043-0x8006:0:0:0 -> ../../sdd
|   `-- usb-0x1043-0x8006:0:0:0-part1 -> ../../sdd1
`-- by-uuid
    |-- 1553-17E8 -> ../../sdd1
    |-- 599b4559-2591-4649-a0e2-2547ef07cf33 -> ../../hda2
    |-- 7e80a6b0-918f-407b-a9d5-70858980a4ce -> ../../hda1
    `-- d6d10936-82a6-4884-8317-784c90a63830 -> ../../hda4

This machine has:

• a single ide hard drive with 4 partitions, one of them labeled home.
• a USB storage reader (3 slots, 6 or so storage types), with a Compact Flash card in it.
• a USB flash stick with the label 1YET57WW on its first partition (why, I have no idea, it was a give-away at OSCON this year...)

So, another huge bureaucratic mess gives no real help and the developers go off and solve the problem on their own. When will they ever learn...

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm

I finally succumbed to the trend of getting a real camera and got one the other day. I'm real impressed, it reminds me of the time years ago that I spend with my old 35mm camera taking zillions of black and white photos. This will be fun.

And, just to show it off, here's a picture of part of my current desktop right now:

Yeah, what a mess, and to think I took some things off of it in order to make the picture look not so cluttered.

Hm, this would make for a fun Friday thing, what does your desktop (real) look like?

linux kernel monkey log - Tue, 10/06/2008 - 4:49pm

Why do people always ask me about legal questions involving closed source drivers in the kernel on the linux-kernel mailing list? Mailing list threads about this topic always devolve into something that goes something like this:

"Well I think it's legal to do this."

"No, I think it's legal to do this instead."

And of course, everyone assumes that just because some companies are getting away with it for now (nvidia, ati, vmware) that it is acceptable for everyone else to do so. Bah, as if that were true.

Anyway, if you have legal questions about if you can ship a closed source module for Linux, just consult a lawyer that specializes in Intellectual Property. They are the best ones to advise you, not a bunch of coders...

In the meantime, me and the rest of the kernel programmers will be over here in the corner, making it harder and harder for any closed source module to ever work in Linux. Applying technical solutions for when legal ones don't work...

As for the people who send me flames (always privately, I guess they don't like to spew crap in public for some reason) because I broke the nvidia driver again, get your facts straight before trying to accuse me of anything...

linux kernel monkey log - Wed, 14/05/2008 - 9:14pm

I've been watching twitter for a while now, amused at the ability for it to keep people appraised of what you are doing at the moment, if they really care. I didn't think it was really worth it.

Until I read this post last night which was linked off of some site that I forgot (probably reddit but I did think it was from the every wonderful Arachaia, which if you are a programmer, you should be paying attention to.)

I just couldn't resist...

So, if you want to see what I am doing, RIGHT NOW (well what I just did, it waits for the command to complete before sending it off to twitter), you can follow along right here.

I'm only enabling it on a few of my terminal windows for now, watching me constantly run mutt and offlineimap would get a bit boring.

I wonder how long it's going to be before I type in my password accidentally to this thing. Or until twitter bans me. Any odds on which is going to happen first?

I pity anyone who subscribes to this twit feed, they are going to start hating me very quickly, like the Portland, Oregon local feed already has...

linux kernel monkey log - Mon, 07/04/2008 - 9:52pm

This is a status report for the Linux Driver Project as of April 2008, describing what has happened in the past year of work. It was originally posted on the developer mailing list.

See more ...

linux kernel monkey log - Tue, 01/04/2008 - 11:23pm

Back in July last year, I wrote a paper for the Linux Symposium about who was doing the actual work in the Linux kernel. Today the Linux Foundation has released a new version of it that contains new data, as well as a lot better writing thanks to Jon Corbet of lwn.net and Amanda McPherson of the Linux Foundation.

The paper was released in both html form, and a PDF version for those who like the pretty graphs to be a bit bigger.

It seems that the trade press has picked this up already, with reviews by the 451 group, internetnews.com, cnet, and infoworld, as well as lwn.net.

Funny note, companies are now emailing me complaining that we aren't counting their contributions properly. Hey, the numbers don't lie, take a look at the tools and logs I used to create all of this if you don't believe them.

To be fair to one company, Google, we were incorrectly counting their representation, keeping Andrew Morton in the "Linux Foundation" bucket instead of the "Google" bucket. That will change the list of top companies placing Google somewhere between 10 and 13, I haven't re-run the numbers yet to get the exact placement.

linux kernel monkey log - Sun, 20/01/2008 - 6:21am

I've been carting the "big wall of kernel developers" poster around the world with me for the past 6 months, getting it signed by as many kernel developers as I could find.

First off was the Ottawa Linux Symposium, where the poster was unleashed apon an unsuspecting crowd of people. They mostly just laughed at it, and I had to update a few names by hand for some late patches that slipped in:

At that conference, which had around 600 attendees, I collected 101 different signatures. That ment that 1 out of every 6 people attending that conference, had gotten a patch into the last kernel version that had just come out (2.6.22 at the time.) That's quite a high concentration all in one spot.

I then displayed it at 2007 OSCON. While a fun conference, it is not very kernel oriented at all, and so, I picked up a few more signatures, mostly from Ubuntu people who happened to be attending due to a recent conference.

After that, it was a jump over the pond to the 2007 Linux kernel summit in Cambridge. I collected a few more signatures there, after having to clear off one whole wall of the conference room, much to the hotel's dismay.

Then, it was a few more plane rides, having it get lost by the airline between London and Hamburg, a train ride to Nuremburg, and then a bus ride to the Czech countryside for a SuSE Labs conference. Once again, the hotel staff looked at me strange, but they eventually found a way to set it up, and a few more signatures were aquired.

In the end, I collected 165 signatures, and the poster traveled with me to five different countries.

But today, I finally said goodbye to it. I sent it off in the mail to linux.conf.au, where it is to be raffled off for charity, after collecting a few more signatures that it is missing.

If you see it, say hello, for after lugging it on more airlines that I want to recall, and having to explain it to more airport security people than should have been necessary, it feels strange to not have to tote it after me anymore.

Maybe I'll go create a new poster for all of the work that happened in 2007 in the kernel, that one should only run about 50 meters long and give me something new to lug around the world again...

linux kernel monkey log - Tue, 23/10/2007 - 3:54am

There was a lot of very good press coverage over my last announcement of the restart of the Linux Driver Project and my involvement in it now full time. It's been a few weeks since that announcement, and we now have over 300 different developers signed up to help create, and maintain Linux drivers!

I've also posted a short status report about the current projects, and what is going on with them. Since then, one more project has started, and there are a handful still in the planning stage.

What we need now is more companies participating in the project, we have the developers, but not enough work to keep them busy.

So how do we change this? I'm thinking that possibly, there really isn't a large number of different devices out there that need Linux support written for them.

As proof of this, I give you the Linux Foundation's Vendor Advisory Board. This group of companies publish a list of priorities that they feel need to be worked on in order to help Linux succeed.

Coming in at number 3 is "Device Driver Support". So, I approached this group and asked them specifically what devices did they see in common use that are not supported by Linux (the obvious 2 video cards being a known exception.) Despite this being such a high priority for this group, they had no examples to provide.

And neither do I. I don't currently know of any common piece of hardware in use today that is not supported on Linux. And since these vendors do not know, and I don't, I'm asking the world to help out.

So, please, let me know what specific type of device you know of that is not properly supported on Linux. If you want, please mark up the wiki page at:

http://linuxdriverproject.org/twiki/bin/view/Main/DriversNeeded

Or just email me with your recommendations. If patterns emerge, I'll approach the companies and ask them if they will work with us.

Hopefully with your help, we can find some work for these 310 developers to do :)

linux kernel monkey log - Thu, 27/09/2007 - 10:51pm

Way back in January, I announced a program to write Linux drivers for companies for free. When I did that, I never expected the response to be as large as it was.

It turns out that there were two large groups of people who responded to the announcement, companies wanting drivers, and developers wanting to help out.

I never imagined that so many different people would offer to help out. There is a real need for a place where developers can find a "real" project to work on in the Linux kernel. The Kernel Janitors project is a great place to start out, but what to do from there? It turns out that over 100 different developers offered up their services. Clearly this was a huge untapped group of talented people who wanted to help out.

Also, the number of companies expressing interest in this has exceeded all of my wildest expectations. Already this announcement has caused a number of drivers to end up in the main Linux kernel source tree, with more in the pipeline.

But unfortunately, I was not able to handle all of these different developers and company requests on my own. I had a full-time job, and a full part-time hobby doing Linux kernel development. These requests ended up going unanswered, and I sincerely apologize for that.

Now this has all changed.

My employer, Novell, has modified my position to now allow me to work full time on this project. Namely getting more new Linux kernel drivers written, for free, for any company that so desires. And to help manage all of the developers and project managers who want to help out.

We have kicked off the project again with this announcement on the mailing list set up for the developers wishing to help out.

If you want to join this group of people, or are a company wanting a free Linux driver written for them, please see our new web page at:

http://www.linuxdriverproject.org/

and follow the instructions there on how to join in.

I can't thank the people who have helped make this possible at Novell enough. They really care about helping make Linux support as many devices as possible, with fully opensource drivers.

Now let's get busy writing code...

linux kernel monkey log - Thu, 12/07/2007 - 5:47am

Just a few random things I wanted to get out about this year's Linux Symposium.

My big "wall of kernel developers" turned out very well, with lots of different people taking pictures of it. I wanted to get everyone who had a patch to sign the thing, and I counted 105 signatures at the end of the week. So, since the attendance was somewhere around 700 people or so, 1/7 of the attendees had gotten a kernel patch into the Linux kernel within the past 2 months.

That is a pretty concentrated number of kernel developers for any type of conference.

I'll be dragging the poster around to different places through the year (OSCON is next), and eventually take it, or send it to linux.conf.au where it will be raffled off for charity.

If you are somewhere you think a lot of kernel developers are going to be, and want me to send you the poster so you can get their signatures, just let me know.

My talk went really well, despite being misquoted about the fact the size of the Linux kernel is growing both with number of individual developers as well as the overall code size. My paper explaining all of this can be found here, and the slides I used for the talk can be found here for people who want to see the real numbers and information provided.

The scripts used to create this information can be found in the paper, and I'll be updating them later in the week, along with the scripts I used to create the big posters too.

Papers you should read if you have not already:

• Len Brown, ACPI in Linux -- Myths vs. Reality
• Zachary A. Brown, Asynchronous system calls
• Venkatesh Pallipadi and Adam Belay, cpuidle - Do nothing, efficiently...
• Inaky Perez-Gonzalez, My bandwidth is wider than yours: Ultrawideband, Wireless USB and WiNET in Linux
• Arnaldo Carvalho de Melo, The 7 dwarves: debugging information beyond gdb
• Steven Rostedt, Internals of the RT Patch

That last one about RT makes me not so afraid of the whole -rt kernel patchset and it even looks kind of fun to me now...

Heck, go read them all, they are all great papers and you will learn something by just browsing through them.

Overall, the conference was great. I had a blast and James's final keynote was great, talking about evolutionary theory, obsolete computer architectures, and how to embrace the myrad of forks we all generate everyday within the Linux communities. What more could anyone want out of a week?

linux kernel monkey log - Mon, 02/07/2007 - 3:47am

Spoken at the final party at this years Linux Symposium by a kernel developer working for a Linux distribution that will not be named:

So the problems started happening when we added the 7th wireless stack to the kernel...

linux kernel monkey log - Tue, 26/06/2007 - 6:16am

So Pete thinks I just do "big announcements" here, so I'll try to stop that and do more frequent little things.

I just got the printed out version of the 2.6.22 kernel developer chart from the printer before flying out to the Linux Symposium and it's amazingly large in person:

Over 40 feet long, hopefully I can find a wall that long for people to be able to look at the thing...

I also uploaded the PDF files if others want to try their hand at printing this monstrosity out.

linux kernel monkey log - Sat, 23/06/2007 - 9:27am

I've been working on the graphics for my Linux Symposium talk and it turns out that the graph of Linux kernel developers and their relationship is a bit larger and more complex than I originally guessed.

I wanted to create a single big poster that showed the whole Signed-off-by: path for the past year or so, but when I finally got it rendered it turned out to be over 165 feet long by 3 feet tall...

Needless to say, that's a bit impractical, so I'm having to resort to graphing each individual release, but they are still turning out quite large, over 40 feet long for some of these.

I've put up some sample renderings if people want to take a look at them:

Be forwarned that they are very large and might crash your browser.

Also ran into the problem that the local Kinkos (an American copy/printing company) can not handle images this big. The PDF version of the file crashes Acrobat Reader, even the professional version, and Illustrator can not handle single images this large. Somehow I need to figure out how to get these banners printed out in time for my plane ride to Ottawa next week.

After spending all week using Inkscape to create these images all I have to say is "it rocks!". I used to use Illustrator a lot a long time ago (the result of a number of college classes in graphic design) and Inkscape does all that, and handles images this large in size with absolutely no problems.

linux kernel monkey log - Tue, 19/06/2007 - 11:51pm

First off, I am a Novell employee, but do not speak for the company at all, the following is my personal opinion, but one that is held by a number of different people at different companies...

I've been hearing from a lot of different companies and users about how the current "enterprise" Linux distros manage their kernels and the current problems they are having with them. With all products that bundle up an every-moving target of an OpenSource projects, there are trade-offs and for the past five years or so the two big Linux distros, SUSE and Red Hat have been trying to walk the line between stability and new features and doing so quite well.

But now that we have been living with these models for a few years, a number of problems have come to light, with the way things currently work. This document describes how the current kernels are managed in these two distros, the problems companies and users are having with them, and three proposed solutions.

Current Model of kernels

An "enterprise" Linux kernel as packaged by Red Hat and SUSE is made up of a kernel.org kernel taken from a specific point in time, and then it is tested, tuned, stabilized and then packaged up and supported for usually a long period of time (5-9 years, depending on the product.) After the product is first released, a series of "service packs" or "maintenance updates" (from now on called "major update") are released, about one every 8-18 months depending on the vendor and the length of time the product has been released.

During the time between these major updates, the distro works to ensure that any bugfix or security update that happens will not break any of the current kernel API or internally visible ABI. It does this so that any third-party kernel modules will not need to change or be "recertified" because of them.

Currently both distros provide a way to have third-party module creators register with them and be notified when an internal ABI change is going to happen in order for them to be able to respin their pre-built modules. They also provide ways for third-party modules to be easily created and build against these kernels so as to ease the build issues that can be caused when attempting to build and package against a distro kernel.

When a major update is released, it usually consists of the original kernel version for the product, with a wide range of new features, drivers, and other fixes backported from the currently released kernel.org kernel to the originally released kernel. This enables new hardware to be supported and new features that are requested by the distro's users and partners to be rolled into the product. This release almost always has ABI and API changes due to the new features and drivers.

At the time of this newly released update, all third party modules must be rebuilt and sometimes reworked due to the new features and backports that were applied to the kernel. Hopefully all third-party module vendors work with the distro to be aware of the proposed changes, but sometimes there is a lag before the new modules are available for the customers to use.

An example of how this works can be seen in the latest Novell SLES10 Service Pack 1 release. Originally the SLES10 kernel was based on the 2.6.16 kernel release with a number of bugfixes added to it. At the time of the Service Pack 1 release, it was still based on the 2.6.16 kernel version, but the SCSI core, libata core, and all SATA drivers were backported from the 2.6.20 kernel.org kernel release to be included in this 2.6.16 based kernel package. This changed a number of ABI issues for any external SCSI or storage driver that they would need to be aware of when producing an updated version of their driver for the Service Pack 1 release.

Problems caused by this model

Here are some of the problems that I have heard with customers and partners who have been working with this kind of release model for a number of years:

• Partners have to get their changes, features, and new drivers into the upstream kernel.org kernel in order for the distros to be willing to accept them. After that happens, they must then backport the feature/driver to the older vendor specific kernel, test it to verify everything works properly, and then ask the vendor to accept the patch for their next service pack, by the deadline imposed by the vendor. This causes a lot of extra work by the partners, having to track at least two vendor kernels, as well as the upstream kernel.org tree.
• If the partner misses the release date for the next service pack, their hardware will not be supported within the whole product until 12-18 months later, when the next service pack is released.
• Partners hate working with externally available drivers, through a driver-disk or some other process. Reasons cited for their dislike of this range from confusion of users for how to get access to these drivers, to security issues, to issues surrounding drivers for boot devices or network devices when doing network installs.
• Due to the changing API between each service pack, third-party vendors need to create a different module build for every major product release (RHEL3, RHEL4, etc) as well as for every maintenance update. Because some customers do not upgrade to the latest maintenance update for various reasons, they are forced to support their driver on all maintenance releases, a very large combination.
• It imposes the old Unix slow release cycle on to Linux, cutting off one of the main reasons people switch to Linux in the first place.
• For machines that must work with new hardware all the time (laptops and some desktops), the 12-18 month cycle before adding new device support makes them pretty much impossible to use at times. (i.e. people want you to support the latest toy they just bought from the store.) This makes things like "enterprise" kernels that are directed toward desktops quite uncomfortable to use after even a single year has passed.

Potential solutions and pros and cons of them

1. Keep doing the same as before. This model has evolved over the years to the current state based on input from partners, users, developers and the companies.

   • Pro: People know the model and are used to it.
   • Con: See the above listed reasons why partners and third-party vendors dislike it.

2. Change the major update to only include kernel bugfixes and security fixes. No new features or drivers will be added to the kernel, helping to ensure that the ABI does not change. If an API has to change due to a more intrusive bugfix, this might still happen at this time, but the change is limited to only a specific area, involving a minor number of symbols and structures, instead of large sweeping change like currently happens.

   • Pro: Partners will not have to worry about the release cycle of the distro kernels, and only focus on getting their drivers working with a set kernel version, not multiple versions over the lifetime of the product.
   • Con: Many new features will not be able to be added in this manner, as they touch core portions of the kernel and can not be updated with external modules (ACPI and the large PCI quirk table for misbehaving hardware are two such examples.)

3. On every major update, the kernel is updated to the latest kernel.org release, much like the consumer products are (Fedora, openSUSE, Ubuntu, Mandriva, etc.) This will ensure that any upstream update for drivers and new features will be automatically included.

   • Pro: All of the latest kernel drivers and features will be automatically supported and included by the distro, enabling the Partners to focus on upstream kernel.org development and not worry about backporting things to older kernel versions. All bugfixes and security updates that the vendor has not included in their minor updates are also pulled in at this time (and there are a lot of them.)
   • Con: Partners whose code is not present in kernel.org releases for whatever reason (do not want it, incompatible licenses, etc.) will have to do a bit more work in tracking the new releases, although this should be only be slightly more than the current amount of development and testing that they currently do.

So, what to do? Currently this discussion is happening in the major distros and their partners. Let me know what you think the model should be for enterprise Linux distros in the future.

Do you like one of the currently proposed models above, or do you have some other model you feel would work better?

Thanks to the many different people who read earlier versions of this document and helped to form the ideas here. This includes the whole Novell/SuSE kernel team who while did not all agree with the ideas here, helped out immensely. Also a number of people at different companies helped out, but probably do not wish to be named here, I want to thank them anyway.

linux kernel monkey log - Sat, 02/06/2007 - 1:49am

Ugh, I've been traveling way too much lately, here's a summary of my trips in the past 2 months:

• Nuremberg for work related meeting
• San Francisco for some meeting I can't remember now.
• Stanford for talk to students
• Prague for training of Linux kernel developers
• Los Angles for FreedomHEC
• Tokyo for LinuxWorld Japan
• San Francisco for driver related meeting.

Remember, I live in Portland, not Germany, as many people seem to be surprised when they meet me for the first time. Don't get fooled by my .de email address...

The last two trips happened this week, with me spending only about 48 hours in Tokyo. It was a lot of fun there, but not much time. However, in that span I did get to do the following:

• Give a talk about Linux kernel development based on a mashup of last year's OLS talk and this upcoming year's talk. People actually asked questions, which I am told is very rare for an audience at this kind of event, so I was happy.
• Signed more copies of my O'Reilly driver book, the Japanese translation, than I have for the English version.
• Went to the Tokyo Linux developer meeting (sorry, can't find link, I know they must have one), along with Tony Luck and gave the same talk again. Tony is the ia64 kernel maintainer and remarked that this is one of the few developer audiences that actually like Itanium. I was really impressed by the meeting, there are a lot of good Linux kernel people in Tokyo, it was nice to see some familiar faces and got to meet a lot of new ones. Hopefully I will see some of them at OLS this year.
• Found some neat USB toys to hack on.
• Drooled over the tiny, 1kg dual core laptops and some ultra-mobile machines that I would love to get Linux running on. The future of ultra-mobile devices is looking very good, I can't wait to get one of them soon.

Then the driver meeting in San Francisco sponsored by O'Reilly. Not as many people showed up as expected (only nvidia, IBM and O'Reilly were there), but I think it was very productive. I'll wrote more about this next week, along with a summary of FreedomHEC.

Oh, and now I'm stuck in the SFO airport due to fog, still trying to get home to PDX and have not slept in almost 48 hours. Travel can be fun at times, but other times it's just a major grind to get through...

Time to go play some Lumines, my new addiction...

linux kernel monkey log - Wed, 28/03/2007 - 8:31pm

In talking with a lot of different companies recently, I've come to the realization that we really need to do something about companies that violate the kernel's GPLv2 license. It has been a common criticism that "Well, our company abides by the GPL by releasing the code properly for our kernel modules, but what about all of those other companies that do not?" The companies that are good members of the community are getting a lot of pressure by people internal to them to stop releasing the code. This is justified by pointing to the companies that do not release their code as they are not having any "penalties" by doing this.

Previously the kernel community has ignored almost all violators (with the obvious exception of the gpl-violations.org project). The kernel changes so rapidly that it is quite expensive for a company to try to keep up without releasing their changes and becoming part of the community. This has been done by the constant API changes and other rapid evolution that dictates Linux kernel development. However, if a company throws a bunch of money and developers at the problem, it is pretty trivial to keep up with this development model.

Another big problem is the fact that the kernel is created and copyrighted by thousands of individual developers and companies. Companies are usually not eager to sue other companies as they most likely already have business agreements with them. So that leaves the individual developers, but it's hard for an individual to do anything on their own against companies who violate their code.

So, what can the community do to handle these problems? Here's a few ideas that I've come up with:

• continue as before, ignoring violators. But if we do this, more companies will see this as an implicit acceptance of the closed source modules and start to do it more and more.
• Go after companies with legal action. This is good, but it's pretty "mean" and doesn't do much to try to help convert companies who could learn to become good members of the community. Remember, we need their help, and antagonizing them isn't the best way to accomplish this.
• Ask companies who are friendly toward Linux to apply business pressure against these other companies to get them to change their ways.
• Quietly take legal action against companies who violate the license. This has been the way the FSF has done things in the past, and for some instances this does work. But it does not give any publicity for the other offending companies to provide a disincentive.
• Do big public notices of the offending companies. This will work in some cases, but others, not at all.

The best thing to do is probably a mixture of the above, but I really don't have any solid answers as to how to achieve some of them very well. Taking legal action against another company takes time and resources that individual developers do not usually have. Perhaps a combination of these things is probably the best thing to do.

Anyone have any other ideas?

Or how about incentives for companies who do abide by the license and are good community members. What can we do for them that will help make other companies realize the benefits of doing the same? It's usually easier to convince companies of a tangible benefit, rather than just the risks of incurring legal action.

Anyone have any good ideas about how we can help these companies more?

We need to do something, as I don't think that the current status is workable over the long term.

linux kernel monkey log - Sat, 10/02/2007 - 12:49am

Due to all of the responses I've gotten for the Linux driver announcement I have gotten a lot of questions asked to me about this. Here is a list of some of the most common ones, and their answers.

Again, if anyone has questions about this program, or wishes to take advantage of it, please feel free to contact me.

Q: You forgot to mention the most obvious benefit to the company, "They might sell more of their devices!" How can they turn down an offer like that?

A: Good point :)

Q: How are you going to write a GPL driver by signing an NDA? Is it going to require a binary blob or some other way of obfuscating the code?

A: No, not at all. I have written many drivers after signing NDAs with companies. They are usually signed either to keep information about the device private until it is announced at a specific date, or to just keep the actual specification documents from being released to the public directly. All code created by this NDA program is to be released under the GPL for inclusion in the main kernel tree, nothing will be obfuscated at all.

Q: This is a lame publicity stunt, Linux development has always been done this way.

A: Well, the NDA program that we have set up with The Linux Foundation is new. But yes, other than that, this is exactly how Linux kernel development has been done. But it is good to point out exactly how it all works for those who are not familiar with how it works.

Q: You are putting the people who do this kind of development for a living out of a job, stop that!

A: This is just not true at all. In fact a number of people who are consultants doing this kind of development have contacted me thanking me for bringing the issue more publicity. They know that some companies really want to pay people to do development and support in order to achieve contractual issues and have some one on the hook for providing support in ways that the community can not guarantee.

Q: Are companies really going to do this?

A: Yes, already we have received a number of serious queries from companies about producing Linux drivers for their devices. More information will be available later when details are firmed up.

Q: Can you write a driver for my [insert device name here] to get it to work? It isn't made anymore and no one has the specs for it.

A: Sorry, but this project is for devices in which we have the specification and hopefully the manufacturer's support. We don't have the time or effort that is needed to reverse engineer the device on our own, sorry.

Q: Do you need developer help for this project?

A: Yes, just drop me an email and I'll add you to the list of people who have volunteered to help out. We are always glad to accept help.

Q: Are companies actually taking you up on this offer?

A: Yes, the initial response to this was amazing, a measurable number of new Linux drivers will be created thanks to this program.

Q: What about helping to get out-of-the-tree GPL drivers into the main kernel tree?

A: A number of people have offered to help out with this in the past, and all code is welcome to Linux. But we aren't going to be pulling in code to the main kernel tree without the permission of the authors.

Q: What about the BSDs?

A: What about them? They are free to do whatever they wish, I have no input into their development at all, sorry.

linux kernel monkey log - Tue, 30/01/2007 - 1:07am

Yes, that's right, the Linux kernel community is offering all companies free Linux driver development. No longer do you have to suffer through all of the different examples in the Linux Device Driver Kit, or pick through the thousands of example drivers in the Linux kernel source tree trying to determine which one is the closest to what you need to do.

All that is needed is some kind of specification that describes how your device works, or the email address of an engineer that is willing to answer questions every once in a while. A few sample devices might be good to have so that debugging doesn't have to be done by email, but if necessary, that can be done.

In return, you will receive a complete and working Linux driver that is added to the main Linux kernel source tree. The driver will be written by some of the members of the Linux kernel developer community (over 1500 strong and growing). This driver will then be automatically included in all Linux distributions, including the "enterprise" ones. It will be automatically kept up to date and working through all Linux kernel API changes. This driver will work with all of the different CPU types supported by Linux, the largest number of CPU types supported by any operating system ever before in the history of computing.

As for support, the driver will be supported through email by the original developers, when they can help out, and by the "enterprise" Linux distributors as part of their service agreements with their customers.

If your company is worried about NDA issues surrounding your device's specifications, we have arranged a program with OSDL/TLF's Tech Board to provide the legal framework where a company can interact with a member of the kernel community in order to properly assure that all needed NDA requirements are fulfilled.

Now your developers will have more time to work on drivers for all of the other operating systems out there, and you can add "supported on Linux" to your product's marketing material.

This offer is in effect for all different types of devices, from USB toys to PCI video devices to high-speed networking cards. If you manufacture it, we can get Linux drivers working for it.

For any questions about this program, please feel free to respond to this email, or contact me directly at greg@kroah.com. I will also be available at FreedomHEC 2007 held adjacent to WinHEC, if anyone wants to bring devices and work face-to-face.

linux kernel monkey log - Tue, 09/01/2007 - 11:13pm

The book I was working on for most of 2006 is now finally showing up in bookstores so it's time to announce it here.

Linux Kernel in a Nutshell is now availble online, for free, from the kernel.org world-wide mirror systems (so that I really have no idea how many people download it, and that's fine with me.)

To quote the book's official site:

If you want to know how to build, configure, and install a custom Linux kernel on your machine, buy this book. It is written by someone who spends every day building, configuring, and installing custom kernels as part of the development process of this fun, collaborative project called Linux.

I'm especially proud of the chapter on how to figure out how to configure a custom kernel based on the hardware running on your machine. This is an essential task for anyone wanting to wring out the best possible speed and control of your hardware.

Not satisified with just offering up electonic PDF versions that mirror the book as it was exactly printed, I have availble the DocBook source that is heavily marked up by some tools that was used to generate the PDF files from.

Also, as a first in the history of publishing books (that I know of), the entire revision history of the book is availble as a git archive so you can see how slowly the process went, how bad my writing really is before the excellent editors at O'Reilly get ahold of it, and how much the Technical Reviewers for the book really helped me out in making this something that everyone will want to have on their bookshelf.

It weighs in at a slim 175 pages, which is amazing as both the editor and myself thought it would be about 350 pages before the layout people attacked it with a bunch of small pointy fonts, saving a few forests in their glee to pack as much information as possible on every printed page.

And yes, to answer all of the questions that people have asked when reading the introduction, the book did start out at over 1,000 pages, consisting of nothing other than a description of every kernel configuration option possible (see the git tree if you don't believe me). Luckily, cooler heads prevailed, and a whole bunch of useful content was written by me to make this something that would acually sell.

What are you waiting for? Go buy a copy or if you are cheap, just download the thing and start building kernels!

What next? No more books for a while, that's for sure. But before quiting the writing gig, I was lucky to write a chapter for a special compilation project from O'Reilly that has turned into an amazing book that I feel honored to have been able to contribute to. More on that in a few months when it gets closer to publication date.

linux kernel monkey log - Thu, 14/12/2006 - 9:19am

Google has just opened up a patent search service that is going to put a number of research companies out of business soon, bringing the ability for anyone to easily search the US patent database.

For example, here's the two patents with my name on them (no, I am not proud...)

And here's a few that my father did (real inventions, not process patent crap mine above...)

But for more fun, here's one from Microsoft where they site a message on the Linux kernel mailing list in their publication list.

And this list should give people a pause when they think that no one is out there doing patents on Linux kernel things.

But this patent looks like my favorite one right now as I'm sure Dave Jones would agree.

linux kernel monkey log - Thu, 14/12/2006 - 1:45am

It's always an interesting day when you get to write a kernel patch, at the urging of Andrew Morton, that notifies the world that non-GPL Linux kernel modules will not work after January 2008 and write some poetry all in the same message.

Ok, Andrew didn't ask for the poetry, but it is an interesting way to protect a copyright license in such a way that all courts today will easily understand it. Just have the kernel build put the copyrighted poetry into a section of all kernel modules, and then if someone tries to lie about the license of the built module, they can easily be caught. Even lawyers understand poetry...

linux kernel monkey log - Thu, 14/12/2006 - 1:45am

A large number of people have expressed interest recently in the userspace i/o driver core which allows userspace drivers to be written to handle some types of hardware.

Right now the UIO core is working and in the [-mm kernel releases][mm]. It's been rewritten from the last time patches were posted to lkml and is much simpler. It also includes full documentation and two example drivers and two example userspace programs that test those drivers.

This core allows for a very tiny kernel driver to be written to handle the interrupt generated by the hardware. Everything else can be done in userspace (direct memory access, interrupt processing, controller logic, etc.) In some instances, this framework has shown a noticable improvement over an all-in-kernel driver.

But in order to get this core into the kernel tree, we need to have some "real" drivers written that use it. So, for anyone that wants to see this go into the tree, now is the time to step forward and post your patches for hardware that this kind of driver interface is needed.

If no such drivers appear, then there is a very slim chance that this interface will be accepted into the tree.

The patches can be found in the -mm releases or at:

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio.patch - UIO core

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio-documentation.patch - UIO documentation

http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio-dummy.patch http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/uio-irq.patch - two example kernel modules and userspace programs showing how to use the UIO interface.

linux kernel monkey log - Sat, 25/11/2006 - 2:14am

The whole Linux ecosystem is quite strange for people who are used to the way "traditional" companies operate. Here's a short primer for those who are need a reminder.

In a "traditional" technology-based company, you have the executives making the deep strategic decisions, the managers carrying out those decisions and telling the engineers what to develop (yeah, there's marketing and sales in there too, but for this essay, let's just ignore them for now.) Normally the executives and managers and engineers are focused on creating the "next best thing" in their industry, and are directly competing with other companies in the same industry.

And this works well, everyone is used to it, and whole major portions of our world's economy depend on this model.

Then there's Linux.

And by Linux, I'm going to focus on the kernel here, but you can extrapolate the idea to any part of the Linux distribution ecosystem too, it all pretty much works the same, in one way or the other.

In Linux, the rules are different, as well as the way the whole system works.

For Linux, the "product" is created by engineers working in the community. These community members get together and work for a common project, making it the best that they know how. These engineers are a very large group, coming from a huge number of different companies and backgrounds.

Companies have realized that Linux is a good thing to use, and have tried to figure out how to make money bundling it up into a semi-stable release and supporting it.

These companies have executives, managers, and engineers much like a traditional technology company has. But here's where things start to work differently. These executives still make deep strategic decisions, the managers work to carry out those decisions and tell the engineers what to develop, but the engineers have to work with the community in order to achieve those goals. These engineers rely on the community to be able to create something that the whole company can then bundle up and make money off of.

Because of this reliance on the community, companies tend to fall into two broad categories (yes, there are more categories, but for now, let's keep things simple.):

• ignore the community. These companies merely bundle up whatever the community creates and sells that. As such, they do not have much influence on the product and become minor players in the market.
• embrace the community. These companies hire members of the community or allow their employees to join the community, as they realize that it is the only way to drive the direction of Linux in ways that they feel it should go. Because of this, the company is able to provide things to their customers a little bit ahead of when the companies in the first category can, and they can support their customers much better as the community members are able to directly help them.

Companies in the first category, can pretty much act however they like, their executives can make deals with whomever, and they can try to be a direct competitor with other companies, and no one in the community will really care, as they are bit players and don't really matter.

Companies in the second category, must pay attention to the community. Their executives can't go around doing things that are not in the community's best interest, their managers can't try to directly compete with their competitors, and their engineers can't ignore the community's wishes or opinions. If any of these things happen, the company will soon be ignored by the community, forced to implement all of the great things the executives and managers dream up on their own, and slowly end up becoming a member of the first category of companies, relegated to being a bit player, as the community, and the companies that are real members of the community, pass them by and go off on their own way.

History is already littered with the remnants of companies who originally started out embracing the community, but then make the mistake that they think for some reason they are a "traditional" technology company.

It will be interesting to see how well the current companies in the Linux ecosystem really understand how different their business environment really is.

Note, all ideas that you might have about what real-life company falls into which category, or why this essay was ever written in the first place, are all in your own mind...

linux kernel monkey log - Tue, 07/11/2006 - 12:48pm

I'm currently in Tokyo for an OSDL board meeting and the OSDL Japan Linux Symposium. I had a short amount of spare time and wandered through a large electronic store and found my "Linux Device Drivers, third edition" translated into Japanese.

So I had to buy it:

It is much more expensive than the US version, and it does look a lot thicker than the English version. But for me, it was worth the price just to now know the Japanese phrase for "Linux device model" is "Linuxデバイスモデル"

"driver" is "ドライバ" and "hotplug" is "ホットプラグ" both of which I think I need to ask someone what that translation really means...

Hm, anyone know of any good gadget stores in Tokyo where I can pick up some different USB toys? I have a few hours to spare tomorrow afternoon and can pop over to Akihabara (the electronic district), so pointers of specific shops to look at there would be appreciated.

linux kernel monkey log - Sat, 04/11/2006 - 8:04am

Well, as my inbox seems to have recovered over the recent Novell/Microsoft deal that was announced yesterday, and a number of people have asked what I feel about this, I might as well post it publicly so I don't have to keep repeating myself.

First off, I am an employee of Novell right now, but I'm speaking for myself, I had nothing to do with this deal, no one consulted me for anything except to let me know a few days before it was announced what was going to happen, I have not read the document describing the deal between Novell and Microsoft, nor do I really have any inclination to do so (because then I'll have to answer more questions than I have been...)

The agreement doesn't seem to have anything to do with the kernel, only Samba, OpenOffice, Mono, and Xen (and we all know Xen isn't getting merged into mainline any year soon, so that isn't really a kernel issue...)

I don't really think this is a big deal at all for the Linux kernel community and code. We are no worse off than we were last week before this announcement, and we actually might be a bit better off now, depending on the actual wording of the agreement (which again, I have not read.)

Linux will continue on to grow and spread into more and more places. And it looks like Microsoft will be helping out in that spreading. This means that we might start to pick up some Microsoft developers to help with the kernel as they get access to the code and have to do testing against it and with it (what, you didn't know that we have a number of ex-Microsoft developers helping with Linux already?)

We've successfully assimilated developers who used to work on AIX, HP-UX, OS/2, embedded OSs, BSD, Dynix/ptx, Solaris, vxWorks, and many others, so what's just one more operating system to add to that list?

Oh, and if Novell has somehow made a "huge mistake" by doing this deal and ends up getting crushed like a bug, then oh well, everyone can point and say "I told you so" and feel nice and smug.

But Linux will survive that because the developers will all still be around and continue to work on it. Our community and code base will remain intact, as nothing can stop that from continuing slowly on toward our true goal.

linux kernel monkey log - Thu, 28/09/2006 - 6:17pm

It seems that the real issue behind all of the recent vitriol about the messages from the Linux kernel developers about the GPLv3 issues comes down to the basic "Free Software" vs. "Open Source" issues.

Linus hits the nail on the head, detailing how the kernel developers, for the most part, never bought into the FSF's crusade, and in the end, eclipsed them by achieving world domination despite ignoring the FSF's rhetoric.

Also, Lawrence Lessig brings up the big point that the FSF needs to realize that the GPL is much bigger than them, and they should pay attention to the whole community when changing these licenses:

So his [RMS] challenge is whether he evolves these licenses in ways that fit his own views alone, recognizing those views deviate from many important parts of the movement he started. Or whether he evolves these licenses to support the communities they have enabled. This is not a choice of principle vs compromise. It is a choice about what principle should govern the guardians of these licenses.

It's part of the learning process when approaching the open source / free software process. Once you let your code/ideas go, they get used by others in ways that you sometimes don't like. Embracing that use and realizing that your code/ideas are now not your own, but part of the larger community and ecosystem as things to be built on and modified is a sign of maturity.

Trying to keep a tight grip on your code/ideas and ignoring others really isn't the true philosophy of what the FSF has been espousing over the years. Hopefully they can realize this and change the GPLv3 to be more inclusive.

linux kernel monkey log - Thu, 28/09/2006 - 12:17am

Been really busy since OLS, hence the lack of any real posts here, sorry about that. I was using all my spare time, and then some, pushing to finish up a new book, Linux Kernel in a Nutshell, which just went off to the production people this week. As per the web site, it will be out sometime in January of next year. I'll be setting up a web site for it in a month or so as it works its way through the production process.

Oh yeah, the book is being released under the same license that we did the Linux Device Drivers book with, so yes, the whole thing will eventually make it online in some form for people to use that way.

Now, time to rest and get back to the things I like doing better than writing text, like writing code...

linux kernel monkey log - Fri, 22/09/2006 - 5:31pm

A number of Linux kernel developers got together and made a unscientific survey of what they felt about the current version of the GPLv3. This information was sent to the different companies that are on the Committee B of the GPLv3 review process. The results were posted today on the linux kernel mailing list for everyone else who might be interested in seeing them.

Also, a smaller number of us got together and wrote a position paper on why we feel the currently drafted version of the GPLv3 is such a bad thing right now for both the Linux kernel, and all current Linux distros. That paper was also posted here, if anyone is interested in seeing it.

linux kernel monkey log - Mon, 24/07/2006 - 2:55am

The organizers of OLS were kind enough to allow me the opportunity to speak this year as the closing keynote speaker. Here's the slides and text of my talk (well, the text is what I intended to say, the actual words that came out probably sounded a bit different.)

If you want to link directly to this talk, please use this link.

See more ...

linux kernel monkey log - Thu, 29/06/2006 - 10:53pm

Way back in 2002, Pat Mochel and I floated the idea of a unified driver model at the kernel summit. My goal for it was to be able to solve the persistant device naming problem that Linux had at the time, which would allow us to remove devfs from the kernel tree.

A few years ago, udev solved the issue of persistant device naming, but devfs lingered on in the kernel tree, despite my many efforts to remove it.

Until today.

Its a good feeling to be able to cross the longest remaining item off of my TODO list.