Terms and Definitions
and Vocabulary and Verbogeny
- Regardless, you first described Seed as "single address space". What does that mean?
It means that programs in Seed all live next to each other in RAM. Normally (in Windows and Unix-derived operating systems), programs are isolated from each other by the x86 processor's memory protection hardware. In Seed, though they are protected from each other by other means ("capability-based on-the-fly permission checking"). Many recently-created operating systems are exploring this approach, both for its simplicity and for its speed benefits.
- Alright, I guess. What does "persistant linear object store" literally mean, though?
I described it in rough terms earlier, but more concretely, linear objects have only one name (or reference to their location in memory). In Seed, objects in a volume are only referenced once - by a hash of their name in a lookup table - so they can be called linear. Blocks of free memory are kept track of in the same way - they have names, just like other objects. This scheme vastly simplifies memory management, and has constant-speed object lookup (and usually constant-speed allocation/deallocation) as an added bonus.
- Fair enough, but you called your linear object store "persistant". What's that?
Persistant objects have their state constantly preserved. One need not explicitly save them to disk. Like the contents of a database, they will be automatically copied from unstable media (like RAM) to more stable media (like a hard drive) when it becomes efficient and necessary to do so. This has interesting implications when combined with the implicit versioning of objects, but I'll leave that alone for now...
- Next in your description of Seed we have "event-based pre-emptive-multitasking". Eh?
Seed is event-based in that programs executing under it can "go to sleep" (or be put to sleep), and be woken by events, which the programs can then respond to and handle. Pre-emptive multitasking means that programs can be interrupted and suspended so other programs can get a chance to execute. Most operating systems nowadays have pre-emptive multitasking, and they all have some kind of event-handling system (usually built around hardware interrupts). Basically, Seed would have a uniform, global event system which everything running on it would use.
- So how does not having a traditional kernel or filesystem fit into this?
Well, instead of a traditional kernel (which is accessed via system calls and isolated from the rest of the system via hardware memory protection), Seed uses a flat address space, so, in a sense, everything could be said to reside in the kernel... And Seed has its persistant linear object store, so it doesn't have or need a traditional filesystem.
- You mentioned moving the locus of system security... What exactly does that imply?
In most popular operating systems, the locus of system security lies with the x86 processor's hardware memory protection. Under that scheme, programs are not trusted to sanely manipulate memory, so they are walled off and isolated from each other by memory protection hardware. In Seed, however, the operating system handles memory management, so programs don't need to be walled off from each other - the tradeoff, though, is that programs can't directly access memory for themselves. That is a task reserved for trusted operating system code.
- And finally, what's up with capability-based on-the-fly object permission checking?
The capability security model has been presented as an alternative to Access Control Lists (ACLs) and Unix-style permissions. Don't worry about it for now - it isn't close to implemented in Seed. Hell, don't worry about the event system either - implementing the linear object store gets first priority.