Subject: not "net appliance" (Re: [coallesced replies] Re: how to create 21,780 new free) software jobs (2,530 in R&D)
From: Tom Lord <lord@emf.net>
Date: Sun, 10 Nov 2002 10:21:44 -0800 (PST)



	tom:
	I don't believe you.

	
	brian:
	Yes you do.  You just want me to do some legwork for you.
	However, I did see where I needed to make a correction -- the
	Net Appliance boom was 2000-2001, not 1999.

I'm not above the kind of laziness you describe, but this isn't an
intance of it.

Andrew workstations (the most concrete example of what I'm describing)
were not net appliances when I was there and I suspect they are not
now.  "Cheap and interchangable" does not always mean "net appliance"
which usually means "anemic client with little or no independent 
capability".

"Interchangable" was a poorly imprecise choice of words on my part: I
didn't mean that the clients all had to be nearly identical within a
very narrow range -- only that users can change the client they use
and their home environment travels with them (whether the user
is using a different client across town, upgrading to a fancier
client, or swapping out a broken client for a working one).

"Cheap" was also poorly imprecise: interesting base-line clients
should be inexpensive but, these days, that's not hard and,
anway....duh, of course they should be.

I said the clients should be "like telephones" -- but I meant that in
every sense.  There's a very wide range of capabilities in telephones
- a lot of consumer choice.  They're "interchangable" because they are
designed to operate against flexible, universal protocols.  You plug
in a conforming telephone and get dial-tone.  (Given the historical
baggage and nature of telephony protocols, please don't look for a
perfect protocol-to-protocol analogy, though.)

So, sorry about the word choice but:

Net appliances usually aren't capable of any meaningful kind of
detached operation, are they?  They don't run purely local apps.  They
don't speak with the servers primarily via a file system -- the file
system isn't used as the common substrate that (mostly transparently)
joins all applications (unless there were NFS-based net appliances -- 
but historic (at least) NFS versions don't scale).

So while the links from google may be helpful, what I don't see is any
strong analogy here -- why you think there is much that is strongly
relevant to learn from the efforts you cited.  Beyond "some of your
files are stored remotely" and "your admin costs are low", net
appliances seem rather different from what I've proposed.

One link you posted was to the "Personal Internet Appliance" -- PIA.
It's described as a "`closed' box" (no expansion slots?).  Being that
it was 1999, it was quite expensive by today's standards and
apparently not convincingly cheap by the standards of its day.  The
article says the PIA is "closer in form and function to a full-blown
PC" than other things that have been given the applance label:
"corporate web servers, wireless networked handheld PCs, and set-tob
boxes" but it also asks "Why buy these things when PCs aren't much
more expensive" (why indeed?) and suggests that the sole point of the
things was "plug-and-play Internet access" (what about non-Internet
apps?).

Some Andrew workstations were quite (for their time) beefy and
capable; the network wasn't homogenous (though it wasn't random,
either) -- people used the extra power and autonomy if they could get
it, but Ellison says that it is a "fundamental mistake" to create PCs
that are increasingly "more powerful and more complex".  Yes, he
wanted to spare users the problems of configuration and installation;
yes he called it a bad idea to support every piece of hardware under
the sun; but, no, _his_ approach was to aim for very stripped down,
low-capability clients.

I think a closer analogy to the plan is Red Hat's cascade of update
servers -- their update protocols and fleet-admin tools filling in for
a small part of the role of the file system in the plan.  I think the
compare and contrast exercise ought to look at the network protocols
and range of services provided by the server connection; at the
strategy and form of upgrades and how users experience the upgrade
process; at the distribution of admin rights and responsibilities; at
the usefulness to the customer of how their subscription fees are
spent; at the kind and quality of support being offered; at the
mechanisms for delivering third party apps; at the additional benefits
received when _all_ apps are transparently linked to the servers via
the file system.  While I think we'd find many significant advantages
to the approach sketched in the plan, we might take some hope from the
fact that while Red Hat hasn't exactly won big, they haven't quite
failed yet either and are arguably on something of a growth path.

Another analogy (though at a different scale, and taking an approach
that the Andrew project found unworkable at their scales) is the classic
NFS/YP/WP set-up.  That solution didn't exactly fail.

I said:

	In other words, could you be more specific so that we can
	compare and contrast the critical details, as well as learn
	from past experience.

What do you think are the comperable or contrasting "critical details"
of network appliances and what do you think we should learn from them?

-t