I mean, we are, if I recall correctly, six or seven people, no? About 10. Yeah, eight, sorry. And well, most of them couldn't come because most of them are based on the use. So that sucks. So what are we going to talk now?

It's what we did, why we did it, and why we are so stupid ourselves, not you. So first thing we would make to make clear

is that, OK, so first thing we want to say is what the UDEC is not. And the first thing we want to make clear, it's not a hate-based fork. We invited Leonard, Kees, and Greg to come here for a reason.

I have something for them.

No, not a fork either. Thank you for giving us cause of this talk, right?

It's our way of trying to say you thanks, and we don't hate you, really. I mean, we have nothing against you. We might make bad jokes, but that's it. It's just bad jokes.

So what is, aren't we? Well, we are not an attempt to make Gen 2 users switch. Greg Dea probably knows about that as much as we. Gen 2 is usually about choice. We have this thing called use-black, which means you can even choose what your package will be built with.

And as such, we understand perfectly that users might want to use UDEP instead of UDEP, and they must be able to do so. And we like them being able to do so. It's good for everybody. So it's also not a lot of crazy coding.

Well, it's used to, but not anymore. Right now, we are doing quite extensive code reviews when we are working on it in order to prevent the insertion of bugs and stuff like that. And usually, a commit has to be reviewed by at least one other UDEP developer. And if it's a quite important commit,

it's necessary at least two reviews before it's accepted. So in that aspect, we are doing our best to make, well, good code at least. It's not untested code. We try our best at the code we do before we even publish it. Because we know that a bug in UDEP

can be a serious problem, because it can mean a user cannot boot the system, for example. That could be something really bad. It's not an end-to-only thing. If there is any other distribution developer out here that wants to join us, he can do so. If you want to use this on your distribution as an alternative to UDEP, you can do so.

And if you have any bugs that are related to UDEP on anything not gentle, please fill them. We will try to fix them, really. And yeah, it's not a closed project indeed. If anybody wants to join, he's welcome to do so.

So this is just a few of the people that have committed to maintaining UDEP and just making it work. We have Luca right there, Lucero.

I tried to get Anthony Bastille, Lunas, to come here, but he's teaching right now, unfortunately. He's been doing a lot of the work on the build system. He refactored the makefile and stuff like that.

We have Francisco Klondike already. AXS, I don't believe that he made it as well. Matthew, hi. Tony Vroon, he unfortunately could not make it either. And Richard is actually with Anthony as his student.

The way these things work. We told you what is not, which is the general direction. Meaning, OK, we took this code, we threw it apart,

we put it back together. What are we going to do with that? The idea is, well, the usual stuff, more or less. We want something that is simple, clean, and possibly with the edit so you can read it and your eyes won't bleed.

We try to stick to the standards, meaning that we try to get rid of everything that is not exactly C, like glib extension or something that is quite specific, but you can do without. So you then can build with like C-lang on Ulibc or

something like this. Some people need that. We provide that. Well, most of the people involved are sort of interested in this kind of provide alternative. So, an alternative libc should work with our project.

Yes, or even muscle, more or less. Then the other direction, we try to keep everything as separate as possible. So if you want to mix and match, you can. So we try to provide, yes, support for all kernels,

support for all way to write rules. When it's possible, we do. So if you have something that is a legacy system, you cannot update the kernel or it's quite an hassle to update all the rules, then we provide you a way to survive.

Pretty much that's a generic idea. Oh, well. So short term, libc-agnostic. There are lots of glibc-specific code. We try to remove them, replace it.

Sometimes it's easy, sometimes it's, well, requires a bit of more effort, but we are trying. Compiler-agnostic. Okay, we still need a C99 compiler. That means that, well, you have not that many opportunities, but the main one are supported.

Yes? Okay. Kernel-architectural-agnostic means that, okay, we got new goodies with the new kernel, but we know people that are

struck with vendor branch that are not updated. And so we try to support them. File system-agnostic. Okay, we got lots of people that have a large deployment that use some kind of strange or weird layouts. We try to support them.

