Re: merge ping6(8) into ping(8)

2016-09-18 Thread Theo de Raadt
> On Sun, Sep 18, 2016 at 12:11 AM, Theo de Raadt  wrote:
> >>  > this does 2 things:
> >>  > [...]
> >>
> >> I may recall what I have sent to you in private email, excerpt from
> >> FreeBSD ping6 manpage:
> >> [...]
> >> When we have two binaries I have more trust when one of them is working
> >> *only* with IPv4 and another one *only* with IPv6.
> >>
> >> So, what user problems are you trying to solve with this merge?
> >>
> >
> > Mikhail, with great regret I am informing you that the opinion of some
> > random gmail user does not actually matter around here.
> 
> It's not about opinion, everyone has it. It's about understanding why
> a thing was done. If a person can't answer to the question "why" a
> thing was done, I suppose he don't fully understand a solution to a
> problem he is trying to solve.
> 
> Random gmail users can bring value as much as fullnamed developers.

sorry to hear you don't understand

this is not really a forum to attempt education



Re: merge ping6(8) into ping(8)

2016-09-18 Thread Stuart Henderson
On 2016/09/18 00:04, Mikhail wrote:
> > this does 2 things:
> > [...]
> 
> I may recall what I have sent to you in private email, excerpt from FreeBSD
> ping6 manpage:
> 
> 8<8<8<8<8<8<
> There have been many discussions on why we separate ping6 and ping(8).
> Some people argued that it would be more convenient to uniform the ping
> command for both IPv4 and IPv6.  The followings are an answer to the
> request.
> 
> From a developer's point of view: since the underling raw sockets API is
> totally different between IPv4 and IPv6, we would end up having two types of
> code base.  There would actually be less benefit to uniform the two commands
> into a single command from the developer's standpoint.

Much of the code doesn't relate to the sockets API. Option parsing,
timestamp perturbation, printing, etc are all mostly common.

> From an operator's point of view: unlike ordinary network applications like
> remote login tools, we are usually aware of address family when using
> network management tools.  We do not just want to know the
> reachability to the host, but want to know the reachability to the host
> via a particular network protocol such as IPv6.  Thus, even if we had a
> unified ping(8) command for both IPv4 and IPv6, we would usually type a
> -6 or -4 option (or something like those) to specify the particular
> address family.  This essentially means that we have two different
> commands.
> 
> 8<8<8<8<8<8<
> 
> When we have two binaries I have more trust when one of them is working
> *only* with IPv4 and another one *only* with IPv6.

As a network operator if I'm interested in reachability to a specific
machine I'm certainly not going to rely on DNS.

And as a user if I'm interested in reachability of a service (which
covers the majority of ping usage) I don't care which af is used. In
fact I'd prefer to know about "whichever af is used by default to reach
this host".

> So, what user problems are you trying to solve with this merge?

Future changes to ping/ping6 only need to be done in one place, no risk
of them getting out of sync. Less disk space. Faster compiles. Less
setuid root code to audit.

The only reason I see for *not* merging them is that no developer
wanted to do the work.

Why should they be separate programs? We don't have to choose between
firefox and firefox6.



Re: merge ping6(8) into ping(8)

2016-09-18 Thread Mikhail
On Sun, Sep 18, 2016 at 12:11 AM, Theo de Raadt  wrote:
>>  > this does 2 things:
>>  > [...]
>>
>> I may recall what I have sent to you in private email, excerpt from
>> FreeBSD ping6 manpage:
>> [...]
>> When we have two binaries I have more trust when one of them is working
>> *only* with IPv4 and another one *only* with IPv6.
>>
>> So, what user problems are you trying to solve with this merge?
>>
>
> Mikhail, with great regret I am informing you that the opinion of some
> random gmail user does not actually matter around here.

It's not about opinion, everyone has it. It's about understanding why
a thing was done. If a person can't answer to the question "why" a
thing was done, I suppose he don't fully understand a solution to a
problem he is trying to solve.

Random gmail users can bring value as much as fullnamed developers.



Re: merge ping6(8) into ping(8)

2016-09-17 Thread Theo de Raadt
>  > this does 2 things:
>  > [...]
> 
> I may recall what I have sent to you in private email, excerpt from 
> FreeBSD ping6 manpage:
> 
> 8<8<8<8<8<8<
> There have been many discussions on why we separate ping6 and ping(8).
> Some people argued that it would be more convenient to uniform the ping
> command for both IPv4 and IPv6.  The followings are an answer to the 
> request.
> 
>  From a developer's point of view: since the underling raw sockets API is
> totally different between IPv4 and IPv6, we would end up having two 
> types of code base.  There would actually be less benefit to uniform the 
> two commands into a single command from the developer's standpoint.
> 
>  From an operator's point of view: unlike ordinary network applications 
> like remote login tools, we are usually aware of address family when 
> using network management tools.  We do not just want to know the
> reachability to the host, but want to know the reachability to the host
> via a particular network protocol such as IPv6.  Thus, even if we had a
> unified ping(8) command for both IPv4 and IPv6, we would usually type a
> -6 or -4 option (or something like those) to specify the particular
> address family.  This essentially means that we have two different
> commands.
> 8<8<8<8<8<8<
> 
> When we have two binaries I have more trust when one of them is working 
> *only* with IPv4 and another one *only* with IPv6.
> 
> So, what user problems are you trying to solve with this merge?
> 

Mikhail, with great regret I am informing you that the opinion of some
random gmail user does not actually matter around here.



Re: merge ping6(8) into ping(8)

2016-09-17 Thread Mikhail

> this does 2 things:
> [...]

I may recall what I have sent to you in private email, excerpt from 
FreeBSD ping6 manpage:


8<8<8<8<8<8<
There have been many discussions on why we separate ping6 and ping(8).
Some people argued that it would be more convenient to uniform the ping
command for both IPv4 and IPv6.  The followings are an answer to the 
request.


From a developer's point of view: since the underling raw sockets API is
totally different between IPv4 and IPv6, we would end up having two 
types of code base.  There would actually be less benefit to uniform the 
two commands into a single command from the developer's standpoint.


From an operator's point of view: unlike ordinary network applications 
like remote login tools, we are usually aware of address family when 
using network management tools.  We do not just want to know the

reachability to the host, but want to know the reachability to the host
via a particular network protocol such as IPv6.  Thus, even if we had a
unified ping(8) command for both IPv4 and IPv6, we would usually type a
-6 or -4 option (or something like those) to specify the particular
address family.  This essentially means that we have two different
commands.
8<8<8<8<8<8<

When we have two binaries I have more trust when one of them is working 
*only* with IPv4 and another one *only* with IPv6.


So, what user problems are you trying to solve with this merge?



Re: merge ping6(8) into ping(8)

2016-09-17 Thread Florian Obser
... and this does things to the build infrastructure.

It survives make release on amd64, it survived i386 in the past but
I'm currently running another make release. I'm trying armv7, too.

Tests on other archs would be very welcome, thanks!

diff --git distrib/amd64/common/list distrib/amd64/common/list
index 4b4f4b1..153c880 100644
--- distrib/amd64/common/list
+++ distrib/amd64/common/list
@@ -40,7 +40,7 @@ LINK  instbin sbin/mount
 LINK   instbin sbin/mount_cd9660
 LINK   instbin sbin/mount_ffs
 LINK   instbin sbin/newfs
-LINK   instbin sbin/ping
+LINK   instbin sbin/ping sbin/ping6
 LINK   instbin sbin/reboot sbin/halt
 LINK   instbin sbin/restore
 LINK   instbin sbin/route
diff --git distrib/amd64/ramdisk_cd/list.local 
distrib/amd64/ramdisk_cd/list.local
index 79982af..7e149a8 100644
--- distrib/amd64/ramdisk_cd/list.local
+++ distrib/amd64/ramdisk_cd/list.local
@@ -1,8 +1,6 @@
 # $OpenBSD: list.local,v 1.26 2015/10/07 18:02:06 krw Exp $
 
 # add local links; use bin/sh since instbin has already been unlinked
-LINK   instbin sbin/ping6
-
 LINK   instbin sbin/dhclient
 LINK   instbin sbin/bioctl
 
diff --git distrib/armv7/ramdisk/list distrib/armv7/ramdisk/list
index 0d13059..82d100e 100644
--- distrib/armv7/ramdisk/list
+++ distrib/armv7/ramdisk/list
@@ -47,8 +47,7 @@ LINK  instbin sbin/mount_nfs
 LINK   instbin sbin/newfs
 LINK   instbin sbin/newfs_ext2fs
 LINK   instbin sbin/newfs_msdos
-LINK   instbin sbin/ping
-LINK   instbin sbin/ping6
+LINK   instbin sbin/ping sbin/ping6
 LINK   instbin sbin/reboot sbin/halt
 LINK   instbin sbin/route
 LINK   instbin sbin/sysctl
diff --git distrib/hppa/list distrib/hppa/list
index 0e2e181..b0f23b7 100644
--- distrib/hppa/list
+++ distrib/hppa/list
@@ -40,8 +40,7 @@ LINK  instbin 
sbin/mount_cd9660
 LINK   instbin sbin/mount_ffs
 LINK   instbin sbin/mount_nfs
 LINK   instbin sbin/newfs
-LINK   instbin sbin/ping
-LINK   instbin sbin/ping6
+LINK   instbin sbin/ping sbin/ping6
 LINK   instbin sbin/reboot sbin/halt
 LINK   instbin sbin/route
 LINK   instbin sbin/sysctl
diff --git distrib/i386/common/list distrib/i386/common/list
index 17d8e39..3d8b00f 100644
--- distrib/i386/common/list
+++ distrib/i386/common/list
@@ -41,7 +41,7 @@ LINK  instbin sbin/mount
 LINK   instbin sbin/mount_cd9660
 LINK   instbin sbin/mount_ffs
 LINK   instbin sbin/newfs
-LINK   instbin sbin/ping
+LINK   instbin sbin/ping sbin/ping6
 LINK   instbin sbin/reboot sbin/halt
 LINK   instbin sbin/route
 LINK   instbin sbin/sysctl
diff --git distrib/i386/ramdisk_cd/list.local distrib/i386/ramdisk_cd/list.local
index 8a59bc8..18ad5b8 100644
--- distrib/i386/ramdisk_cd/list.local
+++ distrib/i386/ramdisk_cd/list.local
@@ -3,7 +3,6 @@
 # add local links; use bin/sh since instbin has already been unlinked
 LINK   instbin sbin/mount_ext2fs
 LINK   instbin sbin/mount_msdos
-LINK   instbin sbin/ping6
 LINK   instbin sbin/mount_udf
 LINK   instbin sbin/restore
 LINK   instbin sbin/bioctl
diff --git distrib/landisk/ramdisk/list distrib/landisk/ramdisk/list
index ea06d58..ba42a8f 100644
--- distrib/landisk/ramdisk/list
+++ distrib/landisk/ramdisk/list
@@ -45,8 +45,7 @@ LINK  instbin sbin/mount_msdos
 LINK   instbin sbin/mount_nfs
 LINK   instbin sbin/newfs
 LINK   instbin sbin/newfs_msdos
-LINK   instbin sbin/ping
-LINK   instbin sbin/ping6