The startup-scene dev message board Hacker News has an "Ask HN" section, and I used it to ask what developers want from a desktop in 2017. https://news.ycombinator.com/item?id=12703836 Here's a summary of what they said:
* Make upgrades painless.
This is often presented as "make it LTS or rolling", but in digging further, it's almost always "I don't want to have to devote a day of downtime to upgrading twice a year".
* 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.
* Give the ability to have package X move at a pace I choose. Separate dev stack from base OS.
* Hardware compatibility just works. (Wifi, sound, HDMI, graphics, suspend, etc.)
* Mixed DPI multi-monitor support.
* Look nice, better fonts, general usability, etc.
* Cross-distro packaging
* Containerized GUI apps
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)
On Fri, Oct 21, 2016 at 1:11 PM, Matthew Miller mattdm@fedoraproject.org wrote:
The startup-scene dev message board Hacker News has an "Ask HN" section, and I used it to ask what developers want from a desktop in 2017. https://news.ycombinator.com/item?id=12703836 Here's a summary of what they said:
Make upgrades painless.
This is often presented as "make it LTS or rolling", but in digging further, it's almost always "I don't want to have to devote a day of downtime to upgrading twice a year".
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.
- 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.
- 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."
- Hardware compatibility just works. (Wifi, sound, HDMI, graphics, suspend, etc.)
Kernel / driver work, getting better every release.
- Mixed DPI multi-monitor support.
Thankfully this got sorted out lately, at least under Gnome.
- 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.
- Cross-distro packaging
Snaps / Flatpaks / AppImage
- Containerized GUI apps
Containerized or just sandboxed? Containerized means docker or LXC, Sandboxed could be the above.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
Hi,
- Make upgrades painless.
hopefully solved by rpm-ostree
- 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.
hopefully solved by a combination of rpm-ostree and flatpak.
- 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
- Hardware compatibility just works. (Wifi, sound, HDMI, graphics, suspend, etc.)
eek.
- Mixed DPI multi-monitor support.
hopefully solved by wayland
- Look nice, better fonts, general usability, etc.
hopefully solved already?
- Cross-distro packaging
flatpak.
- 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
On Fri, 2016-10-21 at 14:55 -0400, Ray Strode wrote:
Hi,
- 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.
- 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
On Fri, 2016-10-21 at 14:05 -0500, Michael Catanzaro wrote:
On Fri, 2016-10-21 at 14:55 -0400, Ray Strode wrote:
Hi,
- 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.
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.
On Fri, 2016-10-21 at 12:09 -0700, Adam Williamson wrote:
On Fri, 2016-10-21 at 14:05 -0500, Michael Catanzaro wrote:
On Fri, 2016-10-21 at 14:55 -0400, Ray Strode wrote:
Hi,
- 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.
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.
On Fri, Oct 21, 2016 at 11:11 AM, Matthew Miller mattdm@fedoraproject.org wrote:
- 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@
On Fri, Oct 21, 2016 at 12:48 PM, Eric Griffith egriffith92@gmail.com wrote:
- 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.
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.
On Fri, Oct 21, 2016 at 11:11 AM, Matthew Miller mattdm@fedoraproject.org wrote:
- 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.
- 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.
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.
- 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!
On Sat, Oct 22, 2016 at 5:55 AM, Peter Robinson pbrobinson@gmail.com wrote:
- 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.
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.
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.
On Fri, Oct 21, 2016 at 12:09:43PM -0700, Adam Williamson wrote:
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.
On Sat, Oct 22, 2016 at 4:51 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Oct 21, 2016 at 12:09:43PM -0700, Adam Williamson wrote:
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.
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.
On 23/10/16 06:39, Chris Murphy wrote:
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.
On Sun, 2016-10-23 at 07:47 +0100, Alexander Bisogiannis wrote:
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.
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
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
On Oct 23, 2016, at 10:49, Monty Montgomery xiphmont@gmail.com wrote:
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.
On Sun, 2016-10-23 at 10:49 -0400, Monty Montgomery wrote:
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
On Sun, Oct 23, 2016 at 12:47 AM, Alexander Bisogiannis alexixor@gmail.com wrote:
On 23/10/16 06:39, Chris Murphy wrote:
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.
I think this email from Lennart still applies: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
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.
On 10/23/2016 10:06 AM, Michael Catanzaro wrote:
On Sun, 2016-10-23 at 07:47 +0100, Alexander Bisogiannis wrote:
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).
On Sat, Oct 22, 2016 at 11:39:05PM -0600, Chris Murphy wrote:
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.
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.
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.
On Sun, Oct 23, 2016 at 09:06:22AM -0500, Michael Catanzaro wrote:
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".
On Sun, Oct 23, 2016 at 11:42:48AM -0500, Michael Catanzaro wrote:
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.
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.
It sounds to me like your single-reboot work is worth continuing. We don't need to support strange edge cases.
Michael
On 10/24/2016 09:21 AM, Michael Catanzaro wrote:
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.
On Fri, Oct 21, 2016, 5:44 PM Chris Murphy lists@colorremedies.com wrote:
On Fri, Oct 21, 2016 at 11:11 AM, Matthew Miller mattdm@fedoraproject.org wrote:
- 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.
<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...
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
On Fri, 21 Oct 2016 20:55:44 +0200, Ray Strode rstrode@redhat.com wrote:
- 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.
On Mon, Oct 24, 2016 at 11:47:55AM -0400, Stephen Gallagher wrote:
On 10/24/2016 09:21 AM, Michael Catanzaro wrote:
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.
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
On Mon, Oct 24, 2016 at 3:46 PM, Liam liam.bulkley@gmail.com wrote:
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.
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.
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Power_profiling...
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.
On Wed, Oct 26, 2016, 12:54 PM Chris Murphy lists@colorremedies.com wrote:
On Mon, Oct 24, 2016 at 3:46 PM, Liam liam.bulkley@gmail.com wrote:
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.
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.
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Power_profiling...
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.
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).
On 10/25/2016 11:46 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Oct 24, 2016 at 11:47:55AM -0400, Stephen Gallagher wrote:
On 10/24/2016 09:21 AM, Michael Catanzaro wrote:
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.
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.
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?
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.
2.0
On Thu, Nov 3, 2016 at 10:35 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 10/25/2016 11:46 AM, Zbigniew Jędrzejewski-Szmek wrote:
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.
2.0
What does "2.0" mean?
josh
On Thu, Nov 3, 2016 at 8:35 AM, Stephen Gallagher sgallagh@redhat.com wrote:
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.targetThis 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
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.
2.0
I thought kexec was disabled for this purpose, at least on UEFI Secure Boot enabled computers?
On 11/03/2016 12:31 PM, Chris Murphy wrote:
On Thu, Nov 3, 2016 at 8:35 AM, Stephen Gallagher sgallagh@redhat.com wrote:
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.targetThis 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?
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?
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.
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.
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.
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
On Fri, Oct 28, 2016 at 12:15 AM, Liam liam.bulkley@gmail.com wrote:
On Wed, Oct 26, 2016, 12:54 PM Chris Murphy lists@colorremedies.com
wrote:
On Mon, Oct 24, 2016 at 3:46 PM, Liam liam.bulkley@gmail.com wrote:
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.
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.
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.
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).
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Thu, Nov 3, 2016 at 7:59 PM, Alex G.S. alxgrtnstrngl@gmail.com wrote:
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.
On Thu, Nov 3, 2016, 10:00 PM Alex G.S. alxgrtnstrngl@gmail.com wrote:
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.
On 04.11.2016 06:42, Liam wrote:
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.
On Thu, 2016-11-03 at 21:59 -0400, Alex G.S. wrote:
Maybe something more traditional like the macOS desktop environment that had similar concepts but built with GNOME technology and Wayland.
So, er...GNOME? ;)
On Fri, Nov 04, 2016 at 08:32:05AM -0700, Adam Williamson wrote:
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.
----- Original Message -----
On Fri, Nov 04, 2016 at 08:32:05AM -0700, Adam Williamson wrote:
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.
----- Original Message -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org 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 -----
On Fri, Nov 04, 2016 at 08:32:05AM -0700, Adam Williamson wrote:
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
On Fri, Nov 4, 2016, 5:12 AM Michael Stahl mstahl@redhat.com wrote:
On 04.11.2016 06:42, Liam wrote:
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).
On 05/11/16 05:45, Liam wrote:
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. :)
On Fri, Oct 21, 2016, 1:11 PM Matthew Miller mattdm@fedoraproject.org wrote:
The startup-scene dev message board Hacker News has an "Ask HN" section, and I used it to ask what developers want from a desktop in 2017. https://news.ycombinator.com/item?id=12703836 Here's a summary of what they said:
Make upgrades painless.
This is often presented as "make it LTS or rolling", but in digging further, it's almost always "I don't want to have to devote a day of downtime to upgrading twice a year".
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.
Give the ability to have package X move at a pace I choose. Separate dev stack from base OS.
Hardware compatibility just works. (Wifi, sound, HDMI, graphics, suspend, etc.)
Mixed DPI multi-monitor support.
Look nice, better fonts, general usability, etc.
Cross-distro packaging
Containerized GUI apps
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
“Cross-platform development on Windows is suddenly awesome” @dubya_brian https://medium.com/@bgourlie/cross-platform-development-on-windows-is-sudden...
No pressure, but this isn't helping the development case for Linux.
On Sat, Nov 05, 2016 at 07:33:33AM +0000, Alexander Bisogianis wrote:
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.
On 07/11/16 13:42, Matthew Miller wrote:
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.
On Mon, Nov 07, 2016 at 01:56:35PM +0000, Alexander Bisogianis wrote:
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. :)
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.
On Mon, Nov 7, 2016 at 2:04 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Mon, Nov 07, 2016 at 01:56:35PM +0000, Alexander Bisogianis wrote:
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.
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 mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On 07/11/16 14:34, Peter Robinson wrote:
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.
:)
----- Original Message -----
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).
On 11/07/2016 10:14 AM, Bastien Nocera wrote:
----- Original Message -----
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.
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.
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..."
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.)
On Mon, Nov 07, 2016 at 10:14:57AM -0500, Bastien Nocera wrote:
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.
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.
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.
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).
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.
On Mon, 2016-11-07 at 10:14 -0500, Bastien Nocera wrote:
nobody tested the performance impact of the logo watermark in gnome-shell.
Is there a problem with it?
On Mon, 2016-11-07 at 10:14 -0500, Bastien Nocera wrote:
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....
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
On 07/11/16 08:39 AM, Michael Catanzaro wrote:
On Mon, 2016-11-07 at 10:14 -0500, Bastien Nocera wrote:
nobody tested the performance impact of the logo watermark in gnome-shell.
Is there a problem with it?
On Mon, 2016-11-07 at 10:14 -0500, Bastien Nocera wrote:
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....
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.
On Mon, 2016-11-07 at 10:21 -0800, Luya Tshimbalanga wrote:
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.
On Mon, Nov 07, 2016 at 11:35:55AM -0800, Adam Williamson wrote:
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.
On Sat, Nov 5, 2016, 3:33 AM Alexander Bisogianis alexixor@gmail.com wrote:
On 05/11/16 05:45, Liam wrote:
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".
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.
On Mon, Nov 7, 2016 at 1:19 PM, Liam liam.bulkley@gmail.com wrote:
On Sat, Nov 5, 2016, 3:33 AM Alexander Bisogianis alexixor@gmail.com wrote:
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.
On Mon, Nov 07, 2016 at 10:39:13AM -0600, Michael Catanzaro wrote:
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.... https://www.youtube.com/watch?v=B6n-2t9aUoM ?
(Possibly with a Workstation-specific version?)
On Mon, 2016-11-07 at 16:52 -0500, Matthew Miller wrote:
Hmmm.... https://www.youtube.com/watch?v=B6n-2t9aUoM%C2%A0?
(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
On 07/11/16 21:19, Liam wrote:
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 :)
On Mon, Nov 07, 2016 at 04:00:46PM -0600, Michael Catanzaro wrote:
Hmmm.... https://www.youtube.com/watch?v=B6n-2t9aUoM%C2%A0? (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....
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.
On Mon, 2016-11-07 at 13:30 -0800, Chris Murphy wrote:
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.
On Mon, 2016-11-07 at 16:00 -0600, Michael Catanzaro wrote:
On Mon, 2016-11-07 at 16:52 -0500, Matthew Miller wrote:
Hmmm.... https://www.youtube.com/watch?v=B6n-2t9aUoM%C2%A0?
(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...
On 07/11/16 01:52 PM, Matthew Miller wrote:
On Mon, Nov 07, 2016 at 10:39:13AM -0600, Michael Catanzaro wrote:
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.... https://www.youtube.com/watch?v=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?
On Nov 7, 2016, at 17:06, Alexander Bisogianis alexixor@gmail.com wrote:
On 07/11/16 21:19, Liam wrote: 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).
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.
- 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.
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.
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.
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.
On Mon, Nov 7, 2016 at 4:37 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2016-11-07 at 13:30 -0800, Chris Murphy wrote:
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.
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.
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.
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?
----- Original Message -----
On 11/07/2016 10:14 AM, Bastien Nocera wrote:
----- Original Message -----
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.
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.
Prominent? I attached the screenshot. It's prominent because there's nothing else on the screen, sure.
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).
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.
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
"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.
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".
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.
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?
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.
----- Original Message -----
On Mon, Nov 07, 2016 at 10:14:57AM -0500, Bastien Nocera wrote:
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 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.
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.
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.
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.
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.
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.
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).
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
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.
And I think we already agreed that nobody likes the wallpaper overlay.
Great, let's get rid of that too then.
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.
----- Original Message -----
On Mon, Nov 07, 2016 at 10:39:13AM -0600, Michael Catanzaro wrote:
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.... https://www.youtube.com/watch?v=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.
On Tue, 2016-11-08 at 06:01 -0500, Bastien Nocera wrote:
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 Tue, Nov 8, 2016 at 1:14 AM, Chris Murphy lists@colorremedies.com wrote:
On Mon, Nov 7, 2016 at 4:37 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2016-11-07 at 13:30 -0800, Chris Murphy wrote:
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.
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
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.
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.
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.
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
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.
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
">> adamwill@fedoraproject.org wrote:
On Mon, 2016-11-07 at 13:30 -0800, Chris Murphy wrote:
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.
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
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.
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.
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.
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
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.
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
On Tue, 2016-11-08 at 05:16 -0600, Michael Catanzaro wrote:
On Tue, 2016-11-08 at 06:01 -0500, Bastien Nocera wrote:
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.)
----- Original Message ----- <snip>
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.
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.
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.
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 -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org 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 -----
On 11/07/2016 10:14 AM, Bastien Nocera wrote:
----- Original Message -----
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.
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.
Prominent? I attached the screenshot. It's prominent because there's nothing else on the screen, sure.
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).
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.
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
"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.
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".
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.
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?
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. _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
----- Original Message -----
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.
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)
----- Original Message -----
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.
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.
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.
On 11/08/2016 06:01 AM, Bastien Nocera wrote:
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.
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.
On Tue, Nov 08, 2016 at 06:02:05AM -0500, Bastien Nocera wrote:
Hmmm.... https://www.youtube.com/watch?v=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.
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.
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 -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org 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 -----
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.
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.
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 -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
----- Original Message -----
On 11/08/2016 06:01 AM, Bastien Nocera wrote:
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.
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.
You can run it with as good an integration as Fedora on... well, Fedora and spins/remixes.
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.
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.
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].
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 :)
----- Original Message -----
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.
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.
On 11/08/2016 10:43 AM, Bastien Nocera wrote:
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.
----- Original Message -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org 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 -----
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.
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.
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 -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Tue, Nov 08, 2016 at 10:16:48AM -0500, Christian Schaller wrote:
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*.
----- Original Message ----- <snip>
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>
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?
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
On Mon, 2016-11-07 at 22:51 +0000, Micah Denn wrote:
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.
----- Original Message ----- <snip>
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.
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.
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.
That's a refreshing (and soothing) stance.
----- Original Message -----
On Mon, 2016-11-07 at 22:51 +0000, Micah Denn wrote:
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.
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.
On Tue, 2016-11-08 at 11:28 -0500, Bastien Nocera wrote:
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
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 -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org 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> > > 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.
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.
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.
That's a refreshing (and soothing) stance. _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Nov 8, 2016, at 11:12, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, 2016-11-07 at 22:51 +0000, Micah Denn wrote: 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.
Then why do we opt for a generic black background for grub?
----- Original Message -----
On Nov 8, 2016, at 11:12, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, 2016-11-07 at 22:51 +0000, Micah Denn wrote: 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.
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).
On 08/11/16 16:49, Bastien Nocera wrote:
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?
----- Original Message -----
On 08/11/16 16:49, Bastien Nocera wrote:
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?
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 ;)
On 08/11/16 16:56, Bastien Nocera wrote:
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 ;)
There could be a delay of say 3-5 seconds, with grub hidden, so if we fail to boot people have a change to react. In any case, I bet that 90% of the people with failed boots will try to boot from USB/CD to a live session.
If you are talking about Macbooks and such, I believe that Workstation should also consider limiting itself to say Thinkpads, maybe X, W and T series. This way the OS can be a lot better coupled with the H/W and the testing scope is a lot more focused.
There is nothing wrong with that, and IMO it would be very well received by the community in general.
On Tue, Nov 08, 2016 at 05:08:26PM +0000, Alexander Bisogianis wrote:
If you are talking about Macbooks and such, I believe that Workstation should also consider limiting itself to say Thinkpads, maybe X, W and T series. This way the OS can be a lot better coupled with the H/W and the testing scope is a lot more focused.
That's an interesting idea. I'd be wary of doing it without a formal partnership with the hardware vendor, though, because without it we have no guarantee that they don't just change everything from underneath us.
On Tue, 2016-11-08 at 11:40 -0500, Eric Griffith wrote:
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.
Then why do we opt for a generic black background for grub?
We don't, we opt for console mode for grub. This is because last time we tried using the graphical mode by default, we had too many bugs with it; IIRC, a few systems where grub wasn't visible at all, and quite a lot where it was very, very slow.
On Tue, 2016-11-08 at 17:08 +0000, Alexander Bisogianis wrote:
On 08/11/16 16:56, Bastien Nocera wrote:
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 ;)
There could be a delay of say 3-5 seconds, with grub hidden, so if we fail to boot people have a change to react.
This is actually exactly what we did a long time ago in the case of single-boot installs. I don't remember precisely what changed.
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 ;)
There could be a delay of say 3-5 seconds, with grub hidden, so if we fail to boot people have a change to react.
This is actually exactly what we did a long time ago in the case of single-boot installs. I don't remember precisely what changed.
I seem to remember it was something to do with the move to grub2
----- Original Message -----
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.
At https://wiki.gnome.org/Design/OS/DownstreamBranding you'll find the start of lists for downstream branding possibilities. If you know of other branding used in distributions, or new ideas, please feel free to add those (or mail me privately if you don't have a GNOME Wiki account).
Cheers
On Tue, 2016-11-08 at 16:52 +0000, Alexander Bisogianis wrote:
Why show grub in the first place, especially if Fedora is the only OS on the disk?
The designs are quite clear that GRUB should only be shown if there are multiple operating systems installed. In particular, we should never show rescue kernels in the boot list (unless someone wants to do all the work required to make those entries show up only when we're sure the main kernel is broken).
Michael
On Tue, Nov 08, 2016 at 12:22:31PM -0500, Bastien Nocera wrote:
At https://wiki.gnome.org/Design/OS/DownstreamBranding you'll find the start of lists for downstream branding possibilities. If you know of other branding used in distributions, or new ideas, please feel free to add those (or mail me privately if you don't have a GNOME Wiki account).
Thanks Bastien. This seems constructive. Would you consider changing "does not impact on the visual identity" to something like "provide a distinct visual identity which works in harmony with the GNOME visual identity and user experience"?
On 11/08/2016 12:34 PM, Matthew Miller wrote:
On Tue, Nov 08, 2016 at 12:22:31PM -0500, Bastien Nocera wrote:
At https://wiki.gnome.org/Design/OS/DownstreamBranding you'll find the start of lists for downstream branding possibilities. If you know of other branding used in distributions, or new ideas, please feel free to add those (or mail me privately if you don't have a GNOME Wiki account).
Thanks Bastien. This seems constructive. Would you consider changing "does not impact on the visual identity" to something like "provide a distinct visual identity which works in harmony with the GNOME visual identity and user experience"?
As an aside, can we try to get "default hostname" off the list? I've actually been trying to push for eliminating the default hostname in favor of a randomly-generated valid name so that we can play better with FreeIPA and AD environments. (Clients of those systems must always have unique names; conflicts cause hard-to-debug issues).
One such reference: https://github.com/rhinstaller/anaconda/pull/164 (the implementation is mostly abandoned at this point, but the purpose is unchanged)
Or, if it is determined that this is important to do, can we try for something like "fedora-UUID" as a default hostname, so it's at least unique? Of course, the problem with that becomes that you end up with stupidly-long names on the default command prompt, which looks ugly. But perhaps it would be okay to just change the default command prompt not to show the full hostname (or auto-truncate it or something).
On Nov 8, 2016, at 12:12, Adam Williamson adamwill@fedoraproject.org wrote:
On Tue, 2016-11-08 at 11:40 -0500, Eric Griffith wrote:
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.
Then why do we opt for a generic black background for grub?
We don't, we opt for console mode for grub. This is because last time we tried using the graphical mode by default, we had too many bugs with it; IIRC, a few systems where grub wasn't visible at all, and quite a lot where it was very, very slow.
Wouldn't that situation have likely changed since UEFI and the emphasis on graphics even very early at boot?
On Nov 8, 2016, at 12:26, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Tue, 2016-11-08 at 16:52 +0000, Alexander Bisogianis wrote: Why show grub in the first place, especially if Fedora is the only OS on the disk?
The designs are quite clear that GRUB should only be shown if there are multiple operating systems installed. In particular, we should never show rescue kernels in the boot list (unless someone wants to do all the work required to make those entries show up only when we're sure the main kernel is broken).
What about doing what every single other distro does and have a "Advanced Options for $distro" option? I was reviewing Kubuntu a year or so ago and saw something I really loved, at least on UEFI installs, they added a "System Setup" grub option for dropping you back into the firmware config.
On Nov 8, 2016, at 12:43, Stephen Gallagher sgallagh@redhat.com wrote:
On 11/08/2016 12:34 PM, Matthew Miller wrote:
On Tue, Nov 08, 2016 at 12:22:31PM -0500, Bastien Nocera wrote: At https://wiki.gnome.org/Design/OS/DownstreamBranding you'll find the start of lists for downstream branding possibilities. If you know of other branding used in distributions, or new ideas, please feel free to add those (or mail me privately if you don't have a GNOME Wiki account).
Thanks Bastien. This seems constructive. Would you consider changing "does not impact on the visual identity" to something like "provide a distinct visual identity which works in harmony with the GNOME visual identity and user experience"?
As an aside, can we try to get "default hostname" off the list? I've actually been trying to push for eliminating the default hostname in favor of a randomly-generated valid name so that we can play better with FreeIPA and AD environments. (Clients of those systems must always have unique names; conflicts cause hard-to-debug issues).
One such reference: https://github.com/rhinstaller/anaconda/pull/164 (the implementation is mostly abandoned at this point, but the purpose is unchanged)
Or, if it is determined that this is important to do, can we try for something like "fedora-UUID" as a default hostname, so it's at least unique? Of course, the problem with that becomes that you end up with stupidly-long names on the default command prompt, which looks ugly. But perhaps it would be okay to just change the default command prompt not to show the full hostname (or auto-truncate it or something)
What about $CompVendor-$SerialNumber ? Serial numbers should be unique, and I thought they were accessible to the OS via the firmware.
On 07/11/16 10:14 PM, Chris Murphy wrote:
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?
I can bring an example of the broken hotkeys on some laptops which I thought Fedora kernel could fix and was suggested to report upstream. One of upstream Linux kernel developers even temporarily brought the laptop in question (in my case Asus X550ZE) for debugging. We discovered a new boot scheme method from BIOS/UEFI vendors used by Windows 8.1 and onward, we realized how far behind the Linux kernel was for years.
To be fair, one of issues on Linux kernel development are manpower. Without the involvement from the reporters, developers would have hard time figured out the problem.
The good news is the fix just landed on the main kernel branch, https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2...
which should be available in Rawhide in a few days. Hopefully affected laptops notably ASUS model will regain their hotkeys functions. I just closed the year reported bug: https://bugzilla.redhat.com/show_bug.cgi?id=1206862
On Tue, 2016-11-08 at 13:18 -0500, Eric Griffith wrote:
On Nov 8, 2016, at 12:12, Adam Williamson adamwill@fedoraproject.org wrote:
On Tue, 2016-11-08 at 11:40 -0500, Eric Griffith wrote:
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.
Then why do we opt for a generic black background for grub?
We don't, we opt for console mode for grub. This is because last time we tried using the graphical mode by default, we had too many bugs with it; IIRC, a few systems where grub wasn't visible at all, and quite a lot where it was very, very slow.
Wouldn't that situation have likely changed since UEFI and the emphasis on graphics even very early at boot?
Possibly. It's worth trying again. There are still many non-UEFI systems out there, though, and people who do BIOS installs to UEFI systems because they think UEFI is the devil's work (or just can't be bothered with it).
On 11/08/2016 01:23 PM, Eric Griffith wrote:
On Nov 8, 2016, at 12:43, Stephen Gallagher sgallagh@redhat.com wrote:
Or, if it is determined that this is important to do, can we try for something like "fedora-UUID" as a default hostname, so it's at least unique? Of course, the problem with that becomes that you end up with stupidly-long names on the default command prompt, which looks ugly. But perhaps it would be okay to just change the default command prompt not to show the full hostname (or auto-truncate it or something)
What about $CompVendor-$SerialNumber ? Serial numbers should be unique, and I thought they were accessible to the OS via the firmware.
The problem with that approach is that it won't work for a virtual machine, unless all of the virtual machine technologies started generating serial numbers for their virtual clients.
So we would need to have a fallback solution in that case no matter what. At that point, I'm not sure there's value in having a special case for physical hardware.
So, this "branding" is for what purpose?
If it is for strengthen the marketing, I think (at least at this point in time) that the better would be focusing in making Fedora "that 'linux' where everything works and I can do my stuff", and, after, "that really cool computer system where I can do really cool stuff".
If it is for a instantly recognizable visual identity, then you inevitably stay hostage of the thing that draws things on the screen (GNOME Shell, for Fedora Workstation). The only way around is to put a logo in the face of the user (GNOME Shell's top bar, because the Wallpaper can easily - and will - be changed).
So, my suggestion to this topic would be:
1- Keep (really) focusing (harder) on making Fedora "doesn't suck". 2- Put a (symbolic, 1 color) Fedora logo somewhere in the GNOME Shell's top bar (like macOS, like Windows 10's bottom bar, like Ubuntu's left bar, [...]). 3- Remove logo from default wallpaper.
I would say though that focusing on having a logo is limiting our approach in my opinion. You quickly recognize a Ubuntu screenshot due to their orange theme for instance, or a mac screenshot due to those 3 red, yellow, green buttons on their window decorations. So even without looking at the logos you quickly identify those systems when you see them.
Christian
----- Original Message -----
From: "Diogo Campos" diogocamposwd@gmail.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Tuesday, November 8, 2016 2:37:50 PM Subject: Re: Fedora Branding - Re: I asked Hacker News what developers want from a desktop, and this is what they said
So, this "branding" is for what purpose?
If it is for strengthen the marketing, I think (at least at this point in time) that the better would be focusing in making Fedora "that 'linux' where everything works and I can do my stuff", and, after, "that really cool computer system where I can do really cool stuff".
If it is for a instantly recognizable visual identity, then you inevitably stay hostage of the thing that draws things on the screen (GNOME Shell, for Fedora Workstation). The only way around is to put a logo in the face of the user (GNOME Shell's top bar, because the Wallpaper can easily - and will - be changed).
So, my suggestion to this topic would be:
1- Keep (really) focusing (harder) on making Fedora "doesn't suck". 2- Put a (symbolic, 1 color) Fedora logo somewhere in the GNOME Shell's top bar (like macOS, like Windows 10's bottom bar, like Ubuntu's left bar, [...]). 3- Remove logo from default wallpaper.
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Tue, Nov 8, 2016, 9:43 AM Stephen Gallagher sgallagh@redhat.com wrote:
On 11/08/2016 12:34 PM, Matthew Miller wrote:
On Tue, Nov 08, 2016 at 12:22:31PM -0500, Bastien Nocera wrote:
At https://wiki.gnome.org/Design/OS/DownstreamBranding you'll find the start of lists for downstream branding possibilities. If you know of other branding used in distributions, or new ideas, please feel free to add those (or mail me privately if you don't have a GNOME Wiki account).
Thanks Bastien. This seems constructive. Would you consider changing "does not impact on the visual identity" to something like "provide a distinct visual identity which works in harmony with the GNOME visual identity and user experience"?
As an aside, can we try to get "default hostname" off the list? I've actually been trying to push for eliminating the default hostname in favor of a randomly-generated valid name so that we can play better with FreeIPA and AD environments. (Clients of those systems must always have unique names; conflicts cause hard-to-debug issues).
One such reference: https://github.com/rhinstaller/anaconda/pull/164 (the implementation is mostly abandoned at this point, but the purpose is unchanged)
Or, if it is determined that this is important to do, can we try for something like "fedora-UUID" as a default hostname, so it's at least unique?
Or a UUID fragment? It just 6 characters from /dev/urandom? A full UUID is unwieldily long.
Chris Murphy
2016-11-08 17:43 GMT-02:00 Christian Schaller cschalle@redhat.com:
I would say though that focusing on having a logo is limiting our approach in my opinion.
Sure.
It's only a quick solution to the "they need to recognize Fedora just by looking at the screen but the wallpaper overlay is crap" purpose.
You quickly recognize a Ubuntu screenshot due to their orange theme for instance, or a mac screenshot due to those 3 red, yellow, green buttons on their window decorations. So even without looking at the logos you quickly identify those systems when you see them.
And you quickly recognize GNOME, too.
Point is: mac's screen is mac exclusive, Ubuntu's screen is (almost) Ubuntu exclusive, but Fedora's screen is not Fedora exclusive (GNOME).
So, the detailed issue is to differentiate Fedora's GNOME from OtherOS's GNOME. For this, a logo and/or a theme come to my mind, and, as said above, probably a logo in the top bar would be the 'solution to this purpose' that uses less human resources, so that the few people available can focus on (and cooperate, and fix) more urgent issues (if they judge this way, of course).
On 11/08/2016 02:46 PM, Chris Murphy wrote:
On Tue, Nov 8, 2016, 9:43 AM Stephen Gallagher <sgallagh@redhat.com mailto:sgallagh@redhat.com> wrote:
On 11/08/2016 12:34 PM, Matthew Miller wrote: > On Tue, Nov 08, 2016 at 12:22:31PM -0500, Bastien Nocera wrote: >> At https://wiki.gnome.org/Design/OS/DownstreamBranding you'll find >> the start of lists for downstream branding possibilities. If you know >> of other branding used in distributions, or new ideas, please feel >> free to add those (or mail me privately if you don't have a GNOME >> Wiki account). > > Thanks Bastien. This seems constructive. Would you consider changing > "does not impact on the visual identity" to something like "provide a > distinct visual identity which works in harmony with the GNOME visual > identity and user experience"? > As an aside, can we try to get "default hostname" off the list? I've actually been trying to push for eliminating the default hostname in favor of a randomly-generated valid name so that we can play better with FreeIPA and AD environments. (Clients of those systems must always have unique names; conflicts cause hard-to-debug issues). One such reference: https://github.com/rhinstaller/anaconda/pull/164 (the implementation is mostly abandoned at this point, but the purpose is unchanged) Or, if it is determined that this is important to do, can we try for something like "fedora-UUID" as a default hostname, so it's at least unique?Or a UUID fragment? It just 6 characters from /dev/urandom? A full UUID is unwieldily long.
True, but in order to address the problem above, it needs to be at least long enough that it's unlikely to recur within an organization, at least. I doubt six characters is enough entropy for that. Windows uses WIN-XXXXXXXXXXX (11 random case-insensitive characters) so that with that an the first four characters it stays under the 16-char limit for the main hostname component.
In order for our systems to work out of the box as clients of Active Directory, we also need to keep to that same limit. We also want to maximize the randomness to ensure that we are unlikely to hit collisions.
The obvious answer could be to use FED-XXXXXXXXXXX which would be the same as Windows. Or we could opt to sacrifice three characters worth of entropy in exchange for using the whole word: FEDORA-XXXXXXXX. In the first case, we would have a 1 in 1.3x10^17 chance of colliding (assuming perfect random number generation). In the second case, it would be 1 in ~2.2x10^12.
Given the size of those numbers, I think FEDORA-XXXXXXXX is probably entirely reasonable.
On Tue, Nov 08, 2016 at 10:23:39AM -0500, Bastien Nocera wrote:
On 11/08/2016 06:01 AM, Bastien Nocera wrote:
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.
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.
You can run it with as good an integration as Fedora on... well, Fedora and spins/remixes.
That's a valid point. Ubuntu is Unity, and Debian's popcon indicates only 30% installations have gnome-shell. But Fedora has gnome-shell in majority of installations, so it's justified to say that Fedora is Gnome, and Gnome is Fedora.
I don't see what the big issue about the background logo is: it is small, unobtrusive, and a lot like a sticker ;) So yeah, let's work on the best possible integration of Gnome and Fedora, and not attach too much weight to details like that: after all it's not something that users complain about.
Zbyszek
On Tue, Nov 8, 2016 at 4:45 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Nov 8, 2016 at 1:14 AM, Chris Murphy lists@colorremedies.com wrote:
On Mon, Nov 7, 2016 at 4:37 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2016-11-07 at 13:30 -0800, Chris Murphy wrote:
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.
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
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.
I'd expect the biggest difference to come from use cases with high idle state. If the CPU or GPU aren't in lower idle states, it'll eat up battery a lot faster.
And that's what I see on the Mac, maybe 2.5 hours Fedora and 4.5 hours macOS. Terminal, texteditor, web browser looking at static pages with minimal content, using the same ad blockers in the same build version of FireFox. My suspicion, since top on both OS's shows about the same idleness, is the discrete GPU isn't being turned off when it could be on Fedora, where it is automatically on macOS.
Over on the HP, it's the same workloads as the Mac, and I get pretty much the same useful life whether Windows or Fedora - but the sample size for Windows is pretty small due largely to the fact it was blown away in the first week.
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.
I don't understand this. Are you saying that the bug report lacks basic system information attachments? It lacks specific problem data collection attachments? Or that there are problems for which the user can't help upstream, upstream must have physical access to the hardware?
Every hardware related bug report I've looked at on kernel.org, developers routinely ask users for rather obscure information from the system. The system has this information, but there's nothing that helps automate its collection and attachment to the bug report. The user then has to manually collect what's asked for, and then manually attach it to the bug report. I see a significant minority of bug reports where a developer asks for more information and there's never a response again from the user.
This isn't possible with Apple's bug reporter. System information reports are required attachments, and it contains a lot of information including power management states, the power management log, system log, and so on.
Chris Murphy píše v Po 07. 11. 2016 v 13:30 -0800:
On Mon, Nov 7, 2016 at 1:19 PM, Liam liam.bulkley@gmail.com wrote:
On Sat, Nov 5, 2016, 3:33 AM Alexander Bisogianis <alexixor@gmail.c om> wrote:
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.
One anecdote: I upgraded my sister's Macbook to Sierra and guess what happened... suspend stopped working :) Moreover there was one process using 80% of CPU all the time which made the system unusable. Based on the fact that I found dozens of pages about the problem I suspect it's a common bug. It was easily solvable for me, but nothing my sister herself could cope with. So the Mac world is not all ideal, it has bugs, quite a few bugs. For example, upgrade of my work laptop to Fedora 25 was, in fact, much less disruptive than the upgrade to Sierra.
Battery life really depends on model. When I got a brand-new ThinkPad X240 it lasted 10-12 hours of normal usage on battery, up to 16 hours in the airplane mode. I don't find that too bad. Of course, if you buy a laptop which was built for and only for another OS (e.g. Macbook), it's hard to achieve the same level of power management with a different OS.
Jiri
On Tue, Nov 8, 2016 at 8:30 PM, Chris Murphy lists@colorremedies.com wrote:
On Tue, Nov 8, 2016 at 4:45 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Nov 8, 2016 at 1:14 AM, Chris Murphy lists@colorremedies.com wrote:
On Mon, Nov 7, 2016 at 4:37 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2016-11-07 at 13:30 -0800, Chris Murphy wrote:
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.
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
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.
I'd expect the biggest difference to come from use cases with high idle state. If the CPU or GPU aren't in lower idle states, it'll eat up battery a lot faster.
And that's what I see on the Mac, maybe 2.5 hours Fedora and 4.5 hours macOS. Terminal, texteditor, web browser looking at static pages with minimal content, using the same ad blockers in the same build version of FireFox. My suspicion, since top on both OS's shows about the same idleness, is the discrete GPU isn't being turned off when it could be on Fedora, where it is automatically on macOS.
Your suspicion is likely correct. Hybrid graphics is a known problem. Also "the Mac" still covers a continually increasing set of hardware.
Over on the HP, it's the same workloads as the Mac, and I get pretty much the same useful life whether Windows or Fedora - but the sample size for Windows is pretty small due largely to the fact it was blown away in the first week.
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.
I don't understand this. Are you saying that the bug report lacks basic system information attachments? It lacks specific problem data collection attachments? Or that there are problems for which the user can't help upstream, upstream must have physical access to the hardware?
I'm saying getting the low-hanging fruit of basic system information is not the problem. It is getting access to similar hardware and the data around what the workload that is difficult.
Every hardware related bug report I've looked at on kernel.org, developers routinely ask users for rather obscure information from the system. The system has this information, but there's nothing that helps automate its collection and attachment to the bug report. The
Ubuntu collects basically a billion pieces of information. It makes the bug report ridiculous. RHEL has something called sosreport which collects similar information but tars it up as an attachment. That's a bit better.
user then has to manually collect what's asked for, and then manually attach it to the bug report. I see a significant minority of bug reports where a developer asks for more information and there's never a response again from the user.
That's related what I'm talking about. The reporting of the bug is not the problem. It's the continued follow through from both user and developer that is. A developer is not going to magically fix a PM bug on a machine they don't have when they can't get feedback and information from a user.
This isn't possible with Apple's bug reporter. System information reports are required attachments, and it contains a lot of information including power management states, the power management log, system log, and so on.
Yeah, that's something we can do but it won't actually solve the problems. It'll just lower the RTT on the initial triage.
josh
On Tue, Nov 08, 2016 at 03:31:51PM -0500, Stephen Gallagher wrote:
Given the size of those numbers, I think FEDORA-XXXXXXXX is probably entirely reasonable.
Agreed. "FED-" is too ambiguous. "FEDORA-", or even better "Fedora-" is much nicer.
The obvious answer could be to use FED-XXXXXXXXXXX which would be the same as Windows. Or we could opt to sacrifice three characters worth of entropy in exchange for using the whole word: FEDORA-XXXXXXXX. In the first case, we would have a 1 in 1.3x10^17 chance of colliding (assuming perfect random number generation). In the second case, it would be 1 in ~2.2x10^12.
We can also use (non-repeating) "-" in the random part, which gives 1 in ~2.8x10^12. Fedora does not have that many installations, and note that this only has to be unique within installation, so I think the odds are pretty good.
Zbyszek
----- Original Message -----
On 11/08/2016 12:34 PM, Matthew Miller wrote:
On Tue, Nov 08, 2016 at 12:22:31PM -0500, Bastien Nocera wrote:
At https://wiki.gnome.org/Design/OS/DownstreamBranding you'll find the start of lists for downstream branding possibilities. If you know of other branding used in distributions, or new ideas, please feel free to add those (or mail me privately if you don't have a GNOME Wiki account).
Thanks Bastien. This seems constructive. Would you consider changing "does not impact on the visual identity" to something like "provide a distinct visual identity which works in harmony with the GNOME visual identity and user experience"?
As an aside, can we try to get "default hostname" off the list? I've actually been trying to push for eliminating the default hostname in favor of a randomly-generated valid name so that we can play better with FreeIPA and AD environments. (Clients of those systems must always have unique names; conflicts cause hard-to-debug issues).
One such reference: https://github.com/rhinstaller/anaconda/pull/164 (the implementation is mostly abandoned at this point, but the purpose is unchanged)
Or, if it is determined that this is important to do, can we try for something like "fedora-UUID" as a default hostname, so it's at least unique? Of course, the problem with that becomes that you end up with stupidly-long names on the default command prompt, which looks ugly. But perhaps it would be okay to just change the default command prompt not to show the full hostname (or auto-truncate it or something).
This seems like something that should be an implementation detail. Do you expect the hostname / "device name" in the Details and Sharing panels to show "c244859c-bae5-4d88-a9ef-e70ba9421610" as a hostname?
A device can have multiple hostnames, though I don't quite understand why that randomly generated one would need to be the main user-visible one, whether on the machine itself (as it would show up in bash, in the Details and Sharing panels) and on machines in the same home network (via mDNS services).
So whether or not we change the default hostname and mDNS visible name to "fedora" instead of "localhost" or "linux" or not, I really wouldn't want to see random numbers as a hostname anywhere user-visible.
----- Original Message -----
On Tue, Nov 08, 2016 at 12:22:31PM -0500, Bastien Nocera wrote:
At https://wiki.gnome.org/Design/OS/DownstreamBranding you'll find the start of lists for downstream branding possibilities. If you know of other branding used in distributions, or new ideas, please feel free to add those (or mail me privately if you don't have a GNOME Wiki account).
Thanks Bastien. This seems constructive. Would you consider changing "does not impact on the visual identity" to something like "provide a distinct visual identity which works in harmony with the GNOME visual identity and user experience"?
Making Fedora recognisable doesn't (necessarily) mean having a distinct visual identity, a different one from GNOME.
Most of GNOME's visual identity also has design foundations, they're not gratuitous. Changing the visual identity (as opposed to making something based on GNOME recognisable) means throwing away part of the user testing and holistic approach to the desktop's design (from boot, all the way to the apps).
Making Fedora recognisable doesn't (necessarily) mean having a distinct visual identity, a different one from GNOME.
Then make a compromise and have a Fedora desktop spin dedicated to "pure GNOME". Fedora Workstation would benefit from taking an approach that aligns it with the Windows 10 and macOS desktop experience. It would still be a GNOME based desktop just the "Workstation Shell" would follow a different metaphor. This wouldn't be any different from what Elementary, Solus and Endless Mobile have done for their own respective use-cases.
Most of GNOME's visual identity also has design foundations, they're not gratuitous. Changing the visual identity (as opposed to making something based on GNOME recognisable) means throwing away part of the user testing and holistic approach to the desktop's design (from boot, all the way to the apps).
Actually agree there's a huge amount of value there and the HIG should be used a guideline but it's about having the freedom to ask questions, imagine possibilities and explore different paths.
On Tue, Nov 15, 2016 at 11:28 AM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On Tue, Nov 08, 2016 at 12:22:31PM -0500, Bastien Nocera wrote:
At https://wiki.gnome.org/Design/OS/DownstreamBranding you'll find the start of lists for downstream branding possibilities. If you know of other branding used in distributions, or new ideas, please feel free to add those (or mail me privately if you don't have a GNOME Wiki account).
Thanks Bastien. This seems constructive. Would you consider changing "does not impact on the visual identity" to something like "provide a distinct visual identity which works in harmony with the GNOME visual identity and user experience"?
Making Fedora recognisable doesn't (necessarily) mean having a distinct visual identity, a different one from GNOME.
Most of GNOME's visual identity also has design foundations, they're not gratuitous. Changing the visual identity (as opposed to making something based on GNOME recognisable) means throwing away part of the user testing and holistic approach to the desktop's design (from boot, all the way to the apps). _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On Wed, Nov 16, 2016 at 12:59 PM, Alex G.S. alxgrtnstrngl@gmail.com wrote:
Making Fedora recognisable doesn't (necessarily) mean having a distinct visual identity, a different one from GNOME.
Then make a compromise and have a Fedora desktop spin dedicated to "pure GNOME". Fedora Workstation would benefit from taking an approach that aligns it with the Windows 10 and macOS desktop experience. It would still be a GNOME based desktop just the "Workstation Shell" would follow a different metaphor. This wouldn't be any different from what Elementary, Solus and Endless Mobile have done for their own respective use-cases.
I am not convinced the Fedora project has a sufficient contributor base to make essentially two Gnome-based spins at the quality either would like to have. It would be diluting the limited resources we already have around testing and integration.
josh
On Wed, Nov 16, 2016 at 01:07:05PM -0500, Josh Boyer wrote:
On Wed, Nov 16, 2016 at 12:59 PM, Alex G.S. alxgrtnstrngl@gmail.com wrote:
Making Fedora recognisable doesn't (necessarily) mean having a distinct visual identity, a different one from GNOME.
Then make a compromise and have a Fedora desktop spin dedicated to "pure GNOME". Fedora Workstation would benefit from taking an approach that aligns it with the Windows 10 and macOS desktop experience. It would still be a GNOME based desktop just the "Workstation Shell" would follow a different metaphor. This wouldn't be any different from what Elementary, Solus and Endless Mobile have done for their own respective use-cases.
I am not convinced the Fedora project has a sufficient contributor base to make essentially two Gnome-based spins at the quality either would like to have. It would be diluting the limited resources we already have around testing and integration.
Agreed. This branch of discussion is going afield of the specific question of Fedora brand recognition IMHO.
On Tue, Nov 15, 2016 at 11:28:45AM -0500, Bastien Nocera wrote:
Making Fedora recognisable doesn't (necessarily) mean having a distinct visual identity, a different one from GNOME.
I'm having trouble understanding what this means. Can you give an example?
Most of GNOME's visual identity also has design foundations, they're not gratuitous. Changing the visual identity (as opposed to making something based on GNOME recognisable) means throwing away part of the user testing and holistic approach to the desktop's design (from boot, all the way to the apps).
"Throwing away" seems a little dramatic. I get the importance of design. Building and reinforcing the Fedora brand is a marketing requirement — one of the things the design needs to accomplish. If it does not do that, it isn't succeeding.
I agree that user testing is an important part, in any case. I'd like to see a lot more of it.
<snip>
user then has to manually collect what's asked for, and then manually
attach it to the bug report. I see a significant minority of bug reports where a developer asks for more information and there's never a response again from the user.
That's related what I'm talking about. The reporting of the bug is not the problem. It's the continued follow through from both user and developer that is. A developer is not going to magically fix a PM bug on a machine they don't have when they can't get feedback and information from a user.
It is a melancholy object to those who browse through our great zilla of bugs or render their regards unto the pamphlets of their peers, when they then see the sites, the feeds, and gazetteer on the corner, crowded with congeries of the converted, followed by three, four, or six choruses, all in rage, and importuning every soul for their allegiance. These hierophants, instead of being able to work for their honest livelihood, are forced to employ all their time in weeding their beds while having to beg assistance for their plightless cause: who as they mature either turn management for want of work, or leave their dear native country to fight for the Lord of Redmond, or sell themselves to the Cupertinoes.
I shall now therefore humbly propose my own thoughts, which I hope will not be liable to the least objection.
Just for bug reports submitted via abrt (or whatever might replace it), might we not offer an opt-in service whereby the reporter can communicate with the developer uniquely via a per bug token. The point of all this is to provide a seamless way for casual users to report bugs and remain in contact.
The biggest change this would induce, and the reason for the opt-in, is that when someone triages the report, they have a direct channel to the reporter via a blessed system notification (assuming the reporter doesn't have a static IP, this would require a phone home to update the ticket with the current IP, though that's not the only way to do this, but these are implementation details). It's the system notification that is the big difference, and that's the thing which is most likely to get a casual user's attention.
Yes, this is a big change, though the development side isn't that complicated, at least from the user to the Fedora side of matters (though, from there, I admit I'm not positive how the bugzilla side would work). It may not even be worth it if the resources don't exist to fix the reported issues.
What it does, imho, is something similar—possibly better—to Windows/macos by providing well integrated service support. It might even be desirable to, eventually, provide a way for a developer to ssh in if the problem is particularly unusual (but for that i think legal would need to be pretty involved) and it doesn't require an account to be created. As it has been mentioned before when this topic has come up, creating an account is rather more onerous than some think, since it's not just the steps involved, or that the person will have yet another account to keep in mind, but that last extra bit of the positive potential barrier they must overcome if they want to report their problem. It's this group—casual users unlikely to have a bugzilla account—who I think is likely the largest group, and I feel we've not done as much as we could to embrace them.
<snip>
user then has to manually collect what's asked for, and then manually attach it to the bug report. I see a significant minority of bug
reports where a developer asks for more information and there's never
a response again from the user.
That's related what I'm talking about. The reporting of the bug is not the problem. It's the continued follow through from both user and developer that is. A developer is not going to magically fix a PM bug on a machine they don't have when they can't get feedback and information from a user.
It is a melancholy object to those who browse through our great zilla of bugs or render their regards unto the pamphlets of their peers, when they then see the sites, the feeds, and gazetteer on the corner, crowded with congeries of the converted, followed by three, four, or six choruses, all in rage, and importuning every soul for their allegiance. These hierophants, instead of being able to work for their honest livelihood, are forced to employ all their time in weeding their beds while having to beg assistance for their plightless cause: who as they mature either turn management for want of work, or leave their dear native country to fight for the Lord of Redmond, or sell themselves to the Cupertinoes.
I shall now therefore humbly propose my own thoughts, which I hope will not be liable to the least objection.
Just for bug reports submitted via abrt (or whatever might replace it), might we not offer an opt-in service whereby the reporter can communicate with the developer uniquely via a per bug token. The point of all this is to provide a seamless way for casual users to report bugs and remain in contact.
The biggest change this would induce, and the reason for the opt-in, is that when someone triages the report, they have a direct channel to the reporter via a blessed system notification (assuming the reporter doesn't have a static IP, this would require a phone home to update the ticket with the current IP, though that's not the only way to do this, but these are implementation details). It's the system notification that is the big difference, and that's the thing which is most likely to get a casual user's attention.
Yes, this is a big change, though the development side isn't that complicated, at least from the user to the Fedora side of matters (though, from there, I admit I'm not positive how the bugzilla side would work). It may not even be worth it if the resources don't exist to fix the reported issues.
What it does, imho, is something similar—possibly better—to Windows/macos by providing well integrated service support. It might even be desirable to, eventually, provide a way for a developer to ssh in if the problem is particularly unusual (but for that i think legal would need to be pretty involved) and it doesn't require an account to be created. As it has been mentioned before when this topic has come up, creating an account is rather more onerous than some think, since it's not just the steps involved, or that the person will have yet another account to keep in mind, but that last extra bit of the positive potential barrier they must overcome if they want to report their problem. It's this group—casual users unlikely to have a bugzilla account—who I think is likely the largest group, and I feel we've not done as much as we could to embrace them.
On Sun, 20 Nov 2016 04:49:54 +0000 Liam liam.bulkley@gmail.com wrote:
...snip...
Just for bug reports submitted via abrt (or whatever might replace it), might we not offer an opt-in service whereby the reporter can communicate with the developer uniquely via a per bug token. The point of all this is to provide a seamless way for casual users to report bugs and remain in contact.
Well, we already have bugzilla that both reporters and developers can communicate on (and also anyone else who is interested).
The biggest change this would induce, and the reason for the opt-in, is that when someone triages the report, they have a direct channel to the reporter via a blessed system notification (assuming the reporter doesn't have a static IP, this would require a phone home to update the ticket with the current IP, though that's not the only way to do this, but these are implementation details). It's the system notification that is the big difference, and that's the thing which is most likely to get a casual user's attention.
What do you mean by 'system notification' ? Some direct pop up dialog? That could be pretty anoying.
Yes, this is a big change, though the development side isn't that complicated, at least from the user to the Fedora side of matters (though, from there, I admit I'm not positive how the bugzilla side would work). It may not even be worth it if the resources don't exist to fix the reported issues.
What it does, imho, is something similar—possibly better—to Windows/macos by providing well integrated service support. It might even be desirable to, eventually, provide a way for a developer to ssh in if the problem is particularly unusual (but for that i think legal would need to be pretty involved) and it doesn't require an account to be created. As it has been mentioned before when this topic has come up, creating an account is rather more onerous than some think, since it's not just the steps involved, or that the person will have yet another account to keep in mind, but that last extra bit of the positive potential barrier they must overcome if they want to report their problem. It's this group—casual users unlikely to have a bugzilla account—who I think is likely the largest group, and I feel we've not done as much as we could to embrace them.
One thing we are planning on doing for them soon is to allow them to login to bugzilla via their fedoraproject.org account. Of course then they have to make one of those if they don't have it, but they won't need to also make a bugzilla account. Might help some folks out.
kevin
On Sun, Nov 20, 2016, 1:12 PM Kevin Fenzi kevin@scrye.com wrote:
On Sun, 20 Nov 2016 04:49:54 +0000 Liam liam.bulkley@gmail.com wrote:
...snip...
Just for bug reports submitted via abrt (or whatever might replace it), might we not offer an opt-in service whereby the reporter can communicate with the developer uniquely via a per bug token. The point of all this is to provide a seamless way for casual users to report bugs and remain in contact.
Well, we already have bugzilla that both reporters and developers can communicate on (and also anyone else who is interested).
If there is interest in this I can draw up a much more detailed proposal but, as I said in the initial post, I have ZERO idea of how to integrate the two changes to the bugzilla side of things. I'm told that the codebase is a cyclopean nightmare-scape full of squamous things with too many limbs and a space that is rather less reliable than the one of common acquaintance. That said, changes may not even be required, as it's possible bugzilla already supports reporter names not associated with a bugzilla account and a way to make easy updates to the reporter's ip (assuming bugzilla even supports raw ip addresses).
This would still use bugzilla (... sorry, I thought I had mentioned that elsewhere). This is targeting the problem—as referenced by Josh—with getting the majority of users to actually both report problems and providing a SEAMLESS way for the developer to get back in touch with the reporter. So, absolutely this is still using bugzilla, but it's changing the way this particular type of user would interact with it.
The biggest change this would induce, and the reason for the opt-in, is that when someone triages the report, they have a direct channel to the reporter via a blessed system notification (assuming the reporter doesn't have a static IP, this would require a phone home to update the ticket with the current IP, though that's not the only way to do this, but these are implementation details). It's the system notification that is the big difference, and that's the thing which is most likely to get a casual user's attention.
What do you mean by 'system notification' ? Some direct pop up dialog? That could be pretty anoying.
That's one of the reasons why it would be opt-in. This is looking to fix a problem that I can attest to having experienced (and can also relay that other contributors to Fedora have as well): making the entire process seamless.
- I encounter a bug and the abrt gui notifies me about it, so I attempt to be a good user and file a report. - Assuming all goes well (hey! I've got an account! but I don't remember my password so into the browser I go...) the report gets filed. - Sometime later I get an email...which I don't see because I get a lot of email, or I don't get a lot of email and only check it occasionally, or I'm just not diligent at checking my email because it's not a place where I do the majority of my communications, etc; and I don't heavily interact with bugzilla, so it's not something my mail client knows to prioritize, assuming it didn't toss it as spam. - For one of those or some other reason, I don't respond to it. In the best case, the bug gets a +1 from other users who then pickup the slack I left. It's more likely that it gets closed automatically after 90 days (or whatever) of no activity when the bug is at the state of needinfo.
To briefly address your concern, this isn't really intended for high volume bug reporters, but people who are "just" users, but who can still help us. And if we can provide a simple, positive experience of a process they may be utterly unaware of, we might provide another avenue that can generate new contributors. Those who are already contributors could also benefit from the simplicity of an integrated process.
Yes, this is a big change, though the development side isn't that complicated, at least from the user to the Fedora side of matters (though, from there, I admit I'm not positive how the bugzilla side would work). It may not even be worth it if the resources don't exist to fix the reported issues.
What it does, imho, is something similar—possibly better—to Windows/macos by providing well integrated service support. It might even be desirable to, eventually, provide a way for a developer to ssh in if the problem is particularly unusual (but for that i think legal would need to be pretty involved) and it doesn't require an account to be created. As it has been mentioned before when this topic has come up, creating an account is rather more onerous than some think, since it's not just the steps involved, or that the person will have yet another account to keep in mind, but that last extra bit of the positive potential barrier they must overcome if they want to report their problem. It's this group—casual users unlikely to have a bugzilla account—who I think is likely the largest group, and I feel we've not done as much as we could to embrace them.
One thing we are planning on doing for them soon is to allow them to login to bugzilla via their fedoraproject.org account. Of course then they have to make one of those if they don't have it, but they won't need to also make a bugzilla account. Might help some folks out.
Yeah, that's really another permutation of this whole issue.
Before, I was making the case regarding one particular type of user (the casual, unengaged one) for which the integrated experience provides as low a barrier as I can reasonably imagine, but there's also the other set of users who do, if they feel up to it, create accounts, file bugs and brave Bugzilla whenever they get an email, but don't always get back to the developer who needinfo.
I would much prefer to just use the one app that I used to submit the report to handle all of these issues. Issues which are really TIED to that particular desktop from which the report came, and not my email account, such can be accessed from any of several devices. My side of the interaction should really only occur if I'm at the computer which was the origin of the report.
On Mon, 21 Nov 2016 22:16:13 +0000 Liam liam.bulkley@gmail.com wrote:
This would still use bugzilla (... sorry, I thought I had mentioned that elsewhere). This is targeting the problem—as referenced by Josh—with getting the majority of users to actually both report problems and providing a SEAMLESS way for the developer to get back in touch with the reporter. So, absolutely this is still using bugzilla, but it's changing the way this particular type of user would interact with it.
So, the idea is to make it easier for the reporter to maintain a dialog with the maintiner(s) by making a more direct interface than a web browser or email client, right? I'm afraid I am skeptical that this will help.
...snip...
- I encounter a bug and the abrt gui notifies me about it, so I
attempt to be a good user and file a report.
- Assuming all goes well (hey! I've got an account! but I don't
remember my password so into the browser I go...) the report gets filed.
- Sometime later I get an email...which I don't see because I get a
lot of email, or I don't get a lot of email and only check it occasionally, or I'm just not diligent at checking my email because it's not a place where I do the majority of my communications, etc; and I don't heavily interact with bugzilla, so it's not something my mail client knows to prioritize, assuming it didn't toss it as spam.
- For one of those or some other reason, I don't respond to it. In
the best case, the bug gets a +1 from other users who then pickup the slack I left. It's more likely that it gets closed automatically after 90 days (or whatever) of no activity when the bug is at the state of needinfo.
Sure, but a pop up dialog bugging me about it sounds a good deal more intrusive than an email.
...snip...
I would much prefer to just use the one app that I used to submit the report to handle all of these issues. Issues which are really TIED to that particular desktop from which the report came, and not my email account, such can be accessed from any of several devices. My side of the interaction should really only occur if I'm at the computer which was the origin of the report.
Perhaps you could approach the abrt folks and see if some of your ideas could be implemented there?
kevin
----- Original Message -----
On Tue, Nov 15, 2016 at 11:28:45AM -0500, Bastien Nocera wrote:
Making Fedora recognisable doesn't (necessarily) mean having a distinct visual identity, a different one from GNOME.
I'm having trouble understanding what this means. Can you give an example?
That, depending on usage, showing a different colour scheme in the default bash prompt, for example, might make Fedora recognisable, without the need to add logos where there weren't any.
Most of GNOME's visual identity also has design foundations, they're not gratuitous. Changing the visual identity (as opposed to making something based on GNOME recognisable) means throwing away part of the user testing and holistic approach to the desktop's design (from boot, all the way to the apps).
"Throwing away" seems a little dramatic. I get the importance of design. Building and reinforcing the Fedora brand is a marketing requirement — one of the things the design needs to accomplish. If it does not do that, it isn't succeeding.
It is "throwing away". Because you literally have to re-do the user testing. Given that very little of it happens in Fedora (or RHEL), that I know of, and most of it upstream, then it means that we invalidate any upstream changes that might have been made, and can't incorporate upstream feedback in the same way either.
I agree that user testing is an important part, in any case. I'd like to see a lot more of it.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On 8 November 2016 at 20:43, Christian Schaller cschalle@redhat.com wrote:
I would say though that focusing on having a logo is limiting our approach in my opinion. You quickly recognize a Ubuntu screenshot due to their orange theme for instance, or a mac screenshot due to those 3 red, yellow, green buttons on their window decorations. So even without looking at the logos you quickly identify those systems when you see them.
Fedora 10 had its own window decorations and icon theme. That has changed and it is fine. Showcasing the original GNOME experience is good and I still believe the logo in the panel [1] an non-disruptive option to consider.
On 15 November 2016 at 17:28, Bastien Nocera bnocera@redhat.com wrote:
Most of GNOME's visual identity also has design foundations, they're not gratuitous. Changing the visual identity (as opposed to making something based on GNOME recognisable) means throwing away part of the user testing and holistic approach to the desktop's design (from boot, all the way to the apps).
The user testing phase here is a bit overestimated. They only tested it once on 7 (seven) people, and the test covered tasks (like setting up the email client), visual identity was hardly elaborated. You can read about the whole process in the blog. Boot screen is fairly independent, and the applications could be left alone.
[1] https://www.linux.org.ru/gallery/13033433.jpg
Misha https://fedoraproject.org/wiki/User:Misha English / Español / Italiano / Русский
----- Original Message -----
On 8 November 2016 at 20:43, Christian Schaller cschalle@redhat.com wrote:
I would say though that focusing on having a logo is limiting our approach in my opinion. You quickly recognize a Ubuntu screenshot due to their orange theme for instance, or a mac screenshot due to those 3 red, yellow, green buttons on their window decorations. So even without looking at the logos you quickly identify those systems when you see them.
Fedora 10 had its own window decorations and icon theme. That has changed and it is fine. Showcasing the original GNOME experience is good and I still believe the logo in the panel [1] an non-disruptive option to consider.
Fedora 10 didn't use GNOME 3.
I also already explained why the logo in the top left corner is problematic (is it a control, is it a menu, is it separate from the activities control?).
Your screenshot is confusing, because you made other changes to your system. You have a menu next to the logo. There's already a logo in our setup where there is a menu there, in the Classic session.
On 15 November 2016 at 17:28, Bastien Nocera bnocera@redhat.com wrote:
Most of GNOME's visual identity also has design foundations, they're not gratuitous. Changing the visual identity (as opposed to making something based on GNOME recognisable) means throwing away part of the user testing and holistic approach to the desktop's design (from boot, all the way to the apps).
The user testing phase here is a bit overestimated. They only tested it once on 7 (seven) people, and the test covered tasks (like setting up the email client), visual identity was hardly elaborated.
Visual identity wasn't explicitly worked on, but changing the visual identity would change controls.
You can read about the whole process in the blog.
What blog?
Boot screen is fairly independent, and the applications could be left alone.
I also explained the reasoning about the boot screen.
On Wed, Nov 23, 2016, 10:29 AM Kevin Fenzi kevin@scrye.com wrote:
On Mon, 21 Nov 2016 22:16:13 +0000 Liam liam.bulkley@gmail.com wrote:
This would still use bugzilla (... sorry, I thought I had mentioned that elsewhere). This is targeting the problem—as referenced by Josh—with getting the majority of users to actually both report problems and providing a SEAMLESS way for the developer to get back in touch with the reporter. So, absolutely this is still using bugzilla, but it's changing the way this particular type of user would interact with it.
So, the idea is to make it easier for the reporter to maintain a dialog with the maintiner(s) by making a more direct interface than a web browser or email client, right? I'm afraid I am skeptical that this will help.
...snip...
That is the core of the idea: removing barriers that prevent people from reporting or following up with reports. A web browser or email client may not seem like much of a barrier, but both require having an account with bugzilla in order to do either. Which is a large enough obstacle to stop plenty of casual users.
- I encounter a bug and the abrt gui notifies me about it, so I
attempt to be a good user and file a report.
- Assuming all goes well (hey! I've got an account! but I don't
remember my password so into the browser I go...) the report gets filed.
- Sometime later I get an email...which I don't see because I get a
lot of email, or I don't get a lot of email and only check it occasionally, or I'm just not diligent at checking my email because it's not a place where I do the majority of my communications, etc; and I don't heavily interact with bugzilla, so it's not something my mail client knows to prioritize, assuming it didn't toss it as spam.
- For one of those or some other reason, I don't respond to it. In
the best case, the bug gets a +1 from other users who then pickup the slack I left. It's more likely that it gets closed automatically after 90 days (or whatever) of no activity when the bug is at the state of needinfo.
Sure, but a pop up dialog bugging me about it sounds a good deal more intrusive than an email.
...snip...
That is why it would be opt in. Again, this is geared toward casual users/reporters who would be getting notifications about one of two bugs at the most.
I would much prefer to just use the one app that I used to submit the report to handle all of these issues. Issues which are really TIED to that particular desktop from which the report came, and not my email account, such can be accessed from any of several devices. My side of the interaction should really only occur if I'm at the computer which was the origin of the report.
Perhaps you could approach the abrt folks and see if some of your ideas could be implemented there?
I guess it wasn't clear, ABRT is exactly what I had in mind for this - an enhancement to ABRT so that it is able to act as the hub for bugs. That's simpler for the user, and, potentially, increases the odds of a filed bug not sitting forever with NEEDINFO.
kevin _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Alex G.S. -
Alexander Bisogianis -
Bastien Nocera -
Chris Murphy -
Christian Schaller -
Diogo Campos -
Eric Griffith -
Jiri Eischmann -
Josh Boyer -
Kevin Fenzi -
Liam -
Luya Tshimbalanga -
Martin Bříza -
Mathieu Bridon -
Matthew Miller -
Micah Denn -
Michael Catanzaro -
Michael Stahl -
Misha S. -
Monty Montgomery -
Paul W. Frields -
Peter Robinson -
Ray Strode -
Stephen Gallagher -
Zbigniew Jędrzejewski-Szmek