>>I take credit as a go-between, not as an inventor. Ken Knowlton
>>introduced the notation ABC in BEFLIX, a pixel-based animation
>>language.
> In BEFLIX, 'ABC' meant what, exactly? Offsets from pixel locations?
It meant exactly what A->B->C means in C. Pixels had properties,
represented in data structures. One valid data type was pointer.
Incidentally, another BEFLIX innovation was the buddy system for
dynamic storage allocation.
Doug
While waiting to see the full text, I've poked around the index for
subjects of interest. It certainly is copious, and knows about a lot
of things that I don't.
The authors make a reasonable choice in identifying the dawn of
"modern computing" with Eniac and relegating non-electronic machines
to prehistory. Still, I was glad to find the prophetic Konrad Zuse
mentioned, but disappointed not to find the Bell Labs pioneer, George
Stibitz.
Among programming languages, Fortran, which changed the nature of
programming, is merely hinted at (buried in the forgettable Fortran
Monitoring System), while its insignificant offspring PL/I is present.
(Possibly this is an indexing oversight. John Backus, who led the
Fortran project, is mentioned quite early in the book.) Algol, Lisp,
Simula and Smalltalk quite properly make the list, but Basic rates
more coverage than any of them. C, obscurely alphabetized as "C
language", is treated generously, as is Unix in general.
Surprisingly there's almost nothing in the index about security or
privacy. The litany of whiggish chapters about various uses of
computers needs a cautionary complement. "The computer attracts crooks
and spies" would be a stylistically consistent title.
Doug
> My belief is that perl was written to replace a lot of Unix pipelines,
I understand Perl's motive to have been a lot like PL/I's: subsume
several popular styles of programming in one language. PL/I's ensemble
wasn't always harmonious. Perl's was cacophony.
Doug
At 11:00 AM 11/16/2021, Douglas McIlroy wrote:
>>> The former notation C(B(A)) became A->B->C. This was PL/I's gift to C.
>
>> You seem to have a gift for notation. That's rare. Curious what you think of APL?
>
>I take credit as a go-between, not as an inventor. Ken Knowlton
>introduced the notation ABC in BEFLIX, a pixel-based animation
>language.
In BEFLIX, 'ABC' meant what, exactly? Offsets from pixel locations?
- John
A private message with Uh, Clem reminds me of another quaint piece of
UNIX group history: JHU Ownership.
The original V6 kernel and file systems used a char for UID and GID.
This meant that you could only have 255 (plus the root user) distinct
users on the machine. The JHU PDP-11/45 was used for the EE classes
and we had more than that many users. The kernel was modified to
check if the GID was 200 or greater. If it was, that was taken along
with the UID to be part of the user identity. We gave all the class
accounts such GIDs.
Of course, we had to be careful about newgrp and fun and games with
setuid/setgid (both the system call and the bits on the executables).
I spent a lot of my time looking for exploits there and fixing them once
I (or someone else) found them.
Hi,
Will someone please explain the history and usage of gpasswd / newgrp / sg?
I've run across them again recently while reading old Unix texts. I've
been aware of them for years, but I've never actually used them for
anything beyond kicking the tires. So I figured that I'd inquire of the
hive mind that is TUHS / COFF.
When was the concept of group passwords introduced?
What was the problem that group passwords were the solution for?
How common was the use of group passwords?
I ran into one comment indicating that they used newgrp to work around a
limitation in the number of (secondary) groups in relation to an NFS
implementation. Specifically that the implementation of NFS they were
using didn't support more than 16 groups. So they would switch their
primary group to work around this limit.
Does anyone have any interesting stories related to group passwords /
gpasswd / newgrp / sg?
--
Grant. . . .
unix || die
Can people **please** send posts to one of these two lists, only? Having to go
through and delete every other post (yeah, I know, I could relete _all_
messages to either list, since they are archived, but old habits are hard to
break) is _really_ annoying.
OK, I can see sending an _initial_ query to both lists, to get it to as wide
a circle as possible: _but_ BCC at least one of them, to prevent lazy people
just hitting 'reply all' and thereby sanding out multiple copies of their
reply.
Thank you.
Noel
I wanted to pass on a recommendation of a new book from MIT Press called:
“A New History of Computing” by Thomas Haigh and Paul Cerruzzi, ISBN
978-0-262-54299-0
Full disclosure, I reviewed a bit of it for them and have been eagerly
awaiting final publication.
I do expect a lot of the readers of this mailing list will enjoy it. They
did a super job researching it and it’s very complete and of course,
interesting. FWIW: the work of a number people that are part of this list
is nice chronicled.
Clem
--
Sent from a handheld expect more typos than usual
I have been looking for some time for a C Reference Manual from early 1973 (or late 1972) where Dennis comments that multiple array subscripts will eventually have Fortran-like syntax with commas separating rather than multiple sets of square brackets. That was the first C manual I had back when I first learned the language. Silly me, I discarded it when a newer one was issued, not realizing the historical significance of the earlier one.
- Alan
> Is there a trick to make a macro or string return a value?
I know what you mean. Though a string does return a value, it
can't compute an arithmetic result. Alternatively, a macro,
which can use arithmetic, can only return the result as a distinct
input line. (That might be overcome by a trick with \c, but I don't
see one right off.)
Though I have no useful advice about this dilemma, it does spur
memories. I wrote the pre-Unix roff that was reimplemented on
Unix and then superseded by Joe Ossanna's nroff. Joe introduced
macros. Curiously, I had implemented macros in an assembler so
early on (1959) that I have (incorrectly) been cited as the father of
macros, yet it never occurred to me to put them in roff.
Joe's work inspired me to add macros to pre-Unix roff. I did
one thing differently. A macro could be called the usual way or
it could be called inline like an nroff string. The only difference
was that a macro's final newline was omitted when it was
expanded inline. That implementation might have helped with
the dilemma.
Doug