Okay. Hello everybody. Hello. My name is Joshua Locke. You made my belt non-deterministic, prepared to sigh. I'm a staff open source engineer at VMware and this talk is an expansion of a Twitter thread I wrote in response to the question, how many of the author's readers had reproducible builds? My thread started with the image on the screen. Having worked on build systems and their security for over a decade at this point, with around 10 years of those being a core contributor to the Yocto project and open embedded in the past three years also being on the update framework and salsa projects. I wanted to share my experience and discuss the three main interpretations of the term reproducible that I've encountered when I've been talking to people about build reproducibility and build outputs. And with me today is my colleague. Hello. I'm Rose Judge. I'm a senior open source engineer at VMware focused on a combination of software build materials, containers, and supply chain security. Joshua and I are here today hoping this talk helps you think about what outcomes you're trying to achieve in the context of reproducible builds and whether your stack supports achieving those with a reasonable amount of effort. There we go. So as Joshua somewhat alluded to, reproducible builds, they aren't new, right? Efforts around reproducible builds have existed for at least a decade now. But the rise in popularity and focus around reproducible builds certainly feels like it is increased in the wake of a surge in supply chain attacks. We can even see this increased focus right here at the conference in the fact that there are two talks on reproducible build alone. And what this ultimately comes down to is a heightened interest in how we can utilize reproducible builds to defend ourselves against supply chain compromise. And as it turns out, having traceability to source during your software compilation process is one of the best ways you can do this. But the benefits that reproducible builds can deliver stretch beyond just supply chain security. Their rise in popularity is as simple as the fact that they are a desirable part of good engineering practice that we as developers are striving for. For example, reproducible builds require enabling caching of intermediate build artifacts, which makes it easier to reproduce, trace, and debug future issues. This in turn requires a thoughtful storage method for storing those build artifacts, which leads to things like storage optimization and improved content availability. And ultimately, implementing reproducible builds encourages a certain level of overall thoughtfulness and consideration when developing and delivering software. So yes, reproducible builds aid in supply chain security and engineering best practices, but why else are they important? Well, they're important because they reduce the need to trust build services, which as we've seen with the SolarWinds attack can be a real threat. So whether that build service is a dedicated production machine, a CI instance, or your laptop, instead of having to implicitly trust that a build service is not compromised and not injecting your build with malicious code, if your software is bit for bit reproducible, you can easily verify and confirm that no backdoor injections have taken place simply by rerunning the build in a different build environment and comparing the results. And this gives you flexibility in which build systems you can use. Reproducible builds also can provide assurances around what software has and will be shipped in the future. So if you know that your build process can be 100% bit for bit reproduced when given the same set of build inputs, you can trace any release past or present back to source. And this is helpful for things like recreating and debugging customer issues when they arise in a release, even a release from two years ago, or determining if a developer build system has been compromised, or maybe a binary deliverable is lost somehow. If your build is reproducible, it's a low effort task to rebuild it exactly as it was. And really, all of these benefits lend themselves to the general theme of reliability for your software. So it's reliable for developers because the software they're developing is easy to share between different development and production environments. It's easy to ensure that build artifacts have not been tampered with during the release process. And there's a reliable caching mechanism in place to record the ingredients for these builds. From a customer standpoint, it's reliable because they know the software they're consuming is secure. They know that checks for tampering have taken place, and they know that should they need an older version for anything, it's available to recreate without much effort. And when I say all this out loud, it sounds obvious, like, great, I'll run the same steps with my source code, I'll have a reproducible build, and I get all these benefits. But what do we really mean when we say reproducible? Yeah, that's a great question. And I think most people intend the same thing when they say they want a build to be reproducible. But the reality is that modern software is complex. So we might say that when I run my build again, I get the same output, that's a reproducible build, but maybe we don't define same output the same way. And that asterisk here is the ambiguity of the statement is really the space in which the talk that we're giving today exists. The reality of our deployments doesn't always meet our expectations, our intent. Differences are often a matter of the software stack we're using, or maybe even the experience of the engineers involved. So when we talk about what it means to be reproducible, it can be that I invoke a build and have the same sequence of commands execute, that's one potential interpretation, or that I can do that. And regardless of where the build happens or when the same sequence of commands is executed and the same equivalent output is produced, or maybe I can do that and get an aspect of the same cryptographic digest, or as Roy said earlier, that's a bit for bit identical output. So during this talk, we'll provide three interpretations that we just loosely stated, which you can think of as levels of reproducibility. And each of those levels has its own supply chain security implications. So I mentioned intention versus practice and there's several reasons why reproducibility is not achieved despite the intention. And we're going to uncover these a bit more as we continue to talk, but at a high level, the three main reasons are build system behavior. So most build systems that we as software engineers use today, we're developed in more innocent times, or perhaps with different priorities, a build system that prioritizes enabling new users to adopt an ecosystem quickly, for example. And these build systems, they capture states often with the intent of adding debugability or just unintentionally capture some kind of state that has implications on the reproducibility of the build. Another factor is that modern software systems are extremely complicated and they tend to be composed of multiple components in multiple layers. And unless you're bootstrapping that entire thing and the tools that you use to produce it from source, which is clearly a non-trivial effort, the layering and the interaction of these different ecosystems can work against you when it comes to achieving reproducibility. And then the final factor, it's just cost. Achieving reproducible builds today takes engineering effort. Achieving reproducible builds requires some long-term storage. And for many organizations, that cost is either unattainable or not easy to prioritize. So fundamentally, I think as well, but purely or strictly reproducible builds are just not something that most engineers, technologists think about. And arguably, they shouldn't really have to. So as Joshua mentioned, we've come up with three different terms and associated definitions for how we can define reproducible. And each of these definitions provides a different level of reproducibility. Each have their own unique quality guarantees, but also their own limitations as to the security assurances they can provide. And as we ascend to each of the next levels here, we'll all get a little closer to unlocking the galaxy brain inside of us. So on this slide, I'll cover the high-level definitions for each. And then we'll continue to dig deeper into some of the nuance surrounding each definition throughout the rest of this talk. So even before these levels, and as you saw in the previous slide, the most elementary level to all of this is an unscripted build, meaning some piece of software is built without any sort of automation. Instead, a human is manually running a series of steps to create the final artifact. And even if the same series of steps are being run, we can't assume that this process is repeatable. There's human error that might be introduced. There's different build environments to consider. And without any sort of build script, we're not able to reproduce this final artifact consistently. But as we move towards reproducibility, we get to this first level, which we're calling repeatable builds. And repeatable builds control these steps for a build. So this means that the build is scripted. And therefore, I can reliably repeat the build process with some level of guarantee that the steps will be executed in the same order, regardless if I'm running the build on my laptop or a CI system. And regardless of where I'm running it, because I'm using a build script that is inherently repeatable, I expect this build to do relatively the same thing, whether I run it today or two weeks from now. The next level of reproducibility, we've coined as rebuildable builds. Rebuildable builds control all explicit inputs for a build. So if your builds are executing at this rebuildable level, you're using some sort of build script. But it also means that your build processes and infrastructure systems are capturing some of the states that are not controlled in a repeatable build process. And by controlling things like artifact repositories and cash give intermediate build artifacts, you're able to produce an equivalent artifact that can be reproduced at any arbitrary future point in time. I did not use the word identical here. And that's on purpose. That's because a rebuildable build will not guarantee a binary identical artifact, but it will guarantee an equivalent artifact and we'll cover nuances between those definitions shortly. The last rung of this reproducible builds ladder can be thought of as the end goal that we're all striving for. So it builds on all the levels before it. And it's what we're calling binary reproducible. So you may have also heard terms like hermetic or deterministic builds. And those mean the same thing for the purpose of this talk, but we felt that binary reproducible is the most clear and descriptive label for it. So binary reproducible builds control all states of the build. So this means that regardless of when and where the build is run, when you run a build with the same inputs, which by nature are fully detailed, you're able to achieve bit for bit identical outputs. And when we're talking about these definitions, you might hear us use the phrase regardless of when a build was run. And I think sometimes we hear this and we think, oh yeah, the build should be the same now and two months from now or three months from now. But I want you to stretch that timeline a little bit and think of it in the scope of years. So if I ran a build a year from now and a build today with the same inputs, how different would those outputs be? Or is that even possible with my build process right now? So for each of these levels, there's an inherent overlap. Each subsequent level necessitates the one before it. Rebuildable builds are founded upon the same principles as repeatable builds. And binary reproducible builds incorporate all the requirements for repeatable and rebuildable builds with additional build process controls. At each reproducible level, we see an increased security benefit and more protection against malicious backdoor injections. Okay, so let's dig into that first definition of it. So a repeatable build, as Rosa's already described, is a build we can repeat on the same or a different system and expect the same steps to be executed. Repeatable builds require that we have some kind of scripted build process, which is just frankly saying software engineering. We need to be able to run the builds and have them behave the same way, whether it's our workstation or our CI system or a colleague's workstation. And we might achieve this with a makefile or maybe with the common build tool for your ecosystem. But however we do that, we have something that everyone has access to and is virtual controlled that we can use to run the build. But a repeatable build is often temporal. If I run a build script today and then run it again in three weeks, I wouldn't expect the same things to happen. And mostly that's what we already touched up, that modern software utilizes a significant amount of kind of layering and a large amount of third party and open source components that are typically retrieved at build time from package repositories and where these direction transitive dependencies are usually not life cycle managed by default. That introduces opportunity for the build to behave differently in future. And so managing the burn for the complex layer cake of cloud software becomes really difficult or really even any modern kind of software build of complex software. It can be challenging to manage the tree of dependencies. So I think I just expand on this a bit but repeatable builds really apart from that dependency problem, the other factor is in what makes them not a suitable solution, not the end goal that we're looking for is that the tools involved by default often capture too much of the local system state. So a typical build script and the toolshades that are called will often include various factors of both the system state and the user's configuration when it's running the build. So you might see things like paths and timestamps embedded in the outputs, how the software behaves might be affected by time zone obviously with the embedded timestamps or locale because different locales sort strings differently for example and these all impact the produced output and prevent it from being binary reproducible. And the dependency problem is often underspecified in a scripted build. So typically scripts might capture the top level dependencies for a project but won't dig in and capture all of the tree of dependencies that they in turn build pull into the build. So even if a user is diligent and pins their dependencies, the indirect dependencies, you typically represent volatile inputs and these any features over the network can and will fail in the future whether it's through some kind of accident or malicious intent. So it's almost impossible to rely on a download from the internet so that will affect our ability to repeat the build picture. So in summary, repeatable builds give you confidence when you need to be able to reliably perform the build again and one of the probably the biggest or perhaps even the only software supply chain security benefit of them is that when you need to release a build on short notice, certainly if you're trying to issue an urgent fix under pressure you definitely don't want to be following manual build steps. So having a scripted build, having a reliable development and release process is going to be a major boon when it comes to making a release under pressure and of course it's really important for your developer services saying developers are important for your software supply chain security but it's not going to provide any benefits for security or compliance monitoring reproducing bugs in the future and isn't going to prevent a situation where your builds are breaking because third party components have disappeared. So as you recall the next level of reproducible builds is rebuildable builds which is a level in which we control the explicit inputs for a build. The rebuildable builds are build processes that can reproduce two equivalent but not necessarily identical artifacts at arbitrary points in time and get the same output.  This means that you likely have some sort of caching mechanism for intermediate build artifacts and those artifacts can reliably be retrieved at a future date. It means that you're not pulling artifacts from third party locations but instead you're mirroring them internally or rebuilding them from source which is also under your control and compared to repeatable builds there's a significant effort increase to achieve rebuildable build status so an example of a repeatable build might be a docker file or a rebuildable build excuse me it might be a docker file with dependencies that are being pulled from an internal repository with the pulling from an internal repository really being the key. It doesn't mean that you're only specifying a version of a dependency you're installing and it certainly does not mean that you're using a generic tag to specify your base image rather it implies that anything being installed in your container comes from a controlled repository and this can be really difficult when you take into account that you have base images you have direct dependencies you have transitive dependencies those can add up very quickly and since I did use a docker file example I'd also offer a word of caution regarding the layer caching mechanism that docker uses to build container images so as you might be aware each docker file command corresponds to a different layer in the resulting container image that gets built and as it builds docker locally caches each of these layers on disk so that it's faster the next time you build because docker will use the built layer served from your local cache and each time the build is run on that same machine docker will use the local cache for that layer unless the docker file run command changes or files being copied in have changed in which case subsequent layers will be rebuilt and this caching can kind of give a false sense of security to developers right developers think great as long as my docker files recorded my build is cached therefore intermediate artifacts are stored and I have a reproducible built however if you are using fresh environments for your builds or the builds are happening on temporary ci systems that cache is not going to be available which means that your build is not actually reproducible now you might be thinking okay I'm following a build script I control the intermediate build artifacts what would make the final artifact not binary identical at different points in time and this is something that can happen when dates times build paths those types of things are embedded in the built objects either by the build system or otherwise so if this happens the final artifact is likely going to differ at different points in time especially if it's built on different build systems in a perfect world these variables like time or date stamps and build paths would either not exist or be declared as explicit build inputs when date stamps or build paths are included as part of your build it makes it impossible to reproduce bit for bit even though arguably in most cases slight variations like time stamps won't actually change the fundamental behavior of the software but if they exist they do make it more difficult to detect malicious anomalies and impossible to automate any checks for reproducibility using Shaw sums when you're comparing final artifacts so in practice rebuildable builds offer more assurance than not and certainly more so than repeatable builds controlling the explicit inputs for a build offer protection against a scenario where build artifacts may become unavailable at a future date and as Joshua kind of touched on before this might happen maliciously say when a developer suddenly yanks all their published modules or intentionally publishes malicious code in protest or it may happen harmlessly like when distributions garbage collect old versions of packages as they publish newer versions rebuildable builds improve the reliability of the entire development and release process and they ensure successful business continuity when providing delivered software and support to customers and I know in this SAS and containers world that a lot of us operate in it's hard to imagine that there's software out there that isn't running on latest but as someone who has worked at IBM let me tell you that it exists there's embedded software running on legacy hardware that is years old and if you're a software vendor without any way to rebuild old versions or at the very least access some copy of an older version there's no way an engineer is going to be able to reproduce and debug a customer issue in the field just upgrade your software is good advice but it's unfortunately not always a feasible solution and if you're providing support to customers in a situation like this rebuildable builds are prerequisite for remediating customer issues and like anything in life there's tradeoffs and this is especially true when achieving rebuildable build status and that tradeoff that fee primer primarily presents itself in the form of infrastructure costs so if you're mirroring dependencies and storing intermediate build artifacts you need some place to put them and with any sort of scale that storage is not going to be free and while I personally think the cost pays for itself and benefits it is still a cost right and if you're not a company with Google sized resources this might be a factor in how you move towards implementing rebuildable builds okay so now we get to the third level definition and this is the only one where we actually include the word reproducible in the name so binary reproducible builds as Rose already said you might hear them referred to as deterministic builds or hermetic builds and effectively the definition is quite simple when I rerun a build with the same inputs I get bit for bit identical outputs regardless of who where and when and so the build environment must be fully defined in order to be able to achieve this we need if we want to provide the same inputs to the build we have to fully define what all of those inputs are and a reasonable modern example of our achieving a reproducible build is with the go program language you know you can vendor your dependencies which fetches all of the dependencies from the network and includes them in a copy in a folder in your project tree and then you can perform the build with the vendor dependencies you can use the trim path command to remove the path prefixes so that only the relative path gets included in the objects and you can pass some linker flags to remove some other things from the built objects so that you could if you ran this go build command on a different system at a different point in time in the future as long as you had the vended source in your project tree then you would get the same output and when I say same of course mean bit for bit identical output so a binary reproducible build is inherently reproducible all the time starry happy face but of course as implied throughout this talk it can be a loss of frowning parent face so the amount of work required depends a lot on the language and tool chain and use it tends to scale with the complexity of the system we just demonstrated it's fairly easy to produce a reproducible go binary and the same is true for some other ecosystems like python wheels nowadays are fairly easy to create a binary reproducible python wheel but it gets more complex if you include the transitive dependencies of the python wheel or if your code base has multiple implementation languages if you're using java and c++ you're probably going to have a lot of work ahead of you maybe you're running on containers as rhodes already indicated they could be quite a lot of work to manage to achieve reproducibility for all of the layers involved if you've got a combination of all of the above you've probably got significantly more work involved in achieving binary reproducible builds so solving this problem for all of the components you ingest into your project third and first party can be massive the supply chain implications of binary reproducible builds are quite significant a major advantage is you don't have to impressively trust the machine you're doing your builds up and for most software engineers you don't can we and we don't control the builds we're doing our machine the machines we're doing our builds on we're using cloud services ci infrastructure as a service whatever it is you know we they're just black boxes we're running our builds on so being able to verify reproducible builds elsewhere is is great it's really good for and just the engineering effectiveness of your entire project that would argue it can help improve the reliability of the entire development and release process because your chance of flaky builds is effectively diminished because if it's binary reproducible you would expect that you can reproduce the failure as well as the success it provides cutting benefits makes delivery optimization easier but as i discussed it it can be very difficult it's not without its cost which is why despite the fact that many smart people have been working towards achieving this goal for a long time it hasn't been achieved by default for many projects so now we know what reproducible actually means when i run my build at two arbitrary points in time regardless of the build machine i get the same bit for bit identical output i don't need to inherently trust my build service which gives me choice gives me flexibility and peace of mind and maybe you've listened to the talk thus far and thought okay i understand the progression i understand the differences between these levels but why should i care about this of course binary reproducible is the gold standard but as you guys have said it sounds hard it is hard and does it really add many more security assurances for the effort that it takes to achieve so should we really care about binary reproducible builds i would argue as open source developers especially we should care i think it's important for all developers but especially for open source developers most of our users will look at us funny if we throw some code over the wall or we throw build over the wall and yet other packages that we're all downloading from open source repositories really that different um our users choose often implicitly to trust the the developers and their source code by its nature source code is verifiable and with distributed revision control systems it's easier to detect tampering this has happened in the wild with git and commit signing also helps provide some additional guarantees here too but between accessible source code and conveniently usable binaries there are um the build systems and the platforms on which the binaries are produced and the content repositories we store those binaries in and these are all places where a backdoor or unauthorized tampering can be introduced verifiably reproducible builds provide a way to prove a binary matches the claim source even if the user does build from source on their own systems a verifiably reproducible build provides them a convenient mechanism to reduce the need to trust their own systems if not the tampering so given the uh advocacy for binary reproducible builds what can we do to move towards uh making this a reality before we uh devise a plan for how we can implement this how we can move towards it in the future i think we need to also understand what's preventing us from achieving binary reproducible builds right now the first is a lack in common understanding and maybe even verbiage for what type of reproducible reproducibility level your software is actually achieving so i've spoken to well-intentioned folks who think their build is reproducible because they have a docker file which in their eyes is a record of how to rebuild their container it's reproducible and if you take a very loose definition of reproducible this is technically true you can reproduce the steps to generate the container but as we've covered there's a lot that is not reproducible about this and it's especially not binary reproducible which others might colloquially understand to be the default definition when somebody says i have a reproducible build there's also purely a realistic aspect to this in that effort and resources are required to achieve binary reproducibility and this gets harder to do the further up the stack you go and as the scope and scale of your software increases a project with no direct dependencies is going to be much easier to binary reproduce than a project where you have to mirror and communicate a thousand dependencies right um reproducible builds are also hard to achieve today as tools can sometimes work against us and i'm not picking on docker here but i think docker is a good example of why this can sometimes be hard docker and the way it builds containers in a layering format using local cache and the way that most docker files are written are uh to pull from latest and to pull from random corners of the internet and i think this demonstrates how what can seem like reasonable decisions um or reasonable tradeoffs can make achieving binary reproducible builds harder developers can't utilize the default functionality of the tool um and they can't if they can't do that then they can't get build reproducibility by default instead they have to consciously make and implement other trust decisions that require more work to achieve so what can we do then as individual developers as teams working on software projects to work to build towards reputable builds um i think the first thing is understanding the factors that affect build reproducibility and avoiding those bitfalls and i i hope that our talk and benard's talk earlier um provide some good uh impetus and some some good information and the reproducible builds website is really a valuable resource for understanding and some of the specifics there i also think it's important to scope appropriately so things you directly control your projects the container images you produce etc are much easier to affect than trying to solve this the entire ecosystem in a single swoop incremental progress is going to help you um feel like you're achieving things uh it takes a long time to go especially for complex software projects it takes a very long time to go from not at all reproducible to fully reproducible um and we see this in for example the microsoft windows uh operating system has been building towards reproducible builds across several major OS releases i'm not sure if they achieved it fully yet but um it's certainly taken a number of years for that uh operating system to achieve um the gains they have i also think it's important uh to adopt the mechanisms that exist for your ecosystem so python and go are well served but there are also efforts happening in other ecosystems and they might not be happening in the default tools but it's much easier to change one of the tools you're using to produce your software than it is to rewrite all of your software um and finally i think uh if your tools don't support reproducible builds if you're in a position where you can choose new tools i would recommend that you select tools that do support reproducible builds but otherwise i also think it's useful to um file a feature request uh and and make the people producing the tools know that this is a priority for their users i think it's really interesting that um there's a the original motivation for the unpackaged manager for JavaScript was actually being able to manage dependencies consistently across machines being able to reproducibly uh deploy Java packages um so i think you know the more tool developers understand that we care about these things the more they will prioritize the features we care about and there's also work we can do as a community the open source something's all about open source communities i think um some of the some of the ways we can come together as a community and improve build reproducibility is investing in both the ecosystem and the tooling and by investing i mean both uh monitoring investments but also you know time investment actually collaborating with those ecosystems so the reproducible builds project we've talked about a few times so um so a working group in a collaboration space that develops standards produces tools and um define specifications to enable projects to achieve big build reproducibility the Debian and SUSE projects have been deeply involved in uh reproducible builds for a long time and both of their Linux distributions are trending towards being you know significantly uh reproducible um there's a great project called rebuild-a-d which can monitor our packages uh monitor a distributions package repository and attempt to verify whether the packages that are put published by the distribution are reproducible so the more um rebuilders that are deployed to verify these reproducible builds the better for the entire ecosystem if not everyone has to rebuild from source to verify that the built artifact matches the source uh we can gain confidence through helping each other out through rebut you know pooling our resources and and rebuilding uh across multiple systems and developing some kind of confidence metric based on the number of systems which have been able to reliably reproduce uh and I also think the SUSE project is is worth a look for anyone that's interested in software supply chain security and uh build system security the SUSE project provides guidelines for protecting against tampering with the projects and the build systems and recommends reproducible builds as a way to achieve that at higher levels reproducible builds are the first ripple in the water as we move towards engineering excellence and a more secure software supply chain but why should we stop there now that we understand the principles and motivations behind reproducible builds why not apply those everywhere so yes reproducible builds but maybe reproducible build servers reproducible infrastructure let's aim for full traceability and confidence in every part of the development cycle if we verifiably derive as much of our pipeline and infrastructure from source code we can require multi-party approval of changes and redeploy with ease this idea of reproducibility also ensures that we don't need to keep anything for extended periods of time so we can just recreate it when we need it instead of storing it and this idea of short-lived everything in the development pipeline means more secure software all around it means even if bad actors are able to gain access to a build system one time they don't retain that access and by regularly redeploying ephemeral environments and hosts we can protect against root kits and other persistent threats applying consistent and reliable reproducibility principles to our software development pipelines and infrastructure is not just good for you and your software it's good for the entire ecosystem it provides transparency as to how things are done which makes it harder for bad actors to hide and it provides an audit trail which makes it easy to spot malicious actors when they attempt to intervene we're confident that the industry is headed in the right direction as we see an increased focus on reproducible builds today and an increased focus on development best practices and we certainly hope that this talk was informative and maybe you even learned something so thank you so much for your time we're here to answer any questions and continue for their discussion thank you


