So we're here with Atom Nano Electronics. So who are you? I am Yifan Chau. I'm the principal scientist of Atom Nano Electronics. So what kind of stuff are you showing here? Our company focuses on both materials, inks and also electronics applications. So this is our 6.5 Hipco single wall combinator inks. This is a pure semiconductor material, ink. You can directly print it on any soft or hard substrate and assemble your transistor. You replace silicon-based transistor materials. So it's for replacing the silicon? Yes, it's for replacing silicon-based transistor materials. So no more silicon valley? No more silicon. It's soft. You can print it on any substrate. It has high oil-off ratio. And more specifically, this is a single species of carbon nanotube. So it has exactly the same band gap of every tube, and that gives you a much higher uniform product. So it's uniform carbon nanotube? It consumes less energy and transparent. Alright. What are you showing there? This is a transistor. We use a 3D ESO gel printer on a glass substrate. 3D what? 3D ESO gel printer to print it on a glass substrate. So the electrodes are based on gold. And we print the nanotube active material in between the gold electrodes. And finally put the dielectric layer and topgate electrode. So what are you showing here on the wall here? These are the raw carbon materials. We separate them into the single species 6.5 carbon nanomaterials. Then we apply them using the ESO gel printer or other printing technique like this casting spinning into the substrate to make TFT bad plans or transistors. And our final target will be to apply these transistors out of TFT bad plans into actual display modules. Alright. So you make the ink? We make the ink. We make the material. And we make the application of it. Is it big machines to make the ink or what? It's mainly separation of the raw material. You can see the raw material is a black powder. But actually separate fine ink is nice purple color. How do you do that? That is secret. Secret. Alright. So that's a nice secret. And in the future it's going to be used a lot or it's already used? It's already used in our company and we are supplying our company's own requirements but we're also trying to expand the market, supply it to any other people interested in transistor applications, in sensors. So what do you think about ID Tech X? This conference? It's a great conference. Since we are a startup company it gives us a lot of opportunities to meet different big small companies and having possible collaborations and nice discussions in different fields. And interesting things happening here, right? Yes. Interesting technologies being worked on around here. Printed electronics is cool, right? It's really cool and we are proud of it.


Hello, I welcome you all once again to my channel Explore Education and I am Dr. Rashmi Singh, Assistant Professor, Department of Education, S.S. Khanna, Girls to be College, University of Al-Ahabat and it is my email ID. And today I am going to discuss a new topic under the new category of statistical analysis. Okay, this is a very important subfield of education, psychology and many other disciplines in which we have to read statistics and have to do statistical calculations. Okay, so the topic of today's discussion is parametric and non-parametric tests and the lecture will be bilingual mode and will be very useful for various topics, examinations and courses. Okay, so do subscribe my channel as well. Generally, we have talked a lot about psychology, I have covered the science in almost every course generally. This was a portion of research and statistics, which I wanted to talk about for a long time. So right now I am starting with parametrics and non-parametric and there are a lot of things to be told about. Data, variable, scale, after that there are a lot of parametric and non-parametric parameters. First of all, the basic knowledge is that what is the meaning of the examinations and what is the meaning of the parametric, non-parametric, parametric, parametric, what is the meaning, what are the assumptions. Then there are a lot of things to learn. So we will learn slowly. First of all, the knowledge of the examinations. A statistical hypothesis test is a method of statistical inference used to decide whether data at hand sufficiently supports a particular hypothesis. Now we have started with the hypothesis, but we believe that you know what is the hypothesis. What is the hypothesis? Sorry. When we go to do some research, do some kind of work, then first of all we can start with the vacuums. We have to assume some assumption that this is the case. So the assumed concept, which we have assumed is the same hypothesis. Why do we need that statistical test? That we are able to tell whether the assumption that we have taken is right or not. So if we put the statistics on it, then we get a lot of power. That John Gairn is right. He is statistically right. He is technically right. Scientifically right. Just don't talk about it many times. So this is what we are saying that the statistical hypothesis test is the same type of statistical inference. We can also estimate the statistics at the level of the data we have that the particular hypothesis is not supporting it. Hypothesis testing allows us to make probabilistic statements about population parameter. Many concepts are not mentioned in this. What is the population? What is the parameter? What is the sample? We believe that you all know or we will talk about it later. Hypothesis testing allows us to say that we are in a probabilistic statement. This is the inference. Hypothesis testing allows us to say that we are in a probabilistic statement about population parameters. Hypothesis testing was popularized early in the 20th century. Early forms were used in the 1700s. This means that it is popular in the 20th century. But it is popular in the 1700s. The first use is credited to John Erbuth-Nott, followed by P. R. A. Simon Laplace. John Erbuth-Nott's name was generally not mentioned. But Laplace's name was mentioned. But Laplace was popular and Laplace was popular. In analyzing the human sex ratio and birth. This is taken from Wikipedia. This means that it is in the 17th and 17th centuries. It is in the 17th and 17th centuries. This means that it is in the 17th and 17th centuries. This means that it is in the 17th and 17th centuries. What is the statistical test? A statistical test is a formal technique based on probability distribution for arriving at a decision about the reasonableness of an assertion or hypothesis. The reasonableness of the parikalna that we have taken, means that you can bring power and support to it. The probability distribution of reaching there is based on it for my technique. The normality of the population distribution forms the basis for making statistical inferences about the sample drawn from the population. We will discuss the sample from the population. As we all know, the sample represents the population. We apply the technique to the sample. We will not go to it. We will go to it. The normality of the population distribution. We have studied it in NPC. You can see my old video on NPC. In general, NPC means the normal probability curve. If we take out any data, then it generally follows the normal distribution. As you can see, it does not have a diagram here. It has a height and weight. What does it mean? What is the tendency of the data? That it stays on the center. And what is extreme, it works there. Now we will not go to NPC. I will show the link of NPC in the description. I will share it with you. When NPC will happen, I will be equal to the median. Then what are they saying? These are statistical tests. Two kinds of assertions are involved. Whenever we take a sample test, then we take two types of assertions. An assertion directly related to the purpose of investigation. One assertion is that the purpose of our investigation is directly related to it. And other assertions to make a probability statement. The second assertion, which is our data, which is our path, which is probability statement. What is the meaning of our research? In general. This is a statistical test. It is a quantitative research. It is experimental research. What is its main goal? We will put a sample test and generalize it on the population. So, it is necessary for generalization to make a probability statement. You will be able to generalize it on a large population. The former is an assertion to be tested. The first one is the purpose of the investigation. We have to examine it. And it is technically called a hypothesis. And it is called a hypothesis. Whereas the set of all other assumptions is called the model. And the second assumption is the model. And these are the two things that the statistical test measures. The first is the hypothesis. This is the reasonableness. And the second model that we are following is so static. It is following the normal probability. It is not following the probability distribution. What are the things that we will see in the future? So, we have to apply the statistics of the data we have taken. According to the statistical test, we can draw its inference. That we are supporting that hypothesis. Whether the entire data or our hypothesis is accepting or not accepting. Sorry, are you rejecting or not rejecting? We will have to talk about the null hypothesis. To tell you a lot about the hypothesis, you should also know about the null hypothesis and alternative hypothesis. So, there are a lot of things that we are following. We know a lot about it. Then it will be the last one. So, the two statistical tests are mainly in two ways. Parametric or non-parametric. There is no need to know anything about India.  There is no need to know anything about India. Parametric or non-parametric. There is no need to know anything about India. So, what are the parametric statistics? Parametric statistics are based on assumptions about the distribution of the population from which the sample was taken. That means, everyone knows that we will do research on the entire population. We will draw a sample from the population. So, the parametric statistics are based on the distribution of the population. That means, we know the distribution of the sample from which the sample was taken. In parametric statistics, the information about the distribution of the population is known. We know the distribution of the population. We are a researcher. And it is based on a fixed set of parameters and some fixed parameters are there. What else is there? The parametric test is the hypothesis test. The parametric test is a comparison of a particle. That provides generalizations. What is this? The quantitative research has the purpose of generalizing it. The more you set the statistics, the better you can generalize the sample. So, parametric test is the hypothesis test that provides generalizations for making statements about the mean of the parent population. One more thing. Parametric tests are there because we know the distribution of the population. That is why there is a central tendency to take the mean. Why do we take the mean? You can see the classification in the future. Because the mean is not skewed in the data. The mean is the center tendency of the static. But if the data is skewed, then it is better to take the media. Because the media doesn't matter which data is at the extreme end. We take the ring of the middle and take the ring of the top and take the ring of the back. So, parametric test talks about the meaning of the parent population. All parametric tests assume that the outcome is approximately normal distributed in the population. All these parametric tests assume that the distribution of the population is normal. This does not mean the data in the observed sample but rather that the outcome follows a normal distribution in the full population that is non-observable. This means that the result will follow a normal distribution if we plot it on the graph. On that population which we have not observed. What is the assumption? What is the assumption of the distribution of the sample should be distributed normally distributed? Samples are in the form of interval ratios. Now let's look at the scale of the program. The scale of the program is the nominal-ordinal interval ratio. The interval ratio is higher than the normal-ordinal interval ratio. Where all the numbers of samples are made, the parameters are placed on them. The nominal-ordinal parameter is non-parametric. Observation must be independent. The population must have the same variance. Samples must have equal or nearly equal variance. Non-parametric states are based on assumptions that the data can be collected from a sample that does not follow a specific distribution. This means that we do not know the characteristics of the sample from that population. This normal probability does not follow. In non-parametric statistics, the information about the distribution of the population is unknown. And the parameters are not fixed. Which makes it necessary to test the hypothesis for the population. This test is mainly based on differences in media. This means that the skewed data is given to the media. Because we do not know how much data is collected. How much data is collected. How much data is differing. When the mean is followed, when we know everything, the normal probability is followed, then the mean will have to be reached. But the skewed data also has to be reached. Why? Because we only take the uncle. We have to understand it from the mind. Hence, it is alternately known as the distribution field. Hence, it is known as distribution free test. You should know that non-parametric test is also known as distribution free test. The test assumes that the variables are measured on nominal and ordinal. What was there before? Your interval ratios are of nominal and ordinal. And non-parametric statistics are classified into three types known as non-inferential statistical measure, inferential estimation techniques and hypothesis testing. This does not mean that these three types are followed by non-parametric statistics. And the common assumptions in non-parametric tests are randomness and independence. And the common assumptions in non-parametric tests are randomness and independence. And the key square test is the most important example. Difference. A lot of people ask what is the difference between parametric and non-parametric tests? The key difference between parametric and non-parametric test is that the parametric test relies on statistical distribution in data, whereas non-parametric do not depend on any distribution. Sahiba, if non-parametric does not make any assumptions and measure the central tendency with the median value, while parametric is a statistical test that assumes parameters and the distribution of the population is known. It uses a mean value, non-parametric uses median value. When the samples are small and the distribution of the outcome is not known and cannot be assumed to be approximately normally distributed, then alternative tests called non-parametric tests are appropriate. They are saying that when the sample size is small and you do not know its distribution, if the data is skewed, then use non-parametric. This is understood with a table. Properties are parametric tests and non-parametric tests. What is the assumption? We know that in parametric tests, we do not know in non-parametric tests. The value of the central tendency is in the mean or the median. In correlation, in parametric tests, Pearson runs and here Spearman runs. Because it is the random order of Spearman. Probabilistic distribution parameter test is normal. It is arbitrary. The population here is known. It is necessary that you know or it is not necessary. This is used in interval data. It is used in nominal data. The applicability is of variables. And this goes on attributes. And reasons to use. This is very repetitive. Please do not read it completely. You will understand that the underlying data do not meet the assumptions about the population sample. The population sample size is too small and the analyzed data is ordinal or nominal. So this is all about non-parametric and parametric tests. And thank you all. And do not forget to like and subscribe my channel. I hope that you understood this concept. Enjoy my telegram group.


