[arch-general] Gentoo udev fork w/o systemd

[Thomas Bächler]

I started replying, and then the post got way too long and I stopped. As
you simply ignored most of what I said, I'll just quote most of this for
reference and not reply to it (it is a funny read, after all). It is
really pointless to keep arguing, because you won't see reason anyway
(and frankly, I won't either).

Look at the bottom for one thing I will actually reply to.

Am 20.11.2012 14:35, schrieb Felipe Contreras:
> On Tue, Nov 20, 2012 at 1:46 PM, Thomas Bächler <thomas at archlinux.org> wrote:
>> Am 20.11.2012 12:00, schrieb Felipe Contreras:
>>> Thomas Bächler wrote:
>>>> Am 20.11.2012 01:07, schrieb Kevin Chadwick:
>>>>> Odd, my take was that the main goal was trying to bring back a
>>>>> separate /usr.
>>>>
>>>> They believe that the problem is that udev refuses to work with /usr not
>>>> mounted. They also believe the problem to be "solved" by just removing
>>>> the test. They do not even remotely understand why separate /usr is
>>>> broken,
>>>
>>> This is not true. It might be broken for *some* setups, but not all.
>>>
>>> Do you want me to point to the mails where Gentoo developers explain how
>>> a separate /usr works perfectly fine in *their* setup?
>>
>> As a Linux distributor, you want to have a setup that works for all of
>> your users.
> 
> Gentoo is not your traditional distributor, read about it.
> 
>> And in fact, I remember receiving many bug reports that library A and
>> binary B needed to be in / instead of /usr. You'd end up patching
>> Makefiles and moving files around, creating new bugs because you missed
>> something. It was a workload that was not worth the gain at all.
> 
> That is up to Gentoo developers to decide, and they will do so in a months time.
> 
>> So you cannot simply consider what is needed for _your_ setup, but what
>> is needed for _all_ setups.
> 
> Yes I can. It is *my* setup.
> 
> If by _you_, you meant Gentoo developers, then read about Gentoo. They
> don't dictate what all their users should do.
> 
>> In addition, some bugs that occur are very subtle, so an ignorant
>> developer may not even notice them, and thus consider them non-existent.
> 
> Yes, all software has those.
> 
>>> This is a hasty generalization fallacy; because a separate /usr is
>>> broken in some cases, doesn't mean it's broken in all cases.
>>
>> If it's broken in any supported setup, it can be considered broken. You
>> need to think globally - thinking about your single computer is
>> ignorant, and you should not be developing a Linux distribution with
>> such thinking.
> 
> If you don't think Gentoo should exist, that's your choice. Gentoo
> does exist however, and what they do is up to them.
> 
>>> Since Gentoo is all about choice, a package like udev should not break
>>> the setups that are already working.
>>
>> That's Gentoo's problem. They refuse to do the right thing and mount
>> /usr before switching from initramfs to real root.
> 
> Not all users use initramfs. What to do is the users' choice.
> 
>>>> and that "fixing" this problem eventually results in installing
>>>> everything to / and leaving /usr mostly empty.
>>>
>>> Wrong. Only the things that are needed at early boot, which are not that
>>> many.
>>
>> And this is where you are wrong. Udev launches programs any time (in
>> particular, on early boot) because certain devices appear. In the
>> future, this will be done for more programs, not less. And every time
>> such a rule is added, you need to move another program from /usr to /,
>> because someone will report it as a bug.
> 
> Really? How many?
> % grep 'IMPORT{program}' -r /usr/lib/udev/rules.d | sed -e
> 's/^.*\({program}=\)"\(\S\+\).*"/\2/' | sort | uniq | wc -l
> 18
> 
> 18 is a lot?
> 
> And no, udev doesn't trigger these programs just because the devices
> appear. It depends on the kind of device. All the udisks rules for
> example are not triggered until the user is logged in. Plus rules have
> conditions they have to meet.
> 
> And ultimately Gentoo has full control over the rules. If upstream
> adds a rule that has a program that doesn't work with separate /usr,
> they can just remove it until it's fixed.
> 
>> Now, you could rewrite udev to ignore those events and execute them
>> later when /usr is mounted. The question you need to ask yourself is
>> this: What is the gain, and what is the cost? The cost: udev becomes
>> much more complex because it needs to store failed events and retry them
>> later, which may lead to many more internal problems. This is a very
>> high cost in terms of maintenance and code over-complication.
> 
> That's for Gentoo developers to decide.
> 
>> What is the gain? You support a separation between / and /usr which
>> serves no technical purpose and is not well-defined. So you do lots of
>> work for nothing - when you just could have made sure everything is
>> mounted and accessible before switching to the real root (which is easy
>> to do, compared to everything I described above).
> 
> Up to Gentoo developers to decide.
> 
>>>> They also "fixed" udev by removing blkid support, although util-linux
>>>> deprecated the "blkid -o udev" option a while ago.
>>>
>>> And you think util-links is the only one that provides blkid?
>>>
>>> What's this that I see in the corner of my eye?
>>>
>>> http://git.busybox.net/busybox/tree/util-linux/blkid.c
>>>
>>> That's right, and alternative implementation of blkid.
>>
>> What you see in the corner of your eye is an implementation of blkid that
>> a) is often behind the util-linux implementation when new file systems
>> appear.
> 
> Irrelevant.
> 
>> b) never supported 'blkid -o udev', which udev relied on before it
>> linked to libblkid.
> 
> Maybe they will. How hard could it be?
> 
>> So, unless eudev reintroduces libblkid support, it will rely on
>> util-linux versions older than 2.23, because that's when the
>> udev-compatible output will be gone.
> 
> It's right there:
> https://github.com/gentoo/eudev/commit/31040610c959a9f12d0df9f28fa3566fc0bc5fe4
> 
> Why are you worrying about potential problems with util-linux versions
> older than 2.23, which is not even released yet on code that is only a
> few days old, hasn't had a single release yet, hasn't even been
> announced, and yet already fixed the problem?
> 
>> This is another indication of how little these guys know about what's
>> going on in the Linux ecosystem.
> 
> Or how little you know about what they are actually doing.
> 
> You are just looking for reasons to complain. What do you gain by that?
> 
>>>> The general consensus seems to be that they have no idea what they are
>>>> doing (see the statements of Greg K-H or Kay Sievers on the topic).
>>>
>>> Oh, I wasn't aware that Greg K-H and Kay Sievers were the holders of The
>>> Truth.
>>
>> They are just two of the people who know what's going on and have dealt
>> with these topics for years. In contrast to the eudev people, they
>> understand the problems and why particular choices were made.
> 
> Kay is the reason why udev is an awful piece of code. Greg hasn't
> touched udev in years.

