public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-pm@lists.osdl.org
Subject: Re: [RFC] Power Management Policies
Date: Wed, 27 Apr 2005 07:22:31 -0700	[thread overview]
Message-ID: <200504270722.31321.david-b@pacbell.net> (raw)
In-Reply-To: <20050418093919.37bb40db@cosmic.amd.com>

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

On Monday 18 April 2005 8:39 am, Jordan Crouse wrote:
>  [ open vs closed device/appliance models]
> 
> From a software point of view, the latter is usually controlled by a
> operating environment (usually GUI based), that is developed by the
> manufacturer and generally not hacked by the end user (most don't even
> have terminals). And of course, Linux on an open system is usually
> installed and hand tuned by the end user working closely with the
> command line.  
> 
> So when it comes to a closed system, then I don't see any problem with
> asking the userspace to configure everything about the policy, because
> it gives the operating environment developer the most control over the
> final device. 

There's product positioning ("marketing") involved here too.  Consumer
electronics models have traditionally been pretty "closed".  Putting
aside (temporarily) the issue that such models don't necessarily serve
the customers as well as they serve the manufacturers, it's also clear
that "open" systems are better for non-appliance/throwaway models.
They support add-on products and multi-vendor "eco"systems, where you
can get new features by add-ons rather than (expensive) replacements.

>From the customer point of view, the attraction of "closed" is limited.
It can be a huge win in terms of ease-of-use to not _need_ to configure
things, and know "this is how you do it".  Turn off brain, use product;
throw it away rather than repairing/upgrading.

I don't see major vendors wanting to move away from "closed" models
at the lower end, or in fact whereever they have the power to dictate
customer "preferences".  (The latter case is also known as a "market
failure", except by radical corporatists...)  But for higher end products,
or when customers truly have (or need!!) choices, then "open" is more
usually the answer.

- Dave


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  parent reply	other threads:[~2005-04-27 14:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-17 21:15 [RFC] Power Management Policies Adam Belay
2005-04-18 15:39 ` Jordan Crouse
2005-04-22 20:05   ` Pavel Machek
2005-04-27 14:08     ` David Brownell
2005-04-27 14:48       ` Pavel Machek
2005-04-28  0:05         ` David Brownell
2005-04-28  8:23           ` Pavel Machek
2005-04-28 17:16             ` David Brownell
2005-04-28 18:59               ` Pavel Machek
2005-04-28 20:28                 ` David Brownell
2005-04-23  7:18   ` Adam Belay
2005-04-27 14:01     ` David Brownell
2005-04-27 14:22   ` David Brownell [this message]
2005-04-27 14:57     ` Jordan Crouse
2005-04-27 16:03       ` David Brownell

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=200504270722.31321.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=linux-pm@lists.osdl.org \
    /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