User talk:Bryan Hilderbrand/Meeting Notes (03FEB)

Raw transcript:

Yaron: On. Hi Brian.

Bryan: Theorem Alex.

Yaron: this is like the

Lex: Hi.

Bryan: I know.

Yaron: theory.

Bryan: Cindy can't make it until halfway through. She Had on our calendar and then someone scheduled a meeting over it, but

Yaron: Yeah.

Bryan: she's gonna try to jump on halfway through

Yaron: Yeah. Some people are over scheduled.

Bryan: she's gonna try to jump on halfway through

Yaron: Yeah. Some people are over scheduled. Cool, are you recording already?

Bryan: Well. It's, it's just got like, the captions being recorded, not that.

Yaron: Sure. So that's a yes, okay.

Bryan: Yeah.

Yaron: Hi Marcus.

Markus: Hi, our own. Hi everyone. Are you

Yaron: um, Okay, cool. Well, we can start already and

Lex: Five.

Yaron: The transcript is going so. Feel free to share any any thoughts you have?

Markus: Wonderful.

Yaron: Direct. Yeah, you want to talk about pickles or anything else? So good time for it?

Rich: Here.

Yaron: So far pickles have been mentioned in the last two transcripts. I figured I would go, you know, if they going

Bryan: What? I will add.

Yaron: um,

Bryan: I've never personally heard of a real pickle before like a fermented pickle, so I caught them very into that whatever a few times ago or whatever was I'm a bit fascinated.

Yaron: yeah. Yeah, it's just really a return back to tradition, you know, this whole thing with vinegar and pickles. That's just a new A newfangled idea. The real thing is letting it sit in a barrel for a while. Yeah. it was good enough for our grandfathers.

Rich: Right, that the advice I always gave

Yaron: but,

Rich: my kids was, don't ever put anything in your body that hasn't been around for a thousand years.

Lex: That's a good one.

Yaron: Eight to see what should?

Rich: Coffee tea.

Yaron: Oh I see not. Not that, that literally hasn't been around for a thousand years, but things like it.

Rich: Right? It's it's these um, like you know, the The Vaping, right? Like, you know, the world has never, you know, humans have never put whatever it is that's going into their anyway, I could ramble.

Yaron: Right.

Rich: the super simple Maxim is if it

Yaron: Yeah.

Rich: it hasn't been around for 200 years, don't do it.

Yaron: Yeah. Well, tobacco is. All right, then. but,

Rich: I mean, I'm not saying that everything's great, but I'm just saying, like, don't know.

Yaron: You know.

Rich: know what you're putting in your body that hasn't been around.

Yaron: Yeah, no absolutely sure that's definitely true.

Lex: You.

Yaron: um well we I guess we can start probably other than a few other people will join so Marcus, I saw that you just that you added, I guess maybe this morning the well not morning for you but sometimes earlier today the blue spice information to the infrastructure solution page. Yeah, I mean, I'll I'll just let me just say it. My inclination is to go with with Lex's solution for this thing for two different reasons. The first is that it works. And I mean, we know it works because cuz, you know, he's it's set up and Brian tried it, and it seems to do everything. I mean it's it's custom made to specifically to do all the things that are required. Unlike, for instance, the blue spice solution, no offense to Blue space but that one's obviously custom done for for blue spices own needs. But we can talk about whether my reasoning is right, or not, the second is that Lex has had you. For whatever reason, the most inclination, Or involvement to to do this. And, you know, at obviously the NASA guys are extremely busy. I mean, the the the main Mesa guys,

Lex: You.

Yaron: yeah, everyone's everyone's obviously busy with things so, so, you know, that seems Lex seems to be the person who has the the most Drive. And therefore, the most willingness, presumably to keep working on it in the future. um, so that's my that's my thinking but you know if anyone else Wants to comment on that. Pro or con feel free.

Rich: I'll make a quick comment. Um, I think Lex, you know, as far as I'm concerned you have my full confidence. Um, I'm not already familiar with your approach but I really do trust and believe that your, you know, you think through things in the most, it's logical way that I hope for. And so Other than the fact that I'm already invested in, as soon as I eliminate that. Aspect. I, I think I look forward to learning more about what you're doing so rock on.

Yaron: You.

Lex: I'm, I like to ask you a question there, because You know what? I came up with this. Media Wiki manager. I actually renamed it. Is not the Builder. It's just the deployment mechanism that I deem very simple. So, I'm not sure what you mean by saying you want to go this way. You know what I mean? I mean,

Yaron: No. Well.

Lex: for example, I'm check the your page on media Wiki org. Where I? I filled in riches table a little bit. And that should clarify a couple of things. Because what I'm describing is not the build process as I I I hope I explained it last time but maybe I wasn't too clear.

Rich: Well, let's okay.

Bryan: I noticed and both Marcus. I think in Lex, kind of agreed that Docker was kind of the way to package something up. and distribute it, but wasn't necessarily the way to get the meeting Wiki core and everything's created the first time. So it can be packaged up how quickly the notes.

Markus: so, I think what what legs mostly does arm is he describes a A schema or an interface as a developer. describes an interface so he says, interface.

Yaron: You.

Markus: So he says, whatever packaging process there is be Mesa or data specifics. I require the output to be of the following structure and then given that output. So that is a translated into Marcus Beach. It's basically a tarball, it's a database down and it's a definition of infrastructure, using a composite file. And then he says, okay when I have these three things, I can now move on to the next step which is built a working infrastructure. Given these three definitions. So I I think that is a very structured approach and we can well use it. But it that there is a follow-up question that is do. We assume in or yarn to you assume that there is a common core of extensions and how do we Define these? So because that process could take the output of Meza. As long as you guys can create a tarball, it can take the output of blue spice of the, the process I described in packaging and it can use any like probably a baron media, Wii guitar ball as well. So, I don't know. So that would be the next step. How do we talk? How, how do we want to? To work in the packaging. But I think having this having this

Yaron: Right.

Markus: definition, this interface definition is a good thing because then if I want to say, say I I want to use this canasta's infrastructure but I want to build my completely own stuff, but I wanted to to build on the deployment mechanisms then given what Lex defined we can do that. Right. So we can just use that and throw it into any tools that are follow-ups. That rely on these three things. Table database and definition of infrastructure.

Yaron: Yeah. Okay I think I understand. So so Marcus briefly to answer your question. The real goal I think is to just create a system that will let people Define their own extensions and skins and then you know packages wiki page data structures the end and create their own products. It will be nice to have some, you know, some kind of Define products that everyone agrees are nice, but I think the real thing is just to have the the let people have the capability to create their own. But yeah, this is something. This is really what I I was planning to start the meeting with but then forgot if you go to the project Canasta page, I've split it up based on what we talked about last time, this is really, I think how it should be defined that there's actually four components to this project. um, And what what I have now is one and two, we're we're incorrectly packaged before. Described before is one thing. The first thing is a way to create, you know what, I call a starter installation, the actual the thing that you want everyone to have, And there's various ways to do that. Of course you can just manually do it if you want. And then the second is, once you have that how do you create a an image or whatever it is? To to, so the other people can have. That on their system as well. And that I think is really what I, that's what I want to talk about. Number, the second step. And so, yeah, I mean, I know one of one of the blue spice products is products. Main strength is the first step and that, and potato, you know, potentially, That can be used directly for this also, but I mean, is that really the issue, Lex and Marcus is that the the thing that both of you were talking about how how Lex's solution. I guess we can call it media Wiki manager, I'll still call Alexis solution.

Lex: Yeah, can you?

Yaron: It's different from the blue spice thing.

Lex: And can I elaborate a little bit on what it Marcus said, Marcus. Thanks a lot for explaining this. I also think that the mission you gave us is to do an Ikea slash NASA deploy. Theme. Now why why do I refer to the two Ikea and NASA have two things in common? When they build. Modules. They must be phenomenally simple to install in space and in apartments. Ikea has the idealism that you can assemble the kitchen table, ideally with nothing except your hands, maybe a screwdriver, maybe a wrench. And I tell you, I guess NASA is also operating on this because in any tool you need in space is a risk expensive and it might be missing. So I understood that the tool set that the customer needs on site to maintain the installation must be as simple as possible and I just posted a link where you can see what I I added this check. What has changed mechanism because

Yaron: You.

Lex: to keep the tools or the solutions to the challenges separate. Let's say we can have several tools deploying it and then we can have a completely different tool maintaining it. So, if you look at the check Dash extensions that Dash div.sh file. That's a two command. you know, bash commands just using the diff command to check what has changed in the extensions folder and what has changed in composer, Json. Now. Of course, the customer cannot act yet on this, but we can develop a tool that can handle this. Honor and handle this information, completely independent of the deployment and build mechanism. And I think that's where the strength of the approach comes in because that means you can have competing Solutions. You know, I can start developing something and then Marcus comes up with a different approach and we can compete between the two approaches and then Decide for the better one. So, you know, divide and conquer me. See.

Yaron: but yeah, but Alexa, I mean, obviously anyone can can have can

Lex: That.

Yaron: solution for any of these things, but the whole point of all these meetings from my perspective is to have something that at least for now is the default recommended approach for all of these. I mean, that's the whole point. I mean,

Lex: Okay, now, I understand that. So if you all agree that as Marcus has said, the interface components of the docker compose, what was it, the MySQL dump and the Turbo file if if you agree on that, fine. We can we can take it from there but this doesn't cover the build process.

Yaron: You, what do you? What do you mean by the build process? Do you mean what I refer to as the first

Lex: Well. Well, the creation process, you know,

Yaron: Yeah.

Lex: blue spots stats or Mesa can all deliver Amelia ql dump. A darker composed file and a turbo.

Yaron: oh,

Lex: And then I don't know whether, you know, I advocate this because I think

Yaron: okay.

Lex: to Ensure that someone is running ansible on. You know we're thinking about the bakery around the corner, right? Not necessarily Boeing. Wouldn't need canasta. I guess or NASA wouldn't need

Yaron: That's not true.

Lex: canasta.

Yaron: That's not necessarily true at all. A lot of large organizations will

Lex: No.

Yaron: have a very small. It stuff that can handle this or maybe it's just one person doing a Skunk Works thing.

Lex: Okay.

Yaron: If?

Rich: Well, what what NASA needs is Media with the easy Administration. Now, that's not meant to be a plug back to Meza, but that is what Meza is meant to be. So, Everything you're talking about is a deployment system. Am I understanding that you're drawing a distinction between the infrastructure buildup? And then the distribution of whatever it is that you've built, right? And so if media with you manager will call that maybe mwm another them. Um, if that's Distributing the build. Then it leaves the question as to. Who how are we building, right. Am I following?

Lex: Well, yeah, but ideally it shouldn't depend. Let you know that you know, the

Yaron: But I think so.

Lex: Yeah. But sort of just very quick, you know, the difference between puppet and ansible. I mean, there are several. But one of the main ones is that puppet as a orchestration system, has an agent on the server So it's sort of tied back to its DNA whereas ansible compiles shell scripts. Deploys them over SS. No Python scripts. Deploy some over SSH and then deletes them. So the server has no clue how it was born. And I think that's a good thing. You know, it separate the concerns don't have vertical dependencies What do you think of that Marcus? Can you relate to that?

Markus: Yeah, I guess so. I was wondering. so basically, I can, I can see that argument of Mesa of you, which that this essentially management is quite, so we need to think about the ongoing. Managing. So, the way with Docker, I think the way, if it's done in a good way, it's fairly easy because I can just, you know, have the same database but use another Docker container, which has a different setup. So we do this for updates, for example, we have, we throw away the old Docker container wire the new Docker container with the data, and then we have new set of whatever functionality there. But that of course requires quite a bit of Care about Docker container compatibility. So it's not a super easy. It, you have to put some work in the, in advance for this. So, I don't know, I assume that missa has some Works more on the basis of change scripts. In this case, is that correct? Or scripted changes. So you can you can apply them to like any instance.

Rich: Up the meso philosophy is that the Mesa command goes through and makes sure that things are the way they're supposed to be. And so if it if you execute it and it finds nothing exists, it puts it there. If it finds that it's already there, it leaves it alone, if it finds that it's already there, and it's at a whack, it's straightens it out. Um, so how do you get Mezza? Meza deploy, how do you update NASA Mesa? Deploy so, from the perspective of the administrator once you're set up, You know, it's effortless to get it and and you tweak it, you know, in a, in a, in a localization, config file. And then you just keep sure that things are the way they're supposed to be. And so if it if you execute it and it finds nothing exists, it puts it there. If it finds that it's already there, it leaves it alone, if it finds that it's already there, and it's at a whack, it's straightens it out. Um, so how do you get Mezza? Meza deploy, how do you update NASA Mesa? Deploy so, from the perspective of the administrator once you're set up, You know, it's effortless to get it and and you tweak it, you know, in a, in a, in a localization, config file. And then you just keep hitting as a deploy once a week. And you're always in fact, even has what they call an auto deployer. Where if you enable the auto deployer, it just it just keeps itself up to date all the time. um, And so if I'm understanding right it includes the distribution mechanism. So anybody who has Mesa Has both. The build. And the district and the acquisition, right? It's being it's being obtained from git. Um, it's the ansible scripts that know how to go out and get the pieces that it needs from all of the reliable sources, all the appropriate versions, all of, that is maintained the, the current system. One of the things you can count on is

Lex: You.

Rich: that. Well, while I know that the NASA,

Yaron: You.

Rich: Owners of Mezza are not

Yaron: You.

Rich: Owners of Mezza are not

Yaron: You.

Rich: Owners of Mezza are not

Yaron: You.

Rich: Owners of Mezza are not

Yaron: You.

Rich: Owners of Mezza are not actively, they're not they're not. publicly active, they are 100% committed to maintaining a long-term support version of Mesa, which I mean, because simply because 1.31 is still has another year of life in it. They're not motivated to move past that. Urgently right? I mean they certainly will but you know if we're all saying that hey meeting with e35 is the current long term support and so that it only makes sense, you know what is it about Canasta that wouldn't work on 1.31?

Yaron: but okay, was that a question or

Rich: I mean, yeah. I mean, I guess what is there? The question I want to ask is, is there a tacit assumption that that this is the 35? Plus. Endeavor or should we agree that it should support? 1.31 is is this Canasta project going to be incompatible with people who are still on one.31?

Yaron: I don't see a reason to support anything below 135. The the target audience is people who don't have media waking,

Rich: Okay. Then then that certainly is a problem for mezzo because they will not, they are not committing to a 35 release date for Mezza.

Yaron: Well yeah, yeah.

Rich: And so then that's dead in the water

Yaron: I mean

Rich: for us. If, you know,

Yaron: Yeah. Yeah, that ties into just a general lack of time on part of the Mesa. Developers Mesa slash?

Rich: First, they will it's it's not a lack of time. It's it's it's just not their priority right now because because

Lex: Hmm.

Yaron: Okay, you know, that's the same

Rich: 31 another year.

Yaron: thing.

Rich: Yeah, and I'm not, I'm not

Yaron: Okay, fine.

Rich: advocating. We go down that road. I'm just saying that Meza is incompatible with canastas. Requirement that it'd be 35 forward. so,

Yaron: Yeah. Okay.

Bryan: well, one thing, well, maybe Canasta

Rich: I won't mention it.

Bryan: is trying to do is also, maybe it's, it's goal, is to be built on 1.35 and 1.35 only but still not. Not only for people that don't have media Wiki yet, but might have midi Wiki on some old, you know, 1.26. And then there's a pathway to say, here's your data, here's the way to get your data dump and then here's just the way to get to 1.35.

Yaron: Um, yeah. I mean it would be nice if there were supported but if that's gonna add a lot of complexity to the code, I would say, I don't know. I I don't know how it works with Docker and all of that to to transpose a Docker thing onto an existing solution. I would say if it has any complexity, then it's not worth the effort. That's my view.

Markus: Those were so in my view, the complexity is not the infrastructure. So It basically downgrading would maybe be bigger deal but for upgrading stuff, I mean, what kind of complex infrastructure do we expect? I think the most complex stuff would be the elasticsearch component, which requires some underlying data structures but elastic searches, highly changeable. So I don't see a big deal here where I see difficulties is in the upgrading procedure for certain extensions because and what if you upgrade you have to rely on the extension, providing a correct recipe to upgrade through all the versions and I guess we all know how to use like extension schema update and things like that. But if we create a generic mechanism for this, then this would be one of the requirements and I think we should have we should Define like what versions we expect to be. It will, and I would also. I would like to agree with yarn here. So if we start this from fresh, I don't see any benefit in supporting, like all the media Vicky persons. I would make it a requirement to say, okay, upgrade procedure from now on should be smooth. So when we start Canasta, ideally as does media Ricky, you can upgrade through all the versions from 135 upwards to the next 50 years but you know how far we should go back. I don't I don't know because I also assumed that most of the for Canasta targets is new and fresh installation. So they don't care about older things. There's one question about Messer. So, which what you basically saying is Mesa is a system that is designed as a one-size-fits-all solution, so there is not. So, for example, if I come, and I want to use blue spice extension set with Mesa, that would not be possible with e with, with the easy effort, right? So that would be a lot of effort because it all relies on one integrated system. No? Okay.

Rich: It would be very easy. So Meza has what they call Core extensions, which are managed by them as a project. And then it has a local config file

Markus: Right.

Rich: Config file called, Meza mesolocal extensions dot yaml. If you guys are familiar with that, I bet you are. So there's a local extensions yaml

Markus: Should.

Rich: file where you define or third party extensions that are not core. So you would just point them to the git, repositories identify their name, identify their repository identify um, the version you want and the installation map that method whether it's Standard or composer, and, and it's a four lines of configuration for additional extension. in fact, let me just

Markus: Then.

Rich: You guys.

Markus: Then why would it be so difficult to to update to Media Ricky 135? That's what I don't understand because I would just really find stuff.

Rich: Right it. And and that question.

Markus: in my,

Rich: that for for the NASA folks who are maintains and Darren who are maintaining this, this is a safety critical application for them. And so there's a degree of, there's a pedigree process, they have to go through and they're not going to take any risks. And so they're not going to They're not going to throw themselves into a situation where they have an unstable safety critical system. And and so they run, they do testing, it's extremely reliable. I mean, the degree of reliability that they go through is fantastic, and we would benefit phenomenally from it once they get there. So, For them to. I think that the core changes in media with e35 dropping the two big challenges are is that they do saml integration SSO saml integration. And that needs to be extremely robust and then they also have all the parsoid integration, automated automated deployment of parsoid and automated configuration. So they have a Wiki Farm And if they've have, you know, if they have 12 wikis, each one needs to have its own parsoid configured. And and so all of that is done. As part of their system. So switching to 35, they need to Personally verify that all of the core extensions are. Pass all of the tests for 1.35, we could help with that. Like, I can't commit any of you guys to anything, right? But I mean, like, if we were, if we took the amount of energy that Lexus put into documenting and developing the work that ours that he's already put into this. If you were to divert some of that attention to them to Mezza, I think you'd have a one about 35 system running. I think the problem is is that James and Darren just haven't had time to go out and look at all the core extensions and see that and verify that they pass all the compatibility tests they have a couple of Internal they have a couple of custom extensions that they have developed that they rely on. That can ask it wouldn't need, we could shed that and probably have a 1.35 functioning Mesa version. In a few days. So I think James's stock because he wrote some extensions that their particular implementation is dependent on. And he doesn't have time to make that one.35 compatible or he's biting his time. and, But for all of the standard media Wiki extensions, you know, if this group could look through that list of core extensions, and let me just link it.

Yaron: Well. I want to get back to. to something that that the came up earlier, I mean, still and sold on lexic solution, I

Lex: You.

Yaron: I guess more than Lex you are. Because, you know, I only you just want to come out there's like alternative Your solution.

Rich: You.

