On the sickness of our community

Posted Oct 14, 2014 15:48 UTC (Tue) by ThinkRob (guest, #64513)
In reply to: On the sickness of our community by johannbg
Parent article: On the sickness of our community

My issue wasn't with Kay's wording or anything like that. I didn't see him be anything but civil. It was more the sentiment behind the action that worried me. Let me try to explain:

> And to this day I have yet to see the kernel community have an architectural discussion about those *generic* namespace kernel parameters which are open to misinterpretation which is the underlying problem that caused this to begin with and change the name of *their* parameters and fix *their* workflow accordingly since misinterpretation like this was bound to happen eventually and bound to happen again. ( If it had not been systemd it would have been something else)

Ok, so you want better naming. Fair enough. (Which, BTW, is what ended up happening, with systemd using a more specific name...)

But like with any API that's been there for a while, there is now an established base of code that depends on certain parameters working in a certain way.

This is where the split in ideology happens.

One side says "we should just start doing things 'the right way' and screw whatever breaks, 'cause it was broken anyways". It seems to me that you're clearly of this mindset, as are many in the systemd community. I understand the appeal, and I too used to be of this mindset.

The other side takes the approach of "here is how people expect it to work, and even if it's not ideal we shouldn't just wholesale break all of their expectations just because we had a better idea". This is where Linus seems to fall. I tend to agree with this more nowadays, having been on the receiving end of one too many "your stuff is now broken 'cause you were doing it 'wrong'" changes, particularly ones where "wrong" meant "not the way I want to do it."

The problem with the first is that very few people can agree on what "the right way" is, so that too ends up in a pissing match. Usually the best politician or the strongest ego wins, and continual battling coupled with CADT means that it becomes very hard to have a system that remains "stable" (in the development/administration sense, not the uptime sense) for more than a couple years.

The problem with the second is that if left unchecked, you wind up with Win32.

Both sides need to be aware of the dangers of their default stance. I've seen awareness of that in the Linux kernel dev. community throughout the years (as evidenced by the many long discussions surrounding various large-scale changes, many of which have been covered here on LWN), but as of yet I've seen precious little awareness of the dangers of the first approach in the systemd community. And *that* is what concerns me.

to post comments

On the sickness of our community

Posted Oct 14, 2014 17:26 UTC (Tue) by johannbg (guest, #65743) [Link] (3 responses)

"One side says "we should just start doing things 'the right way' and screw whatever breaks, 'cause it was broken anyways". It seems to me that you're clearly of this mindset, as are many in the systemd community. I understand the appeal, and I too used to be of this mindset."

Yes I am of the opinion that things that are broken are supposed to be fixed where they are broken not workaround so if that happens to be systemd then it should be fixed in systemd or if it happens to be the kernel it should be fixed in the kernel.

"The problem with the first is that very few people can agree on what "the right way" is, so that too ends up in a pissing match. Usually the best politician or the strongest ego wins, and continual battling coupled with CADT means that it becomes very hard to have a system that remains "stable" (in the development/administration sense, not the uptime sense) for more than a couple years."

I would argue there are only few areas of stability that actually existing in open source software since the governing mentality is "throw it over the wall and see what sticks" Look at Gnome for example I would argue that it has been in beta state since it got introduced in RHL.

With regards to what concerns you I did not manage to follow what you where referring to as first approach and second half hence I could not put into context so you kinda need to spell it out what actually concerns you.

On the sickness of our community

Posted Oct 14, 2014 20:36 UTC (Tue) by viro (subscriber, #7872) [Link] (2 responses)

Bloody wonderful. Do you suggest we do the same with the kernel-to-userland interfaces? You know, on the theory that interface stability is so rare that nobody would care. Because there's a whole lot of ill-designed crap I would love to be rid of - all the *notify stuff, for starters. And cgroup would be much improved by being ripped out and replaced with something saner. And ioctl-based part of socket API is a disgraceful mess - we wouldn't *need* netdev namespaces if it had only been done right back in early 80s. So's sysv IPC interface. Let's kill them, should we? What, tons of userland code would break? Tough, but serves them right for using bad interfaces. Oh, and sysfs? A walking design mistake, with really unpleasant consequences wrt e.g. containers. Let's take it out as well, while we are at it...

Do you really want that? BTW, I'm absolutely sure that glibc people also can provide a not so little list of misfeatures that won't be missed (and screw those who would miss them)...

On the sickness of our community

Posted Oct 14, 2014 21:07 UTC (Tue) by johannbg (guest, #65743) [Link]

I would not say bloody but quite wonderful yes.

If it's broken in the kernel you fix it in the kernel or where else would you have the kernel-to-userland interfaces fixed and the rest you listed there and or wanted to get rid of?

On the sickness of our community

Posted Oct 15, 2014 6:14 UTC (Wed) by tao (subscriber, #17563) [Link]

It certainly *would* be wonderful if that would be at all feasible. Of course it isn't. But trying to clean up a bit in the swamp of boot-time command-line options (which is a mish-mash of options to the kernel, kernel modules, the boot loader and init) is (in my opinion) quite far from stuff like ioctl, cgroups, *notify, etc.

That said, it's Linus's kernel, and if he decides not to namespace the debug option, then I think that's his prerogative.

PS: It would be kind of nice to have a consistent set of "non-legacy" kernel interfaces (such as you allude to) and an option to disable all the legacy stuff. I wonder how much cleaner & safer software written against such an interface would be.

PPS: Yes, glibc would certainly benefit from removing quite a bit of brainfuck and in cases like gets(3) -- which is not deprecated by LSB, obsoleted by POSIX and removed from C11 -- everyone who do use them should indeed be screwed. But again, wholesale crapectomy would of course be infeasible, unless aiming for a "non-legacy" OS.