I told myself that XFCE is eye-candy enough for me and performs really nice without getting in my way while working in terminals.

Today, I switched my two main devices to KDE Plasma 5. Well, my notebook was actually switched yesterday. And because it was such a huge leap in “niceness”, I switched my workstation today.

I also switched my email setup to Korganizer with Kmail for mails. I am looking forward to see how that performs for me.

I always considered KDE the desktop for Linux. The one, normal users should use to get a first impression of Linux. The one, that will be there for “Linux on the Desktop” when it gets real. You know what I mean?

I never considered for a power-user setup. Power users use i3wm, awesomeWM, sway, ... but not full-blown desktop environments, do they? Well, on several occasions I met Kai Uwe, a KDE dev from a town not far from the town I grew up in. We've met on Linux-Days and other Community events. I always was amazed how fast KDE was on his machines. I was blown away by the usability. But I never really considered switching.

Until today.

Memory usage is where it should be: My desktop uses 3.6GB right now, with Cantata (MPD client), Riot-Desktop (Electron!), Telegram, Firefox and Kontact open (plus some more terminals and some services running in the background as well).

My Notebook was at about 5GB RAM usage with the same apps open and even some more stuff running in the background.

After that experience and also that performance on my rather old desktop machine, I'm blown away and am willing to invest time into getting to know how to be even faster and more productive than I am currently feeling with KDE.

tags: #kde #linux #desktop #software

Here's the guide for doing it.

Preface

In the following steps, I will download, unpack and build sources from scratch. My download and compile folder will be at $HOME/compile. My install folder will be at $HOME/install. I don't be installing stuff into my $HOME directly on the uberspace, because I want to be a bit organized here.

Thus, you might want to adapt your commandline calls.

Obtaining sources

First, you should go and fetch all latest sources for the whole dependency chain. I will not link to the individual tarballs, you should figure out the links for yourself to get the latest and greatest of each project.

Here's the list of links where you'll find the code you'll need to compile:

• https://www.samba.org/ftp/talloc/
• https://xapian.org/download
• https://notmuchmail.org/releases/
• http://www.muchsync.org/src/
• https://download.gnome.org/sources/gmime/3.2/ (because github release tags or gitlab release tags do not contain ./configure (thanks to gnome developers thinking it might not be necessary to actually include their build toolchain in the repository), you'll need to use this link).
• https://gnupg.org/ftp/gcrypt/libksba/
• https://www.gnupg.org/download/index.html (gpgme, libgpg-error, libassuan, npth, ntbtls, gnupg)

Configuring the build(s) and building

First of all, execute

mkdir -p $HOME/install/lib/pkgconfig
export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig/:$PKG_CONFIG_PATH

To make sure the pkg-config utility finds the right package configuration files.

It follows a list of configure calls for the respectice library/binary. I hope this list is complete and I didn't miss anything in the process. Feel free to mail-ping me if something is missing.

For all packages that are not listed here, a simple

./configure --prefix=$HOME/install && make install

did the job. For the following packages, it was not as convenient, but after successfully configuring, you can install all of them with a simple make install.

libassuan

./configure --prefix=$HOME/install \
    --with-libgpg-error-prefix=$HOME/install/

gpgme

./configure --prefix=$HOME/install \
    --with-libgpg-error-prefix=$HOME/install \
    --with-libassuan-prefix=$HOME/install

libksba

./configure --prefix=$HOME/install \
    --with-libgpg-error-prefix=$HOME/install

gmime

PATH=$HOME/install/bin:$PATH ./configure --prefix=$HOME/install

libgcrypt

./configure --prefix=$HOME/install \
    --with-libgpg-error-prefix=$HOME/install

ntbtls

./configure --prefix=$HOME/install \
    --with-libgpg-error-prefix=$HOME/install \
    --with-libgcrypt-prefix=$HOME/install \
    --with-ksba-prefix=$HOME/install

gnupg

./configure --prefix=$HOME/install \
    --with-libgpg-error-prefix=$HOME/install \
    --with-libgcrypt-prefix=$HOME/install \
    --with-libassuan-prefix=$HOME/install \
    --with-ksba-prefix=$HOME/install