Yaron: But you know, getting away from the fact that the they're always gonna be competing options for all of these things. I do want to have a recommended approach for everything for people like me who don't want to. A think about all the different options and just want to know what, you know, which set of commands to run, it seems like your solution, does it all build, what's it called update? And all of that stuff.

Lex: Where you're talking about Maison are

Yaron: No.

Lex: not mine.

Yaron: no, I'm talking about yours and when

Lex: No that no no that that doesn't

Yaron: I go,

Lex: update it.

Rich: yeah, I was

Lex: It it it created it.

Yaron: The solution.

Lex: clue. What's happening. As I mean you know Marcus's observation was the perfect one it. I'm describing interfaces. That's exactly. That's very well. Put I'm talking about interfaces and you can you can connect me out to those infant interfaces.

Yaron: okay, I'm

Lex: That's what I mean, honestly.

Yaron: it's I'm confused. Let's take it one step at a time. Okay. You can't update an existing so solution with your code.

Lex: Oh well, okay, that's not entirely true. Yes, I have this change to 135. But it's a it's a little bit of Sledgehammer approach. It's not an elegant. Change of the target system, you're just you're you're replacing everything except local settings and the and the images and then run update PHP. That's how you know, actually you were asking how do you do it? And I was describing how I do it but that was bread in my own kitchen and I'm happy with it. But that doesn't mean I would sort of recommend it directly to to others. So,

Yaron: Okay.

Lex: You know, maybe I I mean and Brian can remember that about two years ago. I coined the term flock to Meza. Can remember that? And I suggested, you know, let's let's take a political decision and say, okay now let's stick to Mesa and we're gonna all Adorn it, until it meets. Everyone's And and my the thing I would suggest at least as an option is this dockerization? that and then you know, if if you can give me a branch on Meza where I can play around with that and just, you know, Then then I'm happy with that. No, no. It's it's really I was just doing my homework that you gave us describing how we do it.

Yaron: so,

Lex: But as I, yeah.

Yaron: what was the point of this whole GitHub repository, you created

Lex: Well to to showcase.

Yaron: You.

Lex: No to Showcase because I always, I want to let my, my code speak code is always better than PowerPoint. Because it never lies.

Yaron: What?

Lex: So no, honestly. I mean it works but it's

Yaron: That's like reading a series of fortune cookies. I have to say, I I don't understand what you're talking about. Okay, go ahead, good sorry. Okay, I'm back.

Bryan: Alright, really quick. I think in the last meeting, Marcus kind of described. This is a there's two important parts. There's the mini Wiki creation part. And then they're the packaging that thing to distribute it. And that's, that's the docker kind of portion of it. But it's not handling. The first part of right now of creating a media Wiki stack, that doesn't exist before.

Yaron: Yeah, well yeah, you're talking about the the the first part what I laid out is the first part of project Canasta, creating the initial installation. Or you start or you talking about something else?

Markus: But what I think is so we have two

Bryan: For example, me.

Markus: options here, I guess option. One is we continue discussing this in all its aspects and deaths and consequences and I You know, I have a tendency for option to now I promise you, we will still be discussing this in two years. The other option would be to just decide on one. And actually, I can also go with with Lexis solution and actually Lex. I think it might be in the strength to say this was quickly crafted because then it leaves a lot of, you know, that's agile. You know, there's a lot of it's easy to understand for everyone, we can reinstall the business, they have a good entry point. That is your definition of what you need. So we are can try our out distributions against this once it's working and see if then the output of Lexis set of scripts is then a working flavor of media as we all like it to be right? So, and and maybe give it give it a little bit of work and should it. That this is not a good solution, I think we will find out early in the process.

Lex: Mhm.

Markus: But that's just a suggestion.

Lex: But yeah, but then, you know, in relation with Mesa, this would be an alternative for Mesa and Rich. I understand Mesa deploy updates an existing mesocide. So, this would be an alternative approach to the second Mesa deploy command. Right. because, It there you cannot build the system from scratch with my Approach here. And I I totally unrecommend using dataspex system builder, that's a business. That's why I created this new Repository.

Yaron: oh,

Lex: Yeah.

Yaron: Well yeah. But you do recommend using this new repository, or you don't.

Lex: It's not the same. It's it's two different things.

Yaron: I know. But do you recommend using the new one or not?

Lex: well, it's the only one, I can't recommend it, you know, really relative to something else but it's

Yaron: Right relative to not using it. Like using Mezza or or blue Spicer or a nut.

Lex: Not the, the big. and,

Yaron: I'm sorry, I may be asking the wrong question here but I, you know, and

Lex: no, because

Yaron: I,

Lex: No. I I'm very grateful to Marcus because, actually he, he understood it correctly. This is about the potentially useful interfaces that we could could have because my, for example, As I read on mezas requirements, if you want to use it on Mac or Windows or a different flavor, that Linux of Linux, then, sentos and red hat. They you recommend going on vagrant or virtual box right now? That's fine for me. I have one developer who absolutely loves both of these things and works on Mac.

Yaron: Okay.

Lex: So he would never go with that. But that's, that's a different problem. I'm just saying adapting ansible for Windows and Mac would be quite a challenge, I guess. Not sure whether you want to invest that time. So that's another question. How to, what extent do we want to support native Windows and Mac? Insta installations without a hypervisor between the installation and the operating system. What's your take on that?

Yaron: Personally I would say I mean it depends on the difficulty it's not high priority if it's easy to do then great. If it's if it's difficult then I would say

Lex: Well, no, but let's say, you know, if if our Target customer is for example, students and artists and Librarians and, you know, people like that. 80% of them are on Mac. And if you tell them, they, they should sort of install virtualbox first Maybe.

Yaron: You know, running a web server on there or want. There's their computer to be a public web server and the it's the I would say if anyone can correct me if they disagree, but I would say definitely the target audience is people who weren't a run of public Wiki or at least a week.

Lex: A public. Okay, okay. Okay.

Yaron: But not necessarily public but you know for for a community of people as opposed to just for themselves.

Lex: Yeah, but then why don't we go? no, I I wonder whether you're you're you're understanding my Approach as more than it actually is.

Yaron: Probably, I think.

Lex: it's not a it's not a fully-fledged thing like Mezza, you know, to know extent, my idea was to to showcase the interfacing idea. I have in mind and it works on my systems. And I'm, I would be interested in in seeing whether it works for other people, but it's really not that I, I'm, you know, given the selection we have that I advocate for my solution, it was really just a poster presentation.

Yaron: Okay. Yeah, I think

Lex: And you understand what I mean.

Rich: so, let's

Yaron: Because I'm assuming because it was based on code that you're actually that you're already running. Well there's any there's that and be, there's the fact that Brian actually used it to install media Wiki for pretty easily from what I understand.

Lex: Yeah, you know, this is based on my my idealism that I say, put my money where my mouth is, so and I eat my own dog food and I want to try it out with someone who's never seen it before. um, so,

Yaron: Sorry to belabor the point but what is the weakness of your system? Is it just the upgrade part. It seems like installation works fine.

Lex: No. It it's just interfacing it. What you see.

Yaron: I don't know.

Lex: Look for example, what I when I say check what has changed have you? Have you seen that? I've got it on my on my GitHub page. That's just the bare information that I think could be useful. To come up with something. But that's not implemented. And, you know, it's it's it's it's

Bryan: oh,

Lex: very simple and stupid and and maybe even rudimentary but As I said, it's it's just interfaces. It's not a fully fledged solution as Meza is.

Bryan: You're only you get what what the system that looks built, does like what it's grabbing and how it created a running midi Wiki instance.

Yaron: No. And I, and on a more General note, I fear that I may not be the the right person to be leading this kind of discussion because I know I think the least from of anyone here about, what all these systems do, I'm just I, I just want this to be done, but I don't understand how any of these Solutions actually work. Um, but yeah. But and so the the answer to any question is probably no. As far as like what I what I understand.

Bryan: I was like one point I think it'd be falated, just jump into a solution and just say that's the right one, it's a pretty important decision. So you know, maybe the idea of creating competing You know, teams and then testing each solution out in a month or something is the way to go or whatever it might be. But functionally, the thing that Lex did it took what was in existing media Wiki? and there was a kind of a dated dump

Lex: It.

Bryan: from it and then it just grabs that pulls that in and makes a Wiki on your machine from that structure that had already existed.

Yaron: That's that's what we need. No.

Bryan: Or but then what how your you originally just said you wanted someone that doesn't have media Wiki to have something that's working, right?

Yaron: Yeah.

Bryan: So, Who, how is that original waking me?

Yaron: Well yeah again that's that's what I I now. Call the first step of project Canasta. Out of the four is creating that an initial Wiki. I'm not worried about that step because whoever wants to create their own product, you know, there's various ways they can create a Wiki that matches what they want other people to have. You can just go through the steps of installing, media, Wiki and Whatever extensions and skins you want, and then you're done with that part. if I understand what you're saying, correctly, And of course, if you have something like blue spice, with hundreds of extensions than it, probably makes sense to have something more automated, but whatever it is, there's going to be a way to do it.

Markus: Well, I mean what I seen in Blue's poison I did at a certain point. I would like to advocate for advocate for that point is I think those places really strong in building the turbo you require for. But I am not, I'm not saying our Docker building process. So getting this out, A standalone application. That's not where we are very strong. That's a lot of hand work. Manual work there. So and and that's Yeah. So Well, I mean what I seen in Blue's poison I did at a certain point. I would like to advocate for advocate for that point is I think those places really strong in building the turbo you require for. But I am not, I'm not saying our Docker building process. So getting this out, A standalone application. That's not where we are very strong. That's a lot of hand work. Manual work there. So and and that's Yeah. So No, sorry. I don't have anything to say.

Lex: That one more question mark is, there's a lot of people who are religiously against using Docker and production. But I understand that you are using Docker containers in production. At customers.

