Sysinstall automatic filesystem size generation.

[C. Michailidis]

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!