Date: Sat, 02 Jun 2012 14:00:21 +0300 From: Daniel Kalchev <daniel@digsys.bg> To: freebsd-stable@freebsd.org Subject: Re: Why Are You NOT Using FreeBSD ? Message-ID: <4FC9F245.8030300@digsys.bg> In-Reply-To: <4FC9DC69.6090907@zedat.fu-berlin.de> References: <CAOgwaMvsv3e1TxDauV038Pp7LRiYeH7oAODE%2Bw-pxHt9oGrXMA@mail.gmail.com> <2730bd1bab4223e718193254cb8bbd60@dizum.com> <CADLo838vpbVP3caXG7LF7st4inWnMLi5zB3U1hD2dkXwf8ZLBg@mail.gmail.com> <20120601194621.GA83046@e-new.0x20.net> <4FC9DC69.6090907@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FC9F245.8030300>