It's not just using udev that will magically solve all your problems, but if something is not broken before, still our version won't warn you or do stuff that prevents you to boot. We try to, yes? I'll just read it.

So the question was, what are we doing different in that regard? I don't remember which version more or less struck some user like a thunder because they forced you

to do something, actually, you won't be able to complete the boot because you need some specific feature. Yes? I mean, you listed that separated slash user

was something you want to support, but we support it. Now what that's, you're saying, because upstream udev does support such as fine. It has forever. And it has forever and nothing changed there. A simple branch.

Yes? Okay, well, I'm going to tell you what we are going to do with back and what we have already done. The first thing we did was making a package that could work well in Gentoo.

That was not your fault. That was Gentoo's package's fault. Now udev works well with bar user. And that's because the things we have learned whilst doing udev have also been useful for the udev developers. But in the future, we try to improve a little bit on that aspect.

I mean, we want to, for example, be able to mark rules as needing particular mount points and listen to the kernel to wait until they are mount. So we can wait. And before we apply that rules until the mount points are already there.

Okay, can you repeat the question? So you want to run udev and slash user is not mounted. What, chocolate? And yeah, and then you have udev rules

which want to start a tool in slash user, but it is not yet mounted. What do you do? Well, our objective is key winter rules so we can apply it once bar user is mount. You skip a key of the rules we cannot apply yet because there is stuff that they need

that is not there and then apply them. We will execute them all at once bar user is mount. Actually you can, yes, auto further. Well, actually it will be in order with other rules

that need bar user, but not with rules that need bar only.

So we also have an initrd diagnostic udev that goes back to the user stuff as in you won't need an initrd to mount your bar user if it's separated and stuff like that. Yeah, actually it's not, no, no, actually it's true.

I mean, the problem about needing an initrd, it's not a udev distro, udev problem. But if there is no initrd and there is a strange layout like a separate bar user, we need to try our best in order to fix it.

Yeah, it's a packaging issue, maybe. But it's... Point out, the majority of these are the issues with the general udev packaging. It is not with the source code of this project. Now forking, so you're gonna fix the majority

of these in your e-build. Have a chocolate. So honestly, the separate user issue

really just confuses the point. It just, it's a minor, all right, it's a minor separate thing. There are many reasons why we did this other than the whole separate user reasoning.

So what was the rate? Yeah, yeah, yeah. So what was the major reason for the forking? It's in other slides. Actually, probably the best reason we have for the fork, it's learning. But you never have to do that.

No, no, no, I said learning, not leonard. My English is quite crappy, sorry about that. So what we are trying to do, it's learn more about udev and udev in particular.

I mean, we have learned a lot just by forking the stuff, doing crazy commits, removing the stuff that we shouldn't have removed. Because where it's removing pieces, you see, oh, it's not working because of that. So the issue that I have with udev

is really not that you guys fork, you can do whatever you want. I was kinda, that you point out these things as if systemd wouldn't support that, but systemd, like systemd slash udev supports separate users, like totally fine. It supports init or the agnostic stuff just fine and all this kind of stuff. Like it's like that slide doesn't make much sense.

It's like, I don't know, it's full of fad about systemd upstream. I don't read the non udevs objectives. I'm reading the, yeah, let's see it and just discuss.

Those are the short time objectives for us. Probably they are shared about, it's working?

Okay. So those are our short term objectives. It's not why we did the fork. So that's more or less, okay, we are trying our best to get to this point. If it's a problem of packaging, it's a problem of having the default configured,

biting you or not, depending on what you want, further later. Well, those are our objectives. If your question is why the hell you did fork that, it's more or less that. Okay, we can, yes, we do, yes. We want to learn that. We want to figure out exactly what the hell is

about udev that is so strange or so esoteric. So just three people here knows that. Good, we try and that's it. The problem is that too many people got this kind of strange expectation that we will defeat the evil overlord right here.

No, we are just learning. And this is just a pet project that some people decide that was huge, important, and whatever, it's just our pet project. We are doing our best to achieve some objectives.

