Date: Sat, 25 Nov 1995 12:18:45 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: hackers@freebsd.org Subject: Thoughts on the install and on Red Hat Linux. Message-ID: <16288.817330725@time.cdrom.com>
next in thread | raw e-mail | index | archive | help
I just installed RedHat 2.1 on my spare box. Hmmmmm. First
impressions..
I have to say that some of the debate that just went on in ports
concerning the new install structure should probably have waited until
all the principals had done some more checking into existing
technologies. :-) There is a wealth of valuable examples to study in
RHL, both good and bad.
I don't think I like their RPMS very much, but many of the ideas
behind them are good. I especially liked their X based package
browser - though the interface was seriously clunky and needed a
face-lift, it could at least be said to be working NOW. I give them
full marks for having done a lot more of the ground work than we have.
If I had to make a guesstimate, I'd say that Red Hat is about half a
generation ahead of everybody else in the free OS world at this time.
Only half, however, and their continued use of libdialog has cramped
their style outside of X (where one still spends considerable amounts
of time during the RedHat install), forcing some information to be
presented in a somewhat constrained fashion. A good example of this
are their TCP/IP setup dialogs, and some of the early X stuff.
Nonetheless, I was favorably impressed by the sheer depth of their
coverage and I was asked enough questions to bring me all the way up
into X on the first try, the installer even giving me the chance to ID
everything from my board's clock chip to the monitor specs. Yup, this
is how to do it!
Once in X, the root login had a reasonable set of defaults (I made a
note: give root some reasonable .dotfiles!! :-) for bringing up fvwm
and a small desktop, one application being the Red Hat configuration
utility - a little TK GUI based app that lets you go see which
packages you haven't installed yet, get information on existing ones,
add and manage EXT2FS / NFS mounts, etc. Actually nothing to really
win any X GUI design awards, but again - it's a lot more than we've
got! :-)
Actually, I found the experience encouraging. It showed me what we
might leapfrog past ourselves, given a concerted development effort
based on some of their ideas and a close examination of our own
experiences. I think there some things we still do better (and can do
even better still) and some things they do way better, but we can get
there too, and probably with a better toolchest when we arrive.
I know that I've been a bit of a demagogue with sysinstall in the
past, but I'm ready to try and share the responsibilities for setup
more and try to be more receptive to different ideas. My primary goal
is that we get some *robust* tools, with plenty of safety netting, and
an easy-to-use interface for them that looks halfway like something
you might expect to see on a commercial product. I don't really care
who does the work, just so it gets done! :)
Can we re-open the traditional (heh heh) dialog on this topic?
Here's my own list of dialog-starters:
1. I think we need to continue with the button & list objects that
Marc van Kempen started, though we probably should start over in
another library outside of /usr/src/gnu so as to get one more
piece out from under the GPL. We might want to also go for a more
forms based approach to Marc's objects since having to do the object
traversal yourself in the application gets tedious - it would be better
to allow a forms shell to handle the traversal along pre-configured
paths, calling any callback functions registered to various objects
along the way.
Then we should add back all the primitive objects necessary to
re-implement menus, gauges, text boxes and whatever else we're using
from libdialog. We can have some *real* radio button menus that call
individual callbacks when you toggle the items - whoopie! :)
[only folks who have worked with libdialog much will appreciate the
significance of that one]
2. I think we need to sit down and devise a list of tcl commands,
in their own little library and name space, for doing all the sorts
of things that one might want to do to files on the system in the
process of "installing packages." Maybe we'll find that existing
TCL or TCLX primitives require just a few more additions to make
for a completely robust package building environment, I dunno.
We'll just have to look and see.
3. We should start looking at what we need to do to get the user into
X in as fool-proof a fashion as possible, working with the folks
doing #1 for the various GUI elements required. I'd like to even
see this done as a separate little sub-project with at least 3 team
members (call it "project slingshot" or something) since it's
actually a non-trivial task and a very important one besides. It'd
be nice if the people focusing on this piece were able to do so
almost exclusively until completion (and I might even be one of
those people, it's hard to say).
Comments? Rotten eggs?
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16288.817330725>