Slackware 10.1: First Impressions

I installed Slackware 10.1 on elrohir over the last week. As I said before, it was mostly a normal ride, and Patrick Volkerding is to be commended for making such an excellent distro. However, I ran into two problems.

1. First I will tell you about the most annoying issues. For annoyances only, this got me some grey hairs and gnawing of teeth! When I first booted into Slackware, I realized that sound was no longer working. When I tried to set my mixer parameters with alsamixer, all I got was the message “no mixer params found”. What could I do?

Booting into XFCe4 gave me a hint: XFCe4’s mixer allowed for selecting among multiple sound cards. Sound card 0 was devoid of all mixer elements, but lo! Sound Card 1 was there, with all my old mixer elements. Thus, it was a matter of somewhat associating the main sound port with sound card 1, right? Not precisely… Sound Card 0 was identified as snd-via82xx-modem and my main card was identified as just snd-via82xx.

I was able to get sound working by making /dev/dsp a symlink to /dev/dsp1. KDE, however, gave me some trouble. aRts (the KDE sound server) kept crashing until I awkardly had to force directing sound to /dev/dsp1 using OSS (the old, legacy Linux system as opposed to the new, state-of-the-art ALSA system now in use) as the underlying sound system.

I was uncomfortable. Even with sound working, aRts would crash randomly; the mixer did not work, and definitely the situation was not to my liking. I tried everything I knew: I tampered with the /dev directory, used the alsaconf utility (which was not helpful here), and countless other hacks. But then I went into the #slackware channel of the network. I shared my problem in the channel, and soon one of the regulars, ka24, suggested I use lsmod and then to add the suspect modules to /etc/hotplug/blacklist. I did so, and after a reboot, that did the trick. Sounds now works like a German toaster again!

2. This other was much less annoying, but it worried me; and the problem was not exclusive with Slackware 10.1, but manifested itself with 10.0 as well, and the problem boy this time was

Slackware does not provide packages. That’s generally fine; the vanilla installer available at the website is good enough.The version I used in Slackware 10.0 was 1.1.2. This version gave me no installation problems. However, when I tried to upgrade either to 1.1.3 or (later) to 1.1.4, the farthest I could go in the install was to see the initial progress meter, and then the installer would always exit quietly. Thus, I was stuck with an version with known issues for use in my job; and is critical for it.

What could be the cause for such problematic behavior? I didn’t know. Perhaps the vanilla installers of versions 1.1.3 and 1.1.4 were compiled against libraries newer than those of Slackware 10.0, or incompatible with it. All in all, I was worried; future versions of the program were leaving me behind, and thus I refused to let the issue go. I filed Issue 39693 with; and if you see the report, you will notice that it even was closed once. I requested its re-opening, and supplied a stacktrace to help pinpoint the issue down. For many days, I had no luck.

When I first upgraded to Slackware 10.1 on elrohir, I had high hopes that the newer versions would work. Therefore, I was happy to learn that OO.o 1.1.4 installed and launched seamlessly right after my Slackware install. However, there was a problem. Some time at a later stage in my upgrade, while rebuilding my older configuration, invoking OO.o resulted invariably in a crash before program startup could be completed. I deleted everything related to OO.o, and tried to reinstall, but oops! now the installer showed the same problem as before in Slackware 10.0!

I was very disappointed in one way; but on the other, I had some clues. What I did after installing on the first time was installing some Bitstream fonts I got from a legacy Corel Draw! box I got. I installed almost all of my fonts under the Type 1 format, and I know that OO.o is picky with that format. So, I got an idea to test: First, I deleted all the AFM (Adobe Font Metrics) files in my Type 1 directory:

[root: /usr/local/share/fonts] # rm ./*.afm

Then, I rebuilt the AFM files with pf2afm:

[root: /usr/local/share/fonts] # for i in *.pfb; do pf2afm $i; done

With a fresh and home-made set of font metrics, I tried to install OO.o again, and guess what: It worked like a Swiss clock engine! I can enjoy OO.o 1.1.4 normally now, so I can say that the problem is solved.

However, the issue remains. Obviously, versions 1.1.3 and up chokes on some AFM files; but then, why is it that version 1.1.2 never had a problem? This is obviously a regression, and an issue of quality assurance that should be solved. Thankfully, we are working on it. I plan to submit my AFM font sets to OO.o on Monday so they could study the root of the problem.


  1. Only once do I recall having to do an AFM remake like that, and it was long ago on some RH installation. It’s also possible to find some fonts crash things themselves. It was far worse under StarOffice 5.x. It was very common to be forced to install all fonts locally to StarOffice, rebuild the AFMs internally so that SO wouldn’t choke on what worked fine for X. A solid, common standard with backward compatibility is just not something Linux/Unix does well in display issues, and most of all with fonts.

Leave a Comment

Your email address will not be published. Required fields are marked *

Bible verses brought to you by bVerse Convert and