Hi, everyone. I'm Sterling. I'm with Runtime. Runtime is a company that I co-founded on the CTL of Runtime. And our goal is to make open source software for embedded microcontrollers. So when I say a bootloader for embedded, it's really kind of a class of devices that are sub-embedded devices.  And Runtime was founded with the idea of making software develop modern and easy for these devices. And so just a little bit about my background before I get started. I'm going to talk about the Minute Bootloader here, which has recently been refactored into a project called MCU Boot. And so I'll give you a little bit of that history. But prior to that, just a little bit of my background. So I was an early, I guess I got started at 13. I got started making websites. I was found open source through the PHP project, was a core contributor to the PHP project. And as I said on my previous talk, then Java started to take over the world and I decided that it was a time to find a safe port in the storm. And so I started working on embedded with a company named SilverSpring Networks. And I started working very basically there and then ended up running the firmware team. At SilverSpring, we shipped 23, 24 million connected devices. We shipped those devices onto the utility grid and in cities. And every single one of those devices had a secure bootloader, which we developed and managed over time. And we did that over multiple iterations of chips from our first ones, which were just simple ATMEGAs, to ARM7s, to our own custom system on chips, which had secure elements within them and had keys and key protection. We developed that and we regularly did software updates to 24 million devices and we did that securely and we run large swaths of the power grid. After that, founded runtime, which I just gave a bit of an overview of. And so this project is about the bootloader in the Apache Minute project. And here's a little bit of background on it. So runtime was one of the original members and contributors to the Apache Minute project. The idea behind Apache Minute is it's really an operating system for connected devices and not an operating system that you would think of as a traditional, just a kernel like UCOS or something like that. But an encompassing operating system that includes bootloader is networking stacks, file systems, everything that you would need to develop a connected product and all open source and Apache licensed. And so a part of that was to make the system software upgradeable, right? Everybody who develops a connected device, the one thing that everybody wants to do is upgrade software on that device. And so we within the Apache Minute project, we actually include libraries to do software upgrades. And those run in the application image itself along with a secure bootloader. And so we were happily working along there and then Zephyr launched. And so we've been talking for a number of months with the Zephyr project and the members of the Zephyr project. Ricardo actually is here in Lunaro. And so we decided to break the bootloader itself out of minute because fundamentally a bootloader should work across multiple operating systems and create a separate project called MCU boot. So right now it's hosted by Runtime. It's github.com slash run time co slash MCU boot. And we now can, with MCU boot, boot both minute images and Zephyr images. So if you come to the Runtime boot, which is just upstairs, a very quick product plug, we can actually show you our cloud being able to upgrade a minute device and have it swap to a Zephyr device and back and forth. And so this talk is about, and Lunaro has actually demonstrated this same bootloader at Lunaro Connect where they did software upgrades on Zephyr as well. So both of us have actually used this bootloader from a Runtime perspective. We've been using this bootloader for about six months on every single check-in and every single pull request to all of our development. We rebuild our entire system and we use this bootloader to upgrade devices and run our unit tests suite on it. So it runs pretty reliably. And so I'm just going to talk a little bit about the bootloader. This is the Flash layout slide, but really the idea behind the bootloader is to make it very, very small and secure for small embedded systems. So the type of processors that we run on are things like the Nordic NRF 51, which have 16K of RAM and 128K of Flash. So they're very, very small embedded devices. They grow in size. So some of them will have four megs of RAM and eight megs of Flash, but that typically is where it tops out. If it gets any bigger, people tend to run Linux and other things on them. I think at Silver Spring we ran up to 32 megs of RAM and 64 megs of Flash, but that was mainly because we had an entire product suite that had much lower-end systems as well as higher-end systems and we wanted a single development tree for all of it. But it's really designed to fit within a small code footprint. So the bootloader itself fits within 12K of code. The significance here is you're kind of at this level really looking at either 8K or 16K that you want to fit into. If you're any bigger than that, then it's just craziness. And the reason why you want to fit within 16K is that typically a bootloader itself needs to be right protected. And so if you look at the Flash, you can adjust where the right protect is set on the Flash. If you go to 17K, then you have to write protect at 32K typically. If you go above 32K, you have to write protect typically at 64K. So fitting within 12K of code size is really good. We can grow up to about 16K. One of the reasons we keep the bootloader itself within 12K of code is we have a serial boot option with minute. So the bootloader plus serial boot fits within 16K of code on these systems, which is fairly important. So if you look at the Flash, in addition to the bootloader itself, what we've talked about with the members of Zephyr is that also defining the actual layout of Flash systems for these small embedded devices. If you looked at what we did or what I've done in previous companies, what it ends up happening is everybody ends up having their own Flash layout for these devices and their own bootloader. So SilverSpring had our own bootloader. We also had our own Flash layout. And when you do that, it becomes very hard to manage these devices in the field and upgrade them over time. How do you, for example, create a running image and know what sectors are on that device? There is no concept of a superblock for these embedded systems, right? So how do you define the layout of a system and how do you understand that is a part of the MCU boot project? And both operating systems are collaborating on this project to do that. So what we have here in the Flash layout is we have the bootloader itself, and I'm trying to, oh, perfect. We have the bootloader itself. That typically sits depending on how you configure your Flash. That can either be at the very end of Flash for systems that boot that way, or it can be at the very beginning of Flash. Typically, it's at the very beginning of Flash. There's then a superblock which defines the layout of the Flash itself. So what it says is essentially this Flash is a certain size, and here are the blocks on that Flash. We are going to allocate blocks 10 through 26 for image 1, 26 through 45 for image 2. There's going to be a file system at 45 through 60. And so the superblock basically gives you the layout of Flash so that any application or kernel image that runs can read that superblock information and understand how the Flash is laid out itself. You then have two image slots. These slots, you can only have one image slot if you only want to have one upgradable image, but there's always two slots. Essentially what you do is if you want to have only one slot, you just make the second slot really, really small. And so images, slot 0 is the primary image slot. So the initial design of the bootloader is for systems that actually have internal flashes and run out of that internal flash. And so when you actually run on one of these systems, you don't want to have to have compile your code in a position-independent fashion. So you always want your image to be able to run from the same location. So slot 0 in our bootloader is the primary image location. Code always runs from there. And then slot 1 is the upgrade slot that you copy into. And if an upgraded is needed, the bootloader swaps the slots. And it swaps those slots using the scratch sector. So the scratch sector needs to be the size of at least one Flash sector so that you can do a safe copy of the two swaps across power cycles, right? Because you can't assume that these devices will always be constantly powered. You may get interruptions while you're doing an image upgrade. So essentially what you have is slot 0 sits there. And when you tell the image to do an upgrade, the bootloader will look at that and it will start swapping slot 1 into slot 0. And it will use the scratch slot as it erases sectors of Flash in slot 0 and replaces them with the contents of slot 1. So the bootloader runs a swap. And an image trailer tracks actually the state of swapping and upgrading the device. The bootloader itself, when it looks at these images, it supports either RSA or ECCDSA for signatures on the images itself. And so if you look at the actual image, essentially in the bootloader itself, what we have is an image header. That image header contains the size and version information for that image. So it's a simple header. Typically there's also some room for padding. So if you want to be able to locate interrupt vectors in text and you want to locate them at a specific location in text, there is a padding in the image header itself. You then have the code that's associated with the running image, so the kernel. And then you have a set of TLVs that include things like the signature of the image data itself. So the image header does not contain that signature, but the signature itself is contained within the TLVs. And then you contain the image trailer, which keeps an ongoing record of how the swap is going when it swaps between slot 0 and slot 1. And that's what those image trailers end up doing. So the way the bootloader works and the boot process is. So the assumption here is that the bootloader is not actually managing the software upgrade itself. There's one caveat to that, but typically what you're going to have is you're going to have slot 0 and slot 1 on your system. And the kernel itself is going to be linked with an image upgrade process. So it's going to be a preemptive, in minute, it's a preemptive task that runs, it's the same in Zephyr. And what we've done is we've implemented an image upgrade protocol that runs over OIC in minute. And you can download a new image. When you download that image, you download it to slot 1. And you can then tell the system to boot to the new image, and you can have a confirmation system based upon that. And that's all done within the application running code itself. That's not done within the bootloader. The bootloader just gets information from the operating system kernel about what image it should be running, and it tells it to do the swap. So what happens is on boot, the bootloader checks both slots. It normally boots slot 0, it verifies the signature of the image. So it does a SHA-256 of the image, and then it verifies the cryptographic signature of that image prior to booting it. And then if a new image is marked in slot 1, it safely swaps both of those images. It tries to boot the image itself, so it then goes and boots the image. When that image boots, it's its job to mark the bootloader and tell the bootloader that it has successfully booted. If it does not mark to the bootloader that it has successfully booted, the bootloader will swap back to the previous image itself. And so you have a fallback mechanism. The way this typically works in the field and the way we've managed devices successfully before is you want to have kind of both options here. If you think about how you're doing an upgrade, and I had to upgrade all those millions of devices, you want to push out that upgrade and you want to push it out to a small percentage of your devices first. If you think about it, first it's going to a few devices in development, then it's going to 20 devices or 100 devices in QA that you want to test. And throughout that process, you're kind of expecting things to fail horribly. You tested it with just your system here and it worked great, but then you didn't test it with the 20 other versions of hardware that you were upgrading and you have some issue. So when you do that, you want to have some way of making sure that the device falls back to the working image so you don't have to manually flash all of those devices. And so what you do is you upgrade the device and you set a fallback. If it doesn't, once it reboots and the network interface has come up and the device has successfully booted, you tell it and you confirm the slot and you say, okay, you have successfully booted and you move on with your life. As you go to rolling this out to larger and larger numbers of devices, you probably don't want to have that kind of information in the process because you have high confidence that the device is working well and you potentially have, you don't want to have a scenario where you have 20 million devices you upgrade and half of them are running one version or half are running the other. So what you can do is you can basically tell the bootloader to swap and confirm. And this typically depends on your process. For some people, even at the 20 million device scale, you're going to always want to swap to the new image and directly tell it to confirm that image and assume you have some sort of end to end check. In other scenarios, you're just going to want to say, nope, swap and confirm, run the new image. I'd rather you run the new image and take that risk than I would run two incompatible versions in a network. And this was, for example, at Silver Spring, we did large-scale mesh networks. So we had five million devices and continuous networks with 10,000 devices all meshing for each other. When we did a large-scale upgrade, we did not want to have to test compatibility of networking stacks at that scale with half of the devices running one image and half the devices running another. So we ran our confirmation process up to about 10,000 or 20,000 devices where we would actually confirm on every device. And then when we pushed it out to the full network, we would just switch and confirm. If you're running a connected wearable over Bluetooth and the phone is right there, you might always want it to fall back. So it really depends on what you want to do. So a little bit about source layout. So I mean, the best thing to do with MCU boot is it works on pretty much any platform that Minute supports, as well as more and more Zephyr platforms, at least the K64F. But I think Lenaro has tested it on more. Okay. So it runs on those same platforms on Minute. It also runs on Zephyr. So if you download Zephyr Minute, there are instructions in the bootloader for building for each of those platforms. And so you can actually play around with it. I'm going to talk mostly about Minute because that's just what I'm more comfortable with. But Zephyr works equally well. So don't be shy about trying it with Zephyr either.  On every device that Minute runs on, you always have a bootloader. So the bootloader is located on the Nordic series, address zero. And you have to flash the bootloader to the device before you actually have the image. So we always go through the bootloader on the Minute system so you're able to download it. If you go to the GitHub address in the slide, so github.com slash runtime co slash MCU boot. What you'll see is a number of directories. And this is just to give you a little bit of an overview on those directories. So there's apps boot. Apps boot is a sample boot application for Minute. So it's what the bootloader itself is actually a library that you can compile in and link to specific locations in the core of the bootloader. In Minute, what we do to create our bootloader that runs on most devices is we have an application called apps boot, which simply brings in the bootloader library and defines a main function and calls into the bootloader. And that's pretty much all it does. Zephyr I think does something very similar. There's boot serial support. So we do support serial boot builder upgrades. That is the one exception to the rule when it comes to the application providing the software upgrade. And this is done for a lot for maker platforms actually was why we originally implemented it. So a lot of maker platforms don't have built-in debugger support, but they ship those devices. So this would be an example of this would be some of the Arduinos as well as the Adafruit has a Feather series where they don't want to spend the extra money on the Jlink chip or their users don't. And so the way they upgrade new software to these devices is over the bootloader. The bootloader is located in a right protect sector. And then you can use boot serial to load new firmware onto a device. You know, typical bootloaders like UBoot and other bootloaders have support for upgrade within them as well. I think over time we'd be happy to add Bluetooth support to the bootloader or USB or ethernet or any of those things. It's not really a high priority for us because most of our upgrade paths end up going through the running kernel image itself, but it's something that we certainly welcome as a contribution and can be any optional thing that is compiled into the bootloader. If you're looking for the core source of the bootloader, that's in boot.util. The Zephyr-based abstraction, so the way that Zephyr has implemented support for this bootloader is the bootloader itself leverages the minute APIs when running on minute for accessing the flash and things like that. So we have a HAL flash API. What Lenaro has done is they've gone ahead and they've created a mapping for the HAL flash APIs to Zephyr's driver interfaces. And so when you look at boot Zephyr, that is the Zephyr port of the bootloader. And there are instructions in the bootloader directory that describe how to build the system for Zephyr. I think Zephyr builds it about the same size as minute. So the abstraction itself doesn't end up costing a lot of code space. Image tool. So there's two ways of creating signed images that can be downloaded or creating manufacturing images that can be downloaded. You can either use the new tool if you're working within the minute framework. And so that tool is newt. There was just a talk on it. And that tool will allow you to create an image out of a minute system. It'll allow you to have a version with that image. It'll allow you to sign that image. It'll also allow you to create a manufacturing image which contains the bootloader itself, the super block, a default image to run, and an empty slot, so a full flash layout that you can load. And that's tied in with the minute system. Obviously, our goal is to make this bootloader work across all operating system interfaces. So we want Riot to use this. We want this to work with freeRTOS. It's our goal to make this a bootloader that everybody can use and that we all share effort on. So having that be the newt system is probably not the right way of doing that. So we've created a separate tool called image tool, which is image signing and generation for the MCU boot project. So if you're using this with other operating systems, you can use that tool. It actually shares source code with the minute system. So minute is written in, newt's package manager is newt. It's written in go. In go, the images, when you distribute a product, it's statically linked and compiled. And that works across Windows, Linux, and Mac. So essentially what image tool does is it just brings in the same signing and generation libraries that are in minute. And it uses those to create images in an operating system independent fashion. So there's no downside to using image tool and it'll work on pretty much any platform you run. And then there's sim, which is a great project done by David Brown from Lunaro, which essentially takes the boot util package from minute, and it runs it through its paces on Unix and Linux systems. So essentially it links in the C file that is boot util, which is just a library that is brought into other systems, and it simulates a local flash system. And so on every commit we can actually run the boot util simulator and run through a full set of test cases on the minute boot loader to actually ensure these things work well. And actually that was that slide. So I think that we covered all of that. So the Apache minute boot loader is fairly, go ahead. Yeah, so the Zephyr source abstraction is, it's essentially, so for example with the boot loader itself, we need some way of accessing flash, to load the images, to erase flash, to write flash. The boot loader itself uses an interface in minute, which is our how, which is how flash, and how flash defines the flashes that are in the system, as well as APIs for accessing and reading those flashes. We have a flash map, which defines is the super block with the information about what's on the flash and defines access mechanisms for that super block. Those are all minute specific APIs. So in boot Zephyr, there are implementations of those minute specific APIs, and there's not a ton of them. There's a handful that map into the Zephyr implementations itself. So for example Zephyr has a driver's flash. And so there's a file there that basically has how flash, which is the minute API mappings into Zephyr's mappings. And it doesn't add too much code. As I said, they end up being about the same size. So Zephyr fits pretty much in everything that minute fits in when it comes to these. But it allows us both to use our own underlying hardware implementations. So when you compile MCU boot for the MCU boot system, you pretty much support every system that Zephyr supports. When you compile MCU boot with the minute system, you pretty much support every system minute supports. And very similarly, we hope to do the same with Riot and other Oasis. So it's a hall area? It's just a hall area. That was more succinct. So Apache minute boot loader is approaching 1.0 now. So it's been, we've done, we've been in active development on it for over a year. That development has died down about three months ago. So the Apache minute boot loader is still within the Apache minute project. This is, that is not MCU boot, although we've maintained compatibility between the two projects. Apache minute is a project that is independent of runtime. We are obviously big contributors to that project and big supporters. But it is the Apache minute project's decision as to which boot loader to use. As runtime, though, we've, we've broken out MCU boot. I think our goal now is to, is to work towards the first release of MCU boot that supports both Zephyr and minute. And that will be, it will essentially be the Apache minute boot loader at 1.0 with full Zephyr support. And that's kind of what we consider our starting point, right? Because what we really want is to get everybody collaborating on the same system. And there are definitely features we need to add to this boot loader and improvements we need to make. But we want to make them as a community and we want to make them across multiple operating systems. And so the boot loader itself for the platforms it supports is, is very stable. We run, we have probably run hundreds of thousands of upgrades with it reliably on these devices, obviously not one at a time. So it's fairly stable for where it's run. But MCU boot does not yet have its first release. We're working towards that very rapidly. I don't think we're about too far off. So I think you should see that within the next three months. And then there's a whole bunch of future work we need to do. So the, and we would love, by the way, contributors and people to join in the effort. We're recruiting you. Please feel free to join. It's an open project. But some of the things we want to do that we haven't done is we have no support currently for hardware APIs for a lot of things. Like, so for example, a lot of the more modern hardware for secure boot will have multiple keys actually written into the hardware and those keys are fusible. So if you want to invalidate a key, you can no longer use that key and that's fusible within the hardware. We don't support any of that. We want to be able to support multi-stage boot loaders. So a lot of times what you'll see in devices is you'll have a very, very simple, rommable portion of the boot loader which literally just verifies the portion of the boot loader that gets written to flash. So it will just perform the signing and verification on that device. You'll often see this especially when a boot loader is located in an external flash as an example. On internal flashes like you have on the Nordic system, it's not that big a deal. But in a lot of cases, one of the potential attacks on a boot loader is if you have a flash that's external, if the boot loader itself is not signed, even if it's a secure boot loader, somebody can just desolder the flash and solder on a new flash and then they can ship an invalid product and the customer has no idea until everything goes wrong. So having a section of the boot loader that is rommable that can sign the actual boot loader and then having the boot loader itself which does the swaps and manages the images is something that we'd like to do in making it very clear what's rommable and what isn't. Support for loading images into RAM, this is a very common one. So often, you know, one architecture is, and this is the architecture in STMs as well as in Minute in the K64, is that you run directly from flash and you run in a fixed location in flash. Another very common architecture is that you have an external spy flash, that's where you locate the image, you have say a meg of RAM on the chip itself, you divide that RAM into where you want to run your image and what your data and BSS and heap is, and then you run your image directly out of the RAM on the chip. We don't support that currently, we obviously need to add that and we'll be adding that. And then supporting, support for replace instead of swap. This has been, this is not a feature we've released a lot but we've definitely heard it from people which is right now we swap the two images so that you can always fall back to the replacement image. There is a, there has been, there have been requests to essentially just erase the old image and replace the new one on top of it to reduce the complexity of the swap. That's an option that we're looking at adding and supporting. And then the major one and I think our real, our real goal here is support for other OS's besides Apache Minute and Zephyr. So we're looking to broaden the support for this bootloader as widely as possible. It's not very hard to do because you know there's a, there's a few things that we had to do to get it to work with Zephyr. It was implementing the HAL. It was, and then it was looking at being flexible about where interrupt vectors were located. So in Minute we located interrupt vectors in RAM because we believe life is too short to have interrupt vectors in text. Zephyr locates them in text. And so if you locate the interrupt vectors in text you need to be able to start the image header offset within the image itself because often interrupt vectors will start as zero or at some fixed location in the image. And so you need to have the image header pass the interrupt vectors themselves. So that was some of the work we had to do. We, I imagine there'll be other little things that we have to implement when we go and we add riot support and free RTOS support and all the other OSs. But I think our primary goal is really to get as many operating systems supported as possible. Because I think if we can, the goal here is really to drive everybody to share a secure bootloader and share the effort. It's not that much code. It's 12K compiled code for these systems. And it really makes sense to all share efforts on certification and security testing and really just make this a very simple and solid bootloader. So that's going to be where the majority of runtime's efforts are focused over the next couple months. And that's pretty much it. So that's the talk about the bootloader. Are there any questions that folks have? Well, so there's a couple things. It's really a configuration option. So there's a couple of layouts that you can have for this. One is you just have to size the slots and basically size your flash to ensure that you have enough room for growth. So our rule of thumb was we basically, when we would select flash, we would basically take double whatever our initial code size estimates were and made sure we had enough flash to do that. And you have to size the slots appropriately. The other option we support in minute is essentially what we do is we don't have a concept really. We have the concept of an application and a kernel. And so what we end up doing is slot zero becomes the kernel itself and it's just the kernel. And then slot one becomes the application. And we end up basically essentially what happens is if you want to do a new upgrade, you erase the application, you load the kernel into the application slot, then you copy the kernel down into slot zero, and then you upload a new application into slot one and you can size those appropriately. So those are the options we've supported. Exactly. Well, they're housed and making sure that they boot appropriately. So just going through and making sure on a regular basis that we test to make sure that we are booting Zephyr. I'm booting Riot on every platform that Riot boots on and similarly for Zephyr, right? Trying to get some alignment there. There is an effort that we're looking to start that's separate from this, which is to share efforts also on the software upgrade schemes themselves. We think that that should be a separate project from the bootloader because we think it should be a part of the running kernel itself and that there's going to be some diversity there, right? For Bluetooth, the way we do upgrades for Bluetooth is over OIC, which is Iotivity, and then we have a Seaborr-based upgrade protocol that runs over Bluetooth. When you're running in a Wi-Fi scenario, you're behind a NAT and you're probably going to want to dial into the cloud and talk to the cloud. So the upgrade protocol and the software that it does upgrades is going to change based upon the transports in the application. The bootloader should remain the same for all of those. So we are looking at a separate effort, which is to, at least for Bluetooth, all converge on an upgrade scheme and start those, but those won't be part of the MCU boot project. There's a standard interface. There's basically a flash interface that you have to tell the bootloader to boot to a new image or to do something. There's a few set of TLVs that you have to basically put it through its paces. And so that'll be standardized for whatever software upgrade protocol you end up using. I saw a hand over there. Sure. So basically every image is signed. So the way typically a secure boot scheme works is that you have a private key that you, as a company, will keep very secret. We, I think, used HSMs to sign our firmware images. The actual key material itself was printed on paper and put in like 30 different locations. And you all had to take it back together. And it was, it was painful. And we actually, these HSMs also give you policies, right? So what you can do is you can require that a product manager, an engineer, and a QA person all have to like, you know, give their thumbprint and sign away their firstborn to sign every firmware image. So those images get signed with the private key, which you keep as a developer or as a company very safe. On every single device that gets manufactured, you put the public component of that private key. And so what the bootloader does is when it comes up and it looks at the image to boot, it goes through and it computes a SHA-256 of the image, which is what actually gets signed by the tool. And then it uses the public key to verify that the private component of that image gets booted. And so that's how you ensure that the image you're booting is an authentic image that you should have booted. The public key is, as I mentioned, it depends, it's up to you. It could be stored on your laptop. I wouldn't recommend it. The public key or the private key? The private key you're using to sign the image is stored by the company that's signing it. So when you create a downloadable software image, you have that private key, at Silver Spring, we do new create image and you provide it with the private key or you provide it with the address of an HSM that can perform the signing operation. Yes, so that's stored right at the end of the bootloader itself. So it's in the right protect portion of the flash itself. Exactly. Well, you can locate it anywhere you wanted flash. Typically, you would locate it within the right protect portion of your flash. Put that image as well. So we locate it at the end of the bootloader. The bootloader itself is not signed today. That would be the thing that we would need to do to make it romable. Right. So essentially, when you have a romable bootloader, what you want to have is you want to have some portion that's located within the chip itself that is preloaded and romped in the chip. That comes out. You have a signed bootloader or a signed image and that gets verified by the rom portion of the chip, but that has no complexity beyond signing, beyond verifying the signature of the bootloader itself. Then the bootloader boots up and it goes and operates the upgrade. Exactly. Typically, those are managed by the chip vendors themselves. So when you start to do kind of higher volume manufacturing, you can actually work with the chip vendors to provide custom rom masks for your security certificates. Well, so we want to get down, I mean, we have to kind of, at least from a runtime perspective, support 16K of RAM and 128K of flash. I think if you look at kind of MCUs that are out there, that's the bottom limit for most of them. You certainly have smaller ones. I think 8K of RAM would be fine as well. We typically don't see many MCUs below that these days. 128. Yeah. It's rare. I mean, you will see 32K of flash on some of these devices. It's very rare. It would probably work on those devices, but although I don't think it would be very useful. Yeah, exactly right. Because we're now 12K of that for the bootloader and then how big is your image actually and do you want it to be secure? So I think for us, kind of where we're targeting is 8 to 16K of RAM and I think 8 is fine, but 128K of flash, which is what you see on most chips today, even the previous generation chips. And then on the upper end, sky is the limit, but I'd say it'd be rare to find anything beyond 128 megs of flash because typically at that point people run Linux.  But it doesn't really matter. I mean, we have enough address space for all of those chips. Yeah. So this is one other thing. Since you're looking at the standard rolling out there, is the superblock going to be some sort of managed somewhere? Is the way that that's defined? Yes. So there is a documentation on the image format itself, as well as on the superblock format that's maintained as part of the project. Everything is documented within the project and maintained as a part of the project. And we want to grow that and really have both the specification of the flash layout and of the superblock and the bootloader and how that works tied in with the bootloader itself. And Zephyr and all of the projects, I think it really benefits us all to just agree on the flash format itself and have a consistent way of understanding how the flash has been programmed. And starting at the bootloader just seems like a good place to do that. One sector of flash. Yeah. So it depends what your sector ends up being. So if you have 2K sectors, 2K, 8K sectors, 8K. Or rather, it has to be the size of the largest sector that you're going to erase within the slots themselves. Today, no, but that would be certainly something that's easy to add to the project and we'd be happy to add. Oh, you can certainly define more than, oh, sorry, these are just image slots. Yeah. So the flash map itself, you can define areas that are for file systems. So in minute, we have a file system, which is a log structure file system called NFFS. So you can say, I want this area to be for NFFS. We have a configuration variable storage mechanism as well that is just purely TLV config variables. And you can define those as an additional one. These are just the image slots.  Any other questions? Awesome. Well, on that note, thank you very much and cheers.


