On 1/19/2024 4:46 PM, John Dallman wrote:
> 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.

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.

> 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.

> 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.

Arne

On 1/20/2024 3:10 AM, John Dallman wrote:
> In article <uof4t2$3c1i2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>> On 1/19/2024 4:46 PM, John Dallman wrote:
>>> 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

On 1/20/24 10:56 AM, John Dallman wrote:
> In article <uogs7c$3o3e0$2@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>
>> 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.

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.

On Sat, 20 Jan 2024 16:56 +0000 (GMT Standard Time), John Dallman wrote:

> 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.

On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:

> 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”.

On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:
>
>> 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...

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <uolqc2$o1rq$4@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:
>>
>>> 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.

On Mon, 2024-01-22 at 13:25 +0000, Simon Clubley wrote:
> 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>
--
Tactical Nuclear Kittens

On 2024-01-22 13:25:22 +0000, Simon Clubley said:

> On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:
>>
>>> 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.

> 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.

--
Pure Personal Opinion | HoffmanLabs LLC

On Mon, 22 Jan 2024 13:25:22 -0000 (UTC), Simon Clubley wrote:

> 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.

On 2024-01-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <uolqc2$o1rq$4@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:
>>>
>>>> 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.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/23/2024 8:13 AM, Simon Clubley wrote:
> On 2024-01-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <uolqc2$o1rq$4@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:
>>>>
>>>>> 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 ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/23/2024 5:36 PM, Dave Froble wrote:
> On 1/23/2024 8:13 AM, Simon Clubley wrote:
>> On 2024-01-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> In article <uolqc2$o1rq$4@dont-email.me>,
>>> Simon Clubley  <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>> On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>> On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman
>>>>> wrote:
>>>>>
>>>>>> 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

On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:
>
> 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.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/24/2024 8:13 AM, Simon Clubley wrote:
> On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> 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 ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/23/2024 8:16 PM, bill wrote:
> On 1/23/2024 5:36 PM, Dave Froble wrote:
>> On 1/23/2024 8:13 AM, Simon Clubley wrote:
>>> On 2024-01-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>> In article <uolqc2$o1rq$4@dont-email.me>,
>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>>> On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>>> On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:
>>>>>>
>>>>>>> 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.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Mon, 22 Jan 2024 14:04:13 -0500, Stephen Hoffman wrote:

> 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.

> 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.

On Tue, 23 Jan 2024 20:16:13 -0500, bill wrote:

> 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 ...

On 1/26/2024 4:31 PM, Lawrence D'Oliveiro wrote:
> On Mon, 22 Jan 2024 14:04:13 -0500, Stephen Hoffman wrote:
>
>> 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.
>
>> 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?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/27/2024 12:36 AM, Dave Froble wrote:
> This reminds me of something.  Anybody remember the Sun employee that
> used to come here and harass us?  Andrew something maybe?

Andrew Harrison

Arne

On 1/27/2024 8:44 AM, Arne Vajhøj wrote:
> On 1/27/2024 12:36 AM, Dave Froble wrote:
>> 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?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <up3dc9$3f7b4$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 1/27/2024 8:44 AM, Arne Vajhøj wrote:
>> On 1/27/2024 12:36 AM, Dave Froble wrote:
>>> 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.

In article <memo.20240127202907.3116s@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <up3ltv$c4l$1@reader1.panix.com>,
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>> In article <up3dc9$3f7b4$1@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>> >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.

On 1/27/2024 2:35 PM, Dan Cross wrote:
> In article <up3dc9$3f7b4$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/27/2024 8:44 AM, Arne Vajhøj wrote:
>>> On 1/27/2024 12:36 AM, Dave Froble wrote:
>>>> 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 .....

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/27/2024 3:29 PM, John Dallman wrote:
> In article <up3ltv$c4l$1@reader1.panix.com>,
> cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>> In article <up3dc9$3f7b4$1@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>> 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