Moving w3m out of standard

Soren Hansen soren at
Sat Jun 21 00:02:13 UTC 2008

On Fri, Jun 20, 2008 at 03:34:52PM -0500, Michael Hipp wrote:
>>>> We should probably add an install option to the server CD to only
>>>> install the base system, so that the die hard group of old school
>>>> admins can keep their Ubuntu systems as small as possible, though.
> >> I'm not sure if you're trying to spark a flame war or not. 
>> Err.. No, I'm not. I'm not sure a) what would make you say that, and
>> b) why you seem to be taking this so very personal.
> Because you made the statement that anyone who disagrees is "die hard
> old school". That's offensive. 

I'm sorry you took offence to what I said. It meant it in the most
affectionate way imaginable. In fact, I usually consider myself to be in
that very group. If someone refers to the style with which I attack a
problem as old school, I blush like a school girl (on the inside, at
least). I also proudly refer to myself myself as a nerd or geek.

> It directly implies that we're some kind of extremists standing in the
> way of good and holy progress.

By the very definition, I would say that if you are a follower of the
"old school", then you believe in the way things used to be.  In
opposition hereto are the followers of the "new school" which represents
the way things are now (or are perhaps becoming).  That is not to say
that either stance is extreme, good, nor bad. They are simply points of

>> INSWYTISP, but that's really not the case. I'm attempting to start a
>> discussion about what sort of stuff we should put on servers by
>> default.  The operative word here is "should". Not "could".
> Agreed, but many of the comments and your own thoughts seem to be
> leading toward a greatly expanded list of items to be installed.

If we look solely at the packages I suggested, I don't think 5-6
packages constitutes a greatly expanded list of items to be

> And "should" surely is subjective and situational.

Yes. You will notice that I have not actually made any changes although
I am actually in a position to make the changes in question. I'm trying
to start a discussion about it and gather data points, so that the
decision will be as objectively sound as possible. 

> The rational-defensible approach, IMHO, is to keep the base install as
> lean as possible but also make it as easy as possible to layer on top
> of that base.

What is the goal you are trying to achieve by doing this?

>> The current approach is something like:
>> 1. Will more than 95% of our users need it? If yes, install it by
>> default. If no, go to next question.
>> 2. Will more than 80% of our users need it? If yes, include on CD. If
>> no, go to next question.
> > 
>> 3. Will more than 10% need it and be completely and utterly screwed
>> without it? If yes, include it on the CD. If no, go to next question.
>> 4. Forget it.
> This is good stuff.

..yet you seem to think that point 1 should read "100%".

>> What I'm suggesting is to add an extra step in between 1 and 2.
>> Something like "Is it something most of our users *should* be using?"
>> or "Does using it constitute what we consider best practice?". If so,
>> install it by default.
> This word "should" keeps cropping up and it bothers me. Who is to say
> what I "should" be using. 

Not I. Nor you. That is why we analyse, discuss, and reach conclusions.

> The tools that a LAMP stack admin should be using are probably quite
> different than what one of my very simple Samba boxes would require. I
> don't think either's list should dictate the other.

You seem to wilfully miss my point. I'm not trying to determine the
/union/ of useful tools for /every possible/ user of Ubuntu Server. I'm
trying to determine the /intersection/ of useful tools for /most/ users
of Ubuntu Server.

>>> Here's my list:
> Evidently my thick sarcasm obscured the fact that this list was
> intended to show how quickly it becomes ridiculous to include what
> everyone thinks is a necessity. 

As we're dealing with tricky bits of set logic, please be careful with
words like "everyone". Surely, "what everyone thinks is a necessity"
(i.e. something that *every* user finds necessary) should be installed?

> (Not to advocate those particular packages.) And I don't agree, for
> example, that 'screen' should be installed by default. It's primarily
> useful, I think, to those of us who never sit at the console. 

I sometimes sit at a console and I find screen to be *really* useful.

> Someone who admins from the console would probably never use it.

I think this is a false assumption. I'm not sure though. That's why I
intend to solicit feedback on the issue when we have established a sound
method for evaluating possible inclusion by default.

> Hence, no matter how bad I want it, it shouldn't be installed by
> default.


>> A guy called Michael Hipp (you may have heard of him) once asked me:
>> "I'm not sure if you're trying to spark a flame war or not."  It just
>> so happens that I'm not, but you sure seem to be.
> And I'm not sure why you think that calling us "die hard old school"
> should not be taken personally or with offense.

I just don't. Sorry.

> It was. 

I apologise. I meant no offense.

>> Let me offer a take on this.  Say there's a package called foo, which
>> 60% of our users would want. If we install it by default, only 40% of
>> our users will have to change the default, while 60% will be happy
>> with it.  Disregarding all other circumstances, surely that sounds
>> sensible?
> No. It doesn't sound sensible. Let me attempt to explain why...

