4 ms·

It was a one-true-language, one-user, no-process-isolation, whole-machine IDE pretending to be an OS. With all the implied advantages and disadvantages. It woul

It was a one-true-language, one-user, no-process-isolation, whole-machine IDE pretending to be an OS. With all the implied advantages and disadvantages. It would have been a nightmare on the modern internet. Root it and you could rewrite anything.

regularfry 17y ago
You could make a similar argument about DOS. Which is a shame. EDIT: Except for the whole-machine-IDE thing, obviously. Although if you wanted to hand-hack assembler, you could, as far as I remember.
- blasdel 17y ago
  What Assembler? It didn't come with one, and what do you need mnemonics for anyway? You programmed in the absolute using the alt-numpad method to input arbitrary bytes, at least to bootstrap yourself.
  - klipt 17y ago
    http://en.wikipedia.org/wiki/Debug_%28command%29 http://en.wikipedia.org/wiki/Debug_%28command%29
    - regularfry 17y ago
      Yep, that's what I was trying to remember.
Hexstream 17y ago
I don't think all these cool features require the system to be "one-true-language, one-user, no-process-isolation". Besides, when you're rooted it's game over anyway.
- angelbob 17y ago
  It's harder for your debug environment to take apart and show the details of every object down to the OS/hardware level if you've got security to prevent it, and harder yet if it doesn't have a very good idea of the specifics of the binary representation. We'd see this problem a lot with calling conventions (C-style vs Pascal-style vs pretty much any weird thing you found a reason to do) if our gdb-based debuggers tried harder to figure out what was going on. Luckily, they rarely really bother and are wrong constant anyway about things like optimization -- they're built to do fairly little and live in constant confusion, so we don't get that problem. And for the record, I like gdb and company. But every so often I get a wet dream about being able to have a debugger that could show me useful representations of objects and what they do. Things are better in Ruby-land, but still not actually, like, good.
cpr 17y ago
Sure, but look at the MIT AI Lab environment from whence it sprang: their PDP-10's ran ITS (the Incompatible Time Sharing system, a jab at the IBM 7090-based Compatible Time Sharing System, CTSS), which was a completely open system. Anyone could create an account, and anyone could bring down the system with a few keystrokes (the terminal interface was an extended DDT, a single-keystroke-command-style debugger), and anyone could delete any file, including system files. They had a radical open system, and defended it (yes, it was early in the life of the ARPAnet/Internet) with great backups and social pressure. The LispMs were not much different.
- j_baker 17y ago
  I don't think that would make sense nowadays. Great backups are good to have, but they aren't a panacea. And I could just imagine how social pressure would work: "Hey guys, please don't exploit this bug in my webserver that will make it reformat the hard drive"

regularfry 17y ago

You could make a similar argument about DOS. Which is a shame. EDIT: Except for the whole-machine-IDE thing, obviously. Although if you wanted to hand-hack assembler, you could, as far as I remember.

blasdel 17y ago
What Assembler? It didn't come with one, and what do you need mnemonics for anyway? You programmed in the absolute using the alt-numpad method to input arbitrary bytes, at least to bootstrap yourself.
- klipt 17y ago
  http://en.wikipedia.org/wiki/Debug_%28command%29 http://en.wikipedia.org/wiki/Debug_%28command%29
  - regularfry 17y ago
    Yep, that's what I was trying to remember.

Hexstream 17y ago

I don't think all these cool features require the system to be "one-true-language, one-user, no-process-isolation". Besides, when you're rooted it's game over anyway.

angelbob 17y ago
It's harder for your debug environment to take apart and show the details of every object down to the OS/hardware level if you've got security to prevent it, and harder yet if it doesn't have a very good idea of the specifics of the binary representation. We'd see this problem a lot with calling conventions (C-style vs Pascal-style vs pretty much any weird thing you found a reason to do) if our gdb-based debuggers tried harder to figure out what was going on. Luckily, they rarely really bother and are wrong constant anyway about things like optimization -- they're built to do fairly little and live in constant confusion, so we don't get that problem. And for the record, I like gdb and company. But every so often I get a wet dream about being able to have a debugger that could show me useful representations of objects and what they do. Things are better in Ruby-land, but still not actually, like, good.

cpr 17y ago

Sure, but look at the MIT AI Lab environment from whence it sprang: their PDP-10's ran ITS (the Incompatible Time Sharing system, a jab at the IBM 7090-based Compatible Time Sharing System, CTSS), which was a completely open system. Anyone could create an account, and anyone could bring down the system with a few keystrokes (the terminal interface was an extended DDT, a single-keystroke-command-style debugger), and anyone could delete any file, including system files. They had a radical open system, and defended it (yes, it was early in the life of the ARPAnet/Internet) with great backups and social pressure. The LispMs were not much different.

j_baker 17y ago
I don't think that would make sense nowadays. Great backups are good to have, but they aren't a panacea. And I could just imagine how social pressure would work: "Hey guys, please don't exploit this bug in my webserver that will make it reformat the hard drive"