Re: implemented features (Re: Decision time....)

["James Frazer" <jfrazer@xxxxxxxx>]

> A good package management system is safe and doesn't require the user to
> be an expert at package management systems.

I agree.  Actually, I think both the package management and installer
share a similar problem.  The problem is in abstracting the complex nature
of both of these tasks -- for the sake of user sanity the abstraction has
to be able to make wise choices (which they only sometimes do), while
dealing with a giant list of problems that can arise.

Take for example someone installing on a system that has multiple HD's and
multiple OS's already installed -- in such a situation it is difficult to
help an inexperienced user without falling back on the technical nature of
the problem:  choosing disks, partitioning, etc.  They might think "I just
want this to install, and hold-my-hand-linux didn't require me to do any
of this" and to them all this other crap is just there to get in their
way.

And worst case scenario is when a magic-easy-script-or-ui fails and leaves
the inexperienced user with a broken or inconsistent system -- which can
/only/ then be fixed by the more advanced/expert tools.

I am reminded of sysinstall's detect x-settings feature -- I don't think
that has ever worked for me, and usually locked up my system -- has that
ever worked for anyone? For a first time user that can be so scary they
might give up and never come back again.  If you can't do something right
99.9% of the time, then you shouldn't do it at all.

On the latest FreeBSD release I had a problem with the installer that
caused an explosion of out of inode messages -- it was a completely
vanilla install, default choices, etc.  It was either a bug or sysinstall
was choosing a root fs size that was too small (although it seemed a
fine size to me). These kinds of problems should never happen.

Another example is a package upgrader that fails in the middle of an
upgrade, leaving half the system unfinished, and not being smart enough to
offer the logical fallback solution to the user: switch back to the old
packages.  Why should the user have to read six man pages and 14 internet
sites to find out that the upgrade program hid the old packages in some
esoteric directory -- and that he/she must now fix the problem manually
themselves?

To me, it seems only fair that if you provide an easy path into a giant
pile of crap, at least a little effort should be placed in providing an
easy path out of it.

These kinds of things are user nightmares, even for experienced users that
have an idea what's going on.  Having to reinstall the OS or packages from
scratch is a lame solution, albeit sometimes the only effective
one.

And I'm suspicious that many of these problems are caused by kludgy old
stop-gap abstractions that somehow became so entrenched in our philosophy
of 'how to do things' that there can be no end to the madness without
throwing them out the window and starting from scratch.  In this respect I
think DragonFly is doing a good job (eg: dropping sysinstall, etc).