This blog is now hosted via ipfs as well.

What does this mean?

This means that you can access this blog via this IPNS name directly. As it is hosted in a distributed manner, a node which has the content must be online, else the retrieval fails. I try to keep nodes online which host this content, though I cannot promise anything, of course.

Old versions (starting today) of this blog can be found here, also hosted via IPFS. So you can see all typos I correct now and then.

How can I help?

You can help hosting this very blog by installing ipfs and pinning the latest hash (which is QmefDSDRcNyQUzNaVJnazQ7GpynjyEzPrdo1sdEk8ZLt8a as of writing, but might be changed by now).

hash=$(ipfs name resolve QmX95tkM6em8MP1SDs9Qae1G9YscqwozQJbX5rWTTYcJea)
ipfs pin add -r "$hash"

The newest version will be published under this name:

/ipns/QmX95tkM6em8MP1SDs9Qae1G9YscqwozQJbX5rWTTYcJea

So you can poll the newest version of this blog by re-resolving this name and pinning the contents via ipfs pin add -r.

How is it done?

Well, that's rather trivial. I have an ipfs daemon running on my machine and a bash script for adding the contents of this blog to ipfs. Each time I run this script, it adds the blog contents to ipfs and writes the last hash to the “old-versions” file. After that, it publishes the name.

So my workflow is like this:

1. Run hugo to update the blog sources locally
2. Run my ipfs publish script to publish the site in ipfs
3. Run my publish script to publish the site on beyermatthias.de

You really should host your things with IPFS as well!

Additional notes

What I had to do before this worked with “hugo”: I had to ensure hugo did not generate absolute URLs. Because if each link links to the full URL of the blog (beyermatthias.de/yaddayadda), each link in the IPFS-checked-in-version links to this URL as well. Instead, each URL has to be relative to the current location, then, the IPFS versions link correctly.

tags: #blog #server #tools

I use vim for my everyday things. No, actually I use vim for everything.

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

When the last semester came to an end, I noticed that my Thinkpad behaved weird. I couldn't nix-store --optimize it, and some other things began to fail silently. I suspected the SSD was dying, a Crucial C400 with 256GB. So I ran the smart tools with a short test – But it told me everything was alright. Then I ran the extended self-test on the drive and after 40% of the check (60% remaining) it told me about dead sectors, nonrecoverable.

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

This is the 23th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

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?

I'm a bit late this month, I know. Anyways, things happened in the imag distribution and I'm eager to write them down, so here we go!

In the last four weeks I merged a lot of PRs – 27 actually! Here are the most awesome ones:

• #836 eliminated the EntryHeader type entirely from the codebase. We are using toml::Value objects now!
• #852 was contributed by @mario-kr to enable cargo workspace support! That was a really awesome PR, as it reduced our build times down to ~4 minutes!
• #854 removed a lot of things (>4k lines) due to the focus-shift to libimagruby (read below)
• #871 added the ruby build setup (read below)
• #872 and #873 and #874 and #892 fixed some things to compile with fewer warnings. Awesome!
• #878 updated the regex dependency.
• #894 reverted the changes from #871 as it broke master :–(

Ruby?

Yes, Ruby!

We implemented the libimagruby, which contains Ruby bindings for libimagstore. So imag can now be programmed in Ruby!

There is a release (0.3.0) in the pipeline (waiting for fixes in cargo), which will then contain rudimentary support for programming the store in the wonderful Ruby programming language. I've written about that before and now it finally works. It is just not released yet.

The next release (0.4.0) will then contain more functionality to program imag, including some more bindings for libraries.

I think this will speed up development a bit, as we have more libraries in Ruby available.

What's coming?

Well, I hope to get out 0.3.0 soonish. We have to wait for Cargo, as we ran into a bug (misbehaviour) of cargo with the current release. As soon as the next cargo version is out I will try to release 0.3.0 and then we'll see...

Of course, I really hope to get some binaries implemented then. Starting with imag-diary and imag-mail, but also more advanced things like imag-music, imag-calendar and imag-contacts.

tags: #programming #rust #software #tools #imag

I just released my task-hookrs crate in version 0.3.0!

Here's what changed.

This release was made because I could update the serde dependency to 0.9, which gave me the ability to remove tons of code:

$ git diff --shortstat v0.2.2..v0.3.0
11 files changed, 126 insertions(+), 492 deletions(-)

because we now have custom derive! So I could remove my custom implementations for Serialize and Deserialize.

