Salix 14.2 Xfce — 2

Part 1: Salix 14.2 Xfce — 1

Unlike Slackware, the intended Salix package management tool is slapt-get and the GUI front-end gslapt. This is a significant difference from the parent Slackware. The native Slackware slackpkg gets most of the attention and discussion online, but through the years slapt-get and gslapt seem to hum along with the ride. While I remember ancient debates about which Slackware package manager to use, in all the years I have used Slackware I do not recall reading anything about slapt-get not working as expected.

A common complaint about Slackware is there is no pointy-clicky way to manage packages. The Salix folks resolve that complaint with gslapt. Even if their target users are lazy Slackers and not non technical users.

The Salix developers recommend not mixing slackpkg and slapt-get. That is, avoid using slackpkg. After years of using slackpkg that requires changing habits and learning new syntax. Fortunately, adapting is helped by the fact that slackpkg is not installed in Salix.

Despite the geeky name, notable is that glsapt is the only reasonable GUI package management tool for Slackware. Through the years I have wondered whether glsapt could be adapted to slackpkg. A GUI front-end to slackpkg would be nice. Probably a moot point because slackpkg does not support dependency checking and only supports the Slackware repositories. Additional third-party tools are required to move beyond those boundaries.

Salix is binary compatible with Slackware. That means Slackware users may use the Salix repositories for additional packages. Slackware users are not required to use slapt-get to use Salix packages, but a caveat with that option is not having a GUI package manager or dependency checking. That is possible only by moving to the slapt-get/gslapt territory. Not that a die-hard Slacker probably cares — many Slackers have grown accustomed to manually checking dependencies and administering their systems at the command line.

The lack of package dependencies long has been a contentious topic among Slackware users. Hence a common but misleading argument that Slackware does not have “package management.” My own view is simple. Tracking package dependencies when installing packages is convenient. Package dependencies should not influence what packages can be removed. This is a design element that long has frustrated me with many distros. Removing a single package often means other packages get removed too.

That Slackware is not officially designed to support package dependencies does not mean impossible. Several people through the years have offered such support. That the Salix folks have included this support is a welcomed touch. Installing a package should not be a geek creds torture test or Silverback chest thumping contest.

A common complaint about Slackware is the lack of binary packages outside the official Slackware release. A popular location most Slackers obtain additional packages is No binary packages are provided at Slackers are expected to use the build scripts to compile packages. Oh, and compile all dependencies too. To unfamiliar users this is a daunting challenge. While third-party tools such as sbopkg exist to help with compiling dependencies, there is still very much a high geek factor involved.

The Salix developers have plans to host binary copies of packages. This is an encouraging announcement.

Other third-party Slackware repositories exist. Binary packages are available too. The catch is without Yet Another Third-Party Command Line Tool such as slackpkg+, obtaining those binary packages requires sweat equity. While not explicitly discouraged, these additional repositories are not officially supported by the Salix developers.

A proverbial thorn in the side of most Linux based distro maintainers is installing non-free and proprietary codecs. The primary concern is the nonsense of patents and being sued. Many distro maintainers avoid the issue completely or “wash their hands” of the legal concerns while allowing users to choose. The Salix folks have chosen this latter option.

Unlike some other distro installers, Salix users must complete the distro installation before being able to install these codecs. An installer option would be nice, but I did not notice one during the installation. The task is a simple pointy-clicky operation, embedded in the panel Multimedia menu.

Selecting the menu option results in a Big Scary Warning about patent encumbered codecs. Selecting the Forward button installs the codecs, which nicely includes libdvdcss. After installing, the user is asked whether to remove the installer option from the Multimedia menu.

Some of the Salix default apps are interesting. Firefox, Thunderbird, LibreOffice, and GIMP are considered staples of the free/libre software world. Like the parent Slackware, the Extended Support Release (ESR) version of Firefox is provided. LibreOffice is not provided in the stock Slackware but is provided in Salix. Curiously, the Salix folks opt for Claws-Mail rather than Thunderbird. Because Salix is compatible with Slackware, installing Thunderbird from the Slackware repository is straightforward. While Thunderbird is hardly without warts and blemishes, I suspect this selection is a developer’s whim more than promoting what most users want or expect. Similar to disabling the root account or defaulting to xfs. Thankfully the world is plenty big enough to accommodate more than one opinion.

I was disappointed with printer support. The panel System menu Manage Printing option opens the web browser to the CUPS server web page. I thought this was lame. Okay, Salix is for lazy Slackers. I would prefer to use the system-config-printer tool. Considering all of the beneficial work providing GUI administration tools, I am surprised that system-config-printer is not used.

I did not try connecting to a printer. I will do that when I move my testing to a physical system on my LAN. I plan to test the system-config-printer tool. I have a network printer. Whether Salix will be able to discover the printer will be a nice test.

The Salix desktop shows a typical geek influence. This can be overlooked somewhat because the target users are lazy Slackers, who are presumed to be geeks or geek wannabes. The usual four virtual desktop work spaces are available, a terminal button in the panel, and a desktop icon for IRC — the geek's tool for tech support. The wiki contains the same geekness — rather than instruct users to use gslapt to install packages, users are told to use the command line.

I found one notable absence in the Salix repositories: gnome-games. With other distros I am accustomed to installing the gnome-games meta package. That is not possible with Salix. While many of the GNOME games are now influenced by GTK3 and possibly systemd, I expected to find at least some versions of the games.

