WEBVTT 00:00.000 --> 00:09.480 Good. So it's always a little bit of a challenge, then you have a long day, and this 00:09.480 --> 00:13.480 was a track that was completely filled at the end of the day. It is still a five o'clock 00:13.480 --> 00:16.920 in the room. You're sort of not emptying out, but actually filling back up. So thank 00:16.920 --> 00:24.560 you to be here. Well, I think to this morning's keynote, and also a resoundist talk basically 00:24.560 --> 00:30.240 very clearly stated in a why we're here. We'll be looking for another way, but what 00:30.240 --> 00:33.800 is the way we're going to go in actually making it real? It's not just a technology 00:33.800 --> 00:37.000 challenge, and I think we're sort of really highlighted as well. It's really sort of a 00:37.000 --> 00:42.520 people challenge. And when we like to know that we are sort of notty, we are a different 00:42.520 --> 00:49.760 fuel in the world, right? We know that this open source is out there. But in my career, I actually 00:49.760 --> 00:54.600 found a lot of people that have no idea. They believe this world doesn't exist, it's 00:54.600 --> 01:00.440 for like a parallel universe, which is very interesting because there's so much power 01:00.440 --> 01:04.480 and opportunity in here, but most of the years, it's not that they don't want to, but 01:04.480 --> 01:08.960 it just don't know. It's not something that's being exposed towards. So we are definitely 01:08.960 --> 01:17.320 on a mission. I say, my partner in crime, he's a Danish citizen, he's a Danish, he's going 01:17.320 --> 01:20.880 to the other track, he's at an XOX track, he's found some new friends. So I said, you're 01:20.880 --> 01:26.320 on your own, have fun, and I will hit the thing afterwards. So here I am. My name is Erik 01:26.320 --> 01:31.320 Mujbach. I'm from the Netherlands. My partner is called Lars Gosson, like I said, he's 01:31.320 --> 01:36.480 from Denmark. And what we are trying to focus on is, okay, let's make Cloud Shimpul 01:36.480 --> 01:44.520 again. That sounds like a great idea, but let's go into that. So it's sort of, it feels 01:44.520 --> 01:50.000 to me to an extent that we have lost our way. The model we know, and like I said, outside 01:50.000 --> 01:55.080 of this room, when you go to the other side, then people don't know, there's an alternative 01:55.080 --> 01:59.640 to Cloud. Not really. And when you speak about them, it's like, yeah, yeah, I hear what 01:59.640 --> 02:06.000 you say, but you know, but it's just so convenient, that EC and robust it just works. You 02:06.000 --> 02:12.720 even, IT people, I have to explain, that there are alternatives to the public Cloud or the 02:12.720 --> 02:17.120 hyper-scalers. Actually, the hyper-scalers are using most of the time, the open source 02:17.120 --> 02:21.920 software, but they don't tell it. It doesn't resonate. So that's really a sort of 02:21.920 --> 02:27.040 emission on them. So in order to do this, we made a decision. Lars stopped his job. He's 02:27.040 --> 02:32.680 a little bit more senior than I am, more older, more wise, I guess. But when I'm doing 02:32.680 --> 02:39.600 I basically am consulting with mid-sized SMB type companies in adoption of AI, my focus 02:39.600 --> 02:45.680 is really to actually have the local AI alternative. And when I'm working with those companies, 02:45.680 --> 02:48.600 most of the time this has, you know, they're really, but it's constrained as well. I had 02:48.600 --> 02:52.640 a lot of public organizations, but it's still very butchered constraint. And when I explain 02:52.640 --> 02:55.680 to them, well, you know, most of the things you can do, you can do it in an open source 02:55.680 --> 03:01.040 way. They sort of look at you there, yeah, you're right, you are. So there is still a lot 03:01.040 --> 03:05.720 of evangelizing to do that, and it's not really the way. And really, if we are refilled 03:05.720 --> 03:11.760 with them, well, where did the cloud come from? Once upon a time, we had the distributed 03:11.760 --> 03:18.080 structure. That's how the internet emerged, right? We did the internet was, indeed, virtually 03:18.080 --> 03:23.240 intended like an inter-connection of independent networks, and each network was self-contained, 03:23.240 --> 03:28.560 but benefits from collaboration. Like we are here as a human individual. When I show this 03:28.560 --> 03:33.920 picture, to most of my peers, and they're not out of the IT domain, the day they have to 03:33.920 --> 03:37.120 really, really, just like a flesh-to-memory lane. It's like, oh, yeah, that was right. 03:37.120 --> 03:42.480 There was an era before the cloud era, but they don't see that it's as possible. So 03:42.480 --> 03:46.800 from a very centralized model, the nice thing about it is there's a unified way to structure 03:46.800 --> 03:52.320 things, it just works nicely together. And we know the consequences of that. The alternative 03:52.320 --> 03:57.280 is more like the bizarre model where you have independent, very powerful elements, but it 03:57.280 --> 04:02.920 lacks that the cathedral, or structure, the unified unification. So the real challenge is really 04:03.000 --> 04:08.120 how do we get the power, the ease, and the efficiency and the robustness that we are 04:08.120 --> 04:13.320 so much liking on the left-hand side, and applying it basically to the world of the bizarre 04:13.320 --> 04:18.760 model. That's really what the core challenges, because people like simplicity, it just 04:18.760 --> 04:22.520 needs to work. And in order for people to actually do really make a jump from the left-hand 04:22.520 --> 04:27.000 side to the right-hand side, we have to sort of need them at that quality level. It has to 04:27.080 --> 04:34.520 be simpler, it has to be as robust, it has to be as efficient. And that's the real challenge, 04:34.520 --> 04:39.560 because all of you know, I think, when you work with open source, and I've been in a home 04:39.560 --> 04:44.920 level for most of my life, and it's so much fun until basically you have the real day jump, 04:44.920 --> 04:48.680 and then you see that you're at one version behind the two versions behind, so an imminent 04:48.680 --> 04:52.920 is really is the pain. It's not just standing it up, and oh, look, it's cool. But when the house 04:53.000 --> 04:57.240 is running on it, and I'm not at home, and home assistant doesn't work, I get an entry 04:57.240 --> 05:01.800 phone call from my wife. So that has to be as robust, it's critical infrastructure in the house now, 05:01.800 --> 05:06.600 because we've got a nice electronic house, it's the motica, but when the switches don't put 05:06.600 --> 05:14.680 on the lights, you know, it's a P1. So it's great to get started, and wow, why the magic this is, 05:14.680 --> 05:21.000 but how do you actually do it, and then at a company scale or at the public sector? So the 05:21.000 --> 05:26.200 barrier is literally complexity. It's basically, there are, there are many proof and products, 05:26.200 --> 05:32.680 and like I said, most of it, if not all of it, you can get us open source. But the integration 05:32.680 --> 05:38.200 challenge becomes yours, right? Because we don't follow the cathedral model, there's no unifying 05:38.200 --> 05:42.600 architecture that brings it all together. So if you want to have multiple packages, just being unified, 05:42.600 --> 05:46.840 and it all just works, and especially in the cloud area, you just point and click and it just 05:46.840 --> 05:51.240 operates, it gets up, but then on open source, that's a little bit hard, because there are so many 05:51.240 --> 05:57.160 packages involved. And let's say you nailed that problem. Then obviously the next thing is 05:58.440 --> 06:03.400 is that you have to operate it as well. So you did it once, but now the software is alive, and it 06:03.400 --> 06:07.000 is all integrated, and then you have to start patching it, and you have to make backups and 06:07.000 --> 06:11.480 restorations, and you have to update, but updates sometimes actually break the integration, so that 06:11.480 --> 06:16.440 the pleasant doesn't work anymore, which you were relying on, and monitoring the hardening, etc. 06:16.760 --> 06:23.080 And all of these products that are so powerful in their own right, when you build a platform out 06:23.080 --> 06:28.760 of them, it becomes very hard to do so. Because now a certain that whole cloud, hyperscale, 06:28.760 --> 06:34.040 the cloud experience, is basically is now lost. So that's why it makes people afraid to actually 06:34.040 --> 06:39.000 make the jump. So I think the one thing that the big five have really done is to make it easy. 06:39.000 --> 06:44.680 And that that model works, right, because some people, if you build an app, you will like to 06:44.840 --> 06:49.080 update the base, but the database needs to be patched, and there should be a backup, and that you 06:49.080 --> 06:54.520 have to have the HP as well for the networking, and file sharing as well, and certificates, and the 06:54.520 --> 06:58.200 NAS, and before you know, if you like our like this stack, then obviously you're actually in the 06:58.200 --> 07:03.800 plumbing layer. You're doing all the prerequisites before you can get back to your app. So that's 07:03.800 --> 07:08.600 what cloud offers, right, that the simplicity, that's it's all just there in just a point and click 07:08.600 --> 07:15.320 type of way. So that's the new problem we're solving, but we are an open social community. We 07:15.320 --> 07:19.880 will be thrive in the bizarre model. I got this great thing, and I'm really going to focus on that, 07:19.880 --> 07:25.080 and not thinking about the other parts. So how do we take the best of both worlds? How do we apply 07:25.080 --> 07:32.840 some cathedral logic to the bizarre model? So you get that platform that basically works to get 07:32.840 --> 07:40.600 nicely. And that in the end, in the essence, is what we're trying to attack with tapas. With TAP, 07:40.600 --> 07:48.440 PAS, it's trusted, automated, private, platform SA, self-hosted, surface. But tapas more than a 07:48.440 --> 07:54.840 colloquial environment like tapas, sharing is caring. That's easier, which is the audience we're in. 07:54.840 --> 07:59.080 So that's the challenge we're trying to do. So we felt like, you know, when we did it as home 07:59.560 --> 08:05.000 and we did it as a side job as a sort of rally, rewarding hobby, apart from the P1s at home, 08:06.440 --> 08:10.920 we really felt like there is no alternative because it's a real investment, it's a vested effort 08:10.920 --> 08:18.760 to get this done. The nice thing is that Lars has built clouds since his entire career. He's now retired. 08:18.760 --> 08:24.760 Officially, he basically, we all have, we both have had corporate careers, but we both retired for a 08:24.920 --> 08:29.640 reason. We wanted to basically do something with all the experience we got to say, right, how do we, 08:29.640 --> 08:33.400 how do we take the best we learned? Not only from a technology point of view or an architecture 08:33.400 --> 08:37.960 point of view and a home level point of view, but also the organizational change point of view and 08:37.960 --> 08:42.760 convincing executives that this is the, is an alternative, maybe even a better way. We said, 08:42.760 --> 08:47.720 right, let's sort of switch gears and let's figure out how to do so. And obviously, then you 08:47.720 --> 08:51.720 entering the whole new world and then a little selling you are looking for funding and then time 08:51.720 --> 08:57.400 is scarce, but it's really exciting. So, we're still going to go with it. So, that's why we created 08:57.400 --> 09:03.480 tapas as I said. Trust it, automated, private platform as a self-hosted service. The real intent 09:03.480 --> 09:09.960 is that everybody can have their own private cloud. And the dirty part, the get-ups, the fact that 09:09.960 --> 09:13.560 you know, it should just work point and click, that is basically what tapas is staying care of. 09:14.760 --> 09:18.680 So, that layer that nobody talks about, well, most of if you're, you are also for the 09:18.680 --> 09:22.120 developer show, when you know, you just think, the things that are under the, under the 09:22.120 --> 09:27.640 button, that basically is the tapas is really focused on, just the hard of it. Because if you just 09:27.640 --> 09:33.800 go around data centers and high-pascals and you just take a note that you look at the essential 09:33.800 --> 09:38.520 services are that they're running, that's not a huge army of it. If you take the high-pascals 09:38.520 --> 09:45.480 of the mention away from it, at the heart, it's not like 50, 80 on the services. The core is not that 09:45.560 --> 09:51.240 hard. If you just take that core, that everybody needs, but nobody likes to do, because it's 09:51.240 --> 09:56.520 the boring work. But once that core is there, then the fun stuff begins. And so we said, let's 09:56.520 --> 10:01.880 let us address that boring stuff, because we easily like to do that. So, it has to be open, 10:01.880 --> 10:07.080 and that means that it has to be ready to serve any workload. So, we deliberately went for a 10:07.080 --> 10:12.440 virtual machine type approach. Thank you. So, any workshop, a workload could be hosted, 10:12.440 --> 10:15.560 any operating system could be hosted, because it has to be as you lift and shift, has to be 10:15.560 --> 10:21.320 enabled for that. It has to be connected to the internet, but it should not be dependent on the internet. 10:22.040 --> 10:27.800 One of our first adopter partners, they have a subsidiary in Ukraine, and they did a disaster 10:27.800 --> 10:35.240 recovery analysis. This is continuity analysis out of the ISO 20771. And they said, so what is the 10:35.240 --> 10:39.400 sort of disaster we should be planning for? Well, the first thing that attackers go for is basically 10:39.480 --> 10:44.440 to issue shutdown, the digital infrastructure. Never communications, you shut it down, electricity, 10:44.440 --> 10:51.240 shut it down, because all of the disaster recovery procedures are on the server. They're not 10:51.240 --> 10:55.480 printed out somewhere. Most of them basically are maintained, and actually on the server. So, 10:55.480 --> 11:00.520 that's how you cannot assume that when there is a real disaster coming, and that you can access 11:00.520 --> 11:06.120 the emergency procedures, because you can't access the server anymore. So, okay, and it's basically 11:06.120 --> 11:12.760 the server for a central, even though it's highly resilient, then if that little place is not available 11:12.760 --> 11:17.160 anymore, then well, I can physically go there, but the buildings are there anymore. So, 11:17.160 --> 11:20.440 they said, well, you have to really think differently when it comes to real resilience. 11:21.720 --> 11:24.120 Which effect are you originally interested in? It was all about, right? Not that I seem 11:24.120 --> 11:30.840 more placed to failure. So, do we know the patents? Yeah. Have you lost our way? Maybe. 11:31.560 --> 11:36.920 So, let's go back to that. So, the resilience, right? It's just back up restore, and ready to go 11:36.920 --> 11:40.600 off-grid, and well, that doesn't need you powering the data sent, you're powering the sugar for 11:40.600 --> 11:44.920 egg. So, that's easier with the battery pack. So, there's more means to that as well. 11:45.800 --> 11:51.320 Sugar, sugar by design, otherwise people won't jump. If you're not complying to the relevant 11:51.320 --> 11:56.520 standards, then we'll use them. I don't, like I was saying, right? People don't trust you or 11:56.600 --> 11:59.800 with the German industry, with the batches. That's the typical question people say, 11:59.800 --> 12:03.960 well, when they understand these open source, those old questions are the typical question 12:03.960 --> 12:09.320 everybody asked, and with the government, but also within SMB companies, right? They still wanted, 12:10.200 --> 12:16.200 but okay, but now I'm maintaining it all. No. Compliance is like I said, open source, 12:16.200 --> 12:23.480 avoid left-handed looking. Well, scalable, both horizontally and vertically. So, we don't have 12:23.480 --> 12:28.840 the cater for the hyperscale size, right? If you just do it at a company or a municipality or a 12:28.840 --> 12:33.080 city mayor's office, you don't catering for hundreds of thousands of people, because the 12:33.080 --> 12:36.120 surfer that you're using is distributed anyway. So, they put in the part of the computers, 12:36.120 --> 12:41.560 they're distributed. You're thinking different scales. So, then to be scalable, although we don't 12:41.560 --> 12:46.760 affect at this point in time, we feel like that with modern hardware and resilience, structure, 12:46.760 --> 12:52.360 and the failover etc. Yeah, I don't think scalability will be a big problem, and also an affordable 12:52.440 --> 13:00.440 way to get around. And affordable. That's where it gets, it's a public sector or a private sector 13:00.440 --> 13:05.800 with SMB companies, they don't have a ton of money to run their data center. So, the harder it 13:05.800 --> 13:13.400 needs to be affordable. And we literally had a Danish partner, and the ITNUman said, right, he was 13:13.400 --> 13:17.240 looking for, I would love to do tapas. So, he's looking to the catalogue, and he was looking to the 13:17.320 --> 13:24.440 center, and then basically the high-end, surfer gate equipment. And we said, I really have to go to 13:24.440 --> 13:28.280 the CFO, and not sure whether I should go there at this point in time, because you know, this is 13:28.280 --> 13:33.800 this is a huge expense. I'm just talking about storage now for my team. And he said, yeah, 13:35.000 --> 13:41.320 but do you think that we're running some level hardware, which is 10,000 euros per just the 13:41.320 --> 13:47.320 storage, and then the rest comes out to it? Well, why not? And then we basically explained that with 13:47.320 --> 13:53.080 software, you can actually have very robust and resilient storage, and it's a compute with 13:53.080 --> 13:57.880 clustering, et cetera, that we own proshum a great hardware, you have to make some smart decisions, 13:57.880 --> 14:03.960 but it is the redundancies built in the so-called, not into the hardware. And we had to explain 14:03.960 --> 14:09.160 three times, because he could not believe what we were saying. So, then after the session which was 14:09.160 --> 14:16.280 in the Friday, on Monday, he called back, and he's been on the net the whole weekend. And he tested 14:16.280 --> 14:20.440 him himself again. He was sort of, I read doubting himself what he was seeing, and said, if you 14:20.440 --> 14:25.640 see a Vs and clustering, et cetera, they got so many ways that you can make things robust. And 14:25.640 --> 14:31.080 because the price so much lower by yourself and other surfer is still way cheaper than the enterprise 14:31.080 --> 14:36.360 level hardware. So, there are all alternative ways. And this was a person that really wanted this, 14:36.440 --> 14:42.520 but he had to sort of overstep his own convictions, I would need to say, to embrace the idea 14:42.520 --> 14:48.760 that for a different level of investment with the right selection of software, you could have the 14:48.760 --> 14:55.400 same or better level of the same level of resilience. And he actually said, well, I would 14:55.400 --> 14:59.640 lovely go to the CFO and ask for the budget now, because this is a completely different conversation. 15:00.200 --> 15:06.040 But so we have that to take to convince people. So, how do you build a cloud? Like I said, 15:06.040 --> 15:11.400 if you just go data set by data center and you take a note pad, you will see that at a 15:11.400 --> 15:15.800 heart, there are not that many services. It's not a full map, it's definitely not an architectural 15:15.800 --> 15:22.280 map, but like I said, Lars has been around this cloud a couple of times. So, we know the essence of 15:22.280 --> 15:28.520 that. So, drawing the picture and knowing how to relate, that's relatively easy. That's the simple 15:28.520 --> 15:35.400 part. We love to draw drawings. When I get so little bit harder, is to find the right 15:35.400 --> 15:40.360 applications to implement the capabilities. And then you wander and enter up in the wonderful 15:40.360 --> 15:47.000 world of the bizarre. There are so many different solutions for the same capability that it's 15:47.000 --> 15:53.960 like luxury, it's like a kitchen in a toy store. But it's not about the individual application. 15:55.240 --> 16:03.560 And with the German system, we just saw a little bit with the batches. You just go for the 16:03.560 --> 16:09.640 repost that are highly liked, the good support, the community support, high degree of 16:09.640 --> 16:15.000 combates, recent updates. So, you could do some filtering, but still in the end there are still 16:15.000 --> 16:19.880 quite some kind of dates coming up. And that's actually what we found much harder. And over the 16:19.880 --> 16:25.640 past five, six years, as home levers, we've been playing with this and learned the hard way 16:25.640 --> 16:30.840 that is not about the individual application, the individual product. It is really about 16:31.240 --> 16:35.960 the original incident, because when you start talking about it like, I remind you it's 16:35.960 --> 16:42.440 best, I know. I appreciate it. It really is about the integration. It's the composition. 16:43.160 --> 16:47.960 Because the problem we were solving is not to have to be the best building block, but actually 16:47.960 --> 16:53.960 to have the best integrated platform. That's what we're looking for. And when you start putting 16:53.960 --> 16:59.400 things together, and you really think about, okay, so I would like to rebuild a cloud-like 16:59.400 --> 17:03.560 experience, point-and-click. And when it runs at runs, you don't think about it anymore, 17:03.560 --> 17:09.160 so it's highly automated, it giddles. And it's self-healing, and it gets backups embedded, etc. 17:09.160 --> 17:14.920 All those things like, okay, so do other APIs. Can I inject the configuration into the 17:14.920 --> 17:20.280 application with an API or not? Can I automatically back it up? Can it be back to the same place? 17:20.280 --> 17:24.360 How do I do certificate management? How do I do it with credential, etc. Then all of a sudden, 17:24.360 --> 17:28.360 you notice that all of these packages are built with that in mind. And that's perfectly fine, 17:28.440 --> 17:32.200 right? That's those are design principles. But when you want to do something like this, 17:32.200 --> 17:37.240 that becomes extremely important. So even through, I think, four years of trying, and it's a real pain, 17:37.240 --> 17:41.880 because I'm running an open source router at my home, and then Larsten came up low. Let's 17:41.880 --> 17:49.000 fit the router. It's like, that's a weekend outage for me. So help me out here. And because I'm 17:49.000 --> 17:54.920 literally running this at home, and it's now clustered up, and we do local AI at home, and it's 17:55.000 --> 18:00.360 all flea backed up, and it's magic, right? It's like, wow, it's quite resilient. V-lans are in there, 18:01.400 --> 18:05.080 and most of my family doesn't have a clue what those are. But those are important. 18:06.840 --> 18:11.480 I'm seeing what the end-to-top has at this point in time, where I'm here, just to play with local 18:11.480 --> 18:15.800 AI as well. So, just to see where there's bricks, a little bit of a latency tell us, but it still works. 18:16.600 --> 18:23.640 But it's the integration that's freaking complicated. And maintenance of this is freaking complicated. 18:24.200 --> 18:29.720 And then, if you want to drop a workload on top of this, guess what? It is freaking complicated. 18:30.440 --> 18:35.240 So, what we actually solve thing is to make that part easy. So, how do you do, basically, 18:35.240 --> 18:40.600 you're your DevOps engineering, you're building your pipeline? How can we make it for workload 18:40.600 --> 18:47.400 easier to basically be onboarded on to tap us? So, let's fix the, I need to have a network IP address. 18:47.400 --> 18:52.280 I need to be part of a certain V-lans. I need to have my credentials in the authentication store. 18:52.280 --> 18:56.680 I need to make sure that I got the right certificate. So, I need to be part of the backup schedule, etc. 18:56.680 --> 19:01.480 Those kind of things, which are the boring, but important things, that is a top-stained care of. 19:02.040 --> 19:06.440 And, like, we've done, basically, abstracted all the details, and we are wrapping them in a sort of 19:06.440 --> 19:11.720 adjacent file. So, you just parameterize how big the VM should be. And then, you don't just understand 19:11.720 --> 19:16.040 how proxmox, which is the foundation of this, actually parameterize it. That's where you take 19:16.040 --> 19:22.360 if, just say, how big is the hard drive, how big is the, how many see virtual CPUs, and it just 19:22.360 --> 19:27.400 provisions it. So, yes, this is nothing more than building a pipeline and you're parameterizing it, 19:27.400 --> 19:32.920 but we're taking the engineering part out of that. Another thing to make this work, some people 19:32.920 --> 19:38.680 like it or not, is that we make some decisions. We are taking some of the flexibility of 19:38.680 --> 19:44.760 all those power products out, because the uses of this platform are not you guys. Those are people 19:44.760 --> 19:49.800 that are used to cloud and it just works. So, that actually means to constrain some of the 19:49.800 --> 19:54.600 predictions, to constrain some of the future decisions. So, that's why we actually like to avoid 19:54.600 --> 19:59.880 people to walk in with super user route access and try to think of themselves. You guys can, 19:59.880 --> 20:05.160 but most people can't. Because they, the whole the skill set about how to admin a platform like this, 20:05.960 --> 20:10.760 that's to an extent also vanished. And so, we said, right, we make the decisions. We make it 20:10.760 --> 20:15.000 robust, you press the button, it just always works updates. We will take care of the package 20:15.000 --> 20:19.560 upgrades, and then it basically on a pull-based model, the all the packages will be updated as well. 20:19.560 --> 20:24.120 The dependencies will also be managed. And a little bit like, that's what we have today versus 20:24.120 --> 20:29.000 it is on the road map versus one day maybe, but that's the thinking behind what you try to do. 20:29.000 --> 20:33.240 To make life easy, if you want to have a platform, the just works, it's now becoming available, 20:33.240 --> 20:35.960 and it can actually be in your basement. It's, it's that small. 20:36.360 --> 20:44.360 Also, life cycle management. And it was all life cycle management. That's really unique and different. 20:45.320 --> 20:50.840 The last and I have been part of a big initiative basically that defined an IT standard, 20:51.560 --> 20:57.160 how to basically do life cycle management of any digital product. Let's abstract away from anything. 20:57.160 --> 21:01.720 And that became the in the system. It's like IT for IT. You can find it at the open group. 21:01.720 --> 21:06.920 It's a privileged standard, a real standard. And what he basically is to do the release part, 21:06.920 --> 21:11.080 and the deploy part is what we think, and also the operate part, so the more entering it, 21:11.080 --> 21:16.680 that it was the packages all being done. But it's based upon the same standard. And we said, 21:16.680 --> 21:20.680 right, you know, life cycle management is life cycle management, guess what, is life cycle management. 21:20.680 --> 21:26.040 So it's coming very much unified. And this was based upon 10 years of people that have been doing IT 21:26.040 --> 21:30.680 for their career, going through between, you know, enterprise companies and smaller companies, 21:30.680 --> 21:34.680 and see what are the patterns and this came out of it. So the last thing is now, 21:34.680 --> 21:38.280 the large cycle thing we got on the control. So we don't have to implement endless 21:38.280 --> 21:43.880 the variations on this. Yes, the the product is different. But what we have to do is quite the same. 21:43.880 --> 21:47.880 And with top as we are trying to add another layer that it doesn't really matter what product you have, 21:47.880 --> 21:54.280 as long as you sort of are within the the top as a wrapper, we can basically do most of this automatic. 21:54.280 --> 21:57.960 Because and that's the way the work is. If you got your application, 21:58.040 --> 22:02.120 you want to let it on the top as you have to start basically embrace the API. But the API is 22:02.120 --> 22:07.880 like a JSON file and make it really simple. And then all of a sudden this starts working for you. 22:07.880 --> 22:12.040 You don't just to make it any more. As a group. So this is essential. 22:13.640 --> 22:19.080 Then scale. We first thought that the original idea came when when last had too much time 22:19.080 --> 22:24.760 in a sense, we liked to do the Danish communes and to have a small server and it may help people 22:24.920 --> 22:29.160 to be more resilient. But then I said, well, you know, I got that at the home. So let's 22:29.160 --> 22:35.880 re-implement my atom server. It's been pretty old, but it still works. So I have a single note 22:35.880 --> 22:40.760 machine. So a single note and a standard machine we actually have it is a two note. So two 22:40.760 --> 22:49.480 servers. We recently bought a mini forum which has 128 gigabytes of memory. And if you do local 22:49.480 --> 22:54.760 AI inferencing, that actually is very important. So my cluster is now an atom on the one hand and 22:54.760 --> 22:58.760 a mini forum in the other end and they're closer together with proxmox and this prox and backup 22:58.760 --> 23:06.120 server behind it. And it just works. It's my son lost his game PC because I wanted to do some 23:06.120 --> 23:11.240 local AI inferencing. And that's not also running in proxmox. So and that basically is what's 23:11.240 --> 23:16.600 powering most of my work now. But we migrate into our similar ecosystem. But the company basically 23:16.680 --> 23:21.720 they're building some pretty decent server wreck servers. And then it's over and you just scale 23:21.720 --> 23:27.400 out in that regard. And they're planning to do a hundred people enterprise. So the difference 23:27.400 --> 23:31.240 we have been thought about what is the minimal set and how do you make the the boot drive 23:31.240 --> 23:35.320 resilient and how big should it be? And all those kind of things we got it like yes, no, yes, yes, 23:35.320 --> 23:39.960 yes, no, yes. So if we notice doing it, it's still so manual working it. If you go to the repo, 23:39.960 --> 23:45.720 you will find that the first proxmox setup is still a lot of follow the manual. But once it's 23:45.800 --> 23:53.240 up and running, it just runs. So I I felt like I was talking about local AI and I'm not sure 23:53.240 --> 23:59.080 how many people are sort of into that at this point in time. But this amazing open source 23:59.720 --> 24:05.400 server that you can use for local AI and open web UI gives you really like a dare I say, 24:05.400 --> 24:13.000 a 70 pt like experience. It is as slick is unified. And the nice thing about it is that you can select 24:13.080 --> 24:22.680 any model above. So we can see here that I'm running via LLM. Some people had Lama CSP or Olamma. 24:22.680 --> 24:27.560 There are ways to do inferencing, which is the AI start stalking over the Lala models since this 24:27.560 --> 24:36.840 morning on your local GPU. So I actually selected this. This is running on the game PC at home on 24:36.840 --> 24:41.560 tapas. But I can also have a close source model. If you know what you do, you just select another model. 24:41.640 --> 24:46.520 But the nice thing is in the same chat you just flip over. And this is a promo talk for what I love. 24:46.520 --> 24:51.400 It's basically open web UI's amazing. And another thing that is really everybody's raising about 24:51.400 --> 24:59.000 is NITN. It's like workflow automation, what with AI and better to knit, if you go on YouTube, 24:59.000 --> 25:07.400 that huge communities about this and it runs on tapas. So I because I use this for my own company 25:07.480 --> 25:17.480 and which you can times up. I will get the very important thing for companies is that we have 25:19.480 --> 25:24.680 the governance control. So who's spending the AI budget? Light LLM. If you have an heard about it, 25:24.680 --> 25:30.440 really important for companies to control the usage of AI in the company. And I know that you 25:30.440 --> 25:36.440 all is like an AI. You can say that everybody can make screenshots. But Qualiver, 30 years, 25:36.440 --> 25:42.280 I is feeding Denmark. Kick the ties for this for six months. And in two weeks ago, they said 25:42.280 --> 25:48.520 we're in. They are implementing tapas now in the company for their whole silver team. And they're 25:48.520 --> 25:55.160 actually in Q2. They are finding pilots, customers. Their capital customers, which are also 25:55.160 --> 26:00.120 Danish communities to embrace tapas with their chauffeur on top. So there's a huge endorsement 26:00.120 --> 26:04.680 for us. They are ISO compliant. They will go through all the compliance checking and all that as well, 26:04.680 --> 26:09.720 which obviously then implies that tapas will also be tested. Yes. 26:09.720 --> 26:13.720 Someone from this team asked for your contact because we have a slide with your contact details. 26:13.720 --> 26:15.000 That's a good point. 26:15.000 --> 26:18.360 So we're done because we are also out of time there. 26:18.360 --> 26:23.800 Yeah. I will. What is the most important? Go to the repo. Just raise an issue. 26:23.880 --> 26:28.760 We don't have a support desk yet. We do have to do things. But go just raise an issue and just find 26:28.760 --> 26:35.480 us. So tapas the torque. We'll point it to the repo as well. And like I said, it's a private 26:35.480 --> 26:40.360 cloud on a plate for your basements. Thank you so much.