[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: default MTA



Chris Knadle <Chris.Knadle@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: