[Info-vax] Hard links on VMS ODS5 disks

[Arne Vajhøj]

On 7/17/2023 6:45 AM, Johnny Billquist wrote:
> On 2023-07-16 20:30, Arne Vajhøj wrote:
>> On 7/16/2023 2:28 PM, Arne Vajhøj wrote:
>>> The two cost are hardware and peoples time.
>>>
>>> With todays TB disks it is very unlikely that having two copies of some
>>> executables will require buying bigger and more expensive disk(s).
>>>
>>> Having developer support the name test logic on multiple platforms
>>> and having sys admins needing to worry about linked stuff
>>> when they clean up is a very small effort but still an
>>> effort greater than zero.
>>
>> And just to make sure we are talking about the same.
> 
> [...]
> 
> Yes. And my point is that this detail is there no matter what. So you 
> didn't "save" anything by having two binaries. Since it's actually just 
> one binary, and how it behaves is based on which name it was invoked as.
> 
> Yes, you *could* have different binaries, with the different behaviors, 
> and not have to deal with all this.
> 
> But that was not what was going on here. The binary we are talking about 
> still have this logic you are hinting at. It's just that in addition to 
> that engineering work, which seems to be your concern, it also uses up 
> twice the space (or even more, depending on how many copies of the 
> program you happen to install).
> 
> I feel like you didn't get the point that the decision on what the 
> program should do based on under what name it was invoked was not absent 
> with these multiple copies... It is still there, and still made use of.

Ah.

You are saying that they ditched the linking but kept the code
that made linking work.

As if in my example had done:

$ cc ab
$ link/exe=a ab
$ link/exe=b ab

That is silly in my opinion. They should have gotten rid of that code.

Simple is good - complex is bad.

Arne