[arch-general] [arch-dev-public] initscripts changes

[Thomas Bächler]

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.

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