|
|
Log in / Subscribe / Register

On the sickness of our community

On the sickness of our community

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

"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.


to post comments

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds