The Strange Birth and Long Life of Unix

http://spectrum.ieee.org/computing/software/the-strange-birth-and-long-life-of-unix/0

by naish • 15 years ago

116 12 15 years ago

spectrum.ieee.org

fendrak• 15 years ago

The rebellious nature of Unix sharing in the early days taught an important lesson for would-be sharers today: either take pains to make sure your software can be used by anyone who wants to, or risk being shackled by lawyers and corporations who don't want it to be used.

plessthanpt05• 15 years ago

other than unix (clearly) being one of the most important technological leaps forward in computing, which is just a given at this point, well, that pic is just awesome!

jamesgeck0• 15 years ago

I can't remember a time before CVS (and now DVCS). Distributing patches via geocache sounds awesome.

sixtofour• 15 years ago

"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." —Tanenbaum, Andrew S.

https://en.wikipedia.org/wiki/Sneakernet#In_media

eru• 15 years ago

The latency is the problem, not the bandwidth.

(By the way, considered as a means of transferring information sex has lots of bandwidth, too. Not, yet, useful for sharing patches, though.)

cygwin98• 15 years ago

Not to nitpick on the author. But 16KB was quite a bit memory in early 1970's.

ajross• 15 years ago

Indeed: 147456 (probably plus some for parity; not sure what the PDP-7 memory bus looked like) tiny little beads threaded onto tiny wires by human beings. That amount of memory in an SRAM array (almost a million transistors!) was unthinkable in a minicomputer, and DRAM had just been invented and was even more expensive than core.

Getahobby• 15 years ago

Ok. Awesome article. Even more awesome that I didn't have to click "next page" 12 times.

vorg2• 15 years ago

> By the mid-1970s, the environment of sharing that had sprung up around Unix resembled the open-source movement so prevalent today.

Not sure what percentage of today's open-source movement has an environment of sharing. Much of it is cathedrals in bazaar's clothing.

thwarted• 15 years ago

Code availability and development methodology are independent axes of sharing. One is sharing the output and the other is sharing responsibility.

Since you don't even need to even ask for the code for open source projects, it's there for the taking, the sharing is actually better than it was in the 1970s. Largely this has to do with the greater ease of communication and distribution. It's easier for me to share my code by putting it on github or providing a .tar.gz and forgetting about it, than it for me to have to cut a tape every time someone asks for it. In fact, when companies honor the letter of many open source licenses by only making their modified source available if you actually ask for it or assert your identity by filling out a web form, rather than putting it on a publicly accessible site somewhere, they are often chided for making the user have to jump through hoops to get the source (notwithstanding the companies that actually violate the license and don't make the source available via any means, of course).

That the development style of not directly/immediately incorporating various changes from other parties may be a more cathedral, rather than bazaar, but nothing is stopping the recipients of the code from forking it and distributing and sharing their own changes with each other. In fact, the very definition of open source is such that that is encouraged; that few do, or that people are not motivated to fork, has nothing to do with the culture of sharing the code, and, again, most likely has more to do with the ease of which it's possible to get the canonical version of the code and the branding behind the consistency of that canonical version.

I can bring a baseball bat I turned on my own lathe to the park and let other people use it, but just because I don't let someone else customize my bat or use my lathe doesn't mean I'm not sharing the bat.

vorg2• 15 years ago

> Code availability and development methodology are independent axes of sharing. One is sharing the output and the other is sharing responsibility.

They're different degrees of sharing, rather than independent axes. Sharing responsibility is a greater degree of sharing than sharing output because you generally don't have an open development process without shared source code.

My comment about "a cathedral in a bazaar's clothing" describes projects which start out as open process, but after a while become less and less open so they end up as open source only. The people taking them over keep up the appearance and terminology of the original open processes, but without the reality.

The Strange Birth and Long Life of Unix

Related Stories