That’s too much data
Ronciak told the audience that gigabit and ten gigabit networks have some issues with the kernel’s throughput handling of the network traffic. Means need to be developed to increase the efficiency.
Brandeburg told us that their attempted solution to the problem was a method called page-flipping. A page is a fixed amount of memory and page flipping means that network traffic coming in would fill one page before being ‘flipped’ over to the application expecting it. The idea is that the buffering into pages should improve the efficiency as the kernel is only doing one thing at a time.
FreeBSD, Brandeburg said, already implements such a system in their kernels, however Brandeburg’s implementation failed to be any more efficient than the existing Linux networking code, and actually came out to be less efficient in all test scenarios.
Tiny is better
Later in the morning, Matt Mackall talked about the Linux-Tiny project.
Linux-Tiny is a project to reduce the size of the Linux kernel and its footprint — or size — in memory, for use on older legacy hardware, or embedded systems.
Mackall explained that the Linux kernel has become bloated over the last ten years and has a lot of room to shrink. He explained very rationally how this came to pass.
Linux kernel hackers got jobs.
In 1994 the kernel was at version 0.99 and could happily run on a 486 SX running at 16MHz with 4 MB of RAM.
By this year, 2004, the kernel had arrived at version 2.6 and could happily run on a 1024 node Intel 64 bit (ia64) architecture cluster with multiple terabytes of RAM.
When Linus got his job at Transmeta, he was suddenly entrusted with a computer running with 512M of RAM and various other improved features over the older hardware he had been developing Linux on. Memory use and disk use become less of a priority, and functionality and features took the forefront.
Over the period of 1994 to 2004 there was a huge growth in personal computing and Internet use, and a constant massive reduction in hardware costs. Coupled with Moore’s law of ever accelerating hardware, this led to the loss of the concept of running Linux on small, old systems.
Linux has grown, Mackall went on, one small change at a time. Eventually lots of small changes adds up to large changes, significant improvements in various performances, and increased size.
Mackall’s project, Linux-Tiny, aims to reverse this trend. He noted that it was nice to be scaling in the opposite direction for a change.
The means Linux-Tiny uses to get to its small memory footprint and kernel image size ends is a radical trimming down of the kernel’s… less necessary features.
Mackall described the various steps he took to reduce the kernel’s size by removing extraneous code, wasted memory, and unneeded text output. His stated goal was to run a small Linux system whose sole purpose in life was to run a web server with no bloat.
He has so far reduced the kernel to a 363 KB image, significantly below the 1.9 MB image found in a default compile of kernel 2.6.5, and comparable to the 1994 kernel 0.99pl15 image size in Slackware 1.1.2 of just 301 KB. His memory consumption is down to less than 2 MB, and together this means that Linux-Tiny can run on embedded systems and legacy hardware efficiently, as it did before Linux kernel hackers got jobs.
OpenOffice is open for developers
Michael Meeks of Ximian, now owned by Novell, gave a presentation called the “Wonderful World of OpenOffice.org”.
OpenOffice.org, he said, is sexy, but it still has a lot of work to be done.
OpenOffice.org, he said, needs more developers. Stop working on GNOME and KDE Office, he implored, they served their purposes, there is now a viable open source office suite — and it’s OpenOffice.org. Sun, he said, has done it right by releasing StarOffice as OpenOffice.org under a proper open source license and supporting and developing it within that framework.
He gave a comparison of sizes of various packages in terms of the total file size of the tar.bz2 archive files. KOffice, he pointed out, has less code than the Linux kernel, which in turn has a fraction the code of all of KDE, which in turn has less code than OpenOffice.org.
He explained that Sun has released OpenOffice.org under a pair of licenses. One is the lesser GPL, or LGPL, and the other is the SISSL which allows software to be modified and the source not redistributed, provided the API and file formats are not affected.
If SISSL-licensed code has been modified and binaries released that change either the API or file format conformity with the original code base, the source code must be released.
Sun’s biggest problem with OpenOffice.org, said Meeks, is that it is stuck on a retail-oriented boxed set mentality. Every 18 months a new version must be on store shelves, which means 9 months of a release cycle is creating new features, and the other 9 months of that release cycle is debugging.
Thus a new feature implemented immediately after this spring’s OpenOffice.org feature freeze will not be in the package found on store shelves of OpenOffice.org until the end of the next release cycle some 27 months later — or as late as late 2006. Two years between the introduction and implementation of a feature is too long to keep developers’ interest or be usable as a new feature, he pointed out. This is not the way to do it.
He also believes that Sun lacks any real understanding of how to create a community. A community, he said, cannot be manufactured, as much as Sun tries. High mailing list volume does not make for an active community. Most of the developers of OpenOffice.org are full-time Sun employees assigned to the task. While there are a few outside of Sun, the numbers are low, and Meeks actively encouraged members of the community to join the effort.
He said that he would be willing to hold the hand of any developer who wishes to step into the OpenOffice.org developing fray. There is a lot of work to do on OpenOffice.org and there is a hunger for new developers to help with the work.
Anyone who wants to join, he said, should see ooo.ximian.com/lxr/ where information and examples on developing OpenOffice.org can be found. He demonstrated a simple single-line code change that shifted the layout of some buttons within the OpenOffice.org interface and suggested that being able to see real effects of changes would perhaps be a better motivator to wanting to develop.
Every 3 months, OOo lets out a minor release, he said. Unfortunately, minor releases require small sizes and thus a bug in a low level part of the program that requires across the board changes must wait for the full 18 month release cycle to take effect. That, combined with inconsistencies between distros adds to the complications of regular releases of the OpenOffice.org office suite.
He believes that OpenOffice.org is the only viable office suite and that more programmers need to help out, a point he drove home repeatedly.
He outlined some of the changes that still need to be made.
Lots of polish is still required to improve the suite. There are a lot of small, but big-hitting changes left that need doing, and many of the performance problems are not hopeless – they just need someone working on them.
The LSB and me
In the evening, Mats Wichmann, chair of LSB, and Dirk Mohndel, Intel director of Linux and Open Source strategy, hosted a Birds of a Feather (BOF) session discussing the Linux Standard Base project and its impact on Linux and independent software.
Dirk pointed out at the outset that if the LSB were to dictate a system for upgrading packages within the Linux Standard Base, all the distributions would balk at the loss at the one form of lock-in they have, and while he doesn’t blame them – it is their business model – it is such things that provide constraints to what the Linux Standard Base can do. Besides, he said, distribution lock-in is mostly a psychological problem, not a technical one.
The Linux Standard Base is a common set of requirements for all Linux distributions that can be used instead of requiring particular distributions at particular levels to run software.
Currently in development is LSB version 2.0 which will be a certification-based system. Software that is LSB 2.0 certified will be certified to run on any Linux distribution that is fully compliant with LSB 2.0’s base requirements.
The requirements specify in detail what software is available at the lowest level of the distribution and what package formats must be supported — namely RPM.
By using the Linux Standard Base, it will no longer matter what distribution end users are running to govern what software they can run on top of them. As long as the software is complaint with the Linux Standard Base, the software will run.
The LSB does not cover Embedded Linux, the standards for that are set by the Embedded Linux Consortium. LSB attempts only to address the needs of desktop and server Linux.
LSB version 1.3 has been out for some time and its shortcomings have prevented it from going through the process of having a certification system set up. Using the drawbacks and lessons learned in the 1.3 version, the largely hardware company-funded LSB project is working toward version 2.0 which is currently at the state of release candidates, and should be released relatively soon.
The LSB project is not expecting perfection, they said, with version 2.0, but it is a base from which to work to make a perfect version 2.1 with anything they forgot. Evidentially, they do not yet know what will change in 2.1 as they have not yet remembered forgetting it.
The LSB does not plan on releasing a written specification alone, but is to be released with a set of testing tools and test suites to ensure compliance and to confirm the realistic requirements of the written documents.
Distributions of Linux have varying degrees of acceptance of the LSB project. While the presenters refused to answer direct questions about whether or not any distributions were hampering the development, they suggested that some distributions who believed they were already in a monopolistic position within Linux could possibly be less interested in support a project that levelled the Linux distribution playing field.
The LSB is expected to release version 2.0 within weeks.
Category:
- Linux
