From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <3e1e9e6fbfa856a01013a2f51b8d244f@coraid.com> <34270f8ddb3fc06e71d4db496a891dd4@brasstown.quanstro.net> <71f34c7f2a7fac1912f332bbdb14e2ac@brasstown.quanstro.net> <257c46.301443fc.D01R.mx@tumtum.plumbweb.net> Date: Thu, 19 Dec 2013 11:40:36 -0500 Message-ID: From: Jacob Todd To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e013a10462e51db04ede5d245 Subject: Re: [9fans] mk time-check/slice issue Topicbox-Message-UUID: a1190474-ead8-11e9-9d60-3106f5b1d025 --089e013a10462e51db04ede5d245 Content-Type: text/plain; charset=UTF-8 No one is stopping you from changing it in your installation. On Dec 19, 2013 11:38 AM, "Blake McBride" wrote: > On Thu, Dec 19, 2013 at 10:30 AM, Tristan <9p-st@imu.li> wrote: > >> > 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. >> >> how long does it take you to run mk, and then realise you didn't Put your >> last set of changes? >> >> i once changed mk on my local machine to act as you suggest, and then >> took far too long trying to figure out why the program's behavior didn't >> reflect the code. more time than i saved from waiting on mk? who knows? >> > > If the situation you describe can happen then it definitely shouldn't be > changed. Could you please provide me with a scenario (sequence of events) > that would be a problem if mk was changed? I can't think of one. > > Thanks. > > Blake > > --089e013a10462e51db04ede5d245 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

No one is stopping you from changing it in your installation= .

On Dec 19, 2013 11:38 AM, "Blake McBride&qu= ot; <blake@mcbride.name> wr= ote:
On T= hu, Dec 19, 2013 at 10:30 AM, Tristan <9p-st@imu.li> wrote:
> I for one favor practical usefulness over theoretical correctness= . =C2=A0An
> environment variable option would trivially satisfy both = groups. It could
> operate as-is so nothing pre-existing would be affected.<= br>
how long does it take you to run mk, and th= en realise you didn't Put your
last set of changes?

i once changed mk on my local machine to act as y= ou suggest, and then
took far too long trying to figure out why the program's b= ehavior didn't
reflect the code. more time than i s= aved from waiting on mk? who knows?<= br>

If the situation you describe can happen t= hen it definitely shouldn't be changed. =C2=A0Could you please provide = me with a scenario (sequence of events) that would be a problem if mk= =C2=A0was changed? =C2=A0I can't think of one.

Thanks.

Blake
=C2=A0=
--089e013a10462e51db04ede5d245--