Re: debian installation
Evan,
To put this in context, my profession involves developing improved software
distribution methodologies and so I compare most software installations against my
own research and I'm working as hard as I am because I find most approaches
disappointing (not just Debian). I'll try to illuminate my previous comments a bit.
It's clear this is a sore subject for many subscribers. I don't mean to offend and
much of what I'm doing now is targetted for the public domain in the forseeable
future so I intend to put my money where my mouth is.
Evan Van Dyke wrote:
> Julian Taylor wrote:
> > Debian, admittedly, is one of the most primitive Linux
> > installations I've ever used. Among the problems are
> > the fact that no matter what you tell it during
> > installation about your intended configuration, it
> > sets everything up not to work. You'll find the same
> > problem with ppp which is most likely set up to deny
> > all access and printing which is most likely not set
> > up at all.
>
> I would have to disagree with this. Yes, the installation
> is texed based.... but the install menu is well layed out,
> understandable, and it works if you take the time to work
> your way through it. I have had PPP up and running with
> no more than a 'pppconfig' and adding myself to the
> dialout group so that I didn't have to su myself to run
> pon/poff. Printing sets up well and easilly with
> magicfilter and lprng... assuming you installed the
> kernel paralell drivers.
>
> I have installed Debian with Ethernernet networking with
> similar ease.
>
Since my primary experience is with System V, I can find most of the Debian files
I need if I look hard enough. That's a lot of "find" and "grep" but I can manage. In
fact I did find the ppp file (I forget where it was now) that declared "DENY=ALL". I
deleted that and ppp works now to my ISP. I now try to get to my employer through ppp
and that fails because Debian kind of assumes that everything is automated - this is
impossible for access to my employer's system because they use an interactive
prompt-response dynamic password. I get "pppd: permission denied" when I try that
and I have not managed to find what file it is denying me access now.
With Slackware and Caldera, I did this easily through cu.
Justin Wells made some good points in a separate E-Mail. I'll expand some of those a
bit and add a few more. Here's why I call the install "primitive":
1. The user is expected to sit through the entire installation
2. The packages aren't aware of each other
Thanks Justin and I note Mark Brown's response with one additional comment. Mark
suggests filing a bug regarding the repetitive questions but I fear this is not
merely a bug but an architectural issue. These packages aren't aware of each other
because they are not associated into a hierarchy capable of this level of
inheritance. I can see some kludges that may work to resolve a bug but a new
architecture is what's needed (in my opinion).
3. The packages recognize dependency associations only
Packages may depend on other packages but that isn't the only way to look at
this. It must be possible to deliver software assemblies that publish composition
associations with each other. That's how you get past the multiple queries - the
parent generic X Windows package asks the question and it's components learn about it
from her. Without composition and inheritance, this will be nigh on impossible to
resolve cleanly.
4. The packages depend inappropriately on files and other packages
In fact, packages don't usually depend on packages or files. They depend upon
functionalities composed of behaviors and the interfaces that provide access to those
behaviors. Each software assembly that provides a functionality needs to publish
that functionality. Future installations will locate that functionality and the name
of the package that provided it will be superfluous. Twice I had to copy a file from
/usr/local/bin to /usr/bin because a Debian package depended on that executable being
in /usr/bin. The functionality it provided was already in place but the dependency
algorithm was essentially asking too narrow a question.
5. Initial configuration must work by default.
The fact that I had informed the installation mechanism about my intentions for
ppp and it still inserted a DENY=ALL somewhere in the system is not an appropriate
use of my provided information. There needs to be a distinct separation of "install"
and "configure" functionalities but initial install should provide a rich level of
configuration.
While InstallShield is pretty, it doesn't address these issues any better than
Debian. While Debian provides lots of mirror sites for installation, the deb package
isn't really much better suited to this than rpm. I believe deb and rpm packages to
be almost as capable as SVR4 packages and SVR4 packages were entirely obsolete three
years ago.
>
> > You have to read each of the HOWTO's and manually
> > configure each thing. This can sometimes be difficult
> > because different flavors of Linux make subtle changes
> > to the base so some of the HOWTO's don't apply any
> > more (Caldera and yp fer instance). Since I still
> > haven't managed to fully configure my Debian system,
> > all I know is that the HOWTO isn't always enough. I
> > grabbed my XF86Config from Slackware Linux and it
> > worked OK. I'll be glad to send you a copy of it as
> > a start.
>
> While for many custom configurations reading the HOWTOs
> are a must, I have yet to install a debian package and
> not have it up and running with atleast a base configuration
> right 'out of the box,' so to speak. Some things(eg. SAMBA)
> need an edit of the .conf file to tell it what services
> you want to serve, but these are nicely documented by the
> pre/post installation scripts. And while, yes, the
> file structures are different, a simple 'find' or
> 'locate' can easily find the files.
It could be that the "official" Debian CD's (the ones you pay for) are broken in some
way. After installation, and after answering all the questions, I still had to
manually set up ppp, my printer, my NIS configuration, my floppy tape and my dos
partition. This was not the case with the absolutely free "Slackware" release.
Perhaps the Debian group should have a talk with the folks that publish their
official CD.
>
> As to X... X is definately the most complex thing to install
> on ANY linux system... I have had several instances where
> XF86Setup would not work, but xf86config set X up just fine
> without any problems. Admittedly you need to know quite a bit
> more about your Graphics Card and Monitor than you do under
> other OSes, but it is definately possible.
>
I agree, it is true that xf86config (while a royal pain) does the job pretty well. I
only had to do a little tweaking by hand to get the generated XF86Config file to
work.
>
> Also, unless you have _identical_ hardware configurations,
> sharing XR86Config files is a bad idea... the XFree86 FAQ
> has tales of several BadThings(tm) that can happen by doing
> this... as the XF86Config file is specific to each videocard/
> monitor combination.
You make it sound like sharing needles;->
In response to some rather livid E-Mail quite separate from Evan's measured and
constructive response, my solution to this problem is in the works. Other people's
solutions may be better but while I don't provide the actual final solution, I do
reserve the right to criticize constructively. My first E-Mail was admittedly the
"criticize" part. I hope this one suffices as the "constructively" part.
Julian
Reply to: