qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
moonloo has quit [Quit: Connection closed]
pinkieval has quit [Ping timeout: 258 seconds]
pinkieval has joined #spectrum
Irenes[m] has quit [Quit: issued !quit command]
pinkieval has quit [Ping timeout: 265 seconds]
pinkieval has joined #spectrum
moonloo has joined #spectrum
{`-`} is now known as {`-`}_
{`-`}_ has joined #spectrum
<colemickens> "I wrote my own Wayland library, ocaml-wayland, and then used that to write my own version of sommelier. "
^_ has joined #spectrum
V has quit [*.net *.split]
{`-`} has quit [*.net *.split]
moonloo has quit [Quit: Connection closed]
v0idify has quit [Remote host closed the connection]
v0idify has joined #spectrum
cole-h has quit [Ping timeout: 260 seconds]
leah2 has quit [Remote host closed the connection]
leah2 has joined #spectrum
jpds has quit [Ping timeout: 268 seconds]
jpds has joined #spectrum
<flosse> colemickens: haha kudos Thomas
^_ is now known as V
jb55 has quit [Remote host closed the connection]
jb55 has joined #spectrum
<pie_> "One problem with the Wayland protocol is that it’s very hard to proxy. Although the wire protocol gives the length in bytes of each message, it doesn’t say how many file descriptors it has. This means that you can’t just pass through messages you don’t understand, because you don’t know which FDs go with which message. Also, the wire protocol doesn’t give types for FDs (nor does the schema), which is a problem for anything that
<pie_> needs to proxy across a VM boundary or over a network."
<pie_> >:(
<Profpatsch> Isn’t network transparency a mythical thing anyway?
<exarkun> I suppose it is until it isn't
<Profpatsch> 9p never took up steam
<Profpatsch> It’s probably a tradeoff?
<Profpatsch> fd passing is by definition local (unless I’m misunderstanding the fd part)
<exarkun> 9p usage is still increasing, I think
<Profpatsch> But it’s an easy & performant way of getting data from one process to another
<Profpatsch> without falling back to mmap on the one side and an rpc bus on the other
<exarkun> But you could fall back to that if you wanted
<Profpatsch> 9p had serious throughput restrictions iirc
<Profpatsch> yeah, but then you have a branch that nobody ever checks
<exarkun> If you use a (non-cloud) VM today w/ guest/host filesystem sharing then there's a good chance you use 9p
<Profpatsch> I think qyliss said that the 9p was the bottleneck
<Profpatsch> Or /a/ bottleneck
<exarkun> Could be. I know almost nothing about spectrum. :)
IdleBot_1c746da8 has joined #spectrum
inf has quit [Ping timeout: 272 seconds]
edef has quit [Ping timeout: 272 seconds]
edef has joined #spectrum
IdleBot_9d07f448 has quit [Ping timeout: 272 seconds]
inf has joined #spectrum
mx08_ is now known as mx08
edadqr_ has quit [Remote host closed the connection]
edadqr_ has joined #spectrum
<qyliss> Profpatsch: with 9p you have to always be networking, basically -- you have to copy file contents into a socket
<qyliss> if you design for specific use cases, you don't have to do that
<qyliss> e.g. virtio-fs is designed to go host<->guest on one machine, so it can do optimisations like shared memory that 9p can't do because it's more general
<Profpatsch> yeah, I mean if you can assume same-machine (like with wayland), why not use this fact
<pie_> people love throwing out functionality for simplicity <Profpatsch> yeah, but then you have a branch that nobody ever checks
<pie_> which is understandable
<pie_> but is also how you end up with part of todays crap
<pie_> sometihng something tradeoff copout i dont know how to handle
<pie_> theres simplicity from principles and simplicity from leaving stuff out and they arent necessarily the same
<pie_> for the usecases you dont cover you now have to invent another thing
<pie_> </general rant>
<pie_> the only real solution to this is automated testing isnt it? <Profpatsch> yeah, but then you have a branch that nobody ever checks
<Profpatsch> pie_: I would instead opt for a non-branching wayland, and then an “adapter” that can take the fd thing and turn it into network streams
<Profpatsch> If that’s possible
<Profpatsch> so wayland does the fd thing, but exposes enough information so this network bridge can hook into it as client and translate the socket buffers into network accesses
<puck> Profpatsch: do you really want to try and translate GPU buffers into network accesses
<Profpatsch> puck: after you drop it to 10 fps and encode it, maybe? :)
cole-h has joined #spectrum
<pie_> Profpatsch: if that was a component designed non-independently, in step with the rest of the system, id find that acceptable
<pie_> but at this point major disclaimer , i have very limited experience dealing with this and Profpatsch actually has a job
* pie_ goes back to reading to wind down from a very irritating phone call
<Profpatsch> I don’t design performance critical systems with hard latency requirements ;)
<Profpatsch> I wouldn’t say I have have the clue that qyliss has about these things
<Profpatsch> and probably dito puck
<Profpatsch> as in half the clue of puck
<pie_> puck, n. , systems theory -a clue, e.g. "I don't have half a flying puck."
<puck> like, wayland's FDs are actual GPU buffers most of the time
FireFly has quit [Ping timeout: 615 seconds]
FireFly has joined #spectrum
FireFly has quit [Quit: Goodbye]
FireFly has joined #spectrum
FireFly has quit [Read error: Connection reset by peer]
Effilry has joined #spectrum
Effilry has quit [Ping timeout: 619 seconds]
FireFly has joined #spectrum