I assume all of you had a safe year-ending? With all the fireworks, a finger or an eye is easily lost… I also assume that you are full of good intentions for the new year. I wish you all a prosperous and happy 2012, and I hope we will see a new shining release of Slackware Linux in the course of this new year!
Let me tell you some about what I have been doing in the past days. Thinking about the future of course – not much of that will interest you. More to the point, I have been thinking what needs to be done for Slackware to gain a little more ground.
There has not been a lot of movement in slackware-current for the past months and while that is pretty frustrating, we will have to respect Patrick Volkerding for giving his personal life a bit more priority now. In the meantime, I will keep myself busy with some of the “subsystems” in Slackware – KDE 4.8 is around the corner and I will certainly build packages for that.
There is also the urgent issue of dealing with JDK and JRE. As you may remember, Oracle decided that new binary releases of its own Java SE (the runtime or JRE as well as the SDK) may no longer be included with Linux distros. They retired the “Operating System Distributor License for Java” (DLJ) and decided that distros should compile their own packages using the Open Source codebase of OpenJDK,.which Oracle itself uses as well for their binary builds. Slackware has not seen an update to its Java packages since that announcement. I have been busy in the past weeks preparing a set of Slackware OpenJDK packages. That was not trivial, since OpenJDK requires several additional packages in order to be compiled from source. It also required changes to Slackware’s gcc-java and seamonkey packages since I wanted OpenJDK to be “bootstrapped” against GCC’s java compiler. I could have chosen the easy way and compile it using a binary Java package downloaded from Oracle (which is acceptable as long as I do not re-distribute the downloaded binaries) but I had my reasons for not doing that – see below. I have now a working OpenJDK installed on my Slackware-current laptop, including a web-browser plugin for Java. That looks promising and I have uploaded all my work to the Slackware server so that Pat V. can have a look at it and ultimately add it to Slackware.
I had a goal in mind when I decided to take the hard way and compile OpenJDK using the (not fully compliant) GCC Java compiler It is the only way that we may finally be able to create a Java package for ARMedslack! The ARM port of Slackware currently has no Java support at all and I intend to change that.
You may ask, where this interest in Slackware ARM comes from. You have not read my recent posts perhaps?
It’s quite simple really. Because I think this platform is ready for prime time. The first powerful ARM based laptops have finally shown up. They are currently mostly running Android – think of the ASUS Transformer (powered by a Tegra 2 – essentially the chip which also powers a lot of the new Android tablets). You can barely fail to notice that all the big distros (Arch Linux, Gentoo, Fedora, Debian, Ubuntu) are working hard on a port to these new ARM platforms. I believe that Slackware should be part of that effort.
So, first of all, I am eagerly waiting for the Raspberry Pi devices to become available for sale. A computer for 35 dollars, that is something nobody should be able to resist. I want one of those and install ARMedslack on it. Stuart Winter is willing to port ARMedslack to this new device (hopefully the kernel is the only package which needs to be crafted specifically for the new ARM CPU). And second, I already bought another ARM based computer: the TrimSlice Pro. The TrimSlice is of an entirely different league than the low-spec Raspberry Pi. It runs on the same Nvidia Tegra-2 chip I already mentioned earlier. The Tegra 2 has a dual-core ARM CPU running at 1 GHz and a GeForce GPU which should be capable of 1080p full-screen HD video payback.The TrimSlice also has 1 GB of RAM and comes pre-installed with Ubuntu Linux on a 32 GB SSD harddisk… now that screams to be replaced with Slackware. This device should be fast enough to be used for compilation of ARM packages. Stuart is working on a kernel for this device, but there are some complications. The TrimSlice uses a USB to SATA bridge to connect the SSD. That causes USB disconnects with the ARMedslack kernel when large amounts of data are written. Stuart will undoubtedly find a fix for that in the end.
And while Stuart works on the ARMedslack packages I have been considering what would be a second port to ARM. The crux is that ARMedslack supports a wide range of ARM computers (which is linked to the history of the port) and therefore does not profit from the new CPU’s which also have hardware floating point units (FPU). I want to try and start a port to “ARM hard float” architecture which should give it a big speed boost compared to ARMedslack. Of course, this means that the new port will not run on older devices like the SheevaPlug, or ARM based NAS/mediaplayer boxes which typically run cusom Debian distributions. I spent part of my holiday to write a script which cross-compiles a basic toolchain (kernel, binutils, glibc, gcc, bash and other necessary stuff) which can be used to compile the rest of Slackware. I now have a small root filesystem (containing a “armv7hl-slackware-linux-gnueabi” target) ready for testing on the TrimSlice. If only there is enough time left… my short X-Mas holiday is nearing its end, and with it the room to experiment.