Slashdot Mirror
Vector Linux 4 Reviewed
SilentBob4 writes "On October 7th, the developers at Vector Linux released the latest version of their lightweight Linux distro, version 4. Vector has always been built upon the Slackware Linux framework and this time around it is based on Slack 9.0. The interesting thing here is that there was quite a delay between releases from the Vector camp, so as they were readying version 4, Pat Volkerding was releasing version 9.1 of his Slackware distro.
This past Friday, the first review of Vector Linux was released (Distrowatch.com posted a link to it today). It was a pretty good review for the most part, but the interesting thing about it was that they actually benchmarked it against Slackware 9.1 and posted the results. I'll spoil the ending right now and tell you that Vector Linux won, but you should check out the findings. There are some pretty interesting numbers obtained from the two distros. The reviewer has published three PDF documents detailing the results. Everything was tested from the kernel to filesystem performance. It is interesting to say the least. Even if you don't have to time to read the whole article (it's two pages long), do check out the benchmark results. "
Performace won't matter much, except for self-compile distros, where you can get about 10% better performance. But it is a bit silly, on any distro the kernel is easy to compile and so are any applications you really use (database, webserver). But I don't see the point in making vi run 10% faster...
Well, the issue is that different distrobutions include different sets of tools. Some, for example, include many more daemons (think apache, mysql, etc) and turn them on by default. Also, there will be a noticible difference between Gentoo built for Athlon versus Gentoo built for i386, for example. Similarly, the default build instructions are different for different distros. You might download a Redhat ISO targetted for the i586 (pentium) or perhaps Mandrake targetted at i686. So in those cases, often, it would matter.
====
Crudely Drawn Games
Quite easily if you use them as they come out of the box.
I'll probably get flamed for saying this, but in the past when I played around with RedHat and Mandrake before going back to Slackware, I noticed a general sluggishness about those distros.
Most of that got fixed when I rebuilt the kernel my own way, but other aspects such as slow init loading never got fixed until I threw those distros out.
I haven't been able to read the article yet, since it is presumably slashdotted, but I would have thought most benchmarks against Slackware 9.1 would be irrelevant, since the majority of Slackware heads compile their own apps and kernels. In other words, it makes more sense to compare it against Slack in a way that the latter might be assumed to be implemented. Yes, I know that's hard, since Slackware fans tend to be an individualistic lot, but that's too bad.
And yes, I know Gentoo does that, but Slackware gives you a system that works so that you can compile stuff at your leisure, rather than having to leave a machine out of action for hours/days while everything gets built.
If you take a typical redhat kernel, it has support for AMD and Intel both built in,SSE2 and MMX are both on etc., meaning it is not optimised for either.It also enables a lot of stuff like i2c bus support on, which is useful for servers etc. Then there are stuff like patches for faster GUI response etc. which can be added to improve apparent speed. Modules being built in versus loaded matters a lot too.This is for the kernel.
When it comes to tools, there are so many tools available in the typical GNU stuff that choosing a different one can change performance for different stuff. A change in init can increase bootp speed, since this distro is based on another distro here this would not matter. What they probably did is to change a few package options to tweak the speed.For webserver performance you can tweak Apache (this ofcourse depends on knowing your typical load etc.).
Certainly there cant be a significant speed increase between distros, but if you know what you want, then you can compile your packages and set options well enough on YOUR system and get a significant boost.
.ACMD setaloiv siht gnidaeR
It also enables a lot of stuff like i2c bus support on, which is useful for servers etc.
I2C is useful for your home computer, too. SMBus is an I2C bus, which is the temperature/fan speed monitoring/health status information bus for your PC. DDC2 (How your video card gets information from your monitor) is implemented with an I2C bus on your video card.
Here ends the pedentry concerning I2C.
Well, we all know that most of the distros *can* be configured to run on older machines -- if you change all the defaults to load programs and interfaces running with lower memory requirements. Slack and Debian are probably the best for tis task.
But if you're looking for something designed for older PC's "out of the box" then Deli, Damn Small Linux, or most of the other live CD distributions designed for business card CD's will also work, since they're all designed for small memory footprints, which is probably the main constraint on older systems.
Deli, in particular, makes the interesting choice of using the 2.2.25 kernel, which should be good for older machines.
Maybe Morphix Linux is what you are looking for. It has a "base" system and then you could add "modules". there are some modules ready for download or you could download an ISO with some modules installed.
DNA in your Linux: DNALinux
Actually, it comes on the disc but not installed by default :) Its a TGZ package
Somewhat OT, but the idea of a toned down but still functional Linux appeals to me. I had a similar idea of doing this to a distro not well known for being slim -- RedHat 9. For partially philosophical reasons, and partly because I was not getting any work done with all the gizmos cluttering my desktop, I decided to remove the clutter but not lose any functionality. (In my defense, I'm comfortable with Debian and some embedded, minimal distros and have built a Linux from the kernel sources to X).
./configure options carefully to minimize memory usage.
The hardware for this ongoing project is a 333MhZ PII laptop, 192M. I started by getting rid of the Gnome and KDE environments (well, most of it -- I kept the libraries and some select applications around). In their place I put in Fluxbox, choosing
Next, because I spend the majority of my time in the shell, I looked at some of the different xterms around. I was surprised that the native xterm, though much smaller than konsole or gnome-terminal, was still somewhat bloated in comparison with others such as aterm or rxvt. They didn't support transparent terminals but that's no biggie. The important thing was that they could do green-on-black terminals; also no biggie, but I was thinking about this because I made an assumption that a black background would use less battery than a white one. Of course, you could also ditch X entirely and run from a console but browsing the web in elinks or links, though great for documentation, kinda sucks for looking at Dolphin cheerleaders.
Next, I exchanged the stock RedHat kernel with a 2.6.0-test kernel (test9 at this writing). It does seem a lot faster, but I am still working out some module loading issues so there is some functional loss until I get these working. This is important because the goal is not to lose functionality for performance.
I've been testing different journaling modes for the ext3 filesystem. No benchmarks yet, but I understand that there's a decent performance boost to be had from using a different writeback mode.
These are all in addition to the standard tweaks such as using a lower bit depth on the X session, replacing apps with slimmer alternatives (Firebird for Mozilla, etc.). There are also dubious claims of speedups by just recompiling but in my case these gains weren't perceptible.
I'm about to replace syslog with one that batches writes. This will allow the drives to spin down. Since power management is otherwise functional it might gain some performance.
What is cooler than the local building about Gentoo is that I find portage personally easier to use than apt, and Gentoo's init & rc setup is IMO just awesome.
You don't have to stick to your distros init & rc setup. You could even make "init" a bash script containing functions for every runlevel, and have it call the appropriate one, based on the parameters passed.
Personally, I use just 3 bootscripts, one to start, one to stop, and one to enter multi user mode. For me, the best distro is the one that has the least amount of bloat to whine about me changing things around.
I use Crux, a much more user-managed distribution than Gentoo, and have taken out devfs, hacked the init scripts, hacked the ports tree to my liking, etc. Using Gentoo from Crux is honestly like moving from a manual transmission to an automatic (something I'll never, ever do.
I like ports trees that are easy to hack, not done for you (there are always times when you really want ports to behave differently than the official tree).
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
I've easily got 10% performance improvement from compile-it-yourself distros (LFS and gentoo are the two I run here) for a number of reasons:
--- Hot Shot City is particularly good.