Hello everyone!
I had been lurking this list for long, this is my first post to this
list.
I read with a lot of interest, an old Usenix paper by the late Richard
Stevens on a system called "Portals":
<https://www.usenix.org/legacy/publications/library/proceedings/neworl/steve…>
It explores a lot of ideas that found itself in Plan 9, like a
filesystem interface for sockets etc. Wondering if this survived in any
existing, so called "modern" Unix. I have always felt the need to have
something like this in Unix.
Cheers
--
Ramakrishnan
On 2016-04-02 04:00, Greg 'groggy' Lehey <grog(a)lemis.com> wrote:
> On Saturday, 2 April 2016 at 1:06:58 +1100, Dave Horsfall wrote:
>> On Mon, 28 Mar 2016, scj(a)yaccman.com wrote:
>>
>>> ... and I once heard an old-timer growl at a young programmer "I've
>>> written boot loaders that were shorter than your variable names!"
>>
>> Ah, the 512-byte boot blocks... We got pretty inventive in those days
>> (and this was before secondary loaders!) with line editing etc.
>
> I was thinking more of the RIM loader on the PDP-8. 16 words or 24
> bytes.
Bah! The RK8E bootloader for OS/8: 2 words... :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Hi TUHSers,
For a long time now, I have had a theory that I've never seen
substantiated (or disproved) in print. After Steve Johnson's recollection
of how hard it was to type on the Teletype terminals, I'm going to throw
this thought out for consideration.
One of Unix's signature hallmarks is its terseness: short command names
like mv, ln, cp, cc, ed; short options (a dash and a single letter),
programs with just a few, if any, options at all, and short path names:
"usr" instead of "user", "src" instead of "source" and so on.
I have long theorized that the reason for the short names is that since
typing was so physically demanding, it was natural to make the command
names (and all the rest) be short and easier to type. I don't know if
this was a conscious decision, but I suspect it more likely to have been
an unconscious / natural one.
Today, I started wondering if this wasn't at least part of the reason
for commands being simple, with few if any options. After all, if I
have to type 'man foo' to remember how foo works, I don't want to wait
for 85 pages of printout (at 110 characters per second!) to finally see
what option -z does after wading through the descriptions of options -a
through -y.
I certainly think there's some truth to this idea; longer command
names and especially GNU style long options didn't appear until the
video terminal era when terminals were faster (9600 or 19200 baud!) and
much less physically demanding to use. How MUCH correlation is there,
I don't claim to know, but I think there's definitely some.
For the record, I did use the paper teletypes some, mainly at a university
where I took summer classes, connected to a Univac system. I remember
how hard it was to use them. You could almost set your watch by when
it would crash around noon time, as the load went up. :-) On Unix I
only used VDTs, except if I was at a console DECwriter.
Anyway, that's my thought. :-) Comments and or insights, especially from
those who were there, would be welcome.
Thanks,
Arnold
The Unix History repository on GitHub [1] aims to provide the evolution
of Unix from the 1970s until today under Git revision control. Through
a few changes recently made [2] it's now possible for individual
contributors to have their GitHub profile linked to their early Unix
contributions. Ken Thompson graciously made this move last week
following a personal email invitation. I think it would be really cool
if more followed. This would send a powerful message of continuity and
tradition in computing to youngsters joining GitHub today.
What you need to do is the following.
- Create a GitHub profile (if you haven't already got one)
- Click on https://github.com/settings/emails
- Add the email address(es) associated with your early Unix commits
(e.g. foo(a)research.uucp or bar(a)ucbvax.berkeley.edu) You can easily find
an author's commits and email addresses recorded in the repository
through the web search form http://www.spinellis.gr/cgi-bin/namegrep.pl
- GitHub will tell you that a verification email has been sent to your
(probably defunct) email address. Don't worry. Your account will be
linked to the address even without the verification step.
- Adding your photograph to your profile will increase the vividness of
GitHub's revision listings.
If you're in contact with Unix contributors who are not on this list,
please forward them this message. Also, if your name isn't properly
associated with the repository's commits, drop me an email message (or a
GitHub pull request for the corresponding file [3]), and I'll add it.
[1] https://github.com/dspinellis/unix-history-repo
[2] The modifications involved the change of UUCP addresses to use the
.uucp pseudo-domain rather than a ! path and the listing of co-authors
within the commit message.
[3]
https://github.com/dspinellis/unix-history-make/tree/master/src/author-path
Diomidis - http://www.spinellis.gr
Just a friendly word from the guy who runs the TUHS list.
Historical details, with verifiable facts: OK.
Questions and replies about old systems: OK.
Semi-off-topic threads: mostly OK, they usually peter out.
Comments about systems (good or bad): fine.
Comments about individuals and their motivations/actions
(especially if the comments are pejorative): not good at all.
If you think a thread is going to devolve into a slanging match
between people, then a) don't fuel the flames by posting replies,
b) walk away and calm down, c) let me know.
We've had a few threads recently which are coming close to the
edge, and I hate acting as a censor/wet blanket, so please
avoid saying things that will raise other people's hackles.
Back to you regularly scheduled notalgia....
Warren
Marc Rochkind:
BSD is the new kind on the block. I don't think it came along until 1977 or
so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in
the PWB releases, if you don't count the earlier version in SNOBOL4 for the
IBM mainframes.
=====
Correct. We never needed no stinkin' revision control in Research.
More fairly, early systems like SCCS were so cumbersome that a
community that was fairly small, in which everyone talked to
everyone, and in which there was no glaring need wasn't willing
to adopt them.
I remember trying SCCS for a few small personal projects back in
1979 or so (well before I moved to New Jersey), finding it just
too clunky for the benefits it gave me, and giving up. Much later,
I found RCS just as messy. One thing that really bugged me was
those systems' inherent belief that you rarely want to keep a
checked-out copy of something except while you're working on it.
Another, harder to work around, is that in any nontrivial project
there are often stages when I want to make changes of scope broader
than a single file: factor common stuff out into a new file, merge
things into a single file, rename files, etc.
CVS was a big step forward, but not enough. Subversion was the
first revision-control that didn't feel like a huge burden to me.
None of which is to say that SCCS and RCS were useless; they were
important pioneers, and for the big projects that originally
spawned them I'm sure they were indispensible. But I can't imagine
Ken or Dennis putting up with them for very long, and I'm glad I
never had to.
Norman Wilson
Toronto ON
> These are USED cards. That's OK. No duty!
Quite the opposite happened to me in Britain. I wanted to
import an early computer-generated film to show. When I
inquired whether there would be any customs implications,
I was asked whether the film was exposed or not. Britain
charged duty only on exposed film.
With apologies for straying ever farther from Unix,
Doug
> From: Dave Horsfall
> That makes sense, and someone forgot to document it...
Or perhaps it was added precisely to get rid of the window, and then someone
discovered that it could be used to freeze the system, so they decided they'd
better not document it?
If the system had MOS memory, and you had to power cycle the machine to get it
out of this state, there wouldn't be any evidence left of who did the deed
(unless the system was writing extensive audit trailing to disk), so it would
be a great 'system assasin' (aka vandal) tool.
Noel
PS: I guess this is more PDP-11ish than UNIXish - apologies for the off-topic!
On 21 March 2016 at 17:43, Greg 'groggy' Lehey <grog(a)lemis.com> wrote:
> On Tuesday, 22 March 2016 at 1:11:07 +1100, Dave Horsfall wrote:
>>
>> Walking down the corridors of Comp Sci, a student in front of me
>> dropped his entire deck of approx 2000 cards, all over the floor...
>> I have no idea whether he got them sorted, but I sure as hell used
>> rubber bands after that!
>
> But that's what the sequence numbers in columns 73 to 80 are for!
I did that religiously, even with my small PL/C runs -- PL/C runs were
free. One day, they decided to extend the code area to the entire
card.... and so I learned another feature of the card punch.
N.
>
> Greg
> --