Thursday, 9 October 2014

We have been mirroring the slackbuilds.org
(SBo) repository and at the same
time applying slight changes to it for some time now. These changes are
essential to Salix, for a few reasons.

First of all, the SBo maintainers have decided that they
will only list SlackBuild dependencies only if these are not part of a
Slackware full installation. While this may be a decision that is fine
for Slackware itself, since they don't offer any kind of support for
users doing anything other than a full Slackware installation, it's
generally not good for Salix, since a Salix installation of any edition,
is slimmer than a full Slackware installation, by far. For example, in
Slackware it is expected that everyone has the Qt libraries installed,
but this is definitely not true for Salix (except from our KDE edition
of course). So, a lot of the SlackBuilds at SBo end up
having missing dependencies when it comes to a Salix installation.

Then, there is a problem with package/SlackBuild naming. We have a lot
of packages in the Salix package repositories that are also present in
the SBo repository. While we try to keep the package naming consistent
with the one they're using in SBo, that is not always possible. For
example, at this moment, there is a package named "python-configobj" in
our package repositories and another one named "configobj" in SBo, which
are actually the exact same piece of software. Even if we made every
effort and named everything at the time of release according to the SBo
names, SBo is constantly changing and SlackBuilds may be renamed.

Another problem (for lack of a better word) is that SlackBuild
maintainers choose to update their SlackBuilds as soon as a new version
of the software they are packaging is out. While this might not be bad
in itself, it kind of conflicts with the way things work for the binary
package repositories in Slackware and also in Salix, which generally
follow the idea that upgrades should only be done for security reasons.
And since there is a very wide overlap between packages offered in the
Salix binary package repositories and the SlackBuilds provided by SBo,
there are often newer versions available in SBo than in the Salix binary
package repositories. This might confuse users, because by opening
Gslapt, they find one version and by opening Sourcery, they find
another, often newer, version. What's more, if they were to "upgrade" to
the version available in SBo, they would find that Gslapt/slapt-get
would want to "downgrade" that package to the version available in the
Salix binary repositories and the only way to stop that would be to put
the package in the EXCLUDE list in their slapt-getrc file.

So, in Salix, we have to deal with these problems. Here's what we do...

Our own copy of the SBo repository, the one that is
available by default to Salix users through our package management tools
is synced with the main SBo repository every few hours.

For the first problem mentioned above, we have a mechanism for adding "missing" dependencies
in our copy of the SBo repository. For example, the ardour SlackBuild
requires cmake to build. Now, cmake is always thought to be
present in a Slackware installation, otherwise it is not a full
Slackware installation and it is not supported in any way. In Salix
though, cmake is definitely not part of a standard installation and
so we add it as an extra dependency for ardour.

For the second problem, we have created a list of packages/SlackBuilds
that are named in a different way between repositories. Every SlackBuild
that is also present as a binary package in the Salix repositories with
a different name, is removed from our own copy of the SBo repository and
every reference to it in dependencies is replaced with the name that the
package has in our own binary package repository. This way, the package
in the Salix binary package repositories is always used, even if it is
originally named otherwise in the original SBo repository.

Finally, all software that is present in both the Salix binary package
repositories and SBo, is removed from our own copy of the SBo
repository, so there is no way users will be confused and go back and
forth between versions. Actually, the SlackBuilds themselves are not
removed from the repositories, rather the reference for them in the
SLACKBUILDS.TXT file is removed, so it isn't used by our SlackBuild
management tools, slapt-src, Sourcery or spi.

With SBo being a moving target though, this process will always be
ongoing and will never be 100% complete. If you find a SlackBuild that
is missing some dependency, please report it, either in our
mailing list or in our
forums. Similarly, if you find the same
SlackBuild present in both the Salix binary package repositories (hence
available in Gslapt) and our own copy of SBo repositories (hence available in Sourcery), please
report that too. Of course feel free to report any other problem you
might find with our repositories.

Wednesday, 26 March 2014

MATE 1.8 has been released in source code
form by its developers about 3 weeks ago and I have been working on
packages for Salix for about as long. The good news is that I think I'm
almost done! So, expect MATE 1.8 packages to hit the repos sometime in
the following days. We didn't have any MATE release for Salix 14.0, but
it looks like we are going to have one for 14.1!

We have already included some MATE 1.6 packages in our repositories
and we have used those for our Xfce release as well, but a complete MATE
1.6 desktop was not included. The packages that we already had included
were mate-document-viewer (atril), mate-file-archiver
(engrampa), mate-dialogs and their dependencies and that's about it.
These are also the
packages that were built first for 1.8. In total there are about 30
packages that will be pushed to the repositories, so any of these
packages that you might have on your system will be upgraded to their
1.8 counterpart in the next days. The upgrade should be competely
harmless, so nothing to worry about. In fact I had already patched the
1.6 packages with some fixes from the 1.8 branch, so the most important
changes were already there.

