Filepro Version 5.0.15

[Brian K. White]

>> When you release versions that far apart (.15 was like over a year 
>> delayed
>> from its intended release from what I remember, and longer still past 
>> .14),
>> well operating systems move on, I'm sorry.  That's what happens when you
>> move slowly in the middle of a fast-moving field.
>>
>> Unfortunately, the users end up paying the price for that in convenience
>> loss.  But what are you gonna do?
>
> As a developer of toolsets for software developers?
>
> I'm going to keep a non-646 patched machine in my build farm.

Is that a general rule about updates to OS's they support? If so where does 
that stop?
The obvious problem is no one can do that for Linux even if you could for 
every single other OS.

Or are you assuming a level of detailed support for this particular OS such 
that they know Open Servers quirks specifically, enough to know the various 
milestones in the Open Server line and so treat pre/post oss646*, rs50**, 
osr50*mp* almost like distinct OS versions.

That might not be unreasonable, to be expected to know that it's worth 
trying to stick to binaries that need as few of any of those updates as 
possible, without actually accepting known bugs in your binaries or even in 
the surrounding system if they're in areas that affect you.

But really, other, larger software vendors have done far worse by switching 
to producing only UDK binaries to support both OSR5 and Unixware and no 
longer producing native osr5 binaries.
FP gets way more points in my book for not jumping on that bandwagon and 
slurping up sco's claims of support and compatibility as fact.

Two different products we (used to) use fairly heavily both did that and the 
udk versions were never as reliable as the native ones. But they worked well 
enough that it was hard to prove there was a difference to an outsider. In 
one case the problem is completely 100% reproduceable and demonstrable at 
will. But it requires interaction between 3 things to show (filepro, 
pcmiler, OSR5), all of which do not show any similar problem on their own or 
even in interactions between any 2 of the three. There's no single product 
or party who clearly is responsible, and so no one fixes the problem.
The one pattern is, there was no problem before pcmiler went udk, and the 
same problem has been present in every version since then. So, either udk is 
broken or osr5 is broken, or pcmiler is broken, or, the one innocent would 
seem to be filepro, except, I can't cause the failuer any other way except 
inside a filepro system() command and the same exact commands work outside 
of fp, so you can't quite rule them out either.

The other case is vsi-fax and there it's more nebulous and is only shown by 
simple statitics over time. The udk versions have just been less reliable. 
They are still pretty reliable, more so than lot of other software that is 
relied upon even more heavily, so it's hard to claim it's broken. But, it 
_was_ even _more_ reliable before and there is a clear change for the worse 
and it's just plain galling to be forced to pay for the priviledge of 
upgrading to an inferior product.

The fact that fp chose not to play fast & loose with my world by switching 
to udk binaries when many others did, even though the os vendor not only 
supports that move bt actively pushes it, makes me not care about the 
comparatively minor issue of requiring an admittedly staple os patch that 
really every box should get, or at least should get in addition whenever you 
naturally need to touch that box for any other reason. ... holy cow not only 
are they not udk, at least up to 5.0.13 they're not even elf??? Holy last 
century batman!

Of course now osr5 in general hardly matters to me any more so this is all 
academic.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!