4 ms·

I can confirm that the referenced article is chapter 6 in De Mol's and Primiero's book, which from my humble point of view is a typical Springer book, far a way

by Rochus 1y ago

I can confirm that the referenced article is chapter 6 in De Mol's and Primiero's book, which from my humble point of view is a typical Springer book, far a way in an ivory tower. May I ask in what respect you find the article/chapter "very good"? I rather think the author makes a fundamental category error (by comparing a complete operating system with kernel, system calls, process management, file systems, and userland utilities, with a programming language, runtime environment, and object library). Also the assumptions about Unix are wrong; Unix - in it's most incarnations - has a monolithic kernel architecture, a fixed system call interface, a rigid separation between kernel and user space, and (originally) static linking as the primary model. The "composable" aspects Kell emphasizes (pipes, small tools) exist at the userland level, not in the fundamental OS architecture. Further, Unix shared objects (.so files) and dynamic loading mechanisms predate widespread Smalltalk influence; the System V and BSD implementations of dynamic linking were driven by practical memory constraints, not Smalltalk inspiration. And every operating system is a "live system that can be modified while running" to some degree. The chapter reads more like an exercise in pattern matching than serious technical analysis. While academic exploration of conceptual relationships between systems can be valuable, it requires much more rigorous attention to technical details and historical accuracy than Kell provides.

igouy 1y ago
> Also the assumptions about Unix are wrong; Unix - in it's most incarnations … Perhaps the author has chosen to ignore "most incarnations" and instead select what fits his story: "In a traditional (pre-commercialisation) Unix system …" page 4 "When I write of “Unix” or “Smalltalk” in what follows, it will be important to distinguish their early, idealised conceptions from their later evolved forms …" page 6
- Rochus 1y ago
  Not even the "traditional (pre-commercialisation) Unix system" fits his story.
  - igouy 1y ago
    Free yourself from the chains of modernist narrative!
    - Rochus 1y ago
      God Speed!
rbanffy 1y ago
> I rather think the author makes a fundamental category error (by comparing a complete operating system with kernel, system calls, process management, file systems, and userland utilities, with a programming language, runtime environment, and object library) It compares the whole stack, from kernel to the user environment. You can run Smalltalk on bare metal, if you want. The separation between OS and the user environment is entirely an architectural decision. IMHO, Unix got it right, while ST and Plan 9 are too tied to their UIs. > And every operating system is a "live system that can be modified while running" to some degree. That's not the case at all with Unix and Plan 9 - you can't change the semantics of what a file is without recompiling the filesystem module and forcing a reload.
- igouy 1y ago
  Was there something specific that prompted you to say "a very good article"? (Just curious to know what appealed to you.)
- 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.

by Rochus 1y ago

igouy 1y ago

> Also the assumptions about Unix are wrong; Unix - in it's most incarnations … Perhaps the author has chosen to ignore "most incarnations" and instead select what fits his story: "In a traditional (pre-commercialisation) Unix system …" page 4 "When I write of “Unix” or “Smalltalk” in what follows, it will be important to distinguish their early, idealised conceptions from their later evolved forms …" page 6

Rochus 1y ago
Not even the "traditional (pre-commercialisation) Unix system" fits his story.
- igouy 1y ago
  Free yourself from the chains of modernist narrative!
  - Rochus 1y ago
    God Speed!

rbanffy 1y ago

> I rather think the author makes a fundamental category error (by comparing a complete operating system with kernel, system calls, process management, file systems, and userland utilities, with a programming language, runtime environment, and object library) It compares the whole stack, from kernel to the user environment. You can run Smalltalk on bare metal, if you want. The separation between OS and the user environment is entirely an architectural decision. IMHO, Unix got it right, while ST and Plan 9 are too tied to their UIs. > And every operating system is a "live system that can be modified while running" to some degree. That's not the case at all with Unix and Plan 9 - you can't change the semantics of what a file is without recompiling the filesystem module and forcing a reload.

igouy 1y ago
Was there something specific that prompted you to say "a very good article"? (Just curious to know what appealed to you.)
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.