From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on atuin X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, RDNS_NONE,SPF_HELO_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: from [127.0.1.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 5F552AB30; Thu, 17 Oct 2019 11:37:21 +0000 (UTC) Received: from out4-smtp.messagingengine.com (unknown [66.111.4.28]) by atuin.qyliss.net (Postfix) with ESMTPS id DC1A7AB98 for ; Thu, 17 Oct 2019 11:37:18 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 235892208A; Thu, 17 Oct 2019 07:37:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 17 Oct 2019 07:37:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h= from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=fm1; bh=kqdGq8RAqmeIlWw3nzWXfeLZAM aXCMZ/2wXAeuU5Qzw=; b=bBINvD2eTdKHbweEIrr6qleB7wbHebIcDboQRIXIr9 n37CYWi15QeiOdUab66SHC3xbsEY7HfzKFtp641GmJLcgKoHndYtsQix7vzcXDYu sDZaH4oYyfr86AIt/Fu4+Yc05DnhURTZIemoRtO1Fz2If+aLvrcylk6PByPC9uNP jFRFKjCxiVrbO3XqEG3SXFZxyYWU2fJMI+g23O4BHsrCeKqv3s7LEjkFXzrFFZFn kT70f1TNnVO0t/aEMmzEe9dqBJL1FcpSTBVwH9kl8iFfoiJV50ydq4Vd1+9Bdec1 oWpRe3EHh9RHn4yjKzcR0d7OgGFAXsKZAvvMDrdvcmvg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=kqdGq8 RAqmeIlWw3nzWXfeLZAMaXCMZ/2wXAeuU5Qzw=; b=JKOYLGXVNsLiTqUNu9/IrX HmG+pZtCovnolS8pn3iF72FjLIuxF6/BMzuntMzFcinfixFnzWqZvkE6FsavkN87 nEl4P6eY+Tl+UYN0yWmzawDUHgjpJunm2GQBlvRURl3tqjWViWl5jwOobYq1UBNw aqgPIpXpETEnbxb6GJ/E1H0l0GRf68van5vdelAdMGfrJzo1WBuUZ+qyFxWCAB7u XPKBPn8CysPLXXLhPJefY95gwpePgZ5+6EXTOMZEZqnKnOCFQK2Dxky/C730c/4F OjPhlzsTZY1/NiID/WUoOVZBZXhqPMlWrfpGCUSqtdPkuCdC/jbUHd//rAnaHfUw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeejgdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufgjfhffkfggtgesghdtreertd dttdenucfhrhhomheptehlhihsshgrucftohhsshcuoehhihesrghlhihsshgrrdhisheq necuffhomhgrihhnpehnihigohhsrdhorhhgnecukfhppeekgedrudekgedrvddvgedrud ehtdenucfrrghrrghmpehmrghilhhfrhhomhephhhisegrlhihshhsrgdrihhsnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from x220.qyliss.net (p54b8e096.dip0.t-ipconnect.de [84.184.224.150]) by mail.messagingengine.com (Postfix) with ESMTPA id 7801180059; Thu, 17 Oct 2019 07:37:01 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id D5251140049; Thu, 17 Oct 2019 11:36:59 +0000 (UTC) From: Alyssa Ross To: 7c6f434c@mail.ru, devel@spectrum-os.org In-Reply-To: References: <87pniwb7tp.fsf@alyssa.is> <87pniwb7tp.fsf@alyssa.is> <20191016202845.21132-1-hi@alyssa.is> <20191016202845.21132-1-hi@alyssa.is> Date: Thu, 17 Oct 2019 11:36:57 +0000 Message-ID: <87k193bo2u.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: AIGN4V2MASUC5XJZWJEIUO5V3RNPYN32 X-Message-ID-Hash: AIGN4V2MASUC5XJZWJEIUO5V3RNPYN32 X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: jpo@vt.edu X-Mailman-Version: 3.2.2 Precedence: list Subject: [spectrum-devel] Re: [PATCH www] design: state subdirectories, not block devices List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Raskin <7c6f434c@mail.ru> writes: >>> Given that it is sometimes convenient to spawn multiple VMs with almost= =20 >>> identical settings on the fly (e.g. Firefox instances but with different >>> state directories for downloads/uploads), should we commit to define >>> a CLI layer for starting VMs (probably similar to the underlying VMM >>> software CLI, but adapted to the notions we want to use), with the=20 >>> Nix-based management of VM fleet built on top of this CLI? >> >>Yeah, I've been thinking about this too and agree. We should have a nix >>run analogue for temporary VMs. It would be nice for scripts that use >>multiple VMs to be able to start them on the fly as well. (But we >>should definitely not have a nix-env -i analogue, because there should >>be no hidden state on a host.)> > > I think it is better to avoid evaluation, actually. > > So I want a level where there is a Spectrum Profile Generation with=20 > named prebuilt VMs complexity levels (console-only, for stuff like=20 > ImageMagick on images downloaded from 4chan; GUI-but-no-HW, to remove=20 > GPU attack surface and guarantee lack of sound; full-GUI, which is still > not guaranteed to get access to everything, of course), and prebuilt=20 > application sets (just buildEnv stuff, no fancy stuff). > > Then I say: > > spectrum-vm --base full-gui --net nat --app firefox-esr-js-profile \ > --app gvim --dri card0 --rw-directory user:conf/nixcon-2020 \ > -- firefox https://nixos.org/ > > This should not do anything in run time that can be safely cached. VM is > prebuilt, application bunches are prebuilt and just mounted into store, > even Firefox profile is prebuilt and changes are going to be discarded. > No builds, no Nix evaluations. > > (yes, there is also the annoying question of RAM amount management, not > sure how to do it well, ballooning would be the nicest thing if it is=20 > feasible) I think I had imagined you building a "firefox" VM, but yeah, maybe there's really no point to that. In which case, I'd be happy for this sort of thing to be handled outside of Nix. >>> I suspect that building things the other way round is not much simpler, >>> but building a single VM image usable with slightly different settings >>> will have smaller overhead than evaluating a Nix expression for each >>> extra VM. >> >>Maybe. I'll have to think more about that. tbh I think we can assume >>that the evaluator will get faster at some point (because there's big >>potential for optimisations and caching in safe mode). It might be nice > > Oh well, in the safe mode there is even a potential for precompiling Nix > functions. It's another question whether we want to experiment with > workflows without having access to such speedups. > > And even a pure evaluation of a checkout needs to stat all the relevant > files (even if we accept the risk of not checksumming them). Another good point. >>to invent yet another way to do options, and just keep that in Nix. But >>I could be swayed either way. > > I assume there are good arguments for the config to be structured (and > in my current system there are some interface boundaries with structured > config and some wrapper scripts that manage to generate almost all the=20 > usecases using command-line arguments, but sometimes parts of the=20 > structure need to be passed to them). > > On the other hand, JSON can be parsed and written easily in all > languages we might want to use, even in Bash using jq. And we need some > code to setup the namespaces, but nsjail/firejail/bubblewrap are C code > so in the long term there would be some rewrite, probably in Rust??? And > having Nix preprocess arguments for Rust code sounds strange. Not sure about this -- I think it's something we'll have to experiment with. Maybe structured configuration isn't necessary -- it's a pain to do in a CLI... > And whatever you do, Nix evaluation is always just another layer before > running the actual code for setting up the isolated environments that=20 > still needs to interpret its arguments. > > Also, I might want to use some binary cache, but when I am offline Nix > builds wait for a long time for a reply from a binary cache. It's not so > bad if I am intentionally building something and can pass an empty value > for binary-caches via the command line, but doing it for each new=20 > command I execute sounds excessive. Yes, this is true, although I consider it a Nix bug. I shouldn't have to remember to say --option substitute false for trivial offline rebuilds. > Also, it might be convenient to pass entire Nix store inside some VMs, > but if all the _environments_ of all the currently running VMs are=20 > visible in the Nix store??? I really shouldn't. > > I guess if I mention multiuser systems you would say that we need to > allow chmod a-x on /nix/store? I don't plan on doing anything to accomodate multi-user systems, at least for now. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAl2oUlkACgkQ+dvtSFmy ccAQww//X7WMtbmpeFqWfCzkWcYHhGiEnwWK6CysE3UnE1JJXXxBlF33mGi102v4 IrVQbg+CSw5YAu25WImnASf118W9sX7rkhp1fm1Uqvcgu3nlFMi/1LMZEZwgV4MQ JHPzwbSPelM5XxCNMFLL7nQ7Nr+wUbrF1JqHLLSOk0toklwcv730S66RI78gEdjM RA27Gz5hb9N5Gj49h7HMQ+OeLUoI29iQM5jH6Pg/rPerRwLLFHbtfte+0zGbdTx8 59IrtZBJqdKkukLqQFGyi9uTFWK5JAANPZolnqZ4QexV3kN1T5lYoDUNOrz5wDcE l31uyBqXFOBcQO+GwGSdhe/aBm05YXDo8nPaBsPVbs836SbX8ufN1e5nA+hCqtLu ZfkSPAgCMgKDaZizhFJ7TOkIT4gQCQT71cb7/d+RS+ystGvezTbiEDZI+SgwVKWz +Tx6A8kz9BOE0XSRfED/r/Y6f3Qus2HRNtOiGGmhEIZgh6v1fBzVhWXm8r8m2cba yJ18V3rIDYEUBeNeTI2sNzuejg7jem1waUI7xMDo12pYkmcZK3E4/4cA0wybk19i xlfBufl54ibWgL+NZiVYNv7usLq1nVNv84oI9Yvpxo0147CTcdG6oqWDn/uSpUO0 tu0m1eOKy1/i87LdhnJr6XZ3k5/QHn03j3P2k1yIwxIhsmJvVu0= =f6+c -----END PGP SIGNATURE----- --=-=-=--