Free Software Linux

In an announcement for the 2.6.25.10 stable kernel, Greg KH noted, "it contains a number of assorted bugfixes all over the tree. And once again, any users of the 2.6.25 kernel series are STRONGLY encouraged to upgrade to this release." The emphasis on the word strongly led to a lengthy discussion about how security fixes are handled in the Linux Kernel. Linus Torvalds replied, "I personally consider security bugs to be just 'normal bugs'. I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special." Later in the thread he went on to explain, "one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior.

"In the early days, the project was conceived as a way of getting fresh blood into kernel development by giving them fairly simple but generally useful tasks and hoping they'd move more into the mainstream," began James Bottomley starting a thread titled Fixing the Kernel Janitors project. He continued, "if we wind forwards to 2008, there's considerable and rising friction being generated by janitorial patches,", references a recent thread complaining about worthless patches hitting the lkml. Later in the thread he added:

Finding bugs in your code can be quite nasty—especially if you don’t know where to look. However, finding bugs automatically does not require astronaut training. I think it’s time to leave that “pleasure” to free (as in freedom) automatic static code review tools like the ones reviewed in this series of articles.

A thread on the Linux Kernel mailing list discussed the process in place for reporting, bisecting and fixing bugs. In response to a suggestion that some of the issues could be solved by introducing new procedures, Al Viro retorted, "we've got ourselves a developing beaurocracy. As in 'more and more ways of generating activity without doing anything even remotely useful'. Complete with tendency to operate in the ways that make sense only to bureaucracy in question and an ever-growing set of bylaws..." Later in the thread, David Miller agreed and noted that ,"the resulting 'bureaucracy' or whatever you want to call it is perceived to undercut the very thing that makes the Linux kernel fun to work on. It's still largely free form, loose, and flexible. And that's a notable accomplishment considering how much things have changed. That feeling is why I got involved in the first place, and I know it's what gets other new people in and addicted too."

Saturday, January 19th, 2008, marked the 30-year countdown to the Y2K38 wraparound of regular 32-bit UNIX time. UNIX internal time is stored in a data structure using a long int, containing the number of seconds since 1970. On a 32-bit machine this value is sufficient to store time up to the 18th of January 2038. After this date, 32-bit clocks will overflow and return false values.

"Over the last few years, I’ve come to accept the fact that regardless of my attempts to quit this job, I am fundamentally a programmer. I wrote a book about security, I am the Editor In Chief of Free Software Magazine, but in the end I am still just a programmer. A lucky one, I must admit. Until last month, I had been blessed by the fact that either the software I wrote was owned by somebody else after a short contract (and therefore it didn’t matter to me once I had completed it: somebody else eventually took it over), or that what I programmed had been created just for myself (I was the only user of the software… bliss!). This changed when I became a free software programmer. I have recently released what I consider an important project: Drigg. read more