Am 12/28/11 15:24, schrieb Alexander Leidinger: > > Hi, > > you assume in your comment that development time "wasted" in the > linuxulator is time lost for other development. This assumption could be > valid for a commercially developed OS, but is wrong for FreeBSD. I tell > this as a person who spend a lot of time with the linux ports, mentored > a GSoC student who worked on the linuxulator and also put some time into > the kernel parts. That wasn't ment to be any offense! And shortly after I wrote this, i remembered myself that many stuff from JAVA is still completely not open due to Linux-shielded/protected stuff. Even commercial companies like DeLL seem to be incabale of offering JAVA apllets which are compatible to all platforms. I tried hard on geting their iDRAC6 stuff running on FreeBSD and recent firefox or even with diablo-jdk as a standalone JAVA application, but it lacks obviously some functionality only available in Linux firefox and/or JAVA. > > The use case for it is: run linux programs which are not available with > source or where "we" are not able to get it compiled on FreeBSD with a > reasonable effort. As a data point, "we" managed in the past to take the > closed source linux version of the Intel C/C++ compiler and manipulate > it in a way to run in the linuxulator but produce FreeBSD binaries. I > got reports that it was used in some HPC scenarios. Yes, you're right. We also used the Intel C and Fortran compiler to run a lot of scientifc programs on some boxes, but noadays, most software, especially scientific one, is 64bit since we deal with huge datasets which need a lot of memory and/or are happy having no memory limitations doing n-body simulations. But this is times ago. I'm sure there are still applications running 32bit, but the benefit of having 64bit and so a native 64bit compiler is quite huge. > > Wasn't it you who asked if there's a way to run CUDA on FreeBSD? > Pessimistic but interested souls would not wait until there is maybe > some result from open sourcing the nvidia compiler and instead either > try to get something similar up and running, or to get a 64 bit version > of the linuxulator. The later one may be more beneficial for more > people, and may even more easy as the parts are open source and there's > even some code somewhere in a VCS (maybe in perforce). Yes, it was me who asked for a 32Bit CUDA solution, because I desperately needed OpenCL/CUDA. And I asked because I wouldn't like to leave my FreeBSD platform for achiving this, but I do not have any chance. I tried to get the CUDA stuff working on FreeBSD, but it would take me ages to fullfill and at the end I need a development environment. The BLOG mentioned and referred to achive this is quite old and outdated and also stated that one need either a full Linux installation (Gentoo) or an development box. Well, having a development box menas also having a full working Linux that could be 64bit and running my applications. It is now that way. We use Suse 11 and Ubuntu 10 boxes with TESLA boards from nVidia and I have to compile my stuff and run it on those boxes. I also administer one of such boxes and I must confress, that I'm not happy with that. For once, it might be a personal thing, on the other hand I feel lost on such cryptographic and shell-polluted administrative environments, which could only be administered by special scripted tools - and each Linux distribution seems to have its own, holy and mystical way to encrypt former clean administrative ways to do. Days ago nVidia and AMD claimed to have opened their OpenCL intermediate language/representation and and nVidia claims to have opensourced their compiler. But althought requested being "member" of the elite group of people having access to that piece of software, I did not get access to it. So, it seems not to be real opensourced. But I think this might be a topic of another thread, which would be very interesting to me to discuss, since I'm not that familiar with what is possible in FreeBSD and what not. I see that, from the theoretical perspective of how LLVM works, their could be a chance to get FreeBSD on par with Linux in GPGPU concerned applications, which becomes very, very important now. > > Bye, > Alexander. Regards, Oliver > > -- > Send via an Android device, please forgive brevity and typographic and > spelling errors. > > > "O. Hartmann" <ohartman_at_mail.zedat.fu-berlin.de> hat geschrieben: > On 12/23/11 12:44, Alexander Best wrote: > [...] >>> Many suggested that the Linux binaries be run via the FreeBSD Linux >>> emulation. Unchanged. >>> There is one problem here though, the emulation is still 32 bit. >> >> plus the current emulation layer is far from complete. a lot of stuff > hasn't >> been implemented yet (meaning it's missing or implemented as dummy code). >> >> try running recent firefox linux binaries on freebsd. they will all crash >> almost instantly. >> >> cheers. >> alex >> > > [...] > > Sometimes I'm glad to have the Linuxulator, for instance using > Mathematica or an older 32bit IDL or even MATLAB. But lately, I run into > problems on more recent platforms like FreeBSD 9 and 10. > > There maybe serious reasons having the Linuxulator, i do not know. But > if not, why spending rare developer resources on that? As far as I'm > concerned, the only real reason having the Linuxulator is some stuff > from Adobe for desktop systems, Flash. That's it. > For the scientific stuff, I try to move my people towards OpenSource, > since we do "standard" stuff and I expect students and scientists > solving problems without fancy coloured clicky funny things. In > "production", this might be another point of view. SciLab from INRIA is > great, MuPAD, MAXIMA also. > > > But is there a real need running the Linux binary of Forefox on FreeBSD? > > Regards, > Oliver > -- O. Hartmann Freie Universität Berlin Institut fuer Geologische Wissenschaften Fachrichtung Planetologie und Fernerkundung Malteser-Str. 74--100/Haus D D-12249 Berlin Tel.: +49 (0) 30 838 70 508 FAX: +49 (0) 30 838 70 837
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:22 UTC