Fedora 21 To Evaluate Remote Journal Logging, 64-bit ARM Emulation

[phoronix]

Phoronix: Fedora 21 To Evaluate Remote Journal Logging, 64-bit ARM Emulation

Yesterday on Phoronix we covered 12 new feature proposals for Fedora 21 and following that story yesterday were a handful of new feature proposals for this next major Fedora release...

http://www.phoronix.com/vr.php?view=MTY2NDk

[liam]

So, because gnome hasn't designed the interface for firewalld the solution is to disable it until they do create one?
Science!
The firewalld interface isn't bad except fur one annoying thing: the tricky runtime/permanent modes. That should be made clearer. Other than that, guess what? Networking is just really complicated and trying to guess what's right and then not exposing the necessary manual configuration tools to fix it means that, like most gnome tools, it either just works or you have to dig into non-gui solutions (and for networking that can be, as I said, very complicated). That design pattern might be gnome's biggest weakness and lack of manpower is no excuse. This is really, simply, a design issue. They've no interest in exposing these things, regardless. If they're auto-detection doesn't work, file a bug, and in the meantime live with a broken system
Sorry for the rant. I find myself becoming less generous towards gnome the more I hear about them.

[RahulSundaram]

So, because gnome hasn't designed the interface for firewalld the solution is to disable it until they do create one?
Sorry for the rant. I find myself becoming less generous towards gnome the more I hear about them.

None of the changes being discussed have much to do with the desktop environment. Enabling or disabling the firewall is a distro level decision and firewalld has no connection to any desktop environment.

[zanny]

So, firewalld vs ufw. My understanding is ufw was developed first, and that firewalld has some NIH syndrome going on from the Red Hat camp, unless I'm missing some critical failing in ufw that prevented its extension with whatever features firewalld was lacking.

I don't know who to be mad at here for the duplication and waste of developer effort, though, so someone enlighten me?

[Ericg]

So, firewalld vs ufw. My understanding is ufw was developed first, and that firewalld has some NIH syndrome going on from the Red Hat camp, unless I'm missing some critical failing in ufw that prevented its extension with whatever features firewalld was lacking.

I don't know who to be mad at here for the duplication and waste of developer effort, though, so someone enlighten me?

UFW is unmaintained last time I checked out Arch, and has been for awhile.

As far as Firewalld... AFAIK, ufw had to stop and restart the firewall to load the new configuration, which could make it miss connections and just let everything go. Firewalld can load new configurations without restarting the iptables backend. Also it brings to the table new Firewall Zones which can let different networks have different configurations and trust/denial.

[zanny]

So it is more Upstart and Systemd than Wayland and Mir. I've been using ufw on Arch for years, and I had to go check to make sure, but community/ufw is still up to date with upstream (0.33-3), so unless that isn't getting maintained (and I have a hard time buying Canonical not keeping its firewall up to date for Ubuntu) then it should still be doing its job. It is just a simplified interface to iptables anyway. I wonder if either of them is going to support nftables...

I'll keep using ufw for now, though, because I just really like the kde firewall UI for it, makes rule modification really quick.

[Ericg]

So it is more Upstart and Systemd than Wayland and Mir. I've been using ufw on Arch for years, and I had to go check to make sure, but community/ufw is still up to date with upstream (0.33-3), so unless that isn't getting maintained (and I have a hard time buying Canonical not keeping its firewall up to date for Ubuntu) then it should still be doing its job. It is just a simplified interface to iptables anyway. I wonder if either of them is going to support nftables...

I'll keep using ufw for now, though, because I just really like the kde firewall UI for it, makes rule modification really quick.

Last released version was 0.33... 2 years ago[1]. There's been changes here and there since then[2], but nothing substantial and nothing saying its coming towards a new release.

[1] https://launchpad.net/ufw
[2] http://bazaar.launchpad.net/~jdstran...tart_revid=860

How much its "maintained" is up for debate. Personally I've got a thing about using pretty much unmaintained system services, BUT not everyone is the same. So if you're happy using it, go right ahead. Just mentioning it since you brought it up.

[liam]

None of the changes being discussed have much to do with the desktop environment. Enabling or disabling the firewall is a distro level decision and firewalld has no connection to any desktop environment.

I'm not entirely sure what "distro" means given f.N. The proposal I read was for Workstation (so, gnome). Currently we ship both the firewalld service AND gui called firewalld (which looks gtk based to my eye). What Mattias proposed was disabling the service and thus probably not installing the GUI by default.

The current level of integration into the desktop and applications does not justify enabling the firewalld service by default. Additionally, the set of zones that we currently expose is excessive and not user-friendly. Therefore, we will disable the firewall service while we are working on a more user-friendly way to deal with network-related privacy issues.


It will of course still be possible to enable the firewall manually.

The concern is one of DESKTOP and app "integration". The concern is about "ease of use" and making sharing easy. It's very much about desktop environment and perceived notions of what that environment is supposed to do. Fit corporate users those zones are very handy. The problem is that the zones haven't been configured properly to allow for the behavior the owners of gnome desire. Disabling firewalld because of that would be like disabling selinux because packager x won't work with it on. The solution, in both cases, is to fix the relevant policies not disabling key services.

[RahulSundaram]

I'm not entirely sure what "distro" means given f.N. The proposal I read was for Workstation (so, gnome). Currently we ship both the firewalld service AND gui called firewalld (which looks gtk based to my eye). What Mattias proposed was disabling the service and thus probably not installing the GUI by default.

You haven't understood the proposal at all. It has nothing to do with not installing a GUI. firewalld is a system level firewall and doesn't require any kind of frontend. The proposal is about disabling the service by default.

firewalld can have any kind of graphical frontends but those frontends are not part of any desktop environment and is just a distro tool. disabling the service is a distro level decision (ie) Fedora workstation developers decide that. Not GNOME.

[Vim_User]

You haven't understood the proposal at all. It has nothing to do with not installing a GUI. firewalld is a system level firewall and doesn't require any kind of frontend. The proposal is about disabling the service by default.

firewalld can have any kind of graphical frontends but those frontends are not part of any desktop environment and is just a distro tool. disabling the service is a distro level decision (ie) Fedora workstation developers decide that. Not GNOME.

Huh? I can't think of ways to make that proposal more clear:

The current level of integration into the desktop and applications does not justify enabling the firewalld service by default.

This clearly states that firewalld will be disabled by default because it lacks desktop integration. How can that have nothing to do with with the GUI?