A few tools for improving software security

[John Dallman]

Simon's postings would tend to indicate that he believes that
anything not subject to constant probing by hundreds or thousands
of hack.., er, security researchers is just full of latent bugs
waiting to be discovered.

Hundreds of researchers are only a few times as effective as one. I've
done some of this, and worked with people who do more: given good tools,
a few man-months can make significant improvements. In the order in which
they were used:

Valgrind is a binary instrumentation tool: it decompiles an executable
into a higher-level abstract machine language, inserts instrumentation
and recompiles that into the machine language. It doesn't need source,
although it does need debug symbols. https://valgrind.org/ It gets used
for building many kinds of execution monitors and checking tools.

The only one I've used is Memcheck, which finds usage of uninitialised
data, by the brute-force technique of tracking the initialisation status
of every byte of memory in the process. This is too slow to use in
production, but I spent a few months tracking down and fixing all the
uses of uninitialised memory, and we basically stopped getting
unrepeatable run-time errors. Now one of the junior engineers keeps it
running through all our tests on a regular basis and fixing newly added
uses of uninitialised data.

Our QA team use another Valgrnd tool, Callgrind, to track which files and
functions are called by all of our tests. Keeping this up to date keeps a
few machines busy full-time, but it's invaluable. The data is kept in an
SQL database in inverted form, so when developers change source, they can
find out which test cases go through the changed files in seconds, and
run those test cases to find and fix regressions before they release
changes into source-management.

Valgrind runs on Unix-like operating systems. I run it on x86-64 Linux,
which is by far the most-used platform.

Static analysis starts with a compile-like process, in which you run all
your source through an analysis tool that behaves like a compiler.
There's then a pretty heavyweight process of matching up all the
functions, variables and possible execution paths, and then you have data
that can be used to spot security problems, via further automatic
analysis. It's kind of like "lint" on a whole-program basis. The tool I
use is Coverity, which is commercial, and got picked for us by the larger
company. It isn't brilliant, but it works. It runs on Windows, Linux and
Mac.

<https://www.synopsys.com/software-integrity/static-analysis-tools-sast/co
verity.html>

Fuzz testing is the main thing that security researchers do. Digging
through disassembly listings for vulnerabilities by eye is very slow and
unreliable. You need to be able to run the software you're "fuzzing" and
to be able to feed it a data file. You use a fuzz testing tool which runs
the software and monitors it for segmentation violations and other
exceptions. It also mutates the data file, by modifying, inserting and
removing bytes. A bit of correlation analysis lets it find its way to
minimal test cases for exceptions. This burns up a fair bit of CPU power:
people in my team have had four or eight threads on an old x86-64 box
running for about a year. In that time, we've found and fixed a bit more
than one defect per working day.

There are lots of frameworks for fuzzing, but AFL
<https://en.wikipedia.org/wiki/American_Fuzzy_Lop_(software)> is
considered pretty good, and is what we use.

With all these tools, we fix the defect, via initialisation, extra logic
or whatever, without attempting to discover if it could be used for an
actual attack. Proving that's impossible is *much* harder than fixing it.


John

[Arne Vajhøj]

Post by John Dallman
Hundreds of researchers are only a few times as effective as one. I've
done some of this, and worked with people who do more: given good tools,
a few man-months can make significant improvements. In the order in which
Valgrind is a binary instrumentation tool: it decompiles an executable
into a higher-level abstract machine language, inserts instrumentation
and recompiles that into the machine language. It doesn't need source,
although it does need debug symbols. https://valgrind.org/ It gets used
for building many kinds of execution monitors and checking tools.
The only one I've used is Memcheck, which finds usage of uninitialised
data, by the brute-force technique of tracking the initialisation status
of every byte of memory in the process. This is too slow to use in
production, but I spent a few months tracking down and fixing all the
uses of uninitialised memory, and we basically stopped getting
unrepeatable run-time errors. Now one of the junior engineers keeps it
running through all our tests on a regular basis and fixing newly added
uses of uninitialised data.
Our QA team use another Valgrnd tool, Callgrind, to track which files and
functions are called by all of our tests. Keeping this up to date keeps a
few machines busy full-time, but it's invaluable. The data is kept in an
SQL database in inverted form, so when developers change source, they can
find out which test cases go through the changed files in seconds, and
run those test cases to find and fix regressions before they release
changes into source-management.
Valgrind runs on Unix-like operating systems. I run it on x86-64 Linux,
which is by far the most-used platform.

