[HN Gopher] Synit - A Reactive Operating System
___________________________________________________________________
Synit - A Reactive Operating System
Author : gjvc
Score : 90 points
Date : 2023-07-15 11:35 UTC (11 hours ago)
(HTM) web link (synit.org)
(TXT) w3m dump (synit.org)
| tonyg wrote:
| Author, AMA
| patterns wrote:
| Another question, Smalltalk related.
|
| What I noticed in various Smalltalk systems is that there is a
| lot of code duplication for handling UI interactions (such as
| dragging or selecting objects in various kinds of views).
| Garnet, for instance, addresses that problem with Interactors
| and constraints [1].
|
| Also, in Smalltalk, you will find countless instances of re-
| implemented tree data-structures e.g., package trees, class
| trees, UI component trees, which increases maintenance effort
| and makes the system less uniform than it perhaps could be.
|
| Could Syndicate address these problems?
|
| [1] https://dl.acm.org/doi/abs/10.1145/67449.67512
| tonyg wrote:
| Syndicate certainly lets you factor out some kinds of
| repeated behavioral patterns: I discussed in my dissertation
| (chapter 9 [1]) examples around cancellation, around state-
| machines, around observers, and around demand-matching.
|
| Besides these examples, the general facets-plus-
| conversational-context idea lets you factor out composable
| behavioral _traits_. Which word reminds me of the Traits of
| Scharli /Nierstrasz/Ducasse [2]: _those_ Traits have proven
| benefits for improving reuse and reducing redundancy and bugs
| in Smalltalk systems. So perhaps in general what we 're
| looking for are new perspectives on old problems - new ways
| of isolating and composing ideas.
|
| Strictly on the example of dragging objects, I actually have
| a little demo GUI that factors out object draggability into a
| composable facet of behavior that can be "mixed in" to an
| actor representing a graphical object. See [3] and, for
| detail, [4].
|
| [1] https://syndicate-lang.org/tonyg-
| dissertation/html/#CHAP:PAT... [2]
| https://dl.acm.org/doi/10.1145/1119479.1119483 [3]
| https://git.syndicate-lang.org/syndicate-lang/syndicate-
| gui-... [4] https://git.syndicate-lang.org/syndicate-
| lang/syndicate-gui-...
| tonyg wrote:
| Thanks for the link to Interactors, by the way, I will enjoy
| having a look at that paper!
| patterns wrote:
| My pleasure! I found it to be a refreshing read. Thank you
| very much for your response. I will study your examples and
| read up the parts in your dissertation.
| convolvatron wrote:
| I dug around for a little bit. Can you link to something that
| points to intent rather than the implementation?
| tonyg wrote:
| Yes! I think the project page for the NLnet-funded part of
| the project brings across some of the intent:
| https://syndicate-lang.org/projects/2021/system-layer/
|
| Deeper background would be something like "build something
| that is to the Syndicated Actor Model as OTP is to Erlang",
| because I believe the SAM is a great way to build interactive
| programs.
| ryanjshaw wrote:
| Do you have any plans around GUIs? I caught the capabilities
| bug about 25 years ago and as far as I can tell this is still
| the big blocker for a capabilities-based desktop OS .
| tonyg wrote:
| I'm not there yet, no. I think the existing research on ocap
| GUIs is promising, and I have ideas for UI in general (think:
| cloud shells) that might stretch to GUI as well.
| ssivark wrote:
| Thanks for the AMA.
|
| - Any comments/references on the potential applications where
| the Syndicated Actor Model is going to be a particularly good
| fit? (I'm curious, for example, about the potential in
| robotics)
|
| - Are you targeting any of these with Synit, or is it meant to
| be a proof of concept?
| tonyg wrote:
| Proof of concept, to be sure. So far. It's currently on the
| back burner because I have to eat : - )
|
| Re applications, anything interactive and somewhat loosely
| coupled. Particularly good for internet scale stuff, I
| suspect, though again I've not rigorously explored this yet.
| Tightly coupled control isn't a great fit. I suspect some
| aspects of robotics could work well with it, but not the very
| realtime parts. I'm not experienced in robotics.
| ducktective wrote:
| More in the "anything" category, but what do you think of Lisps
| and Common Lisp in particular? Practical to write an OS in it?
| tonyg wrote:
| I'm an old Schemer (well, middle-aged) who has gone apostate
| in favour of Smalltalks : - ) Schemes and Lisps are fine
| systems and I enjoy working with them. And yes, practical to
| write an OS in, but (and this won't surprise you at all)
| probably even better if you add SAM support to them first! I
| have done so for Racket thus far.
| klabb3 wrote:
| "Reactive programming" is promising. I've not looked at OSs,
| but for other things, like databases, I've come to the
| conclusion that our typical mixed-paradigm languages themselves
| are clunky and likely need some changes. There's a lot of
| boilerplate and callback indirection and so on to build
| primitive things.
|
| Did you get this feeling as well? More generally, how invasive
| is the "mental model" in relation to existing stuff? Can you
| benefit from it when mixed with "non-reactive systems", or do
| you get the "worst of both worlds"?
| tonyg wrote:
| Good question. Yes, I get that feeling too.
|
| I find that re-presenting existing systems in terms of
| syndicated state and conversational contexts, like you're
| using an FFI, makes everything fit together fairly well. Lots
| of systems offer a reactive interface of _some_ kind, so it
| 's often a matter of just filling in the gaps; even where
| nothing "reactive" is available, one can always get by with
| polling for changes! For example, adding a thin reactive
| layer to Caddy would get you a nice pluggable systemwide HTTP
| service. Or, as in synit, wrapping eudev and netlink gets you
| reasonably coherent interfaces to plug-and-play and to
| ambient network environment changes.
|
| It's not quite embrace-extend-extinguish, it's more
| encapsulate-embed-embody. You write "drivers" that
| encapsulate non-SAM things, embed them in larger systems, and
| over time take on functionality from the encapsulated
| componentry as appropriate.
| patterns wrote:
| In your dissertation you mention that "program" internals such
| as Exceptions should not be asserted as facts and pollute the
| data-space; only relevant facts/knowledge about the domain
| should be shared.
|
| I understand this point, but what if you want to express
| knowledge on how to adapt the technical parts of a system and
| its infrastructure, not just the "problem" domain? I imagine
| that Syndicate and its abstractions could be very helpful in
| this regard.
|
| What are your thoughts?
|
| Edit: For example, you may want to delegate the diagnosis of
| critical Exceptions to engineers, perhaps suggest resolutions,
| patches. Would you use a dedicated syndicate network for this?
| What would be your approach?
| tonyg wrote:
| Great questions.
|
| Yes, that's fine: if your domain is _implementation detail of
| the system itself_ , then using Syndicate to allow different
| program components to have conversations about that domain is
| totally OK.
|
| The point I was trying to make about exceptions and polluting
| the dataspace is as a point about unnecessary coupling:
| exceptions per se are _not_ in most domains, so
| communications mechanisms that include exceptions as part of
| the transport are in some sense wrongly factored. Likewise
| transports that include sender information at the point of
| delivery of each received message. The point isn 't that
| sender information or exception details aren't useful, but
| that they're not something to _bake in_.
|
| Concretely wrt your example: you could use a dedicated
| dataspace for such things, yes, or you could design the
| language of discourse for a large shared dataspace to allow
| multiple ongoing conversations at once on unrelated or
| semirelated topics.
| patterns wrote:
| I see. Thanks for the clarification!
| toomim wrote:
| Hi! I have a few questions:
|
| 1) What are the benefits of the reactive operating systems? Do
| you have any example use-cases that this does better than
| traditional approaches?
|
| 2) Do you find this related to functional reactive programming
| at all?
|
| 3) Since this is a model of concurrency with eventual
| consistency, do you see it benefitting from eventually-
| consistent OT or CRDT data types?
|
| I am asking because I am working on what might be a related
| model: https://braid.org and https://stateb.us. We are building
| a "distributed state abstraction", that we envision will end up
| in three places:
|
| a) HTTP will upgrade from a state _transfer_ to a state
| _synchronization_ protocol
|
| b) Applications will be separated into UIs on top of a "web of
| state" (see https://stateb.us/static/statebus-demo-3-31.mp4 )
| and transition from _web apps_ to _app webs_
|
| c) Operating Systems will replace file systems with state
| systems; where local variables in memory can persist to disk
| without explicit read/write calls, and can be read/written
| across processes without programming overhead.
|
| So I am asking these questions because I wonder if we are all
| looking at the same programming abstraction, but from different
| perspectives!
| tonyg wrote:
| Thanks for the questions.
|
| 1. Applying the same tools used in the SAM for managing
| concurrency and interactivity "in the small" to "larger"
| aggregations of components, and starting to get insight into
| the semantics of operating systems, if you like. For
| examination of the advantages and drawbacks of the SAM, see
| https://syndicate-lang.org/tonyg-dissertation/html/.
|
| 2. Loosely, but only loosely. My dissertation (linked just
| above) discusses FRP a little, but in a nutshell, the SAM has
| ambition that covers more area than FRP.
|
| 3. Yes, absolutely. I've done some experimentation, but
| nothing rigorous yet.
|
| From the points you mention, I think there might indeed be
| some common underlying _thing_ here we 're looking at from
| different perspectives!
| toomim wrote:
| Thank you! Hm, so is it safe to say that this is an
| experiment for you in applying the SAM to a real operating
| system, to see how the model works in practice?
| tonyg wrote:
| Yep. And so far, so good. I think it works well.
| PAPPPmAc wrote:
| It took me several minutes of clicking to determine that it's an
| init/process lifetime management/IPC thing for Linux, that uses
| the "Syndicated Actor Model" for dependencies and IPC.
|
| They've chosen some interesting terminology that's a little
| different than everyone else.
|
| If it had been around by 2010 (which predates a lot of the
| research it's based on, so no) when many Linux folks were looking
| at SMF/SRC/launchd and thinking they wanted something like that,
| it would be more likely to be relevant, but I think we're going
| to be stuck with the systemd/dbus stack for some time due to
| network effects and its all-or-nothing design, whether or not
| someone comes up with a technically superior solution.
___________________________________________________________________
(page generated 2023-07-15 23:00 UTC)