Hey guys, my name is Jose Montoya. Welcome to this talk named Tavros and Kuma, Essential Software Concerns at the Platform Level. A little bit about myself. I work for a company called Mountain State Software Solutions or MS3 for short. We specialize in enterprise integration software, cloud migration strategies, and API enablement. So I've been doing this for about five years now and for the last six months to a year I've been the principal product manager for Tavros. Tavros is a enterprise integration platform for MS3. Today I'll be taking you guys a little journey between what Tavros is and how we use Kuma to address some of these essential software concerns at the platform level. So we'll get right into it. So the first thing that we should do is talk about this essence of software. So the concept comes from a book called The Mythical Man-Month. You might be familiar with it. It's sort of a classic in software engineering. In this book, Frederick Brooks has basically a collection of essays about software engineering in general. In particular, there is one called No Silver Bullets, The Essence and Accident in Software Engineering, where he basically describes what he thinks the essence of software engineering is. Here's what he says. The hard part of building software is this specification, the sign and testing of this conceptual construct, not the labor of representing it. Basically what Brooks is saying is that the hard part is really understanding what it is that we want to build and kind of creating our mental, this conceptual construct, right, designing it even as a conceptual construct. The part about representing it in the software in a programming language is kind of accidental complexity, right? The hard part is really that conceptual construct understanding and designing it in our minds. He goes on to talk about how he doesn't envision any individual breakthrough in software engineering that is going to really revolutionize the productivity levels that we have when we create software. He talks about things like higher level programming languages or object orientation or even artificial intelligence as things that he doesn't think are going to be monumental in their effect on software engineering. He does have a few things that he considers to be worthwhile attacks on the essence of engineering to provide this kind of boost the productivity. He lists four. I have grouped them here in two groups of two because I think these groups kind of go together. I'll go through them now. First is the requirements, requirements, refining and rapid prototyping. Basically here he talks about iteratively refining your requirements gathering, right? So there's no way that we can get our requirements precisely and accurately all up front. So we might as well just prototype and learn as we go. Just keep refining our requirements and prototyping as we go. I think in the same vein he talks about incremental development where he basically says that instead of trying to deliver all of the features of a software product kind of all at once with the final nail, just kind of do it incrementally, right? So start from a kind of very bare piece, maybe even useless, but you know, standalone and functional and start adding features incrementally, right? So the analogy is to grow software instead of building it as a building, just grow it as a living thing. So I think these two attacks kind of go hand in hand and to me I grouped them together because this for me is just inspect and adapt, right? And so some of the words might have seemed familiar to you guys when we think about agile development for example or continuous delivery. The idea is that we want to go at it piece by piece incrementally not all at once. So agile and continuous delivery I think kind of fit that same idea of, you know, incremental development prototyping and requirements refining. Microservices and containerization I have here because as we make these units of functions smaller, it makes it easier for us to prototype. It makes it easier for us to try different languages, different designs, different framework, et cetera. And observability I have here because it is imperative for us to have good observability into our systems in order for us to really inspect meaningfully and have the ability to make educated decisions on that inspection in order to adapt. The other two attacks that Brooks talks about in his book is buy versus build, which I think is the main one. He's basically saying the most productive time, you know, trying to deliver software is when we don't spend that time at all.  And the other one is great designers where he basically just says, hey, at the end of the day, software is sort of a creative process. It's an artistic process. So some people are just going to be better at it than others. Specifically, you know, more experienced developers are always just going to be better than those non-experienced. So he talks about, you know, spending time and resources on people and get them to be these great designers. But at the end of the day, again, you just have to have good people, good designers. And so these two, I kind of take me into the main driven design, right? So the main driven design by Eric Evans has this concept of distillation, which is basically to say in your software components, in your IT landscape, in your industry, you got to identify what he calls core domains versus generic subdomains. So your core domains are going to be those things that are essential to your business that drive business value for your company. And the generic subdomain ones are going to be just supporting roles that are still essential, but are not the principal drivers of value. They're not the things that are going to differentiate you versus another company in the same industry. So for example, if you think about banking, a fancy CRM is not going to be my core domain. It's not going to differentiate me from another bank. You know, the latest and greatest identity management system is not going to be my core domain. Banking services is going to be my core domain, how fast a customer can open a checking account from their phone. Internally, how fast or how easy internal developers can gather information from six or seven different backing systems that have different types of accounts, how easy they can consume, compose and maybe filter that data to provide mobile phone user interface, maybe even an Alexa conversation or a website, etc. So these are things that do drive the business value that we can offer as a bank that differentiates as a bank. So these will be our core domain. So the idea is that through distillation through this process of identifying core from generic subdomains, we can strategically decide when to buy versus bill. The other point that Eric Evans makes is that because generic subdomains are generic across industries, they've been studied more. They're kind of more tractable. They're not domain specific. They're easy to understand and attack. So they sometimes attract your more skilled developers. So what ends up happening is your your great designers end up working on the things that bring you the least amount of value. So again, the idea is spend some time identifying what you should build versus versus what you should buy and act on those, you know, on what you've identified. If we take it one step further, we can identify even more things that ought to be considered in this process, which I call generic cross cutting concerns. These are things that apply regardless of whether there is a core domain or generic subdomain, things like security, logging, tracing, any of these cross functional cross cutting concerns that apply. And you need to think about it because even though they still play a supporting role, it's still essential. No one's going to use your system if it's not secure. So yeah, we need to keep this in mind and try to bring this into this strategic buy versus build. But we'll start with the generic subdomain. So let's say once we've identified, you know, I'm a bank, I don't need to build a CRM. And we identify all these products and we say we're just going to buy them. We're going liberate our developers, our great designers to work on our core domains. And not on the generic subdomains that are only, you know, supporting, they're the supporting cast. Great. Great first step. What happens though is that now that you have off the shelf products, you bring in some challenges around integration. Now the surface here is going to be smaller than your core domain because integration is mostly going to be about translation and orchestration. But it's still a place where you can drive value value from right. So if, if, if you're a bank again, and you bought a system for mortgage, mortgage accounts, a system for credit card, credit card accounts. If you develop a integration component that allows you to view all of those accounts uniformly from independently developed components, that's a differentiating factor, right? It makes it easier for your customers to access their data. It makes it easier for you to developers, I'm sorry, to develop differ, different user interface experiences for you, for your customers. So it does become a point where you can drive differentiating factors in your industry. Yet we still have to worry again about these generic cross cutting concerns. We have to secure this integration components. We have to make sure their performance that they have blogging and observability, et cetera. So that becomes our next step. How do we buy versus build these generic cross cutting concerns that are not really what gives us value as a bank or any other industry, right? How do we address these so that we can focus even more on the core domain or the integration domain to drive value? So there's two ways of solving this. One is through application or language specific library. So we can say, okay, you know what? There's a spring boot library or a dot net core library that solves security and it solves tracing. So we're going to mandate that all our applications are going to be developed in this one language and we're going to use this library. You've solved it, but you've kind of gone against the idea of containerization and rapid prototyping because, and with microservices because the idea is that you should be able to experiment easily to say, maybe this one particular component would be best implemented in this other language or this other framework. And you can do that now if you've chosen to solve these generic cross cutting concerns through a library. So the other way to solve it is through service mesh. And for that, we've chosen to use kuma. So what this does is it solves those concerns just the same, but in a way that is independent of the language implementation framework, anything that the actual workloads are implemented in. And so this is the decision that we made at Tavros and we'll get into that now. So, you know, given the rise that we've seen obviously because we're in this industry of enterprise integration, we've seen a clear demand and a continuing to grow demand for an integration platform that solves a lot of these, you know, kind of generic concerns for them because as more off the shelf products become available and as, you know, we kind of digitalize ourselves as a society more and more, these companies are figuring that, hey, maybe I really should only spend my time on what makes me, you know, better than my competitors instead of trying to solve logging and tracing and security over and over again. Because that's what we find as a consulting company is that we end up so solving observability in 10 different ways and 10 different clients because they try to do it on their own way. Not to say that that's bad, but that's not, those are not the main, you know, the principal drivers of value for this company. So that's not where they should be spending their time. So we committed to Tavros, which is our enterprise integration platform, writing and orchestration and data transformation are at the heart of it. But we also wanted to make containerization important because we didn't want to be that platform that says, hey, only if here's our engine and our data transformation framework can you deploy to our platform. If you're not using that, then you can use it. You have to use a different platform for your other workloads. And we know some platforms that are like that and we find them to be, you know, pretty limiting. So what we want to do is make sure that whatever choices we make to address some of these concerns for our customers that they were being addressed in a way that was independent of the language and then the framework. And so that's what we achieved through service mesh and through Kuma, like I explained to you before. And then we just chose open source components to address other of these concerns, right? So like observability, security and continuous delivery. This is a pretty high level overview of what Tavros is. So on the top right, for example, we have our observability components on the top on the bottom right, we have some of the other ones like eClick for security, SonarCube for static code analysis, things like that on the left. We have Jenkins and Flux, for example, driven by Git. So this kind of GitOps and continues delivery. This provides GitOps and continues delivery for our platform and for our workloads. But in the middle here is what we have is where we have the application workloads that are fronted by Kong as our API manager and load balancer and Kuma as our service mesh to provide a lot of these generic cross-cutting concerns that we talked about in a way that is independent of the implementation language or framework. So what that ends up meaning for us is that we have this generic workload that there's an application in whatever language and then there's Kuma. In this particular diagram, we're highlighting observability, so we're saying, hey, regardless of how you implement your application, Kuma is going to do observability for you. If your application happens to be aware of distributed tracing, then you can augment what Kuma offers with application-specific tracing. But if it doesn't, no worries, a generic workload will still participate in your distributed tracing because of Kuma. If you have an integration workload and you go with our framework, then you'll get some of this application augmented data. We've chosen camel and data sonnet for engine and our data transformation and open tracing for our distributed tracing in process framework. This will automatically be set up in a Tavros integration application, and so Kuma is going to do what it does with distributed tracing regardless of the type of app. But then, because this is specific to Tavros, you'll get some application-level tracing information like the step and the route in your integration flows, and then you can do custom application-specific context diagnostic tags and things like that. But the whole point of all of this, again, is to address these essential but supporting concerns of software so that the great designers, so that the application developers can focus only on the application-level concerns. So they can actually get to the part that drives value in their business. So we can move that responsibility from the application developers to the platform. So talking about Kuma specifically, what we do in Tavros is we have, you know, designated namespaced environments for workloads. Anytime there's a deployment in one of these namespaces, you'll automatically get some policies applied to your application again so that the application developer transparently gets all this value without really thinking about how it's installed and configured, etc. So what happens is as soon as an application is installed is deployed into one of these environments, they'll automatically get a tracing policy that Kuma is going to start adding tracing information for every incoming request and every outgoing request. If this application happens to be one of the integration workload from our framework, then you'll get that optional application-level data. But again, if it's not, no worries, you'll still have the benefits of getting these cross-cutting concerns addressed because of Kuma working outside of your application language. And so in our demo, what we have here is, for example, this is our logical structure, right? So we have Kong being the load balancer, the ingress basically. Then you have CRM Mobile and CRM Conductor implemented in a language different than our integration framework. It could be .NET, could be anything really. So you can imagine CRM Mobile doing some mobile-specific transformations and CRM Conductor is basically an orchestrator that goes into two integration-specific applications. One is CRM Salesforce that goes to talk to Salesforce and the other one is the database that talks to a database. The idea is that you have some customer data in both of these sources and you want to compose them for displaying them in a mobile application. And so what ends up happening once Kuma is involved in all this tracing information starts being gathered and reported is you end up with a graph like this in a system like Yeager, which is the distributed tracing system that we install and configure automatically for you in Tavros. So you can see it's almost a one-to-one representation of our logical understanding. So you have Khan, CRM Mobile, Conductor and then the two one for each implementation with their integration-specific applications. And so what this does, and this is just a general point on observability, is because we've adopted microservices as an architectural style across basically the whole industry, you start needing these sorts of tools. You start needing graphs and charts in order to make sense out of dozens and hundreds of services. You need to start being able to have analysis, root cause analysis, latency analysis, figuring out what sort of stuck to what other surface, why this particular transaction failed, where did it fail, things of that nature. So you get this for free in Tavros because of Kuma's tracing policy and its ability to work regardless of the implementation. This is another example that we have here. So if you see here in the middle, we have CRM Database and this is again because the CRM Database workload was in our integration-specific framework, we get application level tracing data. So here we have data around a set header operation or a processing operation. Here we have a logger, we have a delay, things like that. So the idea is that when you have an application that can augment what Kuma can do, great, but if not, we still have conductor here, we still have mobile, we still understand what is actually going through our integration stack, through our IT landscape. So that is the value that we needed to achieve for our customers and that we wouldn't have been able to without something like Kuma. When we tie this into your log aggregation system, like we've done between Yeager and Elastic, you can do a lot of neat things like correlating your traces with your logs, doing, like we said, all of these root cost analysis, latency analysis, you can start doing trend forecasts and things of that nature. You can start seeing your worst offenders in sorts of errors and in one single pane on glass, navigate from a high level dashboard of who's being having more errors in the last week to a specific error that has been showing up in a certain percentage of your calls. So that's observability. The second one that I wanted to highlight, let me do a quick time check here. Over time already. So the other one that I wanted to highlight is mutual TLS. And this is another one that we do by default in Tavros, which is basically any deployment that any workload that is deployed into one of the environments that we manage through mesh through Kuma service mesh will automatically also be enrolled in mutual TLS. Kong sits in the middle because it needs to take in requests externally, obviously, but anything from that point on needs to be in this trusted environment. It needs to have a certificate provided by Kuma. So we transparently provide all this information. Your developers no longer have to worry about certificate authority, certificate signing requests, rotating certificates, all this stuff that is really, really hard to do really gets addressed transparently by Tavros through Kuma for the developer again, to only have to worry about that application level logic about really driving business value for that company. They don't have to worry about the stuff. These are those generic things that we wanted to address. And we're able to, we're able to because of Kuma. And this allows us to provide things like zero trust security. And extending that through open policy agent, we can say, hey, not only are we providing the security, but we're doing it in a way that is so simple to understand and configure through declarative configurations that say, you know, all these services must be in a mesh and only A and B can talk to C. And further than that, we need to make sure that a particular all scope is available when this other one calls that other one. And so it becomes a place for you to govern in a single easy to understand declarative way exactly what should be going on internally in order to provide an easy to consume and manage zero trust security. So like I said, I'm basically out of time. So I'm running through this last slide. That kind of does it all for me. I think I'll be taking questions now. These are some links that I'm putting out for you guys in case you're interested in Tavros and the work we're doing. Thank you so much for your time.