Those tools are mostly C/C++ centric right?

If one would be a little cynical: tools to mitigate those languages
lack of the strictness found in other languages.

Post by John Dallman
Static analysis starts with a compile-like process, in which you run all
your source through an analysis tool that behaves like a compiler.
There's then a pretty heavyweight process of matching up all the
functions, variables and possible execution paths, and then you have data
that can be used to spot security problems, via further automatic
analysis. It's kind of like "lint" on a whole-program basis. The tool I
use is Coverity, which is commercial, and got picked for us by the larger
company. It isn't brilliant, but it works. It runs on Windows, Linux and
Mac.
<https://www.synopsys.com/software-integrity/static-analysis-tools-sast/co
verity.html>

I have heard good things about Coverity.

There are alternatives. Commercial: CAST, Klocwork etc.. Open source:
Sonarcube, PMD etc..

Such tools can actually find a lot.

Post by John Dallman
Fuzz testing is the main thing that security researchers do. Digging
through disassembly listings for vulnerabilities by eye is very slow and
unreliable. You need to be able to run the software you're "fuzzing" and
to be able to feed it a data file. You use a fuzz testing tool which runs
the software and monitors it for segmentation violations and other
exceptions. It also mutates the data file, by modifying, inserting and
removing bytes. A bit of correlation analysis lets it find its way to
people in my team have had four or eight threads on an old x86-64 box
running for about a year. In that time, we've found and fixed a bit more
than one defect per working day.
There are lots of frameworks for fuzzing, but AFL
<https://en.wikipedia.org/wiki/American_Fuzzy_Lop_(software)> is
considered pretty good, and is what we use.

Arne

[John Dallman]

Post by Arne Vajhøj

Post by John Dallman
Valgrind runs on Unix-like operating systems. I run it on x86-64
Linux, which is by far the most-used platform.

Those tools are mostly C/C++ centric right?

* Valgrind works on binaries and has no idea what HLL you used. Most
fuzzers are the same AFAIK.

* Coverity needs to know about the source language, but it reads
a lot of them.

Post by Arne Vajhøj
If one would be a little cynical: tools to mitigate those languages
lack of the strictness found in other languages.

Coverity tries to do that. Fuzzing detects the ability to overrun buffers,
irrespective of how it's done.

John

[Arne Vajhøj]

Post by John Dallman

Post by Arne Vajhøj

Post by John Dallman
Valgrind runs on Unix-like operating systems. I run it on x86-64
Linux, which is by far the most-used platform.

Those tools are mostly C/C++ centric right?

* Valgrind works on binaries and has no idea what HLL you used. Most
fuzzers are the same AFAIK.

But native code right.

When working on binaries the source languages obviously
does not matter. But for *nix/Windows there is a pretty
good chance that native code is C or C++.

I wonder how difficult it would be to get it running
on VMS x86-64. ELF image format and x86-64 instruction
set are already done. But I assume it would need to know
about various RTL.

Arne

[John Dallman]

Post by Arne Vajhøj
I wonder how difficult it would be to get it running
on VMS x86-64. ELF image format and x86-64 instruction
set are already done. But I assume it would need to know
about various RTL.

It certainly needs to know about run-times. Valgrind itself is C. The
project's platforms page says:

Windows is not under consideration because porting to it would require
so many changes it would almost be a separate project. ... Also,
non-open-source OSes are difficult to deal with; being able to see
the OS and associated (libc) source code makes things much easier.

VMS is not Windows, but their respective difference from Linux are on a
similar scale. VSI could presumably port it, but it is clearly a long way
from being the most urgent thing for them to do.

John

[Craig A. Berry]

Post by John Dallman

Post by Arne Vajhøj
I wonder how difficult it would be to get it running
on VMS x86-64. ELF image format and x86-64 instruction
set are already done. But I assume it would need to know
about various RTL.

It certainly needs to know about run-times. Valgrind itself is C. The
Windows is not under consideration because porting to it would require
so many changes it would almost be a separate project. ... Also,
non-open-source OSes are difficult to deal with; being able to see
the OS and associated (libc) source code makes things much easier.
VMS is not Windows, but their respective difference from Linux are on a
similar scale. VSI could presumably port it, but it is clearly a long way
from being the most urgent thing for them to do.

