[urbit]

Blatant plug: Urbit (urbit.org) is a general-purpose OS built on the event-sourced model. Urbit's state is a small, frozen function of its event log.

I don't know of any other generalized event-sourced OSes. But almost every principle Fowler describes in special-purpose event-sourced designs also seems to apply in the general-purpose case.

For example, the connection between CQRS and event-sourcing seems very deep and natural. The connection to patches in a revision-control system is also completely apropos.

When Fowler starts pointing at advanced problems like "we have to figure out how to deal with changes in the schema of events over time," you start to see a clear path from special-purpose event-sourced apps to general-purpose event-sourced system software.

Broadly speaking, one category of answer is: abstract the semantics of your app, until it becomes a general-purpose interpreter whose source code is delivered and updated in the event stream. Then the new schema is just a source patch. And your app is not just an app, but actually sort of an OS.

[dozzie]

> Blatant plug: Urbit (urbit.org) is a general-purpose OS built on the event-sourced model.

I've looked through its documentation, and while I couldn't make heads or tails of it, Urbit seems to be everything but an operating system. Espeically that it needs unix system to run.

[urbit]

Linux on Xen would also fail this test.

Urbit is an OS in that it defines the complete lifecycle of a general-purpose computer. It's not an OS in that it's the lowest layer above bare metal.

Sorry you had a bad experience with the docs. Urbit is actually much stupider than it looks.

Unfortunately, premature documentation is the second root of all evil, so some of the vagueness you sense is due to immature code. It's always a mistake to document a system into existence -- that is the path of vaporware. Better to run and have weak docs, than have good docs but not run.

[fb03]

I agree with you on the documentation thing but, what we see (and I experience also) is that most of the time, when things get serious enough (production), there isn't any available time to document the core of the software properly, let alone document it fully.... "lack of time" in this context meaning either (1) management won't let you stop implementing stuff they need "for yesterday" (everything is critical priority) and document for 10-20 hours or (2) your self run project needs more features and it's always cooler to study/code than to document puzzles you have already solved.

I'm not criticizing, I am exposing that I am part of the problem and lost, and I'd like to know how people handle this on their lives. I want to document more but there's always this rush to implement implement implement and not once, during some catastrophic breakdown of something, management wants everything solved quickly but they expect you to remember instantly of everything you did 2+ years ago :-)

PS: ... and they'll get mad if you say "you didn't let me document this damn thing"

[discreteevent]

"What is "data" without an interpreter (and when we send "data" somewhere, how can we send it so its meaning is preserved?)"

- Alan Kay, from a discussion he had with Rich Hickey on HN (Rich Hickey disagrees with the idea that you need to send an interpeter)

https://news.ycombinator.com/item?id=11945722