4 ms·

> Strict separation of code and data contradicts the definition and purpose of "computers." I don't believe that your argument here is correct. Code and data s

by mjb 14y ago

> Strict separation of code and data contradicts the definition and purpose of "computers." I don't believe that your argument here is correct. Code and data sharing the same memory space is not a necessary condition of being Turing complete. Just because a Turing machine works that way doesn't require any Turing complete computer to work that way. On the other hand, the distinction between 'code' and 'data' when running a simulator is a little bit arbitrary. > As for the "principal of least privilege", well, that was the point of microkernels. Not nearly the whole point of microkernels, no.

vy8vWJlco 14y ago
"Code and data sharing the same memory space is not a necessary condition of being Turing complete." See: Church-Turing thesis. If you can simulate a Turing machine (which can clearly be said to hold code and data in one memory space) then the hosting machine can also be said to share code and data in the precise sense given by the mapping of the simulated Turing machine onto the host machine (it's implementation). A computation in the simulated Turing machine is just a computation on the host, with some overhead. Conversely, a simulated CPU can't compute faster than it's host's CPU; if a Turing machine was simulated, the host was Turing complete. "Principle of least privilege" implies a sandbox and IPC for every process, all so things don't run within the kernel, or any other process when possible. That sounds like a microkernel to me. You might say another "point" of microkernels (I don't have an exhaustive list) was to make design and debugging easy too, but those are just the same ideals inflicted on the programmer: keep it simple and homogeneous; the less you do, the less you can do wrong. http://en.wikipedia.org/wiki/Microkernel#Security http://en.wikipedia.org/wiki/Microkernel#Security (I didn't put the reference to least privilege in there...) As you said, where to draw the line of separation is arbitrary. One could certainly make code and data (and processes generally) "more separate," but it's all at the expense of programmability (the general in general purpose) and speed (IMHO, why microkernels aren't everywhere), which brings us to the current compromises: monolithic kernels, OSs that warn you before installing, NX flags, patch Tuesday, and antivirus programs. We build up an environment of temporarily-appropriate limitations from a blank (general) slate. If I ever feel too restricted, I put on my black fedora and perform a "jailbreak" (I reboot). I'm still better off with a malleable computer than with many individual limited tools. (Not that you suggested otherwise, just my 2 cents.)

by mjb 14y ago

vy8vWJlco 14y ago

"Code and data sharing the same memory space is not a necessary condition of being Turing complete." See: Church-Turing thesis. If you can simulate a Turing machine (which can clearly be said to hold code and data in one memory space) then the hosting machine can also be said to share code and data in the precise sense given by the mapping of the simulated Turing machine onto the host machine (it's implementation). A computation in the simulated Turing machine is just a computation on the host, with some overhead. Conversely, a simulated CPU can't compute faster than it's host's CPU; if a Turing machine was simulated, the host was Turing complete. "Principle of least privilege" implies a sandbox and IPC for every process, all so things don't run within the kernel, or any other process when possible. That sounds like a microkernel to me. You might say another "point" of microkernels (I don't have an exhaustive list) was to make design and debugging easy too, but those are just the same ideals inflicted on the programmer: keep it simple and homogeneous; the less you do, the less you can do wrong. http://en.wikipedia.org/wiki/Microkernel#Security http://en.wikipedia.org/wiki/Microkernel#Security (I didn't put the reference to least privilege in there...) As you said, where to draw the line of separation is arbitrary. One could certainly make code and data (and processes generally) "more separate," but it's all at the expense of programmability (the general in general purpose) and speed (IMHO, why microkernels aren't everywhere), which brings us to the current compromises: monolithic kernels, OSs that warn you before installing, NX flags, patch Tuesday, and antivirus programs. We build up an environment of temporarily-appropriate limitations from a blank (general) slate. If I ever feel too restricted, I put on my black fedora and perform a "jailbreak" (I reboot). I'm still better off with a malleable computer than with many individual limited tools. (Not that you suggested otherwise, just my 2 cents.)