Markus: Yeah, yes, we have mixed experience. So with as with any like virtualization, so the experience does not stem from this being a Docker, but from being a container of some sort of any sort. So whenever you you have integration work to do and as I said, like integrated it set up correct firewall, rules change, the port of whatever that you need to manually change things in the docker and the VM in whatever. And that always brings you brings trouble because then thinking of the object process has reached that. Then when I have manual changes to my Docker, containers are meant to be highly standardized. So you virtually, it's, it's a deadly sin to change anything inside the container, right? You're not supposed to do that. So that leaves you with creating a container that has ultim Accessibility, which then is almost as complicated as having a better system, a native system. So But that is also in my view. That's also the reason we we should aim for darker because if you want to maintain an abroad basis and we want to sanitize, then Dockers or a VM or, you know, any sort of automated infrastructure is the way to go. And if people want to to, to do something different, well, in the case of docket, they can just simply read the docker file and do this, that many steps manually on that machine, right? So and I guess it's similar with answerable. That's very remember correctly. And circle is a set of sharescripts in essentially that are fired in any order, but correct and I'm not want to diminish answer, of course. I know it's it's complex but So yeah. so, don't

Lex: Yeah. So

Cindy: Here.

Lex: Yeah, but they see then the question would be what do we abstract out of the container? What goes inside? So for example, what is volumed in and what is controlled by environment variables? And there we can play, you know the

Markus: Right.

Lex: Separate.

Markus: Right.

Lex: stays the same that that's that was the

Markus: Right.

Lex: stays the same that that's that was the

Markus: Right.

Lex: stays the same that that's that was the

Markus: Right.

Lex: stays the same that that's that was the

Markus: Right.

Lex: stays the same that that's that was the original idea had talking about this abstraction layers that should be our You know, this is implementation independent, it's really the question. What is managed on what? Level, right?

Cindy: I encourage you all to read about kubernetes. In this is that I've been talking about the idea of having orchestration around the containers, it's not the containers aren't the solution, it's that they're part of the solution. And that what you need to do is have infrastructure around them to orchestrate the containers to make sure that the containers come up and stay up in the appropriate configuration and number that that you need and so containerization isn't the solution? The other thing I want to say is that you really need to decide what the targeting guideline is. You know, if the target environment is a Windows laptop or a Mac laptop, then you really want to have some sort of install package, that'll install in that environment. You know, whether that be Docker or whatever, you know, I run Docker on my laptop at every time I reboot, I need to start everything up again, you know, that's not something you want to do in a production environment if you've got now. Of course again. If somebody's running this for their own use on their laptop, that's a completely different use case than trying to run it for an Enterprise. You might also want to think about whether You know, an easy entry point into this is just Cloud hosting and having if folks want to use it they just you know, contact you for a cloud instance. And then you don't have to worry about that what their environment is and that might be a way to get an additional initial. if not prototype and initial capability out there and then, Then with further development in the future, you could actually deliver it in a package that people could install within their own environment within certain parameters. So but the key part is what, environment, choose an environment, any environment that you want to have this thing live in, and then figure out what the best architecture is for that environment.

Markus: I have to say, I have to leave. So sorry for this. I go with any decision you make and what's fully supported. Thanks.

Lex: Job.

Yaron: Hi Marcus. Thanks.

Bryan: It's just looked a little bit kind of, with Lex on. Docker Docker compose. Docker swarm and kubernetes, but is there for kubernetes? Just the one site that I was looking at, as a comparison, was really talking about, Where you would be doing orchestration on multiple hosts. is that a real benefit for kubernetes over like Docker compose or

Cindy: not necessarily, it doesn't have to be multiple hosts but the idea is is that you you create Pods that have your containers and you create a functional specification that says these are the characteristics that I need to have. This is that I and then kubernetes will start up, whatever needs to be started in the appropriate configuration that needs to be started. And that can be multiple. The idea is that there isn't a single container, there are multiple containers handling, the different aspects of your system and kubernetes manages. Making sure that they come up and stay up in whatever configuration you need. They don't have to be running on different hosts. They could be and kubernetes would take care of that. But the important part is is that you've got multiple different containers that take that work together to to create your system and And you can have multiple spec files that work in different environments for different, you know. So you could you could have a basic system that had a web container a PHP container a database containment or that are wired together to work correctly as a single Network within the Pod and then you know, using the same container specifications, you could have a different orchestration that allowed you to have a more With a more scalable or, you know, a system that would work at a different, a different level of scalability. So, Yeah. Sorry, my daughter needs me. Hold on one sec.

Bryan: so,

Cindy: Sorry.

Bryan: So then does the the normal dumb user like the not as educated admin. Interact with kubernetes like, did they or that?

Cindy: Shouldn't have to.

Bryan: so, it Would kubernetes handle. You know, an upgrade where it's now looking to have a different pod or container for a different version of media Wiki or something that's changed.

Cindy: Yeah. Yeah, it handles upgrades and seamlessly. Yeah, you you create a new specification, it puts in your new media, Wiki pod, it would one Whatever scripts you need to to update the database appropriately. But yeah, it handles that level of upgrade. and not not without some work of, you know, the developer creating the spec files, you know, but the end user should be able to go through some scripted process that handles that Oh yeah.

Bryan: And Lex. Is that what you're envisioning like? The part leader building would be go ahead.

Lex: You know, that's way over my head now. I, I bolted book, a very expensive book and I read the first 10 pages and now it's here, or

Cindy: I bought three books and I read one entire book. So I'm headed.

Lex: On kubernetes.

Cindy: Yes.

Lex: Yeah, no honestly, that's something I don't want to. I don't.

Cindy: I have, I read. Kubernetes up and running. Can you see that? Kubernetes up and running?

Lex: Yeah. Look

Cindy: And then I've got kubernetes in action and the kubernetes book.

Lex: There you go.

Cindy: Oh actually, I'm sorry, the kubernetes book is the one I read.

Lex: Okay.

Cindy: Yeah.

Yaron: Right.

Cindy: And I've participated in a bunch of meetings because we are kubernetesizing the Wikipedia infrastructure. so, so, I I'm not a doctor but I play one on TV, I anyways. I know enough to be dangerous.

Bryan: But selects would would, would your

Yaron: and,

Bryan: bit, would you say that it would be? Building a lot of these or that creating the correct abstraction layer and creating these containers that do these things that that some tool might use depending on what it needs to do. So there'd be this kind of layer of things that that someone like you have created and then someone else is using them. At appropriate time to do something.

Lex: Not sure whether I understand the question correctly.

Bryan: Like, for example, you're, you know, your system builder, could be one of the things that's used to create a new media, Wiki instance. And then the update thing might be, you know, something that's that's needed but but instead of having the user, you know, go and type in and do the thing. It's, it's this level above. That's, that's telling, you know what to do when it's supposed to do it based off of That the need of the user or the admin I guess.

Lex: Yeah. You know, I think we fell back to a fundamental question. What is the the main goal should should? Are we targeting Enterprises running a public Wiki in their

Yaron: You.

Lex: intranet or Internet or are we targeting artists running it on their MacBook, and my solution is for the MacBook. Not not for the Enterprise but I wonder. Now whether I should try to weave in my Approach into a branch of Mezza. And I think that is that that would be a good way forward and it would be how do you say that in English the small man's nuclear bomb? What is that? You.

Yaron: It's not.

Lex: Know you can, what is it? You know, the

Yaron: The poor man's.

Lex: Lab. The poor man's. Yeah. So

Cindy: now, your lender

Lex: I'm building the the poor man's Wiki branch of Meza. And by poor, meaning no no Linux system, so there's no answerable. It doesn't want a virtual box, and he just wants three artifacts. Putting them all together, cook them up. Has a Wiki

Cindy: That seems like an alternative to

Lex: I would.

Cindy: meso though. It doesn't seem like a branch of Mezza That that take a VM and configure it

Lex: Say yes.

Cindy: get it up and running and that's one

Lex: Yeah.

Cindy: absolutely acceptable way your approach of creating. It is a dockerized environment is another way. I don't know how and I at one point I was thinking about, wouldn't it be great if Mesa worked on Docker? But the more I learned about Docker and Docker compose, and how it's built from? Layering one image, on top of another image, on top of another image. Mezza is all about building that. Image. And so I I see them as Alternatives. Not as a way to

Lex: I,

Cindy: I can certainly see and message does a certain amount of orchestration and you can tweak configuration files to configure how many load balancers, how many you know whatever. And That's what you would do with a kubernetes orchestration of a dockerized environment. So I see a another approach to creating the the same type of thing, which is an environment in, which you can configureably run media Wiki in a productionized environment. so, I don't really see how your adding your stuff to Meza. I see you creating something like Mesa based upon your stuff. Does that make sense?

Lex: Not. And I would rather say it's a spin-off because the only thing I would add is a darker composed camel and a couple of shell scripts, that's it.

Cindy: Yeah, but then you wouldn't be using all of the ansible files that Mesa.

Lex: To to build it, you know, actually imagine imagine someone uses Mesa to install Wiki and it will end up with an installed. Wiki Plus, in a side folder. There are four three artifacts. A tarball, a SQL dump, and a docker composium. It's like a dingy to the cruiser.

Cindy: But a lot of what meds it does is, is taking a bare VM and installing my SQL on it. That Docker is done with a my SQL image. It installs a patchy on it, which in Docker is done by just having an Apache image, it, you know,

Yaron: You.

Lex: Yeah. Yeah.

Cindy: proxy, all of these things. There are already Docker images for that. So the bulk of what Messa does in its ansible script, you wouldn't need. If you replaced it by a Docker compose file that Oh, shoot, am I late for my next meeting? I am I've got to go meet, grant our CTO. So sorry I have six and a half hours of literally back-to-back meetings today so but

Yaron: and,

Lex: Okay.

Cindy: discussing this for there, but I have to run by

Lex: Okay, all right.

Yaron: Any. Yeah. Okay.

Lex: You know, I think we're not. We're we're crossing, we're talking about different things here.

Yaron: Yeah, I think so.

Lex: we have five people and three topics, and

Bryan: Hey Lex you're dingy. What's the the the dingy would be for the bakery on the side of the street or whatever. Is that I mean like Mezza does this thing right? And that could be for The huge, you know, multinational company. But then it also has this dinghy that can be deployed.

Lex: Yeah, exactly. And the dinghy would be the turbo together with a couple of shell scripts and it. Dokayamo. That's it.

