Tech Over Tea - Bottles Next A New Era For Wine | Mirko Brombin

Episode Date: November 17, 2023

Mirko Brombin the developer of Bottles is back on the show this time to talk about the new interface that's in the works with Bottles Next along with a bunch of awesome new features coming to the project. ==========Guest Links========== Github: https://github.com/bottlesdevs/Bottles Website: https://usebottles.com/ Bottles Next: https://usebottles.com/blog/bottles-next-a-new-chapter/ ==========Support The Show========== ► Patreon: https://www.patreon.com/brodierobertson ► Paypal: https://www.paypal.me/BrodieRobertsonVideo ► Amazon USA: https://amzn.to/3d5gykF ► Other Methods: https://cointr.ee/brodierobertson =========Video Platforms========== 🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg =========Audio Release========= 🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss 🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953 🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM 🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw== 🎵 Anchor: https://anchor.fm/tech-over-tea ==========Social Media========== 🎤 Discord:https://discord.gg/PkMRVn9 🐦 Twitter: https://twitter.com/TechOverTeaShow 📷 Instagram: https://www.instagram.com/techovertea/ 🌐 Mastodon:https://mastodon.social/web/accounts/1093345 ==========Credits========== 🎨 Channel Art: All my art has was created by Supercozman https://twitter.com/Supercozman https://www.instagram.com/supercozman_draws/ DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. I'm, as always, your host, Brodie Robertson, and today we have a returning guest, the founder, maintainer, developer, whichever term you want to be using, Mirko Bromben of The Bottles Project. Welcome back to the show. Hello. Short and simple introduction, I like it. short and simple introduction i like it um now the reason i brought you onto the show is because i wanted to discuss what you were doing with bottles next and where you're planning to

take the project but before we get to that i think it's a good place to start to describe what bottles is for anyone who might not be aware of the project okay so bottles uh there is a lot of confusion around the project because a lot of the person think that bottles is like a competitor of Lutris, Heroic Game Launcher, et cetera. But Bottles is a wine prefix manager, like the very old Play on Linux, like Wine Tricks and Pouty for Wine, maybe, and other.

So the only reason to use Bottles is to manage wine prefixes, so to execute a Windows program on Linux using wine. That's the thing. It's not a competitor for Lutti. Of course, like the 90% of the people who use the bottles uh use that for gaming because gaming is okay uh but that's not the the main reason behind bottles it's just that a lot of people you know the main reason that people are going to want to use wine is because of gaming so obviously gaming is going to be sort of a big thing that people talk

about with it yep but there is more of course I mean compared to crossover and other competitors, we can say, we integrated almost every Wine tools, like the task manager, debugger, command line, et cetera, inside the Bottles UI. So everything feels very native compared to Play on linux and other one thing that is very obvious about bottles when someone first uses it is it's got a very

i guess a very clean user interface it's very streamlined in sort of what it's trying to do. It's not providing you just all of these options, just blinding you with options, but they are there if someone wants to configure them. It's just the main path you go down is very straightforward, I guess is the best way to describe it. Yep. That's a cleaner description. I might have

said it in a bit too many words, but I hope that the description at least fits. So, with Bottle... I guess we can just move directly into Bottle's next. Like, that seems like the most sensible thing to do. So there's a lot of things that we can talk about with Bottles Next,

but I think the one that a lot of people probably want to hear the most about is the user interface. So right now, Bottles has a GTK, is it 4 interface? And the plan is to also have a interface made in Vue.js. That's the plan. That's the plan. So there will be two new, two different clients in Next, one in GTK4, as you said, and one in Electron with using UJS3. And you made it very clear in the Bottlesnext post that the GTK interface isn't going away. You said it multiple times, but I have seen...

I have seen a couple of people who think it's just... it's going away. It's never going to be here again, but... That's not the case. There is still going to be both, correct? Yes. correct? Yes. Why do you want to keep both around? Why not just have the new interface

and do away with the old one? Because probably a lot of people will hate me because of the... if I drop the GTK client. Because Bottles, at the time when I published Bottles as a flat pack, I had no idea of the GNOME guidelines. I had no idea of the GNOME guidelines.

And I was not following them. But when we started following them, thanks to Noel and other developers which joined the project, we started following them very strictly. And a lot of users, maybe GNOME fans, started to join the Bottles project because of that. So if I stop, I mean, I have a very big vision of Bottles next with Electron, the next mode, classic mode, etc.

But dropping the GTK for client will create just a big confusion of people thinking that Bottles is just a diet that dropped a shit. I'm not very satisfied of keeping the GT4 client because I have no fun developing GTK4 anymore because of many things. But we had to do that. It's just a political decision. Are you worried that trying to maintain them both at the same time is going to add, like, a lot of extra maintenance burden, or is the GTK4 interface basically in the state you want it to be in, and it's sort of making minor tweaks from now on? No, I mean, we have to recreate,

create the new GTK4 interface from scratch. We can't use, we can use, no, we have to drop the current GTK4 interface. We can't use the current interface. So we have to put some effort

on that side. But thanks to the new structure we are developing that we require probably just a month of development. Oh wow, okay. Not really a problem

I mean I'm not the one which will work on that side so it's fine well that makes sense it would be weird that you don't want to write more gtk4 code and then you're going to rewrite everything from scratch

um that would certainly be an interesting way to go about it. Now, I know you've talked about in the blog post that you want to add a bunch of new features, and we'll get into those features, a bunch of new features with the Vue.js interface. Is the plan to have the GTK4 interface and the Vue.js interface equivalent in the features they have, or are there going to be some things that are in one but not the other?

Probably the GTK4 version will not have the next mode, just the classic mode. I'm not sure about that, but that's probably how things will go. Is there any particular reason why that's going to be the case, or is it just a matter of getting it working and it's a lot of getting it working and it's a lot of extra work to do so there will be probably some extra work to do so that's the main reason but I can think also

of a problem in product identity I mean Hot Tolls is not just a project that we develop in our spare time. It's a product of my company. And we have some features which absolutely need to be in the Vue.js interface, not in the GTK interface, to not

duplicate effort over the time. Okay, that makes sense. So, is it correct to say that the... You would like to see the project shift more into that direction of UGS, but GTK4 isn't going away. It's just there as a way to keep people happy as you would hope more people go to the newer interface. Yup, yup, yes, that's absolutely the thing. So, I know a lot of people probably are asking the question, why Vue.js? Why Electron? I understand you don't particularly want to write GTK code, but, you know, the most obvious place to go if you're not using GTK would be something like Qt, for example.

What, is Vue.js the only thing that you had considered, or were there other things you were thinking about trying and maybe just didn't work out? I considered Qt but it's pretty confusing to me. I tried many many many times to create an application using Qt but it's very very, very, very confusing to me. So I say that the first, with Bottle, next, the first thing I said is that I have to be, to have fun developing this version. Okay. And using some technology like GTK, which I love GTK,

