please deactivate services by default!

[Matthew Woehlke]

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

...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? :-)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"You know what Microsoft's problem really is? They've lost the ability 
to feel ashamed." -- Pamela Jones (Groklaw)