On Wed, Feb 15, 2017 at 1:46 PM, Mark Millard wrote:
> Gleb Smirnoff glebius at FreeBSD.org wrote
> on Tue Feb 14 18:32:40 UTC 2017 :
>
>> After some discussion on svn mailing list [1], there is intention
>> to remove SVR4 binary compatibilty layer from FreeBSD head,
Gleb Smirnoff glebius at FreeBSD.org wrote
on Tue Feb 14 18:32:40 UTC 2017 :
> After some discussion on svn mailing list [1], there is intention
> to remove SVR4 binary compatibilty layer from FreeBSD head, meaning
> that FreeBSD 12.0-RELEASE, available in couple of years would
> be shipped
On 2017-Feb-14 10:32:32 -0800, Gleb Smirnoff wrote:
> After some discussion on svn mailing list [1], there is intention
>to remove SVR4 binary compatibilty layer from FreeBSD head, meaning
>that FreeBSD 12.0-RELEASE, available in couple of years would
>be shipped without it.
On 02/15/2017 08:56, Mark Martinec wrote:
In a similar vein, I noticed also the following in our logs,
with net.inet.tcp.log_in_vain=1.
Looks like messages got concatenated somehow:
Jan 25 01:37:53 mildred kernel: TCP: [2607:ff10:c5:509a::10]:26459 to
[2001:1470:ff80::80:16]:4911 tcpflags 0x2;
2017-02-06 18:04, Eric van Gyzen wrote:
On 02/06/2017 10:19, Mark Martinec wrote:
Hope the fix finds its way into 11.1 (or better yet, as a patch level
in 10.0). Should I open a bug report?
It will quite likely get into 11.1. As for a 10.x patch, you would
have
to ask re@ (I think), but
Well, I'd like to offer help keeping it (because on a personal
opinion, I'd like being compatible `:-D).
But the reasons are pretty reasonable and convincing :-).
I have no more objections against removing it when security risks involves.
--
Best wishes, MMokhi.
In message <20170215081430.gc58...@freebsd.org>, Gleb Smirnoff writes:
>Well, we all "maintain" it, meaning that we keep it compilable. However,
>I'm sure that no one checks the functionality. There are no regression
>tests, and seems to be no users.
And probably nobody ever bothered to
On Wed, Feb 15, 2017 at 10:56:29AM +0330, mokhi wrote:
m> Is this removing is because no-interest on maintaining it?
m>
m> If it helps, I am working to use the `kern_* instead sys_*` as
m> mentioned patch in that discussion suggests for svr4, if this helps.
Well, we all "maintain" it, meaning