absolutely I love GTK, but using something like GTK, which I love GTK. Absolutely, I love GTK. But using something like GTK, Qt, and other toolkit, which does not make me happy because of many things, that's not cool. That is gone. And Vue.js is a very powerful framework. Not JS framework, of course. And I use this framework for my company for every single project.

So that's the most obvious toolkit to use, framework to use. So it's something you already had experience in. It's not something you're just suddenly learning for the sake of doing this. Yeah, yeah. Well, I guess that sort of answers my next thing, which is Vue.js obviously isn't the only web framework out there. And we did in private messages,

I did bring up react, for example, and you said you hate react. I think your exact words, what, what did you say about react? Where is it? React is a mess,

literally a pain to learn. So, if you'd like to expand upon that, I'm happy to hear it. I can expand some word. At the time, I was writing that

you will probably, you have to censor this one. But I was writing that React is a pain in the ass because it's very problematic, has a very hard learning curve. It's just complex to use. We made some product for our company using React Native. We spent like four or five months more compared to Vue.js. Wow.

Because of the learning curve. And at the time, at this time, I still have no idea how to use React. After months of using React. Maybe you won't like this, but React... React is one of the few web frameworks I have experience with, and when I was using it, I personally really enjoyed it. Maybe that's because I haven't tried Vue.js, and Vue.js is a lot better.

But at least for me, I like React, but I understand. I understand. It is certainly... It's weird, is a good way to put it. It's weird. Yeah, you should try Vue.js. Maybe I'll have to try it. So do you have experience with other web frameworks,

or is it just those two? I use it on Angular for like five minutes, probably. It's a mess. I use it... I don't know if Flutter counts as a web framework. Probably not. It can be compiled into web code, so I guess so. But Flutter is sort of a...

Flutter, you can build everything for. That Flutter was considered for bottles next was the the second choice because of the native things etc but it's a mess it's a very it's very difficult there is dart their language the google programming language which is very very, very difficult to me. Just remember that I'm forced to be a developer, but I'm a designer, first of all. Right. So, UJS is still fine.

I have some Vue.js open on the screen, and I, you know, i kind of like it already what is it about view js that you find so easy to work with is it that it's such a it seems like it has a very simple syntax and a it's sort of it doesn't have a lot of extra a lot of extra bloat to what you need to write it's very straight to the point that's one that's the one i mean it is like uh html plus javascript with super power probably that makes sense i made um i created one framework which is not ready for production. It's called, Pietro shows the name, and that's very difficult to pronounce.

It's Fabricative, something like that. It's pure JavaScript and follow the Vue.js philosophy but it's still in early access so we can't use that for Bottos next. But I really like that

I made that with a to follow or to meet all my needs. So that will probably be more easily to me to use compared to Vue.js. But it's not ready, so... Right.

But see, it's public, so you can contribute, fork it, it's open source. So Vue.js, whilst not being absolutely perfect it's the closest thing that exists and is production ready that you can use right now yep okay that makes sense that makes sense i i might need to try out vueue.js. I've been... I've taken a very long break from doing programming stuff, and I've just recently started getting back into it. Maybe I'll have to add this into my list of things to mess around with.

I'm sure I can have some fun with that. I can have some fun with that. And then, you know, maybe I'll make a commit to bottles at some point. No promises, though. Oh, yes. So, I think one of the most important things to talk about with bottles next is obviously the next component you have these two separate modes that bottles can run in you have I believe the original version is called

classic mode and the new one is next Mode. So I guess start by briefly explaining what both of these modes are. What is Classic Mode? How did that work? We'll start there. Okay, to explain this, we have to discuss a big problem that Bottles has, which is Bottles has a Wine Prefix Manager application,

has a lot of features, and many more, many others should be added in the future. The main concern of people using bottles was that bottles is very, very confusing. I mean, I use Lutris a lot, and it's pretty more confusing compared to bottles. But I love Lutris, and I'm a friend of the founder of Lutris. Not a problem.

the founder of Lutris, not a problem. So to fix this problem, we discussed it for quite a few months. That's a pretty big discussion we had. And we said, so we have to satisfy advanced users and new users, new corners. But how can we do so? Because advanced users want access to every single option, like changing the runner, DXVK version, DXVK Plex, VKD, VKD 3D, and all the options, FSR, et cetera, et cetera, et cetera.

But the new user just wants to play the game or run Office and stuff like that. So we say, why not creating two separate interfaces, one for advanced users and one for new users? So we can streamline, we can offer every single functionality to the advanced user and add more functionalities over the time because that's an advanced user and just make the life of the new user simple because i can see a new user opening bottles and saying oh i just wanted to start a plain happy game store installing and using Epic Games Store. Why should you have to create a bottle, open the bottle,

go to installer, click install, and then go to programs, open Epic Games Store, and stuff like that? I just wanted to play and install and play Epic Games Store. So the next mode will just prompt you a search bar where you can search for your program and press Install. And that will show up in your library.

And that's the thing. I mean, you just have this big library with all your programs and just click Play to start using that program. And the different thing is that because under the hood, there is a complex behavior. I mean, the classic mode will use the classic wine prefixes. So you create a bottle, two bottles, three bottles, et cetera.

And here we have more than one wine prefix. While using the next mode, you have just one bottle, one wine prefix. And every single program has its own layer, like the RPMOS3 overlays, we can say. OK. So there is only one wine prefix. Every program has its own layer with all dependencies,

configuration, and stuff like that. And you don't have to work with the wine prefix or tweak that because you tweak the single program. So if I- That's very complex. If I understand it correctly. So if I- That's pretty complex. If I understand it correctly, so even in this next mode, it's sorta like having mini bottles all inside this one.

They all have their own separate environments inside this one bottle. Yup. Because that's one of the things I did see people confused about, because the idea of bottles was that you had these separate things for all of your applications you installed were just in this single bottle? That's thanks to the layers. I mean, you have that wine prefix which has one or more layers. That's the pure concept about under the overlay structure, overlayFS. So there is a lower directory, upper directory, work directory. That's the thing, I mean. It's pretty simple. I mean, the big concern was that bottles,

the name bottles, refer to many bottles. Right. And the next mod proposed to use just one bottle. Yeah, that's probably confusing, but there are more kinds of users. There is the new user, the advanced user, and the advanced user. Probably 50% of the people using bottles are advanced users, so they expect to use more than one bottle. I don't see the problem. I don't see a problem either. It's just that a lot of people weren't sure how it would work.

So it seemed weird. But with your explanation, I think it does certainly make it make a bit more sense. One thing I'm not sure about is, I don't think you mentioned this in the post, but can you make use of Next Mode and Classic Mode at the same time? So have certain applications inside that single big environment and then pick and choose other things that you want to be in their own separate models? choose other things that you want to be in their own separate bottles? Yeah, you can switch from next to classic and vice versa at any time. If you are using the classic mode, if you will use the classic mode, you can still create a next bottle, which use the overlays and that stuff. Of course, the interface will be the classic mode one.