sovereign mobile devices. Our speaker is Paul from Australia who is both the creator of the M65 retro computer and the Serval mesh networking, mesh network telephone system and this project is basically combining these two into one amazing device. Please give him a warm round of applause. Thanks. Today, well let's start with an apology. I had intended to give this talk actually using the 8-bit mobile phone that we're making. Unfortunately, the VGA connector is wonky so we're having to fall back to the old-fashioned solution here. But if you want to, there was a video that I made in New Zealand in January at LCA and we got the entire presentation there using a different one of these prototypes. So yeah, have a look at that if you want to see in action making phone calls and the whole kit or come and grab us and we can have a play with the one here and maybe even get this one working in a nice way for folks as well. I just thought I'd start with this picture of horror really. I'm an Australian, I live in Australia and someone thought it would be a good idea to put Vegemite into pretzels. Clearly this is a bad idea but it just struck me as embodying in many ways the whole problem of the issues we have around proprietary hardware and the loss of sovereignty of our digital devices. We should be able to buy a pretzel that doesn't have Vegemite in it if we want one that doesn't have Vegemite in it and it just gets to the heart of the whole issue. So what I really want to go through today, in many ways it's more on the philosophical side but using what we're doing is a practical example around that and it is really around this issue of digital sovereignty and how we can make mobile devices that are truly digitally sovereign in a way that no other mobile devices are and that are actually still useful to use. And in that there are all these questions around how we can make devices that are actually maintainable because it's the maintenance of capability that's actually harder in many ways than the creation of capability in this particular space. And then as we start thinking about different radio types and things that we can make devices that are independent of infrastructure, independent of energy, we need to think about how we can handle complex untrustable devices in a way that makes them still maintainable as a capability to use. And then finishing around how we can make new interesting mobile devices that have not really been possible to do and to do that with much fewer resources than it currently takes. And then having a look at the very end about how we can do that with radio. So my goal is we'll be finished with me talking in the next 25 minutes or so and have plenty of time for questions but we'll take it fairly flexibly. So what do we mean by digital sovereignty? And my thinking around this has really been around what do we think about as sovereignty for normal, in a normal kind of way of life. So this really is actually that people should be able to create, modify. So what the things we understand from the GPL ought to apply in practice to the devices, the software systems and things that we're using. And this means as we know innovating without permission, changing the purpose, making something useful in a new and different way. And also should be able to sustain capability. And this is the thing that I will keep coming back to. That we need to be able to not just make something but actually be able to make something that can be maintained in the long term for it to actually be practical and useful. And so I took a look at what the Wikipedia definition is for sovereignty. And this is a really interesting point that's hinging around the full right and power of something to do things itself. So if we think about the digital world, it's our full right and power to be able to have a digital artifact and do what we want to it without any interference, without any hindrance from any outside sources or bodies. And this actually makes this really interesting point that the right to modify, the GPL gives us the right to modify. So we can modify the Android open source software project or various other things that are under open source licenses, whether GPL or other ones. But it doesn't mean that we necessarily have the power to do that. That it may require so many person months of effort to even just get the thing to compile, let alone to actually understand how it works enough that we can use it for a different purpose. And so the practical effect of this is a digital sovereignty, and I think we're all probably fairly conscious of this, lags behind physical sovereignty in a fairly significant way. So if we compare just a conventional bucket that you would use to carry water or whatever and a smartphone, we actually find that our freedom, our sovereignty over these devices is wildly different. So with a bucket, we can use it until it breaks, right? We can carry water, it doesn't need updates, the vendor can't make that bucket retrospectively no longer useful. But with smartphones, we see these kind of issues. It's much easier to make a bucket by yourself than it is to make a smartphone by yourself. So the power to make a sovereign smartphone is greatly diminished for us. And of course, we can repurpose a bucket to do whatever we want, you know, whether that is using it as a helmet with eye holes or to carry cheese instead of water. Like it doesn't matter, we can use these things as we want. Whereas with mobile phones, we find ourselves to varying degrees trapped in sandboxes, particularly critical as we know on the iOS devices, but even on Android, you know, you need to root the phone to be able to do certain things.  And then likewise to be able to innovate to make a better phone or a better bucket, this is worlds apart in terms of what we're actually able to do. So this hasn't always been the case that in the early days of computers, they were largely digitally sovereign.  You could buy books that had a disassembly of the entire operating system. And, you know, Commodore didn't sue anyone for doing that because they knew that it would sell more units if people could do more things with the computer. Now, of course, things have changed quite a lot. That partly the growing digital economy and these concentrations of power that's created, that these large companies say, well, you know what, we can make more money if we actually control the way people use things. And that invariably means also restricting what they can do. And actually just the complexity of the devices makes it hard for us to actually be sovereign over them. Again, you know, in theory, you know, I've got a Fairphone 2, so it has an open source operating system version available for that. And I could hack on that. And indeed I can if I want to. But the effort required to do that is actually tremendous. The learning curve required is tremendous. For most people, that's a power they simply cannot in practice exercise. And so this is the problem. And then we have the related issue around planned obsolescence that, you know, companies want to sell new stuff so they don't care about maintaining old product. Why would you spend money doing that when you can be making a new product and making it so that's better and people want to buy it? And you might even go so far as to restrict even further the ways that people can use the old device and give various reasons around that. And there is, you know, this saying from Microsoft that for them, for many years, their greatest competitor was actually the previous version of their software. And so these behaviors can be active or passive, whether they're trying to do these things. And as I say on the slide, this is very naughty behavior, indeed, if we actually want to be able to let people own the things that they have paid for. But again, I think that actually is second fiddle too, this problem that it is the complexity of modern systems that really, really undermines their sovereignty or our power of sovereignty over them. That the more complex something is, the harder it is to even know where to start to be able to make any changes. And so there's this huge effort required, you know, for example, take Android again. If I wanted to maintain an improved version of Android for my fair phone, I would probably need about 10 of me working on it near full time to realistically keep up with that in any really effective way. And, you know, this is even worse if I wanted to actually control a baseband radio in the phone. You know, I can't even get documentation on that. And so, you know, if we want to make fully sovereign mobile devices, we need to change the way that we're doing things. And as I've been reflecting on things, and as was said earlier, that we're making this Mega 65 retro computer, and I'm also leading the server project, that it occurred to me that if we can actually get the simplicity of the 1980s home computer era to be the controlling piece of the phone, we can actually break apart the complexity and restore the sovereign power over the device as a whole. And we'll go on more in that and so then what actually makes it so hard to make a mobile phone? If we want to make fully sovereign ones, we need to understand what the challenges are. The first point really is actually making something that is that small and electronic. You have these tiny circuits and it's just it is simply hard and expensive work to do. And then, you know, how do you connect the devices together? There is a whole bunch of complexities around how that works. But it gets worse. The software is actually really hard to get working. If you make a device, you go, okay, right, I have a new improved phone that has something that I want on it physically, and now I want to, you know, support Android or some other operating system to it and maintain that. This is hard work. And, you know, I love what Fairphone are doing and I love what Purism are doing and I hope they keep on doing it and continue to grow in their capability. But I think both of them would, if we were to ask them, agree that it is a lot of work to maintain a port of Android, let alone to add new features in or indeed of a whole mobile operating system, whether it's Android or not. And then from an open perspective, again if we want full sovereignty, we actually want to be able to trust the hardware. We want to understand how it works. We need to have a mobile radio that we can actually trust and use in a sensible way to protect our privacy. And this basically is impossible to do. And then the cellular network is a piece behind that. We don't even control that. If we want to have fully sovereign mobile communications, we actually need to be able to replace each of those components. And this is no simple task. And as we basically said already, that even if you can achieve this, that maintaining it actually for a single person is basically impossible. So if we want individual sovereignty over our devices, we need to dramatically change the way that we design and make these things so that the barriers to entry are reduced that a determined individual can say, I want a phone that has some characteristic about it and actually create that. So before we go further, just a quick note. As we've already mentioned, from Purism to Librim 5, and there's a bunch of others as Wi-Fone and things there are, I am so glad to see that there are all of these other projects around open mobile devices with varying goals. And they're different things. I love the diversity that that brings, and there are fresh ideas coming from all of them. So I don't want in any way to discourage those projects or talk them down. On the contrary, we all need to be chipping away at the castle walls if we actually want to get to the point of freedom again with this. So I started thinking, how can we do this? And I thought, well, let's actually turn the whole planned obsolescence thing on its head. If you make something and you try and have it current all the time, indeed it's going to get obsolete very quickly, you have this maintenance problem. But what if we can actually start with something that is simple and by modern standards totally obsolete. In our case, it's an 8-bit computer platform, and work out what we need to trim down in order to actually make something that can work on that kind of simple system, and yet still remain as useful as possible. And because we're working on the Mega 65, that was a logical thing for us to do. But also, things like the Commodore 64 demo scene and game scene are actually still active. People are still working out how to push the limits of what should be a very constrained system that's not capable of doing a great deal. And in fact, it instead can actually do a lot. And so we have actually confidence that we can do interesting things with that. Indeed, at Linux Conf in January, we gave an entire presentation using a different prototype of the Mega 65 with its own slide software that we had a student write in a semester. So we think that this is possible to do. So here's a couple of slides on how we built a previous prototype just to give an idea of some of the thinking that we're trying to do around this. So your regular mobile phone is like the part of the top there. Everything is in one horrible insecurity domain. The cellular modem can often do horrible things to the CPU directly, whether the CPU even can notice them or not will depend on the architecture. And even if we sort of say, well, maybe that's not true for all chipsets, we can't prove it for any particular chipset without a huge amount of effort, that we simply cannot trust the devices because they are too complex for us to be able to determine what the architecture is in them, let alone to be able to do anything in that. So our approach instead is to break it apart and not just for the cellular modem, but we can have other things like a Raspberry Pi as a compute module that can run Android natively as a servant processor, a slave processor of what is effectively a Commodore 64. And we can make sure that that doesn't have direct access to the microphone, doesn't have direct access to the speaker, so that we can really quarantine that and do encrypted phone calls, all of these sorts of things if we want to in a way that we can actually be much more confident about the security of. And because it is so important for mobile phones, this whole thing of how we do the audio path and protect that from malicious devices is really important. So in the Mega 65 and the megaphone that we're building around that, we have this audio crossbar mixer so we can actually control every input and every output from the two and from the cellular modems to the speaker, the headphones, Bluetooth, everything, so that we can limit the clear text audio path to only where it needs to go. It also means that you can use Commodore 64 music as ringtones or play it as old music to someone on the phone if you want to because we have full sovereignty over the device. So this started then boiling down in our thinking to, you know, basically turning the whole idea of having a management engine on its head. If you think about modern complex CPUs, you have a reasonable degree of sovereignty over the main part of the CPU, the application processor. What you don't tend to have sovereignty over is the management engine in whatever form it takes on different architectures. So what if instead we actually say, well, we can't trust the complex processors, but we can trust the 8-bit machine, so we'll make that be like the management engine. So we're nominally calling this the little brother, and so that separates all of the components and lets us control what we want to do. Let's just do things like use a complete Raspberry Pi running Android because we can quarantine it. We could even actually virtualize its access to storage so that you could have multiple instances of Android and choose between them that can't contact one another. And of course the cellular modem, but we could have all sorts of other components. And because that connection between them is actually managed by an 8-bit computer you can program in basic, the barrier to entry to integrate that together is actually dramatically reduced. And of course it has the other side effects that we can boot it in under two seconds and you can play fun games while you wait for the cellular modem to actually boot up for you to be able to make a call. You know, again, you have full sovereignty to do what you want with the device. And by generalizing out the interfaces, so if we use the SODIMM form factor Raspberry Pi, it can be removable. And if a new version comes out, we can switch to the new version without us having to rebuild a huge effort for the capability. Likewise for the cellular modems, we can upgrade. So the current prototype that I have here currently has a single 4G modem. We have two bays, we could put two 4G modems in, or when a 5G modem comes out, we can put it in. And it's the industry standard mini PCIe form factor for cellular modems. And we've got the coupling quite loose. There is a digital audio interface, it goes into the crossbar and that's again industry standard. And then it's the UART interface with AT commands and you can do data over that as well at reasonable speeds. So that again, we have these things really separated so that they cannot interfere with one another. And for the cellular modem or the Raspberry Pi to have malicious software that tries to hack the Commodore 64 little brother piece of it is going to be really hard to do. And besides, it's very hard to try and hide malware in 64 kilobytes without someone noticing that there is a tiger under the rug, so to speak. And we can do other things with that, so we can have Genlock for the video so that we can do overlaying of the two together in nice ways, a whole pile of refinements that we can do around that. It also means that if you would be really paranoid at any point, you could actually take out all the untrustable components and be left with only the trustable core of the machine to do some sensitive actions. And like with the Librim 5, we have physical hardware switches to be able to turn things off. So again, we're talking about having a device which is, you know, that you can have sovereignty over. So I've been quite sovereign over the design of this. It has a bunch of features that probably half of them nobody else wants to see all together in a phone at the same time. So maybe they would like to have these two bays to put different radios and things in. We've put four microphones on there so that we can experiment with doing background noise rejection in a really nice kind of way, because I read a cool paper about it and thought that would be great. So, you know, $2 a piece, throw them in the design. We've put a full-sized SIM card and smart card reader in there, partly because I thought it would just be fun to be able to use a full-sized SIM card like on the really old Nokia phones, since we're talking about an 8-bit computer the size of a house brick. But also, we could actually make, if we wanted to, an electronic point-of-sales machine with the banking card reader in there, because it's the same physical interface. I like to play the old Commodore games, so I've put a 100 decibel capable 2-Watt speaker and amplifier in there so that it can do as loud as we want. We've got Bluetooth and Wi-Fi and a joystick plug, so we can actually use real joysticks again. You may not want this on your phone. That's fine. You can make it how you want and without a huge amount of effort. And because I do work with humanitarian sector, we want a device that we can use in the field for several days without being recharged. So let's put a huge battery in it and the entire back surface will actually be a solar panel with sort of between 5 and 10 watts of capacity. And because I lead the several project, I wanted to put mesh capable radios in there, so we've put tri-band laura in there that can work around it, and we'll talk a little bit more about that at the end. And so we could make totally different things. We could make a field hospital unit based on much the same hardware, but we can put the pulse oxy reader that goes in your finger and checks your heartbeat and blood oxygenation. We've already talked about having a point-of-sales machine or field data collection for disaster zones. There's a whole bunch of things that we can do. One more that's actually got me really excited is by effectively virtualizing an Android implementation's access to its peripherals, its physical interface peripherals, we can make a platform that makes it super easy to make smartphones that are customized for use by people living with disability of different kinds. So some people might be able to use a joystick because they only have gross motor control, but not a touchscreen. We could have that actually pretend to be the touchscreen to the Android without having to touch a single line of code or even recompile Android. So all 99% of the complexity has now been shoved out the way. Some code in Commodore 64 basic or assembly language is all that needs to be maintained to make the touchscreen interface, and so a person with disability could actually even iterate over that progressively to make it better for them without even having to come back to someone else for help. That has me excited about bridging the digital divide and doing great things with digital sovereignty. But the last five to ten minutes that we have, I want to talk about the challenges around having packet radio enabled phones so that we can make infrastructure independence with these digitally sovereign devices. So some other phones already in theory have this capability. You can plug a thing in the USB at the bottom, but that's annoying. The Fairphone 2 actually has pads in the back that you could make a thicket case that had an extra radio and things in there if you wanted to. But again, you have this whole problem of the complexity of the system, the effort to maintain the integration even if you managed to compile it and just not having the right size battery in these devices. So what we've done with the Lora radios for the moment, and we can do with any other radio that we want, is these connect via the little brother, the Commodore 64-like implementation, and they can even actually keep working when the FPGA is off to save power because we can independently control the power systems in there. They can do an interrupt that wakes the FPGA up to process packets if we have need to, and so it can be quite energy-efficient and do a whole pile of interesting things, whether it's at the protocol level or software-defined radio. There's a whole bunch of things that we can really do. And we just kind of hop through so that we've already covered the bulk of that. So I just want to talk now about some of the physicals and the legals around how we can try and do this kind of peer-to-peer telephony with a digitally sovereign device because, of course, on mobile phones we're really limited in what can be achieved, but with this actually the world is open to us to how we want to do it.  What it has is a liberal license that lets you use it in really nice and reasonably sovereign ways with respect to other people trying to use it as well. Unfortunately, there's no single global band, and even in the regions that are meant to have harmonized regulation, this is not actually the case. And, of course, in Europe, you're actually particularly bad at the offers, I understand. You've got this teeny tiny bit at 868 megahertz and a little bit at 433 to 434, which I think has horrible duty cycle restrictions on it if you want to transmit it any sensible power. In Australia, where I live in the US and a few other countries, we're a bit luckier. We've got anywhere between 5 and 25 megahertz around 900 megahertz with one-watt EIRP or a four-watt EIRP in some jurisdictions, and that's much more useful. But, again, with a sovereign device, we can put all three bands in. It's not that expensive to do, and we can get creative about how we can use those in ways that are consistent with the social license around that and do really interesting. So we want to use GPS to work out which band to use and what particular rules apply, but not having to have it get permission from a central database because, at that point, you've lost your sovereignty. So we want to allow that, and we've talked a little bit about that. The 900 meg band in the countries that have it is actually really nice. You can get multiple kilometers even with a quite simple waveform, and with laura type radio you can get tens of kilobits over kilometers to tens of kilometers. So this is really interesting for trying to make a useful localized mesh network that could span quite a distance. So certainly we would have no trouble if we had it available here on camp from end to end with a bunch of people using it with carefully designed protocols, and that's another piece that's beyond what we have time to cover. And so also the 433 band, we've talked a little bit about that already. What's interesting is that this is now more available globally than it used to be. There seems to be a desire to allow import of European targeted 433, 434 megahertz band devices, so Australia actually recently allowed their use with particular restrictions that don't line up exactly with here in Europe. And it has a nice advantage that as we push down in that UHF band it gets a little bit bendier, it goes around obstacles a little bit better, and it tends to carry further with reduced loss. But my understanding, and you guys will know better than I do, that here in Europe it's still reasonably congested, and that those restrictions with the duty cycle are particularly limiting in practice. But again with a sovereign device, as the regulations change, or if someone licenses a band, we can actually make use of them. We're not limited to a defective vendor's implementation that is overly paranoid about the use of bands and duty cycle, or maybe they've just implemented the most horrible, narrow common set that works in all jurisdictions. An 868, similar kinds of problems to 434, because I think it's only a quarter of a megahertz wide that's practically usable and is quite congested once again. But we don't have to stick with those bands, depending on what you're trying to do, there can be a bunch of different options available. So there are some legacy bands like Citizen Band Radio, it depends on your jurisdiction, whether you're allowed to do digital over it, and if you are, what waveforms and duty cycles and things apply. But it often gives you quite a number of channels, and again down at the 27 megahertz kind of band for the old VHF CB, this is really quite nice and bendy and will go in many cases sort of around a hill or two, and can be great for hooking people up in remote areas. And even the UHF CB ranges can be quite decent and often these will have much higher transmit powers. So whilst your data rates may be lower, it may be more practical when you actually try to use it to get communications over long range. We're thinking the target kind of applications is text messaging and small file exchange, not full on live voice and things. Although again with work and a sovereign device, people can explore that space and try and push the boundaries.  Depending on where you're trying to work, this can actually be quite cheap. So we do a lot of our field work in the outback in Australia where the spectrum has practically no value. No one wants to license anything other than the main cellular bands. And so for a couple of hundred dollars a year, we have in the past and can easily again license quite a nice slab of UHF frequency, possibly even down to VHF so that we can get really long range. But again with full sovereignty, we can do even crazier things if we want to. We could actually tie in HF radios in a hybrid kind of network. And this will be looking at with a several mesh as well, so that we can choose the right kind of link for the right circumstance and actually make a whole infrastructure that for communities will allow them to communicate even over long range. So with HF, we could hook up islands in South Pacific island nations, for example, who currently have to depend on satellite phones or literally getting in a boat and going to the next island. But also because we're making a fully sovereign device, we could do software defined radio if we want to and FPGAs are great for that. We have an FPGA implementing the little brother. So this could be done. And again with some care and distributing updated bit streams via all of these same kind of communications protocols, we can even update in the field in near real time the capabilities of the device because we have the sovereignty over. We don't have to wait for the vendor to decide whether they even want to help us solve a humanitarian need. We can just get out and do it. So as we start to get to the end, there's all these different barriers. The whole protocol area around this is still an open one. There's been a lot of great work on mesh communications and peer-to-peer and delay tolerant. What I would say is that with this kind of system, the best place to start is actually with delay tolerant communications and things like text messaging that has high value and really can facilitate useful interventions and capabilities for people, but without being so complicated to implement in a robust way that can work on these kinds of bandwidth constrained networks. But this isn't to say that people can't work on new protocols that continue to push the boundaries. And again, if we have the freedom to innovate the radio and be able to try these things in the field so that we can really rapidly innovate without permission, then I think we can actually do a whole lot more. And so for us, we're going to look to port the several rise and delay tolerant networking protocol to this device. We have the Lora radios and to see what we can do with that. So in conclusion then, I really just want us to reflect on this whole issue of the digital sovereignty that we have lost, but that I think we can actually reclaim, that with carefully designing these compartmentalized architectures and having the piece that binds it together, the one ring, so to speak, but instead of binding in darkness, that you can bind us together in the light to be able to do great things, so long as it's simple enough that everyone can learn how to use it and adapt it and make it better. And to demonstrate conclusively that we can remove these barriers, I mean we've made this device, I reckon it's cost us 500 euros give or take from scratch in hardware and it's been myself and two or three students over a span of less than two years to make a device that we can carry around and that's capable of making encrypted phone calls if we so wish. So we're confident that this can be done and we would love for others who would like to even just replicate what we've done or have different ideas about how it should be done. Again, we want to emphasize the sovereignty angle and to work with us to really bring this to be a reality and to help people who can benefit from it and just break up this whole problem of lost digital sovereignty. So at that point I will stop and I'll be delighted to take any questions that people have. Okay, we have about 10-ish minutes for questions, so there should be some microphone angels jumping around, I can't see anything from the stage, but make yourself visible to them and beautiful things will happen. While we wait for this, could you maybe just hold up the megaphone? Yeah, sure. Because I feel like I couldn't really see the size. Yeah, I mean this is what we've just built in the lab, so it's laser cut for the different layers for the case, because that was easy, but you know, it's a nice adult size, game console size, and we can easily reduce that size down. Again, it just takes effort to work on the different pieces. Now I thought I saw a hand back there. Yes, could we go there please? Okay, we have someone ready with a question. I saw someone. Okay, yeah, this thing's on. You've talked a lot about the capabilities and all of that, but not really much about distribution or fabrication. Is this something that you can get a kit for, or do you need to like make the PCB yourself by all the parts, etc., etc.? Okay, so at the moment we don't have kits. We're not at the point of having a refined PCB that you would even want to build yourself. We hopefully will be at that point in a few months. And again, these are all areas that we would love to have the community work with us to make it reproducible in the first instance. There will be some effort and learning curve initially, but then we want that to vary rapidly. We know that it can rapidly tail off so that people can buy a kit or even buy a complete unit. What's interesting with that is with the Mega65, the desktop retro computer, is that we actually have a path to market outlined around that. And so we could actually leverage that to simply sell this as a game console to make enough scale of economy to start doing more interesting things with it as a platform without people even having to build a kit themselves. So do you have a website or a GitHub? We absolutely do. If you go to the Mega65 website, mega65.org, there's a feedback form and you can just basically, that'll contact me directly. Or hop over to GitHub slash mega65 and there are some repos there. Okay, thank you. Do we have a question from the internet? Is there a signal angel in the room? There are no questions from the internet. Okay, internet, ask some questions, please. And now, please, another from here. Hello. First, thank you for making this great idea possible. I have a question. I have seen that you are planning to do encrypted phone calls and using some public frequencies in WeJF, VHF or PMR and possible. Unfortunately, the law in Europe in all the countries as far as I know in the US restricts the use of public non-commercial frequencies with the condition that no form of encryption or voice crumbling even is possible for analog and digital. Yeah, so this varies by jurisdiction. But there has to be gap in that because on Wi-Fi, which is one of these publicly licensed frequencies for 2.4 gigahertz, we're all totally allowed to do HTTPS, which is encrypted. So yes, we need to look at the laws and find out what is possible and what is not. One of the other things that we found that's really interesting is that in most countries, one-time pad is not restricted because effectively it's one bit encryption, one bit per bit, but the keys are only one bit each. And so if it's known people you want to communicate with, it's quite easy for us to have a secure physical one-time pad on this device that these untrustable components can never get access to, but the little brother can mediate access to. So there's a whole bunch of interesting new ways that we can do this that can really give secure communications and in a way that's consistent with national law. I fully agree, but I just wanted to point out that in some countries like Slovak Republic, Czech Republic and so on, the wording specifies any form of it's just a simple sentence. So I will be really happy if this will be possible. Yeah, and it would be interesting if the law is that straightforward, it may be worth someone challenging on the basis that clearly HTTPS is a form of encryption and you don't mean to exclude that. Thank you. Okay, what about the internet? Still no signal? No questions. Then please continue. Yeah, well this is an amazing project actually. I'm glad somebody took on on this idea. My question is, as far as I understood, you could be able, instead of using an 8-bit platform which can be trusted, you could put your knowledge into an FPGA IP core and gain more processing power or put in whatever you want. This is an excellent point and we've already done it. The 8-bit processor is all in an FPGA. We've implemented the Commodore 64 and actually the Commodore 65 prototype system that was never commercially released and it actually extended that a little bit. We can run at 40 megahertz instead of one.  And so all of these, this thinking is fantastic and the more that want to pitch in and work with it, we'd love for that to happen. You were great. Just one question. You did a lot of field tests, as far as I understand. What's your working background, you and your colleagues? Okay, so I work at Flinders University and I teach computer science, networking and security and so the field work really is around the several mesh which is around disaster communications. We work with Red Cross, World Food Program and a bunch of organizations. I'm happy to talk to folks about that anytime on campus as well. Cool, thanks. All right, next question from the room I guess, if the internet is silent. I was wondering what was the freedom status. For instance, what FPGA toolchain you use or will all the software be free software on it? Yeah, okay, so this is an area that we would love to have some help with. The FPGA we're using is a Xilinx FPGA and we're using at the moment the proprietary toolchain. I don't like being stuck in that situation. So we would love for folks to be able to nibble away on that part of the problem and find solutions and even open silicon would be fantastic to do if we can get to that point. I would love to reach that point but at the moment we're busy solving all of the other problems around that to actually make a working phone that people can build their own of and compile within an hour and do whatever they want with it. Maybe with an ECP5 you wouldn't have the toolchain issue for the FPGA. Yeah, look and so again we would love to use some of the open toolchain FPGAs. We need help to do the porting because we're flat out doing all of the other bits and pieces so we'd love your help if you want to. All right, do we have another question? Well, okay now we can also do questions in German for interesting reasons. Is anyone else has a question? Does the internet have a question? Okay, I do actually have a question. So in the end you were talking a lot about bendiness of the signal. Can you say something more about the physics behind that? Yeah, okay so basically the longer the wavelength of a radio signal the bendier it is and conversely the shorter the wavelength the less bendy it is. When I say bendy this is of course a highly scientific term for getting around obstacles. Okay, but how does it bend? Deep physics, electric would be possibly a better person to answer that in detail.  If you make little ripples that have a short wavelength let's you see they don't bend anywhere near as much it is literally the same thing happening just with atoms instead of water sloshing around. All right, very cool. Do we have another question? It can also be even more physics-based for the physicists in the audience? No? Okay then please give us a warm round of applause. Thank you and of course if anyone wants to catch up and have a look at the the phone or the desktop mega 65 prototype that we've got here or just otherwise catch up. Yeah come grab me. We don't really have a fixed spot where we're hanging out but you know my mobile number was there at the the beginning if we just hop back momentarily. In the meantime two toilet-related announcements wash your hands don't steal brushes. Thank you. Yeah okay thanks.


