I asked Hacker News what developers want from a desktop, and this is what they said

I'm really glad you sent this out, Matt, because it hooks into a couple
things I was going to bring up in our other conversation. (Apologies for
not replying to you yet)

I don't think LTS would really fit into Fedora's over all view of being the
first with new features, however a Rolling release is something that I
think we should keep an eye on at all times. Even if we don't explicit
target it / offer it, its a worthwhile goal to have in the back of our
minds just because it ensures consistency of updates and stability. Cheers
to AdamW for his OpenQA work! Rawhide's been pretty stable on my laptop,
even with RPMFusion enabled.

Post by Matthew Miller
* Other improvements to updates (not necessarily upgrades): make them
happen in the background, and provide a way to roll back if something
isn't good. Also this for user tweaks rather than just updates.

A la OpenSuse with Snapper, which hooks into a previous topic: Grubby needs
work if we want to offer rollbacks.

Post by Matthew Miller
* Give the ability to have package X move at a pace I choose. Separate
dev stack from base OS.

Means separate installations of software stacks, and a firmer split between
"This is the pristine state offered by the distro, and this is everything
the user did ontop of it."

Post by Matthew Miller
* Hardware compatibility just works. (Wifi, sound, HDMI, graphics,
suspend, etc.)

Kernel / driver work, getting better every release.

Post by Matthew Miller
* Mixed DPI multi-monitor support.

Thankfully this got sorted out lately, at least under Gnome.

Post by Matthew Miller
* Look nice, better fonts, general usability, etc.

I know we don't have the goal of being "The Windows replacement", but its
worth remembering that being a developer and being an end user are not
mutually exclusive. Every change we make that benefits end users also
benefits developers as well, though not in the same way. Better font
rendering (F24) don't make it easier to cross-compile applications, but
they do improve over all quality of life of developers.

Would it worth it to start polling the community / companies that we know
use RHEL / Fedora, ask them what are some changes that they always make
before deploying it to end users (extensions, tweaks, default apps, etc)
and see what keeps coming up? For example, if every single company or group
that we poll all say "Oh we always install the Dash To Dock extension",
then lets look into shipping Dash To Dock (or getting it integrated
upstream, if we want to stick to upstream) by default, obviously its wanted
functionality, and it would reduce setup time for new installs, plus it
would make Gnome seem a little less alien to new Gnome users, since they
could mentally reference OS X, or Xubuntu, or Unity for how things work.

Post by Matthew Miller
* Cross-distro packaging

Snaps / Flatpaks / AppImage

Post by Matthew Miller
* Containerized GUI apps

Containerized or just sandboxed? Containerized means docker or LXC,
Sandboxed could be the above.

Post by Matthew Miller
--
Matthew Miller
Fedora Project Leader
_______________________________________________

Chris Murphy

2016-10-21 21:14:32 UTC

Post by Eric Griffith

A la OpenSuse with Snapper, which hooks into a previous topic: Grubby needs
work if we want to offer rollbacks.

rpm-ostree does rollbacks. It's more complicated under the hood than
what opensuse is doing, but I think it's easier for the user. And
right now it doesn't use grubby at all, and doesn't require Btrfs.

What openSUSE is doing requires Btrfs, a bunch of GRUB patches to
support Btrfs snapshots which are not upstream, and a bunch of
installer changes. No one within Fedora is working on this.

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to deskt

Peter Robinson

2016-10-22 12:00:29 UTC

Post by Eric Griffith

Post by Matthew Miller
* Hardware compatibility just works. (Wifi, sound, HDMI, graphics,
suspend, etc.)

Kernel / driver work, getting better every release.

Arguably it's not, have you tried to get Linux running on some of the
recent generations of Intel based laptops like a Lenovo Yoga? Even
then if it works we still don't properly support decent power
management in tree on devices pushing two years old[1]. So maybe
getting better as a device gets older but a lot of the newest shiny
that developers actually want the support is somewhere between non
existent and decidedly average!

[1] http://mjg59.dreamwidth.org/42156.html
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedoraproject.o

Ray Strode

2016-10-21 18:55:44 UTC

Hi,

Post by Matthew Miller
* Make upgrades painless.

hopefully solved by rpm-ostree

hopefully solved by a combination of rpm-ostree and flatpak.

Post by Matthew Miller
* Give the ability to have package X move at a pace I choose. Separate
dev stack from base OS.

hopefully solvable by flatpak versioned runtimes

Post by Matthew Miller
* Hardware compatibility just works. (Wifi, sound, HDMI, graphics,
suspend, etc.)

eek.

Post by Matthew Miller
* Mixed DPI multi-monitor support.

hopefully solved by wayland

Post by Matthew Miller
* Look nice, better fonts, general usability, etc.

hopefully solved already?

Post by Matthew Miller
* Cross-distro packaging

flatpak.

Post by Matthew Miller
* Containerized GUI apps

flatpak.

It seems like we're already going in the right direction, modulo hardware
compat, which is just really hard.

I do find it interesting no one talked about out of the box multimedia
support.

--Ray
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to d

Michael Catanzaro

2016-10-21 19:05:09 UTC

Post by Ray Strode
Hi,

Post by Matthew Miller
* Make upgrades painless.

hopefully solved by rpm-ostree

Hopefully solved by GNOME Software. It's really nice that I don't have
to look up command line foo to upgrade anymore, just wait for my
computer to start complaining that there is an upgrade and click a
button.

Post by Ray Strode

Post by Matthew Miller
* Look nice, better fonts, general usability, etc.

hopefully solved already?

I just want to add: it's really cool how much nicer fonts look in F24
than they did in F23. I guess the "better fonts" crowd doesn't realize
how big the difference is, and are just repeating the same old line.

Michael
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@li

Adam Williamson

2016-10-21 19:09:00 UTC

Post by Ray Strode
Hi,

Post by Matthew Miller
* Make upgrades painless.

hopefully solved by rpm-ostree

Lots of people deeply hate the required reboot, though. I mean, they
despise it. You should've seen some of the messages I got around that
whole 'online update crashing X' kerfuffle a couple of weeks back.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an

Adam Williamson

2016-10-21 19:09:43 UTC

Post by Ray Strode
Hi,

Post by Matthew Miller
* Make upgrades painless.

hopefully solved by rpm-ostree

Oh, sorry, I was thinking updates, not upgrades. As you were.

Matthew Miller

2016-10-22 22:51:07 UTC

Post by Adam Williamson
Lots of people deeply hate the required reboot, though. I mean, they
despise it. You should've seen some of the messages I got around that
whole 'online update crashing X' kerfuffle a couple of weeks back.

Oh, sorry, I was thinking updates, not upgrades. As you were.

Well, this was covered by at least one comment as well, which asked for
updates to happen transparently in the background.

Chris Murphy

2016-10-23 05:39:05 UTC

On Sat, Oct 22, 2016 at 4:51 PM, Matthew Miller

Oh, sorry, I was thinking updates, not upgrades. As you were.

Well, this was covered by at least one comment as well, which asked for
updates to happen transparently in the background.

How would it work? It would still yank things out from under the
running environment possibly making the whole system unstable, or
sufficiently confusing for the user that they initiate a reboot in the
middle of the update.

rpm-ostree does its updates out of band, i.e. they're done on an
inactive copy of the root file system, so they could be done in the
background. Even still, this requires a reboot to use the updated
tree. Granted, it's one less reboot than we have now.

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email t

Alexander Bisogiannis

2016-10-23 06:47:00 UTC

Post by Chris Murphy
rpm-ostree does its updates out of band, i.e. they're done on an
inactive copy of the root file system, so they could be done in the
background. Even still, this requires a reboot to use the updated
tree. Granted, it's one less reboot than we have now.

I think what they mean is that the update process itself should not
require rebooting in to this "upgrade mode".

The current method requires two reboots to complete the proccess.
One to boot in "update mode" and another to boot into the updated system.

Abis.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe

Michael Catanzaro

2016-10-23 14:06:22 UTC

This is something that can be fixed down to one reboot with engineering
effort. I believe someone (Stephen?) already has a proof of concept.
This would be good to explore further in the short term.

We've already decided that updates cannot be done safely without at
least one reboot, so let's not bother with requests to remove that. We
now have updates that download in the background, so time required for
that isn't a problem anymore either. But we don't have them applying in
the background yet. Atomic Workstation makes that possible -- then the
update gets applied instantaneously on reboot -- but it might be a
while before Atomic Workstation approaches the usability of normal
Workstation.

Michael
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.

Monty Montgomery

2016-10-23 14:49:48 UTC

Post by Michael Catanzaro
We've already decided that updates cannot be done safely without at
least one reboot, so let's not bother with requests to remove that.

That may be an intentional design decision, but as a result I've
simply stopped installing updates.

Yes, the kernel has traditionally required a reboot, as have power
failures and hardware upgrades. But it seems odd that a reboot is
required for, eg, a GIMP update. (or is that not the case? It has
seemed like everything coming in through Software Update requires
reboots these days. That is my impression, and the impression of many
others, and it may be incorrect.)

Monty
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe se

Eric Griffith

2016-10-23 15:58:39 UTC

Post by Monty Montgomery

Post by Michael Catanzaro
We've already decided that updates cannot be done safely without at
least one reboot, so let's not bother with requests to remove that.

That may be an intentional design decision, but as a result I've
simply stopped installing updates.
Yes, the kernel has traditionally required a reboot, as have power
failures and hardware upgrades. But it seems odd that a reboot is
required for, eg, a GIMP update. (or is that not the case? It has
seemed like everything coming in through Software Update requires
reboots these days. That is my impression, and the impression of many
others, and it may be incorrect.)

It's correct, Monty, any and all updates are handled during a reboot (actually 2). The package manager doesn't have an idea of "This program could simply be restarted, this library isn't currently in use, this package would definitely require a reboot" so it goes with what is guaranteed to work: reboot for everything. It's the safer, though far more annoying, route.

Personally I installed the tracer plugin and just do "dnf update", even on my rawhide system.

Definitely in favor of taking the system from "full desktop" transitioning to "minimal upgrade environment" and then executing the reboot after the upgrade is down. Rather than our current: full desk environment, reboot, minimal upgrade, reboot, full desktop environment.

Hell, not even Windows usually requires two reboots for upgrades.

Michael Catanzaro

2016-10-23 16:42:48 UTC

Post by Monty Montgomery
Yes, the kernel has traditionally required a reboot, as have power
failures and hardware upgrades. But it seems odd that a reboot is
required for, eg, a GIMP update.

This has been discussed repeatedly on devel@, so just to summarize the
end result: the decision is that reboots are required when updating any
RPM package. The reboot requirement can be avoided for desktop
applications by switching to Flatpaks instead.

Michael
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai

Matthew Miller

2016-10-24 12:58:38 UTC

Post by Michael Catanzaro
end result: the decision is that reboots are required when updating any
RPM package. The reboot requirement can be avoided for desktop
applications by switching to Flatpaks instead.

I think that's a fine approach, but in order to do that, we need to get
serious about Flatpacking all of the desktop applications we ship — no
just leaning on it as a technology for third-party apps on Fedora.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai

Stephen Gallagher

2016-10-24 12:21:18 UTC

Post by Alexander Bisogiannis
I think what they mean is that the update process itself should not
require rebooting in to this "upgrade mode".
The current method requires two reboots to complete the proccess.
One to boot in "update mode" and another to boot into the updated system.

This is something that can be fixed down to one reboot with engineering
effort. I believe someone (Stephen?) already has a proof of concept.
This would be good to explore further in the short term.

What I had been experimenting with a few releases ago (F22 or F23, IIRC) was
essentially skipping the first reboot and just doing the equivalent of
`systemctl isolate system-update.target`, running the update and then rebooting
a single time after this.

I got some line noise from people about how the reboot is necessary to guarantee
that the mount state matches a clean boot, but my thoughts on that are:

1) Anyone who is technically competent enough to be modifying their mount table
should be sensible enough to set it back to the right place before upgrading and

2) Who the hell would mess with / and /usr?

To me, this edge case is sufficiently small that I'd be perfectly comfortable
ignoring it in the default case and just having a double-reboot as an optional
choice for anyone that wants to be overly-paranoid.

Just to itemize the issues I had with the double-reboot:

1) System down-time: a lot of servers in the wild have very long POST cycles (I
have a big server under my desk that takes about six minutes to get through
POST). If it has to reboot *twice*, then this is a total of twelve minutes (plus
whatever time the actual update took) of downtime on that machine.

