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

[RedShift]

Thomas Bächler wrote:
> Arvid Ephraim Picciani schrieb:
>> On Monday 07 April 2008 13:52:21 Thomas Bächler wrote:
>>
>>> 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.
>>
>> Your assumptions are worse then i thought. 
> 
> I just assume as few knowledge as I can, as long as maximum control and 
> flexibility is assured. In this very special case, I can assume no 
> knowledge at all without removing any flexibility from smarter users. 
> There could be no better situation than this.
> 
>>> Then I look at the user under the assumption that he knows what 'lo' is:
>>> he still has a working system, 
>>
>> ubuntu is "working" too.
> 
> Actually, from what I hear from experienced Linux users, it's not. I 
> never tried myself though.
> 
>>> 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.
>>
>> weird. exactly the arguments ubuntu devs use. 
> 
> I am insulted by that comment and expect an apology.

Insulted or not, it is 100% right what Arvid wrote.

> 
>>>    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.
>>
>> ubuntu-simple and arch-simple are different.
> 
> Arch implements many aspects of simple:
> - Simple to understand the underlying system (scripts, package 
> management and so on)
> - Simple to modify the system (making packages is soooo easy in Arch)
> - Simple to use and configure
> 
> Most people seem to forget that last point. If we can make the system 
> simpler to use (and thus more robust and error-proof) without adding 
> unnecessary complexity, then we have to do it. But instead of being 
> happy about it, _some_ of our user base start screaming
>> ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu, ubuntu,
> as soon as we make a change that makes life easier for them. In this 
> case, I am being insulted for _thinking_ about adding one line to a 
> script, that would make the lives of many people easier (wow, one extra 
> line, that certainly adds so much complexity, Arch is really becoming 
> Ubuntu these days).
> 
>> just not archlinux.
>>
>> http://phraktured.net/arch-way.html
> 
> If you had actually read that document, you would understand my point 
> completely.
> 
> I quote:
> "'Simple' is defined from a technical standpoint, not a usability 
> standpoint. It is better to be technically elegant with a higher 
> learning curve, than to be easy to use, and technically crap."
> 
> What you don't get is that if you have to make a decision between two 
> equally technically elegant decisions, and one of them improves 
> usability, you go for usability.
> What you and some other people here seem to think is that usability 
> automatically implies technical non-elegance.

There's nothing elegant about hardcoding stuff. Simple as in a technical standpoint, says that it should be mounted in fstab. Why? Because fstab is the place were filesystems that should be mounted on boot go. The damn thing is *made* for it.

Take again for example lo, if I want to reconfigure it, everytime the initscripts get upgraded, I have to apply a patch I had to write myself to change lo to whatever I want. How exactly does this fit the "simple" scenario? Plus it adds unnecessary code to the initscripts, while we've already got a perfectly working network initialization scheme. And lo fits right in.

It's the thought behind all of this that is being questioned here. Arvid is right.

And it doesn't matter if the user Does or Does Not Want, it's about that he Can.

> 
>> http://phraktured.net/patching-patching-patching.html
> 
> This is absolutely not related to this topic, so I won't comment on it 
> here.
> 
> 
> I will say it one last time: Adding the _necesity_ to configure 
> something that doesn't need to be configured is crap, from a technical 
> and a usability point of view and thus defeats the Arch Way.
>