Minimalism matters
Prins, Pjotr
Minimalism matters in computing. To trust systems we need to be able to understand them completely. Openssl heartbleed disaster was caused by code no longer being minimalistic, even if it is free and open source software. Hardware manfucturers and proprietary closed source solutions make things even worse with expectations of intrusion to privacy and backdoors if we don't aim for free hardware, software and minimalism. In this talk I will discuss minimalism in a broad context and narrow down on what the free software community can aim for.
 I have a loud voice. Welcome everyone. We organized the minimalism death room and there have been some very interesting talks. I'm going to take a slightly more generic approach and discuss why we set up the room and why minimalism matters in our opinion. So the crux of the matter is that to really trust systems we need to understand them. And these days even the Debian bootstrap is 350 megabytes of binary blob. Did you know that? And it includes the GCC compiler and a host of other tools. So how do we really know what's in there is secure? Also typically these days we are downloading one gigabyte Docker images. And if you try to do a post mortem on them it's very hard to find out what's actually in there, right? I mean you can find what is in there but how was it built? How was it created? How are you sure that there's nothing untrustworthy in there? So are we driving on luck alone? Are we getting away with murder? I think the answer is yes. So what is minimalism really about? It's about things being simple, being transparent, you know, where the dependencies are really clear. We have clear APIs, you have well-defined behavior and especially, you know, the stuff should be easy to understand and read. How much of our software today actually matches these criteria? None, as far as I know. Well, maybe some scheme programs. So it should also not be bigger than necessary. Yeah, minimalism. Yes, so... So the hardly disaster you've probably all heard about and maybe looked into because it's hurt almost everyone. You know, Cisco system by identified 78 of its products as vulnerable, including IP phone system, telepresence, video conferencing systems. It costs millions of dollars, which I guess is an understatement. And the truth of the matter is it's an open source project and at the time there were only two people working there on it and it has half a million lines of code, right? And what actually happened with HardBleed is there was some code left in there which was not supposed to do anything, right? I mean it maybe was supposed to do something but it was really just left in there and nobody looked at it again and it was the problem. So how many lines of source code do you think there's in the Linux kernel and drivers today? All too low. How much is in Windows? Even more. OSX, Android, Android, 20 million. Mozilla. Facebook, you know, their code that they use. The answers. So this is the Linux kernel, you know, it's grown a little bit over time. So it's now close to 30 million lines, I guess. Oops, sorry. 25 million lines of code including drivers. You can see how it's grown since really small print. I can't really see it anymore but just in a few years, you know, it's come from 5 million. Browsers. Yeah, so 36, well, almost 37 million lines of code in Firefox. That is more than Linux. Seriously. You know, and I mean, at the time, remember when Microsoft was really worried that the browser would become the desktop? We've done it. And it's C++2, right? Scary. So, Windows, they're 50 million. OSX, that's not officially known. Android, sorry, it's only 12 million. Android is only 12 million. And then Facebook apparently has 60 million lines of code to run, you know, everything. How many transistors do we have in the CPU today? Billions. Billions. It's scary. Yeah, so the original 83, 86, which I used the program and I also did the Trash 80, by the way. Yeah, so it had under 300,000 transistors. You know, then it went in 2007 to 400 million. Then in 2014, we surpassed the billion mark. And today we are at, you know, sort of close to 20 billion transistors. Arm, is it simpler? That's what you'd hope, right? Finally, we get a new architecture. It's going to be a lot simpler, right? Eight and a half billion. So it's less than the AMD. But yeah, I think actually for what it offers, it's more. Let's discuss the Intel management engine for a bit. You are aware that every CPU produced since 2008 contains a full operating system. Right on the chip. Yeah, it's Minix. Minix? Any Linux users here today? Minix, right. So and it has, they found weaknesses in it, right? In 2017. And that, you know, this is an exploit that goes back all the way to 2008. And, you know, a normal user cannot disable the management engine. This is actually the last line of computers you could actually, you could disable it. It's a 2011 one. It's not strange I'm using it. You can read about it on Wikipedia. So Intel claims it's a good thing. They have the management engine. You know, they give, you know, X service to corporate customers. They can actually get network access on the CPU. But we don't really know what it does. Right? So I mean, I plugged this from the internet. Oh, sorry. It can read anybody in RAM. It can send data to the network interface. Communicate with the operating system. You know, I mean, it could be abused, right? Could it be? We trust Intel. We all do. And Tanenbaum, I mean Intel, you know, fired a host of questions to Tanenbaum at the time they were introducing Minix on the chip, right? And he didn't know what it was about. So for the record, he says, you know, you know, if I suspected they might be building a spy engine, I certainly wouldn't have cooperated. AMD, any better? No. No. They actually have a management engine and we know nothing about it. Yeah. You can check this right up by someone. So Minix itself is minimalistic. It's about 4,000 lines of code they claim for the kernel itself. It's a microkernel. And they think that they within these 4,000 lines, they can eventually make it bug free. They're not stating it's bug free now. But small helps with minimalism, right? And that's also why probably Intel put it on their chip. It's ironic. So when it comes to minimalism, you know, we really are talking about simple components and composability. You know, how do these components fit together? And the Unix philosophy, the original one, I'm not talking about system D here, they have this. It's served as well, right? So we have Janneke here who is working on GNU-Mess, which is replacing that 350 megabyte binary blob. And he wants to reduce it, the team wants to reduce it to 500 bytes of binary blob. Well, that would be an improvement, no? And it will affect all Linux distributions. So this is also about components and composable and also about readable. What is this 300 binary blob? It's got a GCC compiler in there, Ben Utils. Janne? Ah, so it's a distribution. Yeah, it's a small distribution itself. It's used to, because to compile Debian, you need to compile something, right? Yeah. But this is what Debian does, and the others are no better. The HURT, another group, the GNU projects are co-occurred, they have 400,000 lines of code, so it's not minimal, but it's a micro-curtle. And it aims to surpass the Unix kernel functionality, security and stability. So what it means, security, you know, it has to be more composable and more, sorry, more components, component mentalized, what is the word, and composable, right? So while the GNU HURT doesn't, it's not a very active project today, you can see that in time it could become important. GNU Geeks, anyone heard of GNU Geeks here today? Yeah, so this is another attempt at, you know, making things in smaller components and making them composable. I'll say a bit more about that if I have time. Sorry. So is this minimalistic? So this is a, you know, a billion transistor chip, and it looks like, you know, they're components, and that it's, you know, it certainly probably is composable, but no one, you know, today can understand what's really there. It's all done by machines. But also, you know, it is actually pretty complex. I mean, if you look at the street map of Brussels, yeah, it also looks like it's components, you know, their house is there, and, you know, there's an API, they're functioning together. But what's really happening at that level, we have no concept of understanding anymore, right? I mean, we never had, never really had when we left villages, small villages. So modern CPUs actually look like city maps today, you know, many, many components. They look composable, but they're actually complex, and we rely on that technology throughout, right? That's why that's who a stuff is such a concern. This is a graph, and the graph is a dependency tree from GNU Geeks. So this shows Python with its dependencies. Sorry about this small size. I probably have it open somewhere. Yeah, there you go. Yeah, so if you zoom in a little bit, you can see how it all hangs together, okay? So this is your typical stuff that you run on your computer. Switch. Are they components? These individual pieces of software? You know, well, this is a graph, and it looks like it's components, components. These are not components, really. You know, these are components of software, but how they really interact with each other, we don't know, right? We only can show how they depend on each other. So what we are running on our systems is not really component, it doesn't consist, I mean, it consists of components, but they're not understandable components. So one thing you can improve things to make it more minimalist is say, okay, when I need something to run, I only want, I may create a container or a computer which only has a software on it that I actually need to run it, right? So basically you take the graph and you reduce it. If you take a typical Debian distribution, it will, there will be a lot of install pieces of software and you may never even run, right? But to make it more minimalistic, what you could do with GNU Geeks and the Louser because it controls the dependency graph is to say, okay, I'm going to create a container and I'm only going to put the software on it that I need to run my service, right? And this makes, GNU Geeks makes it reproducible but also minimizes the attack surface, you know, and in a way for embedded systems, it could be redefining the future. So the message really is that things should be simple, transparent, there should be clear dependencies, clear APIs, well-defined behavior, easy to read, you know, we should aim for that in an ideal world. So why do we want minimalism? To avoid dependency hell, I guess, back doors, spying, malicious intent, in a nutshell. Questions? Why do you think software seems to evolve towards the more complex? It sounds like simpler could be simple to make. Yeah, but complexity sounds better. There are many reasons, I think, you know, but before, because we can, it's one word. Because we can, I mean, if you think about, you know, language like Go with all the dependencies and the modules that they pull in, you know, typically hundreds or, you know, JavaScript is also a famous one. Joe Armstrong who created Erlang, you know, he claims that he always avoided dependencies, you know, so for the Erlang compiler and environment, he says, you know, that's the reason why it's still running today or most of the systems are still running today. But there's something to be said for that. Yeah, how much time do I have? Maybe the next week? Yeah. Can I add something to your question? It's also from our education. I'm from the city in Prague and I guess I said that no one teaches students about the problems of complexity, how to do complexity. There's no system at all. And I saw it all myself that I learned this from practice in an open source, but most of the colleagues never learned it. They worked in some corporates and they built all the staff, all the complex staff and don't understand what the problem is. So this is each part of the problem. Yes. Yes, sir. Who have you covered on this course from Emily who is simple, clean and wrong? I'm no philosopher. Yeah. For every simple thing or solution? For every simple problem, there is a solution that is simple, clean and wrong. Yeah, simple, clean and wrong. Yes. It's really a complex topic. I think the point is that simplicity by the way, I said does not guarantee that it's correct. Yeah. So how do you prove that something is correct? Yeah. That's a whole area of research, an active area of research in fact. Yes. Are you ready, Shama? Is it working? Yes, sir. Okay. Jelle? So what do we do? Well, we should aim for simpler hardware and simpler software. Yeah, and with software we can already do a lot. Hardware is going to be a different story for the time being. But I think if open and free hardware platforms come along that are affordable and almost are fast enough to beat my 11-year-old computer, we'll take them. I'll take free hardware. Yeah. So, I'm actually using minimalism as a shift alternative to proper design. Like, the one way to do proper design is to do the minimum design, but it's not necessarily a good solution. So. There are trade-offs, you know. Yeah. So minimalism, there are trade-offs for sure. And companies will, you know, the Microsoft will not opt for minimalism. Normal Google. Yeah, but I think for ourselves, we need to drive for it hard. And when a phone comes along, you know, which is free hardware and it has, you know, a relatively simple operating system and free software, some people will opt for it, you know, and get more privacy out of it. Yeah. I wonder if you have how you measure complexity kind of empirically. I mean, it's easy to say, okay, a million miles of code must be complex. But if they're all doing something like, how do you measure, is there some property of the dependency graph you can measure? How do you measure complexity? How do you measure complexity? Hmm, it's a difficult one, again. And it also depends on what you are trying to create, right? So, you know, we are dealing with complexity in many ways and it's an active area of research also. Yeah, I think with computing, we are going, you know, a little bit off the rails lately. Yes, Mark? Isn't it like a bit like evolution? I mean, if you look at the software which survives at the fittest and it compares to organisms, they all have DNA which junk all over the place and the software is the same basically. Yeah. So, yeah, actually nature is highly efficient. It gets rid of junk. It takes a long time. It takes a long time, yeah. So, I think we also have a very nice tool in popular science which is layers of abstraction. In other words, when I look at these screen points with dark characters on it, I don't think there are pixels that someone had to think about drawing the pixels. I don't have to think about this here. I think a little bit. Come on.
 I have a loud voice. Welcome everyone. We organized the minimalism death room and there  have been some very interesting talks. I'm going to take a slightly more generic approach  and discuss why we set up the room and why minimalism matters in our opinion. So the  crux of the matter is that to really trust systems we need to understand them. And these  days even the Debian bootstrap is 350 megabytes of binary blob. Did you know that? And it  includes the GCC compiler and a host of other tools. So how do we really know what's in  there is secure? Also typically these days we are downloading one gigabyte Docker images.  And if you try to do a post mortem on them it's very hard to find out what's actually  in there, right? I mean you can find what is in there but how was it built? How was it  created? How are you sure that there's nothing untrustworthy in there? So are we driving on  luck alone? Are we getting away with murder? I think the answer is yes. So what is minimalism  really about? It's about things being simple, being transparent, you know, where the dependencies  are really clear. We have clear APIs, you have well-defined behavior and especially, you  know, the stuff should be easy to understand and read. How much of our software today actually  matches these criteria? None, as far as I know. Well, maybe some scheme programs. So  it should also not be bigger than necessary. Yeah, minimalism. Yes, so...  So the hardly disaster you've probably all heard about and maybe looked into because  it's hurt almost everyone. You know, Cisco system by identified 78 of its products as  vulnerable, including IP phone system, telepresence, video conferencing systems. It costs millions  of dollars, which I guess is an understatement. And the truth of the matter is it's an open  source project and at the time there were only two people working there on it and it  has half a million lines of code, right? And what actually happened with HardBleed is there  was some code left in there which was not supposed to do anything, right? I mean it  maybe was supposed to do something but it was really just left in there and nobody looked  at it again and it was the problem. So how many lines of source code do you think there's  in the Linux kernel and drivers today? All too low. How much is in Windows? Even more.  OSX, Android, Android, 20 million. Mozilla. Facebook, you know, their code that they use.  The answers. So this is the Linux kernel, you know, it's grown a little bit over time.  So it's now close to 30 million lines, I guess. Oops, sorry. 25 million lines of code including  drivers. You can see how it's grown since really small print. I can't really see it  anymore but just in a few years, you know, it's come from 5 million. Browsers. Yeah, so  36, well, almost 37 million lines of code in Firefox. That is more than Linux. Seriously.  You know, and I mean, at the time, remember when Microsoft was really worried that the  browser would become the desktop? We've done it. And it's C++2, right? Scary.  So, Windows, they're 50 million. OSX, that's not officially known. Android, sorry, it's  only 12 million. Android is only 12 million. And then Facebook apparently has 60 million  lines of code to run, you know, everything. How many transistors do we have in the CPU  today? Billions. Billions. It's scary. Yeah, so the original 83, 86, which I used the program  and I also did the Trash 80, by the way. Yeah, so it had under 300,000 transistors. You know,  then it went in 2007 to 400 million. Then in 2014, we surpassed the billion mark. And  today we are at, you know, sort of close to 20 billion transistors. Arm, is it simpler?  That's what you'd hope, right? Finally, we get a new architecture. It's going to be a  lot simpler, right? Eight and a half billion. So it's less than the AMD. But yeah, I think  actually for what it offers, it's more. Let's discuss the Intel management engine for a  bit. You are aware that every CPU produced since 2008 contains a full operating system.  Right on the chip. Yeah, it's Minix. Minix? Any Linux users here today? Minix, right.  So and it has, they found weaknesses in it, right? In 2017. And that, you know, this is  an exploit that goes back all the way to 2008. And, you know, a normal user cannot disable  the management engine. This is actually the last line of computers you could actually,  you could disable it. It's a 2011 one. It's not strange I'm using it. You can read about  it on Wikipedia. So Intel claims it's a good thing. They have the management engine. You  know, they give, you know, X service to corporate customers. They can actually get network access  on the CPU. But we don't really know what it does. Right? So I mean, I plugged this from  the internet. Oh, sorry. It can read anybody in RAM. It can send data to the network interface.  Communicate with the operating system. You know, I mean, it could be abused, right? Could  it be? We trust Intel. We all do. And Tanenbaum, I mean Intel, you know, fired a host of questions  to Tanenbaum at the time they were introducing Minix on the chip, right? And he didn't know  what it was about. So for the record, he says, you know, you know, if I suspected they might  be building a spy engine, I certainly wouldn't have cooperated. AMD, any better? No. No.  They actually have a management engine and we know nothing about it. Yeah. You can check  this right up by someone. So Minix itself is minimalistic. It's about 4,000 lines of code  they claim for the kernel itself. It's a microkernel. And they think that they within these  4,000 lines, they can eventually make it bug free. They're not stating it's bug free now.  But small helps with minimalism, right? And that's also why probably Intel put it on their  chip. It's ironic. So when it comes to minimalism, you know, we really are talking about simple  components and composability. You know, how do these components fit together? And the  Unix philosophy, the original one, I'm not talking about system D here, they have this.  It's served as well, right? So we have Janneke here who is working on GNU-Mess, which is  replacing that 350 megabyte binary blob. And he wants to reduce it, the team wants  to reduce it to 500 bytes of binary blob. Well, that would be an improvement, no? And  it will affect all Linux distributions. So this is also about components and composable  and also about readable. What is this 300 binary blob? It's got a GCC compiler in there,  Ben Utils. Janne? Ah, so it's a distribution. Yeah, it's a small distribution itself. It's  used to, because to compile Debian, you need to compile something, right? Yeah. But this  is what Debian does, and the others are no better. The HURT, another group, the GNU projects  are co-occurred, they have 400,000 lines of code, so it's not minimal, but it's a micro-curtle.  And it aims to surpass the Unix kernel functionality, security and stability. So what it means,  security, you know, it has to be more composable and more, sorry, more components, component  mentalized, what is the word, and composable, right? So while the GNU HURT doesn't, it's  not a very active project today, you can see that in time it could become important. GNU  Geeks, anyone heard of GNU Geeks here today? Yeah, so this is another attempt at, you  know, making things in smaller components and making them composable. I'll say a bit  more about that if I have time. Sorry. So is this minimalistic? So this is a, you know,  a billion transistor chip, and it looks like, you know, they're components, and that it's,  you know, it certainly probably is composable, but no one, you know, today can understand  what's really there. It's all done by machines. But also, you know, it is actually pretty  complex. I mean, if you look at the street map of Brussels, yeah, it also looks like  it's components, you know, their house is there, and, you know, there's an API, they're  functioning together. But what's really happening at that level, we have no concept of understanding  anymore, right? I mean, we never had, never really had when we left villages, small villages.  So modern CPUs actually look like city maps today, you know, many, many components. They  look composable, but they're actually complex, and we rely on that technology throughout,  right? That's why that's who a stuff is such a concern. This is a graph, and the graph  is a dependency tree from GNU Geeks. So this shows Python with its dependencies. Sorry  about this small size. I probably have it open somewhere. Yeah, there you go. Yeah,  so if you zoom in a little bit, you can see how it all hangs together, okay? So this is  your typical stuff that you run on your computer. Switch. Are they components? These individual  pieces of software? You know, well, this is a graph, and it looks like it's components,  components. These are not components, really. You know, these are components of software,  but how they really interact with each other, we don't know, right? We only can show how  they depend on each other. So what we are running on our systems is not really component,  it doesn't consist, I mean, it consists of components, but they're not understandable  components. So one thing you can improve things to make it more minimalist is say, okay, when  I need something to run, I only want, I may create a container or a computer which only  has a software on it that I actually need to run it, right? So basically you take the  graph and you reduce it. If you take a typical Debian distribution, it will, there will be  a lot of install pieces of software and you may never even run, right? But to make it  more minimalistic, what you could do with GNU Geeks and the Louser because it controls  the dependency graph is to say, okay, I'm going to create a container and I'm only going  to put the software on it that I need to run my service, right? And this makes, GNU Geeks  makes it reproducible but also minimizes the attack surface, you know, and in a way  for embedded systems, it could be redefining the future.  So the message really is that things should be simple, transparent, there should be clear  dependencies, clear APIs, well-defined behavior, easy to read, you know, we should aim for  that in an ideal world. So why do we want minimalism? To avoid dependency hell, I guess,  back doors, spying, malicious intent, in a nutshell. Questions?  Why do you think software seems to evolve towards the more complex? It sounds like simpler  could be simple to make.  Yeah, but complexity sounds better.  There are many reasons, I think, you know, but before, because we can, it's one word.  Because we can, I mean, if you think about, you know, language like Go with all the dependencies  and the modules that they pull in, you know, typically hundreds or, you know, JavaScript  is also a famous one. Joe Armstrong who created Erlang, you know, he claims that he always  avoided dependencies, you know, so for the Erlang compiler and environment, he says,  you know, that's the reason why it's still running today or most of the systems are  still running today.  But there's something to be said for that. Yeah, how much time do I have?  Maybe the next week? Yeah.  Can I add something to your question? It's also from our education. I'm from the city  in Prague and I guess I said that no one teaches students about the problems of complexity,  how to do complexity. There's no system at all. And I saw it all myself that I learned  this from practice in an open source, but most of the colleagues never learned it. They  worked in some corporates and they built all the staff, all the complex staff and don't  understand what the problem is. So this is each part of the problem.  Yes. Yes, sir. Who have you covered on this course from Emily  who is simple, clean and wrong? I'm no philosopher. Yeah.  For every simple thing or solution? For every simple problem, there is a solution that is  simple, clean and wrong. Yeah, simple, clean and wrong. Yes.  It's really a complex topic. I think the point is that simplicity by  the way, I said does not guarantee that it's correct. Yeah.  So how do you prove that something is correct? Yeah. That's a whole area of research, an  active area of research in fact. Yes. Are you ready, Shama? Is it working?  Yes, sir. Okay. Jelle?  So what do we do? Well, we should aim for simpler hardware  and simpler software. Yeah, and with software we can already do a lot. Hardware is going  to be a different story for the time being. But I think if open and free hardware platforms  come along that are affordable and almost are fast enough to beat my 11-year-old computer,  we'll take them. I'll take free hardware. Yeah.  So, I'm actually using minimalism as a shift alternative to proper design. Like, the one  way to do proper design is to do the minimum design, but it's not necessarily a good solution.  So. There are trade-offs, you know. Yeah.  So minimalism, there are trade-offs for sure. And companies will, you know, the Microsoft  will not opt for minimalism. Normal Google. Yeah, but I think for ourselves, we need to  drive for it hard. And when a phone comes along, you know, which is free hardware and  it has, you know, a relatively simple operating system and free software, some people will  opt for it, you know, and get more privacy out of it. Yeah.  I wonder if you have how you measure complexity kind of empirically. I mean, it's easy to  say, okay, a million miles of code must be complex. But if they're all doing something  like, how do you measure, is there some property of the dependency graph you can measure? How  do you measure complexity? How do you measure complexity? Hmm, it's a difficult one, again.  And it also depends on what you are trying to create, right? So, you know, we are dealing  with complexity in many ways and it's an active area of research also. Yeah, I think with  computing, we are going, you know, a little bit off the rails lately. Yes, Mark?  Isn't it like a bit like evolution? I mean, if you look at the software which survives  at the fittest and it compares to organisms, they all have DNA which junk all over the  place and the software is the same basically. Yeah. So, yeah, actually nature is highly  efficient. It gets rid of junk. It takes a long time. It takes a long time, yeah.  So, I think we also have a very nice tool in popular science which is layers of abstraction.  In other words, when I look at these screen points with dark characters on it, I don't  think there are pixels that someone had to think about drawing the pixels. I don't have  to think about this here. I think a little bit. Come on.
