|
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... posted Wed, 14 May 2008 in [/diary]
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. posted Mon, 07 Apr 2008 in [/linux] 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. posted Tue, 01 Apr 2008 in [/diary] 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... posted Sat, 19 Jan 2008 in [/diary]
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: 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 :) posted Mon, 22 Oct 2007 in [/linux] 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: 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... posted Thu, 27 Sep 2007 in [/linux] 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:
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? posted Wed, 11 Jul 2007 in [/diary] Spoken at the final party at this years Linux Symposium by a kernel developer working for a Linux distribution that will not be named:
posted Sun, 01 Jul 2007 in [/diary] 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. posted Mon, 25 Jun 2007 in [/diary] 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. posted Sat, 23 Jun 2007 in [/diary]
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 kernelsAn "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 modelHere 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:
Potential solutions and pros and cons of them
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. posted Tue, 19 Jun 2007 in [/linux]
Ugh, I've been traveling way too much lately, here's a summary of my trips in the past 2 months:
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:
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... posted Fri, 01 Jun 2007 in [/diary] 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:
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. Thanks to everyone who read and provided feedback to early versions of this document. This includes the whole SuSE kernel development team (not all of whom agree with this document, but they provided their input anyway), and members of other companies that probably do not want to be listed here... posted Wed, 28 Mar 2007 in [/linux]
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. posted Fri, 09 Feb 2007 in [/linux]
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. posted Mon, 29 Jan 2007 in [/linux] |
|
My Linux Stuff RSS |
|
||