Re: Bug#696154: cloud.debian.org: Please install 'less' by default on official Debian AMIs.
On Mon, Dec 17, 2012 at 11:17 AM, Clint Byrum <firstname.lastname@example.org> wrote:
> Excerpts from Thomas Goirand's message of 2012-12-17 06:46:27 -0800:
>> On 12/17/2012 10:23 PM, Charles Plessy wrote:
>> > To Thomas: less is installed on almost all Debian systems where
>> > popularity-contest is installed, and is used in almost a half of these systems.
>> > So instances used interactively, this is definitely a command that is missing.
>> I don't agree.
>> > But in the long run, we need a solid criterion to decide what is included and
>> > what is not.
>> This was exactly my point, and I had no doubts that you would get it.
>> > Do you or others know about evaluations on the costs caused by
>> > adding extra kilobytes or megabytes to a machine image ?
>> The point isn't to add or remove extra kilobytes, but to ship the
>> strict minimum. Otherwise, we might as well add:
>> - GNU screen
>> - vim
>> - joe (yes, I like this one...)
>> - emacs (wooo... a few megabytes!)
>> - less
>> - etc.
>> Why not? These are nice...
>> So if the criteria is to have the strict minimum, "less" isn't needed.
>> If it's to have a nice env, then we'll fight and fight over and over
>> again to decide which should be added (vim vs emacs anyone?).
> Just a thought, but the more that is left out, the more people are pushed
> to create their own special-snowflake images, which makes it much harder
> to consume the official ones. While a few apt-gets at first-boot here
> and there are fine, at some point you look at how much instance time
> you're spending bringing up instances, and you make an image.
> Perhaps apply an 80/20 rule. If a package is useful to 80% or more of
> the users and does not interfere with any other package, then its a win.
> Just using anecdotal reference, I'd say less is something most users
> expect to have. Vim and screen are pretty popular, but I don't think
> they're quite over the 80% hump.
So my viewpoint here is largely in alignment with Clint Byrum's, in
that the standard images should largely not break user's expectations,
and perhaps we should consider looking at what other standard AMIs are
shipping with. e.g. Amazon Linux, Ubuntu, etc. One argument to do this
is so folks can utilize the ton of information already out there on
using EC2, but also, because we don't necessarily want to have to
force new users to have to install a ton of packages just to have a
generic useable system. At a minimum, this should include the tools to
get cloud configuration tools working. e.g. - Python, but also other
tools that are likely to be needed for those used in automatic
bootstrapping, like curl for getting instance metadata. I'd say that
as long as we provide the tools for people to easily build "lean"
AMIs, that building a slightly fatter one should be ok, as those who
want the lean one are likely to be more advanced users, and probably
would want to customize things like root volume size as well.
In the particular example of less, I'd say that it's a fairly standard
$PAGER, and likely makes the cut. In the question of vim vs emacs. I'd
say we should ship with some sort of full screen editors (guessing
pico and vim). (They do say most emacs users know enough vi to install
emacs). Emacs-wise, I'd probably skip since there are so many variants
of emacs we support that are all pretty popular in the emacs crowd,
e.g. xemacs, gnu emacs, ng, etc.
So in summary, I'd say that while it would be easier to make the
threshold for whether a package is installed simply, "Is it absolutely
required to finish bootstrapping", I'd argue we should take the extra
work to be more inclusive and evaluate if it is expected to be there.
(I know the test will be largely subjective, and will take more
research, but I do feel that it is the correct approach.)
If folks agree to this approach, I would be willing to help collect
the data on what default packages other popular AMI/distros ship with.
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
> Archive: email@example.com">http://firstname.lastname@example.org