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

     On Tue, Jul 14, 2015 at 10:02 AM, Stephen D. Williams
     <[2]sdw@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.

References

   1. mailto:kurt.buff@gmail.com
   2. mailto:sdw@lig.net