Hi, I'm Lynn Clark, and I make code cartoons. I also work at Fastly, which is doing a ton of cool things with WebAssembly to make better edge compute possible. And I also am a co-founder of the Byte Code Alliance, which is building a vision of a future WebAssembly ecosystem that extends beyond the browser. Before I start, I want to say thank you to the organizers for inviting me to speak here today. I was really excited when I was asked to give this talk. In the WebAssembly world, we've been looking at many of the same problems that all of you in the cloud native community have been looking at, too. For example, one problem we've been thinking through is how do you deal with code that depends on the concept of a file system in places where you don't actually have a file system available? Or another problem, how do you create a clear separation between the business logic of an app and the orchestration of that app? So we have a lot of goals in common, but our communities have been coming at these problems from different perspectives and bringing different contexts to the conversation. So I think that there are lots of conversations that we can have between our communities combining these perspectives and seeing what opportunities they open up for each other. Before I dive in more deeply into how we've been thinking about these things, I want to explain what made us start thinking about them in the first place. So why was WebAssembly created? The browsers wanted developers to be able to compile code bases that were written in languages like C++ and Rust to a single file and then have that code run at near native speeds in the browser. And they wanted it to run in a very secure way in a well-isolated sandbox, because you need that when you're running code that you just downloaded from the internet that you don't trust. To get that near native speed, the byte code for this WebAssembly binary needed to be as close as possible to the native instruction set architecture, or ISAs like x86 or arm64. But without specializing to any particular ISA. So this meant creating a really low-level abstraction over the various ISAs. This made it easy to run the same binary across a bunch of different machines with different machine architectures. And this got developers really excited, even those that were working outside, completely outside of the browser. But as these developers started bringing WebAssembly to the server and to other places, they left some of the key properties of WebAssembly behind. They were giving these WebAssembly binaries full access to the operating system, system call library. That compromised security, and it also compromised the portability, since now the binary was tied to a particular operating system. So with this, we realized we didn't just need an abstract ISA, we also needed an abstract operating system, one that made it possible to run the same binary across a bunch of different operating systems while preserving the effectiveness of the WebAssembly sandbox. So we started work on WASI, the WebAssembly System Interface. The goal of WASI is to create a very modular set of system interfaces. These include all of the low-level kinds of interfaces that you'd expect from a system interface layer. But it also includes some higher-level ones, like neural networks and crypto. And we expect many more of these higher-level APIs to be added over time. These interfaces need to follow capability-based security principles to ensure that we maintain the integrity of the sandbox. And for the most part, these interfaces also need to be portable across the major operating systems, although we are OK with system-specific interface modules for certainly narrowly-scoped use cases. It was when we started trying to make this portability work that we started getting to some of the problems that I mentioned before. These problems started coming to light when we were thinking about a pretty core concept in many operating systems, the file system. A lot of code to date depends on the file system. And the code uses the file system for many different tasks. So it's where you persist data. It's where you share data between two programs that are running in different processes. It's where you put the code for executables. It's where configuration lives. It's where assets get stored. Files are like these Swiss Army knives that are used for all of these different tasks. But as we were thinking about all of the places where we wanted to run wazzy, we started wondering whether or not this was the right abstraction to use. The file achieved its central position and system interfaces during a very different time in software development. There were a few operating systems that really entrenched the file in this privileged position. And these operating systems were first being developed in the 1970s and 80s. This is when you had the rise of the mini computer, and after that, the personal computer, mostly to help with office work, which, of course, was organized in real paper files. For these kinds of systems, having a file system and having direct access to that file system made a whole lot of sense. If you look at the systems that we're building now, though, things look a bit different. We're still building applications for the personal computer. But with things like browsers, we started running applications inside of other applications, places where you probably don't want the interapplication to have direct access to the file system. And then, as we started moving applications to the cloud and edge networks, and as IoT devices started proliferating, we suddenly had an entirely different landscape where direct access to a real file system was the exception, not the norm. And on top of all of that, as we've moved towards having more modular ecosystems of open source code that you plug together, like MPM or PyPy, these file systems are presenting maintainability and security problems. Because the way that these file systems are used is basically like having one big giant pile of global shared mutable state. Given all of this, files don't really feel like the right kind of universal abstraction anymore. If we're going to try and break out of this file-centric paradigm, we need to think about what a file actually is and what it does. So what exactly is a file? Well, a file consists of two things. Some bytes that encode content, and you can think of this as an array or stream. This is the data. And other bytes that contain metadata about that data. So this includes things like the name of the file, timestamps, permissions, and what underlying device the file is stored on. It's the second part here where we start to have problems. When you're working with this metadata, that's when you need to know about the conventions of the host system that you're running on. But when you think about what most programs are actually doing, what they actually care about, most of them only care about the data. They just want to get that array or stream of bytes and start working on that. They don't care about where the data lives. Now, there are, of course, some applications that do need to know the details of this metadata as well. So for example, if you're building a backup application, you, of course, do need to know the file names of those files. But most of the time, the metadata is unnecessary for what a program is trying to do. My colleague and the architect of much of WASI, Dan Goman, has called this distinction the difference between compute and meta compute. And he had the thought that what if we were to push as much of the meta compute out to the edges of the system as possible, either up to an orchestrating module or even better out to the host itself. To see exactly what this means, let's walk through an example. Let's say that you're writing a utility that shrinks an image down to a particular size. And you want to run this utility from a command line. How would this work in the file system-centric paradigm? We have the host system that's the outside the gray. And the WASI module is running inside of the host, inside of this white box. So the WASI module would be passed in an array of arguments that are all strings. And would take the string that's at a particular index and use that as a file name. And then that WASI module would use that string with the open syscall to get a handle to the file. The operating system would hand it back a handle. And then the WASI module would read the bytes from that file using the handle. With this, we're requiring the module to think about the file system. We're requiring it to think about the context that it's running in. But this module wouldn't really need to know about these details. All it really needs is the stream of bytes to come in so that it can operate on that stream. So now let's try moving this meta compute out of the module and over to the host. Now by convention, a program's main function takes in a very generic set of parameters. So for example, in C, it takes the arg count and then a pointer to the array of strings that are the args. But let's say that we introduced a convention and tooling support for more application-specific parameters. For example, let's say that the main function for this application accepts a stream and returns a result that contains either a stream or an error. When you run this on the command line, the host will be able to look at that string and also see that the type that was asked for by the program is a stream. And the host would know that it can convert a file to a stream. So instead of just passing in a string, the host would instead open the file itself and get the handle, which the host would then use to pass in the stream of bytes to the WASM module. And with this, we've moved all of that meta compute over to the host. So this module no longer has any concept baked into it of whether or not there's a file system. This makes the code more portable. And this architecture also makes things more secure because this way, we didn't actually need to give the open sys call to the WASM module either. And so if this WASM module were to get exploited or were subject to a supply chain attack, it wouldn't have access to open files willy-nilly on your machine. Of course, none of this matters if developers don't use it. We need to have a gradual adoption path. We need a way for everyone in the community to transition to this new paradigm at their own pace so that the whole community doesn't need to move and lock step. We have three different options for how to compile a module to use WASM. And these three options represent that gradual adoption path. So let's say that you already have some legacy code that you wanna compile. And this code makes extensive use of the not so good parts of traditional file system APIs, the ones that bake in expectations about the host environment. In that case, you would signal to the compiler that you wanna use the legacy file system interface. Now, this might be through a flag or through a target triple. This would link your code against a version of libc or whatever your languages standard library is that's implemented in terms of the WASI file system interface. And this is in many ways the same API as the file system API exposed by POSIX and other system interfaces. So your code can act like it has direct access to a file system, which it might in some cases or the host might provide a virtualized file system. Either way, this looks pretty much like the run of the mill file system APIs. So your code would not have to actually make any changes. You wouldn't have to make any changes to your code rather. Now this code would not work on hosts that didn't either provide direct access to the file system or that virtualized file system that I mentioned before. So it wouldn't provide the full portability but it would be an easy on ramp to moving code to use WebAssembly. But what if you want the portability and you also want the isolation between different modules that WebAssembly can give you where you aren't sharing that global file system between modules. For that case, we're providing a compatibility layer. The developer would still write their code using the languages normal file APIs but in this case, what we're currently thinking is that the host wouldn't be providing the file system itself. Instead the module would be virtualizing its own file system. And these quote unquote files would be in the linear memory of the WASM module. This means that we don't have the global shared mutable state problem that the file system introduces. Even though these look like files in the source code, under the hood, they would use a different set of types WASIO types. And this would give them that full portability. However, this virtualization would introduce some inefficiencies, including larger file sizes for the WASM module. So in the case where you want full portability and you want that efficiency all at the same time, you would use a different API in your source code. You would use the WASIO API directly. So that means that you would change your code. Instead of passing file handles around, you'd be passing IO types like streams and arrays of bytes around. And with this, the developer no longer even thinks in terms of files, it's all just these IO types. The developer doesn't think I have a file with this name in this directory. I'll open the file and read the bytes from the file. They just think I have a stream of bytes. So this means that the code really can run anywhere. It doesn't matter what the host system, all systems can represent these basic primitive types. And we've completely gotten rid of the potential for the global shared mutable state, while also eliminating the overhead of the per module virtualized file system. This path also potentially opens up opportunities for further optimizations because the engine now has more detailed type information. Now, in talking about these three options, there's something I want to be clear about. You don't need to make the same choice for all of the different modules in your app. Part of this gradual adoption path is having the ability to convert certain modules before others. With both the second and the third option that I just talked about, you're using the WASIO types either explicitly or implicitly. And in both cases, you're not expecting to share the file system between these two modules. So this means that you can use these two modules together and they can simply pass values back and forth between each other. Now, it's not quite as trivial to plug these modules up to ones that use WASIO file system, but it's still pretty easy. If you want a module that's using WASIO file system to call something from a module that uses WASIO, then you just need to have some code in between to extract a stream or array of bytes from the file's content and pass that into the WASIO module. There are some kinds of modules that will always require full WASIO file system that can't use only the portable parts of the file system. But we expect this to represent a very small fraction of the modules that developers are creating and we're hoping to see the rest of the ecosystem gradually migrate to only using WASIO. So this is the kind of thinking that we're applying as we're building out this new ecosystem. How can we move these details out to the edges so that orchestrating code or the host can take charge of them and potentially optimize them? And it's one of these potential host optimizations that I want to end with. Just to get everybody's mind to start turning on what this paradigm could potentially open up for Cloud Native. And this is just one opportunity that we see, but I'm sure that there are more that others who are more familiar with Cloud Native will also be able to see and we're excited to explore those more. Now this opportunity has to do with requests between containers and how to make those faster. So let's walk through what happens when you make a request. Though I want to be clear here, this is just based on conversations I've had. I haven't actually set this up myself and stepped through it. So there's a chance that I've gotten some of the details wrong here, but I think that this is at least directionally correct. So let's say that you want to make a request to another service in another pod. What does it look like? The data that you're sending over gets serialized using a format like protobufs and this is saved into memory in user space. And then the system makes a syscall. The memory is copied over into kernel space memory. So that's two copies already. And now let's say that you're using a sidecar for something like a service mesh. So that sidecar is another container in the same pod. The data gets sent over to this container as an incoming packet. The data gets copied again into kernel space memory by network drivers. The data is then copied into user space of the sidecar proxy. And then the system deserializes the data into objects that it can use. And only then does the service mesh policy actually run on this data. We haven't even gotten the data out of the pod yet. We still have to go through steps one through four again to get the data out to the network. And then when it gets to the other side this whole process happens in reverse. Now two thirds of the steps here were actually to make a request on the same machine. They were to pipe the data into that sidecar. And you'll see that the documentation about the sidecar pattern calls this out as a trade-off. These docs suggest that you ask yourself whether the isolation is really worth the additional overhead that the sidecar is going to introduce in your use case. But this overhead isn't inherent to the problem. We can actually eliminate this as a trade-off. Since we can do fine-grained sandboxing and wasm we can actually make this relationship between the container and the sidecar much more efficient even running them in the same process. But we still get all of the isolation between the two and possibly more depending on how they were using a file, system or volume. And because of this we don't need the socket to be our interface between the isolated units of code. Instead our interface is just typed function calls. To communicate between these two we simply do a synchronous function call on a single thread stack. We do direct register copies and potentially direct memory copies if they're needed. There's no intermediate serialization and deserialization step here. No heavyweight calls to the kernel or inter-process communication. This actually puts us in the nanosecond range for calls between these two. And this would be much faster than the call we just looked at from container to sidecar. However, sometimes you actually do need things to be on different machines across the network. And it would be inconvenient to have different APIs for representing that and to have to change which API you're using in your source code based on whether or not the other container is on the same machine or not. But we don't have to do that. In this paradigm, we've moved all of the decision-making related to where the code is running out to the edges. So the module that you'd write would import the callee, specifying a function signature that's appropriate for cross network calls. So for example, allowing for various network failure modes and supporting non-blocking. Now in the case where the callee is on a different machine, the host would take care of serializing the data and streaming it over the socket. But if a service mesh is being used, the host would instead supply a proxy module that's on the same machine using the much cheaper calling convention described before. Now the important thing is that it's the host that handles this distinction, not your code. And so in this way, you can get the optimal performance when you're talking to a container on the same machine while not sacrificing the ability to communicate with a container that's across the network. We don't have all of these pieces in place right now, but once we do have these foundational primitives in place, we think that someone could build this kind of efficiency into the existing cloud native ecosystem. And we're excited to explore this further. We'll be writing about all of this more over the coming months as we push these standards forward. And we'd be very interested in hearing from people in the cloud native ecosystem about your use cases and about what you see this kind of architecture opening up. Thank you again to the organizers for inviting me and thank you all for listening.


