The software development firmament has lost one of its brightest lights. Dennis Ritchie, who created C and co-created Unix, has reportedly passed away after a long illness.

The self-effacing Ritchie was the recipient of the development world's most prestigious awards, including the ACM Turing Award, the IEEE Richard W. Hamming Medal, the IEEE Computer Pioneer Award, the IEEE Emanuel R. Piore Award, a Bell Laboratories fellowship, the ACM Software System Award, the U.S. National Medal of Technology and Innovation, and the Japan Prize for Information and Communications. Ritchie was elected to the U.S. National Academy of Engineering in 1988.

Ritchie's C language is still widely used. It has also served as the basis for C++, Java, C#, Objective-C, Perl, Python, and PHP. Unix is omnipresent, as is its open-source derivative, Linux. Ritchie's influence on our profession has been both deep and broad. He will be sorely missed.

Web recommendation: I am more comfortable writing paragraphs than class declarations, but even I hate writing documentation. Unfortunately, I've never had the luxury of turning over my apps to a tech-writing team...I've had to write the docs myself. It's a tedious and thankless task. Maybe that's why so much documentation is so lousy. Even if you aren't responsible for user docs, you should still document your work for the benefit of other developers who use it – and developers who will use it in the future. Get started with this thoughtful blog post from ProgrammableWeb.com: The Six Pillars of Complete Developer Documentation. Food for thought. J.D. say check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He recently relocated to a small town outside Belgrade – stop by if your travels take you through Serbia.

Chatting with some of my friends the other day, we were lamenting the fact that there really isn't a 10-year Linux. Red Hat will sell you long term support for almost any version you're willing to pay for, but for the most part, when it comes to long term support for a Linux kernel and distribution release, you're looking at 2 to 5 years of support, max. And, yes, this is the sort of thing I talk about with my friends over soda pop. We're nerds.

Couple that with the fact that the release cycles themselves factor heavily into your decisions, and you've got a recipe for a rather small pool of possible Linuxes to use. You can't use Debian, because their release cycle is glacial. You can't use Ubuntu because their release cycle is break-neck. Is there room for a Linux that is released once a year, but each year's release has all security patches and bug fixes ported to previous versions?

And the short answer, we decided, is no. But this isn't because the market is moving away, or has already decided to stick with Red Hat, Suse, or Oracle. It's because we're all doing it wrong.

In 2003, you didn't want to touch the OS layer. Your app worked on a single instance of an OS, and it ran on a specific version, due to some requirement, or compatibility issue. But today, that whole paradigm of sticking with an old system to avoid change is rather wrong headed. When it comes down to it, if you're building a Web application, you really don't need to worry about the OS layer too much. Certainly, realtime and high availability systems still need to be concerned with this issue. But for the vast majority of applications, I'm convinced that the long-term problem is going away.

The days of a Linux kernel patch breaking your application should really be behind you. When it comes right down to it, it's the items in your stack over which you should be executing version control. The right versions of the right libraries and components are still essential, and likely will be for years to come.

But the actual OS you're using should be getting more and more irrelevant. The OS is just the container for your application, and considering how stable modern operating systems are, you should be able to contain that application indefinitely, barrring any unforeseen bugs or glitches in the OS layer.

Of course, things aren't playing out like this quite yet. Obviously, moving to a new release of Linux the day it comes out is always going to be a bad idea. But as our applications become more and more modular and transportable, thanks to platform as a service and other cloudy innovations, the OS they run on should become less and less relevant.

So, we're now drawing a line in the sand. If you're worried about upgrading an OS that's below a Web or mobile application, you're doing it wrong. Realtime, embedded and other complex and high performant system designers, you're still doing it right. We'll check back in in a few years to see if, in fact, this is a trend.

And, of course, the inverse of this whole blog entry seems also to be true: as the OS layer becomes less relevant, there's less reason to upgrade it, ever. If it works, you might as well keep that virtual machine and disk image in its present state forever. Unless, of course, you have to update something.

Have you heard of the Freedom Box? It's the brainchild of professor Eben Moglen of the Columbia University School of Law in New York.

In February 2010, Moglen addressed a regular meeting of the Internet Society in New York. In his talk – video of which is available widely over the net, including here – Moglen discussed the security dangers of the current model of the Internet. Centralized servers maintain information about us plus logs that compile histories of our activities, Moglen points out. These servers are typically under corporate control and the user information on them is routinely used – misused – by their owners.

This is a dangerous computing model, Moglen says. And it's a bad deal for users. Free Web-hosting (as offered by Facebook and other social-networking sites) and e-mail (as offered by Google and other hosts) isn't really free: It's offered in exchange for full-time spying. Users have ceded control of vast amounts of their personal information without intending to, nor understanding the consequences.

