• A few tools for improving software security

    From John Dallman@21:1/5 to Berryman on Fri Jan 19 21:46:00 2024
    In article <uobmub$2m944$1@dont-email.me>, mark@theberrymans.com (Mark Berryman) wrote:

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John Dallman on Fri Jan 19 19:42:09 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to All on Sat Jan 20 08:10:00 2024
    In article <uof4t2$3c1i2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhj)
    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.

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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John Dallman on Sat Jan 20 11:26:20 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to All on Sat Jan 20 16:56:00 2024
    In article <uogs7c$3o3e0$2@dont-email.me>, arne@vajhoej.dk (Arne Vajhj)
    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.

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Craig A. Berry@21:1/5 to John Dallman on Sat Jan 20 13:46:40 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Dallman on Sun Jan 21 01:55:06 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to D'Oliveiro on Sun Jan 21 10:10:00 2024
    In article <uohthp$3t9gu$1@dont-email.me>, ldo@nz.invalid (Lawrence
    D'Oliveiro) 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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Dallman on Sun Jan 21 21:36:08 2024
    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”.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Lawrence D'Oliveiro on Mon Jan 22 13:25:22 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to clubley@remove_me.eisner.decus.org- on Mon Jan 22 13:36:03 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Simon Clubley on Mon Jan 22 14:30:24 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Hoffman@21:1/5 to Simon Clubley on Mon Jan 22 14:04:13 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Simon Clubley on Mon Jan 22 23:34:41 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Dan Cross on Tue Jan 23 13:13:33 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to Simon Clubley on Tue Jan 23 17:36:35 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Dave Froble on Wed Jan 24 13:13:12 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to Simon Clubley on Wed Jan 24 19:24:28 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to bill on Wed Jan 24 19:23:43 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Stephen Hoffman on Fri Jan 26 21:31:35 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to bill on Fri Jan 26 21:32:16 2024
    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 ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to Lawrence D'Oliveiro on Sat Jan 27 00:36:11 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Dave Froble on Sat Jan 27 08:44:26 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to All on Sat Jan 27 12:09:46 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to davef@tsoft-inc.com on Sat Jan 27 19:35:27 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to John Dallman on Sat Jan 27 20:46:19 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to Dan Cross on Sat Jan 27 20:29:00 2024
    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.

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to Dan Cross on Sat Jan 27 18:33:59 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From kludge@panix.com@21:1/5 to Dan Cross on Sun Jan 28 02:11:12 2024
    Dan Cross <cross@spitfire.i.gajendra.net> wrote:
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to kludge on Sun Jan 28 08:20:22 2024
    On 28 Jan 2024 02:11:12 -0000, kludge wrote:

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Dave Froble on Mon Jan 29 13:20:13 2024
    On 2024-01-27, Dave Froble <davef@tsoft-inc.com> wrote:
    On 1/27/2024 8:44 AM, Arne Vajhj 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?


    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to Simon Clubley on Mon Jan 29 17:44:17 2024
    On 29/01/2024 13:20, Simon Clubley wrote:
    On 2024-01-27, 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

    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' ?

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Chris Townley on Mon Jan 29 18:04:51 2024
    On 2024-01-29, Chris Townley <news@cct-net.co.uk> wrote:
    On 29/01/2024 13:20, Simon Clubley wrote:
    On 2024-01-27, Dave Froble <davef@tsoft-inc.com> wrote:
    On 1/27/2024 8:44 AM, Arne Vajhj 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'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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to Simon Clubley on Mon Jan 29 19:23:00 2024
    In article <up8pc2$id8p$1@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John Dallman on Mon Jan 29 15:45:27 2024
    On 1/29/2024 2:23 PM, John Dallman wrote:
    In article <up8pc2$id8p$1@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)