v0.3.0 also has some changes in the API, so not another 0.2.x release. This release pins the minimum compatible compiler to rustc 1.15, too.

So, all in all, this release really was a step forward from my point of view.

tags: #programming #software #open-source #tools

I switched to xfce. Yes, I really did, after more than 6 years on i3.

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

Lennart Poettering gave this interview where he said some thing which lead me to the conclusion that he misunderstood some things about unix.

So I do not want to bash systemd or Lennart himself here. This is not a “I hate systemd” article, to be honest, I even like systemd. I acknowledge that a lot of people hate systemd for specific reasons, and I even can agree to a certain degree with some of these points, but overall, I do not hate it.

Everything is a file. Yes it is.

Lets talk about the article from above. There are two things I want to talk about here. The first one is the everything-is-a-file concept:

One of the most well-known concepts that people often cite about Unix is that everything’s a file. I personally think that’s a complete bullshit thing. That’s because everything is not a file. My printer is not a file and if Unix pretends that my printer is a file, that’s complete rubbish because a file is a very different thing.

The above quote is from the article.

I think that Lennart completely misunderstood what the concept is here. Yes, in Unix “everything is a file”. But, in my understanding, this is not a rule but rather an abbreviation to explain an abstraction. The “everything is a file”-thingy is nothing more than a way to interface with things. Fundamentally, there is not such thing like a “printer” or “graphics card” - at least there is no other way to represent those in a operating system, besides a file.

Unix does not say that everything is a file (note the missing quotes in this sentence). It says that files are the interfaces for all the things. The actual quote

Everything is a file.

is just a way to tell users in a short and time-saving manner how Unix abstracts hardware.

Lennart continues...

He said that most people who are programmers will eventually learn about object-oriented programming, hopefully at university or another school. They will find that the most abstract concept that object-oriented programming has, how it sees the world, is generally the object.

which I hope will never be the case. Object orientation is dead.

Do one thing! Do it well!

The second point I want to talk about here is the idea of Unix that a program should do one thing only but do it well.

Lennart says

People often complain that systemd has one large repository where a lot of components are living in one source code repository. They think that is not Unix and that’s actually the greatest rubbish of all. Because if you look at BSDs, which unlike Linux are actually true Unixes, they all maintain pretty much the entire Kernel and user space in one single source code repository. Contrary to what people think, in Unix, everything ended up being maintained in one repository, just like systemd.

which also completely misses the point.

The whole idea is not that everything should be kept in small repositories and cleanly seperated – I really do not care whether my system comes from one giant repository or from hundreds or even thousands of repositories. And I bet nobody does.

What people are complaining about is that systemd does not do only one job. systemd does not have one concern but many. Is it an init system? Is it a service/job control system? Is it a bootloader? Is it a time synchronization application? Is it a package manager? Is it a printer daemon? Is it a container/virtualization layer/helper/manager? Is it a <insert thing>? No, it is not – and yes, it is all of them. And exactly that is the problem people complain about. It doesn't seperate concerns.

Conclusion

I know that Lennart has always an open ear for concerns and critical voices - at least he once wrote that.

I guess he got some things wrong here and I hope that if he sees that he will understand the concerns of the broader community.

---

Please note that this is my view on the things. I'm also just human and I might got things wrong here(, too). I'm more than happy to learn, so if you have anything you want to talk to me about, feel free to send me an email. I know the topics I scratched here are more than emotionally discussed in the community. Because of this: Please keep it calm if you send me an email, keep it technical. I will happily ignore emotional stuff.

Tags: #linux

