This is a "good" review

[Kocil]

Well, sometimes bitter pill is better than sweet candy.
Take this. http://humanreadable.nfshost.com/journal/2006-027.htm

[Triarius Fidelis]

After browsing the Vector support forum I discern that the community there is tight-knit. This is hardly surprising. Visit any support forum and the people there are going to be embrace and be zealous for their distro of choice. Yet, my perception of Vector is that the distro is more of a hobbyist’s distro. That is fine, but I want something different.

I stopped reading there. 

[vector]

clueless in geek heaven..............ohwell
vec

[metvas]

I sent Darrell an email Thanking him for his opinions and asking him if a newbie would have any clue what his review was about? Let alone follow any of it. Newbies also have to be considered. Many new users are newbies, or close to it. I think we still "Rock ".
Regards
Darrell

[newt]

That article/review sucks balls - at least through page 1.

I want my 10 minutes back!!

[Toe]

Honestly, there's a few good tidbits in there (mostly on the first page), but a lot of it... um, yeah.

I also dislike the tendency to popularize the penguin and ignore the gnu symbol. GNU/Linux is more than just the kernel. Ideology plays a significant role in the free software movement and neglecting the gnu symbol is a poor decision.

My reply to that garbage is the same as to anyone else I've seen spouting it: You're absolutely right that your typical 'Linux' distro is more than just the kernel.  But it's also more than just GNU.  So unless you're also going to include all the non-GNU software you're using (you know, like X, or Apache?) in the name, get over yourself and stop propagating RMS's sad little quest to ride the marketing coattails of Linux.

I noticed that Vector had created a directory in my /home partition named backupsys. So that is where the Vector people decided to store backups without my permission. There also was a slapt-get directory located in /home/ftp/pub/veclinux, another directory I did not ask for. Lastly there was a /home/tmp directory with some files that never have existed on my system. Much like the Microsoft mentality, the Vector people assumed far too much with the liberties they could take with my file system structure.

OK, guys, we're supposed to be asking permission for every single directory we create/modify/touch.  Hop to it!

the scripts also use the old Red Hat method of posting an [OK] message on the screen as each test in the scripts is satisfied. Although informative, I find that this feedback mechanism renders the scripts slower.

Er, mind posting some benchmarks on that, friend?

The screen backdrop is artfully impressive to see, but with my aging hardware I disabled the wallpaper.
<snip>
Xfce is still Xfce and that means no system event sounds. I simply cannot adapt to not having any system event sounds.

The fact that this guy disables the wallpaper for 'performance' but can't live without a jingle on startup gives me a funny twitch.

[Triarius Fidelis]

Honestly, there's a few good tidbits in there (mostly on the first page), but a lot of it... um, yeah.

I also dislike the tendency to popularize the penguin and ignore the gnu symbol. GNU/Linux is more than just the kernel. Ideology plays a significant role in the free software movement and neglecting the gnu symbol is a poor decision.

My reply to that garbage is the same as to anyone else I've seen spouting it: You're absolutely right that your typical 'Linux' distro is more than just the kernel.  But it's also more than just GNU.  So unless you're also going to include all the non-GNU software you're using (you know, like X, or Apache?) in the name, get over yourself and stop propagating RMS's sad little quest to ride the marketing coattails of Linux.

I wouldn't say RMS is "sad". He's a brilliant, visionary (if sometimes misguided) man, and we owe something to him.

However, there was an acronym I saw frequently on c.o.l.advocacy that I liked: LGX (Linux/GNU/X).

I noticed that Vector had created a directory in my /home partition named backupsys. So that is where the Vector people decided to store backups without my permission. There also was a slapt-get directory located in /home/ftp/pub/veclinux, another directory I did not ask for. Lastly there was a /home/tmp directory with some files that never have existed on my system. Much like the Microsoft mentality, the Vector people assumed far too much with the liberties they could take with my file system structure.

OK, guys, we're supposed to be asking permission for every single directory we create/modify/touch.  Hop to it!

Well, the /home/ftp/pub/veclinux stuff is for slapt-get. I would imagine Windows, Mac, and RPM or Debian-based distros roll out something similar. (The location for VL is convenient in case you want to run ftpd.) So I don't see what the complaint is for.

the scripts also use the old Red Hat method of posting an [OK] message on the screen as each test in the scripts is satisfied. Although informative, I find that this feedback mechanism renders the scripts slower.

Er, mind posting some benchmarks on that, friend?

Granted, more complex shell scripts might slow startup down a teensy bit, but in itself, echoing a few colored characters to the terminal takes less time than a round of action in the ncurses-based game 'Tales of Middle Earth'.