Aloha, my name is Elaine Gallant and I am your host of Books, Books, Books, a live streaming series to think tech Hawaii on a walkthrough. This is a show where you might talk about reading books, writing books, and anything in between. Today's guest is Paul Devlin Wood. He's a long-favored Maui son, a writer and author, journalist, and instructor of imaginative advanced, imaginative writing at the University of Hawaii Maui College. He's an advanced teaching artist with the Hawaii State Foundation on culture and arts. He's also a novelist, co-novelist, and writing coach. His work has garnered many awards, including the Elliott Cades Award for Literature by the Hawaii Literary Arts Council. Please, let's welcome Paul Devlin Wood. How are you, Paul? Hey. Oh, there I am. Great. I'm so happy. I just didn't recognize myself from that glorious introduction. Being a writer is, hmm, well, I won't deny. That's wonderful. Well, I have to tell you, we've never met in person and only recently just corresponded due to this show. But I've been a secret fan of yours for over 25 years. What do you think of that? I hope I have more secret fans out there. I hope they become less secret. No, that's really nice.  I'm not a particularly good marketer. I think I'm a good writer, but good. Yeah, well, you are a good writer, and I first noticed your writing in the Maui News. But I have to ask you, since it was brought up in our pre-show correspondence and it became the title of a show, you're a writer in Hawaii. Yeah.  Yeah. Well, I don't mean anything disrespectful about Hawaii. I'm a writer in Hawaii because I live here, but also because it's a fascinating place to write about. And to do that, I had to give up being anywhere in the proximity of Manhattan or wherever other people are doing things. And not to put myself in any kind of special position, but there aren't that many people writing in the state that I know of. I mean, there are people and friends and people whose work I respect, but there's a whole lot to say that hasn't been said. And we're shrouded in the influence of the visitor industry, which has its own way of writing about where we are. And it struck me early on in my youth that there's something going on here that the visitor industry doesn't expand to include. So I found my way of being a writer in Hawaii and it's been really diverse and kind of risky. Yes, because you're writing is diverse. I want to talk about that. I see you as a satirist or even a humorist, but you've written some very serious or co-authored and coached, some very serious books as well. So that's quite a range for a writer. So how do you describe your writing as yourself as a writer? Are you a satirist? Oh, well, I like to make people laugh. I think that's, it's a tricky thing to even endeavor to do, but there's not enough of it going on in the world.  Somebody once called me, it was really out of the blue. I was at a restaurant and somebody introduced me and someone I never saw again said, oh, yes, you're the Paul Wood, you're the chronicler of the minutiae. Well, that's cool. But in other words, I find delight in looking at very, very close up at small things. Yes. I find you writing that way too. I really do. I think you have a, you have a, you know, what they have those gels on cameras that change the color of things. When you look at life, you have one of those gel sleeves over and it just puts a funny new twist on it. But before we get into the fun stuff, let's talk about the book that really bore me that you co-authored and that is Laura Gancho. If we can see the cover of that novel, you co-authored this with Ed Padilla.  You want to talk about either of those two because I could, I cannot get Laura Gancho out of my head. I really can't. Sure. I've read it like twice. Yeah. And if I go on too long, just signal me. I will stop you. Laura Gancho is a prison escape story and it's a, it's a true story, a true account. And I want to say something about that in a minute. But I met Ed Padilla at a friend's house. He, he had, he and two of his friends had been arrested in Peru in the 70s and were not sentenced at all, just thrown into the world's worst prison, Laura Gancho, on the outskirts of Lima, Peru. And, and they had been smuggling cocaine and had been, he had been doing it repeatedly. He had an interesting background, kid from Southern California, who is half Mexican, who couldn't get hired for that reason at Disneyland. He grew up in the Long Beach area. And what I'm getting at is he became a founding member of a group called the Brotherhood of Eternal Love, which was a hippie group that was excelled at smuggling marijuana and, and especially LSD. They got into promoting LSD and it became quite an international agency. But all, a lot, most of those people in the Brotherhood came to Maui around 1970. It was less surveillance there and they were sort of kicking back and they served. And so Ed was on Maui. But that, and then it was during that interval in the 70s that he started smuggling cocaine, which was, he realized afterwards was a terrible thing to do. Yeah, ended up in that, in the world's worst prison and ended up escaping. So a little bit on Holy Hell, because that's another one. You did not co-author that one, but you helped Gail. Treadwell, I think Treadwell, did we say? Yes, Treadwell. Yeah, Gail Treadwell, yeah. You coached her on this book because it was a very difficult subject for her to, I mean, she was literally enslaved. Well, that, yeah, in a way, psychologically, let's put it that way. She became a devotee of an internationally famous Hindu saint, the hugging saint, Amma, who a lot of people will recognize that name. And when Amma was just starting, Gail, who is an Australian woman, was in India and became enthralled with her presence and her, you know, whatever she stood for and became her personal assistant. And the relationship became abusive after a while. And so she knew things about Amma and her private life that were a burden for her. And Amma became quite vindictive. It was just a, that's why it was called Holy Hell. It became a Holy Hell for her. And she ended up fleeing. She was under such severe surveillance that she had to hide in the back seat of a car at night and be driven away. And yeah, she came to Maui as a refuge. And because I have a reputation, people find me, you know, who can help me write, write as a, in this case, as a form of self-curing, really. And, and she didn't know how to do it. And I just sat down with her. I talked to her last week, after we talked about doing this show. And she's in good shape. She's moving, because the economy has shifted, she's moving to New Zealand. But she feels like the whole project, she was, she just told the story of her season over many years with Amma. And she did not tell it in a vindictive way. She told it honestly. And she still feels very loving toward Amma. But she felt that she had to get out of there and had to purge this. Yeah, she had to save herself. And, you know, when I read it, I thought, oh my goodness, how often does this go on in the, in all kinds of organizations, right? I mean, but this one, it was, it was a moving story. And I really wish her well. So, what did you... Five criminal charges against her in India, by the way. Gail does or Amma? Gail does, yes. All sorts of obscure Hindu laws have been levied against her. Yes. Well, you know, it's terrible that these same things happen in life. But we're so fortunate that people can write about them as, especially in the way that they have been written, because we can, we can follow it. We can understand it. We can appreciate their, the survivorship that they experienced. And both of these novels are about surviving, about survival. So, how many books have you written yourself?  Well, I have two books in print that are available through, I mean, I self-published them through Amazon. And these are collections of columns I've done. I've done a lot of short pieces. And Upstart, Scallywag, Giveaway for Free, kind of tabloid fold newspapers. I started doing that in the early 90s, when if somebody I knew was a stained glass artist, started a tabloid fold newspaper called The Holly Acula Times. It was paid for by advertising, was passed out and sent out in the mail to people for, and suddenly I had a, I started to help him get it organized. And then he gave me page two to do anything I want with it. So I called the column Four Wheels, Five Corners, which is a direct reference to where I was living at that time around Makawau, Haiku, Upcountry Maui. And there's an intersection called Five Corners and it's a truck kind of neighborhood, as most of Maui is actually. Which you have another fan in that very area. And her name is Susan, let's see, hold on, let's see, Susan Armstrong. And she says, do you have a favorite essay from your Four Wheels, Five Corners column? And would you like to read a little bit? I did, I brought something. Thank you. And I'll take a bit out of it. The whole business of writing a column for one's community taught me really how to be a writer. I was always a writer since I was a kid. But it wasn't until I got to that point where I knew who my audience was. When I went to pump gas in Makawau, the woman behind the window was collecting my money. I just thought, that's my reader there. And it made me realize that I was communicating with people. And then I was able to write about whatever was up. And this piece I just brought, I haven't put this in book form. But it has to do with, I wrote it on the solstice. It's called Blind Man Swinging. And I just talked about the solstice. And I literally recorded what happened to me that day. And now on that day, I left my house in a hurry and saw a blind man. I didn't think he was a blind man. He was just a man with a cane and a dog who was getting attacked by other dogs. And he was swinging his cane around to defend himself. And he scared the dogs away. And then I realized as they drove by, they had these heavy dark glasses on and he was blind. And then my whole day was about that. Later on, I met a guy at the hardware store who was also blind. So just a sample of the way I like to write. Here's just a bit. About mid-afternoon, gloom begins draining the sky. Dark cloud drizzle starts peltering. I find myself standing in the parking lot of the Pukalani hardware store talking with a guy named Bob. Suddenly a woman's voice blasts at us from behind. Excuse me. I don't want to interrupt. She interrupts. I turn. A beefy old Howley gal and a wrinkled Moomoo shuffles toward us in house slippers waving her arms. Her gray hair seems to have exploded on her head. Pinched rimmed glasses teeter as it glued onto the tip of her nose and her plastic necklace includes a medical alert pendant. We can't get home. She cries. My husband and me. We had a taxi. But the taxi driver just drove away and left us. Where do you live? Say Bob and I and Unison. I don't know. She shrieks. We just moved there. I don't remember the name of the street or where it is, but we have to get there before dark. My husband is blind. Where's your husband? I asked. He's still in the hardware store. We need help. So I went in and found this guy who was blind and wasn't wearing glasses and used to sing with Don Ho. And I thought after when I got home I thought well this is kind of an interesting story. We end up together kind of improvising a soft shoe shuffle and singing what's the song? There'll be pennies from heaven for you and me. Anyway and I just thought that's such a local event and tied to a you know celestial time and I don't know. And I got to publish that because no one was telling me it was silly to write about that sort of thing. Wonderful. We have things like that that happen in these islands. And it just depends on how you look at things, right? So thank you for that. Talk about your other book. I read False Confessions. That's one. When that came out I got this award. When that came out I was given the Elliot Cades award. It was a good moment for me. The first book I did with these columns is called Four Wheels Five Corners. I have written other things. I've written everything Elaine. I mean I'm a writer. That's how I feel about it. And I live in Hawaii. That means I'll write all kinds of things for anybody. And I'm really proud of writing press kits for very successful multi-million dollar fundraising campaigns too. And I teach. So I mean people get this glorified sense that writers are somehow on another sphere. I'm just a guy in the community trying to use what skills I have here. But I have written a novel because I just want to say I've written several novels but they're not in print. This COVID situation has really knocked out a lot of my purchase and my places to publish my work on any scale. Do you find your conductive with COVID having happened and being sheltered in place? Well I have. I wrote a novel. I've written two books that are available. I actually have three books available for any publisher who will find me. And I keep sending these things out and they think oh here's a white guy in Hawaii. Take with him. He's not. Anyway never mind. What about your ingenious life of Melbourne Smith? One man's revival of historic sailing vessels. Oh yeah that was a marvelous project. I did an article for Honohoa magazine on a fellow named Woodson Woods who lives in Kamuella on Big Island. And he had a soaring club, these magnificent sail planes. He and his buddies and they would go up, get towed up to the top of Mauna Kea and then soar from that point on. He took me up and we hit it off. He was a sailor and sort of an all around hero kind of fellow. And he had commissioned this man Melbourne Smith to design and build a replica of a War of 1812 vessel. And it's sailing on the east coast now. It's called the links. And Woody said I want to honor Melbourne Smith who is an ingenious antique boat replicator. And so Woody sent me to Florida for 10 days and I hung out with Melbourne and wrote this book and Woody published it and it's on the links. I wish it was more available. Woody has and Melbourne are both gone now. So it was just a magic moment. It's a beautiful book. If anybody wants that, especially as a gift for, I don't mean to be plugging anything. The good gift for anyone who loves boats and I have cartons of them. They just want to get in touch with me. They're not available on Amazon at this time. I think there's one on there that's priced at $1,000 or something. I'm thinking of so many writers that I know that have stacks of their books, you know, because you know for a while there we were doing all kinds of signings and things like that and we had to have them on hand and then COVID just shut it down. Now you have, I want to talk a little bit about your magazines, but you have some new books coming out that I think you should let us know about because they look very interesting. Yeah, I just finished the best thing I've ever written about just six months ago. A novel based on the life of Kalakaua and it is fun to talk about that, but it's called Asking of the World. And then I did, I finished a project about vocabulary. I'm an English teacher, but I wrote a book. Is that a nonfiction on Kalakaua? It is what we call magic realism. It's not an accurate history. It is taking the context of the shift in Hawaii from the beginning of outside contact to what happened in Kalakaua's time. There's more to say about it, but. Okay, all right, so a body of words. Do you want to talk about it? A body of words is a collection that I started a long time ago of taking the words we use for the body, starting with the feet going all the way up to the top of the head and talking about how those words, it's an etymology, a fun etymology piece about the history of words. Can you give us a sample? Oh, sure. Talking about standing and all the words that have to do with standing, they're so essential to our self-concept. But the whole notion of being an animal that stands up while others are four-legged or flying away is the unique scary thing about human beings, and it's our pride, right? So do you understand that that is substantial? And a lot of terms about straightness and correctness come from the fact that we honor our upright stance. That stance came to my mind. Yeah, and so it's just a fun way to teach vocabulary, basically. That's what I'm envisioning. And I'm working on a novel now called Slocum that started as one of my columns. And it's about a Howley guy who lives in contemporary Kihei and gets transported in time back to pre-contact Hawaii in the same spot. And he gets a lesson. And I'm going to get him back to confront his previous reality. Anyway, it's just a fun... Is this a book that you had to do a lot of research on? I mean, Kalakaua would have been, but Slocum one, is this something that you would have had to do a lot of research on? I am doing research on it too. Yeah, right. I don't mean to be a scholar in the sense of academic in this regard, but I have paid attention for quite a long time, my life. And I think I have a pretty good sense of what that would be like without claiming to be someone... I especially don't want to claim to be Hawaiian or know what Hawaiians know about their own culture. And then you have Living with Volcanoes coming up. Is that correct? That's some short... I decided that since COVID is sort of the publisher... Publications have gone dark. I decided I should take my best pieces overall this time. And I isolated 48 or 50 or so, and they're all good. And they showed up in publications that maybe a few people read, and then they're gone. That's not fair. So I thought I'd put them together into a volume. Well, that's interesting because we have a question here in the chat room that says, I remember you well from your column in the Maui News. It's been a while. Would you consider a comeback? This might be the answer to this person's prayers, huh? A comeback. I would like to find a place to keep writing publicly for my community. That's where my heart is. I'd like to make more and be wider known. But sorry, I need to correct. I would never wrote for the Maui News. I've written press releases and seen them get printed with somebody else's name on them, printed verbatim. But my work has been... Say it again? Maybe it was in one of the magazines, like Hanahao or something. Well, I've written a lot in Hanahao. And they've given me some of the best assignments. And my best big pieces have been in there, or Spirit of Aloha when we had Aloha Airlines. All the Eklah Times I did a lot with. And other publications like that. The one that just folded was called On Maui, which was a spin-off from Maui Arts and Cultural Centers. Well, Paul, we're almost out of time. I won't know. Well, first off, I want to put your website up because there's a whole lot of information there. www.PaulWoodWriter.com. Please be sure to visit his website. Are you on any social pages, Facebook, Twitter, or other social media? I'm not doing that stuff. I'm not doing that stuff. Paul, can you tell me what's currently on your bedside table that you're reading? Yeah, let's see. I have a mama's last hug by this Belgian primatologist. What is his name? It slips me. I don't know. But it's a recent bestseller. And his whole premise is that animals have emotions and emotions are part of our intelligence and essential part of our intelligence. And I happen to really believe that and try to teach that too. I've read a couple of novels that are on that subject. In closing, I want to thank you for visiting with me, spending some time with us. I can't thank you enough. I want to thank our underwriters, our technicians, our Jay Fidel, our producer. What can I say? And I want to invite you all back in two weeks with my friend Irita Forsythe. I don't know who her guest is, but I promise you it'll be great fun. And Jay Fidel has a few more new shows coming up that you'll want to stay tuned to the site to find out what they are. I'm very excited for him. I'm very excited for Think Tech. If you can donate, please do. We operate that way. And that's the only way we can keep coming to you. And I want to thank the viewers too. Mahalo and Aloha. Paul, thanks again. Thank you, Elaine. It's been a lot of coffee with you. Okay, we'll do it.