I had considered using packages from the
MATE SlackBuilds project, but only
very briefly. While the guys there have done a good work on their
packages, I realized that in most cases, we had to built our own
packages.

Some of the packages from the MATE SlackBuilds project were
built using dependencies that we would never have in Salix, at least not
by default. Several packages were built with support for NetworkManager,
which we do not ship by default. There was even a case where one package
was built using GTK+ (version 1, that is ancient!) which would definitely
not work for us.

One other thing that I didn't like at all about these
packages, was that help wouldn't work at all (used from the Help menu or
using the respective buttons in any application). It would just show an
error message, because it needs yelp. The problem is that they haven't
included yelp and what's worse, they have removed the actual help files
from the packages. So, even if we built a package for yelp, help would
still not work and there would still be an error message. And having an
error message pop up doing something really normal, like selecting a
menu option that is right there, everywhere, is something I don't like
at all. Now, I also don't care about yelp though and mostly everything
that comes from GNOME. So what I did was that I patched every single
MATE application/plugin and pointed the help menu items/buttons to the
MATE webpage. Works a lot better than any error message.

And then there was the default settings issue. The packages we use,
should include default configuration that will fit with Salix, including
panel location, panel applets selection, icon theme used, window manager
theme, stuff like that. The default menus that ship with MATE also include
two separate "System" menus, one under the "Applications" submenu and
one under the "System" menu, which is kind of confusing in my opinion.
So, I edited the default menu specifications to keep only the latter and
have all "System" applications in one place. Also, I "had" to change the
default menu icon to the Salix icon.

Once again, like we did with the MATE 1.2 packages that we offered with
Salix 13.37 and the MATE 1.4 packages that we offered for Salix 14.0, we
are not building the complete set of MATE packages. We are building all
the "base" packages, that make up the actual MATE Desktop Environment,
like mate-desktop, the Caja file manager, the panel, panel applets etc,
but we are not including Pluma, the text editor, Eye of MATE, the
graphics viewer etc. This is only just because I think we already have
better alternatives for them and we wouldn't use them anyway. For
example Geany, our default text editor/IDE that is also part of the
default Xfce release is a much better editor than Pluma and Viewnior a
better viewer than Eye of MATE.

Once packages show up in the repositories, you should be able to
install the MATE desktop using:

Monday, 24 February 2014

We've been working on this for a while and were hoping to have it ready
by the time 14.1 is released and it seems that we managed to make it!
You can now find the new guide
linked from our main website.

The startup guide was left with no updates since the 13.37 release, so
it was getting a bit old. It was still mostly OK, but there were things
that were out of date.

Another thing that was getting in the way was the format that the guide
was written in. A tool called Publican was used to create the previous
guide, but newer versions of it seemed to only work in Debian (or was it
Fedora?). Anyway, it wouldn't work on Salix/Slackware anymore, so we had
to switch and convert everything to the new format. Once again, the
solution was to go with txt2tags.

So, we converted everything to the txt2tags format. From the txt2tags
format, we can acquire the equivalent in html output very easily. Then,
in turn, the html output is processed through
htmldoc to split it in multiple
pages and create a table of contents and a lot of sed magic is used to
apply css formatting to the output so it looks nice.

The upside of using txt2tags is that it's not only html output that it
can produce. Using the same source file, tex files can be created. These
can be processed throught TexLive to
create a pdf file. And since this is LaTeX we're talking about the
result looks absolutely professional. Still, some sed magic was needed
here too, in order to make fine changes, but after initial setup, pdf
generation is completely automated.

Producing ebooks is the next step. Creating epub and mobi files from the
html output is almost ready and these will also be available for
download soon. So, you could read the Salix Startup Guide in your
favourite ebook reader.

The only downside of using txt2tags like that, is that currently there
is no provision for translations. There is simply no way to do it in a
sane way. Truth is that translators put a lot of work in the previous
versions of the guide, but it seems that we won't be able to provide
localized versions of the guide anymore.

The guide may not be 100% ready yet, there might still be small issues that need taking care of, but we think that it's ready for public release as it is. If you find anything
that you may think needs fixing, please contact us through our mailing list.

Tuesday, 14 January 2014

I've had a few chats lately, either through email, in our forums and in
IRC about the kernels that we're including with our 32-bit releases and I
thought it would be best if I explained things a bit.