Yaron: Can you all right?

Lex: And that.

Yaron: Can you explain and sorry, if this is obvious to everyone else, what is it? That Meza is better at than your set of scripts. And please don't use the word interface just you know,

Lex: Well, it it as it has a

Yaron: it's an example.

Lex: update. And keeping it up to date functionality.

Yaron: Okay, okay.

Lex: whereas, at the moment, what I do is I put the wiki and if I want to update it, I take a sledgehammer. knock the witch out of the kitchen

Yaron: He really updating.

Lex: and Yeah, and put a new one, you know, it the level of sophistication compared to Mezza is zero. it's just nominally simple, but you

Rich: Yeah. Yeah.

Lex: know,

Rich: method of all the steps required to do an update,

Yaron: Yeah, you

Rich: So it doesn't slam new stuff in and say, good luck, you know.

Lex: Exactly.

Yaron: Yeah.

Rich: It goes through the installation procedure for everything.

Yaron: Lex you had said before that you thought you're set of scripts was 80% there, something like that. Is that is that what you meant is the remaining 20% taking?

Lex: Yeah, no. Now it's a hundred percent but it's this.

Yaron: Okay, so the 80% didn't cover this.

Lex: Unsophisticated Sledgehammer instance dollar.

Yaron: mean, or

Lex: No, no.

Yaron: Okay. Well, how

Lex: I, I had everything integrated, the Builder, and the deployer, and then in the, in the wake of your question there, I thought. Okay. And then, let's extract that part and

Yaron: Sure.

Lex: put it into a new and, and you repository and let's let's try it out but it's it's

Yaron: This is fine. Yeah, this might be.

Lex: Really.

Yaron: Yeah, this may be a silly question, but how hard would it be to add an actual upgrade part to your coders? It is it not even really does it not even really make sense to ask that because you'd have to basically rewrite everything

Lex: Well, then I would answer. Well, Meza does it already. So why why do we have to? and,

Yaron: Okay, no.

Lex: Not.

Yaron: And now I'm confused again. About why you created this thing in the first?

Lex: Because, no, because for me, it's enough right. We, you know, in it, use the simplest solution possible. And, I mean, NASA, must must know that right? Your Space Systems, they, you have to be the simplest solution is the best because it's the least. I heard the switches on the space station are from the Apollo program. Is that correct?

Rich: Well, it's also true to say that the space shuttle is the most complicated machine ever built by human beings.

Lex: Exactly. Yeah.

Rich: So there, you know, it's as simple as it can be but the task drives the complexity,

Lex: Sure.

Rich: So it's not to say that, no matter how complicated the task is, you know, that you don't stop until you've found a one button solution. You know, sometimes the solution is complicated because the problem is complicated.

Lex: Yeah.

Rich: And you look for ways. I don't want to go down the the how the NASA philosophy path. That it would be fun. You know what? We're a risk. Based organization, right? We do risk-based decisions and we look at likelihood and consequence. So we brainstorm, what could go

Lex: Yeah.

Rich: wrong? We rate the likelihood of it going wrong and we rate the consequence of it going wrong and we multiply those numbers together and build, what we call a risk assessment code and we make design decisions. Based on mitigating risk. And so James and Darren are maintaining Mezza with that philosophy.

Lex: Okay, there you go.

Rich: So the sledgehammer approach has a high likelihood of things going wrong and a high consequence of. Well I mean the consequences low because who cares what she's supposed to be some You know. Your own, you're rubbing your head. I feel bad. I don't I don't like you see, you seem stressed here and,

Yaron: and,

Rich: and I don't want to contribute to that, I don't know how to What do you what do you want?

Yaron: Sorry.

Rich: What do you want to hear?

Yaron: Well it's I'm I'm hoping to get a clear answer on the question of whether this media Wiki manager is it's called now has any value to us at all.

Lex: I think there's a couple of ideas that are interesting and maybe useful. but as a carrier for,

Yaron: So so, so no. Okay, fine. Okay, well sorry. Okay I I got the sense that this was like a complete solution already and in fact, it's not a it's in fact,

Lex: Well, have you have you tried it out?

Yaron: No, I haven't. No.

Lex: Well but that you should try it out, you know.

Yaron: Okay.

Lex: That's and I think

Yaron: To try it out because it's not, it's it's not good.

Bryan: But what? No. But you should try it out. I mean we should be trying out all these things. I think I'm

Yaron: Yeah, yeah, you're right. Especially because I'm trying I'm yeah, I'm putting other people in the back position of like, try trying to explain everything to me. And I think that's causing the decline in productivity. But fine. I mean I guess we're back to square one. I may be blue, the blue spice solution is good but but neither Meza nor the so called media Wiki manager are Good for what we need and kubernetes seems like the not ideally either. It's an approach to a different problem. um, Ike has his own solution. Maybe it's worth talking about that again. but,

Lex: But what, what, what are the the target use cases? The MVP use cases and the metric. Of.

Yaron: Sorry Target and MVP, two different things.

Lex: Now you know what, what's the minimum functionality you want? And I understood it, installation updating backing up and restoring. These are the four things, you always need.

Yaron: He really distillation and an upgrading, I would say back up and and restoring can be a separate non-docker-based. Approach, I think.

Lex: yeah, but that you see the the it's not the question, whether it's Docker based or not because it's you have a

Yaron: Well.

Lex: darker solution than backup will insta include Docker that and

Yaron: Okay, fine.

Lex: Docker is it's just, yeah.

Yaron: I know fine. Fine. I understand we're saying fine.

Lex: you know, it's you can't exclude, you

Yaron: It's

Lex: You can't say, I want darker here not there and I mean, you theoretically could, but it's

Yaron: Fine. That's it. Started to get on the Sidetrack. So those four things you can say are Sure. the key are the important parts. Yes.

Bryan: well, just As a possible solution to move forward. Right? You know, Lex you originally just talked about possibly taking Meza and tweaking it a bit and guaming on some of you know your solution. and and continuing to do that to see kind of where it goes, but You know, it's like this idea for the ship of Theseus, right? The ship that we all Sail Out on and we might arrive at the next port in a completely different boat over time, and it's really the same shift, right? So it could be that we start off with just Meza. and it could be, we do find out that a Docker and kubernetes based approach is the way to go and we Take bits of it apart as we go and we replace what what we need to. And but at the end, it suits our needs, is there a possible path for that to happen or we start with something that? I mean, because one of the nice things about Meza is Kind of does everything. The

Lex: Not, it's done.

Bryan: that it's not running the most current, you know, LTS, right. But like rich said, it is, you know, with, with this, the people in this room here, right? We could help make that come to fruition sooner than it would otherwise. but again, we can also make changes that we want to see in it and and That boat that we're in, will look different a year from now versus now.

Lex: Yeah, exactly.

Yaron: Okay. Yeah. Okay. I I thought Mesa was sort of out of the picture because there wasn't enough. Development effort or energy. For the moment. But

Lex: Now, I think it's a project where there's most development effort at the moment. even if I didn't know that blue spice that they have sort of improvised or you know, manually constructed docker, Solution aspects. But um,

Yaron: Well, okay. I'm sorry. Well, but me as it uses as it doesn't use docker Do you think? I mean, you thought that before that was a problem? Or do you feel better about it now?

Lex: Yeah. Actually. The idea, it's difficult question. How do you feel about that as no feeling? For me, it's not the same. These are not Alternatives, my You know, Sledgehammer, improvised approach and Mezza. These are not The two different things. One is a poor man's Wiki and the other one is a real week. Or a real management solution, right?

Yaron: Okay.

Bryan: But again, you could use both right? Like you could, you're dingy tied off

Lex: Sure.

Bryan: to the you know, the yacht or whatever, we're calling it. It in transit and you could also just use Meda to create this dump that you're going to be using to deploy to the flower shop at any point, right? And so, I mean, I don't know what I'm talking about, but I potentially some see some way that where you can just kind of work on the same project.

Lex: Yeah, I mean, I could add some ideas or part of my, or my Approach into mesa into a side branch. And then, let's see what

Rich: Yeah. And it might even be ideal to take free files or Greg's quality box Fork. Um, I would start, or I'm sorry, I posted the 35 branch. so, if you I would recommend, we stick with I can't think of his name. James James, and Darren's. I would, I would say we stick with their 35 Branch. We look to Greg's 34, x Branch for insights. you know, and and go from there.

Yaron: Okay, I mean this is this is weird that you know where we've had now three or four this meetings about this and were only now coming to the conclusion that the Mesa is really the only possible solution. um,

Bryan: I wouldn't say that but but there's this is a kind of a big decision in this community and so I don't think I'd make any sense to have gotten 20 minutes into the first meeting, and had a great idea about where to go. I mean that, There's stakeholders involved where this is, this is a big decision, right? And so, we've had a couple meetings to really Enrich has helped with this figure out the language that we're all speaking, right? Because, you know, You're on your finding out even in this meeting like some of the assumptions. You thought didn't hold true but that's wonderful right? We're finding something out that we didn't otherwise know we're coming to an agreement so I'm the forever Optimist in the in the bunch but it's up, wonderful.

Yaron: Yeah. You know, maybe maybe. Yeah, that's true. That's all true.

Bryan: but one thing we should be doing is like, I mean I haven't I haven't deployed Blue spice. But I've tinkered with Lexus solution and you know, it's super easy and I've tinkered with Mezza and there's a lot of complexity back there that didn't understand but the some of the stuff of the surface level is super easy, right? Couple lines. You can just copy paste into you know, your your server and you get something going. um, so, I think I think we could get.

Yaron: It.

Lex: now, I would try it out and Yarn. Try Mesa. And

Bryan: Yeah.

Lex: See how it feels.

Yaron: Yeah, okay, yeah. All right. By the way, just a random thing left. As to an earlier point, I I don't think it makes sense to think about students or Librarians or artists or whatever.

Lex: Okay.

Yaron: But I think I think when you say that you really are talking about people running a Wiki for their own note-taking purposes, if I understand it correctly, one, a single you

Lex: Yeah. Yeah.

