Robust-first Computing Wiki - introduction

contributions

anonymous@undisclosed.example.com (Anonymous) — Tue, 28 Oct 2014 22:40:57 +0000

@@ -1 +1,19 @@
+ ===== Contributions ===== 
  
+ ==== Contributors ====
+ 
+ The initial development of the MFM simulator was supported by Google through a Google Faculty Research Award.
+ 
+ Additional financial (and moral) support has been provided by Jeff Van Dyke and VanDyke Software.
+ 
+ ==== How to contribute ====
+ 
+ If you **get** robust-first computing and would like to help, there are many ways to contribute.  Here are some:  
+ 
+   * For **everybody**: Share the ideas, share the videos, share your enthusiasm! 
+   * For **Linux users**: Play with the software!  Share your finds!
+   * For **C++ programmers**: Develop new elements!
+   * For **talented UNM CS undergrads**: Consider an honors thesis in robust-first computing!
+   * For **talented UNM CS grads**: Although there is currently no additional RA funding available, other interactions such as an independent study may be possible.
+   * For **open-source hardware** people: We need your help for the next-generation tile design project!  Contact Dave!
+   * For **potential funders and patrons**: There are many projects that need your support!  Contact Dave!

how_can_i_install_the_mfm_software

anonymous@undisclosed.example.com (Anonymous) — Sat, 25 Jul 2015 05:03:07 +0000

@@ -3,9 +3,10 @@
  ====Ubuntu====
  Ubuntu software for x86 (32 bit) and AMD64 (64 bit) on precise (Ubuntu 12.04) and trusty (Ubuntu 14.04) can be installed from **ppa:ackley/mfm**
  See https://launchpad.net/~ackley/+archive/ubuntu/mfm
  
+ Note the following picture shows <del>selecting the 'mfm' package</del>, but as of July 2015 the mfms simulator has been incorporated into **the 'ulam' package** and is not being updated separately.
  {{ :wiki:mfm-ppa-montage.png |}}
  
  ====Github====
  Or use the source from https://github.com/DaveAckley/MFM
- 
+ and https://github.com/DaveAckley/ULAM

indefinite_scalability

anonymous@undisclosed.example.com (Anonymous) — Fri, 08 May 2015 07:08:12 +0000

@@ -6,10 +6,10 @@
  //hardware determinism//---is rarely reconsidered.
  
  In the traditional approach to digital computing, the physical hardware is required to be //deterministic//: The machine is to operate in clearly-defined discrete steps, and the state of the machine (the values of all its 'bits' collectively) after a step is absolutely and completely determined by the state of the machine when the step began.  In the agreement between hardware and software, the hardware is not allowed to produce any surprises or unanticipated conditions: nothing misread or misstated, no oopsies or booboos or broken alarm clocks, no excuses of any kind.  If hardware can't perform its duties perfectly, for whatever reason, its final obligation is to kill itself: to crash and "end the world", rather than produce a wrong answer.  
  
- Deterministic hardware makes the programmer's job much easier are easy to reason about and it has been a remarkable, world-changing success in the marketplace, but it ultimately **scales poorly** and offers **poor security**.  But since hardware determinism now underpins so many other design decisions, incremental attempts to move beyond determinism, historically, have struggled to gain traction.
+ Deterministic hardware makes the programmer's job much easier, and it has been a remarkable, world-changing success in the marketplace, but it ultimately **scales poorly** and offers **poor security**.  However, since hardware determinism now underpins so many other computational design decisions, incremental attempts to move beyond determinism, historically, have struggled to gain traction.
  
  
  ===== An alternative: Indefinite scalability =====
  
  Any individual computing device is a //finite// machine, both in physical size and in computational capacity.  But 'finite' doesn't mean 'isolated': To be useful, a finite machine has external connections, at least for power and communications.  We define an //indefinitely scalable machine// to be any procedure for tiling space with finite machines, with no //a priori// requirements that such a tiling have any particular properties---like aligning tile outputs with adjacent inputs.  So tiling space by, say, laying HP65 pocket calculators out in a grid is admissible as an indefinitely scalable machine---it will just prove not to be a very //good// one, once we start defining metrics on indefinitely scalable machines.

key_concepts

anonymous@undisclosed.example.com (Anonymous) — Wed, 03 Dec 2014 21:29:51 +0000

@@ -1 +1,5 @@
+ ====== Concepts in Robust-First Computing and the Movable Feast Machine ======
  
+   * [[Concepts:Indefinite_Scalability|Indefinite Scalability]]
+   * [[Concepts:Neutral_dynamics|Neutral Dynamics]]
+   * [[Concepts:CEO_software|'CEO' software]]

making_an_mfm_video

anonymous@undisclosed.example.com (Anonymous) — Sun, 07 Sep 2014 21:51:20 +0000

@@ -14,12 +14,10 @@
    - Runs ffmpeg (or now 'avconv') on those links to generate an H.264 video
  
  See or download the full script at the bottom of this page.   
  
