On Sunday 28 August 2005 11:37 pm, you wrote:
> I don't really understand what you're so worked up about:  if you don't
> like the defaults, don't use them.

Come on now, Dave.  I know that you don't really mean this.  You are not a 
zombie, are you?  After all, 'like' is an analog, subjective term.  There are 
various grades of likability.  For example, I may like something a lot, I may 
like it just a bit, I may loathe it, or I may love it.

I'm sure you can understand that it is not unreasonable to 'like' the default 
functionality, yet still see room for improvement in it.  Right?  In the real 
world, the mantra "don't use, what you don't like" cannot transcend boundaries, 
no improvements are ever made, and only a finite number of alternatives will 
ever be available.  This is fine for some people, others make an effort to 
improve the situation.  Of course this is much more of a philosophical issue 
that a technical one.

I suppose I'm "worked up" because I am passionate about things that I really DO 
like - such as FreeBSD.  Therefore, if I see something which I believe could 
use improvement, I take action to try and make that improvement happen.  
Although I greatly appreciate your response, I was hoping to receive a more 
technical perspective regarding people's thoughts on the alleged shortcoming.  
If your opinion is "I think the current functionality is fine" then so be it.

Remember, I'm talking about the 'path of least resistance', I understand that I 
could label the slice manually with any number of different configurations.  
The issue I was hoping to shed some light on is... "Can the auto-configuration 
mechanism stand to be improved?".  Is it reasonable (in today's era of dirt 
cheap disk space) to have a mere 256MB allocated to /tmp (or /var or even /) by 
default?  When I looked at the code, it struck me that the 'defaults' aren't so 
much defaults as they are maximums for the default usage.

It is my opinion that the typical end-user should not need to consider the 
nearly infinite number of ways to configure his or her filesystems.  There is a 
'best-practice' recommended by experts (e.g. create /, /var, /tmp, /usr) and it 
presumably should suit the majority of situations encountered.  One day, in the 
near future, a new FreeBSD user will receive a disk drive as a gift that has a 
capacity in the terabyte range.  They will then (unwittingly) proceed to do a 
very typical, default installation of FreeBSD, and end up with a 256MB /tmp!  
I'm actually sad to hear that you think this is acceptable.  In fact, I think 
it is this kind of attitude that keeps open-source systems from being accepted 
by the population at large.  Does your average fireman, police officer, 
accountant, doctor, lawyer, etc. want to think about how they will be laying 
out their filesystems when the reality is that a reasonable and typical layout 
could be done automatically?

> But if you want to change it so the defaults are computed automatically,
> submit a PR with your patches.

I really wouldn't have a problem doing this.  However, before I even begin 
thinking about implementing something, I'd like feedback from the community to 
insure that my reasoning is correct.  This should help maximize the utility of 
the patches as well as the likelyhood that they are actually imported into the 
tree.  For example, I thought that I heard sysinstall was being completely 
re-written by a Google-summer-of-code sponsored project, I may just be 
confusing this with something else.  It would be an awful waste of time to 
implement a change twice or to completely botch something for mere lack of 
knowledge (especially when there is a vast pool of human knowledge to draw from 
such as this mailing list)

Remember, the sysinstall program is used by almost every FreeBSD user to 
perform an installation... it isn't a piece of code you want to simply 'hack' 
at.  I'm sure you have heard of the stories where a missing semicolon caused a 
10 million dollar rocket to explode or a vital telecom network to black-out for 
hours (if not days) on end.  I've lived through these types of stories and it 
has forced me to be much less capricious when I sit down to write a piece of 
code.  As they say... "a stich in time, saves nine".

-Dino

***********************************
Walter Sobchak: GOD DAMN IT! Look, just because we're bereaved, that doesn't 
make us saps! 

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to