After a full night of work (honestly I haven't slept in 26 hours now, working for my masters thesis), the next version of Cursive was published. I immediately had to drop a mail to the author and thank him for his wonderful work.

And this got me thinking...

Sometimes, being awesome to each other is not being friendly, acknowledging others work or enthusiasm about a thing or being tolerant about decisions others have made which might not fit ones own ideas of how life should be.

Sometimes, being awesome to each other can be a simple thing like just saying “Thank you” when it isn't expected.

I do that for quite a while now – dropping other open source authors a “Thank you” mail. But you can be sure – it happens rarely – it is still something special. I write maybe two or three “Thank You” mails per year.

So if you receive one, you can be sure: I deeply value your project!

tags: #life #social

This is the 22th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

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?

My masters courses are hard (time-wise). I didn't manage to do anything at all in the imag codebase. I hate it. I really want to get imag in a usable shape. So here's what I want to do to make this huge task a bit more achieveable.

Focus shift

I wrote about integrations before. I want to shift the focus of my work on imag to develop a Ruby gem from the imag functionality. This will be the next release. I will write either one or several gems with the imag libraries as backend, so one can write integrations in Ruby. I will do this because I think that the Ruby ecosystem fits the problem pretty well.

So what is the problem?

The problem is the following. We have a working imag store. We have working libraries on top of that “database layer” – namingly tags, refs (though they could use some polishing and features) and most importantly links (both external and internal).

What we do not have is the whole $tool -> database stuff. So we cannot put mails into the store, because we need to parse mails. We cannot put calendar data files into the store, because we need to parse icalendar. We cannot put contacts into the store because we need to parse vcard. And so on and so forth.

But the Ruby ecosystem has libraries for all these things.

So the obvious solution is to write a Ruby integration. We can then write the simple data-format-transformation tools in Ruby and we will be faster implementing it. We do not need the guarantees Rust gives us here – they would be nice, but they are not necessary!

Later, for querying the store, we can write the simple stuff in Ruby as well and the more complex stuff – or the performance-critical parts – in Rust.

How to do the shift?

I guess I will branch-off a major branch for the shift and remove some of the functionality which is already in the repository, namingly:

• imag-bookmark
• imag-counter
• imag-diary
• imag-mail
• libimagbookmark
• libimagcounter
• libimagdiary
• libimagmail
• libimagnotification
• libimagtodo

These tools implement functionality which would be way better be implemented in Ruby.

Clearly, some functionality can be kept. We can keep some of the more basic commands:

• imag-link
• imag-ref
• imag-store
• imag-tag
• imag-view (though a Ruby tool might come up with way better functionality)
• libimagentrytag
• libimagentryview

And the related libraries will be kept as well:

• libimagerror
• libimagref
• libimagrt
• libimagstore
• libimagstorestdhook
• libimagutil

I'm not sure about imag-notes though. A Ruby tool might have better functionality for this, though imag-notes works for me pretty well so far, so we might keep it, and its library:

• imag-notes
• libimagnotes

The other libraries... I'm not sure. Maybe some of the tools listed above need them (really... I haven't looked at the codebase for a long time now cry). So maybe we must keep them, maybe we can remove them:

• libimagentryedit
• libimagentryfilter
• libimagentrylink
• libimagentrylist
• libimagentrymarkdown
• libimagtimeui
• libimaginteraction

imag.rb

And we will introduce one new crate: imag.rb. This will be a ruby crate – so we will use ruru to build a Ruby gem out of the functionality implemented in the core crates. Clearly, the first step would be to put the libimagstore interface into this crate (plus its dependencies, libimagerror, libimagutil, ...), but I guess it is a good idea to have libimagtag, libimaglink and the functionality of the other core-libraries in there as well.

How long?

Your question might be: How long will this take? Well. Yes.

I really don't know. As said countless times: Masters degree is engaging. I hope I can get some things done after my exams (which end mid-february). until then – I don't think I have time to do much things.

Help is appreciated, though!

tags: #programming #rust #software #tools #imag

I just found the website githubreportcard.reflect.io which generates github user statistics for 2016.

I went ahead and tried it out. And hell yeah, 2016 was a productive year!

Of course, I worked a lot on imag, which resulted in a lot of changes. But I also did other things in 2016... and guess what? Rust is not the language I wrote the most code in – at least not by repo count!

So let me show some of my numbers:

“This year I made 3,438 commits across 40 GitHub repos in 12 languages.”

12 Languages? Well... yes! I don't know what these languages are, but here are some of them listed (ordered by number of repositories I contributed to): TeX, Rust, Shell, Ruby, C, Racket, Nix, Unknown, PHP. Yes,... “Unknown” is also there, I'm not sure what this is, actually.

Let me show some more numbers:

My Additions – 151,411 My Deletions – 92,512 My Open Source Changes – 95,290

Hell yeah! 151.411 lines of code? Holy sh!t! That's huge, isn't it? I'm not sure where this all comes from ... a huge portion must be from imag. Thinking of some repositories I also deleted in 2016 because they where old... this number might be even higher!

While I guess that 2017 won't be as productive as 2016 (because masters degree, blabla ... you know it – and because a long journey which is planned in summer), I really hope I can have a decent statistic at the end of this year as well.

Enough of me – what about you? What's your github graph of 2016 like?

tags: #github #life #open-source #software #programming