Skip site navigation (1)Skip section navigation (2)
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>