From theCUBE Studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. Hi, I'm Stu Miniman and welcome to a special CUBE Conversation. Digging into some of the hottest topics in tech, of course, multi-cloud has been one of the big things we've been talking about for a number of years, the maturation from just cloud in general, hybrid cloud and multi-cloud. Happy to welcome back to the program, one of our CUBE alumni, Chandomai Mondal. He is the director of marketing from Dell Technologies. Chandomai, pleasure to see you. Happy to be here. All right, so last year we were together for Dell Technologies World, VMworld and of course, I've seen how these solutions have been expanding out, partnerships, especially a lot of it from Dell side, leveraging VMware technologies to extend and connect to what your customers are doing with their cloud strategies. So give us the update as to what you're hearing from customers and how Dell is moving to meet them. Sure, cloud adoption is really growing. And even from the three hyperscalers, AWS, Azure and Google Cloud, there are over 500 different surfaces today. And with this past phase of innovation, I see customers adopting many different surfaces from these public cloud vendors. And again, they want to adopt these surfaces because they are differentiated. They have workloads that can leverage the surfaces and sometimes even from leveraging the same dataset. One challenge that we are seeing is how do customers move data around from one cloud to another so that they can take advantage of the great innovation that is happening with cloud storage or cloud provider because moving the data comes with not only the migration risk, but also huge egress fees, the time it takes. So solving this customer challenge is our number one priority in the cloud offering. Great, Chenamai, you brought up a bunch of really good points there. Of course, nobody solved the speed of light issue. So we know data has gravity, it's not easy to move it. And yeah, absolutely, I've been saying for the last couple of years that data is one of those flywheels when it comes to the cloud. But once you've got it in there, it's not kind of the traditional lock-in, but I have access to the data. I have access to the services and it's not easy to move it out even if customers would want to take advantage of multiple services from multiple clouds. So I'd love to hear, what's Dell's role in this discussion? How are you helping us make our data more of a multi-cloud enabled environment? Absolutely, absolutely, Stu. So with us, Dell Technologies Cloud Storage for Multi-Cloud, we are delivering scalable, resilient, cloud-attached storage with flexible multi-cloud access options, ideal for securely deploying or moving demanding applications to the cloud for many different use cases. The way we are doing it, effectively, that customers can leverage, block, or file storage consumed as a service directly from any different clouds like AWS, Google Cloud, Azure, and we are providing very high-speed, low-latency connections from Dell EMC storage from a managed service provider location using the Direct Cloud Connect option. And let me give you an example. We have Dell EMC Isoland Industries, number one, Gelout NAS. It has very high performance, drives large throughput, scales to multi-petabyte use cases, have multiple different protocol access simultaneously from many different applications. Now, the same Isoland today can be leveraged as Dell Technologies Cloud Storage with direct access to Azure, Google Cloud, AWS, consumed in the cloud operating model. So now, you can run your applications in any cloud while having data sitting outside of your cloud with the high-performance, high-speed access that you need. That's where we are bringing the innovation and the value. Okay, and if I heard you right-hand of my, this is a managed service solution because if I want that high-speed direct connection with Azure and with AWS, normally I need to be in some service provider. Dell, of course, has lots of partners that offer those services. I'm not just talking about connecting my array that I have in my data center connected over the internet because that wouldn't necessarily give me the bandwidth and performance that I need. Did I get that correct? Yeah, absolutely. Because again, you need this connection and co-location with the hyperscalers to get the high-speed connection, say in the case of Microsoft Azure, the Express Route, you need to be co-located in a facility like right next to them so that you have the high bandwidth, high performance that you need for this application. Yeah, that makes a lot of sense. It's kind of your hyperscale adjacent. You just throw that connection. It's relatively close. Might help if maybe if you've got a customer, an industry example of what the real life expectation and use cases for a solution like this. Sure, so let me give you the example of our genomic analysis. Now, is genome sequencer in a single cycle for a human being that creates 100 gigabytes of data and that's just like raw data? You need to run analysis, different types of analysis to the effects that are drug or something having on the DNA. Now, for example, NVIDIA Parabrix is a popular sequencing software that needs to be run on this dataset. And again, it drives very high throughput. Sometimes it needs 100 gigabytes per second throughput to drive the performance. Now, we have worked with Microsoft Azure very closely in using Microsoft Express Route. You can actually get that bandwidth that throughput for running Parabrix or next gen sequencing VMs in Azure leveraging ISA learn. And in fact, we have worked with Azure to provide a completely aggressive data movement. So when this application is writing back data to this application array, to the array as part of the technology cloud storage, there is zero fee associated with it. And it's not just Microsoft Azure, right? You can have the same dataset and run this Parabrix or next gen sequencing VMs in Google Cloud, AWS, Azure simultaneously, thereby scaling up this process much faster. So if you are a pharmaceutical company trying to cure for a disease spreading across the globe, you need to run this on hundreds of thousands of patients creating hundreds of terabytes to petabytes of data. Then you can actually scale up the process across three or more different clouds very quickly. This truly shows you how you can leverage the power of ISA learn, the scalable high-performance storage in a multi-cloud world. Yeah, very interesting. You talked about no cost for egress fee and that can be one of those architectural killers. You think you have a good solution for a cloud, you put things out and then all of a sudden you start getting things on your bill that you weren't expecting. Is there something special that the customer needs to do for this service? Is that you're saying is that a partnership with Dell and Microsoft? Or how does this differ from the traditional egress fees that I'm used to getting for whether I'm using AWS, Azure or Google? So this is like a Dell and Microsoft Azure partnership. So that's where you do not get charged with the egress fee when the applications running in Azure connecting back to LEMC storage as part of the cloud storage services. Okay, excellent. Because yeah, I mean, Chenemi, I'm sure you're well familiar. A lot of times people look at cloud and they're said, okay, when I look at the economic, if it's compute intensive, it makes a little bit more sense. If it's data intensive, there's lots of reasons that it might not make sense. So this is unlocking some of that data capabilities. I guess that leads to some of the opportunity around AI is of course, I need to think about my architecture. A lot of times data is not going to leave the edge environments, autonomous vehicles, an obvious use cape that we talk about. Usually there's training in a central location, but then I need to be able to actually do the work at the edge. So what does this cloud storage for multi-cloud, how does AI fit into this old gut? So yes, for AI, you need to train very large data sets for a long time and to get to the results like you opt in or you want. You gave the example of autonomous driving, right? The self-driving car need to understand many different scenarios, whether it's an IC road, a kid on the road, it's a slippery condition, or they are running into a brick wall, so on and so forth. Now, when it comes to dealing with this petabytes worth of data set, and you need to train these models, okay? You need very specific servers, GPU powered servers, okay? Now, to scale, you think that you'd go to the cloud and then you will be able to get the computer need. However, turns out cloud is not an amorphous homogeneous place. Between the vendors, there is huge difference in terms of what GPU powered server you can get. And even within one particular cloud vendor, depending on the region, this vary widely. So it becomes critical that you can have data set that can be connected from many different clouds, from many different regions as you need it. And one more thing I want to highlight, AI is actually one area where these cloud providers are providing very differentiated services. So in the autonomous vehicle example, there are several stages of model training depending on like what you are trying to achieve at one point in time. Now, you can one day, or for one part of the process, you can leverage AWS PageMaker for your model training. On the other part, you probably would like a TensorFlow for from Google Cloud to do it. Now, when you have your data set outside of the cloud and you have the fast connection from many different cloud, you can take advantage not only the different GPU powered servers, but also differentiated software services that are available from these cloud providers. All right, so, Chandamai, how does the VMware cloud solution fit into this discussion? I know it's been a important piece of the Dell Technologies cloud piece. So how does the multi-cloud storage, VMware cloud and the multi-cloud piece fit together? Sure, so VMware cloud on AWS is one of the key offering that we have, and it also fits into the multi-cloud story very well. Actually, let me explain that with a customer example. We have one of the world's largest energy company down in Texas. They have four petabyte data lake on Isola. And this is all seismic data. They are running analytic workloads to figure out exactly which place in the ocean they should drill, and precision on here can be like millions of dollars of different. Now, they wanted to set up a secondary data center in the case of a disaster. What we were able to do is to spin up a PR service for this customer leveraging Dell Technologies cloud storage. So they replicate the data to the cloud, and then we spin up their PR environment with VMware cloud on AWS, okay? And now the data is already in the cloud. So they got their PR service with VMware cloud on AWS, but with the same dataset. Now they are running those seismic analytics workloads from AWS, Google cloud, and Azure. They are by speeding up the process of finding the next location to drill. So you see the example where we leveraged DMC on AWS for DRS as a service, and since the dataset is already there, now they are running their analytics workloads for their regular operation. Great, well, definitely a quite a bit of maturation in the Dell cloud solution, how that fits into multi-cloud. Help put a point on it, Chandumai, if you would. The conversations you're having with customers and Dell's role in the multi-cloud discussion. Sure, so there are two important things. First, the ability to scale to many different clouds, to leverage the different surfaces, the compute infrastructure, so on and so forth. And the second part of it is, depending on the applications, right, you might need to leverage for the same workload working on the same dataset, different surfaces from different providers. Dell technology's cloud storage for multi-cloud is enabling that for our entire customer set. And I will close out with one more important aspect. If you are the customer who is just starting your cloud journey, or one single cloud provider calls your cloud needs for today. But still, you want to architect your solution so that when the need comes, you can actually leverage multi-cloud for compute or other surfaces. So if you decouple your surfaces from where your data is, while doing the cloud access, that actually makes your cloud architecture future-proof. So with Dell technology's cloud storage for multi-cloud, we are helping customers not only today, but also for future. All right, well, Chandramayandal, thanks so much for the updates. Congratulations to the team on the process. And look forward to talking to you again in the future. Thank you. All right, I'm Stu Miniman. Thank you so much for watching theCUBE.


