The eudev project launches

Posted Dec 17, 2012 16:41 UTC (Mon) by rahulsundaram (subscriber, #21946)
In reply to: The eudev project launches by prometheanfire
Parent article: The eudev project launches

what contributions were rejected?

The eudev project launches

Posted Dec 18, 2012 19:59 UTC (Tue) by prometheanfire (subscriber, #65683) [Link] (27 responses)

I haven't kept a full list, but here is one thing.

http://www.mail-archive.com/systemd-devel@lists.freedeskt...

The eudev project launches

Posted Dec 18, 2012 20:48 UTC (Tue) by rleigh (guest, #14622) [Link] (22 responses)

The bad attitude on the part of the systemd developers here is quite incredible... but was entirely predictable even before udev was merged into systemd. It was clear that udev standalone would be a poorly-supported stepchild, and deliberately rejecting patches which permit users to just build udev alone beggars belief! This lack of accommodation for entirely legitimate use cases is harmful, and will drive a wedge through the Linux ecosystem. Forcefully ramming systemd down our throats at each and every opportunity is not winning you any friends from over on this side of the fence... not cool.

It's things like this that will actively spur the creation of forks like eudev. And while I think in general forking is bad, when treated to such assholery, is there really an alternative? Just sad all around.

The eudev project launches

Posted Dec 18, 2012 21:48 UTC (Tue) by HelloWorld (guest, #56129) [Link] (19 responses)

> It was clear that udev standalone would be a poorly-supported stepchild,
udev works perfectly fine without systemd, so stop spreading this kind of FUD.

> and deliberately rejecting patches which permit users to just build udev alone beggars belief!
The patch increases complexity in the build system and the benefit is totally negligible: it doesn't make *any* difference whatsoever at run time and only requires a few more packages to be installed at build time, which is a tiny inconvenience for a tiny group of people.

So, in your world, rejecting that kind of patch justifies calling other people assholes and accusing them of ramming things down your throat? You're right, this is
> Just sad all around.

The eudev project launches

Posted Dec 18, 2012 22:09 UTC (Tue) by rleigh (guest, #14622) [Link] (18 responses)

>> It was clear that udev standalone would be a poorly-supported stepchild,
>udev works perfectly fine without systemd, so stop spreading this kind of FUD.

It's not FUD when it's true. It's possible to /run/ but not /build/
udev alone without taking additional efforts to do so, you must build
systemd unless you patch it out or make it configurable (which this is
doing). Which is the whole crux of the discussion which you are
not-so-helpfully ignoring.

The fundamental point here is that the current state is not satisfying
a certainly number of users (and distributors). They wouldn't have
gone to the effort in making, testing and submitting a patch if they
didn't consider it important enough to do so. To not recognise that
this work was done to satisfy a legitimate need is explicitly
alienating these people when it would make a whole lot more sense to
accommodate them in this respect. It costs almost nothing to help
others and generates a whole lot of goodwill in the process, rather
than being all take and no give.

>> and deliberately rejecting patches which permit users to just build
>> udev alone beggars belief!

> The patch increases complexity in the build system and the benefit
> is totally negligible: it doesn't make *any* difference whatsoever
> at run time and only requires a few more packages to be installed at
> build time, which is a tiny inconvenience for a tiny group of
> people.

This group is likely greater overall, in terms of numbers building the
software, than for the binary-only distributions if you include
source-only distributions, embedded developers, etc. In terms of end
user counts, you are correct. But that does not mean the other use
cases are any less important or necessary, even if it's not of direct
interest to the core developers.

It's not like the complexity of configure switches and conditional
compilation is at all high. And this doesn't even factor in that it
should have been doing this from the start.

> So, in your world, rejecting that kind of patch justifies calling
> other people assholes and accusing them of ramming things down your
> throat?

It only appears to occur repeatedly in the case of systemd, and pretty
much only because its maintainers' bad attitude has not improved with
time. But yes, in this case I do think it's justified. In adopting
udev, they do have an obligation to keep this type of build working
since it /worked before/, and there are clearly users who /want/ and
/need/ such functionality. To not do so, and to do so deliberately
and intentionally, is greatly disrespectful and will cause unnecessary
fragmentation.

Roger

The eudev project launches

Posted Dec 18, 2012 23:06 UTC (Tue) by HelloWorld (guest, #56129) [Link] (1 responses)

> But yes, in this case I do think it's justified.
Well, you're wrong, and I certainly won't waste any more time with someone with such bad manners.

The eudev project launches

Posted Dec 18, 2012 23:48 UTC (Tue) by hummassa (guest, #307) [Link]

This discussion has been funny to watch because both sides are guilty of this same attitude: "I think something, and I don't have time to properly discuss it, so I will throw some arguments -- valid or not -- and I will call it quits."

The eudev project launches

Posted Dec 19, 2012 14:16 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (15 responses)

Roger,

thank you for calling us assholes.

From time to time we do refuse patches. But when we do we attempt to give very precise explanations why we do that.

I know you are disappointed that we refused the patch that allowed building arbitrary subsets of systemd, and that we refused adopting this Debianism of moving /dev/shm to /run/shm (which I still think is a bad and unnecessary idea). These two items where high up on your personal wishlist. As such I can understand you are disappointed. However, there's no reason to constantly complain about our horrible attitude just because we refused two of your favourite patches.

One cannot always get what one wants. We don't always get that, and you don't get that. We do not fulfil all wishes from the community, but try hard to cover many. Please learn to accept that.

In our attempt to explain in detail what we suggest people to do, instead of merging the proposed split-up patch, we even put together a wiki page that explains how to build arbitrary subsets of systemd:

http://www.freedesktop.org/wiki/Software/systemd/MinimalB...

And that's what I mean with trying hard to explain why we do what we do. It's our attempt to accommodate for these specific requests. I am sorry if this is not 100% what you are asking for, but it would be cool if you could at least acknowledge that we tried to provide something similarly useful.

Following these guidelines you can build any subset you want. You can just build tmpfiles, or just detect-virt, or just udevd, or udevd with its helpers, or only the helpers, or only some helpers, it's entirely up to you.

Constantly calling us assholes and complaining about our attitude on debian-devel, on LWN and everywhere else just because we didn't give you *all* you wanted, but only *some* things, only makes you appear bitter, but will not help us respect you, will not convince us, or even make use the tiniest bit more receptive to your ideas. Right the opposite. Calling us assholes might just get you added to our list of crazy people we ignore by default.

Lennart

The eudev project launches

Posted Dec 19, 2012 16:31 UTC (Wed) by GhePeU (subscriber, #56133) [Link] (13 responses)

That wiki page is ridiculous. People tell you that they want to build only udev because they don't need the rest and they'd like to avoid installing all systemd dependencies just to get a system component that's not dependent on systemd at all and your answer is:

a) restating the problem as a solution
b) suggesting that they create arbitrary empty files who could change at any time if the dependencies list change and then mess with the environment, not exactly the easier thing to do for a build system (and it doesn't even work always!)

And finally you end by saying that you're open to all patches but the patch that would solve the problem. Remove that page, there's no need to mock people.

The eudev project launches

Posted Dec 19, 2012 16:58 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> Remove that page, there's no need to mock people.

Seems like a fairly reasonable solution given the desire to keep the build system simple and not break the config for the core components. No one is being mocked or being sarcastic although a few people are acting very butt-hurt, spreading a lot of negativity with very little basis in reality as far as I can tell.

The eudev project launches

Posted Dec 19, 2012 17:22 UTC (Wed) by HelloWorld (guest, #56129) [Link] (11 responses)

> b) suggesting that they create arbitrary empty files who could change at any time if the dependencies list change and then mess with the environment, not exactly the easier thing to do for a build system (and it doesn't even work always!)
That is an appropriate kind of solution for a problem that is a) a minor nuisance more than anything else and b) affects only a tiny group of people. Some people choose to make their own lives hard by using a source-based distro, and they should live with the consequences. If you can't stand the heat, get out of the kitchen.

The eudev project launches

Posted Dec 19, 2012 17:33 UTC (Wed) by hummassa (guest, #307) [Link] (10 responses)

> affects only a tiny group of people

Nonsense, poppycock!

If "patch to build only udev" was something that "affects only a tiny group of people", you and Leonard wouldn't be here in LWN tying to defend the undefensable. If it was true, eudev would be something of use only for that "tiny group of people".

Regardless of any incorrectness or even downright falsehoods that may or may not be contained on eudev's announcement, the complexity of making and maintaining a ./configure flag "--udev-only" is irrisory. And still, Poettering came here and put up a wiki page (taking more time than he will ever take to make and maintain such flag) TO DEFEND THAT HE WILL NEVER ACCEPT SUCH PATCHES. Oh, come on!

As I said before, both sides are arguing like five-years-olds. Fingers in their ears, la-la-la-la-la. Pathetic.

The eudev project launches

Posted Dec 19, 2012 18:42 UTC (Wed) by HelloWorld (guest, #56129) [Link] (4 responses)

If "patch to build only udev" was something that "affects only a tiny group of people", you and Leonard wouldn't be here in LWN tying to defend the undefensable.

Let me get this straight: the fact that a handful of people on lwn.net flame Poettering is somehow a proof that there's more than a tiny fraction of linux users who care about this?

You can deny it, that won't change the facts: the vast majority of linux users use binary distros. Of those who use source-based distros, at least some use systemd as well, making the issue moot. Of those who use a source-based distro and don't want systemd, most require systemd's dependencies anyway and thus don't have a problem with installing them. Of those who use source-based distros and want neither systemd nor its dependencies, most are probably reasonable people who just get over it, install the dependencies, build udev and remove the dependencies again. So that's a fraction of a fraction of a fraction of a fraction of udev's users for whom this is a problem, and you're actually trying to convince others that that's not what one would call a tiny group?

the complexity of making and maintaining a ./configure flag "--udev-only" is irrisory.

It's easy for you to say that as you don't have to do the work. You should leave that decision to those who do.

The eudev project launches

Posted Dec 19, 2012 19:30 UTC (Wed) by hummassa (guest, #307) [Link]

> It's easy for you to say that as you don't have to do the work. You should leave that decision to those who do.

Let's do exactly THAT: welcome eudev into the community, and all is Ok. Because that is what eudev developers are doing (taking the decision, doing the work).

The eudev project launches

Posted Dec 19, 2012 19:31 UTC (Wed) by hummassa (guest, #307) [Link] (2 responses)

> Let me get this straight: the fact that a handful of people on lwn.net flame Poettering is somehow a proof that there's more than a tiny fraction of linux users who care about this?

No, but the fact that he personally feels like he has to respond seems like a hint.

The eudev project launches

Posted Dec 22, 2012 12:42 UTC (Sat) by ovitters (guest, #27950) [Link] (1 responses)

Your behaviour towards Lennart is really poor. hint: he corrected claims. you just suggest bad intend. Meaning, getting personal, yet again.

The eudev project launches

Posted Dec 23, 2012 3:16 UTC (Sun) by hummassa (guest, #307) [Link]

You should re-read the whole thread.

The eudev project launches

Posted Dec 19, 2012 20:23 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (4 responses)

You know, what you are missing here is that people who go minimalist enough to only want udev from the systemd tree and nothing else, usually don't stop there and want even less than "all of udev" too. i.e. they want some of the helpers and not all, i.e. why would I need the accelerometer helper on my server or the MTD prober on my desktop?

Similar, some folks want only tmpfiles, or only detect-virt or some of the other stuff...

And you know if you then try to accommodate of making all these things optional and selectable specifically at configure time then you necessarily end up with a makefile where every second line is ifdef'ed in by a different configure switch, and even the .c sources are littered with #ifdef HAVE_xxx sections. And that is a) very hard to read and maintain, b) impossible to test in all combinations (explodes the test matrix...), and c) entirely unnecessary, as "make" is already good enough to allow people to build exactly what they need and what they don't want. And yeah, I have no interest in maintaining such a beast, especially since it makes our life harder and gains us nothing.

Anyway, calling us pathetic, and five-year olds also doesn't really make use take you seriously.

Also, to clarify one thing: I don't really care whether somebody forks udev, quite frankly I am quite happy if they do so that they can deal with people like felipec, barbato or rulgard, and I don't have to. What I am annoyed about though is the FUD and falsehoods they spread while doing so. Most specifically their constantly repeated claim that udev upstream wouldn't allow non-initrd with /usr split off, even though we each time point out that udev doesn't care and it's other software that will break, not udev.

But anyway, I'll leave it at this. It's unlikely I'll change you mind on things, and quite frankly you are not really succeeding to change mine either...

Lennart

The eudev project launches

Posted Dec 20, 2012 0:09 UTC (Thu) by nix (subscriber, #2304) [Link]

And you know if you then try to accommodate of making all these things optional and selectable specifically at configure time

You mean like the helpers already were? I suppose that's been taken out now, too.

The eudev project launches

Posted Dec 20, 2012 0:29 UTC (Thu) by hummassa (guest, #307) [Link]

> And you know if you then try to accommodate of making all these things optional and selectable specifically at configure time then you necessarily end up with a makefile where every second line is ifdef'ed in by a different configure switch, and even the .c sources are littered with #ifdef HAVE_xxx sections. And that is a) very hard to read and maintain, b) impossible to test in all combinations (explodes the test matrix...), and c) entirely unnecessary, as "make" is already good enough to allow people to build exactly what they need and what they don't want.

This is a real nice argument; except maybe for the part that you wouldn't be forced to think and make the patch nor maintaining it working (you could shift the responsability that half of the test matrix to the other, more interested, part). Your thing, when a patch like that comes, would be to overlook it, apply it, test *your* side of the test matrix and voilà.

> And yeah, I have no interest in maintaining such a beast, especially since it makes our life harder and gains us nothing.

This is the Most Honest part of your argument. "I am not in the mood, MY code (the code I have to look at from time to time) will get uglier, and it's mine, so I won't do it."

> Anyway, calling us pathetic, and five-year olds also doesn't really make use take you seriously.

Let's be honest here: I called BOTH sides of the discussion pathetic five-year olds; if you can't re-read this whole discussion, take a little distance and see how it is funny, I hate to tell you but you could use some sense of humour. I don't want to be taken seriously -- I want you (and by you, again, I mean both sides of this discussion) to perceive no one is really taking you seriously when you start bickering and sidetracking and trhowing tantrum fits. And this (bickering/sidetracking/tantrums, not being seen as serious) is a BIG loss to the Free Software Community as a whole; so you might want to consider that...

> Also, to clarify one thing: I don't really care whether somebody forks udev, quite frankly I am quite happy if they do so that they can deal with people like felipec, barbato or rulgard, and I don't have to. What I am annoyed about though is the FUD and falsehoods they spread while doing so. Most specifically their constantly repeated claim that udev upstream wouldn't allow non-initrd with /usr split off, even though we each time point out that udev doesn't care and it's other software that will break, not udev.

That is Ugly and Wrong. And that is the pathetic five-year olds part for the other side of the discussion.

Free Software does not need a REASON to be forked: the answer to "we have a team of developers and some infrastructure, we think we could do better maintaining this" is "Good! Be my guest! If it's copyleft, just distribute the source and all is well, maybe you will do a good job and I will use your commits here too!"

> But anyway, I'll leave it at this. It's unlikely I'll change you mind on things, and quite frankly you are not really succeeding to change mine either...

I never intended to change your mind. Even if I don't personally like systemd -- for the reasons I stated elsewhere in this thread, I admire your hard work and I am thankful for it. I just wished (before) that you were more accomodating, but you are not up to it, and there is nothing I can do about it. Now, eudev is a reality, and we all continue to win.

The eudev project launches

Posted Dec 20, 2012 4:14 UTC (Thu) by nevets (subscriber, #11875) [Link] (1 responses)

Maybe you should have a look at the Linux kernel. It's probably the most configurable project that ever existed. The kernel has matured where we don't have lots of #ifdef HAVE_xxx in the .c sources. We do put them into the .h files, where a static inline may act differently depending on the configs set. It's actually quite an elegant solution.

I based my Makefile for trace-cmd and kernelshark partially off of the Linux kbuild system. It's much more versatile and easier to understand than autoconf. I should work on making the kbuild system available for other projects as well. Package it up and reuse it.

Yes, we don't test all the different config options either, but you test what you ship. If someone finds a set of options that break, it's not that difficult (or time consuming) to fix it. I know this from experience as well.

I left off 'c)' because it was entirely an opinion, and not a technical issue at all.

The eudev project launches

Posted Dec 21, 2012 7:35 UTC (Fri) by felipec (guest, #75494) [Link]

Completely true, in fact, there are other projects using Linux's kbuild system; buildroot.

The only way to make a software project work for everyone, is to allow configuration options for everyone. If you don't, for laziness, or whatever reason; forks are bound to happen, as eudev demonstrates.

The eudev project launches

Posted Dec 19, 2012 18:35 UTC (Wed) by man_ls (guest, #15091) [Link]

One cannot always get what one wants. We don't always get that, and you don't get that. We do not fulfil all wishes from the community, but try hard to cover many. Please learn to accept that.

The great thing about Free software is that everyone can get what they want, provided they wish it hard enough... to create and maintain a fork. No need to deny their ponies if they are going to feed them. A fork might even be less work for the main project given that it will accept patches otherwise rejected and avoid a bit of the bitterness.

The eudev project launches

Posted Dec 18, 2012 22:04 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

I don't know why such a simple, clear explanation of why this patch was rejected generates such hyperbole and apoplectic rage on your part. Explaining that splitting the makefiles would be fragile because of the additional complication involved and that while the build products are separable the build process is unified hardly seems like "asshoery". I'm not sure how this is supposed to be "forcefully ramming systemd down our throats" or how that is supposed to work with software? Does your computer get cooties if it builds some systemd binaries that you hold your nose and throw away at the end?

The eudev project launches

Posted Dec 18, 2012 22:42 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

>I'm not sure how this is supposed to be "forcefully ramming systemd down our throats" or how that is supposed to work with software?
It's a bit like kernel developers love to do with submitted patches.

Rejecting a patch because it's 'ugly' is a privilege reserved for kernelspace. All userspace patches must be immediately accepted even if they are butt-ugly in case they solve a kernel maintainer's problem.

The eudev project launches

Posted Dec 19, 2012 16:29 UTC (Wed) by raven667 (subscriber, #5198) [Link] (3 responses)

As a matter of academic interest I wonder what the problematic dependancies are? I just tried building systemd-196 on a couple of systems (CentOS 6.2, Ubuntu 12.04, Fedora 17) and, while I was not actually successful in any case (missing xattr.h from socket.c even though xattr support disabled), the dependancies I had to pull in were gperf, intltool, dbus-devel, libcap-devel, everything else was already on my system. I don't know of these dependancies are in addition to what udev needs, my guess is that gperf probably is, but in a lot of cases these other libraries are going to be on any default install Linux system because they are very widely used.

I'm sure it seems less elegant or offends some sense of "cleanliness" to build and depend on more than you are going to use, but how much of an actual technical problem is that going to be in reality?

The eudev project launches

Posted Dec 19, 2012 16:32 UTC (Wed) by prometheanfire (subscriber, #65683) [Link]

Given the way that package dependencies work in Gentoo it does present a problem. What should be two packages have to be combined because of their mangled build system.

The eudev project launches

Posted Dec 19, 2012 17:01 UTC (Wed) by nix (subscriber, #2304) [Link]

gperf and intltool are only build dependencies anyway, not runtime dependencies (of anything).

The eudev project launches

Posted Dec 20, 2012 16:40 UTC (Thu) by mbiebl (subscriber, #41876) [Link]

The xattr build issue is indeed a bug which has been fixed in [1]
Unfortunately this missed the v196 release.

[1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=cf...