2) Best security practice is for users to have encrypted drives. However, for
end-users, this means that they get stuck having to manually enter their drive
decryption passwords twice during updates (which has the side effect of annoying
them because they can't just hit the "update" button, then go grab a coffee
while the upgrade runs and then enter the password one time when they come back.

As a longer-term change, I'd also like to consider avoiding the post-update
reboot, assuming we ran in the systemd-update.target. We have plugins for DNF
that can detect which updates affected running processes. If we included
something like that in the offline updates processing, we could decide to just
`systemctl isolate default.target` after the update if nothing running was
modified. The end result would be to avoid two reboots entirely (as well as the
POST time that would incur).

Michael Catanzaro

2016-10-24 13:21:10 UTC

It sounds to me like your single-reboot work is worth continuing. We
don't need to support strange edge cases.

Michael
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedorapro

Stephen Gallagher

2016-10-24 15:47:55 UTC

Post by Michael Catanzaro
It sounds to me like your single-reboot work is worth continuing. We
don't need to support strange edge cases.

My remaining concern is this statement from Lennart that I haven't had an
opportunity to understand better:

"However, so far we have quite some concerns about adding this, precisely for
the reason that it pretends to be a reset of everything to the boot-up defaults,
but actually isn't, as a ton of runtime state is retained in /sys and /proc/sys
and other runtime objects."

I don't know what runtime state he's talking about here or whether the risk is
greater than the advantages to avoiding an extra reboot.

Zbigniew Jędrzejewski-Szmek

2016-10-25 15:46:02 UTC

Post by Michael Catanzaro
It sounds to me like your single-reboot work is worth continuing. We
don't need to support strange edge cases.

My remaining concern is this statement from Lennart that I haven't had an
"However, so far we have quite some concerns about adding this, precisely for
the reason that it pretends to be a reset of everything to the boot-up defaults,
but actually isn't, as a ton of runtime state is retained in /sys and /proc/sys
and other runtime objects."
I don't know what runtime state he's talking about here or whether the risk is
greater than the advantages to avoiding an extra reboot.

For example, writing stuff to /proc/sys is not entirely idempotent:
depending on the order, you might get slightly different results. And
of course there's no way to reset the state to kernel defaults.
If a sysctl.d file is removed, that setting will not be "undone" during
an upgrade, until after a reboot. In 99% of cases this doesn't matter.

If we skip the reboot *before* the upgrade, that should be fine.
Skipping the reboot *after* the upgrade is probably not worth the uncertainty.

There's also kexec: with recent kernels kexec does not work for me anymore
(graphics crash). Nevertheless, kexec is something worth considering too:
the state is reset quite thoroughly, and we avoid the potentially very
slow POST.

Zbyszek
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop

Stephen Gallagher

2016-11-03 14:35:02 UTC

Post by Zbigniew JÄdrzejewski-Szmek

Post by Michael Catanzaro
It sounds to me like your single-reboot work is worth continuing. We
don't need to support strange edge cases.

depending on the order, you might get slightly different results. And
of course there's no way to reset the state to kernel defaults.
If a sysctl.d file is removed, that setting will not be "undone" during
an upgrade, until after a reboot. In 99% of cases this doesn't matter.
If we skip the reboot *before* the upgrade, that should be fine.
Skipping the reboot *after* the upgrade is probably not worth the uncertainty.

So, good news! This is in fact already possible to do today, as I just tested.
The following set of commands does exactly this:

```
pkcon refresh force
pkcon update --only-download
pkcon offline-trigger
systemctl isolate system-update.target
```

This all runs in the current boot and will trigger a reboot immediately after
the update completes. All of this should be easily possible to do for
Workstation within GNOME Software if we agree that's easier on the end-user.

For Server, should we provide a couple scripts for simplicity? One for caching
the pending updates and another to trigger the update-and-reboot?

Post by Zbigniew JÄdrzejewski-Szmek
There's also kexec: with recent kernels kexec does not work for me anymore
the state is reset quite thoroughly, and we avoid the potentially very
slow POST.

2.0

Josh Boyer

2016-11-03 16:25:47 UTC

Post by Zbigniew JÄdrzejewski-Szmek
There's also kexec: with recent kernels kexec does not work for me anymore
the state is reset quite thoroughly, and we avoid the potentially very
slow POST.

2.0

What does "2.0" mean?

josh
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-leav

Chris Murphy

2016-11-03 16:31:34 UTC

Post by Stephen Gallagher
So, good news! This is in fact already possible to do today, as I just tested.
```
pkcon refresh force
pkcon update --only-download
pkcon offline-trigger
systemctl isolate system-update.target
```
This all runs in the current boot and will trigger a reboot immediately after
the update completes. All of this should be easily possible to do for
Workstation within GNOME Software if we agree that's easier on the end-user.

Cool. Are the sysfs leak concerns by systemd folks considered minor?
Is there any advantage to running this in an nspawn container if
that's a cleaner environment?

I asked about this on the ostree list and it looks like they're doing
this with bubblewrap, although I can't comment on the qualitative
difference, if any.
https://mail.gnome.org/archives/ostree-list/2016-October/msg00021.html

Post by Zbigniew JÄdrzejewski-Szmek
There's also kexec: with recent kernels kexec does not work for me anymore
the state is reset quite thoroughly, and we avoid the potentially very
slow POST.

2.0

I thought kexec was disabled for this purpose, at least on UEFI Secure
Boot enabled computers?

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to deskto

Stephen Gallagher

2016-11-03 18:03:21 UTC

Cool. Are the sysfs leak concerns by systemd folks considered minor?
Is there any advantage to running this in an nspawn container if
that's a cleaner environment?

Sorry, I think you made some assumptions there that I can't follow. What
advantage would nspawn provide? Would those advantages outweigh the complexity
of dealing with namespacing?

Post by Chris Murphy
I asked about this on the ostree list and it looks like they're doing
this with bubblewrap, although I can't comment on the qualitative
difference, if any.
https://mail.gnome.org/archives/ostree-list/2016-October/msg00021.html

I'm not sure what bubblewrap actually does. Does it provide an isolated
environment for running %post scripts without root privilege? I'm not sure
that's relevant to this discussion.

Post by Zbigniew JÄdrzejewski-Szmek
There's also kexec: with recent kernels kexec does not work for me anymore
the state is reset quite thoroughly, and we avoid the potentially very
slow POST.

2.0

I thought kexec was disabled for this purpose, at least on UEFI Secure
Boot enabled computers?

My "2.0" there was meant to indicate that I'm not personally willing to
investigate that at this time. I see it as more of a "2.0" feature.

Matthew Miller

2016-10-24 12:57:11 UTC

Post by Michael Catanzaro
We've already decided that updates cannot be done safely without at
least one reboot, so let's not bother with requests to remove that. We

I think that's missing some nuance. We've decided that it's very hard
to do safely without a reboot, and currently no one is invested in
making it safer or less hard. We've got a lot of different problems to
solve, so it makes sense to focus on the ones that users really care
about. We've made the call that the current reboot situation combined
with "hey, off the books, you can run dnf update and deal with any
possible problems yourself" is good enough.

If we keep hearing from users that it *isn't* good enough, that the
reboot is causing meaningful user pain — or, "No pain, but I don't ever
update my system" — we should listen rather than "not bother".

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to

Chris Murphy

2016-10-23 18:30:55 UTC

On Sun, Oct 23, 2016 at 12:47 AM, Alexander Bisogiannis

I think this email from Lennart still applies:
https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org/message/GH5WJZGD3O55IBGAM7IOUB4ZAHCHVUSI/

In particular this phrase, "However, so far we have quite some
concerns about adding this, precisely for the reason that it pretends
to be a reset of everything to the boot-up defaults, but actually
isn't, as a ton of runtime state is retained in /sys and /proc/sys and
other runtime objects."

Are /sys and /proc/sys shared with an nspawn container? I wonder if a
sufficiently clean state can exist in an nspawn container based on the
current Fedora base image - and do the update in that container -
instead of rebooting. I think the user still must be logged out while
this update happens though. But at least it'd mean one reboot instead
of two.

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lis

Matthew Miller

2016-10-24 12:49:45 UTC

Post by Adam Williamson
Lots of people deeply hate the required reboot, though. I mean, they

Oh, sorry, I was thinking updates, not upgrades. As you were.

Well, this was covered by at least one comment as well, which asked for
updates to happen transparently in the background.

Well, keep in mind that I asked "what do you want?", not necessarily
"what easy things could we do?". The comment I referred to was:

Background updates – don't prompt me unless it's a breaking change;
do it over night, lunch, any time I'm not actually using the
app/library.

For a lot of updates, we could probably do this reasonably well even
without Flatpak. *With* Flatpak, I think the story becomes a lot
easier.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an e

Martin Bříza

2016-10-25 07:26:10 UTC

Post by Ray Strode

Post by Matthew Miller
* Mixed DPI multi-monitor support.

hopefully solved by wayland

Tested this out of curiosity a few weeks ago and it actually only works
for native Wayland applications if I remember correctly. Definitely not
all applications were scaled. While I understand there's no built-in
support in the other applications, I'd probably expect interpolated
windows. Especially if we (or is that not true?) support only by-integer
scaling.

I also missed the possibility of configuring this like it is on Windows
where you can choose per-monitor scaling as large as you want. This is a
thing that cannot be solved by algorithms - there's a factor of how far
the screen is from my eyes and how good is my eyesight.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedoraproject.o

Chris Murphy

2016-10-21 20:27:06 UTC

On Fri, Oct 21, 2016 at 11:11 AM, Matthew Miller

Post by Matthew Miller
* Hardware compatibility just works. (Wifi, sound, HDMI, graphics,
suspend, etc.)

WiFi is really hit or miss. Macs are a huge miss, using b43 driver
802.11g is the best that gets supported. The proprietary driver is a
pain to thread the needle to get it to work. It's super crappy. I'm
not sure how to make it better. Meanwhile, this HP Spectre I'm using,
WiFi works flawlessly out of the box, yay Intel Wireless I guess.

I think graphics needs a solution for "medium" DPI displays (those in
between low and high). Ideally it'd be something dynamic. Eventually
there will be "higher" DPI displays, they'll need to leverage the same
solution, hence I say make it dynamic. I mentioned this on devel@

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedor

Peter Robinson

2016-10-22 11:55:53 UTC

Post by Matthew Miller
* Hardware compatibility just works. (Wifi, sound, HDMI, graphics,
suspend, etc.)

Although Intel Wireless is not without it's issues, there's been a lot
of issues with it the last few years around 11n and faster support
where to make it stable you basically disable the faster speeds.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@li

Chris Murphy

2016-10-22 19:16:43 UTC

Post by Peter Robinson

Post by Matthew Miller
* Hardware compatibility just works. (Wifi, sound, HDMI, graphics,
suspend, etc.)

Huh, I'll have to test this. At the moment my router uses openwrt
which likewise uses b43 thus lacks 802.11n support; but ddwrt does
support 802.11n so maybe I'll go back to ddwrt now that I have a
laptop that should be able to do 802.11n with the built-in kernel
support.

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedoraproj

Chris Murphy

2016-10-21 21:44:21 UTC

On Fri, Oct 21, 2016 at 11:11 AM, Matthew Miller

Post by Matthew Miller
* Hardware compatibility just works. (Wifi, sound, HDMI, graphics,
suspend, etc.)

Also in the HN thread that came up more than once, and comes up on
users@ and forums often, is power management. This might be a bigger
problem on some hardware than others. My Macs are always hot and run
fans even when idle - I suspect the GPU runs in a non-idle state by
default - and also results in awful battery life.

Meanwhile the HP Spectre so far I'm getting at least 5 hours active
work, and if Firefox or Chrome aren't running, I can get 9 hours -
without powertop, and looks like a couple hours more with it but it's
still early testing. However, with kernel 4.8.x, suspend to ram isn't
working, where it does with 4.7.x, so that'd be a regression, and
rather a bitter pill of one too, even if it's narrow in scope.

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedorap

Liam

2016-10-24 21:46:34 UTC

Post by Chris Murphy
On Fri, Oct 21, 2016 at 11:11 AM, Matthew Miller

Post by Matthew Miller
* Hardware compatibility just works. (Wifi, sound, HDMI, graphics,
suspend, etc.)

Also in the HN thread that came up more than once, and comes up on
problem on some hardware than others. My Macs are always hot and run
fans even when idle - I suspect the GPU runs in a non-idle state by
default - and also results in awful battery life.

<SNIP>

Owen Taylor blogged about a few things that would be of use here (at least
as far as GNOME apps go).

https://blog.fishsoup.net/2014/10/23/perf-gnome-org-introduction/

This discusses some perf tests run as part of CI.

https://blog.fishsoup.net/2015/01/15/gnome-battery-bench/

This is a standalone gui that offers a few different battery tests (one is
opening a browser to a page(Google, iirc), another creates a simple text
doc using gedit, and lastly (again, iirc) there is the baseline test which
just measures idle power at the desktop for a fixed period). I believe he
mentioned that he wanted to include those battery tests as part of the
GNOME CI.

I'm not sure how extensible this app is, and I'm pretty sure this is
targeting X only libraries, but it would seem to point a way forward.

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Power_profiling_overview

On the Firefox side they've a page that addresses this issue and offer a
few solutions (at one point, perhaps they still do, they regularly ran
tests to check for power use).

I'll also mention that osx includes a panel, in the system monitor app,
that will last and blame apps based on energy use. In the same app osx also
offers a sysprof-like tool that allows you to see what calls are happening
(since I'd imagine that it's using dtrace it may offer a great deal more
than that but I've not dug into it).
So, this might be a way to play the bar for users who are experiencing
issues to provide devs with some rather more actionable data than "my
computer is running weird/hot/slowly/away_from_me".

Best/Liam

Chris Murphy

2016-10-26 16:54:09 UTC

Post by Liam
Owen Taylor blogged about a few things that would be of use here (at least
as far as GNOME apps go).
https://blog.fishsoup.net/2014/10/23/perf-gnome-org-introduction/
This discusses some perf tests run as part of CI.

I'd like to know, even if it's an informal survey, what percent of
Fedora developers (and separately, users), are using a laptop. This
perf tests mention desktop hardware. Yesterday on #fedora-kernel I
learned upstream isn't doing much laptop testing. So at the moment it
sounds like to me a bulk of the laptop testing happens once something
goes in updates-testing.

Post by Liam
https://blog.fishsoup.net/2015/01/15/gnome-battery-bench/

It'd be neat if it were possible to cross reference performance
regressions with packages, and somehow opt into getting a slower
release of packages with a higher performance regression rate. Sort of
a performance regression trustworthiness measure.

Separate, but related, I think it's currently a problem for rpm-ostree
which doesn't permit a decoupling between a current tree and the
kernel, for example. It's all or nothing. If there's a 4 month period
where I need to use an older or newer kernel than what's in the
current release ostree deployments, I can't do that using Fedora's
sources. I'd have to setup my own ostree server to get around it.

I'm really concerned about regressions where laptops don't power off
or suspend when the lid is closed. This has come up before, I've read
about it on various lists, but only recently have I experienced it
myself. And I don't know how to get more resources for this but it
seems like to me the laptop and CPU manufacturer should have more
stake and resources in this than they do, and do more testing so
there's an early warning sign before someone ends up with a smoldering
backpack on an airplane.

Post by Liam
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Power_profiling_overview
On the Firefox side they've a page that addresses this issue and offer a few
solutions (at one point, perhaps they still do, they regularly ran tests to
check for power use).
I'll also mention that osx includes a panel, in the system monitor app, that
will last and blame apps based on energy use. In the same app osx also
offers a sysprof-like tool that allows you to see what calls are happening
(since I'd imagine that it's using dtrace it may offer a great deal more
than that but I've not dug into it).

Yea it's neat. It blames services too, not just user visible programs.
If you run any web browser though, that will far and away exceed
almost anything else other than a compiling, rasterizing, or anything
video.

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedoraproje

Liam

2016-10-28 04:15:03 UTC

Post by Liam
Owen Taylor blogged about a few things that would be of use here (at

least

Post by Liam
as far as GNOME apps go).
https://blog.fishsoup.net/2014/10/23/perf-gnome-org-introduction/
This discusses some perf tests run as part of CI.

Post by Liam
https://blog.fishsoup.net/2015/01/15/gnome-battery-bench/

It'd be neat if it were possible to cross reference performance
regressions with packages, and somehow opt into getting a slower
release of packages with a higher performance regression rate. Sort of
a performance regression trustworthiness measure.
Separate, but related, I think it's currently a problem for rpm-ostree
which doesn't permit a decoupling between a current tree and the
kernel, for example. It's all or nothing. If there's a 4 month period
where I need to use an older or newer kernel than what's in the
current release ostree deployments, I can't do that using Fedora's
sources. I'd have to setup my own ostree server to get around it.
I'm really concerned about regressions where laptops don't power off
or suspend when the lid is closed. This has come up before, I've read
about it on various lists, but only recently have I experienced it
myself. And I don't know how to get more resources for this but it
seems like to me the laptop and CPU manufacturer should have more
stake and resources in this than they do, and do more testing so
there's an early warning sign before someone ends up with a smoldering
backpack on an airplane.

Yeah, I've mentioned that issue to you (well, more about my laptop not
resuming than it going note7).
Btw, there's supposed to be a couple of trips that sounds very triggered if
the package exceeds a certain temp. One is called prochot and the other is
thermtrip. I'd expect the battery would also include some similar features,
as should the motherboard, but I've not found any reference to them.

Post by Chris Murphy
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Power_profiling_overview

Post by Liam
On the Firefox side they've a page that addresses this issue and offer a

few

Post by Liam
solutions (at one point, perhaps they still do, they regularly ran tests

Post by Liam
check for power use).
I'll also mention that osx includes a panel, in the system monitor app,

that

Post by Liam
will last and blame apps based on energy use. In the same app osx also
offers a sysprof-like tool that allows you to see what calls are

happening

Post by Liam
(since I'd imagine that it's using dtrace it may offer a great deal more
than that but I've not dug into it).

Yes, but it's something that would make it easier for a user to quickly
narrow down problems. That was really my point (obviously poorly phrased).
It also might be useful to show the user CPU and package states (parsed for
the user, if need be, to something like ludicrous speed, or even PLAID,
when you'd normally expect lightspeed---whatever, just as long as it's
clear where on the scale they are) as that's a great way to determine how
well their system is doing since Joules are basically meaningless without
reference to their system's baseline (which their installation of Fedora
may never approach).

Alex G.S.

2016-11-04 01:59:47 UTC

On the other things: the GUI we have (GNOME, for Fedora Workstation) has

really settled down in core design from how it was a few years ago, with
more room for the polish you're looking for. (Despite the *superficial
appearance as a tablet interface*, GNOME is actually pretty awesome from
the keyboard, and I actually think of it as a keyboard-primary UI, at least
for how _I_ use it.

GNOME has made impressive technological leaps forward but the shell design
and desktop workflow model haven't advanced at the same pace. What if
Fedora Workstation had a unique desktop shell like Elementary OS and
Ubuntu's Unity? Maybe something more traditional like the macOS desktop
environment that had similar concepts but built with GNOME technology and
Wayland. Sometimes superficial appearances are a much bigger factor than we
like to acknowledge in the success of platforms.

It's amazing that macOS a technologically backward platform has managed to
attract a large following among the engineering community because of it's
great desktop environment.

There's also iTerm2 [1] and I would love to see GNOME Terminal have that
kind of look and feel and functionality.

Regards,
Alex G.S.

[1] https://www.iterm2.com/features.html

Post by Liam
https://blog.fishsoup.net/2015/01/15/gnome-battery-bench/

It'd be neat if it were possible to cross reference performance
regressions with packages, and somehow opt into getting a slower
release of packages with a higher performance regression rate. Sort of
a performance regression trustworthiness measure.
Separate, but related, I think it's currently a problem for rpm-ostree
which doesn't permit a decoupling between a current tree and the
kernel, for example. It's all or nothing. If there's a 4 month period
where I need to use an older or newer kernel than what's in the
current release ostree deployments, I can't do that using Fedora's
sources. I'd have to setup my own ostree server to get around it.
I'm really concerned about regressions where laptops don't power off
or suspend when the lid is closed. This has come up before, I've read
about it on various lists, but only recently have I experienced it
myself. And I don't know how to get more resources for this but it
seems like to me the laptop and CPU manufacturer should have more
stake and resources in this than they do, and do more testing so
there's an early warning sign before someone ends up with a smoldering
backpack on an airplane.

Yeah, I've mentioned that issue to you (well, more about my laptop not

resuming than it going note7).

Btw, there's supposed to be a couple of trips that sounds very triggered

if the package exceeds a certain temp. One is called prochot and the other
is thermtrip. I'd expect the battery would also include some similar
features, as should the motherboard, but I've not found any reference to
them.

Post by Liam
https://developer.mozilla.org/en-US/docs/Mozilla/

Performance/Power_profiling_overview

Post by Liam
On the Firefox side they've a page that addresses this issue and offer a few
solutions (at one point, perhaps they still do, they regularly ran tests to
check for power use).
I'll also mention that osx includes a panel, in the system monitor app, that
will last and blame apps based on energy use. In the same app osx also
offers a sysprof-like tool that allows you to see what calls are happening
(since I'd imagine that it's using dtrace it may offer a great deal more
than that but I've not dug into it).

Yes, but it's something that would make it easier for a user to quickly

narrow down problems. That was really my point (obviously poorly phrased).

It also might be useful to show the user CPU and package states (parsed

for the user, if need be, to something like ludicrous speed, or even PLAID,
when you'd normally expect lightspeed---whatever, just as long as it's
clear where on the scale they are) as that's a great way to determine how
well their system is doing since Joules are basically meaningless without
reference to their system's baseline (which their installation of Fedora
may never approach).

_______________________________________________

Chris Murphy

2016-11-04 03:30:40 UTC

Post by Alex G.S.
GNOME has made impressive technological leaps forward but the shell design
and desktop workflow model haven't advanced at the same pace. What if Fedora
Workstation had a unique desktop shell like Elementary OS and Ubuntu's
Unity? Maybe something more traditional like the macOS desktop environment
that had similar concepts but built with GNOME technology and Wayland.
Sometimes superficial appearances are a much bigger factor than we like to
acknowledge in the success of platforms.
It's amazing that macOS a technologically backward platform has managed to
attract a large following among the engineering community because of it's
great desktop environment.

There's not much innovation happening in UI/Ux on macOS or Windows.
They've largely succeeded by catering to developers, making them want
to develop on the platform, while limiting how annoyed they make users
at each iteration. On Windows, they tried to move to a new UI, and it
just made their users and developers mad - there had been so much
stagnation for so long that the sorely needed changes happened all at
once. Apple does something that irks many users with every year's
release, but in a couple months the users are eating the new dog food,
and developers also.

I think nothing is gained by shifting away from GNOME. It'd hurt the
GNOME effort, and it'd hurt Fedora users.

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an ema

Liam

2016-11-04 05:42:50 UTC

Post by Alex G.S.
On the other things: the GUI we have (GNOME, for Fedora Workstation) has
really settled down in core design from how it was a few years ago, with
more room for the polish you're looking for. (Despite the *superficial
appearance as a tablet interface*, GNOME is actually pretty awesome from
the keyboard, and I actually think of it as a keyboard-primary UI, at least
for how _I_ use it.
GNOME has made impressive technological leaps forward but the shell design
and desktop workflow model haven't advanced at the same pace. What if
Fedora Workstation had a unique desktop shell like Elementary OS and
Ubuntu's Unity? Maybe something more traditional like the macOS desktop
environment that had similar concepts but built with GNOME technology and
Wayland. Sometimes superficial appearances are a much bigger factor than we
like to acknowledge in the success of platforms.
It's amazing that macOS a technologically backward platform has managed to
attract a large following among the engineering community because of it's
great desktop environment.

It's not really that surprising. Osx is really good, and has well designed
subsystems that allow developers to actually achieve their designs. Their
toolkit is also absolutely first class (though not quite the same thing,
I've been impressed with some of the recent work that always to be turning
gtk+ into a truly modern toolkit).
The osx shell, while "pretty" is actually really powerful and they expose a
great deal more functionality than, for instance, GNOME, all while not
having to drop into terminal.
Frankly, I've never understood why people think osx is, overall,
technically inferior, especially for the desktop user. For example, while
osx doesn't have proper asynchronous kernel support (and neither does
Linux, incidentally) they've provided a nice solution that can mimic it
more effectively than what you typically see on Linux DE's. This is because
mac programmers are able to count on excellent frameworks/libraries (in
this case, gcd) that let them more easily achieve something that certainly
can be done on, say, Linux, but requires a lot more stack knowledge.
Now, why should a desktop user (say, a developer/engineer/scientist) move
to Linux? Will it let them do their work more quickly (or easily)? Does it
support more of the applications they need and provide seamless support for
sharing arbitrary information to their colleagues (without having to
context switch to email, or the like)? Is it even more enjoyable to use
(much tougher to say, but I've been really impressed with how nice osx is
after having been so often told that "it's pretty but vacuous"---i don't
know that I could've been more shocked when I found out how wrong that
was)?
Personally, this whole thing looks to be part of the cyclic existential
crisis that the community goes through. Lots of talk happens, even
sometimes plans are made, but next year you find yourself immersed in this
same conversation.
There are some pretty obvious changes that might help but shibboleths
aren't usually part of these discussions within the community.

