http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c#n1469
--
Кирилл Елагин
On Wed, Jun 4, 2014 at 1:21 AM, Wout Mertens wout.mert...@gmail.com wrote:
On Tue, Jun 3, 2014 at 8:30 PM, Kirill Elagin
too bad :-) Thanks for the find!
On Wed, Jun 4, 2014 at 8:14 AM, Kirill Elagin kirela...@gmail.com wrote:
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c#n1469
--
Кирилл Елагин
On Wed, Jun 4, 2014
too bad :-) Thanks for the find!
By the way, note that PID-1-only cgroups management is a systemd
decision, as far as I understand from the kernel mailing list posts, the
interface will still be a filesystem, and apparently it is OK to
implement cgroup management by multiple root processes
Hm, I wasn't following the kernel ml on this, but from the systemd's
document it follows that there has to be _exactly one_ writer to this
filesystem and this is a restriction forced by the kernel. systemd's
decision is that it will be PID 1, not some other process. On non-systemd
systems that can
Hi,
For single-user implementations we have this:
https://github.com/nilcons/ceh
In our startup we actively use this on several workstations and servers
with Debian/Ubuntu base systems.
This is less ambitious than your ideas, but worked very well for us.
Gergely
On Thu, 29 May 2014 17:28:48
Obviously systemd would then have to not do things that udev etc are
already doing... Just running services, opening sockets, handling cgroups...
I doubt systemd can do this.
First of all, with the new kernel cgroups interface only PID 1 can manage
cgroups (on the kernel level).
Then, to
On Tue, Jun 3, 2014 at 8:30 PM, Kirill Elagin kirela...@gmail.com wrote:
Obviously systemd would then have to not do things that udev etc are
already doing... Just running services, opening sockets, handling cgroups...
I doubt systemd can do this.
First of all, with the new kernel cgroups
Wout Mertens wout.mert...@gmail.com writes:
I think there is room for improvement for installing and using nixpkgs on
another distribution.
I see two big problems:
1. installation
2. environment variables
Also: setting up services to run when the system boots. For example, Homebrew
tells
Another issue I just remembered is that of setuid binaries. NixOS has a
mechanism for it, and it could just as easily be used elsewhere. Without
it, you can't easily use qemu for example.
Wout.
On Thu, May 29, 2014 at 5:28 PM, Wout Mertens wout.mert...@gmail.comwrote:
I think there is room for
On May 29, 2014 6:58 PM, Eelco Dolstra eelco.dols...@logicblox.com
wrote:
Hi,
On 29/05/14 18:34, Wout Mertens wrote:
Another issue I just remembered is that of setuid binaries. NixOS has a
mechanism for it, and it could just as easily be used elsewhere.
Without it, you
can't easily use
Wout Mertens wout.mert...@gmail.com writes:
I think there is room for improvement for installing and using nixpkgs on
another distribution.
I see two big problems:
1. installation
2. environment variables
Also: setting up services to run when the system boots. For example, Homebrew
tells
On Thu, May 29, 2014 at 10:23 PM, John Wiegley jo...@newartisans.com
wrote:
Wout Mertens wout.mert...@gmail.com writes:
I think there is room for improvement for installing and using nixpkgs on
another distribution.
I see two big problems:
1. installation
2. environment variables
12 matches
Mail list logo
