Sylvestre's blog

For the story, due to license reasons, the version of Java packaged in Linux distributions is not the same as the one released on the official website.
Each time a new version of Java is was released, Sun/Oracle people are were publishing a other distro specific release available on a dedicated website.

Since I have been maintaining sun-java6 packages for a year and half, I am following the rhythm releases (security is one of the reasons).
A few days ago, I pinged on Twitter Dalibor Topic, who is, AFAIK, the person in charge of this at Oracle, he replied with a blog post Retiring the DLJ.

The main information from this blog post is:

[...] further Oracle JDK 6 (or Oracle JDK 7) releases on Linux and Solaris will not be provided under the DLJ [...]

Basically, that means that Linux distributions will not be able to package new releases of the proprietary JVM/JDK (including the latest update -27). The only release available in the Linux distro will be the OpenJDK.

While I am glad to see Oracle pushing the free JDK, I am a bit concern by this sudden decision. There are still bugs (for example, with fonts, applets or other others issues) present in the OpenJDK which does not happen in the sun-java6 packages.
And also, as Andrew John Hughes said on Twitter, the Oracle proprietary JVM just lost one of the two freedoms it had (free to redistribute the software)...

Moreover, many people are still using the proprietary JVM. For example, Debian popularity contest or Ubuntu Popularity Contest reports 836864 installations of sun-java6-jre against 749731 of openjdk-6-jre.

The bottom line is, if you are aware of bugs present only in OpenJDK, please report them (on the Debian bug tracker, launchpad or as a comment of this blog post). We will report them upstream to make sure OpenJDK is as good as sun-java6.

Edit: comments closed due to the spams... Drop me an email on sylvestre@debian.org. I will push them.

During the Debconf 11 in Bosnia, I took the time to implement the following Identi.ca feeds:

http://identi.ca/debiannew/ - Show the new packages submitted for inclusion in the Debian Archive (low traffic: 10 notices per day)
http://identi.ca/debianbug/ - Show the feed of the new bugs (high traffic: 136 notices per day)

They are also mirrored on Twitter:
http://twitter.com/debiannew
http://twitter.com/debianbug

Don't hesitate if you want new Debian feeds added on Identica or Twitter.

Here is some updates on the LLVM world into Debian.
LLVM and CLANG getting better and better after each release. After some lag, it is now time to have all these packages up-to-date into the archive.

Here is an update of their status in Debian:

• LLVM
  LLVM 2.8 and 2.9 are now available into the archive.
  For version 2.8, Matthias Klose deserves most of the credit.
  Version 2.9 is available in experimental.

  They both build pretty well on most of the architectures besides kfreebsd. It is on my TODO list.

