I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to it since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
Matthias
On Tue, 2014-02-18 at 16:24 -0500, Matthias Clasen wrote:
Let me know what you think,
Matthias
* Worth mentioning that packages should not depend on any package that provide an application? (E.g. our bug where removing nm-connection-editor uninstalls control-center.)
* I see the editor is left as a to-do, but I'm not really sure why, since gedit seems like the clear choice. Are you considering something else?
On Tue, 2014-02-18 at 16:24 -0500, Matthias Clasen wrote:
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to it since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
Wouldn't...er...about the first four sections at least be the Base WG's responsibility, in whole or in part? The Workstation specification might want to link into bits of the base specification that might be of significance to people developing to the workstation, but I'd be worried if they started duplicating things.
"Account handling" may be something base also wants to cover in part, and "software updates" (the dnf part), "miscellaneous system information", pulseaudio part of "Media support".
Should there perhaps be some sort of "time limit" on "Even after the switch, an X server will be included, so applications can either connect to Wayland natively, or run as an X client."?
Thanks for the work!
Hi Adam, Yes, some items might fall partly or fully upon the base WG, but we (as their 'customers') need to clearly specify what we need them to deliver. The base WG todo list needs to be based upon the needs and requirements of the 3 product WGs, not the other way around.
Christian
----- Original Message -----
From: "Adam Williamson" awilliam@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, February 19, 2014 3:49:42 AM Subject: Re: technical spec for the workstation up for review
On Tue, 2014-02-18 at 16:24 -0500, Matthias Clasen wrote:
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to it since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
Wouldn't...er...about the first four sections at least be the Base WG's responsibility, in whole or in part? The Workstation specification might want to link into bits of the base specification that might be of significance to people developing to the workstation, but I'd be worried if they started duplicating things.
"Account handling" may be something base also wants to cover in part, and "software updates" (the dnf part), "miscellaneous system information", pulseaudio part of "Media support".
Should there perhaps be some sort of "time limit" on "Even after the switch, an X server will be included, so applications can either connect to Wayland natively, or run as an X client."?
Thanks for the work!
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 https://admin.fedoraproject.org/mailman/listinfo/desktop
On Wed, 2014-02-19 at 06:53 -0500, Christian Schaller wrote:
Hi Adam, Yes, some items might fall partly or fully upon the base WG, but we (as their 'customers') need to clearly specify what we need them to deliver. The base WG todo list needs to be based upon the needs and requirements of the 3 product WGs, not the other way around.
I agree there needs to be communication and co-ordination here, I'm just not sure the workstation technical specification is the place for that communication to happen.
What I was guessing would happen would be that the 'product' WGs and the base WG would have the discussion in some other forum - a mailing list thread, a different wiki page, whatever - and the requirements formed as a result of that discussion would be a part of the base WG's specification, and the product specifications could then reference the base specification where appropriate.
Otherwise it seems like we'll wind up with something unwieldy like the base specification *and* each of the product specifications all containing the same text (or, worse, different text for the same requirements), which seems suboptimal.
On Wed, Feb 19, 2014 at 10:38:37AM -0800, Adam Williamson wrote:
What I was guessing would happen would be that the 'product' WGs and the base WG would have the discussion in some other forum - a mailing list thread, a different wiki page, whatever - and the requirements formed as a result of that discussion would be a part of the base WG's specification, and the product specifications could then reference the base specification where appropriate.
Otherwise it seems like we'll wind up with something unwieldy like the base specification *and* each of the product specifications all containing the same text (or, worse, different text for the same requirements), which seems suboptimal.
I think it's okay for drafts / initial versions to look like this, and then we can eventually collapse parts down to "#include base" or "#include foo from base" / "include base except bar".
On Wed, 2014-02-19 at 13:42 -0500, Matthew Miller wrote:
I think it's okay for drafts / initial versions to look like this, and then we can eventually collapse parts down to "#include base" or "#include foo from base" / "include base except bar".
So, my view on this is that you can't specify a product 'with the core missing'. We have to write up how we want it all to work, from the kernel up. The other product WGs should do the same. And if the base WG managed to extract a common core out of that, more power to them.
But I don't think we can say:
'Our product is going to work like this ... and it is going to have these characteristics ... and it is going to be built on top of this unknown core that we have very little influence over or insight into how it works.'
On Wed, 2014-02-19 at 14:24 -0500, Matthias Clasen wrote:
On Wed, 2014-02-19 at 13:42 -0500, Matthew Miller wrote:
I think it's okay for drafts / initial versions to look like this, and then we can eventually collapse parts down to "#include base" or "#include foo from base" / "include base except bar".
So, my view on this is that you can't specify a product 'with the core missing'. We have to write up how we want it all to work, from the kernel up. The other product WGs should do the same. And if the base WG managed to extract a common core out of that, more power to them.
But I don't think we can say:
'Our product is going to work like this ... and it is going to have these characteristics ... and it is going to be built on top of this unknown core that we have very little influence over or insight into how it works.'
Sure, as I said, absolutely the products have to have considerable input into the Base design. It was purely a procedural point as to how exactly would be the best way to go about doing that. I wasn't suggesting that Base should go out and design the base system in a vacuum, and then the products just have to put up with what they come up with.
A few comments. ;)
* The spec says dnf will be the default software updater. I thought dnf folks didn't want to be default until f22 or so. Have you checked with them if this is ok?
* It would be good to decide on wayland vs X before any alpha. Or wayland as preview, etc.
* Which theme would be selected? adwaita ? (which doesn't yet have a qt part that I know of).
* I share nottings concern with the package list being in there. Perhaps it would be better to provide a description, ie, all the packages that depend on those that you require. (then you could reduce things, etc based on needs). Also, might be worth someone creating a live media with this set and diffing it against the f20 one... it might well show things that were missed, but are important.
* What deliverable(s) would there be? a live image? a live and a DVD? a netinstall? Any size or other constraints?
* Will there be a default method of setting up the install image? Ie, there was talk about putting more resources into liveusb-creator a while back, is that still on the table? or just leave things as 'any way you can copy to a usb' ?
* Given that the install will "limit the pre-installation user interaction to the minimum." Will there be a default filesystem type selected? Any other parts of the installer that should be preselcted for the workstation case?
Looks like a great start! Thanks for writing this up!
kevin
On 20 February 2014 17:47, Kevin Fenzi kevin@scrye.com wrote:
- The spec says dnf will be the default software updater. I thought dnf folks didn't want to be default until f22 or so. Have you checked with them if this is ok?
PackageKit is using librepo and hawkey directly without using dnf in F21.
Richard.
On Thu, 2014-02-20 at 19:36 +0000, Richard Hughes wrote:
On 20 February 2014 17:47, Kevin Fenzi kevin@scrye.com wrote:
- The spec says dnf will be the default software updater. I thought dnf folks didn't want to be default until f22 or so. Have you checked with them if this is ok?
PackageKit is using librepo and hawkey directly without using dnf in F21.
Was that OK with fesco? I thought they didn't want divergence in the default graphical and command line depsolvers.
On Thu, Feb 20, 2014 at 8:40 PM, Adam Williamson awilliam@redhat.com wrote:
On Thu, 2014-02-20 at 19:36 +0000, Richard Hughes wrote:
On 20 February 2014 17:47, Kevin Fenzi kevin@scrye.com wrote:
- The spec says dnf will be the default software updater. I thought dnf folks didn't want to be default until f22 or so. Have you checked with them if this is ok?
PackageKit is using librepo and hawkey directly without using dnf in F21.
Was that OK with fesco? I thought they didn't want divergence in the default graphical and command line depsolvers.
On Thu, Feb 20, 2014 at 8:43 PM, drago01 drago01@gmail.com wrote:
On Thu, Feb 20, 2014 at 8:40 PM, Adam Williamson awilliam@redhat.com wrote:
On Thu, 2014-02-20 at 19:36 +0000, Richard Hughes wrote:
On 20 February 2014 17:47, Kevin Fenzi kevin@scrye.com wrote:
- The spec says dnf will be the default software updater. I thought dnf folks didn't want to be default until f22 or so. Have you checked with them if this is ok?
PackageKit is using librepo and hawkey directly without using dnf in F21.
Was that OK with fesco? I thought they didn't want divergence in the default graphical and command line depsolvers.
https://fedorahosted.org/fesco/ticket/1148#comment:51 (if you don't want to read the whole thing)
On 20 February 2014 19:43, drago01 drago01@gmail.com wrote:
Was that OK with fesco? I thought they didn't want divergence in the default graphical and command line depsolvers.
Agreed. PackageKit now reads and writes to the yumdb just as good as yum did (tested!), but I'm also involved with the people designing the next version of the metadata database.
Richard
On Thu, Feb 20, 2014 at 2:48 PM, Richard Hughes hughsient@gmail.com wrote:
Agreed. PackageKit now reads and writes to the yumdb just as good as yum did (tested!), but I'm also involved with the people designing the next version of the metadata database.
Where is this discussion btw? I'd like to join.
On Thu, 20 Feb 2014 19:36:27 +0000 Richard Hughes hughsient@gmail.com wrote:
On 20 February 2014 17:47, Kevin Fenzi kevin@scrye.com wrote:
- The spec says dnf will be the default software updater. I thought
dnf folks didn't want to be default until f22 or so. Have you checked with them if this is ok?
PackageKit is using librepo and hawkey directly without using dnf in F21.
ok, but I was looking at:
"Software updates dnf will be used to obtain and install software updates for packaged applications and the OS itself. The recommendation for applications is to use the PackageKit APIs to interact with the underlying packaging system."
Which mentions dnf by name...
kevin
On 19 February 2014 19:24, Matthias Clasen mclasen@redhat.com wrote:
So, my view on this is that you can't specify a product 'with the core missing'.
I don't know if this helps or hinders, but this is a mclazy moduleset of installing GNOME 3.12 on Fedora 20: https://gitorious.org/mclazy/mclazy/source/master:modules.xml and all the updated system components it needs.
Richard.
On Wed, Feb 19, 2014 at 7:35 PM, Richard Hughes hughsient@gmail.com wrote:
On 19 February 2014 19:24, Matthias Clasen mclasen@redhat.com wrote:
So, my view on this is that you can't specify a product 'with the core missing'.
I don't know if this helps or hinders, but this is a mclazy moduleset of installing GNOME 3.12 on Fedora 20: https://gitorious.org/mclazy/mclazy/source/master:modules.xml and all the updated system components it needs.
Presumably with the soname bumps for clutter/cogl you'd leave them with the release versions of clutter as opposed to bumping them and having to coordinate a bunch of other rebuilds?
Peter
On 19 February 2014 19:58, Peter Robinson pbrobinson@gmail.com wrote:
Presumably with the soname bumps for clutter/cogl you'd leave them with the release versions of clutter as opposed to bumping them and having to coordinate a bunch of other rebuilds?
Nahh, the new builds are required for the various gnome components.
Richard
On Wed, Feb 19, 2014 at 1:38 PM, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2014-02-19 at 06:53 -0500, Christian Schaller wrote:
Hi Adam, Yes, some items might fall partly or fully upon the base WG, but we (as their 'customers') need to clearly specify what we need them to deliver. The base WG todo list needs to be based upon the needs and requirements of the 3 product WGs, not the other way around.
I agree there needs to be communication and co-ordination here, I'm just not sure the workstation technical specification is the place for that communication to happen.
What I was guessing would happen would be that the 'product' WGs and the base WG would have the discussion in some other forum - a mailing list thread, a different wiki page, whatever - and the requirements formed as a result of that discussion would be a part of the base WG's specification, and the product specifications could then reference the base specification where appropriate.
Someone needs to start the list somewhere. The Base WG hasn't done anything of this nature at all. The spec can be sent to them for review, which I believe Jaroslav has volunteered to do.
Otherwise it seems like we'll wind up with something unwieldy like the base specification *and* each of the product specifications all containing the same text (or, worse, different text for the same requirements), which seems suboptimal.
I agree that's a possibility, but I'd rather _one_ of the WGs start by trying to be productive and then reaching out instead of having them all just sit around waiting for each other.
josh
On Wed, 2014-02-19 at 13:56 -0500, Josh Boyer wrote:
On Wed, Feb 19, 2014 at 1:38 PM, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2014-02-19 at 06:53 -0500, Christian Schaller wrote:
Hi Adam, Yes, some items might fall partly or fully upon the base WG, but we (as their 'customers') need to clearly specify what we need them to deliver. The base WG todo list needs to be based upon the needs and requirements of the 3 product WGs, not the other way around.
I agree there needs to be communication and co-ordination here, I'm just not sure the workstation technical specification is the place for that communication to happen.
What I was guessing would happen would be that the 'product' WGs and the base WG would have the discussion in some other forum - a mailing list thread, a different wiki page, whatever - and the requirements formed as a result of that discussion would be a part of the base WG's specification, and the product specifications could then reference the base specification where appropriate.
Someone needs to start the list somewhere. The Base WG hasn't done anything of this nature at all. The spec can be sent to them for review, which I believe Jaroslav has volunteered to do.
Otherwise it seems like we'll wind up with something unwieldy like the base specification *and* each of the product specifications all containing the same text (or, worse, different text for the same requirements), which seems suboptimal.
I agree that's a possibility, but I'd rather _one_ of the WGs start by trying to be productive and then reaching out instead of having them all just sit around waiting for each other.
Sure, if the long-term plan is to rationalize things down as Matthew also suggested, sounds fine.
----- Original Message -----
On Tue, 2014-02-18 at 16:24 -0500, Matthias Clasen wrote:
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to it since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
Wouldn't...er...about the first four sections at least be the Base WG's responsibility, in whole or in part? The Workstation specification might want to link into bits of the base specification that might be of significance to people developing to the workstation, but I'd be worried if they started duplicating things.
Some parts seems to be what Base would like to own - but we want to keep it as pretty minimal thing unless there are more products using these bits. I'll pass it to the Base WG meeting this Friday, it's good to have initial list we can talk about.
Jaroslav
----- Original Message -----
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to it since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
As mentioned in IRC, I don't think we want the "Firewall" item listed in there: https://fedoraproject.org/wiki/Workstation/Technical_Specification#Firewall
firewalld is a Fedora-only, there's no generic API for application developers to use (unless they only target Fedora), and its current implementation means that it's near impossible to use simple things like Samba browsing, or browsing UPnP shares with the default configuration.
I think we should reconsider not having a firewall by default, and providing firewalld and a UI for it as an external installable system software. That reflects on its current level of integration in the desktop.
I didn't see any sections about error reporting (abrt, SETroubleshoot, GNOME Oops![1]) or SELinux enablement.
Cheers
[1]: https://wiki.gnome.org/Design/Apps/Oops and https://wiki.gnome.org/Design/OS/ProblemReporting
On Wed, 2014-02-19 at 08:47 -0500, Bastien Nocera wrote:
I think we should reconsider not having a firewall by default, and providing firewalld and a UI for it as an external installable system software. That reflects on its current level of integration in the desktop.
This would be quite a shame, but I think it is reasonable to specify that a firewall in its default configuration may not interfere with the normal operation of programs installed by default (Nautilus, Totem, anything in the Sharing System Settings panel, ...).
----- Original Message -----
On Wed, 2014-02-19 at 08:47 -0500, Bastien Nocera wrote:
I think we should reconsider not having a firewall by default, and providing firewalld and a UI for it as an external installable system software. That reflects on its current level of integration in the desktop.
This would be quite a shame, but I think it is reasonable to specify that a firewall in its default configuration may not interfere with the normal operation of programs installed by default (Nautilus, Totem, anything in the Sharing System Settings panel, ...).
Be my guest. I doubt you'll be able to make it work when shares such as DAAP, UPnP and number of others use random high ports that are blocked by the firewall by default. Which means that each application needs to poke a hole in the firewall, which means that it needs to use the Fedora specific and hard-to-use API[1] to do so.
This needs redesigning from the ground up, with the users and application developers as the point of focus.
[1]: See firewalld.dbus
----- Original Message -----
On Wed, 2014-02-19 at 08:47 -0500, Bastien Nocera wrote:
I think we should reconsider not having a firewall by default, and providing firewalld and a UI for it as an external installable system software. That reflects on its current level of integration in the desktop.
This would be quite a shame, but I think it is reasonable to specify that a firewall in its default configuration may not interfere with the normal operation of programs installed by default (Nautilus, Totem, anything in the Sharing System Settings panel, ...).
Be my guest. I doubt you'll be able to make it work when shares such as DAAP, UPnP and number of others use random high ports that are blocked by the firewall by default. Which means that each application needs to poke a hole in the firewall, which means that it needs to use the Fedora specific and hard-to-use API[1] to do so.
Isn't that the idea in general of what the UPNP IGD standard is suppose to implement, maybe adding support for something like gupnp-igd to speak with firewalld via dbus to use a slightly might at least generalise it from the api PoV
peter
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Christian
----- Original Message -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, February 19, 2014 2:47:41 PM Subject: Re: technical spec for the workstation up for review
----- Original Message -----
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to it since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
As mentioned in IRC, I don't think we want the "Firewall" item listed in there: https://fedoraproject.org/wiki/Workstation/Technical_Specification#Firewall
firewalld is a Fedora-only, there's no generic API for application developers to use (unless they only target Fedora), and its current implementation means that it's near impossible to use simple things like Samba browsing, or browsing UPnP shares with the default configuration.
I think we should reconsider not having a firewall by default, and providing firewalld and a UI for it as an external installable system software. That reflects on its current level of integration in the desktop.
I didn't see any sections about error reporting (abrt, SETroubleshoot, GNOME Oops![1]) or SELinux enablement.
Cheers
[1]: https://wiki.gnome.org/Design/Apps/Oops and https://wiki.gnome.org/Design/OS/ProblemReporting -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
----- Original Message -----
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Right. But firewalld can't a Fedora-only solution, otherwise no application developer will want to integrate with it.
We'd also need designs based around that, and see if firewalld is indeed the right technical solution.
Right now, we don't even know whether a firewall is required, or it's just a work-around for applications that aren't integrated.
On Wed, 19.02.14 12:40, Bastien Nocera (bnocera@redhat.com) wrote:
----- Original Message -----
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Right. But firewalld can't a Fedora-only solution, otherwise no application developer will want to integrate with it.
We'd also need designs based around that, and see if firewalld is indeed the right technical solution.
Right now, we don't even know whether a firewall is required, or it's just a work-around for applications that aren't integrated.
I fully agree with Bastien here. I don't think a firewall brings any benefit on th desktop, and particularly not in the implementation of firewalld. There are better ways to make sure the local system is not vulnerable, and in its current state firewalld just creates problems and slows down the boot immensly (it's the number 1 slowest component on Fedora, right now.)
Lennart
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Right. But firewalld can't a Fedora-only solution, otherwise no application developer will want to integrate with it.
We'd also need designs based around that, and see if firewalld is indeed the right technical solution.
Right now, we don't even know whether a firewall is required, or it's just a work-around for applications that aren't integrated.
I fully agree with Bastien here. I don't think a firewall brings any benefit on th desktop, and particularly not in the implementation of firewalld. There are better ways to make sure the local system is not vulnerable, and in its current state firewalld just creates problems and slows down the boot immensly (it's the number 1 slowest component on Fedora, right now.)
On a properly configured system basically the average desktop should have little to no services listening and those that are likely are allowed through the firewall anyway so aren't protected by a firewall. Ultimately though we should likely offer a means to detect when on a public or private network and bring up the firewall on the former to protect the user as they're unlikely to want to share their dlna media with most people on a public network.
Peter
----- Original Message -----
On a properly configured system basically the average desktop should have little to no services listening and those that are likely are allowed through the firewall anyway so aren't protected by a firewall. Ultimately though we should likely offer a means to detect when on a public or private network and bring up the firewall on the former to protect the user as they're unlikely to want to share their dlna media with most people on a public network.
Or have the services listening on the network be stopped.
----- Original Message -----
From: "Lennart Poettering" mzerqung@0pointer.de To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, February 19, 2014 6:57:57 PM Subject: Re: technical spec for the workstation up for review
On Wed, 19.02.14 12:40, Bastien Nocera (bnocera@redhat.com) wrote:
----- Original Message -----
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Right. But firewalld can't a Fedora-only solution, otherwise no application developer will want to integrate with it.
We'd also need designs based around that, and see if firewalld is indeed the right technical solution.
Right now, we don't even know whether a firewall is required, or it's just a work-around for applications that aren't integrated.
I fully agree with Bastien here. I don't think a firewall brings any benefit on th desktop, and particularly not in the implementation of firewalld. There are better ways to make sure the local system is not vulnerable, and in its current state firewalld just creates problems and slows down the boot immensly (it's the number 1 slowest component on Fedora, right now.)
Lennart
Well they are re-implementing firewalld in C++ now, so hopefully the new implementation will be less slow on boot.
Christian
On 02/19/2014 06:57 PM, Lennart Poettering wrote:
On Wed, 19.02.14 12:40, Bastien Nocera (bnocera@redhat.com) wrote:
----- Original Message -----
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Right. But firewalld can't a Fedora-only solution, otherwise no application developer will want to integrate with it.
We'd also need designs based around that, and see if firewalld is indeed the right technical solution.
Right now, we don't even know whether a firewall is required, or it's just a work-around for applications that aren't integrated.
I fully agree with Bastien here. I don't think a firewall brings any benefit on th desktop, and particularly not in the implementation of firewalld. There are better ways to make sure the local system is not vulnerable, and in its current state firewalld just creates problems and slows down the boot immensly (it's the number 1 slowest component on Fedora, right now.)
I will not reply to your personal opinion. But "firewalld is the number 1 slowest component on Fedora, right now."?
See below:
I just did a fresh F-20 gnome installation and applied all updates. After 3 boots I used systemd-analyze and systemd-analyze blame:
F-20 x86_64 virt guest (after 2 boots):
Startup finished in 528ms (kernel) + 1.027s (initrd) + 4.208s (userspace) = 5.765s 2.091s plymouth-quit-wait.service 1.373s firewalld.service 878ms accounts-daemon.service 833ms libvirtd.service 687ms rtkit-daemon.service 615ms avahi-daemon.service 544ms ModemManager.service 470ms chronyd.service 456ms systemd-logind.service
After disabling firewalld (and two boots):
Startup finished in 520ms (kernel) + 996ms (initrd) + 3.948s (userspace) = 5.465s 1.855s plymouth-quit-wait.service 1.145s libvirtd.service 867ms accounts-daemon.service 826ms NetworkManager.service 670ms rtkit-daemon.service 611ms avahi-daemon.service 535ms ModemManager.service 459ms systemd-logind.service 431ms plymouth-start.service
After uninstalling firewalld (and two boots):
Startup finished in 528ms (kernel) + 1.029s (initrd) + 3.944s (userspace) = 5.502s 1.536s plymouth-quit-wait.service 1.230s accounts-daemon.service 1.190s NetworkManager.service 1.089s rtkit-daemon.service 1.053s avahi-daemon.service 975ms ModemManager.service 955ms systemd-logind.service 855ms chronyd.service 709ms libvirtd.service
systemd-analyze was used to produce this initially after 3 boots and after 2 boots after each change.
firewalld is not the "number 1 slowest component on Fedora, right now.", but it is plymouth-quit-wait.
As you can see, the userspace time varies by about 0.3s after disabling and also uninstalling firewalld!
Taking into account that only firewalld changed in these the output of "systemd-analyze blame" is very unexpected. The start times of other services increased by 40 to 50% after firewalld is not started and not available anymore.
I can only measure a difference of about 0.3s in boot time with and without firewalld.
Lennart
Thomas
On Thu, Apr 17, 2014 at 3:40 PM, Thomas Woerner twoerner@redhat.com wrote:
On 02/19/2014 06:57 PM, Lennart Poettering wrote:
On Wed, 19.02.14 12:40, Bastien Nocera (bnocera@redhat.com) wrote:
----- Original Message -----
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Right. But firewalld can't a Fedora-only solution, otherwise no application developer will want to integrate with it.
We'd also need designs based around that, and see if firewalld is indeed the right technical solution.
Right now, we don't even know whether a firewall is required, or it's just a work-around for applications that aren't integrated.
I fully agree with Bastien here. I don't think a firewall brings any benefit on th desktop, and particularly not in the implementation of firewalld. There are better ways to make sure the local system is not vulnerable, and in its current state firewalld just creates problems and slows down the boot immensly (it's the number 1 slowest component on Fedora, right now.)
I will not reply to your personal opinion. But "firewalld is the number 1 slowest component on Fedora, right now."?
See below:
I just did a fresh F-20 gnome installation and applied all updates. After 3 boots I used systemd-analyze and systemd-analyze blame:
F-20 x86_64 virt guest (after 2 boots):
Startup finished in 528ms (kernel) + 1.027s (initrd) + 4.208s (userspace) = 5.765s 2.091s plymouth-quit-wait.service 1.373s firewalld.service 878ms accounts-daemon.service 833ms libvirtd.service 687ms rtkit-daemon.service 615ms avahi-daemon.service 544ms ModemManager.service 470ms chronyd.service 456ms systemd-logind.service
After disabling firewalld (and two boots):
Startup finished in 520ms (kernel) + 996ms (initrd) + 3.948s (userspace) = 5.465s 1.855s plymouth-quit-wait.service 1.145s libvirtd.service 867ms accounts-daemon.service 826ms NetworkManager.service 670ms rtkit-daemon.service 611ms avahi-daemon.service 535ms ModemManager.service 459ms systemd-logind.service 431ms plymouth-start.service
After uninstalling firewalld (and two boots):
Startup finished in 528ms (kernel) + 1.029s (initrd) + 3.944s (userspace) = 5.502s 1.536s plymouth-quit-wait.service 1.230s accounts-daemon.service 1.190s NetworkManager.service 1.089s rtkit-daemon.service 1.053s avahi-daemon.service 975ms ModemManager.service 955ms systemd-logind.service 855ms chronyd.service 709ms libvirtd.service
systemd-analyze was used to produce this initially after 3 boots and after 2 boots after each change.
firewalld is not the "number 1 slowest component on Fedora, right now.", but it is plymouth-quit-wait.
No it just waits for other services to finish (as you have seen it went down without firewalld).
As you can see, the userspace time varies by about 0.3s after disabling and also uninstalling firewalld!
Taking into account that only firewalld changed in these the output of "systemd-analyze blame" is very unexpected. The start times of other services increased by 40 to 50% after firewalld is not started and not available anymore.
Because things run in parallel.
I can only measure a difference of about 0.3s in boot time with and without firewalld.
I wouldn't classify "0.3 seconds" as "only" but yeah that's the difference on your system.
On 04/17/2014 03:51 PM, drago01 wrote:
On Thu, Apr 17, 2014 at 3:40 PM, Thomas Woerner twoerner@redhat.com wrote:
On 02/19/2014 06:57 PM, Lennart Poettering wrote:
On Wed, 19.02.14 12:40, Bastien Nocera (bnocera@redhat.com) wrote:
----- Original Message -----
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Right. But firewalld can't a Fedora-only solution, otherwise no application developer will want to integrate with it.
We'd also need designs based around that, and see if firewalld is indeed the right technical solution.
Right now, we don't even know whether a firewall is required, or it's just a work-around for applications that aren't integrated.
I fully agree with Bastien here. I don't think a firewall brings any benefit on th desktop, and particularly not in the implementation of firewalld. There are better ways to make sure the local system is not vulnerable, and in its current state firewalld just creates problems and slows down the boot immensly (it's the number 1 slowest component on Fedora, right now.)
I will not reply to your personal opinion. But "firewalld is the number 1 slowest component on Fedora, right now."?
See below:
I just did a fresh F-20 gnome installation and applied all updates. After 3 boots I used systemd-analyze and systemd-analyze blame:
F-20 x86_64 virt guest (after 2 boots):
Startup finished in 528ms (kernel) + 1.027s (initrd) + 4.208s (userspace) = 5.765s 2.091s plymouth-quit-wait.service 1.373s firewalld.service 878ms accounts-daemon.service 833ms libvirtd.service 687ms rtkit-daemon.service 615ms avahi-daemon.service 544ms ModemManager.service 470ms chronyd.service 456ms systemd-logind.service
After disabling firewalld (and two boots):
Startup finished in 520ms (kernel) + 996ms (initrd) + 3.948s (userspace) = 5.465s 1.855s plymouth-quit-wait.service 1.145s libvirtd.service 867ms accounts-daemon.service 826ms NetworkManager.service 670ms rtkit-daemon.service 611ms avahi-daemon.service 535ms ModemManager.service 459ms systemd-logind.service 431ms plymouth-start.service
After uninstalling firewalld (and two boots):
Startup finished in 528ms (kernel) + 1.029s (initrd) + 3.944s (userspace) = 5.502s 1.536s plymouth-quit-wait.service 1.230s accounts-daemon.service 1.190s NetworkManager.service 1.089s rtkit-daemon.service 1.053s avahi-daemon.service 975ms ModemManager.service 955ms systemd-logind.service 855ms chronyd.service 709ms libvirtd.service
systemd-analyze was used to produce this initially after 3 boots and after 2 boots after each change.
firewalld is not the "number 1 slowest component on Fedora, right now.", but it is plymouth-quit-wait.
No it just waits for other services to finish (as you have seen it went down without firewalld).
Yes, but all others increased. Therefore the question: Why are other services taking longer to start if firewalld is not started and not installed anymore? Without firewalld the other services in the system should start in the same time as before with firewalld installed and started. Otherwise the calculation is just some number and only partly related to the started service itself.
Lennart, I think you should be able to explain this discrepancy.
As you can see, the userspace time varies by about 0.3s after disabling and also uninstalling firewalld!
Taking into account that only firewalld changed in these the output of "systemd-analyze blame" is very unexpected. The start times of other services increased by 40 to 50% after firewalld is not started and not available anymore.
Because things run in parallel.
I can only measure a difference of about 0.3s in boot time with and without firewalld.
I wouldn't classify "0.3 seconds" as "only" but yeah that's the difference on your system.
On Tue, 22.04.14 10:44, Thomas Woerner (twoerner@redhat.com) wrote:
firewalld is not the "number 1 slowest component on Fedora, right now.", but it is plymouth-quit-wait.
No it just waits for other services to finish (as you have seen it went down without firewalld).
Yes, but all others increased. Therefore the question: Why are other services taking longer to start if firewalld is not started and not installed anymore? Without firewalld the other services in the system should start in the same time as before with firewalld installed and started. Otherwise the calculation is just some number and only partly related to the started service itself.
Lennart, I think you should be able to explain this discrepancy.
systemd-analyze will tell you the raw numbers how long a service needs to start. It can provide you with an indication what is going on, but you have to read it with a grain of salt, since it will always include times a service just waits for another service and doesn't actually consume CPU nor IO. Moreover, the buffer cache is a major source of noise here, since earlier services pay a greater penalty for IO accesses than later services. The readahead logic adds even more noise.
Ultimately this means: it's a system where performance behaviour of services influence each other even if they don't directly communicate. To make the data more reliable, you'd could drop the read-ahead caches, disable excatly one service of the boot, then boot 2 times and measure the resulting total boot speed over a number of subsequent boots. Then, reenable that one service, and disable another one, repeat... This will tell you how much every service actually contributes to the boot time, while staying close to the full system where all services are enabled.
The data systemd-analyze is hence merely a trend. It indicates that firewalld is the worst offender, and given the margin I am pretty sure this will also be the case if you do the more accurate testing suggested above.
Lennart
On 04/23/2014 05:31 AM, Lennart Poettering wrote:
On Tue, 22.04.14 10:44, Thomas Woerner (twoerner@redhat.com) wrote:
firewalld is not the "number 1 slowest component on Fedora, right now.", but it is plymouth-quit-wait.
No it just waits for other services to finish (as you have seen it went down without firewalld).
Yes, but all others increased. Therefore the question: Why are other services taking longer to start if firewalld is not started and not installed anymore? Without firewalld the other services in the system should start in the same time as before with firewalld installed and started. Otherwise the calculation is just some number and only partly related to the started service itself.
Lennart, I think you should be able to explain this discrepancy.
systemd-analyze will tell you the raw numbers how long a service needs to start. It can provide you with an indication what is going on, but you have to read it with a grain of salt, since it will always include times a service just waits for another service and doesn't actually consume CPU nor IO. Moreover, the buffer cache is a major source of noise here, since earlier services pay a greater penalty for IO accesses than later services. The readahead logic adds even more noise.
Ultimately this means: it's a system where performance behaviour of services influence each other even if they don't directly communicate. To make the data more reliable, you'd could drop the read-ahead caches, disable excatly one service of the boot, then boot 2 times and measure the resulting total boot speed over a number of subsequent boots. Then, reenable that one service, and disable another one, repeat... This will tell you how much every service actually contributes to the boot time, while staying close to the full system where all services are enabled.
The data systemd-analyze is hence merely a trend. It indicates that firewalld is the worst offender, and given the margin I am pretty sure this will also be the case if you do the more accurate testing suggested above.
Only because it adds the start times for polkit, dbus and a lot of system things to the start time of firewalld. But not to the other services using these. It adds it to firewalld, because it is started very early. So either add the start times of the requires to all services using them, or just forget about the time information in systemd-analyze at all.
What you are naming "trend" is not even this. See above.
If I am adding "After=" lines for everything that is started additionally, the start time of firewalld is really small.
Lennart
Thomas
Thomas, what is the state of the C-based rewrite of firewalld? Does that render this particular argument at least less important, if not moot?
On Wed, 2014-04-23 at 09:07 -0400, Matthew Miller wrote:
Thomas, what is the state of the C-based rewrite of firewalld? Does that render this particular argument at least less important, if not moot?
This decision should be based on the security and usability effects of the firewall. "My firewall starts a little slow and that makes me sad" is a reasonable argument; "my firewall starts a little slow so let's remove it" is not so much.
On Wed, Apr 23, 2014 at 08:26:31AM -0500, Michael Catanzaro wrote:
Thomas, what is the state of the C-based rewrite of firewalld? Does that render this particular argument at least less important, if not moot?
This decision should be based on the security and usability effects of the firewall. "My firewall starts a little slow and that makes me sad" is a reasonable argument; "my firewall starts a little slow so let's remove it" is not so much.
Right, that wasn't the reason. The reasons are:
* the python implementation is a memory hog
* we would like to have fewer (eventually zero) core components using interpretted languages because a) they're inherently bulky and b) they make life difficult when we have to deal with runtime compatibility for different consumers -- something we're not going to easily solve unless we go full SCL.
* startup time might be an issue if the program is eventually redesigned to run on demand (when a change in state is requested) rather than constantly
So it's my understanding that this is underway, and it might have the _secondary_ advantage of making the conversation about initial boot time less important.
On 04/23/2014 05:56 PM, Matthew Miller wrote:
On Wed, Apr 23, 2014 at 08:26:31AM -0500, Michael Catanzaro wrote:
Thomas, what is the state of the C-based rewrite of firewalld? Does that render this particular argument at least less important, if not moot?
This decision should be based on the security and usability effects of the firewall. "My firewall starts a little slow and that makes me sad" is a reasonable argument; "my firewall starts a little slow so let's remove it" is not so much.
Right, that wasn't the reason. The reasons are:
- the python implementation is a memory hog
Is the use of about 20MB really a point in a workstation with apps?
- we would like to have fewer (eventually zero) core components using interpretted languages because a) they're inherently bulky and b) they make life difficult when we have to deal with runtime compatibility for different consumers -- something we're not going to easily solve unless we go full SCL.
Will JavaScript support be removed from PolicyKit again to achieve this? Please let me know then we will stop evaluating the use of it.
- startup time might be an issue if the program is eventually redesigned to run on demand (when a change in state is requested) rather than constantly
So it's my understanding that this is underway, and it might have the _secondary_ advantage of making the conversation about initial boot time less important.
See my question about start times with systemd.
On Wed, Apr 23, 2014 at 06:26:29PM +0200, Thomas Woerner wrote:
Right, that wasn't the reason. The reasons are:
- the python implementation is a memory hog
Is the use of about 20MB really a point in a workstation with apps?
Probably not. It's pretty awful in a high density cloud environment, though. But you've taken this out of context -- the point was that there are reasons to do this _other_ than desktop startup time, and if it helps with desktop startup time, that's a bonus.
- we would like to have fewer (eventually zero) core components using interpretted languages because a) they're inherently bulky and b) they
Will JavaScript support be removed from PolicyKit again to achieve this?
I hope so, yes. The package is already split so that this would be possible, but currently kept as a dependency to ensure consistent behavior.
Please let me know then we will stop evaluating the use of it.
From the documentation given by PolicyKit upstream, the Javascript
functionality should never be used by operating systems or packaged applications and is intended for local flexiblity only. So you should probably stop that anyway.
On 04/23/2014 03:07 PM, Matthew Miller wrote:
Thomas, what is the state of the C-based rewrite of firewalld? Does that render this particular argument at least less important, if not moot?
We are working on the recode.
Which argument? I have not seen complains about Python in this thread.
On Thu, 17.04.14 15:40, Thomas Woerner (twoerner@redhat.com) wrote:
I will not reply to your personal opinion. But "firewalld is the number 1 slowest component on Fedora, right now."?
Yes. It is.
See below:
I just did a fresh F-20 gnome installation and applied all updates. After 3 boots I used systemd-analyze and systemd-analyze blame:
F-20 x86_64 virt guest (after 2 boots):
Startup finished in 528ms (kernel) + 1.027s (initrd) + 4.208s (userspace) = 5.765s 2.091s plymouth-quit-wait.service 1.373s firewalld.service 878ms accounts-daemon.service 833ms libvirtd.service 687ms rtkit-daemon.service 615ms avahi-daemon.service 544ms ModemManager.service 470ms chronyd.service 456ms systemd-logind.service
plymouth-quit-wait is a special case here. It just waits until everything else is finished and then kills the plymouth boot splash. It doesn't really do anything on its own, it just waits (which the name hopefully indicates).
So yes, firewalld is the slowest component...
firewalld is not the "number 1 slowest component on Fedora, right now.", but it is plymouth-quit-wait.
Yeah, this is certainly misleading, but firewalld is really the slowest component.
As you can see, the userspace time varies by about 0.3s after disabling and also uninstalling firewalld!
Yupp, because we parallelize everything. Also, on a number of laptops we now have 2s bootups. If this is the range, then 0.3s is actually a lot.
Lennart
On Mon, 2014-04-21 at 00:00 +0200, Lennart Poettering wrote:
So yes, firewalld is the slowest component...
$ systemd-analyze blame 16.509s plymouth-quit-wait.service 16.406s ModemManager.service 15.772s accounts-daemon.service 14.807s systemd-logind.service 14.477s firewalld.service 14.354s chronyd.service 14.300s avahi-daemon.service 14.115s gdm.service
Yupp, because we parallelize everything. Also, on a number of laptops we now have 2s bootups. If this is the range, then 0.3s is actually a lot.
Fast booting is a laudable goal, but I don't think that should be a consideration in this discussion, whether the speedup is 0.3 seconds or 3 seconds.
----- Original Message -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Wednesday, February 19, 2014 6:40:37 PM Subject: Re: technical spec for the workstation up for review
----- Original Message -----
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Right. But firewalld can't a Fedora-only solution, otherwise no application developer will want to integrate with it.
We don't need the application developer to intergrate with it. All we do is that in the GNOME Shell/NetworkManager we ask a question the first time you connect to a new network, something like 'Is this a trusted network?'. If the answer is yes we put firewalld in trusted network mode for that network, and everytime the user connects to that network afterwards we default to that trusted setting without asking again. In this mode the firewall will let basically anything through.
For untrusted networks like conference wifi or internet cafes people choose 'not trusted' and we use the current firewalld default.
These settings can then be toggled in the connection manager if you at any point want a specific network to become trusted/untrusted.
This model is very simply (just 2 modes) and it gives our users some extra security when connecting their laptops in public places, including protecting them from themselves in terms of accidentally sharing their private photos and videos on a public network. It should also be quite unobtrusive.
Christian
On Thu, Feb 20, 2014 at 04:28:10AM -0500, Christian Schaller wrote:
This model is very simply (just 2 modes) and it gives our users some extra security when connecting their laptops in public places, including protecting them from themselves in terms of accidentally sharing their private photos and videos on a public network. It should also be quite unobtrusive.
The point is that applications can't depend on this behaviour, because there's no standardised API for managing it. That's not too much of a problem for packaging things inside Fedora, but it's somewhat problematic for independently packaged apps.
As I pointed out in the email you are responding to, there is no application support requirement here.
Christian
----- Original Message -----
From: "Matthew Garrett" mjg59@srcf.ucam.org To: desktop@lists.fedoraproject.org Sent: Thursday, February 20, 2014 4:14:47 PM Subject: Re: technical spec for the workstation up for review
On Thu, Feb 20, 2014 at 04:28:10AM -0500, Christian Schaller wrote:
This model is very simply (just 2 modes) and it gives our users some extra security when connecting their laptops in public places, including protecting them from themselves in terms of accidentally sharing their private photos and videos on a public network. It should also be quite unobtrusive.
The point is that applications can't depend on this behaviour, because there's no standardised API for managing it. That's not too much of a problem for packaging things inside Fedora, but it's somewhat problematic for independently packaged apps.
-- Matthew Garrett | mjg59@srcf.ucam.org -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Thu, Feb 20, 2014 at 10:21:50AM -0500, Christian Schaller wrote:
As I pointed out in the email you are responding to, there is no application support requirement here.
Yes, there is. Applications need to be able to inform the user as to whether or not they're going to work in the current network environment, and they need to be able to tell the user what to do about that. Failing silently is unhelpful.
Hi, Well failing silently isn't helpful, but probably better than the alternative here. Let me outline two scenarios (no firewall at all vs firewall feature as I suggested) as I see them.
Using your laptop at home (trusted network): More or less identical behavior between the two options.
Using laptop at conference/internet cafe: No firewall: All your services and applications will just work
Downside: Your private media and files might end up being made available to anyone on the network. Bigger attack surface
What we would want applications to do: Have the services listening on the network be stopped.
With firewall as described: If you choose the network to be trusted, all your services and applications will just work If you choose the network to be not trusted, your services and applications will silently fail
Downside If you choose the network to be trusted, same as the non-firewall scenario If you choose the network to be not trusted, your services and applications will silently fail
What we would want applications to do: Check if they can actually function and notify user if not
-------------- So to me it seems like we have a trade off between helping protect users privacy and security versus people might having trouble correlating their choice of non-trusted network with DLNA sharing not working on the conference network. (Of course the conference network might also be causing the problem depending on its configuration.)
In both cases we would ideally like the application developers to take some action in terms of how they deal with the situation. That said to me the request we would make of them in the firewall scenario seems easier to do generically than the option we would like them to take in the second option, and also less of a risk when some of the app devs will not do what we hope they will.
Christian
----- Original Message -----
From: "Matthew Garrett" mjg59@srcf.ucam.org To: desktop@lists.fedoraproject.org Sent: Thursday, February 20, 2014 4:24:29 PM Subject: Re: technical spec for the workstation up for review
On Thu, Feb 20, 2014 at 10:21:50AM -0500, Christian Schaller wrote:
As I pointed out in the email you are responding to, there is no application support requirement here.
Yes, there is. Applications need to be able to inform the user as to whether or not they're going to work in the current network environment, and they need to be able to tell the user what to do about that. Failing silently is unhelpful.
-- Matthew Garrett | mjg59@srcf.ucam.org -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
----- Original Message -----
Hi,
<snip>
In both cases we would ideally like the application developers to take some action in terms of how they deal with the situation.
There wasn't any usable APIs for applications when I first replied to this thread, and there still isn't any.
Man "firewalld.dbus" will show you what app developers are supposed to work with.
That said to me the request we would make of them in the firewall scenario seems easier to do generically than the option we would like them to take in the second option, and also less of a risk when some of the app devs will not do what we hope they will.
Certainly, because users will simply disable the firewall and be done with it. That's certainly what I do.
----- Original Message -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, February 21, 2014 10:25:44 AM Subject: Re: technical spec for the workstation up for review
----- Original Message -----
Hi,
<snip> > In both cases we would ideally like the application developers to take some > action in terms of how they deal with the situation.
There wasn't any usable APIs for applications when I first replied to this thread, and there still isn't any.
Man "firewalld.dbus" will show you what app developers are supposed to work with.
Well since the whole context of the discussion was that we can not expect developers to specifically code for firewall.d, I did not of course propose the do this using the firewall.d API. Transmission for instance includes functionality for testing if the port it wants to use is available (and I assume it is not doing that using the firewall.d API).
Of course I don't know if what Transmission does is done using 'non usable' APIs according to your definition.
That said to me the request we would make of them in the firewall scenario seems easier to do generically than the option we would like them to take in the second option, and also less of a risk when some of the app devs will not do what we hope they will.
Certainly, because users will simply disable the firewall and be done with it. That's certainly what I do.
Well I guess you find a lot more value in sharing your photos over DLNA in the local internet cafe than most of us then :). Personally if my DLNA sharing silently failed due to me having chosen the internet cafe to be an untrusted area I would likely never realize as it is not a usecase I have ever cared about.
Christian
Hi,
<snip> > In both cases we would ideally like the application developers to take some > action in terms of how they deal with the situation.
There wasn't any usable APIs for applications when I first replied to this thread, and there still isn't any.
Man "firewalld.dbus" will show you what app developers are supposed to work with.
Well since the whole context of the discussion was that we can not expect developers to specifically code for firewall.d, I did not of course propose the do this using the firewall.d API. Transmission for instance includes functionality for testing if the port it wants to use is available (and I assume it is not doing that using the firewall.d API).
Of course I don't know if what Transmission does is done using 'non usable' APIs according to your definition.
That said to me the request we would make of them in the firewall scenario seems easier to do generically than the option we would like them to take in the second option, and also less of a risk when some of the app devs will not do what we hope they will.
Certainly, because users will simply disable the firewall and be done with it. That's certainly what I do.
Well I guess you find a lot more value in sharing your photos over DLNA in the local internet cafe than most of us then :). Personally if my DLNA sharing silently failed due to me having chosen the internet cafe to be an untrusted area I would likely never realize as it is not a usecase I have ever cared about.
Ultimately someone should probably integrate the use of the UPNP IGD standard better into firewalld, we already have gupnp-igd, so that it can poke firewalld to open up ports dynamically. DLNA is on top of UPNP so there's technologies there that should work and it would nice to be able to have IGD support for firewalld in both a separate firewall/router device and on on local firewalld instances so that when two UPNP devices are communicating they can dynamically open up ports on demand.
Peter
That was my original thinking too, but someone pointed out (I think maybe Bastien?) that UPNP IGD wouldn't work in the local firewall case?
----- Original Message -----
From: "Peter Robinson" pbrobinson@gmail.com
Ultimately someone should probably integrate the use of the UPNP IGD standard better into firewalld, we already have gupnp-igd, so that it can poke firewalld to open up ports dynamically. DLNA is on top of UPNP so there's technologies there that should work and it would nice to be able to have IGD support for firewalld in both a separate firewall/router device and on on local firewalld instances so that when two UPNP devices are communicating they can dynamically open up ports on demand.
Peter
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
Ended up discussing this issue with some people over lunch, so to clarify in the trusted mode there is of course no reason why we couldn't simply not run the firewall at all. Meaning that we start/stop the firewall depending on when you connect to a network you have marked as not trusted. Should solve Lennarts concern about the firewall taking time during boot also.
Christian
----- Original Message -----
From: "Christian Schaller" cschalle@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, February 21, 2014 10:49:20 AM Subject: Re: technical spec for the workstation up for review
----- Original Message -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, February 21, 2014 10:25:44 AM Subject: Re: technical spec for the workstation up for review
----- Original Message -----
Hi,
<snip> > In both cases we would ideally like the application developers to take > some > action in terms of how they deal with the situation.
There wasn't any usable APIs for applications when I first replied to this thread, and there still isn't any.
Man "firewalld.dbus" will show you what app developers are supposed to work with.
Well since the whole context of the discussion was that we can not expect developers to specifically code for firewall.d, I did not of course propose the do this using the firewall.d API. Transmission for instance includes functionality for testing if the port it wants to use is available (and I assume it is not doing that using the firewall.d API).
Of course I don't know if what Transmission does is done using 'non usable' APIs according to your definition.
That said to me the request we would make of them in the firewall scenario seems easier to do generically than the option we would like them to take in the second option, and also less of a risk when some of the app devs will not do what we hope they will.
Certainly, because users will simply disable the firewall and be done with it. That's certainly what I do.
Well I guess you find a lot more value in sharing your photos over DLNA in the local internet cafe than most of us then :). Personally if my DLNA sharing silently failed due to me having chosen the internet cafe to be an untrusted area I would likely never realize as it is not a usecase I have ever cared about.
Christian
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Fri, 2014-02-21 at 06:47 -0500, Christian Schaller wrote:
Should solve Lennarts concern about the firewall taking time during boot also.
Er, well, except to 'solve' that by making the firewall start dependent on which network you connected to, you'd have to wait until the network connection was established to decide whether to start the firewall...which is precisely the wrong way around.
On Fri, Feb 21, 2014 at 04:05:55AM -0500, Christian Schaller wrote:
So to me it seems like we have a trade off between helping protect users privacy and security versus people might having trouble correlating their choice of non-trusted network with DLNA sharing not working on the conference network. (Of course the conference network might also be causing the problem depending on its configuration.)
Those aren't the only options. We could add the desired functionality to the upstream platform.
Which upstream platform are you talking about here? The kernel? Because that is the only upstream platform I can think of that has the kind of marketshare that we could expect most linux software to adapt to it.
Christian
----- Original Message -----
From: "Matthew Garrett" mjg59@srcf.ucam.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, February 21, 2014 3:38:14 PM Subject: Re: technical spec for the workstation up for review
On Fri, Feb 21, 2014 at 04:05:55AM -0500, Christian Schaller wrote:
So to me it seems like we have a trade off between helping protect users privacy and security versus people might having trouble correlating their choice of non-trusted network with DLNA sharing not working on the conference network. (Of course the conference network might also be causing the problem depending on its configuration.)
Those aren't the only options. We could add the desired functionality to the upstream platform.
-- Matthew Garrett | mjg59@srcf.ucam.org -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Fri, Feb 21, 2014 at 10:00:16AM -0500, Christian Schaller wrote:
Which upstream platform are you talking about here? The kernel? Because that is the only upstream platform I can think of that has the kind of marketshare that we could expect most linux software to adapt to it.
Isn't the point of this exercise that we're defining a platform that applications can take advantage of? Obviously for the most part we're doing that using code that applications already take advantage of, but let's not view this as a situation where a lack of existing code means a problem is unsolvable. If we don't want to force users to make a choice between broken applications or potential security risks we don't really have a choice in the matter.
On Wed, 2014-02-19 at 11:42 -0500, Christian Schaller wrote:
Hi, I ended up calling the firewalld maintainer to understand the state of things and there is this concept in firewalld called zones that we should be able to use to create a better user experience, yet at the same time keep the firewall working when people connect with their laptop at an internet cafe for instance.
Just for anyone unfamiliar with it, this works quite a lot like the similar Windows feature. You can set a given NetworkManager connection as being in one of various zones - default set includes the 'special' zones block, drop, dmz and trusted (which do probably approximately what you'd expect from the names) and then external, internal, home, public and work. The system's very flexible and generic, you can define new zones and define the set of services that's blocked and not blocked in each zone.
In Fedora at present, 'public' is the default zone for all connections and there's no 'pop up' or anything when you establish a new connection asking you to select a zone, but you can set the zone for a connection from GNOME's network configuration tool or nm-connection-editor. firewalld's config tool lets you set a zone for an *interface*, but this is overridden if a connection on the interface has a zone specified, IIRC, so for a typical Fedora config it's a dead letter.
On Wed, 2014-02-19 at 08:47 -0500, Bastien Nocera wrote:
it's near impossible to use simple things like Samba browsing, or browsing UPnP shares with the default configuration.
Just a note - Samba browsing ought to work fine. There was a bug with it in F20 - https://bugzilla.redhat.com/show_bug.cgi?id=1038959 - but that turned out to be caused by a bug in NetworkManager - https://bugzilla.redhat.com/show_bug.cgi?id=1032819 - and not actually a problem in firewalld at all. With that fixed, Samba browsing actually works 'out of the box' on Fedora, with no special firewall configuration required.
On Feb 18, 2014 2:24 PM, "Matthias Clasen" mclasen@redhat.com wrote:
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to it since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
Matthias
--
I realize it's early days and process must come before product, but I was hoping to find something here that would differentiate between the Workstation Product and the current/default GNOME desktop offering.
In my imagination, the user was asked what sort of development they do, and appropriate packages were installed and settings applied. For example, vim/emacs with helpful plugins configured, IDEs deployed, compilers and libraries installed, some tooling like devassist or even container integration for testing. Is this more roadmap territory?
--Pete
Pete Travis píše v St 19. 02. 2014 v 12:16 -0700:
On Feb 18, 2014 2:24 PM, "Matthias Clasen" mclasen@redhat.com wrote:
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to
it
since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
Matthias
--
I realize it's early days and process must come before product, but I was hoping to find something here that would differentiate between the Workstation Product and the current/default GNOME desktop offering.
In my imagination, the user was asked what sort of development they do, and appropriate packages were installed and settings applied. For example, vim/emacs with helpful plugins configured, IDEs deployed, compilers and libraries installed, some tooling like devassist or even container integration for testing. Is this more roadmap territory?
--Pete
Right, this is what DevAssistant does. You can easily create a project in your favourite language and DevAssistant does all the dirty work for you (installing packages you will most likely need for programming in that language, setting up an IDE, e.g. Vim or Eclipse, git, creating a project template etc.). If the main target group are developers, DevAssistant should be a big thing for the workstation product. I would even consider preinstalling it. Some integration with the rest of the desktop would be nice, too. For example GOA can support GitHub, OpenShift,... and then you don't have to set it up again in DevAssistant, but it can use GOA. What really makes a difference is not to have all pieces, but to have them nicely integrated to make a pleasant user experience.
Jiri
----- Original Message -----
From: "Jiri Eischmann" eischmann@redhat.com To: desktop@lists.fedoraproject.org Sent: Thursday, February 20, 2014 10:42:24 AM Subject: Re: technical spec for the workstation up for review
Pete Travis píše v St 19. 02. 2014 v 12:16 -0700:
On Feb 18, 2014 2:24 PM, "Matthias Clasen" mclasen@redhat.com wrote:
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to
it
since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
Matthias
--
I realize it's early days and process must come before product, but I was hoping to find something here that would differentiate between the Workstation Product and the current/default GNOME desktop offering.
In my imagination, the user was asked what sort of development they do, and appropriate packages were installed and settings applied. For example, vim/emacs with helpful plugins configured, IDEs deployed, compilers and libraries installed, some tooling like devassist or even container integration for testing. Is this more roadmap territory?
--Pete
Right, this is what DevAssistant does. You can easily create a project in your favourite language and DevAssistant does all the dirty work for you (installing packages you will most likely need for programming in that language, setting up an IDE, e.g. Vim or Eclipse, git, creating a project template etc.). If the main target group are developers, DevAssistant should be a big thing for the workstation product. I would even consider preinstalling it. Some integration with the rest of the desktop would be nice, too. For example GOA can support GitHub, OpenShift,... and then you don't have to set it up again in DevAssistant, but it can use GOA. What really makes a difference is not to have all pieces, but to have them nicely integrated to make a pleasant user experience.
Jiri
Just want to second Jiri here. The nice thing about doing an intergrated product is that we can look at the system as a whole and plan based on that. Which means that instead of trying to cram all kind of functionality into the OS installer for instance, we can rely on things like the Software Installer and the Developer Assistant to be part of the solution.
We should probably add a section to the technical specification talking about DevAssistant and the kind of functionality we want to scope it for.
Christian
On Feb 20, 2014 2:51 AM, "Christian Schaller" cschalle@redhat.com wrote:
----- Original Message -----
From: "Jiri Eischmann" eischmann@redhat.com To: desktop@lists.fedoraproject.org Sent: Thursday, February 20, 2014 10:42:24 AM Subject: Re: technical spec for the workstation up for review
Pete Travis píše v St 19. 02. 2014 v 12:16 -0700:
On Feb 18, 2014 2:24 PM, "Matthias Clasen" mclasen@redhat.com wrote:
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to
it
since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
Matthias
--
I realize it's early days and process must come before product, but I was hoping to find something here that would differentiate between the Workstation Product and the current/default GNOME desktop offering.
In my imagination, the user was asked what sort of development they do, and appropriate packages were installed and settings applied. For example, vim/emacs with helpful plugins configured, IDEs deployed, compilers and libraries installed, some tooling like devassist or even container integration for testing. Is this more roadmap territory?
--Pete
Right, this is what DevAssistant does. You can easily create a project in your favourite language and DevAssistant does all the dirty work for you (installing packages you will most likely need for programming in that language, setting up an IDE, e.g. Vim or Eclipse, git, creating a project template etc.). If the main target group are developers, DevAssistant should be a big thing for the workstation product. I would even consider preinstalling it. Some integration with the rest of the desktop would be nice, too. For example GOA can support GitHub, OpenShift,... and then you don't have to set it up again in DevAssistant, but it can use GOA. What really makes a difference is not to have all pieces, but to have them nicely integrated to make a pleasant user experience.
Jiri
Just want to second Jiri here. The nice thing about doing an intergrated product is that we can look at the system as a whole and plan based on
that.
Which means that instead of trying to cram all kind of functionality into the OS installer for instance, we can rely on things like the Software
Installer
and the Developer Assistant to be part of the solution.
We should probably add a section to the technical specification talking about DevAssistant and the kind of functionality we want to scope it for.
Christian
--
Great! I'm looking forward to the updated spec, and to seeing how integration ideas develop.
To help make Fedora Workstation an OOTB development environment, should I and others focus on contributing to Developer Assistant, or are there other ideas in the works?
Matthias Clasen (mclasen@redhat.com) said:
I've spent quite a bit of time last week on this document: https://fedoraproject.org/wiki/Workstation/Technical_Specification
It is not 100% complete, but I haven't found the time to get back to it since Friday, so I should probably open it up for a first round of review to the other WG member.
Let me know what you think,
What is the rationale for the full depsolved package list? i.e., its it worth setting in stone that 'glusterfs-devel' is part of the list, or is this list merely listing everything such that things like that can be noted for further investigation? (In any case, please pipe the list through sort(1)).
You call out gtk2 and gtk3 separately, but only one version of qt. Intentional? Might be worth covering both 4 and 5.
There's a discussion there about the system installer. Do you feel that the current live installer (modulo parititioning options) meets that criteria? If the workstation's goal is to install 'the workstation', without package selection or similar items, a live install would be more efficient than pacakge-assembly install.
Bill
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Bastien Nocera -
Bill Nottingham -
Christian Schaller -
Colin Walters -
drago01 -
Jaroslav Reznik -
Jiri Eischmann -
Josh Boyer -
Kevin Fenzi -
Lennart Poettering -
Matthew Garrett -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Pete Travis -
Peter Robinson -
Richard Hughes -
Thomas Woerner