Well, the first point is learning. So we do learn. We will probably break some system if somebody is so foolish to use it, but I mean, if somebody decide to use whatever software that is not exactly ready for the prime time,

they are just looking for it. So we are not, as I said from start, and hate fork or we have some kind of interesting idea about conquering the world, at least not yet. We are just experimenting stuff.

The E for UDAV could be experimental. And we are trying our best. We are trying to be as coordinate and as, well, regular about what we are doing. We try to use the best practice to not make a mess.

Obviously, the code itself is complex. So we happen to tear it off just because we want something simple to see and then maybe put back together once we understand exactly what the code is doing or not doing. Pretty much that is.

So those are our short-term goals. Maybe some is just a matter of packaging. Some others are, well, a bit more encompassing since supporting exotic system or not standard system is usually fun. You still learn about it.

That's it. So those are our short-term goals. And one is to keep everything as simple as possible. Quite stupid, we know. If somebody wants to use it, maybe a risk to break or maybe they are fine with it because, let's say, it's simpler.

That's it. Try it, contribute it, learn with us. That's it. Next slide. Yep. Okay. That's probably the other question about, okay, so.

I'll go ahead and take this slide. So one of the things that people we found worried about when we forked UDAV to UDAV was that we would diverge from UDAV and make incompatible changes and make it so that all the stuff that supports UDAV,

we would split, that we would just make it incompatible. But we are aiming to keep ABI compatibility with UDAV as much as possible, as long as it does not interfere with some of our longer-term goals.

And yeah, that's simple. The, when we initially forked UDAV, we did a code refactor because the combined code base between systemd and UDAV was something that we did not,

we don't, we did not like it being combined as it was. We wanted it to be simpler, smaller, more agile. Funny. So we've remade the build system. We found that the build system for systemd UDAV

was not very, well, it's not necessarily that it was fast. It was, I believe one of the initial complaints was that we had to build systemd in order to build UDAV.

You have a shared code, you can decide if the shared code is systemd or shared code. But since the namespace is systemd, well, I would call it systemd. So yes, you need to build systemd, at least part of it, at least logging stuff, at least whatever

that is in the shared directory. We replaced some part. The question was, do we build the stuff in the shared directory of systemd UDAV? I believe what happened is we just refactored the code

and it's not a shared directory anymore since it's just UDAV. We stripped, no, no, no, no, we didn't rename the direct, well, we have a slide on that. Yes, yeah, we're building the same code, well.

You turned the single makefile and top directory into a recursive build system,

which basically means every single directory now needs to be built in one step and then you build the next one rather than everything in parallel. This was just the, oh.

I have another chocolate. So this was just the, so I'm trying to get through all the slides and hopefully most of the slides will answer some of the questions.

Well, actually, if you have many questions on the build system, you probably should ask Blueness. Because he is the one that did most of the work in that aspect. So my recommendation is that you use pink Blueness or FairNote and he will be able to ask what any questions you have. Probably better than all of us together, okay?

So part of the reason that we forked UDAV is to support legacy systems. And we can do that with just be a configure flag. It's just more make stuff. Legacy? The old style of UDAV rules.

So one of the things that we're working on is to monitor mounts so that when rules depend on stuff

that are within those mounts, we retrigger and I guess reinitialize the UDAV rules or whatever. Or whatever. So, init system.

But we don't want to force system D to be unpackaged.

We want to support things like OpenRC, Upstart, other init systems. So we pulled, we're pulling a couple of features out of system D that are useful.

They're good, I'm sure we'll need it.

As I said some time ago in his blog, we also want to cover some myths that have been spread around UDAV. We'd like to note that when UDAV started,

we didn't got any requests for an interview from the media. Actually, we only got one, but we didn't have enough time to ask for it back then because we were on a really short deadline with the UN2 Council. So, there is a lot of food and myths that have been spread out both about UDAV and about UDAV.

And that at least for our site, we'd like to clear out the ones involving UDAV. And if we have time, we'd like if a learner takes the stand and tries to clear the ones involving UDAV that we might have spread. Yeah, really do it, don't be afraid.

