Date: Fri, 24 Nov 1995 01:05:15 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: asami@cs.berkeley.edu, ports@FreeBSD.ORG Subject: Re: Proposal 3: Non-executable file in *_DEPEND Message-ID: <1140.817203915@time.cdrom.com> In-Reply-To: Your message of "Fri, 24 Nov 1995 01:45:56 GMT." <199511240145.BAA00135@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> *laugh* - but you get what I mean though? Or should I have said > "for FTP, just grab enough of the file to pull out the install script, > which should be first in the wrapper" ? My real problem with that approach is that it has these icky hard-coded constraints in there. Magic constants always get me into trouble, and assuming that the installation data will always be 10K or less just strikes me as bad. I'd much rather go to two files than accept such a hack solution, that's for sure. Make me a better offer.. :-) I should also take this opportunity to respond to some of the issues Michael raises concerning group development and how I should "manage" this effort rather than taking it all on myself (an entirely reasonable suggestion, but see below). I'm willing to consider leading a group effort, and would certainly look favorably on a scenario where a group was actually producing a much better installation framework than could formerly be produced by a single person, but I have some reservations.. For one, I would need to feel really confident in the "team" that was put together - confident that each resource within it was going to see it through and not just wander off in the middle or get jerked away suddenly. Those sorts of occurances make you just want to throw up your hands and give up on the entire concept of group development, and I've experienced such occurances in the past. If a group formed here which started looking like a truly credible R&D team, it would have a big effect on my outlook. For two, be it well understood that I'm not actually all that wild about packaging or release engineering issues. Frankly, I find this kind of coding *really boring* and the only times I seem to manage to actually write any are when: a) I've managed to figure out a neat way of solving the problem that is in itself enough motivation to do it. b) My back is against the wall and I realize that FreeBSD isn't going to have whatever feature's at stake at all unless I hack something out. So while I'd be happy to sort of direct traffic at the top, the actual technical piece I chop off is probably going to be whatever piece I happen to think is cool. If my back's to the wall I'm more likely to just beat a feature into sysinstall or pkg_install these days, so that motivation is out. :-) For three, even though I don't much care for this kind of stuff as a technical challenge, I do care very much about it from the presentation side. That's the only reason I got into this mess in the first place, in fact. I couldn't stand to see FreeBSD's first steps be a shell script and then a login prompt.. :-) This means that I'm likely to be very very opinionated about any system that evolves here. I have a very definite picture in my mind about how I want the system to ultimately look, and I daresay that it's probably not even that far from yours (though it could take us weeks just to find the right language for communicating that fact to one another! :-) This is one respect in which it's much easier for me to work alone - I don't have to spend as much time trying to explain what I've got in mind as I do actually implementing it! :-( Those are just my reservations, and I don't think they're necessarily insurrmountable, but we should discuss these things. I can say that I've made a few decisions in the last couple days' worth of contemplation. The general extension language for this whole thing will be tcl 7.5. I've looked at forth and I've looked at scheme and I've looked at my own stuff and I've even looked at PERL and only TCL seems to strike the right balance between the space it eats and the power it provides. It's also got a rich toolchest for bolting in other things (can you imagine how useful a TCL-aware installer with ``expect'' functionality compiled in would be? You could use the stand-alone floppy as a serial line analyser.. :-) and we can go graphical with Tk in the immediate term while we evolve a strategy for being pan-platform. Heck, maybe I'll just eat my words and see if we can't construct Tk interfaces that are simple enough to be displayed with Ctk.. :) [only those who remember my "Ctk sucks! No! No!" postings will really find this suggestion funny :)] It would be a very expedient solution with a fairly high return, and even if Ctk turns out to be too badly broken to use, well, then Michael gets his wish and we start making getting into X a higher priority - at least we know that Tk works well. The other big advantage to TCL is that I know it pretty well, I know how to extend it and I've figured out how to deal with C-side abstract types pretty well using various types of hash table manipulation. We could do at lot with it, and make all of the basic primitives in sysinstall tcl callable. > Based on the same assumptions that (ecch) Windows makes, I would say that we > could safely assume that the vast majority of platforms could be cajoled > into offering a 640x400 monochrome visual. You can do a lot with that. OK, I'll set to you then a challenge: Can you write a setup program for X that probes for mouse type (this is easy to do - there are standard interrogation sequences that the XFree86 people know and can tell you), presents a table of monitors and graphics cards, tests the server and gets the user to feedback on whether or not they saw whatever test pattern was put up, returning them to the setup program until they do. xf86config is just too horrible to contemplate, and looking at Xsetup from the X Inside distribution (see the demo in the commerce distribution) gives a much clearer picture of what we'd like to see. The X Inside people *do* have a 99% success rate, and what's more we even have their server! :-) The demo version will let you launch, I believe, 4 clients. That's a WM, the setup utility, an xterm and a clock.. :-) However, I'm a little loath to lean on a demo server when it only gets the user sort of installed and then leaves them without X again since the config work they did isn't actually applicable to XFree86. We need an xf86config replacement! After you did such a good job with userconfig, I'd say that xf86config will be a piece of cake! :-) > From the point of view of the script controlling the installation, there's > no difference. When the forms interpreter finishes running the form, it > returns a set of values. End of story. Ah, the forms interface perspective. I guess you're right about this, though I'd like some real-time callback ability on the individual subcomponents this time, not the static libdialog crud which never let me say "if these two are on, turn that one OFF!" for callback checks. If we can meet in the middle here, I think taking the forms approach is the right basic way to go. Just don't make it so high level that my forms become "dumb" like the libdialog objects. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1140.817203915>