3 ms·

> You can run Smalltalk on bare metal, if you want. Yes, if you provide the kernel, which implements all madatory primitives (i.e. system calls) required by th

by Rochus 1y ago

> You can run Smalltalk on bare metal, if you want. Yes, if you provide the kernel, which implements all madatory primitives (i.e. system calls) required by the Smalltalk code to work. In the early Alto days, these were implemented in Alto microcode. The characterization of Smalltalk as "running on bare metal" oversimplifies the actual system architecture. In reality, the microcode implementation of the VM served as the effective operating system kernel; this microcode layer handled essential system functions including drive access and display buffer management; Smalltalk ran on top of this microcode layer, not directly on the hardware. Smalltalk is essentially the userland of an operating system, if we compare it to Unix; it's a more primitive system compared to Unix though, since the "kernel" only has one process, no process manager with isolated processes and memory separation. I implemented some tools with which this can be easily studied (https://github.com/rochus-keller/Smalltalk/ https://github.com/rochus-keller/Smalltalk/). > you can't change the semantics of what a file is without recompiling the filesystem module and forcing a reload Linux e.g. supports kernel modules which are loadable/replacable at runtime. And if you include the userland in the comparison (as the article does) there is nothing static at all. You can even run the Smalltalk VM (or any other dynamic language) in a Unix userland and have exactly the same modifiability as the article claims for Smalltalk. And a similar effect as claimed in the article can actually be achieved if you compile, run, modify and the run again a C program.

rbanffy 1y ago
> which implements all madatory primitives (i.e. system calls) Essentially, it's a collection of device drivers. > I implemented some tools with which this can be easily studied Really cool. I'll check it out. > You can even run the Smalltalk VM (or any other dynamic language) in a Unix userland and have exactly the same modifiability That's kind of cheating. All the dynamic behavior is on the Smalltalk side, and nothing of it is on the Linux side. Apart from loadable modules, Linux doesn't change behavior at runtime (IIRC, you can't swap process schedulers after startup).
- Rochus 1y ago
  > Essentially, it's a collection of device drivers. Plus memory management, interrupt handling, and some other stuff, everything you would expect from a single-tasking kernel. > and nothing of it is on the Linux side You likely mean the kernel. There is more to Linux/Unix than just the kernel. You can even have your dynamically modifiable scheduler in the userland if you want. And for the (few) people who really think full dynamic modifiability is a relevant requirement, there are also some other technologies which offer similar flexibility as Smalltalk, or somewhere between (as e.g. the Gnome Window manager with GTK operated via a scripting language, or Stump, Sawfish, Qtile, etc.). The kernel which runs below Smalltalk (or the Smalltalk interpreter, i.e. the thing which runs the Smalltalk bytecode and manages object memory) neither "change behaviour at runtime". So if we do the correct comparision, there is not much difference when it comes to runtime modifiability.
  - igouy 1y ago
    > the thing which runs the Smalltalk bytecode VM ? "There are about one hundred primitive methods that the Smalltalk-80 virtual machine knows how to perform."
    - Rochus 1y ago
      The VM includes a bytecode interpreter and some other functions; its implementation cannot be changed during runtime.

by Rochus 1y ago

rbanffy 1y ago

> which implements all madatory primitives (i.e. system calls) Essentially, it's a collection of device drivers. > I implemented some tools with which this can be easily studied Really cool. I'll check it out. > You can even run the Smalltalk VM (or any other dynamic language) in a Unix userland and have exactly the same modifiability That's kind of cheating. All the dynamic behavior is on the Smalltalk side, and nothing of it is on the Linux side. Apart from loadable modules, Linux doesn't change behavior at runtime (IIRC, you can't swap process schedulers after startup).

Rochus 1y ago
> Essentially, it's a collection of device drivers. Plus memory management, interrupt handling, and some other stuff, everything you would expect from a single-tasking kernel. > and nothing of it is on the Linux side You likely mean the kernel. There is more to Linux/Unix than just the kernel. You can even have your dynamically modifiable scheduler in the userland if you want. And for the (few) people who really think full dynamic modifiability is a relevant requirement, there are also some other technologies which offer similar flexibility as Smalltalk, or somewhere between (as e.g. the Gnome Window manager with GTK operated via a scripting language, or Stump, Sawfish, Qtile, etc.). The kernel which runs below Smalltalk (or the Smalltalk interpreter, i.e. the thing which runs the Smalltalk bytecode and manages object memory) neither "change behaviour at runtime". So if we do the correct comparision, there is not much difference when it comes to runtime modifiability.
- igouy 1y ago
  > the thing which runs the Smalltalk bytecode VM ? "There are about one hundred primitive methods that the Smalltalk-80 virtual machine knows how to perform."
  - Rochus 1y ago
    The VM includes a bytecode interpreter and some other functions; its implementation cannot be changed during runtime.