On Wednesday 29. January 2020 15.32.35 Andrew Warkentin wrote:
I've never really been a fan of multi-personality systems, and I'd say they are less relevant now than ever because of low diversity and ubiquitous hardware virtualization. There are only really two environments for which compatibility matters in most cases - Linux and Windows. Linux compatibility can be implemented in a natively Unix-like environment, and so can Windows compatibility (with Wine). If you really need to run an entire alternate OS environment it can just be virtualized.
Maybe my idea of personalities is somewhat less extensive than yours. For example, providing a filesystem with the necessary files in different places, with libraries looking for those files in the appropriate places, is to me providing a different personality. Consider, for instance, if Solaris had provided a BSD personality rather than putting BSD-related files in one set of places, SysV-related files in another, and so on.
Such lightweight personalities might not be more sophisticated than something supported by chroot or a limited "jail" solution in a traditional Unix-like system, although making such things work within those kinds of solutions can be easier said than done. Systems like Plan 9 might have an easier time of it, though.
Having things like personality-neutral services just complicates the design of the system. It's far easier if you can just write servers to the same API as applications (under UX/RT, all servers except for the root server will be completely normal processes). Multiple personality support would almost certainly make the minimalist file-oriented architecture I have planned a lot more difficult to implement.
In an L4Re-based system, servers do use the same API as applications and they are just normal processes (but maybe I misunderstand your point). But my argument is that personalities would be built on generic services, not that anyone needs to specifically engineer services for certain personalities, or at least not for all functionality. There may be some special behavioural requirements - there was a FreeVMS project that may have had such requirements and had struggled to implement them - but there should be a lot of common facilities that most personalities share.
I can think of awkward behavioural traits that might interfere with a generic services approach. For example, having to support Windows-like file locking semantics where an open file can obstruct usage of that file by other processes. This would raise questions about how processes expecting Unix-like semantics could co-exist with such an arrangement.
As a more mundane example of a personality, consider what L4Re provides already: it is an elementary virtual filesystem offering files with a limited amount of metadata to each task. That does not preclude the development of a Unix personality, nor does it prevent anyone from developing these facilities in a way that completely ignores things like processes and users and other Unix concepts, offering some kind of single-user personality or environment for certain tasks.
So, there could be C library support like that already in L4Re which doesn't really support Unix concepts, whereas another C library could contain the necessary support for interacting with Unix-enabling infrastructure. Such things would presumably be feasible to explore with Linux to an extent, but it probably isn't a particularly interesting avenue to pursue.
To go further, I can imagine a system where notions of users and privileges emerge purely from the configuration of the system. At the same time, there may be notions of users that emerge from filesystem metadata. It is entirely plausible that these notions may co-exist or be orthogonal in some way. But this is perhaps another topic.
Paul