Re: Most stable and tested distribution?

Robert Heller wrote:

Slackware basically has no package management (or a really
simple-minded one).

Its simplicity, actually, is what makes it so good. The assumption is
that the user meant what the user instructed the software to do.

There is not anything like apt-get or yum at all.

Exactly. Some would argue that's a point for Slackware.

You need to check each package *manually* for updates ...

Perhaps you should have checked *manually* whether what you were about
to write is true?

Slackware does produce updated packages for software shipped with each
of a number of recent versions of the distribution, to keep up with
security patches. Upgrades for the sake of upgrades, or to have all
the newest bugs (and a few new features) are saved for the next version
of the distribution, which doesn't get released until the distribution
maintainer is sure most of the bugs in the included software have been
worked out (but usually just in time for some new bugs to be discovered;
such is the nature of software development; that's also when update
packages are most likely to be released ...).

All the user needs to check, for Slackware package updates,
is the "patches" directory of his/her favorite (or nearest) Slackware
mirror FTP site. That's usually trivial to automate. See
http://www.therockgarden.ca/software/slackware/UPGRADE.sh for a simple
shell script that performs this task exactly, for example.

and you also need to *manually* deal with dependencies (basically you
rebuild from source and re-install).

See my points above. What you're describing is neither necessary,
nor the "normal" Slackware experience. However, if someone wanted to
upgrade a particular software package to a newer version than is included
in the distribution (s)he is using, yes compilation would be necessary.
The best way to accomplish this would be to use the same script that the
version included in the distribution was compiled with (these scripts
are available in the "source" directories of the distribution disk(s)).

In practice I find that if a package compiled with the distribution once,
a newer version of the same package will almost always compile with
the same distribution. A small number of exceptions might exist that
require upgrading some library first, but if you're going to this sort
of effort to have the latest greatest version of that software package,
shouldn't you take a little bit of time to read the docs and understand
the process anyway?

Also, you cannot even try to update Slackware, you can only do an
install.

Again, you are apparently misinformed. Perhaps the problem here is that
you might have had to *manually* *read* documentation included with the
distribution to know how to upgrade over an existing installation?

Yes, it can be done, and in fact, the process is normally not terribly
complicated. There just are some preparatory steps that usually need to
be undertaken, and these are clearly laid out in documentation included
with the newer version. That said, it's cleaner to perform a fresh
installation. That way you know that what's on your system is exactly
what shipped with the new version of the distribution, with nothing left
over from the old, but that's true of any Linux distribution.


On Wed, 6 Jan 2010 20:01:03 +0000 (UTC), Giorgos Tzampanakis followed-up:

This sounds like a lot of duplicated effort between Slackware
users. ...

Indeed. One would imagine that users faced with such duplicated effort
might cooperatively find better ways. The poster to whom you followed
up here seems to be quite mis-informed, and the scenario he paints does
not reflect the reality of using Slackware and upgrading software with
Slackware provided packages.

The cooperation I propose among users does exist over and above the
software updates available from Slackware itself, most notably in the form
of build scripts (and unofficial packages) for software not included with
the distribution, so that such software can ultimately be installed and
upgraded just as though it had been included. It's an excellent system,
in fact, and I heartily recommend you investigate it and evaluate whether
it would suit your needs.

See, for a subset of examples (anyone working with other examples,
feel free to add to this list):

http://connie.slackware.com/~alien/slackbuilds/
http://www.slackbuilds.org/
http://www.linuxpackages.net/
http://rlworkman.net/pkgs/
http://www.slacky.eu/

There are others, but I believe these are the better known ones (in no
particular order).

A central software update channel would be much better, even if it was
for the software less likely to break the system (anything except
hardware drivers, X, desktop environments, the kernel etc.)

Agreed, and for software that ships with the distribution, security
related patches are provided by Slackware itself for recent distribution
versions. Updates for new features go into the next distribution
version. It really is quite reasonable.

It certainly doesn't sound enticing, to me at least.

Unfortunately, this is how people tend to get misled about Slackware.
The distribution doesn't try to do things you didn't intend, out of the
box, and that seems to cause people to jump to false conclusions about
what is or isn't possible compared to other distributions that attempt
to know better than the user (which as you've seen, can lead to system
instability, and an overall poor user experience).

I've been using and administering systems running Slackware since 1996, at
home and at work, on workstations and servers, and I can honestly say that
the only instability any of my (Slackware) systems have experienced could
be traced directly back to an error on my part. I'd love to tell you it
never happened, but I have made some mistakes in the years since 1996.
At no time, however, did I upgrade a Slackware-supplied software package,
only to find the upgrade broke some functionality on my system(s).

Try Slackware. You'll wonder why you didn't try it sooner.

I hope this helps ...

--
----------------------------------------------------------------------
Sylvain Robitaille syl@xxxxxxxxxxxxxxxxx

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
.

Relevant Pages