qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<qyliss> cole-h: oh, I meant to say that the keyboard layout in the VM is set to dvorak by default because that's what I use
<cole-h> Yeah, I figured :P
<qyliss> you can change it in rootfs/default.nix
<qyliss> It would probably also be possible to have spectrum-vm pick it up somehow, but I'm not really sure
<cole-h> +1, thanks.
<qyliss> I assumed it would be just be using this program :P
<qyliss> Having to make it work for other people is a nice problem to have :D
<cole-h> Hehe
* cole-h just started his ~/spectrum.txt notes file
<qyliss> do feel free to add things to the manual too :P
<qyliss> but that's awesome to hear
<cole-h> These note files are mostly just snippets from IRC conversations I'll refer to later when I have time
<cole-h> So, I might translate it to actual documentation once I have some free time and am not doing everything I can to not work on my history paper
<qyliss> oh yes that sounds important
<qyliss> puck: what sort of things would you expect wlroots to send fds to clients for?
<qyliss> the only thing I can find is the keymap, but it feels weird to me that it would just be used for that
<cole-h> btw qyliss once you have some free time, a document for The List would be nice... ;^)
<qyliss> oh right yeah
<qyliss> maybe I can try to do that tonight once I hit a wall with wlroots
<qyliss> minimal VM kernel config is #1 on the list I think
<qyliss> because that would save people long kernel build times
<qyliss> #2 on the list is to implement wl_compositor v4 in Sommelier
<qyliss> Merging upstream Nixpkgs, apologies in advance for the kernel rebuilds
<cole-h> :'(
<qyliss> I will look into some sort of cache maybe
<cole-h> Ask our best friend domen for a cachix hookup? :P
<qyliss> if we're doing something like that i think i'd want to self-host it
<qyliss> (or have it hosted independently by a community member)
<cole-h> Fair enough.
<qyliss> I imagine it's not too hard to set up
<qyliss> Indeed it is not! https://nixos.wiki/wiki/Binary_Cache
<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]
MichaelRaskin has joined #spectrum
cole-h has joined #spectrum
<qyliss> cole-h: cache.qyliss.net, qyliss-x220:bZQtoCyr68idLFb8UQeDjnjitO/xAj52gOo9GoKZuog=
<cole-h> Ooooh
<qyliss> I don't consider this at all stable, or critical infrastructure, or in any way even something that should be trusted
<qyliss> but it is now there
<qyliss> I especially plan on changing the name of the key, because "qyliss-x220" was a bad choice
<cole-h> I was wondering about that
<cole-h> Considering all the other cache keys are "url minus https:// hypen one"
<qyliss> yeah
<qyliss> anyway please be gentle with it, because spare bandwidth on the server gets donated to the tor network :)
<qyliss> it should have all of spectrumPackages and chromiumOSPackages cached
<cole-h> I'll be gentle until at least Sunday (in that I won't be using it until finals are over :D)
<qyliss> hehe :)
<qyliss> Okay, I should make spectrum-vm support adding a directory to the VM with 9p
<qyliss> so I can easily test programs inside it
<qyliss> Oh, right. We added crosvm argument forwarding on the stream, so I don't need to do that
<qyliss> :D
<cole-h> What is 9p?
<qyliss> It's a remote filesystem protocol, basically
<qyliss> sort of like NFS
<cole-h> Oh, okay
<cole-h> My first thought was something plan9 related
<qyliss> but it's only really good for if you aren't going across a real network
<qyliss> it is from plan9!
<qyliss> it's the plan 9 remote file system protocol
<cole-h> Well then, I as kinda right :D
<cole-h> s/as/was/
<qyliss> QEMU and crosvm and probably other things use 9p for sharing directories with VMs
<qyliss> Which it works very well for
<qyliss> Although it's on its way out in favour of virtio-fs, which is specifically designed for VM filesystem sharing
<qyliss> But that's very new and not well supported yet
<cole-h> "on its way out" as in "will be removed"? I hope it's not before virtio-fs has the kinks worked out
<qyliss> oh no
<qyliss> I imagine it'll be supported forever
<qyliss> It's just, virtio-fs is the future
<cole-h> Oh, just as in "virtio-fs is the future"
<cole-h> Yeah
<qyliss> :D
<cole-h> "The future is now, old man!"
<qyliss> e.g. crosvm has the very beginnings of virtio-fs support, but it's not usable yet
<MichaelRaskin> 9p is not really going anywhere
<qyliss> virtio-fs has nice benefits like shared memory pages between VMs, I believe
<MichaelRaskin> (of course everyone uses 9p2000.L, the Linux-specific version)
<qyliss> Nix uses 9p for something as well but I forgot what
<qyliss> NixOS tests maybe?
<MichaelRaskin> NixOS tests of course mount store via 9p
<tazjin> it's for qemu stuff
<MichaelRaskin> Well, it's built into Qemu
<tazjin> lol, this is mentioned on the 9P wikipedia page: https://en.wikipedia.org/wiki/9P_(protocol)#Server_applications
<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...
<qyliss> [ERROR:src/linux.rs:1734] child virtio-pci (virtio-9p) (pid 22601) died: signo 17, status 31, code 2
<qyliss> so that's not so good
<qyliss> works without the sandbox though
<qyliss> wonder if there's a seccomp bug
<MichaelRaskin> Ohhh, so it's not just their sandbox conflicting with nsjail?
<qyliss> doesn't seem to be
<MichaelRaskin> I thought I was doing isolation wrong, grabbed rust-9p into https://github.com/7c6f434c/7c6f434c-configurations/blob/master/crosvm/rust-9p.nix and used it
<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> It's abandoned upstream, though, afaict
<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?
<qyliss> cool, thanks!
<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)