aporem.net

From the status report June-October 2006:

• XEN
  Through a Summer of Code project (f(o)unded by Google) Xen has been ported to FreeBSD. This means that the domU support is finished.

  Unfortunately, there was not enough time for a dom0 support which is much more anticipated by myself.

  By the way, Xen announced its update to 3.0.3.

• ZFS
  Outside of Solaris, I dare to say that FreeBSD has the most mature support for ZFS, the zeta file system from SUN.

  Nevertheless there is very much left to do. ZVOL is done (sort of) and ZPL is being worked on. For those like me, who don’t know the innards, there is a source tour available on the Solaris homepage.

• Linux compatibility
  As every FreeBSD fan knows, there is a syscall compatibility to the Linux kernel. Default compatibility is with version 2.4.2.
  In another Summer of Code project, compatibility with version 2.6.16 has been achieved.

The full report can be found here.

For all those who think that expensive equals jewellery laden, with unnecessary optical eye candy:

Fujitsu has announced a special version of its excellent happy hacking keyboard (HHK) series to mark it’s 10 year anniversary. It will set you back extraordinary 3300 Euro! (That is 55 Euro per key!!)
If you don’t want lacquered keys, the anniversary edition will cost mere 1600 Euro. (Apart from being less expensive, I like the anthrazit more.)

The happy hacking keyboards come without number field or cursor block, not even function keys. This guarantees a minimum of distraction.
Additionally, all HHK are available with blank keys for even less confusion.

Pictures and the original post are available from Akihabaranews.

California based iXsystems has announced on October 10 that it has aquired PC-BSD, the producer of the FreeBSD based OS with the same name.

The main selling points of PC-BSD are the graphical installer and a point-and-click packet manager (called PBI), apart of the rock-solid FreeBSD foundations. And all this comes for free!

So why did an enterprise-class hardware provider buy a graphically inclined BSD?
For one, iXsystems also has high-end workstations in its portfolio and probably want to run a (ABI-)stable but up to date OS on them.
On the other hand, there is a will to push the development of PC-BSD towards a more sophisticated Server and Laptop support in the announcement. Although I wonder how Servers and Laptops fall into the same category for hardware support.

I’m very curious to see how the journey for PC-BSD continues. Hopefully, the focus on not BSD-savvy users (administrators?) doesn’t get lost.

The original announcement from iXsystems.

Since October 6, there is a code search engine available from Google. So it’s already up a while but there is nevertheless something remarkable about that.

First of all, it works good. It’s easy to focus the search by defining the implementation language, the license model or package names. But that’s not remarkable by itself. The key point is, that without any rumours up front, the code search engine has gone right into production.
Ok, it’s not far from the main product and the index probably integrates well in the “crawl through the web, find everyting and rate it” cylce.
And the idea is not new. O’Reilly has put up a code search one month ago.

But still Google jumping in and creating a service indicates a growing demand (or at least a growing perception of a demand) in specialized search engines.

The original article can be found at vunet.com.

This is the last post in the series developing against third party software.

You have successfully shipped around the obstacles of using third party software in your project and are ready to ship your product. Congratulations!

But wait, you have to tell your users what to expect. More precisely, what you expect from them!
System requirements are an important part in your rollout procedure to test. More important than testing is, however the design time decision how much you would like to integrate the third party software into your project.
More integrated, the third party product becomes your own and you have to serve first level support for your clients if any problems arise. The benefit, on the other hand, is because of this thight integration, you have more control over the environment in which your product operates.
With just loose integration (or none at all, just depending on the existence of the third party software at run-time) you don’t have to worry about much since this has shifted the responsibility for mainenance to the user. This comes at a price: you have to support every version of the third party software. And no, you can’t limit yourself to special versions, your clients won’t read the system requirements or come crying and demanding you to support their versions in use.
While deciding which level of integration to choose, you have to consider that license agreements could prohibit you from distributing the third party software as part of your product.

But things may not as bad as they seem, maybe the design decision has already been made by the author of the third party software.
For example, source libraries have to be compiled in while some software tools for the operation system should stay with the vendor and just be invoked like any system call.

Finnally, you have to be extra carefull to document the system requirements and communicate them to your user base. Without this, you’re in for trouble!

This post is the third in the series developing against third party software.

So, here you are, you have chosen a third party software product to use in your own project. The software meets your needs and the license doesn’t hurt you.
You’ve already startet coding (probably written already a bunch of code) when you realize that the third party software contains a bug, rendering your program unusable!

