[Nix-dev] Security channel proposal

Wout Mertens wout.mertens at gmail.com
Thu Sep 25 14:54:31 CEST 2014


On Thu, Sep 25, 2014 at 2:41 PM, Michael Raskin <7c6f434c at mail.ru> wrote:

> >It sounds like a necessary evil.
> >
> >Another option would be to make Hydra super fast... What has been explored
> >to optimize compile speeds? Using distcc, ccache, SSD, elastic scaling?
> >
> >What if we had a security build fund that we could use to briefly run 500
> >machines to complete security builds? Would that allow 2-hour security
> >rollouts?
>
> I bet against our package set being buildable in 2 hours — because of
> time-critical path likely hitting some non-parallelizable package.
>

I think most large projects can be compiled via distcc, which means that
all you need is parallel make.

Libreoffice build is inherently a single-machine task, so to speed it
> up you need something like two octocore CPUs in the box.
>

Point in case:
https://wiki.documentfoundation.org/Development/BuildingOnLinux#distcc_.2F_Icecream
. Building with "icecream" defaults to 10 parallel builds.

Also, with ccache the original build time of 1.5 hours (no java/epm) is
reduced to 10 minutes on subsequent runs.


> With such a goal, we would need to recheck all the dependency paths and
>
optimise the bottlenecks.
>

Sounds good :)

Another option is to have a jobset which builds only a "server" subset of
NixPkgs, and which has higher priority than the trunk builds. I don't know
of many servers that need libreoffice installed...

You can have multiple binary buildsets right?

Maybe making dependency replacement work reliably (symlinking into
> a special directory and referring to this directory?) is more feasible…
>

Can you elaborate?

Wout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140925/f91a78a3/attachment-0001.html 


More information about the nix-dev mailing list