Salix 14.2 Xfce — 1
Of the many mysteries and unfinished stories in my life, one is I have spent little time with Salix. Odd, considering the usability improvements added by the maintainers. Yes, there are only 24 hours in the day. I will use that as my reason for not testing Salix.
My primary goal is to find a standard desktop distro for all of my computers. Because I have used Slackware for many years, I intend my Salix testing to be meaningful and not a useless click-bait collection of installation screen shots.
Despite a nominal desire to remain abreast with how non Slackware distros function and are designed, I am not making that a hard criterion. As I update my current Slackware 14.1 systems to 14.2, seems that investigating Salix is a reasonable step in exploring desktop distros.
Onward and upward.
Salix is a Slackware derivative that is binary compatible with Slackware.
Target users are not non technical users. Target users are “lazy Slackers.” What is a lazy Slacker? I found no official definition — something the Salix developers might consider adding. There is an online description of the Slackware philosophy. The expression seems to imply that a lazy Slacker is somebody who likes the Slackware distro and design. Somebody who is not intimidated by the command line or getting hands dirty with a computer operating system. Do not expect lots of hand-holding, expect occasionally to provide sweat equity, expect the result to be Slackware. Throw in the usual RTFM. In other words, Salix targets geeks. Comparing Salix to Ubuntu is proverbial apples and oranges. Don’t go down that road with those expectations.
Salix provides notable features that the parent Slackware does not.
- GUI administration tools.
- Dependency checking when installing packages.
- An extended repository system.
- Tools to compile packages from slackbuild scripts.
In addition to the project web site, looking for project documentation finds a wiki, a blog, and a startup guide. There is a user forum.
The wiki contains many articles, but browsing the wiki hinted that some articles might be obsolete or outdated.
The Startup Guide suffers from a common geek perspective. There is a section for installing. A section for command line usage. A section for using the Ratpoison environment.
I worked in technical writing for many years. I appreciate the effort required to support documentation. Typically I suggest distinct guides. For example:
- Installation Guide
- Quick Start Guide
- User Guide
- Administrator Guide
For small projects, an Installation Guide could be merged with an Administrator Guide to create an Installation and Administrator Guide.
A user’s guide is for using the system. Obtaining and installing a distro is an administrative task, something that is performed once by most people. Focus the user’s guide toward using the system. Avoid cramming every topic into a single mega-manual.
Okay, the target audience is lazy Slackers, which seems to lean toward including installation and some administration tasks in a Startup Guide. Oddly, while there are occasional online references to this target audience, the Guide forgets to mention that goal.
Lazy Slackers are not interested in the few command line examples in the Guide. That kind of material is for non technical users, which lazy Slackers are not. Moreso, there are thousands of online command line tutorials for new Linux users. Despite the additional GUI tools provided in Salix, a command line section in a Startup Guide is odd.
Supporting several desktop environments complicates documentation. While the Guide mentions the supported desktop environments, containing only a section for Ratpoison is off target and should be a separate guide or a wiki article. Or the guide should be renamed to Startup Guide Ratpoison Edition. Or there should be sections for all supported environments. This is where individual guides become more practical.
A counter argument is each individual environment is already covered by the upstream project documentation. In that case a Startup Guide should point to those references.
Although I have yet to dig deep into Salix on a daily basis, I see potential in the design to reach beyond lazy Slackers. A focus beyond lazy Slackers would create a strong future foundation for documentation.
I hear the wolves howling. If I am experienced with documentation then I should participate and improve the Salix documentation. I am not yet using Salix daily. Perhaps if or when I do I will offer some help in documentation.
Time to give Salix Xfce 14.2 a spin.
I prefer to first test a distro in a virtual machine (VM). I started with a VirtualBox VM. I assigned 1 GB of RAM and a 16 GB dynamic disk.
A PAE enabled system is the default but is not required to boot the 32-bit version.
Curiously, Salix uses the stock Slackware huge kernel rather than the generic kernel with an initrd.
The Salix installer does not boot to the familiar Slackware screen, instead booting to a blue ncurses dialog.
Salix supports running the installer in several languages. Oddly, all of the languages options are in English. People who do not read English will struggle to select an appropriate language. Each language option should be in the native language.
The ncurses dialog heading is in English too. The heading does not remind the user which edition is being used. To avoid the English-only problem, the heading should look like “Salix 14.2 Xfce (32-bit)” without the words “Installation of.”
Installing Salix is much the same as installing Slackware with the familiar and well known text based ncurses interface. I have been around computers a long time. I don’t care whether an installer is graphical or text based. Neither type of installer irritates or excites me. Except when they are confusing.
With an unpartitioned disk, the Salix installer drops to the cfdisk partitioning tool. This is a nice gesture compared to the parent Slackware ISO. Nonetheless, users are expected to have some familiarity with partitioning. If this was a graphical installer then I presume the installer would drop to gparted.
Unlike the stock Slackware, the Salix default file system is xfs. I am no file system expert and do not play one on TV. I use xfs in my LAN server videos partition with large files. I prefer ext4 elsewhere with smaller files and smaller partitions. This setup has worked well for me for many years. I selected the ext4 option.
The installer asks the user whether to enable Num Lock. While the installer dialog explicitly references “on boot,” the dialog could provide more meaningful information. That is, enabling Num Lock through this dialog is specific to the console only and does not affect the X GUI desktop. Enabling Num Lock is not performed by installing the numlockx package but by enabling an /etc/rc.d/rc.numlock script. As the name implies, the numlockx package is for the X GUI desktop.
Curiously, the rc.numlock script is launched from the /etc/rc.d/rc.M script. The rc.numlock script should be launched in /etc/rc.d/rc.S. Booting to single user mode for maintenance does not eliminate a person's preference for using Num Lock.
I am a long-time Num Lock user. I appreciate this gesture. That said, the developers forgot to disable the annoying Hint: Num Lock on message presented at a console. One way to disable the irritating message is edit /etc/inittab and add the --nohints parameter to the agetty commands. The installer could be configured to modify inittab when the user agrees to enable console Num Lock. A sed one-liner would provide the magic.
sed -i 's|--noclear|--noclear --nohints|g' /etc/inittab
Similarly, the practice in all distro designs, including the stock Slackware, is to launch the preferred console font only in multi-user mode. Booting to single user mode does not change a person's preference to use a more comfortable console font. Salix suffers from this same flaw by launching the /etc/rc.d/rc.font script from within rc.M rather than rc.S.
The Slackware installer prompts the user to provide a root password but not create user accounts. Slackware users are expected to create user accounts on their own. The Salix installer prompts the user to create a user account only. The reason is the Salix developers disable the root account. Restoring the root account is easy to find on the Salix wiki. I find this specific design decision peculiar because the target users are lazy Slackers and not non technical users. I am unconvinced the sudo approach provides additional security, but for non technical users this design probably is conservatively sane. Yet lazy Slackers is the target audience, not non technical users. A congenial approach is during the installation ask the user whether the root account should be enabled. Dictating usage policies is not a great idea.
Like Slackware, Salix uses LILO rather than GRUB. Despite using Slackware for many years I never use LILO except in VM testing. I always have used GRUB because I find multi-booting a system easier with GRUB. That Salix uses LILO means I will need to manually configure GRUB when I install on a physical machine. Been there done that.
Installation is fast. I rebooted into a full system in about five minutes.
The Salix developers use a 5 second delay to boot LILO rather than the exasperating 2 minute delay in the stock Slackware.
While providing a sane LILO boot image, Salix does not use a boot splash. That is fine and dandy for me. I much prefer scrolling stdout to know when something fails. The boot output is color coded to improve readability. The color coding is performed by sourcing /etc/shell-colors, which is a container of escape codes.
The login manager is the GNOME 2 Display Manager (GDM). The theme selection looks fine. GDM 2 is the same core software used with the Linux Mint Display Manager (MDM). A nice feature is this display manager can be compiled without dependencies on systemd or PAM. I prefer to boot to a command line (init 3) rather than a graphical login (init 4), but using a simpler display manager without such dependencies is refreshing.
NetworkManager is installed and enabled as the default method to manage network connections. For the unaware that explains why, unlike the Slackware installer, the Salix installer does not prompt to configure the network. This makes sense because the design focus is a desktop and not a server or generic system. Not to worry if wanting to use a static IP addresses or not wanting to use NetworkManager. Open a terminal and run the traditional stock Slackware netconfig tool. Remember to disable the NetworkManager service to avoid conflicts.
After installing Salix 14.2 in a virtual machine (VM) I tried updating the system. Here I stubbed my toes. I waited almost an eternity to download the change log. The progress dialog showed bytes per second. I changed the repo and again waited forever. Something was awry.
A ping test to the ISP eventually succeeded but in a manner indicating there might be DNS resolution issues. Very slow. I again changed the repo. Same horrible slow results.
Because the installation was so fast, I reinstalled, thinking perhaps I had made a mistake. This time I chose a different default repository. Same slow connection speeds.
I had a hunch about the cause of the problem. I powered down the VM. I configured the VM to use the host machine for DNS queries.
vboxmanage modifyvm "Salix Xfce 14.2" --natdnshostresolver1 on
I booted the VM. I updated the system in only a few moments. The vboxmanage command resolved the slow connection speed. The problem is caused by a lack of a DHCP server on my LAN. I use static IP addresses. Curious though because I do not recall experiencing this before in a VM.
Virtualization is common these days. I wanted a full screen. With VirtualBox that requires installing the Guest Addition drivers. I wish all distro ISO images included the VirtualBox Guest Addition drivers or at least the kernel sources to help install the Guest Additions. The Salix developers provide neither. They provide wiki instructions. Testing Salix in a VirtualBox VM requires installing the kernel sources and the Guest Addition drivers.
I was testing with the direct installer version and not a Live ISO version of Salix. While I understand arguments against the overhead of virtualization support in a direct installer ISO, I ran a quick check of the Live ISO. I was disappointed to find the Live ISO does not support the Guest Additions. I realize Salix is a desktop distro and not a generic distro. Thus few people will be running Salix inside a VM. Yet pretesting a distro inside a VM is common these days. Distro hoppers who casually test Salix are unlikely to discover how to enable full screen resolution.
The stock Slackware installer defaults to installing the kernel sources. Restoring that option in the Salix installer should be easy.
Considering the Salix ISO does not fit on a CD, optical disk space is not a restriction. The kernel sources package is 87 MB. On my relatively slow broadband connection, that would add about 90 seconds to downloading the ISO. Most people who use VirtualBox usually have a copy of the Guest Additions ISO. Including at least the kernel sources would be a decent gesture. Yes, Salix targets lazy Slackers. Still, I would rather see better support here.
The kernel sources are needed by people who want to use the NVidia proprietary drivers or compile a virtualBox package. While there is a wiki article addressing the NVidia drivers, seems that installing the sources by default like the stock Slackware would make things a lot easier. Even for lazy Slackers.
More to follow.
Posted: Category: Usability Tagged: Salix, Slackware, Xfce
Next: Salix 14.2 Xfce — 2
Previous: Finding A New Desktop Distro