Wednesday, 30 October 2013

How much of Slackware is in Salix?

That is a question that I had in my mind for a while. At some point I had also done the actual counting, so I had an idea, but I never wrote anything down.

There are many people that believe that a derivative distribution only just leeches their parent distribution, maybe changing the default wallpaper or a couple of settings here and there and making a release. I know for a fact that some people that have never tried Salix (or have tried Salix but never Slackware itself) even think the same for Salix. I don't doubt that there are a lot of derivative distributions that are like that, but well... Salix is definitely not like that.

The numbers that are shown here are for Slackware/Salix 14 .0 and the 32-bit repositories. For previous, or more recent releases (when they will be released) the numbers would probably be very similar. The 64-bit repositories should be the same as the 32-bit repositories (give or take a package). These numbers may also change a little in the course of each release's lifetime as security related packages are added to the patches directories etc, but only just a little.


First of all, all of Slackware is in Salix. What I mean by that, is that every package that is included in the Slackware repositories, is available in Salix through the package manager (GSlapt from the GUI or slapt-get from the command line). There are a few exceptions, where we substitute Slackware packages for Salix-specific package, for several reasons that are very important to us, but that's it.

So, in terms of available pre-packaged software that you can find through the package manager in Salix, there is a total of 2145 packages. Of that, 1151 (53.7%) are original Slackware packages. The rest (994, 46.3%) are packages that were build for Salix and that you cannot find in Slackware repositories. Of course, Slackware users can install any of those packages if they like as every package is 100% compatible to Slackware. So, Salix almost doubles the amount of ready made software that a Slackware user can install.


So, what happens with Salix releases and the system that you get right after a fresh installation? The answer here varies, as Salix has several releases, based on different Desktop Environments and there are also different installation modes for each of those releases, Core, Basic and Full, respectively.

We'll take a look at our Xfce, KDE and our soon-to-be-released Ratpoison editions for version 14.0.

Keep in mind that the numbers listed below are what happens right after a fresh installation. If people install the multimedia codecs using our salix-codecs-installer tool (and most people would), the number of Salix packages would increase by about 50.

Core Installation

A Salix Core installation is exactly the same, no matter what iso image you used to make the installation.

After a Core mode installation, you get a total of 250 installed packages. Of those packages, the vast majority (233, 93.2%) are Slackware packages. The rest (17, 6.8%) are Salix-specific packages. The Salix packages are mainly the package manager, the Salix command line system tools and their dependencies and nothing more.

So, what you get with a Salix Core installation, is mainly a Slackware system that only works from the command line and only very few added packages by Salix. It's funny, because there are a lot of Slackware users that apparently look for a stripped down Slackware installation with no GUI, but never look at Salix.

Xfce Basic Installation

OK, so what happens once we start adding a GUI and all related packages. A Salix Basic installation adds only the Desktop Environment and very few graphical applications on top of it, like a browser, a graphical package manager and the Salix GUI system tools.

After an Xfce Basic installation, you get a total of 579 packages (including all the packages in the Core installation). 532 of those packages (91.9%) are pure Slackware packages. Still, only 47 (8.1%) are Salix specific packages. The number of Salix specific packages might still be small, but these few packages this time make a difference; among these packages there are packages that add important functionality, like the Salix GUI system tools or a login manager etc.

Xfce Full Installation

An Xfce Full installation is what most people would use though.

A total of 761 packages are installed (including all packages in the Core and Basic installations). Of those packages, 611 (80.3%) are Slackware packages and 150 (19.7%) are Salix packages. So, the Salix part becomes really significant here and among the Salix packages are some that are considered really important for a desktop distribution, like the LibreOffice suite, the media players, document/image viewers etc.

KDE Basic Installation

After a KDE Basic installation, you get a total of 626 packages installed. The number of Slackware packages is 580 (92.7%) and the number of Salix packages is 46 (7.3%). The numbers are similar to the Xfce Basic installation.

KDE Full Installation

A KDE Full installation includes a total of 760 packages. Of those, 661 (87.0%) are Slackware packages and 99 (13.0%) are Salix packages. The numbers are similar to the Xfce Full installation, only slightly skewed to the Slackware side, as KDE is a major part and the default DE for Slackware and a lot of KDE-related software is part of Slackware anyway.

Ratpoison Basic Installation

In a Ratpoison Basic installation, there is a total of 561 packages. Of those, 514 (91.6%) are Slackware packages and 47 (8.4%) are Salix packages. So, numbers are similar across all Basic installations.

Ratpoison Full Installation

A total of 672 packages are installed in a Ratpoison Full installation. The number of Slackware packages is 575 (85.6%) and the number of Salix packages is 97 (14.4%). The numbers are somewhere in between the Xfce and KDE Full installations.


Here is a table that sums up all the numbers mentioned above:
Total Slackware Salix
Repositories 2145 1151 (53.7%) 994 (46.3%)
Core 250 233 (93.2%) 17 (6.8%)
Xfce Basic 579 532 (91.9%) 47 (8.1%)
Xfce Full 761 611 (80.3%) 150 (19.7%)
KDE Basic 626 580 (92.7%) 46 (7.3%)
KDE Full 760 661 (87.0%) 99 (13.0%)
Ratpoison Basic 561 514 (91.6%) 47 (8.4%)
Ratpoison Full 672 575 (85.6%) 97 (14.4%)

