> From: Clem Cole > when she found out the elevators were hacked and controlled by the > student's different computers, she stopped using them and would take > the stairs It wasn't quite as major as this makes it sound! A couple of inconspicuous wires were run from the 'TV 11' on the MIT-AI KA10 machine (the -11 that ran the Knight displays) into the elevator controller, and run onto the terminals where the wires from the 'down' call buttons on the 8th and 9th floors went. So it wasn't anything major, and there was really no need for her to take the stair (especially 8 flights up :-). The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) from Knight TV keyboards; typing 'ESC E' called the elevator to the floor that keyboard was on (there's a table, 'ELETAB', which gives the physical floor for each keyboard). The machine could also open the locked 9th floor door to the machine room (with an 'ESC D'), and there some other less major things, e.g. print screen hardcopy. I'm not sure what the hardware in the TV-11 was (this was all run out of the 'keyboard multiplexor'); it may have been something the AI Lab built from scratch. Noel
Noel Chiappa writes:
> The code is still extant, in 'SYSTEM; TV >'. It only worked (I think)
> from Knight TV keyboards
(This isn't TUHS material, but I can't resist. CC to COFF.)
There is also a Chaosnet service to call for the elevator or open the
door, so it can be used remotely. The ITS program ESCE uses this
service. I suppose there must have been something for the Lisp machines
too, maybe even a Super-Hyper-Cokebottle keyboard command.
On 10/01/20, Noel Chiappa wrote:
> > From: Clem Cole
>
> > when she found out the elevators were hacked and controlled by the
> > student's different computers, she stopped using them and would take
> > the stairs
>
> It wasn't quite as major as this makes it sound! A couple of inconspicuous
> wires were run from the 'TV 11' on the MIT-AI KA10 machine (the -11 that ran
> the Knight displays) into the elevator controller, and run onto the terminals
> where the wires from the 'down' call buttons on the 8th and 9th floors went.
>
> So it wasn't anything major, and there was really no need for her to take the
> stair (especially 8 flights up :-).
>
> The code is still extant, in 'SYSTEM; TV >'. It only worked (I think) from
> Knight TV keyboards; typing 'ESC E' called the elevator to the floor
> that keyboard was on (there's a table, 'ELETAB', which gives the physical
> floor for each keyboard).
>
> The machine could also open the locked 9th floor door to the machine room
> (with an 'ESC D'), and there some other less major things, e.g. print screen
> hardcopy. I'm not sure what the hardware in the TV-11 was (this was all run
> out of the 'keyboard multiplexor'); it may have been something the AI Lab
> built from scratch.
For those not aware: we have the TV-11 running again under emulation and
it is once again the preferred way to use ITS.
Unfortunately I'm not quite sure how to emulate all the elevator
behaviour...any ideas? :D
aap
Mention of elevators at Tech Square reminds me of visiting there to see the Lisp machine. I was struck by cultural differences. At the time we were using Jerqs, where multiple windows ran like multiple time-sharing sessions. To me that behavior was a no-brainer. Surprisingly, Lisp-machine windows didn't work that way; only the user-selected active window got processor time. The biggest difference was emacs, which no one used at Bell Labs. Emacs, of course was native to the Lisp machine and provided a powerful and smoothly extensible environment. For example, its reflective ability made it easy to display a list of its commands. "Call elevator" stood out amng mundane programmering actions like cut, paste and run. After scrolling through the command list, I wondered how long it was and asked to have it counted. Easy, I thought, just pass it to a wc-like program. But "just pass it" and "wc-like" were not givens as they are in Unix culture. It took several minutes for the gurus to do it--without leaving emacs, if I remember right. Doug
[-- Attachment #1: Type: text/plain, Size: 1746 bytes --] On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > Mention of elevators at Tech Square reminds me of visiting there > to see the Lisp machine. I was struck by cultural differences. > > At the time we were using Jerqs, where multiple windows ran > like multiple time-sharing sessions. To me that behavior was a > no-brainer. Surprisingly, Lisp-machine windows didn't work that > way; only the user-selected active window got processor time. > > The biggest difference was emacs, which no one used at Bell > Labs. Emacs, of course was native to the Lisp machine and > provided a powerful and smoothly extensible environment. For > example, its reflective ability made it easy to display a > list of its commands. "Call elevator" stood out amng mundane > programmering actions like cut, paste and run. > > After scrolling through the command list, I wondered how long > it was and asked to have it counted. Easy, I thought, just > pass it to a wc-like program. But "just pass it" and "wc-like" > were not givens as they are in Unix culture. It took several > minutes for the gurus to do it--without leaving emacs, if I > remember right. > It should have been something like (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by. ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse... Warner [-- Attachment #2: Type: text/html, Size: 2245 bytes --]
Hoi.
[2020-01-12 09:56] Warner Losh <imp@bsdimp.com>
>
> It should have been something like (list-length (command-list-fn)) but I'll
> bet that ? was bound to a complicated function that just displayed the results
> and didn't properly abstract out the UI (printing) from the data collection
> (getting a list), which is what made it so hard. I've had so many gnu emacs
> experiences like this over the years, but to the community's credit, there's
> fewer and fewer as time goes by.
>
> ObUnix: This shows the power of having the right abstractions and being
> disciplined to code to those ideal abstractions any time there might be
> reuse...
True words.
These concepts (what you call abstractions) is no optional geek
pleasure but the most important information for everyone using the
system or language. It's important to teach them, make them explicit,
deal with them, substract points in exams for correct solutions that
have bad style, keep the libraries and books on a high level, ...
This is one of the lesser regarded aspects of what Unix did really
well.
meillo
This is kind of illustrative of the '60s acid trip that perpetuates in
programming "Everything's a string maaaaan". The output is seen as
truth because the representation is for some reason too hard to get at
or too hard to cascade through the system.
There's a total comedy of work going on in the unix way of a wc
pipeline versus calling a length function on a list. Nonetheless, the
unix pipeline was and is often magnitude easier for a single user to
get at. This kind of thing is amusing and endearing to me about our
profession in modern day.
Regards,
Kevin
On Sun, Jan 12, 2020 at 9:57 AM Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:
>>
>> Mention of elevators at Tech Square reminds me of visiting there
>> to see the Lisp machine. I was struck by cultural differences.
>>
>> At the time we were using Jerqs, where multiple windows ran
>> like multiple time-sharing sessions. To me that behavior was a
>> no-brainer. Surprisingly, Lisp-machine windows didn't work that
>> way; only the user-selected active window got processor time.
>>
>> The biggest difference was emacs, which no one used at Bell
>> Labs. Emacs, of course was native to the Lisp machine and
>> provided a powerful and smoothly extensible environment. For
>> example, its reflective ability made it easy to display a
>> list of its commands. "Call elevator" stood out amng mundane
>> programmering actions like cut, paste and run.
>>
>> After scrolling through the command list, I wondered how long
>> it was and asked to have it counted. Easy, I thought, just
>> pass it to a wc-like program. But "just pass it" and "wc-like"
>> were not givens as they are in Unix culture. It took several
>> minutes for the gurus to do it--without leaving emacs, if I
>> remember right.
>
>
> It should have been something like (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by.
>
> ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse...
>
> Warner
I'll counter with Linux's /proc where everything is a string. It's super pleasant and I say that coming from SysV /proc where it was all a mess. If performance is the metric, everything is a string is not so much. If performance is not the high order bit, a /proc that you can read with cat or grep is super pleasant. On Sun, Jan 12, 2020 at 01:25:13PM -0700, Kevin Bowling wrote: > This is kind of illustrative of the '60s acid trip that perpetuates in > programming "Everything's a string maaaaan". The output is seen as > truth because the representation is for some reason too hard to get at > or too hard to cascade through the system. > > There's a total comedy of work going on in the unix way of a wc > pipeline versus calling a length function on a list. Nonetheless, the > unix pipeline was and is often magnitude easier for a single user to > get at. This kind of thing is amusing and endearing to me about our > profession in modern day. > > Regards, > Kevin > > On Sun, Jan 12, 2020 at 9:57 AM Warner Losh <imp@bsdimp.com> wrote: > > > > > > > > On Sun, Jan 12, 2020 at 6:44 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > >> > >> Mention of elevators at Tech Square reminds me of visiting there > >> to see the Lisp machine. I was struck by cultural differences. > >> > >> At the time we were using Jerqs, where multiple windows ran > >> like multiple time-sharing sessions. To me that behavior was a > >> no-brainer. Surprisingly, Lisp-machine windows didn't work that > >> way; only the user-selected active window got processor time. > >> > >> The biggest difference was emacs, which no one used at Bell > >> Labs. Emacs, of course was native to the Lisp machine and > >> provided a powerful and smoothly extensible environment. For > >> example, its reflective ability made it easy to display a > >> list of its commands. "Call elevator" stood out amng mundane > >> programmering actions like cut, paste and run. > >> > >> After scrolling through the command list, I wondered how long > >> it was and asked to have it counted. Easy, I thought, just > >> pass it to a wc-like program. But "just pass it" and "wc-like" > >> were not givens as they are in Unix culture. It took several > >> minutes for the gurus to do it--without leaving emacs, if I > >> remember right. > > > > > > It should have been something like (list-length (command-list-fn)) but I'll bet that ? was bound to a complicated function that just displayed the results and didn't properly abstract out the UI (printing) from the data collection (getting a list), which is what made it so hard. I've had so many gnu emacs experiences like this over the years, but to the community's credit, there's fewer and fewer as time goes by. > > > > ObUnix: This shows the power of having the right abstractions and being disciplined to code to those ideal abstractions any time there might be reuse... > > > > Warner -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
Kevin Bowling writes:
> This is kind of illustrative of the '60s acid trip that perpetuates in
> programming "Everything's a string maaaaan". The output is seen as
> truth because the representation is for some reason too hard to get at
> or too hard to cascade through the system.
>
> There's a total comedy of work going on in the unix way of a wc
> pipeline versus calling a length function on a list. Nonetheless, the
> unix pipeline was and is often magnitude easier for a single user to
> get at. This kind of thing is amusing and endearing to me about our
> profession in modern day.
>
> Regards,
> Kevin
Can you please elaborate? I read your post, and while I can see that it
contains English words I can't make any sense out of what you said.
Thanks,
Jon
I honestly can't tell if this is genius level snark :) in case you're
sincere we generally go to great lengths to build up data types and
structures (in C lingo) when programming only to tear those useful
attributes off often at inopportune times. Basically type
systems/type safety have been too expensive or too difficult to use
through history.
Think of sitting at an SQL prompt as a counterpoint. You can pretty
easily get at the underlying representation and relationships of the
data and the output is just a side effect. Not saying SQL is the
ultimate answer, just that most people have a bit of experience with
it and UNIX so can mentally compare the two for themselves and see the
pros and cons to preserving the underlying representations.
Regards,
Kevin
On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon@fourwinds.com> wrote:
>
> Kevin Bowling writes:
> > This is kind of illustrative of the '60s acid trip that perpetuates in
> > programming "Everything's a string maaaaan". The output is seen as
> > truth because the representation is for some reason too hard to get at
> > or too hard to cascade through the system.
> >
> > There's a total comedy of work going on in the unix way of a wc
> > pipeline versus calling a length function on a list. Nonetheless, the
> > unix pipeline was and is often magnitude easier for a single user to
> > get at. This kind of thing is amusing and endearing to me about our
> > profession in modern day.
> >
> > Regards,
> > Kevin
>
> Can you please elaborate? I read your post, and while I can see that it
> contains English words I can't make any sense out of what you said.
>
> Thanks,
> Jon
Kevin Bowling writes:
> I honestly can't tell if this is genius level snark :) in case you're
> sincere we generally go to great lengths to build up data types and
> structures (in C lingo) when programming only to tear those useful
> attributes off often at inopportune times. Basically type
> systems/type safety have been too expensive or too difficult to use
> through history.
>
> Think of sitting at an SQL prompt as a counterpoint. You can pretty
> easily get at the underlying representation and relationships of the
> data and the output is just a side effect. Not saying SQL is the
> ultimate answer, just that most people have a bit of experience with
> it and UNIX so can mentally compare the two for themselves and see the
> pros and cons to preserving the underlying representations.
>
> Regards,
> Kevin
>
> On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon@fourwinds.com> wrote:
> >
> > Kevin Bowling writes:
> > > This is kind of illustrative of the '60s acid trip that perpetuates in
> > > programming "Everything's a string maaaaan". The output is seen as
> > > truth because the representation is for some reason too hard to get at
> > > or too hard to cascade through the system.
> > >
> > > There's a total comedy of work going on in the unix way of a wc
> > > pipeline versus calling a length function on a list. Nonetheless, the
> > > unix pipeline was and is often magnitude easier for a single user to
> > > get at. This kind of thing is amusing and endearing to me about our
> > > profession in modern day.
> > >
> > > Regards,
> > > Kevin
> >
> > Can you please elaborate? I read your post, and while I can see that it
> > contains English words I can't make any sense out of what you said.
> >
> > Thanks,
> > Jon
I wasn't being snarky. You said
"The output is seen as truth because the representation is for some
reason too hard to get at or too hard to cascade through the system."
I honestly have no idea what that means.
Likewise,
"There's a total comedy of work going on in the unix way of
a wc pipeline versus calling a length function on a list."
I just don't know what you mean.
Jon
On Sun, Jan 12, 2020 at 1:45 PM Jon Steinhart <jon@fourwinds.com> wrote: > > Kevin Bowling writes: > > I honestly can't tell if this is genius level snark :) in case you're > > sincere we generally go to great lengths to build up data types and > > structures (in C lingo) when programming only to tear those useful > > attributes off often at inopportune times. Basically type > > systems/type safety have been too expensive or too difficult to use > > through history. > > > > Think of sitting at an SQL prompt as a counterpoint. You can pretty > > easily get at the underlying representation and relationships of the > > data and the output is just a side effect. Not saying SQL is the > > ultimate answer, just that most people have a bit of experience with > > it and UNIX so can mentally compare the two for themselves and see the > > pros and cons to preserving the underlying representations. > > > > Regards, > > Kevin > > > > On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart <jon@fourwinds.com> wrote: > > > > > > Kevin Bowling writes: > > > > This is kind of illustrative of the '60s acid trip that perpetuates in > > > > programming "Everything's a string maaaaan". The output is seen as > > > > truth because the representation is for some reason too hard to get at > > > > or too hard to cascade through the system. > > > > > > > > There's a total comedy of work going on in the unix way of a wc > > > > pipeline versus calling a length function on a list. Nonetheless, the > > > > unix pipeline was and is often magnitude easier for a single user to > > > > get at. This kind of thing is amusing and endearing to me about our > > > > profession in modern day. > > > > > > > > Regards, > > > > Kevin > > > > > > Can you please elaborate? I read your post, and while I can see that it > > > contains English words I can't make any sense out of what you said. > > > > > > Thanks, > > > Jon > > I wasn't being snarky. You said > > "The output is seen as truth because the representation is for some > reason too hard to get at or too hard to cascade through the system." > > I honestly have no idea what that means. If the SQL prompt example did not clarify you are welcome to go one on one if this is something you think is curious to you, I think I've explained the point I was making adequately for a general audience. > > Likewise, > > "There's a total comedy of work going on in the unix way of > a wc pipeline versus calling a length function on a list." > > I just don't know what you mean. > Reason through what happens in a shell pipeline, the more detail the better. A quick nudge is fork/exec, what happens in the kernel, what happens in page tables, what happens at the buffered output, tty layer etc. Very few people actually understand all these steps even at a general level in modern systems. If you had a grocery list on a piece of paper would you a) count the lines or read it directly off the last line number on the paper if it is numbered b) copy each character letter by letter to a new piece of equipment (say, a word processor), until you encounter a special character that happens to be represented as a space on the screen, increment a counter, repeat until you reach another special character, output the result and then destroy and throw away both the list and the word processor equipment. This kind of thing doesn't really matter in the small or at all for performance because computers are fast. But most programming bugs in the large eventually boil down to some kind of misunderstanding where the representation was lost and recast in a way that does not make sense. Regards, Kevin
On Sun, 12 Jan 2020 12:44:30 -0800 Jon Steinhart <jon@fourwinds.com> wrote:
>
> I wasn't being snarky. You said
>
> "The output is seen as truth because the representation is for some
> reason too hard to get at or too hard to cascade through the system."
>
> I honestly have no idea what that means.
>
> Likewise,
>
> "There's a total comedy of work going on in the unix way of
> a wc pipeline versus calling a length function on a list."
>
> I just don't know what you mean.
May be this is not what Kevin meant but the way I interpreted
his message: smushing everything down to strings for output as
in unix pipelines loses any underlying structure which then
may have to be rediscovered by the next program in the
pipeline by parsing. This is slower, indirect and errorprone.
If one can communicate a structured representation of data between
components that would be better.
Bakul Shah writes:
> On Sun, 12 Jan 2020 12:44:30 -0800 Jon Steinhart <jon@fourwinds.com> wrote:
> >
> > I wasn't being snarky. You said
> >
> > "The output is seen as truth because the representation is for some
> > reason too hard to get at or too hard to cascade through the system."
> >
> > I honestly have no idea what that means.
> >
> > Likewise,
> >
> > "There's a total comedy of work going on in the unix way of
> > a wc pipeline versus calling a length function on a list."
> >
> > I just don't know what you mean.
>
> May be this is not what Kevin meant but the way I interpreted
> his message: smushing everything down to strings for output as
> in unix pipelines loses any underlying structure which then
> may have to be rediscovered by the next program in the
> pipeline by parsing. This is slower, indirect and errorprone.
> If one can communicate a structured representation of data between
> components that would be better.
Ah. So lines IS the structure that a lot of people want. As I just
said in a post, the JSON tools are a good example of communicating
structured data although I would have done them differently.
Jon
>> After scrolling through the command list, I wondered how >> long it was and asked to have it counted. Easy, I thought, >> just pass it to a wc-like program. But "just pass it" and >> "wc-like" were not givens as they are in Unix culture. >> It took several minutes for the gurus to do it--without >> leaving emacs, if I remember right. > This is kind of illustrative of the '60s acid trip that > perpetuates in programming "Everything's a string maaaaan". > The output is seen as truth because the representation is > for some reason too hard to get at or too hard to cascade > through the system. How did strings get into the discussion? Warner showed how emacs could be expected to do the job--and more efficiently than the Unix way, at that: (list-length (command-list-fn)). The surprise was that this wasn't readily available. Back then, in fact, you couldn't ask sh for its command list. help|wc couldn't be done because help wasn't there. Emacs had a different problem. It had a universal internal interface--lists rather than strings--yet did not have a way to cause this particular list to "cascade through the system". (print(command-list-fn)) was provided, while (command-list-fn) was hidden. Doug
On Sun, Jan 12, 2020 at 3:26 PM Doug McIlroy <doug@cs.dartmouth.edu> wrote: > > >> After scrolling through the command list, I wondered how > >> long it was and asked to have it counted. Easy, I thought, > >> just pass it to a wc-like program. But "just pass it" and > >> "wc-like" were not givens as they are in Unix culture. > >> It took several minutes for the gurus to do it--without > >> leaving emacs, if I remember right. > > > This is kind of illustrative of the '60s acid trip that > > perpetuates in programming "Everything's a string maaaaan". > > The output is seen as truth because the representation is > > for some reason too hard to get at or too hard to cascade > > through the system. > > How did strings get into the discussion? Warner showed how > emacs could be expected to do the job--and more efficiently > than the Unix way, at that: (list-length (command-list-fn)). > The surprise was that this wasn't readily available. Bakul provided an explanation for the pipeline, the funny cue to me that I interpreted from Warner's message is just that emacs had the ability to do it in a coherent way but did not and ISTM that the way you make a mess of that is by losing the intent of the representation. I am regularly surprised by how surprising type systems are to computing professionals. The language and environment may help or dissuade you from doing that, wasn't really relevant to my original point. Larry tells me the message is somehow inflammatory, it wasn't intended that way I was just trying to make light of the situation and provide people a launch pad to think for themselves about some fundamentals because it's worthwhile to do so occasionally. > Back then, in fact, you couldn't ask sh for its command > list. help|wc couldn't be done because help wasn't there. > > Emacs had a different problem. It had a universal internal > interface--lists rather than strings--yet did not have > a way to cause this particular list to "cascade through > the system". (print(command-list-fn)) was provided, while > (command-list-fn) was hidden. The only response I can come up with to these two points eventually boils down to a philosophical riddle: does the work matter or does how the work is done matter? Both, the situation dictates. I execute innumerable shell pipelines per day and perhaps craft a dozen ephemerals ones. Regards, Kevin