Excellent, Mern, Atlantis. Yeah, we appreciated the KU peak. It was vivid down here, too. Floating into view in this live television picture from the flight deck of Atlantis, Commander Jim Weatherby, now in his fourth flight into space. Weatherby's last mission more than two years ago, aboard Discovery on the STS-63 mission, was the first rendezvous with the Mir space station in which Weatherby guided Discovery to within 37 feet of the Mir in a practice, a dress rehearsal, if you will, for the eventual initial docking of the shuttle to the Mir two months or several months later by Commander Hoot Gibson. There is pilot Mike Bloomfield about to make his way down into the mid-deck of Atlantis as the astronauts continue to set up equipment in preparation for the day's activities. We got all seven of us down yesterday when we had all the equipment down there for recovery after a great launch and a very short flight day one to stow everything, it was amazing. The troops here did a great job, it was an incredible ride. He did a great job, he had a couple of launch pad, which didn't amount to much, but it does cause us to identify the failures and deciding what to do about it, which was basically nothing because Atlantis is such a great ship. It turned out they were just ducer problems and the work he saw a couple of inches that we wanted to, so we're on our way to Mir, which we should be there by tomorrow to get set up for the running boot tomorrow. Work as a team tomorrow, everyone coordinated and the processing of the vehicle. I'd like to echo what Jim said, thanks to all the great troops that made all this possible. It was really the greatest ride of my life, a real e-ticket ride, and we're all very busy on our first flight day, but things are really coming together for the crew. And I'd just like to point out in this picture that too short, Lawrence is really taller than I am in space. I guess everybody always wants to know are you nervous on the launch pad? And probably enough, we're busy enough or thinking about enough that we're not usually, but in the last 15, 30 seconds, you start thinking about it and Scott and Bob, already up here, what about these guys that are just incredibly all pro at this and this is what professional astronauts are all about is pulling this off safely because when those solids go, start gimbling on the ground and the vehicle starts shaking around and you know there's a lot of moving parts here under G in the suit and I just thought about those guys up there and guys are just the best there are and you should see them up here. It was pretty impressive, the launch, the most impressive thing is it started out dark as we're sitting on the pad, but all the way up hill, it was basically daylight and the fire behind us pushing us up in and right at SRB set, you can see the SRBs come off and it's a very, very impressive show. I hope it looked just as neat on the ground and it's great to be up here with a great crew that are making life easy for me. One new experience for me on my fourth flight, this is the first time I've had the double space have module and I did get to float down the tunnel past the volumes that were going to dock with me and it's a pretty long way so it was awfully fun floating down there, the length of the tunnel. We hope to have more of these short visits with you where we get everybody up on camera and thanks a lot, it's time for us to get back to work. Dr. David Wolfe, I think it would be an understatement to say that the whole world is watching and is very concerned about you going aboard the Mir. Are you the least bit concerned about going on Mir? I always take space flight seriously and I'm concerned as I would be in any other space flight, but the Mir is in excellent condition to my mind and I'm looking forward to being over there.  How would this mission compare being on Mir with your stunt piloting experiences? Starts, I do aerobatics and which are, I don't consider that particularly dangerous as long as you do it carefully and don't cross the line and that's how I plan to conduct this mission also in a conservative fashion and we'll do it very safely. Commander Lawrence, besides dropping off David Wolfe and picking up Michael Foll, you're delivering some much needed supplies to the Mir including a new computer and drinking water. Atlantis is supposed to dock with Mir tomorrow. What happens if the Mir's computer goes out before the shuttle docks with it? Going off to the commander since he's been training for that scenario right up until launch. Okay, go ahead. I'll also say that we do have a long tunnel between our living quarters here and the space hab and I do stunts going down there in between what I'm trying to get from one place to another. We love to do rolls and flips as we're translating. That's where we do our stunts in between modules. If they lose their computer before we dock we will separate it for a safe distance away and allow them to reboot the computer. They've been successful in doing that. They've practiced that technique over the past couple of weeks and they are very good at rebooting it now and getting it back up to speed. Mir will regain control capability and then we will dock maybe the next day. If they lose it in close, we can continue the rendezvous and the docking manually and Scott and Mike just match the rates that we have with the Mir and then I continue to dock and Volodic continues to take ranging measurements with a laser gun that's similar to a police laser for ranging information. So either way, if it doesn't fail, we'll have a successful docking hopefully. If it does, then they can reboot it. Commander Lawrence, give us an idea of some of the supplies that you're gonna be carrying up to Mir. In addition to computer for the Mir and water for the Mir, we're taking over a gyrodion which will also improve the motion control system. We're also taking over a great deal of scientific hardware that David will need to complete his mission. Their experiments are in a wide range of disciplines. You will be doing some experiments that will help us better understand how the human body functions in weightlessness over long periods of time, specifically studying the loss of calcium which is very important because it's very applicable to patients who are bedridden for a long period of time. We're also gonna continue a series of protein crystal growth experiments. We have a handful of experiments that we will be transferring once we docked and then we also have a very interesting experiment. In fact, David has participated in this field for many years. We are gonna be growing some tissues on board, some cancer tissues that we hope in the long run will help us better understand that disease and find a cure for it. So there's a great, great number of experiments that are going over an even larger amount of hardware for MIR and other, of course, food and personal equipment for Dave, but we're gonna be very, very busy transferring about 7,000 pounds of equipment. David Wolf, do you anticipate doing space walks while you're there trying to find the leak in the MIR? I sure would like to. We have trained extensively for both a group of scientific space walks and to do repair work in various scenarios, but we'll have to watch that as it unfolds. Of course, we have Pavel and Anna Tolle who are up there in extremely capable cosmonauts, so I'll be happy to help them from inside also. Do you think that the problems with the MIR have been blown out of proportion? Well, none of the minds of those of us working in the space program both the Americans and the Russians because we don't think that they're out of proportion. We don't think that they're big failures. Some of them, of course, were. The fire was very dangerous for about several minutes, but once it was taken care of, then there is no more danger and the decompression, of course, was a short-term event that after they isolated the leak within about three minutes doing a great job as a crew, then the danger has passed and so we go about our business to try to fix problems and ensure that they don't happen again. We don't dwell on the failures other than to make sure that we do everything we can to make sure that they don't happen again and we improve our redundancy in the future design of the International Space Station. They may be blown out of proportion in other people's minds, but those of us working in the program don't really see it that way. Okay, Bill, we're ready. In fact, in case you guys are wondering what these big blocks are floating around here, these are pieces of the argometer, which we're kind of in the process of setting up while we're doing other things. Hey, copy Dave, we're two minutes to the ZOE and we'll pick you back up at 1833. Now, having gotten that out of the way, let's see, what we see, it looks like you have is the balanced unbalanced. You got a free-flowing cable coming out of one end. Now is one of the ends at the other end of the cable connected to the PDIP? It's then connected back to a white cable to the one says, the open one says TVIP video cable and the other one is a downlink balanced, unbalanced TV video cable. And Dave, do you know, have you located the actual SSV box itself? Yeah, that's a completely separate box. It's got a number of LEDs on it. It should be powered. It's got a DC utility power cable or a PGSE power cable that goes into it. The other cable to that box also comes out of the PDIP panel, out of the J107 port. Pat Peresewski on the left side in the foreground of the camera closest to the camera and Vladimir Titov sitting on the right side, cockpit closest to the camera, like Bloomfield in the pilot seat up on the right and I'm in the left side. You can see the checklists in front with the xenon lamps illuminating a portion of Mike's checklist, of course the three CRTs. I think we've already had the access arm retract and here comes main engine ignition and then six seconds later you'll see SRB ignition. The light show and the violence as we go uphill. I don't recall, I don't remember it being this much vibration because we're concentrating, of course, on engine parameters in the roll program, et cetera. A sensor that we had on the fuel cell, staying on this flight where we had first-stage guidance for steering. As you can see, a light show out the front windows as we get higher into the center atmosphere that gets eliminated in front of us and you see that out the window at pretty much like daytime. One G vertical acceleration at lift-off builds to about three Gs after two minutes or indication we looked at that briefly. The light show that you see here, it's pretty incredible. Of each solid that pushes the solid rocket boosters away from the vehicle so that we can continue to accelerate uphill using the fuel and the external tank and the three main engine options in the Atlantic Ocean, picked up with ships and refurbished after SRB set and raise our visors. As we approach Mach 25, Mike is concentrating more and more on the engines and there's main engine cutoff and you see we instantly decelerate to zero times before some gravity and we're immediately weightless. Then a few seconds, the external tank drops off of the vehicle and it drops into the ocean and there are the jets firing and the pyrotechnics that separate the external tank. We are traveling at orbital speed in our overdue from the jets and as the jets fire for attitude control, you can see them, the light bouncing off of the haze that's around us and it flashes like radiation into the space flight business on its first flight with the two failures right off the launch pad which were relatively minor but yet the master alarm rings and it gets your attention. Right at external tank separation, he had his third failure, the jet on the left side of the vehicle, the third manifold that is pointed in the down direction that helps the tail go up if we fire that jet, failed. Question and warning system correctly and propellant from the vehicle out through the main engines and that takes a couple of minutes after main engine cutoff and it is slightly propulsive even though the propellant is not ignited or on fire as it comes out of the vehicle, it is mass flow and it also wants to cause the vehicle to change its attitude or pitch a little bit and so the jets are firing here and you see them again flashing every time the jet fires relative to the earth but we don't think about that at all especially if we're not looking out the window and seeing the earth.