So you don't have the library with every program installed, et cetera, but just a classic bottle with the list of the installed programs. So a bit different, but you can still switch to the next mode and all the bottles you created using the classic mode will just be hidden and you can just use the next bottle. Okay, okay. So for those advanced users, it still gives them the power of this new solution if they do want to use it exactly that makes sense that that yeah that definitely does make sense um so what was confusing about the the old method that you had with that classic mode what was i i've not been i've not really

used bottles that much but what was confusing about having to make a bottle for each of these individual applications was was the extra configuration that needed to be done what what really was the problem here? Based on the reports, some people just... There were some users healing the application during the bottle creation because the first bottle you create in the current version of bottles

takes around one or two minutes to create because it's not just a one prefix. It's based on the environment you select. It installs some dependencies, registry keys, et cetera. So it takes some time. But that's only the first bottle because in bottles there is a concept of templates which is a sort of a cache and every time the first bottle the first one prefix you create is used as a template for the next one and that was some that was confusing for some users

because they say, ah, it's taking forever, just kill the application. And currently there is a problem in bottles because if you kill bottles during that creation, it will create a broken wine prefix, which would work, but 99% of the case is just broken and you can't use that for anything. And that was the first point. The second one was also a criticism from the GNOME circle. circle, which is what is the main action in Bottles.

And the main action is to run an executable, not using the installer. We have an installer view, when you can install bottleneck origin, Epic install, et cetera. But the main action is still running a single executable. And that was not very clear. And some users misunderstand that. They go to the installer, use the installer,

or if they want to install Epic Games Store, they use their run executable button, picking the executable of the Epic Games Store and that will never work because you need some dependencies which only the installer install so that's

pretty confusing for some users yeah unless you had gone into that following a tutorial, I can see why someone would get lost with that. I would probably stumble around for a while until I probably worked it out, and I'd probably just give up and look up how to do it. So, yeah, I can understand why that's something you'd want to, you'd want

to clean up. Um, sorry, were you saying something? Nope. Oh, okay. So let's see. Right. Actually, wait, let me, let me think what i'm trying to say so if you're going from wait now i'm struggling with english um so bottles next is not currently ready is that correct? Are you still a work in progress?

Mm-hmm. Mm-hmm. So... It's in, uh, first stage. Okay, okay. I assume the plan is to make sure that when someone is moving from the current version of Bottles up until Bottles next, when that is ready, everything they currently have set up is just going to smoothly migrate over? Maybe.

Okay. We are still discussing that, because there will be a very different structure behind the hood. We'll probably create a sort of migrator for the legacy bottles application. So, yeah, you've touched on it a couple of times, but the architecture of bottles is drastically changing.

And I think that definitely deserves a bit of talking about as well. You've got a diagram in the blog post where you've got a client, server, and agent. I guess let's talk a bit about the way the new architecture functions. Yeah. way the new architecture functions. Yeah.

Then bottle next as a whole different structure compared to any previous version of bottles. Um, what is the current architecture that it's using? Currently it's like a single code base. Okay. Front end, back end, everything is just one code base, which is a mess. The big problem of having a Qt client for Bottos right now is that the back end is not really detached from the front end.

It's not separated. So there are many problems. But the real problem right now is that there were many developers working on bottles. And there is source code coming from the very first version of Bottles. Some source code around Bottles v3, some added some days ago. It's completely burned. It's complex to work we can't just and there is also a problem in implementing

new functionalities because right now we are using um uh how can i say a sort of modular source code. We have kind of a modular source code. We can implement every single wine utility and map that to a Python interface, Python class. But there are many issues at the core of the project, which does not allow us to connect those new utilities, new functionalities to the interface, because we will have to rewrite the core itself. Right.

With compatibility. So everything right now is a little bit too meshed and tied together it's really hard to to pull things apart yeah i assume it was designed like that because it wasn't really thought ahead early on and it was just easier to do it like that as opposed to it was intentionally designed like this it's sort of the the easiest way to make it is just do everything in this giant mess of a code base as opposed to having a good architecture uh to be honest I have to say that when I started developing the current source code, because there was a rewrite, but not a 99% rewrite, like an 80% rewrite of the source code. I wrote that in thinking about scalability and to put new functionality very simple. But there was a problem because of how wine prefixes works. So I developed that with the best intention, but that's not very very cool.

So you had... you wanted to make it... you had a good plan for the project, but... or you had at least good ideas for the project but it didn't didn't really turn out that way if i'm understanding correctly yeah yeah that's correct okay okay so now now you have a chance to sit down and properly lay out a architecture that you know properly lay out a architecture that you know is going to be able to be scaled further into the future able to be built upon whilst not leading back into that same problem not having this problem where everything is directly tied together and it's hard to move anything out. Yeah, yeah. That's the current situation. Okay. So with this new model, this is a client-server-agent model.

Now, most people have probably heard of a client-server model, but the agent part there is, you know, something I usually don't hear. So I guess let's go through each of the pieces. What is the client in this situation? The client is the interface, what the user sees. user use what the users see okay so that's in this new interface is going to be the view js interface yeah okay and that's the client like the gt4 the new gtk4 client interface will be the client so actually one thing i did want to uh did want to ask so in the future if you changed your mind about qt for example and you felt like you wanted to actually learn it if you wanted to go make a qt interface with this bottles next uh sort of

architecture you have doing so would be a lot easier. Yeah, you just have to create a new client using Qt and Python, C Sharp, C++. Okay, maybe not C Sharp, but C++, et cetera. Yeah, that makes sense. If someone wanted to... I assume this is not, like, the main focus, but if someone wanted to make a QT interface,

would that be something that you would be interested in bringing into the project? Or maybe not QT, or whatever sort of interface they felt like making. Was that something you would be interested in bringing into the project if they showed that they were well supporting it it was being frequently updated or are you not really interested in in having that in as a part of bottles new clients are pretty welcome because but we have to discuss this thing but

we'll probably introduce the concept of official and unofficial clients because I mean if one user asks me to create a new Qt client they are welcome

to create a new Qt client, they are welcome to create a new Qt client. I can publish that in FlatHub. I can sponsor that. There is no problem. But they must develop that client because if they change their mind and stop producing the Qt client, the problem will be me,

not the new developer because the persont client, the problem will be me, not the new developer. Because the person behind bottles, it's not only me, but for the people around, the person behind the project is me. So if you want to create a Qt client, you are pretty welcome. But do that and maintain that as an unofficial client. I think that's the best way to handle it. If there was...

So, right now the plan is not to have any other official clients besides the GTK4 and the Vue.js. Yep. Okay, that makes sense we'll have to wait and see in the future what people feel like making as unofficial clients maybe maybe no one feels like they need to or maybe someone is bored and wants to to write something that's sort of just a matter to wait and see what people end up wanting

to do. Yeah, I think that's the cool thing about OpenStreetMap. You can do whatever you want. Yeah, that's definitely true. Okay, so the next piece we have is

