Robert Finch <robfi680@gmail.com> writes:

On 2025-03-30 11:33 p.m., Dan Cross wrote:

I think this stems from this idea you seem have that threads
somehow turn into "processors/cores", whatever that means, as
these are obviously not the hardware devices, when interrupts
are disabled on the CPUs they are running on. Near as I can
tell this is your own unique invention, and nothing else uses
that terminology; use by the systems you cited is not supported
by evidence.

Consequently, I find your repeated assertions about these terms
rather strange.

- Dan C.

Having some trouble following the discussion as I do not have a lot of >experience working with software threads. I know they need
synchronization means.

Are you talking about two different kinds of “threads”? RISCV at least >refers to ‘harts’ which I think stands for hardware threads. A CPU core >may support multiple harts, which implies multiple copies of the
processor state. In a multi-core system there could be multiple harts
even though each core is only supporting a single one. I am under the >impression hardware and software threads are not the same thing.
I hope I got the lingo correct.

In the abstract, a thread can be considered a sequence of instructions
executed with a consistent processor state (registers, flags, MMU).

Threads, using that definition, can be implemented fully in software
(using OS facilities for coordination between entities). User-mode
threads are an example of this, and were implemented in systems that
did not have Operating system support for threads as a schedulable
entity.

Operating systems later added explicit support for multiple threads
of execution to share a single address space by defining a thread
schedulable entity encapsulating the thread context (general register
state, et alia). POSIX Pthreads was the standard on the Unix side.

Subsequently, the hardware vendors realized that they could better
utilize the hardware by creating the concept of a 'hardware thread'
where the processor resources for a core could be divvied up and
shared by multiple hardware contexts (Intel called it hyperthreading).

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

Scott Lurndal wrote:

Robert Finch <robfi680@gmail.com> writes:

On 2025-03-30 11:33 p.m., Dan Cross wrote:

I think this stems from this idea you seem have that threads
somehow turn into "processors/cores", whatever that means, as
these are obviously not the hardware devices, when interrupts
are disabled on the CPUs they are running on. Near as I can
tell this is your own unique invention, and nothing else uses
that terminology; use by the systems you cited is not supported
by evidence.

Consequently, I find your repeated assertions about these terms
rather strange.

- Dan C.

Having some trouble following the discussion as I do not have a lot of
experience working with software threads. I know they need
synchronization means.

Are you talking about two different kinds of “threads”? RISCV at least
refers to ‘harts’ which I think stands for hardware threads. A CPU core
may support multiple harts, which implies multiple copies of the
processor state. In a multi-core system there could be multiple harts
even though each core is only supporting a single one. I am under the
impression hardware and software threads are not the same thing.
I hope I got the lingo correct.

In the abstract, a thread can be considered a sequence of instructions executed with a consistent processor state (registers, flags, MMU).

Threads, using that definition, can be implemented fully in software
(using OS facilities for coordination between entities). User-mode
threads are an example of this, and were implemented in systems that
did not have Operating system support for threads as a schedulable
entity.

Operating systems later added explicit support for multiple threads
of execution to share a single address space by defining a thread
schedulable entity encapsulating the thread context (general register
state, et alia). POSIX Pthreads was the standard on the Unix side.

Subsequently, the hardware vendors realized that they could better
utilize the hardware by creating the concept of a 'hardware thread'
where the processor resources for a core could be divvied up and
shared by multiple hardware contexts (Intel called it hyperthreading).

In my programmer world view, a pure user software thread isn't that interesting, it typically allows the programmer to control (more or
less) when it can be interrupted.

A harware thread is anything which could, at any time (even in the
middle of a long-running instruction like a block move), interrupt the currently executing thread and potentially modify anything in the local context which isn't currently locked down.

I.e. just like a separate processes running on another core, except that (nearly) nothing is really private. This makes for a much more
"interesting" programing environment.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

Terje Mathisen <terje.mathisen@tmsw.no> writes:

Scott Lurndal wrote:

In the abstract, a thread can be considered a sequence of instructions
executed with a consistent processor state (registers, flags, MMU).
=20
Threads, using that definition, can be implemented fully in software
(using OS facilities for coordination between entities). User-mode
threads are an example of this, and were implemented in systems that
did not have Operating system support for threads as a schedulable
entity.
=20
Operating systems later added explicit support for multiple threads
of execution to share a single address space by defining a thread
schedulable entity encapsulating the thread context (general register
state, et alia). POSIX Pthreads was the standard on the Unix side.
=20
Subsequently, the hardware vendors realized that they could better
utilize the hardware by creating the concept of a 'hardware thread'
where the processor resources for a core could be divvied up and
shared by multiple hardware contexts (Intel called it hyperthreading).
=20

