3 ms·

Could I bother you to elaborate? I'm interested in OS design and capabilities too :)

zzo38computer 3y ago
A program can receive capabilities from kernel and from other programs, and can also make up its own capabilities (which can proxy existing capabilities, so they are called "proxy capabilities") which can then be sent in messages to other capabilities; all messages are sent to and received from capabilities and messages can contain both bytes and references to other capabilities (allowing the program that receives them to use those capabilities). (This is a bit similar than SCM_RIGHTS, although there is a bit difference.) One thing that can be done with proxy capabilities is to run programs with any instruction set whether or not it is the instruction set on the computer that it is running on; the programs will just work. This is because an emulator can provide a proxy of the execution capability and can detect the instruction set required and emulate it. (Of course this only works if the program that spawns it is given the proxy capability, although it doesn't know that it is a proxy capability.) (It could also emulate specific instructions, e.g. if you are using x86 without BMI2 extensions and you want to run a program that uses BMI2 extensions.) Another thing that can be done is to run a program on another computer just as though it is local (or vice-versa); a program can, when sending/receiving messages through the network service, make IDs for any capabilities it send/receives and use those to handle passing the messages. So, capabilities can be shared between computers, and a program can use a combination of capabilities from multiple computers. (Multiple locking will be a bit more complicated.) Or, you can use proxy capabilities for testing what a program might do ten years from now (by proxying the date/time capability), or simulated disk errors, etc. Or, if you do not have a camera, you can make a program that expects it to be given the contents of a video file instead. There are many more possible uses, too. The kernel need not know what proxy capabilities are used for, in order to work. When a program starts, it receives an initial message, which will contain any capabilities it is allowed to use (and, depending on what capabilities they are, might be able to use those capabilities to request further capabilities). (If the initial message contains no capabilities, then the program is immediately terminated (unless a debugger is attached to it), since it would not be able to do any I/O and is therefore worthless.) (Note that there are no command-line arguments, environment variables, etc; only the initial message.) Files can contain links to other files in their stream as well as bytes, and links to files can also be made into capabilities which can be sent in messages too. A link can be either to the latest version, or to a fixed version (in which case copy-on-write is used if it is accessed and written through a link that is not to a fixed version). Another feature is that locks and transactions can involve multiple objects at once, instead of having to lock each one individually. (This is helpful for many kinds of synchronizations. For example, a program might write to (or read from) two files and avoid a race condition of another program reading (or writing) the two files and receiving (or sending) inconsistent data.) I also have many ideas of the high-level design (of stuff other than the kernel); most of the above is about low-level design. There will be common conventions for formats of messages, including endianness, etc; this way programs written for different instruction sets can communicate with each other without being confused. One high-level feature is the "common data format", which is a binary structured format, used for most of the system. This can include plain lists, key/value lists, rich text, diagrams, zoned spreadsheets, time series, typed arrays, extensions, and others. The command shell has some ideas similar than Nushell, although using the binary structured format instead of text, using Extended TRON Code instead of Unicode, and others. It can also be used as a programming language, can be used to control other programs (if having access to the appropriate capabilities) (a bit similar than ARexx ports), etc. You can also just as easily move and copy data and objects between the command shell and GUI, so they are designed to work well together, rather than independent. The file system is strange, not having file names and not having directory structures (except for a root directory with 256 numbered entries, mainly used for some low-level startup stuff; not all entries need to link to a file). A file can have several numbered forks (not necessarily consecutively numbered; perhaps 32-bit numbers); some of the low numbers have specific conventional uses while higher numbers can be used for your own use. There is journaling needed, including of transactions of multiple files at once. A POSIX compatibility library is also possible. This is a user program that a C program can link to, and a set of conventions for messages to use with POSIX (e.g. command-line arguments, environment variables, etc), which can be used to run programs that are designed for POSIX. (However, designing the program for this system instead would make it much better suited for this system in many ways, since it can then take advantage of many of the helpful features of this system.) My intention is that it is not a single implementation of the operating system, but a specification that multiple implementations would be possible. Some implementations might run by themself while others might be able to run inside of another operating system (similar than Inferno). A program for this operating system could then run on any of the available implementations. The kernel and the higher-level parts of the operating system need not match (other than stuff such as drivers), although usually would be expected that they would match.

A program can receive capabilities from kernel and from other programs, and can also make up its own capabilities (which can proxy existing capabilities, so they are called "proxy capabilities") which can then be sent in messages to other capabilities; all messages are sent to and received from capabilities and messages can contain both bytes and references to other capabilities (allowing the program that receives them to use those capabilities). (This is a bit similar than SCM_RIGHTS, although there is a bit difference.) One thing that can be done with proxy capabilities is to run programs with any instruction set whether or not it is the instruction set on the computer that it is running on; the programs will just work. This is because an emulator can provide a proxy of the execution capability and can detect the instruction set required and emulate it. (Of course this only works if the program that spawns it is given the proxy capability, although it doesn't know that it is a proxy capability.) (It could also emulate specific instructions, e.g. if you are using x86 without BMI2 extensions and you want to run a program that uses BMI2 extensions.) Another thing that can be done is to run a program on another computer just as though it is local (or vice-versa); a program can, when sending/receiving messages through the network service, make IDs for any capabilities it send/receives and use those to handle passing the messages. So, capabilities can be shared between computers, and a program can use a combination of capabilities from multiple computers. (Multiple locking will be a bit more complicated.) Or, you can use proxy capabilities for testing what a program might do ten years from now (by proxying the date/time capability), or simulated disk errors, etc. Or, if you do not have a camera, you can make a program that expects it to be given the contents of a video file instead. There are many more possible uses, too. The kernel need not know what proxy capabilities are used for, in order to work. When a program starts, it receives an initial message, which will contain any capabilities it is allowed to use (and, depending on what capabilities they are, might be able to use those capabilities to request further capabilities). (If the initial message contains no capabilities, then the program is immediately terminated (unless a debugger is attached to it), since it would not be able to do any I/O and is therefore worthless.) (Note that there are no command-line arguments, environment variables, etc; only the initial message.) Files can contain links to other files in their stream as well as bytes, and links to files can also be made into capabilities which can be sent in messages too. A link can be either to the latest version, or to a fixed version (in which case copy-on-write is used if it is accessed and written through a link that is not to a fixed version). Another feature is that locks and transactions can involve multiple objects at once, instead of having to lock each one individually. (This is helpful for many kinds of synchronizations. For example, a program might write to (or read from) two files and avoid a race condition of another program reading (or writing) the two files and receiving (or sending) inconsistent data.) I also have many ideas of the high-level design (of stuff other than the kernel); most of the above is about low-level design. There will be common conventions for formats of messages, including endianness, etc; this way programs written for different instruction sets can communicate with each other without being confused. One high-level feature is the "common data format", which is a binary structured format, used for most of the system. This can include plain lists, key/value lists, rich text, diagrams, zoned spreadsheets, time series, typed arrays, extensions, and others. The command shell has some ideas similar than Nushell, although using the binary structured format instead of text, using Extended TRON Code instead of Unicode, and others. It can also be used as a programming language, can be used to control other programs (if having access to the appropriate capabilities) (a bit similar than ARexx ports), etc. You can also just as easily move and copy data and objects between the command shell and GUI, so they are designed to work well together, rather than independent. The file system is strange, not having file names and not having directory structures (except for a root directory with 256 numbered entries, mainly used for some low-level startup stuff; not all entries need to link to a file). A file can have several numbered forks (not necessarily consecutively numbered; perhaps 32-bit numbers); some of the low numbers have specific conventional uses while higher numbers can be used for your own use. There is journaling needed, including of transactions of multiple files at once. A POSIX compatibility library is also possible. This is a user program that a C program can link to, and a set of conventions for messages to use with POSIX (e.g. command-line arguments, environment variables, etc), which can be used to run programs that are designed for POSIX. (However, designing the program for this system instead would make it much better suited for this system in many ways, since it can then take advantage of many of the helpful features of this system.) My intention is that it is not a single implementation of the operating system, but a specification that multiple implementations would be possible. Some implementations might run by themself while others might be able to run inside of another operating system (similar than Inferno). A program for this operating system could then run on any of the available implementations. The kernel and the higher-level parts of the operating system need not match (other than stuff such as drivers), although usually would be expected that they would match.