NetBSD Problem Report #44781

From fair@clock.org  Mon Mar 28 16:48:50 2011
Return-Path: <fair@clock.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 0403C63BB73
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 28 Mar 2011 16:48:49 +0000 (UTC)
Message-Id: <20110328164845.55F3715ECAF@cesium.clock.org>
Date: Mon, 28 Mar 2011 09:48:45 -0700 (PDT)
From: fair@netbsd.org
Reply-To: fair@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: units(1) currency conversions are not dynamic or updated
X-Send-Pr-Version: 3.95

>Number:         44781
>Category:       bin
>Synopsis:       units(1) currency conversions are not dynamic or updated
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar 28 16:50:00 +0000 2011
>Last-Modified:  Sun Oct 09 22:15:01 +0000 2016
>Originator:     Erik E. Fair
>Release:        NetBSD 5.1
>Organization:
	The NetBSD Project
>Environment:
>Description:
	The units(1) program's currency conversion values were last
	updated in 1993. While perhaps of historical interest, it's
	not very useful. The program should either have a mechanism
	for the user to trigger an update to those currency exchange
	conversion tables, or they should be removed from the
	program's units library (database).

	One example in a competing system: the Mac OS X "calculator"
	application does unit conversions similarly to the units
	program, but its currency conversion tables can be updated
	by the user (there is a menu option for that - the program
	is not doing so on any periodic or continuous basis, so
	its many instances (i.e. every Mac OS X instance in the
	world) are not beating the data source to death with update
	queries).

	This is just the most obvious example of a more general
	problem in this program: there are conversion units which
	are physical constants, and then there are units which are
	measured, and those measurements can change over time (e.g.
	the number of seconds in a year (we have leap seconds added
	by the IERS, and how does that affect the definition of a
	light year?)), sometimes quite dynamically (e.g. currency
	exhange rates).

	The units program should have two databases (libraries)
	for conversion units: one that's static as in the current
	implementation, and a second one for dynamic units whose
	contents can be fetched/update on a triggered basis by any
	user of the program. Further, at minimum, the source of
	the information should be documented for authentication
	purposes, if not actually authenticated by the update
	mechanism itself.

	The "dynamic" units library's last update timestamp should
	be presented to the user, and compared against current
	date, with a warning if the data is "too old."

>How-To-Repeat:
	visual inspection of /usr/share/misc/units.lib
>Fix:


>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/44781: units(1) currency conversions are not dynamic or
 updated
Date: Sun, 9 Oct 2016 22:12:56 +0000

 On Mon, Mar 28, 2011 at 04:50:00PM +0000, fair@netbsd.org wrote:
  > 	The units(1) program's currency conversion values were last
  > 	updated in 1993. While perhaps of historical interest, it's
  > 	not very useful. The program should either have a mechanism
  > 	for the user to trigger an update to those currency exchange
  > 	conversion tables, or they should be removed from the
  > 	program's units library (database).

 As we saw the other day, currency conversion values can vary on the
 timescale of seconds. But even when that kind of thing doesn't happen,
 they vary substantially on the scale of days to weeks. This is faster
 than any reasonable update schedule for the units(1) database.

 Since having wrong things in units(1) is not useful, I think these
 ought to be dropped.

  > 	The units program should have two databases (libraries)
  > 	for conversion units: one that's static as in the current
  > 	implementation, and a second one for dynamic units whose
  > 	contents can be fetched/update on a triggered basis by any
  > 	user of the program. Further, at minimum, the source of
  > 	the information should be documented for authentication
  > 	purposes, if not actually authenticated by the update
  > 	mechanism itself.

 Having "any user" update a system file requires having a setuid
 program downloading stuff off the internet, which isn't really the
 world's greatest idea.

 But ignoring that -- where does this proposed database come from and
 who's going to maintain it every week?

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

Home	PR Database Search