| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This allows for a more dynamic workspace assignments, especially when
varying between the number of heads. We now not only can use the NixOS
module system to set workspaces but also assign applications to them.
And the default workspace layout is to evenly spread out the heads among
the available heads.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
This was only a cable problem and is fixed now, so we don't need to
enforce anything anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
We now have two disks only and the disk containing the bootloader from
the previous layout is now gone so we need to write it to the new disks.
Of course, we also need to switch two swap devices as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
We only defined kernelParams within the body of "let" but didn't
actually use the attribute in 2df7ee103a01da34c9c82235bc286dde35e0f1ba.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, the main board has died so I needed to quickly assembly a
replacement machine. I haven't found a compatible main board for the
last set of hardware so the "new" machine is now a Core 2 Duo with only
2 GB of RAM.
I'm looking forward to more frustrations during build I already had with
the i7 I had previously.
Also, all these changes are untested for now, because I'm still
shoveling the btrfs filesystems to two new hard disks, because the new
mainboard only has 2 SATA ports.
At the moment the GRUB bootloader is still on the old disk and as soon
as the data is on the new disks, the GRUB install devices will change as
well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
| |
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
This adds the kernel patch to all machines and uses it as the default
scheduler. Let's see when I need to scream at the edit of a commit
message again, because the disk is busy and the editor is waiting for
I/O.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
| |
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>
|