Re: [Nix-dev] In multi-user Nix, let the daemon handle creation of GC roots

> Note, sharing /nix is already not really possible because the metadata > is stored in sqlite and its locking does not play nice with nfs. (*) Sharing is possible if you use a distributed file system that handle consistency correctly, like GPFS, Lustre or similar. We use Nix in shared model in

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

Le 21. 03. 17 à 16:56, William Casarin a écrit : > Eelco Dolstra writes: >> On 03/19/2017 12:10 PM, Jan Malakhovski wrote: >>> For eeePC try disabling hardening. Seriously. >> Hm, I wasn't aware hardening has a significant performance impact. Do you >> have >> more

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

Le 21. 03. 17 à 11:52, Alexey Shmalko a écrit : > Eelco Dolstra writes: > >> Hi, >> >> On 03/19/2017 12:10 PM, Jan Malakhovski wrote: >> >>> William Casarin writes: >>> I tried to run NixOS on my eeepc, it feels a lot more sluggish than when

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

Note that NixOS FreeBSD/NetBSD is just SLNOS with a different kernel, because we are gonna to be free from glibc and GNU tools. I am sorry in advance for this comment. But I can only get amused of seeing some GNU, Linux and systemD-haters spitting on C++ and software complexity on their main

Re: [Nix-dev] Fosdem

Ok to meet up :) name: adev Le 04/02/17 à 01:09, Franz Pletz a écrit : We will probably be hacking somewhere on the venue in between talks. Ping me on IRC if you want to meet up. ___ nix-dev mailing list nix-dev@lists.science.uu.nl

Re: [Nix-dev] Fosdem

I will also be there Adrien Le 01. 02. 17 à 10:27, José San Leandro a écrit : > Me too (+1) > > On Tue, Jan 31, 2017 at 9:55 AM, Théophane Hufschmitt > > wrote: > > I'll be there too ! > With another nixer friend > > Quoting zimbatm

Re: [Nix-dev] List of companies using NixOS

