allowing programs to open ports
Stephen John Smoogen
smooge at gmail.com
Mon Dec 22 17:58:21 UTC 2014
On 22 December 2014 at 01:26, Björn Persson <Bjorn at rombobjörn.se> wrote:
> Stephen John Smoogen wrote:
> >Uhm no. You seem to be wanting a fight over something, and I have no
> >mood to engage. I hope you have a more pleasant holidays than what
> >your tone indicates you are currently having.
> The idea of making two calls to open a port seemed like a bad design to
> me, so I proposed what seemed like a better design. I received a reply
> that rejected my proposal for a very vague technical reason and an
> incomplete political reason, so I asked for clarification of both
> reasons. I honestly can't see how any of that would come across as
> picking a fight.
> In general I wish people could discuss the technical merits of proposed
> solutions without turning the discussions into personal fights all the
I would love that also. But as far as I can tell you started the personal
fight. It is very hard to believe you wanted a technical discussion with
sentence structure like:
So you think that countless other upstreams would feel compelled to
accept the patches to always open ports twice, because they want their
software to work on Fedora, but GlibC is important enough to be able to
refuse without risk of being dropped from Fedora? Or maybe that GlibC
can refuse because it's a library and can push the problem up to the
You barrel over my attempt at conversation by giving me idiotic options to
try and defend that I never said in the first place..
To try and technically answer your strawmen questions:
1) I do not feel that countless programs will or want to accept patches to
open ports twice. I expect them to actually open a port once and if they
want to work with firewalld or some other firewall daemon signal on dbus
that they are looking to have a port open using a predefined and open
protocol. The port will be open like it always was and the firewall will be
closed if they don't use it, and possibly open if they do (depending on the
top level policy of whatever firewall management program is there).
2) glibc is important enough to be able to refuse without risk of being
dropped from Fedora. Just like the kernel is important enough to regularly
refuse things without risk of being dropped from Fedora.
3) glibc is meant to work on multiple OS's and distributions. Fedora and
even Red Hat are not important enough to force through a change that isn't
in the interests of other distributions. Which is where the vague politics
comes up. This sort of change would require working with other
distributions, other OS's and other organizations to get their consensus on
how it should work. That takes a long amount of meetings, talking with
people, showing them why it would be worthwhile, figuring out all the
corner cases and seeing if they are fixable, etc. And it would see if it
breaks various 'promises' like POSIX compliance and such that the glibc
team work actively to keep.
> Björn Persson
> devel mailing list
> devel at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel