Linux kernel

Navy’s ship cancelation a blow for real-time Linux, IBM

The U.S. Navy’s cancelation of its $20 billion Zumwalt destroyer contract last week because of a 50% price hike is disappointing for the Linux community and surely must be for IBM The Armonk, N.Y.-based computer company developed Java-based, real-time capabilities to the Linux kernel specifically for the Zumwalt to ensure that all shipboard systems will run with precision timing, particularly battle systems. The Zumwalt’s unified computing system, developed by general contractor Raytheon Co.. in Waltham, Mass., runs on an IBM BladeCenter and IBM x86 servers on Red Hat Enterprise Linux.

Since the 2005-2006 Navy design undertaking, IBM has incorporated its technology in IBM WebSphere Real Time, a computing environment for running real-time Linux applications, and recently won an innovation award for its real-time kernel project at this year’s Red Hat Summit.

Now, after the completion of only two destroyers, the contract has been aborted, which surely means a hefty chunk of lost hardware sales for IBM but, more significantly, a step backward for shipboard computing technology, in general, and Linux in particular.

IBM spokesman Mike Darcy said he didn’t know the impact of cancelation on future IBM revenues but said that IBM will continue to work with other customers, defense and financial sectors among them, as interest “continues to grow” in real-time Linux operations.

“Real-time Linux will continue,” Darcy said. “This [the Zumwalt project] is a great showcase for Linux technology.”

Raytheon spokesman Jonathan Kasle agreed.

“We don’t believe the Navy can afford to put old technologies onto any ships,” he told the Boston Globe last week. “Zumwalt technologies advance mission capabilities to address current and evolving threats and support … lower ship personnel levels and lower operating costs. These technologies can be leveraged for future or existing ships.”

According to Darcy’s general reference to current “defense” customers, it appears that the military is already doing so. Let’s hope so. Reverting to old technology on new Navy ships is not the way to go.

Red Hat previews virtual management tool

At a mid-morning session during the Red Hat Summit in Boston today, a standing-room only crowd of more than 125 attendees got a preview of oVirt, a “next-generation open source virtualization management solution.”

Currently in beta, oVirt comprises two components: oVirt Managed Node, which is an embedded hypervisor based on a Linux kernel and KVM; and oVirt Server Suite, an administrative console that includes a Web interface and has functionality for tasks related to virtual machine management, such as status monitoring, performance monitoring and visualization and authentication.

With oVirt, IT administrators get a picture of “what’s going on in your server room from a virtualization perspective,” said Red Hat CTO Brian Stevens. The current generation of virtualization management tools, contends Stevens, fall short for customers because they are proprietary and do not integrate into the enterprise.

The oVirt infrastructure integrates with several open source projects, including libvirt for virtual machine management, FreeIPA for directory services, Cobbler and Koan for provisioning, and collectd for performance data collection.

Currently oVirt enables IT administrations to collect data from managed hosts; eventually Stevens said that oVirt will include automation capabilities to allow IT administrators to establish service-level agreements around physical and virtual machines and migrate machines accordingly based on those levels.

Linux Kernel 2.6.24 released

Last Friday saw the release of the Linux Kernel version 2.6.24. This new version does not include anything spectacular (Linus’ words, not mine), but does include some updates to network drivers. These improvements will assuredly make some users experiencing network issues happy. You can go to http://www.kernel.org to download and build your new kernel.

But should you? Is there ever a reason to build your own kernel and not just wait for it to come down the pipe from your distribution’s software repositories? For the most part, no, you should not need to build your own kernel for enterprise Linux installations these days. Most kernels that come with stock Linux installations such as Red Hat, SUSE and Ubuntu are fine.

However, some occasions require building a new kernel, for example:

- Licensing changes, which forces one to redact certain bits from the stock kernel (see my previous SVV blog post on 2.6.23 and VMware)

- Support for a new CPU ID that is not yet present in the Kernel

- Performance improvement for servers tasked with performing intense calculations

Got any other good reasons for building a kernel? Send them to us.

Ubuntu Releases Alpha Version of Server 8.04

