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 -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
