putty - filepro -sco

[Fairlight]

Simon--er, no...it was Brian K. White--said:
> Careful. That version of openssh for osr5 has been obsoleted by several
> later sco builds.  Obsoleted 2 ways, newer versions, and simpler
> custom-installable packages, not to mention the intangible blessing of
> simply being built and packaged by SCO themselves.

Not to mention security patches too numerous to actually count.  Yours was
the only pre-OSR6 binary dist of which I was aware, however.

And personally, I don't consider it a blessing that SCO compiles it
themselves. i consider it an inexcusable black box situation.  Witness that
perl, when it actually builds, fails about 60%+ of its own tests when not
modifying the source.  Last time I tried, I determined it was going to take
significant effort to port it correctly.  Significant being more money than
it would cost to just switch to BSD or Linux--and all for -one- subsystem.

Apache wouldn't build at all (1.3.37) on 5.0.6a with gcc from SkunkWare.
Getting a new gcc to build was an exercise in futility, as the provided gcc
crashed while trying to do so.  OSR6 doesn't even -have- a gcc, last time I
checked (repeatedly).

Basically, that platform is a lost cause for compiling, as far as I'm
concerned.  The only blessing of SCO having built it is that a binary dist
exists at all.  But that comes at the cost of living with what they're
willing to release--which has historically been behind the curve and not
keeping in line with security bulletins.  Last time I checked, users had
the option of 1.3.33 apache, buying SCO Office for 1.3.37, or punting.  I
don't consider that a viable set of options.

It's really simple for me:  If you really want the true flexibility of open
source software, SCO is the wrong platform.  It's fine for canned stuff.
It's not robust enough a platform to easily accomodate running a lot of OSS
stuff, however.  It'd be a cold day in hell before I tried compiling PHP on
that beast unless someone was seriously willing to pay for even the
attempt.  It's bad enough on systems on which it -should- build just fine.
I don't want to think about how badly it would fail on a system on which
perl needs major mojo to work correctly.

And quite obviously, they've not exactly ingratiated themselves to the
community so that people bother porting things regularly to it, given their
lawsuits, etc.  It was bad enough when it was just a beast to build on.
Now it's a beast to build on -and- people detest them.  Not a winning
combination.

They can gussy it up all they like, release the odd version of this or that
for which they figure their users should be grateful, but the method to
their madness is inadequate at best, in my opinion.

When SCO users can actually get the latest security updates, prebuilt by
SCO, within a week of the alerts hitting the SANS digest, let me know.  So
far it's not even been within six months in many cases--notably apache,
which is just plain -stupid-.  Yup, let's let a public service with a known
hole just sit there.  That's bright.  Why, again, was SCAMP a good idea
when they don't even keep one of the initials current?  And if they don't
bother with updating apache, you can almost bank on their not updating PHP,
which given the holes that come up in PHP and how often they come up, would
be a far more grievous sin of omission.

In other words, not something I'd personally take seriously as a robust,
secure solution.  They'd need to get a lot more serious about it and stop
relying on a community that's being hamstrung by lack of a decent and
officially supported ANSI compiler (esp in OSR6) before I'd consider it
anything other than a poor joke on their part.

This isn't me going back to my '93-'95 anti-SCO stance borne of BSD vs SysV
differences I wasn't happy with.  This is simply looking objectively at
what is easily and reasonably tennable and what is not on the platform,
without breaking the bank, and deciding what is not a good fit.  I find it
to be an abysmal fit.  About their only saving grace is that they ship perl
standard now, and perl very, very rarely needs security updates.  But even
their perl dist has issues--like XS modules having an 80%+ chance of not
working against the SCO-built main dist, even when they build.  They tend
to not like to load.  So much for their saving grace.

And unlike ye olden days, I don't have hours to sit around porting stuff
because it's fun.  In fact, I consider it more of a PITA now than anything.
The fun went out of porting about 5+ years ago for me.  I just need to get
stuff -done- and done -right- (ie., securely), and that is ot the platform
on which it's most easily and cost-effectively achievable, to say the least.

Bill Campbell had -the- biggest archive of open-source ports for SCO.  I
think the flow of new ports has shrunk, if not ceased.  What's that tell
you?  It tells me that it ain't just me--and his porting chops have
-always- been better than mine, hands down.  It's definitely nothing to do
with skill on his end.  It must have been a choice with a reason backing
it, as I've never known him to do anything without a solid reason--whether
I agreed with it or not.

Bottom line:  If SCO is offering ports, they better be secure.  If they're
not, that's SCO's problem, not mine, since that's almost all that's
available anymore and the gcc available is increasingly undependable for
newer software.  But that's almost all there is anymore.  So people using
SCO for open source based projects buys their tickets and takes their
chances, IMHO.

mark->
-- 
The latest synth mixdown...
http://media.fairlite.com/Isolation_Voiceless_Cry_Mix.mp3