Welcome to the talk. My name is Dustin Yance. This is design systems aren't hard But they are complex and also hard On the internet. I'm known as mills the opt-af which is a name. I picked in 1998 and I just never got around to changing I've been working on large websites since roughly 2008 I've been working with design systems since we used to call them swatches or even just style tiles. I Currently work in design engineering and indeed which is a job that I think comes with probably the greatest laptop sticking around So you might be asking yourself. What exactly is a design system? I first saw this graphic from Nate Baldwin in a talk at artifact conference fall of 2019 It really drove home. Just how many different definitions there are to the term design system just how complicated it can be Each of those circles is an artifact and the team made that artifact whether it's you know, the UI kit The component library the documentation a Lot of people don't think about content strategy as part of a design system, but it definitely is and If you kind of squint your eyes and look at this just right kind of starts to resemble. I don't know like an orchard Conway's law states Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations It's kind of a long-winded way of saying that products tend to resemble the communication of the teams that build those products Uncle Dave Rupert has his own law Your website is a manifestation of your organization's problems Products tend to reflect the communication problems of the teams building that product If you take a look at this graphic one more time We can see that each of these artifacts is coming from a different team either communicating or not communicating with other teams Something like documentation Maybe it's owned by a product team or maybe it's owned by a technical writers The UI presentation layer could be owned by a UX department While the actual UI kit and the visual design language is owned by maybe a brand team Or a marketing team teams that you know don't necessarily work together on a day-to-day basis And that isn't really you know clear things up when you're trying to think about what a design system is So let's think about it from a different angle What isn't a design system a figma library? That's not a design system You know a figma library or a UI kit built with some other tool It could have all of your components in it. It can have all of your colors all of your buttons You can show people how your your menus look You know this is going to represent maybe one team's idea of the design system really well But it may not be perfectly suited to another team You know developers They like figments a lot nicer than using some other software at times For a developer to get in and get the data that they need to make the product that they need But it doesn't tell them you know it often doesn't tell them things like how things look when they animate or what they look like when a page transitions So okay, maybe a figma library. That's not a design system What else what else is in a design system a react component library? This is the kind of thing the developers always want when they're talking about a design system They want something that lets them do the least amount of work when it comes to building new product new interface a React component library is a great way to share code easily Helps you build functional prototypes or even entire products really quickly with a minimum of custom code But this still isn't a design system It doesn't always say it doesn't always reflect the flow of a customer through the product very well It'll show you know what a button looks like or what a form looks like But it can't actually show you what it looks like to go from beginning to end for a customer So what else? An external website promoting your design system You know, I think we all love to check out the latest design systems that are being released by some of the big companies out there The you know the Google's the Github's All kinds of really great things to look at things to learn from Lightning's been doing really great work with web components Polaris is amazing for theming But these are actually not design systems either these these are just kind of a snapshot Frozen in time of the system that that company is actually using internally a Lot of times these public versions that they release they can lag by months or even years Behind what is actually being used inside of the company? These are all the artifacts These are not the system So what is a design system at the root? It's an agreement on how digital products are made That's all it's an agreement within your team or your department or your company On what your products are what they look like and how they work What kind of agreements are we talking about? We're talking about user interface design how the digital experience looks Interaction design how it feels you know when you're actually clicking around when you're going through and using the software Content strategy again, this isn't always super obvious, but this is a huge part of a design system We need to know how our digital experience should sound to the customer when they're when they're reading our interface and Near and dear to my heart documentation We need to know how this digital experience is crafted whether we're designers or developers Whether we're in marketing it doesn't matter We need to know the decisions that have been made and why they've been made And that's documentation design systems Unfortunately, they take time. They take time because it takes time to reach an agreement on big things on small things You might be surprised to learn just how long it can take to agree about something as simple as a button You know just your standard primary button can be weeks or months of back-and-forth and negotiation Maybe you're testing your ideas and your assumptions in your live product using a B testing This is going to take time Here are the primary buttons from five five different design systems They're all very similar. They're all buttons. They all have text You can click them and they do a thing But they'll have very distinct differences whether it's color or shape shadow Sometimes a design system will have a paper icons on a button. Sometimes it won't on the internet the button is one of your primary interaction points with a customer and That means that a lot of people have a lot of opinions about it inside of your company It's going to be a large source of frustration when you start building a design system So you need to be prepared for that. So we know they take time But you know time is money and that means that design systems take money You can't shortchange this you should take the time to do it right So I bother I mean this seems like seems like an awful lot We've we've got a you know, we got to think about oh, we have to you know agree on buttons We have to agree on typography We have to agree on the tools that we're going to use So what are we getting out of this? And the answer to borrow a business word is scale Design systems are all about it You're going to get interface design at scale interaction building at scale content creation at scale When everyone on your team knows how a thing should be built They can just go build it They don't have to stop and think they don't have to ask questions. They just know in my current job I'm working on design systems And we do a lot of support more support than you might think and The absolute number one question we get how do I do X? How do I use a primary button? How do I use a secondary button in relation to a primary button? How do I invoke a modal and the number two question? Why? This is you know as important if not more important than the first one To give people the ability to do things on their own They need to know not only what they should do But they also need to know why they should do it so that the next time they encounter a problem They can apply that rationale and come up with their own answer and not have to come to you I believe that a design system is a service not a product and this it can be difficult inside of companies To convince people of this They want to treat it like a product. They want to do roadmaps as if it was a product But at the end of the day, it's not it's a service It is providing answers. It is deciding on new answers to new questions It's you know helping people integrate the design system with a new product or an existing product you know legacy code bases that power large chunks of corporate websites are Very hard to get design systems to work in sometimes and that is the job You know treating it like a service You know having support channels having dedicated people and those support channels people who aren't writing code that day All they're doing is there to ask questions answer questions Because really you need to answer questions Not rate code Coming back to this picture You know again, there's a lot of artifacts here What do you think is the most important one what would you guess You know, I think if you come from a design background you're gonna Kind of tend towards the ones that are kind of reddish pink the UI presentation layer or the components or the UI kit If you're a product person, you're gonna be very drawn to the purple you're gonna want to talk a lot about processes If you come from a brand background where you're thinking about you know Like that the holistic look and feel of a company Content strategy is gonna stick out as well as the visual design language If you're a UI person, you know, maybe a little bit of everything And if you're a developer, I mean dev standards, that's a big one So which one's the biggest the most important If you only have the time or the money to do one thing and do it well What should it be? I would say documentation I think documentation is the single most important piece of the puzzle a Design system we've already talked about is a made up of agreements You need to write those agreements down You can't just say oh well, you know two months ago in a meeting on Tuesday Somebody said this so let's do that You need to have it written down where everybody can see it and review it and understand it and edit it as they need That is the most important thing you can do If you have the budget, I would strongly recommend You hire a service designer. This may not be a job tell you've heard of before. I Hadn't before I started my current job A service designer is there to think about people and think about infrastructure You can think of them as the personification of documentation and customer support They may often come from a UI background or development background But they are there to think from you know A to Z about the customer They can help drive adoption of new design systems. If you know you have a deadline You need to have a design system rolled out by a certain date. They are absolutely invaluable They are the extroverts To the to the development and design introverts. They will make the relationships They will you know find the data convince the stakeholders that need to be convinced They are fantastic And finally your documentation should change as often as necessary Shouldn't think of it as set in stone You know we're not writing things in spiral notebooks But you should think about what kind of software that you use when you're writing down your documentation It should be something that's easy to edit quick to edit that everybody has access to I would recommend not using a git repository. I think that's a common pitfall for teams, you know Developers they love git repositories. They love markdown But that's not the friendliest for designers or product Designers love things like sigma. They love to write things down in there. That's not the friendliest for a developer So think you know think about something kind of abstracted something agnostic I've seen people use things like notion really well You can you know, obviously use something like Google Docs. It's got a lot of great tools One of the nice things about something like Google Docs is it lets you know who changed something And when it changed which can be super important down the road at the end of the day Design systems can be used to help everyone. That's a great thing When I say everyone I don't just mean designers and developers, but specifically the users Users that aren't always thought about Design systems give you accessibility at scale They give you a system that you can be reasonably assured a button is going to work as a button Links are going to work as links Animations are going to automatically respect the prefers reduced motion directive Without having to think about it without having to write extra code Somebody can simply pull in an animated component and know that it's going to work in an accessible manner It also gives you inclusion at scale You can be sure that when you pull in a form field, it's going to accept accented characters It's going to accept You know you various types of unicode like somebody wants to put an emoji in a field It'll probably work if you've made one form field work that way. They should all work that way Things like right-to-left text presentation is just going to work This is an incredibly difficult thing to do on just about every product. I've ever worked on But once you do it once and you do it, right? It's really easy to use that across all of the different places where you're displaying text In our in our products that indeed We actually have we are global company We have lots of job postings that are mixed languages and this is a very complicated thing to fix Once you fix it once it's it's fixed Somebody wants to write a job title on Japanese and a job description in English easy somebody wants to write a job title in German and a job description in Arabic It's done. That's great So always think about you know how you can take those hard problems that need to be solved and Figure out a way to solve them once for everybody Drive that that scale of inclusion that scale of accessibility so If you learn nothing else from this talk learn this if you do nothing else Write documentation If you can do nothing else plus one thing higher service designer Design systems are hard And that's the work And that's okay There's you know in our industry. It's it's really It's really tempting to try and make things easy for ourselves as designers and as developers at the expense of ease of use for an end user And we need to avoid that trap We need to do the hard work. We need to find you know the unified methods of working for our teams So that you can reap the rewards long term Superior experience is not just for your developers and your designers, but also your end users Just want to drop some resource links here at the end some of the places where I found some of the information on this Hopefully you've learned something. Hopefully you can take something back and make your team a little bit better Thank you very much. Have a good day