System startup is not a luge race, people. Go make a sandwich already.

The screen backdrop is artfully impressive to see, but with my aging hardware I disabled the wallpaper.
<snip>
Xfce is still Xfce and that means no system event sounds. I simply cannot adapt to not having any system event sounds.

The fact that this guy disables the wallpaper for 'performance' but can't live without a jingle on startup gives me a funny twitch.

The only time a background ever causes a noticeable, persistent slowdown is when one has set a terminal emulator to 'translucent' mode. That may sometimes result in an annoying delay in line feeds and scrolling.

[Kocil]

Hey, come on.
The review is "different" than the rest.
I took some idea for improvement from it (and little from the candy ones, really).
Here are some:

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.

He is not a newbie, or ordinary tester. He knew what he was doing.

the Vector developers have eliminated that part in the installation process where
the end-user can install from a manually selected external directory.

Ok, we did eliminate this.

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, ....

Damn .. he is a hacker.
How many of us has done this before
Lesson to learn: Some users are genius, don't try to outsmart them.

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.

Ck ck ck ... he really-really dig deep.
Lesson to learn: Our documentation need upgrading !!!

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.

Well, I was the crappy programmer
To be honest I was thinking like him too, but I ignored it.
I did not implement the feature he talked about because:
- It is a lot of easier to just mount the media, then looking for the ISO / veclinux directory in the root
- the "dialog" program inside the isolinux installer does not support file open dialog (it is, but not so good)

Lesson to learn: don't be lazy. If your heart say it is crap, other people will. So fix it as far as you can.

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.

Yeah ... one compliment at last
AFAIK, no other distro can do this.

Code:

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.

See ... he gave a good suggestion.
Lesson: Always spare the hardway for the hardcore people

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.

That is true, for any common old box.
New boxes use /tmpfs, which requires some extra swap space.
And read somewhere, a database server asks for 2 MB swap.

Lesson to learn: He did not know, or ignored, that special systems really need special treatment.
So do we. Our installer was based on asumption that VL will be installed by ordinary people
on ordinary computers.
We will see that most of his problem was, because his system is not ordinary.
Read on ...

understand the need to empty a partition before beginning an installation, but I did not like the tone of the message.

Ok ok ... let's change the "no matter what" message.
Any suggestion ?

again ran into the nonsensical requirement to format the swap partition. Dammit, any box with an existing swap partition already has that partition formatted.

Well, room for improvement.
We tried to skip the swap file reformatting when it is already exist, but it was causing some problem.
We decided to "always reformat" the swap partition when we were testing VL Dynamite 5.x.
I remember vec said something like "I'm sure the system will be alright when the format swap dialog took a long time".
Right vec ?

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 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.

Quite a sophisticated system he had, didn't it ?

The actual installation went quietly. Nothing dramatic happened for 20 minutes or so

Hey ... maybe we can play some music while installing,
instead of the boring "running developers".
By the way, 20 minutes is quite long,
not to mention that he is installing from an ISO in the hard disk.
It would be take longer if he was installing from a CD.

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.

Dough ...., did I say his system is not ordinary ?

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.

We discussed this matter, didn't we.
So, who made that naughty packages ?

Yet, now I was really mad with Vector.
Quality control and consistency obviously is not a significant idea with the Vector people.

Any objection about this statement ?
I'm with him.

Lesson to learn :
This distro would not happened without the contribution of the community,
however, it is also hard to keep the consistency between many vectelopers.
I knew it when I was the chief of VL SOHO 5.0.
I received many contributed packages, some of them without the proper PREFIX,
CFLAGS, nor the description-pak (only the dafault made by checkinstall).
To check the consistency, I got to explore the package one by one (using mc).
That was a time consuming process, and when I found inconsistency,
most of the time I got to recompiled the package.

So for vectelopers, please follow the guidelines.
If we cannot maintain the consistency, we are no more than Slackware + www.linuxpackages.net.

[Triarius Fidelis]

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.

We discussed this matter, didn't we.
So, who made that naughty packages ?

Yet, now I was really mad with Vector.
Quality control and consistency obviously is not a significant idea with the Vector people.

Any objection about this statement ?
I'm with him.

Lesson to learn : This distro would not happened without the contribution of the community, however, it is also hard to keep the consistency between many vectelopers. I knew it when I was the chief of VL SOHO 5.0. I received many contributed packages, some of them without the proper PREFIX, CFLAGS, nor the description-pak (only the dafault made by checkinstall). To check the consistency, I got to explore the package one by one (using mc). That was a time consuming process, and when I found inconsistency, most of the time I got to recompiled the package.

