Re: merge ping6(8) into ping(8)
> On Sun, Sep 18, 2016 at 12:11 AM, Theo de Raadtwrote: > >> > 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)
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)
On Sun, Sep 18, 2016 at 12:11 AM, Theo de Raadtwrote: >> > 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)
> > 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)
> 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)
... 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