In my programmer world view, a pure user software thread isn't that=20 >interesting, it typically allows the programmer to control (more or=20
less) when it can be interrupted.

Using the pre-pthreads posix facilities (signals and getcontext/setcontext)
to support user-level threads wasn't uncommon. Unix SVR4ES/MP actually had both kernel threads (called lightweight processes (LWP)) and user-level
threads in an M-N setup (M user threads multiplexed on N kernel threads).

Didn't turn out to be particularly useful.

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 4/1/2025 8:31 AM, Scott Lurndal wrote:

Terje Mathisen <terje.mathisen@tmsw.no> writes:

Scott Lurndal wrote:

In the abstract, a thread can be considered a sequence of instructions >>>> executed with a consistent processor state (registers, flags, MMU).
=20
Threads, using that definition, can be implemented fully in software
(using OS facilities for coordination between entities). User-mode
threads are an example of this, and were implemented in systems that
did not have Operating system support for threads as a schedulable
entity.
=20
Operating systems later added explicit support for multiple threads
of execution to share a single address space by defining a thread
schedulable entity encapsulating the thread context (general register
state, et alia). POSIX Pthreads was the standard on the Unix side.
=20
Subsequently, the hardware vendors realized that they could better
utilize the hardware by creating the concept of a 'hardware thread'
where the processor resources for a core could be divvied up and
shared by multiple hardware contexts (Intel called it hyperthreading). >>>> =20

In my programmer world view, a pure user software thread isn't that=20
interesting, it typically allows the programmer to control (more or=20
less) when it can be interrupted.

Using the pre-pthreads posix facilities (signals and getcontext/setcontext) >> to support user-level threads wasn't uncommon. Unix SVR4ES/MP actually had >> both kernel threads (called lightweight processes (LWP)) and user-level
threads in an M-N setup (M user threads multiplexed on N kernel threads).

Didn't turn out to be particularly useful.

Are you referring to green threads? Or Fibers?

Neither.

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 4/1/2025 1:01 PM, Scott Lurndal wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

On 4/1/2025 8:31 AM, Scott Lurndal wrote:

Terje Mathisen <terje.mathisen@tmsw.no> writes:

Scott Lurndal wrote:

In the abstract, a thread can be considered a sequence of instructions >>>>>> executed with a consistent processor state (registers, flags, MMU). >>>>>> =20
Threads, using that definition, can be implemented fully in software >>>>>> (using OS facilities for coordination between entities). User-mode >>>>>> threads are an example of this, and were implemented in systems that >>>>>> did not have Operating system support for threads as a schedulable >>>>>> entity.
=20
Operating systems later added explicit support for multiple threads >>>>>> of execution to share a single address space by defining a thread
schedulable entity encapsulating the thread context (general register >>>>>> state, et alia). POSIX Pthreads was the standard on the Unix side. >>>>>> =20
Subsequently, the hardware vendors realized that they could better >>>>>> utilize the hardware by creating the concept of a 'hardware thread' >>>>>> where the processor resources for a core could be divvied up and
shared by multiple hardware contexts (Intel called it hyperthreading). >>>>>> =20

In my programmer world view, a pure user software thread isn't that=20 >>>>> interesting, it typically allows the programmer to control (more or=20 >>>>> less) when it can be interrupted.

Using the pre-pthreads posix facilities (signals and getcontext/setcontext)
to support user-level threads wasn't uncommon. Unix SVR4ES/MP actually had
both kernel threads (called lightweight processes (LWP)) and user-level >>>> threads in an M-N setup (M user threads multiplexed on N kernel threads). >>>>
Didn't turn out to be particularly useful.

Are you referring to green threads? Or Fibers?

Neither.

I think we are talking about user threads, ala PThreads, vs kernel
"realm" threads... Is that right?

https://www.tech-insider.org/unix/research/1992/0720.html https://ieeexplore.ieee.org/document/528923

Here, it's called the many-to-many model.

https://docs.oracle.com/cd/E19620-01/805-4031/6j3qv1oej/index.html

https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos

The NT4 source code was licensed by Microsoft to other
companies.

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

scott@slp53.sl.home (Scott Lurndal) writes:

