Core system design¶
The thox approach is that of a microkernel one, which is to separate as much as possible distinct software components in order for the newcomer to be able to understand them one by one without requiring two pages to be opened at once.
In this section, you’ll be able to find explanations, usage instructions, API reference and internal mechanisms descriptions for each of the thox components.
- thox startup
- thox processes and interactions
- initd: the thox init daemon
- fsd: the thox filesystem daemon
- gpsd: the thox GPS daemon
- netd: the thox network daemon
- rand: the thox random and entropy production daemon
initd will require some kind of way to boot up fsd without having fsd booted up. Maybe the default context can provide some sort of bootup equivalent for fsd RPC calls?
Some services that could be useful in the future:
A redstone management daemon.
A turtle management daemon, for queuing actions and observation results and caching inventory content.
An HTTP and websocket management daemon.
A terminal/monitor management daemon, for managing inter-mod screen output and keyboard / clipboard input.
A package management daemon. For now we can just concentrate on building distributions statically.
Virtualization guest package for common emulators, such as CCEmuX, for adding and removing peripherals, opening other machines, etc.
Sound management? Might require process priorities, depends on if the existing hardware has sound queues or not, but we need to run often even if that’s the case.
Some database management daemon, supporting SQL?
Cloud Catcher client daemon, or maybe that should be put in the terminal/screen management daemon with a dependency on HTTP/websocket?
Maybe Krist wallet management as well? Since it is popular amongst ComputerCraft players.