So for vectelopers, please follow the guidelines.
If we cannot maintain the consistency, we are no more than Slackware + www.linuxpackages.net.

That has been my biggest, and to a large extent, my only complaint with this fine distribution. I've posted notes about package quality on several occasions, and it has improved significantly IMO.

Because M0E-lnx began the brilliant vpackager initiative (for which I wrote the improved backend  ), it has became significantly easier for the neophyte to create standards-compliant packages of good quality. Tack så mycket!

Remember, sorry looks behind; hope looks up.

[tomh38]

Okay, let me get this straight:  this guy writes a pretty negative review of Vector with some valid complaints for the developers, but also seems kind of in a bad mood because he couldn't install it his way because his CDROM drive is broken, which is about the equivalent to not having a floppy drive 12 years ago.

I, on the other hand, don't know Jack Schmidt about computers, really.  But I not only have VL installed and running on my own machine, but I've installed it on about 20 other computers for various people.  Of those twenty, I'm pretty sure at least ten are using VL (at home) exclusively.  Four or five are dual-booting, and the rest I don't know about.

You guys do what you need to do.  As far as I'm concerned, though, things are going very well.

Sorry for the interruption.  Continue now with your regularly scheduled broadcast.

[saulgoode]

The first half of part one was rather a painful read as the author described the great hardships forced upon him in finding a solution to installing from a harddrive. I tend not to be overly sympathetic toward those who dive into installing a distro using their own presuppositions and who fail to look at the files provided with a distribution. Admittedly, the documention for the 'vinstall*' scripts could be improved upon (especially considering that thecomments in the source code provides the best understanding) but those scripts also address special case needs and it is certainly acceptable that the automated, menu-based installer does not attempt to address those needs (though some mention of the alternative install methods should appear in the automated installer, if it does not already).

Instead, such flexibility in installation alternatives is better served by command-line scripting. This, of course, is just my opinion; but it would seem a good compromise to meeting the needs of both the novice and advanced users. I should like to see 'vinstall*' scripting enhanced in the future (e.g., network install), but not necessarily provided as options of the automated installer.

There is nothing wrong with Vector removing some of the options and flexibility of the Slackware installation process; indeed, many would consider this one of Vector's main benefits. FWIW, I personally prefer the SW approach (with its options for individual package selection) but I accept the VL unified install for what it is and recognize it for its benefits.

-------------

I agree with the author's comments about 512Mb of swap being unreasonably large. I am not sure why it is spec'd so high as I was able to use one a quarter that size (on a box with 64M of RAM). It has been mentioned in the forums a couple of times that if the LZW compression was performed at level "7" instead of "9", RAM requirements would be significantly reduced (with perhaps a 1-2% increase in final ISO size, if my calculations are correct). This should be investigated.

-------------

The author's criticisms of the "tone" of the VL installer's messages should be taken with an appropriately-sized grain of salt. I tend to share the author's preference is for less light-hearted messages, but the vast majority of reviews I have read cite the conversational tone of VL's installer messages as a refreshing change from other distros. Basically, this is a non-issue.

-------------

The comments about files being placed in /usr/local are spot on; this should not happen and steps should be taken to eradicate such offenses. The criticism about mounting a pre-existing /boot partition again falls under the category of the installer making some presumptions in order to simplify the task for the majority of users. Again, I don't see a driving need to support the special case of a user having a pre-existing /boot since (as the author admits), the problem is easily rectified after installation by a knowledgable user.

-------------

Apparently the author had some difficulty getting his X Window System up and running. That is a shame and for anyone having such problems I would recommend helping the Vector developers in trying to resolve it. I haven't ever experienced difficulty with VL setting up X (or with most other distros, for that matter). Without further details from the author, little can be done about this criticism.

-------------

From the author's comments about KDE and /opt, I gather he holds the expectation that one distribution's and another's applications should be able to co-exist in a single, shared filesystem; with either distro able to execute the same binary and configuration. That is a fine ideal but I don't see as it is a worthy ambition for any particular distro to have. Maybe I am missing the author's point but I see nothing misguided in the Vector developers presuming that their /opt directory contains applications specific to their distribution.

-------------

