Live data from Hacker News

1972 Unix V2 "Beta" Resurrected

tuhs.org

121–130 of 153 posts

Re: 1972 Unix V2 "Beta" Resurrected

#121

Earlier quoted context omitted.

I also think people under estimate how much pondering one does before starting a project.

I think so. I don't think Ken had zero thought about UNIX and then suddenly came up with a minimum but complete solution in under 3 weeks. Previous experience also tells a lot too. Wozniak was able to quickly design some electronics, but he probably already bagged 10,000 hours (just to borrow the popular metaphor) before he joined HP.

They both had been working on the Multics project for Bell Labs before they pulled out of the project and had written several languages already.

While some ideas like hierarchical filesystems were new it was mainly a modernized version of CTSS according to Dennis Ritchie's paper "The UNIX Time-sharing SystemA Retrospective"

I was playing with this version on simh way too late last night, taking a break from ITS, and being very familiar with v7 2.11 etc.. It is quite clearly very cut down.

I think being written in Assembly, which they produced by copying the DEC PAL-11R helped a lot.

If you look through the v1 here:

https://www.tuhs.org/Archive/Distributions/Research/Dennis_v...

It is already very modular, and obviously helped by dmr's MIT work:

https://people.csail.mit.edu/meyer/meyer-ritchie.pdf

But yet...work for years making an ultra complex OS that intended to provide 'utility scale' compute, and writing a fairly simple OS for a tiny mini would be much easier....if not so for us mortals.

It isn't like they just came out of a code boot camp...they needed the tacit knowledge and experience to push out 100K+ lines in one year from two people over 300bps terminals etc...

Re: 1972 Unix V2 "Beta" Resurrected

#122
post #99
post #47

I once saw a talk from Brian Kernighan who made a joke about how in three weeks Ken Thompson wrote a text editor, the B compiler, and the skeleton for managing input/output files, which turned out to be UNIX. The joke was that nowadays we're a bit less efficient :-D

I’ve heard that Torvalds build Git in 5 (or 10) days and that Brendan Eich created JavaScript in 10 days. Maybe the average programmer is less efficient, but the distribution is probably heavily skewed these days.

Brendan Eich would say "10 days" whenever one of the big warts from the that are unfixable came up.

Re: 1972 Unix V2 "Beta" Resurrected

#123
post #104
post #99

Earlier quoted context omitted.

I’ve heard that Torvalds build Git in 5 (or 10) days and that Brendan Eich created JavaScript in 10 days. Maybe the average programmer is less efficient, but the distribution is probably heavily skewed these days.

> I’ve heard that Torvalds build Git in 5 days And it shows. I am joking of course, git is pretty great, well half-joking, what is it about linux that it attracts such terrible interfaces. git vs hg, iptables vs pf. there is a lot of technical excellence present, marred by a substandard interface.

That's why Magit exists

Re: 1972 Unix V2 "Beta" Resurrected

#124
post #68

Earlier quoted context omitted.

I’m wondering what the process was for the early UNIX developers to attain this level of productivity. Did they treat this as a 9-5 effort, or did they go into a “goblin mode” just to get it done while neglecting other aspects of their lives?

Back in my early career, the company I worked for needed an inventory system tailored to their unique process flow. Such system was already in development and was scheduled to launch "soon". A few months went by and I got fed up with the toil. Sat down one weekend and implemented the whole thing in Django. I'm no genius and I managed to have a solution that my team used for a few years until the company had theirs la…

I worked at a place in love with their ERP system. Some there had been using it 30+ years, since it ran in DOS.

My Excel skills completely blow, and I hate Microsoft with a passion, but I created a shared spreadsheet one long Saturday afternoon that had more functionality than our $80K annual ERP system. Showed it to a few more open-minded employees, then moved it to my server, never to be shown again. Just wanted to prove when I said the ERP system was pointless, that I was right.

Re: 1972 Unix V2 "Beta" Resurrected

#125
post #52

Earlier quoted context omitted.

Otoh: I got react to run my tests without any warnings today.

If I write a bunch of tests for new code, and all of them pass on the first attempt, I'm immediately suspicious of a far more egregious bug hiding somewhere…

"never trust a test you've never seen fail." has kept me honest on more than one occasion.

Re: 1972 Unix V2 "Beta" Resurrected

#126
post #106
post #68

Earlier quoted context omitted.

I’m wondering what the process was for the early UNIX developers to attain this level of productivity. Did they treat this as a 9-5 effort, or did they go into a “goblin mode” just to get it done while neglecting other aspects of their lives?

