an ominous comment

Thu Jul 16 08:39:17 PDT 2015

2015-07-15 2:20 GMT+09:00 Kurt Buff <kurt.buff at gmail.com>:

> On Tue, Jul 14, 2015 at 10:02 AM, Stephen D. Williams <sdw at lig.net> wrote:
> > Everything will be run in the cloud and browser because it is, overall, a
> > better computation model.
>
> Certainly that's the current bias, but web  browser as platform isn't
> really all that it's cracked up to be, IMHO - all browsers suck, and I
> don't see them getting better any time soon, especially if they run
> javascript and plugins.
>

"All browsers suck"?.. They run HTML pretty darn well. I'd say HTML is a
document language, not an application language, and now it's trying to be
both and it's a pretty psychotic fit. But it still works pretty darn much
better than anything else out there. I'd like there to be an "all settled
standards compliant fast and secure browser", but the secure is usually
omitted (and there's a rush to support the not-quite-settled standards).

Not much wrong with JavaScript, but I hope they'll soon support several
other languages too. Like perhaps LLVM's intermediary format - so we can
compile whatever into a near-metal language that will run really fast. (and
saving a lot of people the effort of writing/maintaining to-js compilers)

But the cloud is a better computational platform because of:
 * Economies of scale for computer electronics, power, network connections
 * Time sharing on the cloud's hardware
 * Sometimes architecture advantages

But, pushing back, there's:
 * Latency/bandwidth to user
 * Loss of end user's control over essential hardware
 * Massive trust and security issues

We're looking at the following:

- micropower devices; IoT and thinner smartphones (less power usage as
batteries do not seem to develop fast), home automation panels, extra
body-mounted-displays, in-car panels, home-appliance panels (refrigerator
to mixer), televisions, alarm clocks, some tablets and laptops
anything with power or financial constraints. These machines are that which
the user interacts with. Their entire design gives way to human preference
and comfort. They do not compute much, and might contain nothing but a
video-stream-decoder and a "window manager" that decodes simple graphics
statements (hopefully simpler than HTML).

- computers; workstations, desktop pc's, laptops, stand-alone "videocards"
with generic computing support, servers, gaming-appliances
fast computers that are positioned somewhere in the house. Low latency to
the user and with very good price/performance relationships (desktops now
are miracles). Given the single-core-ceiling these machines will typically
fare better than ideal cloud setups for many applications. They can be
rented out to remote users dynamically.

- remote processing; the cloud, the neighbors' computers, etc
time-shared computing that is not in-house. Typically high latency,
extremely high maximum power and lowest cost. Latency constraints force it
to be used only for very expensive operations - such as rendering tasks and
machine learning (for business intelligence or otherwise). If the
set-up-time for such an operation is 2000ms many tasks are still better ran
locally - the application-support-system (OS?) will have to make choices
about this rather fast.

> >  However, that doesn't preclude you from running a
> > cloud locally.
>
> Certainly better than public/commercial clouds - at least until proven
> encryption becomes the norm.

What I've described above is a sort of multi-tier architecture. At the
moment remote or local computing is a wild west with exclusively homebrewed
solutions. At some point we will integrate all our devices, and software's
locality will be managed better as well. Encryption will be applied
automatically at the appropriate places. I think the largest desired
capability is the inaptly named "homomorphic encryption", which should be
optimized and packaged such that heavy processing can be remotely executed
in a safe and trustless manner.

What is to be done? Well, I hope we can avoid the situation where we run
the browsers and they run the software. We're going there now because the
architecture I mentioned does not exist - and because it's a simpler model.
A business could be made out of making hardware that follows the above
model, that would probably be the best way to make it happen. Elsewise
we're all along for the ride that the unknowing public is buying us into.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 5594 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20150717/4cb1223d/attachment-0002.txt>