On Sep 19, 2013, at 10:25 AM, shridutt kothari
wrote:
> Hi Jeremy,
>
> That sounds awesome, What would be the key use cases we can imagine with this?
We discuss several use cases both in our paper, and on our website:
http://cells.cs.columbia.edu/.
As a quick summary, multiple, isolated,
Quoting Jeremy C. Andrus (jere...@cs.columbia.edu):
> On Sep 19, 2013, at 10:25 AM, shridutt kothari
> wrote:
>
> > Hi Jeremy,
> >
> > That sounds awesome, What would be the key use cases we can imagine with
> > this?
>
> We discuss several use cases both in our paper, and on our website:
>
Hey Michael,
tried this out on a saucy vm, and it looked good until it died with
>receiving incremental file list
>fedora-release-19-2.noarch.rpm
>
>sent 47 bytes received 33329 bytes 9536.00 bytes/sec
>total size is 32472 speedup is 0.97
>warning: fedora-release-19-2.noarch.rpm: Header V3 RSA
Hey everyone,
So there are quite a few major changes coming to the way the LXC project
will is managed and to the infrastructure we use.
As most of you probably noticed, Daniel Lezcano has been incredibly busy
of late and only had time to do the final review and merge before
tagging a release, le
After perusing the entire script now,
It seems to me that Michael's major contribution is all the
parts described in my previous post.
In fact, it looks like Michael grafted his good work on to a Fedora
setup script.
If I'm right, then IMO substantial parts of what I posted about
earlier may be r
Hi,
I am trying to run a busybox based container on android. However, lxc-start
fails with the following msgs. Any idea what could be wrong here? Thanks
for your time and help!
lxc-start 1378915396.741 WARN lxc_start - inherited fd 8
lxc-start 1378915396.744 WARN lxc_start - inhe
On Fri, Sep 20, 2013 at 9:37 AM, Stéphane Graber wrote:
> In the end, the plan is to completely stop using sourceforge and instead
> use github for everything but the mailing-lists which will be handled by
> our own mailman server.
+1
> Finally, I'd like to thank Daniel for the hard work he's be
Hi Jeremy,
That sounds awesome, What would be the key use cases we can imagine with
this?
Regards,
Shridutt Kothari
Impetus Infotech Limited
shriduttkoth...@gmail.com
On Thursday, September 19, 2013 3:47:47 AM UTC+5:30, Jeremy C. Andrus wrote:
>
> Hello everyone,
>
> On behalf of myself and
These might be a bit controversial. The process lock was held
for some long periods of time for tweaking consoles. These
can deadlock with some of lock holds I introduced recently. I
would argue that if two threads are fighting over the console,
you're gonna have trouble anyway, and the process
Quoting Dwight Engen (dwight.en...@oracle.com):
> On Fri, 20 Sep 2013 14:48:40 -0500
> Serge Hallyn wrote:
>
> > These might be a bit controversial. The process lock was held
> > for some long periods of time for tweaking consoles. These
> > can deadlock with some of lock holds I introduced re
On Fri, 20 Sep 2013 15:26:47 -0500
Serge Hallyn wrote:
> Quoting Dwight Engen (dwight.en...@oracle.com):
> > On Fri, 20 Sep 2013 14:48:40 -0500
> > Serge Hallyn wrote:
> >
> > > These might be a bit controversial. The process lock was held
> > > for some long periods of time for tweaking conso
On Tue, 2013-09-17 at 10:26 -0700, Tony Su wrote:
> Regarding
>
> LXC and the use of Linux Bridge devices for configured networking,
> At least on openSUSE, LXC is not configured with any /etc/lxc/* by
> default, and possibly because I also have libvirt configured to
> support LXC (although that i
Hey Serge,
On Fri, 2013-09-20 at 09:57 -0500, Serge Hallyn wrote:
> Hey Michael,
> tried this out on a saucy vm, and it looked good until it died with
> >receiving incremental file list
> >fedora-release-19-2.noarch.rpm
> >
> >sent 47 bytes received 33329 bytes 9536.00 bytes/sec
> >total size
Quoting Dwight Engen (dwight.en...@oracle.com):
> On Fri, 20 Sep 2013 15:26:47 -0500
> Serge Hallyn wrote:
>
> > Quoting Dwight Engen (dwight.en...@oracle.com):
> > > On Fri, 20 Sep 2013 14:48:40 -0500
> > > Serge Hallyn wrote:
> > >
> > > > These might be a bit controversial. The process lock
On Fri, Sep 20, 2013 at 02:48:40PM -0500, Serge Hallyn wrote:
> These might be a bit controversial. The process lock was held
> for some long periods of time for tweaking consoles. These
> can deadlock with some of lock holds I introduced recently. I
> would argue that if two threads are fighti
On Fri, 20 Sep 2013 14:48:40 -0500
Serge Hallyn wrote:
> These might be a bit controversial. The process lock was held
> for some long periods of time for tweaking consoles. These
> can deadlock with some of lock holds I introduced recently. I
> would argue that if two threads are fighting ov
Being able to set close_all_fds via API would be usefull for the
situations like running an application (let's say web server)
that controls the lifecycle of the container using the LXC API.
We don't want forked process to inherit parent's resource (file, socket, ...)
Signed-off-by: S.Çağlar Onur
Branch: refs/heads/staging
Home: https://github.com/lxc/lxc
Commit: 6711ffc1227d61831b3e990d630b4fc6d3c8177e
https://github.com/lxc/lxc/commit/6711ffc1227d61831b3e990d630b4fc6d3c8177e
Author: Serge Hallyn
Date: 2013-09-20 (Fri, 20 Sep 2013)
Changed paths:
M src/lxc/conso
Quoting S.Çağlar Onur (cag...@10ur.org):
> Being able to set close_all_fds via API would be usefull for the
> situations like running an application (let's say web server)
> that controls the lifecycle of the container using the LXC API.
> We don't want forked process to inherit parent's resource (
Branch: refs/heads/staging
Home: https://github.com/lxc/lxc
Commit: 130a188840ae655da41dde4771074ff38abaf46f
https://github.com/lxc/lxc/commit/130a188840ae655da41dde4771074ff38abaf46f
Author: S.Çağlar Onur
Date: 2013-09-20 (Fri, 20 Sep 2013)
Changed paths:
M src/lxc/lxc_
Quoting Dwight Engen (dwight.en...@oracle.com):
> This change proposes to add support to LXC for additional LSMs (Linux
> Security Module), namely SELinux. It does so by turning the existing
Thanks, Dwight!
I do some bikeshed arguing below, but I will do a closer review next
week, hopefully monda
21 matches
Mail list logo
