

Re: please deactivate services by default!

Patrice Dumas wrote:
On Thu, Sep 25, 2008 at 03:11:52PM -0500, Matthew Woehlke wrote:
Besides; Patrice, your argument is that we should remove functionality that is critical to some users because no one has bothered to fix the /bug/ that by default logwatch sits around filling the spool with large, mostly-redundant messages.

It is not really my argument. First I think that these issues are
power user issues.

Yes, but...

And then that there is no clear solution for this
issue, there are many use cases with different choices. So, if there no integrated solution, like something with firstboot, /etc/sysconfig or
whatever the users should not rely on a specific setup and should setup
what they prefer and configure it themselves. And they can do that since
they are power users. Starting from this point of view it is better to
have nothing started nor configured and things only pulled in as

...you still need to let them know there is something they need to do, that they never had to do before (which in itself has Irate User potential).

And I strongly disagree with changing from 'something that always worked before' to 'nothing, with potentially catastrophic consequences if you don't know that we removed functionality' being a good idea.

I don't really care that it worked before,

Obviously, I do :-). You're "removing" a feature I depend on. It would be one thing if you have a way to ensure that I know this has been done so that I can re-enable it. You apparently feel differently.

once again it is a very specific
use case and I can't see why it should be priviledged.

...because so far I haven't heard that you've ensured people depending on this will know they have to do something special, now. And, as I've pointed out, that lack of knowledge can have severe consequences.

Because - ok, I told myself I wouldn't, but I'm going to pull out the Big Gun now - if Red Hat did this, and I lost data because of it, I'd be filing a lawsuit. Seriously. You're talking about playing games with people's data, and I don't take that lightly.

And I don't understand why we're still having this conversation. Several suggestions (that, to me at least, seem perfectly reasonable) have already been suggested. Something in anaconda or firstboot would be best (ideally, you could configure things like if you want logwatch at all), that would make sure you either get a local mail MTA, or are required to click through the Big Scary Warning about the Dire Consequences if you elect not to run one. Or make cron require an MTA. Or possibly both.

I'm willing to blame it on user negligence if they knowingly choose not to have an MTA, or purposefully circumvent cron's normal use thereof. I *don't* consider it acceptable for the default cron setup to be changed from one that (IMO) is effective, to one that silently discards output in a way that the user may not even be aware that there is a problem.

Why is that so hard to understand?

(And I'll repeat what I said elsewhere. The replies I'm getting from some people seem to indicate that this is a real issue. If I'm really just inventing a scenario that can't happen, /someone bloody please just tell me!/)

I think that it
was always a mistake to start sendmail in the default case, and even to
install it (not as a dependency).

(I happen to disagree, but that's me... Unless you're only talking about the daemon(smtp) part, and not the MTA part that handles local mail.)

Well it should not be changed within a release, nor by updates, but I would find it normal to have it broken by clean installs (with release notes, if possible).

Who reads release notes? :-)

"You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw)