notmuch

You might want to open a new shell for the environment variables

export LD_LIBRARY_PATH=$HOME/install/lib:$LD_LIBRARY_PATH PATH=$HOME/install/bin:$PATH
export LDFLAGS="$LDFLAGS -L$HOME/install/lib/ "
export CFLAGS="$CFLAGS -I$HOME/install/include/ -std=c99 "
export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig:$PKG_CONFIG_PATH

./configure --prefix=$HOME/install \
    --without-bash-completion \
    --without-docs \
    --without-api-docs \
    --without-emacs \
    --without-desktop \
    --without-ruby \
    --without-zsh-completion

muchsync

You might want to open a new shell for the environment variables

export LDFLAGS="$LDFLAGS -L$HOME/install/lib/ -Wl,-rpath,$HOME/install/lib/"
export LD_LIBRARY_PATH=$HOME/install/lib:$LD_LIBRARY_PATH
export CXXFLAGS="$CXXFLAGS -I$HOME/install/include "
export PKG_CONFIG_PATH=$HOME/install/lib/pkgconfig

./configure --prefix=$HOME/install --exec-prefix=$HOME/install

List of versions this guide was written for

This is the (alphabetically sorted) list of stuff I had to compile and install, including versions so you can figure whether you have something newer and might need to investigate on differences when compiling your stuff:

• gmime-3.2.7
• gnupg-2.2.21
• gpgme-1.14.0
• libassuan-2.5.3
• libgcrypt-1.8.6
• libgpg-error-1.38
• libksba-1.4.0
• muchsync-5
• notmuch-0.30
• npth-1.6
• ntbtls-0.1.2
• talloc-2.3.1
• xapian-core-1.4.16

Of course you should update your installation if new versions come out.

Happy compiling.

tags: #uberspace #email #linux

History

First of all, some history. I was introduced to “the other operating system” in grade 11 by a close friend of mine. At the time, I didn't know a thing about computers. I just graduated middle school (“Realschule” in Germany) and started high school (“Gymnasium” in Germany) and made new friends. My friend showed me his notebook, which was running Ubuntu Gnome 09.04 or something like that, and I was blown away by the fact that there was something else besides Microsoft Windows – and one also got it for free (as in beer).

Soon, I started with Kubuntu,... KDE 3 was amazing to me. Maybe half a year after my friend suggested, because I was only using terminal applications by that time – learning vim and so on – that I should try Archlinux. So Archlinux it was.

In 2015 I switched to NixOS, using i3 as window manager and was a Linux-only guy.

Today I use XFCE on NixOS and couldn't be happier. All my machines work perfectly well.

The reasons

Now that you know my history with Linux, let me give you some reasons why I use Linux today:

1. It works. Sounds strange, but for me this is perfectly reasonable: I've become a pragmatist – and because my setup, my machines and my workflow just suits me perfectly well, I absolutely have no reason to switch operating systems.
2. It is fast. Just today I had the opportunity to compare my workstation to the workstation of someone else running Windows 7. The workstations are approximately the same (so not handheld vs. datacenter): AMD 8 core processor with 16GB RAM on my side vs Intel i7 4-Core + Hyperthreading with 16GB on the other side. Tell you what? Mine is much faster with everything. From loading websites, loading applications, ... everything is just smooth and performs really well. Of course this is not a scientific approach in measuring and comparing these machines... but my point is not that my machine is faster, my point is: My machine is fast. My second machine, a Lenovo Thinkpad X220, is fast as hell as well – I never experienced any lagging or something the like.
3. I know what is going on in my machine. With Linux under the hood, I know what is running on my machine. With free (as in freedom) software, I actually can read what is going on. How many times have Windows users asked my why some application does not work as intended... How many times have I replied “Wait, I will check the Sourcecode on what it does... Oh, wait, you're running proprietary Software? Well... not my problem then, is it?” (yes, I'm a bit of a jerk in that regard).
4. I can configure how something should work! If I don't like how my menu works, how switching windows works or on which screen an application appears when starting it... I can change it! Some time ago someone complained that the “Print” dialog on his window machine always opens on the wrong screen. That's a problem I've never experienced with Linux or Linux-running machines. Just configure it how it should work – and then it does that!
5. If I don't like something, I can use something else! Well, if you purchase software and you don't like it, you cannot return it. Sometimes there are trial versions and that helps a lot – but what if you don't like the UI your operating system ships? Well, for me that is “uninstall XFCE, install KDE” ... ready to go, don't even need to reboot.
6. I can make it look as nerdy or as hipster-like as I want. Customizing a desktop environment is not one of my favourite ideas of how to spend an evening. But I could do it if I would like to.
7. I can adapt it to my workflow – I don't have to adapt my workflow to it. I'm a heavy user of keybindings. And I love having vim-bindings in my desktop environment, in my bash, in my tmux and in my vim (of course). I can configure that! Hell yeah, that's the power of free software! I can make it behave like I want to!
8. I don't have to rely on a company to fix their bugs! I can do it myself if I need to. Or I can pay someone to fix them!
9. It is free as in freedom and as in beer. For me, as a poor student, both count equally. I love to have free (as in freedom) software at my hands I can mess with. But it is also important that I can use it for free (as in beer). My friends at university pay hundrets of bucks for their Software,... I can use that money to do something else,... for example buying a camera and start learning photography! And because of the free (as in beer) image processing software, I can even post-process the images without purchasing expensive software for it!
10. I am a programmer. Unix (or in this case Linux) is my IDE! I'm also a techie and Linux is my playground.