It is obvious that the contribution of Salix to the Slackware ecosystem is significant. With Salix almost doubling the amount of packages that Slackware offers, it is the largest third-part package repository for Slackware out there. What's most important is that these packages are of very high quality, tested and guaranteed to work in a pure Slackware installation.

Moreover, the part that Slackware plays in every Salix release is apparent. What you get after a Salix installation, is really a stripped Slackware system, that includes all the extra parts that Salix provides to make it really usable.

Tuesday, 22 October 2013

New website design!

As many might have noticed, we now have a new main website design!

Since the Salix project was started, the main website was actually a part of our wiki, which is using the MediaWiki engine. That had one main advantage, which at that time seemed enough to justify that choice; we would use a single CMS to manage both our wiki and our main page. So, we created a custom MediaWiki theme that would look good as a main project page and as a wiki. And admittedly, that worked fine for several years!

During the last months though, disadvantages started to become obvious. What happened first was that the latest updates to the MediaWiki software broke our custom theme. So, that meant that we should either fix that custom theme (which mostly meant writing it from scratch again) or separate the main page from the wiki and use the wiki with a standard MediaWiki theme. We went for the latter option as that was considerably less work! So, the wiki would look more like any other MediaWiki based wiki out there, but we were free to upgrade it to newer versions, covering security issues without thinking of what it will do to our main webpage.

That left us hunting for a system to manage our main page. The first option we tried was Pelican. It really looked like a good choice. The content was written in simple markdown and then using Pelican we would take that markdown and transform it into a full website that Pelican could also upload and sync to the main server. And what Pelican created was simple HTML content. No database was needed to run in the background and there was no PHP content anywhere. Nice and simple. The fact that the content was plain HTML, would mean that the website would be less prone to attacks. Also, the fact that also used Pelican for managing their website was very reassuring too. So, we took the Pelican theme that was using, tweaked it a bit and that looked good and very close to what we wanted!

The advantages of using such a system became apparent shortly after we switched. Unfortunately, we had hardware troubles with the server that hosted our main page, our wiki and our forums. The MySQL databases that the wiki and forum were using would become corrupted and the wiki and forums would stop working. It took us a while to realize that this was actually caused by a hardware problem. We first thought that it was a hard drive in the RAID array failing, but all hard drives passed any tests without problems. Then, since we were getting filesystem errors constantly, we thought that it may be the hard drive controller card, but that looked OK too. It turned out that the mainboard was faulty, so after a mainboard replacement, everything was back to normal again. But during all that time, the wiki and forum was mostly down, but at least our main page was working! The fact that it was only static HTML pages and it didn't need a database or any code for that matter running on the server made it work with no problems with even such severe hardware errors!

So, Pelican looked indeed like a very nice choice! And it worked nicely as our main page for a month or so. Serving static content is also a lot faster than serving a complex CMS, the main page would load a lot faster than before. But then trouble started again. I wanted to update some content on the main page. For generating the main page, we had originally used Pelican 3.0 and that was what I had installed on my laptop which I had used then. Unfortunately, I had forgotten that laptop at my parents house after a weekend visit and wasn't going to get it back for at least another couple of weeks. So, I went ahead and installed Pelican 3.3 at the laptop I actually had with me, which was now the latest version (and the one that was easier to install using pip). And then realized that everything was broken. The upgrade from Pelican 3.0 to 3.3, meant that the theme that we were using needed a major restructuring (possibly a complete rewrite) because it wouldn't work at all any more. So, we either had to do that, or switch to something different, once again. During all that time, it also became apparent that Pelican was mostly suited to writing blogs, instead of mostly static content which is what we wanted. It could create static content, but it's main thing is really blogs...

It was then that I remembered that I was already using a tool that could create simple, static HTML content using simple markdown. I was already using txt2tags to create man pages for all the system tools that you can use in Salix, but it can also create HTML pages too (among over a dozen other different output formats). So, maybe it was simpler to switch to txt2tags. And it was! txt2tags can be used to create simple HTML pages and those pages can look like anything you like, using CSS! That is an even simpler system than Pelican and closer to what we were looking for in the first place. The txt2tags website itself is written in txt2tags as are a number of other different websites which you can find on the txt2tags website. I liked the looks of the txt2tags website so much that I used exactly the same CSS, with only minor changes. So, that is why both pages look very similar.

In the spirit of Pelican, I created a simple Makefile that would help with generating the static HTML content and also with updating the main webpage with it. Everything is online in my github repo.

If in the future we decide to switch to a different look, it's just as simple as using a different CSS. Since the txt2tags syntax is highly unlikely to change, our main page is now beautiful, fast, more secure and future-proof!

I'd like to thank Thorsten for all his work with our wiki, forum and Pelican website. I'm mostly ignorant of how it all works...