Welcome, everyone. Thank you for coming. This session is using Kubernetes and OpenStack for CPU and GPU intensive workloads. Really, what the session is designed to do is to explore where those make sense, when they make sense, and then how you ultimately be able to do something like that using things like OpenStack and Kubernetes to drive and where those workloads are most appropriate. I'm Marco Cepi. I work at Canonical. I lead up and am interested in things like Cloud, Cloud-native architectures and really pushing the next levels of computing, getting every ounce and drop out of my CPU, my memory, my disks, and my GPUs to make sure that the smallest footprint possible can get the most amount of performance. Because of that, we actually tiptoed to different territories. What I want to do is I want to actually just briefly recap what we're talking about when we talk about Cloud. Because at the end of the day, there's lots of different things that help define Cloud. But at its core, it's essential. The way I view Cloud is you have effectively the commoditization of consumption of three things. Compute, as in I've got VMs that give me instances that allow me to have CPU time. I've got network, which allows me to get network connectivity between more than one instances in my compute. I've got storage, a way to persist in accents, and utilize storage in an on-demand fashion. At its core, that's what Cloud is. Now, of course, Cloud as a scope goes way beyond that. We've seen this in the Upstack Projects. There's lots of other things that are adding on-demand service value additions, whether that's things like DNS, or load balancers, or databases. But at its core, all of these things are to provide commoditized accessibility to these things, which is traditionally a lot more harder to get access to. So why I want to talk about Cloud at its core is because really the thing we're going to be focusing on, we're talking about CPU and GPU intensive workloads, is the compute layer. The compute layer really boils down to those two things. At its layer of compute, you have access to either CPUs or you have access to either GPUs, or both rather, I guess, it's not mutually exclusive. But the idea is that at its foundation, a Cloud platform should provide you the means to abstract and access these things. So what's great about OpenStack is that it does that for you today. Right now, if you have an OpenStack running, running in one of the more recent versions of OpenStack, you can actually go ahead and define a way to pass not just CPUs to your virtual machines, but also pass in PCI devices directly and access GPU to hardware. That's in your Nova compute units. So I want to focus on GPUs. I think everyone here understands the core functions of what CPUs provide you when you're running workloads. It's the way to actually do the logical calculations of the tasks at hand, whether it's processing traffic from web server, managing with record lookups in a database. That is effectively CPUs. But what I'm talking about is why GPUs, why GPUs are becoming such a hot topic today, where they came from, why people are using them in computing and outside of just in your laptop video card as an example. So what we've really got is the rise of a general purpose GPU, something that's more than just a graphics processor unit. It's actually something that allows you to do computation cycles in a much different fashion at a much higher rate. So this is effectively what you find in your computer today. It's a CPU, it has a bunch of cores, there's a caching layer, and then on the motherboard you have a system memory. What's interesting about this model is it's designed in a way that's to process certain instruction sets really well. So if we're dealing with code that branches a lot at a lower level, it has a lot of taxing computations to take care of, the parallelization of multiple core CPUs is designed to tackle that. But it's not always the most efficient way to handle different types of workloads outside of just deep nested tree branching and code executions. That's what GPUs come into. GPUs started as a way to give you graphics and display. I mean, back in the days of Amiga, you have a simple way to actually have a dedicated board handling the graphics instructions and doing a refresh of lines on screen. What that came into is as GPUs and displays and monitors became more dense, more highly available, cheaper to consume, we actually saw GPU vendors building discrete cards that can handle parallelization of tasks in a way that gives you from 0 to a line refresh much faster. To achieve that, they actually started packing more dense cores, using more expensive but higher throughput memories and reorganizing the architecture of the boards in a way that is actually super conducive to doing parallelization of very shallow branching but high data throughput. So being able to process a deterministic route really quickly without doing too much instruction sets. At the end of day, what this gets you is from my laptop, from your gaming device, the ability to push a lot of pixels at the same time. So that's what a high bandwidth GPU gives you today, that's what this market pushed into. What was realized is that it's actually more than just graphics that actually gives you the ability to utilize these things. So there's other data models that can harness GPUs in a way that would provide them with the parallelization and the density to execute these things faster than on a traditional CPU architecture. So what we're getting into is what actually works well for GPU processing, what would you actually want to use GPUs to process instead of CPUs? So we look at things like instructionalization parallelism, that's your traditional workloads today. Things like databases, web servers, caching softwares, network functions, things that have been written in instruction sets that work against CPUs and that could potentially utilize one or more core, but have very complex branching instruction sets. We do a lot of complicated routines to produce the results. What we're seeing data parallelism come into place, where you can actually utilize more cores to produce and render faster output, is in the areas of rendering, graphics cards for rendering data to screen, rendering actual frames for movies and things of that nature, and also things like transcoding, where you're actually dealing with, again, that high velocity of data, that high volume of data to produce a result, where splitting those out into hundreds of thousands of jobs on a single card, is much faster than having it split between one or two or three cores in a CPU. Because of that, what actually happens is in some arenas, this is mostly in the areas of machine learning, blockchain management, in memory, in process deep learning applications. They have the same problem exists, very shallow code branching that you have in things like rendering and transcoding, but can actually benefit from a lot of data parallelization, where you can computate a bunch of things very shallowly, very quickly, by using the high bandwidth data model. So that's where we're seeing these applications that are springing up, things like TensorFlow, which is Google's machine learning library, Ethereum, which is a blockchain-backed cryptocurrency, blockchain itself as an item, Apache Spark, which does in process computations for big data sources, and many, many more applications are applying to find where we have data models that are much more denser, with very little actual computation driving to be run against them. Because of this, it does very well to that model. So I want to walk through an example here. Most of these new breeds, these breeds up here at the top, TensorFlow, Ethereum, et cetera, because they are built to be stateless in that they're given an input, they produce a computation, they produce a result, and store that somewhere else. A lot of these new products will be picked up and used are using things like Docker and Ubuntu to develop and actually build a way to deliver these things at scale. So not only can they utilize multiple cores, thousands of cores on GPU, but also be able to utilize multiple hosts running multiple GPUs to increase the parallelism of tasks. So because they're using things like Docker and Ubuntu, it makes an interesting intersection of how do you actually start utilizing these in a team? A lot of people here today will either have an open stack or a building open stack or building a cloud that people can access. If your cloud doesn't provide GPU resources, what oftentimes happens is these teams won't be able to actually execute effectively their tasks for data processing, and that could be numbers of things. With it's training deep learning models, using machine learning to do predictive analysis, inline processing of data streams, all these things that lend themselves very well GPU workloads will be hit in orders of magnitude and performance when done just on CPU resources alone. So this is where Kubernetes comes into place. So open stack today can absolutely give you instances with CPU, with memory, with networking, with all the things you need in order to run general workloads and even specialized workloads, including GPU deployments.  Because things like VMs from an open stack cloud, and Docker containers are so different in not just how they're produced, but also how they're managed and how they're deployed, it lends itself to a new breed of systems to manage these things. And in fact, they become very complimentary. So Kubernetes itself is really just a management platform for Docker and Docker style containers. And what it's giving you is the ability to actually say, here's how I, using this new format of delivery mechanisms, this is how I consume the general compute, networking and storage, all of these components, but at that level, at that Docker style container level. So it becomes very complimentary in that, in a typical data model that you're running these new breeds of applications, these new data science type things, these new high performance throughputs, almost all of them are stateless by nature because state itself becomes a bottleneck for computation. If you have to continuously flush the disk, you're not using the latest NMV SSD disks or on memory chips, it actually becomes the bottleneck compared to your CPU processing power. So because of this, what you normally see is there's a set of persistent storage that's modeled outside of this workflow. And in fact, what you find is data scientists who usually lever just the stateless portions of it inside these Docker containers. And what you have is a pipeline of delivery saying I have an ingestion process that stores in a database, on a file system, to a disk, to an HDFS volume, to a number of different places. And this is something that's persistent. This is something that has to actually exist and persist state. This is where you'd wanna run VMs. You don't normally wanna run a virtual machine, sorry, a database service in a Docker container because if that container goes away and it's not set up properly and it's not morphed and configured, you'll lose all that data. And that's not something you normally wanna do when you're talking about computations. When it comes to running and executing multiple cycles of data training or analysis of data streams, those lend themselves very well to being stateless. They boot up, they're given an input, that data's processed, it's exported somewhere else and that process shuts down. It's done, it's done its thing. There's no need for it to persist state which is why they're typically modeled at things like Docker containers and Docker style containers. So because of that, this becomes a very complimentary thing where normally what you'll see is teams that are doing these things will run in a Kubernetes on top of their OpenStack or potentially alongside their OpenStack where they're using OpenStack and traditional VMs and the things that we've come to learn and appreciate and that commoditize resource pool to spin up and store all their persistent data, all their persistent management but then using Kubernetes to get that same style, that same flow, that same feel before that Docker container process. Instead of having to go into a VM somewhere, install all the tool chains that you need, then go and launch those containers manually and then go manage those processes. How do I scale them up and such? Things that OpenStack is done for us, for bare metal and for hardware is done at that same level whether it's on an OpenStack or next to an OpenStack or even below an OpenStack. That's what Kubernetes is looking to achieve and that's where these two intersections become really interesting. So I wanna show a few examples of what an output workflow would look like for these things. And then I wanna show how you can actually get started today if you're using Ubuntu and you wanna deploy, if you have data scientists that are itching to run these processes and to really start maxing out things like GPUs and CPUs, how simple it would be for people to get started doing so. So this is what we're looking at for this demonstration. We've got a data ingest pipeline. This is actually just grabbing a huge pool of images and putting it on an NFS file storage. Nothing particularly fancy or necessarily stressful. And then we're gonna be using TensorFlow to help train a model that we've predefined and then evaluate if this pool of images actually matches a set of criteria that we've defined in this model. So is this a cat or is this a dog which is the kind of typical data evaluation for a TensorFlow workflow. And so what we've done ahead of time is we've said here is a group of pictures of dogs and here's a group of picture of cats. And we've trained this model and we have a huge pipeline of hundreds of thousands of images that are sitting in this NFS storage. And we're gonna use TensorFlow in Docker containers running on top of Kubernetes using CUDA and NVIDIA GPUs to go and process the cycle through does this actually match a dog or cat and give me an output. And then finally serve those results. So the first thing we've done is we've deployed Kubernetes. And once Kubernetes is deployed you're given a dashboard like this. And this is actually very similar to what you find in Horizon. It's a dashboard of all the things you have running inside of your Kubernetes. In this case you can see we're running a set of workloads. Gives us the idea of how much CPU usage is being moved across the cluster, how much memory is being utilized. And all these are running on top of a GPU enabled set of servers. So this is what our TensorFlow job looks like once deployed. And TensorFlow itself has a dashboard for its own application. Much like many applications today there's some way to log in and view what's happening there. So once we're training this model what you see is something like this which gives us an output of here is all the data we've crunched. Here is the outliers. Here is the evaluation testing. Here are the peaks and the wanes. And then furthermore from there here's the idea of actually a standardized curve of how accurate our estimations have been. Where using a data training model we go and back and assert is this a cat, is this a dog based on a set of images we've already had. So how accurate are we actually translating these things? And we can see here that after a few moments of time we actually get pretty close to a 90% certainty that what we've guessed is actually accurate. So I'm gonna switch out of this and actually show what this looks like to get something like this running. And while I'm doing so does anyone have any questions so far? Yeah, absolutely. Let me get rid of this. Cool, that worked. Okay, so on this example here since I don't have any GPUs at my house that I could use for these things I actually spun this up against an Amazon cloud using their P2 instance types. So it's K80 NVIDIA GPUs. I've had other people in other sections. A few folks over at NASA are using this same methodology to do different computations for machine learning statistics on rocket analysis. And a few other folks are using this same methodology for doing rendering large scale rendering of 3D models. So it's applied at varying levels. NASA's doing this on bare metal as NASA scientists. I've did this in a public cloud and then the GPU rendering farm is actually running a hybrid of both OpenStack and Kubernetes for their different persistent volumes. So let's go ahead and see how we booted this up. So the first thing it is I've already configured a cloud endpoint. Again, I don't have an OpenStack readily available for me to show this on OpenStack but this was applied in the same way. Now, what I've done is I've installed a tool ahead of time called Chandra. So Chandra is just a way to get a really good idea of a starting point for a model for software. In this case, for building things like OpenStack clouds, for building things like Kubernetes clusters, et cetera. So I'm just gonna go ahead and run Chandra up. Yes, I have a small screen.  If you wanna be deploying things like Kubernetes clusters, OpenStack, other interesting pieces, we're gonna go with Kubernetes and a Kubernetes core deployment. And so, from here I can choose where I wanna deploy this actually. So there's a set of endpoints. If I had an OpenStack cloud, you see OpenStack, my OpenStack cloud listed in here. There's a different set of exit points for this to be deployed onto. And what ConDrup is gonna be doing for us is actually take a set of starting examples. So I have an example topology that I wanna start with. One master control plain service, several workers on a GPU. And I can then use this to manipulate that, scale my cluster over time and manage it. For the sake of this, I'm gonna go ahead and use a pre-existing cluster I've turned up. And we're gonna do this on Amazon, US West. And so what ConDrup's gonna do is gonna say, hey, here's a list of the applications I can deploy. So this is just a standard Kubernetes topology. You've got etcd, which is its data backing store. This is very similar to how you would leverage my SQL or another database store inside of OpenStack for coordination of services amongst other. A Kubernetes master component. This is the API server. This is the identity manager. This is the controller manager. The schedule manager. And then a worker which is actually the effectively the comparable NOVA for Docker containers effectively where you actually run your workloads. And then we're using Flannel for an overlay network, but this could be potentially something else. I'm gonna keep the default topology because it's probably the easiest. I'm just gonna go ahead and deploy. So this is gonna go ahead and run through deployments. In a few moments, this will come back and actually execute this on my cloud. So this could have been me booting up and OpenStack cloud using PCI pass-through profiles to give me actual access to GPU hardware. Or in this case, I'm using Amazon to give me P2 instances to actually have access to GPUs on demand from a public cloud. What's great about these things is because we're using things like the standard upstream Kubernetes mechanisms, it actually gives us a chance to really do some interesting things with Kubernetes where we can use our local, either bare metal or our local OpenStack to deploy a cluster. And as a team or resource starts to grow and they no longer can be tenable on that cluster, they can actually use and burst out into some other public clouds, whether that's Google's hosted GKE or whether that's Amazon, another cluster deployed in Amazon itself. By the end of all this run, what you're presented with is kind of an actual view of what's been deployed. So this will take a few minutes to run and it's not interesting to see how it's deployed, but you'll see how you can actually start utilizing it. So I have deployed this cluster just a little bit ago. I would say probably about 10 minutes ago. So let's see what we have here. Yeah, so 15 minutes ago I deployed this cluster. This is that same cluster, it's running on US East One. And it's got a GPU enabled worker on it. So what we can do now is using this by having this setup run, all the things that are required to actually operate and manage a Kubernetes for GPU workloads. That's enabling flags, making sure drivers are installed. All of those operational components that would normally take days, maybe even weeks to go and actually get assessed out are all managed by using these tools, ConDrup and such. And what it's doing is actually giving us operational insights and expertise to manage that Kubernetes cluster and all the underlying pieces below it. So let's just give you an idea. We'll see that we'll run the NVIDIA SMI command which shows us what's actually on that box. So on this worker we happen to have the NVIDIA Tesla K80. No processes are currently running and it's driver version 375.51. So what it's done is automatically detected the hardware running on there. It's deployed all the drivers required and configured Kubernetes in a way that knows that it can now schedule GPU workloads on that box. So what I'm going to do is just run this same example. Oh, one second. And while I wait for this example to start spinning up, does anyone have any questions for me so far? Yeah. Yeah, that's probably one of the downsides on GPUs that are being built today because they have such a higher throughput, magnitudes more than what you find on system memory drives. They're very small in size themselves. I think the biggest cards now are maybe 16 gigs at most. What we normally see is we can actually, well, we do see that pop up from time to time and it's just a matter of waiting for card developers to get to a point where the L2 caches and the size of memory on card aren't necessarily gonna be a bottleneck going forward. So if you're running really memory, really high intensive GPU workloads, it's typically better to spread them across more than one card or a couple cores actually channeled appropriately than having a cluster of jobs split between two different core caches where you start to hit an overhead of actually jumping between system memory and GPU cache. So we don't see it as much anymore. Most of the modern cards today have quite a bigger set of cache than what was on generation previous or even the previous generation before that. Even the Tesla K80 card is probably a bit older than what you find today in most modern NVIDIA drivers cards. But yeah, that's a good question. I think you'll see in the next coming year a lot of that bottleneck will go away for sure. Especially as more card developers develop this capabilities much like how NVIDIA's cards have here. Any other questions while I get this last piece set up for us? Right, so we're gonna go ahead and deploy the TensorFlow example. And so I'm gonna walk through just real briefly. This is gonna be a lot more lower level Kubernetes bits. So I'm just gonna highlight briefly what we're doing and how this all works. So we're gonna just run a real quick manifest. Manifests are a lot like the definition of how to actually execute your workload onto Kubernetes. So what this is giving you is, I'm gonna make this a little bigger for everyone. What this is giving you is just we're gonna run a simple container to show that we have the NVIDIA devices being passed through appropriately. So we're just gonna create a quick job. It's gonna be called NVIDIA SMI. That's gonna run this command using the NVIDIA CUDA image. So these lines here are kind of important. The image we use, this is the Docker container we're running. In this case, it'd be NVIDIA CUDA, but this would be potentially Google slash TensorFlow or your application that your data scientists have worked on and have packaged up and deployed. And then we're gonna make sure a couple other things happen. We're gonna make sure that we utilize the NVIDIA GPU resources in Kubernetes so it knows that we need to have it on a machine that has GPUs enabled. And then we're gonna make sure that a couple paths get passed through. So it has access to the drivers on the machine. And that's it. So this is about a 20 line file that gets us a running job to be able to test and validate these things. And this is executed. So I went ahead and applied that YAML file to our Kubernetes cluster. Now if I do a CUBE, Cuddle, we see that we had an NVIDIA SMI job run. We had one job run, zero successful, 11 seconds. So it must still be running. So it's still running in a few seconds. This will come up after it puts the image, downloads it and runs the task at hand. And this is effectively a stateless machine. This has got no state that's being preserved. This is much in the way you'd run your existing applications, your existing workflows that your data scientists are using for their images. Yes. So Docker Compose is, it's definitely comparable to what we're doing here. Docker Compose gets you kind of a running set of bundle of Docker containers. What Kubernetes is doing is composing that in its own way that gives you additional flexibility on top of that. So they definitely are, they're definitely an overlap, but Docker Compose is a much more lower level mechanism. That's if you have a machine, you SSH to it, you wanna get some stuff running immediately, install Docker IO, go run Docker Compose and against the YAML file and get things running. What you get by using something like a coordinator like Kubernetes is the repeatability and flexibility of those jobs being run again. Yeah. Right, so it is similar, it's not gonna be the same thing by any stretch of the imagination. So while this is wrapping up, we'll look at this one more time just to kind of walk through. So this is a very Kubernetes specific file format. It runs on Kubernetes only effectively, but is achieving the same results as a Docker Compose where we're defining a set of primitives. This is a job, it's not a pod, it's not a service, it's not a node, it's a job, it's gonna boot up, run its thing and stop. Whereas we could say I wanna run my TensorFlow dashboard, which is a service, it consistently runs and needs to make sure I have a minimum number of these things running and that would define a separate set of schema results for those things. And then we define the spec for this job. So we're gonna be applying this label, we're gonna be using this container, we're gonna run this command in that container. These are the resources Kubernetes needs to make sure are present for execution, these are mounts we're gonna apply to it. So while it does achieve the same thing, there's definitely a lot more in this spec and it's not something that you can just take from one and push it the other. All right, well it's been two minutes, I'm not quite sure why this job isn't finishing up, I'll have to go poke at this in a minute. But the important thing to note here and we'll see how this second install is running, moving along progressing. So the important thing to note is when it comes to things like GPU workloads, a lot of new GPU workloads that are being created are being created using Docker containers, being developed on Ubuntu by data scientists and it lends itself to a new set of platform primitives. Data scientists aren't necessarily operations people, but I'm sure there's some overlap, but generally speaking they're more focused on getting things running and getting data back than they are necessarily focused on making sure there's 100% uptime on this machine running here. So what Kubernetes, the platform lends itself to, very complementary to that open stack primitive is, operators need to make sure that your persistent data is there. Your databases are still running, your file stores are still there, you have data integrity and you have uptime. Data scientists are typically just saying I'm gonna have a set of processes that I wanna run and execute them quickly. Kubernetes on open stack or alongside open stack gives them that same primitive while also leveraging their format that they're currently developing in. So with that, I'm just gonna leave a few notes and then I'll open it up for questions. All right, does anyone have any final questions? Yes, the front here first. So that's, no, it's a good question. So the question being what would you recommend as a pattern for having access to GPUs? Would you recommend running them alongside an open stack, utilizing the hardware directly or leveraging them through an open stack where the tenants inside of an open stack instance have the pass-through device and it's inside of there? I think that's really gonna be dependent on the cloud and the team utilizing Kubernetes. We've seen both patterns. I think both work really well and it depends entirely upon what fits best into your org's needs. If it's easier just to say, here you've got a class of instances that have PCI pass-through devices and each team can just go and say, hey, spin up a Kubernetes as large as you want it within your tenant, you can utilize them, you have it there. It makes it easier for your operations team. It's one less thing that they worry about. There are some instances where having the full breadth of metal underneath the Kubernetes cluster is more important. At which side they work really well as well next to each other where you're sharing maybe your networking control plane and managing them as entities alongside. But there isn't really one recommendation over another. I think you'd see them being used in both models for certain. Yep, absolutely. So if you wanted to utilize this Kubernetes to run COLA on top of, that most certainly is a workflow you can push through it, absolutely. And having GPUs exposed up through that way as well, completely possible. Yes, I think it depends larger than the domain of the business. We're seeing a lot of data scientists uptake on GP GPUs just simply because of it is multiple magnitudes more for quicker to process a lot of their tasks than it is on CPU-based workloads. So in certain domains, that's definitely exploding exponentially. You're not gonna see people clamoring to have their database services necessarily run against or more traditional database services run against those things. But for tasks that lend themselves very well to high parallelization of processing of data, you'll see GP GPUs being uptake quite quickly. I think because we're seeing a lot more availability of GP GPUs on clouds, it's much more accessible to developers. So I know a few developers that just kind of hack in their spare times and they'll spin up a GP GPU instance for a couple hours, which is maybe three bucks and do some interesting data processing because they're interested in learning how they can expedite tasks or playing with machine learning or deep learning models and kind of planning for the next breed, which is building data models in clouds and delivering them to edge devices like your car or your thermostat or something else as well. So there are definitely an uptake in people because of the availability of GP GPUs in clouds where normally it's very expensive investment plus a lot of power draw, plus a lot of heating and cooling bills when you get a good size cluster running at your home. So I definitely think you see an uptake in that for sure. Yes? Yeah, so this is the, is there a way to do something more than just pass through of a device? There's a project in OpenStack that's trying to tackle this, Cyborg, which is trying to find a way that using the OpenStack APIs provide a, not a pass through directly, but actually a chunk of GPU or a chunk of networking and stuff. So there's a project tackling that now if you're interested. I'm not sure where the progress is on it, but we've been kind of following loosely this, the progress of there. So it's very interesting that in a perfect world you'd have a slice of CUDA cores available for instance, which is much more economical than an entire instance sitting on a board, which can be quite costly in the size of the amount of cores you've just lost. If you're not utilizing them to their full potential. So yeah, I would check out Cyborg for sure and join up the development meetings there and kind of follow along. Yes, so I found a new friend. So yeah, I'm very interested to see how that grows into the project to make that a little bit more accessible. So cool, thanks for joining. So for the most part, and James Page, correct me if I'm wrong, but for the most part, once you whitelist the PCI device, the schedule will just find a matching Nova host that has that whitelisted device on it. So you won't be utilizing. Generally speaking, you don't want to necessarily have heterogeneous hardware in a zone, but that happens a lot and it's fine. So I'm pretty sure OpenStack handles that pretty well today. We don't do much additional munging there. It's just whatever happens in upstream. Right, so since you're using PCI pass-through, it's not necessarily the host that needs that driver. It's the tenant, yeah. Sure, it could be absolutely better. I hear there's a project that might help with that. But yeah, we just use whatever mechanisms exist today in the upstream OpenStack repose. Yeah, normally speaking, when we have customers that are deploying GPUs into their hypervisors, they're setting aside a region to handle that and a lot of that hardware is as close to possible the same that way they can say here's a region with availability zones with GPU processing available. Yeah, any other questions? I think I'm running up at a time, but I have a few more, yes? No, no, it's a good question. So how does Gigi Charms relate to Docker in general? What's? Yeah, Gigi Charms. Yeah. So what Gigi Charms are is a way to encapsulate operation of software. So how do I deploy? How do I upgrade? How do I scale? How do I configure and reconfigure Kubernetes as an example? So what we've done is we've worked with the upstream projects. So the Charms for Kubernetes live in the Kubernetes tree. They worked on there and upstream and we tackled how do you manage life-cyclist code? And so Charms themselves absolutely could launch Docker containers, but it's a bit on a different plane of operation. So if your lower-level control plane services can run in Docker containers, that's something you could do. We have examples where there are telco network function virtualization vendors that have a lot of their stuff Dockerized and non-Dockerized, so they'll write Charms that do Docker launch over here and Docker run over here and Docker compose here and then here's how I do the other additional bits. So there's definitely a place for it, but it doesn't necessarily fit directly into the model here. It's generally easier to give your developers, your data scientist access to a platform where they can just press a button or run a single command to get workloads spun up and spun down, instead of having to write a bunch of operations code, because they're generally speaking not the same people that are operating your persistent data source, your under clouds and stuff. That's very true about the stack. It's really important about just both the stacks that can run themselves and the stack that can be upgraded every day, right? You know when binary matches the whole thing that is and you're gonna keep it up-to-date, operate it cheaply, that matters, and the affinity is to do that with our students. If you choose to remain in that speed, whether I can find it or not. Yes. I'm very impressed. I'm, yeah. So Lexi does absolutely, I'm sure. So Lexi speeds every two points. Yeah, absolutely. So if you wanna run a couple Lexi machines past the PCI device too, you could use that as a target as well, cool. I think we're out of time. Thank you all for joining me. Now if you have any questions, I'll be hanging out for just a little bit longer, but enjoy the rest of your day, enjoy your lunch, and then we'll be back here in about 45 minutes.


