On 22/08/2019 00:10, Chris Murphy wrote:
> Anyway, the Fedora Workstation working group has this as an issue
> being explored by a subgroup very soon, and make recommendations back
> to the working group. So there will be a lot more discussion about
> this in the near future.
>
On Wednesday, August 21, 2019 3:10:04 AM MST Ernestas Kulik wrote:
> On Tue, 2019-08-20 at 07:32 -0700, John Harris wrote:
>
> > On Monday, August 19, 2019 2:56:58 PM MST Przemek Klosowski wrote:
> >
> > > the right thing to do is to suspend on inactivity
> > > in all cases.
> >
> >
> > I
On Wednesday, August 21, 2019 1:13:03 PM MST Przemek Klosowski via devel
wrote:
> On 8/20/19 11:15 PM, John Harris wrote:
>
> > There is no significant fire risk from this. It's just not good for the
> > laptop. There's not exactly a temperature range that can cause damage,
> > but
> > there is
On Wed, Aug 21, 2019 at 2:22 PM Przemek Klosowski via devel
wrote:
>I think Fedora should optimize
> for laptops/desktops, so if we had to chose one default I would vote for
> sleep, or shutdown if sleep was not available.
The default could be predicated on systemd chassis attribute.
> but
On 8/20/19 11:15 PM, John Harris wrote:
There is no significant fire risk from this. It's just not good for the
laptop. There's not exactly a temperature range that can cause damage, but
there is a nominal range for each individual chip, and a nominal range for the
entire system based on that.
On Wed, Aug 21, 2019 at 1:35 AM Vitaly Zaitsev via devel
wrote:
>
> On 21.08.2019 4:59, Chris Murphy wrote:
> > The very
> > simple work around for the computer shutting off in 3 minutes of
> > inactivity and you don't like that?
>
> 1. Such unpredicted shutdown can damage headers of
On Wed, Aug 21, 2019 at 09:34:57AM +0200, Vitaly Zaitsev via devel wrote:
> 1. Such unpredicted shutdown can damage headers of LUKS-encrypted volumes.
We're not talking about taking the system out behind the toolshead here.
Is LUKS really so brittle that 'shutdown -h now' is insufficient?
> 2.
On Tue, Aug 20, 2019 at 08:15:21PM -0700, John Harris wrote:
> There is no significant fire risk from this. It's just not good for
> the laptop. There's not exactly a temperature range that can cause
> damage, but there is a nominal range for each individual chip, and a
> nominal range for the
On Tue, 2019-08-20 at 07:32 -0700, John Harris wrote:
> On Monday, August 19, 2019 2:56:58 PM MST Przemek Klosowski wrote:
> > the right thing to do is to suspend on inactivity
> > in all cases.
>
> I don't think it's fair for one person to decide what the "right
> thing to do"
> is. This kind
On 19.08.2019 12:38, Dominique Martinet wrote:
> LCD definitely has this issue - display the same image forever and the
> pixels will remember it / you will be left with an overlay of the
> previously still image.
This is a known IPS displays issue, known as "ghosting". This is not a
burn-in. It
On 21.08.2019 4:59, Chris Murphy wrote:
> The very
> simple work around for the computer shutting off in 3 minutes of
> inactivity and you don't like that?
1. Such unpredicted shutdown can damage headers of LUKS-encrypted volumes.
2. If it will be implemented, it must be an opt-in feature.
--
On Tuesday, August 20, 2019 8:19:24 PM MST Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 9:16 PM John Harris wrote:
>
> >
> >
> > On Tuesday, August 20, 2019 7:45:15 PM MST Chris Murphy wrote:
> >
> > > On Tue, Aug 20, 2019 at 6:38 PM Solomon Peachy
> > > wrote:
> > >
> > >
> > >
> > > >
> > >
On Tuesday, August 20, 2019 7:59:44 PM MST Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 8:37 PM John Harris wrote:
>
> >
> >
> > On Tuesday, August 20, 2019 7:35:05 PM MST Chris Murphy wrote:
> >
> > > On Tue, Aug 20, 2019 at 5:35 PM John Harris
> > > wrote:
> > >
> > >
> > >
> > > >
> > > >
On Tue, Aug 20, 2019 at 9:16 PM John Harris wrote:
>
> On Tuesday, August 20, 2019 7:45:15 PM MST Chris Murphy wrote:
> > On Tue, Aug 20, 2019 at 6:38 PM Solomon Peachy wrote:
> >
> > >
> > >
> > > On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote:
> > >
> > > > Why wouldn't
On Tuesday, August 20, 2019 7:45:15 PM MST Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 6:38 PM Solomon Peachy wrote:
>
> >
> >
> > On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote:
> >
> > > Why wouldn't it be appropriate for a system running on battery power?
> >
> >
> >
On Tue, Aug 20, 2019 at 8:37 PM John Harris wrote:
>
> On Tuesday, August 20, 2019 7:35:05 PM MST Chris Murphy wrote:
> > On Tue, Aug 20, 2019 at 5:35 PM John Harris wrote:
> >
> > >
> > >
> > > I think we can all agree that shutting the system down is not the
> > > appropriate
> behavior,
On Tue, Aug 20, 2019 at 6:38 PM Solomon Peachy wrote:
>
> On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote:
> > Why wouldn't it be appropriate for a system running on battery power?
>
> I've personally had this happen to me several times, where (far more
> improtantly than the
On Tuesday, August 20, 2019 5:34:03 PM MST Alexander Ploumistos wrote:
> On Wed, Aug 21, 2019 at 2:43 AM John Harris wrote:
>
> >
> >
> > On Tuesday, August 20, 2019 2:35:03 AM MST Christophe de Dinechin wrote:
> > […]
> >
> > > On macOS, when full disk encryption is active, there is a
On Tuesday, August 20, 2019 7:35:05 PM MST Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 5:35 PM John Harris wrote:
>
> >
> >
> > I think we can all agree that shutting the system down is not the
> > appropriate
behavior, right?
>
>
> I do not agree at all, even a little bit.
>
> --
> Chris
On Tue, Aug 20, 2019 at 5:35 PM John Harris wrote:
>
> I think we can all agree that shutting the system down is not the appropriate
> behavior, right?
I do not agree at all, even a little bit.
--
Chris Murphy
___
devel mailing list --
On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote:
> Why wouldn't it be appropriate for a system running on battery power?
I've personally had this happen to me several times, where (far more
improtantly than the battery) a laptop tucked into a confined sleeve got
On Wed, Aug 21, 2019 at 2:43 AM John Harris wrote:
>
> On Tuesday, August 20, 2019 2:35:03 AM MST Christophe de Dinechin wrote:
> […]
> > On macOS, when full disk encryption is active, there is a different
> > boot-time login screen. The process is described here:
> >
On Tuesday, August 20, 2019 2:35:03 AM MST Christophe de Dinechin wrote:
> Samuel Sieb writes:
>
>
> > On 8/20/19 1:17 AM, Benjamin Kircher wrote:
> >
> >>> On 20. Aug 2019, at 04:15, Chris Murphy
> >>> wrote:
> >>>
> >>>
> >>>
> >>> I'm not certain it matters, but I'm curious how Windows and
On Tuesday, August 20, 2019 7:54:40 AM MST Przemek Klosowski wrote:
> On 8/20/19 4:31 AM, Samuel Sieb wrote:
> >> At my work, most of the windows laptops have full disk encryption so
> >> I asked a coworker for some info. She started her laptop on battery
> >> and let it sit at the encryption
On Tuesday, August 20, 2019 8:31:27 AM MST Przemek Klosowski via devel wrote:
> On 8/20/19 10:32 AM, John Harris wrote:
>
> > On Monday, August 19, 2019 2:56:58 PM MST Przemek Klosowski wrote:
> >
> >> the right thing to do is to suspend on inactivity in all cases.
> >
> > I don't think it's
On 8/20/19 10:32 AM, John Harris wrote:
On Monday, August 19, 2019 2:56:58 PM MST Przemek Klosowski wrote:
the right thing to do is to suspend on inactivity in all cases.
I don't think it's fair for one person to decide what the "right thing to do"
is. This kind of thinking is what leads to
On 8/20/19 4:31 AM, Samuel Sieb wrote:
At my work, most of the windows laptops have full disk encryption so
I asked a coworker for some info. She started her laptop on battery
and let it sit at the encryption password prompt for about 30 minutes
and nothing happened. She also told me that
On Monday, August 19, 2019 2:56:58 PM MST Przemek Klosowski wrote:
> the right thing to do is to suspend on inactivity
> in all cases.
I don't think it's fair for one person to decide what the "right thing to do"
is. This kind of thinking is what leads to things like GNOME's awful defaults.
On Monday, August 19, 2019 3:42:10 AM MST Artur Iwicki wrote:
> The fact whether we're in the OS or not, whether it's a bootloader or a
> pre-init script or whatever is irrelevant from the end-user perspective.
> The end-user sees that the system will wait the password endlessly and I
> agree with
Samuel Sieb writes:
> On 8/20/19 1:17 AM, Benjamin Kircher wrote:
>>> On 20. Aug 2019, at 04:15, Chris Murphy wrote:
>>>
>>> I'm not certain it matters, but I'm curious how Windows and macOS deal
>>> with this same scenario. I'd be surprised if they just wait forever,
>>> in particular if power
> On 20. Aug 2019, at 10:20, Samuel Sieb wrote:
>
>>> On 20. Aug 2019, at 04:15, Chris Murphy wrote:
>>>
>>> I'm not certain it matters, but I'm curious how Windows and macOS deal
>>> with this same scenario. I'd be surprised if they just wait forever,
>>> in particular if power is
On 8/19/19 8:46 PM, Samuel Sieb wrote:
On 8/19/19 7:15 PM, Chris Murphy wrote:
I'm not certain it matters, but I'm curious how Windows and macOS deal
with this same scenario. I'd be surprised if they just wait forever,
in particular if power is disconnected on laptop.
At my work, most of the
On 8/20/19 1:17 AM, Benjamin Kircher wrote:
On 20. Aug 2019, at 04:15, Chris Murphy wrote:
I'm not certain it matters, but I'm curious how Windows and macOS deal
with this same scenario. I'd be surprised if they just wait forever,
in particular if power is disconnected on laptop.
As for
> On 20. Aug 2019, at 04:15, Chris Murphy wrote:
>
> I'm not certain it matters, but I'm curious how Windows and macOS deal
> with this same scenario. I'd be surprised if they just wait forever,
> in particular if power is disconnected on laptop.
As for macOS, it will shut down the machine
On 8/19/19 7:15 PM, Chris Murphy wrote:
I'm not certain it matters, but I'm curious how Windows and macOS deal
with this same scenario. I'd be surprised if they just wait forever,
in particular if power is disconnected on laptop.
At my work, most of the windows laptops have full disk
On Mon, Aug 19, 2019 at 2:14 PM Samuel Sieb wrote:
>
> On 8/19/19 3:42 AM, Artur Iwicki wrote:
> >> Do you have OLED monitor? Generic LCD/LED monitors does not suffer from
> >> this issue. I never shut down my monitor for years and it works fine.
> > The monitor damage is not the issue here;
On 8/19/19 4:14 PM, Samuel Sieb wrote:
On 8/19/19 3:42 AM, Artur Iwicki wrote:
Do you have OLED monitor? Generic LCD/LED monitors does not suffer
from this issue. I never shut down my monitor for years and it works
fine.
The monitor damage is not the issue here; it's just a possible side
On 8/19/19 3:42 AM, Artur Iwicki wrote:
Do you have OLED monitor? Generic LCD/LED monitors does not suffer from this
issue. I never shut down my monitor for years and it works fine.
The monitor damage is not the issue here; it's just a possible side effect of the issue.
As Chris mentioned
Tomasz Torcz wrote on Mon, Aug 19, 2019 at 04:45:31PM +0200:
> Actually, I don't think systemd touch the kernel default here.
> See consoleblank= parameter
> https://www.kernel.org/doc/html/v5.2/admin-guide/kernel-parameters.html
> Some years ago it was set to be disabled by default, previously
On Sat, Aug 17, 2019 at 05:24:18PM -0700, Joseph D. Wagner wrote:
> Sorry if this is the wrong place to post. I need to start somewhere.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1742953
>
> Description of problem:
> The Plymouth LUKS password prompt will wait FOREVER for me to type in a
>
On Mon, 19 Aug 2019 at 07:36, Dominique Martinet
wrote:
>
> Vitaly Zaitsev via devel wrote on Mon, Aug 19, 2019 at 09:31:33AM +0200:
> > On 19.08.2019 8:18, Joseph D. Wagner wrote:
> > > It is intended to display the same image on the screen continuously
> >
> > Yes. User must enter LUKS password
The fact whether we're in the OS or not, whether it's a bootloader or a
pre-init script or whatever is irrelevant from the end-user perspective. The
end-user sees that the system will wait the password endlessly and I agree with
Joseph that it's not good behaviour.
>Do you have OLED monitor?
Vitaly Zaitsev via devel wrote on Mon, Aug 19, 2019 at 09:31:33AM +0200:
> On 19.08.2019 8:18, Joseph D. Wagner wrote:
> > It is intended to display the same image on the screen continuously
>
> Yes. User must enter LUKS password to continue booting. System cannot be
> booted until all drives
On 19.08.2019 8:18, Joseph D. Wagner wrote:
> It is intended to display the same image on the screen continuously
Yes. User must enter LUKS password to continue booting. System cannot be
booted until all drives from /etc/fstab will be unlocked and
successfully mounted.
Screensaver cannot be
On 2019-08-18 02:57, Vitaly Zaitsev via devel wrote:
On 18.08.2019 2:24, Joseph D. Wagner wrote:
The Plymouth LUKS password prompt will wait FOREVER for me to type in
a
password
This is intended, because system is not even started yet on
LUKS-encrypted media attach stage.
It is intended
On 18.08.2019 2:24, Joseph D. Wagner wrote:
> The Plymouth LUKS password prompt will wait FOREVER for me to type in a
> password
This is intended, because system is not even started yet on
LUKS-encrypted media attach stage.
If you don't want to enter LUKS password on every boot, you should use
On Sat, Aug 17, 2019 at 6:25 PM Joseph D. Wagner
wrote:
>
> Sorry if this is the wrong place to post. I need to start somewhere.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1742953
>
> Description of problem:
> The Plymouth LUKS password prompt will wait FOREVER for me to type in a
>
Sorry if this is the wrong place to post. I need to start somewhere.
https://bugzilla.redhat.com/show_bug.cgi?id=1742953
Description of problem:
The Plymouth LUKS password prompt will wait FOREVER for me to type in a
password without powering down the monitor or blanking the screen. This
leaves
48 matches
Mail list logo