the server. And the server is what we call the backend in the current codebase. And that's what does the... what manages the bottles. So, all the logic behind the management of

the bottles is handled in the server. And there are no wine operations performed by the server. That's just the pure bottles management. So the configuration, storing the bottles, download components like runner, DXVK, et cetera. And that communicates with the client like a parallel communication. So client can ask the server to list the bottles

and the server return the list of the bottles. The client ask the server to download a component, the server start downloading and push the response to the client. That's the classic client-server combination. Yeah. Now, the third piece is the agent. Now, what is the agent? That's complex to explain.

Okay. Because in short, the agent is WineBridge, which we are already using WineBridge in Bottles, but not in the way we use it in Bottlenext. Because in Bottlenext, WineBridge is the only way we use it in Bottlenext. Because in Bottlenext, Winebridge is the only command we use because Winebridge is a G-sharp with.NET application which runs inside the Wine prefix and exposes

a micro server, we can say. So the Bottlene bottle server can ask to every single bottle using WineBridge to perform an operation. So let's explain that way. If the user using the client press the run executable and execute like the notepad++.exe that the client ask the server to execute that can see, to execute the not-plus-plus.x. And that, not using command line, not using weird commands with impossible structure, will just execute that program using a native WinAPI call. Okay. And that's faster, simple.

There are no problem in conversion. Like right now, Wine uses a convertitor from Unix path to WinPath and vice versa. Right. And that arises some problems because there are many different structures, like in the spaces, backslash, and things like that.

So the agent is like an agent inside the wine prefix, which perform everything natively. OK. Hm. natively okay hmm so it's quite different compared to lutris etc mm-hmm

so how are you currently so I did see something in here about um previously you were managing the prefixes and all the wine stuff using shell commands. So this agent is, if I'm understanding it correctly, a replacement to doing it through that method.

Exactly. Mm-hmm. Exactly. So, you were saying that the shell commands sort of have issues with the file path conversion, obviously there's that performance issue. Is there anything else that's a problem with doing it through the shell command method, or did you mostly touch on what the problem was? command method or did you mostly touch on what the problem was? No, there are many issues like double quotes, escaping quotes, escaping special character, because in Bottos, if you are, if you enable game scope, game mode, mango HUD, and it's became with some flags, et cetera, the final command will be a set of environment variable with game scope

which requires some arguments which must execute the final command using double quotes which use game mode which use the final executable There are quotes inside quotes with other quotes and argument with argument with other command because of that argument. The final command in Bottos right now is something you really don't want to see. Quite confusing. I've worked with much simpler commands

than that and it's already something I don't want to see that does not sound fun to work with I can understand wanting to move away from that I spent like years around this problem

and no no like years around this problem and no. No. So Stop using shell commands as I can please. Yeah, I think we can agree on that.

So would this wine bridge have any actually we'll phrase that a different way. Do these shell command methods have any limitations for what is possible that WineBridge makes possible? Or is it just that it's a lot easier to work with?

a lot easier to work with? WineBridge allows to perform async calls because WineBridge is asynchronous and you can execute multiple commands without freezing the interface, without freezing the operation. So you can ask the WineBridge to run this executable and another executable, open WineConfiguration, register a keys, everything at the same time,

and that will manage the queue. So if you ask WineBridge to kill the server, so kill the WinePrefix, close every process which, so kill the WinePrefix, close every process which is running inside the WinePrefix, but you also ask it to execute a command and

another command, I mean, a program and another program, or registering a key, etc. WineBridge manages the queue. So it says, okay, WineBridge manages the queue. So it says, okay, you are asking me to kill. That's not a forced kill. That's just a stop operation.

So I will end all my registration for the keys in the WineRegistry, which is another task. You can simply kill this operation because you could simply break the whole prefix. And when those are completed, you can say, oh, okay, I can stop. And that's probably the best thing in using WineBridge. So that, I would imagine, is a big part of the performance improvement you get. So by not having to wait one by one for each section of the command to run, it just naturally allows things to be a lot quicker. Yep.

Another thing that you said that you heavily rely on is Python, and that is also, from my understanding, not going to be a big part... is not going to be a part of the backend anymore, if I understand correctly. Yeah, we are dropping Python in the whole project. So what were you using Python for before then? Python was used for everything, the interface, backend, everything.

And right now we are switching to of course Vue.js, TypeScript, Electron, etc. But the backend is brought in using Go language. Okay. Why Go? What about Go was appealing? Because let it go.

let it go is that it? forgot me please I mean Go has a nice learning curve we had we need a performant language for bottlenecks. We have Go language as the Go routine, which simplifies asynchronous tasks a lot.

Because we need a lot of asynchronous code inside the application, we said, okay, just use Go, which can be compiled. So we can compile the whole backend inside a single binary without dependencies of any kind. And there's a very good learning curve. So new users can join the project without finding barriers or obstacles of any kind. I've personally not used Go myself. Was this a language you previously had experience with, or is this something that you were you know learning for this uh in fact in my company we use uh go a lot but the whole vanilla s project is built using go every utility every root topics etc are all built using a go that makes sense then so with um with python on the back end were you

are you dropping it because you had uh performance requirements that were not being met by it is obviously good uh go is probably going to be more performant, but were there specific issues with what Python was allowing you to do and the performance it was offering you? The main issue is because I'm moving to

a typed, only two typed languages which Python is not typed. can simple define an argument as a boolean and use that as an integer or as a string without problems and that in big projects can be a problem because you can simple simply lost your focus inside a project you can simply lost your focus inside a project. You can define that variable. Oh, yeah, that's a Boolean. And at the end of the function, it become an integer.

Why? I feel the pain. I personally don't like duck-typed languages. I get it, I get why people like Python, but you are right. Typing, clear typing is very important. Um, one thing we didn't mention is that it's not just Vue.js you're working with, it's also using TypeScript. Yeah. Very important. Because otherwise, JavaScript is not typed, so there will be the same problems as Python. Yep, yep. JavaScript... I don't understand why people like not having clear typing.

It's... Yeah, if you haven't thought to that... Because people like shit. You know, you're not wrong. I can agree... I can agree with you there after this podcast this podcast

podcast I will have more enemies than before maybe I don't know I feel like I'm I have a lot of fans who are really big C fans so actually to be fair in C you can point a pointer to

anything, so maybe they won't like you. When did you realize that just not having a clear typing system was going to be a problem? Was this something that you realized thanks to Bottles,

or was this something that you'd known for a while but still went ahead with using Python in the Bottles project? I must say that Pietro, the older mind behind bottles, tried to introduce me to typed languages for years, probably. But I always say, ah, but I can define a boolean and use that as an integer without problems. What can be the problem? It's fine.

an integer without problems what can be the problem it's fine well some time ago uh or me and pietro asa and have a company and we we got a new customer with an already existing product which i can say but that product was developed by uh don't know, like a monkey probably because there was a function wrote in Italian I don't know how that could even be