Hello friends, welcome to the session. I am Malka. Let's discuss the given question. Let A with the coordinates 4 to B coordinates 6, 5 and C with the coordinates 1, 4 be the vertices of triangle A, B, C. First path is the medium from A meets B, C at D. Find the coordinates of the point D. Our figure is A, B, C is the triangle and A, D is the medium on B, C. Now let's discuss the first path. Since we are given that the medium from A meets B, C at D. So we have to find the coordinates of the point D and D is the midpoint of B, C. Therefore, we will apply the midpoint formula. That is midpoint formula is given by x1 plus x2 upon 2 and y1 plus y2 upon 2. So this will give the coordinates of the midpoint. That is the point D. So coordinates of DR 6 plus 1 by 2 and 5 plus 4 by 2. So coordinates of DR 7 by 2 and 9 by 2. So this is the solution of the first path. Now let's see the next path. Our next path is find the coordinates of point P on A, D. There is a point P on A, D such that A, P is to PD equal to 2 is to 1. Now let's begin with the solution of the path second. P is the point on A, D such that A, P is to PD equal to 2 is to 1. Now we have to find the coordinates of the point P and we are given the coordinates of the point A and D. So we will use the section formula to find the coordinates of the point P and we know that section formula m1 x2 plus m2 x1 upon m1 plus m2 m1 by 2 plus m2 y1 upon m1 plus m2. So these are the coordinates of any point which divide the line segment in the ratio of m1 is to m2. Therefore coordinates of P will be into 7 by 2 plus 1 into 4 upon 2 plus 1 into 9 by 2 plus 1 into 2 upon 2 plus 1. So these are the coordinates of the point P. On further simplifying them we get 11 upon 3 and 11 upon 3 as the coordinates of the point P. So hope you understood the solution of the second path. Our third path is find the coordinates of points Q and R on mediums VE and CF respectively such that VE VQ is to QE equal to 2 is to 1 and CR is to RF equal to 2 is to 1. Now let's begin with the solution of the path third. Here we have to find the coordinates of point E and F. So coordinates of will be, here we will use the midpoint formula that is x1 plus x2 upon 2. So it will be 4 plus 1 upon 2 and y1 plus y2 upon 2 that is 2 plus 4 upon 2. So this will give us 5, 5 by 2 and 6 by 2 or we can say 5 by 2 and 3. These are the coordinates of the point E. Now we find the coordinates of point Q and we have given that VQ is to QE equal to 2 is to 1. So coordinates Q will be, now here again we will use the action formula. So that is 2 into 5 by 2 plus 1 into 6 upon 2 plus 1 and the y coordinate will be 2 into 3 plus 1 into 5 upon 2 plus 1. So these are the coordinates of the point Q which on further simplification will be 11 upon 3 and 11 upon 3. So these are the coordinates of the point Q. Now we have to find the coordinates of the point R. So for this we first find the coordinates of the point F. Therefore coordinates of will be, it will be given by the midpoint formula. So 6 plus 4 by 2 and 5 plus 2 by 2 will give us the coordinates of the point F or it can be written as 5 and 7 by 2. These are the coordinates of the point F. Now we find the coordinates of the point R and we have also given that C R is to RF equal to 2 is to 1. Therefore coordinates of will be 2 into 5 plus 1 into 1 upon 2 plus 1 into 7 by 2 plus 1 into 4 upon 2 plus 1. So these are the coordinates of the point R. Which on further simplification will be 11 upon 3 and 11 upon 3. So these are the coordinates of the point R. Hope you understood the solution of the third part. Now let's discuss the fourth part. Our fourth part is what do you observe? As we have seen that the coordinates of the point P, Q and R are same. So this implies that P, Q and R is same point. So we observe that coordinates of P, Q same. So therefore this implies that Q point, the centroid divides the median in the ratio 2 is to 1. Centroid divides the median in the ratio 2 is to 1. So this is the observation we had from our figure. Now let's discuss the next part. Our fifth part is F A with the coordinates x1, y1, b, coordinates x2, y2 and c with coordinates y3. Our vertices of triangle A, B, C find the coordinates of the centroid of the triangle. Let's begin with the solution of the part fifth. A, B, C is the triangle with coordinates of A as x1, y1, b, x2, y2, c, x3, y3, ad, be and cf are the medians and the common point of intersection of the medians is the point P which is the centroid and we have to find the coordinates of centroid. So to find the coordinates of the point P, we first have to find the coordinates of the point D and we know that the centroid divides the median in the ratio 2 is to 1. So let's find the coordinates of the point D, coordinates, we find the coordinates of D by the midpoint formula. So that is, we can see from the figure x2 plus x3 by 2 and y2 plus y3 by 2. So these are the coordinates of the point D. Now we have to find the coordinates of the point P and we know that if P is the centroid then the ratio of AP is to PD equal to 2 is to 1. So we can write AP is to PD equal to 2 is to 1. Now we will find the coordinates of, therefore the coordinates of P are, we will find the coordinates of P by the section formula that is 1 into x1 plus 2 into x2 plus x3 by 2 upon 1 plus 2 and the y coordinate is given by 1 into y1 plus 2 into y2 plus y3 by 2 upon 1 plus 2. So on for the simplification it can be written as x1 plus x2 plus x3 by 3 and y1 plus y2 plus y3 by 3. So these are the coordinates of the point P that is the centroid. Therefore coordinates of centroid P x1 plus x2 plus x3 by 3 and y1 plus y2 plus y3 by 3. So hope you understood this part. Answer to the different parts of the question are D coordinates of D are 7 by 2 and 9 by 2, coordinates of the point P are 11 by 3, 11 by 3, coordinates of the point Q and R are 11 by 3, 11 by 3 and the basic observation is that P, Q and R are the same points and the coordinates of the centroid at this point P are given by x1 plus x2 plus x3 by 3, y1 plus y2 plus y3 by 3. So these are the coordinates of the centroid. So hope you understood the solution of all the parts and enjoyed the session. Goodbye and take care.