Yaron: I don't I don't see any value in. In selling to that kind of Market. If selling is even the word we want, I think people who are actually using it as a Wiki, I mean, as a collaborative. Platform. Which I guess means Linux, I don't know. Um,

Bryan: What really quick is I don't know if is Ike still on the line. I know the least of his docker.

Ike: I'm here.

Yaron: yeah, right. That's what I was wondering about too.

Bryan: Do you like, do you have a somewhat similar approach to Blue spice? And/or? Lex, the did anything. You hear a long way from them? go counter to what you've been trying to do or

Ike: I think it's kind of a different system because we have one main Docker one that 35 image. And then we create a separate DACA image that kind of layers on top of that. You know, the main Docker image has like a lot of the standard extensions like visual editor and stuff like that, but then we've customizations for each client. So we create another Docker image for them. So obviously you know for your system you can't have that next layer where you're layering on top of that main core. Because, you know, The average user can create their own Docker, derivative image, or whatever it's called. But I mean, the main product, I guess in theory could be useful. Maybe you can even, you know, take that product and make your own branch of it. That kind of Covers. The extensions that you want connected to include. It essentially. But essentially all you're left with is, I don't think any different than Alexis doing conceptually. We have our own Stuff we have in there but basically what you end up with is a Docker image, right?

Yaron: How does how does your system handle upgrades? I guess that's the big challenge in any such system.

Ike: So one of the developers goes and updates, either the original image or the new derivative image for The Quiet, depending on what we want to upgrade. If we want to upgrade to the next minor release then developer goes and Does something to the main Docker image and tells it, you know. Now you got to pull the minor one instead of the major one and At least, I think that's how it works. And then you go on to the individual system and you pull the new image and does its thing. I think that's what happens. Like, I don't think there's a separate. I don't think that's like a separate script that's run.

Bryan: You, you had something? I think it was you actor was like a GitHub repo for each customer that handled. Nuance, or

Ike: Yeah. Yeah, that's exactly what I'm talking about. The each, the main Docker images hosted on our GitHub, and then, the derivative images for each customer also on our GitHub.

Bryan: oh, okay.

Ike: If you if you give me a second you guys can continue. I'm going to take a look at what actually happens when we upgrade it to make sure I got this right.

Bryan: And then this is an ignorant question from the orchestration level, but the that second kind of layer. Is there any way that you think that could be automated?

Ike: Not really, you mean to create that layer.

Bryan: Yeah.

Ike: I don't see it being automated because in theory, anything could be added to that layer, you could be fully

Yaron: If?

Ike: extensions from The main Wikipedia Foundation repo, it could be from somewhere else. It could be a completely custom extension that you wrote, right? Like

Bryan: but,

Ike: There's no, there's no way to know what the second layer needs.

Bryan: it for all your customers, your you're the only one that configures that or teach them how, okay?

Ike: Yeah. Now we do the whole thing, like if they tell us, you know, build the site with a bunch of these extensions. So then we Will Branch well, we don't really Branch or create a new repo that says you know, pull this main repo and also pull a bunch of extensions, right? And we compose that whole thing for them once it's already we go into their server and we pulled the You know, we do the doctor compose thing and the whole thing just works.

Yaron: Yeah, here's something I don't understand and apologize. Again, if this is clear to everyone else, what I described as the upgrade process sounds pretty simple. And I mean, it makes sense to upgrade. All you need is an upgraded Docker image that you can repull or something and then, possibly call update PHP to update the database or something. What's the what's the difficulty there? Why what what's the extra stuff that Meza does? That's so important. In the upgrade and why?

Ike: I shouldn't I should note that I I'm speaking about from, you know, perspective, someone who really doesn't understand Docker. So I hope I got it right, but I don't

Yaron: Well. Okay.

Ike: know for sure. I can, I can ask. I can ask one of the people who are more educated than I am. Do what they say.

Yaron: well, we have some people here who, I don't know, potentially could

Ike: Well, I mean, who also know how we actually do it.

Yaron: oh, I see, I get weird saying But you'd probably know like if there was some like you know, Advanced processing going on. I mean, it does, it seems like it should be simple. Docker is good at that kind of thing of upgrading from what I understand. So so what is it? What what's, what's the difficulty there in getting a, you know, a standard upgrade component?

Ike: Um yeah, I don't I don't think it is difficult.

Yaron: Okay. Yeah. Lex

Ike: you know, if you're using docker

Yaron: Sorry. Yeah. Lex. Why does your system need to reinstall everything? It's supposed to just doing a doctor update or is that the same thing?

Lex: No, my doctor image is totally media. Weekly agnostic. So, if you want to upgrade media, there is no necessity. To upgrade your Docker containers,

Yaron: Right.

Lex: Docker containers should only upgrade

Yaron: So

Lex: if the packages of the infrastructure components update, or if you need

Yaron: Yeah, sure.

Lex: further tools, like image magic or

Yaron: Yeah.

Lex: WhatsApp and stuff like that.

Yaron: Well, so, I mean, you've talked about this before but why is Media Wiki not part of the docker image in your setup.

Lex: Well, because I volume it in. so that you can just unpack it tarball to actually install the entire aversion, right? But that's what I mean, it can be. Questioned, whether part of the media week you should go inside the container or not.

Yaron: Seems like it has to know for the up

Lex: No.

Yaron: to be. But isn't that the is not the problem? Isn't that what makes your system currently unusable?

Lex: Well for example, let's say you can you can put the only things that you really have to take out of the container so that you can reuse. The container with different customers is the images folder and the local settings PHP. now, you could argue that if you put

Yaron: Yeah, but

Lex: the extensions folder into the media into the container. That means, if you want to upgrade one of or add an extension, you would have to upgrade the entire Docker image. But you can volume in the extension folder or for that matter, the entire media Wiki route. so that the the container becomes truly General and ephemeral, Well ephemeral it is ephemeral in fact anyway but let's say truly truly General but this is design. That's a design question that we can do either that way or that way.

Ike: Yeah. Yeah. I just I looked at the actual container here. We definitely we have like, like I said, we have media Wiki with all the extensions and I my understanding is when you're upgrading you're not really upgrading right? You're pulling a new version of the container and removing the old one but

Lex: Exactly.

Ike: You know, all you have.

Lex: Yeah.

Ike: different between the new one and the

Yaron: Oh, okay.

Ike: And the old one is that Instead of pulling one that 35.0. Now, it's going to pull one that 35 that one and everything else can stay the same or if you're upgrading an

Lex: Yeah.

Ike: extension, it just checks out a new version of the extension. But yeah.

Yaron: Okay. Well, yeah.

Ike: But yeah, the only thing we have out

Yaron: Yeah, well, what's wrong with doing that? With just reinstalling everything from the user perspective, they don't really care. If only five files of changed, or if you know 5,000 files have changed. As long as it works still.

Lex: Well, that's my sledgehammer, right?

Yaron: Yeah. But what's wrong? So wrong with that?

Lex: I don't know.

Yaron: Okay.

Lex: I I haven't field tested it and I'm not sure whether Rich would would agree that that's a good.

Yaron: well, actually, I don't know if message does the same thing, but it certainly could

Ike: the third guys, I have a one o'clock

Lex: No matter, no.

Ike: afternoon starting to jump out,

Lex: Bye. No, I understand that Mesa just proper surgery. I replace the entire body.

Yaron: And, yeah, but that's fine. But that's fine. And if from the user perspective, it doesn't, it doesn't matter. And let me add the caveat that there, that we, I think what makes sense is to have some way. So that the, when the admin wants to add an extension or skin or make some change to a setting, there's there should be a way for them to do that. That's outside of whatever code they got through this product.

Ike: right.

Yaron: So have a separate settings.php file have a separate extensions, directory and skins director or something for for custom changes. So that you can do that and, and basically, the assumption is whatever change you make on the at, on the code that you got is probably gonna get wiped at at some point. So, you know,

Lex: Yeah.

Rich: Yeah, method.

Lex: That.

Yaron: Okay. Okay. Yeah, that makes sense. So yeah.

Rich: Yeah, local and core. So core is the stuff that you get.

Yaron: Okay.

Rich: Okay.

Lex: Just and Rich. What is the proceed? I will try Meza tomorrow morning first, first thing honestly. But what's the procedure to add an arbitrary extension?

Bryan: You're unmute rich.

Yaron: It.

Rich: thank you, if you look at the link that I posted on the mesacore extensions Dot yaml

Lex: Yeah.

Rich: You will see. actually, that's actually a bad file

Lex: Okay.

Rich: to look at because it's, it's got really complicated extension installation steps up front. So scroll to the very bottom.

Lex: yeah, go that

Rich: And at the very bottom you'll see one, two, three, four, five extensions. That get it installed three lines

Lex: No.

Rich: Three lines data transfer page importer Semantic meeting minutes and header footer and numer Alpha.

Lex: Okay.

Rich: So, You know like line 355. 356 and 357. Those are the three lines that you need to install data transfer with no special configuration options.

Lex: okay, so you would add this and save the file and then run as a deploy

Rich: Yeah. And and even better than that.

Lex: Okay.

Rich: special tags that say that don't do all the core stuff. So us, if you do method deploy, it's gonna start from scratch and it's gonna make sure that Apache is in good shape, it's actually going, okay.

Lex: Yeah.

Rich: All of the core components of Linux. So, one of the first things it runs is it make sure that you know, all of your base packages are up to date. You know, and then it just proceeds from their methodically if you if you simply make and that can take that can take a half an hour to run from a new install. So if you have a vanilla Sentos installation and you type message deploy for the first time. Get a cup of coffee and sit back in 30 minutes later you're gonna have a full system. If all you do is make a tweak on an extension, then you run Mesa deploy. Tags equals media with you skip backups, right? And like, you know, you can tailor it. There's a in the Mesa documentation where it says how to install Extensions, there's a pro tip in there. There's like a little hint that says, hey if you've just made an extensions change, then just copy this line. Paste it in hit go and it'll end in like two minutes. You'll have your extensions folder updated.

Lex: Okay.

