> I especially liked the bit in which Tom's virus infected a multi-level secured UNIX system that Doug McIlroy and Jim Reeds were developing which they didn't spot until they turned on all their protections ... and programs started crashing all over the place.
That's not quite right. The system was running nicely with a
lattice-based protection system (read from below, write to above)
working fine. Processes typocally begin at lattice bottom, but
move to hivel levels depending on what data they see (including,
of course any exec-ed file.) All the standard utilities, being
usable by anyone are at lattice bottom.
Cool, until you realize that highly trusted system programs
such as sudo are at lattice bottom and are protected only by
the old rwx bits, not by the read-write rules. So, following
an idea of Biba's, that integrity rules are the opposite of
secrecy rules. You don't want to forbid writing to high-integrity
places, nor read from low-integrity places.
This was done by setting the default security level away from
the lattice bottom. High-integrity stuff was below this floor;
high-secrecy above.
The Duff story is about the day we moved the floor off bottom.
An integrity violation during the boot sequence stopped the
system cold. Clearly we'd misconfigured something. But no, after
a couple of days of fruitless search, Jim Reeds lit up, "We
caught a virus!" We were unaware of Duff's experiment. He had
been chagrined when it escaped from one machine, but was able
to decontaminate all the machines in the center. Except ours,
which was not on the automatic software distrutioin list, since
it was running a different system.
> From: Andy Kosela
> That is why MIT and Bell Labs represented two very different cultures.
Oi! Not _everyone_ at MIT follows the "so complicated that there are no
obvious deficiencies" approach (to quote Hoare's wonderful aphorism from his
'Emperor's Old Clothes' Turing Award Lecture).
My personal design mantra (it's been at the top of my home page for decades)
is something I found as a footnote in Corbato and Saltzer, 'Multics: The First
Seven Years': "In anything at all, perfection has been attained, not when
there is nothing left to add, but when there is nothing left to take away..."
No doubt some people would be bemused that this should be in a Multics paper,
given the impression people have of Multics as incredibly - overly -
complicated. I'll avoid that discussion for the moment...
I've often tried to understand why some people create these incredibly
complicated systems. (Looking at the voluminous LISP Machine manual set from
Symbolics particularly caused this train of thought...) I think it's because
they are too smart - they can remember all that stuff.
Maybe my brain isn't like that (or perhaps I use large parts of it for other
stuff, like Japanese woodblock prints :-), but I much prefer simpler things.
Or maybe I'm just basically lazy, and like simpler things because they are
easier...
Noel
Hi,
ed(1) pre-dates pipes. When pipes came along, stderr was needed, and
lots of new idioms were found to make use of them. Why didn't ed gain a
`filter' command to accompany `r !foo' and `w !bar'?
To sort this paragraph, I
;/^$/w !sort >t
;/^$/d
-r t
I'd have thought that filtering was common enough to suggest a `^'
command with an implied `!'? (Not `|' since that was uncommon then.)
ex(1) has `!' that filters if applied to a range of lines, and this
carries through to vi's `!' that's often heavily used, especially when
the "file" is just a scratch buffer of commands, input, and output.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
There's a story I heard once in supercomputing circles from the 80s, that
Ken visited CRI in Minneapolis, sat down at the console of a machine
running the then-new port of Unix to one of the Crays, typed a command, and
said something like "ah, that bug is still there."
Anybody know what the bug was?
It's time to assert my editorial control and say: no more 80 cols please!
Anybody who mentions 80 cols will be forced to use either a Hazeltine or
an ADM3 (not 3a) for a month.
Thanks, Warren
Jim "wkt" Moriarty:
> Anybody who mentions 80 cols will be forced to use either a Hazeltine or
> an ADM3 (not 3a) for a month.
=====
So who has a modern emulator for either of those terminals?
Norman Wilson
Toronto ON
(Still not really in Toronto, but no longer in Texas)
Does anyone know if the image
http://www.tuhs.org/Archive/Distributions/Research/Dennis_v6/v6root.gz
is somehow bootable as-is?
I wasn't able to figure out how to get it to boot, so I went on a quest
to make it bootable. Here's what I did - let me know if this was
overkill or misguided.
Basically, I downloaded the known bootable v6 distribution tape from
Wellsch directory in TUHS. I then extracted 101 blocks from the image
(tmrk, a bootblock, and who knows what else, but seriously what else is
on those first 100 blocks?), converted it to a simh compatible tape
format, and booted a simh generic pdp11/40 with my new little boot tape
and Dennis's root disk attached. I used tmrk to copy the bootstrap from
my little tape to Dennis's root disk (am I clobbering anything
important?). Then voila - it was bootable :)! I could have done it
straight off Ken's tape (after converting it to a simh tape format), but
I wanted to keep the little tape image around for use in other contexts.
Details for the curious are here:
https://decuser.github.io/bootable-tape-v6.txt
I thought the Ken Wellsch tape was basically the same as the Dennis
Ritchie disks, but now I'm not so sure - on Ken's tape, it boots to:
@rkunix
mem = 1035
RESTRICTED RIGHTS
Use, duplication or disclosure is subject to
restrictions stated in Contract with Western
Electric Company, Inc.
#
on Dennis' it boots to:
@rkunix
mem = 1036
#
Makes me curious to see what else is different. Maybe Dennis's was prior
to preparing an official distro where the rights were added to the kernel?
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Nemo:
And for that reason, I have never used Python. (I have a mental block
about that.)
====
I used to feel the same way. A few years ago I held my nose
and jumped in. I'm glad I did; Python is a nifty little
language that, now I know it, hits a sweet spot twixt low-level
C and high-level shell and awk scripts.
Denoting blocks solely by indentation isn't at all bad once
you do it; no worse than adapting from do ... end to C's {}.
What still bugs me about Python:
-- It is unreasonably messy to give someone else a copy of
a program composed of many internal modules. Apparently
you are expected to give her a handful of files, to be
installed in some directory whose name must be added to
the search path in every Python source file that imports
them. I have come up with my own hacky workaround but it
would be nice if the language provided a graceful way to,
e.g., catenate multiple modules into a single source file
for distribution.
-- I miss C's style of for loop, though not often. (Not
quite everything can be turned into a list or an iterator.)
-- I miss one particular case of assigment having a value:
that of
while ((val = function()) != STOP)
do something with val
Again, there are clunky ways to work around this.
As for 80 columns, I'm firmly in the camp that says that
if you need a lot of indentation you're doing it wrong.
Usually it means you should be pulling the details out
into separate functions. Functions that run on for many,
many lines (once upon a time it was meaningful to say
for many pages, but no longer) are just as bad, for the
same reason: it's hard to read and understand the code,
because you have to keep so many details in your head at
once.
Likewise for excessive use of global variables, for that
matter, a flaw that is still quite common in C code.
Having to break an expression or a function call over
multiple lines is more problematic. It's clearer not
to have to do that. It helps not to make function or
variable names longer than necessary, but one can carry
that too far too.
Style and clarity are hard, but they are what distinguishes
a crap hack programmer from a good one.
Norman Wilson
Toronto ON
(Sitting on the lower level of a train in Texas,
not on a pedestal)
