Kartik Agaram I have next to no real-life experience with distributed computing, so I'll leave such questions to others. Everything I have personally used sucks (that's mostly MPI for parallel scientific computing).

+1 with Konrad Hinsen on the terribleness of MPI. I like Actors and pi calculus, but for networked things you really need to build for both component failure and network partition. Erlang is the best thought out thing in production that I've seen in this regard.

Kartik Agaram I think Smalltalk's original model (going back to Kay's 1-page description of Smalltalk) is that each object in the system represents a mini-computer (or better a computational process). I recall him writing somewhere that even by the late 70s he felt Smalltalk could be done better, and the official Smalltalks had reified too much of the interesting bits to be able to evolve.

To Stefan Lesser's point, if more SOCs exposed the microcode of the system, it would be possible to defer 'reification' of software to hardware until the last minute, providing a lot more flexibility. So you could imagine a VM that could customize the processor it was running on to optimize the way it ran, ie instead of JIT'ing the running of the VM, you reify the operations the VM needs to run efficiently down to the hardware level. From Kay: "Another example: all the Parc personal computers of various kinds were microcoded, and in the latter 70s you could sit down to any of them to e.g. run Smalltalk, whose image would be sent from a server, and the machine type would select the special microcode for the Smalltalk VM on that machine."

That quote was from a comment to one of his answers on quora starting with "We need to note that the plan": ` https://www.quora.com/How-old-is-cloud-computing/answer/Alan-Kay-11?comment_id=179237241&comment_type=2

I think Alan made a comment that's stuck with me for a long time - hardware is just reified software

I actually sent him my OP -- and he responded among other things with that exact quote 🙂

ah would love to see his response, if it doesn't feel intrusive to share

i have a bot that checks his quora feed, i've been devouring his answers and follow-on comments. Always feels like I'm getting a small peak into the blue plane. I wish that he could one day release a book or even a set of his collected writings in one place.

Actually it was only one other thing: https://www.youtube.com/watch?v=AnrlSqtpOkw&t=135s

Which was interesting to rewatch in this context.

Yep, I love that version of Smalltalk. I've been trying to see if I could get it running baremetal on a raspberrypi and give it to my kids and see what they can do with it

I'd love to hear if you do.

That video is depressing, considering that what we have today in terms of "personal dynamic media" is at the same time more complicated and more limited. As far as I can see, even today's Smalltalks (Squeak, Pharo) don't support this.

Kartik Agaram sure, will post here when I get it working. I'm using https://github.com/michaelengel/crosstalk as a base, with modifications to support the smalltalk version used above

I don't believe it is particularly useful to equate heterogeneous computing with distributed computing and use the same abstractions (especially something as high level as an actor model) because the constraints and failure cases tend to be wildly different

I don't know of any consumer hardware that will continue to run if say, its GPU just dies

but in a true distributed system (you usually) care about robustness for potentially many machines that have much different uptime requirements than a consumer device

Scott Anderson I'm going to play devils advocate here 😈

I don't know of any consumer hardware that will continue to run if say, its GPU just diesI have a direct counter example:

I have two GPU's in my laptop, the one bundled with my CPU, and an "external" Nvidia card. The Nvidia card regularly has driver failures and my laptop falls back to the on die graphics card.

This is almost seamless, and very much a distributed system. OS kernels handle these kind of driver failures all the time, and they are conceptually very similar to a distributed database that experiences a network partition.

Some more extreme examples are Plan9 "everything is a file" and EMACS TRAMP. Both are examples of abstractions that cross both file system and network boundaries with similar semantics and error cases.

referring back to my earlier story about my National Science Foundation work, there was one group of grad students working on GPU's, and another group working on distributed graph algorithms on AWS. We were part of the same umbrella project, and regularly exchanged ideas about how to solve problems.

The constraints and failure cases are not wildly different at all imo.

Sure, and there are ways in modern graphics APIs to explicitly manage that there are multiple GPUs. The thing is it's very rare that they have symmetrical capabilities, so if you have a work load that actually needs that Nvidia hardware and you switch to intel integrated graphics, you'll have a worse experience. A language with an actor model that abstracts heterogeneous hardware and treats it as a homogeneous distributed system won't really solve that

And making the cases where it doesn't matter easier doesn't really help anyone I guess? I mean potentially there is an interesting abstraction of a "command buffer" (a circular ring buffer that could look a little bit like messages in actor model systems) and an actor could be an explicit piece of defined hardware that has specific capabilities (both fixed function and code) but programming models and capabilities of different hardware are different enough that I'm not sure how useful it would be

Maybe there is a interesting use case where you can use local or remote compute for the same task and its entirely invisible (don't have a GPU and it automatically uses a cloud GPU)

Also device hang\device lost due to a driver crash is not the same as an actual hardware failure. The OS will recover from that, and as a system wide resource it doesn't practically make sense for applications to handle that. In some cases (most of the interesting ones) a discrete GPU failing and falling back to an embedded GPU is effectively a not working computer. Laptops switch regularly but desktops will by default have embedded GPUs turned off, and don't have the same switching capabilities. Consoles and smartphone generally have one GPU as part of an SOC, etc.

The reason I bring up command buffer as an abstraction is because new consoles have custom I/O hardware that uses a GPU style command buffer model for I/O requests, with the assumption that modern games will be making I/O requests at a similar rate they make draw calls. Game engines also generally use command buffers to send commands to a render thread (running on another core on the CPU) to drive rendering on the GPU. It works great when you are mostly pushing data/commands to another device, not so great for frequent two way communication though, because this pattern tends to be used in systems with high-throughput and high latency (relatively speaking, high latency for a GPU is still really low compared to an HTTP request)

I don't believe it is particularly useful to equate heterogeneous computing with distributed computing and use the same abstractionsUsing the same abstraction does not mean requiring the same constraints.

And continuing with graphics as an example, things like feature flags for OpenGL are used all the time to provide different feature sets depending on hardware capability.

Similarly, Erlang and most actor models have ways to query the available resources for a particular process. Smalltalk has this as well.

In some cases (most of the interesting ones) a discrete GPU failing and falling back to an embedded GPU is effectively a not working computer.It is a matter of opinion about what is interesting...

The fact that I can still use my laptop if one of the GPU's fails seems pretty damn useful to me personally, even if the experience is degraded.

In the network case, variable bitrate video is also extremely interesting. If my network is suddenly over saturated or degraded, I used to not be able to play a video on Youtube at all, or my video call would be disconnected.

With variable bitrate streaming, the quality is simply lowered.... Same abstraction, that has built in semantics for heterogenous capabilities (dynamically changing capability btw)

Not all applications can gracefully downgrade, and a ton of effort goes into supporting that. For example, Cyberpunk 2077 got delisted because it actually wasn't playable on last generation console hardware. If your discrete GPU dies and you're playing the game on PC it will be unplayable (either functionally or actually due to lack of capabilities). You could apply the same logic to machine learning training and other GPU tasks that require high compute. Also its great that your laptop keeps running, but I'm not sure how a distributed systems approach in a user land application programming language fixes that? Maybe the idea is it could make it easier for driver and kernel developers to implement local failsafe?

Not all distributed databases are usable if the network failure is bad enough, That doesn't mean the abstraction is wrong.

There are always failure cases that cannot be recovered from. It does not mean using an abstraction of heterogenous and distributed computing is a bad model (your original point iiuc).

Maybe the idea is it could make it easier for driver and kernel developers to implement local failsafe?This is exactly what things like micro-kernels and Docker do. IPC is a form of distributed abstraction.

I'm not sure how a distributed systems approach in a user land application programming language fixes that?The point of exposing these to the user application level is that the application can have a say in how the failure is handled. Cyberpunk 2077 maybe can't run if the GPU fails, but Microsoft Word still can. You want to allow both options.

I guess I'm stuck on... What do we get if we treat a local machine like a distributed system? What features of distributed programming are generally not necessary for local hardware? GPU programmers do have to handle device removed (https://docs.microsoft.com/en-us/windows/uwp/gaming/handling-device-lost-scenarios), which could mean try to reinitialize and reload, and that could mean using a different device, but it also could mean crash or quit. I'm focused on GPUs because I'm a graphics programmer, but I imagine you could apply this to any specific hardware (storage, audio, etc.) Maybe the issue is this all handled at OS level, should be to implement the OS in a different way rather than try to abstract over all OS APIs?

Similarly for security models. In docker or CGroups situation, you may or may not have access to a system resource depending on the security policy. Your application can decide how to handle that. Your database may try to set up a database on a certain file system, but if it doesn't have access, maybe it falls back to a memory backed store.

I'm focused on GPUs because I'm a graphics programmerI'm a database programmer, so this is fun to compare perspectives 🙂

I guess I'm stuck on... What do we get if we treat a local machine like a distributed system?

Maybe the issue is this all handled at OS level, should be to implement the OS in a different way rather than try to abstract over all OS APIs?Microkernels are the best practical example I can think of that try to do exactly this: http://www.microkernel.info

It's more about security and reliability. It does have a performance cost. (Which I'm sure sounds like pure pain to a GPU programmer lol)

Your example about cloud GPU is already here as well, That's basically what Google Stadia is.

When I started the thread I was thinking about all the ways in which non-programmable processors (built out of programmable components!) hide inside our computers. It's a place for bugs and especially security issues to hide. It might be an interesting exercise to ask how we might bootstrap a computer from a single tiny bit of RAM, either by building hardcoded circuits or requiring an upstream device to initialize them. I said "distributed computing" just because it was the closest term I could think of, but it did pull in unintended connotations that it's been interesting to see explored 🙂

It might be an interesting exercise to ask how we might bootstrap a computer from a single tiny bit of RAM, either by building hardcoded circuits or requiring an upstream device to initialize them.This sounds like the idea of a microkernel taken to the level of firmware / BIOS / UEFI. Sounds like an awesome research project to explore 🤩

I'm also reminded of a podcast I listened to a while ago: https://oxide.computer/podcast/on-the-metal-3-ron-minnich/

Google does some of this kind of thing on their servers, and also on chrome-books with U-root. (Trusting trust type stuff at the firmware level.)

It's frustratingly difficult because the hardware vendors do not want this. It has taken companies like Google, Facebook, and Amazon to strong arm them into opening up their firmware more....

Also, Alan Kay's quote as mentioned by @Naveen Michaud-Agrawal

"Another example: all the Parc personal computers of various kinds were microcoded, and in the latter 70s you could sit down to any of them to e.g. run Smalltalk, whose image would be sent from a server, and the machine type would select the special microcode for the Smalltalk VM on that machine."I remember talking to Kartik Agaram about this exact quote a while ago.

The closest modern equivalent we have is probably FPGAs.

Yeah I was probably being way too specific about what the definition of distributed system is now that we're explicitly talking about distributed systems within hardware. Back to the original post, what I know of FPGA architecture, it's laid out in a similar way as MFM

Blocks/shapes are just one projection that a projectional editor could choose. The good stuff is having multiple possible projections, as per what Christopher Galtenberg mentions. See also https://gtoolkit.com.

I fully agree with what you're trying to do. Data should just BE, and ways to create, share, and view it should be trivial. Good luck with this!

I've considered making a drag and drop JSON viewer and editor, that you can just plug APIs into, and then create functionality and views around. So for example, make it easy to get at the data in existing things like FaceBook or your bank account, and combine and interact with or however you want. Maybe something like that could be a good bridge from existing infrastructure, into something like what you're building

I did have a JSON version of this, and wrote a Node/Heroku server to adapt from multiple sources into it, including Twitter and dbpedia APIs and screen scraping from websites!

There's a talk I did about that at skillsmatter online somewhere

I'd love to see that. I'll look, but let me know if you find the link

I've been frantically updating the object.network page recently to try and explain things as simply as possible!

Yeah:

https://skillsmatter.com/skillscasts/3044-object-network-mapping-the-web

is really bad

😄

The "mapping the web" bit was added by someone else for some reason, I think there was a mix-up

And tag me, so I can respond? :)

The joy of slack for threaded messages.. Sorry, will do.

Yeah, and every group has its own rules, to add to the confusion. Sorry about that.

(Seriously. I just click follow on pretty much everything here.)

Consider Agda, for example this recursive set tutorial:

https://people.inf.elte.hu/divip/AgdaTutorial/Sets.Recursive.html#1

Not sure anything corresponds exactly to what you are looking for, but Lean (https://leanprover.github.io/about/) is certainly worth a look, as are other proof-oriented languages such as Coq's (https://coq.inria.fr/) underlying language Gallina. Computer algebra systems are another candidate. Axiom (https://github.com/daly/axiom) is huge but also the most likely to contain what you are looking for. There are also more specialized systems popular in specific branches of mathematics, which unfortunately I don't know much about.

Thanks both of you. I will look into them. Also, interesting to see what it (may) take to build such a system with an extension / library system built in so that people can take the basic system as extend it to the domain they are interested into

Fortran was designed to do exactly that

I mentioned this in a other thread but Pure Lang has many pieces that make it useful for both symbolic and computational mathematics

Do you have in mind examples how such a language would be used and what it would be used for? What kind of programming would you do with topology? If it is theorem proving in topology then lean seems like the kind of language you're looking for. Just curious.

I do not have any example right now. It was more of a curious question. However, I am interested in probabilistic logic programming (https://github.com/ML-KULeuven/problog). And machine learning. I have a strong feeling that we can use them together (https://bitbucket.org/problog/deepproblog/src/master/) however, I was wondering that whether we can extend the symbolic domain significantly. And from that thought, this one followed. '

Yeah, I've a big old directory of probabilistic programming resources, which I plan to ignore hoping for more coherent theory and practice to emerge before I get around to reading any. 😉

You might like: http://pll.cpsc.ucalgary.ca/charity1/www/examples.html as it is based on CT.

I saw corrupted files frequently, mostly when they are coming from the network and were cut in the middle, or when a stream wasn't working well, but also as part of memory dumps where some parts of the memory was written over etc.

In some ways the distinction between text and binary is arbitrary. Text files just have a whole ecosystem of tools that are able to parse (and display) the bits in a certain way. I expect any issues of corruption or error-correction would equally apply to both.

text files often indicate (to some extent) human-readable files and human-readable files have a lot of redundancy built in—all human languages do

Yep. When a human reads a file, they can eyeball it to see if it looks corrupt, make a guess at what it should have looked like, and manually patch it. With binary files, usually your parser just barfs. All the recovery steps a human performs have to be programmed in.

As to the actual question, the only time I can remember personally was from downloading ISOs: s couple of them failed their hash check and had to be re-downloaded. Bad disk dismounts are the other classic case, with a broader category of bad disk write/flush handling that can leave a file in weird states (https://danluu.com/file-consistency/). TBH I wouldn't want to hand-restore one of those files either.

Corrupted files have always been part of my digital life. The main cause: software bugs. Number two: aborted computation jobs, usually due to resource limitations on batch systems.

For programs that write serialized output, a corrupted file is usually just truncated. That is usuallyl recoverable. But when working on large binary files, random-access modification is quite frequent and can result in just about any mistake.

@Naveen Michaud-Agrawal The "advantage" of text files is that characters are encoded individually and each character only takes a couple of bytes. If there's an incorrect byte, the corruption is limited to at most two characters. In binary encodings, a single error (e.g. in a length field) can corrupt everything that follows.

But you're right, text files are basically a subset of binary files and all advantages they have could also be achieved in other (non-text) formats.

I think @Andrew F nailed it with "they can eyeball it". It's less of a theoretical math problem and more of a pragmatic "how long does it take you to figure out exactly what the file should be and what it is".

I worked at a data storage company so we'd corrupt binary stuff all the time in dev, it was really hard to tell what was broken when it was binary. I really wanted to, but never got around to, a to_json serializer so I could see system state in a structured, textual format.

Most people don't appreciate how easy it is to undelete a file on Unix:

• make the file system read-only (to prevent more writes)

• grep -n10000 the device of the hard disk, go get a coffee

• Scan the output in a text editor, find the right section, delete above and below.

If it's a binary file you now need more tooling.

+1 that the main benefits are legibility and the ubiquity of text-based tooling

in my case corrupted files I've had to handle mostly fall on two cases 1) truncated files 2) a file with a block of zeros at the end

Not to my knowledge is there anything online as a specification, because the system was constantly changing and being experimented with.

I understand that it's implemented as a superset of Lua which probably was getting desugared to Lua. IIRC from my convos with Joshua Horowitz is that the whole system (a couple years ago at least) has one system input "time" which advances everything else forwards.

There is a photograph of the source of the realtalk system in one of Bret Victors tweets. I believe it used either Ohm or OMeta as the parsing system.

My understanding is mostly from "Background of Realtalk" section from Omar's "https://omar.website/posts/notes-from-dynamicland-geokit/". Looks like while they've been fairly quiet recently they are still continuing on with research.

I took some photos and videos when I visited a couple of years ago (with the Bay Area FOC group) that I need to share

specifically I have some real-talk photos

Didn't get much but here are a couple

I believe this is a lot of the code that parses\desugars the natural language datalog query language used in "say" and "when" statements, there is probably a lot missing though

I'm also not certain that Dynamicland has made it. Walking by their old space in Oakland it seems vacated, but maybe they just moved

It has been a wild year with COVID-19.

Scott Anderson thanks, so most of those pages look like the pure lua bits.

Looks like they are still going - https://twitter.com/worrydream/status/1349606736047443968

I thought COVID might have done them in because of the physical computing aspect

good thing investors (or whoever is supporting the project now) aren't thinking so near term on this

Keep in mind that RealTalk isn't really documented because it was always provisional. Beyond two takeaways, the rest of the details (all the syntax, the use of Lua) are irrelevant.

• Loose coupling between components. They don't directly reference each other. Often physical proximity was the way of doing dependency injection. No need for explicit patching when valid wirings are mostly unambiguous.
• Having a distinction between "wishes" and "claims" where a "claim" tells you something about the world, and a wish requests that the world change to have some quality.Can't think of anything else. I mean there's the whole spacial/collaborative aspect of Dynamicland but that aspect is pretty obvious.

Recurse center has a project inspired by realtalk https://www.recurse.com/blog/132-living-room-making-rc-programmable and the code is online https://github.com/living-room/turing

@William Taysom thanks, I think you've nailed the underlying idea. Everything else (projection and computer vision, use of Lua) is just an implementation detail of the current manifestation. I expect that if touch-reactive eInk and arduino/microbits were cheap and easily programmable, the whole RealTalk system could have been built using that hardware.

Scott Anderson What did you make of DL?

I want to like it because of how much I love BV's work, but... it just doesn't click for me, from what I've seen...

I visited Dynamicland and tried to give Bret some ideas for fundraising. This was when they had lost the funding from SAP. My advice to him was that he should make a version that could be run on a single desktop (mini projector and cam mount of sorts) so that people could build these as kits for the home. I also suggested abstracting out the events similar to what TUIO has done. Not sure that that was part of his plan, but oh well....

@Vijay Chakravarthy "TUIO?" To me it seems Bret worries a lot about people misinterpreting his intentions and so an important part of Dynamicland was to maintain a certain clarity by making a hard break from conventional computational systems.

Working under the same roof as the IHMC Robotics Lab, I was always jealous of visceral immediacy of the robots. You can simply see people working on them whereas practically all screen activities have a certain disengaged, lazy posture. Since then, I've been keen to make the abstract more embodied.

It is somewhat unfortunate that reality developed a strong bias against the kind of close in-person collaboration that Dynamicland envisions.

https://www.tuio.org/

I actually think we are at the beginning of what will be a big shift in user interactions for computing. Given the prevalence of multiple devices and visual and auditory understanding of intent (via AI) I think that there is a big shift possible in how people interact with computers in both single and group environments. For the group environment just the fact that everyone brings their own touch surface (mobile device) is a pretty interesting model for collaboration.

I wonder if Bret is worried about people 'missing the point' if they work too much in the open, and only the surface ideas spreading memetically, similar to what happened when Jobs visited Xerox PARC and only saw/internalized one of the three things (the GUI) that he was shown at Kay's Learning Research Group.

I have been greatly inspired by Dynamicland and have spent the last couple years playing with these ideas (https://programmable.space). My thoughts on the Dynamicland system: The focus is on the objects and how they can interact and be understood, rather than the current implementation of code or the “papers and dots” Augmented Reality system.

Important points not related to the code or RealTalk implementation:

• Always on. Key to making the system more casual.
• 1-to-1 relation between seeing an object in the world and it having influence on the world. This is key to understandability.
• Use affordances of physical objects, rather than trying to solve them in code. The tangibility is important here, but using physical objects can also reduce the scope of what code has to do. For example, your code becomes simpler if you don’t have to worry about fitting modals, tabs, and substates into a single screen if you can separate them across many papers/programs. This also includes using the spatial relation of programs to influence control flow.

That being said, there are some interesting things on the technical side that support the physical side:

• Shared tuplespace is a good fit for ideas that are “the size of a room”. Data is pretty small and doesn’t need to run “at production scale” so it can be kept simpler and more understandable.
• Pub/sub like system using “claim”/“wish” + “when X” is a nice and simple way for programs to communicate.
• - The system bootstrapping itself is also interesting. There are a lot of AR-desk demos but being able to edit the system without having to switch back to a traditional computer GUI is cool.

@Jacob Haip programmable.space has a lot of really cool ideas in it. Thanks for sharing!

I was less excited about it after visiting, but I still like the ideas behind it. Most of my disappointment was with implementation, which is maybe the wrong thing to critique in a research environment, but it's still something that matters. Specifically the overall latency of the system was disappointing, it was challenging to code or interact with any programs that felt immediate. When I was there they said latency would be addressed, but it's also a hard problem given the implementation of the system. The other thing I didn't like so much was that claim\wish\when system wasn't well utilized in most of the tables they had in the space. That is, usually a single page or two felt like a self contained application, and the dream of a loosely coupled dynamic play space that required little coding to compose interesting and useful behaviors wasn't realized. There's no reason I could see that they couldn't support it, and some of the debugging tools gave a glimpse of that, but it was really hard to pick up a random page from one table, bring it across that space and have it do something interesting (or at all) with other pages. Designing a semi-shared set of common claims (outside of system level ones to access lower level drawing, audio, etc. functionality) would have made it more interesting I think.

My favorite demos were things that worked around these limitations and also showed something that would be tedious to do outside of the environment. Like the demo where you could draw multiple sketches and have them automatically animated on another page. Latency didn't matter, because you got much more immediate feedback than if you did this with a camera or a scanner in a traditional computing environment. Another one I liked was a simple book (like the equivalent of a CD album booklet) where you could turn the page and play different songs, with text with the song and artist name. In some ways the projector system might be a good visual equivalent to an audio home assistant (Alexa, Google Assistant, etc.) I really wanted to see more, here are a bunch of building block pages, compose them however you like. I think back to Nicky Cases concept for visual programming (below) in Dynamicland, and although I don't think I just want that, the actual act of programming in dynamicland was writing lua scripts on an extremely text laggy editor, with poor error\compile feedback, and I would have liked to build things with the same ease and in the same natural way as interacting with some of the demos

Scott Anderson Thanks for your impressions. Just to situate them, would you be able to say how long ago you visited? From what I understand the space is constantly undergoing change, so it could be that some of the physical implementation issues were fixed in later iterations.

The only detailed description I've seen online is Omar's geokit post, and that seems closer to the ideal of independent, loosely coupled play space (especially the ability to leverage other physical objects like the dial to interact with the maps)

It was in March of 2019 with a bunch of other current and former members of this Slack, I thought it was longer than that but it was just 2020 wrapping my sense of time :)

Geokit is still one of the few detailed descriptions online

There are a few others I believe

But nothing as comprehensive

and his followup post on using raspberry pi's as the IO for DynamicLand

there's this but it's not very technical, more about the history of Dynamicland and it's creation https://tashian.com/articles/dynamicland/

There is some info about pieces of Dynamicland that preceded it, like natural language datalog and La Tabla

Yep, I've seen those.

@Glen Chiacchieri talking about Laser socks got me excited about the space early on, this was years before my visit http://glench.com/LaserSocks/

The tashian article is interesting when talking about the funding aspect. I've often wondered how much funding CDG would need per year - Alan's talked about how he would 'buy' the future to be able to build/research it in the present.

but the Geokit blog is the only comprehensive public write up about how the system actually works, specifically what its like to make a program for Dynamicland

@Naveen Michaud-Agrawal iirc they were looking for $60mm to be around indefinitely or something on the order of 1mm-500k/yr

The funding model is unsustainable. My advice to Bret was to use the creativity of the team to fund small kickstarter like projects. There are immediate applications of the technology to education especially childrens education. I even had a few venture capitalist friends (I know, thats an oxymoron :)) that suggested that funding for such initiatives could be arranged. I think its better to be in control of your own destiny than to be beholden to large corporate grants where the political climate change can cause those grants to vaporize in a heartbeat.

Garth Goldwater when I spoke to them they were burning 150k a month I think.. the facility itself must be about 30k rent. The individual salaries for about 10 researchers would be about 2 MM a year fully loaded. So ballpark I assume around 2.5 M burn per year.

that sounds about right to me

that would be around 4% of 60mm

Operating cost per facility is likely to be 500k - 1MM per year. I think they wanted to replicate this model for large number of facilities. IMHO it would be better to miniaturize the model (raspberry PI + some tiny projector), hook it up to the cloud (so you can do realtime collaboration) and sell it for a bunch of use cases. They could even then fund the library model plus allow educational institutions to copy it for free.

@Vijay Chakravarthy I think I can tell you with some certainty that your ideas about funding are very off the mark for how Bret wants to run research

I would bet that in Bret’s thinking “products/markets are where research goes to die”

They could have moved to a less expensive location, but yes researcher costs aren't going to be cheap no matter what

@Glen Chiacchieri I’m well aware of that. I’ve done both research and entrepreneurship - IMHO I feel that Dynamicland had potential not just to be a research facility but also to influence real product development.

“products/markets are where research goes to die” - and Bret would be wrong. I see a full reflection of the naivety that came along with Xerox labs and other places where people treated the commercialization of technology as something beneath them rather than a problem to solved.

Time travel debugging

No more apps https://www.youtube.com/watch?v=ntaudUum06E

Some overlap with @Jared Windover’s proposal, but not exactly the same: malleable systems https://malleable.systems/

infra-style interactive coding: https://m.youtube.com/watch?v=L8VpCCIxuME

(splitting the messages so preview works): https://m.youtube.com/watch?v=8k6n1m4leQo

(each video is about 2 minutes): https://m.youtube.com/watch?v=hs42TeFytEk

Dissatisfaction with the status quo, but one specifically informed by an awareness of history and the myriad possibilities just waiting to be explored.

Democratization of coding

FOC is not "No Code" or "Low Code", it is "Grow Code"

Getting away from keyboard + mouse (and even flat screen) interactions, to make digital things. Bret Victors 2011 rant on http://worrydream.com/#!/ABriefRantOnTheFutureOfInteractionDesign is still very much relevant. I hope I don’t have to stare at a screen to be a digital maker in the future 🚀