Date: Thu, 23 Nov 1995 12:04:39 -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: <25005.817157079@time.cdrom.com> In-Reply-To: Your message of "Thu, 23 Nov 1995 15:16:12 GMT." <199511231516.PAA29078@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> The ability to _work_ with multiple files is desirable, yes. The > _necessity_ for multiple files is IMHO _not_. > > 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! :-) I appreciate that you're trying to limit the scope of development to reasonable bounds, but let's not let expediency lead us down more dark and limited paths - we've DONE that already! :-) > Behavioural constraints? The less behaviour, the fewer constraints 8) > Or are we talking about package-specific user preferences? The latter. > > > 6) Deal with *other* packages > > Aigh! This is an N-complete problem - every package would have to know > about every other package that it might conflict with, or which might > conflict with it. I think not. Certainly, some rudimentary No, this is doable. This is also not optional. This MUST work or you cannot trust the package collection to work. > I'm thinking "I want my disk space for my data. If I want backups, > I'll make them myself, on tape." I'm thinking that this would be a Nice > Toy from the admin-weenie point of view, but the overheads would be > horrific. Not necessarily. For one, who says you need 3 copies? If one is all you can afford, the 3DFS code can be smart enough to essentially become a one-level deep history mechanism. You don't lose anything you don't already lose now. 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 future. There are ways to make this work in space-starved situations, and in fact you can even turn it to your advantage. Consider a "delta" type of "compress" - you could apply a change to the tree that essentially did no more than compress a section. Roll back the pointer one step later and you uncompress it. Since every file in the tree can go through a "gate" in becoming visible (or disappearing to save space), you have a lot of flexibility. I'm trying pretty hard to make life easier for the detached developer, since we're trying so hard to recruit them these days! :-) > Imagine someone tracking -stable, -current, ports and the distfiles. > Naturally, sup would support the 3dfs (if it were implemented properly); > imagine how much space would be consumed. Now be realistic here, if they're wanting to do all of that then it's a reasonable assumption that they can afford the disk space. I certainly can, and everyone I know doing development can. If you can't then you've the pretty simple choice of *not tracking* all these items or getting with the program and buying a bigger friggin' disk! :-) Also, see above about compaction deltas and other clever tricks. If you're just working on one section of the tree at a time, I can engineer 3DFS to *save* you space, guaranteed! > 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! > Isn't this doing things the hard way though - should we be looking to > a journalled filesystem instead? (presuming my understanding of JFS is > correct...) No, it doesn't do what we want. > > > Still, it's really too early to declare the death of character mode > > interfaces. Yes, I'm an X hacker and I much prefer hacking on X > > interfaces, but an all-singing, all-dancing system written in Tk > > would, I believe, still be just a *bit* before its time. We'd still > > have all these people with perfectly reasonable systems but totally > > unable to get past the evil and scarey xf86config program and > > considerably frustrated by the exercise. For those all-too-numerous > > people, we need to use ncurses. > > 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. 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. > 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? 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. 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. 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. Maybe I should just run off and do all of this and then come back with a fait accompi.. :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25005.817157079>