On 04/17/2014 03:51 PM, drago01 wrote:
On Thu, Apr 17, 2014 at 3:40 PM, Thomas Woerner <twoerner@xxxxxxxxxx> wrote:
On 02/19/2014 06:57 PM, Lennart Poettering wrote:
On Wed, 19.02.14 12:40, Bastien Nocera (bnocera@xxxxxxxxxx) 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.
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop
