Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
The eudev project launches
Posted Dec 17, 2012 17:11 UTC (Mon) by koenkooi (subscriber, #71861)
You can't claim rejection if you haven't sent anything.
Posted Dec 18, 2012 19:59 UTC (Tue) by prometheanfire (subscriber, #65683)
Posted Dec 18, 2012 20:48 UTC (Tue) by rleigh (subscriber, #14622)
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.
Posted Dec 18, 2012 21:48 UTC (Tue) by HelloWorld (guest, #56129)
> 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.
Posted Dec 18, 2012 22:09 UTC (Tue) by rleigh (subscriber, #14622)
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
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
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
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
Posted Dec 18, 2012 23:06 UTC (Tue) by HelloWorld (guest, #56129)
Posted Dec 18, 2012 23:48 UTC (Tue) by hummassa (subscriber, #307)
Posted Dec 19, 2012 14:16 UTC (Wed) by mezcalero (subscriber, #45103)
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:
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.
Posted Dec 19, 2012 16:31 UTC (Wed) by GhePeU (subscriber, #56133)
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.
Posted Dec 19, 2012 16:58 UTC (Wed) by raven667 (subscriber, #5198)
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.
Posted Dec 19, 2012 17:22 UTC (Wed) by HelloWorld (guest, #56129)
Posted Dec 19, 2012 17:33 UTC (Wed) by hummassa (subscriber, #307)
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.
Posted Dec 19, 2012 18:42 UTC (Wed) by HelloWorld (guest, #56129)
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.
Posted Dec 19, 2012 19:30 UTC (Wed) by hummassa (subscriber, #307)
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).
Posted Dec 19, 2012 19:31 UTC (Wed) by hummassa (subscriber, #307)
No, but the fact that he personally feels like he has to respond seems like a hint.
Posted Dec 22, 2012 12:42 UTC (Sat) by ovitters (subscriber, #27950)
Posted Dec 23, 2012 3:16 UTC (Sun) by hummassa (subscriber, #307)
Posted Dec 19, 2012 20:23 UTC (Wed) by mezcalero (subscriber, #45103)
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...
Posted Dec 20, 2012 0:09 UTC (Thu) by nix (subscriber, #2304)
And you know if you then try to accommodate of making all these things optional and selectable specifically at configure time
Posted Dec 20, 2012 0:29 UTC (Thu) by hummassa (subscriber, #307)
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.
Posted Dec 20, 2012 4:14 UTC (Thu) by nevets (subscriber, #11875)
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.
Posted Dec 21, 2012 7:35 UTC (Fri) by felipec (guest, #75494)
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.
Posted Dec 19, 2012 18:35 UTC (Wed) by man_ls (subscriber, #15091)
Posted Dec 18, 2012 22:04 UTC (Tue) by raven667 (subscriber, #5198)
Posted Dec 18, 2012 22:42 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Dec 19, 2012 16:29 UTC (Wed) by raven667 (subscriber, #5198)
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?
Posted Dec 19, 2012 16:32 UTC (Wed) by prometheanfire (subscriber, #65683)
Posted Dec 19, 2012 17:01 UTC (Wed) by nix (subscriber, #2304)
Posted Dec 20, 2012 16:40 UTC (Thu) by mbiebl (subscriber, #41876)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds