Date: Fri, 24 Nov 1995 01:45:56 +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: <199511240145.BAA00135@genesis.atrad.adelaide.edu.au> In-Reply-To: <25005.817157079@time.cdrom.com> from "Jordan K. Hubbard" at Nov 23, 95 12:04:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard stands accused of saying: > > ncftp -c <URL> |tail -c +10000 | tar xf- --fast-read +INSTALL > > Oh ick, I'd sooner cut my own nuts off than do something like this! :-) *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" ? > > Behavioural constraints? The less behaviour, the fewer constraints 8) > > Or are we talking about package-specific user preferences? > > The latter. Agree. If we want to do that, we need a programming language. I still think that that's as much something that the original software authors have skimped on as anything, but if we want to integrate things, we do have to do the work. > > > 6) Deal with *other* packages > > > > Aigh! This is an N-complete problem - every package would have to know > > No, this is doable. This is also not optional. This MUST work or you > cannot trust the package collection to work. Well, you're the guy with the experience; I just think it's a helluva job 8) > For another thing, I think you're still thinking from the perspective > of "one disk charlie" - disk prices are plummeting, and if we don't > think just a little bit from the "a gig will be really cheap soon" > perspective then we're unnecessarily hamstringing ourselves for the As long as the tools can work _effectively_ when disk space is constrained, there's no problem. If we place our reliance (and I'm not saying that this method _would_) on a space-dependant scheme, the One Truism of Disk Space (*) will make us Real Unpopular. (*) Data always expand to occupy all available space. > I'm trying pretty hard to make life easier for the detached developer, > since we're trying so hard to recruit them these days! :-) I appreciate this. I'm not trying to detract from your vision, just commenting on the bits that I can comprehend 8) > > You could use this to 'reconstruct' a broken installation. Then again, > > the same information could be held in a +LIST file in the current > > database format. > > No it couldn't - no MD5 checksums! Who says a +LIST file wouldn't have checksums, if they'd help the process? > > A custom-cut X server with support for nothing but VGA mono and Herc mono > > would have no need for configuration. You'd only have one colour > > model to support too 8) > > Ha ha, you're assuming that you can even get this server to work on > all cards/mice/monitor situations. Trust me, you can't. No, not "all". But a large proportion, yes. I consider mice to be an extremely optional extra. 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. > The assumption that we can get even 90% of our user base straight into > X from a standing start is a deeply flawed one. Trust me, I've tried > and I've also listened to the technical support calls. The problem with the failures is not in the failure, but in _detecting_ it and switching to a fallback 8( This is the safety net that makes _trying_ for the graphical interface worth the effort. > > Before you ask - yes, I'm interested in working on this. Anything for a > > real project, instead of running around coming up with half-baked ideas on > > my own 8) > > Hmmmmm. Would you care to share the details of your design? You've seen them all 8) If you mean "would I care to spend a lot more time working it out in detail", perhaps to the extent of a prototypical definition for the forms-layer and script-layer interfaces, sure. I'd like to be reasonably sure that I'm not running off at a tangent, though. > Why not > simply use TCL as the "mid-level" language spec and just not use Tk > directly? The last thing we need in this life is Yet Another > Specification Syntax. Um. TCL would be _good_ from the point of view of commonality, and you could extend the interpreter with appropriate primitives (I see a "disklabel" primitive, for example 8). I'm not sure whether it would be up to snuff in terms of data structure though. TCL has always been weak like that 8( > That was always my gripe with Ctk/Tk - I don't feel that Tk is > sufficiently low-level enough to make a good emulation target. There > are nicer ways of being able to say "I want a button here and I want a > label there" without ever assuming an underlying concept of "button" > or "label" that's less than completely generic. On the contrary, I think Tk is _too_ low-level. (Although perhaps we are confusing high and low here 8) Who wants, or really needs, to go that low? I'm thinking more that we want to classify the information we want (from forms, menus etc) into a limited set of types (really, there are only a few), and leave the window dressing related to extracting the information from the user to the interface-specific forms interpreter. A set of fields, like the interface configuration screen for example, would be a dialog under X, a fullscreen form on an ncurses-supported terminal, or a series of prompts/are you happy with this? questions on a glass tty interface. >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. > At another level, I'm a little tired of doing the binding at even that > low level. I'd like to be able to say "get me a value for this > variable" or "call me if anything representing me on the screen gets > frobbed" (whatever that might be). In other words, I'd like to > completely decouple of front and back ends of the app. Still too low-level, and too GUI-oriented. Think data, not presentation 8) Remember that something like an installation is basically a linear process. You ask a lot of questions, swap a lot of disks, and exit. The questions can usually be grouped into related sets, and there are obviously several paths the process can take, but it's essentially a gather-then-process thing. > Maybe I should just run off and do all of this and then come back > with a fait accompi.. :-) Maybe you should look to managing the project (and obviously participating), rather than trying to be Atlas? I'm not trying to peg you down (heaven forbid!), but sysinstall has always been a last-minute hide-in-the-corner thing (remember your ramblings about "setup" after 2.0.5? 8) that's had the rest of us sitting 'round twiddling our thumbs feeling sorry for you. I recognise that remote developer help can be slow to respond, and that can be maddeningly frustrating at the best of times. Just now, there's no great pressure on for something to be finished though, so isn't now perhaps a good time to get something rolling? > 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?199511240145.BAA00135>