First of all, 32-bit Slackware ships with two different kernels. The
first one, which is the most used of the two is an i686 optimized,
PAE enabled,
SMP capable
kernel. The second one is an i486 optimized, non-PAE, non-SMP capable
kernel. The options with which these kernels have been built is a
decision made by Slackware and it is our policy that we don't change
major things like that.

While all previous 32-bit Salix releases included both kernels, since the Salix
Xfce 14.0 release, we do not ship the i486 kernel anymore for our "big
desktop" releases. That includes all Xfce, KDE and MATE releases (we
skipped the last one for 14.0, but that's another subject). And that's
the same thing that we're going to do for our 14.1 releases.

The reason for this is a simple one: size. The nature of software is to
grow and while the iso images for our first Salix Xfce 13.0 releases
was no more than 550MB, since 14.0, we are struggling to keep the size
within 700MB. And that's with keeping the software that is installed by
default the same, more or less. The 700MB limit is a very important one,
because it means that the
iso image can be burned to a CD-ROM disc. If we exceed that limit,
there are mainly two options, either burn and use a DVD-ROM or transfer
the image to a USB flash drive and install using that.

I'm only referring to our 32-bit releases, since anyone with a 64-bit
capable PC probably has a DVD-ROM drive anyway and certainly can boot
using a flash drive. So, I don't really care much if we exceed the limit
in our 64-bit releases. But a big portion of older PCs do not support
booting from USB and several of them do not have a DVD-ROM drive and our
32-bit releases need to cover for those.

Right now, the latest Salix Xfce 14.1beta1 32-bit iso image is exactly
702MB. That still fits into a CD-ROM disc, the actual limit being a bit
higher than that. But it only includes the i686 kernel. If we were to
add the i486 kernel as well, that would mean that the iso size would
increase by at least another 50MB. And that would definitely put it over
the CD-ROM size limit (yes, I know that 800MB CD-ROM discs exist, but they
were never that popular, mainly because there were never reliable).

So, we had to make a choice. Either we include the i486 kernel too and
require a DVD-ROM to burn and install the iso, or ditch it and keep it
within the CD-ROM size limit. We went with the latter.

Now, let's see which CPUs we are excluding exactly with that choice,
because there is a lot of misunderstanding going on about that.

A lot of
people seem to think that since the i686 kernel is an SMP capable
kernel, that immediately excludes all single core CPUs for some reason.
But SMP capable just means that the kernel can support multiple cores
(or motherboards with multiple CPUs) if it happens to find them and
there is no problem at all running such a kernel with a single core CPU.

Then of course there is the issue that the kernel is built for i686. All
CPUs that were manufactured after and including the Pentium Pro though,
support the i686 instruction set. And Pentium Pro was introduced in
1995. The only CPUs that are actually excluded by the architecture
choice are Pentium 1 chips (max 200MHz), i486 chips and compatibles (AMD
and Cyrix equivalents) from that era.

The most important issue is actually that the i686 kernel is built with
PAE support. Unfortunately that excludes all CPUs that do not support
PAE. But still, every CPU that has been manufactured after and including
the Pentium Pro supports PAE! The only exception being some Pentium
M CPUs, but still not all of those, only the ones with a 400MHz bus,
which were marketed using the term "Centrino". By the way, the Pentium M
is a CPU that came out in 2003.

So there you have it. The PCs that can't be used to install Salix
Xfce, KDE or MATE to, are ones that have an i486, a Pentium 1 or a
specific kind of Pentium M CPU, with the only really loss being those
few Pentium M PCs. I don't think anyone in their right minds would want
to use Xfce or KDE or MATE on an i486 or Pentium 1 PC. And really,
nobody would probably want to use KDE on a Pentium M PC either. Xfce and
MATE might work modestly, but for that CPU, faster and more spartan
alternatives exist.

If we had made a different choice and kept the i486 kernel, sure we
would be also covering all PCs with those CPUs as well. But then we
would be excluding most of them all over again, requiring a DVD-ROM
drive. And in the process we would be excluding all PCs that have a
better CPU but only a CD-ROM drive instead of a DVD-ROM drive and also
the people that have a bunch of CD-writable media they would want to
use. I'm fairly certain that this is a much more significant number of
people.

However, all is not lost even for those with those very old CPUs. As we
did with our Salix Ratpoison 14.0, release, all our "lighter desktop"
releases will also include the i486 kernel. That will certainly include
a Ratpoison release and maybe we'll come back to a Fluxbox or LXDE
release and I know someone is considering an Openbox release. We might
even have a core-only iso, we'll see. These will include both i486 and
i686 kernels simply because even if they do, the iso size stays well
within the 700MB limit.