Date: Mon, 27 Nov 1995 06:52:23 +0000 () From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: msmith@atrad.adelaide.edu.au, asami@cs.berkeley.edu, ports@FreeBSD.ORG Subject: Re: Proposal 3: Non-executable file in *_DEPEND Message-ID: <199511270652.GAA03800@genesis.atrad.adelaide.edu.au> In-Reply-To: <1140.817203915@time.cdrom.com> from "Jordan K. Hubbard" at Nov 24, 95 01:05:15 am
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard stands accused of saying: > > > *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.. :-) Ok, how about a clearer explanation 8) The installer starts FTPing the file. As it comes in, it verifies that it's getting a tar archive. It also verifies that the first file in the archive is called +INSTALL (or whatever), and keeps reading until it's got all of it. It then summarily closes the FTP connection (a la Netscape et al.) On resumption, it could well adopt the technique that ncftp uses for resuming a file, to avoid pulling the INSTALL script again. > 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. Without offering people a salary (and even that's not always enough 8), you can't expect a guarantee of that. I think it would be fair to say that almost everyone interested in this thread has a 'real job' that they need to keep in order to, amongst other things, pay for the hardware on which they might perform such work. Everyone knows what 'real jobs' do to you 8(. I don't know how to resolve that one. What would make a group start to look "truly credible" in your eyes? > 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. :-) Understood. This, in perspective with my understanding of your background, is just fine, providing the coding grunts can be found 8) > 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 Good! Somebody has to. > 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. Don't get me wrong, if I thought we could get MGR up more easily than X, then I'd advocate it 8) I just think that the days of the text-based installer being K00L are numbered, and the 'tooliness' of a set of bits based on the predominant windowing system (for reuse in administration tools, or whatever) can't be ignored. > The other big advantage to TCL is that I know it pretty well, I know And you can expect to find grunts who know it or can learn it, and there's a ton of code out there for it, and and and... > 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 I've written mouse firmware, so this makes me queasy, but if this is what it takes to be credible 8) How's the PS/2 mouse support for the GENERIC kernel, on this one? > 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. Ok. > xf86config is just too horrible to contemplate, and looking at Xsetup Agreed. > After you did such a good job with userconfig, I'd say that xf86config > will be a piece of cake! :-) There's a word for that sort of comment 8) > 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. I've been beating this around in my head since you started mentioning callbacks - the purist approach is, of course, that a form should not be _able_ to contain contradictory data, and that if it does, there is a shortcoming in the forms interpreter or in the form as presented. Dilbert knows about purists, and I tend to agree. I can see a simple way of doing callbacks while still sticking to the connected-via-pipe model, and on reflection, I have no qualms about the idea at all. After all, the idea is to write tools that help their user, not stuff them around 8) > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511270652.GAA03800>