> Take the 60% group that needs the package. The only pain they feel is the 
> necessity, after install, to type a 30-character apt-get command. (I'm assuming 
> it's on the CD or the net is available.) Their system is no worse for it.

Since they take their time to install it later, they find the package to
be useful. Hence, the lack of said package makes their system less
useful than it could potentially be. "less useful" is "worse" here, IMO.

> But the 40% group must a) allocate partition space for a package they
> don't need, 

Some of the suggested packages are less than 100kB. I know very few
people who allocate partition space with smaller granularity that a
megabyte.  (The ones who do, I would certainly call "old school", but
that's a different point).  If you're doing so, how do you cope with
increasing size (added help messages, more code) of packages when you
upgrade, for instance? I'd say you're asking for problems.

> b) possibly answer configuration questions during install for a
> package they don't need, 

It's funny that when I suggest installing a packages, I'm assuming that
we'll choose them carefully so as to avoid there being asked additional
questions on install, while you seem convinced that if we add but a
single package more to be installed by default, it will surely be huge
one which will ask tons of questions during its installation, will ony
be useful at all to at most 51% of our users, and extremely offensive to

If you have this little faith in us, I think you're using the wrong

> c) remember to uninstall something that is likely
> out-of-sight-out-of-mind, 

Why would you bother?

> e) live with the knowledge and risk of knowing that uninstalling
> packages is far more likely to break something than an install would
> be (from my experience, anyways).

The idea -- which seems to be lost somewhere -- is to add additional
packages, which users will not want to remove (other than to be
pointlessly difficult).

> (To use an extreme analogy, it's somewhat like all the "crapware" that
> comes on a PC from a big-name manufacturer. 

Except, of course, of the tiny detail that it's called "crapware"
because it's useless to most users.

> And please note that I place great weight on item 'e' above,
> uninstalling is far worse than installing. 

Why do you bother? I'm genuinely curious.
> I think that's a *good* thing because I consider a server to be a
> *platform* upon which I add the things (applications) that make it do
> what I need.

Does "do what you need" include keeping out crackers?

> Note that we could turn this around and complain endlessly about how
> limiting is Ubuntu's rule of "no open ports". You can, to be sure,
> build a far more functional box if you toss that rule. 

Almost true. It's only a functional box, if it's still under your
control. Given enough time, any software will prove to be insecure in
some way. By not installing stuff that listens on the network, we've
contained this threat rather well.

> But please don't. Default deny is still the correct dogma.


> >> If we want to start shipping various huge hand-holding metapackages
> >> to help all those gui-obsessed windows admins to cope, then great.
> > INSWYTISP, but could you please take a deep breath and read what I
> > wrote again. I'm suggesting nothing of the sort.
> Yes you didn't say that at all. But the point I was trying to make is
> that these "package deals" that are optionally installable are, IMHO,
> a better solution than adding lots of clutter to the base install.

Can you perhaps take a minute to explain why you insist on assuming that
"lots of clutter" is what we'll add. All that is being suggested is to
add "a few tools that are useful to most people".

>>> But please don't put them on my server. They won't be much help when
>>> I'm trying to admin a system over a flaky satellite link with 1200ms
>>> ping times.
>> I'm sure you'll enjoy installing extra packages over that sort of
>> connection.
> I do it all the time. Please think of the difference between something
> like apt-get or wget versus something interactive like ssh or, perish
> the thought, a gui. 

You're the one who brought GUI's to the discussion. I don't find the
very interesting when dealing with servers, to be honest.

> The cli can only be made tolerable with tools like screen. 

..yet you only want to share this useful tool with the few lucky users
who already know about it.

> GUIs are unusable.

This is an interesting topic which I'd love to discuss in a different

>> Whether stuff is installed by default or just included on the CD does
>> not matter when it comes to the work we have to put into putting out
>> security updates, FYI.
> I wasn't thinking of the Ubuntu packagers or security team. I was
> referring to the work by the end admins of having to install (test,
> verify) security updates for packages they don't want or need.

Good point.

> Every update/install is a risk - especially if you're talking about a
> mission critical server that is 300km distant. It's a risk that the
> update might go wrong and hose the box. It's also a risk that the
> update might be missed and lead to an unpatched vulnerability.

You might have noticed that at least some of the tools I suggested to
begin with were security tools. They're designed to solve security
problems. Their failure to be installed by default are this very minute
making scores of machines more vulnerable. (and it's all our fault,
because we failed to simply install those packages by default).

Soren Hansen               | 
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd.             |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <>

More information about the ubuntu-server mailing list