qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<qyliss> Okay, I'm going to put the new site online
<qyliss> It's not perfect, but it's a lot better than what we have.
<samueldr> heads-up, www.spectrum-os.org seems to point towards qyliss
<samueldr> .net*
<samueldr> the vhost, that is
<qyliss> oh, cheers
<qyliss> samueldr: should be fixed now
<samueldr> confirmed
<samueldr> (I was hoping to see that new site though ;))
<samueldr> if only because I'm curious
<qyliss> I'm updating my configuration for it right now :)
<qyliss> The previous one was just some static files, though. I want this one to actually be a Git repository that checks out the new content when pushed to.
<qyliss> So I need to do things like actually put git in environment.systemPackages on this machine.
<samueldr> is it that the ssh session with which you git push has to have git on its path for that to work? never delved deeply in git fun stuff
<qyliss> Yeah
<qyliss> Sweet: git init --shared=group --separate-git-dir=/home/spectrum/git/www.git /home/spectrum/www && git --git-dir /home/spectrum/git/www.git config core.worktree ../../www && git --git-dir /home/spectrum/git/www.git config receive.denyCurrentBranch updateInstead
<qyliss> Now I can have a git repo at /home/spectrum/git/www.git that will update /home/spectrum/www whenever it's pushed to
<qyliss> Anyway, new website: https://spectrum-os.org/. repo: https://spectrum-os.org/git/www. patches to devel@spectrum-os.org please.
<qyliss> cc samueldr
<samueldr> I was looking :)
<samueldr> hm, never used ch in css, that's a fun one
<qyliss> I use it all the time
<qyliss> Especially useful with monospace fonts
<samueldr> I used em/ex with the same approximate purpose
<samueldr> though I see how with monospace fonts it's a winner
<samueldr> heh, embracing html5's rules about optional end tags I see :)
<samueldr> don't see that often
<qyliss> My thinking is that if I had to close all my tags I'd end up feeling like I needed markdown or whatever
<qyliss> ;)
<samueldr> imo it's entirely fine, and at least it's specced
<samueldr> though, I'm curious how and if each browser deviate from the spec
<qyliss> it's pretty basic stuff i think
<qyliss> doesn't make sense to have a <p> inside a <p>
<qyliss> i'd be surprised if any browser choked on ti
<samueldr> not necessarily this case, but the whole feature
<qyliss> it's only really supported in cases where there's no logical alternative
<qyliss> <p>, <head>, <body>, etc
<samueldr> yeah, I know, but those browsers accrete quirks and misfeatures as time goes on, a less used feature of the spec I wouldn't be surprised for deviations or weirdness to happen at some point :/
<qyliss> idk, the spec is so strict these days, and compatibily is so important to browsers
<qyliss> Okay, I should go to bed, before I start trying to tweak things and breaking them again.
<MichaelRaskin> OK, looking at the main page… «User data remains isolated» sounds a bit like Android's «good luck having a working File manager without jumping through hoops»
<MichaelRaskin> Does Nix still get to have «the»?
<MichaelRaskin> List of mailing list archives works, link to archive of a single mailing list gives 500
<MichaelRaskin> I guess if documentation is always good, you should setup misc-doc repository and say that patches in any format are welcome and pandoc will always save us later?
<MichaelRaskin> Do you want to explicitly invite tester feedback? I guess it is too early to test, of course, but the situation with documentation is the same right now…
<MichaelRaskin> In git view of Nixpkgs it would be nice be able to see latest commits different from upstream, even if not in real time…
<MichaelRaskin> (but maybe that's expensive or annoying to implement)
<MichaelRaskin> You definitely want to mention firejail and maybe bubblewrap/nsjail among security-by-compartmentalization previous systems
<MichaelRaskin> (Saying as someone who runs all Firefox instances and all PDF viewers in nsjail with a ton of helper setup code around it)
<MichaelRaskin> I guess one could also say that convenient support for resetting application state is also a good thing, like with Firefox you can forget about supercookies and only worry about fingerprinting (and maybe provide templates that make fingerprinting among default SpectrumOS Firefox setings more complicated, too)
<MichaelRaskin> Is crosvm any better than kvmtool, by the way?
<MichaelRaskin> «our long-term focus should be on one per application» — one per application instance, right?
<MichaelRaskin> I think virtual block devices are not actually a good way to provide paths between VM and host. Something like 9P sounds better.
<MichaelRaskin> I might want to provide a Firefox instance access to a subdirectory of my source repository, for example…
<MichaelRaskin> I guess once there is a mailing list that is actually alive and with working archives, I will send a description of my current online-jail-generation CLI.
<MichaelRaskin> You do not need users to write Nix code if you could tell them to run spectrum-vm --provide /home/user/src/arxiv-paper pkgsi686Linux.torbrowser/bin/firefox https://arxiv.org
MichaelRaskin has quit [Quit: MichaelRaskin]
pie__ has joined #spectrum
pie_ has quit [Ping timeout: 246 seconds]
<IdleBot_bf4161f7> Oh well, I guess I want to negotiate motivation/design to see how much I would be able to reuse (and to prevent you from committing to unfriendly and unnecessary limitations)
<IdleBot_bf4161f7> (that is MichaelRaskin, via a low-volume chat always-on bot on VPS)
<hyperfekt> virtfs (9p via virtio) is relatively low performance, but should work while in prototype stage. longterm, virtio-fs support in crosvm would be neat to actually achieve native-like interactivity
<lejonet> hyperfekt: even tho I agree with that virtio-fs support in crosvm would be nice, I imagine the applications that actually need some type of performance to be fairly limited, unless the performance of virtfs is in the tens/hundreds of kbps, it should be adequate for quite a lot of applications
<lejonet> I've never really played around with 9p via virtio to have any gauge of the performance
<hyperfekt> lejonet: It tops out around about 100MBps iirc. Definitely very workable.
<lejonet> hyperfekt: oh, that was a lot higher than I expected, then we definitively shouldn't have applications that get "bottlenecked" by that, unless the search time or handling of small files is dreadful
<hyperfekt> lejonet: I have no idea what the IOPS is, we'll see how feasible turning off the guest page cache is when we try it out I guess.
<lejonet> hyperfekt: would be a good idea to do some tests of it, because to my experience, that is where stuff usually fails when it comes to "share" filesystems over network/machine boundries
<IdleBot_bf4161f7> on other goals: run Atom in a no-network VM but allow it to spawn Git in a separate network-connected VM
<ehmry> BTW, git doesn't work over 9P
<ehmry> too many mmap optimizations
<IdleBot_bf4161f7> in a sense, Git does not fully work over ext4. Over ext3 it has better safety guarantees, over ext4 it can trash a repo on hard-poweroff