From owner-freebsd-hackers Sat Nov 25 12:25:53 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA15640 for hackers-outgoing; Sat, 25 Nov 1995 12:25:53 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA15635 for ; Sat, 25 Nov 1995 12:25:51 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id MAA16290 for ; Sat, 25 Nov 1995 12:18:45 -0800 To: hackers@freebsd.org Subject: Thoughts on the install and on Red Hat Linux. Date: Sat, 25 Nov 1995 12:18:45 -0800 Message-ID: <16288.817330725@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk 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