possible but every single variable was in Italian. But some other function was written in English. Some other in, I think that's not Italian. I don't know what user was using, but I don't know. And trying to understand that source code, which was Python, was very confusing because there was no time, no one time, where that developer defined a different thing, like a string or an integer or even a class.

And that was pretty confusing to me. So I said, I can say, fuck you, Python. I can just go in any other language with that typing. I can just go in any other language with the typing Was this was this before or after you had started working with bottles?

After Okay, okay If you had that experience beforehand and you still went ahead with Python, I would be very confused. Sorry? If you had that experience before you started working on bottles, it would be weird if you would still go with Python then. I will never use python for bottles then if I had that experience before I mean

yes yes yes I must say that bottles has turned 6 this October has 6 year wow so happy birthday but no I was at my at the start of my how can I say say, my campaign with Python. I was starting using Python at that time, so I was a noob.

Python was just, I can use Python for everything, like games, everything, like bottles. And now I can say,'t use a Python for anything. If you had to pick one that you had to keep using, would you rather deal with Python or shell commands? What is the one you dislike the least can i just dislike both i mean probably shellcom nah maybe python maybe typed python which is not really typed because there are no compiler errors because Python is not compiled. But maybe Python with typing is something I can work on. With the way that you are currently using Python, do you try to make sure that you're not randomly changing the type of a variable or

is it sort of just depending on when the code was written um depending on how it's written yeah okay so we. So we did a big work on bottles, on typing the whole Python code. So if you look at the source code right now, we added typing for every variable, argument, everything. And that's better, but still a mess okay okay let's see if i can find some of it uh that that should i see okay yep yep i see it's yeah

it's yeah so i i is it safe to assume that early on you were just randomly changing the types of variables yeah yeah yeah okay okay on a mistake i mean i, not on purpose, maybe. So that's been something that you've been trying to clean up, and you have cleaned up a lot of it, but even so, you want to move to something that has a proper type system where this just won't be an issue going forward. Yeah. If you use a wrong type,

there must be a compile error. No, you can just compile it and go away. No problem, man, you can... That's a bullet, no, that's a number. No problem. No. When you have commits being made to the backend in Python, do you have people that are just randomly changing typing, or do you have a style guide for how the backend code currently has to be written?

We have no style, we have no guidelines for the source code, but everyone follows the typing, so no problem on that side. Well that's good. Otherwise, no matter how much you fix your own code, there's going to be more code that gets added that's also terrible. So you mentioned that Bottles Next is... You said in stage one. So it's very, very early on from my understanding. Yeah. There is a... There's a source code on my understanding. Yeah. There is a... I have a source code on my computer.

But there is like just the window and some customization of the window. Nothing. We are working on Figma to prototype the whole interface. I don't think you should mention any possible timelines because as soon as you say a date for when something is going to be done someone is going to expect it to be done then but do you have any idea when even just an early version of it would be ready?

I can't say. I don't know. Fair enough. My focus is on Vanilla OS and another project right now, so I don't know. Do you have any... Maybe not when you... Actually, how would I say it? Well, right now, you said a lot of stuff is being done in Figma.

What is the next step for Bottles next? What are you directly next working on? Probably the server. Before the interface. Okay, so is it just the UI that's currently had the main focus at this point then? Yeah. So Bottles Next right now basically doesn't do any of the bottle stuff right now. It's just you've got some layout for how it's going to be able to work but if the it doesn't do any of the important stuff exactly okay so we shared the the screenshots

just um some weeks ago just to see how the community if the community was happy about that and seems like that i mean a lot of people just contacted me to say ah electron is a human trust remove that use gtk4 use qt don't use elect is a you are a what GTK4, use QTE, don't use Electron is a shit, you are a shit I did see a lot of people complain about using Electron, a lot of people saying it's bloat

saying all of these things I I don't I the people who are really obsessed with using none of the resources their system has. I understand not wanting to have an application that is just needlessly running really badly. That makes sense. But it's not like an

Electron application is using you know, 20 gigabytes of RAM and 80% of your CPU to run. Yeah, I don't understand, honestly. Right now, Bottos is using like 500 megabytes of RAM just to run. If you start to use Bott bottles and play some random games,

open the registry, etc., it will use around 1 gigabyte of RAM. So I tested, I did some experiment with Electron, and it used around

300 megabytes. And you can add a lot of features. I made some terrible loops just to test some heavy loads. And that has never reached the 500 megabytes of RAM. The problem in the Electron website, in the documentation, they explain very well that you must be

very careful to use Electron, but not in general. Because if you use Electron and JavaScript and things like that everything is fine it's just a matter of rendering and simple calculation simple operation but if you use some node modules packages which use the some node native codes that could use like one two or more gigabytes of ram

so it's just how you develop that program i think that heroic game launcher flavio the founder of the project is very respectful of the system hardware and Heroic does not use a lot of resources that's very a good representation of how Electron should be used and I use UJS, Chromium, etc

since years right now so I hope to do something like heroic. Heroic is a really cool project. I didn't know it was using Electron. That's cool. Yeah, that's Electron.

I asked no, I should ask, I never asked but I should ask Flavio. I'm friend with Flavio. We talked randomly. And I should ask Flavio. I'm friends with Flavio. We talk randomly. And I should ask him to remove the system decoration from Heroic Game Launcher. Because Electron has this thing that you

can use custom window decoration, like VS Code, also in Linux and Windows Mac. And that would be probably better since GTK decoration in electronic applications are terrible What's wrong with them? I don't know what the problem is here

They're just terrible looking okay right I thought there was more to it than they looked bad that's yeah that's fair enough yeah you can use removing the window decoration you can use radius border

you can use custom shadow custom effects like a sort of colored border of the window you can do whatever you want to do, one of the things mentioned here is about the Steam Deck. The Steam Deck obviously wasn't a thing back when Bottles first started, The Steam Deck obviously wasn't a thing back when bottles first started. But now that it's out, obviously a lot of people are using bottles on the Steam Deck. And at least from the way it's written here, it's not super well optimized for a smaller screen like that. Is that correct to say?

Yeah. That's correct. So it was designed very much around what like a most monitors like 24 to 27 inches so it's it's designed around that sort of scale. Yeah, developing our own interface and our design language because that's called our design language we can create any sort of component to every selector input button we develop everything, which some users can see this as a stupid effort because GTK and material design and some other toolkit already exists. But in developing, thinking our own design language can help us to create what we want. Like if in the future, like this large coverage, when you use Bottles Next in Steam Deck, you use the large coverage mode, which is

the one you are talking about. Yes. And as more big buttons. Some features are disabled. The library has big buttons with big covers. And that's something we can do only if we develop that language, that design language. So that probably requires more effort

compared to using something that already exists, but in the long time can help a lot. And another thing I must say that the toolkit we are developing for bottles, it's obviously open source so everyone can use that in their own application help work and help improving that developing new application so that's still open source So... I guess... When you were saying before that you

program, not because you want to, it's because you have to do it for design? I can't remember exactly how you phrased it, but this sort of shows that you have a lot more interest in doing the design aspect