Targeted advertising is just the beginning. Moglen cites a research project that found it was possible to identify closeted gay users on Facebook. The task was relatively easy, Moglen explains. And he warns that this kind of data-mining is just the tip of the iceberg.

The solution, Moglen says, is the Freedom Box – a small, inexpensive Web server that you plug into the wall and forget about. The Freedom Box handles your mail and file transfer and commercial transactions and social networking without exposing you to external servers whose sponsors may not have your best interests at heart. Such a server could be the size of a cell-phone charger, Moglen speculates, and sell for $30 or so once the devices are made in production quantities.

The software component of the Freedom Box is free, of course. A project to create and assemble the required software is under way at the FreedomBox Foundation. The software is based on Debian GNU/Linux plus readily accessible free-software components. The foundation's tech lead is Bdale Garbee, former project leader of Debian.

You don't need me to tell you that the current state of Internet security is a catastrophe waiting to happen. Check out the Freedom Box. Get involved by contributing money or code or ideas. It's good stuff.

Web recommendation: Why do software-development superstars have such primitive Web sites? I recommended Charles Petzold's site in a recent blog post despite its lackluster layout and 1990s-style design. Now I find that I need to point you to the personal site of free-software legend Richard Stallman, whose accomplishments as an Internet pioneer and political activist are too numerous to list here. Stallman is a little strident and a little paranoid for my tastes, but he is that rare individual, a certified idealist. And he has literally changed the world. His Web page is a cornucopia of thoughtful writing despite its bare-bones plain-text appearance. You'll find it here: http://stallman.org/. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He recently relocated to a small town outside Belgrade – stop by if your travels take you through Serbia.

Developers are now writing more applications in Apple's Macintosh environment than they are in Linux, according to a June survey by research firm Evans Data Corp. Both still lag far behind Microsoft's Windows platform, though, the study noted. More than 80 percent of the 400 North American professional software developers responding to the survey said they program on Windows, while 7.9 percent now use Mac OS and 5.6 percent prefer Linux. The survey also found that Linux still leads Mac OS as a development target, with more than twice as many developers targeting Linux as Mac OS. "Windows firmly remains king, but developers are obviously attracted to Apple's devices, while at the same time Linux has lost some of its luster after years of only single-digit adoption," said Janel Garvin CEO of Evans Data Corp. Among the other findings:

* Mobile and cloud development will increase in importance over the next three years, while the DevOps movement will be least important, developers said.

* Nearly half of the respondents said they use or expect to use Java ME for development.

What does this mean? The findings most likely reflect the fact that developers are writing apps for more than the desktop, and Apple is leading the way for smartphone and tablet development. Is it simply that Apple has all the momentum right now, and Linux gives the appearance of having stalled (only recently being upgraded to version 3 to reflect some minor tinkering with the kernel)? Perhaps. But the key word here is "professional." These are developers working for companies that are willing to spend for the latest technology, that want to go where the pack is heading, and that want to be seen as ahead of the curve (or at least on top of it). Does it mean Mac OS is better or more stable than Linux? No. It simply means more companies are spending on iMacs, that come preloaded with lots of cool applications. Less bother, less DIY means more productive programmers.

Linux has finally made the jump to 3.0. The move is not an Earth-shattering one. A few months back, Linus Torvalds suggested it was time to move the version numbers forward, if only to fix the fact that the term "2.6 kernel" had effectively become meaningless. I'll post in the message Linus sent to the Linux kernel mailing list, sans code. The original post includes the list or recent changes to the kernel. The 3.0 insinuates that this was a big break, but in reality, it's a fairly standard update.

So there it is. Gone are the 2.6.bignum

days, and 3.0 is out.

This obviously also opens the merge window for the next kernel, which will be 3.1. The stable team will take the third digit, so 3.0.1 will be the first stable release based on 3.0.

As already mentioned several times, there are no special landmark features or incompatibilities related to the version number change, it's simply a way to drop an inconvenient numbering system in honor of twenty years of Linux. In fact, the 3.0 merge window was calmer than most, and apart from some excitement from RCU I'd have called it really smooth. Which is not to say that there may not be bugs, but if anything, there are hopefully fewer than usual, rather than the normal ".0" problems.

And as I already mentioned yesterday, I'm hoping the 3.1 merge window will be calm too, because due to the delays the latter half of the merge window will fall into my vacation time. I briefly considered simply waiting two extra weeks, but quite frankly, that wouldn't really have solved anything (it would have made the merge window instead fall into LinuxCon and my divemaster weekends).

So I'm going to try to keep to the normal two-week merge window, but if it ends up being too busy for me to keep up, I may end up extending the window just so that I can merge everything. However, even if that happens, that will *not* mean that I will accept big pull requests for longer, it just means that I may end up delaying things to catch up with timely merge requests.

That said, judging by past experience, the summer merge windows often tend to be quieter, so maybe I worry needlessly. Much of Europe is starting to go on vacation, and parts of the US are being fried to a crisp, so maybe 3.1 will be calm too.