I will skip over some of the minor (IMO, anyway) points such as the performance hits of echoing "[ok]" to the terminal (and the author's desire for a different grouping of packages) to address the following:

I noticed that Vector had created a directory in my /home partition named backupsys. So that is where the Vector people decided to store backups without my permission. There also was a slapt-get directory located in /home/ftp/pub/veclinux, another directory I did not ask for. Lastly there was a /home/tmp directory with some files that never have existed on my system. Much like the Microsoft mentality, the Vector people assumed far too much with the liberties they could take with my file system structure.

Creating a backupsys user for the sole purpose of guarding against loss of your system seems to me to be a quite reasonable approach and in keeping with the general Unix philosophy of dividing resources based upon tasks. I seem to recall being asked whether I wanted the system to be backed up (if not, perhaps that query should be considered for addition) but even if I was not, it is the prerogative of a distro (or even Microsoft, OMGasp) to implement a maintenance methodology if it deems that a desirable feature to offer.

Personally, I ignore the backupsys because I haven't taken the time to learn how it functions (I avoid blindly trusting other people's implementation of mission-critical functionality). I should think that, given the article author's other proclivities, he would find the VL approach greatly preferable to one in which the backupsys data became a more integral part the HFS.

Likewise, the employment of '/home/ftp/pub/veclinux' falls within the guidelines for the Unix approach for system maintenance. In fact, it follows quite closely the Slackware defaults for local mirrors -- though a more technical interpretation of the SW convention would suggest the location '/home/ftp/pub/Linux/veclinux'.

There is nothing onerous about Vector Linux developers choices in either of these cases; they fall well within the philosophy of Unix, the guidelines of Linux FHS, and the conventions of Slackware mirroring. The authors indignation here is quite misplaced.

---------------

In conclusion, I don't think the author's review should be dismisse out-of-hand; indeed, he makes a few valid points which need to be addressed. Though I think he expresses himself poorly at times and has some of his own misconceptions of "proper" system implementation, his effort in reviewing Vector should be respected and his points given consideration.

I don't feel his labelling of Vector as a "hobbyist" distribution is at all accurate; at least not from the standpoint of the user. A hobbyist distribution would be one that caters to a specific audience such as HAM radio operators, book collectors, et cetera. I fail to see Vector's appeal as being so selective.

If the author intended to convey the sense of VL being "amateur", there is some truth to that; and Vector should strive to improve in this regard. However, I don't think the author did a very good job supporting this claim; other than the valid comments about /usr/local, most of his complaints focused on his own expectations of support for his own (non-standard) needs.

I do think there is room for Vector to improve with regards to becoming less "amateur" -- I have my own concerns with some of the fragmentation in approach to system maintenance that is cropping up (installer being programmed in GAMBAS, VASM2 in Perl, Vpackager in Python). I recognize that Vector is a volunteer effort and realize the constraints that places on development efforts.

Like for the author of the article, the goals of Vector aren't a particularly good match for my own needs (and I try to temper my posts here in the forums accordingly) but I do see Vector as a great distribution for many others. Vector is not my distro of choice (Slackware is my main machine) but it is the first distro which I would recommend to most others. 

[blurymind]

this review is pretty gloomy.
everybody today is a critic.

[MikeCindi]

I haven't read the writing and probably won't as anyone can state what they think should be right with a distro they don't use. From the posts and quotes in this thread it would seem that the author would prefer to place each file where he wants it and all should work as his mind thinks it. As some have commented, he has valid criticisms...based on what standard? Slackware? Is VL now to become just Slack repackaged? The assumption is absurd. Uniformity within VL is appropriate but uniformity of VL within Slack is not (otherwise just use Slackware). And why complain because he has bad hardware? If it takes 20 minutes to load from the iso then he has old, slow, bad hardware at that. I have loaded from the CD (5.8 std Gold) on a PIII 500MHz 256Mb RAM machine in about 20 minutes reboot (start) to reboot (finish). (I did pre-partition with GParted though). Of course the CD-ROM works on that machine! I would agree that 512Mb swap is probably not necessary but disk space is cheap if you would want to use that much. If you want to suspend to disk and have 1 Gb RAM then you need twice that much (or you can use another predetermined area of your disk that would otherwise be unused). Thus, the author's personal needs are not what VL is about. Perhaps being able to customize to those specs would prompt him to create his own distro as I doubt any other would allow everything he expects either.

[Joe1962]

You pretty much hit the nail on the head, mikecindi. It's obvious he wants everything his own way, so there's probably no distro for him, except maybe LFS. This makes the tone of the comments regarding VL very incisive and unwarranted. Also, one minute the writer comes across as very knowledgeable and the next as completely clueless...

[lagagnon]

everybody today is a critic.

Exactly. It is very easy for today's human mind to critisize. Critisism is an easy thing to do for most humans. What is much harder to do is to come up with solutions to problems. Most take the easy way out. When I was in a management position for a short time I made it a policy that any staff member could criticize to their heart's content, but for each critisism aired they would have to have two potential solutions to contribute.