Re: Why Are You NOT Using FreeBSD ?

On 06/01/12 21:46, Lars Engels wrote:
> On Fri, Jun 01, 2012 at 08:32:08PM +0100, Chris Rees wrote:
>> On 1 June 2012 16:20, Nomen Nescio <nobody_at_dizum.com> wrote:
>>>> Dear All ,
>>>>
>>>> There is a thread
>>>>
>>>> "Why Are You Using FreeBSD ?"
>>>>
>>>>
>>>> I think another thread with the specified subject   '"Why Are You
NOT Using
>>>> FreeBSD ?" may be useful :
>>>>
>>>>
>>>> If you are NOT using FreeBSD for any area or some areas , would you
please
>>>> list those areas with most important first to least important last ?
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.

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.

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.

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. We created our own ports for some
of those, but maintaining these, especially those provided by the USGS
(ISIS3) is hard work. Other software, like the AMES StereoPipeline,
seems to be crippled by intention when it comes to the sources
(essential portions are "vanished" in the repositories).
Developers are unwilling - by intention, lack of time or lack of
capabilities.

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 ...)


Well, item 3 isn't a real FreeBSD issue. I have the impression that
since the good old UNIX times, mid 1990s, a deadly Virus spread around
called Linux, attracting development schemata known from
Microsoft/Windows: narrow minded Linux-only sources, nearsighted
development, shortcuts due to political reasons, even if the sources are
available for all.
I regret this development of "open software" very deeply and it is not
the *BSD UNIX developers fault (excluding item 1 and 2, that are
political issues and a burden of the BSD folks having made political
decissions in the past!).

I do not speak for my department and I do not speak for my colleagues. I
speka for myself and my opinion.
Personally, I use FreeBSD private and under my desk - and I really
suffer from the lack of GPGPU, since even some opensource, high
performance software like "Blender" benefetis tremendously from using
CUDA/OpenCL if GPU is available.

Regards,

Oliver Hartmann