Scilab in Fedora GNU/Linux
Filed under: 
aving encountered problems with Octave in Fedora 14, I decided to explore scilab, which I wanted to try about a week ago anyway (and canceled the process after being warned that it was not as complete as octave, at least not for my needs). Fedora does not appear to have scilab in its repositories (Ubuntu on the other hand does have it). A yum and kpackagekit search around “scilab” yields nothing, so I went to the official scilab Web site and downloaded the latest package from that nice Web site, then uncompressed it. This was not the end of it as far as Fedora was concerned because, due to it not being available in the repositories, dependencies could not be resolved, so I needed to also install java manually, then figure out that SELinux was standing in my way. This is the type of thing which would deter new users and as much as I would love to endorse Fedora 14, it is experiences like this which leads me to saying that Kubuntu is still a better choice. Here is a self-explanatory story:
[roy@blueberry scilab-5.2.2]$ ls ACKNOWLEDGEMENTS CHANGES_3.X CHANGES_5.2.X lib RELEASE_NOTES_5.0.X thirdparty bin CHANGES_4.X COPYING license.txt RELEASE_NOTES_5.1.X CHANGES CHANGES_5.0.X COPYING-FR README_Unix RELEASE_NOTES_5.2.X CHANGES_2.X CHANGES_5.1.X include RELEASE_NOTES share [roy@blueberry scilab-5.2.2]$ cd bin/ [roy@blueberry bin]$ ls intersci modelicac scilab scilab-adv-cli scilab-bin scilab-cli scilab-cli-bin [roy@blueberry bin]$ ./scilab Could not load JVM dynamic library (libjava). Error: libjvm.so: cannot enable executable stack as shared object requires: Permission denied If you are using a binary version of Scilab, please report a bug http://bugzilla.scilab.org/. If you are using a self-built version of Scilab, update the script bin/scilab to provide the path to the JVM. The problem might be related to SELinux. Try to deactivate it. Scilab cannot open JVM library. [roy@blueberry bin]$ su Password: [root@blueberry bin]# yum install libjava Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list Setting up Install Process No package libjava available. Error: Nothing to do [root@blueberry bin]# yum install java Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package java-1.6.0-openjdk.i686 1:1.6.0.0-44.1.9.1.fc14 set to be installed --> Processing Dependency: jpackage-utils >= 1.7.3-1jpp.2 for package: 1:java-1.6.0-openjdk-1.6.0.0-44.1.9.1.fc14.i686 --> Processing Dependency: rhino for package: 1:java-1.6.0-openjdk-1.6.0.0-44.1.9.1.fc14.i686 --> Processing Dependency: tzdata-java for package: 1:java-1.6.0-openjdk-1.6.0.0-44.1.9.1.fc14.i686 --> Running transaction check ---> Package jpackage-utils.noarch 0:1.7.5-3.11.fc14 set to be installed ---> Package rhino.noarch 0:1.7-0.7.r2.fc12 set to be installed --> Processing Dependency: jline for package: rhino-1.7-0.7.r2.fc12.noarch ---> Package tzdata-java.noarch 0:2010o-1.fc14 set to be installed --> Running transaction check ---> Package jline.noarch 0:0.9.94-0.6.fc14 set to be installed --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Installing: java-1.6.0-openjdk i686 1:1.6.0.0-44.1.9.1.fc14 fedora 27 M Installing for dependencies: jline noarch 0.9.94-0.6.fc14 fedora 88 k jpackage-utils noarch 1.7.5-3.11.fc14 fedora 60 k rhino noarch 1.7-0.7.r2.fc12 fedora 775 k tzdata-java noarch 2010o-1.fc14 updates 151 k Transaction Summary ======================================================================================================= Install 5 Package(s) Total download size: 28 M Installed size: 84 M Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata updates/prestodelta | 248 kB 00:00 Processing delta metadata Package(s) data still to download: 28 M (1/5): java-1.6.0-openjdk-1.6.0.0-44.1.9.1.fc14.i686.rpm | 27 MB 00:10 (2/5): jline-0.9.94-0.6.fc14.noarch.rpm | 88 kB 00:00 (3/5): jpackage-utils-1.7.5-3.11.fc14.noarch.rpm | 60 kB 00:00 (4/5): rhino-1.7-0.7.r2.fc12.noarch.rpm | 775 kB 00:00 (5/5): tzdata-java-2010o-1.fc14.noarch.rpm | 151 kB 00:00 ------------------------------------------------------------------------------------------------------- Total 2.2 MB/s | 28 MB 00:12 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : jpackage-utils-1.7.5-3.11.fc14.noarch 1/5 Installing : jline-0.9.94-0.6.fc14.noarch 2/5 Installing : rhino-1.7-0.7.r2.fc12.noarch 3/5 Installing : tzdata-java-2010o-1.fc14.noarch 4/5 Installing : 1:java-1.6.0-openjdk-1.6.0.0-44.1.9.1.fc14.i686 5/5 Installed: java-1.6.0-openjdk.i686 1:1.6.0.0-44.1.9.1.fc14 Dependency Installed: jline.noarch 0:0.9.94-0.6.fc14 jpackage-utils.noarch 0:1.7.5-3.11.fc14 rhino.noarch 0:1.7-0.7.r2.fc12 tzdata-java.noarch 0:2010o-1.fc14 Complete! [root@blueberry bin]# ./scilab Could not load JVM dynamic library (libjava). Error: libjvm.so: cannot enable executable stack as shared object requires: Permission denied If you are using a binary version of Scilab, please report a bug http://bugzilla.scilab.org/. If you are using a self-built version of Scilab, update the script bin/scilab to provide the path to the JVM. The problem might be related to SELinux. Try to deactivate it. Scilab cannot open JVM library. [root@blueberry bin]# killall selinux selinux: no process found [root@blueberry bin]# ./scilab Could not load JVM dynamic library (libjava). Error: libjvm.so: cannot enable executable stack as shared object requires: Permission denied If you are using a binary version of Scilab, please report a bug http://bugzilla.scilab.org/. If you are using a self-built version of Scilab, update the script bin/scilab to provide the path to the JVM. The problem might be related to SELinux. Try to deactivate it. Scilab cannot open JVM library. [root@blueberry bin]# ./scilab
This worked the second time only because I made SELinux more permissive, but this could have many users give up. Here is what I then got:
As expected, there is no support for some fairly basic functions in scilab, which is not a complete octave replacement.
-->imshow('in')
!--error 4
Undefined variable: imshow
-->imread('in')
!--error 4
Undefined variable: imread
I do not want to install MATLAB or Fedora (although we do have an academic licence), but experiences with Fedora so far may drive me towards installing proprietary software or simply working from another box which happens to be better equipped and work perfectly well with Octave. That box runs Kubuntu.
BOUT three weeks ago I decided to go back to working with Fedora. This distribution served me well over the years, especially in distributed clusters. Fedora 14 looked very promising and it still is, but there are creases that are hard to undo and to hide. In order for matters to improve I will post a quick rant and hope that someone, somewhere will help address the issue that I’ve already reported (I also submit bug reports whenever that’s possible).
‘ve been an Octave user on several machines and everything worked perfectly well until Fedora 14, which has a newer version of the software and thus a serious conflict of incompatible libraries. For many image loaders the following type of error is shown just before Octave crashes:
HIS POST is part of a series that I do about my incursions moving from MATLAB to Octave, which has so far been a pleasant experience. QtOctave looks better and is easier to install than MATLAB (on GNU/Linux with KDE at least). For those who experienced being a customer/user of MATLAB, it can really be a pain in the butt, licence-wise. The parent company, MathWorks, can be very aggressive when it comes to licensing (it pays the BSA after all), so people are kept tied to particular IP addresses and must renew something to remove artificial limitations. Moreover, the toolboxes that MATLAB sells separately are a case of artificial scarcity and they can be expensive. Octave resolves much of this by centralising a lot of software as shown in the screenshots above (also separating free/libre from proprietary). Rather than waste time with paperwork and bank transactions, any QtOctave user can simply and quickly click away to receive anything s/he desires. It’s truly like a candy store.
N A KDE (Qt) desktop like mine, despite MATLAB putting a lot of effort into improving the GUI on the GNU/Linux side* (even adding a Microsoft Windows-esque “Start” button at the bottom left), QtOctave integrates more nicely with the desktop. Thanks to all those who suggested some other tools including R,