than just the programming part. Ah, that's correct. I had no fun developing the current version of Bottles. I had to leave the project

for some months because I literally had no fun working with bottles because at the start, like the first years of the project, I could just add some widgets, edit some widgets, do whatever I want. But in the last year, last two years, a lot of people started contacting me

because, ah, that's not how GNOME do that. That's not how you should do that. Look at GNOME settings. Look at these ways of application. Look at this. And I had absolutely no fun working with Bottles anymore. And that's because

I had to leave GTK in that project. Because in another project, Manilo S, we are using GTK for everything and I love working on GTK on that site. But in Bottles, I just wanted to leave GTK

and do whatever I want. Mm-hmm. Mm. Why is there this difference with how you look at GTK between these two projects? What is it that's different about it when doing the Vanilla OS stuff? Because the difference is that in Vanilla OS,

we are not inventing the interface. We are inventing the backend behind those interfaces. So like the Apex GUI, which is the program which allows you to manage the containers, etc., we developed, we invented that way to use containers in the backend of Apex, in the interface, we have no effort on redesigning how that should work. We are not creating custom widgets with a complex interface or some random ideas. It's just how that should look. It's just how that should look.

So if someone asks me to, oh, change this because GNOME do that, that way, okay, open the pull request and just fix that. That's not a problem. Bottles is something that I'm taking care for more of six years now. And that's a completely different matter. So in Vanilla OS because you're already working in the GNOME environment you're not trying to make something unique you're just

trying to make something that fits into GNOME whereas with Bottles, Bottles is your own thing that you want to be set up your own way. Yeah, and Bottles is used in KDE, XFCE, GNOME, and other desktop environments which does not really care about Grom Git lines I should not put my effort on following them if also other desktop environments are involved in this

so that's No, I understand that and as we said you clearly have an interest in doing design so giving yourself this this project that you can really express how you want this design to be i think is it's really cool it's really neat have this... you have this passion in doing design because there is... there is a lot of FOSS projects out there where it is run by a developer and they develop it

because they are focused more on doing the features. It's nice to see someone who is approaching it from the other side where they do the design work first and that's their main focus, getting that nice and clean, and then also it needs features as well, but having a nice way to access it is it's a nice it's a nice difference yeah I think that Lutris sometime will move to

another toolkit because they have a lot of functionalities and when I say a lot of functionalities and when I say a lot I mean a fucking lot because when you

open settings for a wine prefix in Lutris you are just you are pretty confused about what you should touch there are many many

settings and the problem in Lutris in my honest opinion is that they can't really move to GTK4 they moved to GTK4 I think already

but they can't move to Libadwaita without to GTK4. They moved to GTK4, I think, already. But they can't move to LibAdvita without reaching a lot of users, asking them to follow the guidelines very strictly. And Lutris has many developers. And I don't know if they have designers. I think not. And that could be a problem for such a big application like Lutris, which has many more years compared to bottles.

They probably should stick with GTK4 without attaching Libadwaita or maybe switch to another toolkit. Or just don't give a shit and do whatever they want with Libidwaiter or maybe switch to another toolkit or just don't give a shit and do whatever they want with Libidwaiter yeah I like that plan just do whatever you want just make it work I can understand what you're saying if they bring in

if you do bring in Libividwaiter because then... Yeah, then it does sort of... You've already adopted a big part of the GNOME approach of doing styling. So if you're going to do that, then you should probably go all the way with it and keep bringing in these other things. Which might then get in the way of it and keep bringing in these other things which might then get in the way of the vision of that project yeah

yeah I must clarify that I love the work we actually I'm still in the foundation I love the work we actually I'm still in the foundation in the ground foundation I love the work we are doing because Linux

they serve a lot of standardization guidelines we need these in Linux but I also need the freedom to do whatever I want the way I want sure yeah it's good to have some random users I also need the freedom to do whatever I want the way I want. Sure. Yeah, it's good to have... Some random users contact me.

No, I get what you're saying. It's good to have this standardization in the context of the place where the standardization makes sense. But, you know, Pl plasma is never going to follow the gnome design guidelines budgie is never going to follow it all of these other desktops are doing their own thing and if you want to make a gnome app go ahead and make a gnome app that perfectly follows the guidelines but not everything needs to fit into that and it's okay to make something that is different.

Yeah. Um, let's see. So what else is on here that we haven't really touched on? We've not talked about parental controls, which is something that you are planning to add. Should I explain that? Yeah, sure, go ahead, because I don't see that many applications that have parental controls. Because there are not many applications working with Wine, allowing the user to install Windows software in Linux or macOS, which is a new target for bottles, they can actually work around the system

parental control. So if you turn on in MacOS, for example, the parental control, which does not allow you to install a new application or download software from the app store, etc. Using bottles

allows you to skip that parental control because the software is not installed inside the system but inside the wine prefix. Implementing a parental control inside bottles, which will work with the system parental control,

allows the parents to reduce the risk for the user, for the child, for the person, to install software keeping the system parental control. If you enable the parental control in Bottles, you can't install programs. You can't do anything. You can just use what the user, what the guardian, I can see, chose to allow during the parental control.

Makes sense, yeah Simple as that, definitely makes sense Is this So right now In bottles, like the current version There isn't any sort of parental control It's something that you Realize later on That needs to be added.

Yeah, actually there is an issue in GitHub. It started like two years ago maybe. Or maybe it was a discussion on Discord, I don't remember. But this was discussed some years ago. don't remember but this was discussed some years ago I tried to I won't be able to find it I thought I might be able to do a quick search and be able to get to it but no

so people have already been discussing this as something that maybe would be worth adding it's just not something that had been done so far. Yeah, yeah. I was unaware that you were targeting macOS as well. That's a question?

Yeah, more like just a statement I didn't know that so right now Bottles is only Linux or is it or macOS as well or is that just what the plan is going forward? Only Linux okay right but the

with Bottles next Bottles next the idea is to have both Linux and macOS. Yeah, yeah, yeah. Okay, okay. I always forget that Wine's a thing over there as well. I don't know how it works, but it should work. Yeah, I don't know either. That's a question for the wine developers, who I'm sure could spend two hours just talking about the intricacies of how wine works. I think that wine developers, I mean Codewivers developers, will never reply to my question.

Because there is a discussion on Hacker News, Hacker Post, Hacker News, and one of the CodeWeavers developers, which say that we chosen to use bottles to, I don't know how to say. I don't remember that post, but it was accusing. Is that accusing a word? Bottles because of the name, because the crossover used bottles for their, instead of wine prefix, they called those bottles.

And they say, ah, they are called bottles because they want to destroy the project. And a lot of users commented that said, but we are talking about wine and bottles. It's the most common

thing. I mean, where do you put the wine? Inside the bottle. So that's why bottles is called bottles. That was funny. If I can find this, I'll definitely have to have a read of this thread. It sounds like it's just one developer just going off on a rant.