Michael Stahl

2016-11-04 09:11:24 UTC

Post by Liam
Frankly, I've never understood why people think osx is, overall,
technically inferior, especially for the desktop user. For example,

Liam

2016-11-05 05:45:15 UTC

Post by Liam
Frankly, I've never understood why people think osx is, overall,
technically inferior, especially for the desktop user. For example,

it depends on what part of the stack you look at: the high level desktop
stuff is very good, but the POSIX implementation is horribly buggy,
basic things like poll(2) may not actually work, with different bugs in
different releases:

https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/

so developers that write low-level portable software tend to hate macOS,
while other developers who write non-portable desktop apps tend to love it.

They're less concerned about people writing portable code than having to
implement, arguably, poor crossplatform standards (YAYS! everyone get the
to enjoy the same, suboptimal experience!). So, like the above blog
mentions, they have a rather neglected poll and instead, simliar to NT,
want people to use "their" event monitors (kqueue,iocp,epoll). Now, iocp is
quite different, and harder to support, but even then we have helpers like
libevent or libuv.
I'm thinking about iokit (on the very lowest level) and the various core
services that allow mac to have such fantastic apps (and happy devs).

Alexander Bisogianis

2016-11-05 07:33:33 UTC

Post by Liam
They're less concerned about people writing portable code than having to
implement, arguably, poor crossplatform standards (YAYS! everyone get
the to enjoy the same, suboptimal experience!). So, like the above blog
mentions, they have a rather neglected poll and instead, simliar to NT,
want people to use "their" event monitors (kqueue,iocp,epoll). Now, iocp
is quite different, and harder to support, but even then we have helpers
like libevent or libuv.
I'm thinking about iokit (on the very lowest level) and the various core
services that allow mac to have such fantastic apps (and happy devs).

The issue is more fundamental than just implementing "kits".
An operating system has to decide if it is made to be a desktop, a
server, a mobile device OS etc.

Most of the server oriented software is available in all *NIX platforms,
because portability and choice is more valuable than leveraging specific
OS features. The way that server software-houses do business, forces
then to use "standards", most de facto, but standards nonetheless.

Fedora, and by extension RHEL, have to decide if they want to be a
desktop OS, a server OS or say a mobile OS. (not a distro, this is a
bailout IMO).
Pretending to be both server and desktop does not lead anywhere.

In my (really) humble opinion. :)
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email

Matthew Miller

2016-11-07 13:42:46 UTC

Post by Alexander Bisogianis
Fedora, and by extension RHEL, have to decide if they want to be a
desktop OS, a server OS or say a mobile OS. (not a distro, this is a
bailout IMO).
Pretending to be both server and desktop does not lead anywhere.

Sure. And we're not -- this is why we have separate editions.

Alexander Bisogianis

2016-11-07 13:56:35 UTC

Post by Matthew Miller
Sure. And we're not -- this is why we have separate editions.

Agreed, but this is a very recent development, Fedora 21 was the first
to provide editions, if I am not mistaken.

There should be a clear distinction between what the base OS is and what
the applications that run on top of it are. Not for technical reasons so
much, but for "branding" reasons mainly.

One step at a time :)

Thanks for building a great OS.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@list

Matthew Miller

2016-11-07 14:04:00 UTC

Post by Alexander Bisogianis
Agreed, but this is a very recent development, Fedora 21 was the
first to provide editions, if I am not mistaken.

That doesn't feel recent to me, but maybe I'm living on an accelerated
timeframe. :)

Post by Alexander Bisogianis
There should be a clear distinction between what the base OS is and
what the applications that run on top of it are. Not for technical
reasons so much, but for "branding" reasons mainly.

We're actually working on that, too, wih the Modularity initiative. On
the desktop side of things, the rough plan is to start shipping some
"application modules" as flatpaks.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to de

Peter Robinson

2016-11-07 14:34:42 UTC

Post by Alexander Bisogianis
Agreed, but this is a very recent development, Fedora 21 was the
first to provide editions, if I am not mistaken.