All right, let's see what everyone's doing. Is Jersey sleeping? These things work better than an actual ball. They like, yeah, it's lighter for them. It's more fun for them to throw, not all birds, but some. I find with my birds, they're like a rolled up tissue. This is the kind of engagement you wanna have with your parents. They're extremely intelligent. They get bored easily. This is the engagement part of Engage Not Gage. You wanna stimulate their brain, and make them find things. Especially with cockatoos, you wanna make them put two things together. They like to undo things. She wants to figure out something to do with them, which is why they're so smart. So look, she's looking at me like, what? There's a straw here. But also, but also I have this for you to try to put together. So with Jersey, she's a little bit smarter than just the straw. She needs a lot more to be stimulating, and so she wants the straw and something else. Jersey will actually thread things, okay? If you give her something with a hole in it and a piece of fabric, she'll put it through and through and through. Jersey needs that kind of excitement. She's looking at you like you're cruising. She wants you to play. She thinks you wanna hide from her. Just duck, just duck under the counter. That's all she wants. Yeah! Tell me it's not the cutest face in the world. To play ball. Now Aura could play ball with you because then Aura won't have to run. Now Aura, how exhausting is it maintaining a toddler? I should call them toddlers. Can I keep it? Can I take it away? Here, I gotta put it here and see. He's telling you to put him down. He doesn't know how to jump down here. Look, Mom, look. He's gonna talk, watch. Yeah. He's gonna talk. I'm gonna sing in there and it's checking it all out. Mom didn't believe me. I'm like, she's like, I don't understand how you know he's gonna want this thing. I'm like, believe me. And thank you to Sasha over at Petco for building it for me. Rocky, we want you to sing. He's checking the dimensions. He's like, I'll contract this part out. Stretch this kitchen out over here. Yeah. Oh, that means sing. Me? Yeah, do la, la, la. That's not gonna make him. Just do it, he likes it. La, la, la, la. See? He didn't do anything. La, la, la, la, la, la, la, la, la, la. I can't sing. Yeah, do it again. See? He didn't react like that to mine. I'm sorry. He didn't react like that to mine. I can't, Megan. Oh, oh, oh. Megan? Again. Mom. Like my thing. Just do it, Megan. It's for the bird. Yeah, I can't sing. It's brilliant. It's not brilliant. It's not. It absolutely is. Show me you're singing and I'll show you mine. I should do that old woman's voice so he doesn't. Oh. Because I mess it up. Yup. Vinnie, what are you doing? Checking out. Vinnie, let's do beats together. You want more? Okay. Okay, I'll do more. You want a different song? Different beats? Yeah. See how he changes it and matches me. He's so smart. Do you like the box? Hopefully I'll make it more interesting than that box. Okay? Vinnie. Shh. You wanna catch the box? We dive bombed. Go touch that package over there. By the way, don't forget if you guys are looking for an amazing bird food brand for your bird that is healthy, organic and not full of food colorings and sugar and peanut smash, check out Marlene's signature blend. I did this along with Top's parrot food. We've just launched in the UK. Northern Parrots now sells our food. You guys have been asking for it. You got it. Also, Things for Wings in Canada sells our bird food right now. I'm proud to announce and they will ship it to you. I encourage you guys to check out my Feathered Fun Box. It's a passion project. It's a subscription box that comes with parrot toys for your bird and also special merch. Kind of like my dream box. Honestly, I put so much into it. I love that there's something like this for birds out in the world. That's why I created it, www.featheredfunbox.com. I love you guys so, so much. Thank you for listening.


As part of effort to improve the nation's security system, the Nigerian armed forces have reiterated the readiness to use acquired knowledge, skills, and professionalism to surmount in security challenges that confront the country. The chief of Amistad, Lt. Gen. Azubuike Yeji Reka, retired, said this after a graduation lecture. Our senior course 45 tried to maximize in command and start training for a fulfilling career in the Armed Forces of Nigeria. At the Armed Forces Command and Staff College in Jaji, Kaduna, State Northwest, Nigeria, he extensively emphasized on the training and retraining of military officers, which is key, noting the two variables every successful military officer must invite. They missed a command to battalions and their equivalents in their other services. So the expectation from them is high. And one message is they should not rest on their hours. They should now apply the knowledge they have learned in mentoring their subordinates and in discharging their functions efficiently. Also a commandant of the armed forces command at Staff College, Vice Marshal Hassan, a large art student of class 45, to uphold professionalism and patriotism in carrying out the duties as commandant officers stressing the national interest should prioritise above their individual desire in defending the country's territory. So you must be very close to the armed forces of the Federal Republic of Nigeria. Our job is to make sure that you are here today. You are here for Nigeria and you must do much for Nigeria. They are not very smart. The other thing is, you are here to be commandant in more than 100 percent. Officer to protect the world in many ways. Officer to focus on their work, officer to focus on their country. It is all armed country. That's why you are here, that's why you are very listenable. And that's what you are going to do. You are now in the service of the armed forces commandant at Staff College. Don't forget to hit the notification button so you get notified about fresh news updates.