• Clang. A C/C++ compiler.
  clang 2.8 and 2.9 are respectively available in unstable and experimental.
  These versions cover most of C/C++ specifications and more and more big software (Qt, Boost, Scilab, etc) succeed to be built with it.

  Like LLVM, it is available under most of the Debian architectures (but I haven't tested the quality of the ASM generated).

  clang can be used just like gcc. With most of software, calling configure/make with CC="clang" or CXX="clang" should be enought.

• * Dragonegg
  Dragonegg is a gcc plugin (llvm-gcc-4.5) which allows gcc to use optimizer and code generators of LLVM.
  It is now straightforward to use:
  
llvm-gcc -o foo foo.c


  I have lighten the "contact" between the gcc version used to build the extension and the version used to run it.
  It required the exact same version of gcc (even if the sources say it is probably a too strong requirement).

  Now, a warning like this one is displayed:
  
Potential incompatible plugin version. GCC: 4.5.3. Expected: 4.5.2
Defines 'dragonegg_disable_version_check' as env variable to remove this warning
Please note that unexpected errors might occur.


  If there is a better way to tackle this issue, I will be happy to hear it.

• llvm-defaults
  Last but not least, I uploaded llvm-defaults, a work of Arthur Loiret. This package allows a similar behavior to gcc-defaults. The installation of llvm will provide the default version of llvm.

Deprecated stuffs:

• llvm
  The llvm package has been removed. Actually, it was just the version 2.6 of llvm (see bug #625729). llvm (from llvm-defaults) is now providing the favorite version of llvm.

• llvm-gcc-4.2
  Upstream stopped the development of this plugin.
  It has been removed from the archive (see bug #626007) and dragonegg is taking the relay.

• llvm-snapshot
  llvm-snapshot (see bug #626083) followed the same direction as llvm-gcc-4.2

• llvm-2.7
  llvm-2.7 is still in the archive (see bug #626081) because of some reverse dependencies...

First, a quick news. Scilab 5.2.2 has been released a few days and he now available in the Debian archive (Debian Unstable for now).
It is mostly a performance improvements and bug fixes release. See the changelog.

Second, for a second year, Scilab is part of the Google Summer of Code v2010. I am admin (and also mentor) this year again.
Google just released the list of accepted students. We have 9 students (against 7 last year). 2 are working on experimental projects, the other should have a finished result by the end of the GSoC.

Extends Scilab UI Control - Han Dong
Extension of Scilab User Interface construction (uicontrol) by providing more elements (tree, image display, etc).

Simulink import in Xcos - Jerzy Zagorski
Importation of most of the Simulink schemas from Xcos.

Cumulative distribution function improvements - Michael Zhang
Improvement and extension of the current cumulative distribution functions (CFD) into Scilab.

Metanet and Boost.graph - Balša Raičević
Extension of the Metanet capabilities in term of graphs by Boost.graph

SOAP Client/server - Artem Glebov
Making available from Scilab both SOAP client and server capabilities as an ATOMS module.

Database module + fuzzySQL - Igor Gridchyn
Allow to access to most databases systems from Scilab. Based on this work, the FuzzySQL will be introduced, a SQL extension to allow flexible conditions in queries.

Python import - Baozeng Ding
Introduction of a mechanism to load and use Python code (objects in particular) from Scilab.

Experimental projects:
Use Eigen into Scilab - Joseph Fahnbulleh
Base some components of the Scilab core code on the Eigen library which is a state-of-the-art C++ linear algebra library. This work will be a joint mentoring between Gaël Guennebaud from the Eigen team and Scilab R & D team.

Hybrid Automata module - Ievgen Ivanov
Provide a convenient environment for direct modeling of hybrid automata in Scilab/Xcos.

In the numerical computing world, the cornerstones libraries are BLAS and LAPACK. They have been used in most of the numerical software for decades (like Scilab, R, numpy, OpenOffice with calc, etc).

During that time, many implementations appeared to improve the performances taking advantages of clusters, multicore, SEE{1,2,3,4}, various levels of cache...
Between the reference BLAS (refblas) to an optimized one like ATLAS or MKL (Math Kernel Library by Intel - non-free), it is not rare to have a 15 factor.

In Debian, we use by default the reference implementation of BLAS (168 reverse dependencies) and LAPACK (178 reverse dependencies). If the results are usually bad, they are pretty easy to use. What is hard to use, is switch between highly optimized libraries.
For now, the main one in the archive is ATLAS. ATLAS build process will launch many computations to know what will work best on the architecture. Results are usually excellent.

1) Upload of a refactoring of the ATLAS package.
I have been working on this for a while and after 19 uploads into Debian Experimental and I am happy (and kind of relief) to upload into debian unstable the release 3.8.3 of ATLAS.

The new key elements in this release are:

• Package of the release 3.8.3 ... Long overdue
• Much more packages for recent architectures (sse3, core2sse3, etc)
• A simplified maintenance
• Easy to build a custom package: fakeroot debian/rules custom
• Easy upgrade to version 3.9.X when it is stable
• 12 bugs closed in Debian (including 4 RCs)
• 6 bugs closed in Launchpad.
• MMX optimized package removed

Note that, as before, all prebuilt binaries of ATLAS will be always slower than if you built them on the target architecture (but using Debian binary packages will save a few kilograms of Uranium).

And one of most important feature is the capability to switch to any ATLAS implementation.

2) Switch between the different implementation
The problem in Debian (and Ubuntu) was that it was hard to switch between the ref BLAS/LAPACK and the optimized libraries. The user has to play with the LD_LIBRARY_PATH to use the various optimized packages and since there is no convention between the various distribution, the upstream developer has to develop crappy tricks to handle such things.

It is why I implemented the following proposal: Handle different versions of BLAS and LAPACK.

The main idea is to use the update-alternatives system to allow a quick and easy switch. For example:

# update-alternatives --config libblas.so.3gf 
There are 3 choices for the alternative libblas.so.3gf (providing /usr/lib/libblas.so.3gf).

  Selection    Path                                           Priority   Status
------------------------------------------------------------
* 0            /usr/lib/atlas-core2sse3/atlas/libblas.so.3gf   55        auto mode
  1            /usr/lib/atlas-base/atlas/libblas.so.3gf        35        manual mode
  2            /usr/lib/atlas-core2sse3/atlas/libblas.so.3gf   55        manual mode
  3            /usr/lib/libblas/libblas.so.3gf                 10        manual mode

# update-alternatives --config liblapack.so.3gf
There are 3 choices for the alternative liblapack.so.3gf (providing /usr/lib/liblapack.so.3gf).

  Selection    Path                                             Priority   Status
------------------------------------------------------------
* 0            /usr/lib/atlas-core2sse3/atlas/liblapack.so.3gf   55        auto mode
  1            /usr/lib/atlas-base/atlas/liblapack.so.3gf        35        manual mode
  2            /usr/lib/atlas-core2sse3/atlas/liblapack.so.3gf   55        manual mode
  3            /usr/lib/lapack/liblapack.so.3gf                  10        manual mode

Thanks to this, it is just trivial to switch from one to the other...

Conclusion:
I just pushed the changes into Debian unstable for blas, lapack and atlas.
I have been testing a lot these deep modifications and I fixed all the problems that I found. However, in case I missed something, please report a bug...