That doesn't feel recent to me, but maybe I'm living on an accelerated
timeframe. :)

Two years ago, plus a year of implementation (F-20 -> 21 was a year)
plus the planning prior... I personally don't call that recent either.

We're actually working on that, too, wih the Modularity initiative. On
the desktop side of things, the rough plan is to start shipping some
"application modules" as flatpaks.
--
Matthew Miller
Fedora Project Leader
_______________________________________________

_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedorapro

Alexander Bisogianis

2016-11-07 14:43:32 UTC

Post by Peter Robinson
Two years ago, plus a year of implementation (F-20 -> 21 was a year)
plus the planning prior... I personally don't call that recent either.

I meant how long has Fedora been released in the wild with editions, not
the long internal preparation.
Fedora has a looong history, so three releases (two years) is recent.

:)
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-

Liam

2016-11-07 21:19:24 UTC

The issue is more fundamental than just implementing "kits".

I probably should've capitalized Core to make it clear that I'm speaking of
the, well, some of it is middleware, some strides from userspace to the
drivers, but the exact implementation isn't the point, imho, but that they
provide an coherent interface for developers to do their work. Some of
those things just aren't possible with a generic kernel, but, again, that's
not the whole story.

An operating system has to decide if it is made to be a desktop, a
server, a mobile device OS etc.

This is an excellent point. I happened to be reading something from the
architect of coreaudio and he related, basically, the point you just did.
To paraphrase: if you want glitch-free audio [they did, because they wanted
to keep the media creators by designing the best audio stack] you have to
design the entire os within that in mind. This happened with osx, and led
to some interesting design decisions, but the point was that they knew what
they wanted to achieve.
If we want a desktop system like osx we need to look at this from the
kernel up, and no, it's not an easy thing to do or as fun as some other
exercises (creating another calculator/ToDo/web browser/whatever, and i
completely realize those aren't necessary areas of overlap, but there are
apps, and APIs, that Fedora could helping to create that would move us in
the direction of being more desktop appropriate), but we've been cribbing
off osx for awhile (no bad thing, btw) and not in a way that takes the
whole into consideration. The systemd folks are doing fantastic work, and
"we" should be working with them to hammer out the minimum set of
functionality and interfaces that would be required of a MODERN desktop.
Iow, a new shell isn't adequate. You can do as much work with GNOME shell
as fvwm, so I care less about how these things look (within reason) than
what possibilities they open for developers, and thus users. but if
developers aren't

Most of the server oriented software is available in all *NIX platforms,
because portability and choice is more valuable than leveraging specific
OS features. The way that server software-houses do business, forces
then to use "standards", most de facto, but standards nonetheless.

Fedora, and by extension RHEL, have to decide if they want to be a
desktop OS, a server OS or say a mobile OS. (not a distro,

this is a
bailout IMO).
Pretending to be both server and desktop does not lead anywhere.

In my (really) humble opinion. :)

We don't need to decide because there's a separate Fedora image for
servers, and one for the cloud (and, possible, one did IoT). The issue is
that except for a bit of a package delta a with server, Workstation hasn't
really taken advantage of the freedom we've been given.

Chris Murphy

2016-11-07 21:30:52 UTC

Post by Liam

Post by Alexander Bisogianis
An operating system has to decide if it is made to be a desktop, a
server, a mobile device OS etc.

This is an excellent point. I happened to be reading something from the
architect of coreaudio and he related, basically, the point you just did. To
paraphrase: if you want glitch-free audio [they did, because they wanted to
keep the media creators by designing the best audio stack] you have to
design the entire os within that in mind. This happened with osx, and led to
some interesting design decisions, but the point was that they knew what
they wanted to achieve.

By extension, I think a while ago but certainly in 2016, Fedora needs
more emphasis on laptop support and workflow than is currently the
case; the switchable graphics support feature for Fedora 25/26 is a
good example of pushing things forward. But there remains no release
criteria on anything power management related like suspend or
hibernate - no meaningful alternative to hibernation like DE stateful
saving and restore - and no line in the sand on what kinds of
regressions aren't OK.

A considerable reason why any developer with a laptop would pick
Windows or macOS these days is because power management is so much
better, that it's even considered basic. There is no such thing as a
suspend regression bug on macOS - I've never even heard of such a
thing let alone encountered it. Hibernation is a bit trickier, I have
experienced some bugs there to the degree I think it's best avoided.
And for the most part Apple saves application state on logout now,
with most of the apps I care about opting into to having their state
saved as well including all unsaved documents.

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to deskto

Adam Williamson

2016-11-08 00:37:44 UTC

Post by Chris Murphy
A considerable reason why any developer with a laptop would pick
Windows or macOS these days is because power management is so much
better, that it's even considered basic. There is no such thing as a
suspend regression bug on macOS - I've never even heard of such a
thing let alone encountered it.

I think you're kind of overselling this because you happened to run
into a suspend regression this cycle. I've been suspending two laptops
and a desktop (with two displays) for the last, like, six years without
significant issues. When I ran into an issue with Rawhide it got fixed
pretty fast. It's really not that awful.

Of course Apple has fewer hardware-related bugs to deal with. We all
know the reasons for that. Even if we blocked on suspend,
realistically, it wouldn't magically prevent hardware-dependent issues
with suspend. We still wouldn't magically be testing on all hardware,
or be any more predisposed to block on a suspend issue on a specific
device even if we happened to find it. Your system-specific regression
would not be a blocker even if we added suspend in general to the
release criteria and committed to the development resources necessary
to fix major issues in it.

Chris Murphy

2016-11-08 06:14:55 UTC

On Mon, Nov 7, 2016 at 4:37 PM, Adam Williamson

In the 4.7 cycle a bunch of Fedora 24 folks got hit with a hibernation
regression. I don't know which part you think I'm selling let alone
over selling. This isn't limited to suspend or hibernation bugs, but
all sorts of other optimizations to get better battery life. I'm in
fact not experiencing a battery life problem on this new HP, but on
the Mac I do, and I know plenty of people who have crummy battery life
running Fedora compared to Windows. So this isn't just about a
singular regression - which Intel folks have picked up on the
upstream bug I filed and we're doing a back and forth so hopefully
it'll get sorted soon.

Post by Adam Williamson
Of course Apple has fewer hardware-related bugs to deal with. We all
know the reasons for that.

The singular reason from which all other stem is that power management
on laptops is a priority to them.

Post by Adam Williamson
Even if we blocked on suspend,
realistically, it wouldn't magically prevent hardware-dependent issues
with suspend. We still wouldn't magically be testing on all hardware,
or be any more predisposed to block on a suspend issue on a specific
device even if we happened to find it. Your system-specific regression
would not be a blocker even if we added suspend in general to the
release criteria and committed to the development resources necessary
to fix major issues in it.

This isn't just about Fedora bringing some things to the table to make
power management better; it's a question whether and how to get
upstream more interested in it, and my reasoning for suggesting they
aren't is when my particular regression came up I was surprised to
learn from the Fedora kernel team that laptops don't get much upstream
testing. If they aren't looking for such regressions, they will not be
found early on. When they're looking for particular regressions, they
are found early on. Not rocket science. This responsibility also lies
with hardware manufacturers, but how can the testing and reporting be
made easier, as in, more automated?

--
Chris Murphy
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedo

Josh Boyer

2016-11-08 12:45:22 UTC

Post by Chris Murphy
On Mon, Nov 7, 2016 at 4:37 PM, Adam Williamson

It would be interesting to know what hardware they have and workloads
they are using that are similar between Linux and Windows. The Fedora
kernel team did some battery life investigations between the two on
identical hardware and found the differences to be negligible. The
biggest finding is that streaming video (hangouts, skype, etc) was
terrible on battery life universally.

Every time I talk to someone about battery life on Linux vs. Windows
it turns out they aren't even comparing similar hardware. Or if they
are, they're comparing completely dissimilar workloads (e.g. compiling
a ton of stuff while it is running Linux, basically using Chrome to
look at the internet in Windows). Please note I am not saying you are
incorrect. I am simply pointing out that statements like that without
quantifiable data do nothing other than spread misconception.

Post by Chris Murphy
singular regression - which Intel folks have picked up on the
upstream bug I filed and we're doing a back and forth so hopefully
it'll get sorted soon.

Post by Adam Williamson
Of course Apple has fewer hardware-related bugs to deal with. We all
know the reasons for that.

The singular reason from which all other stem is that power management
on laptops is a priority to them.

And they have the documentation and hardware engineers accessible to
them to do it.

The models the upstream developers use get testing. They don't go out
of their way to test the very large variety of hardware (which implies
a variety of firmware, which is important) out there. At LPC last
week, I saw a lot of XPS 13 machines, new macbooks (at least 1/2 of
which were running OS X), and Thinkpads. Anything outside of that
gets into the weeds.

Post by Chris Murphy
found early on. When they're looking for particular regressions, they
are found early on. Not rocket science. This responsibility also lies
with hardware manufacturers, but how can the testing and reporting be
made easier, as in, more automated?

Reporting is not the problem. We get tons of reports. It's
recreating the problem, on the workload the user has, on the same
hardware. It's about access and data, not reporting.

josh
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedoraproject.or

Peter Robinson

2016-11-08 12:54:34 UTC

Post by Josh Boyer

It would be interesting to know what hardware they have and workloads
they are using that are similar between Linux and Windows. The Fedora
kernel team did some battery life investigations between the two on
identical hardware and found the differences to be negligible. The
biggest finding is that streaming video (hangouts, skype, etc) was
terrible on battery life universally.
Every time I talk to someone about battery life on Linux vs. Windows
it turns out they aren't even comparing similar hardware. Or if they
are, they're comparing completely dissimilar workloads (e.g. compiling
a ton of stuff while it is running Linux, basically using Chrome to
look at the internet in Windows). Please note I am not saying you are
incorrect. I am simply pointing out that statements like that without
quantifiable data do nothing other than spread misconception.

Post by Chris Murphy
singular regression - which Intel folks have picked up on the
upstream bug I filed and we're doing a back and forth so hopefully
it'll get sorted soon.

Post by Adam Williamson
Of course Apple has fewer hardware-related bugs to deal with. We all
know the reasons for that.

The singular reason from which all other stem is that power management
on laptops is a priority to them.

And they have the documentation and hardware engineers accessible to
them to do it.

One of the biggest improvements I've seen on my Lenovo Carbon G3 is
adding mjg's "SATA link power management" patch series [1] which added
an hour plus for me in some cases. I use to do it with each new kernel
up to 4.6 or so but ultimately got sick of building yet another
kernel. I know his reasons for not heralding them upstream but given
the improvement on the generations of laptop you mention there I'm
kind of surprised someone hasn't picked up the mantle to get them
upstream.

Peter

[1] https://github.com/mjg59/linux/commits/sata-lpm-firmware
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-leav

Bastien Nocera

2016-11-08 12:59:17 UTC

----- Original Message -----
<snip>

Post by Josh Boyer
Every time I talk to someone about battery life on Linux vs. Windows
it turns out they aren't even comparing similar hardware. Or if they
are, they're comparing completely dissimilar workloads (e.g. compiling
a ton of stuff while it is running Linux, basically using Chrome to
look at the internet in Windows). Please note I am not saying you are
incorrect. I am simply pointing out that statements like that without
quantifiable data do nothing other than spread misconception.

Mind, it's not all the kernel's fault. libva/vdpau support for GPUs
aren't shipped with Fedora proper, and when it's installed, GStreamer/
clutter-gst bugs keep breaking support in Videos, when it's not simply
unsupported (in Wayland).

The latter parts are all being worked on, but as long as it's an optional
third-party download, we won't be seeing the improvements any time soon.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedorapr

Peter Robinson

2016-11-08 13:03:08 UTC

Mind, it's not all the kernel's fault. libva/vdpau support for GPUs
aren't shipped with Fedora proper, and when it's installed, GStreamer/
clutter-gst bugs keep breaking support in Videos, when it's not simply
unsupported (in Wayland).
The latter parts are all being worked on, but as long as it's an optional
third-party download, we won't be seeing the improvements any time soon.

Well the reason it's not included is due to legal/patent issues so
it's no different than all the other codec patent issues we already
have in that regard.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to de

Bastien Nocera

2016-11-08 13:49:51 UTC

----- Original Message -----

Post by Peter Robinson

Mind, it's not all the kernel's fault. libva/vdpau support for GPUs
aren't shipped with Fedora proper, and when it's installed, GStreamer/
clutter-gst bugs keep breaking support in Videos, when it's not simply
unsupported (in Wayland).
The latter parts are all being worked on, but as long as it's an optional
third-party download, we won't be seeing the improvements any time soon.

Well the reason it's not included is due to legal/patent issues so
it's no different than all the other codec patent issues we already
have in that regard.

Which we're working towards solving/working around. Those aren't any different.

(16 year veteran of the codecs patents skirmishes)
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedorapr

Alexander Bisogianis

2016-11-07 22:06:55 UTC

Post by Alexander Bisogianis
The issue
is that except for a bit of a package delta a with server, Workstation
hasn't really taken advantage of the freedom we've been given.

First of all, I feel a bit bad judging about other people's work.
Please do not receive the below as anything else but honest criticism.

Let me get out of the way this:

My opinion is that out of all the OSS/Libre operating systems out there,
the only one specifically created for *desktop* computing is Haiku.

Below are a couple of examples, which tie in to the discussion about
"bootloaders" in this thread:

- The boot experience is perfect. No switching to console, no twitching
no nothing. You see some icons light up, which double as progress bar
and information on the boot process (for those that care).

- Is your system is unbootable for *any* reason? No worries. Boot form
USB/CD, hold *Space" and you are presented with all Haiku *boot* (i.e.
root) volumes. Choose one and boot. End of troubleshooting. You can also
boot form USB/CD and access your files, of course. You also get a nice
list of failsafe graphics modes, if you have graphics issues.

The above work-flow, while probably possible to implement, is no where
near to what is really provided by any distro out there.

