its VS notes

Compile ITS and just run :macsyma at the DDT prompt (shell/debugger) from ITS:

https://github.com/pdp-10/its

The syntax it's the same, I even made a plot and 'printed' into the host from an ARDS output from the plot command, by converting the file into PPM->PNG or PPM->PDF.

ITS didn't really have password control, one was technically added but IIRC it was a fig leaf on some requirement from outside MIT. The user accounts were there mostly to inform others who was logged on and who owned what process.

You could login either using terminal through ARPAnet dial-in support, or later over network, and over time there was added a more concrete "tourist" policy.

DonHopkins seems to have an interesting writeup https://donhopkins.medium.com/mit-ai-lab-tourist-policy-f73b...

and of course there's PDP-10 org and its gather docs on github: https://github.com/PDP-10/its

Terry and SHRDLU at 8:23 here: https://archive.org/details/what-about-tomorrow-on-the-side-...

See this for some more information: https://github.com/PDP-10/its/issues/425#issuecomment-145588...

The Magic Switch (in reference to the More Magic, above)

Oops, URL should be https://github.com/PDP-10/its/pull/2150

For more info, see https://github.com/PDP-10/its/pull/2150

It's (partially) a fundamental problem with Python and most other programming languages. The majority of libraries don't need more authority than doing (some) computation, yet any Python script can access anything and everything by default.

https://en.wikipedia.org/wiki/Capability-based_security is the solution for this, yet Python will probably never be capable of this kind of internal encapsulation, it's too much of a fundamental change - and even if some sort of sandboxing ability is accomplished, creating separate/recursive sandboxes (needed when importing more, separate libraries) will probably require another interpreter instance (as with WebAssembly).

I hope current and future language designers will take this into account, and construct their compilers, virtual machines and interpreters accordingly. Python was created before the internet as we know it now existed, so perhaps its lack of security mechanisms shouldn't be surprising. But it and any new developments that fail to consider this aspect of computation will be fundamentally flawed from the beginning.

https://github.com/void4/notes/issues/41

Not if done correctly. Have a look at this link: https://github.com/void4/notes/issues/41

There is no issue with just limiting resources (unless there is unpredictable overhead). It doesn't have to be hardware resources either, it could be abstract/higher level resources like interpreter steps or managed memory slices.

I'm creating a series of VMs to show that this is possible, like rarVM, the recursively sandboxable virtual machine: https://esolangs.org/wiki/RarVM

Showcase: https://www.youtube.com/watch?v=MBymOp6bTII

When calling a function you can specify how many interpreter steps it can run until it aborts (and optionally gives you a continuation so you can "refill" and resume it later).

Stackless Python can do this too, but unfortunately due to the reasons discussed above will never be a safe language, this specific mechanism works only in trusted environments since the called function has the ambient authority to increase its own resource limits: https://stackless.readthedocs.io/en/2.7-slp/library/stackles...

Another approach would be to have a counter (or several) that limit the number of instruction steps, like the Stackless Python programming language (https://stackless.readthedocs.io/en/latest/library/stackless...) or the KeyKOS operating system (https://github.com/void4/notes/issues/41) did

Ann Hardy programmed one of the first mainframe operating systems, and certainly the most secure one: KeyKOS

There are syntactic and semantic aspects. Personally, I think algebraic effect systems and capability security seem to be very worthwhile areas of research because they provide abilities and guarantees that just aren't possible with currently popular languages due to their architecture.

This might be of interest to you: "Why KeyKOS is fascinating" - https://github.com/void4/notes/issues/41