The problem is not, that there is a bug in the third party software. There is no bug-free software. The problem is, what to do and how to handle the situation.

First, make sure this is really a bug and not a missing feature of the software you use. And that the product you have is used according to its desing. It is more than probable that the original author of the third party software has never envisioned such a use case and therefore never has tested against “those anomalities” that are lurking in the dark corners of every big piece of code.

Then you have to decide if it’s possible to code around that bug in a way that if it’s going to be fixed one day, won’t break your work around.
This is the hardest part, since you have to hunt down the real breakage, find an implementation for a fix without messing with the original code and then make sure that a future change won’t blow your code to pieces.

Alternatively, you can submit the bug report to the original author and hope for a fix. But be aware that it could possibly happen that the day of the bugfix won’t come. This can have a million reasons, starting from the discontinuation of the product to a change in course of the developement to the fear that fixing this bug would break existing code of other customers.
On the other hand there may be hope, since using an open source third party product you always have the opportunity to fix the bug for yourself. But beware, extensive patching or adding of new features takes time & ressources and not every suggestion is welcomed like you envisioned it.

Thus it is clearly seen that coding around bugs in third party software takes much more skills than just finding the bug and fixing it.
You have to weight the time it takes to adapt your code, eventually comming back later when the bug gets fixed, and the time it takes to get it fixed in the first place by the original author.

And there is also the option to switch to another third party software if available. But there may be dragons, too!

This post is the second in the series developing against third party software.

First, assume that your software developement project is at a point where you have to decide to use third party software for the first time. (Since each foreign license imposes some restrictions on your project, adding extra third party software has to be dealt with separately.)
If you’re lucky, you can choose between several products that solve your programming problem. Aside the evaluation, which product suites your needs best, you should also take their license into account. And, believe it or not, there is no such thing as a license free software! (I won’t comment on the “ethical” pros and cons of any licensing scheme and just point out which implications the licenses have on your project.)
The license scheme that imposes the least restrictions to the programmer probably is everything BSD-derived. You can do anything with the software as long as you honor (=mention) the originator in your on work.
At the other end is the GPL scheme, which has a, for commercial developers, feared “viral” quality. This means, that each modified version of such a product has to be licensed under GPL again. But there is also a less strict version called LGPL which is used for most GPL libraries, in order to allow developers to link again GPL software without imposing any licensing restrictions.
The scope of commercial licenses is usually negotiable with the only limitation on what you can afford to pay. The non-negotiable core is usually the re-licensing without royalties to the original author and the disclosure of the inner workings of the software.

Now to the hard question (to everyone without a degree from a law school): which licenses can be mangled and how?
The answer is: it depends. And ask your lawyer!

But to give you some ideas, here are some obvious cases.
Using products under BSD licenses or anything less restrictive usually doesn’t change anything.
You have to be very careful, giving away source code of your own work if you have commercial licensed software in your project. The best way is to seal your code off from the third party code. This also has the benefit of being independent of this source. Later you can switch (or even better: you can allow your customers to switch) to another vendor.
You don’t have to think much about using software under GPL if it won’t leave your production environment.

So, enough dry theory, back to fun, back to coding!

Since writing blogs is not in the job description of my day job, I have to adjust the updating schedule.
Instead of posting every monday, wednesday and friday, I will just post on tuesdays and fridays.

Even though this has no direct impact to my site (at least I hope so), since I do no direct coverage, I felt that I’m obliged to mention changes to the point 6 of the bloging principles.

Yesterday the security officer of FreeBSD reminded of the impeding end of lifecycle of several FreeBSD releases. You can read the full text here.

In the next few months, first the 5.4 and 5.5 branches go out of support then 6.0 (depending on the release of 6.2) and in january next year the whole 4 branch reaches it’s end of life.

So, why is this so important? The reminder goes out to all administrators that have production boxes and hence require planning for any downtime. Additionally, the test teams (usually the same administrators) have to work out upgrading plans and test for all eventualities.
And developers supporting applications that require specific versions of the operating system have to adapt their support lists too. For example if a company decides to support their application on every FreeBSD branch with extended lifecycle support can stop supporting the 5.3 branch and eventually inform their customers about available upgrade procedures.

And why do I mention this? Because features like this make the difference between a geek OS and a enterprise grade OS. Usually one has to pay to get this kind of support from a Linux distributor or the Redmond based software company.