From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <71f34c7f2a7fac1912f332bbdb14e2ac@brasstown.quanstro.net> References: <3e1e9e6fbfa856a01013a2f51b8d244f@coraid.com> <34270f8ddb3fc06e71d4db496a891dd4@brasstown.quanstro.net> <71f34c7f2a7fac1912f332bbdb14e2ac@brasstown.quanstro.net> Date: Thu, 19 Dec 2013 09:58:48 -0600 Message-ID: From: Blake McBride To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1133251eb72eff04ede53c1f Subject: Re: [9fans] mk time-check/slice issue Topicbox-Message-UUID: a0eaa606-ead8-11e9-9d60-3106f5b1d025 --001a1133251eb72eff04ede53c1f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 19, 2013 at 8:55 AM, erik quanstrom wrote: > > I was thinking about the problem and actually, at least in all > > circumstances I can think of, changing that one operation from <= to < > > would fix the problem. If the times are on the same second, I would > never > > have had time to change it. This would fix the problem. Perhaps this > > functionality can be controlled by an environment variable like NPROC. > > i thought this idea might come up. i think the reason not to do this > is a very fundamental principle: correctness. never give up on > correctness. > > I for one favor practical usefulness over theoretical correctness. An environment variable option would trivially satisfy both groups. It could operate as-is so nothing pre-existing would be affected. Blake --001a1133251eb72eff04ede53c1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 19, 2013 at 8:55 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> I was thinking about = the problem and actually, at least in all
> circumstances I can think of, changing that one operation= from <=3D to <
> would fix the problem. =A0If the times are on the same se= cond, I would never
> have had time to change it. =A0This would fix the problem= . =A0Perhaps this
> functionality can be controlled by an environment variabl= e like NPROC.

i thought this idea might come up. =A0i thi= nk the reason not to do this
is a very fundamental principle: correctness. =A0never give up on correctness.


I for one favor practical usefulness=A0over theoreti= cal correctness. =A0An environment variable option would trivially satisfy= =A0both groups. It could operate as-is so nothing pre-existing would be aff= ected.

Blake
=A0
--001a1133251eb72eff04ede53c1f--