6 ms·

I guess we should have been listening to Terry all of this time!

throwaway7645 9y ago
I really wish I could do a good bit of my work on his OS. I'd much rather a Kawasaki than an aircraft carrier that is half sinking. Charles Moore of Forth fame has an amazing interview where he argues that the OS is really not necessary on modern hardware. Of course this man built his own language, CAD software, and chips...some of which are in outer space. Impressive man.
- olewhalehunter 9y ago
  Chuck and Terry's work prove that most kernels are just really terrible compiler systems
- ioddly 9y ago
  Where is Chuck Moore now? He used to write a blog that was sometimes quite educational.
  - fish_fan 9y ago
    I believe he's still with GreenArrays.
    - throwaway7645 9y ago
      He retired a week ago apparently.
  - Jtsummers 9y ago
    https://groups.google.com/forum/#!original/comp.lang.forth/LmthCiZ4Cjk/f-e03GHXAQAJ https://groups.google.com/forum/#!original/comp.lang.forth/L... Per this, he's retired now.
- noblethrasher 9y ago
  I don't suppose you have a link to the Chuck Moore interview; I would love to take a look at it. (Alan Kay and co. also argued that point.)
  - throwaway7645 9y ago
    http://www.ultratechnology.com/moore4th.htm http://www.ultratechnology.com/moore4th.htm https://www.red-gate.com/simple-talk/opinion/geek-of-the-week/chuck-moore-on-the-lost-art-of-keeping-it-simple/ https://www.red-gate.com/simple-talk/opinion/geek-of-the-wee... The first one has where he mentions the OS. Personally, I do think the OS is needed, but not in its present form. Instead, something far far simpler than even Linux. Yes, I've seen Alan Kay's similar presentation on the amount of code in windows and the F-22 raptor. Stacked it is supposedly unbelievably high like many stories, while their Smalltalk Machine built at Xerox had the entire language, GUI, text editor, image programs...etc in a tiny amount of code. In the modern day I think of Rebol which has a very powerful and simple DSL for so many tasks such as creating GUIs and the full download is like a few MB with zero install. Truly a marvelous piece of software.
    - mwcampbell 9y ago
      > the entire language, GUI, text editor, image programs...etc in a tiny amount of code But it wasn't internationalized, accessible to people with various disabilities (e.g. blind people via a screen reader), automatically installing updates over the network, encrypting all communication over the network (as in TLS today), etc. No doubt some bloat comes from accumulated incidental complexity. But to some extent (I don't know how much), one person's bloat is another person's essential features. For example, if you tell me about some bloat-free GUI toolkit that draws its own widgets (as opposed to a wrapper over multiple platform native toolkits), my immediate reaction will be "What about accessibility?".
      - mpweiher 9y ago
        [missing features] Well, MS Office, for example, is around 20000x the code of early Smalltalk "Personal Computing" systems. Let's assume that that core code covers only 1% of the features, so you'd need 100x more code to implement all of them. I think this is being very generous, but let's stick with it. That would mean you still have a factor 200 unaccounted for. In other words, even when being very generous, we still haven't accounted for 99.5% of the code.
