<guest`>ewemoa: no, generated html is already hard enough (ecmascript worse), WebAssembly is to aid "mobilization" (people needing a "computer" for things like running, so we have government surveillance): Firefox OS, ... <ewemoa>guest`: it will be nice if readability is improved <ewemoa>mark_weaver: i'm getting a failure for guix download with "Bad Date header" -- similar to what's mentioned at https://gnunet.org/bot/log/guix/2013-10-16 -- using wget -S, i see that the Expires date uses PDT instead of GMT -- is there some good work-around? <civodul>ewemoa: could you send the command and output to bug-guix@gnu.org? <civodul>sounds like a bug in Guile's web client and/or the HTTP server it's talking to *civodul goes afk for a while <ewemoa>mark_weaver, civodul: FWIW, manually downloading followed by guix download file:///<pull-path-to-downloaded-file> seems to be one work-around <efraim>for a build recipe, how do I write that I want gtk+2.x and not gtk+3.x? <civodul>efraim: refer to the variable corresponding to the package object for GTK+ 2 <efraim>civodul: i was looking at gnu/packages/games.scm, and I noticed the #:use modules aren't alphabetical. I dont want to make basically a "whitespace patch" but is there something planned to change that? <efraim>so under inputs id write ("gtk+-2" ,gtk+) <civodul>here "something" is just a label for use in the recipe <rekado_>is there a variant of find-files that does not recurse over directories? <rekado_>I just want to copy all matching files from the top directory. <mark_weaver>rekado_: the second argument to find-files can also be a procedure. <mark_weaver>that procedure gets the file name including directories <mark_weaver>the docstring of 'find-files' says that it gets the absolute file name, but actually that's only true if the first argument to 'find-files' is an absolute filename. <mark_weaver>if the first argument to 'find-files' is ".", then the filenames that the predicate gets will be things like "./foo", "./foo/bar.c" <mark_weaver>anyway, to make a long story shorter, you could just use a slightly modified version of 'file-name-predicate', except without the 'basename' call in there. <mark_weaver>and then pass (full-file-name-predicate "^\\\\./…") as the second argument to find-files <mark_weaver>alternatively, you could import the (ice-9 ftw) module and use (scandir ".") which just returns a list of file names in the current directory. (warning: includes "." and "..") <mark_weaver>'scandir' also takes an optional second argument, a predicate procedure. <mark_weaver>rekado_: so you could do this: (scandir "." (lambda (name) (string-match <REGEXP> name))) <rekado_>mark_weaver: looks good. Thanks for the pointers. <mark_weaver>we don't plan these things. packages get added when someone does it and submits it. would you like to? <mark_weaver>we already have some other packages from suckless, see gnu/packages/suckless.scm <mistnim>ok mark_weaver, I still haven't tried guix, maybe in the future <mistnim>the problem is that i3 is really critical for my workflow <mark_weaver>well, we are all volunteers. we don't add packages that we're not personally interested in. <mark_weaver>frankly, what we need at this stage are people willing to contribute. <mark_weaver>all of us have added packages that we care about, and that's how we make progress <mark_weaver>you can install guix on top of another distro, and then use your host distro's i3 while you package i3 for guix. <mark_weaver>many of us followed that pattern, only switching to GuixSD after Guix had the packages that were most important to us. <ewemoa>how nice...the i3 tarball has a file named "PACKAGE-MAINTAINER" :) ***ueno__ is now known as ueno
<mistnim>mmh, btw, am I wrong or there is no 32bit version? <mistnim>that's not really clear, x86_64i686 is missing a whitespace <ewemoa>mistnim: fwiw, i don't think guix has the following yet (which appear to be dependencies for i3): xcb-util-cursor, libev, yajl <mark_weaver>ewemoa: we have several xcb packages, maybe one of them has it. sometimes the mapping from library name to package name is not obvious. <mistnim>I guess I can try ratpoison, is there wpa_supplicant in the installation cd? <mark_weaver>we are a 100% free software distro, no blobs, so hopefully your wireless device doesn't need one. <ewemoa>mark_weaver: yes, i came across a number of xcb packages, but i don't see xcb-util-cursor, and http://xcb.freedesktop.org/dist/ shows a specific tarball for it -- i didn't turn anything up grepping through gnu/packages, but perhaps i missed something <mistnim>mark_weaver: well, I was already thinking about that, unfortunately I think I will need to add the wireless firmware <mistnim>mark_weaver: wow, I'm not sure actually, it's in the laptop <mistnim>I knew that, already had the problem <mark_weaver>afaik, lenovo has a policy of enforcing a "whitelist" of cards, so it's not possible to get an atheros card working in there without hacking the BIOS somehow :-( <mistnim>I have also two random usb cards, and both of them too require blobs, one is ralink, the other is Asus <mistnim>I guess those that don't are vary rare <mark_weaver>I own a ThinkPenguin TPE-N150USB. Guix actually builds the firmware for it from source code. <mark_weaver>The Tehnoetic is based on the same Atheros chipset, so I guess it would also work. <davexunit>I still use a proprietary BIOS because the thinkpad x220 is unsupported by libreboot, but it has been hacked such that the whitelist has been removed. <davexunit>which allowed me to replace the intel wireless chip with an atheros one from thinkpenguin <fchmmr>davexunit, coreboot supports the X220. You'll still have a ME (and maybe other things), but it's freer than lenovobios <fchmmr>mv/nully can hook you up with a SPI flasher <davexunit>fchmmr: you have an irc client that alerts you every time "libreboot" is mentioned, don't you? :) <fchmmr>davexunit, also, someone (not me) forked libreboot to create "nonlibreboot" <fchmmr>You could add a config there for X220, and build for it <fchmmr>(that's a blobbed coreboot, but they re-use libreboot's automated build system) <fchmmr><davexunit> fchmmr: you have an irc client that alerts you every time "libreboot" is mentioned, don't you? :) <davexunit>I'm going to start inserting random words into my irc messages and based on your response time determine what they are. <fchmmr>My real name is also stalked on IRC <fchmmr>If you say my real name, or any part of it (as long as you don't misspell it) I will be pinged. <fchmmr>my client has a limit of how many words I can use, though. I need to modify the src to remove that limitation. <fchmmr>there's no actual limit, it's a bug <mark_weaver>ewemoa: I've forgotten, were you the one who asked if you could submit packages to guix without revealing an email address? <mark_weaver>ewemoa: so you'd prefer to communicate with us exclusively over IRC and paste sites? <ewemoa>that's part of it, but to be honest, i haven't really used email in some years now <mark_weaver>ewemoa: well, it is possible to have an email address that is difficult to attach your name to. on the other hand, anyone on irc can see your IP address by typing "/whois ewemoa" <civodul>mark_weaver, ewemoa: i'm fine with anonymous contributions <civodul>but i don't imagine myself reviewing/applying patches not submitted by email <civodul>ewemoa: would it be an option for you to use anonymous email accounts? <mark_weaver>civodul: yes, of course anonymous is fine. but ewemoa hasn't used email in years and would prefer to communicate exclusively over IRC and paste sites. <ewemoa>mark_weaver: he he -- for the time being, i will try to send more polished things via some web 2 mail gateway -- thanks for your consideration :) <ewemoa>mark_weaver: thank you for that pointer :) <mark_weaver>I guess from my point of view: I don't care what your name is or where you live. <mark_weaver>However, I do care about being able to establish trust in a contributor, and therefore some way to know that your submission next week is coming from the same person who sent it this week. <mark_weaver>right now, anyone could log in as ewemoa and pretend to be you. <rekado_>how should we attribute such patches? <mark_weaver>but the other thing is that it makes less work for us to receive patches over email created by "git format-patch" <mark_weaver>I'm okay with someone using an alias and an email address that cannot be tracked back to the individual. <mark_weaver>one way to do that is to create and access the email account exclusively through Tor. <rekado_>I mean as those with commit access are submitting the patches, how do we declare the author? <mark_weaver>well, the author could be an alias and anonymous email address. <mark_weaver>but apart from any of these considerations, which need not be set in stone, I see two issues: <mark_weaver>(1) in git, commits have an associated "author", which is required to have an email field. <mark_weaver>(2) there needs to be a clear record that the author submitted this to guix to incorporate into our project. <mark_weaver>with email, we have a record of every package submission that's not from someone with direct commit access. <mark_weaver>we can point to that record and say "that person donated this package to us" <mark_weaver>well, I'm not sure about that, but it's a concern... <mark_weaver>bavier: sure, that would be a way to establish trust in a contributor, by their signing key. but it doesn't solve the copyright problem. <mark_weaver>civodul: my biggest concern about accepting patches over IRC and paste sites is that we have no clear record that someone submitted this new code to us and intended for it to be part of guix and released under the GNU GPLv3. <civodul>so i guess contributions have to be pseudonymous at best <civodul>and again, email is a must as far as i'm concerned :-) <Steap>Should I write patches to Python against core-updates rather than master ? <Steap>we got a bunch of modules that are not compiled in Python <mark_weaver>Steap: yes, I think changes to python are probably best for core updates <mark_weaver>rekado_: iiuc, each entry in .links is a hash of the file contents. when a file is added to /gnu/store, .links is checked to see if a file with the same contents is already in the store, and if so, another hard link is made. <rekado_>well, my experiments with lsyncd are not very promising, unfortunately. <rekado_>the event queue quickly overflows and then lsyncd restarts and re-syncs everything with rsync. <paron_remote>davexunit: btw we should talk about guixops soon and what I can do to help at this state <paron_remote>I guess I could just check out the code and look at it already <davexunit>paron_remote: it needs to get rebased onto the current master branch. <davexunit>once the basic container functionality is in master we'll have another decent testing platform. <paron_remote>davexunit: maybe I should wait for the container stuff for now? <davexunit>I hacked on it a bunch before. it will just be nice to have it when it's ready. <paron_remote>I'm going to hack a bit on the web application I'm working on now and between today and tomorrow I'll start poking around in guixops <davexunit>I think help defining more high level details would be useful. if we can get on the same page of what the workflow is. <davexunit>figuring out exactly what the interface for <platform> needs to be. <davexunit>how to do all the networking is important, too. <davexunit>how would something like 'guix deploy ssh my-web-server' actually work? <paron_remote>davexunit: okay, cool, looks like there's plenty for me to comment on then :) <davexunit>paron_remote: yeah there's tons. we're definitely lacking some solid direction. <davexunit>I have a decent, very high-level plan that I wrote on the list about awhile ago ***exio4 is now known as y
<civodul>Steap, mark_weaver: maybe a python-update branch would be more appropriate? <civodul>mark_weaver: BTW what happened with the cURL failures in wip-diet on hydra? <mark_weaver>civodul: I restarted the build and it worked the second time. <Steap>civodul: then what is core-updates for ? :p <civodul>Steap: updates to the "core", where "core" means everything that leads to %final-inputs (GCC, Binutils, libc, etc.) <mark_weaver>I've also tended to apply other updates and changes that are non-essential (no hurry) but would require a lot of rebuilding. I don't know if that's undesirable. <mark_weaver>I guess there is a benefit to isolating changes so that breakage can be attributed to one change... <mark_weaver>but on the other side is the limited capacity of our build farm. <civodul>mark_weaver: we have to make tradeoffs due to our limited build farm, indeed <civodul>so we can't really have one branch for each change we make <civodul>but in this case, i think it's reasonable to make a special python branch <civodul>davexunit: see the last part about running each app in a container <davexunit>I think he was hinting at how we want to be able to isolate applications on guixsd. <mark_weaver>that's probably the easiest way for someone to hack into my computer remotely. <davexunit>what kind of resources would you like it isolated from? <davexunit>I'd like to keep gathering use cases so we can make gnu/build/linux-container.scm have a sufficiently generalized implementation to handle all of them. <Steap>I have a colleague who runs everything in Qemu <Steap>it's a "heavy container" solution :D <davexunit>right now I give the user control over which namespaces they want to unshare and what file systems they want created. <davexunit>though I suppose that if the user doesn't want a new mount namespace then all the file system stuff should be skipped... hmm... <Steap>so why is Docker so bad but bare containers so good ? <davexunit>Steap: we first must make a distinction between the core technology and Docker's UI and domain specific things. <davexunit>I define a linux container as a combination of namespaces, cgroups, and a chroot/pivot_root. <davexunit>Docker builds on this base with a particular type of workflow and design. <davexunit>Docker containers are defined by Dockerfiles, an imperative list of instructions to perform to build a static disk image, or rather a series of static disk images. <davexunit>these images are unioned with a union file system and the resulting file system is mounted inside the container process. <davexunit>my argument is that the use of raw disk images is insufficient for addressing the problems of reproducibility and leaves little opportunity to take advantage of a cache, though of course Docker tries. <davexunit>since Guix uses a purely functional model, we get system-wide caching/deduplication quite easily. <davexunit>in Docker you will only not waste space if your various containers use the exact same base images and do subsequent configuration steps in the *exact* order as in other Dockerfiles. <Steap>I don't get why you do not achieve reproducibility <paron_remote>and yet, a friend of mine said they talked to docker folks about known security problems, "and they acknowledge that but don't have the resources to work on it" <davexunit>Steap: because the results of the build change depending on what time you build the container image, for one. <davexunit>I have started working with Docker at my new job, and I will be doing more and more of it. it's certainly better than other lesser solutions like Chef. <davexunit>too many tools that don't compose. Guix composes. <davexunit>so let's keep hacking and in a few years maybe we'll have a shot at using it "in production" <Steap>I mostly hate the fact that people now like to share binary images <Steap>+ the whole thing seems fucking complex <rekado_>re containers: is nobody using mandatory access control (e.g. SELinux)? I tried to contain my browser with SELinux but wasn't very successful, unfortunately. <davexunit>SELinux always grossed me out for some reason. <rekado_>oh, it is gross, but I think it's useful. <davexunit>Steap: unfortunately, a lot of people see the sharing of binary images as an advantage. <rekado_>unfortunately I never learned how to write policies from scratch --- any other sysadmin I met disables SELinux. <davexunit>Docker is "open source" software project for creating binary images of proprietary web applications for the "cloud", basically. <davexunit>so whatever, that's fine. the free software community just needs something else to meet our needs. <Steap>yeah, CLoud operators seem to like Docker <davexunit>the proliferation of tools needed to make all this stuff work makes my head spin. <davexunit>we may not have many software packages or system services, but I am always very happy to upgrade my guix software and guixsd system that generally "just works" <davexunit>the functional package management paradigm is the clear winner to me. <mark_weaver>davexunit: ideally, I would like my web browser to not have the ability to read or write arbitrary files of mine, nor debug attach to my processes, nor log my keystrokes when one of its windows is not in focus, etc. <mark_weaver>so if I download a file, it would go to a download directory that my normal user could access. <_`_>Steap: http://sprunge.us/GcVe that's my thoughts on docker outside of outside of comparing to atomic packages and the deterministic features of a functional package manager <mark_weaver>and if I want to upload a file, I would have to copy it to a special directory first. <_`_>mark_weaver: that last one is impossible with X <_`_>idk if wayland is *good* enough either, but hopefully. <davexunit>mark_weaver: we can easily create a container that bind-mounts a downloads and uploads directory and launches icecat <mark_weaver>davexunit: that would be a great improvement, I think. <davexunit>I don't know how, but it's possible to share whatever is needed for the x server stuff so that the window can be opened. <_`_>I think that's trivial, issue is it's not isolated. <davexunit>it's just a matter of what files/directories need to be bind-mounted. <mark_weaver>it could be run within Xephyr for some added protection, although I don't know how much more. <davexunit>I think 'guix system container' will work for this. a minimal guixsd config with just a service or two to do whatever setup is needed and launch icecat. <davexunit>I would need to add an option to select which namespaces 'guix system container' would unshare <_`_>I remember just passing the top levels $DISPLAY it it just working… which is kinda sad <davexunit>I don't have netlink stuff working yet, and only root could do that anyway, so this icecat container would have to run without a new network namespace. <mark_weaver>yeah, ideally it wouldn't have access to localhost ports, but that could wait until later. <davexunit>the plan is to have a container daemon that runs as root and builds containers for other users, like the guix-daemion. <_`_>mark_weaver: Within an unprivileged container I could just use the DISPLAY env of the X server belonging to user (on the host) spawning the container, and this just ran the client on the host's X server. <_`_>no I haven't tried Guix's unprivileged container mechanism yet. <_`_>but, yeah it's a sad convenience <mark_weaver>I would expect xauth to prevent that, assuming that the container lacks the needed cookie. <davexunit>_`_: read your little docker notes above. it's a shame that Docker cannot utilize user namespaces yet. <davexunit>that would eliminate the unprivileged user creating privileged containers issue. <_`_>they're too focused on supporting every os level virt mechanism ever <_`_>s/supporting/shoehorning/ <_`_>can't be helped with those priorities <davexunit>I don't understand why they would support all the backends that do the same thing: create namespaces, configure cgroups, call chroot, etc. <_`_>they attracted joyant with initial support for illumos zones even microsoft by what I think is trying to utilize the windows sandbox <davexunit>and lol at Docker running on OS X by just using chroot. <_`_>Docker reminds me a lot of Apple really <davexunit>#guix is my happy place where I can hack on what I feel are real solutions to packaging and deployment problems. :) <_`_>And are they really “isolating” with chroot(1) for os x? I thought they were using vagrant to have users download a VBox VM with ubuntu plus docker installed. Not that the latter is sane either. <davexunit>"Whilst chroot offers something of a lowest common denominator environment for all Unix operating systems, it’s likely to be the path of least resistance for a native OS X implementation that avoids the use of virtual machines running Linux." <_`_>is that actually implemented and something they ship? <davexunit>I mean, they admit that it's the LCD, but a chroot is just not sufficient for anything <_`_>I'm scared to find out <davexunit>maybe they've come to their senses about that particular thing. <_`_>stranger things have happened <davexunit>mark_weaver: I was wondering, since test suites often use random numbers, is there anyway that we can set the seed to something fixed so that the test suite always runs with the same set of random numbers? <davexunit>the seed will of course be chosen by a fair dice roll. <mark_weaver>is there a way to arrange for /dev/random and /dev/urandom to be deterministic within the build container? <davexunit>people could hardcode that number in their test suites and change behavior <davexunit>so yeah, maybe the derivation hash would be a good idea. <mark_weaver>I think I would prefer it based on the derivation hash, so that we at least get different test scenarios across builds. <mark_weaver>but the clock is another big source of non-determinism <davexunit>in ruby land, we use a library called timecop to deal with time in test suites, but it's not a system level thing. it just stubs out methods in the relevant Ruby interfaces to return fixed values. <davexunit>I wonder if we can address it at the system level... <davexunit>I bet if we could it would have been done by now. <mark_weaver>and a lot of other stuff in /proc like cpuinfo, and the kernel being used, etc. <mark_weaver>and then there's software that actually tries running CPU instructions that are only implemented on certain CPUs. <davexunit>can one bind-mount over /proc/cpuinfo? I bet not. <davexunit>anything we can do to further remove sources of non-determinism would be great. <mark_weaver>yes, you can. or at least it just worked for me on linux-libre 4.1.1 <mark_weaver>that would actually be helpful for arm builds, I suspect <davexunit>so perhaps we can add fixed versions of these files that change depending on the underlying hardware <phant0mas>what env variable I am missing? because I am getting "possibly undefined macro: GUILE_MODULE_AVAILABLE" with autoreconf -vfi <davexunit>phant0mas: you're missing guile's aclocal stuff <mistnim>how can I launch the guix image with virtualbox? <Steap>could we use a chromebook with an ARM CPU ? <mistnim>mark_weaver: where should I put the firmware blobs in the installation image? <mistnim>mark_weaver: ifconfig doesn't see a thing, I supposed this means the kernel doens't have the driver of neither my eth nor my wifi card <davexunit>people are making special-purpose distros just for running Docker or whatever on. <davexunit>because debootstrap, etc. are too hard I guess. <davexunit>mistnim: we can't really give advice about how to add blobs to your system here. <davexunit>mistnim: we would be encouraging the usage of proprietary software. <mistnim>awell davexunit I'm poor, I'm not going to change my laptop, so you are not really encouragin the usage of proprietary software. It's better to help me use guix and eventually contribute I think. Next time I have money I will buy a 100% free laptop <mistnim> this is already like a 7 years old computer, it's not like a bought it yesterday <davexunit>mistnim: I'm sympathetic to your cause, but we really cannot encourage the use of proprietary software here. there are instructions elsewhere online for loading kernel modules. <guest`>mistnim: a old computer is probably supported by free software, try running trisquel first <guest`>davexunit: <mistnim> mark_weaver: ifconfig doesn't see a thing, I supposed this means the kernel doens't have the driver of neither my eth nor my wifi card <davexunit>mistnim: well we can try to help with your ethernet chip if the module is in linux-libre ***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | 0.8.3 is in the works | https://savannah.gnu.org/forum/forum.php?forum_id=8273 | This channel is logged, see <https://gnunet.org/bot/log/guix>.'
<Steap>davexunit: should we use "return" or "exit" in guix environment ? <Steap>cf. my patch about the return value <Steap>davexunit: yeah, but I see you're using (return (...)) <davexunit>search around for what kernel module that responds to <Steap>damn, that's becoming quite complexe <Steap>nah I don't get it like at all <Steap>yeah, that's the first thing I have no clue about <davexunit>so non-monadic values must be wrapped with (return ...) <davexunit>just know that you'll need 'return' to get things out of the monadic expression <rekado>actually, "return" puts a non-monadic value into a monadic context, no? <davexunit>I'm trying to describe it in another way that makes more sense in this context <davexunit>Steap is trying to get a "normal" value out of the monad. <mistnim>guest` do I have to add a compiled module to the installation image? How does that work? <davexunit>you should be able to modprobe the needed thing <rekado>(BTW: I very much recommend learnyouahaskell.com --- it's a very easy read with silly pictures and when you're done monads are a very intuitive concept.) <guest`>mistnim: there is a field to build modules on the initrd, mark_weaver had such configuration, ask him in the mailing list if he don't reply here <guest`>mistnim: modprobe can work too, but is less convenient <rekado>cmake-build-system and I are no friends anymore. <rekado>looking at the definition it looks all right, but in so many packages using it I have to manually do something to get the RPATH set properly. <civodul>davexunit, Steap: (return (status:exit-val ...)) is sufficient, i think; 'exit' is implicit <amz3>sneek: later tell alezost yes, my address is now amirouche@hypermove.net, thanks. <davexunit>the program can just return an integer and it will exit with that value? <mistnim>no, the modules, where already loaded, that is not the problem <davexunit>and 'ifconfig -a' lists nothing but loopback? <davexunit>worth a try, I don't enough to help further right now. <Steap>ice-9/boot-9.scm:65:2: Throw to key `vm-error' with args `(vm-run "VM: Stack overflow" ())'. <Steap>does that ever happen in Guix ? <davexunit>civodul: were you showing me that docker article 1) to have a little laugh and 2) to emphasize that you want to run certain programs within contains on guixsd? <Steap>ok, this happens when I build tk <mistnim>yes, it's listed in ifconfig -a, weird <davexunit>civodul: mark_weaver and I were discussing coming up with a configuration for running icecat from call-with-container <davexunit>made me think that we perhaps we need a tool for this use-case to make it convenient. <davexunit>with the expose/share flags from 'guix system' <davexunit>and another in case the user wants to specify which namespaces to use <guest`>mistnim: maybe you are just without dhcp? <Steap>hum, the tk build is OK on hydra <guest`>mistnim: maybe you need to activate the interface like "ifconfig eth0 up" or "ifup eth0" <guest`>mistnim: you mean dhcp works in your guix installation? <civodul>davexunit: definitely, icecat is a good example of something to run in a container <mistnim>guest`: yes, I'm pretty sure that it works <davexunit>civodul: I'll work on such a thing after I get what I have ready for release. <civodul>the problem is that until we have a container-managing daemon, we'll have to 'sudo guix container run ...' <davexunit>civodul: *not* if the process only uses a single uid/gid <civodul>because it could run under a separate uid name space you mean? <davexunit>yeah, an unprivileged user can still create a user namespace that maps *only* her uid/gid <civodul>right, but then you can't do the other things: other name spaces, chroot, etc. <davexunit>and for icecat, we would just tell guix not to unshare the network namespace <davexunit>civodul: the new user namespace allows us to create all the others :) <davexunit>for example, I use 'guix environment --container' as an unprivileged user <civodul>but you still can't use mount(2) or chroot(2), can you? <davexunit>there's a new mount namespace, so yes, you can. <davexunit>an unprivileged user can only map themselves <civodul>yes, but that's enough for 'guix environment' and that kind of things <davexunit>and of course they can't create network bridges and things <davexunit>so the container daemon will still be useful for those things <davexunit>but yeah, you're not totally screwed as an unprivileged user. <davexunit>root probably also has to setup cgroups, I imagine. <civodul>so when we were discussing about guix-daemon vs. uid name spaces, that makes sense <civodul>i'll have to think why this works; mount and chroot have always been restricted on unix <davexunit>new mount namespace that doesn't interfere with the mount points elsewhere <davexunit>call-with-container creates a directory in /tmp that it owns to use as the new root <davexunit>mounts a tmpfs there, then /proc, /sys, and various bind-mounts <zacts>they have it up for purchase <zacts>davexunit: the MIT bookstore? :-) <zacts>davexunit seems so excited about it, that he is getting a headstart on waiting outside the MIT bookstore in a tent all night, just like the crazy friday after thanksgiving americans do for other things. <zacts>but davexunit is such a nerd he will only do this for a scheme or lisp book <zacts>davexunit should do a parody short documentary that shows him waiting in a tent all night to guarantee he gets the book the next day <paron_remote>it's too bad the MIT Press website shopping cart doesn't work for me