|
|
| Author |
Message |
twenex
|
|
The Unix History Item
| 
Sep 16 23:22 UTC 2006 |
This is the history of Unix item. This item is for discussing and reminiscing
on the history of Unix, its interplay with other historical systems, etc.
|
| 16 responses total. |
remmers
|
|
response 1 of 16:
|
Sep 18 15:01 UTC 2006 |
My first exposure to Unix was as visiting faculty at North Dakota State
University in 1981-82. My department had a PDP-11 running Unix Version 6
with Rand extensions. As someone whose previous experience was mostly
DEC-10, this was quite an eye-opener. At last, command line and
programming interfaces that actually faculitated rather than interfered.
I've been a Unix fan ever since.
|
herasleftnut
|
|
response 2 of 16:
|
Sep 20 13:26 UTC 2006 |
My first experience with Unix was around the end of 1995 and the start of
1996. At the time, I was playing this online game called Mortal Realms at the
University of Wisconsin. Anyhow, I asked a few people how they connected to
the gaming site from home. I wanted to still play the MUD on Christmas
vacation. I was told to use the unix telnet client.
I think my first time I put *nix on a PC was my senior yr in college (circa
1999). Damn studies got in the way. I guess I never really got interested in
it because most *nix discussion usually involved programming. At the time,
I has zero interest in programming. I think my interest in Unix and computer
programming in general happened after I moved out to California a few years
ago. For whatever reasons, I had read an old article in the Phrack called
"Smashing the Stack for Fun and Profit" by Aleph1.
Even thought I didn't understand a damn word of the article, it sounded cool.
So I did what any sane male would have done. I literally went line by line
though the article, trying to understand what he was talking about. It was
a real good time. Those moments where it took me 2 weeks of googling to
understand one paragraph in the article. In the end, it took me way to fucking
long to understand the article. But somewhere along the way, I not long found
computer programming (and Unix) as mundane.
|
herasleftnut
|
|
response 3 of 16:
|
Sep 20 13:28 UTC 2006 |
Oka, well I was doing good until that last sentence.
|
nharmon
|
|
response 4 of 16:
|
Sep 20 13:46 UTC 2006 |
My first experience with Unix was on here (Grex). I learned a lot about
Unix on Grex, M-Net, and Nether.net (back when it gave out free
accounts). But really how much can you learn about Unix from just being
a user? So I set out to run my own box. I think that was around 1995. I
downloaded Slackware off of a BBS. This took a long time because I was
on a slow dialup connection then. I think I downloaded like 30 floppy
images. And once I had those, I reloaded my 386 computer with Linux.
|
albaugh
|
|
response 5 of 16:
|
Sep 20 15:29 UTC 2006 |
I have set up an alias "h" for my UNIX "history". ;-)
|
cross
|
|
response 6 of 16:
|
Sep 20 22:25 UTC 2006 |
Regarding #4; I think one can actually learn quite a bit being just a user;
a lot of what I've learned about Unix has been as a user, though it's true
that you can get into some esoteric stuff if you're root. Some of, to me,
the most fascinating things have been discovered under just my ordinary
login.
Incidentally, Plan 9 does away with the concept of root.
|
twenex
|
|
response 7 of 16:
|
Sep 20 22:53 UTC 2006 |
So is there a wheel group or something?
|
cross
|
|
response 8 of 16:
|
Sep 20 23:32 UTC 2006 |
There are multiple groups that can do system administration like things. Most
of the need for it is eliminated by architectural differences, though. For
instance, backups are just built into the filesystem - no need to be root to
get at the raw disk devices to dump them to tape. Namespaces are mutable:
no need to be special to put something in /bin; just bind your personal bin
over it. Groups can easily share this way: everyone bind everyone else in
the group's bin onto /bin and you end up with the union of everybody's work.
About the only special tasks that need to be done are adding accounts and
resetting passwords and things like that. These are done from the console,
or via secure network authenticated programs somewhat akin to Kerberos.
|
gull
|
|
response 9 of 16:
|
Sep 21 16:47 UTC 2006 |
One of UNIX's weaknesses, from a security standpoint, is the number of
tasks it has where you have to be root. Root is dangerous; it has
*too* much power. A finer-grained security model would avoid a lot of
problems.
For example, think of all the messiness involved in daemons starting as
root, then dropping privileges. Most of that could be avoided if there
were a way to grant other accounts the ability to bind low-numbered
ports.
|
twenex
|
|
response 10 of 16:
|
Sep 21 16:56 UTC 2006 |
In fairness, UNIX was invented for an environment in which you really wouldn't
expect more than one or two users with administrative privileges per
(non-networked) multiuser computer. There are ways around the problem - using
sudo, for example, you can assign rights to run x or y to this or that user
- but I doubt, in an environment where few users bother using "limited"
accounts (in order to avoid having to type in passwords, especially when doing
administrative stuff) that it is reasonable to expect single-user workstation
owners to remember and use different account names and passwords for printer
installation, drive configuration, networking filesystem configuration...
|
cross
|
|
response 11 of 16:
|
Sep 22 01:00 UTC 2006 |
Regarding #9; Perhaps, though finer grained security models can be a mixed
bag. Very often, there's a tendency to not want to sort through exactly
what privileges are needed for what, so you end up just taking the union of
all privileges and end up being about as powerful as root. That's not
particularly good....
Regarding #10; It's true, Unix was designed for a vastly different
environment than what it ended up occupying.
|
herasleftnut
|
|
response 12 of 16:
|
Sep 24 00:25 UTC 2006 |
This reminds me of what Dennis Richtie wrote in the Forward to "Advanced
Programmin in the Unix Environment."
And I quote:
"As it happened, Unix was able to adapt rather gracefully to a networked
environment and, perhaps less elegantly, but still adquately, to a graphical
one."
|
cross
|
|
response 13 of 16:
|
Sep 24 01:12 UTC 2006 |
Al Aho once told me, "Dennis Ritchie is a peach of a guy!" and he's
absolutely right; Dennis is a great guy. But, my sense from talking to him
about these issues is that he was unsatisfied with the way X11 turned out,
and felt that sockets were okay, a bit ugly, not perfect, but usable.
X11 is certainly a step backwards; the window system they had under research
Unix was much morer interesting and didn't rely as much on the old terminal
paradigm. But some of the X11 decisions were clearly influenced by sockets,
and some of the things the Berkeley people added to Unix to support the
model of networking prevelant in a TTY-based world, where you login through
some sort of virtual pseudo-terminal interface. It worked, it had utility,
but forced preservation of a model that dates to the mid-1960's and arguably
stifled a lot of potential for progress.
Sockets broke from the view of the world where the file was the fundamental
locus of system interaction for the application programmer. Instead, of
opening and reading and writing files, you now had sockets that existed in
this wierd parallel namespace that was more or less addressed by special
function binary structures, with special system calls devoted to bringing
these things into being and manipulating them. The radically simple view of
the world was a hierarchical name tree was gone.
Networking was done differently in 9th and 10th Edition research Unix, but
those never got out of the labs and never had as big an impact on the rest
of the scene as the earlier editions, up through 32V, did.
|
twenex
|
|
response 14 of 16:
|
Sep 24 13:05 UTC 2006 |
Bugger.
|
dtk
|
|
response 15 of 16:
|
Jan 6 23:54 UTC 2013 |
During my first attempt at college, I got access to a SunOS server run a
the Computer Center, which was there to assist the computer science
faculty and students. This server ran SunOS 5.5.1 (Solaris 2.5.1) on an
E3500 (I think -- could be remembering the hardware wrong). When it was
brought down (shortly after I was kicked out), it had an up-time of five
and a half years, and only came down because the Computer Center was
moving across campus, and they were going to have some undergrads load
it onto a cart and walk it a mile across campus. While it did receive
userland upgrades, no-one applied kernel upgrades or patches. Back in
the day when big iron had *UP-TIME*.
A couple of years before I got my current job, I worked for a datacenter
outsourcing provider who rented space from a telco that also leased
space to American Airlines. AA had a four-way StarFire cluster, running
Oracle RAC. That was serious iron. -DTK
|
tod
|
|
response 16 of 16:
|
Jan 27 14:53 UTC 2017 |
Did you work with the Oracle RAC cluster? That's some expensive iron.
|