| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
| |
This was changed during the unified kernel config refactor.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
The attributes driSupport32Bit, s3tcSupport and videoDrivers are now no
longer in services.xserver and now reside in services.mesa.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
| |
Haven't noticed that we already have a service module for synergy, so
let's use it instead of just executing the client/server on X session
initialization.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
| |
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
Referring to kernelPackages recursively is no longer needed in current nixpkgs,
so let's remove it :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
No changes in functionality, only style change, as using inherit is much easier
on the eyes than repeating those attributes twice.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
| |
No feature changes, it just caused eye cancer to me.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
This should get rid of the duplication already marked with XXX and of course
should make the machine-specific configuration way easier to read.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
| |
Just committed the new multi head option upstream at NixOS/nixos@0129717.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
So, now we no langer need to issue synergys by the window manager or in the
shell, just log in and everything is set up :-)
Well, of course you should only do something like this in a trusted environment,
because this means, that mouse movements and keystrokes are sent unencrypted! Be
sure to set up a SSH tunnel or something similar if you're in a hostile
environment.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
In my case this is just dual head for this machine. Synergy is not yet added to
the NixOS configuration, but this is in preparation for it to work.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So, this was a big adventure during the last days, because as you might have
guessed from my older configuration this was a single-disk system. And that
single disk failed, so I had to do data recovery instead of actual useful things
in upstream NixOS. Fortunately I could recover everything, so nothing is lost...
just a bit hard to find :-D
Anyway, the new filesystem layout is now without LUKS and LVM, as I really want
to have the flexibility to change striping/raid behaviour per file and possibly
encryption as well someday.
Well, as you might have noticed from the previous commit: ecryptfs is now built
into the kernel and is currently my workaround for encryption until btrfs
finally gets native crypto support.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
| |
So, this is the first step towards enhancing manual kernel configuration. Of
course. this still looks a bit ugly because I personally don't like
all-uppercase variable names for the kernel config and it still needs to have a
few more expressions to properly handle value types (y/n/m, int, hex, string).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I'm just using the kernel source from mmrnmhrm, even though it's older than
dnyarri's kernel config. The reason is because I want to make sure that a
nixos-rebuild won't bring up any changes. It is rather unlikely, but I better
want to make sure it won't happen.
Afterwards, let's upgrade that old kernel, because the 3.7.0-rc7 tag was pushed
by Linus just about two hours ago.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
| |
|
|
|
|
|
| |
This should at least clean up some of this mess and only hardware and filesystem
specific stuff should now endup within the respective machine expressions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
The network.nix file roughly resembles a charon network expression file.
Not that i intend to use charon in order to manage both machines right now, but
it definitely makes sense that way. At the moment the network.nix file is just
imported by /etc/nixos/configuration.nix on both machines, pointing to the
respective attribute set.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