wolfgke 9y ago
Terry A. Davis' TempleOS does not run in real mode, but in 64 bit mode (long mode) in ring 0.
- TomMarius 9y ago
  I think what he really meant was real >time<.
  - wolfgke 9y ago
    > I think what he really meant was real >time<. On "normal" x86 processors (say: the CPU that will be inside your PC/laptop if you buy one) it is really hard (I don't want to claim "impossible", but at least really hard) to do real-time stuff. Intel knows that and this is also among the reasons why they released their Intel Quark SoC/micro controller, which is perfectly suitable for real-time stuff. Why is this the case? One obvious reason is that the caches (D$, I$, micro op cache etc.) und the pipeline stages (EDIT: including out-of-order execution) make it really hard to predict/prove/test strict upper bounds on the performance of some code fragment on "normal" x86 processors. Another also well-known "issue" is that many modern x86 clock up or down depending on core temperate (I think this behavior can at least partly controlled by the firmware (UEFI)). But there is a much more subtle reason, too: It is SMM (system management mode): https://en.wikipedia.org/w/index.php?title=System_Management_Mode&oldid=780439819 https://en.wikipedia.org/w/index.php?title=System_Management... For backward compatibility a lot of legacy functions are implemented via SMM calls such as emulating a PS/2 mouse/keyboard (while really a USB mouse/keyboard is connected). As long as you cannot guarantee that the code of your OS will not trigger such a function that is emulated via SMM, it is very hard to ensure real-time guarantees. EDIT: To quote directly from the Wikipedia article: "Operations in SMM take CPU time away from the applications, operating system kernel and hypervisor, with the effects magnified for multicore processors since each SMI causes all cores to switch modes. There is also some overhead involved with switching in and out of SMM, since the CPU state must be stored to memory (SMRAM) and any write-back caches must be flushed. This can destroy real-time behavior and cause clock ticks to get lost. The Windows and Linux kernels define an ‘SMI Timeout’ setting a period within which SMM handlers must return control to the operating system or it will ‘hang’ or ‘crash’. The SMM may disrupt the behavior of real-time applications with constrained timing requirements."

I really wish I could do a good bit of my work on his OS. I'd much rather a Kawasaki than an aircraft carrier that is half sinking. Charles Moore of Forth fame has an amazing interview where he argues that the OS is really not necessary on modern hardware. Of course this man built his own language, CAD software, and chips...some of which are in outer space. Impressive man.

olewhalehunter 9y ago
Chuck and Terry's work prove that most kernels are just really terrible compiler systems
ioddly 9y ago
Where is Chuck Moore now? He used to write a blog that was sometimes quite educational.
- fish_fan 9y ago
  I believe he's still with GreenArrays.
  - throwaway7645 9y ago
    He retired a week ago apparently.
- Jtsummers 9y ago
  https://groups.google.com/forum/#!original/comp.lang.forth/LmthCiZ4Cjk/f-e03GHXAQAJ https://groups.google.com/forum/#!original/comp.lang.forth/L... Per this, he's retired now.
noblethrasher 9y ago
I don't suppose you have a link to the Chuck Moore interview; I would love to take a look at it. (Alan Kay and co. also argued that point.)
- throwaway7645 9y ago
  http://www.ultratechnology.com/moore4th.htm http://www.ultratechnology.com/moore4th.htm https://www.red-gate.com/simple-talk/opinion/geek-of-the-week/chuck-moore-on-the-lost-art-of-keeping-it-simple/ https://www.red-gate.com/simple-talk/opinion/geek-of-the-wee... The first one has where he mentions the OS. Personally, I do think the OS is needed, but not in its present form. Instead, something far far simpler than even Linux. Yes, I've seen Alan Kay's similar presentation on the amount of code in windows and the F-22 raptor. Stacked it is supposedly unbelievably high like many stories, while their Smalltalk Machine built at Xerox had the entire language, GUI, text editor, image programs...etc in a tiny amount of code. In the modern day I think of Rebol which has a very powerful and simple DSL for so many tasks such as creating GUIs and the full download is like a few MB with zero install. Truly a marvelous piece of software.
  - mwcampbell 9y ago
    > the entire language, GUI, text editor, image programs...etc in a tiny amount of code But it wasn't internationalized, accessible to people with various disabilities (e.g. blind people via a screen reader), automatically installing updates over the network, encrypting all communication over the network (as in TLS today), etc. No doubt some bloat comes from accumulated incidental complexity. But to some extent (I don't know how much), one person's bloat is another person's essential features. For example, if you tell me about some bloat-free GUI toolkit that draws its own widgets (as opposed to a wrapper over multiple platform native toolkits), my immediate reaction will be "What about accessibility?".
    - mpweiher 9y ago
      [missing features] Well, MS Office, for example, is around 20000x the code of early Smalltalk "Personal Computing" systems. Let's assume that that core code covers only 1% of the features, so you'd need 100x more code to implement all of them. I think this is being very generous, but let's stick with it. That would mean you still have a factor 200 unaccounted for. In other words, even when being very generous, we still haven't accounted for 99.5% of the code.

wolfgke 9y ago

Terry A. Davis' TempleOS does not run in real mode, but in 64 bit mode (long mode) in ring 0.

TomMarius 9y ago
I think what he really meant was real >time<.
- wolfgke 9y ago
  > I think what he really meant was real >time<. On "normal" x86 processors (say: the CPU that will be inside your PC/laptop if you buy one) it is really hard (I don't want to claim "impossible", but at least really hard) to do real-time stuff. Intel knows that and this is also among the reasons why they released their Intel Quark SoC/micro controller, which is perfectly suitable for real-time stuff. Why is this the case? One obvious reason is that the caches (D$, I$, micro op cache etc.) und the pipeline stages (EDIT: including out-of-order execution) make it really hard to predict/prove/test strict upper bounds on the performance of some code fragment on "normal" x86 processors. Another also well-known "issue" is that many modern x86 clock up or down depending on core temperate (I think this behavior can at least partly controlled by the firmware (UEFI)). But there is a much more subtle reason, too: It is SMM (system management mode): https://en.wikipedia.org/w/index.php?title=System_Management_Mode&oldid=780439819 https://en.wikipedia.org/w/index.php?title=System_Management... For backward compatibility a lot of legacy functions are implemented via SMM calls such as emulating a PS/2 mouse/keyboard (while really a USB mouse/keyboard is connected). As long as you cannot guarantee that the code of your OS will not trigger such a function that is emulated via SMM, it is very hard to ensure real-time guarantees. EDIT: To quote directly from the Wikipedia article: "Operations in SMM take CPU time away from the applications, operating system kernel and hypervisor, with the effects magnified for multicore processors since each SMI causes all cores to switch modes. There is also some overhead involved with switching in and out of SMM, since the CPU state must be stored to memory (SMRAM) and any write-back caches must be flushed. This can destroy real-time behavior and cause clock ticks to get lost. The Windows and Linux kernels define an ‘SMI Timeout’ setting a period within which SMM handlers must return control to the operating system or it will ‘hang’ or ‘crash’. The SMM may disrupt the behavior of real-time applications with constrained timing requirements."