On 7/6/20 7:30 PM, Greg 'groggy' Lehey wrote:
> People (not just Clem), when you change the topic, can you please
> modify the Subject: to match? I'm not overly interested in uucp,
> but editors are a completely different matter. I'm sure I'm not the
> only one, so many interested parties will miss these replies.
I see this type of change happen — in my not so humble opinion — /way/
/too/ /often/.
So, I'm wondering if people are interested in configuring TUHS and / or
COFF mailing list (Mailman) with topics. That way people could
subscribe to the topics that they are interested in and not receive
copies of topics they aren't interested in.
I'm assuming that TUHS and COFF are still on Mailman mailing lists and
that Warren would be amicable to such.
To clarify, it would still be the same mailing list(s) as they exist
today. They would just have the to be utilized option of picking
interesting topics. Where topics would be based on keywords in the
message body.
I'm just trying to gauge people's interest in this idea.
--
Grant. . . .
unix || die
On Wed, 8 Jul 2020, Jacob Goense wrote:
> When I have tuned out of a long running thread and the topic drifts
> significantly I'm always grateful to the kind soul that tags..:
>
> Subject: Re: new [was: old]
Yeah, I try and remember to do that...
-- Dave
The Internet's original graphics trio of "*Booth, Beatty, and Barsky*" (who
had been affectionately dubbed the graphics industries' "*Killer Bs*") lost
one for their greats minds and personalities this last week. With great
sadden in my heart, I regret to inform you that John Beatty has passed
away. I was informed this AM by his partner is so many enterprises, Kelly
Booth, that John died peacefully in his sleep in the early morning on
Thursday, July 2, 2020.
When we look at the wonders of the Internet's growth in the use of computer
graphics, we view his legacy. But more than that, John was a good friend of
many of us and, of course, we all miss him.
Kelly tells me that the obituary with further information is being prepared
by John’s sister, Jean Beatty, and well as others. We'll be sure to try to pass
on a copy (or a link if it is on the web) when it has been released.
Clem
Does anyone have any experience with UUCP on macOS or *BSD systems that
would be willing to help me figure something out?
I'm working on adding a macOS X system to my micro UUCP network and
running into some problems.
- uuto / uucp copy files from my non-root / non-(_)uucp user to the
UUCP spool. But the (demand based) ""call (pipe over SSH) is failing.
- running "uucico -r1 -s <remote system name> -f" as the (_)uucp user
(via sudo) works.
- I'm using the pipe port type and running things over an SSH connection.
- The (_)uucp user can ssh to the remote system as expected
without any problems or being prompted for a password. (Service
specific keys w/ forced command.)
I noticed that the following files weren't set UID or GID like they are
on Linux. But I don't know if that's a macOS and / or *BSD difference
when compared to Linux.
/usr/bin/uucp
/usr/bin/uuname
/usr/bin/uustat
/usr/bin/uux
/usr/sbin/uucico
/usr/sbin/uuxqt
Adding the set UID & GID bits allowed things to mostly work.
Aside: Getting the contemporary macOS so that I could edit the
(/usr/share/uucp/) sys & port files was a treat.
I figured that it was worth inquiring if anyone had any more experience
/ tips / gotchas before I go bending ~> breaking things even more.
Thank you.
--
Grant. . . .
unix || die
In 1966, Engineers at IBM invented a method of speeding up execution
without adding a lot of very expensive memory. They called their
invention the muffer. The name did not catch on so they picked another
name and submitted an article to the IBM System J. The editor noted
that their second name was heavily overused and suggested a third name,
which the engineers accepted. The third name was cache.
(Muffer was short for memory buffer.)
This from "IBM's 360 and Early 370 Systems", MIT Press. I found this
an amusing tidbit of history -- hopefully so may others.
N.
Redirected to COFF, since this isn't very TUHS related.
Richard Salz wrote:
> Noel Chiappa wote:
>> MLDEV on ITS would, I think, fit under that description.
>> I don't know if there's a paper on it; it's mid-70's.
I don't think there's anything like an academic paper.
The earliest evidence I found for the MLDEV facility, or a predecessor,
is from 1972:
https://retrocomputing.stackexchange.com/questions/13709/what-are-some-earl…
> A web search for "its mldev" finds several things (mostly by Lars Brinkhoff
> it seems) , including
> https://github.com/larsbrinkhoff/mldev/blob/master/doc/mldev.protoc
That's just a copy I made.
ABC-TV "Grantchester" (a detective-priest series[*]) featured someone who
died from mercury poisoning, when someone opened the tanks. Apart from
the beautiful Teletype in the foreground, there was a machine with lots of
dials in the background; obviously some early computer, but not enough
footage for me to tell which one, but is a British show if that helps.
[*]
I suppose that I need not remind any Monty Python freaks of these lines:
"There's another dead bishop on the landing, Vicar-Sergeant!"
"Err, Detective-Parsons, Madam."
Etc... Otherwise I'd go on all day :-)
-- Dave
[ -TUHS and +COFF ]
On Mon, Jun 8, 2020 at 1:49 AM Lars Brinkhoff <lars(a)nocrew.org> wrote:
> Chris Torek wrote:
> > You pay (sometimes noticeably) for the GC, but the price is not
> > too bad in less time-critical situations. The GC has a few short
> > stop-the-world points but since Go 1.6 or so, it's pretty smooth,
> > unlike what I remember from 1980s Lisp systems. :-)
>
> I'm guessing those 1980s Lisp systems would also be pretty smooth on
> 2020s hardware.
>
I worked on a big system written in Common Lisp at one point, and it used a
pretty standard Lispy garbage collector. It spent something like 15% of its
time in GC. It was sufficiently bad that we forced a full GC between every
query.
The Go garbage collector, on the other hand, is really neat. I believe it
reserves something like 25% of available CPU time for itself, but it runs
concurrently with your program: having to stop the world for GC is very,
very rare in Go programs and even when you have to do it, the concurrent
code (which, by the way, can make use of full physical parallelism on
multicore systems) has already done much of the heavy lifting, meaning you
spend less time in a GC pause. It's a very impressive piece of engineering.
- Dan C.
> I've never heard of the dimensionality of an array in such a context
> described in terms of a sum type,[...]
I was also puzzled by this remark. Perhaps Bram was thinking of an
infinite sum type such as
Arrays_0 + Arrays_1 + Arrays_2 + ...
where "Arrays_n" is the type of arrays of size n. However, I don't see
a way of defining this without dependent (or at least indexed) types.
> [...] but have often heard of it described in terms of a dependent
> type.
I think that's right, yes. We want the type checker to decide, at
compile time, whether a certain operation on arrays, such as scalar
product, or multiplication with a matrix, will respect the types. That
means providing the information about the size to the type checker:
types need to know about values, hence the need for dependent types.
Ideally, a lot of the type information can then be erased at run time,
so that we don't need the arrays to carry their sizes around. But the
distinction between what can and what cannot be erased at run time is
muddled in a dependently-typed programming language.
Best wishes,
Cezar
Dan Cross <crossd(a)gmail.com> writes:
> [-TUHS, +COFF as per wkt's request]
>
> On Sun, Jun 7, 2020 at 8:26 PM Bram Wyllie <bramwyllie(a)gmail.com> wrote:
>
>> Dependent types aren't needed for sum types though, which is what you'd
>> normally use for an array that carries its size, correct?
>>
>
> No, I don't think so. I've never heard of the dimensionality of an array in
> such a context described in terms of a sum type, but have often heard of it
> described in terms of a dependent type. However, I'm no type theorist.
>
> - Dan C.
> _______________________________________________
> COFF mailing list
> COFF(a)minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
[-TUHS, +COFF as per wkt's request]
On Sun, Jun 7, 2020 at 8:26 PM Bram Wyllie <bramwyllie(a)gmail.com> wrote:
> Dependent types aren't needed for sum types though, which is what you'd
> normally use for an array that carries its size, correct?
>
No, I don't think so. I've never heard of the dimensionality of an array in
such a context described in terms of a sum type, but have often heard of it
described in terms of a dependent type. However, I'm no type theorist.
- Dan C.