Yeah. Yeah. Okay, so one other thing you mentioned in the blog post is accessibility. So this is obviously, it's an important thing for really every project, but what if any accessibility features are currently present i didn't get this sorry uh in the current version of bottles what sort of accessibility features are available? Nothing. Nothing, okay. Just what comes with GTK. Mm-hmm.

So on here, say you want to do colorblindness, various types of colorblindness stuff, high contrast, and ensure compatibility, uh, compatibility with screen readers, all of which I think are very important things, um, I guess, what sort of, how would I say this, um, sort of, how would I say this? Um, what sort of issues with the screen readers are currently present? Was there really any thought put into that with the current design or is it? Yeah. I, I know I lost my train of thought there. So, what would you need to do

to ensure compatibility with screen readers in the context of bottles? How would you need to go about designing things to make sure things are working as they should be? designing things to make sure things are working as they should be I must say that screen readers is something we put in

that article just to make it clear because some users would say they are dropping GTK so they are dropping screen reading compatibility. No, there will be screen reader compatibility. Okay, that makes sense. So,

I guess then, what specific stuff is in the works or is being discussed that you would like to add with the new interface you're working on in the article, because the only one left is the... how could I say... for blind users. I mean literally blind users, but that's the screen reader thinks. I think the plan is to cover every kind of accessibility, so there should be no problem. I have no idea. It's almost certain that as this interface gets released out and everything is in a state that's ready to be tested, users who require these sorts of additional things are likely going to try out the project and report issues on things that currently are not in a state that they would like

them to be in? Yeah, if there will be problems they can still report and thanks to this new structure, so the client, the server and agent, if a new kind of accessibility is required we can just develop that for the client, the server and agent. If a new kind of accessibility is required, we can just develop that for the client without any problem. That's how Waze is. Now, maybe this is kind of old drama at this point, but I think it's also worth mentioning the bottles package situation. Because I did a video on this.

Yeah, you know. Oh, Fedora. so okay for anyone who is entirely unaware of what happened with the bottles package what is

how do you prefer bottles to be used if someone is completely new to the project and asks you how should I install bottles? What are you going to tell them? Ah, Platpack. Yes. So...

I should spoil that I'm working on my spare time on a distribution format, on a package format, using OCI containers that works like a Flatpak in the way you define the flat, in the way you define the application, in the way you install that, the duplication, et cetera. But it's not a flat package is using containers so you can define a an oci image like an alpine linux add some dependencies from using the package manager and that it's just an experiment

i'll probably never distribute that as a solid alternative to Flatpak. I'm working on that with Luca Di Maio, the Distrobox founder. But we'll probably use that for bottles.

Okay. Not instead of Flatpak. I mean, not replacing Flatpak because we will never... I must say that. But that's probably one of the future package format for bottles. Hmm. That's actually really cool.

I'm curious to see what ends up happening with that. So. to see what ends up what ends up happening with that so there will be a flame a big big flame the war another package format I must say that this is ridiculous because

some people, some users said to me that you should have worked to Silverblue, not inventing a new world distribution you should have worked to OS3 not inventing ABroot you should

but the point is that Silverblue and Vanilla OS are two different things. OS3 and ABroot are two different things. Some users, which are very addicted to Flatpak, always say, ah, Snap should not exist because we have Flatpak. But Flatpak, I mean Snap, because we have Flatpak. But Flatpak, I mean Snap was born before Flatpak. Snap was, I think, before Flatpak.

So the problem is that some project can exist and some other project can't exist. Some projects can exist, and some other projects can't exist. Because if I invent a new Flatpak, a similar Flatpak system, some users, I already know, will tell me that I can't because there is Flatpak. But why Flatpak can exist if Snap already exists? Why I can't develop Vanilla OS and a lot of people already say that to me, I can't develop Vanilla

because there is Silverblue, because there is Micro S, etc. Why I can't but other projects can? I think people are weird. The way that I look at it is, even if this other solution doesn't end up becoming a popular thing that people use, the way that we come up with new ideas

is by people trying things out we wouldn't have a lot of the great software we have today without someone thinking hey maybe if i take what this other project is doing and try to do it in a slightly different way like I think an obvious example here is X11 X11 obviously is on its way out but X11

it came from a, it was based on a previous project called W it was an open source implementation and modification of what was being done there the entire graphical framework that we have existed on linux has always been someone seeing a thing that existed and then doing it a bit differently and Yeah, I think even if it's not like a Even if it's just a one-off project and it eventually gets abandoned

Even something like that can be a learning experience for you maybe later down the line or someone finds the project and sees what was being done and then wants to do something else themselves everything that we do in this space leads to a bit more innovation and hopefully better software somewhere down the line. I agree. That's the thing. I think a lot of the people that complain about you doing the vanilla OS stuff or

someone else doing some other project I don't imagine a lot of these people are I don't think a lot of these people are... I don't think a lot of these people are developers. I can't imagine many developers being super focused on what some other project is doing.

Maybe some of them are, but you're not seeing any project leads that are that are arguing about other projects existing in this in this sort of way Yeah, I think just go ahead make like make. Even if this format you're trying out doesn't end up making sense, maybe something else you do later on builds off of that and then, you know,

ends up does making sense. Yeah, everyone should do whatever they want. I mean, there are some cases like, do you know Apex, the package manager, container manager, actually, of Manila OS? Yes, yes. And a lot of distribution started creating loaners of Apex without giving credits

for the idea, without giving credits to Luca Di Maio because of using Distrobox, and I'm talking about BlendOS. I say that, oh yeah. But that's a different thing

because I am not, I can say for AB root, which is what manages the immutability in Vanilla OS, I am not recreating OS 3. I am creating a whole different thing that results in immutability and atomicity. So the goal is quite similar, but the project is completely different. But there are some projects which do exactly what Apex does behind the hood.

And that's the clone. It's a different thing. You are not experiencing with a new method, new concept. No, you are just doing the same shit we are doing in Apex. And that could be a problem.

Not me doing Abirute, Vanilla OS, or another format package which is using OCI or something like that. That's the real problem. And I wrote an article on my website some months ago talking about this, on duplicating effort, on the wrong way to do open source.

And some user contacted me on Mastodon, and one of those was Sony Pires, developer of the Workbench app, telling me, ah, but you're doing the same with Vanilla OS, AP root, et cetera. I'm not doing the same. I'm doing a whole different project which could be shared the same goal.

But it's very, very different in the structure. It's not a clone of OS 3 with a different name or a different language. Yeah, you're aiming for the same

end result, but the way you're getting there is very different. Yeah. There are different benefits, different problems, maybe more problems, maybe less problems,

but it's a whole different technology. Yeah, yeah, yeah. And that's the matter. Hmm. Yeah, no, I... I like the idea... Why Vanduul S is copying everything from Vanilla S. I must say this

I don't think you have to say it that's probably the first time I say this online I'm very exhausted to the Vanilla OS team always say to me, don't give a shit to that person which is the founder of the BlendOS project.