- Here's a three-minute example:
- [[http://youtu.be/bueoWfK7IKU|Stabilizing Wa-Pat with fish sticks]]
  
- That video was made with aggressive acceleration and surge parameters (see next section) to reveal deep-time dynamics in a relatively short presentation.  
+ {{ youtube>bueoWfK7IKU}} At right is an example illustrating the 'fish sticks' shark stabilization strategy.  That video was made with pretty aggressive acceleration and surge parameters (see next section) to reveal deep-time dynamics in a relatively short presentation.  
  
  ===== Video-related command-line parameters =====
  
  Given that the '-p' switch causes the simulator to generate a .PNG each epoch, the primary relevant command-line switches are those that affect the size of an epoch:

mfm_usage_and_tips

anonymous@undisclosed.example.com (Anonymous) — Fri, 29 Aug 2014 08:52:13 +0000

@@ -24,4 +24,15 @@
        
        then it will try to load file1.mfs on startup, and if you then hit 'Reload', it'll alternately load
        /path/file2.mfs and file1.mfs each time you click it.
  
+ ===== MFM Tool Questions =====
+ These are questions and comments on how to use / usability of the mfms GUI tool.
+ 
+   * Q: Is there a way to change the brush radius? I see a 2 next to the nuke icon, but I don't know how to change it.
+     * A: Use the scroll wheel, with the mouse positioned over grey background in the toolbox
+   * Q: Is there a way to start back at 0 kAEPS? I cleared the grid, but I would like to reset the timer. I clicked Reload, but it doesn't seem to do anything...
+     * A: At present (29-Aug-2014 02:44:17AM-0600) the only way to reset the timers is to restart.  There's a lot of distributed internal counters and stats behind the main AEPS display so resetting it properly is a little more involved than might appear.
+   * Q: I would like to be able to change the variables of an Atom after right clicking, but it seems like the variables only appear on a left click, which changes the bindings.
+     * A: Good point!  Have to look into that!
+   * Q: Having the toolbox be a separate window would be nice so I could see the grid and the toolbox at the same time.
+     * A: mfms is a 'one window' app by pretty deep design, so that would be a major change.  But you can get much of the effect by using the scroll wheel over the grid to shrink it a bit, and/or use the arrows or Ctrl-Left-Drag to move the grid, so that the toolbox doesn't cover it up.

robust-first_computing

anonymous@undisclosed.example.com (Anonymous) — Wed, 03 Dec 2014 21:26:41 +0000

@@ -9,6 +9,13 @@
  ===== An alternative: Living computation =====
  
  There are other ways to compute, that offer different --- and perhaps more attractive --- tradeoffs, but which as yet have received scant research and development attention.  While serial deterministic machines were growing by leaps and bounds, that was understandable, but now those traditional architectures are increasingly struggling to grow further. 
  
- Viewed as a kind of computer, note how different a //living organism// is compared to a serial deterministic machine.  Deterministic machines are 100% completely repeatable -- same input, same output, while living organisms rarely do anything the exact same way twice.  Deterministic machines will crash, seize-up, or otherwise misbehave when virtually anything goes wrong inside them; living organisms, by contrast, can suffer grievous injury and yet survive, handle the immediate situation, and get away long enough to heal up and live on.  
+ Viewed as a kind of computer, note how different a //living organism// is compared to a serial deterministic machine.  Deterministic machines are 100% completely repeatable -- from the same inputs will come the exact same outputs --- while living organisms rarely do anything the exact same way twice.  Deterministic machines will crash, seize-up, or otherwise misbehave when virtually anything goes wrong inside them; living organisms, by contrast, can suffer grievous injury and yet survive, handle the immediate situation, and get away long enough to heal up and live on.  
+ 
+ ===== For more information =====
+ 
+ 
+   * [[introduction:where_can_i_get_more_information|Links to videos and papers]]
+   * [[introduction:key_concepts|Brief descriptions of key concepts]]
+

where_can_i_get_more_information

anonymous@undisclosed.example.com (Anonymous) — Sun, 16 Nov 2014 17:28:04 +0000

@@ -1,13 +1,16 @@
+ ====== Resources ======
  More information about indefinite scalability, Robust-First Computing, and the Movable Feast Machine can be found in the following:
+ 
+ ===== Videos =====
+ 
+   * **[[http://youtu.be/7hwO8Q_TyCA|Beyond Efficiency]]** (2013): Fifteen minute introduction to Robust-First Computing.  Transcript begins: //For the safety of society, and to build really big computers, we should pursue robust-first computing.//
+   * **[[http://youtu.be/helScS3coAE|Robust-first computing: Demon Horde Sort (full version)]]** (2013): Half hour introduction to Robust-First Computing and the Movable Feast Machine.
  
  ===== Papers =====
  
    * **[[http://www.cs.unm.edu/~ackley/papers/hotos-11.pdf|Pursue Robust Indefinite Scalability]]** (2011): Five page introduction for computer scientists.  Abstract begins: //For research insights and development potential, we should explore computer architectures designed to scale indefinitely.// 
    * **[[http://nm8.us/1|Beyond Efficiency]]** (2013): Three page //Viewpoint// essay on Robust-First Computing for general computer-literate readers.  See related video below. Subtitle: //Esteem for efficiency should be tempered with respect for robustness.//
    * **[[http://www.mitpressjournals.org/doi/abs/10.1162/ARTL_a_00117|Bespoke Physics for Living Technology]]** (2013): Eighteen page //Artificial Life// journal article on indefinite scalability and the Movable Feast Machine. Abstract begins: //In the physics of the natural world, basic tasks of life, such as homeostasis and reproduction, are extremely complex operations, requiring the coordination of billions of atoms even in
  simple cases.//
  
- ===== Videos =====
  
-   * **[[http://youtu.be/7hwO8Q_TyCA|Beyond Efficiency]]** (2013): Fifteen minute introduction to Robust-First Computing.  Transcript begins: //For the safety of society, and to build really big computers, we should pursue robust-first computing.//
-   * **[[http://youtu.be/7helScS3coAE|Robust-first computing: Demon Horde Sort (full version)]]** (2013): Half hour introduction to Robust-First Computing and the Movable Feast Machine.