Date: Mon, 18 Dec 1995 19:57:18 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dennis@etinc.com (dennis) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: FBSD support inc. Message-ID: <199512190257.TAA13394@phaeton.artisoft.com> In-Reply-To: <199512190228.VAA23233@etinc.com> from "dennis" at Dec 18, 95 09:28:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Your passion is admirable, but I'm afraid that you've missed the point. > the point is, that standard interfaces always make trade offs, and > always leave a few things out. There's a price to pay for generality. The > point that I was trying to make above, was that if you wanted to implement > a single product for a specialized system you wouldn't use any of the > standards above...because they basically suck. The trade off is between external scripting of interface use and apparent performance, at least in the case of an admin tool. Since I can do a hell of a lot of scripting relative to the slowest link in the control system, to wit: the human operator, I don't see the necessary tradeoffs as much of a problem. Remember that I said that one must pay attention to appearance-of-speed issues? You can have an app that loads a bit, prints a line, loads a bit, prints another line, etc... Or you can have an app that loads a bit and loads a bit and loads a bit and then page-flips the VGA card to paint the screen. Which one do you think will get the user's "Damn! That was *fast*!"? This is exactly the argument I used with Doug Michaels when ODT came out when I suggested delaying the event processing for the expose event on the window manager, such that the expose was not sent until the window manager had done it's expose processing. The actual difference would be between: swap/paint WM detail/swap/paint app detail/swap/paint WM detail/... and: swap/paint *all* WM detail/swap/paint *all* app detail That is, there would be little difference in the total elapsed time, but instead of seeing a slow app + window manager, the user sees a fast WM, followed by a fast app. It's the same reason the trade of slightly slower execution vs. fast startup following the command being issued was made in the exec loader. The speed decrease in the overall execution was negligible, but the speed increase between hitting return and the program doing *something* was astonishing. There is room for similar trading in admistrative tool interfaces. Plus a nice bonus of a uniform command line interface for all admin tools written for the job (since they don't need scripting to hook them). 8-). Regards, Terry Lambert terry@lambert.org --- 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?199512190257.TAA13394>