I wrote about imag before. I wrote about the problems I see with PIM on the commandline and how I want to solve them.

Well, it happens that some of my friends stepped up and reviewed the implementation (in manner of Software architecture) and suggested a design-overhaul. So this is what is happening right now.

As I stated before, I wanted the whole project to be a bit like git: each subcommand is an own executable, you can easily re-use parts of the code in your own projects as library and so on. This was one major point why we removed the whole codebase and started from scratch. Well not really from scratch, as the history is preserved and we can re-use parts of it by digging into the git-history. And, of course, the experience is not lost at all.

But before we did that, I set up a document where we can specify and document what we do. The major point of the paper is to define how the modules should work and what kind of interface they should export.

Some of these things are work in progress, some other things are already defined.

The roadmap changed a lot, of course. As we have now several libraries to implement and later glue together, we have a lot work to do on defining interfaces and (re-)implementing functionality.

I consider this as great opportunity to learn a whole bunch about software architecture.

We also applied some tweaks to the repository. We have now homu for merging and editorconfig so we are all in the same coding style.

The paper is written in pandoc-Markdown, so the paper can be read in either Markdown with your favourite text editor, PDF or as web-page (HTML). Both of the latter have to be compiled first, of course.

I hope enough people care about this project, so we can make it happen as fast as possible. I really want this to succeed, as I would personally benefit a lot from it.

More posts on this topic will follow, of course.

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

In my blog article On the sad state of PIM for nerds I ranted over the lack of a PIM (Personal Information Management) suite for the terminal (and therefor for nerds like me).

I said that such a suite would be awesome to have and I listed some core features such a suite should have. I also said that I might not have the time for this. I was wrong. I just released version 0.0.1 of “imag” today.

“imag” stands for “Information ManaGement”. Not that creative, though I like this name. I just released version 0.0.1, which is in pre-alpha shape. I also only contains one “module” of the whole idea – a bookmarking module, where you can store your bookmarks and add tags to each of them.

The roadmap

There is a roadmap on github, this is the idea:

• Release v0.0.2 : Notes Module.
• Release v0.0.3 : BM + Notes combination, where one can link to bookmarks from a note
• Release v0.0.4 : Show meta-module for showing content of arbitrary modules
• Release v0.0.5 : Todo Module. Might wrap taskwarrior here. Not decided yet.
• Release v0.0.6 : Calendar Module, using icalendar standard
• Release v0.0.7 : Contacts Module, using vcard files

These are the releases planned so far, more planned Modules are (in alphabetical order):

• (Shopping)Lists Module
• Bibliography-Management Module
• Diary
• Ledger – to track personal finance
• Mail Module – to index email and link to from other content
• Movie library tracker – to index movies and link to from other content.
• Music library tracker – to index music and link to from other content.
• News Module – RSS/Atom, maybe using external tools like newsbeuter, undecided.
• Podcast module – implementation details completely undecided here
• Project planner – implementation details completely undecided here
• Wiki Module – expansion of the notes module with subpages and so on

Other things to do