So, when my eyes are on the eye, it's that we are hate-based work. I think quite obvious, my note that not. That's, we have nothing in particular against systemd or UDAV. We have nothing in particular

against Lenard, Kees, Craig. Indeed, we have, and because this is not working well.

Better? Better, yeah, cool. Thank you. So, indeed, we try to use to cover some necessities

that we had back then. They were not all related to UDAV itself. Some of them were related to how we packaged it. But for example, we want to let our users be able to use the last test videos in UDAV whilst using whole kernels. Okay, old, let's define old.

For example, something like 2.6.32, which is already, yeah, actually it's 31, but the 32, if I recall correctly, is the last maintainer kernel that we have in our trees. So, we'd like people to be able to use most of the UDAV stuff with all kernels if they can.

Well, that's slightly a lie. It shouldn't be a state like that. About UDAV doesn't support certain physical layouts. Actually, it's our old way of packaging UDAV doesn't support certain system layouts.

Yeah, there is users with less deployments depending on that one. And we want them to be able to use new versions. There is also that UDAV remove once default rules. This covers mostly the legacy stuff that we said. I mean, things like, for example,

the old naming or network interfaces and other similar stuff that we'd like at least to have around for some time. It might not work well, but we are trying our best there. And then there is the fact that UDAV is matched on systemd. And, well, there is no long-term support

for standalone UDAV. We read that comment on Leonard saying back then, I'm not sure if you will stand by it now, saying in the future, everything should be systemd and nothing else, and UDAV won't be a separate project. That was one of the reasons

why we started the fork back then. And, well, we have a lot of users that are happy with OpenRC indeed. So we'd like them to be able to keep using UDAV even if they are using OpenRC. Then there is the copyright fiasco.

I think it's the chance, please throw me a stone. It was me, it was my fault. This stuff was basically a really big misunderstanding, how about Laos and stuff like that. Since we were forking UDAV, I planned on preparing some copyright here that's for files.

So they instead depended on the M2 Foundation because as M2 developers, our work was there. And when I had done it, after two or three hours, we didn't have the freaking C and H file in order to check the copyright here, which by the way, you could standardize, it could help a lot

because there were different formats depending on its file. So, well, I finally got the commit, a really big commit. I pushed it to my personal branch. And since I was tired as hell, I went to sleep. There was people monitoring our tree as if we were going to break her laws.

There was people monitoring my branch, which only had that commit. And yes, also we never merged that into Trung and it never got into main UDAV and it never got outside of that rank. We got a lot of maybe a bombing

and a lot of complaints on that topic. So please accept my apologies on that aspect for doing stupid things on public branches. And I'm sorry for that. Then we have the code removal.

Yes, UDAV started as a learning project and everybody knows that the best way to know who a computer work is removing pieces until you see it won't work anymore. So we try to do a similar thing. We started removing pieces of UDAV. We have only 10 minutes, thank you. We started removing pieces of UDAV

until we had something that was as close to the core of UDAV as we could. We tried to remove that pieces as we could in order to learn how they work. And well, actually we want to put back everything that we remove it or most of the stuff that we remove it slowly

as we have learned how it works. Please take into account that UDAV is a project with a really long history. It has a freakingly lot of features and we are news here. I mean, it's hard for us to learn everything on a single go. So we want to go step by step.

And yeah, another complaint is that the developers are inexperienced. Yeah, we are. We frequently are. I mean, that's not a myth. We are inexperienced when it comes to that. We have never talked to UDAV before. Yeah, but there is a few things. We have contributed to other projects.

We already have some experience developing other stuff. And we are careful in what we commit. We try to prevent stupid stuff like the one we did when we began. And we learn, really. I mean, there is a lot of bad habits that we had when we started that are not there anymore.

Like for example, committing with a survey viewing. And yes, we are open to discussion. I mean, our way is probably not the best one. Our way is probably not the only one. But we will try to defend it. But we will respect the fact that there are other ways of doing the task. After all, this is how we solve our work. You don't like something, you force it.

