<qyliss>
> As nix-serve is capable of serving only on IPv4
<qyliss>
uhh
<cole-h>
Seems like an odd constraint..
<multi>
ah
<qyliss>
doesn't matter since it's behind nginx anyway
<multi>
yeah
<multi>
that's a thing
<qyliss>
weird though
<multi>
it's a limitation in the plack/psgi running which nix-serve uses iirc
<multi>
i did look into this briefly once
<qyliss>
how come?
<multi>
s/running/runner/
<qyliss>
(just curious that the person who knows about this is a noted non-Nix user :P)
<multi>
i don't recall the detail, but it's entirely possible that it was some regex which looked for addresses in v4 format, splitting on colon for port number etc
<multi>
ah
<multi>
a nixos-using friend asked me to take a look at it
<multi>
because i know more perl than they do
<multi>
yep
<multi>
perlPackages.starman
<multi>
s/\.s/.S/
<multi>
(starman in debian)
<multi>
line 74ish of lib/Starman/Server.pm, if you're curious
<multi>
alternatively, patch default.nix in nix-serve to use a different plack/psgi executor
<multi>
or just stick an nginx in front of it :P
<qyliss>
Yeah :P
<qyliss>
I might have a go at setting this up while I wait for my kernel build
<multi>
:)
<cole-h>
qyliss: Will your server be able to handle the abuse as a cache?
<cole-h>
Considering cloning nixpkgs was out of the question the other day... ;P
<qyliss>
Yeah I think a cache will be fine, because that's unlikely to be CPU bound
<qyliss>
it's fine for, y'know, serving stuff
<qyliss>
less fine for heavy compute :P
<cole-h>
Serving a clone is heavy compute?
<qyliss>
Yeah
<cole-h>
Oh, I guess it has to compress
<qyliss>
Exactly
<qyliss>
And that (by default) uses a huge amount of memory
<qyliss>
It doesn't now because I manually GCed
<qyliss>
And I'm going to automate that
<qyliss>
So then the compression will happen once up-front, rather than for every clone
<qyliss>
okay, in theory I now have a binary cache
<qyliss>
hmm, shame I can't sign paths with a yubikey or whatever
<qyliss>
cool, copying some builds into the cache
<qyliss>
nix copy is very slow though so it'll take a bit
<qyliss>
ah, it's just ssh-ng that's slow
julm has joined #spectrum
cole-h has quit [Quit: Goodbye]
<puck>
<qyliss> puck: what sort of things would you expect wlroots to send fds to clients for? <- copy/paste, drag/drop?
<puck>
at least, according to the wayland protocol xml
edef has quit [Ping timeout: 260 seconds]
edef has joined #spectrum
nixbitcoindev has quit [Remote host closed the connection]
nixbitcoindev has joined #spectrum
<pie_>
do you guys think i could pitch making a qt binding generator to NGI or something -_-
<pie_>
i figure i should try to get some funding for tihs thing if im struggling with it anyway
<pie_>
*haskell
<qyliss>
pie_: I think that's unlikely to fit into the NGI themes
<pie_>
yes i iddnt think so xD
MichaelRaskin has quit [Ping timeout: 264 seconds]
<ehmry>
9p is what made plan9 a distributed OS, everything was a file, and all file-system interaction was done through 9p, so anything could be done transparently over a network
<MichaelRaskin>
What is nice with 9p is that it only needs stream sockets…
nixbitcoindev_ has joined #spectrum
nixbitcoindev has quit [Ping timeout: 240 seconds]
<qyliss>
got a virtio 9p thing mounted, tried to ls, and...
<MichaelRaskin>
Nice thing is that unpfs nicely serves on unix!/path/to/socket!0
<MichaelRaskin>
(command being ["${rust-9p}/bin/unpfs" "unix!${socket-9p-dir-internal}/${socket}!0" path])
alj[m] has joined #spectrum
<MichaelRaskin>
qyliss: is the VM-to-VM communication currently Wayland-oriented, or can I use it as a host-to-VM socket?
<MichaelRaskin>
I guess I could setup a rust-9p no-IP-networking demo with CrosVM. I remember you wanted an option for a filesystem not backed by storage with a notion of .., and for that it would be nice to have a full socket-based 9p support.
leah2 has quit [Ping timeout: 260 seconds]
<qyliss>
MichaelRaskin: you can already do host-to-VM socket I think
<qyliss>
If you can modify your program to do some ioctls instead of send/recv you can definitely do it
<MichaelRaskin>
ioctl's are needed inside the VM?
<qyliss>
they are for virtio wayland
<qyliss>
I think there might be a socket-compatible thing but I'd have to look for it
<MichaelRaskin>
I hoped to delay learning Wayland as long as possible…
<qyliss>
There's no need to learn Wayland
<qyliss>
virtio_wl is a protocol-agnostic socket transport
<MichaelRaskin>
That's true, but I expect all the upstream code comments to be from «you obviously know wayland» point of view
<qyliss>
the mistake you are making there is expecting there to be upstream code comments :P
<qyliss>
There is a program you can run inside the VM that proxies virtio wayland to a normal socket
<MichaelRaskin>
… trying to decide whether to feel relief or not
<qyliss>
I think your options are to either use tcp, or that
<qyliss>
That program just does the virtio_wl ioctls, and copies things into a unix socket inside the VM
leah2 has joined #spectrum
<qyliss>
You'll also need a guest kernel with virtio_wl, of course
<qyliss>
Actually, the better way would be to use vsock
<MichaelRaskin>
On the one hand, I kind of know that you will at some point patch virtio_wl into virtio_plain_socket
<qyliss>
That's vsock
<qyliss>
Almost
<MichaelRaskin>
Or maybe indeed clean-room something based on vsock
<qyliss>
I think the best way to do host socket -> guest socket would be to socat to vsock
<MichaelRaskin>
Yes, socat to vsock inside sounds nice
<qyliss>
But I haven't used vsock with crosvm, so I don't know if you have to do anything special for that
<qyliss>
Try it and see, I guess
<qyliss>
--vhost-net might be helpful
<qyliss>
Firecracker can do vsock without involving a host networking stack
<qyliss>
I intend to port that to crosvm at some point
<qyliss>
(The interfaces for implementing that sort of thing are still largely identical between the two)
<MichaelRaskin>
vhost-net definitely wants and fd it will use as tap; it is true that I only tried it with a true namespaced tap
<MichaelRaskin>
Hmmmmm
<alj[m]>
Hello everyone! I'm a long-time QubesOS user and I just read about Spectrum like 2 hours ago. I just wanted to tell you all, that I'm very excited this project exists and spent the last two hours reading about spectrum, Power9 and more. Thank you so much for making this real!
<qyliss>
alj[m]: hello! That's awesome!
<qyliss>
I should update the mention of POWER9 on the website
<qyliss>
because it turns out there's a (relatively small) amount of VM work that would need to be done for POWER9 before we could support it
<qyliss>
Until then we can't however
<MichaelRaskin>
Well, to be fair there is a larger amount of VM work before you just generally have something you are willing to call PoC in general, regardless of arch
leah2 has quit [Ping timeout: 272 seconds]
<qyliss>
that's true
<qyliss>
but I think I'm capable of doing most of the rest of the VM work
<alj[m]>
btw is there any other way to obtain POWER9 without buying the Talos 2?
<qyliss>
not really, unless you want to go through IBM sales
<MichaelRaskin>
Which can be expected to be much more expensive and might also be longer.
<alj[m]>
i really wish more people would push Power9 and make it a little more attainable...
<qyliss>
Yeah :/
<qyliss>
You can also buy a Blackbird, from the same company as Talos
<alj[m]>
qyliss:
<alj[m]>
* qyliss: are you the author?
<qyliss>
Yes
<alj[m]>
> qyliss: are you the author?
<alj[m]>
Does me editing the last message show up over Freenode? 😅
<alj[m]>
You are amazing!
<MichaelRaskin>
Yes, with an asterisk prefix
<qyliss>
thank you!
<MichaelRaskin>
Like in non-edit-supporting Matrix client
<qyliss>
alj[m]: may I ask how you found out about Spectrum?
<alj[m]>
May I ask, where I can find your streams?
<qyliss>
I post the URL in here shortly beforehand
<MichaelRaskin>
Usually a rough estimate of time is discussed here a day or two before
<cole-h>
Or rather, *I* post the URL shortly beforehand, after qyliss says "it should be the same as last time" hehehe
<alj[m]>
I see! I understand it there is no "recording" aka VOD?
<qyliss>
Yes, indeed :)
<qyliss>
No, they're not currently recorded
<MichaelRaskin>
Current streams would need to be recorded BBB-style, in sync with chat
leah2 has joined #spectrum
leah2 has quit [Ping timeout: 272 seconds]
<FireFly>
or just recorded, then with IRC chat rendered from logs and composed with the video afterwards.. might be easier
<FireFly>
(though I guess with just plain IRC logs that just gets you second granularity.. but eh, good enough probably)
<qyliss>
Yeah, there's a 7-second video delay anyway
<FireFly>
... I geuss the easier thing would just be for qyliss to have an IRC client (perhaps a separate one that's only in here for privacy reasons) in view of the stream
<qyliss>
screen space is pretty limited...
<FireFly>
*nod* true
<qyliss>
I'm not sure I'd actually want the streams to be recorded?
<qyliss>
might make me more nervous about actually doing them
* FireFly
nods
<FireFly>
I was wondering about that previously (since I missed most of the first stream), but figured it was a conscious decision
<qyliss>
well, it's one of those things where I would have to make a decision either way, but laziness provides me with a default answer so I just go with that
<MichaelRaskin>
I think it was more of a conscious decision not to over-invest into setting things up
lukegb has quit [Ping timeout: 258 seconds]
<MichaelRaskin>
Given that even Nginx live-re-wrapping for in-browser watching has not been implemented
<qyliss>
well, nobody has ever even requested that, iirc
lukegb has joined #spectrum
<MichaelRaskin>
I think the only way to measure interest is to declare that you will accept an Nginx location to do that
leah2 has joined #spectrum
<alj[m]>
Is there any way to use sway with spectrum? I read that WayFire is being patched/extended for some specific memory allocation behaviour which to me sounds like this rules out all other wayland compositors, right?
<qyliss>
too early to say
<qyliss>
the memory allocation stuff will likely be in wlroots rather than Wayfire, so could also apply to sway
<qyliss>
But, the reason for using Wayfire is that we can write plugins to do stuff like coloured window decorations, like Qubes
<alj[m]>
qubes supports i3wm doing colored window decorations (I'm looking at them right now :D ) in a repo dedicated to some qubes-specific i3 patches
<Shell>
also fairly sure it'd be possible to implement i3-style window management in Wayfire? (there's already a tiling plugin in there)
<alj[m]>
there is one in there, but I personally would not look forward to reimplementing sway as a Wayfire plugin
<alj[m]>
I do think implementing window decorations in sway would be much easier. But I guess thinking about high-level, late-game stuff like this is not really important right now
<qyliss>
Wayfire has an actual plugin API, sway would have to be patched.
<qyliss>
but sure, in principle you could probably use any compositor you wanted :)
<qyliss>
(and especially any wlroots compositor should be fine)
<MichaelRaskin>
One could hope for smithay, or at least something that doesn't routinely cast pointers to pointers to a strictly larger struct…
<MichaelRaskin>
But then Smithay should become an actual compositor first
<qyliss>
Yes, a Rust compositor at some point would be excellent
<cole-h>
RIP Way Cooler
<MichaelRaskin>
Way Cooler would not really be a Rust compositor
<MichaelRaskin>
All interesting pointer manipulation from wlroots would still be there (and it does _more_ interesting stuff with pointers than a typical C library)