Please understand that my intention is not to judge negatively the hard
work of others, but to help make fedora a better OS.

As per Liam's post, Haiku has the notion of "kits", exactly like MacOSX,
because BeOS had them and MacOSX was inspired by it, in more than one way...

Haiku also has "drag 'n drop" installation. Yo udownlaod an HPKG, drop
it in a folder called "packaged" and you are done.

Finally, the Haiku core devs own every single application that is
installed by default, including the web browser.
This is the only real way to have a clear distinction between "OS" and
"Third Party Applications". They provide an "App store", but when a user
updates the *OS*, they only update the *OS*, nothing else.

Haiku has a million flaws and deficiencies, but one clear goal, even if
futile.

Fedora has to have the same type of dedication to desktop/laptop use, in
order to achieve it's goal, which is to atteact developers and users
from Windows and macOS.

Again, I apologize if I have insulted anyone, my intention is not to
insult of belittle, but to inform and help.

Thanks for a great OS and sorry for the spam.

I will cool down now :)
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe

Eric Griffith

2016-11-08 05:20:55 UTC

Post by Alexander Bisogianis

Post by Alexander Bisogianis
The issue
is that except for a bit of a package delta a with server, Workstation
hasn't really taken advantage of the freedom we've been given.

First of all, I feel a bit bad judging about other people's work.
Please do not receive the below as anything else but honest criticism.
My opinion is that out of all the OSS/Libre operating systems out there, the only one specifically created for *desktop* computing is Haiku.
- The boot experience is perfect. No switching to console, no twitching no nothing. You see some icons light up, which double as progress bar and information on the boot process (for those that care).

I wonder if maybe we need to announce an official theme for each release... like this upcoming release the focus is definitely on switchable graphics. Fedora announced awesome improvements and it's a feature that can be directly seen and pointed to.

Given that Fedora has a fairly quick 6 month release cycle, maybe every cycle should have a focus point. This release was switchable, next release could be boot process, the release after that could be handling updates. It helps out the Marketing guys because they have something to target the materials at, but it also helps developers because we can say "If you don't know what to work on, go work on this."

It's like when Ubuntu did the 100 paper cuts project. It was more than a single release, but it gave a focus point for development. Amazing things are coming down the pipe in switchable graphics support... because development was focused.

Post by Alexander Bisogianis
- Is your system is unbootable for *any* reason? No worries. Boot form USB/CD, hold *Space" and you are presented with all Haiku *boot* (i.e. root) volumes. Choose one and boot. End of troubleshooting. You can also boot form USB/CD and access your files, of course. You also get a nice list of failsafe graphics modes, if you have graphics issues.

The ease of trouble shooting could be handled by having a "Boot to initramfs" option. Just bring up the bare minimum we need to for an interactive system, and then stop. Probably wouldn't have graphics (could it?) but it'd be something that MIGHT work in the absence of alternative boot media.

Post by Alexander Bisogianis
As per Liam's post, Haiku has the notion of "kits", exactly like MacOSX, because BeOS had them and MacOSX was inspired by it, in more than one way...
Haiku also has "drag 'n drop" installation. Yo udownlaod an HPKG, drop it in a folder called "packaged" and you are done.
Finally, the Haiku core devs own every single application that is installed by default, including the web browser.
This is the only real way to have a clear distinction between "OS" and "Third Party Applications". They provide an "App store", but when a user updates the *OS*, they only update the *OS*, nothing else.

I've been trying to think of any way that Linux could have a firmer split between "This is the 'default OS' and 'This is the crap you installed ontop' and I really can't think of any way we could do it... I mean I guess we could do some crazy package dependency magic where "If you install this package, it will remove anything that isn't part of the 'base install' group" but I am not any where near skilled enough with RPM packaging to figure out the syntax for that one.

Post by Alexander Bisogianis
Haiku has a million flaws and deficiencies, but one clear goal, even if futile.
Fedora has to have the same type of dedication to desktop/laptop use, in order to achieve it's goal, which is to atteact developers and users from Windows and macOS.

Anaconda folks: how hard would it be to add a drop down box on the last screen where the user could pick a tuned profile? I managed to get some noticeable performance improvements out of a virtualization host, and better battery life out of a laptop, by configuring tuned... once I knew that tuned existed.

Post by Alexander Bisogianis
Again, I apologize if I have insulted anyone, my intention is not to insult of belittle, but to inform and help.

Don't apologize. Nothing in this world got better without being criticized. If we want to continue to raise the bar, then we have to be willing to be honest with ourselves about where we are failing.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-

Adam Williamson

2016-11-04 15:32:05 UTC

Post by Alex G.S.
Maybe something more traditional like the macOS desktop
environment that had similar concepts but built with GNOME technology and
Wayland.

So, er...GNOME? ;)

Matthew Miller

2016-11-04 16:01:11 UTC

Post by Alex G.S.
Maybe something more traditional like the macOS desktop
environment that had similar concepts but built with GNOME technology and
Wayland.

So, er...GNOME? ;)

I for one am glad that after the initial period of rapid development
after the 3.0 release, GNOME has settled into a relatively stable,
comfortable, and usable design. I don't think we'd gain anything from
starting all that again. If people are interested in experimenting with
something like that as a Spin, cool, that's what we've got Spins for —
but I'm not sure it's the best use of resources for Workstation.

I *would* like to see a little bit of distinguishing flair giving some
separation between Fedora Workstation and stock upstream GNOME. I love
the clean minimalism of the existing design and I don't want to stray
from the productive partnership we have with upstream — or from the
general perception of Fedora as the premier distro for GNOME. But, I
would like people to easily recognize when Fedora is in use.

The desktop watermark with the default wallpaper is was a quick
last-minute hack, but I think we can do better.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe

Bastien Nocera

2016-11-04 16:10:11 UTC

----- Original Message -----

Post by Alex G.S.
Maybe something more traditional like the macOS desktop
environment that had similar concepts but built with GNOME technology and
Wayland.

So, er...GNOME? ;)

I for one am glad that after the initial period of rapid development
after the 3.0 release, GNOME has settled into a relatively stable,
comfortable, and usable design. I don't think we'd gain anything from
starting all that again. If people are interested in experimenting with
something like that as a Spin, cool, that's what we've got Spins for —
but I'm not sure it's the best use of resources for Workstation.
I *would* like to see a little bit of distinguishing flair giving some
separation between Fedora Workstation and stock upstream GNOME. I love
the clean minimalism of the existing design and I don't want to stray
from the productive partnership we have with upstream — or from the
general perception of Fedora as the premier distro for GNOME. But, I
would like people to easily recognize when Fedora is in use.
The desktop watermark with the default wallpaper is was a quick
last-minute hack, but I think we can do better.

It was awful then, and is now as well. Most of the Fedora developers that
also happen to be GNOME developers don't like it.

We already have patches to the details panel to prominently show Fedora,
we have custom wallpapers that don't match the upstream ones, and that
watermark.

Spending more time differentiating Fedora's GNOME and the upstream GNOME
means that we lose the upstream work on providing a simple yet recognisable
design and branding.

We want to make the difference in Fedora by providing the features and
technologies before other distributions, not by changing the upstream visual
identity.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an em

Christian Schaller

2016-11-04 18:57:21 UTC

----- Original Message -----

Sent: Friday, November 4, 2016 12:10:11 PM
Subject: Re: I asked Hacker News what developers want from a desktop, and this is what they said
----- Original Message -----

Post by Alex G.S.
Maybe something more traditional like the macOS desktop
environment that had similar concepts but built with GNOME technology and
Wayland.

So, er...GNOME? ;)

I for one am glad that after the initial period of rapid development
after the 3.0 release, GNOME has settled into a relatively stable,
comfortable, and usable design. I don't think we'd gain anything from
starting all that again. If people are interested in experimenting with
something like that as a Spin, cool, that's what we've got Spins for —
but I'm not sure it's the best use of resources for Workstation.
I *would* like to see a little bit of distinguishing flair giving some
separation between Fedora Workstation and stock upstream GNOME. I love
the clean minimalism of the existing design and I don't want to stray
from the productive partnership we have with upstream — or from the
general perception of Fedora as the premier distro for GNOME. But, I
would like people to easily recognize when Fedora is in use.
The desktop watermark with the default wallpaper is was a quick
last-minute hack, but I think we can do better.

It was awful then, and is now as well. Most of the Fedora developers that
also happen to be GNOME developers don't like it.
We already have patches to the details panel to prominently show Fedora,
we have custom wallpapers that don't match the upstream ones, and that
watermark.
Spending more time differentiating Fedora's GNOME and the upstream GNOME
means that we lose the upstream work on providing a simple yet recognisable
design and branding.
We want to make the difference in Fedora by providing the features and
technologies before other distributions, not by changing the upstream visual
identity.

Being first is definitely important and something we should focus on, but differentiation
in open source is a hard challenge and branding is a big part of it. We are not GNOME,
just like we are not the linux kernel or systemd or glibc. Yes, we happen to make use of
all those projects, but what we are is the sum of all of those and more plus the testing,
integration, customisation, extensions and specific combination of things. And making sure that
totality has a clear and easily identifiable visual identity is not wasting time. It is to build
a design and branding that highlights that Fedora Workstation is a unique thing and not just
one of many ways to run a generic GNOME desktop.

Christian
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@li

Bastien Nocera

2016-11-07 15:14:57 UTC

----- Original Message -----

Post by Christian Schaller
Being first is definitely important and something we should focus on, but differentiation
in open source is a hard challenge and branding is a big part of it. We are not GNOME,
just like we are not the linux kernel or systemd or glibc. Yes, we happen to make use of
all those projects, but what we are is the sum of all of those and more plus the testing,
integration, customisation, extensions and specific combination of things.
And making sure that
totality has a clear and easily identifiable visual identity is not wasting
time. It is to build
a design and branding that highlights that Fedora Workstation is a unique
thing and not just
one of many ways to run a generic GNOME desktop.

In which case the problem is that we don't consult with designers, or work on
that branding work upstream. Case in point, our changes to the Details panel
in Settings aren't upstream, nobody tested the performance impact of the logo
watermark in gnome-shell.

It also seems bizarre to me that we would push that branding on Fedora
Workstation, but not in other variants with a Fedora branded motd before login
on the server variant for example.

Do we *actually* have a problem with Fedora being identified as such?
In which sort of deployment do we have that problem?

We already have branding in GRUB, in plymouth, in gdm, in the default wallpaper,
in the Details panel. I'd rather we sent our stickers for laptop covers, and
Windows keys, and toned down the branding on other parts of the OS, as well as
investigated other possible branding (changing the default hostname, and .local
name seem like no-brainer with no performance impact, and greater reach).
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedoraproje

Stephen Gallagher

2016-11-07 15:26:03 UTC

Post by Bastien Nocera
----- Original Message -----

The Fedora Server does prominently display
"Fedora 24 (Server Edition)"
at the login prompt. It also presents URLs for signing into the Cockpit
administrative interface which announces "Fedora Server Edition" in big block
letters and the Fedora logo in the corner.

Post by Bastien Nocera
Do we *actually* have a problem with Fedora being identified as such?
In which sort of deployment do we have that problem?

I think the main concern here is that we want Fedora to be easily recognized as
itself because that increases mindshare significantly. Most people can recognize
Ubuntu quickly because of its graphical environment (whether it's a positive or
negative recognition is basically irrelevant here).

There's a net positive to having our brand be displayed prominently because it
can help to associate our name with whatever else is being showed off in
presentations and the like.

"Hey, that's a really cool new web application. Oh, and the person demoing it is
doing so on Fedora, so it probably works well on Fedora..."

Post by Bastien Nocera
We already have branding in GRUB, in plymouth, in gdm, in the default wallpaper,
in the Details panel. I'd rather we sent our stickers for laptop covers, and
Windows keys, and toned down the branding on other parts of the OS, as well as
investigated other possible branding (changing the default hostname, and .local
name seem like no-brainer with no performance impact, and greater reach).

Modulo the watermark, we don't have branding in the default wallpaper; just
because it's not the same as upstream does not necessarily make it immediately
recognizable as Fedora.

Grub, plymouth and GDM are transitive things that are almost never seen when
doing a demo or presentation for someone. There is real value in subtle
associations of Fedora with showing off cool stuff.

I'm not advocating that we cover the screen like ads on a race-car, but there
must be some subtle ways we can improve the branding without compromising the
aesthetics of the upstream design.

Heck, even something as simple as putting the topicon version of the Fedora logo
next to the clock could be an option. (I'm not a designer, obviously. I'm just
throwing out a straw-man for discussion.)

Bastien Nocera

2016-11-08 11:01:26 UTC

----- Original Message -----

Post by Bastien Nocera
----- Original Message -----

Post by Christian Schaller
Being first is definitely important and something we should focus on, but
differentiation
in open source is a hard challenge and branding is a big part of it. We
are
not GNOME,
just like we are not the linux kernel or systemd or glibc. Yes, we happen
to
make use of
all those projects, but what we are is the sum of all of those and more
plus
the testing,
integration, customisation, extensions and specific combination of things.
And making sure that
totality has a clear and easily identifiable visual identity is not wasting
time. It is to build
a design and branding that highlights that Fedora Workstation is a unique
thing and not just
one of many ways to run a generic GNOME desktop.

Prominent? I attached the screenshot. It's prominent because there's nothing
else on the screen, sure.

Post by Bastien Nocera
Do we *actually* have a problem with Fedora being identified as such?
In which sort of deployment do we have that problem?

We've been making GNOME recognisable, and well enough that you can recognise
it among screenshots. We've also made Fedora Workstation good enough that it's
what a lot of users use, and we can nearly assume.

Post by Stephen Gallagher
There's a net positive to having our brand be displayed prominently because it
can help to associate our name with whatever else is being showed off in
presentations and the like.

Then I'd happily remove all the crappy branding in most places in Fedora, and
offer you branding space on the "presentation" screen:
https://bugzilla.gnome.org/show_bug.cgi?id=750277