You try to get as fast as you can. Worst case, everything gets merged. Sorry. Worst case, everything gets merged back into the original at the rank. Or if nothing gets merged yet, well, the project is death and nothing has happened and nobody cares.

Or vice versa, the other project takes over. The old one tries to merge with the original one. And we are happy and we try to be together. That's not a problem. And well, that's a myth that I really hate. They say that UDP is gentle. No, I mean, come on. For starters, we still keep recommending using UDP

instead of UDP gentle. In order to make a big change, like removing UDP from gentle, we would need the support of the console and that's not going to happen. UDP indeed is to gentle the same as it, UDP is to gentle the same as it is to GitHub.

We just use the infrastructure. Yeah, we are developers, so what? I mean, that's like saying that everything Lenar says, it's saved by systemd. No, he has a person, he has personal opinions that might not be the same of the project. And in general, well, yes, we are a N2 project which means that we use N2 infrastructure.

We are N2 developers, but we are not N2. So, yeah, oh, I really like that one. We are the definitive solution to bar user on a separate partition. Yeah, no, we aren't. I mean, there are things that might still be broken.

There is stuff that happens. But what we are going to try is to make it as little problematic for the users as we can from our side. It might work well, it might work bad, we'll see. By your face, you are saying it's not at all? Well, in some cases,

we are going to try our best in that aspect. Yeah, but you are promising things you cannot. I'm not promising it. I'm saying we are going to try it. You make the impression to promise that. No, I'm not promising that we are going to fix it. Please note it down. I don't, we don't promise at all. We are going to fix all the cases of bar user

or even most of them. And I can promise that we are going to try. And we'll see. Hopefully we do it. In the worst case, well, we get a wall and we stamp ourselves. But, yeah. So I think that covers everything. Is there any more questions or anything you want to ask us?

It is, ah, yes. Well, I don't quite have questions, but I would have something to add. This project, the EUDEV, was made, I believe so, that was made for every distro

to not listen to Leonard's code. Am I right? No. Okay. Listen, I mean, by listen to use it. So everybody thinks Leonard's code is awful.

Everybody thinks that. Yeah, don't worry. It's just, it's just a thing. So, or at least, at least some of them. Well, the thing is, the thing is,

there are many, Can I just say one thing? Yes. You want to see awful code, go to my work page. You have a code from when I was on the first course of the career. Then you will see awful code, okay? Okay, okay, perfect. The idea is, there are some developers out there in all other distros that are still interested

in the old standards of EUDEV. And I'm sure of it. Some of them usually come in Ghent EUDEV to ask, well, I need our AUR package from Arch for EUDEV. I need the DEB package.

I need the RPM package. Well, the question is, why not having an alternative to systemd? That's my question. We are totally passing. Of course, you are. There is a lot of things that are not system and that are still in existence over there.

Okay, system is not an init system. It's two smaller stuff. But we use different packages to do everything that system needs to do. The idea is to have a valid EUDEV system. I mean, to have a working EUDEV system.

And to be honest, yeah, love that. To be honest, as far as I've seen, the USR was not quite well integrated in EUDEV. Am I right? I mean, EUDEV, no, sorry. The user feature, slash user feature

is not currently working in EUDEV. Am I right? Japan is still being developed. It works. Okay, okay, it works.

Who is doing all the main code of the project? Well, wait a moment. First, these slashes are stuff. It's just a small little feature that requires more packaging coordination than just changing some little code here and there.

And as I say, it's not just saying, okay, from tomorrow we will support it because you have a number of issue and a number of non-issue. The non-issue is you are having that, you have a server that is completely static. Okay, you can even do without EUDEV from scratch.

Some people need some bit of EUDEV for whatever reason. Then you have to make sure that that bit doesn't require slash user. And it is as simple as that. How to do that, you have a number of way, but it's not exactly depending on just this bit.

It's something that is more all encompassing. It's okay, I've understood. Lots of people are still pestering us about it. So okay, we will have a look about it because there are people that are interested. You know, open source. You have an itch, you scratch it.

