Chris Knadle <chris.kna...@coredump.us> writes: > On Wednesday, May 29, 2013 15:46:15, Russ Allbery wrote:
>> That's exactly the point, and is why I would prefer not to write those >> notifications into a file that no one ever looks at. (Which is why I >> don't find sending them to syslog much more appealing, since the >> average desktop user is never going to look there either.) > Somehow this problem reminds me of the "event log" used on "a popular > operating system". Most users don't read that log either. Yes, but what users *do* read is some sort of event log that throws an attention icon (or spawns a window) on login or on event that doesn't go away until the user looks through the messages. I know we probably don't have something like this right now, but it's something that can be done, and would be much superior to email for a lot of users (including myself on a lot of systems). One could easily solve the persistent problem in a similar way if a history of such notifications were kept and could be retrieved by the user by manually launching the application. None of this seems particularly novel (we've written similar things at Stanford for managed desktop situations and deployed commercial products that do something similar, not to mention that it's how most anti-virus updators and now the OS patch updators work), which makes me wonder if someone is already working on (or has finished) a mechanism of corraling some desktop notifications into that sort of framework. Basically, what we're looking for here is the equivalent of a check engine light (except, of course, with better user-visible diagnostics available). That's what the end user actually wants: something clear and visible indicating that something is wrong, which they can drill down and see the details and dismiss the error condition if they want, or have all the details available to consult someone who knows more about computers if they don't know what to do with it themselves. Historically, root cron mail has been exactly that, and that's still a great way of handling it for servers, since that mail can be sent off somewhere centrally, analyzed and assigned to sysadmins, used to open internal trouble tickets, etc. But increasingly desktop users are just not thinking about their computer as something that sends them mail, nor is there a good mechanism in place most of the time for the computer to do so effectively. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87hahlz659....@windlord.stanford.edu
