mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Kay Sievers <kay@vrfy.org>
Cc: Takashi Iwai <tiwai@suse.de>, Jens Axboe <axboe@kernel.dk>,
	Oliver Neukum <oneukum@suse.de>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: How to fix CDROM/DVD eject mess?
Date: Mon, 2 Feb 2015 21:12:34 +0000 (GMT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1502022050170.22715@eddie.linux-mips.org> (raw)
In-Reply-To: <CAPXgP124AvjVp7-7g4Te7L9Pznppr-8XDHvHDpLy7mq6-vBCDA@mail.gmail.com>

On Mon, 2 Feb 2015, Kay Sievers wrote:

> >  All the technical details aside, this is a bold statement -- how do you
> > know what the user actually wants?
> 
> By working with people who spent a lot of time with the questions what
> the default behavior of user interfaces should be. Buttons, especially
> physical ones, need to give immediate feedback to the user. If they
> don't give it it, people will look for something else to get what they
> want.

 It still covers a group of people only, not all of them.  A UI is a 
convention, there may be different ones.  There is little if anything more 
frustrating in interacting with computers than an UI that "knows better" 
what I want to do than I do, with no way to override the built-in logic.  
I am not a statistical sample, I am an individual with my own preferences.  
I have suffered from such built-in assumptions myself and I talked many 
times to people who complained about them too.

> >  I for one want to see the medium locked if in use, just as it has been
> > since 1990s.  If I wanted to do an emergency eject (the equivalent of
> > ripping out a USB cable), then I would use a paperclip in the manual eject
> > hole.  So you've got a counterexample to your assertion now.  All people
> > are not the same.
> 
> It's just the current default setup and intentional behavior. You or
> your distribution can for sure implement something else.

 Fair enough, but if this is a matter of decisions made by a distribution, 
then why is this an issue raised on LKML?  What does it have to do with 
the kernel or why does it have to be addressed in the kernel, one way or 
another?  Or does it indeed?

  Maciej

  reply	other threads:[~2015-02-02 21:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-02 13:20 Takashi Iwai
2015-02-02 19:03 ` Kay Sievers
2015-02-02 19:34   ` Maciej W. Rozycki
2015-02-02 19:45     ` Kay Sievers
2015-02-02 21:12       ` Maciej W. Rozycki [this message]
2015-02-03 12:36         ` Takashi Iwai
2015-02-03  8:52       ` Oliver Neukum
2015-02-03 13:34       ` One Thousand Gnomes
2015-02-03 17:53         ` Theodore Ts'o
2015-02-02 20:02     ` Austin S Hemmelgarn
2015-02-02 20:53       ` Ondrej Zary
2015-02-03 12:31   ` Takashi Iwai
2015-02-03 13:39     ` One Thousand Gnomes
2015-02-03 13:49       ` Takashi Iwai
2015-02-03 13:40     ` Austin S Hemmelgarn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.11.1502022050170.22715@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=axboe@kernel.dk \
    --cc=kay@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oneukum@suse.de \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®