AddressSanitizer might be more possible given the LLVM-based compilers
on x86. But I believe -fsanitize requires a link-time component, and it
isn't clear to me whether it could operate on the downstream side of the
GEM2IR translations, and if not, it could only work for clang. And a lot
of the OS modules written in C are probably not clang-ready at this
point. So it wouldn't be a small project. Whether it would be a big
project or a humongous one I don't know.

[Lawrence D'Oliveiro]

VSI could presumably port [valgrind], but it is clearly a long
way from being the most urgent thing for them to do.

On the other hand, it would be something else that they could get
essentially for free with a Linux port.

[John Dallman]

Post by Lawrence D'Oliveiro

VSI could presumably port [valgrind], but it is clearly a long
way from being the most urgent thing for them to do.

On the other hand, it would be something else that they could get
essentially for free with a Linux port.

However, they aren't going to do that, are they?

Going that way would need to have been started much earlier, at the start
of the x86-64 port. It would have required doing something that was a
*much* better version of the Sector 7 product, and avoiding the existing
VMS customers losing confidence in VSI. That's two quite hard things, and
starting on them now makes less sense than carrying on with the current
strategy, for good or ill.

John

[Lawrence D'Oliveiro]

Post by John Dallman
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.

I think that’s called the “sunk-cost fallacy”.

[Simon Clubley]

Post by John Dallman
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.

I think that?s called the ?sunk-cost fallacy?.

So VSI's choices are to either continue selling x86-64 systems to customers
and complete the missing bits, or they stop selling systems for 3 years
while they write a migration tool from the ground up for something that
will never be as close in operation as the first option above.

Hmmm, I wonder which option they will choose ? :-)

Lawrence, you manage to make the current bunch of extreme zealots on both
sides of the political landscape in the US seem reasonable.

Simon.

PS: Although given it's looking likely that one of those groups will be
heading back into power in a year's time, I wonder how I (and the rest of
the world) will feel about that then...

[Dan Cross]

Post by Simon Clubley

Post by John Dallman
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.

I think that?s called the ?sunk-cost fallacy?.

So VSI's choices are to either continue selling x86-64 systems to customers
and complete the missing bits, or they stop selling systems for 3 years
while they write a migration tool from the ground up for something that
will never be as close in operation as the first option above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on both
sides of the political landscape in the US seem reasonable.

I would suggest respectfully to stop feeding the troll. Or, as
I suspect he's less a troll than just a crank, perhaps stop
turning the crank.

- Dan C.

[Simon Clubley]

Post by Dan Cross

Post by Simon Clubley

Post by John Dallman
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.

I think that?s called the ?sunk-cost fallacy?.

So VSI's choices are to either continue selling x86-64 systems to customers
and complete the missing bits, or they stop selling systems for 3 years
while they write a migration tool from the ground up for something that
will never be as close in operation as the first option above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on both
sides of the political landscape in the US seem reasonable.

I would suggest respectfully to stop feeding the troll. Or, as
I suspect he's less a troll than just a crank, perhaps stop
turning the crank.

I know Dan. I'm finally at the end of trying to reason with him, and
I have come to the same conclusion that others have, but I consider it
rude to just stop talking to someone without explaining why, which
I have now done. :-)

Simon.

[Dave Froble]

Post by Simon Clubley

Post by Dan Cross

Post by Simon Clubley

Post by John Dallman
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.

I think that?s called the ?sunk-cost fallacy?.

So VSI's choices are to either continue selling x86-64 systems to customers
and complete the missing bits, or they stop selling systems for 3 years
while they write a migration tool from the ground up for something that
will never be as close in operation as the first option above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on both
sides of the political landscape in the US seem reasonable.

I would suggest respectfully to stop feeding the troll. Or, as
I suspect he's less a troll than just a crank, perhaps stop
turning the crank.

I know Dan. I'm finally at the end of trying to reason with him, and
I have come to the same conclusion that others have, but I consider it
rude to just stop talking to someone without explaining why, which
I have now done. :-)
Simon.

What is really rude is talking about Linux on c.o.v ...

[bill]

Post by Dave Froble

Post by Simon Clubley

Post by Simon Clubley