Casually searching previous Salix release repositories, I found gnome-games 3.4.2 in the 14.0 release. Possibly the older versions no longer compile. A more hopeful answer is the developers simply no longer build the package.

Despite the absence of gnome-games, I found AisleRiot Solitaire in the repos. A rather recent version too, which might imply that other games can be compiled.

As the design goal is to create a focused desktop system, many stock Slackware packages are not installed. All of the missing stock packages are available in the repos. For example, nmap is not part of the default Salix installation but is part of the standard Slackware install.

The Salix developers offer a one-app-per-task distro. Designing a distro with such a goal creates a distro subject to developers’ preferences. Other packages are available after installation, but the default ISO is one app per task. The default ISO includes the following notable packages:

  • Firefox ESR
  • Claws Mail
  • Gigolo
  • Zim Desktop Wiki

Gigolo is an interesting name for software. The original author of the software explains the name, which some people do not like. C'est la vie. I wondered why such an app is included or deemed needed. The Thunar file manager supports a Browse Network option.

I am curious about the Zim Desktop Wiki app. I have a documentation project I want to start. I was planning to test the app along with cherrytree.

I was pleased to see geany installed as a default app.

The lack of GUI administration tools long has been a contributing reason many less technical users do not adopt Slackware. This collection of GUI administration tools could be sufficient to lure some non technical users or lazy technical users. If such GUI tools existed in the stock Slackware, even if in the /extra repository, perhaps Slackware would have a different reputation these days with the less technical crowd. That is unlikely to happen.

Salix includes some handy GUI administration tools. This is where Salix notably separates from the stock Slackware:

  • Dotnew, a tool to manage new /etc configuration files.
  • GTKRepoSetup, a GUI front-end to reposetup, which helps select a repository mirror.
  • GSlapt, a front-end to slapt-get, the package manager.
  • GUEFI, a boot manager for UEFI systems.
  • Hostnames, to configure the host name of the computer.
  • Keyboard Layout, to configure keyboard layouts.
  • Rebuild Icon Cache, to rebuild system icon caches.
  • System Clock, to configure the system time zone and time.
  • System Language, to configure system locale.
  • System Services, to configure system services scripts.
  • Users and Groups, to manage user and group accounts.
  • Salix-Update-Notifier, a notifier when system updates are available.
  • Sourcery, a front-end to slapt-src, which is used to build packages from slackbuild scripts.

All of the GUI admin tools use ncurses when run in a terminal or console. The tools are accessible only through the System menu and not through the Xfce Settings Manager. Partly I understand because some people view the Xfce Settings Manager as applying only to the desktop settings. Yet this is a good place to present the admin tools to GUI users. I prefer the approach of the MATE Control Center where there is a dedicated Administration section. I do not like the PC Linux OS (PCLOS) approach of two control centers. Perhaps another idea is similar to Windows by providing a single “Administration icon in Desktop Settings that opens a dialog containing the admin tools.

The Rebuild Icon Cache tool is interesting. Several years ago there was an online debate about various house keeping features launched in /etc/rc.d/rc.M. These tasks affected boot times. The Salix folks removed those tasks from rc.M. I have not investigated where these tasks have been relocated, but the existence of the Rebuild Icon Cache tool indicates that at least this task is launched manually.

Because of a past irritable quirk with the Xfce terminal and Midnight Commander (mc), I installed mc and launched the Xfce terminal. I opened multiple tabs and could not replicate the original shrinking terminal window bug. This one bug alone was sufficient to stop me from using Xfce. With the annoying behavior resolved, I am open to using Xfce rather than MATE. Unlike MATE, the Xfce terminal supports a persistent tab bar.

The Salix developers support the MATE desktop. That means I can replace Thunar with Caja for my file manager. A missing feature in Thunar is expandable folders in the file pane. I use this feature a lot.

Salix provides an update notifier. The notifier launches when starting the desktop. No icon appears in the system tray unless there are updates. The notifier does not check anything until 10 minutes after starting. The executable is a bash script and defaults to checking for updates every 2 hours. That interval is configurable in /etc/salix-update-notifier.conf, but the first initial check interval is not configurable. The notifier is only that — a notifier. When a user selects the notifier icon the notifier launches gslapt. This is different from the way update notifiers work in other distros, where the notifier is actually a minimal package installer.

Two hours is melodramatic. I long have used a daily cron job to check for updates. Once a day is sufficient.

While patterned after Debian Synaptic, gslapt contains fewer options. Updating is a three-step process. The user selects the Update button, selects the Mark All Upgrades button, and then selects the Execute button. Like Synaptic, merely launching gslapt requires an administrative password. I always preferred that running a package manager should not require permissions. Only the Execute option should require a password. Like Synaptic, gslapt is not pretty, but is functional. There is something to be said about function. Seems that many newer GUI software managers these days are more bling than functional, often hiding many packages from users. This silliness then forces users into a terminal to find those packages.

For grins I reduced my virtual machine allotted RAM to 64 MB. Salix booted. Performance was slow, but the system functioned. Other distros I have used refuse to boot or run with less than 144 MB of RAM.

More to follow.

Posted: Category: Usability Tagged: Salix, Slackware, Xfce

Next: Salix 14.2 Xfce — 3

Previous: Salix 14.2 Xfce — 1