|
|
Zenwalk 4.4.1 — Part 8
© Copyright Darrell Anderson.
The Zenwalk developers are accomplishing something important: making Slackware usable to the common person. Yes, I had an unusual time installing Zenwalk, but the primary reason was the newly imposed 15 partition limit. For whatever reason IDE drives are now treated as SCSI drives and my elaborate partition scheme ran afoul of that new method. Who made this decision and why I don’t know, and I disagree. This is a kernel decision, not a Zenwalk decision. After I grasped the new kernel limitation and overcame that particular hurdle, installing Zenwalk was relatively straightforward.
Zenwalk more or less worked as advertised. I have no significant complaints about Zenwalk. I suspect that had I decided to merely wipe my hard drive and perform a standard installation that my story would have been different.
Yet I am, as some people have said, fussy. I prefer the word meticulous. I tend to see both the trees and the forest. I am one of those people who can make a software developer’s life miserable because I see things developers usually do not. I also view software from a novice’s perspective. With that in mind, to me Zenwalk is incomplete. I mean this constructively. From following threads at the Zenwalk support forums, I see that mostly people who possess some computer experience are the main proponents of the distro. After all, Zenwalk is a Slackware derivative, which likely means that many or most Zenwalkers are former Slackers. I suspect a typical computer user could and would easily adapt to Zenwalk — preinstalled. I find this is true with most computer users. Most typical users can adapt to any operating system that is preinstalled. But Zenwalk, like just about every GNU/Linux distro, is not preinstalled. That changes the perspective about an operating system.
I am consolidating my Zenwalk improvement suggestions here rather than post several dozen threads at the Zenwalk support forum or require visitors to read all of my journal entries. I mean all of these suggestions to be constructive and not intended to be a statement about the current Zenwalk or the maintainers. All ideas suggested here are improvement suggestions and nothing more. More detailed information and explanations are available in my previous journal entries. Whether the Zenwalk developers agree with me or find these suggestions helpful is for them to decide.
Installation
- Although flaky hardware is not the responsibility of the Zenwalk maintainers, an appendix to the user manual would be helpful explaining how to run the installation through an ISO image. Better yet, provide a setup option to automatically mount an ISO image. This also would be useful for people with no CD drive.
- Along the same thought, additional text in the user manual would be helpful explaining how to use the option to install Zenwalk from a pre-mounted directory.
- Although flaky hardware is not the responsibility of the Zenwalk maintainers, an appendix to the user manual would be helpful explaining how to gracefully recover from a failed installation. There is a reason why a particular bumper sticker remains popular — things happen.
- The Zenwalk kernel is not compiled with the useful Alt-SysRq recovery option. This is a significant usability issue. Despite fan-boy claims about the stability of the Linux kernel or Linux-based operating systems, many times I have had to restart my computer from various system lock-up issues. Pressing Alt-SysRq-r-k-e-i-s-u-b has saved me many times. Please add this option when compiling the kernel.
- The initial installation screen should provide a better explanation that users with pata drives should use the sata kernel option. That description also should explain that the new kernel now treats all IDE drives as SCSI drives. This shift is confusing and needs better explanation on screen.
- I realize that compiling optional kernels is a lot of work, but people using older hardware, or basic home users, are not going to need RAID and multiple disk support in the kernel. Consider providing a simpler third kernel option. I know this can get complicated, but one or two additional kernel options would be helpful. Because of the internal goal of keeping the CD size to 400 MB, perhaps one idea is to post additional kernel options (and relative modules) on line as a package add-ons in the Zenwalk repository. Regardless, the Alt-SysRq recovery option should be enabled in all kernel options.
- Toggling to alternate consoles when running setup is not immediately available. A user needs to exit setup before obtaining access to the alternate consoles. These consoles should be available and active before setup begins to run.
- The initial Zenwalk README file should explain the new 15 partition limit associated with the 2.6.20 kernel. This is a kernel issue but end-users need to be forewarned.
- The setup script needs to scan the number of hard drive partitions and if there are more than 15, display a notice to the user that partitions beyond the 15 limit will not be used.
- The Swap section of startup should format the swap partition only if requested by the user. An existing swap partition is more than likely already formatted.
- The setup script should provide a reinstallation option. This is helpful not only for novice users but for experienced users who might reinstall software on a regular basis during testing. This reinstallation option should present a pick list from which a user selects the already known existing root partition. From that single piece of information, the setup script then can scan the /etc/fstab entries and automatically populate the Target list for installing. This would save much time and eliminate the potential for typing errors. There is way too much data at stake. I always have disliked this manual typing method of this portion of the Slackware/Zenwalk installation script.
- For those people who manually select Target partitions during the installation, a pick list should be provided — of both the existing partitions and a list of common file list mount points such as / (root), /boot, /home, /opt, /usr, /usr/local, /tmp, /var. The pick list should not display partitions beyond the new 15 partition limit. There should be no typing required except for those people who create unusual mount points. During that manual typing stage for unusual mount points, if the user tries to sneak in a partition beyond the 15 partition limit, the script returns an error message and asks the user to select again.
- The Target section of setup provides no option to correct mapping selections. The script displays the final list of mount point mappings, but provides no method to modify that list. People make typing mistakes and they need a way to back step to the target selection process. The only current option is to proceed forward or restart the entire setup procedure.
- The Zenwalk user manual needs a section explaining the manual Target selection process.
- I appreciate the strict “one tool, one task” philosophy and I do not question the maintainers right to select what they believe are appropriate tools. However, I believe the installation scripts should at least provide an option for GRUB users who are not going to install LILO. An option like Don’t install LILO, I use GRUB could add a boot option to the GRUB menu.lst. GRUB users will know how to later update or beautify the text, but at least the necessary information gets inserted.
- People with limited hardware are not going to possess more than two IDE ports. LILO (and possibly GRUB if later supported), should be configured to add the noprobe boot parameters to eliminate those kernel “error” messages. Such messages are distracting and disorienting.
- I realize that die-hard Slackers (and various strains of masochists and sadists) scream and bark at every available tree when anybody suggests graphical installers, but Zenwalk is not the stock Slackware. Zenwalk is intended to make Slackware more usable for the common person, not the die-hard Slacker. Let die-hard Slackers continue using the stock Slackware installer. I personally can survive just fine with the ncurses installer, but consider saying good-bye to ncurses and provide a modern graphical installer. Yes the ncurses installer is functional, but a graphical installer is going to better motivate curious users far more than ncurses. The installer should support a mouse because most typical users today, even if not understanding how a computer works, do understand basic point-and-click. And no, an ncurses installer supporting the GPM is not my idea of how to win popularity contests. A square mouse pointer? How 1980s. Many people see their computers as a tool or appliance, not a hobby or a toy. These people no more expect to tinker under a computer’s hood than most people expect to tinker under a car’s hood. They want — and rightly insist — upon point-and-click to get their computers to work. They have other things they want to do other than tinker with computers. Therefore the goal of any installer is not only function but ease-of-use and elegance too. Novice users must have peace of mind when they insert that installation CD.
- When converting to a graphical installer, which would support a mouse, be sure to design the installer such that people using a left-handed mouse need not revert to a right-handed mouse. Throughout computerdom, left-handed mouse users are always treated as second-class people. Because there are no context sensitive menus in such a program, simply enable both mouse buttons to serve as the selection button.
- With that all said about a graphical installer, if the improvements suggested here are implemented then as a transitional step the ncurses installer can become more pleasurable.
- Similarly, replace the scary command line cfdisk with gparted for those people who will be manually repartitioning their hard drives.
- New versions of any distro should never be released without also updating the user manual. The current user manual contains obsolete screen shots as well as obsolete text. The English version contains some French text. This is confusing to any novice user.
Post Installation
- Unlike the 2.4 series kernel, the 2.6 series kernel provides support for hotplugging and coldplugging. This is a noticeable difference from the current stock Slackware. But novices and people unfamiliar with the 2.6 kernel need some help in configuring the udev daemon. For example, on my aging hardware, I do not and never will possess many of the hardware options used today with modern hardware. A script or tool to help people automatically disable unnecessary hardware scans, without having to learn udev scripts and config files would be a great addition to Zenwalk. Error and warning messages, and delays in the boot process, of any kind, tend to upset end-users.
- Although the Zenwalk developers thankfully have fixed a long-standing stock Slackware bug in that a simple two-button mouse with a scroll wheel is correctly configured in xorg.conf (woo-hoo!), the setup selection options do not reflect anything that describes a two-button mouse with a scroll wheel. Update those descriptions such that end-users realize that scroll wheels are supported.
- The mouse configuration section in setup should ask whether to configure the graphical environment for a left-handed mouse. This shortcoming has always been frustrating for left-handed mouse users. Always.
- If the previous suggestion is not possible within the installation phase, then seriously consider some kind of Personalizer tool similar to the one used in KDE for first-time users. The Zenwalk installation does include an /etc/rc.d/rc.postinstall script, so there at least is a portal available to provide for a left-handed mouse and other configuration options.
- Much like the KDE Personalizer (which needs improvement too), users should be asked some basic questions about the Xfce interface. Yes, this is more of an Xfce issue than Zenwalk, but people with older hardware are not interested in having all the latest gadgetry and GUI effects enabled.
- Perhaps I failed to see the option, but when I was asked to create a new user account, the userconfig tool did not automatically create a group named the same as the user and did not automatically select that group as the user’s primary group. This should be fixed, or if that option exists, become more obvious.
- The userconfig tool should ask whether a home directory ought to be created rather than assuming to create one. People who run multiple distros might want to use existing /home directories and need only create the user and group accounts.
- I found the userconfig tool confusing with having to select the Back button. I realize the Zenwalk developers put a lot of serious work into this tool, but a better model is the KDE kuser tool. Often in the computer world an existing idea is already the better idea. There is no need to play the NIH (Not Invented Here) game. Being free software, just grab the kuser base code and then convert to the GTK environment.
- Although the Zenwalk video configuration tool correctly identified and configured my LCD monitor in xorg.conf (another woo-hoo!), an on-screen message would have provided me a calming effect. The stock Slackware never has done this correctly with my hardware and a simple informational message would have helped. An installation option to modify the xorg.conf Identifier sections would be nice too. Reading Samsung SyncMaster 712N is more comforting than “videoconfig.”
- Along with the previous suggestion, add an option asking the user the color bit-plane depth they want to use. The default is 24 bit-planes, but with older hardware users likely will want 15 or 16 bit-planes. Let the users decide without having to possess knowledge about manually editing xorg.conf.
- The default Zenwalk creates a $HOME/.Xresources file setting the default display size to 96 dpi. Many users who run 1280 x 1024 screens or higher prefer 120 dpi. This setting should be determined by the end-user when running the video configuration. Additionally, this setting likely is global to all users and should be set globally rather than in the user’s home directory. The startx serverargs section is a good global location for this option.
- Similarly, the font display should be set to the same resolution.
- The Zenwalk installation scripts do ask users the run level they want to boot Zenwalk, a much needed improvement over the stock Slackware which simply defaults to run level 3 and requires manual editing of /etc/inittab to modify that option. But the Zenwalk feature should go further. Why bother asking users this at all? I always configure my bootloader for both options. My default is run level 4 to use the graphical login manager. Yet in my bootloader options I always provide myself the option to boot into run level 3 should I encounter problems when I experiment. Dispense with asking users which run level they prefer and instead provide both options.
- In addition to the previous idea why not convert into a separate tool the section of the setup script that asks the user which run level they prefer to boot, much like xwmconfig or timeconfig? Then users at any time may modify their preferred run level and never edit the inittab file.
- Although the rc.numlock script is a great improvement over the stock Slackware (something I did long ago in my rc.local script), I would rather prefer seeing the kernel and X compiled to exclude that nonsense. When an end-user configures the BIOS to boot with NumLock enabled, that should be the end of the discussion, case closed. The kernel and X should never again manipulate this option. Period. To see how crazy this all is, boot the computer and watch the NumLock LED. The BIOS sets NumLock on, Linus then disables NumLock. The user, wanting NumLock on, enables the rc.numlock script. The LED is back on. Then the user starts the GUI. X disables NumLock and the LED is off. Then as the GUI preconfigures, and the GUI is configured to enable NumLock, the LED again pops on. Yet the silly saga continues. Try next swapping to a different user session. As the computer toggles to the new session, X disables NumLock. If the login manager supports the NumLock key, such as with the KDE KDM, the NumLock LED is popped back on. When that user logins in, X disables NumLock, and then the moment the GUI is preconfigured, NumLock is on again. Then, with two user sessions enabled, toggle between the two sessions. Between the login manager, X, and the user’s configuration selections, the NumLock LED is basically a damned marquee light. This is total nonsense. Strip the NumLock code from the kernel and X.
- There are at least two bugs in the netconfig tool. The tool is designed to require a domain name, something that is not required or needed on a standalone box or even in any small internal LAN. Second, the script always adds an ending period in the /etc/hosts file if no domain name is provided.
- Get rid of the obsolete stock Slackware cutesy of telling the root user that mail is available — especially when no command line mail tool is provided in Zenwalk. Move that message to some place new users will read the text without being bothered with this silly message. On my box I had to less /var/spool/mail/root to read the message. Put this message somewhere in the post installation scripts and then, in /etc/login.defs, disable mail checking (MAIL-CHECK-ENAB=no).
- The default Zenwalk method of configuring xinitrc files is to copy the master xinitrc.xfce to the user’s home directory. Not a bad idea, but Zenwalk is a “one tool, one task” operating environment, which means only Xfce is officially supported. Therefore the stock Slackware does this correctly in created a soft link from /etc/X11/xinit/xinitrc to /etc/X11/xinit/xinitrc.xfce. If end-users later want to add additional desktop environments they then can use xwmconfig to create an individual $HOME/.xinitrc file.
- I’m unsure whether the ssh-agent daemon should be run for all users from within the xinitrc script. That option should be something left for users in their local bash startup scripts. Perhaps a setup option should ask the end-user whether to install that option locally or globally.
- The netpkg tool is a significant step toward making Slackware package management more usable. Dependency checking has seldom been a significant Slackware issue because the people who create packages usually are very good at including all the needed dependencies. Seeing a dependency checking option available will calm many people, but the netpkg interface needs some attention. Not explained in the user manual, and not at all intuitive, after I selected a site mirror the dialog box just sat there. I did not know what to do. I expected the tool to automatically pop into the next sequence of events. When I selected the Close button, because I thought netpkg was broken, then the tool changed the interface to display packages. With that first screen, the Close button should be changed to Continue so that users have a clue what is happening. Or, the tool should automatically move into the next interface.
- The netpkg tool needs an option to allow downloading packages but not installing. If this option already exists then the option is not intuitive to me. This is important to people who manage networks and want only to download the packages to a central local repository, or to people who do not immediately want to install packages.
- Again, perhaps the options exist, but any time a program provides a graphical interface then users expect that same interface to provide the means to modify the underlying configuration. I saw no obvious way in netpkg to add mirrors via point-and-click or to modify the cache location, etc. I had to manually modify the underlying configuration file.
- The netpkg tool does not contain many mirrors located in North America (perhaps there are very few because Zenwalk is primarily a European distro). The only mirror provided in the list is terribly slow. Surprisingly, the mirror that worked best for me, download.zenwalk.org, is not in the pick list, but I later manually added that option and the downloads were much faster. Yes, I know that this consumes bandwidth at the local Zenwalk server, but the speeds I otherwise experienced were typical of a dial-up connection. No thanks.
- The netpkg tool could provide a better interface explaining which mirrors serve which purpose. For people who want to update security patches only, they want to connect to the current branch of the Zenwalk package tree. For third party software and add-ons they would select a different mirror. People who want to update to the bleeding edge of all software should see a different option. None of this is intuitively obvious.
- Overall I found netpkg way too slow to connect to any mirror. I do not understand why there is such a significant delay in connecting to a mirror, especially an HTTP mirror. In the end I gave up, rebooted to Slackware where I could run KGet.
Miscellaneous
- Because Zenwalk is packaged as a “one tool, one task” environment, dispense with installing the loadlin package. Loadlin is useful for people who need to boot GNU/Linux from within Windows, but are those people the target audience of Zenwalk? I don’t know, but loadlin should be installed only if the user wants to boot the box using the Windows bootloader.
- Zenwalk provides no support for an /etc/rc.d/rc.shutdown script. This is useful and should be available.
- In the rc.inet2 script is a an attempt to run all miscellaneous scripts in the rc.d directory tagged as executable but not otherwise run in any other startup script. A noble idea, but this effort caused weird display problems on my screen. Screen messages in those additional scripts displayed in a haphazard manner and garbled the login screen. This is because the scripts launched within rc.inet2 do not complete running until after the remainder of the main startup completed and some of my additional rc.d scripts contain screen messages. I disabled the ampersand for background running and then there were no more screen problems. But then I realized that every executable script was going to launch, including the rc.shutdown script. I therefore decided to avoid the entire problem by disabling that last section in rc.inet2 and run my miscellaneous rc.d scripts the old-fashioned way — from within rc.local and copying sections from the stock Slackware rc.inet2 script. Using the ampersand to run scripts in the background make sense for people booting into run level 4 who will only see the graphical login manager. But for people booting into run level 3, the discombobulated login screen is disorienting. Lastly, trying to run all additional rc.d scripts in such a global, no-questions-asked manner is potentially dangerous.
- Another rc.d script problem I encountered is that unlike the stock Slackware script, in the Zenwalk version of rc.M, system logging is started after the rc.inet1 script executes. I added some logging messages to the Zenwalk rc.inet1 script because I like being informed about what is happening. With the Zenwalk reversed order, however, the messages no longer output to the system logs but to the screen. I therefore moved the section starting the system logs to before running rc.inet1.
- The new X 7.x supports new features not supported in version 6.9. One of those features is AIGLX. Many modern video cards support this feature, but my aging cards do not, despite one card supporting direct rendering. This enabled feature causes a warning (WW) message in Xorg.0.log. Hardly destructive, of course, but all such messages are always a nuisance. I was able to disable the warning message by adding Option "AIGLX" "false" to the ServerLayout section.
- Running ldconfig and fc-cache when booting has long been a traditional sore spot for many Slackers. Are those options necessary? The installpkg and upgradepkg scripts automatically run ldconfig. Running fc-cache takes a long time the more fonts that are added to a system. Zenwalk does not come with any font installer package and that should be the correct time to run fc-cache, not when booting.
- I like the way the Zenwalk developers have added some color (and life) to the otherwise dull Slackware boot process(another woo-hoo!). But the developers currently use hard-coded escape sequences. Why not provide a human readable method as described here? I use a basic color scheme that does not overwhelm the user with a rainbow of colors and the color displayed is based upon the type of screen message appearing. The Zenwalk developers are welcome to grab my scripts and merge them into their system. As I state here at my web site, the scripts are considered free software.
- Along that same path, how about colorizing the boring login screen? I run a simple script to update my /etc/issue file and I use that file in my login display.
- But do not stop there. Provide additional color in the console, which again shows end-users that the developers care. Zenwalk already supports colored man pages, add some more professionalism.
- Unlike the stock Slackware, Zenwalk supports using an /etc/skel directory (another woo-hoo!). Zenwalk provides some nominal bash startup script support, but could do better with a full startup script package.
- For whatever reason, the Xfce Tips and Tricks and Fortune messages are not installed in my Zenwalk installation. Yet the menu option exists and this seems to be a standard Xfce feature.
- The GNU/Linux world seems overwhelmed with the NIH (Not Invented Here) syndrome and provides no standard X white mouse pointers. There is no need to provide this through themes, and many people do not like mouse pointers with drop-shadows. Please provide a simple white mouse pointer option.
- Speaking of mouse pointers, the default GTK pointer is disorienting. Yes, I know, Xfce and GNU/Linux are not Windows, but I nonetheless prefer the standard Windows mouse pointer collection. The drag pointer used to expand the size of a window, that silly and ugly right-angle metaphor, is disorienting. Provide a mouse pointer option that uses the standard double-arrow. I use such a white pointer in KDE.
- Zenwalk suffers from an old stock Slackware error message: stderr is not a tty where are you?. The solution to eliminate this message is here.
- I have long disliked the cryptic way startx must be used to run X on a display other than 0. I have created a basic setup so that users need only type startx at any console and the associated scripts are programmed to know which display to use. I’d like to see the Zenwalk developers refine and improve this idea.
- The default inittab is designed to interpret the Ctrl-Alt-Del keyboard sequence to perform a system reboot, but there is no similar way to perform a system shutdown. Yes, users can shut down a box from the command line, but I do not like that method because then my bash history is not updated. Updating .bash_history requires logging out. A Catch-22 problem. I have provided a Ctrl-Alt-End shutdown method here that I think should be absorbed into Zenwalk.
- In ‘nix systems, the Right Alt key traditionally has served as a grand modifier (AltGr function) key. Many people migrating from Windows are not accustomed to this configuration option. Many people do not need this configuration option and would like the Right Alt key to function exactly the same as the Left Alt key. They should have that option. When users are asked to select a keymap, at the top of the list should be an option to select a keymap with the Right Alt key mapped to the same as the Left Alt key. I have provided a method here to provide such a keymap. (Note: this keymap also includes the Ctrl-Alt-End shutdown sequence described in the previous paragraph.)
- Although eventually I discovered the gdmsetup tool to modify the GDM login and session manager, the tool provides no option to modify the login box text size. This was the only option I wanted to modify. I truly do not understand the modern obsession with tiny font sizes. I do not know if the lack of such a configuration option is a GNOME, Xfce, or Zenwalk issue, but on a 1280 x 1024 screen, common these days, the login box text size is simply too small.
I realize there is much to consider in this list and I do not intend to overwhelm the Zenwalk developers. The Zenwalk developers are on a path that dramatically improves the stock Slackware. All of the ideas mentioned here are provided in that spirit. More importantly, all of these ideas are usability improvements, which is what Zenwalk is about. I hope the Zenwalk developers read this list in a constructive way.
I like what the Zenwalk people are trying to do and I believe these ideas will help. Frankly, many of these ideas apply to all GNU/Linux operating systems and not just Zenwalk — including the stock Slackware.
Finis.
Next: Xfce and GTK
Table of Contents
|
|