Post by John Dallman
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.

I think that?s called the ?sunk-cost fallacy?.

So VSI's choices are to either continue selling x86-64 systems to customers
and complete the missing bits, or they stop selling systems for 3 years
while they write a migration tool from the ground up for something that
will never be as close in operation as the first option above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on both
sides of the political landscape in the US seem reasonable.

I would suggest respectfully to stop feeding the troll.  Or, as
I suspect he's less a troll than just a crank, perhaps stop
turning the crank.

I know Dan. I'm finally at the end of trying to reason with him, and
I have come to the same conclusion that others have, but I consider it
rude to just stop talking to someone without explaining why, which
I have now done. :-)
Simon.

What is really rude is talking about Linux on c.o.v ...

I don't know about rude, but even suggesting that the VMS kernel
(which now runs just fine on x86-64) should be replaced with a
Linux kernel has to be the stupidest idea I have ever seen here.

bill

[Dave Froble]

Post by bill

Post by Dave Froble

Post by Simon Clubley

Post by Dan Cross

Post by Simon Clubley

Post by John Dallman
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.

I think that?s called the ?sunk-cost fallacy?.

So VSI's choices are to either continue selling x86-64 systems to customers
and complete the missing bits, or they stop selling systems for 3 years
while they write a migration tool from the ground up for something that
will never be as close in operation as the first option above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on both
sides of the political landscape in the US seem reasonable.

I would suggest respectfully to stop feeding the troll. Or, as
I suspect he's less a troll than just a crank, perhaps stop
turning the crank.

I know Dan. I'm finally at the end of trying to reason with him, and
I have come to the same conclusion that others have, but I consider it
rude to just stop talking to someone without explaining why, which
I have now done. :-)
Simon.

What is really rude is talking about Linux on c.o.v ...

I don't know about rude, but even suggesting that the VMS kernel
(which now runs just fine on x86-64) should be replaced with a
Linux kernel has to be the stupidest idea I have ever seen here.
bill

I don't know Bill, some pretty stupid things have graced c.o.v at times.

:-)

[Lawrence D'Oliveiro]

I don't know about rude, but even suggesting that the VMS kernel (which
now runs just fine on x86-64) should be replaced with a Linux kernel has
to be the stupidest idea I have ever seen here.

Gosh, now there’s an insightful argument I haven’t yet come across in this
discussion ...

[Simon Clubley]

Post by Dave Froble
What is really rude is talking about Linux on c.o.v ...

Unless you consider VMS to be perfect and not in need of any improvement,
other operating systems offer some good ideas that it would be nice to
see in VMS, especially around security and internal isolation in general.

Simon.

[Dave Froble]

Post by Simon Clubley

Post by Dave Froble
What is really rude is talking about Linux on c.o.v ...

Unless you consider VMS to be perfect and not in need of any improvement,
other operating systems offer some good ideas that it would be nice to
see in VMS, especially around security and internal isolation in general.
Simon.

Then discuss the ideas and concepts ...

[Single Stage to Orbit]

Post by Simon Clubley
Lawrence, you manage to make the current bunch of extreme zealots on
both sides of the political landscape in the US seem reasonable.

<sfx: Muttley sniggering>

[Stephen Hoffman]

Post by Simon Clubley

That's two quite hard things, and starting on them now makes less sense
than carrying on with the current strategy, for good or ill.

I think that?s called the ?sunk-cost fallacy?.

So VSI's choices are to either continue selling x86-64 systems to
customers and complete the missing bits, or they stop selling systems
for 3 years while they write a migration tool from the ground up for
something that will never be as close in operation as the first option
above.

Three years' effort is barely a start on the API coverage needed for a
non-trivial app; for a porting library akin to Sector 7.

I'd expect the "kernel transplant" approach to take most of a decade.
If it is even achievable without causing existing customers to migrate
their own apps else-platform; either to Sector 7, or an incremental app
port, or a wholesale port as has happened elsewhere.

Running on multiple platforms (past x86-64 and AArch64) isn't a big
selling point for commercial installations either, and that support
adds vendor testing and qualification and customer support costs for
each of the platforms. And adds costs for ISVs.

And all for no obvious benefit. Yeah, a kernel transplant would
probably make another port (AArch64 or maybe RISC-V) in a decade or two
slightly easier. But that at the cost of a lack of focus; of customers
getting fewer enhancements for another decade, and at the cost of
customers simply waiting for the next port, and with all the usual
disruptions and delays of a port for those that do migrate.

Not gonna happen. Not until well after VSI is a whole lot bigger and a
whole lot better funded, and is encountering some hard limits in their
chosen hardware platform and tooling.

And I still haven't heard a sales pitch for which kernel to pick, as
Linux is but one of many fine choices. And GPL'd Linux quite possibly
not the best choice for grafting a closed-source commercial platform.

Post by Simon Clubley
Hmmm, I wonder which option they will choose ? :-)

This whole scheme reminds me of a sales deal from some years ago, where
a vendor migrated a customer off the vendor's own proprietary platform,
and onto a commodity platform.

The customer was quite happy with their purchase. The vendor did get
that last server hardware sale, but at no small migration cost, and
with ~no long-term future with that customer.


TL;DR: epic troll, or epic dumb.

[Lawrence D'Oliveiro]

Post by Stephen Hoffman
Not gonna happen. Not until well after VSI is a whole lot bigger and a
whole lot better funded, and is encountering some hard limits in their
chosen hardware platform and tooling.

You tell me: either it is too late, or it’s not. If it is, then VMS is
already essentially circling the plughole.

Post by Stephen Hoffman
And I still haven't heard a sales pitch for which kernel to pick, as
Linux is but one of many fine choices. And GPL'd Linux quite possibly
not the best choice for grafting a closed-source commercial platform.

Businesses like to take, but not give back, don’t they?

Many have criticized the GPL on this basis, but one thing it has helped to
ensure is a level playing field. That’s why so many businesses have
adopted GPL’d software, regardless of their earlier carping--because their
competitors had done so, and they didn’t want to be left behind.

Compare the BSDs: there have been several startups over the years that
took the BSD code and made it proprietary, because the licence allows you
to do that. Most startups fail, as you may know. When those startups
failed, their proprietary code died with them. And so the BSD ecosystem
lost yet another bit of its lifeblood.

But when startups build their product on GPL’d code, then if/when they
die, their code lives on, perhaps to fertilize the soil where another
startup can grow.

[Dave Froble]

Post by Lawrence D'Oliveiro

Post by Stephen Hoffman
Not gonna happen. Not until well after VSI is a whole lot bigger and a
whole lot better funded, and is encountering some hard limits in their
chosen hardware platform and tooling.

You tell me: either it is too late, or it’s not. If it is, then VMS is
already essentially circling the plughole.

Post by Stephen Hoffman
And I still haven't heard a sales pitch for which kernel to pick, as
Linux is but one of many fine choices. And GPL'd Linux quite possibly
not the best choice for grafting a closed-source commercial platform.

Businesses like to take, but not give back, don’t they?
Many have criticized the GPL on this basis, but one thing it has helped to
ensure is a level playing field. That’s why so many businesses have
adopted GPL’d software, regardless of their earlier carping--because their
competitors had done so, and they didn’t want to be left behind.
Compare the BSDs: there have been several startups over the years that
took the BSD code and made it proprietary, because the licence allows you
to do that. Most startups fail, as you may know. When those startups
failed, their proprietary code died with them. And so the BSD ecosystem
lost yet another bit of its lifeblood.
But when startups build their product on GPL’d code, then if/when they
die, their code lives on, perhaps to fertilize the soil where another
startup can grow.

This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?

[Arne Vajhøj]

This reminds me of something.  Anybody remember the Sun employee that
used to come here and harass us?  Andrew something maybe?

Andrew Harrison

Arne

[Dave Froble]

Post by Arne Vajhøj

Post by Dave Froble
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?

Andrew Harrison
Arne

You think maybe he changed his name?

[Dan Cross]

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?

Andrew Harrison

You think maybe he changed his name?

I doubt the current troll could have gotten a job at Sun.

- Dan C.

[John Dallman]

Post by Dan Cross

Post by Dave Froble
You think maybe he changed his name?

I doubt the current troll could have gotten a job at Sun.

I met some remarkably useless Sun marketing managers.

John

[Dan Cross]

Post by John Dallman

Post by Dan Cross

Post by Dave Froble
You think maybe he changed his name?

I doubt the current troll could have gotten a job at Sun.

I met some remarkably useless Sun marketing managers.

Yeah well.... It's tell that the current troll couldn't have
even gotten a job where it was possible to trip over the hiring
bar.

- Dan C.

[bill]

Post by John Dallman

Post by Dan Cross

Post by Dave Froble
You think maybe he changed his name?

I doubt the current troll could have gotten a job at Sun.

I met some remarkably useless Sun marketing managers.

Back around 1990 HP's had them beat when it came to useless.

bill

[Dave Froble]

Post by Dan Cross

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?

Andrew Harrison

You think maybe he changed his name?

I doubt the current troll could have gotten a job at Sun.
- Dan C.

Well, if the job was to be a troll .....

[k***@panix.com]

Post by Dan Cross

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?

Andrew Harrison

You think maybe he changed his name?

I doubt the current troll could have gotten a job at Sun.

Also I would expect anyone from Sun to be strongly anti-Linux. Here's
a nickel, kid. Get yourself a real computer.
--scott

[Lawrence D'Oliveiro]

Also I would expect anyone from Sun to be strongly anti-Linux. Here's a
nickel, kid. Get yourself a real computer.

The irony is that Sun is gone, and the company that now owns Solaris has
no clue what to do with it.

And all the “real” computers are now running Linux.

[Simon Clubley]

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?

Andrew Harrison
Arne

You think maybe he changed his name?

I'm not sure enough to post a link (and I am not joining LinkedIn to read
the full details), but it looks like he _may_ be working for Oracle in
their cloud division.

Do a search for "andrew harrison sun microsystems" (without quotes) and
see what you think...

Simon.

[Chris Townley]

Post by Simon Clubley

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?

Andrew Harrison
Arne

You think maybe he changed his name?

I'm not sure enough to post a link (and I am not joining LinkedIn to read
the full details), but it looks like he _may_ be working for Oracle in
their cloud division.
Do a search for "andrew harrison sun microsystems" (without quotes) and
see what you think...
Simon.