So we got people that are quite focused on that because they have large deploy that they use whichever strange architecture. So they will try to contribute to this project. You want to contribute to this project, we are quite happy to have you join. Are you interested in cooperation with other distros? Obviously, yes.

One of the myth is that this project is a Gen 2 project, meaning that just Gen 2 does stuff. No, it is a Gen 2 project just because. So it's mainly for other distros to also cooperate on EU dev. If they're interested in making the alternative,

with using alternative of EU dev, right? Yes, actually we do have books involving art Linux that we are trying to resolve. And for example, well, I see that there is a person with a Ubuntu research over there. If you also want to have EU dev and you have problems, you are welcome to open box. We are going to try our best on fixing them. And if you want to join the project,

you can also do that. One last question. One last word. If you are trying to seek cooperation with other distros, how will you represent it? I believe that's how do you report bugs? Okay.

So we, so although we're a Gen 2 project, we work with the source code and most of the bug tracking is taking place in GitHub. You just opened a bug in GitHub. You don't what? Oh, so initially when we first worked the project, we tried to focus on just getting the code base sane

and working. So we focus mainly on Gen 2 since we're mostly Gen 2 developers. We are, as we grow and as we get everything more stable, we hope to work with other distributions to have EU dev working with them as well.

Okay, new question. You said you're hoping for people to contribute to your project. And it's like you expect that to be or become a community project and you want to learn from the code base. And you consider forking the right way

to work with an existing community project. Have you actually thought about by, I'm not saying here's a question. Have you actually thought about approaching this by just cloning the existing EU dev, making a branch that has your features on it like a regular distribution branch and then trying to submit those back to the upstream project just by sending merge requests

and that by also you're working together with the existing EU dev maintainers and you actually learn from their experience before you have to make a lot of cock-ups yourself and learn the slow and hard way. So I'll go ahead and respond to this initially at least. So part of the reason that we refactored the code

is to just make it simpler. I don't know how to explain it very well, I'm sorry. But, oh, yes, there are a few patches. For instance, one of the reasons that we forked

is because some of the except for stuff was not accepted upstream. You know the except for stuff. For the except for stuff, maybe it's neither to just fix the lipsy in question

rather than walking around in 10 projects, which you said, or 20. I mean, it's just a question. Maybe you should fix the problem because there are other uses just to fix it. One project where the bug actually is, it's usually. What do you mean exactly?

I mean, you guys are referring to the except for thing that was a fuck-up on some architectures in lipsy where basically the lip wasn't in sync with what the kernel exported. So, well, there are other reasons. I mean, it's open source, you can fix it everywhere. Sure. Not only us. But, yeah, if you have the problem

of integrating the whole thing, sometimes you have people that are stuck with something that is not that optimal. So you have to be, well, realistic and, yes. Obviously, you would like to fix the problem where it is, but workarounds are what make stuff working.

Well, define optimal. Sometimes. Like, sometimes that's real world. So. I was just saying, is that what a distribution branch is for?

I mean, every distribution out there has patches to upstream packages. And that's a very common way of working where distribution differences are handled in those circumstances. And if there is a problem with a package, why don't you patch it in your lipsy in the right place in the distribution or whatever? Or if you need a workaround and you need to put it

into UDA for your users, then just put it there. It's not a crazy situation, really. Actually, we like to think of UDEP as a patchless version of UDEP. I mean, yeah, we have changed the codebars, the codebase, and now it's almost impossible

to track stuff from UDEP to UDEP and vice versa. But we weren't thinking of it as our own version of UDEP with the patches we wanted to see there. So it's not that different from what you said, actually. Well, it kind of is in a way, because by approaching the project in that way,

you're almost consciously and deliberately creating some kind of division rather than working how distributions have always worked for many years, which is to carry these patches, push upstream the ones that they can and carry the ones that they can't in their downstream packages. But by announcing it as a public project

and taking it down that route rather than going down the more traditional route, it's almost creating division by its very nature. Well, actually, we don't think that forking creates division. I mean, forking will only create division if there is no communication between the sites

