Hi,
There's too much confusion or too many bugs to even start filing...
http://flatpak.org/apps.html Click on LibreOffice, the very first link.
Click on that file from within FireFox, and it opens Gnome Software which gives me the option to install. I click install. It counts up from 0% to 84% and then the status bar turns back into an Install button. There's no error message.
LibreOffice is not installed.
[chris@f26h ~]$ flatpak remotes gnome user org.libreoffice.LibreOffice-origin user,no-enumerate
I'm not expecting these to be user installed but rather system installed. This user is an admin and I really don't want every user on this system having to install their own copy of e.g. LibreOffice. My understanding is admin users would have runtimes and apps installed as system not user.
[chris@f26h ~]$ flatpak remote-delete org.libreoffice.LibreOffice
## Gnome shell puts up a modal authentication dialog. I didn't have to authenticate to get to this point, why do I have to authenticate to back out? Anyway, I authenticate and:
error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code1: Remote "org.libreoffice.LibreOffice" not found
[chris@f26h ~]$ flatpak remote-delete gnome ##authenticate dialog error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code1: Remote "gnome" not found
I can't modify these either. So now I'm stuck.
Back in Gnome Software, click on the Install button and it does nothing, no error message.
Hi,
I can't comment on the installation failure, but:
On Sun, Apr 2, 2017 at 7:57 AM Chris Murphy lists@colorremedies.com wrote:
[chris@f26h ~]$ flatpak remotes gnome user org.libreoffice.LibreOffice-origin user,no-enumerate [...] [chris@f26h ~]$ flatpak remote-delete org.libreoffice.LibreOffice
The remote is called "org.libreoffice.LibreOffice-origin" and configured as "user" rather than "system". So I think that
$ flatpak remote-delete --user org.libreoffice.LibreOffice-origin
will work (and not require an authentication dialog either). desktop-leave@lists.fedoraproject.org
Florian
On Sun, Apr 2, 2017 at 2:17 AM, Florian Müllner fmuellner@gnome.org wrote:
Hi,
I can't comment on the installation failure, but:
On Sun, Apr 2, 2017 at 7:57 AM Chris Murphy lists@colorremedies.com wrote:
[chris@f26h ~]$ flatpak remotes gnome user org.libreoffice.LibreOffice-origin user,no-enumerate [...] [chris@f26h ~]$ flatpak remote-delete org.libreoffice.LibreOffice
The remote is called "org.libreoffice.LibreOffice-origin" and configured as "user" rather than "system". So I think that
$ flatpak remote-delete --user org.libreoffice.LibreOffice-origin
OK that's a good hint. [chris@f26h ~]$ flatpak remote-delete --user org.libreoffice.LibreOffice-origin
No error. And then.
[chris@f26h ~]$ flatpak remote-delete --user gnome error: Can't remove remote 'gnome' with installed ref runtime/org.gnome.Platform.Locale/x86_64/3.20 (at least)
[chris@f26h ~]$ flatpak list org.gnome.Platform.Locale/x86_64/3.20 user,runtime org.gnome.Platform/x86_64/3.20 user,runtime [chris@f26h ~]$ flatpak uninstall org.gnome.Platform.Locale --user Uninstalling org.gnome.Platform.Locale/x86_64/3.20 [chris@f26h ~]$ flatpak uninstall org.gnome.Platform --user Uninstalling org.gnome.Platform/x86_64/3.20 [chris@f26h ~]$ flatpak list [chris@f26h ~]$ flatpak remotes gnome user [chris@f26h ~]$ flatpak remote-delete gnome --user
Now things appear to be cleaned up.
- How to troubleshoot the installation of *.flatpakref files when there are no user visible error messages and the journal is unrevealing?
- The current behavior of Gnome Software installs software and runtimes in the user's home, unlike on other platforms where the default is all users get to use app store installed programs and those binaries are stored outside users' home. The Gnome Software behavior is unintuitive, and it makes backup and restore of /home sufficiently complicated that it's going to break people's workflows.
On Sat, 2017-04-01 at 23:57 -0600, Chris Murphy wrote:
[chris@f26h ~]$ flatpak remotes gnome user org.libreoffice.LibreOffice-origin user,no-enumerate
I'm not expecting these to be user installed but rather system installed. This user is an admin and I really don't want every user on this system having to install their own copy of e.g. LibreOffice. My understanding is admin users would have runtimes and apps installed as system not user.
Well we have to figure this out, because my expectation is the opposite: I would expect that all users can have a completely separate set of apps installed. :( This might be a case where having a user- visible preference is desirable since it's not always what you want, for space reasons.
Also: being able to install without authentication but not delete matches our behavior for system packages. I think it's silly to allow users to install stuff but not to remove it, but that's our status quo.
Michael
On Sun, Apr 2, 2017 at 8:44 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Sat, 2017-04-01 at 23:57 -0600, Chris Murphy wrote:
[chris@f26h ~]$ flatpak remotes gnome user org.libreoffice.LibreOffice-origin user,no-enumerate
I'm not expecting these to be user installed but rather system installed. This user is an admin and I really don't want every user on this system having to install their own copy of e.g. LibreOffice. My understanding is admin users would have runtimes and apps installed as system not user.
Well we have to figure this out, because my expectation is the opposite: I would expect that all users can have a completely separate set of apps installed. :(
I don't see the upside. And it's not consistent with other platform: Windows, macOS or Android.
There's a distinction to be made between where apps are installed, and how they're presented. Certainly they can be stored in a way that make them available to all users, even if they aren't visible.
For example user "chris" installs LibreOffice for the first time, and that means a bunch of binaries are downloaded and installed at a system level. When user "larry" goes to Gnome Software to install LibreOffice, Gnome Software actually just links to the existing LibreOffice. Basically it just creates an icon for it under Activities.
This might be a case where having a user- visible preference is desirable since it's not always what you want, for space reasons.
I never want to be backing up binaries. We already have this absurd difficulty of carving out what parts of the file system hierarchy are static and stateless, ostensibly the domain of atomic host, and what parts are stateful with system or user information. The FHS continues to make that effort difficult. It actively thwarts making this easy. And putting binaries into /home conflates what /home is mostly used for as well, which is user data. And apps haven't previously been considered user data, so I think it's confusing and messy, and makes it more difficult to do rebuilds, or migrate to a new computer, etc.
On Sun, 2017-04-02 at 09:44 -0500, Michael Catanzaro wrote:
On Sat, 2017-04-01 at 23:57 -0600, Chris Murphy wrote:
[chris@f26h ~]$ flatpak remotes gnome user org.libreoffice.LibreOffice-origin user,no-enumerate
I'm not expecting these to be user installed but rather system installed. This user is an admin and I really don't want every user on this system having to install their own copy of e.g. LibreOffice. My understanding is admin users would have runtimes and apps installed as system not user.
Well we have to figure this out, because my expectation is the opposite: I would expect that all users can have a completely separate set of apps installed. :( This might be a case where having a user- visible preference is desirable since it's not always what you want, for space reasons.
On this question, I'm slightly in favor of system-wide installation. It is what we've been all along, and I don't think there's a very compelling reason to move away from it. On the contrary, installing software in $HOME comes with extra complications such as nfs homedirs.
Also: being able to install without authentication but not delete matches our behavior for system packages. I think it's silly to allow users to install stuff but not to remove it, but that's our status quo.
If we want to allow users to install and delete software without prompts, we can do that regardless of where the installation goes.
On Sun, 2017-04-02 at 09:44 -0500, Michael Catanzaro wrote: On this question, I'm slightly in favor of system-wide installation. It is what we've been all along, and I don't think there's a very compelling reason to move away from it. On the contrary, installing software in $HOME comes with extra complications such as nfs homedirs.
Or a $HOME on a partition mounted noexec.
On Sun, 2017-04-02 at 09:44 -0500, Michael Catanzaro wrote:
Also: being able to install without authentication but not delete matches our behavior for system packages. I think it's silly to allow users to install stuff but not to remove it, but that's our status quo.
I thought the intent was that you should need admin privileges to do either. The only thing regular users are supposed to be allowed to do without admin privileges is *update* the system, though since that now requires a system reboot, I'm not sure even that should be allowed without auth any more.
On Wed, 2017-04-05 at 14:14 -0700, Adam Williamson wrote:
On Sun, 2017-04-02 at 09:44 -0500, Michael Catanzaro wrote:
Also: being able to install without authentication but not delete matches our behavior for system packages. I think it's silly to allow users to install stuff but not to remove it, but that's our status quo.
I thought the intent was that you should need admin privileges to do either. The only thing regular users are supposed to be allowed to do without admin privileges is *update* the system, though since that now requires a system reboot, I'm not sure even that should be allowed without auth any more.
To be clear, this is only my recollection, I haven't gone back and checked yet. I may be misremembering the discussions...
On Wed, 2017-04-05 at 14:16 -0700, Adam Williamson wrote:
To be clear, this is only my recollection, I haven't gone back and checked yet. I may be misremembering the discussions...
There was a well-debated design decision to allow installation without authentication, maybe three or four years ago. I think the goal was to make installing apps with GNOME Software easier.
Michael
On Wed, 2017-04-05 at 22:16 -0500, Michael Catanzaro wrote:
On Wed, 2017-04-05 at 14:16 -0700, Adam Williamson wrote:
To be clear, this is only my recollection, I haven't gone back and checked yet. I may be misremembering the discussions...
There was a well-debated design decision to allow installation without authentication, maybe three or four years ago. I think the goal was to make installing apps with GNOME Software easier.
That's the discussion I was thinking of, but sounds like I didn't remember the outcome right.
Hello!
I don't use Gnome Software a lot, but certainly it doesn't requires authentication, while DNF & Yumex do require it.
Cheers, Sylvia
On Wed, 2017-04-05 at 20:23 -0700, Adam Williamson wrote:
On Wed, 2017-04-05 at 22:16 -0500, Michael Catanzaro wrote:
On Wed, 2017-04-05 at 14:16 -0700, Adam Williamson wrote:
To be clear, this is only my recollection, I haven't gone back and checked yet. I may be misremembering the discussions...
There was a well-debated design decision to allow installation without authentication, maybe three or four years ago. I think the goal was to make installing apps with GNOME Software easier.
That's the discussion I was thinking of, but sounds like I didn't remember the outcome right.
On Wed, Apr 5, 2017 at 3:14 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Sun, 2017-04-02 at 09:44 -0500, Michael Catanzaro wrote:
Also: being able to install without authentication but not delete matches our behavior for system packages. I think it's silly to allow users to install stuff but not to remove it, but that's our status quo.
I thought the intent was that you should need admin privileges to do either. The only thing regular users are supposed to be allowed to do without admin privileges is *update* the system, though since that now requires a system reboot, I'm not sure even that should be allowed without auth any more.
Ick.
I want to see the OS and apps updated on a regular basis, by default, no user intervention. Just do it. I've tacitly given permission for this by installing Fedora already. It should be one of its responsibilities. Like cleaning up /var/tmp.
Especially flatpak applications - just update them. They can be rolled back if they break something.
As for where to install, whether admin user or non-admin, I think the app needs to go outside of /home. Find another way to additionally embargo "user" apps behind the scenes, but storing them on /home I think is consuming the wrong resource.
Android phone, I can install an application and not be asked to authenticate anything beyond the lock screen.
On Wed, 2017-04-05 at 17:32 -0600, Chris Murphy wrote:
On Wed, Apr 5, 2017 at 3:14 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Sun, 2017-04-02 at 09:44 -0500, Michael Catanzaro wrote:
Also: being able to install without authentication but not delete matches our behavior for system packages. I think it's silly to allow users to install stuff but not to remove it, but that's our status quo.
I thought the intent was that you should need admin privileges to do either. The only thing regular users are supposed to be allowed to do without admin privileges is *update* the system, though since that now requires a system reboot, I'm not sure even that should be allowed without auth any more.
Ick.
I want to see the OS and apps updated on a regular basis, by default, no user intervention. Just do it. I've tacitly given permission for this by installing Fedora already. It should be one of its responsibilities. Like cleaning up /var/tmp.
Well, it's about rebooting the system, not installing the updates. Having said that, if we already allow non-admins to reboot the system without authenticating as an admin, then allowing them to trigger a reboot to install updates isn't any worse.
Especially flatpak applications - just update them. They can be rolled back if they break something.
As for where to install, whether admin user or non-admin, I think the app needs to go outside of /home. Find another way to additionally embargo "user" apps behind the scenes, but storing them on /home I think is consuming the wrong resource.
Android phone, I can install an application and not be asked to authenticate anything beyond the lock screen.
But Android phones generally aren't multi-user devices. I'm only talking about *non-admin* users, here. On a single-user system, the single user is likely going to be an admin.
On Wed, Apr 5, 2017 at 6:01 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2017-04-05 at 17:32 -0600, Chris Murphy wrote:
On Wed, Apr 5, 2017 at 3:14 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Sun, 2017-04-02 at 09:44 -0500, Michael Catanzaro wrote:
Also: being able to install without authentication but not delete matches our behavior for system packages. I think it's silly to allow users to install stuff but not to remove it, but that's our status quo.
I thought the intent was that you should need admin privileges to do either. The only thing regular users are supposed to be allowed to do without admin privileges is *update* the system, though since that now requires a system reboot, I'm not sure even that should be allowed without auth any more.
Ick.
I want to see the OS and apps updated on a regular basis, by default, no user intervention. Just do it. I've tacitly given permission for this by installing Fedora already. It should be one of its responsibilities. Like cleaning up /var/tmp.
Well, it's about rebooting the system, not installing the updates.
Inhibit reboot if another user is logged in; disallow non-admins from forcibly logging those users out.
Otherwise, on a *workstation* there's no good reason to prevent a normal user from suspend, reboot, or shutdown. Of course a server is different.
Android phone, I can install an application and not be asked to authenticate anything beyond the lock screen.
But Android phones generally aren't multi-user devices. I'm only talking about *non-admin* users, here. On a single-user system, the single user is likely going to be an admin.
Sure.
But anyway:
Since forever, macOS has had ~/Applications where a non-admin user can install applications without authentication. Drag and drop. Done. Yes non-admins can reboot the computer, and shutdown, and put it to sleep.
Android does application autoupdates without asking me, by default. They happen whenever plugged into a charger. Thanks for not bugging me about routine things like this.
Also, this reference has some interesting points about Android multiuser behavior. https://source.android.com/devices/tech/admin/multi-user.html
* Each user gets a workspace to install and place apps. * Any user can affect the installed apps for all users. ## not sure what affect means, may not mean remove
My understanding of how a secondary user installs an already installed application is that it's basically creating a link; it's not literally downloading another copy of the binary and installing it.
Meanwhile on Windows with non-admin users, they're totally stuck. They have an inept admin, who lets them have 6 month old or older web browsers? They're fakaked. They can't update it. They can't replace it. They can't use a substitute. Proven failure when it comes to keeping things up to date.
Chris Murphy píše v St 05. 04. 2017 v 17:32 -0600:
On Wed, Apr 5, 2017 at 3:14 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Sun, 2017-04-02 at 09:44 -0500, Michael Catanzaro wrote:
Also: being able to install without authentication but not delete matches our behavior for system packages. I think it's silly to allow users to install stuff but not to remove it, but that's our status quo.
I thought the intent was that you should need admin privileges to do either. The only thing regular users are supposed to be allowed to do without admin privileges is *update* the system, though since that now requires a system reboot, I'm not sure even that should be allowed without auth any more.
Ick.
I want to see the OS and apps updated on a regular basis, by default, no user intervention. Just do it. I've tacitly given permission for this by installing Fedora already. It should be one of its responsibilities. Like cleaning up /var/tmp.
Especially flatpak applications - just update them. They can be rolled back if they break something.
Automatic updates of apps is a frequent request I hear from users. If they use Firefox Nightly for Flatpak which gets updated every day, they just get tired of updating it manually.
Update rollback is also something I'd like to see exposed in Software, but first it needs to be in libflatpak API. I opened a ticket about it recently: https://github.com/flatpak/flatpak/issues/664
Jiri
On Thu, 2017-04-06 at 14:48 +0200, Jiri Eischmann wrote:
Automatic updates of apps is a frequent request I hear from users. If they use Firefox Nightly for Flatpak which gets updated every day, they just get tired of updating it manually.
I have no opinion on automatic updates, but we can never in any circumstance prompt the user to install updates every single day. That's crazy. If they want to check daily, fine, but prompts are supposed to be weekly.
Michael
On Thu, Apr 6, 2017 at 7:03 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, 2017-04-06 at 14:48 +0200, Jiri Eischmann wrote:
Automatic updates of apps is a frequent request I hear from users. If they use Firefox Nightly for Flatpak which gets updated every day, they just get tired of updating it manually.
I have no opinion on automatic updates, but we can never in any circumstance prompt the user to install updates every single day. That's crazy. If they want to check daily, fine, but prompts are supposed to be weekly.
Michael _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
In my opinion, we shouldn't even prompt the user to update apps if updating the app doesn't require a reboot - we should just update. Android updates apps automatically if you're on wifi and charging, I think it works well. Users can disable auto-update for individual apps if they need to.
Of course, if we do it automatically, we should be a little better than Android: On Android, if your device updates an app you're currently using, it'll close itself after the update (it's very annoying when it happens when you're in the middle of something). I don't think we should do that, of course. I imagine some sort of a notification "<some app> has been updated to version <something>, close & re-open it to switch to the new version" if the app is running when the auto-update occurs.
How does iOS and mac OS handle this kind of thing?
System updates that require a reboot are something else entirely, and should obviously not happen *every day*.
On Fri, 2017-04-07 at 00:20 +0300, Elad Alfassa wrote:
On Thu, Apr 6, 2017 at 7:03 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, 2017-04-06 at 14:48 +0200, Jiri Eischmann wrote:
Automatic updates of apps is a frequent request I hear from users. If they use Firefox Nightly for Flatpak which gets updated every day, they just get tired of updating it manually.
I have no opinion on automatic updates, but we can never in any circumstance prompt the user to install updates every single day. That's crazy. If they want to check daily, fine, but prompts are supposed to be weekly.
Michael _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
In my opinion, we shouldn't even prompt the user to update apps if updating the app doesn't require a reboot - we should just update. Android updates apps automatically if you're on wifi and charging, I think it works well. Users can disable auto-update for individual apps if they need to.
This is the kind of thinking that made my laptop blow through my cellphone data plan limit in about fifteen minutes while I was tethering.
On Fri, Apr 7, 2017 at 12:59 AM, Adam Williamson <adamwill@fedoraproject.org
wrote:
On Fri, 2017-04-07 at 00:20 +0300, Elad Alfassa wrote:
On Thu, Apr 6, 2017 at 7:03 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, 2017-04-06 at 14:48 +0200, Jiri Eischmann wrote:
Automatic updates of apps is a frequent request I hear from users. If they use Firefox Nightly for Flatpak which gets updated every day, they just get tired of updating it manually.
I have no opinion on automatic updates, but we can never in any circumstance prompt the user to install updates every single day. That's crazy. If they want to check daily, fine, but prompts are supposed to be weekly.
Michael _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
In my opinion, we shouldn't even prompt the user to update apps if
updating
the app doesn't require a reboot - we should just update. Android updates apps automatically if you're on wifi and charging, I
think
it works well. Users can disable auto-update for individual apps if they need to.
This is the kind of thinking that made my laptop blow through my cellphone data plan limit in about fifteen minutes while I was tethering. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
Well, that's why we should make sure to not do it on metered connections. There are all kinds of heuristics we could use to detect a metered connection (idk which ones are actually implemented, if any), and there should also be a checkbox to mark a connection as metered if the detection fails, imo. NetworkManager already has the relevant API for this.
On Thu, Apr 6, 2017 at 3:59 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2017-04-07 at 00:20 +0300, Elad Alfassa wrote:
On Thu, Apr 6, 2017 at 7:03 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, 2017-04-06 at 14:48 +0200, Jiri Eischmann wrote:
Automatic updates of apps is a frequent request I hear from users. If they use Firefox Nightly for Flatpak which gets updated every day, they just get tired of updating it manually.
I have no opinion on automatic updates, but we can never in any circumstance prompt the user to install updates every single day. That's crazy. If they want to check daily, fine, but prompts are supposed to be weekly.
Michael _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
In my opinion, we shouldn't even prompt the user to update apps if updating the app doesn't require a reboot - we should just update. Android updates apps automatically if you're on wifi and charging, I think it works well. Users can disable auto-update for individual apps if they need to.
This is the kind of thinking that made my laptop blow through my cellphone data plan limit in about fifteen minutes while I was tethering.
I've had this happen variably on every platform and it drives me bezerk how much crap Windows, macOS, and even Fedora, is willing to download behind the scenes. Fedora is perhaps the worst offender on a per day basis because dnf and packagekit don't share metadata, and it's not an incremental (diff'd) update. It's a twice duplicative download of metadata. It's pretty much one of my top "too much sand in the wrong places" complaints.
However...
gnome-software at least has awareness of whether a connection is metered, but I'm not sure all the pieces are in place in the whole chain to get that fact communicated properly all the way to gnome-software.
Maybe a wifi connection login dialog needs a checkbox to indicate whether it's a metered connection. Because however it's supposed to work, isn't reliable in the real world.
On Thu, 2017-04-06 at 16:45 -0600, Chris Murphy wrote:
Maybe a wifi connection login dialog needs a checkbox to indicate whether it's a metered connection. Because however it's supposed to work, isn't reliable in the real world.
Yeah, this is basically my conclusion. I strongly doubt it'll ever be possible to achieve an acceptable level of magic detection here. Even connections that aren't *tethered* could certainly have data transfer caps for one reason or another. Just assuming you can go ahead and download as many GB of updates as you like without any kind of prior warning or even notification while the download is ongoing is a really bad idea.
On Thu, Apr 6, 2017 at 5:20 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2017-04-06 at 16:45 -0600, Chris Murphy wrote:
Maybe a wifi connection login dialog needs a checkbox to indicate whether it's a metered connection. Because however it's supposed to work, isn't reliable in the real world.
Yeah, this is basically my conclusion. I strongly doubt it'll ever be possible to achieve an acceptable level of magic detection here. Even connections that aren't *tethered* could certainly have data transfer caps for one reason or another. Just assuming you can go ahead and download as many GB of updates as you like without any kind of prior warning or even notification while the download is ongoing is a really bad idea.
Yeah I don't have a great solution for this other than literally bugging the user and asking at each initial connection. Maybe it's plausible to not do this for wired connections? I'll get crotchety if I plug in a wired connection but don't get a network and internet connection straight away. But then I also get crotchety when, upon a clean installation, Fedora sucks down a gig worth of updates in the first 5-10 minutes (Windows and macOS do not do this, they ask). But at a certain point down the road, I do want such updates and to not be bothered.
So the only thing I can think of is actively notifying the user of the current behavior and inviting them to change it, rather than it just being passive and murky. So maybe something in g-i-s for the initial inform and consent? And then a checkbox in wireless connect dialogs?
On Thu, Apr 06, 2017 at 06:49:48PM -0600, Chris Murphy wrote:
So the only thing I can think of is actively notifying the user of the current behavior and inviting them to change it, rather than it just being passive and murky. So maybe something in g-i-s for the initial inform and consent? And then a checkbox in wireless connect dialogs?
I don't know exactly what the UX for this would be, but it seems like a good place to also insert "I want other systems or devices on this network to be able access my system."
On Fri, 2017-04-07 at 09:27 -0400, Matthew Miller wrote:
On Thu, Apr 06, 2017 at 06:49:48PM -0600, Chris Murphy wrote:
So the only thing I can think of is actively notifying the user of the current behavior and inviting them to change it, rather than it just being passive and murky. So maybe something in g-i-s for the initial inform and consent? And then a checkbox in wireless connect dialogs?
I don't know exactly what the UX for this would be, but it seems like a good place to also insert "I want other systems or devices on this network to be able access my system."
A prompt like that would mystify me - 'access my system' - what does that even mean ? Are you talking about ssh / vnc / a local repo cache ?
On Fri, Apr 07, 2017 at 09:53:34AM -0400, Matthias Clasen wrote:
I don't know exactly what the UX for this would be, but it seems like a good place to also insert "I want other systems or devices on this network to be able access my system."
A prompt like that would mystify me - 'access my system' - what does that even mean ? Are you talking about ssh / vnc / a local repo cache ?
I'm open to different wording. "I trust this network" would be fine with me. Or we could go with Microsoft's "Home network / Work network / public network" https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.tec...
On Fri, Apr 07, 2017 at 10:14:50AM -0400, Matthew Miller wrote:
I'm open to different wording. "I trust this network" would be fine with me. Or we could go with Microsoft's "Home network / Work network / public network"
Please no. I find this utterly confusing. What is the difference between a "trusted home" and a "trusted work" network? Why does it even matter if "all the computers on this network" are at my home or my workplace?
It's only mildly better than putting up a message that says "we want you to take a deep dive into the documentation, NOW".
On Fri, Apr 07, 2017 at 10:09:30PM +0200, Lars Seipel wrote:
Please no. I find this utterly confusing. What is the difference between a "trusted home" and a "trusted work" network? Why does it even matter if "all the computers on this network" are at my home or my workplace?
Huh. I find the resistance to this to be the confusing thing. Do you really not know, or are you imaging that a user might not know? I very, very much want to have a restrictive package filter running at all times when I'm on a foreign network, and allow a more open firewall on my own. I know how to configure that, but that's because *I* took a deep dive into the documentation. If I had the option of making this choice when connnecting to the network for the first time, I'd absolutely understand it and know exactly what I wanted.
And frankly, I don't think I'm super-smart or special in this regard. I think that fits for *most* people in the workstation target audience — and beyond. https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
On Fri, 2017-04-07 at 17:03 -0400, Matthew Miller wrote:
On Fri, Apr 07, 2017 at 10:09:30PM +0200, Lars Seipel wrote:
Please no. I find this utterly confusing. What is the difference between a "trusted home" and a "trusted work" network? Why does it even matter if "all the computers on this network" are at my home or my workplace?
Huh. I find the resistance to this to be the confusing thing. Do you really not know, or are you imaging that a user might not know?
I sure don't. Whenever that dialog pops up on Windows, I have no clue what to expect as a consequence of several of the choices. As Lars says, what's the difference between "trusted home" and "trusted work"? Especially given that I work from home? :)
On the other hand, it should not be difficult at all to ask whether unlimited data transfer is acceptable for this connection in a way that shouldn't confuse anyone.
On Fri, Apr 7, 2017 at 3:51 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2017-04-07 at 17:03 -0400, Matthew Miller wrote:
On Fri, Apr 07, 2017 at 10:09:30PM +0200, Lars Seipel wrote:
Please no. I find this utterly confusing. What is the difference between a "trusted home" and a "trusted work" network? Why does it even matter if "all the computers on this network" are at my home or my workplace?
Huh. I find the resistance to this to be the confusing thing. Do you really not know, or are you imaging that a user might not know?
I sure don't. Whenever that dialog pops up on Windows, I have no clue what to expect as a consequence of several of the choices. As Lars says, what's the difference between "trusted home" and "trusted work"? Especially given that I work from home? :)
On the other hand, it should not be difficult at all to ask whether unlimited data transfer is acceptable for this connection in a way that shouldn't confuse anyone.
Haha. Yeah there is a distinct irony here: Firewall Zones in the Network panel is a lot of unneeded and meaningless granularity, meanwhile there's no UI to have the pipe closed to silent and massive background downloads.
On 04/07/2017 05:51 PM, Adam Williamson wrote:
On Fri, 2017-04-07 at 17:03 -0400, Matthew Miller wrote:
On Fri, Apr 07, 2017 at 10:09:30PM +0200, Lars Seipel wrote:
Please no. I find this utterly confusing. What is the difference between a "trusted home" and a "trusted work" network? Why does it even matter if "all the computers on this network" are at my home or my workplace?
Huh. I find the resistance to this to be the confusing thing. Do you really not know, or are you imaging that a user might not know?
I sure don't. Whenever that dialog pops up on Windows, I have no clue what to expect as a consequence of several of the choices. As Lars says, what's the difference between "trusted home" and "trusted work"? Especially given that I work from home? :)
Microsoft agrees with you, which is why in Windows 10 they have only "Trusted home or office network" and "Untrusted public network" as choices.
On Fri, Apr 7, 2017 at 3:03 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Apr 07, 2017 at 10:09:30PM +0200, Lars Seipel wrote:
Please no. I find this utterly confusing. What is the difference between a "trusted home" and a "trusted work" network? Why does it even matter if "all the computers on this network" are at my home or my workplace?
Huh. I find the resistance to this to be the confusing thing. Do you really not know, or are you imaging that a user might not know?
At this point, I think all networks are untrusted. My own network is only very marginally more trusted. The distinction between work and home networks - meaningless. I do a lot of consulting and some of those networks are heavily filtered with firewalls, and other work environments are probably more infected inside the organization than the internet itself. So "work" to me is like a sewage system, I just have no idea how much it's being used or flushed.
I very, very much want to have a restrictive package filter running at all times when I'm on a foreign network, and allow a more open firewall on my own. I know how to configure that, but that's because *I* took a deep dive into the documentation. If I had the option of making this choice when connnecting to the network for the first time, I'd absolutely understand it and know exactly what I wanted.
It's a bit off topic, but...
Originally with the firewalld feature change, we were supposed to get a GUI configuration tool, in fact the GUI tool was considered the primary configuration tool, not CLI. But Workstation WG canned that idea because they hated the UI, and said something else was needed instead, but nothing has appeared. So I think that needs to be re-evaluated as a default.
macOS has a firewall, it's off by default. But they also sandbox pretty much everything these days. When enabling the firewall, it gets pretty restrictive, and is made less restrictive by adding applications to it. And it dynamically figures out what resources that app wants and basically permits it. It's a brain dead simple UI.
On Fri, 2017-04-07 at 17:10 -0600, Chris Murphy wrote:
Originally with the firewalld feature change, we were supposed to get a GUI configuration tool, in fact the GUI tool was considered the primary configuration tool, not CLI. But Workstation WG canned that idea because they hated the UI, and said something else was needed instead, but nothing has appeared. So I think that needs to be re-evaluated as a default.
A firewall app that exposes confusing concepts like network protocols and ports is unsuitable for the Workstation product, sorry. We'd definitely consider a simpler firewall app based on app permissions rather than protocols. I suppose that would require all desktop apps to be containerized.
Michael
Hello,
I for myself never understood the difference and, unwilling to dive deep in the documentation, always opted to mark nothing and let the system to figure out. I guess is not the best option but I really can't see the difference, except the physical location.
My two cents, Silvia
On Fri, 2017-04-07 at 22:09 +0200, Lars Seipel wrote:
It's only mildly better than putting up a message that says "we want you
to take a deep dive into the documentation, NOW". _______________________________________________
On Fri, 2017-04-07 at 10:14 -0400, Matthew Miller wrote:
On Fri, Apr 07, 2017 at 09:53:34AM -0400, Matthias Clasen wrote:
I don't know exactly what the UX for this would be, but it seems like a good place to also insert "I want other systems or devices on this network to be able access my system."
A prompt like that would mystify me - 'access my system' - what does that even mean ? Are you talking about ssh / vnc / a local repo cache ?
I'm open to different wording. "I trust this network" would be fine with me. Or we could go with Microsoft's "Home network / Work network / public network" https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.bl ogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00 /55/08/metablogapi/2251.clip_image001_627A00E5.png
We do this in the sharing panel, where we tie the various things that can be shared to known networks. This seems better to me than a very fuzzy idea of 'trusting a network'.
On Fri, Apr 07, 2017 at 04:49:49PM -0400, Matthias Clasen wrote:
We do this in the sharing panel, where we tie the various things that can be shared to known networks. This seems better to me than a very fuzzy idea of 'trusting a network'.
That panel does seem like a fine place to put this; and, sure, we could call it "firewall" or "packet filter" or something. It'd be nice to have a link to it when connecting to a network for the first time, though, and maybe a link on the menu in the network area — I had no idea there were per-network settings here.
On Fri, 2017-04-07 at 17:07 -0400, Matthew Miller wrote:
On Fri, Apr 07, 2017 at 04:49:49PM -0400, Matthias Clasen wrote:
We do this in the sharing panel, where we tie the various things that can be shared to known networks. This seems better to me than a very fuzzy idea of 'trusting a network'.
That panel does seem like a fine place to put this; and, sure, we could call it "firewall" or "packet filter" or something. It'd be nice to have a link to it when connecting to a network for the first time, though, and maybe a link on the menu in the network area — I had no idea there were per-network settings here.
Oh, this is not about a firewall or about packet filtering, at least not directly. It is about controlling what you share on the network, to avoid a 'pants down' moment in the office or coffee shop. The only way in which this is related to the firewall is that the firewall must not get in the way of any sharing that the user has turned on.
For the more abstract/fuzzy 'network trust' level concept that you seem to be after, there is the 'Firewall zone' setting for wifi connections in the network panel. But good luck figuring out what any of those zones imply in terms of trust or broken applications. UX-wise, this setting is a disaster.
----- Original Message -----
On Fri, Apr 07, 2017 at 04:49:49PM -0400, Matthias Clasen wrote:
We do this in the sharing panel, where we tie the various things that can be shared to known networks. This seems better to me than a very fuzzy idea of 'trusting a network'.
That panel does seem like a fine place to put this; and, sure, we could call it "firewall" or "packet filter" or something. It'd be nice to have a link to it when connecting to a network for the first time, though, and maybe a link on the menu in the network area — I had no idea there were per-network settings here.
I really wish we'd stop with the backseat designer approach to solving hard problems, completely ignoring the history of prior discussions.
It only takes us years doing anything in Fedora Workstation, and bringing back old discussions like this on the table really doesn't help.
Might as well start discussing putting flags next to the language lists.
On Mon, Apr 10, 2017 at 05:53:50AM -0400, Bastien Nocera wrote:
I really wish we'd stop with the backseat designer approach to solving hard problems, completely ignoring the history of prior discussions.
Oh, I didn't mean to go down the rabbit hole of the actual design. I don't really care about the specifics of that per se. It just seems like if there *is* to be design work around a specific per-network configuration item which needs user input, it would be good to also look at some of those other unsolved hard problems *also* around per-network configuration which requires user input.
Even in Europe and UK, most of plans have some kind of top, whether download or speed. I don't think auto-updating is a good idea. Saying that other operating systems do it it's not a valid argument. Windows does a lot of c**** and it would be a very bad idea to copy it into Fedora.The point of using Linux systems is keeping control of your own computer, if everything will be hidden and automatic without even a warning or a prompt... the whole point is lost.
My thoughts,Silvia
On Thu, 2017-04-06 at 16:20 -0700, Adam Williamson wrote:
On Thu, 2017-04-06 at 16:45 -0600, Chris Murphy wrote:
Maybe a wifi connection login dialog needs a checkbox to indicate whether it's a metered connection. Because however it's supposed to work, isn't reliable in the real world.
Yeah, this is basically my conclusion. I strongly doubt it'll ever be possible to achieve an acceptable level of magic detection here. Even connections that aren't *tethered* could certainly have data transfer caps for one reason or another. Just assuming you can go ahead and download as many GB of updates as you like without any kind of prior warning or even notification while the download is ongoing is a really bad idea.
On 04/07/2017 12:45 AM, Chris Murphy wrote:
Maybe a wifi connection login dialog needs a checkbox to indicate whether it's a metered connection. Because however it's supposed to work, isn't reliable in the real world.
You also have to do it for USB Ethernet because many UMTS sticks present that as an interface.
Thanks, Florian
Hello, First of all, I don't want my computer behaving like a phone. I already have a phone to do that. Second, I think it should be the other way round, if you want to auto-update check the box. Otherwise, system will just prompt a notification and user can decide whether wants/can update or not.Keep in mind that updates in Fedora can be really big sometimes, and not *everyone* has a fast reliable connection to do this blindly. Please, consider the many users Fedora has in places like South America and Middle East where internet is slow and often only usable in specific places.
My thoughts.Silvia
On Fri, 2017-04-07 at 00:20 +0300, Elad Alfassa wrote:
On Thu, Apr 6, 2017 at 7:03 PM, Michael Catanzaro <mcatanzaro@gnome.o rg> wrote:
On Thu, 2017-04-06 at 14:48 +0200, Jiri Eischmann wrote:
Automatic updates of apps is a frequent request I hear from
users. If
they use Firefox Nightly for Flatpak which gets updated every
day,
they
just get tired of updating it manually.
I have no opinion on automatic updates, but we can never in any
circumstance prompt the user to install updates every single day.
That's crazy. If they want to check daily, fine, but prompts are
supposed to be weekly.
Michael
desktop mailing list -- desktop@lists.fedoraproject.org
To unsubscribe send an email to desktop-leave@lists.fedoraproject.o rg
In my opinion, we shouldn't even prompt the user to update apps if updating the app doesn't require a reboot - we should just update. Android updates apps automatically if you're on wifi and charging, I think it works well. Users can disable auto-update for individual apps if they need to.
Of course, if we do it automatically, we should be a little better than Android: On Android, if your device updates an app you're currently using, it'll close itself after the update (it's very annoying when it happens when you're in the middle of something). I don't think we should do that, of course. I imagine some sort of a notification "<some app> has been updated to version <something>, close & re-open it to switch to the new version" if the app is running when the auto- update occurs.
How does iOS and mac OS handle this kind of thing?
System updates that require a reboot are something else entirely, and should obviously not happen *every day*.
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org
On 6 April 2017 at 13:48, Jiri Eischmann eischmann@redhat.com wrote:
I want to see the OS and apps updated on a regular basis, by default,
Automatic updates of apps is a frequent request I hear from users.
That's the plan we have for GNOME 3.26. We had some design work done in 3.24, but too late to land before the feature and UI freeze. With flatpak we can do live app updates safely and sanely, and it's something we've been working towards for a few years now.
Richard.
I disagree. I want an updated system but without giving up security.Also comparing a phone with a computer isn't correct, they have different uses and features, and they're mean to accomplish different tasks.About placing Flatpak apps inside of /home.... The idea is keeping them in a sandbox separated from system. I don't see anything wrong in placing them there, but if you do, please explain. I'm curious to know.
Kind regards,Silvia
On Wed, 2017-04-05 at 17:32 -0600, Chris Murphy wrote:
On Wed, Apr 5, 2017 at 3:14 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Sun, 2017-04-02 at 09:44 -0500, Michael Catanzaro wrote:
Also: being able to install without authentication but not delete matches our behavior for system packages. I think it's silly to allow users to install stuff but not to remove it, but that's our status quo.
I thought the intent was that you should need admin privileges to do either. The only thing regular users are supposed to be allowed to do without admin privileges is *update* the system, though since that now requires a system reboot, I'm not sure even that should be allowed without auth any more.
Ick.
I want to see the OS and apps updated on a regular basis, by default, no user intervention. Just do it. I've tacitly given permission for this by installing Fedora already. It should be one of its responsibilities. Like cleaning up /var/tmp.
Especially flatpak applications - just update them. They can be rolled back if they break something.
As for where to install, whether admin user or non-admin, I think the app needs to go outside of /home. Find another way to additionally embargo "user" apps behind the scenes, but storing them on /home I think is consuming the wrong resource.
Android phone, I can install an application and not be asked to authenticate anything beyond the lock screen.
On 2 April 2017 at 06:57, Chris Murphy lists@colorremedies.com wrote:
Click on that file from within FireFox, and it opens Gnome Software which gives me the option to install. I click install. It counts up from 0% to 84% and then the status bar turns back into an Install button. There's no error message.
Curious.
I'm not expecting these to be user installed but rather system installed.
As am I:
$ gsettings get org.gnome.software install-bundles-system-wide true
Back in Gnome Software, click on the Install button and it does nothing, no error message.
Okay, so lets work out what's going wrong. What I suspect is happening is that we're "falling back" to the per-user install because there's something wrong lower in the stack, e.g. your user could not authenticate or something to do with polkit. For both issues, if you can get a full log of:
killall gnome-software gnome-software --verbose
..then we can figure out what's going on. Thanks.
Richard.
On Mon, Apr 3, 2017 at 9:53 AM, Richard Hughes hughsient@gmail.com wrote:
On 2 April 2017 at 06:57, Chris Murphy lists@colorremedies.com wrote:
Click on that file from within FireFox, and it opens Gnome Software which gives me the option to install. I click install. It counts up from 0% to 84% and then the status bar turns back into an Install button. There's no error message.
Curious.
I'm not expecting these to be user installed but rather system installed.
As am I:
$ gsettings get org.gnome.software install-bundles-system-wide true
Back in Gnome Software, click on the Install button and it does nothing, no error message.
Okay, so lets work out what's going wrong. What I suspect is happening is that we're "falling back" to the per-user install because there's something wrong lower in the stack, e.g. your user could not authenticate or something to do with polkit. For both issues, if you can get a full log of:
killall gnome-software gnome-software --verbose
..then we can figure out what's going on. Thanks.
Attached the log to this bug report. Installing gnome twitch in this example did not fail as did the libreoffice installation, but it does user install it instead of system install. https://bugzilla.redhat.com/show_bug.cgi?id=1438528
While work out the above, I stumbled into this bug. If I double click the same *.flatpakref file gnome-software offers an Install button to install it again, rather than having Launch / Remove buttons. https://bugzilla.redhat.com/show_bug.cgi?id=1438531
desktop@lists.fedoraproject.org
-
Adam Williamson -
Bastien Nocera -
Chris Murphy -
Christian Stadelmann -
Elad Alfassa -
Florian Müllner -
Florian Weimer -
Jiri Eischmann -
Lars Seipel -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Richard Hughes -
Silvia Sanchez -
Stephen Gallagher