RedShift schrieb:
You guys just don't get it. This is about _principle_.
YOUR principle.
Yes, and guess where I got them from. Arch, 3 years ago.
I doubt that narrow-mindedness is a principle that you got from Arch.
It is not mandatory for basic system operation. With basic system operation I mean getting a virtual console working and that's it. You know, the thing the users aren't supposed to be afraid of? Having some working xterm's or whatever in X is not basic system operation.
Clearly, you can define basic system operation one way or the other. I count the possibility to allocate Pseudo TTYs as basic system operation. Now, seriously: Show me one system out there that doesn't have devpts mounted or lo up. Show me one user who doesn't those. Show me one machine where the presence of lo or devpts is bad for the system. Only one. You won't find it.
Yes, there are things that need to be hardcoded because there is no way around them. I have no problem with those. /dev/pts doesn't fall in this exception.
That's right, it doesn't.
Then don't complain, I'm sick of it. These changes do not decrease your flexibility, nor do they break anything. Believe me, I am all against changes that remove control from the user. But this is about things a user doesn't have to control, doesn't even want to control. What I want is a system that is flexible on the one hand, robust and unbreakable on the other hand. The 'lo' change (as well as the devpts change) is about increasing robustness without removing any flexibility. I cannot see how this is not a good thing.
*everything* should be in the user's control. That includes things that can shoot him in his own foot. You don't know if there are out there that want to control lo or devpts. Now they'll have to apply a patch every time the initscripts get upgraded.
It is in your control. I'm just doing what makes sense ... if you want to do things that don't make sense, feel free to fork your own initscripts, that's in your control.
This is rule number one of development, always assume the user is stupid. The result of that is, that I have less emails with complaints to answer, less forum posts to unbreak user's systems, one less bugreport to close. It essentially means that I have more time doing things that actually benefit the Arch community.
Yah, that's kind of like exactly the opposite of what Arch stands (stood?) for.
Not necessarily. Of course, at some point I have to assume that a user knows certain things and if the task becomes complicated, then I have to assume much knowledge. However, by keeping the assumption on a user's knowledge to a minimum, I avoid problems. Let's take the 'lo' example: If I assume a user has no idea what 'lo' is, I can still give him a working system by hardcoding the 'lo' interface to rc.sysinit. Then I look at the user under the assumption that he knows what 'lo' is: he still has a working system, his flexibility has not been reduced at all, he is as happy as before (in fact, he won't even notice). To go further: if he really wants to configure 'lo' differently (which he doesn't), he still can. There is in fact a valid reason why we should not hardcode devpts and I am thinking of dropping the thought, but none of you even cared to bring it up, instead you bitch about your weird principles, which you claim to be Arch's principles, insulting developers and being an ass on the way. I am following KISS and trying to make things simpler, while you want to keep things more complicated, because you think that's what Arch is about.