Minimalism_matters_ssYCtfasK8Y_0_179.png Minimalism_matters_ssYCtfasK8Y_180_4967.png Minimalism_matters_ssYCtfasK8Y_4968_8567.png Minimalism_matters_ssYCtfasK8Y_8568_9191.png Minimalism_matters_ssYCtfasK8Y_9192_11699.png Minimalism_matters_ssYCtfasK8Y_11700_15863.png Minimalism_matters_ssYCtfasK8Y_15864_22619.png Minimalism_matters_ssYCtfasK8Y_22620_22799.png Minimalism_matters_ssYCtfasK8Y_22800_22859.png Minimalism_matters_ssYCtfasK8Y_22860_23135.png Minimalism_matters_ssYCtfasK8Y_23136_23579.png Minimalism_matters_ssYCtfasK8Y_23580_23891.png Minimalism_matters_ssYCtfasK8Y_23892_24167.png Minimalism_matters_ssYCtfasK8Y_24168_24251.png Minimalism_matters_ssYCtfasK8Y_24252_24323.png Minimalism_matters_ssYCtfasK8Y_24324_24527.png Minimalism_matters_ssYCtfasK8Y_24528_26879.png Minimalism_matters_ssYCtfasK8Y_26880_26951.png Minimalism_matters_ssYCtfasK8Y_26952_27407.png Minimalism_matters_ssYCtfasK8Y_27408_27767.png Minimalism_matters_ssYCtfasK8Y_27768_27959.png Minimalism_matters_ssYCtfasK8Y_27960_28119.png
I have a loud voice. Welcome everyone. We organized the minimalism death room and there have been some very interesting talks. I'm going to take a slightly more generic approach and discuss why we set up the room and why minimalism matters in our opinion. So the crux of the matter is that to really trust systems we need to understand them. And these days even the Debian bootstrap is 350 megabytes of binary blob. Did you know that? And it includes the GCC compiler and a host of other tools. So how do we really know what's in there is secure? Also typically these days we are downloading one gigabyte Docker images. And if you try to do a post mortem on them it's very hard to find out what's actually in there, right? I mean you can find what is in there but how was it built? How was it created? How are you sure that there's nothing untrustworthy in there? So are we driving on luck alone? Are we getting away with murder? I think the answer is yes. So what is minimalism really about? It's about things being simple, being transparent, you know, where the dependencies are really clear. We have clear APIs, you have well-defined behavior and especially, you know, the stuff should be easy to understand and read. How much of our software today actually matches these criteria? None, as far as I know. Well, maybe some scheme programs. So it should also not be bigger than necessary. Yeah, minimalism. Yes, so... So the hardly disaster you've probably all heard about and maybe looked into because it's hurt almost everyone. You know, Cisco system by identified 78 of its products as vulnerable, including IP phone system, telepresence, video conferencing systems. It costs millions of dollars, which I guess is an understatement. And the truth of the matter is it's an open source project and at the time there were only two people working there on it and it has half a million lines of code, right? And what actually happened with HardBleed is there was some code left in there which was not supposed to do anything, right? I mean it maybe was supposed to do something but it was really just left in there and nobody looked at it again and it was the problem. So how many lines of source code do you think there's in the Linux kernel and drivers today? All too low. How much is in Windows? Even more. OSX, Android, Android, 20 million. Mozilla. Facebook, you know, their code that they use. The answers. So this is the Linux kernel, you know, it's grown a little bit over time. So it's now close to 30 million lines, I guess. Oops, sorry. 25 million lines of code including drivers. You can see how it's grown since really small print. I can't really see it anymore but just in a few years, you know, it's come from 5 million. Browsers. Yeah, so 36, well, almost 37 million lines of code in Firefox. That is more than Linux. Seriously. You know, and I mean, at the time, remember when Microsoft was really worried that the browser would become the desktop? We've done it. And it's C++2, right? Scary. So, Windows, they're 50 million. OSX, that's not officially known. Android, sorry, it's only 12 million. Android is only 12 million. And then Facebook apparently has 60 million lines of code to run, you know, everything. How many transistors do we have in the CPU today? Billions. Billions. It's scary. Yeah, so the original 83, 86, which I used the program and I also did the Trash 80, by the way. Yeah, so it had under 300,000 transistors. You know, then it went in 2007 to 400 million. Then in 2014, we surpassed the billion mark. And today we are at, you know, sort of close to 20 billion transistors. Arm, is it simpler? That's what you'd hope, right? Finally, we get a new architecture. It's going to be a lot simpler, right? Eight and a half billion. So it's less than the AMD. But yeah, I think actually for what it offers, it's more. Let's discuss the Intel management engine for a bit. You are aware that every CPU produced since 2008 contains a full operating system. Right on the chip. Yeah, it's Minix. Minix? Any Linux users here today? Minix, right. So and it has, they found weaknesses in it, right? In 2017. And that, you know, this is an exploit that goes back all the way to 2008. And, you know, a normal user cannot disable the management engine. This is actually the last line of computers you could actually, you could disable it. It's a 2011 one. It's not strange I'm using it. You can read about it on Wikipedia. So Intel claims it's a good thing. They have the management engine. You know, they give, you know, X service to corporate customers. They can actually get network access on the CPU. But we don't really know what it does. Right? So I mean, I plugged this from the internet. Oh, sorry. It can read anybody in RAM. It can send data to the network interface. Communicate with the operating system. You know, I mean, it could be abused, right? Could it be? We trust Intel. We all do. And Tanenbaum, I mean Intel, you know, fired a host of questions to Tanenbaum at the time they were introducing Minix on the chip, right? And he didn't know what it was about. So for the record, he says, you know, you know, if I suspected they might be building a spy engine, I certainly wouldn't have cooperated. AMD, any better? No. No. They actually have a management engine and we know nothing about it. Yeah. You can check this right up by someone. So Minix itself is minimalistic. It's about 4,000 lines of code they claim for the kernel itself. It's a microkernel. And they think that they within these 4,000 lines, they can eventually make it bug free. They're not stating it's bug free now. But small helps with minimalism, right? And that's also why probably Intel put it on their chip. It's ironic. So when it comes to minimalism, you know, we really are talking about simple components and composability. You know, how do these components fit together? And the Unix philosophy, the original one, I'm not talking about system D here, they have this. It's served as well, right? So we have Janneke here who is working on GNU-Mess, which is replacing that 350 megabyte binary blob. And he wants to reduce it, the team wants to reduce it to 500 bytes of binary blob. Well, that would be an improvement, no? And it will affect all Linux distributions. So this is also about components and composable and also about readable. What is this 300 binary blob? It's got a GCC compiler in there, Ben Utils. Janne? Ah, so it's a distribution. Yeah, it's a small distribution itself. It's used to, because to compile Debian, you need to compile something, right? Yeah. But this is what Debian does, and the others are no better. The HURT, another group, the GNU projects are co-occurred, they have 400,000 lines of code, so it's not minimal, but it's a micro-curtle. And it aims to surpass the Unix kernel functionality, security and stability. So what it means, security, you know, it has to be more composable and more, sorry, more components, component mentalized, what is the word, and composable, right? So while the GNU HURT doesn't, it's not a very active project today, you can see that in time it could become important. GNU Geeks, anyone heard of GNU Geeks here today? Yeah, so this is another attempt at, you know, making things in smaller components and making them composable. I'll say a bit more about that if I have time. Sorry. So is this minimalistic? So this is a, you know, a billion transistor chip, and it looks like, you know, they're components, and that it's, you know, it certainly probably is composable, but no one, you know, today can understand what's really there. It's all done by machines. But also, you know, it is actually pretty complex. I mean, if you look at the street map of Brussels, yeah, it also looks like it's components, you know, their house is there, and, you know, there's an API, they're functioning together. But what's really happening at that level, we have no concept of understanding anymore, right? I mean, we never had, never really had when we left villages, small villages. So modern CPUs actually look like city maps today, you know, many, many components. They look composable, but they're actually complex, and we rely on that technology throughout, right? That's why that's who a stuff is such a concern. This is a graph, and the graph is a dependency tree from GNU Geeks. So this shows Python with its dependencies. Sorry about this small size. I probably have it open somewhere. Yeah, there you go. Yeah, so if you zoom in a little bit, you can see how it all hangs together, okay? So this is your typical stuff that you run on your computer. Switch. Are they components? These individual pieces of software? You know, well, this is a graph, and it looks like it's components, components. These are not components, really. You know, these are components of software, but how they really interact with each other, we don't know, right? We only can show how they depend on each other. So what we are running on our systems is not really component, it doesn't consist, I mean, it consists of components, but they're not understandable components. So one thing you can improve things to make it more minimalist is say, okay, when I need something to run, I only want, I may create a container or a computer which only has a software on it that I actually need to run it, right? So basically you take the graph and you reduce it. If you take a typical Debian distribution, it will, there will be a lot of install pieces of software and you may never even run, right? But to make it more minimalistic, what you could do with GNU Geeks and the Louser because it controls the dependency graph is to say, okay, I'm going to create a container and I'm only going to put the software on it that I need to run my service, right? And this makes, GNU Geeks makes it reproducible but also minimizes the attack surface, you know, and in a way for embedded systems, it could be redefining the future. So the message really is that things should be simple, transparent, there should be clear dependencies, clear APIs, well-defined behavior, easy to read, you know, we should aim for that in an ideal world. So why do we want minimalism? To avoid dependency hell, I guess, back doors, spying, malicious intent, in a nutshell. Questions? Why do you think software seems to evolve towards the more complex? It sounds like simpler could be simple to make. Yeah, but complexity sounds better. There are many reasons, I think, you know, but before, because we can, it's one word. Because we can, I mean, if you think about, you know, language like Go with all the dependencies and the modules that they pull in, you know, typically hundreds or, you know, JavaScript is also a famous one. Joe Armstrong who created Erlang, you know, he claims that he always avoided dependencies, you know, so for the Erlang compiler and environment, he says, you know, that's the reason why it's still running today or most of the systems are still running today. But there's something to be said for that. Yeah, how much time do I have? Maybe the next week? Yeah. Can I add something to your question? It's also from our education. I'm from the city in Prague and I guess I said that no one teaches students about the problems of complexity, how to do complexity. There's no system at all. And I saw it all myself that I learned this from practice in an open source, but most of the colleagues never learned it. They worked in some corporates and they built all the staff, all the complex staff and don't understand what the problem is. So this is each part of the problem. Yes. Yes, sir. Who have you covered on this course from Emily who is simple, clean and wrong? I'm no philosopher. Yeah. For every simple thing or solution? For every simple problem, there is a solution that is simple, clean and wrong. Yeah, simple, clean and wrong. Yes. It's really a complex topic. I think the point is that simplicity by the way, I said does not guarantee that it's correct. Yeah. So how do you prove that something is correct? Yeah. That's a whole area of research, an active area of research in fact. Yes. Are you ready, Shama? Is it working? Yes, sir. Okay. Jelle? So what do we do? Well, we should aim for simpler hardware and simpler software. Yeah, and with software we can already do a lot. Hardware is going to be a different story for the time being. But I think if open and free hardware platforms come along that are affordable and almost are fast enough to beat my 11-year-old computer, we'll take them. I'll take free hardware. Yeah. So, I'm actually using minimalism as a shift alternative to proper design. Like, the one way to do proper design is to do the minimum design, but it's not necessarily a good solution. So. There are trade-offs, you know. Yeah. So minimalism, there are trade-offs for sure. And companies will, you know, the Microsoft will not opt for minimalism. Normal Google. Yeah, but I think for ourselves, we need to drive for it hard. And when a phone comes along, you know, which is free hardware and it has, you know, a relatively simple operating system and free software, some people will opt for it, you know, and get more privacy out of it. Yeah. I wonder if you have how you measure complexity kind of empirically. I mean, it's easy to say, okay, a million miles of code must be complex. But if they're all doing something like, how do you measure, is there some property of the dependency graph you can measure? How do you measure complexity? How do you measure complexity? Hmm, it's a difficult one, again. And it also depends on what you are trying to create, right? So, you know, we are dealing with complexity in many ways and it's an active area of research also. Yeah, I think with computing, we are going, you know, a little bit off the rails lately. Yes, Mark? Isn't it like a bit like evolution? I mean, if you look at the software which survives at the fittest and it compares to organisms, they all have DNA which junk all over the place and the software is the same basically. Yeah. So, yeah, actually nature is highly efficient. It gets rid of junk. It takes a long time. It takes a long time, yeah. So, I think we also have a very nice tool in popular science which is layers of abstraction. In other words, when I look at these screen points with dark characters on it, I don't think there are pixels that someone had to think about drawing the pixels. I don't have to think about this here. I think a little bit. Come on.
is that to really trust systems we need to understand them. And these days even the Debian about? It's about things being simple, being million lines of code, right? And what actually interact with each other, we don't know, right? has a software on it that I actually need to run run, right? But to make it more minimalistic, learned this from practice in an open source, but should aim for simpler hardware and simpler do a lot. Hardware is going to be a different know, the Microsoft will not opt for minimalism. comes along, you know, which is free hardware and