that have forked at the original project. We are actually trying our best to remove that division from our project. And we are trying our best to communicate between us and the people on UDEP. And that's indeed one of the reasons why I personally sent an invite to these guys over here to come, because we want to show them that we don't hate them,

that we want to communicate with them. Did you just say that through the refactoring that you did, it's almost impossible to port something from one project to the other? I mean, communication not only happens with words, but also with code, and if your main achievement

is like making it incompatible. I mean, I don't see that much changes. The biggest change is that it has gotten more or less incompatible with the initial upstream. One thing is that our project, it's not directly compatible with UDEP, as in the sense of we have made more refactoring.

You cannot port a patch directly from one site to the other. Another different idea is that the ideas we apply or the systems we apply cannot be used on UDEP because the basis is still the same. And probably just by changing some paths and using slightly different functions, you can get it done on UDEP.

Yeah, but I think you should be very careful about, if you think of the future of your project, you should try to not add more division for very little reason. Let's put it this way. Well, actually we are trying our best not to increase that divide we have already created.

I think that despite our project being, how much, three months old, something like that? Yeah, three months. Three months old. It started as some sort of a revolution thing. And anybody that knows a little bit of politics knows that revolutions suck, are probably the best we think in the world,

the worst thing in the world. Because basically after a revolution, you just try to get things fixed fast, badly and patch stuff that you shouldn't patch. And in that you end up with things that are hard to maintain or things that are bad. But our aim is that at least

when we get to a stable branch, we have as little change from UDEP as possible. Sorry, from UDEP as possible. Okay, hi, my name is Michael. I'm working for the Debian project. First some observation. I mean, the name UDEP probably wasn't the best choice of word or name for your project.

Half of the time, if you're talking about your project or the original project, just an observation. So. Well, that's fine. One is systemd, the other is UDEP. Yeah, but just saying, I mean, it wasn't exactly clear when you were talking about what.

So, specifically the topic about slash user or separate slash user. I mean, I'm coming from Debian. There's also sorts of talk about how we have to support that. And I know the difficulties that it entails. And I mean, you also talked about KISS. And I think if you look about the idea

to just use the initrd to mount slash user and you solve all those problems for free, that it's just so compelling. Or, I mean, the easiest way obviously is to not use a separate slash user. But if you just take those two sets and see which users are there which don't want to have an initrd

or which don't want to have a slash user. I mean, there aren't that many. And having to complicate things that much for such some, I don't know. I mean, maybe you have a magic idea how you solve this in your UDEP rules. I mean, how exactly do you wanna do that? Do you take the binary, look if that's in slash user and then defer the rules?

Or, I mean, how do you know if a binary, which even is in slash bin, but needs resources from other parts of the system in slash user? How is this supposed to work? I can't imagine what your plans are. A couple of questions there. One of the, I think the battery's dying.

One of the reasons that we forked is to support. So out of 100% of the systems out there, we wanna support as many of them as possible. Just for instance, pulling a number out of a hat.

System.dudev supports 95%, just a number. We aim to support 98%. We're just trying to get those few users. We're trying to support them as best as we can. Some users are not able to use initrds. How about embedded systems a lot of the time?

Do you really think embedded systems have a complicated layout with separate slash user, for example? I don't think so. For example. I mean, that's what I'm talking about. The set of user. No, but for example, we have a lot of users that have servers with really constrained and separated bar boot partitions. Those people who have a really hard time

getting an init ID that could take 10, 20 megabytes that they cannot use in the system. I mean, I have a friend there in Valencia, for example, that is still using a painting tool.

So what? Okay, but there is that. So what? That's the main point. It's not so what. We got somebody that has this itch and wants to scratch. As simple as that. It's not a matter of, oh God,

you're wasting time or whatever. It's just somebody that has this problem, wants a solution. I don't know. If the guy wants to work on that, so be it.

There is one. Well, think of it in this way. How many people has the problem? Let's say one. And you push the next version that makes a lot of trouble for that one user. You think that one user is going to say good things about you? You said you are having problems with food.

