Previous NewsForge OLS coverage: Day one; day two; day three.
LSB testing tools
The last day started with a session by Stuart Anderson on the Linux Standard Base's testing tools.
As discussed on the 3rd day of OLS, LSB has a set of required base design for all flavours of Linux to allow all independent software vendors to run on top of any Linux, regardless of distribution, provided it is in compliance with the LSB's standards. In order to test compliance, the LSB releases software and tools.
Anderson described the LSB as a binary implementation of the POSIX source API standards.
One of the challenges for the LSB said Anderson is that the LSB's tools need to hook into existing applications to test them while they are running without changing their behaviour and thus nullifying the test. To do this, he suggested three possibilities.
The first is a program called abc, simply "a binary checker". This system works by changing library names in the compiled program to its own libraries which are substitute libraries with the same functionality but various additional checks to make sure the code works properly. Because this system requires the modification of binaries, Anderson said it was out of the question. There was a risk that an independent software vendor would run their software through the tests and then distribute their compiled programs -- with the modifications, thus breaking it completely for all end users.
The second option he proposed was the use of ltrace. ltrace follows a program as it runs and examines what it is doing from the sidelines. Unfortunately, Anderson said, ltrace does not support all the library calls required by the LSB specifications.
The final option he suggested was fakeroot. Fakeroot, he told the audience, pretends that calls to the system have been done and returns friendly but entirely untrue information to the program calling it that yes, that system call has been done. It intercepts the calls and can be used to trace them to ensure nothing LSB non-compliant takes place without having any real effect on the system.
While Anderson went into very deep detail about the technical aspects of the verification process, the important points were clear.
The code tests administered by the LSB's self-tests do not cover any problems outside of the LSB specifications. If the test runs across a serious problem, it is not the responsibility of the test code to warn the developer running it that there is a problem, unless it violates the LSB's specifications. The tests validate data types and data for conformance with LSB specifications.
The LSB spec only allows a small handful of ioctl()s. These are ways for programs to talk directly to hardware, however they can change from one kernel version or hardware platform to the next and are not advised except in a small number of cases. LSB forbids the use of ioctl()s which are specific to any piece of hardware.
Sometimes applications being tested, however, do not directly call these ioctls, said Anderson, but functions that they call call ioctl()s in turn. This makes compliance more difficult for some software vendors.
The LSB test software is about 80,000 lines of code across 2000 files on the first layer. The second layer, which is the meat of the actual tests, is about 100 files and 15,000 lines of code.
The LSB test package still has a lot of work to do, Anderson said. The performance hit of the tests on the software being tested needs to be quantified, for one, though the list of technical details that need work is longer.
Multiple architectures are now supported, said Anderson, by the LSB. This TODO list item has been completed allowing the Linux Standard Base to apply to more than just x86 systems.
He concluded by inviting all to join the LSB real time discussion channel at irc.freestandards.org in channel #lsb.
Conary: An alternative packaging system
Eric Troan of Specifix ran the last formal session of this year's Ottawa Linux Symposium in room C on an alternative packaging system developed by his company.
Conary is designed as a distribution-wide or even multiple distribution package management system. As Troan explained it, it essentially takes the best of rpm, CVS, and gentoo and combines them with some more features into a comprehensive revision control system and package manager.
Troan explained that the Conary package management system had been released just one week previous to his session. Its fundamental purpose is to allow entire distributions of Linux to become fully customisable so that a distribution of Linux can be created for internal use within a company, or for a niche market, with a minimal hassle.
The decision to release all the code they have spent the last several months working on, he said, was a difficult one. Their business model is not the selling of the distribution system as a package or the service of hosting a package repository for customers, but Specifix plans to build its own distribution which will be specifically designed to be highly customisable and sit inside the framework they built first. This distribution and distribution management system will then be sold to companies, particularly embedded companies, seeking a way to manage their own distributions.
Fighting GPL violations
After lunch, Linux firewall package netfilter contributor Herald Welte described his efforts at fighting corporate violations of the GNU General Public License in his native Germany.
His discussion was a BOF session, interactive by nature. He said he is has been making a living as a free software developer since 1997 and is a code author, not a lawyer.
But Welte is not satisfied with the way the Free Software Foundation has been handling GPL violations and has taken it upon himself to do it the way he sees as properly.
Welte said that the FSF's approach to GPL violations is to approach companies that have been found violating the GPL and quietly negotiate with them to stop violating the GPL on their current product to little public fanfare or scrutiny. He said the FSF's approach has caused many such cases to go completely unnoticed.
With the system the FSF is using, said Welte, companies have no incentive to stop violating the GPL. If a company violates the GPL and negotiates with the FSF to stop, by the time they agree to stop the product is done and they're gone on to the next one -- which could also violate the GPL. Then they can go through the whole process again without really losing much.
Welte said that in Germany he can only act on cases that affect his code directly. Should he find iptables/netfilter Linux firewall code in a proprietary device such as a router, his first course of action, he said, is to reverse engineer the device, an inherent right still present in Europe pointed out an audience member, to confirm the violation.
The second step is to provide notice to the company that they are in violation of the GPL and inform them that injunctive action will be taken if they do not attempt to remedy the situation.
The third step is, said Welte, to wait and see if the company responds.
The final step is, if the company has still not responded, to go to court and seek a preliminary injunction against the product that is violating the GPL, preventing it from being shipped in Germany effective immediately until the problem is resolved, and subjecting the company to fines should they continue to ship the product.
He cited an example of a recent company called Sitecom which ignored all his communications until receiving a notice from the court bailiff that there was now an injunction against distributing any of their products. Only then did the company even hire a lawyer to solve the problem. The company responded by releasing the modified source code to the device they were selling but insisted on appealing the injunction anyway.
The long and the short of his presentation was that it is necessary for preemptive measures to be taken by GPL coders, such as not correcting typos in code, to make it easier to find code violations.
If you do find a GPL violation, says Welte, don't go to the media with it, go to a lawyer with it. In order to get a preliminary injunction, there needs to be evidence of urgency, and in order for that to happen, the court needs to feel like they were the first people to be contacted after the offender themselves.
Andrew Morton's keynote address
The last day of the conference saw the traditional keynote address.
This year, last year's keynote speaker Rusty Russell introduced the keynote speaker for this year, Linux' very own Andrew Morton, the current maintainer of the stable release of the kernel.
Morton's speech addressed the reasons for inherent monopolisation in the system software markets.
Independent software vendors and hardware manufacturers are both interested in having one stable platform for which to release software or hardware and drivers, he said. As a result, both software and hardware manufacturers look to one or a small number of players as being relevant in the operating system market.
In order for a new player to get into the market, as Linux has done, the new player has to develop all the hardware drivers that would normally be vendor supplied for themselves, and new software has to be written across the board.
As a result, new operating systems and operating systems companies seldom show up or survive once they do.
Morton went on to state that he does not believe that the Linux kernel is likely to fork simply because of the volume of work that would be necessary for a forked kernel project to maintain their code base.
The Linux kernel decision making process, he said, is a consensus based process. It would take a serious rift to get to the point where Linux could actually have a serious fork.
Morton made a point of thanking Richard Stallman for his work and for being consistent throughout the years in his viewpoint and actions. We owe him a lot, he said.
Morton indicated that companies have been offering up developers to the free software community, and those developers are often becoming hooked on the whole free software notion. These developers, he pointed out, will eventually become managers and will have a better understanding of the free software world.
"World domination is proceeding according to plan," he concluded.
Asked questions after his speech, Morton suggested he did not believe that Linux would ever necessarily change to a 3.0 kernel version. As the project moves forward, the need for major changes decreases, and thus the need to change the major version number from 2 to 3 drops.
Following Andrew Morton's keynote address, CE embedded Linux group gave away 3 door prizes, 2 of which were Sharp Zauruses.
To wrap up the formal part of the conference, the audience gave a warm thank you to the conference's organiser, Andrew Hutton of Steam Balloon, who has, with a number of volunteers for the last six years put on the Ottawa Linux Symposium and it has become a central part of the development and discussion process for Linux developers the world over. In recognition, Andrew Hutton received a standing ovation at the end of OLS, the only one during the conference.