On Wed, 09 Feb 2011 13:43:59 +0800, Bret Busby wrote:
> Could the Release Notes include a component that matches CPU model with
> appropriate distribution version?
(...)
For someone who is going to install an OS, that's something that should
be found by the user itself. More than a mere "technical" decision (both
architectures -i386 and amd64- will work under 64-bits machines),
choosing between the two is something that is completely up to the user's
preferences as there are many other aspects to consider beyond going A or
B.
If in doubt, better ask here or in forums.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.02.09.11.16.46@gmail.com">http://lists.debian.org/pan.2011.02.09.11.16.46@gmail.com
Wed Feb 9 12:30:03 2011
Return-path: <desktop-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Wed, 09 Feb 2011 12:10:31 +0200
Received: from bastion02.fedoraproject.org ([209.132.181.3]:58884 helo�stion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <desktop-bounces@lists.fedoraproject.org>)
id 1Pn70J-0006dJ-Bk
for tom@linux-archive.org; Wed, 09 Feb 2011 12:10:31 +0200
Received: from lists.fedoraproject.org (collab1.vpn.fedoraproject.org [192.168.1.21])
by bastion02.phx2.fedoraproject.org (Postfix) with ESMTP id DFDF4111ECC;
Wed, 9 Feb 2011 11:18:41 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id A59DB326782;
Wed, 9 Feb 2011 11:18:40 +0000 (UTC)
X-Original-To: desktop@lists.fedoraproject.org
Delivered-To: desktop@lists.fedoraproject.org
Received: from smtp-mm03.fedoraproject.org (smtp-mm3.fedoraproject.org
[152.46.7.226])
by lists.fedoraproject.org (Postfix) with ESMTP id 8101D326743
for <desktop@lists.fedoraproject.org>;
Wed, 9 Feb 2011 11:18:28 +0000 (UTC)
Received: from mail-ey0-f173.google.com (mail-ey0-f173.google.com
[209.85.215.173])
by smtp-mm03.fedoraproject.org (Postfix) with ESMTP id C388B37D58
for <desktop@lists.fedoraproject.org>;
Wed, 9 Feb 2011 11:18:27 +0000 (UTC)
Received: by eyg7 with SMTP id 7so14422eyg.32
for <desktop@lists.fedoraproject.org>;
Wed, 09 Feb 2011 03:18:27 -0800 (PST)
Received: by 10.213.34.9 with SMTP id j9mr1604942ebd.42.1297250306921;
Wed, 09 Feb 2011 03:18:26 -0800 (PST)
Received: from valhalla.rhi.hi.is (valhalla.rhi.hi.is [130.208.69.191])
by mx.google.com with ESMTPS id b52sm144388eei.1.2011.02.09.03.18.25
(version=SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 03:18:26 -0800 (PST)
Message-ID: <4D527800.2000600@gmail.com>
Date: Wed, 09 Feb 2011 11:18:24 +0000
From: =?UTF-7?B?IkorQVBNLWhhbm4gQi4gR3UrQVBBLW11bmRzc29uIg==? <johannbg@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14
Thunderbird/3.1.7
MIME-Version: 1.0
To: desktop@lists.fedoraproject.org
Subject: Re: GNOME3 feature page - updated scoped and comments
References: <1297201044.9601.113.camel@flatline>
In-Reply-To: <1297201044.9601.113.camel@flatline>
X-BeenThere: desktop@lists.fedoraproject.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Discussions about development for the Fedora desktop
<desktop@lists.fedoraproject.org>
List-Id: Discussions about development for the Fedora desktop
<desktop.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/listinfo/desktop>,
<mailto:desktop-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/desktop>
List-Post: <mailto:desktop@lists.fedoraproject.org>
List-Help: <mailto:desktop-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/desktop>,
<mailto:desktop-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="==============&74790273415707913=="
Sender: desktop-bounces@lists.fedoraproject.org
Errors-To: desktop-bounces@lists.fedoraproject.org
This is a multi-part message in MIME format.
--==============&74790273415707913=Content-Type: multipart/alternative;
boundary="------------070102010202030204010508"
This is a multi-part message in MIME format.
--------------070102010202030204010508
Content-Type: text/plain; charset=UTF-7
Content-Transfer-Encoding: 7bit
On 02/08/2011 09:37 PM, James Laska wrote:
> = Comments +ACY- Discussion > Given that GNOME 3 offers a +ACo-dramatically+ACo- different user experience
> than GNOME 2.X, there are going to be plenty of users who are
> surprised/disrupted by the changes. As a result, we wanted to start
> compiling common questions/workarounds/workflows that have come up so
> far. I anticipate referencing these a lot on irc/lists. Perhaps, over
> time these migrate into release notes.
We need to get this list going and keep tabs on bugs filed against that
design decisions and preferable point to upstream bugs/discussion(s) as
Bastien did in respond to me in another thread on this list since I hit
yet another case what I call a regression/bug but another might call
works as designed.
We had a shitty weather last night which was perfect for me to just
throw myself in the couch in the living room reading a ebook over a warm
cup of coffee before you hit the sack well that did not turn out so well
I spent most of the time battling "power saving" features since I was
running the laptop on battery on my couch in my living room.
No matter what I did ( setting the brightness to max ) after I period of
time I either had a screen lock or the display decided to dim it self
again which by the way to not seem to be consistent to behaviour I set
it to and going through the power settings I notice that for some
reasons the ui designers have decide to remove the option "Never" and in
the end I accepted defeat ( or achieved victory over power saving
depending how you look at it ) and unplug one of the lamps in the living
room and plug my adapter in to work around "Power saving" behaviour.
These four bugs I encounter as in three code bugs one design bug or are
these not bugs and are +ACo-working+ACo- as designed?
1.
The screen lock taking place which did not be consistent to what
settings I had in power settings.
2.
The display deciding to dim it self after a period of time that did not
seem consistent to what I had set to in the power settings.
3.
The display deciding to dim it self after an reset the display
brightness setttings after I manually set it ( happens regardless if I
used a key compo to increase it or I did so through application ).
4.
Usability regression or a design bugs as I call them the removal of
"Never" as an option and be stuck with one hour.
In case of what I refer to as bug 1. 2. 3. they are probably all related
to the same problem ( probably X/Kernel bug ) as in there seems to be
some underlying +ACo-intelligent+ACo- that probably is tied in what ever it has
defined as user +ACo-activity+ACo- ( most likely is a key being pressed or the
mouse being moved ) within a defined time frame and when that does not
happen that intelligent decides to +ACo-save power+ACo- and starts doing all
kinds of things to do that like ignoring ( user ) defined settings in Gnome.
Now there are several use cases that you might be doing some task
in/with the laptop without that task involving a mouse being mover or
user pressing a key like reading, having presentation of the device it
self or simply Gnome etc..
In the case of 4 we need to have the ability to turn all "power savings"
off completely. I'm not saying it should be the default far from it a
good power saving policy should be the default but the ability for the
user to do that needs to be in place because you might need to perform
some tasks that require you to utilize all the resource the computer has
cpu etc.. at the cost of saving several minutes of you battery life time.
Now one way to deal with all those various power needs/use cases the
user has when running on battery would be to introduce power managing
profiles where the user could select profile based on a task he's
performing like in my last nigh case I was reading so I would have
chosen the "Reading" power managing profile which would have for example
set the brightness of my screen to max but save power everywhere else
possible and in the case of needing max performance user would just
choose the Performance power management profile which would just turn of
all power savings.
The benefit of having power management profile is that user could simply
just choose amongst predefined profiles for the most common usage
scenario and the configuration part of it could be stuffed
behind/exposed to the user only under creating a custom power management
but you know this just one idea that could be used to solve/satisfy
various power managing tasks for various usage scenarios in a non
complication to much knobs neat way for the end user.
Note that I have not filed a single one of those bug(s) I have mentioned
since I'm not sure these are bugs at all or working as designed. . .
JBG
--------------070102010202030204010508
Content-Type: text/html; charset=UTF-7
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-7" http-equiv="Content-Type">
</head>
<body bgcolor="+ACM-ffffff" text="+ACM-000000">
On 02/08/2011 09:37 PM, James Laska wrote:
<blockquote cite="mid:1297201044.9601.113.camel+AEA-flatline"
type="cite">
<pre wrap="">= Comments +ACY-amp; Discussion Given that GNOME 3 offers a <b class="moz-txt-star"><span class="moz-txt-tag">+ACo-</span>dramatically<span class="moz-txt-tag">+ACo-</span></b> different user experience
than GNOME 2.X, there are going to be plenty of users who are
surprised/disrupted by the changes. As a result, we wanted to start
compiling common questions/workarounds/workflows that have come up so
far. I anticipate referencing these a lot on irc/lists. Perhaps, over
time these migrate into release notes.
</pre>
</blockquote>
<br>
We need to get this list going and keep tabs on bugs filed against
that design decisions and preferable point to upstream
bugs/discussion(s) as Bastien did in respond to me in another thread
on this list since I hit yet another case what I call a
regression/bug but another might call works as designed.<br>
<br>
We had a shitty weather last night which was perfect for me to just
throw myself in the couch in the living room reading a ebook over a
warm cup of coffee before you hit the sack well that did not turn
out so well I spent most of the time battling "power saving"
features since I was running the laptop on battery on my couch in my
living room. <br>
<br>
No matter what I did ( setting the brightness to max ) after I
period of time I either had a screen lock or the display decided to
dim it self again which by the way to not seem to be consistent to
behaviour I set it to and going through the power settings I notice
that for some reasons the ui designers have decide to remove the
option "Never" and in the end I accepted defeat ( or achieved
victory over power saving depending how you look at it ) and unplug
one of the lamps in the living room and plug my adapter in to work
around "Power saving" behaviour.+AKA- <br>
<br>
These four bugs I encounter as in three code bugs one design bug or
are these not bugs and are +ACo-working+ACo- as designed?<br>
<br>
1. <br>
<br>
The screen lock taking place which did not be consistent to what
settings I had in power settings. <br>
<br>
2. <br>
<br>
The display deciding to dim it self after a period of time that did
not seem consistent to what I had set to in the power settings. <br>
<br>
3. <br>
<br>
The display deciding to dim it self after an reset the display
brightness setttings after I manually set it ( happens regardless if
I used a key compo to increase it or I did so through application
).+AKA- <br>
<br>
4.<br>
<br>
Usability regression or a design bugs as I call them the removal of
"Never" as an option and be stuck with one hour.<br>
<br>
In case of what I refer to as bug 1. 2. 3. they are probably all
related to the same problem ( probably X/Kernel bug ) as in there
seems to be some underlying +ACo-intelligent+ACo- that probably is tied in
what ever it has defined as user +ACo-activity+ACo- ( most likely is a key
being pressed or the mouse being moved ) within a defined time frame
and when that does not happen that intelligent decides to +ACo-save
power+ACo- and starts doing all kinds of things to do that like ignoring
( user ) defined settings in Gnome.<br>
<br>
Now there are several use cases that you might be doing some task
in/with the laptop without that task involving a mouse being mover
or user pressing a key like reading, having presentation of the
device it self or simply Gnome etc..<br>
<br>
In the case of 4 we need to have the ability to turn all "power
savings" off completely. I'm not saying it should be the default far
from it a good power saving policy should be the default but the
ability for the user to do that needs to be in place because you
might need to perform some tasks that require you to utilize all the
resource the computer has cpu etc.. at the cost of saving several
minutes of you battery life time.<br>
<br>
Now one way to deal with all those various power needs/use cases the
user has when running on battery would be to introduce power
managing profiles where the user could select profile based on a
task he's+AKA- performing like in my last nigh case I was reading so I
would have chosen the "Reading" power managing profile which would
have for example set the brightness of my screen to max but save
power everywhere else possible and in the case of needing max
performance user would just choose the Performance power management
profile which would just turn of all power savings. <br>
<br>
The benefit of having power management profile is that user could
simply just choose amongst predefined profiles for the most common
usage scenario and the configuration part of it could be stuffed
behind/exposed to the user only under creating a custom power
management but you know this just one idea that could be used to
solve/satisfy various power managing tasks for various usage
scenarios in a non complication to much knobs neat way for the end
user.+AKA- <br>
<br>
Note that I have not filed a single one of those bug(s) I have
mentioned since I'm not sure these are bugs at all or working as
designed. . .<br>
<br>
JBG<br>
</body>
</html>
--------------070102010202030204010508--
--==============&74790273415707913=Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
--==============&74790273415707913==--
which version for intel chipset 64bit
