Date: Fri, 16 Sep 2016 20:09:06 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: scratch65535@att.net Cc: freebsd-ports <ports@freebsd.org> Subject: Re: Checking port option descriptions Message-ID: <CAN6yY1spzzW7Poj=mkgqmR1=fOHyBuTXPLtB47cPnjaqfv-4kQ@mail.gmail.com> In-Reply-To: <ipqotbtp084uvimbt3o360cusgjgn15msd@4ax.com> References: <alpine.BSF.2.20.1609160951090.12548@wonkity.com> <3de26d31-e4e0-ddc4-27ae-03bab473849b@ohlste.in> <ipqotbtp084uvimbt3o360cusgjgn15msd@4ax.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 16, 2016 at 3:42 PM, <scratch65535@att.net> wrote: > On Fri, 16 Sep 2016 15:11:51 -0400, Jim Ohlstein <jim@ohlste.in> > wrote: > > >"[S]ome" being the operative word here. I don't disagres with your basic > >premise, but the truth is, at the end of the day it's up to the user to > >understand the consequences of his decisions. If a user doesn't know > >what 'XYZ' is, then adding 'Include protocols for use with XYZ servers' > >probably doesn't tell him or her that much. On the other hand, if a user > >knows what 'XYZ' is, then 'Enable XYZ' is likely enough information with > >which to make a decision. > > > >So in this case there are likely to be two categories of users: those > >who know what 'XYZ' is and those who do not. Those in the former have > >the information either way. Those in the latter have three basic choices: > > > >1) Educate themselves before possibly adding software to their system > >that they do not fully understand, thereby moving into to the former > >category. > > > >2) Choose the default, on the (very possibly mistaken) assumption that > >the porter "knows what's best." Unfortunately that assumption may be a > >bad one, as the porter/maintainer is more likely to choose something > >that satisfies "most users" and loads people with unnecessary > >dependencies (thus defeating much of the benefit of building your own > >ports), or worse, to choose options that work best for him or her. > > Most people want to *use* the machine they're integrating. For > them it's not a pastime or hobby. > > Very few such people have the time or energy to "educate > themselves" enough to understand the interactive effects of the > many MANY options for each of the ports they want to install. > > In part, that's due to the useless "comments" Warren rightly > calls out in his post. So yes, in hope of being safe, they'll > accept the defaults. With real, thoughtful, information-rich > comments, that might actually happen less often. > > The same problem affects software development and causes a lot of > code to be re-written from scratch rather than maintained. Told > to comment their code, too many programmers write things like " > x=x+1 ; // increment x" and are baffled when more experienced > engineers are scathing during code review. After all, they did > comment each line, so what's the problem? If people want to > understand what the code does, they should study it! > While I agree that you can't hope to fully cover the meaning of the each option, some clue as to what it means if just so we can know where to look for more information. Some items are both hard to describe briefly and not worth the effort. E.g. the long list of available codecs and formats. What can you hope to say about inclusion of speex or x264 in the available space? On the other hand, what the heck is VDPAU? (Yes, I know, but lots of people don't). Also, if an option has licensing implications, that's important to many, but seldom mentioned. Even when the meaning is clear in global sense, what are the implications for an application. E.g. "RTC=on: Add support for kernel real time clock" in mplayer. I know exactly what the RTC is, but I have no idea why I might or might not want it in mplayer. No, I don't know the best thing in many cases, but I can assure you that the defaults, while usually a good choice, are sometimes not. A prime example is optimization. It is almost always desirable, but is usually not default so that the package can be run on any hardware. I have no answers, but it's not easy or clear-cut, but there is clearly room for improvement. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1spzzW7Poj=mkgqmR1=fOHyBuTXPLtB47cPnjaqfv-4kQ>