Unix SVR4ES/MP actually had
both kernel threads (called lightweight processes (LWP)) and user-level >threads in an M-N setup (M user threads multiplexed on N kernel threads).

Didn't turn out to be particularly useful.

Maybe the SVR4ES/MP stuff was not particularly useful. Combining
user-level threads and kernel threads in an M-N setup has turned out
to be very useful in, e.g., Erlang applications.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

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

In article <2025Apr2.082556@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

Unix SVR4ES/MP actually had
both kernel threads (called lightweight processes (LWP)) and user-level >>threads in an M-N setup (M user threads multiplexed on N kernel threads).

Didn't turn out to be particularly useful.

Maybe the SVR4ES/MP stuff was not particularly useful. Combining
user-level threads and kernel threads in an M-N setup has turned out
to be very useful in, e.g., Erlang applications.

It's useful when threads are carefully managed, so that programs
can ensure that the set of OS threads is always available so that
runnable LWPs can be scheduled onto them. This implies that the
OS-managed threads should not block, as if they do, you lose
1/M'th of your parallelism. But the N:M model really breaks
down when LWPs become unrunnable in a way that does not involve
the user-level thread scheduler, something that can happen in
surprising places.

For instance, consider Unix/POSIX `open`: from an API
perspective this simply maps a symbolic file path name to a file
descriptor that can subsequently be used to perform IO on the
named file. While it is well-known that the interface is
defined so that it can block opening some kinds of devices, for
example, some terminal devices until the line is asserted, that
is not the usual case, and noteably `open` does no IO on the
file itself. So generally, most programs would expect that it
has no reason to block.

But that's just the interface, the implementation is different.
When we observe that the resolution of a name to an FD is always
synchronous with respect to the calling program, we can see that
there are a number of places where `open` can block in the
kernel because it may actually require IO: the path name
argument may point into a non-resident part of the address space
that needs to be paged into memory. Or the per-component
lookups while walking the path may require IO to find the
corresponding directory entries in directory files, and so on.
POSIX does not provide us an alternative asynchronous `open`
call, so if an LWP opens a file, we might lose the OS-managed
thread it was running on for a while, if it becomes blocked in
the kernel waiting on IO. About the best you can do to detect
this kind of blocking is schedule an event to send yourself a
signal after some reasonable timeout, and cancel that event if
`open` completes before the timeout expires.

Furthermore, because LWPs and OS-managed threads are usually
independent, their respective schedulers might make pathological
decisions with respect to one another. Consider two LWPs that
are passing a token back and forth between themselves for some
reason; for good throughput, we'd want these gang-scheduled onto
OS threads, but they might bounce around running on the
available set of OS threads, and if the OS snatched the thread
that one was scheduled to while the other was running,
throughput would suffer. The problem here is that generally,
scheduling decisions made by the LWP scheduler are not knowable
to the OS and vice-versa, even though you really want both to
cooperate in this case.

1:1 threading models solve all of these problems, at the expense
of being heavier-weight. Languages like Erlang and Go do a
decent job in an M:N context by enforcing tight control of the
language runtime, which handles all of the squirrely details on
the program's behalf.

A lot of work has been done on M:N: Pysche, Scheduler
Activations, `rfork`, upcalls to DECthreads in VMS, etc. More
recently, systems like Akaros proposed a different model that
punted nearly all scheduling to userspace and adopts something
that's more like M:C, where "C" is "cores", by building a virtual-multiprocessor abstraction for many-core processes. http://akaros.org/news.html

- Dan C.

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

On Tue, 1 Apr 2025 16:44:11 +0200, Terje Mathisen
<terje.mathisen@tmsw.no> wrote:

In my programmer world view, a pure user software thread isn't that >interesting, it typically allows the programmer to control (more or
less) when it can be interrupted.

Done properly, user space threads can be pre-emptively scheduled and
otherwise interrupted.


Also, consider "scheduler activations", wherein the kernel provides
only virtual cores, and all threading is done in user space.

https://homes.cs.washington.edu/~tom/pubs/sched_act.pdf https://www.cs.ucr.edu/~heng/teaching/cs202-sp18/lec7.pdf

There is an implementation of this idea on NetBSD http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html


It's not a terribly popular idea, but IMO it is an interesting one.
YMMV.

Terje

George

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

In article <fm6sujprvvtaq33pnliab0jl6bofbjvhm9@4ax.com>,
George Neuner <gneuner2@comcast.net> wrote:

