<jpo>
ehmry: i'm really glad you made a sigil writeup. i'm sad to see it die (or be put on haitus?) but it's nice to peer behind the curtain for someone otherwise too preoccupied to have followed the source
<jpo>
the eris stuff was particularly nice to see
<jpo>
and i'm still not sold on dhall, but i would be interested in hearing more of your thoughts on the genode configuration data model and any particular insights that may have resulted from your efforts at improving non-redundancy and type safety
<jpo>
because simply s/xml/cbor/ doesn't address the issues of redundant specification of routing, etc.
<ehmry>
jpo: I think cbor kind of makes the problem go away, because it requires a translation layer, and the translation wouldn't be a good one if it didn't correctly genereate the redundant configuration points from a single specification
<jpo>
at that point it's more than a mere translation though -- you aren't merely taking json/xml/whatever and encoding it differently, it's a semantic conversion which requires domain-specific knowledge of the configuration it's transforming
<jpo>
so, encoding becomes less relevant than data model and type system or whatever
<ehmry>
true
<qyliss>
> The project was too ambitious for one person. The goal was to produce an outcome maintainable by a single person, and I was able to "keep the whole project in my head" to a substantial depth, but this was not practical. Localizing the vision, planning, implementation in one head leads to short feedback loops between those concerns, and this led to something incoherent to observers.
<jpo>
so i think there are some potentially interesting perhaps non-trivial lessons to be learned from your efforts playing with the details for so long about how best to structure config of a recursive capability system
<qyliss>
:x
<jpo>
qyliss: ;)
<jpo>
i think there might be generalizable principles here which, if made explicit, could be better accounted for in the design of future systems which aren't constrained by resource-hungry evaluation, etc.
<jpo>
lessons which aren't immediately apparent to the casual observer
<ehmry>
jpo: cbor is particularily nice because it handles binary data without any encoding overhead, and you can put cbor into a tagged byte string, and put that into more cbor, so the outer parser can handle the inner cbor as opaque data
<ehmry>
I wrote a cbor parser for genode and did some of the dhall modeling, but it was a step too far to actually transition away for xml
<ehmry>
and for dhall, I think any dhall code could be later translated to nickel (maybe even automatically)
<jpo>
ehmry: i'd be curious to hear your thoughts on the merit of explicit schemas in-line with your data. your complaints about sysfs being untyped could be addressed by sysfs carrying additional metadata about its structure, types, availability, etc. which could be checked before runtime. the same can be said of e.g. RPC interfaces (look at FIDL, or reflection in protobuf, or ...). what would you think of using something like Avro, where you aren't necessarily
<jpo>
i suspect there might be a place for something like avro but with a richer type system
<jpo>
a dependently-typed data model, made explicit as side-band information within your data stream
<ehmry>
I haven't given it much thought, but yes, getting a schema at runtime would be nice
<jpo>
if used for e.g. genode configuration, then you could statically ensure that, rather than merely "this component gets a config rom", that the emitter and consumer of the config rom share a compatible schema -- and this could be to some degree checked at system build time
<ehmry>
yes, and if ERIS were integrated then scheme could just be a hash that you get from the server that can be used to get the document somewhere else, so you don't have a lot of overhead for static systems
<jpo>
anyway, as you pointed out in your writeup, these are all benefits which would be much easier to gain with an rpc system with an explicit canonical definition format which is not c++
<jpo>
what the optimal form for type-safer rpc formats is though remains an open question afaict
<ehmry>
well that was something mirage-os joe brought up at bornhack, I can't take credit for it
<ehmry>
yea, and network transparency would be a nice
<ehmry>
feature.
<ehmry>
I like Plan9 and 9P but I think the interfaces have similar schema problems
<jpo>
network "transparency" (in the sense that you can draw arbitrary lines between components and insert a network boundary there) is a fools errand IMHO. i think X11 is a great example to learn from. they did serialization instead of shared memory with network transparency being an explicit goal, and yet, the ecosystem ended up with chatty protocols which have borderline unusable user experiences over even reasonably-low latency (but non-local) network links
<ehmry>
sure, I can say its nice to have, but you are probably right
<jpo>
and SOAP is a good example to learn from too, which also tried to have method calls be able to cross runtime boundaries "transparently", but ended up with endless nightmares of timeouts because synchronous calls don't map will to the real failure modes where your other side can arbitrarily disappear, but perhaps only for some period of time, etc.
<jpo>
IMHO wayland got this right (keep things local, and if you want to do something over a network, use something designed for it (like video encoding instead of draw calls))
<ehmry>
things that require low-latency network links are dangerous anyway because metadata
<jpo>
^ also a good point
<ehmry>
thats pretty tangental, but i would like to see more things designed for high latency
<jpo>
ssb ftw :)
<jpo>
same
<jpo>
and low-energy. pure-functional rebuild-the-world is nice, but, if i had infinite free time, i'd like to optimize for less rebuilding of everything for every close-to-root-deps change
<jpo>
theoretically there's no problem with the road the ecosystem is on now, it's "merely a matter of effort"
<jpo>
yet... free time is a scarce resource while selling ones soul, unfortunately
<jpo>
so, if you were to add typing to 9p, have you thought about what you would want it to look like?
<ehmry>
no idea, I've not thought about it, someone on mastodon might have been talking about this
<ehmry>
genode has some better drivers than 9front anyway
<ehmry>
I have half a mind to say screw it and go into lisp-machines/smalltalk/oberon/urbit, but I wont
<ehmry>
even if we have a nice urbit (but alt-left) we still need drivers
<jpo>
i've never looked at oberon or urbit. what are their merits in this context?
<ehmry>
that all code is in a single language
<ehmry>
and with urbit I think everything is done in a pretty high-level functional language
<ehmry>
an alternative to the linux desktop would be to use one of these systems, but as great as they might be you still need a good platform for driving the hardwar
<jpo>
ehmry: do you know if there's a good reason why the genode gcc toolchain _doesn't_ have its own triplet? is it just a matter of nobody's done the work? or perhaps some actual technical problem (e.g. wanting to inherit libc-specific hacks from people's autotools scripts, or something?)
<ehmry>
jpo: I think gcc is probably too much of a pain to completely patch, its recursive autotools
<aaronjanse>
I'd like to also think ehmry for writing up a retrospective look at the project. I really appreciate you sharing what you learned
<aaronjanse>
I'd like to also thank ehmry for writing up a retrospective look at the project. I really appreciate you sharing what you learned