Steve Langasek wrote: > On Wed, Oct 12, 2011 at 08:34:52PM -0700, Josh Triplett wrote: > > The main reasons to stop having an MTA in standard: > > > - Starting a daemon at boot time, which slows down booting. This led me > > to notice the problem in Debian Live: it took a non-trivial amount of > > time for the boot process to finish starting exim and move on. > > Does Debian Live use insserv with parallel booting? Granted, I/O is the > bottleneck for booting from CD, so there's still going to be some impact; > but on my systems (which all use postfix - so you can count me among the 20% > of popcon users who have uninstalled exim to install postfix), MTA startup > time is pretty small - on the order of 1.5s according to my bootcharts, > which is hardly anything on the systems in question.
As far as I know, it uses insserv; I don't know if it uses parallel booting or not. I suspect it uses the default configuration, which means it uses parallel booting. However, even with parallel booting, the login prompt does not become available until all the init scripts finish. exim4 took several seconds to start, and the login prompt did not appear until it finished. I was booting from a USB disk, and not a particularly fast one, which may have contributed to how long exim took. I can say that it took a nontrivial fraction of the total boot time. On the flipside, getting to the point where the system only takes a couple of seconds to boot means eliminating everything unnecessary. > > - Listening on ports by default, which exposes the system to any > > potential vulnerabilities, as well as potentially allowing the sending > > of spam. I've checked, and out of all the packages with priority > > standard or above, only exim and isc-dhcp-client listen on ports by > > default. Removing an MTA significantly reduces the attack surface of > > a default Debian system. > > Running an MTA does not imply accepting mail from outside the machine for > delivery. We could address this by configuring our standard MTA to only > accept from localhost by default, or to only accept submissions via > /usr/sbin/sendmail by default. If the MTA didn't listen on any ports by default (localhost or otherwise), only accepted submissions via sendmail, and didn't run a daemon, then I'd care a lot less about getting it out of standard. > > - Asking configuration questions via debconf at install time, which > > increases the amount of work and complexity required to install > > Debian. For most users, these questions will duplicate the process > > they later go through to configure their MUA. > > That's absolutely a bug in the MUAs for requiring additional configuration > instead of working with the default. I've already found out via this thread that exim4 now defaults to local-only delivery, and asks no questions at startup, so feel free to ignore this point. > > - Taking time to download and install, which increases the time and > > bandwidth needed to install or upgrade a Debian system. > > I think you're reaching with this one. The primary bottleneck when installing Debian consists of waiting for a large number of packages to download and install. Making that process take less time, multiplied across the huge number of people installing Debian, seems worth it. This holds particularly true for slower Internet connections. > > - Running a daemon all the time, which takes up RAM. > > You're worried about this on a desktop system running firefox? So we should make it that much worse for everyone? Every bit of RAM used by a program represents that much less disk cache. Plenty of people work on making Firefox and other programs use less RAM; let's not contribute to the problem. Also, exim4, as a daemon that doesn't wake up often, is a pretty good candidate for swapping out, which makes for that much more of a performance hit when it needs to swap back in. (Oh, and one reason I forgot: waking up periodically also makes systems use marginally more power.) > Your proposed benefits become more outlandish from there, so <snip> I listed every reason I could think of here, rather than pruning at the point where I felt it already far outweighed the cost of requiring mail server administrators to type one command to install a mail server. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111016004513.GA29963@leaf
