Fwd: Bug#696154: cloud.debian.org: Please install 'less' by default on official Debian AMIs.
Den 17 dec 2012 17:32 skrev "Brian Gupta" <firstname.lastname@example.org>:
> On Mon, Dec 17, 2012 at 11:17 AM, Clint Byrum <email@example.com> 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.
> >> And?
> >> > 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.
What 80/20 rule? I know of no such rule when it comes to how technical
excellence in Debian are done.
> 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.
As said, I don't agree, as that are no way of deciding what is "nice"
to have. Debian is based on technical merits, and packages should be
selected on technical merits. What is needed and what must be there.
If there are something more which could be useful for beginners, then
a package that will install that would be more useful, it would even
be very good to have. But as a long time Debian user I expect only
technically excellence, and not lots of extras that are "useful" but
not needed in a base installation.
> 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.
I think Emacs proper, GNU, is much more useful than anything else and
are one of the first packages I install after ntp, but I do not expect
that to be installed in a base installation. As I wrote, I do not
expect a base package to be bloated, I expect it to be lean. And I
expect that there are other packages that fix other not so clean
installations, like beginners web servers 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.)
I would say it again, it is much easier to add packages than to
remove, and also easier to verify correct behaviour on a smaller
number of package. It is hard as it is.
> 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.
Why then look at others, when we do have popcorn installed on so many
machines and do already have the statistics of what people uses in
Debian? Which basiclly is what is on CD one.
I don't think that your offer to work on this are bad, but I don't
think it's the right decision to base the base package on. But it
would be great if that could easily be added later when you deploy
your machine, by just list packages to install. As infrastructure for
automatic installation of Debian packages and configuration of them
are already there, it shouldn't be that hard to inject lists for this
into the image.
Yours, Anders Jackson