Re: [Computerbank] Linux distribution standardisation

[Dale Long <dalel@loftuscomp.com.au>]

On Mon, 10 Dec 2001, David Hatton wrote:
> Raul made some good points about a high level approach and working out
> various configuration details.

It is preferable to define what type of high level functions/services are
required, but the how-to needs to be kept in focus at the same time.

Each choice we make, especially with low end machines, can have a domino
effect down the chain from the 'application' level to the technical
details.

> Several others have discussed the choice of distribution, and the
> options seem to be narrowing to either RedHat or Debian - from memory
> Mandrake is optimised for Pentiums and won't install on 486's (?).

Mandrake have mentioned a 486 version, but I have not followed it up. The
only offset here is that low end Pentiums are better utilised. This pro
may not outweigh Mandrake's cons. Is it possible to have a 586 optimised
compiled relase of Debian within CBAUS? Would it give low end Pentiums
some extra life?

> I'd like to put in a plug for Debian.  As outlined above, it lends
> itself to customised network installs, and I have found the package
> installation management tools way ahead of the rpm based distributions,
> even though some people might be put off by the non GUI installation
> interface.  As someone else commented, once you have stepped through
> the install a couple of times, it all starts to make sense.

The ergonomic issues with it tend to contrast highly with the Debian goals
for efficiency and practicallity. But this is a minor point when installs
are mostly automated.

> Now I'm happy to admit that I'm not a rpm expert, but I have tried to
> install software packages on both Mandrake and RedHat after an initial
> setup has completed. Maybe I'm unlucky, but I have frequently selected
> a package or two only to have the rpm installer come up with a message
> to the effect that "I can't install package A because it requires
> package B which is not installed" and quits. Sometimes it just gives a
> file name, eg/. libsensor.so.1, and I have no idea which rpm package
> contains the missing file.

The dependency lookup in RPM still does suck. But finding the required
package can usually be solved consistently by looking up the package if it
is a part of the distribution. Eg: look for libsensor-x.xx-rpm. It is less
than perfect. But once a system install is automated it is not an issue.
Mandrake has an automated rpm dependeny feature similar to the way debian
works, but I think it is only GUI based and it is resource hungry.

> Regardless of the distribution, all package managers will have some
> gotchas, and while Debian may have other management issues they seem to
> be ones which are amenable to a standard fix which then becomes part of
> a routine install. Such fixes do need to be documented, however.  I
> suppose my pre-occupation with package management is because that is
> what I find myself using most frequently to get systems installed.

I would like to see Debian have something similar to Red Hat chkconfig and
service commands. Again thse are minor points and may not be something a
recipient will ever need or see. I spend most of my times maintaining
systems.
 
> With respect to kickstart etc - I may be on the wrong tram here but my
> impression is that these type of mass installers are intended for
> machines which are pretty much identical in hardware specs - how would
> they go installing two machines, say one with a Pentium 200 and 48MB
> RAM, and one a 486DX/100 with 32 MB RAM, each with different video and
> network cards ?

It works well over a variety of hardware and configurations using a
single standard install. I have setup many a box this way. There is better
automation of driver identification and installs, which can be sticking
points on some machines.

> Printing - I'd suggest either a short list (ideally one or two only)
> of printers for which we can develop a standard setup, or a GUI setup
> tool complete with printer drivers to cover the options.  Perhaps we
> could migrate a suitable tool to the distribution of choice if needed?

I was thinking more in terms of lpr vs lprng vs cups, postscript,
ghostscript, printer filters, how the chosen application links with the
chosen environment links with the chose distribution of the chosen OS, and
so on. Then weighing this up with hardware requirements and so on.

> Partitioning Hard disks - cbv have usually used the KISS approach for
> single disk installs - one partition mounted on / and one partition for
> swap. 

I am thinking that it might be preferable to keep "the system" and "the
recip's data" seperate. So that a system could be rebuilt or upgraded with
a fresh install aas erquired. The only problem here might be juggling disk
space on small disks. There would of course be swap.

Has any extensive use of kernel 2.4.10+ been done on low end machines?
Will the focus be on the 2.2 kernel?

Dale.

_______________________________________________
computerbank mailing list
computerbank@lists.linux.org.au
http://lists.linux.org.au/listinfo/computerbank