The Human Brain Project (https://www.humanbrainproject.eu/) and The Blue Brain Project (http://bluebrain.epfl.ch/) uses NIX in its HPC to deploy our softwares on all our Supercomputers and our HPC computing clusters. This includes 3 of the most powerful machines in the TOP 500. That allows us

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

> I agree with this. A key that is trusted itself (rather then trusting a > domain name) would be a very large security increase. I agree too. And this more or less the way taken by RPM / DPKG that ship their trusted key on the client side when you install a new repository instead of relying on

Re: [Nix-dev] Malicious installation methods

the best way to go. Cheers, Adev Le 17/06/2016 15:23, Kevin Cox a écrit : > On 17/06/16 09:17, Adrien Devresse wrote: >>> The installer, when run, will fetch more code for users to blindly execute >>> (as most of that code will be provided in compiled form). How is blindly &g

Re: [Nix-dev] Malicious installation methods

> The installer, when run, will fetch more code for users to blindly execute > (as most of that code will be provided in compiled form). How is blindly > running an installer worse than running other code from the same provider? Simply put the shasum of your installer on the website and ask the

Re: [Nix-dev] gitFetchPrivate on NixOS

Hi Ash, I join to this mail the script I use to use gitFetchPrivate in a multi-user configuration. Have a look, you should be able to adapt it to your usage quite easily. The trick is to give to the nix-daemon access to three things : - rw access to your ssh-agent socket - read access to your

[Nix-commits] [NixOS/nixpkgs] d7749f: bup: add ${git} to the $PATH of the wrapper

75fc1b https://github.com/NixOS/nixpkgs/commit/b6193dbac7961a412c106932f6af5a07e875fc1b Author: Adrien Devresse <adrien.devre...@epfl.ch> Date: 2016-05-28 (Sat, 28 May 2016) Changed paths: M pkgs/servers/computing/slurm/default.nix Log Message: --- slurm-llnl: improve

Re: [Nix-dev] How to use binaries from other hosts?

> I tried _everything_. I cannot nix-copy-closure, as this one does not allow me > to set the SSH port (which isn't 22 but something above 1). You can define any host / port matching through the configuration file "~/.ssh/config" for any program using SSH. Something like "" Host [youHost]

Re: [Nix-dev] --ftls-model=global-dynamic for every lib?

Thx Domen, this is exactly what I was looking for. Le 28/02/2016 11:33, Domen Kožar a écrit : > See > https://github.com/NixOS/nixpkgs/pull/12895/files#diff-8ac87a75c3dd650a7f760fa3b2d041bfR239 > > On Sun, Feb 28, 2016 at 10:31 AM, Adrien Devresse <a...@adev.name > <

Re: [Nix-dev] --ftls-model=global-dynamic for every lib?

To generalize a bit on this. Most of the Linux distributions have a mandatory default set of flags for all libraries / binaries that are enforced through "configure / cmake" macros ( -fPIC is part of them ). They do this for very good reasons: security, protability, compatibility. It would be

Re: [Nix-dev] On nixpkgs and reasonable code size

> I'm totally for that, but do note that there is an equivalent problem > in deciding who gets "PR approval" access. But, I suppose since we > control hydra/whatever and not github, we can roll our own logic like > allowing people to only approve PRs for automatic merging that affect > certain

Re: [Nix-dev] On nixpkgs and reasonable code size

> I think the inflow of PRs *is* high wrt. the number of active > contributors with push access. Certainly too much to keep quality very > high all the time, but on the other hand, for those less important > packages it's not a big deal... The way the other distributions solved this issue is by

Re: [Nix-dev] Debugging Symbols

+1 to this proposal. The current solution to recompile with a nix function is far to be a perfect solution: - It happens often that recompiling with debug flags change the behavior of the progrm itself and make the crash/problem impossible to reproduce with debinfos. - It is a pain when a

Re: [Nix-dev] Providing Debian, Arch etc. packages counterproductive?

An other point to consider is the integration aspect. Nix requires a system install in a shared environment. The daemon needs to be setup properly, group created, etc In most companies, the sysadmin will simply refuse to install on any existing shared system anything which is not packaged

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

/passwd/group syscall triggers the error too. Adrien Le 23/06/2015 12:48, Eelco Dolstra a écrit : Hi, On 23/06/15 11:47, Adrien Devresse wrote: Ideally, libnss_sss should be part of stdenv. That's not going to happen because there are any number of NSS modules that we can't possibly all add

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

of issue definitively. Adrien Le 23/06/2015 15:38, Eelco Dolstra a écrit : Hi, On 23/06/15 14:50, Adrien Devresse wrote: If possible, you could also enable chroot builds. It might be possible to override /etc/nsswitch.conf in the chroot by setting the Nix option build-chroot-dirs

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

matching, and not on how the output was produced? James *Not sure if it's really fixed-output when leaveDotGit = true. On 6 June 2015 at 14:38, Adrien Devresse a...@adev.name wrote: I would say, it does not solve the problem. If adding the system libnss_sss path to the LD_LIBRARY_PATH can

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

I would say, it does not solve the problem. If adding the system libnss_sss path to the LD_LIBRARY_PATH can be an acceptable solution for firefox, I think it is not for fetchgit/git. Adding libnss_sss to the LD_PATH as requirement for any invocation of igt would make any build using fetchgit

Re: [Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

, Eelco Dolstra a écrit : Hi, On 05/06/15 00:10, Adrien Devresse wrote: I triggered this failure (http://pastebin.com/Lw6a0p4J) while trying to use nix on a RHEL 6.5 configuration setup with ldap authentication ( sssd + libnss_sss ). After a bit of research, this is due to the dependency of git

[Nix-dev] Impossible to use Nix + fetchgit on any Linux configured with LDAP authentication /libnss_sss

Hi, I triggered this failure (http://pastebin.com/Lw6a0p4J) while trying to use nix on a RHEL 6.5 configuration setup with ldap authentication ( sssd + libnss_sss ). After a bit of research, this is due to the dependency of git on getpwuid and to the fact that the nix glibc do not have by