There are more things planned in the github issues, like output formatter, where we can print all things with JSON (for example) so one can include “imag” in scripts. Also, an integrated webserver where one can view content as website would be nice (though I don't like the idea of editing content via a web page). Basically I'm open to all ideas.

Also one major paint point right now is the following: I have not yet integrated git support. So the file store is not yet version controlled, and I really have to do this soon, so I'm save.

I also did not think about encryption yet. I am thinking about encrypting the store and decrypting it on every call to “imag”, but I'm not sure whether this is the right way, as some application might call “imag” in background later (see next chapter). I'm not even sure whether I should encrypt the store at all, as the user should encrypt his or her device anyways.

Implementation, License, call for contributors

Well, as I want to be safe, I implement “imag” in Rust, my new favourite programming language. If you want to learn Rust, you are welcome to join me, as I'm also still learning things.

“imag” is licensed under the terms of LGPL v2. This is because “imag” might be used to be integrated into other software, maybe someone wants to write a curses frontend for “imag” at some point? Maybe vim plugins? Or something similar? I'd welcome it!

That said, I have to implement the core features first. Linking between content is one of my desired core features and will follow as soon as the notes module is implemented. As the readme file also says, there is a lot to implement, but not that much modules with actual user input. Only four modules: Notes, Shoppinglist, though I guess I will implement this one without user-input support as it only holds a list, then the wiki module and the Bibliography module, whereas I'm not sure whether this one has user input as well. So basically two modules have actual user generated input (speaking of text a user is supposed to edit with an text editor). All other modules contain structured data (JSON) the user can edit via the commandline.

All this is not carved in stone yet and I'm happy to argue about the points I just mentioned. Also I'm happy to argue about more modules and of course I'd love to see pull requests on github!

So feel free to contribute!

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

Almost all issues for the 0.2.0 release of imag are done.

Here are some notes how I want to do releases before the 1.0.0 version of imag, which, of course, is really not there yet. But I had to think about a decent release strategy for the 0.x.y releases, so here the notes.

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 existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

First, all the things I note here apply to releases before 1.x.y, so basically all 0.x.y releases.

I want to do 0.x.0 releases with a bunch of new features every 3 months or something like this. This time range is not fixed, and releases will happen if they are ready, but 3 month is a good first idea, in my opinion.

I won't declare a fixed set of features for every new version, but move around some features as I like, but I try to keep the number of changes decent. For example, the 0.2.0 release has 49 closed and 13 open issues/prs at the time of writing. As I sometimes do more PRs per issue and sometimes just one PR for one issue, or even file PRs without an existing issue in the first place, this number might vary, but I guess about 100 issues/PRs per release should be a maximum.

What I want to do, and what I already do: I mark issues as

• optional if they are optional for the release they are attached to
• soft-required if I would like to get them into the release but wouldn't mind moving them to the next release
• hard-required if they have to be in the release.

I also set a release date. hard-required issues will get my attention first, I try to implement them as soon as possible and get them ready. After that I focus on soft-required things and after that on optional things.

hard-required issues might postpone a release date. soft-required and optional issues do not. But if an issue has to move to the next release, because the release-date is near and the issues are not solved by then, they will automatically advance.

That means, if an issue is optional in 0.2.0, it will get soft-required if it has to move to 0.3.0 and hard-required if it has to move to 0.4.0.

This way, one can easily calculate when a feature will definitively be implemented in the imag codebase.

---

Another thing I try to do: Plan ahead a bit. At the time of writing, the milestones for 0.2.0, 0.3.0 and 0.4.0 exist. I won't create a 0.5.0 milestone before 0.2.0 is done, so I try to plan ahead about two releases, which equals about six months.

---

I will do y-releases (as in 0.x.y) if I encounter a really serious bug. But as we do not guarantee anything right now (see below), I doubt that will ever happen.

---

All the things I wrote above are ideas how I want to do it. I will see how things work out and we'll see whether this is doable for me or not. As I already said somewhere, I'm starting my masters degree this week and I don't know how the workload will be. I really hope I can get things implemented as planned, but I might have to move issues to future milestones if I notice that things are not doable for me in the planned time.

Also, as we are in the 0.x.y release phase, I won't give any guarantees on stability and interfaces an so on.

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

I just noticed that I have no blog article about nixos-scripts version 0.3 yet, though the tool was released exactly one month ago.

So I catch up on this now.

Changelog

The third release contains some neat things for the “switch” and the “update-package-def” command, lets start with the latter.

The “update-package-def” command is now able to translate arguments for --cores and --max-jobs now, so you can pass the number of cores or jobs to use for the build. This is extremely helpful for updating large packages. I myself happen to maintain a set of rather small packages, but from time to time I want to update packages I do not maintain, for example i3 or similar packages. Building these packages with more jobs results in much better build time, especially on my OctaCore processor.

The “update-package-def” command is now able to push to a pre-configured remote after successful build now. So your update-workflow is a bit smoother now:

1. Get the URL for the patch from monitor.nixos.org
2. Run “update-package-def”
3. Create pull request on github

The “switch” command got some neat updates as well. First of, the command is now quiet by default. This means you don't get this noisy output anymore when updating your system, as nixos-rebuild is called with -Q now. The command has changed some background behaviour: The nixpkgs repository (if known) gets updated (via git fetch) before a tag is created. This way we can be sure the commit exists before creating a tag on it. Tagging is now disabled for build as command type. Also the codebase was refactored, so its maintainability was improved a bit.

Another big point is the “channel” command. We have commands for channel updates now, they also create tags in your configuration repository. My workflow for updating my system is now:

nixos-script -v channel update
nixos-script -v switch

Which updates the channel with the first command and rebuilds the system with the second command. I don't use the nix-* commands anymore for my system, really!

We have another command (“container”) for container management. This tool has three subcommands:

1. “setup” for building a new container from a template. You can specify a configuration.nix file, which will be copied to the container after it is created. It will call your editor to customize the configuration file right afterwards and rebuild the container then.
2. “stats” which prints a simple table with statistics about your containers (name, IP, status and host key).
3. “kill” kills a container and gives you the option to destroy it as well.

More options will be added to the container subcommand as soon as I need them. We'll see...

The “show-generation” command is now able to show generations from a custom profile.

A tool was added for downloading sources of packages into the store. So you can download all the sources you need for building a package and then disconnect from the Internet and rebuild your system while beeing offline.

A tool I'm rather proud of is the REPL I've added. Its capabilities are limited, but I'm still a bit proud of it. So you can have a simple “shell” where you don't need to type nixos-scripts all the time. Normal bash commands are allowed as well, though functionality is limited here. It also lacks features like autocomplete and “one up for last command” or these things...

The help texts were polished.

What's up next

Well, there are some releases planned in the github issue tracker by now... Lets iterate:

0.4

This release will contain auto-complete for all the things. Nothing more, nothing less. It is something like an one-feature-release. I hope to get this done soon, but at the moment I really have no time to work on nixos-scripts, so ... feel free to send me pull requests to help me there.

0.5

The 0.5 release will introduce user-defined functions. So the user is allowed to put custom code in the configuration file and these functions will then be used for generating the tag names for example.

I'm really looking forward to this, as I do not want to restrict the user in matter of tag names my scripts generate in the users configuration repository. Backward compatibility will be provided, though.

Another feature I want to include is a (sort of) meta-command, which updates and cleans the system in litterally one step:

1. Update channels
2. Rebuild the system
3. Remove old generations
4. run the GC
5. Offer a reboot of the system

0.6

As the 0.4 and 0.5 releases are sort of one-feature-releases, this release will introduce all the small fixes and cleanups, new functionality for commands and so on. As this milestone gets rather big on github, I may split it into 0.6 and 0.7, I don't know yet.

---

So that's it. I apologyze for writing this post now, not one month ago. Though I'm not committing to the repository at the moment, the project is not dead, really! Feel free to send pull requests and issues!

Stay tuned! tags: #linux #nix #nixos #software #tools

How do you do your Personal Information Management? Or, more specific: How do you organize your contacts over multiple devices, how do you organize your calendar, todo lists, notes, wiki, diary, browser bookmarks, shopping list, mails, news feeds,...

Do you use Google for all this? Maybe you do. Don't you want to uncouple from Google? Well, then... I have to tell you about the sad state of PIM for nerds.

If you want to organize your personal information without google and host everything on your own, you will soon meet tools like owncloud, emacs orgmode or similar tools. Sadly, all these things are not what I want. OwnCloud is getting more buggy with every release and it is already slow as hell. orgmode needs emacs, which is a huge tool itself and you have to learn a whole new ecosystem. If you are a vim user like me, you don't want to use emacs.

But I'm not talking about editors here. I'm talking about PIM tools. What I do right now: Owncloud with khard, khal, vdirsyncer for contacts and calendar organization. As said, OwnCloud is buggy and sometimes calendar entries cannot be synced to all my devices. On Android, I use Apps to sync my contacts and calendar as well, and they fail as well, sometimes.

I use taskwarrior, which has a sync server available. Sadly, it doesn't work yet on NixOS, but well, that's my issue and I'm working on a solution. Nevertheless, the Android client (Mirakel) is badly supported and does not work that good as well.

For news, I use ttrss, which works fine and the appropriate Android App works good, too, so no issue here. For a Wiki, I use Gollum, which works but is a bit annoying to use because it is not that customizable. I do not use note-taking tools at all, because they simply suck. There's no good note-taking tool available for commandline use which integrates with the other tools. Mails work fine with mutt, of course, but they cannot be integrated in the wiki, todolist tools or the other tools I just mentioned. I do not use browser bookmarks at all, because there is no CLI tool available for them. Same goes for shopping lists.

What I want

What I want is simple: One tool, which integrates

• Personal wiki
• Personal todolist
• Personal notes
• Personal mail indexing
• Personal Calendars
• Personal Contact management
• Personal News Feeds (RSS/Atom mostly)
• Personal Bookmarks
• Personal Shopping list
• Personal Diary

in the following ways:

• I can use whatever
  • text editor
  • mail reader, sender, receiver
  • rss reader I want to use
• I can synchronize everything to all devices, including Android smartphones or my Toaster
• Everything is done with open standards. Means
  • vcard for contacts
  • ical for calendar
  • markdown for
  • wiki
  • notes
  • diary
  • shopping list
  • maybe YAML for todolist
  • mbox or Maildir for mails
  • normal Atom/RSS for news stuff
  • for bookmarks, YAML or JSON would be appropriate, I guess.
• I can access all my data in the system with a text editor, if I have to
• a clean and polished (+fast) Android Application to access and modify this data.
• I can move/link data from one system to another. For example:
  • I can link an Email from my notes
  • I can link a entry from my RSS, notes, calendars to (for example) my Wiki
  • I can send a shopping list from my mail client to a contact and attach a calendar entry which links to the shopping list
  • ... and so on
• All the things are encrypted (optionally)

As everything should be plain text, git would be fine for synchronization. The sync should be decentralized at least, so I don't have to host a server at home and cannot sync if I'm on the go. A web-hosted entity should be optional and so should be a web interface. Having a web-UI like owncloud has is nice, but not that critical for me. A full encryption of the content would be nice as well, but would be kinda hard for the Android devices, at least if the device gets lost. Anyways, my drives are encrypted and that should be enough for the first step.

It is, for me, really important that these tools interact well with eachother. The feature that I can send a mail to a contact and attach for example a shopping list, which itself has a calendar entry (which gets attached as well, if I want to), is a real point for me. Same goes for attaching a RSS entry to a wiki article or todo item.

Another requirement would be that the tool is fast and stable, of course. Open Source (and at best also free software) would be a crucial point to me as well. GPLv2 would be the thing.

Do it yourself, then!

Well, developing such a tool would be a monstrous huge amount of work. I'd love to have time for all this, especially as student. But I think I have not. I have a lot of opinions how such a tool should work and also a lot of ideas how to solve a certain problem which may arise, though I absolutely have no time to do this.

I, personally, would develop such a tool in Rust. Simply because it gives you so much power to your hands while remaining a really fast language in manner of execution speed (speaking of zero-cost abstractions here). Though, there would be the need for a lot of external libraries, for example for git, vcard, ical, yaml, json, markdown, configuration parsing, etc etc. While some of these things might be available already, others are clearly not.

Sadly, such a tool is not available. Maybe I can find time until I'm 35 years old to develop such a thing. Maybe someone else has done so until then. Maybe I just inspired you to develop it? Would be neat!

tags: #life #linux #mail #media #open source #programming #software #rust #tools #vim #wiki

It happened that I ordered a new mobile phone for myself. And because I don't want to have a google account, pre-installed facebook Apps and the like, it is a OnePlus One.

The order

Well, to order a oneplusone you can go to amazon and order it for like 433 Euro (64 GB version). Or you go to the oneplus store and order it for 299 Euro, which is what I did. I also ordered a screen protector and a case for it, to protect it even more.

But well, if you want to order from the manufacturer, you have to register on their page, which pissed me off a bit. The second problem was that you can only pay via Paypal and because you order from non-germany, you have to setup your Paypal account with a credit card. I do not have a Paypal account (because it really sucks) – so I asked someone else to pay the order for me and transfered the money to the persons bank account.

Unboxing

The One arrived seven days after I ordered it. It was absolutely nicely boxed, though some boxing was rather ridiculous: I understand that the power adapter has to be boxed separately, because of adapter variants. I do not understand why it has to be boxed two times – one time in a box, another time in a plastic-foil.

Screen protector

I also ordered a screen protector. It was shiped together with the One, nice! I applied it accordingly to this tutorial and I managed to get only one really tiny bubble under the protector foil. Well done!

Update!

Of course, when starting the One for the first time, it asks you to insert your google account data, etc. etc. I do not have a google account, so I was really pleasant surprised when I was offered a “skip” button!

As I do not have a micro/nano-SIM card yet, I also skipped the SIM setup.

Then, after some localization and skipping, I was offered to update the phone from CM 11 to CM 12. I did this, of course. It was really fast, although it said it would take up to 20 minutes. While updating it told me that 128 Apps are optimized. I always thought CM comes without Apps preinstalled? Well... We will see.

Initial setup

After applying the update I was asked for several things again, including google account data. Of course I switched off what I could switch off.

I also disabled everything the google apps want to do. None of the google apps should now be able to access my texts or other data. I hope.

The initial setup was fun. I really enjoyed using the device. It is a bit heavier than my old device, but it is also a few inches bigger, so that's completely okay.

I really hope I can get my SIM card as soon as possible, so I can start using the device properly.

What really bothered me in the first place: I have a 64 GB device. I can use about 55 GB of this – copying music will be painful! But well... I solved that “issue”. I found out, that one can install git-annex on Android. So I did that and just imported my complete music library. It took a rather long time to create the 44771 files and 3913 folders on the device. But having git-annex available on my Android device is a great plus point. So I don't have to care about syncing the files and so on, I just can use git-annex and it does everything for me. I just have to be careful with the available memory, as 55 GB can not handle my 500 GB music library, of course.

And, just you know, I do not use the web interface. I use the terminal emulator, of course!

But then, the disillusion: The music player didn't work with the symlinks git-annex generates. So I removed the git-annex repository from the device and copied music to it as I am used to.

Sync with owncloud

Well, syncing with owncloud was a topic. I thought it would be easy, but it wasn't.

There is this DavDroid app on both the market and F-Droid, which can by used to sync between caldav/carddav servers and the device. I entered my owncloud data and synced, but it just won't work.

So I filed a bug in the forum of the developers, but they couldn't help me with my problem (though they responded really quickly and were really nice at all).

So I tried other synchronization apps and finally landed with CalDAV Sync Adapter and carddav sync free which worked.

Now I have everything set up to use the oneplusone as my daily driver! Yay!

A gem I found

I found a nice app in the f-droid as well: whohasmystuff, which can be used to keep track of things you lend to someone. Really nice and basic app. It just works™.

tags: #android #cmmod #linux #media #music #open source #software #oneplusone

Read another NixOS success story here, about how I updated my kernel and removed the old graphics driver and using another one in one step.

And I didn't even care about the fact that my system maybe wasn't bootable afterwards.

Indeed, that's NixOS awesomeness. So, the problem is, I have an AMD graphics card in my workstation at home. I was on kernel 3.18 a rather long time. I mean, I was on 3.18 from 3.18.1 to 3.18.whatisitatthemoment – I guess I was there until 3.18.16 or something!

I used the ati_unfree driver in my system, so it wasn't appropriate for Christmas and holy St. GNUcius. I wanted to fix this. Kernel 4.3 will have the free AMD driver infrastructure, but it isn't out there right now, so I thought of updating to kernel 4.2 with the ati_unfree driver package. But it didn't work, ati_unfree couldn't be build on my system. I don't know why and I actually do not care.

So here's what I did:

I removed the ati_unfree driver from my services.xserver.videoDrivers setting and set it to [ "ati" "nouveau" ] – each of the drivers listed will be loaded and tested, told me the description of this option. I then did a nixos-rebuild build run, to verify it builds. It did. So I updated the kernel to boot.kernelPackages = pkgs.linuxPackages_4_2; and did a nixos-rebuild switch (actually I used my awesome nixos-scripts for this), but yeah...

And then I rebooted. I didn't even have to think about potential breakage, I just tried to boot the new system. If it would have been unbootable, I would just boot into an older generation and instantly be back on my kernel 4.1 and ati_unfree driver I used before the update.

This is what I call NixOS awesomeness.

tags: #nixos #linux #software

I started a project some time ago, where I develop a template for a wiki which is statically compiled into a html page. As the template is more mature now, I want to introduce you wiki.template and explain why I wrote it.

Once upon a time...

If you read this blog you know that I'm a member of the NixOS community. The NixOS community has, of course, a wiki. And the quality of this wiki is bad. No really, it is just one large page (the landing page) linking to sub-pages which are more or less maintained and contain only snippets of information. Sure – there's a lot of content in there, but (especially beginners) one has to search for it. You can't simply find it.

That's why I wanted to have a new wiki for the NixOS community. And because I like git, I wanted the content to be stored in a git repository.

So I came up with the idea to recreate the NixOS wiki and start it from scratch. Of course, the content of the original wiki has to be migrated to the new wiki then, but this has to be done carefully and by hand to ensure that things are ordered and easy to find afterwards.

The requirements

The requirements where rather simple, but nevertheless important to me. As already said, I wanted to have the content version controlled with git. The templates and markups for other data should be version controlled as well, if possible. This way, the content (or whole wiki) can be distributed with git, hosted on github or similar hosting platforms and so on.

I wanted to be able to customize the style of the wiki completely and I wanted to be able to write snippets of markup which can be reused, such as a warning-alert template where you can pass custom text and get a red alert box in your wiki page. Pretty normal stuff for a wiki.

Syntax highlighting, TOC-generating, all these things should be integrated or available through plugins (or there should be the possibility to write such plugins).

So I searched for wiki software with git backends...

The state of git-backend-driven wiki software

The state of wiki software with git backend is bad. No, it is even worse. There are actually two projects I had a look at and one which is written in Perl (and I didn't have a look on this one, because Perl).

gitit

First of all, there is gitit. Gitit is a wonderful piece of Haskell software. It works great and is fast. But it has its issues:

1. No Templates. Period.
2. Content is checked in, but neither templates nor style information
3. Haskell. So writing plugins – nah, not really.
4. Just few plugins available

So it was pretty clear that gitit is not an option for me.

gollum

Gollum was the other alternative. Developed by github, ruby thing, sounds well, right?

But. There's a big but.

1. No templates
2. No plugins
3. No custom styling or at least no documentation about it

It was clear to me: No option!

The solution

Well, the solution? Just write it yourself! And that's what I did. I started to work on a template for a wiki which is statically compiled with nanoc. Later I switched to jekyll.

Compiling the wiki to a static site has several advantages. First of all, hosting the site is cheap. A common web server can host thousands of pages without even noticing. Of course, you are also protected against hacking and all this stuff, as you do not have the problems dynamic websites have.

But these are common advantages of static compiled sites. An even bigger advantage is, that contributions to the wiki must pass a review-process of some kind. Of course, I will not grant push access to the repository to anyone and of course nobody gets access to merge pull requests, besides myself. I will protect myself against pushes to master as well, so each change to the wiki has to be reviewed. And that's what matters when it comes to quality: Changes must be reviewed.

Besides this big advantage, I do not have to care about updates (of the compilersoftware). I can do them locally and roll back if they fail. I do not have to keep track of spam bots, security updates, user account data, etc. etc. etc.

So here's the story how I wrote the template:

wiki.template

I started the project with nanoc, the static site compiler I love. The project is at version 4 these days and the compiler is really really good. It is flexible, scales well, fast and a joy to work with.

I just failed integrating foundation, the CSS framework I wanted to use. I played around with Jekyll a bit, but wasn't able to get Haml working. But at some point, foundation seemd to be more important than Haml, so I switched to Jekyll.

I also thought of the option to build the site with Jekyll directly from the github repository and build a github page with it, just because this way I can save money for hosting. I still think of that option, but as I use Jekyll with plugins I cannot build it on github directly. So I searched for tutorials on how to build it with travis and deploy my github page from travis. This is documented and a known as working.

Current state of wiki.template

To get my stuff working, I had to use some plugins. And these plugins basically work for me, but the code was either a mess or lacked features I wanted to have. So what did I do? Right, I forked them and send pull requests to the maintainers.

At this very point in time, I have three pending pull requests to these plugins, two of them just normal “cleanup codebase” PRs, one feature. I also opened issues for other features I do not necessarily need but would like to see implemented. I would implement them myself, but well... not enough time.

So what is the current state? Well, wiki.template is basically usable. I want to integrate some more features and it completely lacks of documentation on how to use it.

But these things will be done soon and I hope I can then create a fork of it to start my NixOS Wiki.

The NixOS Wiki

I already announced the NixOS Wiki fork (semi) officially on the NixOS mailinglist. Of course, as always in such communities, a discussion started on whether to do such a thing or not, which software to use and whatever. I don't care about this, I will simply do this and we will see whether it succeeds or not. Discussion all over the place helps nobody.

tags: #git #linux #nix #nixos #open source #programming #software #wiki

I just released the version 0.2 of the nixos-scripts. Read here what is included in this release.

44 patches are included in this release, merges not counted. There were some basic changes and a handful of features were added.

First, the switch command includes the hostname of your machine by default now, whereas the flag is now changed from adding your hostname to preventing the hostname in your tag.

The tags which are generated by switch are no longer annotated.

The switch command also has now an option to do all the things, but not nixos-rebuild at all.

The switch command can also tag the local nixpkgs clone now if the switch succeeded. The subcommand switch is default for the switch command now, you don't have to do nix-script switch -c switch, you can do nix-script switch.

The command for updating a package definition has now a flag for not checking out a new branch before updating the package. This can be used to mass-update packages on one branch. Also a flag for not checking out the base branch after a successful update of a package.

The user gets less output now, only output which can be relevant to the user is printed if the -v flag is passed to the nix-script command. The -d (debugging) flag prints all the information which can be used to debug the scripts now. But normal users don't need this flag.

All the scripts have support for the RC file now. You can put configuration in ~/.nix-script.rc now, so you don't have to pass things all the time. For examples, see the nixos-scripts repository at github.

Channel tools were integrated as well. The channel tools can be used to diff between channel generations, list the channel generations, checkout a specific channel generation and so on. More utilities will be included as time goes on, of course.

What is in the pipeline

Of course, the next release is already planned. v0.3 will land as soon as there are enough new features. In the pipeline is already:

• A tool to update the nixos channel and generate tags for it in the configuration directory
• A repo-reset command, which can be used to generate a branch in your nixpkgs which is based on the commit which your current nixos generation is build from
• Container helpers. Everything you need to manage nixos-containers
• diff-generations will be able to list the diff in your configuration
• A tool for test-building a package based on a special branch

More things will be done behind the scenes: Verification that everything worked well, checks before commands are executed, on so on.

v0.4 will be a one-feature-release which will only include completion support. The PR on github for this feature exists already, but it will be developed until v0.3 is ready and if everything works, it will be integrated with a single merge commit.

So that's it for today. tags: #linux #nix #nixos #software #tools

NixOS has a new Logo. So I have a new wallpaper now.

Awefully enough, my last wallpaper had this stupid error in the slogan. I just created a new wallpaper I want to share now, feel free to use and/or modify it (both the .png and the .xcf files) under the terms of WTFPL.

I think I got the slogan right this time.

GIMP project file. tags: #linux #nix #nixos