More on system layer
This commit is contained in:
parent
d52b7d2a91
commit
3399768581
|
|
@ -68,3 +68,20 @@ process up to coordinating activity between machines around the world. A distrib
|
|||
could be an excellent foundation for collaborative applications, where privacy concerns come to
|
||||
the forefront. In effect, a dataspace can become a richly-structured "VPN", containing
|
||||
application-specific shared data and with application- or schema-specific access controls.
|
||||
|
||||
## References
|
||||
|
||||
[Birgisson et al 2014]: #ref:birgisson14
|
||||
[**Birgisson et al 2014**] <span id="ref:birgisson14"> Birgisson, Arnar, Joe Gibbs Politz,
|
||||
Úlfar Erlingsson, Ankur Taly, Michael Vrable, and Mark Lentczner. “Macaroons: Cookies with
|
||||
Contextual Caveats for Decentralized Authorization in the Cloud.” In Network and Distributed
|
||||
System Security Symposium. San Diego, California: Internet Society, 2014.</span>
|
||||
|
||||
[Ellison 1999]: #ref:ellison99
|
||||
[**Ellison 1999**] <span id="ref:ellison99"> Ellison, Carl. SPKI Requirements. Request for
|
||||
Comments 2692. RFC Editor, 1999. <https://doi.org/10.17487/RFC2692>.</span>
|
||||
|
||||
[Ylonen et al 1999]: #ref:ylonen99
|
||||
[**Ylonen et al 1999**] <span id="ref:ylonen99"> Ylonen, Tatu, Brian Thomas, Butler Lampson,
|
||||
Carl Ellison, Ronald L. Rivest, and William S. Frantz. SPKI Certificate Theory. Request for
|
||||
Comments 2693. RFC Editor, 1999. <https://doi.org/10.17487/RFC2693>.</span>
|
||||
|
|
|
|||
|
|
@ -90,9 +90,9 @@ For example, a system layer may:
|
|||
among other things. All of these areas are common *across* applications, unique to none of
|
||||
them.
|
||||
|
||||
To come up with this list, I surveyed a number of existing open systems such as Linux
|
||||
distributions, desktop environments, and so on, plus (in a limited way) Android and Mac OS,
|
||||
looking for commonalities and differences. That is, the list was developed in a largely
|
||||
To come up with this list, I surveyed[^raw-notes] a number of existing open systems such as
|
||||
Linux distributions, desktop environments, and so on, plus (in a limited way) Android and Mac
|
||||
OS, looking for commonalities and differences. That is, the list was developed in a largely
|
||||
informal way. Despite this, I've found it a fruitful starting point for an investigation of the
|
||||
properties of system layers in general. I welcome additional perspectives that others might
|
||||
bring.
|
||||
|
|
@ -270,13 +270,13 @@ for the addresses of fine-grained resources (e.g. single objects) within a proce
|
|||
distributed garbage-collection[^binder-vs-syndicate] that is extremely widely used in
|
||||
Android.
|
||||
|
||||
From a [2009 email from Dianne Hackborne](https://lkml.org/lkml/2009/6/25/3):
|
||||
<q>For a rough idea of the scope of the binder's use in Android, here is a list of the basic
|
||||
system services that are implemented on top of it: package manager, telephony manager, app
|
||||
widgets, audio services, search manager, location manager, notification manager,
|
||||
accessibility manager, connectivity manager, wifi manager, input method manager, clipboard,
|
||||
status bar, window manager, sensor service, alarm manager, content service, activity
|
||||
manager, power manager, surface compositor.</q>
|
||||
From a [2009 email from Dianne Hackborne](https://lkml.org/lkml/2009/6/25/3): <q
|
||||
id="binder-success">For a rough idea of the scope of the binder's use in Android, here is a
|
||||
list of the basic system services that are implemented on top of it: package manager,
|
||||
telephony manager, app widgets, audio services, search manager, location manager,
|
||||
notification manager, accessibility manager, connectivity manager, wifi manager, input
|
||||
method manager, clipboard, status bar, window manager, sensor service, alarm manager,
|
||||
content service, activity manager, power manager, surface compositor.</q>
|
||||
|
||||
## Name-binding, name-resolution, and namespaces
|
||||
|
||||
|
|
@ -374,39 +374,33 @@ Machine and Google's Android backup support libraries.
|
|||
|
||||
## Synthesis, or, Toward a Complete Vision of a System Layer
|
||||
|
||||
Want to make it *easy* integrate portions of a system layer together. The core of the core has
|
||||
to be good IPC and state-management and -introspection.
|
||||
Looking back at all these features and variations in design and implementation, we might
|
||||
imagine some kind of ideal system layer.
|
||||
|
||||
- systemd/udev/D-Bus/NetworkManager/dhcpcd/etc., as sketched above
|
||||
- init/inetd/crond/etc., the traditional Unix system layer
|
||||
- daemontools/runit/s6: service supervision software
|
||||
- OpenRC/[s6-rc](https://skarnet.com/projects/service-manager.html):
|
||||
service manager and supervisor used in Alpine
|
||||
- Android architecture components
|
||||
- Erlang's OTP, the system layer for the Erlang virtual operating system
|
||||
- It should be structured around a flexible, high-performance communications substrate with a
|
||||
coherent, system-wide security model, a story around data privacy, flexible name-to-address
|
||||
mapping, and reliable failure signalling
|
||||
|
||||
| Component | SM | RX | HL | AC | PR | IPC | NS | JQ | UI | CF | RR | BK |
|
||||
|----------------------|----|----|----|----|----|-----|----|----|----|----|----|----|
|
||||
| Linux kernel | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | | | |
|
||||
| udev | | ✓ | | ✓ | | | ✓ | | | | | |
|
||||
| D-Bus | ✓ | | | ✓ | | ✓ | ✓ | | | | | |
|
||||
| NetworkManager | | ✓ | ✓ | ✓ | | | | | | | | |
|
||||
| dhcpcd | | | | | | | | | | | | |
|
||||
| systemd | ✓ | ✓ | | | | | ✓ | ✓ | | | | |
|
||||
| daemontools/runit/s6 | ✓ | | | | | | | | | | | |
|
||||
| OpenRC | ✓ | | | | | | | | | | | |
|
||||
| OTP (Erlang) | ✓ | | | | | ✓ | ✓ | ✓ | ✓ | | | |
|
||||
| X11 | | | | ✓ | | ✓ | ✓ | | ✓ | | | |
|
||||
| Time Machine | | | | | | | | | | | | ✓ |
|
||||
| Nextcloud | | | | ✓ | | ✓ | ✓ | | ✓ | | ✓ | |
|
||||
| Syncthing | | | | ✓ | | | ✓ | | | | ✓ | |
|
||||
| Windows Registry | | | | | | | | | | ✓ | | |
|
||||
| GNOME | | ✓ | ✓ | ✓ | | | | | ✓ | ✓ | | |
|
||||
| Android | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | |
|
||||
- It should offer a service description language and a mechanism for managing services,
|
||||
tracking service demand, and responding with appropriate service supply
|
||||
|
||||
- ideally, a system layer's security mechanisms would offer a coherent, system-wide approach
|
||||
to security and privacy. few do so
|
||||
- It should allow modular addition of components that enrich it with additional high-level
|
||||
perspectives on the system
|
||||
|
||||
- It should offer utility services such as job-queueing and -scheduling, including
|
||||
calendar-like and time-based scheduling
|
||||
|
||||
- It should offer a user interface
|
||||
|
||||
- It should provide data backup services
|
||||
|
||||
- It could provide data replication services
|
||||
|
||||
The most important of these is, in my view, the communications substrate, which dovetails
|
||||
inextricably with the state-management and -introspection subsystem. A good design for this
|
||||
part of a system will have compounded effects and will make it easy to integrate portions of a
|
||||
system layer together. (Witness the [success](#binder-success) of Android's binder, discussed
|
||||
[above](#binder)!)
|
||||
|
||||
## References
|
||||
|
||||
|
|
@ -414,12 +408,6 @@ to be good IPC and state-management and -introspection.
|
|||
[**Bass et al 1998**] <span id="ref:bass98"> Bass, Len, Paul Clements, and Rick
|
||||
Kazman. Software Architecture in Practice. Addison-Wesley, 1998.</span>
|
||||
|
||||
[Birgisson et al 2014]: #ref:birgisson14
|
||||
[**Birgisson et al 2014**] <span id="ref:birgisson14"> Birgisson, Arnar, Joe Gibbs Politz,
|
||||
Úlfar Erlingsson, Ankur Taly, Michael Vrable, and Mark Lentczner. “Macaroons: Cookies with
|
||||
Contextual Caveats for Decentralized Authorization in the Cloud.” In Network and Distributed
|
||||
System Security Symposium. San Diego, California: Internet Society, 2014.</span>
|
||||
|
||||
[Clements et al 2001]: #ref:clements01
|
||||
[**Clements et al 2001**] <span id="ref:clements01"> Clements, Paul, Rick Kazman, and Mark
|
||||
Klein. Evaluating Software Architectures: Methods and Case Studies. Addison-Wesley,
|
||||
|
|
@ -433,20 +421,11 @@ January 28, 2019. <https://lwn.net/Articles/777595/>.</span>
|
|||
[**Day 2008**] <span id="ref:day08"> Day, John. Patterns in Network Architecture: A Return to
|
||||
Fundamentals. Prentice Hall, 2008.</span>
|
||||
|
||||
[Ellison 1999]: #ref:ellison99
|
||||
[**Ellison 1999**] <span id="ref:ellison99"> Ellison, Carl. SPKI Requirements. Request for
|
||||
Comments 2692. RFC Editor, 1999. <https://doi.org/10.17487/RFC2692>.</span>
|
||||
|
||||
[Rice 2019]: #ref:rice19
|
||||
[**Rice 2019**] <span id="ref:rice19"> Rice, Benno. “The Tragedy of Systemd.” Conference
|
||||
Presentation at linux.conf.au, Christchurch, New Zealand, January 24, 2019.
|
||||
<https://www.youtube.com/watch?v=o_AIw9bGogo>.</span>
|
||||
|
||||
[Ylonen et al 1999]: #ref:ylonen99
|
||||
[**Ylonen et al 1999**] <span id="ref:ylonen99"> Ylonen, Tatu, Brian Thomas, Butler Lampson,
|
||||
Carl Ellison, Ronald L. Rivest, and William S. Frantz. SPKI Certificate Theory. Request for
|
||||
Comments 2693. RFC Editor, 1999. <https://doi.org/10.17487/RFC2693>.</span>
|
||||
|
||||
---
|
||||
|
||||
#### Notes
|
||||
|
|
@ -466,9 +445,9 @@ Comments 2693. RFC Editor, 1999. <https://doi.org/10.17487/RFC2693>.</span>
|
|||
YouTube transcript of the talk, and then cleaned it up.
|
||||
(Emphasis mine.)
|
||||
|
||||
[^libc-resolver]: The resolver built in to libc plays the major part in this; but things like
|
||||
dnsmasq play a role too, especially when combined with virtual machines running within a
|
||||
host.
|
||||
[^raw-notes]: The [raw notes that I
|
||||
took](https://git.syndicate-lang.org/synit/synit/src/branch/main/notes) during my survey
|
||||
and during the Synit design process are available.
|
||||
|
||||
[^binder-vs-syndicate]: Looking at binder, I see *strong* similarities with the [Syndicated
|
||||
Actor Model](syndicated-actor-model.md) and its [protocol](protocol.md)!
|
||||
|
|
|
|||
Loading…
Reference in New Issue