Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1972 Unix V2 "Beta" Resurrected

tuhs.org

Post reply on HN
Print view View original

111–120 of 153 posts

Re: 1972 Unix V2 "Beta" Resurrected

#111

Post by markus_zhang »

richardlblair wrote: post #109
markus_zhang wrote: post #102

Earlier quoted context omitted.

I'd argue that ordinary programmers can perform the same *type* of exercises if they: - Put away a few weeks and go into Hermit mode; - Plan ahead what projects they have in mind, which books/documents to bring with them. Do enough research and a bit of experimental coding beforehand; - Reduce distraction to minimum. No Internet. Dumb phone only. Bring a Garmin GPS if needed. No calls from family members; I wouldn't…

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.

Re: 1972 Unix V2 "Beta" Resurrected

#112

Post by wpollock »

skissane wrote: post #51
wpollock wrote: post #17

Earlier quoted context omitted.

I remember using an ed-like editor on a Honeywell timeshare system in the 1960s, over a Teltype ASR-33. I don't remember much except you invoked it using "make " to create a new file. And if you typed "make love" the editor would print "not war" before entering the editor.

The “MAKE LOVE”/“NOT WAR” easter egg was in TECO for DEC PDP-6/10 machines. But DEC TECO was also ported to Multics, so maybe that was the Honeywell machine you used it on. But, for a whole bunch of reasons, I’m left with the suspicion you may be misremembering something from the early 1970s as happening in the 1960s. While it isn’t totally impossible you had this experience in 1968 or 1969, a 1970s date would be muc…

You're probably right. It definitely was teco and likely 1970ish.

Re: 1972 Unix V2 "Beta" Resurrected

#113

Post by amszmidt »

Imustaskforhelp wrote: post #89
codr7 wrote: 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 ?

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.

Re: 1972 Unix V2 "Beta" Resurrected

#114

Post by somat »

Imustaskforhelp wrote: post #89
codr7 wrote: 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 would generalize it to a compiler produces some sort of artifact that is intended to later be used directly, while for an interpreter the whole mechanism(source to execution) is intended to be used directly.

The same tool can often be used to do both. trival example: a web browser. save your web page as a pdf? compiler. otherwise interpreter. but what if the code it is executing is not artisanal handcrafted js but the result of a typescript compiler?

Re: 1972 Unix V2 "Beta" Resurrected

#115

Post by amszmidt »

dpassens wrote: post #95
Imustaskforhelp wrote: post #89

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…

While an interpreter can do optimizations, they do not produce "byte code" -- by that time they are compilers!

As for the comparison with the JVM .. compare to a compiler that produces x86 code, it cannot be run without an x86 machine. You need a machine to run something, be it virtual or not.

Re: 1972 Unix V2 "Beta" Resurrected

#116

Post by amszmidt »

Imustaskforhelp wrote: post #107
dpassens wrote: post #95

Earlier quoted context omitted.

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…

Then what is the difference, I always thought of Java as closer to python in the sense that it's running the byte code. And python also has bytecode. I don't know what the difference is , I know there can be intepreters of compilers but generally speaking it's hard to find compilers of intepreters Eg C++ has compilers , intepreters both (cpi) , gcc Js doesn't have compilers IIRC , it can have transpilers Js2c is good…

The easy definition is that an interpreter takes somethings and runs/executes it.

A compiler takes the same thing, but produces an intermediate form (byte code, machine code, another languages sometimes called "transpilar"). That you can then pass through an interpreter of sorts.

There is no difference between Java and JVM, and Python and the Python Virtual Machine, or even a C compiler targeting x86 and a x86 CPU. One might call some byte code, and the other machine code .. they do the same thing.

Re: 1972 Unix V2 "Beta" Resurrected

#117

Post by o11c »

Imustaskforhelp wrote: post #107
dpassens wrote: post #95

Earlier quoted context omitted.

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…

Then what is the difference, I always thought of Java as closer to python in the sense that it's running the byte code. And python also has bytecode. I don't know what the difference is , I know there can be intepreters of compilers but generally speaking it's hard to find compilers of intepreters Eg C++ has compilers , intepreters both (cpi) , gcc Js doesn't have compilers IIRC , it can have transpilers Js2c is good…

Programming languages mostly occupy a 4-dimensional space at runtime. These axes are actually a bit more complicated than just a line:

* The first axis is static vs dynamic types. Java is mostly statically-typed (though casting remains common and generics have some awkward spots); Python is entirely dynamically-typed at runtime (external static type-checkers do not affect this).

* The second axis is AOT vs JIT. Java has two phases - a trivial AOT bytecode compilation, then an incredibly advanced non-cached runtime native JIT (as opposed to the shitty tracing JIT that dynamically-typed languages have to settle for); Python traditionally has an automatically-cached barely-AOT bytecode compiler but nothing else (it has been making steps toward runtime JIT stuff, but poor decisions elsewhere limit the effectiveness).

* The third axis is indirect vs inlined objects. Java and Python both force all objects to be indirect, though they differ in terms of primitives. Java has been trying to add support for value types for decades, but the implementation is badly designed; this is one place where C# is a clear winner. Java can sometimes inline stack-local objects though.

* The fourth axis is deterministic memory management vs garbage collection. Java and Python both have GC, though in practice Python is semi-deterministic, and the language has a somewhat easier way to make it more deterministic (`with`, though it is subject to unfixable race conditions)

I have collected a bunch more information about language implementation theory: https://gist.github.com/o11c/6b08643335388bbab0228db763f9921...

Re: 1972 Unix V2 "Beta" Resurrected

#118

Post by amszmidt »

haunter wrote: post #7
snovymgodym wrote: post #3

Earlier quoted context omitted.

https://opensimh.org/ Works great on Apple Silicon

What’s the difference between an emulator and a simulator in this context?

I think it is more about design, emulation mimics what something does. A simulator replicates what something does.

It is a tiny distinction, but generally I'd say that a simulator tries to accurately replicate what happens on an electrical level as good one can do.

While an emulator just does things as a black box ... input produces the expected output using whatever.

You could compare it to that an accurate simulator of a 74181 tries to do it by using AND/OR/NOT/... logic, but an emulator does it using "normal code".

In HDL you have a similar situation between structural, behavioral design ... structural is generally based on much more lower level logic (eg., AND/NOR/.. gates ...), and behavioral on higher logic (addition, subtraction ...).

"100%" accuracy can be achieved with both methods.

Re: 1972 Unix V2 "Beta" Resurrected

#119

Post by Postosuchus »

b0in wrote: post #69
JeffTickle wrote: post #65

Can anyone provide a reference on what those file permissions mean? I can make a guess but when I searched around, could not find anything about unix v2 permissions. ls output looks so familiar, except for the sdrwrw!

Someone in the mailing list thread linked the man pages that they were able to extract out https://gitlab.com/segaloco/v1man/-/blob/master/man1/stat.1?... for sdrwrw: - column 1 is s or l meaning small or large - column 2 is d, x, u, -; meaning directory, executable, setuid, or nothing. - the rest are read-write bits for owner and non-owner.

Pretty interesting. I guess it was way later, when they came up with the SUID semantics and appropriated the first character for symlinks (l) or setuid binaries (s)...

Re: 1972 Unix V2 "Beta" Resurrected

#120

Post by hylaride »

noisy_boy wrote: post #70
xattt wrote: 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?

Genius level mind minus scrum/agile nonsense can help.

Impossible! How can the product managers maintain control without the bureaucracy? /s
Post reply on HN