I have two questions.
1)
I'm testing H2O 3.10.5.1 version for xgboost modeling.
There is a known bug (PUBDEV-4585) that binary save/load of xgboost doesn't work.
Has it been fixed in the recent version? Confirmation is needed in order to make a decision with the server admin whether to upgrade the system or not.
2)
H2O.ai xgboost documentation says there is some limitation to platforms.
The "compilation OS" is Ubuntu 14.04, but is there a limitation to any other linux OS version like Redhat?
h2o.xgboost.available() returns TRUE but I need to make sure.
Thanks
Ad.1 Yes it's been fixed in version 3.18.0.1
Ad.2 The distro itself isn't really important. It's more important which exact version of RedHat are we talking about (since different versions come bundled with different lib versions) and whether you can upgrade libraries on your own if necessary. For example if you want to run the GPU version you'll need a certain version of glibc (2.17 or never if I remember correctly). For the CPU version most recent Linux distributions should be ok.
Related
Let's say if your remote host has python version 2.7. What difference does it make having 2.7 version vs. a newer version like 3.6 in the remote node? Does it make execution of playbooks faster? Same for the control node - What difference the python version makes other than some modules not being compatible with older python versions ?
Both versions 2.7 and 3.6 of Python are past end-of-life, so support for both of them is likely to be variable. Many modules have dropped support soon after end-of-life, and others may drop support at any time.
In principle, neither 2.7 nor 3.6 get security updates any more, although that may not be important if all ends of the connection are in any case trusted. However, if your systems have Python 2.7 and 3.6, other parts may also be past their respective end-of-life dates, and those may be more security critical.
Speed of execution is unlikely to be a big difference, most likely not noticeable; the biggest delay will in any case be the network round-trips.
I would like to try scidb as a replacement for hdf5. I would like to test it on my Debian laptop (no clusters) to give it a try.
Is this possible? Might be that Debian (as opposed to Ubuntu) is not supported?
I had no luck with the installation instructions. The deployment script tells that my OS is not supported. The scidb userguide says about some pre-built packages (for Ubuntu, at least). But there is no hint on how to obtain them.
SciDB is limited to RedHat / CentOS, and to Ubuntu as of the 14.9 release. Folk who want to run it on other distros generally compile from code.
Information about how to obtain the sources (as well as current documentation and community discussion) can be found on the forums here ... http://www.scidb.org/forum/. You'll need to register as a forum user.
Specifically, have a look at http://www.scidb.org/forum/viewtopic.php?f=16&t=364. There's a list of releases and links to code bundles there.
I installed SciDB several times using several ways (building from sources and installing from packages, installing the cluster version and the dev version).
Installation from packages
First, if you choose to install from packages (the easiest and fastest way), SciDB is very very sensitive about your Linux version. For example, for the last version of SciDB (14.8), if you choose to install on a Ubuntu, it has to be a Ubuntu 12.04 (and not a 14.04, a common mistake) 64 bits (meaning you have to install the AMD64 version even if you have an Intel processor). It won't work if you have a different version.
If you have an Ubuntu 12.04 AMD64, Paradigm4 provides a deployment script and a documentation with very simple steps:
https://github.com/Paradigm4/deployment
Installation from sources
It's not so difficult but it can be painful and time consuming. I did it because we had to compile a custom plugin for SciDB. You have two types of installation: dev install (in SciDB user directory) and cluster install (in /opt/ directory).
You have to be registered on their forum to have the link to the source code. They provide a specific documentation to build from source.
Good luck.
Several months ago I have dealt with porting SciDB 14.12 to an unsupported Linux - Fedora 19. If your OS is not supported, it will neither be supported if you try to install from the sources. You have to start from the sources, but then you have to adapt the deployment and installation scripts. The sources can be downloaded from SciDB forum.
Namely, add a new platform to deployment/common/os_detect.sh. Then, there are multiple platform specific deployment scripts, such as deployment/common/prepare_toolchain.sh, deployment/common/prepare_coordinator.sh and deployment/common/prepare_chroot.sh. You need to make sure those prepare the environment as they would on the supported OS'. I used Red Hat 6 and CentOS 6 as a reference, as those are both more similar to Fedora. Since your OS is Debian, you can first try falling back to Ubuntu deployment (in os_detect.sh).
Another problem you may encounter are the 3rd party tools, specially Boost. In my case, I had to build it manually from sources.
Sometimes when porting and debugging it is not convenient to run the scripts with deploy.sh, but it's better to run the deployment scripts directly on the target machine (e.g. coordinator).
Probably the best way to install and to start with SciDB is to download a standard image. With this image you only have to import the virtual machine with a software to virtualize. Moreover there are some characteristics of this virtual machine that are great to develop your first applications.
The main advantage, is that you have an API to SciDB queries and another to R. Then you can explore all options and to test SciDB.
This is the version that I downloaded few months ago: http://www.paradigm4.com/forum/viewtopic.php?f=14&t=1329&sid=606f614e401900cfa750375ba56de656
Nevertheless, there is a problem, the community is too poor. There are little people developing with SciDB.
I'm trying to install/update my clang from Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn) to clang version 3.3. I've downloaded the pre-compiled binaries into usr/bin/, as suggested by other posts (How can I update clang to 3.3 on Mac OS X 10.6).
The point of this installation/update is to be able to use C++ code (not written by me, and written for a newer machine OS 10.8.x) on my mac. I would preferentially use Xcode to update this, but unfortunately, Apple has not made the necessary version of Xcode available for free without a developer's subscription.
I've edited my PATH and LD_LIBRARY_PATH to include clang3.3/bin/ and clang3.3/lib, but I get an "Illegal Instruction" error and it's not clear to me why this is.
What I'd really like is to try the whole process again from the beginning with a step-by-step outline of the process, like is seen here (How to install clang pre-built binaries ubuntu 12.04), except for Mac OSX system, not Ubuntu.
I realize there are some previous threads that ask almost the same question, but I am asking specifically for these versions (and from a standpoint that includes very little experience installing via terminal/understanding pathways/etc.).
Thanks for any help.
How do I install a current Frama-C release and its prerequisites on Macs?
I have a laptop running Mac OS X 10.6.8 and a desktop running Mac OS X 10.7.5
which I can install software on. I also have access to a lab of machines
running Mac OS X 10.8 which our technical support people will install stuff on
if I ask nicely.
I have a student who is interested in program analysis and needs something
that we have a fighting chance of understanding and adding to. I was already
aware of Frama-C, and a colleague at another university recommended it.
I had previously tried to install Frama-C and failed miserably. The colleague
commented that he'd had the same experience. Well, times change. So I visited
the Frama-C web site, was more impressed and keener to have it than ever, and
set about it.
The frama-c.com download page doesn't have links to any binaries for the
current (Flourine 3) release for any platform. The link to installation
instruction takes me to a page that says to download the auto-installer.
What auto-installer?
There are instructions for an old version of Mac OS X, but following them
didn't work; loading one set of prerequisites as instructed produced a
state where the next prerequisite (gtksourceview) would not install.
Of course I checked the older releases, and I see that there's a Nitrogen
version for Mac OS X Leopard, but "Please untar the archive as root in /"
asks me to perform the impossible. I don't have a root account and will
never be given one (the machines all belong to the university). It is
perfectly possible to install gcc and clang anywhere you like; why does
Frama-C want to be in /?
In addition to Pascal's answer, you can also have a look to opam, which is a source package manager for OCaml applications. It appears to run on MacOS X, and there are packages for Frama-C's Oxygen and Fluorine.
All Frama-C binary packages want to install in / (precisely, in /usr/local/Frama-C) because Frama-C uses GTK+ and various GTK+-related libraries that were never designed to run from anything other than a fixed location. They load configuration files and resources from paths that have been hard-coded at compile-time. GCC and Clang install anywhere because they don't rely on GTK+. Like them, the command-line version of Frama-C can be relocated through various environment variables listed here.
Note that to take advantage of a binary package, you would only need one symbolic link pointing from /usr/local/Frama-C to the place where you really extracted the files, if your administrator(s) can grant you that. Binary packages only work for one OS X version. For packages available from the official website, this version is usually 10.6 (Snow Leopard).
I have ceased making Frama-C binary packages for two reasons:
by removing features and support for hardware configurations in each of the last two OS X releases, Apple has fragmented the OS X landscape in a way I don't have the time to deal with. You mention 10.6, 10.7 and 10.8 in your question. I also have Macs running each of 10.6, 10.7 and 10.8. They are all incompatible (when trying to build a software package that includes a compiler).
I have much less time available now that I am participating in the creation of a start-up that offers Frama-C-based static analysis to interested industrial users.
This said, Frama-C the Open-Source advanced research prototype continues to be developed and maintained, and continues to be a great testbed to experiment in. You can install Frama-C without root access on a Mac in two ways apart from what you have already tried:
Install only the command-line version. Then the only dependency is a recent version of the OCaml compiler. Frama-C's configure will detect that you do not have the GTK libraries and will not try to use them. Installation should take 20 minutes at most for a recent OCaml + the latest Frama-C.
Install a recent Linux distribution in a virtual machine. Use that distribution's package manager to obtain all the GTK+ dependencies. If the distribution's OCaml package is recent enough, use that and then the lablgtk-2 package, otherwise, compile OCaml and then lablgtk-2 from source. Then compile Frama-C.
For Fluorine, the oldest supported OCaml version is 3.12.1.
with macports:
export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
sudo port install opam
opam init
Y
eval `opam config env`
sudo port install gtksourceview2 lablgtk2 ocaml-ocamlgraph
opam install frama-c
I have a bit of a problem. I need to use the strace utility to figure out why a command is crashing on an older Linux system. Unfortunately, I don't have strace nor do I have gcc/binutils on that system.
I tried building the app statically on a current Debian system, but calls to getpwnam require a dynamic load of the version of libc that was used at compile time. That would be fine, but being that the utilities on the older system were all built using an ancient version of libc, putting a newer libc on that system breaks everything else.
Short of downloading and installing an old distribution of Linux and then doing the build, is there an easier way around this problem? The original distribution on this system is currently unknown and the more I research it, it's getting to seem like a huge chicken vs egg problem. Any tips would be much appreciated.
Using an outdated Linux system is never wise... can it be upgraded? If not, why not? What is failing, and how? Any chance of updating that?
There should be a file named /etc/release or similar, that should give you an idea of the distribution and version. Or uname -a might give a clue on the distribution. If it doesn't work, try to see if commands like rpm, apt-get, or one of the other package management commands are available, that will narrow down the distribution. A Google search for some of the installed packages with versions might help narrow down the version of the distribution.
Knowing distribution and version you may be able to get strace (and perhaps other needed packages). Many distributions keep archival versions (at least of the original installation media for old versions) around.