Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature: Linux
OLS Day 3: Failed experiments, Linux-Tiny, and the Linux Standard Base
Share
Print
CommentsThat'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.
Comments
on OLS Day 3: Failed experiments, Linux-Tiny, and the Linux Standard BaseNote: Comments are owned by the poster. We are not responsible for their content.
Since when is bloated code a benefit? Koffice is really lightweight when compared to OpenOffice, and it has a great KDE-integration. It starts just about instantly, where OpenOffice seems to take an eternity to start up!
And isn't OpenOffice written in C? Koffice is C++, which means that Koffice-hackers might not be that good at hacking OpenOffice, since their expertice is C++ and not C.
And besides, Koffice and OpenOffice are different. For example, OO's Writer is a MS Word clone, whereas Kword is more like Framemaker.
Developing Koffice does not in any shape or form make OpenOffice worse. And since they will be sharing fileformats, I fail to see why we should put all our eggs in one basket.
True, it isn't. That's why OpenOffice.org is trying hard to reduce bloat. Each new version is faster than the previous one. The current version (1.1.2) is quite decent, and version 2.0 promises to be faster and have much better integration into the native environment. They are rewriting the graphics layer to use the native toolkit of each platform (Gtk/Qt under GNU/Linux, Win32 under Win, Aqua under Mac). Something similar to wxWidgets. Now, writing the graphics bindings is also a lot of work. So the initial versions will just be Gtk on Linux and Win32 for Win. The rest will have to wait a little.
And isn't OpenOffice written in C?
It's C++.
And besides, Koffice and OpenOffice are different. For example, OO's Writer is a MS Word clone, whereas Kword is more like Framemaker.
AARRGGHHH!!
Please don't call OOo a clone of MS Word. I am an OpenOffice.org volunteer and I can tell you that it is *not*. We do *not* try to copy MS Word, and OOo is *not* like MS Word. For example, with our use of styles (which we do well and Word doesn't) and integrated vector graphics we can perform functions normally associated with Desktop Publishing packages.
Developing Koffice does not in any shape or form make OpenOffice worse. And since they will be sharing fileformats, I fail to see why we should put all our eggs in one basket.
It's a tough call, but I think I'll agree with you. On the one hand, developers are a limited resource and we really need help. Having a lot of different office suites is not efficient. On the other, competition and diversity re good things, to be encouraged. OOo is not right for everyone, and KOffice is not right for everyone. It's good that we have both.
I think that, in my ideal world, there would be two OSS office suites and they would share file fomats.
Just my $0.02
Cheers,
Daniel.
No, I want to work on something that's small enough to understand, compartmented enough not to annoy my neighbour coder, open enough to add something new to and that uses something standard enough that I don't have to start with the gui basics.
I'm happy hacking Krita, and no amount of calls to cease and desist will make me do so<nobr> <wbr></nobr>:-).
Boudewijn Rempt
For the sake of fairness, I should point out that this is because the OOo codebase predates any of the cross-platform toolkits that exist today.
Now that they exist, and OOo is open source, we are trying to move towards using those toolkits. On version 2.0 OOo will use Gtk on GNU/Linux and there will probably be a Qt version later on as well.
It contains a small set of components that is apparently not really extensible
OOo is actually fairly extensible. But it is also big and overwhelming. We are trying to improve this.
when was the last new app added to the suite?
What new app do you think we need? We need new functionality, and each version brings something. 1.1.0 brought PDF and Flash export, 1.1.1 brought DictOOo, 1.1.2 brought FontOOo.
This, algthough the bulk of the work has gone into improving what we currently have: MS Office compatibility, refactoring the GUI, reducing bloat (each version is faster than the previous one), etc.
The code has a history that spans many more years than KOffice, and many more developers, which adds up to complexity.
True that. OOo is bigger than the Linux Kernel.
No, I want to work on something that's small enough to understand, compartmented enough not to annoy my neighbour coder, open enough to add something new to and that uses something standard enough that I don't have to start with the gui basics.
OOo is comparmented and open. But I hear you about the "small enough" and "standard enough".
As for the smallness thing, we are creating a scripting framework which will make it much easier to add functionality without having to learn the internals.
I'm happy hacking Krita, and no amount of calls to cease and desist will make me do so<nobr> <wbr></nobr>:-).
Oh well... we certainly could have used another coder.<nobr> <wbr></nobr>:-)
Cheers,
Daniel.
That's true -- and it's also its age that makes OpenOffice so complete. It's got an enormous head-start in terms of functionality.
Now that they exist, and OOo is open source, we are trying to move towards using those toolkits. On version 2.0 OOo will use Gtk on GNU/Linux and there will probably be a Qt version later on as well.
But through a compatibility layer, isn't it?
What new app do you think we need? We need new functionality, and each version brings something. 1.1.0 brought PDF and Flash export, 1.1.1 brought DictOOo, 1.1.2 brought FontOOo.
A flow charter, a raster image editor, a report generator, for instance.
Oh well... we certainly could have used another coder.<nobr> <wbr></nobr>:-)
I'm afraid I wouldn't feel like I'm contributing anything useful for ages, if ever. Plus that the problem I'm currently interested in isn't covered by OpenOffice.
Yup.
Personally I am amazed at how complete OOo is. Much more that people realize -- because they look at it from an MS Office prism, they miss all the ways in which OOo is superior to MS.
On version 2.0 OOo will use Gtk on GNU/Linux and there will probably be a Qt version later on as well.
But through a compatibility layer, isn't it?
Yes, correct. Otherwise we would lose some things:
* Wouldn't be able to use Aqua on Mac.
* Wouldn't be able to use Qt on Linux because Qt is not free for Windows.
* Gtk is not as good on Mac and Windows.
So it kind of makes sense to use whichever the native toolkit of each platform is. But this means that you need an in-between layer.
raster image editor
A *raster* image editor? Have you tried GIMP? (joke)
Seriously though, we want to avoid duplicating work that others have done well. Instead, we try to integrate with existing apps.
So I will mentally replace your suggestion with "integrate with GIMP".<nobr> <wbr></nobr>:-) Yes, that would be a good idea.
As a side note: an old version of StarOffice *did* have a raster image editor. But they found that it was a lot of work, not very good, and added little to the package. So they dropped it.
But just because it didn't work last time doesn't mean it can't work ever. I think GIMP integration is the way to go. I love GIMP.
As for a flow-charter, I heard someone suggest that once before. It should be doable with the vector-graphics infrasctructure we already have.
Thank you for your thoughts. I appreciate the constructive criticism.
Cheers,
Daniel Carrera.
They look alike, and they do the same thing. True, there are quite a bit differences deep down, but to the average user, they are very much alike.
And my point was that Kword and OO's Writer are designed around two different paradigms. Writer is page-oriented (like MS Word is), whereas Kword is frame-oriented (like Framemaker is)
"Please don't call OOo a clone of MS Word."
Isn't that what's happening right now? Koffice is migrating to OO's fileformats as their default fileformat. In the near future, we will have two competing office-suites that are 100% compatible with each other.
BTW: does OO open Koffice-files? I honestly don't know.
>
>They look alike, and they do the same thing. True,
>there are quite a bit differences deep down, but
>to the average user, they are very much alike.
OOo and MSO don't look alike, but all word processors look similar. If OOo Writer is a clone of MS Word, then Word is a clone of WordPerfect which is a clone of Abiword which is a clone of KWord which is a clone of OOo Writer.<nobr> <wbr></nobr>:-)
OOo Writer is no closer to MS Word than MS Word is to WordPerfect.
> Koffice is migrating to OO's fileformats as
> their default fileformat. In the near future,
> we will have two competing office-suites that
> are 100% compatible with each other.
That will be fantastic. I look forward to it. I hope everyone will use the OASIS file format.
> BTW: does OO open Koffice-files? I honestly
> don't know.
It doesn't. But as you said, KOffice is moving to OOo's file format. So there are better things we can do to support KOffice than making filters for the KOffice format. Two examples I can think of:
* OOo is making a library for WordPerfect files. This is what KOffice uses to open WP.
* OOo is working with Inkscape and Sodipodi on the Open Clip Art Library (www.openclipart.org). This project is making a public domain clipart library. So all open source projects can benefit.
Cheers,
Daniel.
If OOo wants to being in new developers they need to make the project worth joining for the developers. How this is done varries a lot but they need to find what their "it" is and then they'll get people hacking code.
- scanner not recognized (yes, I've got SANE installed)
- DSL modem not recognized
- printer not recognized (yes, I've got CUPS installed).
Please, Linux zealots, spend more time on making things work instead of bashing M$.
You might also want to file bugs in the bugzilla databases of SANE and CUPS.
Remember, we can only fix the bugs we know about.<nobr> <wbr></nobr>:-)
Cheers,
Daniel.
Windows doesn't recognize many devices, it relies on the device manufacturers to provide drivers.
Those manufacturers can't always be bothered to develop Linux drivers, which means that its up to the Open Source community to spend their time writing them from scratch.
If you have taken the time to complain here, why not complain to the manufacturers of your scanner, modem and printer, ask them why they can't provide drivers for Linux, or at least make it easier for the Open Source community to write them?
One further note:
People that use the term 'Linux Zealots' flippantly are starting to be perceived as ignorant, pro-Microsoft, anti-Linux, FUD stirring types; or should I say "Microsoft Zealots". It's probably wise not to use it if you don't want to come across in this way.
http://www.osviews.com/modules.php?op=modload&nam<nobr>e<wbr></nobr> =News&file=article&sid=1779&thold=0&mode=0&order=<nobr>0<wbr></nobr>
I have used Knoppix to troubleshoot why another distribution would not recognize a particular device - and in most instances it was a configuration issue that was easily fixed; the distribution made some assumptions about the scope of things I would do with it. I have yet to find a device in my stable of machines that was not supported by linux when I started digging.
Remember, there are various distributions and they are not all created equal. As mentioned before, Windows has similar problems with various devices - that your (probably) OEM machine company took care of for you by doing the integration work with Windows. With Linux you are your own integrator - and no one distribution will work right out of the box for every piece of hardware - just as windows will not work right out of the box for every piece of hardware.
You should be complaining to Microshaft - ask them why they are locking their OEM partners into their operating system, and preventing them from integrating their hardware with Linux for you?
Lean and mean isn't just about running on a 486SX or inside some device as an embedded OS. It is also about wringing real performance out of any compatible hardware. It is about empowering the poor who cannot afford Win XP compatible desktops, Win 2003 servers, and who won't be able to afford Longhorn compatible hardware tomorrow. It is about preventing waste in a throw-away society and curbing the upgrade cycle and planned obsolescence.
I'd like to see a new dedication within the Linux community, and that is while all the great new enterprise features are cobbled on, and as new architectures are supported, that the community also rigorously support hardware built 10 years ago.
Perhaps the 386 processor has outlived its usefullness. And maybe it is time to move forward to supporting no less than the 486 and 8 MB RAM. But lets draw the line there for at least another 5 years before deciding the 586 is the oldest processor, and 16 MB RAM is the least supported.
This is a world of 6 billion souls and many are struggling to join the world economy. Amortized hardware running Linux around the globe will do much to establish Linux and Linux applications as the world standard, provided Linux remains useable on that old hardware.
Most of us, if we live and work in the industrialized world, overlook that. By falling into the trap of code bloat, Linux offers one less incentive to break the dependence on Windows as a standard.
Those who don't believe there is still a need for Linux to run on 486 -- in both desktop and server roles -- need to travel some of the less affluent corners of our planet.
lsb
Posted by: Anonymous Coward on July 24, 2004 09:55 PMnice info though!
regards - benjamin
#