On Aug 23, 2014 6:45 AM, "Elad Alfassa" <elad@fedoraproject.org> wrote:
>
> On Fri, Aug 22, 2014 at 6:08 PM, Christoph Wickert <christoph.wickert@gmail.com> wrote:
>>
>>
>> I don't think we missed that point, in fact it was already addressed
>> earlier by Thomas, when he quoted the workstation's mission statement:
>> "The system will primarily be aimed at providing a platform for
>> development of server side and client applications that is attractive to
>> a range of developers - from hobbyists and students to developers
>> working in corporate environments."
>>
>> So if the goal of the platform is development and our target audience
>> are hobbyists, students, and developers, how can "simple enough for
>> non-technical users" be a criteria for inclusion of apps?
>>
>
> We need to eradicate this dangerous notion that a "technical user" or a "developer" knows everything about the ins and outs of an operation system or computer networks.
>  It leads to bad design.
>
I'm not sure anyone is saying that, but the idea that a developer doesn't know what ports are is a bit unlikely, if not impossible. The point, I think, is that the workstation product has a fundamentally more focused target than any other of the major platforms. As such, looking to, for instance, osx, as providing the exact experience we want may not make sense. Obviously they do some things very well, but checking those boxes may not be the best use of effort in order to make the Fedora desktop a better developer environment.

>
> If your OS is good enough for non-technical users to use it without being intimidated or confused by it, then it will be easy and simple for developers too.
>
Yes, but let's not confuse that with, "if it satisfies the needs of the "nontechnical" user it'll work well for the developer".

> If you design your software thinking your users will know immidiately how to operate it and how it works because they are "technical" you will have software that is extremely painful to use.
>
> Another point is that our product definition states we should support all these usecases while still being usable for the non-technical users.
>
Yes, but (sorry for the many buts ;) that is more of a secondary issue. The point of all this is to bring in more contributors. IMHO, the most likely path to that goal is to focus on making Fedora a desktop that is designed with developers in mind. A mostly usable desktop for all should fall out of that effort.

>> > If it's really important then we should keep it, but if it just works
>> > out of the box as I've heard (thanks to the firewalld team for working
>> > on this!), then hopefully it can go.
>>
>> Accessing the internet does work out of the box, but FWIW a lot of
>> client and server development will not. Therefor I suggest we keep
>> firewall-config for now and continue to improve it's UI.
>
>
> You are wrong, I'm sorry.
> Our default firewall configuration allows any port higher than 1024 (ie. high ports / non-root ports) to accept incoming connections, as well as some very specific services such as avahi or samba-client. This means that the following will work out of the box:
>  * Network printing
>  * Avahi zeroconf auto-discovery
>  * Samba network shares
>  * Web browsing
>  * Python / Ruby web stacks which default to using a non-root port when running as a non root user, which is the normal way in which Python / Ruby web developer test their applications.
>  * Anything else that listens on a non-root port
>
> Most developers will not need to touch the firewall configuration because everything will just work. And as emphasized before, we are not aiming this product at linux system developers, we are aiming it at web developers, android developers, application developers, game developers and such. Non of these target usecases will ever need to use a port lower than 1024.
>
> So if most of are target users might not know what a firewall is or how to operate one, might not know about protocols, ports, or how computer networking actually works, and will probably not need to change the default configuration *ever*, including this tool by default seems silly to me. And again, people who for some reason don't want the default can install the tool from GNOME Software easily enough, so there's no real reason why it should be included by default.
>
Again, I'd love to see the evidence that "most of our target users" won't know about firewalls (you say might, but given that this discussion is about dropping a part of the current standard install, we probably need more than fud to go on).
Personally, I've never had to adjust the firewall for (web)development reasons, but for personal use I most certainly have (and being able to type in firewall, and having it popup, AND knowing it's the tool that should work, unlike installing random firewall app X, is a nice feeling).

Best/Liam



On Sat, Aug 23, 2014 at 6:45 AM, Elad Alfassa <elad@fedoraproject.org> wrote:
On Fri, Aug 22, 2014 at 6:08 PM, Christoph Wickert <christoph.wickert@gmail.com> wrote:

I don't think we missed that point, in fact it was already addressed
earlier by Thomas, when he quoted the workstation's mission statement:
"The system will primarily be aimed at providing a platform for
development of server side and client applications that is attractive to
a range of developers - from hobbyists and students to developers
working in corporate environments."

So if the goal of the platform is development and our target audience
are hobbyists, students, and developers, how can "simple enough for
non-technical users" be a criteria for inclusion of apps?


We need to eradicate this dangerous notion that a "technical user" or a "developer" knows everything about the ins and outs of an operation system or computer networks.
 It leads to bad design.


If your OS is good enough for non-technical users to use it without being intimidated or confused by it, then it will be easy and simple for developers too. If you design your software thinking your users will know immidiately how to operate it and how it works because they are "technical" you will have software that is extremely painful to use.

Another point is that our product definition states we should support all these usecases while still being usable for the non-technical users.

> If it's really important then we should keep it, but if it just works
> out of the box as I've heard (thanks to the firewalld team for working
> on this!), then hopefully it can go.

Accessing the internet does work out of the box, but FWIW a lot of
client and server development will not. Therefor I suggest we keep
firewall-config for now and continue to improve it's UI.

You are wrong, I'm sorry.
Our default firewall configuration allows any port higher than 1024 (ie. high ports / non-root ports) to accept incoming connections, as well as some very specific services such as avahi or samba-client. This means that the following will work out of the box:
 * Network printing
 * Avahi zeroconf auto-discovery
 * Samba network shares
 * Web browsing
 * Python / Ruby web stacks which default to using a non-root port when running as a non root user, which is the normal way in which Python / Ruby web developer test their applications.
 * Anything else that listens on a non-root port

Most developers will not need to touch the firewall configuration because everything will just work. And as emphasized before, we are not aiming this product at linux system developers, we are aiming it at web developers, android developers, application developers, game developers and such. Non of these target usecases will ever need to use a port lower than 1024.

So if most of are target users might not know what a firewall is or how to operate one, might not know about protocols, ports, or how computer networking actually works, and will probably not need to change the default configuration *ever*, including this tool by default seems silly to me. And again, people who for some reason don't want the default can install the tool from GNOME Software easily enough, so there's no real reason why it should be included by default.


--
-Elad Alfassa.

--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop