Summary of accepted Fedora 20 Changes - week 30

[Nicolas Mailhot]

Le Sam 27 juillet 2013 21:31, Michael Scherer a écrit :

> Sure, so that's 1 person. No, find just a bit more and we will start to
> be able to have proper data instead of anecdote.

I'm quite sure you'll find more than a bit more such users among Fedora
users. And, btw, the burden of proof is on the people who made the
unsubstantiated assertion, don't try to reverse it

Anyway, I've seen a quite a few bad arguments on this thread so I'll make
answers in one go.

1. system MTA is bad, because sendmail is bad → just switch to a modern
replacement like postfix

2. system MTA can not use different sender credentials by user → yes it can

3. it's too much work to configure a mail per user → because it's less
work to do it once per user and per mua rather than one per user
centrally?

4. this is not a simple anaconda patch → I believe it's be way easier to
have anaconda write a stable config file that the ever-changing
"desktop-only" mess we've forced it to cope with for years

5. users don't want local mail spool, they use gmail → then let them
configure at install time the system MTA so it relays mail to gmail

6. nobody understands cron mail, it's obscure, untranslated → nobody is a
stretch and anyway this is a property of the sending apps not of the
communication medium. Fix the text of the notices, localize it, and then
give it to the MTA. You'll need to work on this anyway if you want to do
GUI notifications

7. There is no rate limiting on mail notifications → just do the rate
limiting at the source with a filter-before-sending program. Again, you'll
need to do the same work for GUI notifications

8. but I don't care about those notices, I'll just suppress them, or bury
them in the journal, and no one will be the wiser → this is ostrich
design. Those notices were created because people found them useful

9. A mail does not permit proper interaction → somehow Amazon, Google,
Ebay manage it perfectly. It's just a matter of writing good notification
texts, and adding callbacks to your system with single-use tickets (either
web links or attachments a specialized app can display in a notification
center). When people wanted to play with extensions, there was no such
"can not integrate Internet with the deskop" argument

10. users do not expect a desktop that sends mail → users didn't expect
smartphones at all. I guess neither Apple, not Google, not Samsung should
have spent a dime on them. Users are far more adaptable than you think,
what they expect is irrelevant, what matters is whether your
implementation sucks or not

11. smtpd has no place on a desktop → neither Microsoft, not Apple, nor
Google, are building pure desktop solutions. They're integrating desktops,
laptops, servers, appliances, gizmos, cloud, to provide the best user
experience and choose technical bricks based on the functionality they
want to achieve, not based on archaic silos

12. all users do not know how to filter their mail → a hell of a lot more
users know how to filter their mail than how to filter the custom
notification systems people want to replace them with. And this will still
be the case in the future, since filtering mail is useful for lots of
other things, and dealing with a GUI system that will be rewritten anyway
in a few years is not

13. there will only be at most one Fedora system per home anyway → If
that's the case, Fedora will be a failure. Given plummeting hardware
prices the only bottleneck is Fedora execution (see for example the latest
Google dongle. Google is *not* settling for a single Google system per
home)

14. Fedora users are irrelevant, I want normal users → what has this
attitude ever produced except a collapse in Fedora users? Your normal
users, when they actually had a vote (ie RHEL side, when an unhappy user
can just cancel his subscription), didn't vote the way your "common sense"
indicated (and it was not the first time either, see spacial desktop). Use
less "common sense" and "design", do more actual user studies (real users
not imaginary ones). Removing features never made other features appear by
magic

15. it's useless on servers → on the contrary, once the email
notifications are streamlined and standardized it'd be trivial for server
alerting systems to pick up mail notifications and inject them in a
central console (or if you want to be fancy, just take the local
notification processing node, and have it queue notifications on a
centralized AMPQ bus instead of smtp-side when the bus is available). The
main point is to process notifications before deciding how they are sent,
instead of the direct app-to-GUI-popup unmanaged inconsistent mess

16. I can do the same with a central syslog → good for you, but even if
that was the case it'll be a lot easier for your central system to process
notifications that have been streamlined for a little for smtp sending
rather than the current inconsistent situation

17. there's no need to work on this, "technical" users will know how to
set up an MTA → that's what Solaris people thought before Linux people ate
their lunch integrating stuff they didn't want to bother with

18. We  need a mechanism for providing error data to
users that doesn't require them to run a local application → send-to-gmail
is such a mechanism

-- 
Nicolas Mailhot