The foundations of the digital revolution were all sponsored and funded by the United States Department of Defense. The context was the Cold War, which legitimized the design and implementation of perhaps the most significant industrial policy since medieval mercantilism. The history of ICT is a prime example of the economic power, not just the scientific and technological value of mission-driven R&T. So we start from where we were in lecture four. We must step outside of the framework of neoclassical economics to grasp the dynamics of the ICT revolution. DOD, the Defense Department, orchestrated the coordination that the market could not provide. We must step outside the framework of national income accounting to appreciate the value generated by mission-driven research and development. Now by definition of the national income accounts, the public sector output equals the input. No productivity gain is possible by construction. Plus federal financing of ICT as a public good had enormous implications for intellectual property and accelerated the diffusion of new knowledge. Contrast this open innovation environment with Watt and Bolton's holdup of the steam power general purpose technology. And note the importance of the procurement function and perhaps most important, the institutional innovation embodied in the belated establishment of American research universities. Now some specifics. First, digital computers. The military supported multiple projects, not a single national champion. The history of the first general purpose programmable computer, ENIAC at University of Pennsylvania, is exemplary. It was designed to calculate artillery firing tables for the Army and then repurposed to explore the feasibility of building a hydrogen bomb. John von Neumann was a universal genius based at the Institute for Advanced Study in Princeton. His notes were compiled from sessions at Penn exploring the possibility of a next generation computer with the ability to store and execute its own programs. The EDVAC. John Mawkley and Prosper Erkert, the designers of ENIAC, bitterly resented the transfer of their IP to the public domain. They were finally awarded a patent that in turn was voided because of the existence of prior art, art that was arguably their own. But letting out the model for a programmable digital computer broadly across the domain of interest radically accelerated the development of computing. Second, semiconductors. Now here note the disparity. The established firms, the Giants, AT&T and IBM, got most of the R&D contracts. But the procurement contracts went to the new firms like Fairchild Semiconductor. And then on to the birth of software, SAGE, the semi-automatic ground environment to manage the network of radar stations established to track a potential Soviet attack. It was obsolete by the time it was completed. And missiles succeeded bombers, which were all that those radars could track. But software as an independent craft was born. Finally, upstream investment in creating the enabling discipline, computer science. The same sort of federal support was also devoted to solid state physics, the basis for semiconductor processing. The digital revolution was also accelerated by a different kind of state intervention. Antitrust, again reducing the ability of the investors in R&D to control, appropriate, and limit access to intellectual property. The positive consequences were enormous. The antitrust interventions opened up the IT sector to competitive entry by new companies. From 1980 to 1983, the nascent information technology sector went through profound structural change. Recall the McNamara depression of the early 1960s that forced micro-electronic firms to seek commercial markets. By contrast, in the early 1980s, commercial markets, above all the new market for personal computers, pulled IT firms away from the military market. Millspec, designing products to meet the military specifications, became a niche, a narrow niche characterized by extreme performance requirements. Eventually, the military migrated to COPS, commercial off-the-shelf hardware and software, as the commercial market defined the priorities for all participants in the industry. The broadly defined computer industry has evolved through a succession of platforms. IBM System 360 was the dominant computing platform for what turned out to be a short generation. But the PC platform was delivered by the wind-tell duopoly of Microsoft and its software and Intel and its computer chips, not by a single computer manufacturer. Today, there is a standard platform, open-source software, the Apache Stack, riding on the cloud computing services from Amazon, secondarily Microsoft, and with Google struggling to catch up. A platform that is incredibly open and incredibly cheap. The result is the flood of software-defined, web-delivered services, indeed a Darwinian explosion of innovative applications. The first critical architectural transformation occurred in the 80s, the shift from a vertical, closed and proprietary industry to a horizontal industry, open network through published interfaces and protocols. Now this treats the Internet only as a communication medium, but of course it is much, much more as we shall see. Now the location of the Internet initially, within the public sector, contradicted the principles of market fundamentalists and constrained any commercial evolution of the network technology. The critical role of the National Science Foundation, however, a public lead user of the Internet, led the transition from the Defense Department to a privatized medium for commerce as well as for information. The open character of the public sector Internet carried over into the private sector, at least it has until now when net neutrality seems to be under threat. But a set of critical technical choices were made in the early days on which openness depended, especially what's known as TCPIP, Transmission Control Protocol, Internet Protocol, chosen in the face of proprietary offerings, especially from IBM, that would have closed the Internet and led to control of access from the beginning. Then the gift to the world from Sir Tim Berners-Lee of CERN, the World Wide Web. Shane Greenstein identifies the distinctive organizational characteristics of the Internet with respect both to governance and technological direction. It's the integration of communications with transactions, plus the application of real-time analytics to communicative and transactional behavior that distinguishes the Internet as a unique environment and enables the proliferation of the seemingly limitless range of applications. Early perception of these factors was catalyzed by Netscape's IPO with the first commercial web browser in 1995. The outlines of a new economy began to become visible and the basis for a bubble emerged. Today, the digital revolution has grown up. It's no longer dependent upon state sponsorship and support and in fact, the digital revolution has evolved to attack the authority of the state at the micro level, enabling assaults on the regulatory ecosystems of established markets and at the macro level, enabling a new wave of automation, globalization and financialization that challenge the state's ability to buffer its constituents from disruptive change and at the most fundamental level, the digital revolution has been undermining the integrity of the political process on which the authority of the state ultimately rests. Digitalization of physical activities transforms atoms into bits. Digitalization eliminates technological frictions, but other frictions remain. All of these real-world frictions can slow down the diffusion of innovation and the growth of the disruptors. They may even call into question the long-term sustainability of the digital disruptors. Recall discussion of the unicorn bubble in lecture three and note that a characteristic flaw in the world view of those who know they are inventing a new world is not to pay attention or to understand how this world came into existence and how it works until it bites them in the ass. During the 1990s, value in computing shifted from hardware to software. Hardware was commoditized and software became the vehicle for creating and capturing value. Now it's shifting from software to data as software in turn is commoditized to availability of open source system software and are bundled into cloud services. The feedback from more data to better algorithms in principle is complex. In some domains, such as identifying a unique individual, there appears to be diminishing marginal productivity from incremental data. Relatively few data points give you what you need to know whether or not you should know it. In other domains, such as natural language processing, there may be no such constraint or we certainly haven't come close to reaching it yet. But the first effect of more data in general is a lower signal to noise ratio. That is, the number of potentially false correlations rises exponentially with the amount of data and the challenge of identifying genuinely causal relationships becomes both harder and more urgent. This is why the promise of machine learning is at best somewhat problematic and at worst offers a veneer of objectivity to data that embeds prejudice. But even as the digital revolution pervades economic and social and political life, productivity growth has slowed markedly across the developed world, generating an intense academic and policy debate. There are multiple candidate sources for mis-measurement of productivity, including missing output due to economic activities crossing the production boundary. That is, work that used to be paid for and captured in the national income accounts become self-service. Second, final goods become intermediate services that drop out of GDP. For example, rental of cloud computing services substitutes for the purchase as final goods of computers themselves. Overstated inflation as a third factor, cost-reducing innovations come too fast for correction. But mis-measurement on its own appears insufficient. And in fact, average productivity growth itself can be very misleading. The OECD has tracked the best versus the rest across both manufacturing and services sectors. Productivity growth for the top 5% has continued on trend as with the diffusion of all technologies. It takes time to master the new. The same pattern shows an analysis of some 30,000 UK firms. Look at the enormous gap between the 99th and the 90th percentile of productivity growth. Multiple studies show that the productivity puzzle is bound up with several related observables. Increased industrial concentration, rise in market power, decline in labor's share. This paper by a brilliant young graduate student at Cambridge University examines the impact of the increase in intangible capital that is not stuff you can kick but intellectual property services, IT algorithms due to the adoption and exploitation of digital technologies. Intangible capital reduces marginal costs and increases fixed costs. It confers competitive advantage on the first movers whose lower costs in turn chill competition from potential new entrants and cut aggregate productivity growth in the longer term. So this is a story about how digitalization has increased market power and reduced productivity growth. Thomas Philippon's important new book, The Great Reversal, examines in detail the sources and consequences of slower growth of productivity and increased concentration in US industries and markets accompanied by increased share of revenues going to profits and lower share going to wages. Philippon in his book sorts through a range of alternative explanations to find that two hypotheses, the rise of superstar firms and decreasing domestic competition are consistent with the pattern of increased concentration and increased profit margins. But the pattern of investment and productivity growth reject the superstar hypothesis as dominant. And a recent paper by Axeget and Ateves takes the argument one step further, reduced dynamism expressing itself in slow productivity growth and in other observable ways once again reflects the perverse consequences of an excessively tight intellectual property regime with patents concentrated amongst a relatively small set of incumbent market leaders. Even while the productivity puzzle has unfolded in the statistical economy, numerous studies from different sources protect increased impact on the labor market from increasingly intelligent automation. Like previous technological revolutions, the digital revolution has transformed both the content of work and the management of work. So did the introduction of the factory system in the first industrial revolution. So did the introduction of the production line in the second industrial revolution. Indeed, the digital revolution may have more disruptive impact through the algorithmic management of work versus changes in the content of work. The rise of the gig economy is generating endogenous labor market and political responses from guilds of Uber drivers and the political response has actually reached a segment of Republican-aligned conservatives. This is a statement, very recent statement from a Republican think tank arguing that workers need to have a seat at the table. When we turn to the macro consequences of the digital revolution, they transcend national borders. They have transformed the global economy and spilled over to disrupt the political process across the developed world. The first globalization peaked at the start of World War I. It too was enabled by new technologies, steamships, railways, the telegraph and telephone networks. It involved free movement of people and capital, trading goods with limited by protectionism in the top follower nations, the United States and Germany and gross trade peaked at about 30% of world GDP. The second globalization, our globalization was enabled by IT. It involved free movement of goods and services and capital. Movement of people was clearly not so free but IT enabled the movement of work internationally also known as outsourcing. Gross trade peaked at no less than 60% of world GDP. The pursuit of efficiency in the construction and management of global supply chains directly and necessarily reduced their robustness as we have learned under the impact of the coronavirus pandemic. IT driven globalization in the real economy eliminated buffer stocks and redundancy and left the production system of the world dangerously fragile. Now, financialization is the third dimension of the digital revolution's transformation of economic life. This chart shows the sheer scale of the financialization of the US economy. From 1950 to 1980, the value of financial assets relative to GDP rose only from 1.3 to 1.8 times. As a compound annual growth rate, you could barely see it. But from 1980 to 2007, the ratio of financial assets to GDP rose from 1.8 times to 4.8 times. As discussed in lecture five, the great credit super bubble that burst in 2008 could not possibly have emerged without IT, expressing cataclysmically in the huge and unsustainable increase in leverage. For each individual bank, more leverage increases its capital efficiency. Each dollar of capital supports more loans and other assets and generates more income in absolute terms and in higher returns on capital. Oh, yes, it also generates higher bonuses. For the system, increasing leverage reduces the robustness of the system just as with physical supply chains. Immediately prior to the global financial crisis, the banking system was so leveraged that a mere 3% decline in asset values would have rendered it insolvent and did so. Again, efficiency and robustness are at war with each other. And of course, globalization and financialization interacted. The key measure in this chart is the volume of cross-border claims of banks on other banks. The thicker the link between regions, the greater the volume of loans. Between 2002 and 2007, just five years, US claims on Europe rose from half a trillion dollars to more than one and a half trillion dollars, a factor of three. And Europe's claims on the US rose from one trillion to two and a half trillion. As with the global supply chains in the real economy today, a decade ago, the global financial networks enabled by IT proved shockingly fragile. Globalization of the world's financial economy has generated the political dilemma defined by Danny Rodrick of the Harvard Kennedy School. You can have deep economic integration. You can function as an autonomous nation state. And you can have representative, responsive government, two out of three. The Eurozone has been a prime stage for the acting out of that trilemma. Responses to the political stresses generated by the trilemma express themselves both domestically in the rise of polarized populism and internationally in the rise of barriers to trade and to migration. At the most fundamental level, the digital revolution is undermining the integrity of the political process on which the authority of the state rests. And so in one generation, the relationship between the state and the digital revolution has been reversed. And so the IT revolution sponsored by the state and funded by speculation feeds back not only to transform the market economy, it also conditions the political dynamics that shape the capacity of the state to offset and balance the coordination failures and self-destructive outcomes of markets disrupted by those same digital technologies as their participants operate under conditions of radical uncertainty. The retreat from hyper-globalization was already well underway before the impact of the coronavirus pandemic. Managing that process through and beyond the pandemic will continue to test to the utmost the competence and authority of states around the world even as they are urgently called upon to address the next needed technological revolution, the green revolution in response to climate change, the subject of the final lecture in this series.


Equalize is a quick, effective way to report suspicious activity, surveillance, elicitation, testing security. They will analyze security practices and procedures. You may even see someone acquiring supplies that could be used in an attack. It may be someone who just doesn't seem like they belong. The Equalize website allows you to log on if you see something suspicious. You enter your information and what you observed. It is our shared responsibility to keep our community safe. If you see something suspicious, report it at usmcegalize.org. Stay alert, stay alive, watch, report, protect.