<div dir="ltr">This discussion around GUI vs CLI is as old as I am - more or less - and I'm not sure it's as simple as having a GUI abstraction to increase uptake. I have been using both environments for most of my career and as far as I can tell it's always about what works best for any particular problem.<div><br></div><div>The most visible place this was brought home to me was a decade or more ago when I was evaluating KDE vs GNOME by running two plain desktops side-by-side in identical virtual machines. I wasn't interested in performance metrics, I was looking to learn what the useability differences were.</div><div><br></div><div>It was at the time a stark contrast between the two. Most notable was the Control Panel environment. Under GNOME you had access to a limited number of buttons and preferences. A screen would typically have no more than a dozen, more often less than that, settings and options for things like screen rendering, panels, edge detection, etc. Under KDE it appeared that pretty much every single option was visible in the GUI, making for pages and pages of settings that most users would never need or want and as a power user myself, I still didn't need or want.</div><div><br></div><div>The point is that GUI abstraction is about finding a balance between usability and functionality and I think that's the precise point where we run into issues with things like firewalls. There's always going to be the top-10 things people want to achieve with their firewall, those can well go into a GUI, but if that prevents someone doing something that is unexpected, then you've essentially killed off that functionality, even though the underlying system is perfectly capable of achieving it.</div><div><br></div><div>One potential method is to use a GUI to generate a text configuration that can be edited in a text-editor and that doesn't get overwritten by the GUI when edited later. You can put this into a git repository and track changes, because changes are where 99.99% of the mistakes happen - after initial configuration.</div><div><br></div><div>While a dumbing down of complex concepts can be achieved by a GUI, I don't think that security and productivity are actually increased by hiding complexity. Some things ARE complex and pretending that they are not is going to bite you every time.</div><div><br></div><div>o</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 22 Feb 2024 at 08:07, Brad Campbell <<a href="mailto:brad@fnarfbargle.com">brad@fnarfbargle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22/2/24 08:02, Dean Bergin wrote:<br>
> Hello Bill,<br>
> <br>
> Thanks for sharing.<br>
> <br>
> As a network engineer, I'm not normally exposed to these sorts of tools (I normally operate on commercial grade/proprietary products like firewalls or routers) so I often don't see much value in operating a host-level firewall unless it's a server and/or said server participates in routing and/or carries data plane traffic and you don't trust upstream.<br>
> <br>
<br>
G'day Fred ;)<br>
<br>
Yes in this case the devices in question are among other things acting as firewalls and routers. One of the next items on my todo list is to put a proper firewall/router in place so these machines are further from the "world".<br>
While I like the idea of a GUI abstraction, this particular case is one where there is a pretty robust and flexible GUI in place (new OpenWRT), however it doesn't have the flexibility to put the rules in place I need.<br>
At least with direct access I can build the rules manually rather than relying on the GUI to do it for me.<br>
<br>
Regards,<br>
Brad<br>
_______________________________________________<br>
PLUG discussion list: <a href="mailto:plug@plug.org.au" target="_blank">plug@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/plug" rel="noreferrer" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
Committee e-mail: <a href="mailto:committee@plug.org.au" target="_blank">committee@plug.org.au</a><br>
PLUG Membership: <a href="http://www.plug.org.au/membership" rel="noreferrer" target="_blank">http://www.plug.org.au/membership</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Onno Benschop<br><br>()/)/)()        ..ASCII for Onno..<br>|>>?            ..EBCDIC for Onno..<br>--- -. -. ---   ..Morse for Onno..<br><br><span style="color:rgb(136,136,136)">If you need to know: "What computer should I buy?" </span><a href="http://goo.gl/spsb66" style="color:rgb(17,85,204)" target="_blank">http://goo.gl/spsb66</a><div><br>ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219 8888   -   <a href="mailto:onno@itmaze.com.au" target="_blank">onno@itmaze.com.au</a></div></div></div>