on Fri, Apr 16, 2004 at 09:26:53AM -0700, Robin Lynn Frank (rlfrank@paradigm-omega.com) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We've been using Mandrake Linux for a number of years and have come accross
> problems with the way its library packages are set up. (We encounter
> problems compiling certain software because of this.)
>
> It was suggested to us that debian might be more to our liking. Before biting
> the bullet, I have a couple of questions.
>
> 1) What are debian's strong and weak points as a server?
> 2) What are debian's strong and weak points as a desktop workstation?
The "Why Debian Rocks" patge at TWikIWeThey, which I administer, has
already been mentioned. Manoj Srivastava (Debian Project Secretary)
also has a very good page up on the topic (referenced above IIRC).
Basic benefits:
- Policy.
- Sane defaults.
- Very high quality.
- Open bugtracking system.
- Tune system to specific needs. No more, no less. In particular,
the "kitchen sink installation practice common to RPM-based distros
isn't necessary (and is discouraged).
- Project is geared to user and community needs, by charter, as
expressed by the Debian Social Contract.
- Choice of stability / currency tradeoff points with different Debian
releases: stable (old but rock solid), testing (equivalent to most
other distro's current release), unstable (usually works, but watch
the release notes / upgrade lists), experimental (unofficial, *will*
stab you in the face, given the opportunity. My basic
recommendation is 'stable' for servers, 'testing' for workstations,
until you understand packaging tools. After which point you want to
look at pinning.
- Large number of packages. 8000+ in stable, 14,000+ in
unstable/testing.
- Compatibility with RPM-based packages, when necessary, through
'alien'.
- Choice of installers.
> 3) Any caveats I should be aware of?
- *Backtracking* from testing/unstable to 'stable' is very difficult,
and generally will break things. Debian's packaging system is an
upgrade tool. You can generally switch back and forth between
testing/unstable without too much trouble. The gap between testing
and stable may include major changes to system libraries or Perl,
both of which are key to Debian.
- There are differences between SysV init scripts, networking
configuration, and some other directory locations between Debian and
RPM-based distros. I find Debian's configurations cleaner and
saner, having used both extensively. Be aware of this.
- Know your packaging tools: dpkg, dpkg-reconfigure, apt-get,
apt-cache, apt-file, aptitude, and synaptic.
- Your package cache will be large, and hence /var space requirements.
I'd recommend ~2 GiB for /var on a workstation. More info at
http://twiki.iwethey.org/Main/NixPartitioning
- Choice of installers. There's the stock installer, which some
people gripe about (though I've had good results). The 'bf24'
install kernel will work for much HW not presently supported. I
like using chroot installs based either on debootstrap or the
base_2.2.tar.gz image file (documented at TWikIWeThey and in the
Debian Installation Manual). It's possible to preform your
installation as a chroot under a running instance of GNU/Linux, if
you've got the space for it. There are also several graphical
installers. Recommendation is to try the stock method if
appropriate and/or usable. If you've got problems applying it, post
to this list, describe your problem(s), and ask for specific
recommendations.
A comprehensive list is at:
http://www.linuxmafia.com/faq/Debian/installers.html
> 4) Any ease of installation/use problems?
- Installation: see above. Generally, it's that newer hardware isn't
supported by the stock 'stable' installer. Some people apparently
find the curses-based stock install "too primitive". There's also
little if any autodetection support in the stock kernel. There are
many alternatives, and you have enough flexibility under Debian to
install under pretty much any scenario. Including (all of which
I've personally done or assisted with): install from install CD
set, install from Netinstall disk, install from Jigdo-built disks,
install via chroot under any of tomsrtbt / lnx-bbc / knoppix and
both base_2.2.tar.gz and debootstrap, via serial and/or parallel IP,
or remote chroot under Red Hat or other existing GNU/Linux distro.
> Any information is appreciated as I would have 50 boxes to switch over.
- Package lists can be shared among systems. 'dpkg --get-selections >
file' on source. 'dpkg --set-selections < file' on target. Then
'apt-get dpkg-upgrade' on target.
- FAI can be used to automate Debian installs, though I've not used
this. It's roughly equivalent to RH Kickstart.
- There's no utility of which I'm aware to map a RH package selection
to Debian. However you can query for and install packages rapidly
via dpkg, apt-cache, and apt-file.
- You might want to set up an apt-proxy caching server and use this
for your local installations. You'll then be fetching package lists
and packages once over your external network connection, then serve
the rest locally at LAN speed. This also makes ongoing maintenance
and updates much faster.
- With 50 systems, you may want to look at clustering or other means
of centralized control and administration. There've been some
recent posts here on the topic.
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
I think you're reading *way* more into two specimens of underground
vegetable than has ever been implied.
- Peter Samuelson
Attachment:
signature.asc
Description: Digital signature