Date: Wed, 1 Feb 95 9:42:46 MST From: terry@cs.weber.edu (Terry Lambert) To: root@io.cts.com (Morgan Davis) Cc: jkh@FreeBSD.org, hackers@freefall.cdrom.com Subject: Re: sup: Ok, I'm gonna do it. Message-ID: <9502011642.AA06840@cs.weber.edu> In-Reply-To: <199502010705.XAA01059@io.cts.com> from "Morgan Davis" at Jan 31, 95 11:05:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> In lieu of adminstrator's manuals that basically give an overview of > what makes FreeBSD work, there should be some kind of roadmap that > spells things out clearly. Here's how you get the sources so you can > at least recompile your kernel. Here's how you set up sup so you can > get the bug fixes to those sources you just picked up. Here's how you > reconfig your kernel to turn your machine into a network router. > Here's how you easily get PPP working. Here's how you... The current > FreeBSD.FAQ is horrible and filled with incorrect information. This > is not a roadmap. It's a hack. Would an all singing, all dancing administration tool, like SVR4 sysadm or AIX's be a sufficient answer to this problem? What it if was only available as a GUI tool? > After I installed 2.0R in November just after it was released, I > exited from the nice installer interface wondering, OK, now how do I > get back to that? The installer ought to be EASILY reentrant -- I had > no idea where it ran or how to get back to it once it quit. And it > should also assume that the user may want to come back to it to do > other things and really make a lot of noise about proceding with > things like fdisk and disklabelling, post-install. The installer is a special purpose program -- that is, its scope is extremely limited. It does what it does extremely well. You might liken it to a car that runs real well in one lane of a 20 lane freeway. Reentering it is like trying to signal a lane change. Unless you already know and obey the rules of the road, you are just as likely to lane change the wrong direction, and then you are out in the weeds. Going 60 MPH toward a canal. There are a lot of size and other justifications for making the installer seperate from the standard tool set. I think the problem is that there isn't a standard tool set. I also think that a standard tool set is a bigger job than it sounds. Let me digress for a minute: how does something like Motif get written? Well, you go to add a user. But there isn't an add user utility. So, being a programmer, you say "Hmmm... I might one day add another user", and go off and write 3000 lines of code to do what you could do in 5 minutes. Then you look at this code and say "This is crud. No one will be able to use this without a front end". So you hack a front end on to it using curses. In the process you discover that curses sucks. You say "Hmmm... really, I need to be able to replace the front end with something that doesn't suck", so you hack the program in two. But the front end still sucks. So you say "I might as well write a front end that doesn't suck". Another 8000 lines of code go by. You say "you know, the industry standard right now is Motif". Another 2600 lines of code. "You know, the front end ought to be able to front end for any program". That's a toughie; 15000 more lines of code. Now, what about those people who don't have Motif? It's a proprietary standard, which is an idea that rankles you morally anyway. Standards should not have compulsory licensing built in to achieve compliance. "Hmmm...". The problem with self-directed coding projects is that they never get done until a long, long time has passed. This is both good and bad. Maybe what's needed is a tool writing pragmatist, willing to start pulling administration sources from the comp.sources archives and make them work. In a volunteer project, that person may be difficult to find. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502011642.AA06840>