Moving w3m out of standard

Michael Hipp Michael at Hipp.com
Fri Jun 20 20:34:52 UTC 2008


Soren Hansen wrote:
> [Michael told me in a different e-mail that he replied off-list by
> accident, so I'm taking the thread back on the list]
> 
> On Fri, Jun 20, 2008 at 08:07:14AM -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. It directly implies that we're some kind of 
extremists standing in the way of good and holy progress.

> 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. And "should" surely is 
subjective and situational. 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.

> 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.

> 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. 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.

>> 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. (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. Someone who admins from the 
console would probably never use it. 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. It was. Maybe it shouldn't be, but it was. 
(And it is often said, erroneously perhaps, that perception is reality.)

> 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.

But the 40% group must a) allocate partition space for a package they don't 
need, b) possibly answer configuration questions during install for a package 
they don't need, c) remember to uninstall something that is likely 
out-of-sight-out-of-mind, d) type a similar 30-character apt-get command to 
remove the package, 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).

(To use an extreme analogy, it's somewhat like all the "crapware" that comes on 
a PC from a big-name manufacturer. You have to endure the pain of the degunking 
in order to have a machine that runs and responds like it should. Yes, it would 
be way over the top to insinuate this would be anywhere near that bad.)

So a crude economic analysis would put the "cost" of making the 60% group happy 
much higher than going with the wishes of the minority 40%. And please note 
that I place great weight on item 'e' above, uninstalling is far worse than 
installing. Maybe I'm just unlucky.

>> None of them (along with w3m) are in any way essential to get a basic
>> server up and running. So why include them?
> 
> Because a server that does nothing but boot is useless for anything but
> heating your house and increasing your electrical bill?

Oddly, that's pretty much how an ubuntu-server install is. It really won't do much.

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.

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. But please don't. Default deny is still 
the correct dogma.

>> So don't start me out in a mansion when a rustic cabin is adequate for
>> my needs.
> 
> To keep to the house analogies, I think that your suggestion is closer
> to just providing the foundation of the house and leave it up to anyone
> who actually wants a place to live to build the house itself, install
> doors, windows, heating facilities, bathrooms, kitchens, etc., because,
> you know, a very significant percentage of the world's population
> manages survives without most of these things, so who are we to go and
> decide that everyone should have heating facilites installed even though
> they can just choose to not turn them on?

You're right, it's probably more accurate to call it a foundation. My word was 
platform. They're roughly synonyms. Again, that's what I want: a foundation. 
Carrying on the silly analogies: I suspect some who would make very sensible 
choices about heating systems would be completely bumfuzzled at my insistence 
that it be heated by a wood stove rather than something more modern. But I 
don't want a resource-sapping central air monster when something far more 
simple and functional would have fit my needs better.

>> 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.

>> 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. Apt-get works very well over sorry links. The cli can only be made 
tolerable with tools like screen. GUIs are unusable.

> 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.

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.

Michael




More information about the ubuntu-server mailing list