Post by Stephen Gallagher
"Hey, that's a really cool new web application. Oh, and the person demoing it is
doing so on Fedora, so it probably works well on Fedora..."

If we're focusing on presentations, we probably don't need that branding
in the default wallpaper.

Modulo the watermark, we don't have branding in the default wallpaper;

"Apart from branding, we don't have branding".

Post by Stephen Gallagher
just
because it's not the same as upstream does not necessarily make it immediately
recognizable as Fedora.

It makes it recognisable as not upstream GNOME, and I don't think those
wallpapers are of the same quality as the upstream GNOME ones.

Post by Stephen Gallagher
Grub, plymouth and GDM are transitive things that are almost never seen when
doing a demo or presentation for someone. There is real value in subtle
associations of Fedora with showing off cool stuff.

Then we agree that should remove the unnecessary branding in those transitive
states?

Post by Stephen Gallagher
I'm not advocating that we cover the screen like ads on a race-car, but there
must be some subtle ways we can improve the branding without compromising the
aesthetics of the upstream design.
Heck, even something as simple as putting the topicon version of the Fedora logo
next to the clock could be an option. (I'm not a designer, obviously. I'm just
throwing out a straw-man for discussion.)

I invite you to read the archives about this trainwreck of an idea. About the
time of the GNOME 3 release.

Michael Catanzaro

2016-11-08 11:16:05 UTC

Post by Stephen Gallagher
Heck, even something as simple as putting the topicon version of

the Fedora

Post by Stephen Gallagher
logo
next to the clock could be an option. (I'm not a designer,

obviously. I'm

Post by Stephen Gallagher
just
throwing out a straw-man for discussion.)

I invite you to read the archives about this trainwreck of an idea. About the
time of the GNOME 3 release.

I'm curious, it seems like a relatively subtle tweak, and the word
"Activites" does feel almost out of place.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscrib

Mathieu Bridon

2016-11-08 12:54:50 UTC

Post by Stephen Gallagher
Heck, even something as simple as putting the topicon version of
the Fedora logo next to the clock could be an option. (I'm not a
designer, obviously. I'm just throwing out a straw-man for
discussion.)

I invite you to read the archives about this trainwreck of an idea.
About the time of the GNOME 3 release.

I'm curious, it seems like a relatively subtle tweak, and the word
"Activites" does feel almost out of place.

On the contrary.

I've seen extremely non-technical users figure out on their own the
"Activities" button.

For example my dad, who doesn't even know he's browsing the web when he
thinks all he's doing is "going to le bon coin". When I walked into the
room the first time he used GNOME Shell and asked him how he managed to
get where he wanted without my help, the answer was:

« Well, there was nothing on the screen, but I saw"activities", so
I thought that's where I needed to go to "do things", and then I
saw "the orange icon to go to le bon coin" [that's how he calls
Firefox] so that was it ».

I'm convinced adding a logo next to the "Activities" word would have
made the experience less obvious:

« Is the logo the same as the "Activities" button? Do I click on
"Activities" or on the logo? What does "F" stand for? Maybe I
should wait until Mathieu is here before I make a mistake? »

Not asking themselves all those questions means the user doesn't feel
intimidated and belittled. Figuring out the interface on their own
means they feel confident using their computer without external help.
It means we're empowering them to do what they need.

Of course, this is just anecdata, but I'm willing to bet this is
something which consistently happens for beginner users.

For similar reasons, there's nowhere in the top-bar where a logo
wouldn't feel out of place and wouldn't make users wonder why it's
there and what it does as a UI element. (is it a button? does it have a
specific menu? is it a bug that it doesn't seem to have a specific
menu? etc.)

--
Mathieu
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send a

Christian Schaller

2016-11-08 13:10:29 UTC

Hi Bastien,
You seem to be coming at this discussion with the positive attitude of Donald Trump :)
I don't think Matthew, myself or anyone else is especially tied to specific branding items
that we currently have, what everyone cares about is the overall branding and
how it plays into our marketing of Fedora to new users. So instead of grumpily shouting 'ok, so
lets just remove that then' try to listen and understand where people are coming from and
then lets find an overall approach here that actually solves our needs. And maybe very
little of the current branding survives such a setup, but lets look at the overall picture
instead of doing what we have ended up doing the last 4 years, which is go into the trenches
and then end up adding random branding to try to avoid thinking about the actual goals of
the request.

And the good thing here is that a lot of the upstream GNOME designers are working for Red Hat,
so I am sure that as part of their job they will be able to find acceptable solutions for
both sides.

Christian

----- Original Message -----

Sent: Tuesday, November 8, 2016 6:01:26 AM
Subject: Re: I asked Hacker News what developers want from a desktop, and this is what they said
----- Original Message -----

Post by Bastien Nocera
----- Original Message -----

Post by Christian Schaller
Being first is definitely important and something we should focus on, but
differentiation
in open source is a hard challenge and branding is a big part of it. We
are
not GNOME,
just like we are not the linux kernel or systemd or glibc. Yes, we happen
to
make use of
all those projects, but what we are is the sum of all of those and more
plus
the testing,
integration, customisation, extensions and specific combination of things.
And making sure that
totality has a clear and easily identifiable visual identity is not wasting
time. It is to build
a design and branding that highlights that Fedora Workstation is a unique
thing and not just
one of many ways to run a generic GNOME desktop.

Prominent? I attached the screenshot. It's prominent because there's nothing
else on the screen, sure.

Post by Bastien Nocera
Do we *actually* have a problem with Fedora being identified as such?
In which sort of deployment do we have that problem?

Then I'd happily remove all the crappy branding in most places in Fedora, and
https://bugzilla.gnome.org/show_bug.cgi?id=750277

Post by Stephen Gallagher
"Hey, that's a really cool new web application. Oh, and the person demoing
it
is
doing so on Fedora, so it probably works well on Fedora..."

If we're focusing on presentations, we probably don't need that branding
in the default wallpaper.

Post by Bastien Nocera
We already have branding in GRUB, in plymouth, in gdm, in the default wallpaper,
in the Details panel. I'd rather we sent our stickers for laptop covers, and
Windows keys, and toned down the branding on other parts of the OS, as
well
as
investigated other possible branding (changing the default hostname, and .local
name seem like no-brainer with no performance impact, and greater reach).

Modulo the watermark, we don't have branding in the default wallpaper;

"Apart from branding, we don't have branding".

Post by Stephen Gallagher
just
because it's not the same as upstream does not necessarily make it immediately
recognizable as Fedora.

It makes it recognisable as not upstream GNOME, and I don't think those
wallpapers are of the same quality as the upstream GNOME ones.

Then we agree that should remove the unnecessary branding in those transitive
states?

I invite you to read the archives about this trainwreck of an idea. About the
time of the GNOME 3 release.
_______________________________________________

_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe s

Bastien Nocera

2016-11-08 13:51:45 UTC

----- Original Message -----

Post by Christian Schaller
Hi Bastien,
You seem to be coming at this discussion with the positive attitude of Donald Trump :)

I find that highly offensive, smiley or not.

Post by Christian Schaller
I don't think Matthew, myself or anyone else is especially tied to specific branding items
that we currently have, what everyone cares about is the overall branding and
how it plays into our marketing of Fedora to new users. So instead of
grumpily shouting 'ok, so
lets just remove that then' try to listen and understand where people are coming from and
then lets find an overall approach here that actually solves our needs. And maybe very
little of the current branding survives such a setup, but lets look at the overall picture
instead of doing what we have ended up doing the last 4 years, which is go
into the trenches
and then end up adding random branding to try to avoid thinking about the actual goals of
the request.

Which is exactly what I'm doing. Neither GNOME upstream, nor GNOME designers
and developers in Fedora were given the opportunity to make holistic design
decisions with regards to branding.

And I don't like that "grumpy" label either. I care about what the products
I work on look and act, and I'm disconcerted, and bemused when non-GNOME
Fedora participants act as if we don't have a foot in both teams.

Post by Christian Schaller
And the good thing here is that a lot of the upstream GNOME designers are
working for Red Hat,
so I am sure that as part of their job they will be able to find acceptable solutions for
both sides.

Which is what I'm currently working on with them.

Switch to upstream theme for Plymouth:
https://bugzilla.redhat.com/show_bug.cgi?id=1392836
Spinner theme update:
https://bugs.freedesktop.org/show_bug.cgi?id=98640

Details panel changes:
https://bugzilla.gnome.org/show_bug.cgi?id=770593
and
https://bugzilla.gnome.org/show_bug.cgi?id=695691

Hostname changes as branding:
https://bugzilla.redhat.com/show_bug.cgi?id=1392924 (avahi)
https://bugzilla.redhat.com/show_bug.cgi?id=1392925 (systemd for hostnamed)
https://bugzilla.redhat.com/show_bug.cgi?id=1392926 (anaconda)

We still have to work on the presentation mode, which would be a much better
way to advertise Fedora during presentations (!), and discuss what to do with
those other cases of downstream branding.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe se

Christian Schaller

2016-11-08 15:16:48 UTC

It is good that you care about the products, but you can't be unaware
that doing things like filing that bugzilla entry for that spinner bug
halfway into a discussion comes off as very aggressive and uncollaborative?

As for designers not having enough time, I would beg to differ about that
being the problem here. We been having these branding discussions for at least 3
years now if not more, which I think should be more than enough time for anyone.
I been trying to push things along at multiple instances, I even tried setting up a
branding working group years ago with various designers in the hope they could find
a holistic solution to address the needs in both Fedora and RHEL. For various reasons
that effort did not really resolve anything either. What has happened every time, and
I definitely deserve the blame for not making sure we kept on this, is that we end up having a
flare-up shortly before each release, end up doing something that is doable within
that short timeframe, leaving nobody really happy; and then drop the ball waiting for the
next flare up at a later release.

So if you want to own this problem and ensure we have a proper solution finally
that is great, but you have to do it by making sure you speak to Fedora and RHEL
stakeholders and ensure there is actual agreement that this resolves our needs
for the long term as opposed to be another bandaid for the next release, because
I think we both agree there has been enough of those.

Christian

----- Original Message -----

Sent: Tuesday, November 8, 2016 8:51:45 AM
Subject: Re: I asked Hacker News what developers want from a desktop, and this is what they said
----- Original Message -----

Post by Christian Schaller
Hi Bastien,
You seem to be coming at this discussion with the positive attitude of
Donald
Trump :)

I find that highly offensive, smiley or not.

Post by Christian Schaller
I don't think Matthew, myself or anyone else is especially tied to specific
branding items
that we currently have, what everyone cares about is the overall branding and
how it plays into our marketing of Fedora to new users. So instead of
grumpily shouting 'ok, so
lets just remove that then' try to listen and understand where people are
coming from and
then lets find an overall approach here that actually solves our needs. And maybe very
little of the current branding survives such a setup, but lets look at the
overall picture
instead of doing what we have ended up doing the last 4 years, which is go
into the trenches
and then end up adding random branding to try to avoid thinking about the
actual goals of
the request.

Which is exactly what I'm doing. Neither GNOME upstream, nor GNOME designers
and developers in Fedora were given the opportunity to make holistic design
decisions with regards to branding.
And I don't like that "grumpy" label either. I care about what the products
I work on look and act, and I'm disconcerted, and bemused when non-GNOME
Fedora participants act as if we don't have a foot in both teams.

Which is what I'm currently working on with them.
https://bugzilla.redhat.com/show_bug.cgi?id=1392836
https://bugs.freedesktop.org/show_bug.cgi?id=98640
https://bugzilla.gnome.org/show_bug.cgi?id=770593
and
https://bugzilla.gnome.org/show_bug.cgi?id=695691
https://bugzilla.redhat.com/show_bug.cgi?id=1392924 (avahi)
https://bugzilla.redhat.com/show_bug.cgi?id=1392925 (systemd for hostnamed)
https://bugzilla.redhat.com/show_bug.cgi?id=1392926 (anaconda)
We still have to work on the presentation mode, which would be a much better
way to advertise Fedora during presentations (!), and discuss what to do with
those other cases of downstream branding.
_______________________________________________

_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.f

Bastien Nocera

2016-11-08 15:43:17 UTC

----- Original Message -----

Post by Christian Schaller
It is good that you care about the products, but you can't be unaware
that doing things like filing that bugzilla entry for that spinner bug
halfway into a discussion comes off as very aggressive and uncollaborative?

Certainly not. You're assuming the worst in me, and I would expect
that members of the Fedora community would assume people mean well. I linked
to the discussion, I linked the discussion to the bug, I'm pretty sure the
maintainer of the package reads this list (or should!) and can verify that
the consensus is towards that, and I'm making sure that the bug doesn't just
stay there because "nobody had the time to look into it" by providing a patch
that could fix this problem.

I think that looking into what could be technical hurdles early in discussions
is something required not to hit a wall when implementing them. This is exactly
what I did. And I really thought there was consensus.

Post by Christian Schaller
As for designers not having enough time, I would beg to differ about that
being the problem here. We been having these branding discussions for at least 3
years now if not more, which I think should be more than enough time for anyone.
I been trying to push things along at multiple instances, I even tried setting up a
branding working group years ago with various designers in the hope they could find
a holistic solution to address the needs in both Fedora and RHEL. For various reasons
that effort did not really resolve anything either. What has happened every time, and
I definitely deserve the blame for not making sure we kept on this, is that
we end up having a
flare-up shortly before each release, end up doing something that is doable within
that short timeframe, leaving nobody really happy; and then drop the ball waiting for the
next flare up at a later release.
So if you want to own this problem and ensure we have a proper solution finally
that is great, but you have to do it by making sure you speak to Fedora and RHEL
stakeholders and ensure there is actual agreement that this resolves our needs
for the long term as opposed to be another bandaid for the next release, because
I think we both agree there has been enough of those.

I'm happy to own the problem as long as, as mentioned in the mail to Stephen,
"Fedora" trusts GNOME to do what's right for the distributors, and we don't
get those knee-jerk logo slapping reaction, but constructive feedback.