Yeah, new book coming out in September. It's called climate a new story And the purpose of the title all part of partly is because it is about climate and Most people don't read anything that has climate in the title So I thought okay cuz like right. I already know what it's gonna say and and I feel helpless to do anything about it and and You know, it's just too depressing. Etc. Etc. So that's why I also put a new story in there but also because it's accurate to the content because it says that or One thing it says is that the Basic narrative that we have around climate change is itself part of the problem that Climate change is a lot bigger than we think it is that We have put way too much emphasis on fossil fuels and emissions and not nearly enough emphasis on Ecosystems biodiversity water soil Forests wetlands and so forth and the reason for that the reason we need to put more emphasis on that is that this planet is alive Not just a complicated machine whose inputs we can monkey with to create a better Result, but that it's a living being and that through what is called development We are destroying the organs and the tissues of this living being. That's what the forests are That's what the coral reefs are. That's what the the the wetlands are the mangroves The grasslands these are organs of a living being and we degrade those and then the body of This being becomes less capable of dealing with challenges one of those challenges could be rising levels of atmospheric gases But it could be other challenges too, and if we keep so basically my thesis is and and you know, I have a lot of I cite various science to Substantiate it, but my thesis is basically that even if we cut emissions to zero overnight if we continue to degrade the biosphere the planet will still die a death of a million cuts and That we might not even face global warming we could face global cooling we could face climate derangement where we have these gyrations and fluctuations of Like like like if your body were unable to maintain It's constant temperature anymore unable to maintain homeostasis because of one organ after another is getting degraded Like that's the crisis that we face so Basically, then we need to shift toward earth care toward regeneration toward conservation Toward healing what has been damaged over hundreds and hundreds of years like in New Zealand Most of the rivers are so poised and you can't even wade in them like much less swim or drink from them and That's not because of climate change That's because of you know agriculture runoff and toxic pollution and mining and things like that and that kind of seems like You know in the dominant narrative, that's not an existential threat to the planet You know, it's like that kind of comes second first thing is carbon And then we can you know deal with the toxic waste and stuff like that and the plastics and things like that And I think that mentality is mistaken I think that we that it really is the opposite that the we cannot have a healthy planet without healthy rivers So that brings the focus of environmental urgency to a more local level, which also is more tangible Doesn't require trust in the institutions of science That you know whose computer models tell us that in 50 years sea levels are going to rise by whatever But like we can see the we can see the damage right in front of our face here and now and we we can Act on it here and now and that doesn't mean that we can continue business as usual and You know pick up the litter. No, this is Requires a fundamental change to our relationship to this material world a change toward Every single decision takes into account more than just ourselves