But I must say that I am very, very, very exhausted of the situation because we started talking about one feature in the discord the public developer channel and some days after that that person announced that thing and that could be one time you time free time but that could be a problem because we are taking our time to develop the Vanilla OS 2 version because we want to develop everything in the right way with testing, with inventing a lot of technologies.

And we are taking a lot of time. And not every time, but a lot of time, I talk about Vanilla someone tell me ah but blend os is doing the same not blendret is not doing the same blend os is rushing uh very poorly a lot of our feature our features just because he has absolutely no idea and no skill to do that. I hope this is clear. Remember how I said before we started recording, if there's anything you want me to cut, you can send me a message.

Ah, you can take this. That's no problem. Okay, that's fine. Okay. When I brought you back on the show, I didn't think you were just going to rant about BlendOS. This is not what I expected to happen. Oh.

That happened. It did happen. I was unaware that you had these sorts of feelings about Blender, Wes. Yeah. Yeah. I'm a bit exhausted about this whole situation. I didn't realize there was

a situation in the first place. Yeah, I was unaware. I mean, that's pretty clear. Vanilla OS was created before BlendOS was a thing. And since we are talking about this, I asked the BlendOS founder, because at the start, he was using Olmos, which we were using Olmos before

AB root. Olmos was a technology to gain immutability in the system. He was using the exact copy of Olmos, the same exact source code of Olmos. I asked him to at least give the credits because that was not a fork. That was exactly a copy-paste of the code changing the logo. I have the screenshot somewhere. I don't know. Probably I have a screenshot. I have the screenshot somewhere. I don't know. Probably I would say screenshot.

He said to me that that code was very, very bad and he will rewrite the code. So there is no need to give the credits. I mean, what the fuck? What? What? fuck what and that's on discord that's a public conversation on discord and probably the post are still

in our discord server and I asked him I was generally friendly with him I asked him why put effort on a whole new distribution? You can work with us on Vanilla OS. We can develop those features together.

He said, ah, maybe I could work. Yes, yes. Some days after that, he developed the exact copy of Apex. Then Luca Di Maio, because that was using Distrobox under the hood like Apex. Then, Luca Di Maio, because that was using Distrobox under the hood like Apex, Luca Di Maio said, can you at least give me some credits because you are still using Distrobox

behind the hood? And he said, ah, I'm rewriting everything because that's shit or something like that. And that guy rewrote everything that Distrobox did just to not give the credit to Luca.

Like, what the fuck? I'm having a lot of fun right now. This is enjoyable I don't know I mean that's a public conversation you can find that on Discord I don't know yeah

I don't know where to go from that um well i before we end off i guess we can sort of actually briefly talk about vanilla os a little bit uh what is like what's been going on with the project i've not checked in for a while. Has there been anything exciting that's happened over the past couple of months? We had a talk at Guadec. I don't know if you... Oh, that's cool.

That was a very hard talk. That was a very hard talk with Pietro as the speaker. There is a lot of work. We are almost ready, at least for the public beta. But we should have ready. We were expected to be ready for this summer. But then there was a lot of work to be done. So we were not ready this summer. That's why this happens when you don't rush features. But, okay.

It's working. Vanilla OS 2 Orchid, codename Orchid, is using a world-different structure compared to any other Linux distribution. It's entirely based on OCI images. It's using a custom system unit, which does not replace the system. Just the AB root is used before system D for some tasks.

It's a very different combination compared to other distributions, but it works. I am literally on Vanilla S2 at this moment, so it's working. We are almost ready. Everything

is going very, very, very well, and I am very excited to announce the public beta. Awesome. But that's one of the things I really like about what you guys do over at Vanilla. It's not just, like, a lot of distros out there really... I know some distro devs don't like me saying this.

I know some distro devs don't like me saying this, a lot of distros out there are basically just glorified configuration files. But Vanilla OS is actually, you are actually building different tech that goes into this. It's actually a different thing that provides a different kind of experience. And that is really cool. It may not be an experience that everybody likes. It may not be an experience that works for every use case, but it is a different sort of project than,

than any other distro out there. And that's cool. Yeah. Yeah. cool. Yeah, yeah, yeah, yeah. Thanks. And I, yeah, I'm happy with my terribly broken arch system that is held together with lots of glue and is ready to fall apart at any moment. But Vanilla OS is cool and I'm happy that you're on your way to getting the new version done. an abroot v2 can be used with any other distribution it's very simple compared to to the v1 so that's that's good yeah it's cool that there are

there are options for doing an immutable distro because right now it's really just OS tree like OS tree is sort of the It's the way that people usually go about it but having a different way to do it might you know, it might provide a Better experience in some in some specific cases. And at least Ebiru does not require you to

lose your mind behind because OS 3 is very, very, very confusing. You can't just say, ah, I will start using US3-Mice distribution, because no. You need a different structure.

You can't simply port your distribution using US3. There are a lot of configuration, command line interfaces, and things like that. While Abirute just say yeah you can download the abirute binary put that everywhere anywhere define your configuration setting up the link to the oci image you want to use which could be an arch linux Ubuntu, whatever you want, or your custom made. And that works. That just works.

It just works. Well, on that note, we are almost at two hours now. We have been talking for quite a while. Wow. We have been talking for quite a while. Wow. So I think it's about time to end off the show today. Let people know how they can get involved with bottles,

what websites they should go to, all of that stuff. Yeah, to contribute to bottles or just discuss about bottles you can go to usebottles.com and click on the discord link and join us on discord that's simple everything as this could said on this course so just join that channel we'll be happy to discuss with them. Easy. Everything's just in one place. That makes it easy to find.

That's a proprietary platform. That's a shit platform. Matrix is a... Yeah. Just do everything with a mailing list that's the that's the correct way to do it like the fedora mailing list is hey at least the fedora mailing list has a forum interface that you can view it with which makes it a bit easier to deal with. Um, but, yeah. No, I, I, I am happy with Discord. I, I, actually, maybe not happy. I am, I accept Discord. Yup. If there was something better, I would use it but Matrix Matrix I wouldn't

say is better it's just not Discord is there anywhere else you would like to direct people to or is that all you would like to mention no no

honestly no okay easy cool I'll do my outro then No, honestly no. Okay, easy. Cool, I'll do my outro then. So if you like this and you want to see more stuff from me, my main channel is Brodie Robertson. I do Linux videos there six days a week. I have no idea what will be out when this comes out, so go check that out, see what's there. I've got the gaming channel that is Brodeon Games, and now that my internet works correctly,

I can stream things without randomly dropping frames. I should be playing through Armored Core 6 and maybe still Kingdom Hearts Dream Drop Distance. If you are listening to the audio version of this, you can find the video version on YouTube at Tech Over Tea. And if you want to find the audio version, pretty much any podcast platform out there, search Tech Over Tea. There is an RSS feed, and it's pretty easy to get your hands on.

I'll give you the final word. How do you want to end the show? Peace and love. I like the sound of that. See you guys later.