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

* 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?

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

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(a)redhat.com&gt;
To: "Discussions about development for the Fedora desktop"
<desktop(a)lists.fedoraproject.org&gt;
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop

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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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".
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org&gt;

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 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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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(a)scrye.com&gt;
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.

On Thu, 2014-02-20 at 19:36 +0000, Richard Hughes wrote:
> On 20 February 2014 17:47, Kevin Fenzi <kevin(a)scrye.com&gt; 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(a)redhat.com&gt; wrote:
> On Thu, 2014-02-20 at 19:36 +0000, Richard Hughes wrote:
>> On 20 February 2014 17:47, Kevin Fenzi <kevin(a)scrye.com&gt; 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

On 20 February 2014 17:47, Kevin Fenzi <kevin(a)scrye.com&gt;
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(a)redhat.com&gt;
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 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, Feb 19, 2014 at 1:38 PM, Adam Williamson
<awilliam(a)redhat.com&gt; 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.

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

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

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, ...).

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(a)redhat.com&gt;
To: "Discussions about development for the Fedora desktop"
<desktop(a)lists.fedoraproject.org&gt;
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop

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.

----- 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
--
Lennart Poettering, Red Hat

> > 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

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.

From: "Lennart Poettering" <mzerqung(a)0pointer.de&gt;
To: "Discussions about development for the Fedora desktop"
<desktop(a)lists.fedoraproject.org&gt;
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(a)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 Wed, 19.02.14 12:40, Bastien Nocera (bnocera(a)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.

On 02/19/2014 06:57 PM, Lennart Poettering wrote:
>
> On Wed, 19.02.14 12:40, Bastien Nocera (bnocera(a)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.

On Thu, Apr 17, 2014 at 3:40 PM, Thomas Woerner
<twoerner(a)redhat.com&gt; wrote:
> On 02/19/2014 06:57 PM, Lennart Poettering wrote:
>>
>> On Wed, 19.02.14 12:40, Bastien Nocera (bnocera(a)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.

>>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
--
Lennart Poettering, Red Hat

On Tue, 22.04.14 10:44, Thomas Woerner (twoerner(a)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.

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?
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org&gt;
"Tepid change for the somewhat better!"

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.

> 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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org&gt;
"Tepid change for the somewhat better!"

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.

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.

>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.

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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org&gt;
"Tepid change for the somewhat better!"

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...

From: "Bastien Nocera" <bnocera(a)redhat.com&gt;
To: "Discussions about development for the Fedora desktop"
<desktop(a)lists.fedoraproject.org&gt;
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

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(a)srcf.ucam.org

From: "Matthew Garrett" <mjg59(a)srcf.ucam.org&gt;
To: desktop(a)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(a)srcf.ucam.org
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop

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(a)srcf.ucam.org

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(a)srcf.ucam.org&gt;
To: desktop(a)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(a)srcf.ucam.org
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop

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.

From: "Bastien Nocera" <bnocera(a)redhat.com&gt;
To: "Discussions about development for the Fedora desktop"
<desktop(a)lists.fedoraproject.org&gt;
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

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(a)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(a)redhat.com&gt;
To: "Discussions about development for the Fedora desktop"
<desktop(a)lists.fedoraproject.org&gt;
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(a)redhat.com&gt;
> To: "Discussions about development for the Fedora desktop"
> <desktop(a)lists.fedoraproject.org&gt;
> 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop

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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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(a)srcf.ucam.org

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(a)srcf.ucam.org&gt;
To: "Discussions about development for the Fedora desktop"
<desktop(a)lists.fedoraproject.org&gt;
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(a)srcf.ucam.org
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop

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.
--
Matthew Garrett | mjg59(a)srcf.ucam.org

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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

On Feb 18, 2014 2:24 PM, "Matthias Clasen" <mclasen(a)redhat.com&gt; 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

From: "Jiri Eischmann" <eischmann(a)redhat.com&gt;
To: desktop(a)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(a)redhat.com&gt;
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

----- Original Message -----
> From: "Jiri Eischmann" <eischmann(a)redhat.com&gt;
> To: desktop(a)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(a)redhat.com&gt;
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

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?

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