We also need to be able to quantify what success would be.

Putting the burden on GNOME, and the Fedora version of GNOME to carry all the
branding of the distribution for Fedora Workstation is unfair, IMO.
Having a Fedora blue hue to the default shell-prompt is likely more recognisable
and more generally useful a downstream change than the boot logo. See how
well the Linux tux logo is recognised as the airplane media centre sign for failure.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to deskt

Stephen Gallagher

2016-11-08 15:57:03 UTC

Post by Bastien Nocera
I'm happy to own the problem as long as, as mentioned in the mail to Stephen,
"Fedora" trusts GNOME to do what's right for the distributors, and we don't
get those knee-jerk logo slapping reaction, but constructive feedback.
We also need to be able to quantify what success would be.
Putting the burden on GNOME, and the Fedora version of GNOME to carry all the
branding of the distribution for Fedora Workstation is unfair, IMO.
Having a Fedora blue hue to the default shell-prompt is likely more recognisable
and more generally useful a downstream change than the boot logo. See how
well the Linux tux logo is recognised as the airplane media centre sign for failure.

To be fair, I explicitly stated that the "logo in the header bar" idea was
intentionally a straw-man to start a discussion. I hadn't thought of changing
the shell chrome color, but that's certainly worth consideration.

And yes, I agree that the bootloader references to Fedora are not a terribly
effective means of identifying Fedora: if you are seeing it, then you are either
booting for the first time (and already know what is coming) or a reboot has
occurred and either you already know what is coming or something has gone wrong,
in which case we probably don't want to shout our name around at that point :)

What I was most concerned about was that it seemed like you were coming down on
the side of "Fedora should just ship GNOME however GNOME upstream wants it"
which was ignoring Fedora's needs entirely. I'm quite happy to work together on
figuring out how we can solve this in upstream GNOME to solve Fedora's (and by
extension, other distros') needs for brand identity.

The reason we've done things downstream in the past is mostly because (as
Christian noted) the problem isn't highly prioritized upstream, so it gets
ignored until it becomes a fire-drill. So let's work on that; let's plan solve
the Fedora 26 problem in 2016 (or really early in 2017) so it's ready to be
implemented in time for a Spring 2017 release.

Bastien Nocera

2016-11-08 16:10:55 UTC

----- Original Message -----
<snip>

Post by Stephen Gallagher
To be fair, I explicitly stated that the "logo in the header bar" idea was
intentionally a straw-man to start a discussion. I hadn't thought of changing
the shell chrome color, but that's certainly worth consideration.

No, the bash/zsh shell colour. This goes with:
"
Putting the burden on GNOME, and the Fedora version of GNOME to carry all the
branding of the distribution for Fedora Workstation is unfair, IMO.
"

Changing the default hostnames, colouring the shell prompt in Fedora colours
are both useful to users *and* good for the branding.

<snip>

Post by Stephen Gallagher
What I was most concerned about was that it seemed like you were coming down on
the side of "Fedora should just ship GNOME however GNOME upstream wants it"
which was ignoring Fedora's needs entirely.

Fedora's needs were never set out, which makes it really complicated to even
start working on this. What is there to work on when Fedora is just going to
make its own changes anyway, right?

Post by Stephen Gallagher
I'm quite happy to work together
on
figuring out how we can solve this in upstream GNOME to solve Fedora's (and by
extension, other distros') needs for brand identity.
The reason we've done things downstream in the past is mostly because (as
Christian noted) the problem isn't highly prioritized upstream, so it gets
ignored until it becomes a fire-drill. So let's work on that; let's plan solve
the Fedora 26 problem in 2016 (or really early in 2017) so it's ready to be
implemented in time for a Spring 2017 release.

Which means it needs to be worked on now so the changes are in GNOME 3.24 for
those changes that affect GNOME. And you'll also need to convey that need to
the maintainers of other, non-GNOME, software in Fedora, so they can have their
discussions with their upstreams in the same way as we're engaging here.

Cheers
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email

Christian Schaller

2016-11-08 16:08:27 UTC

----- Original Message -----

Sent: Tuesday, November 8, 2016 10:43:17 AM
Subject: Re: I asked Hacker News what developers want from a desktop, and this is what they said
----- Original Message -----

Certainly not. You're assuming the worst in me, and I would expect
that members of the Fedora community would assume people mean well. I linked
to the discussion, I linked the discussion to the bug, I'm pretty sure the
maintainer of the package reads this list (or should!) and can verify that
the consensus is towards that, and I'm making sure that the bug doesn't just
stay there because "nobody had the time to look into it" by providing a patch
that could fix this problem.
I think that looking into what could be technical hurdles early in discussions
is something required not to hit a wall when implementing them. This is exactly
what I did. And I really thought there was consensus.

Post by Christian Schaller
As for designers not having enough time, I would beg to differ about that
being the problem here. We been having these branding discussions for at least 3
years now if not more, which I think should be more than enough time for anyone.
I been trying to push things along at multiple instances, I even tried setting up a
branding working group years ago with various designers in the hope they could find
a holistic solution to address the needs in both Fedora and RHEL. For
various
reasons
that effort did not really resolve anything either. What has happened every time, and
I definitely deserve the blame for not making sure we kept on this, is that
we end up having a
flare-up shortly before each release, end up doing something that is doable within
that short timeframe, leaving nobody really happy; and then drop the ball
waiting for the
next flare up at a later release.
So if you want to own this problem and ensure we have a proper solution finally
that is great, but you have to do it by making sure you speak to Fedora and RHEL
stakeholders and ensure there is actual agreement that this resolves our needs
for the long term as opposed to be another bandaid for the next release, because
I think we both agree there has been enough of those.

If you want Fedora or anyone else to trust GNOME to know what is best in terms of
building the distribution brand then you need to show that helping distributions
building their individual brands is a top priority for GNOME. Maybe such discussions
have been had or that there is a document showing how GNOME envision distributions
building their own brands while shipping GNOME, but I have not seen that yet.

We also need to be able to quantify what success would be.
Putting the burden on GNOME, and the Fedora version of GNOME to carry all the
branding of the distribution for Fedora Workstation is unfair, IMO.

Well GNOME is providing us with the 'face' of the distribution, so for better or
worse it is where such things naturally would go. Its kinda like how putting a tattoo
on your skin has a lot bigger impact on peoples perception or idea about you than what
brand of hip replacement you have, even though a hip replacement surgery is a ton more intrusive
than getting a tattoo.

Having a Fedora blue hue to the default shell-prompt is likely more recognisable
and more generally useful a downstream change than the boot logo. See how
well the Linux tux logo is recognised as the airplane media centre sign for failure.

I agree with this, that branding doesn't need to be about logo slapping, just figuring
out design elements that makes us individually recognizable from others. So for instance
an idea I had was that instead of slapping a logo on the activities bar somewhere, maybe
something subtler like a faint background swirl along it would be more effective and
less in your face. That is just a random idea though, not a demand from me that is the
final solution.

Christian

_______________________________________________

_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an e

Bastien Nocera

2016-11-08 16:19:48 UTC

----- Original Message -----
<snip>

Post by Bastien Nocera
We also need to be able to quantify what success would be.
Putting the burden on GNOME, and the Fedora version of GNOME to carry all the
branding of the distribution for Fedora Workstation is unfair, IMO.

And adding a tattoo can look good or really ugly depending on where it is. I
think we should look into changing clothes and our accessories before branding
permanently.

Post by Bastien Nocera
Having a Fedora blue hue to the default shell-prompt is likely more recognisable
and more generally useful a downstream change than the boot logo. See how
well the Linux tux logo is recognised as the airplane media centre sign for failure.

That's a refreshing (and soothing) stance.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fe

Christian Schaller

2016-11-08 16:37:02 UTC

I think to get this discussion back on track I think we all need to remind ourselves that
we are not shipping GNOME, nor are we shipping any of the thousand other pieces of software
that we have rpms for. We are shipping the Fedora Workstation, that is our product here.
So there are of course a lot of components in there which have new versions since the last
release, but for our users that is an implementation detail at the end of the day.

So what we want to do here is decide on how to build the identity and brand of the Fedora
Workstation, and we need to start with defining what our goals with that effort is. Once
we have those goals we can look into which pieces of software needs to change to accommodate
those goals and those pieces might come from a long range of upstream projects be that bash,
plymouth, GNOME, grub and so on and so forth.

I realize that it is hard to completely decouple the principle discussion with the implementation
details, which is why so many times in the past we managed to derail ourselves into endless flamewars
about where to put a logo and how big it should be, but if we want to fix this and avoid revisiting
this topic again and again while growing more and more frustrated, we need to agree on the overall goals
here first and then work our way down the stack.

So to try to make a start I think what we want on a general level is things that makes someone looking at
a Fedora Workstation screen or screenshot instantly recognize it as that. The goal of that being develop
a distinct Fedora Workstation identity and to ensure that every Fedora user becomes a Fedora ambassador.

Christian

----- Original Message -----

Sent: Tuesday, November 8, 2016 11:19:48 AM
Subject: Re: I asked Hacker News what developers want from a desktop, and this is what they said
----- Original Message -----
<snip>

Well GNOME is providing us with the 'face' of the distribution, so for
better
or
worse it is where such things naturally would go. Its kinda like how
putting
a tattoo
on your skin has a lot bigger impact on peoples perception or idea about
you
than what
brand of hip replacement you have, even though a hip replacement surgery is a
ton more intrusive
than getting a tattoo.

And adding a tattoo can look good or really ugly depending on where it is. I
think we should look into changing clothes and our accessories before branding
permanently.

I agree with this, that branding doesn't need to be about logo slapping,
just
figuring
out design elements that makes us individually recognizable from others. So
for instance
an idea I had was that instead of slapping a logo on the activities bar
somewhere, maybe
something subtler like a faint background swirl along it would be more effective and
less in your face. That is just a random idea though, not a demand from me that is the
final solution.

That's a refreshing (and soothing) stance.
_______________________________________________

_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe sen

Matthew Miller

2016-11-08 16:08:57 UTC

Post by Christian Schaller
flare-up shortly before each release, end up doing something that is
doable within that short timeframe, leaving nobody really happy; and
then drop the ball waiting for the next flare up at a later release.

To be clear: I'm not aiming to get any changes into F25 at this point.
That would be kinda crazy. I'm hoping to avoid the above situation by
talking about F26 plans *now*.

Matthew Miller

2016-11-07 15:35:04 UTC

Post by Bastien Nocera
In which case the problem is that we don't consult with designers, or work on
that branding work upstream. Case in point, our changes to the Details panel
in Settings aren't upstream, nobody tested the performance impact of the logo
watermark in gnome-shell.

I'm consuluting with designers.

I do agree that we should test the impact of any changes, for
performance (if any affect), but also for overall UX and
identifiablity.

Post by Bastien Nocera
It also seems bizarre to me that we would push that branding on Fedora
Workstation, but not in other variants with a Fedora branded motd before login
on the server variant for example.

Have you looked, here? Of course Fedora Server identifies itself at the
login prompt. And the Cockpit GUI uses the Fedora Server logo. I think
there's room for improvements in this too, but the basics are there.

Post by Bastien Nocera
Do we *actually* have a problem with Fedora being identified as such?
In which sort of deployment do we have that problem?

It is important to increase Fedora brand reach and recognition. A
strong visual identity is an important part of this. If you want to
phrase it in terms of a "problem", every place where there is a Fedora
deployment and it is not easily recognized as Fedora, we have that
problem.

Although it's not nothing, branding which is only shown briefly at boot
and when not logged in does not contribute strongly to the visual
identity. Branding in the "details" panel, though, is arguably
*worse* than nothing, as it sends the signal that Fedora is merely
that, a "detail". And I think we already agreed that nobody likes the
wallpaper overlay.

I'm all for investigating possibilities, especially ones which have no
performance impact and reach. We should do everything we can, and we
certainly *do* provides stickers and other Fedora swag. We need to work
on the contrbutions of the desktop visual appearance to our brand
identity as well.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe sen

Bastien Nocera

2016-11-08 11:01:34 UTC

----- Original Message -----

I'm consuluting with designers.

I don't think the designers really got consulted for that particular feature,
given that the developers barely had time to get this feature in at your behest.

Post by Matthew Miller
I do agree that we should test the impact of any changes, for
performance (if any affect), but also for overall UX and
identifiablity.

Work which can only be done holistically upstream.

1 mention in GRUB, 1 mention in the login screen. In contrast, Workstation
has 1 mention in GRUB, 1 in the splash screen, 1 in the login screen, 1 in
the desktop wallpaper, 1 in the Details panel, 1 in Software when upgrades
are available.

Post by Bastien Nocera
Do we *actually* have a problem with Fedora being identified as such?
In which sort of deployment do we have that problem?

Being able to recognise Fedora from a screenshot of a maximised application
on a GNOME 3 desktop would go counter to what we've been trying to achieve
with GNOME 3.

Although it's not nothing, branding which is only shown briefly at boot
and when not logged in does not contribute strongly to the visual
identity.

Then you agree with Stephen and I that we should drop the Fedora plymouth
branding. Great, I filed a bug about that:
https://bugzilla.redhat.com/show_bug.cgi?id=1392836

Post by Matthew Miller
Branding in the "details" panel, though, is arguably
*worse* than nothing, as it sends the signal that Fedora is merely
that, a "detail".

Huh? This is where information about the system is.

Post by Matthew Miller
And I think we already agreed that nobody likes the
wallpaper overlay.

Great, let's get rid of that too then.

Post by Matthew Miller
I'm all for investigating possibilities, especially ones which have no
performance impact and reach. We should do everything we can, and we
certainly *do* provides stickers and other Fedora swag. We need to work
on the contrbutions of the desktop visual appearance to our brand
identity as well.

I think that being the best GNOME Workstation distributor would go a long
way towards making Fedora the de facto choice for GNOME use, and that would
likely be more effective than slapping non-upstream logos in places.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to

Stephen Gallagher

2016-11-08 14:07:27 UTC

