 I'm gonna just get one test from somebody to speak. Hello! Hello! Hey. Awesome. So welcome to the Team Q&A session. We have quite a few people in this room, so hopefully it works fine. Just a quick round of introduction to the people we have. We have Levent Poljak, the project leader of Arch Linux, also part of the security team lead in the security team reproducible builds. We have David, Dave the Rave or something, which I've learned recently, his nickname is, he is the ArchEason maintainer and had that talk at 12 today. We have Jonas Witschel, which is a fairly recent TV addition. He works on the TPM and does a lot of packaging on the TPM stack. We have James Allad, his name is, he's one of the ArchEason maintainers. He also writes AOR utils and does also some RCOP stuff. We have Philippe Lainz, also called FFY00. He does packaging mostly on some Arduino stuff, my controllers that I can recall. We have Sven Staro, he does infrastructure stuff. And in general, he's a developer and does packaging. We have Green Carlo Rasolini, which is an Arch developer, maintains MK in its CPO and packages a lot of stuff. It's a bit hard to remember what everybody's doing. Javier Levanderva, which does a developer, works on the security team, reproducible builds, and ArchWeb maintainer as well, if I recall correctly. And we also have Bruno Pajellini, also called ArchChange, but I think he's dropping a little bit in and out of the sessions. We'll see what happens. And then lastly, you have me, FoxBaron, also Martin Linderu, I do security team stuff. Reproducible builds, I also organize this conference and sort of producing the entire thing, which is why I have a nice camera. So yes, hopefully this is working fine. This is the first time trying something like this. So I hope this is interesting. So we'll just try. We have, I see the same language has been doing a little bit of questions. So we'll just take the round table once first to get things started. What's the most fun or interesting part working slash being part of the Arch Linux team? Anybody wants to start? Hands, raise a hand. So Ella, what's the most interesting part? For me, the most fun was meeting everybody at the conferences at FoxBaron, CCC, at ArchComp last year in Berlin. Oh yeah, it was fun. And doing things together. So that was the most fun. But the question was, I guess, the most interesting, right? Yes. Eh, oh, you know, everything's interesting. Yeah, but generally conferences are great from doing the CCC part. Faustem is great, meeting people. There was also that room. I'm sure if anybody else has something else to add on being part of what's fast fun with Leventa. Leventa wants to speak, yes. Yeah, basically, I just wanted to repeat the same because I still want to take a little bit focus on people because we are not just a technology, we're actually people behind the technology. So for me, it was also meeting people at the conference and then having not just nicknames behind some work, but actually pieces and persons. So I agree. Yes, David? Yeah, the social aspect for sure. But also in general, I think it was really interesting to find quite open spaces for things to be improved, to find projects that you see like, oh, nice, oh, I can fix that. And then suddenly you maintain it. It's not always a good thing, but it surely is also very interesting and a great feeling that you can actually contribute and change something that is of value to not only yourself, of course. Yeah. Personally, I think one of the most interesting parties, you sort of work on this sort of in isolation, but you rarely sort of have these kind of conversation. So one of the more interesting parties when we did the first at the Chaos Communication Congress, the first Q&A session we had live, I just had the organized self-organized session, didn't promote it at all, but sort of it wound up having 150 people bum-rushing to a room and starting interacting. And it was a really interesting experience to just have that overwhelming feeling of, oh, what people actually appreciate the work you do and then having an entire room full of 100 people clapping to the work you're doing on the free time. That's, I think that's super, super valuable. So you have a lot of questions that we just continue. And we can probably do, is it worth becoming a TV if you want to bring one package only into the repositories from PostFactum? Anybody wants to answer? We can do Sven, if you want to answer. Well, sure. Frankly, probably not. I would say if you take a look at the repositories and maybe if you can find some orphans, we have tons of orphans. Maybe outside contributors might not yet know about that, but actually it turns out that we have some unmaintained packages. And if you were to go in and maybe interested in picking some of those up, that would be great. And this would be a great reason for you to become to you. Anybody else has something to add or something you'd like to speak? We can also personally, if you have some sort of pet, not necessarily just one package, but a group of packages with a common theme, we recently had what is there for elementary, which Eli and the Shibumi sponsored, Raster. Raster, which is one of the upstream maintainers of enlightenment, I guess, I think, which also reached the joint, well, basically the main enlightenment packages. So is there any chance Arch will be doing Google summer of code and outreach in the future from Mascaroon? Yeah, you can answer. Last year we applied for the Google summer of code, but we didn't get accepted. This year, I think we will try again. And, but the main issue, the main problem is that somebody really has to drive this from our team and the Google summer of code requires quite a lot of time investment from our side, which my, yeah, is a tricky thing because we're all volunteers, right? So for outreach, I think we also looked at this recently and it requires, I think, us to sponsor somebody, which, but the same thing applies. We have to find time to, somebody from our team needs to take the time to submit everything and mentor somebody. Yeah. So we also have some texting question. One will Arch get debug packages from Al and Ramsey, loaded question. Anybody wants to answer that one? Levente. I think in some regard, we're pretty close to that. We also have tried different approaches, but it also depends at the end which way we go. And there are also some technical challenges just to name one. Yeah. We use some split packages to also have different variants because it's actually not really feasible from a package perspective to have multiple sets of different things while they're still the same. And the issue which comes in mind is having the same pass then, which leads to problems with debug packages. So I believe if we go that way, then maybe we will get it when we have an alternative system in Pac-Man ready. Vincarlo, you had something to add? Vincarlo. Okay. Alad, you had something to add. So as far as line mode, thing of a debug packages, it was like limitations in DB scripts. So whenever we talk. I wanted to mention that if you want to have a look on the alternative, can you guys hear me? Yes. You can hear you. Is there a slight delay on you? I think Crosereen has a slight delay on this feed. Alad, you can just continue, I think. Sorry. Okay, right. So when we were always looking at the Git migration, just like we like our adaptation of DB scripts, the thing with debug packages would like always one part of it. So the idea was if we get to Git migration done, we would at the same time get the thing with the debug packages done. And it's been done more than a few times over like this year already. And like there was a new initiative in the last part one, but then it's sort of lost and then because of people working on it, didn't have time and so on. So hopefully that will improve later. Yeah, I can also add a little bit on that. So I think Eli already did a quick patch for DB scripts to have a separate pool of debug packages. We've also been sort of looking into how debug info D, which is sort of a debug package server you can connect to and sort of figure out how we can, if we don't distribute them, we can at least provide some way of retrieving the debug symbols. There are patches, but there still needs to be some work on that migration path. So we have a question from Oak. Anything new on the seamless reboot free kernel updates? I think he's mentioning the kernel hooks, which would potentially like sim link and clear up the modules, library stuff. Anybody has something to add to that? Want to answer it? Leventa, project leader, do you want seamless kernel updates? Do I need to answer now? No, I can. There's been some movement in the bug report, actually. I'm not sure if you follow it, but there's been some recent, I think one of the Linux from scratch, book authors is also contributing to that discussion. But yeah. Yeah, I'm also subscribed to that issue. I guess it still boils again down to actually having people on our team being interested in the topic. I mean, not just responding with ideas, but actual having some open discussion, which leads to some kind of implementation, which in my opinion is still lacking. So as long as we don't have anyone who really wants to work on this, I can't really do give any estimate on it either. So are there any plans to make Arch Linux available on Windows subsystem for Linux? I'm not sure. Did some discussion on that previously, but does anyone else have something to add? Aled? So it's been brought up a few times in the past and basically the like stuff like trademark issues, like the Arch showing up on the Windows store and some weird image with all kinds of modifications and unsigned repositories and whatever. And in the end, it was decided that there would be no support for it, like not on the port, for example. Like even on the Arch Wiki, the WSL redirects to Arch Linux support only. Yes. So I don't see it happen. Yeah. I believe part of that was both the trademark issue and there was also an issue in terms of support because previously at least on WSL one, there was some patch to G-Lib C and kernel stuff going on and you'd have to essentially be supporting a secondary system on top of it. So let's see what we have in terms of questions. Are there Arch developers trust users who use Arch in a work slash enterprise company context? I use it for a PXC booted rescue system on a few hundred machines, but I feel alone with this setup. So is there anybody out here that either deploys Arch in production at the work or use it for work stuff? Yes, Sven. I actually do quite a lot actually. And the reason is that, well, so I use it in multiple contexts. So I work mostly for enterprise clients currently and it actually is quite the advantage to be able to get all the most recent packages. And especially when I do Docker builds and I use Arch Docker, the official Docker image I actually quite a lot for our CI just because it's faster usually than just getting the packages as opposed to using some Ubuntu image and then maybe hunting down some PPAs for some GCC, whatever. So yeah, and it works really well actually, but I don't really deploy it on any scale. It's more like for myself and for CI, but I wouldn't give it to my colleagues, for instance. Yeah. Why is there not a graphical installer on the ISO, David? Oh, that's a long heated topic, I guess. Mainly because no one has done it. Secondly, because there's often like a controversial around what Arch should be like. I think over the past years, it has fallen under this conception of Arch being this hard to install type of gateway kind of thing where you're not really having an easy time installing and that's supposed to be like this because we kind of leave out the beginning the beginner users, et cetera. That's not really the reason. The reason is more like no one really spent time on this. Arch ISO in itself has been unmaintained for a while and has been kind of bedrotting also a little bit. And I mean, you basically need to really work on concepts to make this happen. And this is something that there are initiatives for, but this requires time, of course, and also to get this right and not just randomly provide people with installers or something like that. It's a lot about integrating from what we have now to something that makes sense from the standpoint in which we are now. And it requires time, but there's something in the pipeline, at least. So you can just continue that tangent. Is there any plans to make the installation easier? Yeah, I'd talk as well, but I can just continue on the same tangent. Yeah, in a way, I would like to see that a lot because it is an unnecessary bottleneck to some extent to have manual steps or many of them that you script away then either way, which leads to a gazillion of custom user-based scripts that, oh, this is how I deploy my system. And then you have hundreds, literally hundreds of that stuff flying around. And no one really knows how that works. And if you try to debug that together with that set user that messed up his or her system with it, it's really hard to trace these steps to find out what actually happened, what went wrong. If you have no way of tracing it. And therefore, I think it would be nice to actually have some sort of template-based installation that makes this easy and also traceable for us and for the user. So you can take, how long can we take, Sven? So one maybe less known fact is that we had an install in 2012, and then one of the developers took that project and continued it to ArchBoot, which is like some... So one of the Arch developers has one of these images. It doesn't always work. There was a time where it didn't work for six months or something. So it's basically only a thing that you use. It's like, you know, what you're doing, or it should fall out from the way before, but it's there. So that's one of the more classical approach that you'd have 10 years ago, some menu that you clicked through. But what David said on his templates, stuff that's... I find it also interesting, and I think maybe last year a bit more before that I was someone who proposed something like this, but I think there was like one guy, some sort of... I think it was a bit comparable to Ansible. Something like that, like the infrastructure from Arch, it's all to this Ansible to set up all server and so on. I think that's also an interesting approach, but I guess there wasn't really that much interest in it to continue it. But there was also some other like internal discussion. If you could use like some graphical projects or whatever to install it, but I think it's very much like, so either there's not that much interest or it's still a work in progress. Yeah, so did you have anything to add? Yeah, so I think probably the primary challenge is really that nobody really knows how an installer that is compatible with Arch philosophy would actually look like. And I think the primary or all the graphical installers that I know about, primarily Calamaris, they mostly focus or primarily focus on getting the system installed for the users quickly and without any friction. And now the thing that Arch has this error about it, that it's kind of elitist or hard to install, and it's really not that we try to keep this up, it's more like it has to be this way in order for us to be comfortable installing Arch other way, because it means that we have all of the customizability in our hands during the installation. And if we had an official installer that is graphical and everything, it would have to follow in this vein in these steps. And so it's just something that this is a problem pretty specific to Arch. And so we can't really copy from anybody else. And this is why it's conceptually so hard to come up with this. It's not like we are opposed to graphical stuff. I mean, we're all running graphical environments, I think. But this is just kind of the background on why this is so hard for us. Levente? Yeah, I also agree on what Sven said of that being hard. But at one point, we also should at least a little bit reconsider and see how we could make things work, because right now from an accessibility standpoint, it really sucks. And we're excluding a bunch of people we really shouldn't exclude. So at least we should, at one point, I guess have really in discussion how we may want to approach some stuff and how to tackle those challenges Sven mentioned. Philipp, you had something to add? Yeah, I have thought in the past about trying to include accessibility features in the ISO. Doesn't need necessarily to be a graphical interface, but just a simple vice to text setup so that you can just take the commands and the ISO will type them, which I think will increase the accessibility for a lot of users. The problem, I think, is just time. Yes, I know David has been talking with the talk arch. Maintainer about providing some more accessibility. So hopefully something gets done just in the base ISO. I'm just going to try this a little bit along. So what's the most challenging thing you've done as part of contributing to arch? Does anybody want to answer? We can take, I think Greencar is still sadly disconnecting. What you can take, Levente? So basically it was also the reason why I started to get involved in arch or more. Like at one point I was like, okay, we don't have a security team. And also Ellen made a call for action on it. And I was like, well, okay, if there is none, but I really want to have one. If I'm using this distro, then well, I guess I need to get involved and do it myself. So this was basically my motivation, why I stepped ahead on that regard. And it was quite challenging creating something out of nothing. Alec? I think the hardest part for me, like when I joined, or when I started using arch in like 2014, there was this, for the installation, there were like two guides on the ArchWiki. There was like a beginner's guide, which was like a very huge detailed guide for, which was like 40 pages long, and it was a very short installation guide, which was like maybe two pages, and almost like contained a very limited amount of information. So what I did, it looked like two or three years, was to like put these two guides together. And I think that was like a very challenging part, because you have to like adapt to two audience now. Like one part of the user-based audience wants to like, just to read some page and adapt these instructions. Like very general instructions, without like having to necessarily like, choose some specific option that is best for them, but just like some generic recommended option. And then the other part of user-based wants to like, have maximum flexibility, and choose everything on their own, and read everything and whatever. We have to like now, we have like one guide for both of these audiences. So the one thing it meant is that actual articles in the Wiki would have to be much better, because like five or six years ago, there was a lot of information in this beginner's guide, right, in this very long page, and there was not a lot of information sometimes in other pages, not very organized. So we had to like adjust all kinds of pages to have more details, so that they would work from a smaller guide. And that took a lot of time and effort and discussion with other community members. But in the end, I think it worked out for the most part. The bonus. So one huge challenge, but I think the nice thing about Arch is that you actually, in your day-to-day life, always encounter situations where you don't really know what to do, because some package updates doesn't mean it doesn't build anymore at all. And I think the nice thing is that you always have some people to rely on to ask how to do that. And I think it's a great opportunity to learn new stuff. So if you want to get involved, don't think it's too hard. I could never do that. Just find something you want to contribute to, and you will learn on the go. So you can move a little bit forward. How much time are you devoting to arch development and do you have day jobs related to programming slash development? Who wants to take a stab at that? Alec? For me, this year was pretty hard to spend time in arch because now I'm doing my master in mathematics and I have to move to a different country and all kinds of stuff. So I think it's like, because we're all doing this in our free time, sometimes it's sort of hard to take time away from your actual life and spend it on arch. And I think that's also sometimes why some projects like the thing with the debug packages sort of stall. Because people just have a life or work of their own and then they can't always spend it invested to arch. So that's just for me. So what I usually do is when I have some extra days in some months, I usually take some extra days to spend a lot of time on it and then maybe some time after I might not spend so much on it. And then I take another set a few days and spend a lot of time and so on. So I'll put a look at the time that I have and then when I have it, I try to take advantage. Personally, I do security engineer work as my day job but a lot of my personal free time is spent to order to Arch Linux. Like the conference has taken a few weeks to organize along with my standard packaging maintaining. I, Sven, I think was first afterwards. I lost a little bit of track of who's, who? No, who's- Right. I'll just, I'll just go ahead really quick. So I spend, I think, about an average of like 10 to 12 hours every week on Arch. So not quite part-time, but not quite nothing as well. And well, I do much of the same stuff I do in Arch. I do professionally. So I suppose it kind of gets naturally and probably kind of stupid to be doing the same thing that I do professionally in Arch, but I don't know. It works for me. That was Philippe. Philippe, did you have anything to add? And it's silent. You guys can still hear me, right? Yes. Awesome. Where you had Philippe, yes? Yeah. Okay. So you can hear me. Yes. Now we can hear you. You don't need to mute me because I'm muting myself. Right. So I spent a few hours, but it depends on the, on the weeks and what I, what I'm doing. If I am just updating packages or adding new packages, that sometimes that actually requires a big amount of time. If I have to pull a bunch of dependencies and make sure everything works together. But yeah. So I am studying it. So I do have a little bit of time to contribute, but yeah. Even when I'm in school, I sometimes end up doing art stuff in the background. We can, we can try. Gracilini has a six, seven second delay, but we can try, we can see if you can get an answer for him as well. In how much time do you spend on Arch Linux? I'm not sure if you can hear me. If the delay is a little bit longer, we can... Yeah, guys. So I spend around, lately I have been spending around 34 hours on Arch weekly. But yeah, I try to spend around 10 hours per week. It's a, it's a, it's a little, so you have to, to calculate how much time I spend, but lately have been quite difficult for me to spend more, right? But yeah, that's around it, it's good to spend four hours per week. Yes, thank you. So let's see, more questions. What's the best learning lesson from contributing anthrax? So for me, it's quite specifically at, and it is very far back in the past, but the biggest lesson I had is basically, I think there are different stages of evolution when you start contributing to open source. And for me, the biggest step was basically when you stop just opening bug records and complaining about stuff, but actually start fixing it yourself. Because, well, at first it helps open source most because you're actively contributing to it instead of just complaining about something. And at the end, basically, this is the way how you get your stuff fixed the fastest. Just do it yourself. And so this is the biggest lesson or learning basically I can give to everyone. Stop complaining and start doing it yourself. And this, I think this is nice. I will also to the, to another question, which is what drove you to join the Arch Linux team? I think this is probably some few people share. They have some issue they want to solve or some scratch page. And then they start contributing, David. Yeah, that's basically one of the reasons why I started contributing to Arch, because all of the pro audio stuff sucked, because there was just no one maintaining it anymore. And I got really frustrated with that shit. So eventually I just applied to become a two and started fixing these packages. And more and more, these packages either got dropped from extra to community. And well, now I have a lot of packages. That's not necessarily good, but it's kind of nice that this is kind of in better shape again now. I'll try to find people actually to help maintain this because this is something that truly is something that can be dealt with better in a group than only with one single person. And yeah, so if you're interested in packaging, there's a lot of audio stuff, a lot of multimedia stuff also that Arch has in the repositories that requires maintenance. And it's always better to have more than one person on it. And hopefully with an eventual Git migration from SVN, where we have a lot of the packages on GitLab instead of the SVN repository, where you have to attach patches to bug reports or email patches to maintainers, hopefully it'll be easier for people to get started maintaining stuff. So stay tuned for that, maybe take a little while, but hopefully we get there. Ah, we could take an easy one. Okay, now, Alek, do you want to add something? I just wanted to add that on the question with the installer, I was wrong on when Arch Boot came out. So it was like at least 2008, like, Ellen linked the change lock in the IRC channel. Questions, questions, questions. So how often do you guys update your systems? Personally, I do it once a week, and then I'm not there, so I do partial updates on the kernels because I can't be arsed to reboot that often, sadly, but usually a weekly update. What do other people do? I personally do it basically daily, so when I first set in front of my computer, the first thing I do to basically get awake is doing an update. Yes, that's all brand considering your polo shirt. Flippa? Okay, so I tried to update it at least every couple of days, make sure that I don't have a big backlog of packages to install. Then we can take Gracelini with a slight delay on answering, hopefully. Yeah, so I tried to update the data as well. The only time I don't update is when there is some kernel updates and I can't reboot right away, and I try to start my day by updating everything. The funny thing is, is that I have to update two machines because I use a VM for work, so I have to update twice, that's the thing. But mostly updated. Nice, anybody else has something to add? Yeah, I just update every few hours to be honest. Which are without testing? With testing, I always run it. I think on all of, no, I have one server that doesn't run testing, but apart from that, I update most of the time. Oh, yes, the perpetual updating of Arch Linux. Yeah, I am the meme, essentially. Oh, yeah. So what's the first thing that people do when they get a fresh Arch install up and running? Personally, I get my .files set up and patch stuff from my backups from the previous computer and set it up. What do all the people do? Somebody, Sven? Yeah, I also get my .files is a good first one, but I think actually I transfer some SSH stuff that I need first and then set up my .files because I also need some files and then usually some graphical environment and then usually actually I'm set. I never reinstall, what's this? Yes, that's also perpetual Arch installations using the same hard disk and just direct over and just boot it up, fix the fstab and you're good, some people do that. We can take an interesting question. If Arch had a paid position, what would be the first position slash responsibility to use that salary on? So essentially if we could pay someone to work on Arch, what would be sort of the most critical or the things we should be solving, probably? Nobody has something to add? Switching your post stories to Git. David? Yeah, mainly infrastructure, I guess. That's always a good thing to improve. We have lots of legacy systems that we more or less want to get rid of and being able to work on that full time would probably improve that switch, I guess. Fasten it. Yes, Sven? Yeah, I think generally speaking, things that nobody wants to work on for free. Things that just aren't fun. We do all the Arch for fun. Things aren't fun. You need some, let's say, extra motivation. Hi, we need Git migration. Okay, here's like a thousand lines of bash code that you need to sort of figure out and solve. And that's not fun, but it needs to be done. It's slow. What would you tell yourself if you went back before you started calibrating and sort of what would be your words of wisdom to yourself? Levanta? Basically, this is a little bit funny because I really was basically distro hopping back then. And at least on my home machines I was running Gantu, which basically I was super annoyed about compiling all the shit over and over and over again. So what I would tell myself is, go your path you are about to go, but don't do it because you stop compiling shit. Because it turns out I now compile all the shit. So at least I'm pretty happy that it turns out like this, but I'm still compiling shit. So... There's somebody else I don't think that I'm not sure if I completely get all of the hands ups. Nope, then we can continue with the next question. How do you guys test package builds and manage to maintain that many packages in terms of to use Arch, root and spawns, QMU, other VM stuff? So I can just quickly, first I just use the DevTool stuff with a little bit of custom scripting with IORutils to sort of have new dependency cycles tested before entering the community, but a lot of that is still just being built with end-spawn. If somebody else has something to add, anybody does something special with testing their packages? We could take David first. I do some testing on certain packages that are a little brittle and weird when they concern audio and so on, especially when it's packages that are like core feature packages such as Jack, etc. Then usually I try to test this upfront. And I mean, sure, we also have the testing repository, but it's often much more interesting to test this locally, especially if it's something hardware-facing, hardware bound that you can actually test on a real machine. Quite important to do that yourself or find someone to do it with you or for you. We could take Dibonus. I should write this down. I don't. Yeah, apart from, I mean, basically, obviously it's always good if you use your package yourself because then you realize when something's wrong. But I also found that just some basic sanity checking already goes some long ways. So if you just use Difascope or just compare the files you had in the old package versus the new package and you see that a lot of stuff is missing, then maybe there's something wrong. So basically looking at your package before you install it can help fix a lot of problems that you miss because you didn't add a new dependency, for example. Yes, I will try Gracilini. I'll poke him on RSCs. We avoid delay. See if this works. Yeah. So I tried to run, I run testing and I tried to make sure that I test everything on bear. There are a few things that I use VMs to test. So for example, I use VMs to test MEK and ECPAO and some other things. But basically, yeah, I run everything on bear and I try to report guys because this is very important. I report with something's broken because we have very few tests, right? So I try to report everything. Cool. Then we can take Philipp. Okay, so I just usually try to check for the differences in packages when I'm playing. I also usually always check the tree of the table to make sure everything is fine. And then I just run it locally to make sure everything is working. I also try to keep myself updated on the changes in the upstream. So try to know what went into the new version, what changed. So if something breaks, I have an idea what might have caused it and it also helps with compatibility with other packages. So if something changed in some place that can have side effects and break other packages. So I try to keep that in mind when updating, but generally I just test locally. So yeah, I think that's sort of all the questions we had had time for. Somebody has in the last words for the viewers watching us live. No, get involved, guys. Oh yes, get involved. Absolutely, absolutely. Find something to work on and just get involved. Yes, email people, talk with them on RSC. Yeah, that's also what I always urge people to do. We are all people behind the technology and we make the technology. So just stop complaining and start doing it yourself. This is really the best thing I can recommend to everyone. And it will be the best thing for you personally as well, because you get your topics to think you are very interested in fixed or implemented. So just get involved. Just help us. Yes, so I think we'll take a round over there. I hope this was interesting. A little bit interesting doing this entire Q&A live with all of the impulses and questions from the chats. So yeah, now it's time for a break. A new DJI set and we'll see you guys after the break.