The first alpha release from the growingly popular Ubuntu Linux is now available. The build is clearly marked as a not ready for prime time player, but offers a sneak peak at the next release, 8.04, expected in April 2008. You can also publicly contribute to the bug tracking mechanism should you choose.  I installed the alpha release, Hardy Heron Alpha-1 which was generally indistinguishable from other Ubuntu releases, namely the gutsy 7.10 release.

Some takeaway notes about this alpha release are that it includes Xorg 7.3 for the X Window System manager and pulls in some Debian changes as well.  It uses kernel 2.6.22, which is the same as gutsy 7.10.  Comparatively, Red Hat Enterprise Linux 5.1 is on the 2.6.18 kernel and Novell Suse is on the 2.6.16.21 kernel.  If you use Ubuntu 8.04 Server, keep in mind that packages may detect a newer version of the kernel and want to recompile.  A good example is VMWare tools for guest operating systems. 

Canonical Ltd. does not support the alpha releases of Ubuntu, which is to be expected.   When 8.04 is released after the community development process is complete, Canonical will support the end-state product.

More information about the Ubuntu release can be found at:  http://www.ubuntu.com/testing/hardy/alpha1

It’s 10 o’clock. Did you remember to turn packet forwarding on?

So I am on a VPN kick lately; I wonder if it shows? I spent the last week setting up and tweaking Openswan on an Ubuntu box in order to allow me to connect to my home network with my MacBook Pro. I finally got it working — you can see some of the fun gotchas you might run into when using Leopard to connect to Openswan at my own blog — but I could not actually see anything on my home network. Well, it turns out I seem to be a special case. (My wife is insisting that I had a prefix “head” to case). My VPN box was never previously a part of my home network topology. It was a DNS and DHCP server, but it played no role in packet switching or forwarding. I guess most people install VPN software on a Linux box that is already a router of some sort. Thus the Kernel did not have packet forwarding turned on and the VPN server was not forwarding packets to the rest of the network.

To turn packet forwarding on simply issue this command:

echo "1" > /proc/sys/net/ipv4/ip_forward

After you do this the packets will flow! Of course, I would have known about this a lot sooner if I had used the “ipsec verify” command. This command will check your system to see if it is properly configured to run Openswan and tell what you need to do in order to get it into a ready state.

Hope this helps!

Linux 2.6.23

Usually I put on a little party hat and blow up some balloons for days like these, but I missed my alarm this morning and things got a little hectic in the ol’ apartment, or Linux Launch Pad, as I like ot call it.

Onwards and upwards to the news: Linux kernel version 2.6.23 is live and ready for your perusing pleasure.

LKLM:

Finally.

Yeah, it got delayed, not because of any huge issues, but because of various bugfixes trickling in and causing me to reset my “release clock” all the time. But it’s out there now, and hopefully better for the wait. Not a whole lot of changes since -rc9, although there’s a few updates to mips, sparc64 and blackfin in there. Ignoring those arch updates, there’s basically a number of mostly one-liners (mostly in drivers, but there’s some networking fixes and soem VFS/VM fixes there too).

Shortlog and diffstat appended (both relative to -rc9, of course - the full log from 2.6.22 is on kernel.org as usual).

I want this to be what people look at for a few days, but expect the x86 merge to go ahead after that. So far, all indications are still that it’s going to be all smooth sailing, but hey, those indicators seem to always say that, and only after the fact do people notice any problems.

My my, seems like Linus is a little peeved this morning too. I wonder if he missed his alarm? I bet it’s a penguin. No, a real one.

Linux kernel newbies has a nice summary up today about what’s new in this release (note, it’s been Dugg, so this is a Google cache link):

2.6.23 includes the new, better, fairer CFS process scheduler, a simpler read-ahead mechanism, the lguest ‘Linux-on-Linux’ paravirtualization hypervisor, XEN guest support, KVM smp guest support, variable process argument length, make SLUB the default slab allocator, SELinux protection for exploiting null dereferences using mmap, XFS and ext4 improvements, PPP over L2TP support, the ‘lumpy’ reclaim algorithm, a userspace driver framework, the O_CLOEXEC file descriptor flag, splice improvements, new fallocate() syscall, lock statistics, support for multiqueue network devices, various new drivers and many other minor features and fixes.

