Testing begins - 32-bit or 64-bit?

Rickard Osser starts to test the code on FC12

In preparation for CentOS 6.0 Rickard Osser starts to test the existing 5106R code under Fedora Core 12. In general our code compiles, but runs into the usual PHP-5.3 related oddities, which we expected.

Rickard also plays with the code to get it to compile under 64-bit, which required some changes. But now that this is done, this also opens new possibilities.

To go 64-bit or not? That is the question!

While we are working on BlueOnyx for CentOS 6.0 we also now have to ask us the above question, which will have many implications.

Sure, we can build a 64-bit version of BlueOnyx for CentOS-6.0. But there is still plenty of hardware around that doesn't support 64-bit OS's. When setting up my own devel box for this I was also astonished to realize that the box that I had set aside for that very purpose wasn't capable of running a 64-bit OS.

So if we go for a "64-bit only" release of BlueOnyx on CentOS-6.0, then quite a few people will suddenly face the realization as well that their hardware may not be able to run it.

If we remain 32-bit only, then this will mean that some people that are interested in 64-bit will continue to ignore us.

So this means that we may have to provide both a 32-bit version and a 64-bit version of BlueOnyx on CentOS-6.0.

The implications of a dual release:

- We'll have to build (and support!) two different ISO images for the initial installation.

- We will have to run a 32-bit and a 64-bit development server where we build all RPMs.

- We will have to run test boxes for both the 32-bit and 64-bit version of BlueOnyx on which we test all updates prior to a release.

- We will have to maintain three different YUM repositories:

1. BlueOnyx 5106R on CentOS-5 (32-bit only)
2. BlueOnyx 5107R on CentOS-6 (32-bit)
3. BlueOnyx 5108R on CentOS-6 (64-bit)

- Third party packages for BlueOnyx on CentOS-6 will have to be provided for both the 32-bit and 64-bit versions! Packages designed for the 32-bit version cannot be installed on the 64-bit version of BlueOnyx and vice versa.

Bottom line:

We need more hardware (who's gonna pay for that?) and we'll need much more time and effort at maintenance whenever we release updates. In essence it doubles the work load.

What do we gain from 64-bit?

Quite frankly: We discussed this controverly on the developer mailing list and we're kinda torn on this issue. My personal view is that - as far as BlueOnyx is concerned - 64-bit is only good for public relations.

Why I think so?

Lets backpedal on this for a second and look at what we're actually using BlueOnyx for: General hosting platform.

Which programs or services are we currently using that would benefit from 64-bit support?

1.) Kernel. Right now the 32-bit kernel uses some "hacks" in order to be able to use all the available RAM. The 64-bit kernel doesn't need to do that. The performance gain from a 64-bit memory management may be somewhere between 1-5% on most hardware.

2.) MySQL. That's probably the only daemon which really benefits from going 64-bit.

Anything else? Sendmail? FTP? Apache? Not by a very long shot.

So what benefits we'd have for going 64-bit? None at all, aside from a "marketing" point of view.

Summarily said: If looked at a BlueOnyx stand alone installation the differences between a pure 32-bit install and a 64-bit install are entirely neligible.

However: If you plan to run BlueOnyx inside a VPS, then it can be much more appealing to run it on a 64-bit node and then it would make sense if the VPS itself also runs a 64-bit guest OS.

So what will it be?

As much as I hate to say it: We will have a dual release of both a 32-bit and 64-bit version of BlueOnyx on CentOS-6.0.

For this to happen we will also have to hand the hat around and have to beg and to appeal to our users for donations, because we will need a well connected 64-bit capable server to run our development and test boxes for the 64-bit versions.