I tested the previous "version" and found my environment to be exactly the same.
Let's start discussing possible extensions/improvements somewhere else. For now it's a nice improvement.
This change does two things:
* "NixOSizes" environment variables generation. This allows some more
error-checking and opens possibilities for a modular environment
configuration. From now on the most of environment variables are
generated directly by the nix code. Generating sh code that
generates environment variables is left in a few places where
nontrivial access to a local environment state is needed.
* By doing the first change this patch untangles bash from the
environment configuration and makes it trivial to add a support for
other non bash-compatible shells.
Now to the sad part. This change is quite large (and I'm not sure it's
possible to split it) and yet is not quite complete, it needs some
changes to nixpkgs to be perfect.
See !!! comments in modules/config/shells-environment.nix.
Main principle behind this change is "change environment generation
and nothing else". In particular, shell configuration principles stay
exactly the same as before.
This didn't work reliably because it raced with the remounting of /.
So if you were unlucky, then / was read-only by the time we ran
"alsactl store". Now the sound card state is saved before anything is
unmounted/remounted.
This reduces code duplication, but more importantly means that the
DRI modules can be found by X enabling hardware acceleration.
Close#249; the PR also refers to more about DRI modules.
Set "networking.tcpcrypt.enable = true;" to enable opportunistic TCP encryption
based on the user-space tools available from <http://tcpcrypt.org>.
Network attackers come in two varieties: passive and active (man-in-the-middle).
Passive attacks are much simpler to execute because they just require listening
on the network. Active attacks are much harder as they require listening and
modifying network traffic, often requiring very precise timing that can make
some attacks impractical.
Opportunistic encryption cannot protect against active attackers, but it *does*
protect against passive attackers. Furthermore, Tcpcrypt is powerful enough to
stop active attacks, too, if the application using it performs authentication.
A complete description of the protocol extension can be found at
<http://tools.ietf.org/html/draft-bittau-tcp-crypt-00>.
I.e., modules that use "require = [options]". Nowadays that should be
written as
{
options = { ... };
config = { ... };
};
Also, use "imports" instead of "require" in places where we actually
import another module.
The NixOS config need not be $NIXOS_CONFIG, it can also be set through
-I nixos-config=... or not exist in a separate file at all (e.g. in a
NixOps deployment).
Issue #212.
dramatically speeds up my boot time because it was the last
service (for me) that depended on udev-settle.service
udev-settle isn't needed for modern system initialization but some
oldschool services (mdadm/lvm/cryptsetup) depend on it so they can
just enumerate devices instead of having to react to changes
dynamically. In NixOS these things are usually already taken care of
during stage 1 (early ramdisk) if you use them.
The option services.openssh.hostKeys now allows specifying multiple
host keys. The default value enables both a DSA and ECDSA key.
(Clients by default will use the ECDSA key, unless known_hosts already
has a DSA key for that host.) To use only an ECDSA key, you can say:
services.openssh.hostKeys =
[ { path = "/etc/ssh/ssh_host_ecdsa_key";
type = "ecdsa";
bits = 521;
}
];
If the option is enabled, the DNS servers from networking.nameservers
will be inserted in /etc/resolv.conf after the DNS servers that
NetworkManager receieves by DHCP, or that is configured manually
in the connection settings.
If the option is enabled, the DNS servers from networking.nameservers
will be inserted in /etc/resolv.con and override any DNS servers that
NetworkManager receieves by DHCP, or that is configured manually
in the connection settings.
With this it's now possible to directly embed a configuration file
using `services.xserver.windowManager.i3.configFile = path`, which then
will be used instead of the one in the users home directory.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Running at a low priority is generally bad since it runs the risk of
priority inversions, etc. It's really the builders that should run
under a different priority (e.g. in their own cgroup).
