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

[RedShift]

Thomas Bächler wrote:
> RedShift schrieb:
>>> /proc and /sys are already hardcoded. About your system being broken
>>> without these filesystems mounted:
>>> - SSH (both server and client) won't work without devpts mounted
>>> - None of the virtual X terminal things will work without devpts mounted
>>
>> It doesn't prevent the system from booting and having a working 
>> virtual console. So people can fix it if they decided to mess with the 
>> default entries in fstab.
> 
> That's correct.
> 
>> 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.

> 
>> And its not because there already are some filesystems hardcoded, that 
>> the rest should be.
> 
> I'm not talking about "the rest", I'm talking about things that are 
> mandatory for basic system operation.

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.

> 
>> In fact, these should be moved from hardcoding to fstab. But that will 
>> probably never happen.
> 
> You're right, it won't, because it is impossible. If you would care to 
> even read rc.sysinit, you would know why.

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.

> 
>> Wether these are "virtual" or "real" filesystems, it doesn't matter: 
>> the fs in fstab stands for FileSystem, period. If something needs to 
>> be mounted, it should go there.
> 
> Says you?

Yes. It's logical.

> 
>> This is exactly as what happened with the lo moving to rc.sysinit, 
>> hiding stuff so the newbies won't remove it because they think they 
>> don't need it. And the fact is, if you remove lo from the system, you 
>> can *still* boot your system and most stuff works without lo. So they 
>> can still fix lo if they removed it.
> 
> This is not about hiding things, it is about keeping it simple. What is 
> simple about having to configure something that everybody needs, always 
> needs it and will break everything if it is configured differently? It 
> is unnecessary to even be able to configure it. So simplicity tells me 
> to hardcode it.
> 
>> I'm sick and tired of complaining about issues like these, that 
>> shouldn't be discussed in the first place. Do you think I like 
>> complaining?
> 
> 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.

> 
>> Since when do we assume the user is stupid? All that's been 
>> accomplished here is create a big mess.
> 
> 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.