aporem.net

ISVs have a problem supporting GNU/Linux: the multitude of Linux distributions and their packaging systems. While the LSB helps opening Linux distributions to ISVs by defining the library paths and a single file system hierarchy, there is no such thing for the packaging system.

This makes installation of “alien” software a hard task. Both for the customer and the ISV. The first breaks his packaging system since now there are files in his file hierarchy that are not maintained by this database and hence could cause trouble. Additionally, the information about dependencies is not integrated into this system. The ISV on the other hand has to cope with a bunch of packaging systems he has to support or risking that he misses out some business opportunities.

But help is here, on the Packaging Summit there has been a push for a LSB package API that should avoid all these hassle without forcing the distributors to abandon their current systems. It should spawn the basic information (files installed, dependencies) into the packaging system even if an ISV uses his own installation routines.

This sounds too good to be true? Perhaps, but it’s a start into the right direction: freeing the users from the firm grasp of their distributors.

The original article can be found here.

The laptop database for FreeBSD is back since January 18 and can be found here.

The old database maintained by Lukas Ertl has been offline since the server hosting it was shut down with January 1st.

The FreeBSD status report for the fourth quarter of 2006 has been mailed on January 16.

Fortunately, there has been so much activity that a roundup would take almost as long to read as the original, so I’m not going to waste your time. Nevertheless I want to mention some highlights:

• ZFS is now functional, ACLs are the next item on the ToDO list.
• The Linux Compatibility Environment is being upgraded to Linux kernel version 2.6 while several improvements have been made for kernel version 2.4
• X.org 7.2 is coming to FreeBSD! The team estimates the merge into the ports tree with end of January.
• It is planned to make TrustedBSD Audit a production feature for the FreeBSD 6.3-RELEASE

Almost two weeks ago, Chad Fowler has finished his article series “Big Rewrite”. He lies down the pitfalls of rewrite projects in a very amusing way.

The first post is an overview how and why management and/or programmers are lured into rewriting an existing application. The usual factors include maintenance costs, stability and the inability to implement new features without breaking existing ones.

The next logical step is to take either the software or the code as a spec. This has already been laid out as a way to disaster in “The mythical man month” by Frederick P. Brooks. First, making the newly written software “act like the old one” includes reproducing all the bugs and design errors the old project had. Why then rewrite? Second, the effort to extract the specification from the running program or the source code is always underestimated: the poor state the project is in has been the reason to rewrite it…

Paired with the preceding problem comes the underestimation by staffing the project as an implementation without any innovation involved. This is obviously not what reality looks like, since both recreating the existing functionality and improving the design of the project are highly innovative tasks.

The fourth article sports one key point in a rewrite project. Keep the feature creep out at all costs! — I guess the reasons behind this are clear.

The Big Bang approach is to change from the current productive system to the rewritten one in one single step, the Big Bang. Clearly, this has inherently several pitfalls. The current system is a moving target, since it has to be maintained during the rewrite as well. It therefore can not serve its purpose as a specification. Then, the new system is probably cleaner by design but not all parts will match up in speed and robustness with the old ones. The results are often fatal. (In my opinion, if there is a chance to upgrade in a Big Bang, the product was not complex and hence the rewrite not necessary.)

The post Justifications and Lies comes somewhat late in this series. It’s about what happens, if a justification for rewriting a product gets nailed down and find its ways into the specs. Not that there should be no justification but most of the time the effects can’t be measured in a decent way and hence the decision should be a strategic one, e.g. taking the abilities of new employees into account.

Finally, the personnel is taken into account: since the more experienced users/programmers have to tend the store, i.e. maintaining the current program, the inexperienced respectively those who are unfamiliar are charged with the rewrite. They stand no chance to wiping out existing bugs they don’t know about and are likely to repeat the design errors (the first program wasn’t written by monkeys either).

All in all, most of the time a big rewrite isn’t something worth the hassle…

Yesterday, the final release of FreeBSD has been announced.

After considerable time slips due to severe issues that came up after the release process was started (and which have been addressed very professionally from my point of view) the Release Candidates came on time as did the final release.

I’m very impressed by the list of new features even hough there are not that many items on the list. I consider the integration of csup as one of the most useful features and the implementation of the OpenBSM audit subsystem one of the most valuable ones.

As usual, the Release Notes and the Errata are available and should be read before installation.

The scheduler is one of the most important parts of an operating system. It is responsible for managing the run-queue of all active processes and hence is made responsible every time the machine “feels sluggish” under load.

While being such an integral design part, little to no changes have been made to the original 4BSD scheduler used by FreeBSD. This, for one, lies in the effects any change could bring: from unusual behavior to severe performance regressions. Second, the task in rewriting a scheduler (more precisely inventing or implementing a new scheduling algorithm) is technically challenging. Obviously, the piece of code has great powers and must not give up under any circumstances. On the other hand, it has to be very efficient in order to not waste cpu-cycles, since it’s called upon every context switch.

This tremendous task has been attacked in FreeBSD to create a new scheduler, dubbed ULE. But this scheduler newer met its design goals (never both stability and efficiency) and hence never replaced the 4BSD code.
Development would have been more fruitfull if it wasn’t for the advent of SMP machines, where ULE has been historically weak.
After a quarrel about the principle usefulness of ULE under certain circumstances some months ago, nothing new was heard from the scheduler.

But on january 4, Jeff Roberson announced that he had addressed some long standing concerns about ULE and has committed ULE 2.0 into CURRENT.
With this my hopes are again high that a viable alternative to the current scheduler will be available some day in the future.

On december 27, Release Candidate 2 for the 6.2 Release has been announced by Ken Smith.

Since this ought to be the last RC before final release, all open issues have been taken care of, especially the heinous device driver bugs.
Additionally, due to a security issue, a new version of BIND had to be integrated into the operating system.

If testing doesn’t reveal any issues, the final release is predicted to be somewhere round january 10, which would be tomorrow.