A big one is the lack of peer reviews and processes, including team meetings, that would slow them down. No PM, no UX, just yourself and the keyboard with some goals in mind. No OKRs or tickets to close. It's a bit like any early industry, from cars to airplanes to trains. Earlier models were made by a select few people, and there was several versions until today where GM and Ford have thousands of people involved in…

IMHO the biggest thing is that they were their own customer. There was no requirements gathering, ui/ux consultation, third party bug reporting, just like you said. They were eating their own dogfood and loving it. No overhead meant they could focus entirely on the task at hand.

Re: 1972 Unix V2 "Beta" Resurrected

#127

Earlier quoted context omitted.

I think so. I don't think Ken had zero thought about UNIX and then suddenly came up with a minimum but complete solution in under 3 weeks. Previous experience also tells a lot too. Wozniak was able to quickly design some electronics, but he probably already bagged 10,000 hours (just to borrow the popular metaphor) before he joined HP.

They both had been working on the Multics project for Bell Labs before they pulled out of the project and had written several languages already. While some ideas like hierarchical filesystems were new it was mainly a modernized version of CTSS according to Dennis Ritchie's paper "The UNIX Time-sharing SystemA Retrospective" I was playing with this version on simh way too late last night, taking a break from ITS, and…

Yeah. They were pretty professional by then :D

Re: 1972 Unix V2 "Beta" Resurrected

#128

Earlier quoted context omitted.

Where feasible, I like to start a suite with a unit test that validates the unit's intended side effects actually occur, as visible in their mocks being exercised.

I laughed. Thank you for that

Sure. For Patreon subscribers at the $5/month tier and up, I also have a course on making integration ("e2e", "functional") tests more maintainable by eliminating side effects.

Re: 1972 Unix V2 "Beta" Resurrected

#129

Earlier quoted context omitted.

compiler creates a binary in elf format or other format which can be run given a shared object exists. Intepreter either writes it in bytecode and then executes the bytecode line by line ? Atleast that is what I believe the difference is , care to elaborate , is there some hidden joke of compiler vs intepreter that I don't know about ?

An interpreter runs the code as it is being read in. A compiler processes the code and provides an intermediate result which is then "interpreted" by the machine. So to take the "writes it in byte code" -- that is a compiler. "executes the byte code" -- is the interpreter. If byte code is "machine code" or not, is really secondary.

Then isn't theoretically all languages assembly intepreters in the endd

Re: 1972 Unix V2 "Beta" Resurrected

#130
post #110
post #66

Earlier quoted context omitted.

That's possible but unlikely. MTP as defined by Suzanne Sluizer and Jon Postel in RFC 772 in September 01980 https://datatracker.ietf.org/doc/html/rfc772 seems to have been where SMTP got that convention for ending the message: > ...and considers all succeeding lines to be the message text. It is terminated by a line containing only a period, upon which a 250 completion reply is returned. But in 01980 Unix had only b…

The "." to terminate input was used in FTP mail on ARPANET, defined in RFC 385 which was well before anyone outside Bell had heard of Unix.

Oh wow, really? I didn't look because I assumed mail over FTP was transferred over a separate data connection, just like other files. Thank you!

And yes, in August 01972 probably nobody at MIT had ever used ed(1) at Bell Labs. Not impossible, but unlikely; in June, Ritchie had written, "[T]he number of UNIX installations has grown to 10, with more expected." But nothing about it had been published outside Bell Labs.

The rationale is interesting:

> The 'MLFL' command for network mail, though a useful and essential addition to the FTP command repertoire, does not allow TIP users to send mail conveniently without using third hosts. It would be more convenient for TIP users to send mail over the TELNET connection instead of the data connection as provided by the 'MLFL' command.

So that's why they added the MAIL command to FTP, later moved to MTP and then in SMTP split into MAIL, RCPT, and DATA, which still retains the terminating "CRLF.CRLF".

https://gunkies.org/wiki/Terminal_Interface_Processor explains:

> A Terminal Interface Processor (TIP, for short) was a customized IMP variant added to the ARPANET not too long after it was initially deployed. In addition to all the usual IMP functionality (including connection of host computers to the ARPANET), they also provided groups of serial lines to which could be attached terminals, which allowed users at the terminals access to the hosts attached to the ARPANET.

> They were built on Honeywell 316 minicomputers, a later and un-ruggedized variant of the Honeywell 516 minicomputers used in the original IMPs. They used the TELNET protocol, running on top of NCP.

Post reply on HN