Linux 2.6.23-rc9 and x86 merge incoming

Linus Torvalds provides us with an update on the Linux kernel today, as well as a heads-up about incoming x86 merge news set to drop fairly soon.

LKML:

I said I was hoping that -rc8 was the last -rc, and I hate doing this, but we’ve had more changes since -rc8 than we had in -rc8. And while most of them are pretty trivial, I really couldn’t face doing a 2.6.23 release and take the risk of some really stupid brown-paper-bag thing.

So there’s a final -rc out there, and right now my plan is to make this series really short, and release 2.6.23 in a few days. So please do give it a last good testing, and holler about any issues you find!

This is also a good time to warn about the fact that we’re doing the x86 merge very soon (as in the next day or two) after 2.6.23 is out, so if you have pending patches for the next series that touch arch/i386 or x86-64, you should get in touch with Thomas Gleixner and Ingo Molnar, who are the keepers of the merge scripts, and will help you prepare..

Doing it as early as possible in the 2.6.24-rc4 series (basically I’ll do it first thing) will mean that we’ll have the maximum amount of time to sort out any issues, and the thing is, Thomas and Ingo already have a tree ready to go, so people can check their work against that, and don’t need to think that they have to do any fixups after it his *my* tree. It would be much better if everybody was just ready for it, and not taken by surprise.

Sounds like the kernel fellas have some work to do this week.

Monday morning Linux kernel news

It’s kernel update time. This is the single security bug fix edition:

We (the -stable team) are announcing the release of the 2.6.22.7 kernel. It contains a single security bugfix for the x86_64 architecture. There is potential for local privilege escalation, so all x86_64 users are certainly encouraged to upgrade.

CVE-2007-4573: x86_64: Zero extend all registers after ptrace in 32bit entry path.

I’ll also be replying to this message with a copy of the patch between 2.6.22.6 and 2.6.22.7.

I’m going to go out on a limb and guess this won’t be the last we hear from lwn.net.

Linux 2.6.23-rc5 in the wild

As is often the case, with a new month comes new, exiting ideas from the Linux kernel community. Today, I present to you with much admiration and bombastic prose, Linux 2.6.23-rc5.

Now humbled, we can examine the details of this release candidate:

I’m making ready to leave for the kernel summit (as are probably a lot of other core kernel people), and as part of that, there’s a 2.6.23-rc5 out there now.

Hopefully we’ve addressed most regressions, so please do give it a good testing.

The shortlog and diffstat are appended: the diffstat is uglified by some powerpc defconfig updates, but otherwise it all looks pretty nice and small. The shortlog is fairly informative if you care about the details of what changed, but it does end up boiling down to “fixing a number of generally pretty small issues”. Mostly in drivers and SCTP.

So have fun, give it a go, and expect a quiet week next week. — Linus

Kernel summits and uglified diffsat’s? Truly, this fine September could not get any more bright.

Linux 2.6.23-rc4 — come and get it!

RC can mean many things to many people. Some think of the olden days of RC Cola; its blue and red cans glistening in the summer sun, waiting to be enjoyed at a ball game or picnic with friends. Others think of remote control cars feverishly jockeying for position on a homemade backyard race track.

On the Enterprise Linux Log, we think of release candidates and the Linux kernel. It’s what we do. It’s what we enjoy. It’s life, Linus Torvalds style, all the time.

Ok, I lost it, and let two weeks pass between -rc releases. My bad.

As a result, -rc4 is a bit bigger than it would/should have been, but hopefully it’s all good, and we’ve fixed most regressions. There’s some arch updates (MIPS, power, sparc64, s390) and an ACPI update, but the rest of it is mainly lots of small fixes (mostly to various random drivers). With some scheduler and networking noise.

I think the shortlog is _just_ too big to be posted on the kernel mailing list, but since it can mostly be described with the one word “boring”, it’s not a huge loss. As usual, just do

git shortlog v2.6.23-rc3..v2.6.23-rc4

If you have the git trees to get the all the details on extraneous semicolons, missed or duplicate include files, kzalloc conversions, new PCI ID’s etc etc.

Linus

Truly, a great day to be alive. Anyone thirsty?