Wanna try?

So, there are some good reasons for using Linux. If you want to try using Linux, go ahead with some of the beginner-friendly distros like Linux Mint Ubuntu Mate or Fedora KDE – and remember that you can make each of them look like the other – because with Linux, you have the choice!

tags: #linux#

But let me start explaining where I come from.

I started with Linux when I was 17 years old. At the time I ran an Kubuntu 9.04 (if I remember correctly) with KDE 3. I disliked Gnome because it looked silly to me (no offense, Gnome or Gnome people). So it was simply aesthetics which made me use KDE. Before switching to Linux I had only experienced the cruel world of Microsoft Windows, XP at the time. When I got a new Notebook for my Birthday, I got Vista and two days later I had this Linux thing installed (which friends of mine kept talking about). Naturally, I was blown away by it.

After some time I got rather comfortable using this black box with the green text on it – the terminal finally had me! Soon, I launched a full blown KDE 3 (themed hackerlike in dark colors) to start a few terminals, open vim and hack away. Then, the same friend who suggested Linux told me about “tiling window managers”. wmii it was shortly after.

A long journey began. After some troubles with Ubuntu 12.04 I switched to Archlinux, later from wmii to dwm and after that to i3 which I kept for a few years.

In 2015 I learned about NixOS, switched to it at the beginning of 2016 and in late 2016 I reevaluated my desktop and settled with XFCE.

And here's the thing: I wanted KDE, but it lacked one missing critical feature: Beeing able to sync its configuration between my machines.

I own a desktop machine with three 1080p Monitors and two Notebooks – a Thinkpad X220 and an old Toshiba Satellite (barely used), if that matters at all.

There are things in the KDE configuration files which shouldn't be there, mainly state information and temporary values, making the whole thing a pain in the ass if you want to git add your configuration files to git push them to your repository somewhere in the web and git pull it on another machine.

Apparently the story is not that much better with XFCE, but at least some configuration files (like keyboard shortcuts, window decoration configuration and menu-bar configuration) can be git added and synced between machines. And it works for me, even with two so different machines. Some things have to be re-done on each machine, but the effort is pretty low.

But with KDE (I tried Plasma 5), it was pure PITA. Not a single configuration file was untouched, reordering values, putting state information in there and so on and so forth.

