Why Are You NOT Using FreeBSD ?

[Daniel Kalchev]

On 02.06.12 12:27, O. Hartmann wrote:
>
> 1a) On "scietific production systems", FreeBSD has been banned due to
> the lack of HPC compilers and appropriate mathematical libraries. The
> lack of professional/academic support, like that from NAG in the late
> 1990s, has been droped for FreeBSD as well as the presence of C/C++/F95
> compilers.

Could you please elaborate on this a bit. "Scientific" software, as such 
rarely depends on any hardware and should be practically OS agnostic. 
What are these libraries, that "scientific production systems" use that 
cannot be used on FreeBSD? Same about support. If someone supports an 
"scientific" library on an OS, chances are they can support it on 
FreeBSD just as well, except if they are religious fanatics, that is.

FreeBSD has always had more or less recent compilers available. Perhaps, 
not in the base system. As you say, this issue is strictly political (to 
not have "cuitting edge" [double the quote, for more pun] compilers). 
The policy with FreeBSD is stability over all else and that the base 
must be able to compile itself -- this is what any UNIX system is 
supposed to handle, but that's another long story. The recent 
developments with clang/llvm are very promising as well.

I can hardly imagine it being that difficult to maintain an "advanced" 
compiler around just to compile your highly specific code. Further, 
recent gcc is in ports anyway.

> 1b) The lack of GPGPU. This has become so important to HPC these days.
> We use nVidia GPU based TESLA boards with OpenCL software (CUDA is
> luckily not necessary). The lack of professional drivers for 64Bit on
> FreeBSD was long time an issue, nVidia now provides drivers, but they
> don't provide their CUDA/OpenCL libraries along with their nvcc compiler
> natively for 64Bit FreeBSD/amd64. The Linuxulator isn't any option.

This one is regrettable. Outside of the "scientific" usage, it could let 
desktop users offload a lot of processing to their (in most cases more 
powerful than the CPU, video controller). But how is this FreeBSD fault?
I would attribute it more to inability of nVidia programmers, or their 
lack of resources (I doubt that many people do driver development there 
anyway) as the reason why we don't see it. If they have scarce resources 
available, it's understandable why they do not see the immediate need to 
port their code to FreeBSD. I am confident, given this hardware is not 
that cheap, that any bigger user asking for FreeBSD support could 
motivate them to just do it.
I also believe there is nothing hidden in FreeBSD and that in general 
FreeBSD has been more stable API-wise than other UNIX platforms around. 
And, I also believe should there be interest from nVidia, tey will see 
support and help from FreeBSD developers. Or they could just release 
their hardware spec, if they can't do it themselves for one reason or 
another. After all, much more complex tasks have been resolved with FreeBSD.


> 2) Disk and network I/O issues under load. We realized that FreeBSD has
> some issues in multithreaded environments. Even on 6/12 or 12/24
> core/thread systems, under heavy load (especially network and CPU load),
> disk I/O was (is?) poor. This is a no-go in a HPC environment.

Could you please elaborate on this a bit?
On one hand, I am surprised that the HPC environment will have such 
requirements and on the other hand this is how typical higher-end 
storage systems are built with FreeBSD. I haven't seen anything like 
this and am willing to test on 24-32 core systems.

You said this is political for FreeBSD .. why? I don't get it? FreeBSD 
has no policy of failing under heavy load -- quite the contrary.


> 3) Outdated ports OR not available ports: some important software
> maintained by the US government (USGS, NASA/JPL) is only provided for
> Mac OS X and some Linux derivatives.

This may be for many, many reasons, including (most often and most 
unfortunately) licensing. But there is not much anyone working with 
FreeBSD can do, except create an port, if the license permits.
If the license does not permit this software run on FreeBSD -- then 
probably the only choice is to try and persuade it's author.
If it runs on OS X, chances are it will run on FreeBSD with very little 
effort. (except if it relies heavily on Cocoa)

> 4) The lack of clustering capabilities. The lack of a clustered
> filesystem grows more and more important in the area of HPC, where
> storage systems get spread over a department. I lost track in the
> development on FreeBSD since around 2003. At the moment, for me
> personally this issue isn't so important, but in combination with items
> 1) through 3) and the migration towards Linux (we use prefereably Ubuntu
> server, some Suse and on some servers CentOS/RedHat, which suffers from
> the Linux-narrowminded deseas as well, in my opinion, but you'll get
> support by Dell and others - in times of strangling contracts, a more
> and more restricted freedom of science in favor of "business" ...
> another story ...)

Can you explain on this too? What kind of clustering filesystem you 
need? FreeBSD doesn't do bad in the storage area and in fact many 
(most?) commercial storage solutions are built on top of FreeBSD.


Daniel