Does that mean he passed away, and is advising from 'upstairs' ?

[Simon Clubley]

Post by Chris Townley

Post by Simon Clubley

Post by Dave Froble

Post by Arne Vajhøj

Post by Dave Froble
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?

Andrew Harrison

You think maybe he changed his name?

I'm not sure enough to post a link (and I am not joining LinkedIn to read
the full details), but it looks like he _may_ be working for Oracle in
their cloud division.
Do a search for "andrew harrison sun microsystems" (without quotes) and
see what you think...

Does that mean he passed away, and is advising from 'upstairs' ?

No. :-) Oracle really do have a cloud division and it looks like
Andrew might be working for them (if it is the same Andrew).

Simon.

[John Dallman]

Post by Simon Clubley
No. :-) Oracle really do have a cloud division and it looks like
Andrew might be working for them (if it is the same Andrew).

There's certainly an "Andy Harrison" working for Oracle as a "Cloud
Services Solution Architect" which may well be "Technical backup for
Sales, plus a fancy title". He is based in Reading, UK, and was acquired
by Oracle along with Sun. He's had a wide variety of experience in UNIX
sysadmin and development; this is from his LinkedIn page.

John

[Arne Vajhøj]

Post by John Dallman

Post by Simon Clubley
No. :-) Oracle really do have a cloud division and it looks like
Andrew might be working for them (if it is the same Andrew).

There's certainly an "Andy Harrison" working for Oracle as a "Cloud
Services Solution Architect" which may well be "Technical backup for
Sales, plus a fancy title". He is based in Reading, UK, and was acquired
by Oracle along with Sun. He's had a wide variety of experience in UNIX
sysadmin and development; this is from his LinkedIn page.

I doubt it is the same.

Using Andrew on usenet and using Andy on LinkedIn seems
opposite of what one would expect.

When Andrew was active here he used the title Senior
Consultant, which seems a little more senior than
what titles Andy had at the time.

Andrew posted here with signature saying SunUK
in periods when Andy was not at Sun.

Not hard evidence, but when combined I doubt this
is "our" Andrew.

Arne

[Lawrence D'Oliveiro]

Post by Simon Clubley
Lawrence, you manage to make the current bunch of extreme zealots on
both sides of the political landscape in the US seem reasonable.

*Yawn* Your repeated attempts at personal attacks on me are just getting
tiresome.