Slackware vs. Vectorlinux
 

I currently use Slackware and love it.
Recently I'v been playing with Vectorlinux.

Apart from the default window manager I didn't notice much of a difference. Now I've only played with VL for about 3 days now. Could someone who has used it longer tell me what the advantages/disadvantages of using VL over slackware are?

BTW the system specs for the machine running VL 4.3 are:
AMD XP 2800+
Asus A7V8X
1GB DDR Ram
80GB Seagate

Any thoughts?

Vector is alot lighter and optomized for newer hardware. Its compiled for i686 Machines and doesn't include alot of extra stuff. But pretty much there the same thing, with different package sets :).

I don't like the ascii Logos, and I didn't like the install. Everyone should use something similar to red hats way but through command line.

But I do think its better because you get later kernel, supermount, etc.

So you are saying that you think everyone needs their hand held by anaconda? :rolleyes:

LMAO............redhat should be shot and then hung for coming up with their RPM garbage..................Slacks way of using tarballs should be the "standard" of all distros...........

agreed.. Rpms suck. and SlackmeUp.. all im saying is that vectorlinux needs a 'back' button in their install ;) And I like how anaconda waits till the very end to start doing anything.

A 'back' button. . . I donno... I kinda like the idea of learning the hard way... you know, the whole measure twice -- cut once deal. I mean, RTFM has so much more meaning when it deals with something major like a system install.

I prefer Slackware on my system, but with older systems, i will install vector, then install slackware packages as needed

Can you explain why RPM's suck? I am mainly a Slack user, but I like the ease of package management a system that uses RPM has, especially if you use apt/synaptic or yum. The default package management tool in Slack does not check or resolve dependencies as far as I know.

Ever try expanding an RPM based system with RPMs not provided by the distro?
It's a headache.

In the end, sometimes you have to do as much or more work to get a random RPM working then a TGZ package made for slack. And that's just not acceptable for people who need to have the system do the work. Back when I was a n00b, (and to this day I'm still learning... as we all are) having RedHat Linux 7.1 install without a hic-up off the CDs was really sweet. But the first RPM I downloaded from a non Redhat source almost made me want to toss my computer out the window. So I guess that is the reason I don't like RPMs... it's two faced: almost the best system when the source is constant, and the gates to hell when you start mixing it up with packages found elsewhere.

My :twocents: ... things might be a bit different these days.. but that's just the way I feel.

I didn't like RPMs because I would get errors like:

Gaim079.mdk.rpm needs Gaim079.mdk.0.rpm to install

And I just started installing things from the source from there on. Now I only like to use tgz binary packages or ebuilds.

RPM based distros do not always put packages in the same directories or name packages in a similar fashion due to the fact that they prefer to do thingss in their own way, for example a KDE rpm from Mandrake will not work on Suse, because Suse puts KDE stuff in /opt and Mandrake in /usr. To make matters worse Mandrake splits packages into seperate library files, binary files and then development files, so if you tried to install a Mandrake rpm on lets say Fedora, you could be met with a lot of dependencies because the rpm is not desiigned for that system.

If you stick to rpms designed for your system, you usually have no problems with rpm or if you have any at all, there would only be minor ones. APT an YUM are particularly useful tools, fo resolving such dependencies.

I use Slack as my main distro of choice and I don't think the Slack packaging system is that superior to anything else thats out there due to the fact that it doesn't resolve dependencies and you may have to resort to third party apps like swaret.