So I'm Mark Miller. I'm a founder and chief scientist of Gorek and a senior fellow at the foresight Institute, and I've been working on smart contracts since the 1980s. And I've been working on it since then because it's important. And in this talk, I'm going to try to give you my perspective on why. But first, a slide on the history of the world since 1820. The red on this diagram represents the number of people living in extreme poverty. The green represents the number of people not living in extreme poverty. Back in 1820, almost everyone was in extreme poverty. And as the population grew, the number of people not in extreme poverty grew much faster than the people in extreme poverty. Lately, we've been seeing something even more wonderful. The number of people living in extreme poverty has been plummeting at an accelerating rate, even in absolute numbers, as the total number of people have been increasing. And even Pinker says, we've been doing something right. It would be good to know what it is. There's two phenomenon here that need to be explained. We can view civilization as a problem solving superintelligence. The number of people that it supports not living in extreme poverty, the green on this diagram, represent it's ever increasing superintelligent problem solving capacity. And the plummeting red on this diagram represent its alignment with human needs. These are both emergent phenomenon that need to be explained. How is it that civilization is both increasing in its superintelligent problem solving capacity, and that this capacity is deployed so well in aligned with human needs. Well, civilization is not an agent. It's not a superintelligent intelligence. It's not that it wants anything. It doesn't suffer or not suffer. It has no utility function. But it has a dynamic to it. It has a tropism. And that's what I'll try. I'll be talking about in this talk. Civilization is that which emerges from us from the choices that we're all making. So let's imagine the choice landscape among possible worlds. Over here we have in this diagram, every point in the space represents a different possible world. And they're organized spatially according to Alice's preferences and Bob's preferences. The red dot in the center represents the current world. We should remember though that the overall space we're talking about has seven billion dimensions to it. But most people don't know each other. Most interactions between one group of people is independent of interactions among another group of people. And any particular relevant choice landscape among possible worlds will have lower dimensions than the overall seven dimensional space, and these will proceed somewhat independently. So we organize the possible worlds vertically according to Alice's preferences, the ones that are higher are the possible worlds Alice would prefer to the current world. And we all organize them horizontally according to Bob's preferences, the ones to the right are the ones that Bob would prefer. You've probably heard the terms positive some and negative some, but not realize how peculiar a notion it is. We can think about preferences as revealed by the choices that that the various parties make the choices that Alice makes. And we can reveal her preference among various consequence. But the notion of positive some presumes that we can think of these preferences not just as a rank ordering but as a metric, and is and that we can furthermore compare these between parties that we can compare Alice's preferences and Bob's preferences we invent this notion of utility for preferences as a metric and then we imagine further that we can meaningfully add them together. So a utilitarian is one who sees a transition to the green above the diagonal, where the sum of utilities are greater than that in the current world any move from the current world into that upper right area would be considered to be preferable to a utilitarian. We can divide up that area into segments. The upper right quadrant is the is the segment containing the points, the possible worlds that are Pareto preferred by Alice and Bob to the current world. So for example, the blue dot is Pareto preferred to the red dot what this means is that at least one party prefers the blue dot to the red dot, and no one prefers the red dot to the blue dot. So these are the points that to a first approximation we can reach by voluntary cooperation, because somebody would rather move there, and no book no one should be resisting. The upper left is still positive some being a good utilitarian suggests to Bob that we should move from the current world to that blue dot, because, although Bob will be worse off Alice will be more better off than Bob will be worse off. But despite Alice's impeccable utilitarian logic, for some reason, Bob does not like this plan. We should expect Bob to resist. Furthermore, we should expect that Alice will expect Bob to resist, and Bob will expect Alex, Alice to expect that. So we've got a cascade of expectation of conflict, and that cascading mutual expectation of conflict leads to the Hobbesian trap, where each party, even if they weren't inclined to actually engage in a conflict might do so first, in order to get ahead of the other party is also known as the first strike instability and as we saw during the Cold War, that instability might even destroy the world. So, let's return to our happy upper right quadrant. And not all points on this quadrant are actually reachable by deals between Alice and Bob starting from the red dot. And some of the reasons are human psychology that with that blue dot move to the blue dot Alice does tremendously better off. And Bob just gets a few crumbs. So, even though Bob is still better off. He might not agree to that deal because he resents the unfairness of the deal being offered. And experimental economics has shown very consistently that humans will refuse such deals as it violates their fairness intuitions too much. So the green cone within the upper right quadrant is the sweet spot it's the deals that are more easily more easily reached by by voluntary cooperation by deals between Alice and Bob. Now we should remember that human psychology isn't as necessarily as much of a constraint going forward as it has been. We're not the only players involved, and we'll be increasingly sharing our world with art with our artificial intelligence descendants, which will have mind architectures incomprehensibly different than our own. But we will still want a world in which we can peacefully coexist and cooperate with them. The notion of interpersonal utility comparison. When applied to coexistence with incomprehensibly different mind architectures becomes incoherent. The whole notion of utility as a metric when applied to such mind architectures is incoherent. And a coherent notion universal enough to still apply is the notion of revealed preference that goal seeking entities make choices and services that are goals and so doing reveal preferences. And if utility is no longer metric if all we have is a ranking order than the diagonal line becomes meaningless. So we need to remember the distinction between the upper right quadrant and everything else remains robust. Furthermore, even without human psychology necessarily being a factor. The green cone is still the sweet spot for arriving at deals, because Bob, knowing something about Alice's preferences and trade offs might hold out for a better deal. There's still more interesting reasons why not every point in the parade or preferred quadrant might be reachable by Alice and Bob. And the main one that we should be concerned about and I would say the main one that this conference is about our collective action dilemmas, preventing us from making progress that we would like to mutually preferred worlds. And to explain this, let's start with the very simplest example of a cooperative deal a simple trade 10 shekels for a gore. But let's assume the worst case for bringing about cooperation, which is that Alice and Bob have never heard of each other they're outside of any cultural or legal context that would help them make a binding deal. They're anonymous and it's a one time interaction. But let's say that the deal that they have in mind is that Bob would give Alice 10 shekels and Alice would in turn give Bob Gord. So, there's a problem with this. When Bob gives Alice 10 shekels Alice's 10 shekels richer Bob is 10 shekels poor. And when Bob says to Alice, where's my guard. Alice, quoting Hobbes says, for he that perform at first has no assurance the other will perform after because the bonds of words are too weak. And Alice runs off with the Gord. And of course Bob anticipating that that would be what happens actually never offers Alice the 10 shekels in the first place. So this dynamic is the Nash equilibrium trap for both Alice and Bob, there's another world that they would both prefer to move to, but they can't get there through individual actions. Through separate actions without getting trapped the way Bob got trapped in the scenario that we saw. And we can think of that as a barrier where it's a step around the barriers to fall into one of these traps. So to overcome this long ago we invented technologies of credible commitment. Reputation like iterated games like promises like contracts like escrow. All of these ways are all of these mechanisms are technologies of credible commitment that enable Alice and Bob to effectively move forward to the world that they would jointly prefer together. However, our society is full of collection active action dilemmas, essentially the same structure with large we're now these collective action dilemmas might involve thousands or millions of people and play out over years or decades. And these things can be very hard to figure out how to surmount. And our civilization is to a substantial degree the evolution of norms and cultures and human institutions and political frameworks that enable us to solve the problems these are one of the main problems that civilization has learned to solve over time is how to build these bridges over these barriers so that we can jointly cross into worlds that we would all prefer. And what we're doing in our new industry crypto commerce with blockchain and crypto and smart contracts and especially what we're doing here at this conference funding the Commons is we figuring out how to use our whole new technology base that we've created. It's a whole new technology base useful for many things but especially for building bridges over such barriers bridges that were previously inconceivable bridges that have a degree of trustworthiness that was previously impossible with institutions simply built out of people. So returning to our theme civilization. Once again is not an agent, it doesn't want anything, but it does have a dynamic it has a tropism by tropism. We're making analogy to things like photo tropism where plants grow towards the light. And we understand the chemical processes from which that tropism emerges what I've tried to do in this talk in an incredibly oversimplified way, sweeping many many problems under the rug but nevertheless get at the essence of what the mechanism is such that each of us, making individual choices and participating in the evolution of our civilization. Bring about this tropism of our civilization into the upper right quadrant with ever increasing problem solving capacity that's well aligned with human needs. And we're just getting started. Let's figure out how far we can take it. Thank you very much Mark and I know Allison will also be joining remotely and I'd like to welcome to the stage Christine Peterson and Juan Benet. Please grab a seat. Let's give a round of applause for the panelists. Okay. Super. Thank you. It's great to be here. And can we get Mark Miller and Allison on screen? Is that possible? While we wait for them to join us. I have one here and I get to ask him any question I want. I'm going to push him out on his speculative edges which is saying something, right? Because this is a fairly visionary guy. You know we've talked about, all weekend we've talked about funding the commons, creating new tools. We haven't talked a huge amount about AI and now would be a great time to do that. And we're looking here for positive visions, right? Not the nightmare scenarios. We're all very good at that. We're not as good at generating really inspirational positive scenarios. But I have a feeling one might be able to do that. So tell us a little about how you see AI playing into all this. Things like epistemic assistance. Things like that. Let's hear about it. Yeah, thanks for the question and thanks for the prompt. I completely agree that we are in general very good at focusing on the bad things to avoid and we tend to lack well articulated positive visions of the future. So thanks for the prompt. So I think it really sort of varies at different time scales. So in the multi-hundred-year, a thousand-year, a million-year time scales, we're talking about a total different civilization or species evolution or really a phase transition into something very different. So it becomes extremely difficult to speculate even a thousand years out because the kind of improvement rate that we're in means that we might be able to have beings that are able to be fully digital or you might have different forms of intelligence that can converge and can converse with each other by exchanging entire portions of themselves. So it's a totally different kind of landscape. So I think maybe constraining my speculation to just like the next twenty to a hundred years because that's just a lot easier to talk about. I think that the positive outlook for AI systems is that say pre-AGI moment we will have just increased utility from more and more and more sophisticated agents and intelligences that can take on a great degree of task with increasing degrees of complexity and danger. So there's all kinds of things that are not ideal for humans to do or that humans are just not as good at that will have AI systems take on an increasing amount of things. I believe this is Hans Morovec who described this sort of like rising tide of machinery and intelligent systems taking on more and more and more tasks of different levels of complexity while humans kind of rise to the hilltops to take on things that are still too complex for AI systems to do. And eventually there's a transition change at which you get to an AI system or an ASI system that is able to do everything that any human can. And I think at that point that the really positive outlook becomes one where humanity and AI systems sort of co-evolve or merge in some way. And I think at that point it becomes about thinking about AI systems as kind of like a neural extension to ourselves. And so that I think is really mediated by brain computer interfaces. If we can gain brain computer interfaces first, we'll get there to a really great degree. To your point about epistemic agents and so on, I do think that there is very high utility in being able to use AI systems, not necessarily AI systems yet, but like the tooling that we have today is really good to be able to orient us towards better conversations, more orientators truth, more orientators knowledge and knowledge diffusion and so on. Sorry, that was a little bit long-winded. Not at all. That's exactly what we needed to hear and I'm inspired. And Allison is staying on that theme. First I want to introduce our fourth panel member, Allison Dutman. She is president of Forsyte Institute. Many of you are familiar with Forsyte. And first author on this new book, which is coming out very soon, these are bound proofs for the author. Allison is first author along with Mark Miller and third author is myself called Gaming the Future, Technologies for Intelligent Voluntary Cooperation. So if you take Mark's talk and sort of expanded by a factor of 100 or 1,000 in vision and detail, that's the book. Which Allison did all the heavy lifting on, I have to say. So Allison, we're on the topic of positive futures here. When you think back about all the tools we reviewed here in the book, what are you excited about in terms of tools that this crowd should know about for positive cooperation? Well, I mean, I think apart from the many that have mentioned, have been mentioned throughout the conference day, which, you know, I think you really did a fantastic job at curating such a broad variety. And I think that the main tools, I think that, yeah, we will pay attention to in the future years. I'm not saying that we have more ideas here really, but, you know, like from everything from so-bound token to dollars, impact certificates, quadratic funding. I thought like you really did a fantastic job first of all. I do think that there's a few more that have been also quite at home in the foresight community for a while. One of them obviously is prediction markets. And I think Robin Hansen, for example, who's a foresight senior fellow as well, actually started a prediction market at our 1999 member gathering, where people still send checks to our offices. And now we have this wonderful tool kit that crypto commerce enables, where we can have these like amazing systems that are decentralized, that are immutable, that are first jurisdictional, that are already existing, and we can already use them. And I think, you know, like we also collaborate very closely with the DSIDE community. And for those, for example, you can have replication markets as well, right? For example, you could predict on whether or not a study could be replicated or not and then use that as an indicator for which studies to replicate first. So I think there's a ton of potentials in prediction markets. And I think that that is still really like, yeah, I think it could be explored even more. And then there's obviously others that I think, in addition to the prediction markets, you know, we talk a little bit in the book about how we can move toward a smart contracting. And we say that usually when you talk about that, people are like, well, we cannot automate everything. We can't get all the way there. And I think that's true. Like I think that, you know, there's probably always bits that we can't write an automated contract and that's probably for the better. But I think we can build towards that with using things like split contracts, which is one thing, for example, that was also pioneered by Chip Mornigstah and a few of the IMAX folks and the foster community. And that's basically you have half of the contract, the pros, half of the contract be automated and you predetermine like an arbitration system basically afterwards, similar to Claros, what they are basically already doing that can basically come in when a certain part of the contract doesn't work. So I think we can gradually move towards a more automated world. I think maybe one of the ones that they haven't seen much at this event at least about is Dominant Assurance Contract, which were developed by Alex Tabarak much, much before the notion of smart contracts was even a thing. And it's basically similar to Kickstarter, which is an assurance contract. So, for example, like a public goods only gets funded if enough people want to fund it too. But the hunch here is that in addition, the first people that ship in, if it doesn't get funded, they get a reward. And so you incentivize early contributions and you make it more likely that these things actually do get funded because sometimes it's hard to get them off the start at first. And there's many, many more. We talk about a few of them in the book, but one other thing that I still want to draw people's attention to and it fits in what King Tong talked with a tech tree and also what Juan mentioned on AI is really the notion of crypto commerce is larger than just cryptocurrencies, obviously. And, you know, it relies a lot on the underlying cryptographic technologies. And there's a few things like federated learning that I think we should be paying much more attention to. Like federated learning would allow mutually distrusting parties to cooperate without actually sharing their data. So you can do like a computing on encrypted data. And so that I think it's really exciting because it means that we don't have to like have these centralized agents that like go above all the data, but we can actually like collaborate, for example, on even maybe even things as essential or as sensitive as like healthcare data in a decentralized way. And so we can avoid many of the, I think, you know, usually like data sweeping problems that we usually face.  But, you know, I think why we wrote the focus just we need to point out to you guys that I think all of you are working on things that are so fundamental and important for the future. And I think that especially if once AI comes into the mix like crypto commerce has really the like potential to reshape the future that we have from like the bottom up, right? Like I think it's the meta tech tree of all the other tech trees that we need. And it's really exciting that we can now build the types of technologies and signs that was that it's usually interested in. And it's really wonderful decentralized way. So I'm just really happy that this community is coming together and very excited to be a tiny adjacent part. Great. Thank you, Allison. For those of you who want to read the book right now, it is on Substack. You just go to Substack, type in Foresight Institute. It will take you right to the book. It should be available on Amazon. I'm guessing in about a month, Allison, you cannot if that's about, if that sounds right, about a month. And for those of you who love this topic, Foresight's having a workshop in October, October 4th and 5th on this topic. You can go to our homepage and apply to attend in San Francisco, and we'd love, if you love these topics, that's the place to be. So quickly Mark, since we're short on time, I just wanted to ask you one thing we'll be covering in October are computer security technologies because none of this happens, like none of it happens without good computer security. Very briefly, can you just mention a small number of tools that this audience should be aware of in terms of funding the Commons projects that deserve participation? When I first got involved in computer security, there was a dominant paradigm, which we now label identity-based access control, which the dominant form is access control lists and all the mainstream commercial operating systems. Everyone that you've touched on a commercial product has been based on that access control paradigm. There was a historically another paradigm, capabilities, that we've now to make some distinctions of clarified with term object capabilities, that at the time I got involved was considered a discredited paradigm due to some misunderstandings. And since then we've succeeded at clarifying those misunderstandings, reviving the paradigm, it's getting increasing academic attention, but it's now getting increasing actual systems building. The only practical, high-performance, mechanically verified secure operating system, SEL4, is based on object capabilities. The entire agoric smart contracting stack is based on object capabilities. A lot of the cosmos infrastructure is based on object capabilities. And I know Juan is also a big fan of object capabilities, and I'll let him talk to what degree those concepts are incorporated into his systems. But the essence of object capabilities is this, is the transferable right, the transferable bearer right. And you can think of that as most familiar from object-oriented programs, where the safe, unforgible pointer to an object enables another object that holds that pointer to use the public interface of that object. And in using that interface, by invoking it, it can pass it as a parameter. And this simple notion of passing it as a parameter, one object can permit another object to invoke yet a third object. It turns out you can rebuild all of these, the computer security systems patterns in kind of this alternate way, starting from these very simple foundations. And in doing so, you can partition risk very effectively. So we'll never build bug-free systems. What we should be seeking to do is build systems that are much more resilient in the face of their own bugs. And we should also build systems in which the value that can be compromised in the face of any one bug is strictly minimized. And there's many techniques for doing that, but the primary, the core, is the principle of least authority. Mark, briefly. Okay, sorry. And so in any case, an object capabilities are very naturally expressed architectures and then on top of that, we build security patterns for further limiting and partitioning risk. Is there one project you'd point us at, one? I think there is. That's why I'm asking this question. Well, I would take a look at the hardened JavaScript that we've created as a supported sub-language within JavaScript. I've been on the ECMAScript committee, the committee that standardizes JavaScript since 2007, and I've gotten into the JavaScript standard. The mechanisms needed to support hardened JavaScript, which is still proceeding in committee, but it can now be used securely as a library. So I would point to that. I would point to the Eugorek stack that's built on top of that, running hardened JavaScript on blockchain, running smart contracts written in hardened JavaScript. And separately, I would also point that the SEL for operating system, which is the, as I mentioned, the only practical, mechanically verified, secure operating system. And if we want to move forward into any future that is safe in the face of artificial intelligence must already be safe in the face of cyber war. And SEL4 represents, for which I have no commercial affiliation. SEL4 represents the most important first step towards rebuilding our infrastructure in a way that is safe and will remain safe in the face of artificial intelligence attackers. Thank you, Mark. That was great. We are short on time, so I'm going to make this as brief as I can. This is sort of the wrap up in the conclusion on this session. First, I want to correct a confusion that I've heard yesterday and today again, which seems to be there's a confusion, probably not among people who are tight into the community, but I've heard it more than once now, where there seems to be this impression that if you build a future of individual choice with self sovereign participation, that somehow this world is going to be a world of selfish individuals, atomized, isolated, Marlboro men out riding their horses and smoking cigarettes on their frontier, right? And that somehow what we're doing is selfish. This is exactly the opposite of how I see it. And I hope we will all, when we run across this confusion, I hope we all reach out and correct it and say, no, in fact, the goal here is to enable voluntary cooperation and mutualism. You can't have that if you don't have voluntary choice at the lowest level, right? These are levels that interact. If you want voluntary, higher levels, it has to be voluntary choice from the bottom up, or you don't have that. There is another way to come up with a civilization, right? You don't have to have bottom up choice to have a civilization. You can have top down control. We see that in the world today. Those are real civilizations with real achievements. The question is, can we save the one we have here where we do have some individual choice, where it's based on individual choice? And as Juan was pointing out yesterday, our institutions are floundering today. We're in trouble, right? I mean, I've lived long enough to see them deteriorating. They're either dysfunctional or sometimes they're actually captured. The regulatory structures have been captured by the industries that they're supposed to be regulating. That's why we have lousy healthcare. We have instead sick care. People are making money off our illnesses. Okay, so that's my little rant there about the mutualism thing. Let's try to keep our eyes open and get rid of this idea that what we're doing is selfish in some way. It is very much not that way. So it sounded to me when Juan was doing the kickoff yesterday that he was kind of challenging us, if I understood correctly, to rebuild civilization from the bottom up because of our institutions being broken. And I have to say I want to join that call. I've seen them deteriorating. The only thing that gives me hope is Web 3, this community. And you have so much potential power with the tools you're building compared to the floundering we see in society at large, right? You can do this. You actually can do what Juan was calling you to do. Will it take time? Yes, it's going to take time. How long? About 40 years is my guess. Why 40 years? I've been around a long time, and I've seen how long it takes to do hard stuff. It takes a long time. And that's why if any of you are like giving 110%, you might want to rethink that, okay? Because you are not in a sprint. You are in a marathon. It's going to take a long time. It's going to be hard to do what you're doing, especially challenging things in physical space like Vida-Dow. Okay? They're trying to reform and make it so that we have health instead of a sick care system. This is a huge undertaking, and it's in physical space, not in bit space, right? It's in meat space. Things in meat space are harder. Why are they harder? Well, two reasons. One, atoms are very hard to control. They're just very difficult. Chemistry is awful. Biochemistry is worse. Biology is a mess. If you think software is bad, biology is a disaster. Okay? And we're made of meat, right? Remember that? We're made of meat. So if we want to be healthy, we have to get this meat thing under control. So that one reason is atoms are hard. What's the other reason? Well, when you do things outside the computer, out in the physical world, there's opposition. There are legacy institutions who are making money off the problem you're trying to fix. And they don't necessarily want that problem solved. And this is not because they're bad people. It's just because the system is set up to make money off something that is a problem, like illness. And it's very hard to change that, especially with the regulatory system being captured. So there will be opposition. So things that should be easy take longer. So things that should take 20 years take 40 years. Do we give up? No, we don't give up. We don't have a choice. We have to do this, right? So that's why you have to take this additive. It's a marathon, not a sprint. You got to pace yourself. It's a long time. It's going to take a long time to do these things. But it's totally worth it. And so my suggestion to all of us and to Juan in particular is I suggest we come back together 40 years from now in this room. And I think this room will still probably be here in 40 years. It's been here a long time, right? And see how we did, right? We have a long list of dreams and goals that I've heard at this conference. The one that's closest to my heart is Vita Dao, because the payoff for humanity is so huge. And let's see what Vita Dao can do in 40 years. It's a much harder problem than almost anything we've done before because human biology is so bad and there's all this infrastructure we're going to have to fight. But number one, they're very smart people and I hope you're all on the team either directly or indirectly. Number two, the tools that you guys are building are super powerful. And number three, our community as was pointed out yesterday has significant resources. And this is a cause that our community cares a lot about. So I think there's a very good chance that we can make major progress so that 40 years from now you guys will be back and you'll be in pretty damn good shape because Vita Dao did their job. And on that note, I hope to see you in 40 years right here and let's see how many of these dreams we can make come true. Thank you.


