|
|
||
Vector Linux — Part 1© Copyright Darrell Anderson. Recently I continued my investigation into derivative Slackware operating systems. My next choice after Zenwalk was Vector Linux. I had once before investigated Vector about four years ago. I was unimpressed then, but I knew less about GNU/Linux then than I do now and that version of Vector was several versions ago. Hopefully things would be much different this time around. I downloaded the 5.8-Gold ISO as well as the 5.8-SOHO Beta 2. The former version uses Xfce and the latter KDE. I was curious with the way Xfce might be implemented only in the sense that I might notice anything different from Zenwalk. I was curious about the SOHO edition because I wanted to see whether the focus issues I currently experience with Kate continue with KDE 3.5.6. I burned the CDs after downloading the ISOs. I also then copied the file tree from each ISO to my /home/public directory. I planned to install the systems from there because of my flaky and undependable CD drive on my test box. I also maintain a large 15 GB /home partition on my test box and I like having the entire file tree available on that box without having to mount ISO images. After adding a GRUB menu.lst option for installing Vector (which is not the same as a menu option to boot and run Vector), I rebooted my box. The kernel booted fine and loaded the setup script. Unfortunately, although installing Slackware and Zenwalk in this manner is straightforward, the Vector developers have eliminated that part in the installation process where the end-user can install from a manually selected external directory. Initially, everything I tried failed to coax setup to find my file tree. My plan to install from the hard drive stalled. I have done this several times with both the stock Slackware and Zenwalk. Not so with Vector. Every time I tried to run setup from my hard drive the script always stalled looking for the veclinux directory. Specifically the script was looking for the SETUP.CONF file within the veclinux directory. I verified the directory existed although as I merely copied the entire file tree from the ISO image I knew the directory existed. After studying the setup script, I decided that once the program loaded into RAM I could exit the script, edit to look for my relocated files in the known subdirectory path, and then restart setup. This all made sense to me but for whatever reason, I never succeeded. After surfing the web for clues, I began to wonder whether I could install directly from the ISO image. There is a script included with the distro called vinstall-iso. I’m no shell scripting expert and the best I could garnish from reviewing that script is the program installs the entire ISO image. I got the feeling the script is intended more for reinstalling Vector rather than any initial installation. The documentation for the script is scant and when I read that using the script was a “piece of cake,” I knew right then that the opposite was true. I never did figure out how or when to use that script. I knew I could use the CD I created. I also knew that about 10 minutes into the installation the CD drive would go belly up. I wanted to avoid that. Besides, I was already booting from my relocated file tree on my hard drive. The problem was that the setup script was not finding the file tree. I was beginning to get frustrated, but after much trial and error I succeeded. The trick was to install the ISO image to the root directory of any drive or partition. Likewise with the extracted file tree from the ISO. I had extracted the file tree to a subdirectory in my /home/public directory, much like any organized person would do. Similarly, my ISO image was located in a subdirectory called Vector, located on an external hard drive where I store all of my ISO images. Temporarily moving the ISO image to the root of the external hard drive file tree finally satisfied the setup script. This is an example of really crappy programming and nearsightedness. I believe the Vector developers have the right idea to install from the ISO image, something I want to see fully supported in the stock Slackware and Zenwalk. Why the developers limited the search pattern to the root directory is beyond me. Also, why did they modify that portion of the stock Slackware setup script where a user merely types a known external location? All of this left me cold. I think the Vector developers have tried to be too smart for their own good. They ought to restore that feature and when the user wants to install from an external directory, to avoid typing mistakes, use the pick list idea that they incorporated elsewhere. Any end-user who wants to install from a hard drive file tree or ISO image is going to know the location. Provide a pick list for the drive or partition, and then allow the same approach to select the correct subdirectory. When developers try to outguess end-users they usually cause more problems than they solve. This is an example. At least the stock Slackware and Zenwalk setup script succeed in this area very well. After I temporarily moved the ISO image to the root directory on my external hard drive, the installation finally moved forward. But I again I felt uneasy about Vector. The setup dialog box instructed me that that I had to have at least a 512 MB swap partition. That is nonsense and unacceptable. Any box with 256 MB of RAM needs almost no swap partition at all. Not that I cared with my test box because there my swap partition is 1 GB — just in case one day I want to venture into crazy things like remastering CDs. But that is my test box. On my primary box the swap partition is 256 MB, plenty large enough for the 256 MB of RAM installed. Yet had I been trying to install Vector on my primary box I would have had to quit right then and there. I next was estranged by the message that the partition I selected for the root partition would be reformatted and that I had no choice about the question. Well, I do have a choice — not installing at all. I understand the need to empty a partition before beginning an installation, but I did not like the tone of the message. This is my box and my rules apply. Not the other way around. I expect people from the Microsoft world to treat me and my box in this manner, but not people from the free software world. This is an attitude problem I do not take lightly. I almost stopped the installation right then and there. I also was feeling uneasy with the apparent attempt to create a more light-hearted installation process. The messages included in the dialog boxes are intended to alleviate some of the pressure of installing a new operating system, to create an air of jocularity, but the messages did not come across to me as light-hearted. Instead the messages seemed pompous and arrogant. I suspect that was never the intent of the developers and I do not want to stop them from having fun, but the tone of those messages left me feeling uneasy. I again ran into the nonsensical requirement to format the swap partition. Dammit, any box with an existing swap partition already has that partition formatted. Stop wasting my time formatting partitions that are already formatted. The stock Slackware does this and Zenwalk does this. They all need to stop this. They all at least should ask the user whether or not to format instead of just assuming. Finally, however, the Vector people got something right. Something I want to see in the stock Slackware and Zenwalk is a pick list method to select and map target partitions to the file tree. Such a process eliminates typing errors. That made me feel a little better about Vector. No sooner was I feeling better that I again was back to feeling uneasy. I was able to map my partition scheme using the pick list, but I was not allowed to map my /usr/local partition, where I store all of my personal scripts and programs not installed from a distro package. I use this approach because whenever I want to install or reinstall a distro, I never have to recreate that file system. Yet with Vector I was denied this option. I also was denied any opportunity to map the /boot directory to my dedicated boot partition. This is where I maintain my kernels and GRUB files. I know that afterward I easily can move those files to my boot partition and then modify the fstab accordingly, but at this point I was starting not to like Vector for denying me these options. I next selected the packages I wanted to install. Unlike the stock Slackware, the choices were few. Unlike the stock Slackware, many programs are accumulated into one package. Although during installation Zenwalk provides no option to select packages (they have no real need because of a “one tool, one task” philosophy), at least each package is unique and separate from all others. Basically the Vector approach is an all-or-none approach with various packages — very much like in the proprietary world. Vector was quickly losing appeal. The actual installation went quietly. Nothing dramatic happened for 20 minutes or so. After the files installed, there were several scripts that tried to help me configure my system. I found the effort disappointing, especially with configuring X. There was no noticeable auto detection or configuration of X and I was left with the impression that once again, like the stock Slackware, I was going to have to configure X manually. Still, Vector did make more of an effort to preconfigure my box than the stock Slackware. Because I use GRUB, I did not install LILO. For me that is no great effort — I merely boot into my Slackware installation, mount the Vector partitions, glean the necessary information, and update my GRUB menu.lst. That is what I proceeded to do when I rebooted. That is when I really lost my appeal for Vector. I could not boot into KDE. I stared at my monitor for a few seconds and then opened the .xsession-errors file hoping for a clue. There was only one line in the file but that was all I needed. The message was that xinit could not find startkde. WTF did Vector do? Without informing me, Vector had installed a nominal KDE directory to my /opt partition. When I selected my target partitions, I mapped /opt to its own partition. This is what I have long done with Slackware and recently, with Zenwalk. Never a problem. My first mystery was I did not understand why Vector installed any KDE files at all. This was not the SOHO edition. Additionally, as a Slackware derivative, the developers surely understand that people who test Vector are likely to include existing Slackware users, who likely already have KDE installed in the same /opt location. The Vector approach is very much like the proprietary world where they seem not to care about what else might be installed. Fortunately for me, however, was that I install KDE to my /opt partition by version number and then create a soft link to the version of KDE I want to use. Therefore, although Vector had installed a nominal KDE directory to my /opt directory, all that had happened was destroying my soft link. I renamed the new Vector KDE directory and then recreated my soft link. I then booted into Slackware as expected. But now I was a little perturbed. Had I not established this habit of soft linking to the KDE directory, Vector would have mingled files and made a nice mess of things. Yes, I could diff the directory with my backups, but that would have been time wasted. After booting into Slackware and KDE, I mounted the Vector partitions. I started Konqueror to take a look around. The first thing I notice is an initrd directory in the root file tree. There is a INFO text file there informing me that I do not need the directory if I am not booting with an initrd and a SCSI hard disk. I never recall seeing any such directory with either Slackware or Zenwalk. I do not recall that such a directory is part of the file system hierarchy standard. There also was a soft link in the root directory named common. The link was dead, however. Based upon where the link was pointed, I knew the link came from the Amarok package because the stock Slackware packages install Amarok with several of these links pointed to the wrong location (a harmless bug but a nuisance). Regardless, what was this link doing in the root directory? Next I wanted to edit fstab to remap the location of my /usr/local files located on a separate partition. When I investigated the stock Vector /usr/local, I discovered the directory filled with many files. Another WTF moment. The file system hierarchy standard specifically allocates the /usr/local tree as being reserved for the end-user, not for the vendor. Installing files in my /usr/local file tree is a huge no-no. Although I was glad the installation script prevented me from mapping a partition to the /usr/local tree, preventing me from doing so was wrong, But had I been able to perform that task, I would have had all of these new files intermingled with my /usr/local files. Being my test box I was not in any great predicament, and I could easily diff the directories with my backup files. Yet, now I was really mad with Vector. Quality control and consistency obviously is not a significant idea with the Vector people. At this point I exited KDE, shut down my box, and went to bed. Whether Vector remained on my box was something I would decide later. Finis. Next: Vector Linux — Part 2 |
||