Rich: as a Is that? It has its own set of commands. so, you know, if you're if you have people at already know, Docker and and they already know you know like there's a certain skill set that they can hit the ground running with The problem with Mesa is is that it brings its own commands into the project and you have to use those commands in order to install and maintain and update Mesa. Now the good news. So the bad news it has its own

Lex: Okay.

Rich: things, you have to learn but the good news is there's only three You know, you know, it's not like you've got this complicated library of functions, you have to memorize, you know, there's three things you do.

Yaron: And yeah, okay. I it's still seems to me that Lexis Lincoln can is workable. I mean, once again, seems to me and I don't see a problem now, with, with the reinstalling instead of supposed update. Just want to throw that out there.

Lex: Well, let's see again.

Yaron: Not. Essentially the same thing. I mean, granted this isn't Docker but still, you know,

Lex: You know, at the very outset I was just advocating for abstracting stuff into an into a container that was my original idea.

Yaron: oh yeah.

Lex: but that goes against Real, the religion of a lot of people, I know, they the vehemently would would argue against that, so,

Yaron: But what that's what we've been talking about is container a container-based solution though. Or is that or the?

Lex: Yeah. But you can yeah how people like

Yaron: Is that something?

Lex: Cindy are wary of that, right?

Yaron: Oh yeah, okay.

Lex: So and you know, Cindy is a lot more experienced in running. Wikis for customers than I am. Or large ones. and,

Yaron: Yeah, but I don't think is getting back to the target audience. She's, she's coming from the other perspective. Her targeted audience is people who are running this with database clusters and whatever else.

Lex: Her.

Yaron: Which is not. Something we need I don't think either.

Bryan: oh my gosh, it comes in the routine but if every if The group guamed on us solution, that could be a feature that pops up at some point when there is a need. But that's the cool thing about if we all started working on a common thing and what my just dream is my naive dream is, you know, Lex jumps on. This demonstrates, the, the sweet yacht. That does something on the side that can do something for his need, other people have that need, then he demonstrates how the ship engine could be rebuilt in a way that it's just a drop in replacement that, you know, is now dockerized or contained or whatever else. And again, like two year now, the vast majority of the code looks nothing like what it does now. But it meets all Lexus needs and we're all better for it.

Yaron: Yeah and absolutely yeah I think that we can all agree that the the perfect shouldn't outweigh the good and you know just getting something working is would be a great first step.

Lex: But you're on, I would really recommend you. Try Mesa tomorrow. With all use cases.

Yaron: Okay.

Lex: back and forth and adding stuff and removing it and upgrading

Yaron: Okay, all right.

Lex: and,

Yaron: All right.

Bryan: I I can up a sentos into US VM right

Yaron: That'll be

Bryan: and then hand you the keys and we can Tinker with the

Yaron: Without having yeah, because I don't even have Docker. Well, I guess I don't need Docker but I don't have any of that stuff on my server.

Bryan: yeah, I I'll just I'll just create a a centerless image and and then either put your public key into it or just give you the key somehow and

Yaron: Have you run Mesa by the way?

Bryan: that

Yaron: Brian.

Bryan: Yeah.

Yaron: Okay. See well.

Bryan: I try to.

Yaron: So, here you're good person to talk to ask then you've now tried both Lexus solution and Meza.

Bryan: Yeah, but not the best person to ask

Yaron: Yeah.

Bryan: but I'm willing to, I'm willing to Tinker.

Yaron: Okay.

Bryan: but,

Yaron: Do you have any thoughts at the moment about the two?

Bryan: I don't think no, no.

Yaron: Okay, all right.

Lex: Now I Aaron since you are the guy driving this, obviously, why don't you try it out?

Yaron: Well.

Lex: explain to us what you think if any Meza is missing for you. For your experience, right?

Yaron: Okay. Okay, we know one thing it's missing

Lex: and,

Yaron: which is support for mediocre 135 obviously that's going to

Lex: Okay but then you know we can we can work on that and then if you have unmet needs, we can all work together and and Chip it into Mezza. And then But I think that the the building block should is rather Meza than mine. Honestly.

Bryan: Although I can also spin up another server and then meeting your own can do, you know, your system builder and your, you know, media Wiki deployment tool or manager.

Lex: I would stick with the deployment tool, not with the builder. I mean, you can try it out. and it should be well explained, but it might break and then we can No, but let's do that. You're on. Try out Mesa and make a short list of what of your You know what you envisage that can ask us should do is if any not met currently by Meza and then we cooperate on that. And, and make it. Work for your needs.

Yaron: Yeah.

Lex: Or your. What you want you? What do you think?

Yaron: but, I mean, Sure, right. But okay. yeah, and

Lex: Rich. What is your opinion on that?

Rich: Um well I think I'm biased. Everything that I've heard. Being discussed here. Mesa seems like, Um well I think I'm biased. Everything that I've heard. Being discussed here. Mesa seems like, Based on what I know as much as I try as much as I honestly. Tried to dial out my personal preferences Mesa seems to be the solution.

Lex: Yeah.

Rich: Um, I think will a little bit of work. We can have the 35. X branch. and I think once all four of us and the larger group has run Um, I think will a little bit of work. We can have the 35. X branch. and I think once all four of us and the larger group has run Um, I think will a little bit of work. We can have the 35. X branch. and I think once all four of us and the larger group has run Um, I think will a little bit of work. We can have the 35. X branch. and I think once all four of us and the larger group has run a Um, I think will a little bit of work. We can have the 35. X branch. and I think once all four of us and the larger group has run a deploy I think it will slowly win you over.

Yaron: Who's the maintaining it in the future?

Rich: That's a great question. So my hope based on just casual conversations. I had with Brian is is that whatever is decided on here at Canasta, will be adopted by the media Wiki stakeholders. Nonprofit organization. And so one of the things that I thought was sort of at stake here was the opportunity for I know personally that James and Darren would love to see Meza Our own by an organization that was invested into its continued. Existence.

Lex: Mm-hmm.

Rich: There they are burdened with being the owners of it and so I know they will be happy to turn it over to the Wikimedia. Stakeholders group. If that's what the stakeholders group chooses. So, um, I would want to run to ground the the claim that the meeting with the stakeholders group will adopt, whatever we chose here. And I want to get a commitment from them. and if they agree that whatever you guys choose to pour your energies into for Canasta, we will We Will, We Will flock to it. So they that the media Wiki stakeholders. Organization will flock to whatever we choose. And if we choose Mesa, they will flock to Mesa. And we just need that commitment. So, in order to run the risk, the risk is That whatever we choose would be unmaintained in the future. We put a half a Year's worth of work into it. We like what we do and then two years later, it's untouched. Okay, that's the risk. And the consequences is that everything we've done is for not so it's a very high consequence. So in order to drive in order to drive the likelihood down of that unwanted consequence, we need a commitment from meeting with the stakeholders.

Yaron: Just to clarify that, there's no, there's no official connection to the media Wiki stakeholders. Organization Group, whatever the group for this project but I mean it'd be cool. Of course, whatever development. They wanted to provide would be cool.

Rich: You know, all these major programs like ansible and get and you know, they they all are these kind of super well-established, you know, tell me if I'm wrong but is ansible a for-profit company? Or are they a nonprofit? Organization. Ansible make money. What's the business model?

Lex: I think it belongs to Red Hat.

Rich: Okay. So then Red Hat plowed, the they they're the ones that historically showed the world, how you can make money on a support model rather than a proprietary code model.

Lex: Hmm.

Rich: and, And the media Wiki or Wikimedia Foundation, right. They're clearly invested in into or meaning. and so, what's missing in the in the in the world right now is some stable, nonprofit organization, that's willing to take A build a fully and a lot of an extension rich. Bill of So what red hat does is that they provide a distribution of Linux for Linux kernel with all of the additional packages verified. And so what red hat is to Linux. I'm hoping media with the stakeholders can be to Media with you.

Lex: Canasta.

Bryan: Irma.

Lex: Yeah.

Bryan: Where can I sell?

Rich: Right. I mean would be if media would put

Yaron: well, that's What?

Rich: could take their Whatever. Their mission and vision is that that exceeds merely being a clone of the wicked media Foundation, right? But whatever, the mission and vision is the media would be stakeholders. Nonprofit organizations should be to pick some kind of a project out there that utilizes the established semantic media with me page forms. You know, these mainstream extensions bundles them together. Provides that bundle of. Support the people support the activities to make sure that there's always an active updated bundle. Ready to go. And and then, the world profits. And then there be, and then we have the platform for a Marketplace for extension based or working based tools like, you know, categories, forms templates, properties, those kinds of things. Then we can create that Marketplace based on Based on an established. It would stakeholders endorsed committed to project. otherwise, it's just, it's just A couple of people who have a passion.

Lex: Mm-hmm.

Rich: and, There is an end to everyone's passion.

Yaron: All right, I think this is a good place to wrap it up. I guess some of us have homework for next time. Maybe just me, although it would be great if other people can.

Lex: No, no, I'll do it.

Yaron: Yeah. Okay.

Rich: if you'd like we could do group thing where you know your own, you could just share your screen, we could all follow along I think you would benefit the most by actually King in the commands and doing it and, you know, and doing the one doing it and Brian and I are sort of already in the know and I think Lex could learn just as well by watching as he could by doing and I think, you know, so I mean if if we can find a time where we all have one hour and we'll make it a challenge, right? Is it possible to install Mesa? Talk about it and get it from from a blank slate to a fit it to an installed system. Can we do that within one hour and even Benchmark Benchmark? The deployment

Lex: Yeah.

Rich: That'd be fun.

Lex: Now I'll do it. I try to add tomorrow morning and then just invite me. If you have one of these, what such a session, I'll join you.

Yaron: Oh yeah, okay. Cool. I mean yeah. I mean. All right. Yeah sure you know Brian whenever you want to do it, he can definitely invite other people to participate.

Bryan: So it included looks I think this is around the best time for both coasts and then Europe.

Rich: You.

Bryan: so, I mean. Morrow, I have a opening from eight to nine. Thirty, my is a half hour earlier than we started today and then

Lex: That's right.

