February 28, 2012, 8:00 AM —
If there was any concern that the "new" SUSE would somehow not be innovative within its enterprise-oriented product lines, that concern may be alleviated with today's general availability release of SUSE Linux Enterprise 11 Service Pack 2 (SP2).
The SP2 version of SLES 11 not only marks the first release of the SLES line since Attachmate's acquisition of Novell and its SUSE division, it also denotes an important shift from traditional Linux enterprise deployment models to what company reps call the “forward-looking platform model.”
This buzzword-y sounding phrase smacks a bit of marketing flim-flammery, but there’s actually some interesting technology going on here.
Consider the usual model for enterprise Linux distribution development: dev teams pick a set of technologies that are considered to be highly stable and essentially plant their stakes right on those applications, libraries, and the Linux kernel. From that point, any innovative software that was developed to connect to a later version of that staked software would be backported to those older, stable versions.
A common example of this is the Linux kernel itself. Many’s the time that an enterprise Linux distro like Red Hat Enterprise Linux (RHEL) or SLES would have to stick with an older version of the kernel and backported any newer technology to work with that kernel drivers, for instance, were a big reason why this backporting was done, because the distro would have to have a stable kernel, yet still work with the newest software possible.
But SLES 11 SP2 is taking a different approach to this usual way of doing things.
SP2 is instead planting its stake much farther ahead than it would otherwise, capitalizing on several advantages that exist in the Linux ecosystem for using more advanced technologies such as the Linux kernel.
“Customers wanted more advanced features,” explained Kerry Kim, Director of Solutions Marketing. And this forward-looking model enabled SUSE engineers to deliver those features without delivering more risk to the end user.
Kim emphasized that one of the big drivers how this was possible were the various improvements that were implemented in Linux kernel development since the start of Linux 2.6 development. Because of those improvements, SUSE felt much more comfortable pulling ahead with its kernel version for SP2--which is why the release is going with the 3.0 kernel.
If this seems to introduce more risk, Kim explained that in a sense, backporting actually brings more risk to customers. In order to get backporting to work, Kim said, many patches would have to be added to the stock Linux kernel being offered.
“Backporting was very intrusive,” Kim said in an interview last week, “it introduced more risk at times than the forward-looking model does.”
Kim was very careful to emphasize that SUSE wasn't just throwing new things into the release just for the sake of being new. So was his colleague, Dr. Gerald Pfeifer, senior director of product management.
Pfeifer explained there were decision points that had to be met with the introduction of any newer technology in this release. First, forward-porting had to be worth it: SUSE didn’t want to just toss in a small security fix to get a higher version number.
Second, Pfeifer explained, the code had to be safe.
“Everything that worked on SP1 had to work on SP2,” Pfeifer said.
Finally, the holistic costs of engineering, quality control, and maintenance were weighed to determine whether newer software could be forward-ported rather than back-.
Because of these criteria, Pfeifer told me, not everything in SP2 was newer by default. Because of the risks involved with compilers for applications, SUSE decided to go with an older set of compilers as the default option--though the newer compilers are available as well.
So how much of an advantage does this forward-porting get SLES SP2? Under the older development model, Pfeifer said, SP2 would have likely been released with Linux 2.6.32, rather than Linux 3.0. Also, while the larger “big-ticket items” would have been backported, he added, there are numerous smaller pieces of code that would not have been backported.
“These are the icing on the cake,” Pfeifer said. And even without the icing, the costs of backporting on that original stock 2.6.32 kernel would have been significant: the kernel would have been 2.6.32, with over 10,000 patches, Pfeifer said.
It will be interesting to see how fast this model of development is adopted by the other Linux vendors working in the enterprise space. Given the higher pressures to differentiate these days, expect more forward-porting in future releases.