On Tue, 1 Apr 2025 16:44:11 +0200, Terje Mathisen
<terje.mathisen@tmsw.no> wrote:

In my programmer world view, a pure user software thread isn't that >>interesting, it typically allows the programmer to control (more or
less) when it can be interrupted.

Done properly, user space threads can be pre-emptively scheduled and >otherwise interrupted.

This is true, but the details on contemporary machines and
operating systems are super intricate. Goroutines can be
preemptively scheduled, though, as an example.

Also, consider "scheduler activations", wherein the kernel provides
only virtual cores, and all threading is done in user space.

https://homes.cs.washington.edu/~tom/pubs/sched_act.pdf >https://www.cs.ucr.edu/~heng/teaching/cs202-sp18/lec7.pdf

There is an implementation of this idea on NetBSD >http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html

It's not a terribly popular idea, but IMO it is an interesting one.
YMMV.

Scheduler activations was an interesting idea, but came with
significant drawbacks. Lack of support for deferring activation
events during (user) critical sections and lack of a virtual
core abstraction to complement its virtual multiprocessor were
probably the biggest.

Psyche provided a virtual core abstraction, but not a VMP.

Akaros combined the two in a novel way that gave an M:C model,
but never got past the research stage.

- Dan C.

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

Terje Mathisen <terje.mathisen@tmsw.no> writes:

Dan Cross wrote:

In article <2025Apr2.082556@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

Unix SVR4ES/MP actually had
both kernel threads (called lightweight processes (LWP)) and user-level >>>> threads in an M-N setup (M user threads multiplexed on N kernel threads). >>>>
Didn't turn out to be particularly useful.

Maybe the SVR4ES/MP stuff was not particularly useful. Combining
user-level threads and kernel threads in an M-N setup has turned out
to be very useful in, e.g., Erlang applications.

It's useful when threads are carefully managed, so that programs
can ensure that the set of OS threads is always available so that
runnable LWPs can be scheduled onto them. This implies that the
OS-managed threads should not block, as if they do, you lose
1/M'th of your parallelism. But the N:M model really breaks
down when LWPs become unrunnable in a way that does not involve
the user-level thread scheduler, something that can happen in
surprising places.

For instance, consider Unix/POSIX `open`: from an API
perspective this simply maps a symbolic file path name to a file
descriptor that can subsequently be used to perform IO on the
named file. While it is well-known that the interface is
defined so that it can block opening some kinds of devices, for
example, some terminal devices until the line is asserted, that
is not the usual case, and noteably `open` does no IO on the
file itself. So generally, most programs would expect that it
has no reason to block.

The one case where open was a problem on traditional unix was
for line printers. The open of /dev/lp could block if the
printer (on a centronics port) was not-ready. And it was
an uninterruptable block, even SIGKILL was blocked.

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

Dan Cross wrote:

In article <2025Apr2.082556@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

Unix SVR4ES/MP actually had
both kernel threads (called lightweight processes (LWP)) and user-level
threads in an M-N setup (M user threads multiplexed on N kernel threads). >>>
Didn't turn out to be particularly useful.

Maybe the SVR4ES/MP stuff was not particularly useful. Combining
user-level threads and kernel threads in an M-N setup has turned out
to be very useful in, e.g., Erlang applications.

It's useful when threads are carefully managed, so that programs
can ensure that the set of OS threads is always available so that
runnable LWPs can be scheduled onto them. This implies that the
OS-managed threads should not block, as if they do, you lose
1/M'th of your parallelism. But the N:M model really breaks
down when LWPs become unrunnable in a way that does not involve
the user-level thread scheduler, something that can happen in
surprising places.

For instance, consider Unix/POSIX `open`: from an API
perspective this simply maps a symbolic file path name to a file
descriptor that can subsequently be used to perform IO on the
named file. While it is well-known that the interface is
defined so that it can block opening some kinds of devices, for
example, some terminal devices until the line is asserted, that
is not the usual case, and noteably `open` does no IO on the
file itself. So generally, most programs would expect that it
has no reason to block.

Pretty much all WIidows machines suffer badly from this, due to the
inclusion of realtime/inline virus/malware scanning.

A friend of mine/former coworker was part of the team which fixed rustup
on windows, basically by treating every single file IO operation as
async: It turns out that Windows can indeed maintain more or less the
same throughput as Linux on a workload which is heavy on file
creation/file write, but each individual operation will suffer from a
lot of latency, so it is only by allowing more or less all of them to
overlap that the latency cost can be mostly hidden.