Bryan: That work for.

Lex: that's,

Bryan: You guys.

Lex: Yeah.

Yaron: So, what time?

Bryan: A half hour earlier tomorrow morning, then we started this meeting today.

Yaron: Oh yeah, that's fine with me if you're willing to do it.

Bryan: Oh it riches riches looking like he's

Rich: You.

Bryan: a no for that.

Rich: Right. So this meeting started at 11:30 am for me in my time zone and you're proposing a half hour earlier, right?

Bryan: Yeah.

Rich: Okay? And my whole day is free except for half year and you know,

Bryan: What about super early East Coast time? Like so I have a meeting at An hour before this meeting starts. So, do you Lex by the way? But I'm, if we started, six am my time.

Yaron: Whoa.

Bryan: So nine nine pm.

Yaron: and,

Bryan: Right. 9 am rich in your own time. Does that work?

Yaron: Prime with me.

Lex: And that's three and my time, right?

Rich: Well.

Lex: Yeah.

Bryan: Yep.

Yaron: Yeah.

Rich: and,

Lex: Now, that's fully sure.

Rich: Say that. Okay, what's the time? Again, super early Eastern.

Bryan: In nine am your time.

Yaron: Man.

Rich: Do it. and then,

Bryan: Okay. All right open, just the well, I guess I'm going to set it up so your own will be ready to drive. Rich will do, you know, he'll share his screen and Rich, you can kind of talk him through it and I can either just send it to this group here, the four of us or we can extend it to the Canasta group to watch along. It's Theory as it's called,

Lex: Here.

Rich: Yeah. Um, so just to make sure we're set up for Success. The only thing that we need to have already done is a fully installed sentos machine.

Bryan: Yep. Yep.

Rich: Okay, and be sure to look. It's sentos 7, I think sentos 8 is the current

Bryan: Okay.

Rich: So yeah, Meza is, is not sent us 8 compatible, so I that was a horrible mistake. I made with a summer intern last year, was, you know, I said, oh, it's so easy, right? It's three commands and you'll have it all running and I forgot to say, make sure it's sent, oh, seven.

Yaron: Is that as of no Js?

Bryan: Yep.

Rich: I don't know what the problem is.

Yaron: Yeah.

Rich: I I could look at notes for what the errors were, but we beat our and I think it has to do with ansible, I think it's ansibles

Lex: Now.

Rich: Compatibility with sentos 8 is not where it should be.

Bryan: And that that right off the bat gives us a preview about, you know, things that we might want to work on if we do, you know. So called flockton regular right, making sure it work. One the most recent version and sent us but then also possibly at some point in the future Ubuntu or something else. If all at all one, I'm interested about rich and you can answer this for me possibly but I know it does some weird things right now with sign on where it At some level can automatically sign you off. Or is that just a part of your own internet or your it? That's security stuff that they're implementing something different.

Rich: Um, so there was a problem that's been resolved. With semantic media working and it was dirtying up, there was something about it, would dirty the session. And so media Wiki would destroy the session cooking because it was dirty and it was getting dirty because of something semantic. Media Wiki was doing wrong and that's all been resolved.

Bryan: Great. Okay.

Rich: Are we to are you? Is that what you're talking about? Like, you you log into the wiki? And and you're saying that like, you know, while you're editing something drops you out, is that what you're saying?

Bryan: yeah, even suddenly sometimes people lose their edits because they don't understand how to like capture what

Rich: Oh,

Bryan: they had been working on and then back in

Rich: 100% a NASA, single sign-on.

Bryan: Okay, wonderful.

Rich: A NASA single sign-on issue and you we will not have that because by default when when you when you when you install Meza it's not going to have a single sign-on configuration. So it's going to be a self-signed certificate. And it's going to be. Yeah, local. Local logins. Only.

Bryan: okay, so I didn't didn't want to

Rich: so,

Bryan: this with further questions about it, but just wondering,

Rich: Okay.

Yaron: Does it make sense?

Rich: Yeah.

Yaron: Also try elected solution in the second two or will that just take too long? I'll be working.

Bryan: Oh, we're gonna just after this over that you. I was gonna offer two more things, one for lack, like, your early morning. Tomorrow, my my layers tonight, we could do meso which would also help me to make sure that it actually worked for tomorrow. But then also your own later today. At some point, I can stand up another and just Tinker with Alexis because I can run through that. Well, we'll do the same thing. I'll talk you through it. I'll give you the kingdom.

Yaron: Okay. Yeah, and anytime today or tomorrow or anytime

Lex: Nope.

Bryan: But if we're going to grab more people, it might well we could read both tomorrow. Morning.

Lex: And by the way, and off topic remark, please have a look at. I just posted a link. Does any one of you know, Wonder dot mean?

Yaron: Now.

Lex: It's a it's a conferencing solution. That looks pretty interesting because it's different than all the others I've seen you've got, you know, virtual tables that you can move your avatar to and

Yaron: Well.

Rich: You.

Bryan: That's that's what like they're

Lex: I,

Bryan: getting smart. They're trying to take some of the best part real conferences. That's what I like about the upbringing and different rooms and your own ability to move yourself in a different rooms with this seems even even

Lex: Want. Yeah, I can you know, if if we could try this out I would. I've because I need some Pals to try it out with you know, guinea pigs.

Bryan: what you know it's got a little darkness of pop that there's get a room and that's an American kind of slightly people that they should just move on and do something around themselves but

Lex: Yeah.

Bryan: I'm down in the room with Alex, if you want.

Yaron: Get a room, guys.

Lex: No. But I mean, it looks, you know my

Rich: Well.

Lex: my my dream would be that if you move your avatar from one table to the other, the audio would be, you know, it would fade from the people, you

Yaron: Right.

Lex: move around. I mean, this would be so cool because that's the big problem with those rooms, you know, these these breakout rooms, we had, in hop in, because you've got 25 people, but only one person can talk. because otherwise it's complete, but

Bryan: Yep.

Lex: But if you move your avatar around, you can I mean it would be so great.

Bryan: yeah, and you could you far away, if

Lex: Oh,

Bryan: And you could you far away if you don't want to hear everybody. So one quick little anecdote there's a video game called Red Dead, Redemption 2. It's this like video game based in the old west where you get to shoot people and whatnot. There's a whole contingent of business. That holds their meetings in the video game Red Dead Redemption 2 because They can circle around a campfire. And talk. And then two people can move slightly away and talk and they mostly hear themselves. But in the back, they Southern

Lex: Yeah, yeah, yeah.

Bryan: Comfort. But it's a little bit more looted or something.

Rich: Is this is that VR enabled?

Bryan: Still don't. So that's the that's exactly the next part I'm gonna move, it's not. But that's the next point where you can then like get some of those inflections from people's faces and you know and because it we miss that too, in normal conversation. So but you know your own you're written and I am planning for the next EMW. Con and I have been considering using hop in the same thing that the semantic media Wiki conference did. And I thought that I was a drastic improvement over zoom and Bernard recently gave me a full write-up that I'm gonna put somewhere public about his thoughts about what worked well and what didn't about that. But yeah, I'm very willing to give this a world to see if it if it might be a better.

Lex: And I've got some, I've got some more, but this is the one that I I really like to to try out.

Bryan: Yeah.

Lex: If you if you want I mean we could let's why don't we try tomorrow?

Bryan: Sure. Yeah, let's just let's try that and

Lex: well, let's

Yaron: Yeah,

Bryan: we'll have a if it doesn't

Lex: Don't. Let's not hesitate, not let's not lose time. Let's try this tomorrow.

Bryan: That. Let's do it. And if it doesn't work, it takes us all of two minute up a different meeting and

Lex: Exactly.

Rich: Why don't we know?

Bryan: Okay. Okay. Yeah. Well, I mean

Lex: You want to do it right now? Okay. But wait, I need a drink. I I need a drink now. Just

Bryan: Here, I'm starting it up right now.

Rich: Okay, so should we all get a room or

Bryan: I'm doing it right now.

Rich: Okay. so, I'm gonna be mute and, and

Bryan: I love.

Rich: hopefully, the next time I hear you, it'll be in Wondering. Drop a link. In this chat. To the room that you get.

Bryan: Yeah.

Rich: Flex, what you drinking.

Lex: Actually just water because there's there's only Red Bull but no beer. I would have a beer now but if I drink a Red Bull now I won't sleep

Yaron: Yeah.

Lex: till four o'clock.

Rich: so,

Yaron: Well yeah.

Rich: So, red bulls. One of those things that I tell my kids hasn't been around for 200 years. Don't put it in your system.

Lex: That's right. By the way, you know, the book food

Yaron: If?

Lex: rules. This is a guy who integrated all the science into into heuristics and very simple. You know, Max seems to follow.

Rich: Yeah, I love it already.

Lex: So, what another one is that never eat anything that has an ingredient that a three-year-old can't pronounce.

Yaron: Oh, that's not a book. That's just a saying.

Rich: Yeah, I struggle with that one because you know, I got to tell you

Lex: Why?

Rich: the joke, right? So the guy walks into the pharmacy and says doc, can I have some acetic acid? And the pharmacist says, I'm sorry, do you mean aspirin? And a guy says, look, I can never

Bryan: Yeah.

Rich: remember that other name.

Yaron: Okay.

Bryan: Yeah, I mean like dihydrogen monoxide or something, right? Like okay but

Lex: So Brian, are you the host?

Yaron: And it was gonna say if it was my three year old. I could never eat a carrot again, but that's a different pronunciation problem. Yeah, sorry. Good.

Rich: Now, I invented my my don't put anything into your body that hasn't been around for a long time. I invented that to try to get my teenage boys to stop doing energy drinks.

Bryan: so,

Lex: It also that it also means the

Rich: I was.

Lex: humanity would die out, you know?

Bryan: I'm I'm gonna jump in that other room and it's asking me to enable my mic and camera. So I'm muting and turning off my camera here. I don't know if both can be used on.

Lex: so, Oh, there.

Yaron: Okay, well, see you guys on wonder me I guess.

Lex: Let's see. Yeah.

Yaron: Hello, hello.