 Okay, that's the view of the next session, but before just a few announcements, remember that we will have a final closing session at the end of the program today for 30, I think we have some prizes that you can win, so stay with us until the end, until the end. But now, we are going to start a presentation of things from Feather infrastructure, and it will tell us how to own your infrastructure in a way that we know it's going to be. So, good morning everyone, thank you for coming despite this being pretty much lunchtime. So, I hope you have a sandwich that you're going to join me for lunch afterwards. So, what I'm going to try to do today is to present you a number of tools and solutions that you can deploy within your project or within your company in such a way that you benefit from the current modern workflow that has been introduced by GitHub and popularized by GitHub, but still benefiting from the advantages of doing self hosting. So, owning your infrastructure in the edge of GitHub is not an easy task because there are some very, very big players in the field, and there are a number of reasons why you would not want to use your own infrastructure. Some of these reasons include basically convenience. I mean, if you host, if you don't host your domain name, you can use just Gmail's and you know, Gmail's works out of the box. It's free, well, okay, it's free. How do they make money? What's, if it's free, basically the product, it basically means that you are the product, you are what is being sold. So, Gmail is great, it works out of the box for you, but you are the one that is being sold to someone else. It's convenience, it's work, it has calendaring, it has to-do tracking, it works. You have other big players. GitHub just works. I mean, you create your project in GitHub, you upload your SSH key and everything works out of the box. So, it's really convenient to rely on existing solutions. There are also costs, consideration to take into account here. Having a team of people working in your company or a team of volunteers maintaining your infrastructure can have some costs. In the short term, in the longer term, these are things that you as a project manager or as a person running a company or not just a project in general, you want to take into account. You still need to pay for the domain name, you still need to pay for the hosting, you still need to have people that are present. If you're a community of volunteers, that does mean that you will accept the cost of eventually having your server offline when something goes wrong because eventually the community is not big enough to have CSAT mean that are present all over the world and therefore around the clock. So, it's, you know, it's a balance. It's something that you would have as a manager, most often you will look at the numbers and say, well, we can cut down on that expense because we can go to some other places. And then there is the social aspect. I mean, one of the biggest reasons why people are using GitHub, despite the convenience and the cost, is basically everybody is on GitHub. Let's make a raise of hand here. Does anyone in the room not have a GitHub account? I have three hands. So, I mean, a lot of good girls, guys. I mean, you actually survived the GitHub wave, so that's, congrats, you made it. But that basically means that people have GitHub accounts because other people are using GitHub, so there is a social component to that aspect. So, one of the things which you want to take into account is basically how big is your community? How big is your company? And look at what are the advantages of self-hosting. So, why would you self-host? Well, the first and foremost obvious reason is confidentiality. You don't want to have your information out there, then you keep it with you. You don't want other people to have access to it, then you keep it private. If GitHub has private Git repos, private projects that you need to pay for, but, I mean, there are still Git admins, there are still people having access to the file system, so, you know, in theory, it's not entirely private because other people will have access to it. If you're the only one with the access on the server, you're pretty sure that nobody else is going to gain access to it except for security breaches, of course. The second thing is convenience. The best part about self-hosting, so convenience you can see is both a reason why you would not want to solve, but also something why you would want to host your own infrastructure. So, convenience, the self-hosting is really nice because you actually get to pick what you want to host. You get to choose the tools for your needs. You get to compare the different solutions that are present and pick the right one for what you want. And that actually comes to the third point, which is customization. If you get to pick one tool, and if it's a tool that your sysad means, or IT team is, you know, let's say your IT team is in Python because that's what I'm going to talk about afterwards. If you deploy a tool which is great, but in Java, they might have a little bit of problems or need a little bit of adjustments to actually customize it to your need, make it, well, first to get it running, and then to actually adjust it for your needs. And, you know, if you want to tweak it, something, it gets a little bit trickier. And I'm not even speaking about proprietary solution here, where customization becomes a cost center and not a feature. And then there is the basic idea of principle. I want to own my infrastructure because I want to be relying on open source software because I want to. Because I know it's a cost, I know it's sometimes not convenient, I know it gives me a lot of flexibility, but it's just something which I want to do. So it's also something that depending on who is managing the project, depending on the spirit of the company or the team, principle can just be one of the reasons why you're owning your infrastructure. So I'm going to talk a little bit about what's, which kind of project I'm speaking about here, because there are a large variety of projects. So when I'm speaking about projects in the rest of the presentation, I'm speaking about community project. But when I say community, I'm not necessarily referring to community of volunteers, which you normally get in most open source projects, but I'm also speaking about the community of employees. I mean, your startup, your company itself is a community, and you all work together towards your goal, which is most likely getting paid at the end of the month. But your community might also involve both. You could have volunteers and you could have people paid to work on the project. So I'm, when I say community projects here, I'm speaking about all of these communities. When I speak about source code, I don't necessarily speak about computer programs, but that can also be designs. That can be documentations projects. That can be anything that multiple people want to work on. It could be expense reports for whatever it means. So yeah, I'll really mention some of them. So it can be all these type of projects. We'll have similar kind of needs, and these are the one which I want to present. When you run a community, so regardless of the type of community which I presented, when you run a community, the community is, you need a place where people can discuss, you need a place where people can exchange ideas, and nowadays it pretty much means emails. I mean, you can have different communication channels, you can have chats, you can have the coffee machines in the corridor. But at the end of the day, what you want is, you really want to have an email service. Emails are asynchronous. You can get them whenever you want. You can send the information and the people will reply when they can. And it also keeps tracks of what was said and who said it when and what. You also want to host your sources. So you actually want to host the core of the project, being documentations, designs, or computer programs. You actually want a place where you do ticketing. So ticketing is really handy because it allows your manager to say, well, we should work on that. And then it allows you to track down, well, these are the things we need to work on. And your manager can go there and prioritize tickets and close some and open new ones. It's also a place for the community to report ideas. We are doing that, and this is not working, but we should do that. And this will work. And then it's also a place where you can discuss change proposal. So basically this is what GitHub calls pull request, which gets itself call request pull. And it's just basically, I want to do this change whether you think about it. And then we need a place where, so we have different tools, we have communications, we have ticketing, we have source code. We need a place where you have a account system. You need a place where your employees are listed. You need a place where they can log in to the different tools. And you preferably want something which can cover all of your use case. So I'm going to go through a little bit of the three main ideas here. Account system, hosting, and communications. And I'm going to do that in the reverse order compared to what's on this slide here. And start with the account system. So the account system can be as simple as system user. So you just, someone comes in the company, you just create a shell account on the server, and they will use this username and password to log in on the different service. It can be a solution that is homemade. So the federal infrastructure is using a program that's called FAS, the federal account system. And that's something which is home baked. It fits our needs. It offers support to all the way people can sign in. They can upload their information. And then we go from that account system to the different machines that we run and synchronize information there. It can be something which is more enterprise-like or enterprise-ready. The big names in there are probably LDAP, free IPA, which is an easier way of deploying an LDAP, I'm going to say, which has a bunch of bells and whistles, which you probably want to look into. It makes your life a little bit easier. And if you're not in the Linux world, there is of course the Windows Active Directory server. So all of these are going to store your username and password, but then you actually need to use your user account to authenticate. And one proposal for this is the epsilon project. So the epsilon project is a pretty neat project. It's a Python-based project, so I'm going to specify this for all the tools which I'm presenting. They are all written in Python. One of the idea being that if you install all of them you get a certain harmony in the technology which is being used. So there are also solutions. I'm going to show you the solution because it's a Python project and it fits in the flow here. So you can imagine epsilon as being some sort of portal. It takes information on the back end. So the back end is like where you store your username and passwords and user information and it exposes this information to your applications. And the back end can be any of the applications. It can be a Kerberos system. It can be Apache Auth authentication. So if you do the famous HT Password file on the server, epsilon can just read that file and expose it to the application. It can use PAM. So if you do the first approach which I presented, which system local user accounts to the server. It can be basically anything. It's a simple Python file which has a single function which for a given username and password returns a true and a false. So whatever your account system is, you can just write it around a Python function and make it work with epsilon. And then on the front end, it exposes different protocols. And these are the famous protocol. I think everyone has heard about OpenID. It's a little bit less known than OpenID. And you probably have not heard about OpenID Connect because this is brand new. It's basically an OOF2 protocol on-stared written by the OpenID consortium. And that fixes a number of the issues that OOF2 was bringing along. So you can actually pick. You say, well, my company is going to use LDAP back end and all our applications are going to use OpenID. But then one of your applications is going to use OpenID Connect. Well, that's a problem. You can actually enable one of the front ends or you can enable two of them or you can enable all of them. So you actually free your developers from the authentication protocols as long as they rely on something which is known and well-developed. So if you want to know more about it, there is the epsilon-project.org website which provides more information. And bring a beer. But if you want to give him a beverage upstream is wearing the red t-shirt on the back of the room over there. Thank you, Patrick. So the second thing is, so now we have a consistent way of users taking out on tickets. The second thing is how to host your project. So we need a place where we host our source, where we do ticketing and where we do change proposal. For this, I propose the Pegger project. Like I say, it has ticketing, it does change proposal via pre-request and it can host the documentation of your project. So this is pretty much my baby. I'm going to spend a little bit more time on this. Just for in general, if you have questions feel free to interrupt. I might be going through open doors here, but if you have questions feel free to ask. So Pegger, what is it? So the first question people ask is how do you pronounce it? You can pronounce it however you want basically as long as people know what you're talking about. The idea is it's a French terminology for the hermit crab, for the family of the hermit crab. And the hermit crab is this little guy here that lives at the bottom of the sea. So it's a very small, it starts as a very small, I have no idea how to call that shell. Crab basically, because the shell is the whole trick about this crab. So it starts as a very small crab and it looks for a place to live and it looks for a shell basically. And as it grows, the shell doesn't belong to him. So it finds an empty shell at the bottom of the ocean, moves in, and then as it grows and the shell becomes too small, it goes to find another shell and then another shell. So this could actually be three different types of crabs, but it could be the same crab that just grew up and moved from shell to shell. And I really like, when we come up with the world, I really like the idea and the comparison because one of the main ideas of Pager is to be able to allow your project to move from a Pager instance to a Pager instance. One of the ideas which I had when we wrote Pager was being able to have two Pager instance in your company, one that is exposing the public information, the public link to the private instance of Pager and your developer internally only work on the private instance and your community can contribute in the public instance and tickets and pre-request can be synced from one place to the other. And one way we did that is that basically one project in Pager equals four Git repositories. There is one that is going to be your core Git repositories, which we all are used to, which contains the sources. There is one which is going to contain your documentation. There is one that is going to contain all the metadata of the tickets, so basically every comments on a ticket, every actions made on a ticket is going to be reflected on this Git repo and there is one that contains the metadata of the pre-request. So again, who opened it, again switch branch, what were the comments somewhere. That also allows for local access of the information, so if you travel, take an airplane or if you come to DevConf or live DevConf, you can actually clone the ticket repo and access it offline during the flights and you could actually comment, we don't have the CLI tool to do that right now, but in theory you could comment to the tickets offline and then when you find Internet again you just Git push and the UI gets updated from the content you pushed in the Git repo. I can say it could be used to sync project between Pager and it's also the mechanism that we are using if you want to migrate to Pager, so if you come from, so Fedora is running the Fedora Austit project which is a bunch of track forge and we are going to decommission that project and so we are moving people off track and into Pager and one way we do that is that we are eating the XMLRPC end points of track, generating the JSON blobs which represent the issue metadata, putting that in the Git repo of the tickets, pushing that and then suddenly all your tickets are moved from track to Pager. It can also be used to move between Pager instance like I said before, it can also be used to move off Pager although I have no idea why you would do that. There are two things about Pager also, we have very strong dedications to actually make Pager possible. If you want to run Pager, it is possible. If you want to run Pager against an open ID server, it's possible if you want to run Pager against using local user account, you can actually tweak Pager. It has three authentication models currently. It has FAS and the FAS login and first Fedora project contributor agreement so it's ensured that people that are contributing to Pager, it's basically the same thing as the FAS module except that it doesn't enforce the FPCA and you have local user account so you could have a public Pager instance and then people are just creating accounts as they want just like GitHub does basically. The second thing is that we are and are moving more and more towards service oriented architecture because as the project grows we realize that in a synchronous way it's not always the fastest and not always the most reliable in some ways. So to give you, since we are in the micro service topic, I just wanted to give you a little bit of an overview of how Pager looks like these days. It looks a little bit messy so I'm going to try to box you it's a little bit pointer. Let's start from the left. You have the web user on the left. Sir? There is a red point. So on that side we have the user and its web browser so that's the part that we care the most about because they are the users but it's a part which is not in our infrastructure. The core of Pager is basically the core of the application here, the web server, it's a flask applications and then this part here has then a number of services and it's a part to the web base, it updates it and carries it and then here we have a second service which is the documentation server. So the idea we need we basically use the documentation server to run it in a different domain name because the documentation is something which is uploaded by the users and therefore not trustworthy, sorry folks. To avoid any potential cross-site scripting we actually run the source hosting and if you deploy your own instance and you want to run the documentation server it's highly recommended that you actually do the same setup so two different domains. Subdomains is not enough you really want different domains. But basically so here we have, I'm going to throw the different service first and then I'm going to spend a little bit more I'll try to extrapolate on that. So we have a filter here. So a filter is a post-fixed filter basically. So when you comment on a ticket in the web UI it will send a notification to all the people that are subscribed to the project or to the issue and the user can directly reply to that ticket by replying to the email and replying to the email is going to go through the filter and the user is going to be reflected in the UI. So basically you can discuss around an issue directly using your mail client and not having to go to the web UI all the time. One way that we actually so when someone comments on the UI or via the filter to a ticket there is the events of server down here that actually sends a server sent event back to the browser to the web browser which means that when someone comments on a ticket they are actually able to refresh the page live or to add the comment live. So it's actually quite funny because when you have two people walking on the same ticket you can see the comments appearing one after the other. So it becomes like a chat system where you just type answer someone and then answer the next answer and so on and so forth. So it's really nice to see. That works so the live refresh works on tickets and the web book server which sends web book notifications. We have a CI service which is now at the moment tied into Jenkins. So basically when there is a pull request that is created or updated it will trigger a web book on Jenkins to start the build and at the end of the build it will receive a web book called by Jenkins to tell that the build was finished. It will then check what was the result of the build, did it fail, did it pass the information back into the pull request that started the process. And then we have a last service at the top here which is the log com service. And that's the most important service because you know the world famous by GitHub calendar IKMAP that shows your activities through the days Pagura is the same. That's the one that is responsible for filling commit information for you. So it's really one of the most important. So the nice thing about this design is that basically every single piece here is optional. Pagura itself runs if you want to run Pagura you just run the simple version you just run Pagura server and you're done. I mean you won't be able to use documentation but that's a configuration key. You won't be able to have web books notification but that's also a configuration key. You won't be able to have live refresh of the page and that's fine. I mean the core experience about a senior project is here. And one of the things that we are doing about how to integrate with Git is that we actually rely on Gitolite which is well known, well tested and I know it's the only piece of pearl that's going to be in this presentation. But I had at one point the idea of maybe moving away from Gitolite and use our own module that would uniquely look into the database if you have the permissions to push or create branches and so on. And actually someone was like please don't do that because one of the key ideas one of the benefits that he was saying in Pagura was that it was really an existing technology. So if you really have a Git server internally or in predictions you can basically put Pagura on the top of it and it's not going to change the experience that you are already using your Git server. So that's a little bit how it works these days. Some of the features I've already mentioned a few of them. You can reply to tickets by emails. We live refresh the page on tickets and pre-quest. You can do self-registration and it's basically a self-service. So if you do local accounts to Pagura you can do self-registration. You can create your project. You don't need anyone to create a project for you. You can create a new project button and you're done. It has the calendar activity map which is very important for manager because they show you what your team was working on. It has notification via webbooks but also via a fed message which is a message bus. So instead of having an HTTP endpoint that waits to be called you can just listen to the bus and react on events there. You can flag. You can get a bus which allows third party integration to your pre-request. So basically Jenkins integration is done by a flag. At the end of the Jenkins build the Pagura CI is going to flag the pre-request saying this service said it was 0% so it was a failed build or it was 100%. It was a successful build. The idea of using percentage is that it allows for things like report. For example, instead of saying 0, 1, 0 test build test fail it could actually tell you which percentage of the test failed and which percentage of the test built. So 99% of the tests were successful or 98% of the test were successful and that gives you an idea of how much test how much broken your pre-request how much how much you broke the wall with your pre-request. There are a few tag issues and the idea of tag is that you can actually then filter by tags and you can combine tags filtering, you can filter by multiple tags you can exclude a certain tags from your filtering and then when you're done you can actually save that in reports so that it's easy to share the link with people and you don't have a URL that is five kilometers long. So that's few of the features there are some more I'm probably forgetting some here so where we are now we have accounts, we have authentication methods we have our source hosting what is missing is basically a place where we can discuss a place where we can announce, change there is a new version of Pager where we can support outside of tickets so it's someone trying to do something doesn't want to do the tickets I'm trying to do this thing could you please help me for this the main answer is most often and for that I would propose you the Mainman 3 suites so Mainman 3 was released a couple of years ago it's the new generation of the world famous meaningless program, Mainman it's Python 3 based which means that it's while the other two are actually Python 2 based and it's designed around a core Mainman core which talks to the SMTP server and exposes a REST API which is then consumed by two Django applications Perseus, the admin interface and HyperQT, the archive interface so this looks, this is basically how it looks you get the SMTP server that doesn't look like an SMTP anymore here you have Mainman core that's retrieves information from the database, the admin interface that fills the database and HyperQT that goes updates the database and reads to it and gets the message received directly from Mainman core so to go a little bit more about HyperQT HyperQT's goal was to bridge firms and meaningless so the idea is that you can actually go to the meaningless or the UI and it would be as if you would as if you were on any firms so you could like basically post a new, start a new thread on the meaningless that you've not subscribed to and not get the emails about this meaningless you can go to the UI, start a conversation just follow that conversation ignore everything that's going on in the list you can be pointed to the conversation and just reply on the list you can reply on the UI without using your main client and it will just work and then it was I did some of the social network features you can actually plus one or minus one someone or a certain email you can tag conversations so that you're able to find them back it has one of the features that Mainman2 did not have it has search you can finally search your archives and find that email that was sent two years ago and that you know it was sent we already discussed that point and you can actually find it back now it also has some interesting statistics about the meaningless itself so it gives you like it gives you a number of females per day over the last 30 days so when you want to kick off a discussion it gives you an idea of what are the chances that you're actually going to get an answer it also gives you the most active people so that gives you an idea of who is going to likely to reply and is it a bot or is it a person these kind of things so it's actually being run by the federal project so if you want to see just see how it looks you can see at least the federal project attack so I think that covers it we now have a account system, authentication we can also also project and we can discuss about it so do we have any questions left? so how would I compare Pager and GitLab feature wise Pager is probably probably lacking some of the features let's be honest on that Pager was started about two years ago now and as one main developer myself and a community of contributors which are doing a very good job but under space time GitLab has a company behind it I assume is a little bit more than one person and a community of contributors so Pager definitely lacks some of the features from GitLab and from GitLab on the other side we are evolving very quickly there is a release of Pager most of the time I do at least one release a month and we have had people that have been working hard on it, pushing new features so it really changes fast and I'm very open for our fees and even more open for progress of course so yeah it's a country give an idea of how much feature we are lacking how much feature we have I do think we have things that they don't have and they definitely have things that we don't have so I didn't do that myself I know that so when I was seeing that Pager is strongly dedicated to self hosting we already have a few Pager instances in the world that we don't manage there is one from Pager Space in Bruno which has apparently nothing to do with Red Hat so Pager Space in Bruno folks learned about Pager by themselves and decided it was cool and deployed I've heard about a couple of companies deploying it and there is the community which is behind notobug.org that is currently running a forge using GoG so the goal line and they are not entirely happy with GoG so they are looking to move away from it and they did an entire spreadsheet comparisons of the different solutions available good, GitLab I'm not sure if you can see I was in there but Pager gets into that and apparently that choice is going for Pager so I don't have exactly the entire table in mind but there were a number of features that made Pager appealing to them more than GitLab was it might have to do with Python it might have to do with managing the thing in the long term but I wouldn't want to go into trolling Ruby right now Sure So the question is why do we decided to go from Pager from scratch instead of using GitLab so I have to go back to the generesis of Pager basically it originally started as something I wanted to play with Python and Git and see what kind of libraries are available and how do they perform and what we can do with it and when you want to play around with something you need to have some kind of project that you want to build around so my first went to do a Seagate like in Python and it was just a pet project I spent a couple of weeks on it and I had I was able to display commits to the commit tree, the commit itself I was able to do basic pre-request not everything was perfectly working but the basic was there and we then had the problem in the federal itself we wanted to have more people contributing to the real engineering part of the community and that implied having a place to discuss around features and pre-requests and GitLab was not an option GitLab was just out of the plate but that means it was something that we had to host internally or in the federal infrastructure and GitLab has been trying to get to get into federal for a few years there has been at least that I know Google Summer of Code dedicated to packaging GitLab to actually be able to deploy it at one point but one of the requirements of the federal infrastructure is that things have to be packaged as RPM and therefore GitLab is just not available as an RPM in federal or IPO so one of the problem of GitLab is it's a huge pile of Ruby gems and managing the dependencies in Ruby is a little bit of a tough and unpleasant work I apologize for any Ruby person in the room which makes basically packaging GitLab there has been years of trying to get GitLab packaged and that never succeeded so we were left with project like Calicia there was also Fabrikator that was on the roadmap but I actually discussed with the Calicia upstream a couple of years ago and they are very strongly dedicated to review requests so it's a little bit like Garrett but much less about project hosting so a ticketing system was something that they had in their mind but something which was like long way down the roadmap so maybe they will come with a ticket feature if someone comes up to it but it's not a priority for them and it wasn't their use case so at the end we had the prototype of Pagure that was kind of working we had GitLab that wasn't packageable there was Fabrikator and Calicia that don't really have our use case so we got a green light to go with Pagure and it was like okay let's do it and that's basically the genesis of Pagure the question is which license is Pagure it's a GPL license I believe version 2 it's not even a GPL it might not have been smart but we were nice so you can host it you can have your own modifications and redistribute them or not that's not using the A currency basically more questions, more RFEs Rotten Tomatoes, flowers well thank you then one of the single Fabrikators I really don't like the UI and it's like Calicia the use case is really much about reviewing changes I think Fabrikator has a little bit of ticketing you can use the task for tickets but I don't think it has the modifications or even codos yes because in KDE we are moving to Fabrikator yeah one of my problem with Fabrikator is making the UI I just don't like it we have a Fabrikator instance running already so I was very much like I did this prototype Reliance Engineering was looking I let them basically look at the different options and they were like okay we're going to look at yours for me but yeah I did not myself did the comparison between Fabrikator I can say that I'm always lost when it comes to the UI what does it do what does it not want as I wanted to but that's I know that the Calicia guys were very strongly in favor of for requests not really much not much into ticketing Fabrikator does a few things I don't know how easy it would have been to move from track to Fabrikator or this kind of thing thank you do you have some time to sit down and talk about the migration of the different ambassadors in France do you want to go for lunch at one point I don't know if you want to eat if you have already eaten no I haven't actually I'm having a problem I'm so tired so tired so she's she's she's she's she's she's she's she's she's okay then we're that's perfect that's one of the things we have here in I think it's here where we know we think it's more so we can find some space or try to sometimes it's only about the access and we then we like to stay for like I think that you have this what state real estate and let's let's we are we're they're outside we're We're we're we're We're we're we're we're So it's easier if you change something in the classroom. A lot of people work in the NGCF, so it's better to do that. So the children work in the NGCF. Okay. How's that? So obviously this thing is really important. So I mean, it's easier if you just, yeah, that's what it looks like. That's the default that you send your peers. If you add something new, it's fine. Yeah, it's a special thing. It's a lot easier if you're a teacher. But you don't have to deal with it. Because that's... Okay, that's something that is really small. Think about the... You may have a little bit of patience that I can find. So the track is real. It's fine. It's all just a shot. It's true. I think that is okay. I'm still okay with getting it. It depends on the situation. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. So this is something that's been going on for a long time, so I've never seen it before. That's why I'm so excited to see the question now. So what is the end result? So this is actually going to be looked at later. So this is later. So here's all of this, the extreme, all of the important aspects of each person. So this is a barrier, and the strengths of each person. You can find a way to get this all together. You can do a lot of things with a lot of stuff. You can get all of the questions. You can do a lot of things with a lot of stuff. And you can get all of the questions. And the end result is going to be a lot of questions. So I'd like to see what you guys can do. That's going to look at everything. Okay. The thing is, like, we have, like, we have reports of all the expenses we have. That's going to be a group. Not this one person, which is, like, a better problem for all of us. But I would just add that person. See, so now everything's going to be more real. It's a group of people. Okay. So we're going to be able to do all of this. We're going to be able to do all of this. We're going to be able to do all of this. We're going to be able to do all of this. Okay. All right. I would just agree. I have an iPad actually, Bill will be okay. We had some problems with Macs. Yeah, I had to use VGA. I had a problem yesterday with the laptop, so I already need to go get it. That's fine. So it's a different approach from the time. Do you want to just speak or have the questions at the end? I think I'll have. I should have time for the questions at the end. So it's like 40 minutes plus 10. Yeah. And I've already started giving you the signs, like 3 minutes, 5 minutes, what? Great. And so far. I just remembered, the microphone here is in the ear, just look at the corner. Okay. This one is in the ear. And you can look at the questions. Really? Yeah. And I have somebody else here who has these discussions at the end, but not the left one. Okay. I can do that. Do you want the speaker for the slides? No, I don't. I'll just click on mine. Okay.