<cole-h>
Which big green button does that? Rebase or squash?
<cole-h>
(I'm assuming rebase)
<qyliss>
Does what, exactly?
<qyliss>
rebase produces a totally flat history
<cole-h>
Makes history nice and clean
<cole-h>
like that log
<qyliss>
Yeah, that's the equivalent of Google and I both using rebase merges, but when I merge in their code I use a merge commit
<cole-h>
OK, nice. When I merge stuff for borg, I will use the green "rebase and merge" button, then :D
<cole-h>
(not that it makes much of a difference)
<qyliss>
Merge commits, IME, only make sense for long-lived branches where the point of divergence matters
<qyliss>
But that's a fairly controversial opinion
<cole-h>
Do you have an example of that? Hard for me to visualize.
<qyliss>
If I was in charge of Nixpkgs, I'd use merge commits for merging staging-next into master, and staging into staging-next, etc.
<qyliss>
But not for some PR updating a package, for example
<qyliss>
Does that make sense?
<cole-h>
Yeah, I see now.
<cole-h>
What about haskell-updates?
<qyliss>
I'd merge that, probably.
<cole-h>
I think I'd lean towards a merge for that, too
<qyliss>
Because it's a long-lived branch that's periodically merged in
<cole-h>
OK, cool. Thanks for solidifying some git stuff in my brain :D
<cole-h>
(Well, we'll see if it's actualy solidified)
<qyliss>
This follows pretty naturally from email git, fwiw.
<cole-h>
True.
<qyliss>
Like, if I receive a patch, I'll just apply it straight to master. It would be weird to make a branch, apply the patch, and then immediately merge --no-ff that branch.
<qyliss>
But none of this is all that important, in the scheme of things :)
<cole-h>
True, more just house-cleaning.
<qyliss>
(And so naturally it's hugely controversial)
<cole-h>
Heh
<qyliss>
Okay, so in theory, I've hooked up the memfd server to crosvm
<qyliss>
but I have so far tested none of it so it will almost certainly not work
<qyliss>
(yet)
<qyliss>
And indeed, it did not work :)
<tazjin>
I don't actually think I believe in long-lived branches anymore
<qyliss>
I don't think I do either in most cases
<qyliss>
But, say, spectrum crosvm master is a long-lived branch to some extent
<qyliss>
I guess you could distinguish that as something that will never be wholesale merged, though.
<qyliss>
memfd server isn't working because i tried to allocate 8031938417022231912 bytes of memory
<tazjin>
you might find that difficult to achieve without swapping
<qyliss>
indeed
cole-h has quit [Quit: Goodbye]
<hyperfekt>
> tazjin: I would like a button for "only show me spectrum related log messages" in the nixpkgs tree
<hyperfekt>
oh god i wish this was a thing. seems strange to me still that there isn't a unique branch identifier in git. git could then add that to the commit's notes to know where it came from
<hyperfekt>
i really like this. so you rebase your new commits onto the latest commit before your commits, and then you do merge commits every time you add commits from upstream?
<hyperfekt>
8e55e9cole-h> What about haskell-updates?
<hyperfekt>
if you merge that peti can't force push it anymore lol
<MichaelRaskin>
If only Git kept the «branch of original commit»…
<Shell>
branches aren't actually a thing in git, is the problem
<Shell>
they're just... a reference to a commit which gets updated occasionally.
<MichaelRaskin>
Branches are a thing, it's just Git that chooses not to sync information about them, and not to store it for too long
<qyliss>
hyperfekt: well, I just commit directly to my master, and then merge commits for merging with upstream
<qyliss>
but when I am ready to pull in, say, the stuff currently on the interguest branch, I'll rebase that
<qyliss>
Okay, let's figure out why the VM thinks the virtio_wl send has failed when it hasn't.
<qyliss>
I'm so excited
<qyliss>
This is so close to working
<qyliss>
I think it works!
<qyliss>
VM connects to a virtio_wl socket called __crosvm_memfd, sends a message with a debug name and a size, memfd server on host allocates a memfd, and sends it back to the guest through virtio_wl
<Shell>
very nice.
<Shell>
qyliss: pls remember to limit how much memory stuff can allocate through this :p
<qyliss>
yes :P
<qyliss>
tbh probably should just run every crosvm in a cgroup, and do memory limiting that way
<Shell>
mmm
<qyliss>
but a specialised small limit for this would be reasonable too
<qyliss>
anyway, we learned last night that it's already limited to at least <8031938417022231912 bytes :P
<Shell>
XD
<qyliss>
man I am looking forward to writing TWIS tomorrow
<qyliss>
I've been thinking a lot about this sort of thing recently. Very relevant for us. Nice to find a paper on it.
<alj[m]>
i also thought about microkernels while reading about spectrum. there is a firewall microkernel for qubes for example, that eliminates having to create and run a full sys-firewall VM and only requires 32 MiB. It was written in oCaml and based on "mirage" if i recall correctly
<qyliss>
Yeah that sounds right
<qyliss>
MirageOS is a popular microkernel written in OCaml
<pie_>
what a coincidence c:
<Shell>
MirageOS is a unikernel, not a microkernel.
<Shell>
it is written in ocaml though.
<MichaelRaskin>
Then there are NetBSD rumpkernel based things.
<qyliss>
Sorry, yes
<Shell>
MichaelRaskin: where you can't call fork(), iirc.
<qyliss>
Unikernel
<alj[m]>
ah terminology issues, I apologize
<qyliss>
alj[m]: this paper is also about unikernels, though, so MirageOS is a relevant example :)
<Shell>
also their API is not actually quite the NetBSD userland API, which makes the whole thing kinda hard to use.
<pie_>
funny thing now that i thnk about it, one of the arguments back in the day against micro/whatever kernels was slower ipc as opposed to monolithic kernels or somesuch right? and yet here we are using heavyweight VMs
<pie_>
(with a lot of hardware support i guess)
<qyliss>
> we find that [carefully-configured Linux, with program running in kernelspace] outperforms microVM and at least one of the reference unikernels in all of the following dimensions
<alj[m]>
just fyi my sys-firewall is doing nothing except forward the connections and is using 380MiB right now. it plain sucks. same for my vpn VMs and other one-service stuff. If there was a way to fix that, that would be amazing
<qyliss>
I suspect we can do better :)
<Shell>
pie_: also, microkernels have got a lot more micro and a lot faster. seL4 is nice stuff. Genode builds on it, esp in their Sculpt desktop operating system, and some of what they're doing is clever but not exactly *useable* in the way that Spectrum is likely to be.
<alj[m]>
So far Spectrum promises to fix all issues/fullfill all dreams I had with Qubes, so that would be another amazing addition
<qyliss>
The VMs I'm working with at the moment actually have a maximum memory size of 256M
<qyliss>
We might have to raise that, but I haven't run into memory issues yet
<alj[m]>
omg are you serious?
<alj[m]>
thats amazing
<qyliss>
Bear in mind they're not doing much
<qyliss>
Running a Wayland compositor and a terminal
<alj[m]>
better than the 400M minimum for qubes stuff
<MichaelRaskin>
Shell: well, there is work on running lightweight Linux VMs inside Genode for both drivers and applications (I think some things work)
<qyliss>
But 300M+ for a firewall does seem like a lot.
<qyliss>
also important to remember you'll be running more VMs at once with Spectrum than Qubes
<alj[m]>
when are you able to test more demanding stuff like firefox?
<alj[m]>
one VM for every program/application, right?
<qyliss>
That's the idea.
<Shell>
MichaelRaskin: I am aware of this work.
<qyliss>
I could in theory test firefox right now, but I suspect getting it running would be tricky.
<alj[m]>
and VMs are grouped into security contexts, that define filesystem access and similar stuff?
<qyliss>
alj[m]: that's sort of vague right now
* pie_
imagines spectrum + raptor
<qyliss>
ideally in most cases VMs will request and be granted permissions case-by-case
<pie_>
where are the massive government grants smh :)
<qyliss>
e.g. you want to open a file in LibreOffice, so you grant a VM access to that one file through a trusted file picker
<alj[m]>
Don't know how i think about that yet, I would have to try it with my workflows and such
<alj[m]>
pie_: what is raptor?
<Shell>
alj[m]: in theory, this system will integrate with existing toolkits via the same mechanisms as Flatpak's sandboxing (known as xdg-desktop-portal). GTK3, Qt, and large applications like Firefox have support for parts of it that just have to be enabled for applications to use a Spectrum-supplied filepicker whenever they would currently show a GTK/Qt one.
<alj[m]>
gotcha
<alj[m]>
i work almost exclusively from terminal but i guess that would be rather trivial to do too
<Shell>
there's definitely going to be a significant degree of terminal support.
<Shell>
otherwise qyliss couldn't work on... anything, tbh. :p
<alj[m]>
terminals are great :3
<Shell>
terminals are very good for some things and very poor for others. :)
<alj[m]>
ofc :D but i generally prefer doing stuff with the keyboard instead of clicking on stuff and terminals are great at that ;)
<alj[m]>
I also despise apps and websites that are not usable without mouse.
<Shell>
they're usually not useable for people with screenreaders either, which is the sucky part.
<alj[m]>
agreed
<MichaelRaskin>
Is there any non-sucky part about (granted, non-image-manipulation) applications with poor or no real mouse support?
<MichaelRaskin>
* non-mouse support
<FireFly>
what about games? (depending on genre)
<MichaelRaskin>
Some of them have control scheme that is effectively image manipulation…
<MichaelRaskin>
Some of them do have keyboard-control mode!
<MichaelRaskin>
Some need to ban aimbots which means that a sucky UI is a part of the challenge
<qyliss>
Nice to know that per-application kernel configuration doesn't result in any real performance win (from the paper)
<MichaelRaskin>
Nice to check but not surprising
<qyliss>
Yeah
<qyliss>
This paper is pretty much confirming my instincts
<qyliss>
but still nice to have that confirmation
<MichaelRaskin>
There is a ton of «yeah, but how to keep this off the hot path?» discussions for every feature
<cole-h>
qyliss: Update: I am done with finals :D I'll see what I can work on later this week (gonna attempt to switch to NixOS sooner rather than later)
<qyliss>
Nice! :D
<alj[m]>
congrats cole!
<qyliss>
congrats cole-h :) looking forward to working with you
<cole-h>
<3 all
<qyliss>
It's also nice to read that system call overhead isn't even that high for general use
<qyliss>
Which means most of the benefit is just coming from kernel configuration
<qyliss>
(And that's nice because kernel-mode linux isn't practical, but a good kernel config is)
<hyperfekt>
alj[m]: we're running on kvm so weget kernel same-page merging, which i'm expecting to save quite a bit of memory
<qyliss>
> Alharthi et al. study 1530 Linux kernel vulnerabilities and show that 89% of these can be nullified via configuration specialization
<alj[m]>
hyperfekt: I'm all here for saving memory. I hate it when i cant open my f**king gpg vm or smth else small
<alj[m]>
I just wanna send a darned email okay PC?! I already have 16Gigs RAM leave me alone
<hyperfekt>
qyliss: this ties back in with my mention yesterday about teto wanting to specify needed kernel config for packages but eelco rejecting it with the comment that w ehave o way to verify that anyway
<alj[m]>
> > Alharthi et al. study 1530 Linux kernel vulnerabilities and show that 89% of these can be nullified via configuration specialization
<alj[m]>
that is crazy
<hyperfekt>
alj[m]: i actually upraded to 32gb when i still had qubes and now i have nixos and live in ram luxury
<qyliss>
That was a good paper
<alj[m]>
I guess I'm waiting for Spectrum for a OS switch. I'd love to nix it up, but its just kinda impossible (read impractical) with qubes...
<alj[m]>
qyliss: That means you have a very early beta (or even alpha) tester in me, if you want
<hyperfekt>
actually i think most of the value of spectrum is going to be in the integration stuff. qubes is notoriously useless for day-to-day use because it's severely lacking in that part. crosvm is just what's going to enable that
<hyperfekt>
useless as in most people have very big domains and everything gets compromised. i basically had like the driver ones, and then used a trusted one for keys, one for my applications and disposable ones for untrusted stuff
<qyliss>
When I used Qubes I had very small domains, but then it was very difficult to use and then I gave up
<alj[m]>
I'm trying to keep domains small too, but its hard
<qyliss>
Yeah
<qyliss>
I think that domain management is not a thing that comes natually to humans
<MichaelRaskin>
Can confirm, having per-application containment with easy passing-in of necessary directories makes runnning everything scary inside per-instance containers quite acceptable
<qyliss>
DispVMs in Qubes were very nice
<qyliss>
Those were my favourite part of it
<alj[m]>
also updating the templates is a nightmare. first i cobbled together a saltstack script to run updates, then they provided a gui for that, but in the end I'm still spinning up a management VM for every single template. and there isnt even a package caching mechanism built in, i had to do that myself
<qyliss>
What eventually got me to stop using Qubes was that I broke a template, and decided to reinstall
<qyliss>
And then never managed to get the installer to work again
<alj[m]>
the anaconda(?) based installer is hell.
<alj[m]>
and the second i heard about nix and NixOS I was like "damn I wanna configure VMs like this"
<alj[m]>
Again: the second Spectrum is usable I'll at least set up dual boot if not switch completely
<MichaelRaskin>
Wrong goal! A better goal is «as soon as isolation looks like it could in principle be working, I will try migrating my workflows into Spectrum-tooling VMs»
<alj[m]>
um, yeah i guess?
<cole-h>
Best goal: "as soon as I have free time, I will contribute to Spectrum"
<qyliss>
using Spectrum-tooling VMs on Qubes or whatever is likely to be pretty difficult, I'd say
<qyliss>
But I can't really substantiate that.
<MichaelRaskin>
qyliss: well, for testing inside a domain with Nix installed it should be fine maybe?
<qyliss>
difficult to say I think
<alj[m]>
I'd love to contribute but I don't know what i can add (and if i know the necessary programming languages)
<qyliss>
cole-h: I wondered if you might be interested in doing the chromiumOSPackages update when those release in a few days? There's an updateScript, so it's mostly fixing up patches and stuff.
<cole-h>
I hope you don't feel like I've bullied you into it -- I was just letting you know there are more ways than contributing code!
<MichaelRaskin>
Given that the overall design has not been discussed, and apparently also doesn't exist in qyliss' head, early testing might be pretty valuable…
<cole-h>
qyliss: Sure, I could give it a shot. Would you mind giving a brief overview of what that would entail? (Especially how to use the `updateScript` attr would be useful)
<qyliss>
cole-h: nix-shell maintainers/scripts/update.nix --argstr path chromiumOSPackages is the official way, that should work for any package in Nixpkgs with an updateScript
<qyliss>
But this particular updateScript happens to be written so that you can also just run pkgs/os-specific/linux/chromium-os/update.py if that's easier to remember
<qyliss>
Then do nix-build -A chromiumOSPackages -A spectrumPackages and check everything still builds, basically.
<qyliss>
(It probably won't, there'll probably be patches I backported that no longer apply, etc.)
* cole-h
wishes he paid closer attention to that update stream
<cole-h>
lol
<qyliss>
And then you can try to fix those up yourself, or we can work through them together
<qyliss>
fwiw I just removed the packages in the update stream that were really problematic
<qyliss>
since they weren't actually used any more
<cole-h>
Like minigbm? I tried to run the script (and hadn't pulled recently) so it failed on that package :D
<cole-h>
(Works now that I pulled... lol)
<qyliss>
Oh, no, that was me forgetting to actually commit the default.nix file for that package
<cole-h>
Hehe
<cole-h>
When will this chromiumOS update appear, roughly?
<cole-h>
OK, cool, thanks. If you haven't heard anything from me, feel free to ping. I'm west coast US, so there's a little bit of a time difference :P
<qyliss>
So, basically, just try to run the update script every day from May 19. At some point it'll update, which you can see with git diff :).
<alj[m]>
I'm confused, How are Chromium OS and Chrome browser related to each other?
<qyliss>
alj[m]: they're not really, except organisationally
<qyliss>
So they release at the same time, and have the same version numbers and stuff
<alj[m]>
gotcha
<cole-h>
"at the same time"-ish :P
<qyliss>
Yeah
<qyliss>
alj[m]: did you already read enough to understand what Chromium OS has to do with Spectrum?
<qyliss>
I can explain if not, I'm not sure how much this is actually mentioned on the website
<cole-h>
qyliss: Never knew about the update script. Pretty nifty.
<alj[m]>
Spectrum is using crosvm the "VMM" from chromium OS and some kernel stuff
<cole-h>
(update script being maintainers/scripts/update.nix)
<alj[m]>
right?
<qyliss>
Correct :)
<alj[m]>
also the virtio WL thing
<alj[m]>
^_^
<qyliss>
cole-h: it's quite neat, especially for updating multiple packages at once
<qyliss>
I think it can do stuff like do everything you're a maintainer for
<cole-h>
I wonder if I could leverage that for when I eventually get around to patching in all the binaries in fish's many scripts...
<alj[m]>
i wish i new Rust well enough to help out :(
<cole-h>
It's never too late to learn :) I'm sure some "easy" stuff will pop up eventually, as more work is done.
<alj[m]>
I'll keep my eyes peeled.
<alj[m]>
Btw any plans to upgrade to something like gitea?
<alj[m]>
or move to another git instance like github?
<alj[m]>
I completely understand all and agree with most of your arguments. Since I'm not used to using git like this, it still kinda feels like a step back in time...
<qyliss>
Is there anything in particular you're missing, out of curiousity?
<alj[m]>
not sure, but I'll get back to you when I can crystallize my thoughts
<qyliss>
okay :)
<MichaelRaskin>
alj[m]: also it _is_ step in time, with the intention of throwing away the results of unfortunate later events
<alj[m]>
everything has its pros and cons IMO
<qyliss>
of course :)
<qyliss>
fwiw anybody is of course welcome to mirror the sources elsewhere
<qyliss>
Sleep time I think
<qyliss>
tomorrow I'll try to sandbox the memfd server
<qyliss>
then integrate it into wlroots
<qyliss>
(right now I'm just testing it from a little test C program)