Anyway, what has changed since -rc7 is mainly some RCU interactions with the scheduler, and the RCU problems should hopefully be behind us. The pathname lookup race is also fixed. There's a few DRI fixes (i915 modesetting, and some Radeon fixes), and Al walked through some more esoteric VFS d_lock issues. Other than that it's really pretty small and random.

The shortlog from -rc7 is appended, the bigger "everything since 2.6.39" list is obviously unmanageable.

Linus

In case you missed it, Linux is turning 3. Well, really, it's turning 20. 20 years of Linux have come and gone, and yet, until recently, we've been stuck in 2.6.x kernel hell. The kernel has been in the 2.6 phase for almost half of that 20 years, in fact. This has caused endless annoyances for developers and distribution managers, sadly.

You see, because my laptop runs kernel 2.6.32, it is relatively up to date. It includes the Completely Fair Scheduler, and a host of other major improvements over, say, a machine running 2.6.20. One might even suggest that two machines running kernels that far apart are essentially running completely different Linuxes. It's like the difference between Windows XP and Windows 7.

And, of course, marketing always gets involved. When buying a Linux-based device, for example, it's almost a given that the marketing materials will claim the machine uses an "up-to-date 2.6 Linux kernel!" Which is like saying my Buick uses an up-to-date radio that accepts portable media. The secret that's being left out in both cases is that the definition of a 2.6 kernel is just as broad as the definition of portable music media. Heck, records are portable. So are tapes. And a Linux machine running 2.6.5 is still a 2.6 kernel-based Linux machine.

Here's Linus discussing the 3.0 shift on the Linux Kernel Mailing List:

I decided to just bite the bullet, and call the next version 3.0. It will get released close enough to the 20-year mark, which is excuse enough for me, although honestly, the real reason is just that I can no longe rcomfortably count as high as 40.

The whole renumbering was discussed at last years Kernel Summit, and there was a plan to take it up this year too. But let's face it - what's the point of being in charge if you can't pick the bike shed color without holding a referendum on it? So I'm just going all alpha-male, and just renumbering it. You'll like it.

Now, my alpha-maleness sadly does not actually extend to all the scripts and Makefile rules, so the kernel is fighting back, and is calling itself 3.0.0-rc1. We'll have the usual 6-7 weeks to wrestle it into submission, and get scripts etc cleaned up, and the final release should be just "3.0". The -stable team can use the third number for their versioning.

So, there you go. Version 3.0 mystery solved. While other projects spend time pushing out big changes to coincide with major point release updates, Linux has simply moved to 3.0 because it was time. No fancy new features, no crazy hooplah about how 3.0 wil change your life. It's just a number.

Of course, fsck -f -y /dev/node just forces a preen, but it's still funny.

The Wall Street Journal reports that VMware is going to buy SuSE Linux from Novell. What, exactly, that would leave Novell, I can't really say. But I think I know exactly why VMware wants SuSE, and it's got very little to do with actual Linux. It's not about the Linux so much as it is about the Mono.

You see, VMware has Microsoft squarely in its sights. The current game plan for the company is to grab up frameworks and supporting infrastructure to allow VMware to squeeze platform players out of the equation. The biggest such platform is Windows. So, what do you do if you want your customers to cut out one of their vendors, while still allowing those companies to reap the benefits of having dozens of .NET applications? Why, you buy up an open source implementation of .NET.

It may sound a tad far fetched, but I truly believe that the most important thing VMware is getting if it buys SuSE is Miguel de Icaza. If Mono does end up at VMware, you can bet they'll soon be offering a free environment in which to run your .NET applications without the need for a Windows license.

Just a quick note to point out that Linux 2.6.35 was deemed fit for the world by Linus on Sunday. There's a great summary of the change log at Kernel Newbies. Here's an even further streamlined summary:

• 1. Transparent spreading of incoming network traffic load across CPUs
  2. Btrfs improvements
  3. XFS Delayed logging
  4. KDB kernel debugger frontend
  5. perf improvements
  6. Graphic improvements
  7. Memory compaction
  8. Support for multiple multicast route tables
  9. L2TP Version 3 (RFC 3931) support
  10. CAIF Protocol support
  11. ACPI Platform Error Interface support

If you use Linux and you program, you've probably used the ldd command to track down a dependency or two. If you use it with any frequency, you definitely need to read this article. Peteris Krumins explains that ldd is not an innocuous little utility, devoid of malicious possibilties. From the blog entry:

For example, you can put a malicious executable in ~/app/bin/exec and have it loaded by ~/app/lib/loader.so. If someone does `ldd /home/you/app/bin/exec` then it’s game over for them. They just ran the nasty code you had put in your executable. You can do some social engineering to get the sysadmin to execute `ldd` on your executable allowing you to gain the control over the box.