Hey guys, welcome to Andy Elliot's YouTube channel the number one objection that I get from automotive sales Professionals new in the business or that have been in the business for a while that haven't managed their money Is that they're broke and they don't feel like investing in themselves is a smart thing to do So what I want to do is I want to take you into the lion's den come with me I'll show you our lion's den our automotive training facility for our people follow me right here I'm Sean Pollard. I'm gonna leave the way for a minute. I'm gonna introduce you to a few of my guys Let's see if we catch them off guard, but I'll I gave them all A piece of advice when they started with me because they all said the same things. Hey Sean, I'm broke. I don't have any money I'm broke. I'm on empty. I don't know what to do. Everybody at my dealership makes fun of me that I'm talking about investing with Myself with either the hot the highlights earners in automotive that now work for Andy Elliot. Let's get their take on this What's going on guys I call this guy the Sandman we have nicknames for each other because he's a wrestler But I first met Danny He was selling Chinese food or just getting into the automotive industry from selling Chinese food Nice, okay, I remember you had what 1500 two grand in the bag.  I'm broke. I'm broke. Yeah.  Whoo. That's what I'm talking about. We're not done yet This is right, this is Ryan Rasmussen, right What's going on everybody I love it this guy big old mountain of a man Do you know why immediately guys don't like him because he's so good-looking stand up man So come on big you are look at this. You're gonna make me blush Immediately side this guy up and he's so good-looking just like I don't like this guy Dude, he's a good heart and man, but did I coach you in the beginning? Yes Yeah, you're my coach. What did you tell me when I got you to invest in the seminar first and foremost? What did you say to me? Honestly? I was like I'm broke. I can't afford it I was broke. No money dude can't come What was my advice to you to fix your broke state honestly Sean told me quit drinking beer quit buying beer quit Going to the bar Ryan I ended up saving a couple hundred But well actually the price thousand dollars a month and then spent the money and did some training with Sean Change my life quit drinking beer, baby Still bus Chris up cuz Chris is one of our top coaches now one of the highest earners in our company 42 years old We first invested yes, you first invest in Andy I reached out you reached out.  I don't money all of my advice to you so He literally looks at me and he goes look. What's the difference man? You're either broke with regrets in your life or you broke with skill. Which one do you want to be? I was like Well, that's a no-brainer man If I can require if I can access the skill to go farther in my life or be broke I mean, you're not gonna make any more money being broke. Yeah, so what's you gonna choose? He took me on a journey nine months later guess where I'm at Come on buddy. You guys this is the Elliott group. This is what we do We've all been broke two and a half years ago when I reached out to Andy I had come off a very tough time in my life personally with my son I was broke I leveraged the money I flew to Oklahoma now We're here in Scottsdale Arizona the journey is what you make of it The money is nothing more than a tool to leverage to make more money I don't know any millionaires and I don't know any billionaires that save their money To become a millionaire or billionaire money is used as a tool to leverage to make more money That's what you're gonna do with your money So if you're broke and unempty reach out to the Elliott group reach out to one of these coaches They'll take you on a journey will help you go make that money and in return Will you invest in yourself to go to the next level grow and scale and become someone new? That's our intent. That's our desire. We want to see you scale So this is the Elliott group you guys want to check out the conference room should we do that that good I'll tell you the inner den What this is all about what this is built not about of industry has any Elliott all over it We're in six thousand stores We have three hundred and fifty thousand automotive self-professionals training with us now And it's a movement two and a half years ago And he made a decision to take his broke mindset from being a GM making millions of dollars And he bet on himself to go stop what he was doing And start a training company Then you have the wisecracks. Oh if you so good, why would you start a training company? Those who can't do train those who can't do coach. That's the man when you're earning the type of money that Annie's earning He wanted to get back to the people. This is our automotive training facility. This is the closure of Lance room This is where we meet for dinner the night of or the night before and right here Hope the story is open for you guys. We have our seminar the lion's den come on in This lion's den holds 300 men and women and every month This seminar goes live. We get crazy. We get passionate. We're here to serve you at the highest level This is all for our people. So if you're broken on empty right now Chances are if you do nothing, you'll be like 98% of the world that stays broke their entire life because that's a mindset shift It's a saying that 2% 2% will go out and surprise the world 2% Are you part of the 2% that are gonna watch this video? Are you part of the 2% that come into this room and change their lives forever and dominate the game and make their Names known or are you gonna be like the 98% of the world that does absolutely nothing and lives a mundane life? Thank you for having me man. This is Sean Paul and welcome to the lion's den my brothers and sisters hope to see you soon


It can be annoying and they're very expensive to rebuild these days. Just the great news of the day, Tony Quinn is back in. If you have been following the event, you would know that this Lamborghini was parked in a paddock looking to side of his second hand a couple of days ago. He vowed to clean it yet back in and he's back in today, Friday. 160 K's of specials today, six special stages ending in Cromwell overnight in Tony Quinn's backyard.