Re: Considering Debian (currently using Red Hat)
On Wed, Jan 14, 2004 at 09:55:04PM -0600, Rod Rodolico wrote:
> > 2.) A related reason we used Red Hat was that practically anything you
> > could want to use was pre-packaged in a simple to install RPM. And they
> > were typically pretty high quality RPM's, and very often well maintained.
> > Do admins typically find that they're able to find Debian packages for most
> > software they're typically interested in using? I realise this varries
> > greatly between markets, but I guess what I'm asking is do you usually find
> > 70% of the packages you're interested in in Debian package format, and well
> > maintained? 80%? Just a general idea.
for me, well over 95%.
> I run a small IPP. I believe, there is only one package I use that is not
> available via Debian, RT from bestpractical.com (it may be there, but I
> haven't found it).
RT has been in debian for some time. in stable, the package was 'webrt',
the latest 'unstable' has RT1 and RT3 packages:
Package: request-tracker1
Replaces: webrt
Provides: webrt, request-tracker
Package: request-tracker3
Replaces: request-tracker
there is a backport of RT3 for woody at:
deb http://people.debian.org/~sjq/debian woody rt3
> I do not recall any other packages I use that are not available from the
> standard distro.
i occasionally need a perl CPAN module which is not packaged yet. dh-make-perl
makes it trivially easy to quickly generate a package which is good enough for
local usage (albeit not "polished" enough for uploading to debian).
dh-make-perl is an excellent tool.
> > 5.) Of course we'll be testing it extensively ourselves, but what would
> > you say the most significant differences, both from a user and an admin
> > perspective, are between Debian and <Brand X> Linux? Or, maybe better
> > stated, why Debian? I know that's a religeously charged question, but at
> > the moment our only position is "not RHL." We're open to being converted
> > ;-)
IMO, the number one benefit of debian is consistency. debian is a *system*
rather than a random collection of mis-matched parts. debian policies define
where things belong and how certain tasks (e.g. lockfiles and syslog
facilities) should be done.
so, debian is a distribution with all config files in /etc, all binaries have
man-pages, all packages are documented in /usr/share/doc/PACKAGE, all mail
programs use the *SAME* locking mechanism (which means that mbox spools do not
get corrupted) and the same syslog facility ("mail" rather than some using
"mail", some using "daemon", some using "local") and so on.
the syslog stuff is very useful, it results in logging being split properly
according to type in /var/log - which is far better than just dumping
everything into 'messages' or 'syslog'. read about mail stuff in mail.log,
read about mail errors in mail.err, news stuff in news.log, miscellaneous
daemons in daemon.log, kernel stuff in kern.log, and so on.
consistency is such a small, simple thing but the effects spread throughout
every part of the debian system, making it a real pleasure to work with.
> From an admin perspective: Again, I use Debian because it is stable. I don't,
> like many, use it for a workstation. I use SuSE or Mandrake or something.
> But, I don't want to mess with my servers, especially since some of them are
> across town in a NOC. I am an anal retentive control freak, so I do my
> security updates manually instead of scripting it in, but I have never had an
> upgrade problem with stable. My personal opinion is that RH is the
> equivilent or unstable or testing (haven't decided yet, and that may be too
> harsh). I've maintained RH servers, and don't like them.
that's way too harsh. unstable is far better quality than RH. i've been using
unstable on all of my servers (dozens of them) for years, since 1995. i've
rarely had an upgrade-related problem. i've only twice ever had an upgrade
problem that took me longer than 10 minutes to fix.
one of my reasons for using 'unstable' rather than 'stable' is that it is, IMO,
the best way to keep ahead of the script-kiddies. most of the exploits that
appear are for versions of software that i upgraded 6 or more months before.
in my experience, upgrading to the latest 'unstable' regularly and often is
less hassle than only upgrading to the new 'stable' every year or two. the
main reason for this is that a smaller number of packages are upgraded at one
time, so if there are problems you only have a few things to deal with rather
than potentially hundreds. also, practice makes perfect - the more often you
upgrade, the easier it will be.
NOTE: there are two caveats to using 'unstable' on production servers:
1. you have to know what you are doing. this is not for novices (unless
that novice wants a high-pressure course in becoming expert very
quickly. not a good idea)
2. you *MUST* test all upgrades on unimportant machines first. upgrade your
workstation first, then all machines in order from least important
to most important. by the time you get to the important machines,
you will know all the little quirks (if any) of the upgrade and know
exactly what to do about them.
btw, many of my servers are remotely located too. many of them are hundreds of
kilometres away, proxy/mail/web/etc servers for libraries in small towns across
the State of Victoria. i upgrade them by script - do the first one or two by
hand, then write a small script to upgrade the rest of them automaticaly.
> From a user perspective: Unless you enjoy tinkering, don't mess with it for a
> workstation. I rebuild workstations on a regular basis, so I don't mind the
> other releases that have problems every once-in-a-while.
i would have to disagree with that. i use debian for all my workstations, and
couldn't imagine using anything else. i want my workstations to work as well
and as reliably as my servers. i want the same consistency and quality as my
servers.
just as importantly, i want the same environment on my workstations as on my
servers. this allows the workstations to serve the dual-purpose of being
testing and development machines for the servers. develop and test on a
workstation, cut over to a server when it's ready.
and i want my assistant sysadmins and other staff learning the debian
environment rather than becoming expert in RH or Mandrake or SuSE or whatever
because i want their skills to be directly relevant to our servers.
apart from that, debian *just works*, even as a workstation. i've installed it
on dozens of workstations, desktops & laptops, with all manner of video cards,
mice, and strange devices. most of them just worked out of the box. some
required some fiddling with the config.
> I just want the installer to autodetect all my hardware, and give me the
> latest versions of X, JBuilder, Perl, Quanta, Bluefish and bzFlag. So, for
> me, Debian is not what I use in a workstation.
maybe you should consider using unstable for workstations, even if you don't
want to use it on servers.
craig
Reply to: