On Fri, Apr 08, 2011 at 10:33:17PM -0700, Garrett Cooper wrote: >On Fri, Apr 8, 2011 at 9:54 PM, J. Hellenthal <jh...@dataix.net> wrote: >> On Fri, Apr 08, 2011 at 07:36:45PM +0400, Sergey Vinogradov wrote: >>>On 08.04.2011 19:23, Mike Oliver wrote: >>>>On Fri, Apr 8, 2011 at 08:08, Sergey Vinogradov<boo...@lazybytes.org> >>>>wrote: >>>>>Hi, hackers. >>>>>I have a question: why ipv4 netmask is displayed by ifconfig in hex format? >>>>>Isn't dot-decimal notation more human-readable? Will the attached patch >>>>>break something in the very bad way? >>>> >>>>Who's using IPv4 anymore? ;-) >>>Long live IPv4! :) >>> >>>>Seriously though, if you give a small amount of time to learning the >>>>hex -> binary translations then you would see how convenient it is to >>>>use hex rather than decimal when representing what are ultimately >>>>binary numbers. >>>> >>>>See this blog entry by Jeff Doyle... >>>> >>>>http://www.networkworld.com/community/blog/how-are-your-hexadecimal-skills >>>The article is great, but dot-decimal notation is de-facto standard >>>for stand-alone network mask representation. Like CIDR is standard for >>>IP blocks represenation. That's the reason I've started this thread. >>>And despite the greatness of the article you've mentioned, I think >>>it's a bad itea to hardcode its URL into ifconfig's output. You know, >>>for every single user reading it, and choosing the "way of hex" ;) >>> >> >> This is the year 2011 right ? when are we going to support new users >> rather than supporting old outdated washed up "scripts" ? >> >> I for one am for this change, given that there are lots of users from >> the PC-BSD community that do not read hexadecimal, octal and other such >> forms like a programmer does. >> >> And just because the change can be made does not mean that a >> compatibility shim cannot be put into place that restores the old >> functionality. >> >> >> It is time to stop living in the past and start thinking about the >> future. These types of things are what causes forks of projects to >> happen ultimately yielding in less contributors and developers. I for >> one hate to see things like that happen. > >I understand your pain and while I've been on your side of the fence >several times in the past dealing with different things of this sort, >having to maintain backwards compatibility is a painful reality of >past design choices or mistakes. pkg_install and sysinstall are one of >many examples, but there are of course other areas as well. > >Although I see the value of your and Sergey's argument, the problem is >that it may cause unexpected breakage for other third parties that >depend on a particular behavior in FreeBSD as Bjoern and others have >suggested; I have a script at least that does properly parse out the >hex output in order to set IPs properly with ipmitool, and I would be >perturbed to have to hack around this further in my script. Mind you, >this script is in my workspace, but having to track minor output >changes like this across versions of FreeBSD, or interface changes >like the semi-gratuitous removal of /dev/<device>c in 8.x still had to >be worked out on many branches my group maintains at $WORK. > >Getting back on track, I think that more 'user friendly' variants of >FreeBSD, e.g. PCBSD, etc, could and should diverge with this one line >patch as they're not mainline FreeBSD and the change is trivial for >less hex inclined users as you suggest. > >Granted, this is just one of many bikeshed topics. Funny how many >lines of debate have been written and how many feathers have been >unnecessarily ruffled over the output of one printf. >
Yeah I can agree with that. In either case right now (to me) it makes utterly no difference and is just a cosmetic fix as I can read hex, oct, dec in either fashion and convert between them quickly. I just hate to see other non-technical users fall subject to the same things that have been support way past a deprecation period that should have ended 10+ years ago. Anyway there are so many views on this, in any case the right decision is made going forth and positives and negatives can be discussed then. -- J. Hellenthal
pgpOEzTg9C6fE.pgp
Description: PGP signature
