Date: Wed, 01 Oct 1997 09:34:13 +0930 From: Mike Smith <mike@smith.net.au> To: Peter Korsten <peter@grendel.IAEhv.nl> Cc: chat@freebsd.org Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <199710010004.JAA02444@word.smith.net.au> In-Reply-To: Your message of "Tue, 30 Sep 1997 19:23:44 %2B0200." <19970930192344.25916@grendel.IAEhv.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
> Mike Smith shared with us: > > > > [the discussion was about GUI's and browsers] > > > > Also consider that whatever the interface, it has to work with a > > textmode browser (ie. lynx). > > Aren't you the guy who said I was totally failing to get the point > you were making? Yup. You're still doing a good job of it. 8) Please remember that we've been over all this territory before. I'm happy to rehash it so that you understand the situation, and desperate to hear something new. > We began with graphical user interfaces. Then we got to implementing > those in a browser (which I think is the user interface of at least > the near future). > > And now you want a fallback to - yes - a text interface. And also > one for browsers that don't support Java. Talking about missing > the point. No, again you're not quite picking it up. HTTP using a browser is a convenient technique for providing a remote management interface. Such a thing is highly desirable. However, there is a not insubstantial text-mode-only group of users, whose desire to be able to use such a tool is valid. In some cases, these will be single-system users not running X, in others we may be talking embedded systems, or hardware with remote consoles; there are plenty of valid reasons for not having a graphical console available, and this is no excuse for not having a management interface. Implementation resources are *LIMITED*. This means we can, at most, afford to attempt to develop and maintain *ONE* interface and set of tools. To make this viable, we need to hit as large a target group as possible. If we build a monstrosity that needs client-side Java, local PGP and (by the flavour of recent proposals) an administration guru just to set up and maintain it, nobody will use it. The development effort will be wasted. So, I'll say it again; what we need is an interface which abstracts the content of the configuration information from its form. This will give us a foundation which will make implementing CM frontends much easier. Then, if we want to target a web-based interface, we should pursue something secure and browser-neutral purely as a conservation of effort and resources. If, once the backend is done, a party of enthusiastic beanheads wanted to write a browser-specific buzzword-positive frontend to it, Nobody Would Complain. Hell, I'd use the damn thing. We'd love it. But suggesting that that's the only way to go is a big ask. > Noone cares about browsers that don't support Java or graphics. > I make a living writing software for web sites and these issues > are _not_ taken into consideration. Your first sentence would have more credibility in the absence of the second. 8) Just stop for a moment and consider this: If this hypothetical tool _works_, we will want to use it for *everything*. This includes installation. If we are to support single-system installs, ie. non-networked machines, we have to supply the browser as part of the install. Neither FreeBSD Inc. nor Walnut Creek can ship Netscape, the only Java-capable browser for FreeBSD, due to Netscape Inc.'s prohibitive licensing restrictions. How many more ways should I put it? The lowest common denominator is an 80x25 cursor-addressable terminal. We *must* support this in a usable fashion. I don't think that your 'no professional uses anything less than a 17" monitor on anything' sentinment is likely to be terribly popular. 8) > Just make the darn thing. Or support it, at least in spirit, even > if it isn't 100% secure or compatible. There's a firm making billions > of dollars with stuff that isn't secure nor compatible. Sure. Just step up and keep helping. You may have noticed we don't have the billions that you alluded to; instead our wealth (and sometimes desperation) is the support of volunteers like yourself. > P.S. I'm going to adjust my mail filter in a short while, so if > people start receiving 'message refused' messages from me, > that's because you sent it to the list as well as to me. > Editting your headers solves the problem. It's easier just to filter incoming duplicates, and more civilised to boot. We can't tell which lists you're subscribed to. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710010004.JAA02444>