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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