This was of course not a problem back on MSDOS around 1986, before the
first anti-virus software came along. We had zero multi-threading and
mostly had to care about making file read/write buffers large enough to
sature the disk interface.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

In article <FoxHP.1477197$eNx6.766449@fx14.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:

Dan Cross wrote:

[snip]
For instance, consider Unix/POSIX `open`: from an API
perspective this simply maps a symbolic file path name to a file
descriptor that can subsequently be used to perform IO on the
named file. While it is well-known that the interface is
defined so that it can block opening some kinds of devices, for
example, some terminal devices until the line is asserted, that
is not the usual case, and noteably `open` does no IO on the
file itself. So generally, most programs would expect that it
has no reason to block.

The one case where open was a problem on traditional unix was
for line printers. The open of /dev/lp could block if the
printer (on a centronics port) was not-ready. And it was
an uninterruptable block, even SIGKILL was blocked.

I'd worry more about, say a pathname that requires traversing
NFS for one reason or another (symlinks, or just on a mounted
filesystem). Nothing prevents an NFS server from becoming
inaccessible during a lookup.

- Dan C.

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

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <FoxHP.1477197$eNx6.766449@fx14.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:

Dan Cross wrote:

[snip]
For instance, consider Unix/POSIX `open`: from an API
perspective this simply maps a symbolic file path name to a file
descriptor that can subsequently be used to perform IO on the
named file. While it is well-known that the interface is
defined so that it can block opening some kinds of devices, for
example, some terminal devices until the line is asserted, that
is not the usual case, and noteably `open` does no IO on the
file itself. So generally, most programs would expect that it
has no reason to block.

The one case where open was a problem on traditional unix was
for line printers. The open of /dev/lp could block if the
printer (on a centronics port) was not-ready. And it was
an uninterruptable block, even SIGKILL was blocked.

I'd worry more about, say a pathname that requires traversing
NFS for one reason or another (symlinks, or just on a mounted
filesystem). Nothing prevents an NFS server from becoming
inaccessible during a lookup.

However, you can specify a soft mount rather than a hard mount
to resolve that.

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

In article <AvzHP.350389$sbY2.343252@fx40.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <FoxHP.1477197$eNx6.766449@fx14.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:

Dan Cross wrote:

[snip]
For instance, consider Unix/POSIX `open`: from an API
perspective this simply maps a symbolic file path name to a file
descriptor that can subsequently be used to perform IO on the
named file. While it is well-known that the interface is
defined so that it can block opening some kinds of devices, for
example, some terminal devices until the line is asserted, that
is not the usual case, and noteably `open` does no IO on the
file itself. So generally, most programs would expect that it
has no reason to block.

The one case where open was a problem on traditional unix was
for line printers. The open of /dev/lp could block if the
printer (on a centronics port) was not-ready. And it was
an uninterruptable block, even SIGKILL was blocked.

I'd worry more about, say a pathname that requires traversing
NFS for one reason or another (symlinks, or just on a mounted
filesystem). Nothing prevents an NFS server from becoming
inaccessible during a lookup.

However, you can specify a soft mount rather than a hard mount
to resolve that.

To kill the process, sure. Still kinda sucks, though, from a
user experience point of view. :-)

- Dan C.

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

On Thu, 03 Apr 2025 01:38:53 -0400, George Neuner wrote:

Also, consider "scheduler activations", wherein the kernel provides only virtual cores, and all threading is done in user space.

https://homes.cs.washington.edu/~tom/pubs/sched_act.pdf https://www.cs.ucr.edu/~heng/teaching/cs202-sp18/lec7.pdf

There is an implementation of this idea on NetBSD http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html

The scheduler activations implementation of threads was removed from
NetBSD in 2012.

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

On Fri, 4 Apr 2025 10:41:44 -0000 (UTC), Robert Swindells
<rjs@fdy2.co.uk> wrote:

On Thu, 03 Apr 2025 01:38:53 -0400, George Neuner wrote:

Also, consider "scheduler activations", wherein the kernel provides only
virtual cores, and all threading is done in user space.

https://homes.cs.washington.edu/~tom/pubs/sched_act.pdf
https://www.cs.ucr.edu/~heng/teaching/cs202-sp18/lec7.pdf

There is an implementation of this idea on NetBSD
http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html

The scheduler activations implementation of threads was removed from
NetBSD in 2012.

Yes, but it is still available from the archives.

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