What I think Matthew and I are trying to say is that this is a very limited and
GNOME-centric perspective. Fedora is more than just GNOME. It has to be,
otherwise what is the point? You can run GNOME on dozens of other distributions.

The value of Fedora is more than "well, it runs a vanilla version of GNOME".
Fedora's value is that it's a source both of and for awesome open-source
software. We want to encourage people to use and contribute to Fedora because
*that's how open-source improves*. Fedora is one of the largest *contributor*
distributions in the world and we want to continue to grow that.

Part of that means that we have to spend time and effort associating the Fedora
brand with "cool new stuff". One of the easiest and most effective ways to do
this is by ensuring that whenever you see "cool new stuff" showed off somewhere,
there's an easy cue to the viewer that it's being done on Fedora.

In another email, I think you misunderstood when I talked about presentations. I
don't just mean formal, LibreOffice Impress presentations. I mean when someone
spins their laptop around on a table to show you something cool. There should be
*some* sort of sensory cue that what you're looking at is Fedora.

Like I said: Ubuntu accomplished this by establishing Unity as unique to their
platform (for better or worse). If you see someone running Unity, you assume
that's an Ubuntu system (even if it actually isn't; Unity *does* run on an a
couple other OSes). With vanilla GNOME, all you know is that the user is running
GNOME. Might be Debian, might be Fedora, might be something else. That's fine
and good to positively associate with GNOME. I love GNOME. But it doesn't help
*Fedora*, and we need to do that.

Bastien Nocera

2016-11-08 15:23:39 UTC

----- Original Message -----

You can run it with as good an integration as Fedora on... well, Fedora and
spins/remixes.

Post by Stephen Gallagher
The value of Fedora is more than "well, it runs a vanilla version of GNOME".
Fedora's value is that it's a source both of and for awesome open-source
software. We want to encourage people to use and contribute to Fedora because
*that's how open-source improves*. Fedora is one of the largest *contributor*
distributions in the world and we want to continue to grow that.

And that's probably not going to work quite as well as it should when you go
against the opinion of the upstream as to how to present their software, or
how to integrate it in the greater whole.

Post by Stephen Gallagher
Part of that means that we have to spend time and effort associating the Fedora
brand with "cool new stuff". One of the easiest and most effective ways to do
this is by ensuring that whenever you see "cool new stuff" showed off somewhere,
there's an easy cue to the viewer that it's being done on Fedora.

That's the idea of the branding in the presentation display.

Post by Stephen Gallagher
In another email, I think you misunderstood when I talked about presentations. I
don't just mean formal, LibreOffice Impress presentations. I mean when someone
spins their laptop around on a table to show you something cool. There should be
*some* sort of sensory cue that what you're looking at is Fedora.

[1].

Post by Stephen Gallagher
Like I said: Ubuntu accomplished this by establishing Unity as unique to their
platform (for better or worse). If you see someone running Unity, you assume
that's an Ubuntu system (even if it actually isn't; Unity *does* run on an a
couple other OSes). With vanilla GNOME, all you know is that the user is running
GNOME. Might be Debian, might be Fedora, might be something else. That's fine
and good to positively associate with GNOME. I love GNOME. But it doesn't help
*Fedora*, and we need to do that.

That means making downstream modifications to the shell or GTK+ theme, or
showing a permanent logo.

I think we're better off building the best-integrated, best-tested, least-buggy,
most-current version of the GNOME desktop. That doesn't stop us from using
Fedora as branding where we set room aside for that purpose, from showing
a logo or watermark where it doesn't change or invalidate the interaction testing
or design that was done upstream.

Take for example the tidbit of integration for dual-GPU. We're fixing bugs upstream
in the kernel and Xorg to enable this, we're integrating menu items upstream and in
Fedora. When do you think those will land in other distributions? In 6 months? A year?

If you want to *always* know that it's running a Fedora system, that will likely
lead to more work for little reward.

If you don't trust upstream to do what's right for its distributors, then I'm really
not sure what to do to alleviate that fear.

Cheers

[1]: At the bottom not to make this more tense than it is, but: stickers :)
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedorapro

Michael Catanzaro

2016-11-07 16:39:13 UTC

Post by Bastien Nocera
nobody tested the performance impact of the logo
watermark in gnome-shell.

Is there a problem with it?

Post by Bastien Nocera
We already have branding in GRUB,

And it's dramatically worse than our upstream designs. I really hope we
can find time to implement this:

https://wiki.gnome.org/Design/OS/Boot
https://wiki.gnome.org/Design/OS/BootOptions

Someone recently mentioned an anecdote where a user just installed
Fedora and thought the rescue kernel boot entry meant it had been
installed multiple times by mistake. It's not OK to show kernel version
in the bootloader....

Post by Bastien Nocera
in plymouth,

This is arguably the biggest wart on the distribution right now: our
boot splash looks very poor compared to the plain spinner theme. Is
poor branding worse than no branding? It's possible to make a great
branded bootsplash -- just look at elementary OS -- but I think we'd be
better off with the spinner than what we have right now.

On the bright side, we have come a long way for these to be my primary
concerns. :)

Michael
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai

Luya Tshimbalanga

2016-11-07 18:21:00 UTC

Post by Bastien Nocera
nobody tested the performance impact of the logo
watermark in gnome-shell.

Is there a problem with it?

Post by Bastien Nocera
We already have branding in GRUB,

And it's dramatically worse than our upstream designs. I really hope we
https://wiki.gnome.org/Design/OS/Boot
https://wiki.gnome.org/Design/OS/BootOptions
Someone recently mentioned an anecdote where a user just installed
Fedora and thought the rescue kernel boot entry meant it had been
installed multiple times by mistake. It's not OK to show kernel version
in the bootloader....

Speaking about Boot, it will be time to visit systemd-boot formerly
gummiboot for hardware using efi partition. It seems simple to implement
on Fedora Workstation.

--
Luya Tshimbalanga
Graphic & Web Designer
E: ***@fedoraproject.org
W: http://www.coolest-storm.net

_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe

Adam Williamson

2016-11-07 19:35:55 UTC

Post by Luya Tshimbalanga
Speaking about Boot, it will be time to visit systemd-boot formerly
gummiboot for hardware using efi partition. It seems simple to implement
on Fedora Workstation.

Bootloading is enough of a f**king nightmare to deal with without
making it harder for ourselves by throwing more damn bootloaders on the
pile.

Matthew Miller

2016-11-07 19:54:56 UTC

Post by Luya Tshimbalanga
Speaking about Boot, it will be time to visit systemd-boot formerly
gummiboot for hardware using efi partition. It seems simple to implement
on Fedora Workstation.

Bootloading is enough of a f**king nightmare to deal with without
making it harder for ourselves by throwing more damn bootloaders on the
pile.

As far as I know, the main objection to grub2 is that the configuration
system seems to have been designed by someone who likes levels of
abstraction just a *litttttle* too much. Peter Jones recently mentioned
to me that he's working on a thing which will allow it to be configured
by simple drop-in snippets, making that not so much of a concern and as
a bonus, making grubby obsolete.

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe se

Matthew Miller

2016-11-07 21:52:22 UTC

Post by Michael Catanzaro
This is arguably the biggest wart on the distribution right now: our
boot splash looks very poor compared to the plain spinner theme. Is
poor branding worse than no branding? It's possible to make a great
branded bootsplash -- just look at elementary OS -- but I think we'd be
better off with the spinner than what we have right now.

Hmmm....

?

(Possibly with a Workstation-specific version?)

Michael Catanzaro

2016-11-07 22:00:46 UTC

Hmmm.... http://youtu.be/B6n-2t9aUoM
(Possibly with a Workstation-specific version?)

yes yes yes yes yes

The trick is making it look good during a boot process that can take an
unknown amount of time. (Probably we would need to run the animation
once quickly like that, then stop animating until boot completes?) And
turning it into a Plymouth theme. And handling offline updates.

But yeah, something like that!

Michael
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe s

Matthew Miller

2016-11-07 22:09:02 UTC

Hmmm.... http://youtu.be/B6n-2t9aUoM
(Possibly with a Workstation-specific version?)

yes yes yes yes yes
The trick is making it look good during a boot process that can take an
unknown amount of time. (Probably we would need to run the animation
once quickly like that, then stop animating until boot completes?) And
turning it into a Plymouth theme. And handling offline updates.
But yeah, something like that!

Okay, so, now the trick is to hook up the artist with someone who can
implement....

--
Matthew Miller
<***@fedoraproject.org>
Fedora Project Leader
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an

Micah Denn

2016-11-07 22:51:58 UTC

I don't know that much about plymouth and its fantastically poorly documented. I'm almost certain that it can't play that many large frames at a watchable frame rate.
Although if we simplified it a bit I think most of the animation could be implemented in code, which would be much better in terms of performance.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to deskto

Michael Catanzaro

2016-11-08 16:12:03 UTC

Post by Micah Denn
I don't know that much about plymouth and its fantastically poorly
documented. I'm almost certain that it can't play that many large
frames at a watchable frame rate.
Although if we simplified it a bit I think most of the animation
could be implemented in code, which would be much better in terms of
performance.

Would the animation still look good if we did it over the gray noise
background that we currently use for the login screen? The upstream
designs call for that background to be used from the GRUB theme all the
way to the login screen.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an

Bastien Nocera

2016-11-08 16:28:46 UTC

----- Original Message -----

I don't think the logo needs to be there at all. I think it reflects badly
on the distribution when it fails (see Tux story), when it's seen too often,
when it's used as a replacement for the update progress bar, or when it's seen
long enough to be remembered.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@li

Michael Catanzaro

2016-11-08 16:33:37 UTC

Post by Bastien Nocera
I don't think the logo needs to be there at all. I think it reflects badly
on the distribution when it fails (see Tux story), when it's seen too often,
when it's used as a replacement for the update progress bar, or when it's seen
long enough to be remembered.

Personally, I have no preference as to whether it's used on the boot
screen or not.

But I do want to avoid it on the update screen. All that does is
associate Fedora with slow updates. :)

Michael
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lis

Eric Griffith

2016-11-08 16:40:49 UTC

Then why do we opt for a generic black background for grub?
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to des

Bastien Nocera

2016-11-08 16:49:05 UTC

----- Original Message -----

Post by Eric Griffith

Then why do we opt for a generic black background for grub?

Technical reasons, not design ones.

To make it smooth, we'd need to use the exact same texture in all of grub,
plymouth and gdm (easy enough) at the same resolution. Doing graphics at the
grub level is likely to be slow (the RHEL grub with the logo was pretty slow
last I actively tested it), and not have access to all the resolutions that
the OS would.

Maybe it'd be super efficient to do for just EFI based systems, and at the
right resolution, but that's hard to say without buy-in to make it happen.

From my side, it's important, but not as important as some other things to do
in the boot manager side (32-bit EFI support and support for in-OS boot management,
to name but 2).
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an ema

Alexander Bisogianis

2016-11-08 16:52:16 UTC

Post by Bastien Nocera
To make it smooth, we'd need to use the exact same texture in all of grub,
plymouth and gdm (easy enough) at the same resolution. Doing graphics at the
grub level is likely to be slow (the RHEL grub with the logo was pretty slow
last I actively tested it), and not have access to all the resolutions that
the OS would.

Why show grub in the first place, especially if Fedora is the only OS on
the disk?
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedoraprojec

Bastien Nocera

2016-11-08 16:56:32 UTC

Post by Alexander Bisogianis

----- Original Message -----

Why show grub in the first place, especially if Fedora is the only OS on
the disk?

Because, if we fail to boot, you won't have an opportunity to even get to the
boot menu on many systems. Would be easier if we could design the hardware
to go with the boot menu ;)
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@list

Adam Williamson

2016-11-08 00:39:14 UTC

Hmmm.... http://youtu.be/B6n-2t9aUoM
(Possibly with a Workstation-specific version?)

yes yes yes yes yes
The trick is making it look good during a boot process that can take an
unknown amount of time. (Probably we would need to run the animation
once quickly like that, then stop animating until boot completes?) And
turning it into a Plymouth theme. And handling offline updates.
But yeah, something like that!

I vaguely recall around the time I joined Fedora, someone - I forget
who, could be Harald - invested rather a lot of work in implementing
all the necessary bits so we got an almost perfectly themed and mode-
switch-free boot process from grub through to the desktop.

What happened after that, of course, is we threw out half those
components and rewrote the other half so that all become history in
about three months flat...

Luya Tshimbalanga

2016-11-08 01:52:45 UTC

Hmmm.... http://youtu.be/B6n-2t9aUoM ?
(Possibly with a Workstation-specific version?)

That will be a great step. It will be nice to apply that model for both
offline update and shutting down screen which needs more love. Perhaps
for Fedora 26 and onwards?

--
Luya Tshimbalanga
Graphic & Web Designer
E: ***@fedoraproject.org
W: http://www.coolest-storm.net
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe se

Bastien Nocera

2016-11-08 11:02:05 UTC

----- Original Message -----

Hmmm.... http://youtu.be/B6n-2t9aUoM ?
(Possibly with a Workstation-specific version?)

From your other mail:
"
Although it's not nothing, branding which is only shown briefly at boot
and when not logged in does not contribute strongly to the visual
identity.
"

I have trouble reconciling that statement with that proposal.
_______________________________________________
desktop mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to desktop-***@lists.fedorapr

Matthew Miller

2016-11-08 14:20:06 UTC

Post by Matthew Miller
Hmmm.... http://youtu.be/B6n-2t9aUoM ?
(Possibly with a Workstation-specific version?)

"
Although it's not nothing, branding which is only shown briefly at boot
and when not logged in does not contribute strongly to the visual
identity.
"
I have trouble reconciling that statement with that proposal.

Doesn't seem hard to me -- from another part of that message, "We
should do everything we can". Michael identified the boot splash as an
area he thinks needs improvement, and we're building on that. I don't
see that brief message as a big deal, but if other people do, that's
cool -- let's make it better.

Liam

2016-11-07 04:31:22 UTC