And I am rather amazed with KDE and really want to play with it, because I think (and that's not just an attempt to kiss up to you KDE guys) that KDE is the future of Linux on the desktop! Maybe it is not for the Hacker kid from next door, but for the normal Linux User, like my Mom, your Sister or the old non-techy guy from next door, KDE is simple enough to understand and powerful enough to get stuff done efficiently without getting in your way too much.

So here's my request:

Please, KDE Project, make your configuration files human readable, editor-friendly and syncable (via tools like git). That means that there are no temporary values and no state information in the configuration files. That means that configuration files do not get shuffled when a user alters a configuration via a GUI tool. That means that the format of the configuration files do not get automatically changed.

The benefits are clear, and there are no drawbacks for KDE as a project (as far as I can see) because parsing and processing the configuration files will be done either way. Maybe it even reduces the complexity of some things in your codebase?

A word on “why don't you submit this to the KDE project as a request”: I am not involved with KDE at all. I don't even know where the documentation, bug tracker, mailinglist(s), ... are located. I don't know where to file these things, whether I have to register at some forum or whatever.

If someone could point me to a place where nice people will discuss these things with me, feel free to send me an email and guide me to this place!

tags: #open-source #software #tools #git #desktop #linux

This post was published on imag-pim.org as well as on my personal blog.

What we have

Right now, the logging implementation is ridiculously simple. What we do is: On every call to one of the logging macros, the log crate gives us an object with a few informations (line number, file, log message,...) – we apply our format, some color and write it to stderr.

This is of course rather simple and not really flexible.

What we want to have

I want to rewrite the logging backend to give the user more power about the logging. As we only have to rewrite the backend, and the log crate handles everything else, the actual logging looks non different and “client” code does not change.

+----------------------------+
| imag code, libs, bins, ... |
+----------------------------+
              |
              | calls
              |
              v
+----------------------------+
| crate: "log"               |
+----------------------------+
              |
              | calls
              |
              v
+----------------------------+
| imag logging backend impl. |
+----------------------------+

So what features do we want? First of all, the imag user must be able to configure the logging. Not only with the configuration file but also via environment variables and of course command line parameters. The former will be overridden by the latter, respectively. This gives the user nice control, as she can configure imag to log to stderr with only warnings being logged but when calling a script of imag commands or calling imag directly from the command line, these settings can be temporarily (for the script or one command) be overridden.

The configuration options I have in mind are best described by an example:

# The logging section of the configuration
[logging]

# the default logging level
# Valid values are "trace", "debug", "info", "warn", "error"
level = "debug"

# the destinations of the logging output.
# "-" is for stderr, multiple destinations are possible
default-destinations = [ "-", "/tmp/imag.log" ]

# The format for the logging output
#
# The format supports variables which are inserted for each logging call:
#
#  "%no%"       - The of the logging call
#  "%thread%"   - The thread id from the thread calling the log
#  "%level%"    - The logging level
#  "%module%"   - The module name
#  "%file%"     - The file path where the logging call appeared
#  "%line%"     - The line No of the logging call
#  "%message%"" - The logging message
#
# Functions can be applied to the variables to change the color of
# the substitutions.
#
# A format _must_ contain "%message%, else imag fails because no logging should
# be forbidden
#
[logging.formats]
trace = "cyan([imag][%no%][%thread%][%level%][%module%][%file%][%line%]): %message%"
debug = "cyan([imag][%no%][%thread%][%level%][%module%][%file%][%line%]): %message%"
info  = "[imag]: %message%"
warn  = "red([imag]:) %message%"
error = "red(blinking([imag][uppercase(%level%)]): %message%)"

# Example entry for one imag module
# If a module is not configured or keys are missing
# the default values from above are applied
[logging.modules.libimagstore]
enabled = true
level = "trace"
destinations = [ "-" ]
# A format is only globally configurable, not per-module

One of the most complex things in here would be the format parsing, as variable expansion and functions to apply are some kind of DSL I have to implement. I hope I can do this – maybe there's even a crate for helping me with this? Maybe the shellexpand library will do?

These things and configuration options give the user great power over the logging.

The approach

Because imag already logs a lot, I think about an approach where one thread is used for the actual logging. Because each logging call involves a lot of complexity, I want to move that to a dedicated thread where other threads speak to the logging thread via a MPSC queue.

Of course, this should be opt-in.

The idea is that the logging starts a thread upon construction (which is really early in the imag process, nearly one of the first operations done). This happens when the Runtime object is build and hence no “client code” has to be changed, all changes remain in libimagrt.

This thread is bound to the Runtime object, logging calls (via the logging backend which is implemented for the log crate) talk to it via a channel. The thread then does the heavy lifting. Of course, configuration can be aggregated on construction of the logging thread.

The logging thread is killed when the Runtime object is dropped (one of the last operations in each imag process). Of course, the queue has to be emptied before the logging is closed.

I am also thinking about converting the code base to use the slog crate, which offers structured logging. But I'm not yet sure whether we will benefit from that, because I don't know whether we would need to pass a state-object around. If that is the case, I cannot do this as this would introduce a lot of complexity which I don't want to have. If no such object needs to be passed around, I still have to evaluate whether the slog crate is a nice idea and of course this would also increase the number of (complex) dependencies by one... and I'm not sure whether the benefits outrule the inconveniences.

tags: #linux #open source #programming #rust #software #tools #imag

I was really eager to do this becaues the old style was... not that optimal (I'm not a web dev, let alone a web designer).

Because the site is now generated using hugo, I also copied the “What's coming up in imag” blog posts over there (I keeping the old ones in this blog for not breaking any links). New articles will be published on the imag-pim.org website.

This very blog article will be published on both sites, of course.

tags: #linux #open source #rust #software #tools #imag

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

What happenend?

Luckily I can write this iteration on imag. After we had no blog post about the progress in imag in April this year, due to no time on my side, I'm not very lucky to be able to report: We had progress in the last 4 (8) weeks!

Lets have a look at the merged PRs (I'm now starting to link to git.imag-pim.org here):

• #915 merged a libruby dependency for travis.
• #918 removed some compiler warnings.
• #917 merged some travis enhancements/fixes.
• #916 superceeded PR #898, which simplified the implementation of the FoldResult extension.
• #895 started a re-do of the ruby build setup.
• #911 changed the interface of the StoreId::exists() function to return a Result now.
• #904 added initial support for annotations in the libimagentrylink library, which gives us the posibility to add annotations to links. There are no tests yet and also no remove functionality.
• #921 was a cleanup PR for #911 which broke master unexpectedly.
• #914 fixed a compiler warning.
• #929 removed libimagruby entirely because we couldn't merge to master because a dependency on master started to fail. The whole ruby thing is a complete mess right now, dependencies are not found, tests fail because of this... it is a mess.
• #927 removed unused imports.
• #924 updated links in the readme file.
• #926 added tests for the StoreId type.
• #919 merged preparings for the 0.3.0 release, which is overdue for one month right now, because the ruby scripting interface does not work.
• #930 updated the toml-rs dependency to 0.4, which gives us even more superpowers.
• #932 added some tests for the configuration parsing functionality.
• #933 Adds a new dependency: is-match, a library I extracted from the imag source code into a new crate.

The libimagruby mess

Well, this is unfortunate.

libimagruby should be ready for one month by now and usable – and it is (the basic things, few things tested also)! But as the CI does not work (fuck you travis!) I cannot merge it. I also don't know how to properly package a Ruby gem, so there's that.

I really hope @malept can help me.

I'm already thinking about adding another scripting interface, so I can continue and start implementing frontends for imag, for example I'm thinking about a lua or ketos interface, still. Lua might be the better idea, as there are libraries around for certain things, while there are no libraries for ketos (I assume).

What will happen

I honestly don't know. I will continue working on imag, of course, but right now, the libimagruby is stalled. I'm not sure where to start working besides libimagruby – a Ruby scripting interface is what I need right now, but it won't work ... so there's that.

As soon as the Ruby interface is ready, we can have nice things. But right now, it is really hard to continue.

tags: #linux #open source #programming #rust #software #tools #imag

And today I rewrote large parts of my vim configuration. Here's why.

Dead mappings

I removed a lot of mappings from my vimrc that I did not used. For example: I had a mapping in normal mode that'd fire up fzf for the complete filetree I was in. I didn't use it in months, maybe more, because I use netrw (the vim-builtin file manager).

I don't need plugins

Well, at least you don't need the most of them. First, I removed maybe three or four plugins I didn't use at all, for example the “linux-kernel-style” plugin or “Goyo” and “Limelight”. Not because I didn't like them (I do, believe me), but because I simply did not use them at all. I also removed everything with snippets, because I barely used them. So “UltiSnips” and all the snippet packages are gone now.

Then, for example, I had the vim plugin “vim-indent-guides” with a great snippet of viml I found online:

" Simple replacement for vim-indent-guides
"
" unicode characters explained:
" tab: \uBB == ">>"
" trail: \uB8 == "-" in red box
exec "set listchars=tab:\uBB\uBB,trail:\uB7,nbsp:~"
set list

This does the very same as indent-guides and even does more, because I can have a dot (unicode character \uB7) if there is trailing whitespace at the end of a line. I really like that!

vim as server

Because I'm running XFCE, as explained in another post for some time now (and I still like it), I figured that I could use gvim instead of commandline vim. But gvim startup time is not that great – so I figured that I could use the awesome vim server capability to have only one running vim instance.

So I re-configured my aliases to be

alias vim="vim -g --servername VIM --remote-tab-silent";

for example, so I automatically start in a running gvim instance (which has the name VIM by default). If no vim instance is running, this automatically starts a new gvim instance.

But because I'm a notorious :q-hitting vimmer, I remapped :q:

if has("gui_running")
  cnoremap <silent> wq<CR> w<bar>bd<CR>
  cnoremap <silent> q<CR>  bd<CR>
  cnoremap <silent> x<CR>  bd<CR>
  nmap <Leader>q :bd<CR>
endif

So when I hit :q it actually executes bd, which just closes the current buffer. If the current buffer is the last buffer, it enters an anonymous buffer instead. This is really awesome! To actually close my vim session, I have to :quit now, which is longer and therefor I have more time to stop myself from doing that.

Edit 2017-03-06:

The code above did not completely work as intended, so I changed it to the following:

if has("gui_running")
  fu! CloseWindowOrBuffer()
    if winnr('$') == 1
      if bufnr('$') == 1
        :echo "Closing last instance not allowed"
      else
        :bd
      endif
    else
      :close
    endif

  endf
  nmap <Leader>q :call CloseWindowOrBuffer()

  cnoremap <silent> wq<CR> w<CR>:call CloseWindowOrBuffer()<CR>
  cnoremap <silent> q<CR>  :call CloseWindowOrBuffer()<CR>
  cnoremap <silent> x<CR>  bd<CR>
else
  nmap <Leader>q :q
endif

I'm still not sure whether this is what I want.

env!

Finally, I set my $EDITOR and $GIT_EDITOR variables to

export EDITOR="vim -g --servername VIM --remote-tab-wait-silent"
export GIT_EDITOR="vim -g --servername VIM --remote-tab-wait-silent"

To get the best experience when calling vim through scripts or other programs like git.

What I want to get from this

Well, I made my vim installation a lot less bloated. By removing a bunch of plugins I made vim start up way faster, and by using only one vim instance for all the things, even more. Using gvim, I can have pretty fonts and so on.

I wonder how these things work out for me...

tags: #desktop #linux #vim

So I got a new SSD and installed NixOS from my old installation. Here's how.

So I got a nice new Samsung EVO 850 PRO with 256 GB. I was really amazed how light these things are today. No heavy metal in there like in a HDD!

Preparation

First of, you need to prepare your current installation. Make some backups, be sure everything is fine with them.

Then, verify that your configuration.nix and your hardware-configuration.nix file list your partitions not by UUID, but by /dev/sda1 and so on. That could be really helpful later.

If you have some crypto keys you need to keep, maybe make another backup of them.

The installation

First of, we need to format the new drive. Use gdisk for this if you have a UEFI setup like with an Thinkpad X220. Format your partitions after that. Make sure that your boot partition is formatted as vfat (fat16). I don't know why, but it is only possible to boot from vfat, according to the nixos documentation. Also, do your cryptsetup.

For simplicity, I refer to the boot partition by /dev/sda1 and to the root/home partition as /dev/sda2 – you can, of course, have more partitions, maybe for a seperate /home. But I saw no need for it. With only one partition I do not have to take care of the size of the /nix/store and if I have few things in the store I can grow my music collection a bit – so I'm really flexible. And yes, I know about LVM, but I really don't need these things, do I?

Now, mount the partitions as follows:

• /dev/sda2 in /mnt
• /dev/sda1 in /mnt/boot (you might need to mkdir this directory first)

Ensure things are properly mounted. This broke my neck twice during my installation, as /mnt/boot wasn't mounted properly and I failed to rebuild the system. Took me some time to see this, actually.

Now you can nixos-generate-config --root /mnt. After that you might want to modify your configuration.nix file in the newly generated setup under /mnt/etc/nixos/configuration.nix – I did not! I nixos-install --root /mnted to get a minimal bootable system.

Then I rsync -aed my /home/$USER to /mnt/home/ and symlinked the configuration.nix (which lives in /home/$USER/config/nixos/$HOSTNAME.nix on my machines) to /etc/nixos/configuration.nix. I renamed the host as well, to avoid confusion.

Then, I shutdowned, removed the old SSD, assembled the new one and booted. I had some problems with failing mounts during boot (because I had mount operations specified by UUID rather than via /dev/sdaX). I got a rescue shell and was able to fix things up. After several reboots I was able to get my system up and running.

When I was able to boot my minimal installation, I just followed the manual and created my user and so on. Then, I nixos-rebuild switched. And because I copied my whole configuration.nix setup from my old drive, everything got build for me.

After some more nix-env -iA calls (because some things only live in my user environment), I fully restored my system. Awesome!

Conclusion

Installing NixOS from NixOS works really nice. You have to be careful with some things, UUIDs and so on, but overall it is rather simple.

Anyways, you benefit if you really know your system. I wouldn't necessarily recommend this to an inexperienced NixOS user – hacking things into the TTYs and getting a rescue shell for fixing the installation is no thing that a newbie really wants to do – except for learing and if backups are at hand!

Because of the awesomeness of NixOS and the configuration.nix file, I was able to rebuild my complete system within a few minutes. Despite my extensive adaptions in my configuration.nix file – speaking of container setup, custom compile flags for packages, custom vim setup with plugins compiled into the vim derivation (and the same again for neovim), hundreds of packages and stuff – I was able to rebuild my system without much effort.

Overall, leaving out the UUID fail, I think I am able to redo a complete setup (including syncing /home, which was ~100GB data, and reinstalling everything) in maybe 90 minutes, depending on how fast the internet connection is for downloading binaries.

One could even mount the old /nix/store from the old installation and copy over derivations, which would be a hell lot faster and would result in a reinstallation without the need for internet access. But I don't know how to do it, so I leave it as exercise to the reader.

tags: #desktop #linux #nix #nixos

Here's why.

Right now, I'm writing this very blog post in gvim in a xterm on xfce4-12. Why did I leave i3? Well... I love i3, I really do. It is the perfect tool for beeing productive with a lot of terminals.

Although, I have noticed that I use tmux more and more lately. Having a terminal multiplexer at hand means you don't have many terminals anymore.

So I thought: Switch away from i3?

I thought about switching to a framebuffer terminal, moving away from X11 entirely. I could have used elinks, tmux, mutt, newsbeuter, rtv, rangern, of course vim and so on... but only on a framebuffer terminal.

But that wouldn't work well with multi-monitor setups. I thought about KDE5, a lot actually. But KDE is too heavy for me.

So what is a good alternative to KDE, leightweight, has nice performance but also looks nice? Yes, XFCE!

And so far, I really love it!

The only problem I have is, of course, syncing of configurations via git. It seems that XFCE writes state information to the configuration files as well, which is unfortunate. What I will do: Not track the configurations except maybe the keyboard bindings. I hope that'll do.

So I have a nice-looking desktop environment now, which has nice keybindings for doing all the things I did with i3 as well – speaking of tiling. I configured the XFCE desktop to do basic tiling like i3, yes. That gives me the same productivity I had with i3 before. One thing I couldn't figure out by now is how to switch the focused monitor with a keybinding. That might not be possible at all, which would be unfortunate, though I guess I can live with that.

A nice side effect of my new setup: People I work with don't think “What a hell of a nerd” anymore. Not that I care about what other people think, but this way they might get the impression that Linux on the Desktop rocks – and I guess this is a nice thing to have, isn't it?

tags: #software #linux #desktop #life