On Tue, Oct 2, 2018 at 10:02 AM, Justin Forbes <jmforbes(a)linuxtx.org> wrote:
On Tue, Oct 2, 2018 at 10:12 AM, Lennart Poettering
> Can you give examples of other kernel subsystems that are also
> advertised as available by the Fedora kernel, and part of the core
> kernel RPM but are of this "tech preview" kind?
You want things that are potentially buggy and can eat data? How long
have we had btrfs enabled now?
That's silly to the point of nonsense. There's quite a lot of evidence
of hardware bugs as a result of both ZFS and Btrfs catching such
things in the act. That fully checksumming file systems intentionally
face plant by design because they're immediately aware of
inconsistency isn't a bug. I've had zero data eaten on Btrfs, I can't
say the same due to bugs on other file systems or volume managers - on
the same hardware where I know for sure it wasn't hardware instigating
the problem. And this has been confirmed as XFS moved to metadata
checksumming, just how silly some hardware behaves. It's basically the
same dilemma as what's under discussion with hibernation.
We tend to not make recommendations
as to what people choose to use on their own systems, but we
absolutely suggest that desktop environments with a large number of
users not write a bad policy around them. Now people are asking to
cripple the mechanism so that Gnome users can default to poor policy.
Why should non gnome users have to change their systems at all to
accommodate a gnome desktop policy?
I agree with this logic. The user space policy change is premature
given the known state of things, and it's an open question what effort
is being put into this by manufacturers of hardware and at Microsoft -
which is relevant because that's bulk of the hardware market we're
supporting. I guarantee you hibernation isn't working on Macs -
whatever they're doing is not standard ACPI, 100% of the time on every
Mac I've ever tried suspend on, the kernel detects the hibernation
file is corrupt. Whether it's corrupted at the time it's written out
or read in, I have no idea. But Apple's hibernation is not foolproof
either. I see maybe 1 in 10 restore from hibernation fail.
Application state saving on iOS and Android is about as fool proof as
I've ever experienced. And if that's not the way forward, that's fine,
but I don't see how looking backward at suspend to disk is really that
helpful, as a policy. I'd say it's a net failure because it's not
consistent, or reliable enough even on hardware it does often work on.
Both suspend and hibernation have a much higher risk of failure to
complete the cycle: leaving the laptop closed, running, discharging,
and getting hot. Poweroff has almost none of that risk.