You said you are having problems with food. Why do you think they happen? I mean, if by pushing something you are doing, a user has a bad user experience, he is not only going to try not to use your project, he's also going to say the worst things in the world on your project.

And if somebody says something bad to him, even if it's not true, he's going to be a big amplifier saying that. So if the effort it takes to make that user not angry, it's not that much. Let's do it. Why not? Let's make another item like kernel 2.6.32.

Yes, there are many systems that are using that and are stuck with that. Shall we support them or not? The answer is yes. But if we can, why not?

So one simple question. One is for the systemd developers and the other one is for the udev developers. So the question is the same. And why did you decide to drop support for older kernels and why did you decide to put the support

for older kernels back in? Thank you. Who wants to go first? So we decided, I have a chocolate. We decided to support the older kernels because I have a friend that needs support

for the older kernels. That's part of the reason. Then we'll have these users with OpenV set that can only use the 2.6.32. When you upgrade a system, you upgrade everything. You cannot always keep backward compatibility for everything.

As someone who changes the kernel all the time, we break old user space in ways that you don't know because you upgraded other packages. You can't do it. Your maintainability of things over time, it's good to drop things and put them away.

They wanted to. Well, there is, for example, a reason why you would want to upgrade udev. Let's go a few years back.

There was this nice trace condition issue in udev that could be exploited in order to get root access by some strange teaming stuff. I'm not sure if it was udev or refchrome, but it was one of those two packages that had this issue.

Then you have an old kernel, which you cannot upgrade because they have stopped giving support or whatever, and you have that version of udev. Would you like to be able to? Okay.

We have to leave. We will discuss probably outside. The short version for that. Okay, people want some software that use the new libudev that requires the new udev, and they are struck with that kernel, and the system is like a set of box, multimedia stuff,

and you really want the new version of the software. So what you do? You try to repo up and fix all the users of libudev so everything is sort of okay, and then you do again for the other stuff, or you ripple down, and if you can't touch the kernel,

you try to touch the stuff that is the closest in the chain that you actually would like to upgrade. So kernel is banned. udev, maybe not, because it's quite simple. I'd like to say one last thing. It's an Android phone with cyanogen mode 11.

It's the 4.2.1 version, and it uses a 2.6.39 kernel, because the developers of the phone don't want to update it. No, it doesn't have udev in there,

but the point I'm trying to say is that there are users that still need all their kernels because maybe the manufacturer is stupid enough not to support them. The one thing, like the original question is why we don't support that. It's like, it's not that we only support.

the most recent we support like a couple of them like like one years or so but the thing is we try simple clean code that that is reliable and we always want to fix the the problems where they are so in order to keep simples

no you know you have to keep always the compatibility forever it's like it makes you code you need to deal with if devs you need to deal with all these bugs and this thing is also it's about the question about the test metrics basically like if you want to support all the possible combinations of software in any version ever then you explode your test metrics and you actually need to to to make sure that it all works together

and that's the thing we can't really do I don't know it's it's a question of keeping a code simple or not like like we tend to not want to have that many if devs for example in our stuff and we're pretty good at that and then for example for the except for stuff that they were raising is yeah we don't we think that the except for stuff is something you much better fix in

lipsy once and it works for every tool then fix it in every tool like work around in every tool and have the if there's and have the configure checks and have the implementation except for it's just the way to work and now you can say of course yeah I don't know it's it's basically we like our code simple and maintainable and clean and that you

can read it and that there's no if stuff there's no side effects that you can't see there's no non obvious stuff that we can't test I want to be sure that when I compile system d that that I actually I'll test that is in the system d tree but I can't do that if they're if devs and tons of

optional code that is used on some systems but not on mine so it's it's a question about about I don't know with system we are relatively fast in developing things and the way we do this is by making sure that that we can test the stuff as we go and and be reliable in that if you have all this abstraction code like it's the same questions about portability to other

operating systems if you have all the abstraction code in there then you always need to make sure that it also works on the other operating system everything so it's a question about yeah