Live data from Hacker News

1972 Unix V2 "Beta" Resurrected

tuhs.org

91–100 of 153 posts

Re: 1972 Unix V2 "Beta" Resurrected

#91
post #78
post #10

Earlier quoted context omitted.

There is LOADS of gray area, overlap, and room for one's own philosophical interpretation... But typically simulators attempt to reproduce the details of how a particular machine worked for academic or engineering purposes, while emulators are concerned mainly with only getting the desired output. (Everything else being an implementation detail.) E.g. since the MAME project considers itself living documentation of ar…

Not the case at all. Tons of emulators are near 100% accurate.

exactly. makes you wonder , is it all just philosophical.

Calling the same thing a different name.

Re: 1972 Unix V2 "Beta" Resurrected

#93
post #78
post #10

Earlier quoted context omitted.

There is LOADS of gray area, overlap, and room for one's own philosophical interpretation... But typically simulators attempt to reproduce the details of how a particular machine worked for academic or engineering purposes, while emulators are concerned mainly with only getting the desired output. (Everything else being an implementation detail.) E.g. since the MAME project considers itself living documentation of ar…

Not the case at all. Tons of emulators are near 100% accurate.

Irrelevant to the concept being expressed, and does not invalidate.

The goals merely overlap, which is obvious. Equally obviously, if two goals are similar, then the implimentations of some way to attain those goals may equally have some overlap, maybe even a lot of overlap. And yet the goals are different, and it is useful to have words that express aspects of things that aren't apparent from merely the final object.

A decorative brick and a structural brick may both be the same physical brick, yet if the goals are different then any similarity in the implimentation is just a coincidense. It would not be true to say that the definition of a decorative brick includes the materials and manufacturing steps and final physical properties of a structural brick. The definition of a decorative brick is to create a certain appearance, by any means you want, and it just so happens that maybe the simplest way to make a wall that looks like a brick wall, is to build an actual brick wall.

If only they had tried to make it clear that there is overlap and the definitions are grey and fuzzy and open to personal philosophic interpretation and the one thing can often look and smell and taste almost the same as the other thing, if only they had said anything at all about that, it might have headed off such a pointless confusion...

Re: 1972 Unix V2 "Beta" Resurrected

#94
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

Ken is definitely a top-notch programmer. A top-notch programmer can do a LOT given 3 weeks of focus time. I remember his wife took the kids to England so he was free to do whatever he wanted. And he definitely had a lot of experience before writing what was first version UNIX.

Every programmer that has a project in mind should try this: Put away 3 weeks of focus time in a cabin, away from work and family, gather every book or document you need and cut off the Internet. Use a dumb phone if you can live with it. See how far you can go. Just make sure it is something that you already put a lot of thoughts and a bit of code into it.

After thinking more thoroughly about the idea, I believe low level projects that rely on as few external libraries as possible are the best ones to try the idea out. If your project relies on piles of 3rd party libraries, you are stuck if you have an issue but without the Internet to help you figure it out. Ken picked the right project too.

Re: 1972 Unix V2 "Beta" Resurrected

#95
post #31

Earlier quoted context omitted.

The difference is about as crystal clear as compiler/interpreter.

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 ?

I assume GP meant that a lot of compilers also interpret and interpreters also compile.

For compilers, constant folding is a pretty obvious optimization. Instead of compiling constant expressions, like 1+2, to code that evaluates those expressions, the compiler can already evaluate it itself and just produce the final result, in this case 3.

Then, some language features require compilers to perform some interpretation, either explicitly like C++'s constexpr, or implicitly, like type checking.

Likewise, interpreters can do some compilation. You already mentioned bytecode. Producing the bytecode is a form of compilation. Incidentally, you can skip the bytecode and interpret a program by, for example, walking its abstract syntax tree.

Also, compilers don't necessarily create binaries that are immediately runnable. Java's compiler, for example, produces JVM bytecode, which requires a JVM to be run. And TypeScript's compiler outputs JavaScript.

Re: 1972 Unix V2 "Beta" Resurrected

#96

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 ?

I assume GP meant that a lot of compilers also interpret and interpreters also compile. For compilers, constant folding is a pretty obvious optimization. Instead of compiling constant expressions, like 1+2, to code that evaluates those expressions, the compiler can already evaluate it itself and just produce the final result, in this case 3. Then, some language features require compilers to perform some interpretatio…

Thank you!

Re: 1972 Unix V2 "Beta" Resurrected

#97
post #52

Earlier quoted context omitted.

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…

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

Re: 1972 Unix V2 "Beta" Resurrected

#98
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…

That's fine when it's self-motivated, but it sets a terrible precedent for expectations. Doing things like this can put in management's mind unrealistic expectations for you to always work at that pace. Which can be unhealthy and burnout-inducing.

Re: 1972 Unix V2 "Beta" Resurrected

#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.

Re: 1972 Unix V2 "Beta" Resurrected

#100
post #28

Earlier quoted context omitted.

The daves garage youtube has an episode where he documents the pitfalls of compiling 2bsd for a PDP-11/83. https://www.youtube.com/watch?v=IBFeM-sa2YY basically it is an art on a memory constrained system. What I found entertaining was when he was explaining how to compile the kernel, I went Oh! that's where openbsd gets it from. it is still a very similar process.

What’s the process look like?

On openbsd it's

    cd /sys/arch/$(machine)/conf
    cp GENERIC CUSTOM
    vi CUSTOM    # make your changes
    config CUSTOM
    cd ../compile/CUSTOM
    make
https://www.openbsd.org/faq/faq5.html

I have never done it for 2bsd but according to http://www.vaxman.de/publications/bsd211_inst.pdf

    cd /usr/src/sys/conf
    cp GENERIC CUSTOM
    vi CUSTOM
    ./config CUSTOM
    cd /sys/CUSTOM
    make
Post reply on HN