Earlier quoted context omitted.
We lost the environment where the whole OS was a debugger, and everything could be inspected and modified as the system was running.
Except, that’s what the browser is, and increasingly that’s where software lives.
What have we lost? [video]
21–30 of 86 posts
Re: What have we lost? [video]
#22Earlier quoted context omitted.
We lost the environment where the whole OS was a debugger, and everything could be inspected and modified as the system was running.
The linked video seems mostly about UI usage, and one rarely sees nice live action UI demos for machines that (mostly) no longer exist. They should do a sequel that shows these other very powerful system features you mention. One practical downside is that the live editing / code & continue / source code-free operation (mentioned in the Interlisp-D segment of the video) could lead to needing "just the right image" wi…
Had I had time, I would have patched the NFS code to run in "permissionless" mode, where it asks what creds are necessary to access a file, then just sends those creds. Hopefully somebody will be inspired to explore and blog about it though :-D
Re: What have we lost? [video]
#23Earlier quoted context omitted.
We lost the environment where the whole OS was a debugger, and everything could be inspected and modified as the system was running.
How does that work when you drop to the debugger in the middle of an interrupt handler? A page fault? A task switch? How does the privilege separation work for that environment? (mostly rhetorical questions)
As I understand it though, you don't have the concept of page faults at the image level; IIRC, Genera doesn't have any form of virtual memory, or if it does, it's all in microcode. Task switches are, iirc, handled in the image, but in the same way that it's done in Smalltalk: there's a function in the "kernel" to decide what task to switch to next, but the actual context switch is handled in microcode.
Also, there's no such thing as privilege separation; everything's running in a single address space and namespacing is handled using Common Lisp's package system.
Re: What have we lost? [video]
#24Re: What have we lost? [video]
#25Did we really “lose” the Lisp Machine, or did we just realize that compiling Lisp to a general-purpose instruction set like x86 and then having someone else in charge of creating hardware to efficiently execute that is much more clever?
We lost the environment where the whole OS was a debugger, and everything could be inspected and modified as the system was running.
You can't hide implementation from the User in such an environment; at least not to the degree you can with precompiled programs with debug symbols stripped. One requires you to infer function from raw assembly, the other, lets you step through areas of code that vendors want to keep out of the reach of user understanding.
90% of established security practices around code delivery are around keeping your product from being too easily reversed or "owned" by those who use it.
Thus the popularity of -as-a-Service business models. You can't invoice for something a user just uses.
Re: What have we lost? [video]
#26Earlier quoted context omitted.
We lost the environment where the whole OS was a debugger, and everything could be inspected and modified as the system was running.
Well, did we? You can still do that! Those environments were extremely primitive and it doesn't take much work to match or vastly exceed their capabilities. This is so much the case we often don't even recognize such environments staring us in the face. Consider another story on the HN front page right now: IntelliJ 2021 is out. Load IntelliJ and you have something that which can be arbitrarily scripted, altered and…
Adding plugins without restarts in IDEA is a feature that's only a couple of months old now, and even then, making your own plugin is a very involved process. You can't just copy a single function into your own code, modify it, load it, and be done. In genera, that would take 1-5 minutes; quick enough that if something bothers you, you don't really need to think about whether it's worth taking the time to fix it. By the time you've done a cost/benefit analysis, you'd have been done with the fix.
Re: What have we lost? [video]
#27Smalltalk Pharo is like these OS: an environment where everything is an object that you can inspect, modify, duplicate, ... Here a demo with a minesweeper clone i once made to discover Pharo: https://files.catbox.moe/jggff7.webm It was really amazing but i didn't went further than that; Using Pharo quickly felt like being on a secluded island. More about Pharo: https://pharo.org/features
Re: What have we lost? [video]
#28Did we really “lose” the Lisp Machine, or did we just realize that compiling Lisp to a general-purpose instruction set like x86 and then having someone else in charge of creating hardware to efficiently execute that is much more clever?
We lost the environment where the whole OS was a debugger, and everything could be inspected and modified as the system was running.
Re: What have we lost? [video]
#29Did we really “lose” the Lisp Machine, or did we just realize that compiling Lisp to a general-purpose instruction set like x86 and then having someone else in charge of creating hardware to efficiently execute that is much more clever?
Fitting Lisp in a stack based machine (or vice-versa) is mostly a compromise, not exactly a "realisation" of a "clever" method, because Lisp makes extensive use of list appends/concats, environments and garbage collection, which are not an easy fit for heap/stack C abstractions.