In the last segment, we took a look at the fluid mechanics associated with free or natural convection. What we're going to do in this segment, we're going to take a look at the governing equations. When we looked at the velocity profile, if you recall, we were drawing a plate, assuming that the plate temperature was hotter than that of the surrounding fluid. We had the condition where T wall is greater than T infinity, and T infinity was the quiescent or ambient fluid outside of the plate. When we did this, what we did is we introduced a coordinate system with x going in this direction and y being normal to the plate. We will continue with that coordinate system as we look at the governing equations. What we're going to do, we're going to begin with the x-momentum equation that has been reduced a little bit, similar to the boundary layer approximations. We're not doing that in this course, but if you look at my fluid mechanics course, you'll find discussion about how to reduce the Navier-Stokes equations into the boundary layer equations. With that, I will write out the x-component of the momentum equation. That is the x-momentum equation. One thing that you may notice immediately, if you compare this to the Navier-Stokes equation, we have a minus g here. The reason for that, the reason why it is negative is because the gravity vector is acting downwards, which with our coordinate system that we've just cast out here, are written there, that would be a negative value, and that's why we have the negative value there. It's negative as x is acting downwards, or as the gravity acts downwards. That is the x-momentum. The other thing that we know, we were showing that the boundary layer starts to grow from the beginning of the plate, and in reality, what's happening is we do have fluid being entrained, and so there would be fluid coming in from below, and that would give us a little bit of a velocity profile at the beginning, but usually what we assume is out beyond the boundary layer, that is when we get into what we call the quiescent region, where quite often we make the approximation that the velocity in that region is zero. With that approximation, what we can do is we can look at the x-momentum equation, and the x-momentum equation then in the quiescent region reduces to the following. This was just minus rho infinity g is equal to the pressure gradient. Now what I'm going to do, I'm going to call the x-momentum equation equation one. I'll call the quiescent region equation equation two, and now what we're going to do, we're going to sub equation two into equation one. With that, the following results, and so we obtain this equation here, and now what we're going to do, we're going to focus in on this term here, how to handle the fact that we have a density difference, and in order to do that, what we're going to do, we're going to introduce the volumetric thermally expansion coefficient, and the volumetric expansion coefficient is defined in the following manner. So beta is related to the change in density with temperature at a constant pressure. And with this, what we can do is we can look at it for a couple of different scenarios, be it a gas or a liquid. And so to begin with, if we're dealing with a gas, if we're dealing with an ideal gas, we can use the ideal gas equation, and with that, we can rewrite beta in the following manner, and then making a substitution for the density. We get one over the temperature in Kelvin is beta for an ideal gas, and if we're dealing with a liquid or a non-ideal gas, in those cases, beta would be from property tables. So that's how we handle beta, which is our volumetric thermal expansion coefficient. Coming back though, what we want to do is we want to be able to find a way to use beta in order to figure out how to handle this term here, where we have the difference in density. And so what we're going to do, we're going to express beta in terms of a finite difference. So that would be beta expressed in terms of a finite difference. Now what I'm going to do, I'm going to solve for rho infinity minus rho, which is what is in our momentum equation. So what we have here is an expression for the difference in density expressed now in terms of the density, the volumetric expansion coefficient, and the difference in temperature. And this is referred to as being the Boozinesq approximation, and it gives us a coupling between the momentum equation and the energy equation. So with that, what I'm going to do is I'm going to rewrite our governing equations. So we have the x momentum equation, we have continuity, and lastly we have the energy equation. So those are the three equations that we have that we need to solve if we want to be able to determine the temperature and the velocity profile in front of or above a plate that has natural convection. So remember y was in that direction, x is in that direction, and this would be a case where the plate wall is greater than t infinity, t infinity being out here. So we have momentum, continuity, and energy, and those would have to be solved. What we're going to do in the next segment, we're not going to solve them, we'll actually rely on a solution that others have come up with, and it turns out that in order to solve this, you get two differential equations that you have to solve numerically, very similar to the Blasius solution actually. If you look at my fluid mechanics course, you'll see a discussion about that process. But what we'll be doing, we're going to be doing some dimensional analysis, we'll non-dimensionalize the equation I should say, and then some non-dimensional numbers will be dropping out of them, and that's what we'll be looking at in the next segment.