"Awful piece of code" demands some proof.

> And if you put so much emphasis on what these guys say, what about this guy?

Yes, the eudev people keep bringing this up.

In fact, this post is about a bug that they did not even mention in
their posts, that has since been fixed (with an extra 2 lines), and that
they didn't do anything about. But let's take it apart.

>> Kay, you are so full of sh*t that it's not funny.

Yes, Linus loves to insult people. We all know that.

>> You're refusing to
>> acknowledge your bugs, you refuse to fix them even when a patch is sent to
>> you, and then you make excuses for the fact that we have to work around your
>> bugs, and say that we should have done so from the very beginning.

What Linus completely ignores is that Kay sent a mail to the LKML about
the changes long before they hit any major distributions (execpt Arch)
- and nobody spoke against them. Linus didn't even reply to the thread.
So suddenly, 9 months later, what didn't even deserve his attention
before is now a big problem - and it even got "fixed" after he spoke.

Kay did nothing wrong here, he communicated his changed openly.

>> but quite frankly, I am leery of the fact that the udev maintenance seems to
>> have gone into some "crazy mode" where they have made changes that were known
>> to be problematic, and are pure and utter stupidity.

Oh yes, Linus likes to generalize when he is ranting. This was about
this single change, he didn't give examples of any others. And as I
said, the change was clearly communicated when it was made (many many
months before the thread you referenced).

>> We are apparently better off trying to avoid udev like the plague. Doing
>> something very similar to this for module loading is probably a good idea
>> too.

More insults with no technical justification. Linus' "rant mode" is
something you need to read with lots of care.

> Linus Torvalds:
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49758/focus=1368496
> 
> Or are you interested in the opinions of prominent developers only
> when they fit your world-view?

I am interested in opinions when they are founded on a technical basis.
Linus often likes to rant, and most of the time he is right when he
does. In this case, there was only one technical argument - most of the
people that quote this post (press, eudev maintainers, ...) don't even
know what this was about in the first place (do you?). They merely read
the insults around it and believe Linus is right, because he is Linus.

This whole issue has long been settled, and yet they use it as an
argument against Kay and his maintainership of udev.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20121120/941776f7/attachment.asc>