summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--content/posts/2019/2019-02-03-how-to-sign-pgp-keys.md141
-rw-r--r--content/posts/2019/2019-04-11-perl6-nightly-docker-images.md124
-rw-r--r--content/posts/2019/2019-07-22-the-powerful-tooling-of-gentoo.md177
-rw-r--r--content/posts/2019/2019-08-10-the-soc-controversy.md99
-rw-r--r--content/posts/2019/2019-10-17-getting-things-done-with-app-gtd.md166
-rw-r--r--content/posts/2019/_index.md3
6 files changed, 710 insertions, 0 deletions
diff --git a/content/posts/2019/2019-02-03-how-to-sign-pgp-keys.md b/content/posts/2019/2019-02-03-how-to-sign-pgp-keys.md
new file mode 100644
index 0000000..d5f401a
--- /dev/null
+++ b/content/posts/2019/2019-02-03-how-to-sign-pgp-keys.md
@@ -0,0 +1,141 @@
+---
+title: How to sign PGP keys
+date: 2019-02-03
+tags:
+- PGP
+- Tutorial
+---
+
+Having attended [FOSDEM](https://fosdem.org/2019/) last weekend, I have been
+asked to help some people out with signing PGP keys. As it is an international
+gathering of users and developers of all levels of expertise, it's a great event
+to get your key out in to the wild. While helping people out, I figured it might
+be even easier next time around to just refer to a small tutorial on my blog
+instead.
+
+## Creating a PGP key
+
+The first step to sign keys, is to have a PGP key. If you already have one,
+you're good to go to the next part of this tutorial. If you don't, you can check
+out the `gpg` manual on how to create a key, or read about key creation in my
+[article on using PGP with a Yubikey][yubikey-pgp-article]. While I would
+strongly suggest reading at least some material, `gpg` does quite a good job of
+guiding you through the process without prior knowledge, so you can just get
+started with `gpg --generate-key` as well.
+
+[yubikey-pgp-article]: {{ "/post/2018/09/04/setting-up-pgp-with-a-yubikey/#creating-pgp-keys" | prepend: site.baseurl | prepend: site.url }}
+
+## Create key slips
+
+A *key slip* is a small piece of paper containing some basic information about
+the PGP key. They're exchanged when people meet, so they don't have to
+immediately sign the key, but can do it safely at home. When you're signing in a
+group, this may be faster to work with. Another benefit is that some people
+don't have their private keys with them. They can then just collect the key slips
+from the people who's key they want to sign, and sign it whenever they are in
+possession of their private key again.
+
+A key slip doesn't have to contain much. A key ID, fingerprint, email address and
+a name is plenty. For reference, my key slips look as follows:
+
+```txt
+Patrick Spek <p.spek@tyil.nl> rsa4096/0x7A6AC285E2D98827
+ 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827
+```
+
+## Verifying the owner
+
+Before you sign anyone's public key, you should verify that the person is
+actually who they say they are. You can easily do this by asking for government
+issued identification, such as an ID card, driver's license or passport. What
+constitutes good proof is up to you, but in general people expect at least one
+form of government issued identification.
+
+If the person can't verify who they are, you should *not* sign their key!
+
+## Retrieving their key
+
+Once you have verified the person is who they say they are, and you have
+received their key slip containing their key ID, you can look up their key
+online. You can let `gpg` do all the work for you in searching and downloading
+the key, using the `--search` switch. For instance, to retrieve my key, do the
+following:
+
+```txt
+gpg --search-keys 0x7A6AC285E2D98827
+```
+
+If a result has been found, you are prompted to enter the numbers of the keys
+you want to download. Make sure you download the right key, in case multiple
+have been found!
+
+After retrieving the key, you can see it in the list of all the keys `gpg` knows
+about using `gpg --list-keys`.
+
+## Signing their key
+
+To actually sign their key, and show that you trust that the key belongs to the
+person's name attached to it, you can use `gpg --sign-key`:
+
+```txt
+gpg --sign-key 0x7A6AC285E2D98827
+```
+
+You will be prompted whether you are sure you want to sign. You should answer
+this with a single `y` to continue.
+
+After signing it, you'll have signed a PGP key! You can verify this by looking
+at the signatures on a given key with `--list-sigs 0x7A6AC285E2D98827`. This should
+contain your name and key ID.
+
+## Exchanging the signed key
+
+While you could publish the updated public key with your signature on it, you
+should **not** do this! You should encrypt the updated public key and send it to
+the person that owns the private key, and they should upload it themselves. One
+reason for this is that it allows you to safely verify that they do in fact
+actually own the private key as well, without ever asking them explicitly to
+show you their private key.
+
+To export the public key, use `--export`:
+
+```txt
+gpg --armor --export 0x7A6AC285E2D98827 > pubkey-tyil.asc
+```
+
+The `--armor` option is used to export the key as base64, instead of binary
+data.
+
+You can attach this file to an email, and let your email client encrypt the
+entire email and all attachments for they key ID. How you can do this depends on
+your email client, so you should research how to do this properly in the
+documentation for it.
+
+However, it's also possible to encrypt the public key file before adding it as
+an attachment, in case you don't know how to let your email client do it (or if
+you don't trust your email client to do it right).
+
+You can use the `--encrypt` option for this, and add a `--recipient` to encrypt
+it for a specific key.
+
+```txt
+gpg --encrypt --recipient 0x7A6AC285E2D98827 < pubkey-tyil.asc > pubkey-tyil.pgp
+```
+
+Now you can use this encrypted key file and share it with the owner of the key.
+If the person you send it to really is the owner of the key, they can use the
+private key to decrypt the file, import it with `gpg --import` and then publish
+it with `gpg --send-keys`
+
+## Winding down
+
+Once all this is done, other people should have sent you your signed pubkey as
+well, and you should have published your updated key with the new signatures.
+Now you can start using PGP signatures and encryption for your communication
+with the world. People who have not signed your key can see that there's other
+people that do trust your key, and they can use that information to deduce that
+whatever's signed with your key really came from you, and that anything they
+encrypt with your public key can only be read by you.
+
+With this [trust](https://en.wikipedia.org/wiki/Web_of_trust), you can make
+communication and data exchange in general more secure.
diff --git a/content/posts/2019/2019-04-11-perl6-nightly-docker-images.md b/content/posts/2019/2019-04-11-perl6-nightly-docker-images.md
new file mode 100644
index 0000000..61b54f5
--- /dev/null
+++ b/content/posts/2019/2019-04-11-perl6-nightly-docker-images.md
@@ -0,0 +1,124 @@
+---
+title: Perl 6 nightly Docker images
+date: 2019-04-11
+tags:
+- Perl6
+- Docker
+- Raku
+---
+
+Due to the slow release of Rakudo Star (which actually did release a new
+version last month), I had set out to make Docker images for personal use based
+on the regular Perl 6 releases. But, as I discovered some [memory related
+issues](https://github.com/rakudo/rakudo/issues/1501), and [another branch with
+some possible fixes](https://github.com/MoarVM/MoarVM/pull/1072), I changed my
+mind to make them nightlies based on the `master` branches of all related
+projects instead. This way I could get fixes faster, and help testing when
+needed.
+
+These nightlies are now up and running, available on [Docker
+Hub](https://hub.docker.com/r/tyil/perl6) for anyone to use! You can also find
+[the Dockerfiles I'm using on git.tyil.nl](https://git.tyil.nl/docker/perl6),
+in case you're interested or have suggestions to further improve the process.
+
+The timing of the (public) release of these images could have been better,
+though. About two weeks ago, other nightlies were released as well, by Tony
+O'Dell, as has been noted in the [Perl 6 Weekly
+post](https://p6weekly.wordpress.com/2019/03/25/2019-12-cool-truck/). While I
+greatly appreciate his efforts, I was not going to just abandon all the work
+I've put into my images. Instead I've tried to make smaller images, and provide
+different bases than him. Maybe we can eventually learn from each other's images
+and improve Docker support for the entire community together.
+
+The easiest thing to work on was providing different bases. For now, this means
+I have images with the following four base images:
+
+- Alpine
+- Debian
+- Ubuntu
+- Voidlinux
+
+This way, people can have more options with regards to using the distribution
+tooling that they're more comfortable with. One could also opt to use a more
+familiar or better supported base image for development and testing out their
+module, and use a smaller image for production releases.
+
+As to the size of the images, Tony's `tonyodell/rakudo-nightly:latest` is about
+1.42GB at the time of writing this post. My images range from 43.6MB
+(`alpine-latest`) to 165MB (`voidlinux-latest`). Though this is not a
+completely fair comparison, as my images have stripped out a lot of the tooling
+used (and often required) to build some Perl 6 modules, making them unusable in
+their default shape for many projects.
+
+To remedy this particular issue, I've also created *-dev* images. These images
+come with a number of additional packages installed to allow `zef` to do its
+work to get dependencies installed without requiring end-users to search for
+those packages. This should reduce complexity when using the images for
+end-users. If we take the dev images into account when comparing sizes, my
+images range from 256MB (`alpine-dev-latest`) to 1.27GB
+(`voidlinux-dev-latest`). That's much closer to the `rakudo-nightly` image.
+
+If you're interested in trying these images out, you may be interested in the
+way I'm using these images myself as reference. Currently, my [CPAN upload
+notifier bot](https://git.tyil.nl/perl6/app-cpan-uploadannouncer-irc) is using
+these nightly images in its
+[`Dockerfile`](https://git.tyil.nl/perl6/app-cpan-uploadannouncer-irc/src/branch/master/Dockerfile).
+
+```Dockerfile
+FROM tyil/perl6:debian-dev-latest as install
+
+RUN apt update && apt install -y libssl-dev uuid-dev
+
+COPY META6.json META6.json
+
+RUN zef install --deps-only --/test .
+```
+
+As you can see from the `Dockerfile`, I start out by using a `-dev` image, and
+name that stage `install`. I'm still contemplating to include `libssl-dev` into
+the `-dev` images, as it seems to pop up a lot, but for now, it's not part of
+the `-dev` images, so I install it manually. Same goes for `uuid-dev`. Then I
+copy in the `META6.json`, and instruct `zef` to install all the dependencies
+required.
+
+```Dockerfile
+FROM tyil/perl6:debian-latest
+
+ENV PERL6LIB=lib
+
+WORKDIR /app
+
+RUN mkdir -p /usr/share/man/man1
+RUN mkdir -p /usr/share/man/man7
+RUN apt update && apt install -y libssl-dev postgresql-client
+
+COPY bin bin
+COPY lib lib
+COPY --from=install /usr/local /usr/local
+
+RUN mkdir -p /var/docker/meta
+RUN date "+%FT%TZ" > /var/docker/meta/build-date
+
+CMD [ "perl6", "bin/bot" ]
+```
+
+Then I start a new stage. I set the `$PERL6LIB` environment variable so I don't
+have to use `-Ilib` at the end, and set a `WORKDIR` to have a clean directory
+to work in. Next, I set up the *runtime dependencies* of the application.
+
+I then continue to copy in the `bin` and `lib` directories, containing the
+application itself, and copy over `/usr/local` from the `install` stage.
+`/usr/local` is where Perl 6 is installed, and `zef` installs all its
+dependencies into. This way, the `-dev` image can be used for building all the
+dependencies as needed, and only the finished dependencies end up in the final
+image that's going to run in production.
+
+Lastly, I set the build date and time of the image in a file, so the
+application can refer to it later on. It is displayed when the IRC bot replies
+to a `.bots` command, so I can verify that the running bot is the one I just
+built. And finally, the `CMD` instruction runs the application.
+
+I hope this displays how the images can be used for your applications, and the
+reasoning as to why I made them the way they are. If you have any suggestions
+or issues, feel free to contact me in whatever way suits you best. You can find
+some contact details on the homepage of my blog.
diff --git a/content/posts/2019/2019-07-22-the-powerful-tooling-of-gentoo.md b/content/posts/2019/2019-07-22-the-powerful-tooling-of-gentoo.md
new file mode 100644
index 0000000..9d8cff2
--- /dev/null
+++ b/content/posts/2019/2019-07-22-the-powerful-tooling-of-gentoo.md
@@ -0,0 +1,177 @@
+---
+title: "The Power(ful Tooling) of Gentoo"
+date: 2019-07-22
+tags:
+- Gentoo
+---
+
+People often ask me for my reasons to use [Gentoo](https://gentoo.org/). Many
+perceive it as a "hard" distro that takes a lot of time. While it does come
+with a learning curve, I don't perceive it as particularly "hard", as the
+documentation is very thorough and the community is very helpful. And the
+tooling you get to maintain your system is far beyond what I've come across
+with any other GNU+Linux distribution.
+
+This blog post will highlight some of the key features I love about Gentoo.
+There are certainly many more perks that I don't (yet) use, so please feel free
+to inform me of other cool things that I missed.
+
+## Configurability
+
+One of the main reasons for preferring Gentoo is due to the ease of configuring
+it to work just the way you want.
+
+A great example for this would be with `init` choices. Many distributions only
+support [systemd](https://en.wikipedia.org/wiki/Systemd) these days. As I'm not
+a big fan of this particular system, I want to change this. But even asking a
+question about this will get you a lot of hatred in most distribution
+communities. In Gentoo, however, changing init is supported and well
+documented, allowing you to pick from a range of possible inits.
+
+### `USE` flags
+
+One of the core concepts of Gentoo are the [`USE`
+flags](https://wiki.gentoo.org/wiki/USE_flag). These allow you to easily alter
+the software you're compiling to use the features you want. They can also be
+used to indicate which library you would like to use to make use of a certain
+feature, if there are multiple implementations available.
+
+### `make.conf`
+
+Like most distros that work with self-compiled packages, Gentoo has a
+`make.conf` file available to specify some default arguments in to use while
+compiling. Unlike most other distros, Gentoo's `make.conf` also allows for some
+configuration of the `emerge` utility.
+
+For instance, I use my `make.conf` to ensure `emerge` always asks for
+confirmation before performing actions. I also ensure that the build system,
+`portage`, is heavily sandboxed when building packages.
+
+Additionally, like all configuration files in `/etc/portage`, it can be made
+into a directory. In this case, all files in the directory will be loaded in
+alphabetical order. This allows for easier management using tools like
+[Ansible](https://www.ansible.com/).
+
+### Ease of patching
+
+Another feature I find very useful of Gentoo, is the ease of applying my own
+patches to software. If you have a custom patch for a package that you want to
+be applied, all you have to do is drop it in a directory in
+`/etc/portage/patches`. The directory is should be in is the same as the
+package's name the patch is intended for. For instance, I have the following
+patch in `/etc/portage/patches/www-client/firefox`:
+
+```diff
+diff --git a/browser/extensions/moz.build b/browser/extensions/moz.build
+index 6357998..c5272a2 100644
+--- a/browser/extensions/moz.build
++++ b/browser/extensions/moz.build
+@@ -5,15 +5,10 @@
+ # file, You can obtain one at http://mozilla.org/MPL/2.0/.
+
+ DIRS += [
+- 'activity-stream',
+ 'aushelper',
+ 'followonsearch',
+ 'formautofill',
+ 'jaws-esr',
+- 'onboarding',
+- 'pdfjs',
+- 'pocket',
+- 'screenshots',
+ 'webcompat',
+ ]
+```
+
+Whenever a new Firefox is released and built, this patch will be applied on it
+to remove some of the features I dislike.
+
+## Ebuilds and overlays
+
+In Gentoo vocabulary, `ebuild` files are the files that describe how a package
+is to be built, which `USE` flags it supports and everything else relating to a
+package. An overlay is a repository of ebuild files. Everyone can make their
+own, and easily add 5 lines in their `repos.conf` to use it. In most cases,
+they're just git repositories.
+
+The documentation on everything around ebuilds is superb, in my experience,
+especially compared to other distros. It is incredibly easy to get started
+with, since it's made to be usable with very little effort. While being simple,
+it's also very flexible: All default behaviours can be overwritten if needed to
+get a package to build.
+
+## Binary packages
+
+Yes, you read that right. [Binary
+packages](https://wiki.gentoo.org/wiki/Binary_package_guide)! Contrary to
+popular belief, Gentoo *does* support this. You can instruct `emerge` to build
+binary packages of all the packages it compiles, which can then be re-used on
+other systems. It does need to be compiled in such a way that the other machine
+can use it, of course. You can't simply exchange the packages of an x64 machine
+with and ARM machine, for instance. You can set up a [cross build
+environment](https://wiki.gentoo.org/wiki/Cross_build_environment) to get that
+particular usecase going, though.
+
+If you want to easily share the binary packages you build with one machine, you
+can set up a
+[binhost](https://wiki.gentoo.org/wiki/Binary_package_guide#Setting_up_a_binary_package_host),
+and have `emerge` pull the binary packages on the other systems as needed using
+`--usepkg`. There actually is a [binhost provided by Gentoo
+itself](http://packages.gentooexperimental.org/), but it seems to only contain
+important packages used to restore systems into a working state.
+
+## Tooling
+
+Some of the core tooling available to any Gentoo user has already been talked
+about. But there's some additional tooling you can install to make your life
+even better.
+
+### `genkernel`
+
+One of the hardest tasks to newcomers to Gentoo is often to compile a kernel.
+Of course, Gentoo has an answer for this, `genkernel`. The defaults `genkernel`
+will give you are reasonably sane if you just want to have a kernel that works.
+Of course, you can still edit the kernelconfig before compilation starts. It
+will also build an `initramfs` when requested, that goes along with the kernel.
+When things have been made, the kernel and initramfs will be moved to `/boot`,
+and a copy of the working kernelconfig is saved to `/etc/kernels`. All you need
+to remember is to update your preferred bootloader's configuration to include
+your new kernel.
+
+### `eix`
+
+[`eix`](https://wiki.gentoo.org/wiki/Eix) is a utility most Gentoo users use to
+update the Portage repositories and search for available packages. The
+interface is considered more convenient, and it's a bit faster at getting your
+results.
+
+To get a quick overview of which packages are in need of updates, you can run
+`eix -uc` (*u*pdates, *c*ompact). To sync the Portage tree and all overlays,
+`eix-sync` is the way to go. This will ensure the cache used by `eix` also gets
+updated.
+
+In addition to having a cleaner interface and being faster, it also comes with
+additional tools for keeping your system sane. The most notable to me is
+`eix-test-obsolete`.
+
+This utility will report any installed packages that are no longer provided by
+any repository (orphaned packages). It will also report all configuration lines
+that affect such packages. This is really valuable in keeping your
+configuration maintainable.
+
+### `glsa-check`
+
+The `glsa-check` utility is part of the `app-portage/gentoolkit` package. When
+ran, it will produce a list of all packages which have known vulnerabilities.
+It will use the [GLSA database](https://security.gentoo.org/glsa) for the list
+of known vulnerabilities. This can be much easier than subscribing to a mailing
+list and having to check every mail to see if a vulnerability affects you.
+
+### `qlop`
+
+`qlop` is another utility that comes with `app-portage/gentoolkit`. This
+program parses the logs from `emerge` to give provide you with some
+information. I use this mostly to see compile times of certain packages using
+`qlop -Htvg <package-name>`. Using this, I can more easily deduce if I want my
+desktop (with a stronger CPU) to compile a certain package, or if it'll be
+faster to just compile it on my laptop.
diff --git a/content/posts/2019/2019-08-10-the-soc-controversy.md b/content/posts/2019/2019-08-10-the-soc-controversy.md
new file mode 100644
index 0000000..762492d
--- /dev/null
+++ b/content/posts/2019/2019-08-10-the-soc-controversy.md
@@ -0,0 +1,99 @@
+---
+title: The SoC Controversy
+date: 2019-08-10
+tags:
+- CodeOfConduct
+- Conference
+- Perl6
+- Raku
+---
+
+{{< admonition title="Disclaimer" >}}
+{% admonition_md Disclaimer %}
+Please keep in mind that the opinion shared in this blog post is mine and mine
+alone. I do not speak for any other members of the PerlCon organization team.
+Please do not address anyone but me for the positions held in this post.
+{{< / admonition >}}
+
+Those that know me are probably aware that I generally dislike to make
+political posts on my personal blog. I'd rather stick to technological
+arguments, as there's less problems to be found with regards to personal
+feelings and all that. However, as I'm growing older (and hopefully more
+mature), I find it harder to keep politics out of my life as I interact with
+online communities. This becomes especially true as I plan to assist with
+organizing [PerlCon
+2020](https://wiki.perlcon.eu/doku.php/proposals/2020/amsterdam).
+
+PerlCon 2019 ended yesterday, and I had a lot of fun. I'd like to thank the
+organizer, Andrew Shitov, once more for doing an amazing job. Especially so, as
+he has been harassed for weeks, for trying to organize the conference. The
+reason behind the harassment was partly due to his decision to not have an SoC,
+or "Standards of Conduct", for PerlCon 2019.
+
+During his final announcements at the end of the conference, he noted that this
+is still happening, even in person at the conference itself. This toxic
+behavior towards him has made him decide to no longer involve himself in
+organizing a conference for the Perl community. I personally think this is a
+loss for everyone involved in the community, and one that was completely
+avoidable by having humane discussion instead of going for Twitter harassment.
+
+For what it's worth, I think Twitter is also the worst possible place on the
+Internet for any reasonable discussion, as it puts a very low limit on the
+amount of characters you are allowed to spend on a single post. This makes it
+downright impossible for any discussion, and seems to always lead to petty
+name-calling. This is one of the reasons why [I'm instead using a Pleroma
+instance](https://soc.fglt.nl/main/public) for my social media presence on the
+Internet. If anyone is on the Internet with the intent of having interesting
+discussion, I'd highly recommend to use some entrance into the Fediverse. The
+instance I'm using is open for sign-ups!
+
+But I digress. The SoC controversy is what made me want to write this blog
+post. I wonder why this even is a controversy. Why do people think it is
+impossible to co-exist without some document describing explicitly what is and
+is not allowed? I would hope that we're all adults, and can respect one another
+as such.
+
+I wonder, was there any certain event at PerlCon 2019 that would've been
+avoided if there *was* a SoC provided? I certainly did not, at any point, feel
+that people were being harmful to one another, but maybe I'm just blind to it.
+If anyone has concrete examples of events that happened during PerlCon 2019
+that a SoC could've prevented, I would be genuinely interested in hearing about
+them. If I am to assist in organizing PerlCon 2020, and I want to be able to
+present a good argument on the SoC discussion, I'll need concrete examples of
+real problems that have occurred.
+
+Of course, I also consider the opposite of this discussion. Can the SoC be used
+to *cause* harm, in stead of deter it? For this, I actually have clear
+evidence, and the answer is a resounding **yes**. The harassment brought upon
+Andrew was originally caused by an event that transpired at The Perl Conference
+in Pittsburgh (2019). A video was removed, and a speaker harassed, for
+dead-naming someone. Until that event, I wasn't even aware of the term, but
+apparently it's grounds for removal of your presentation from the conference
+archives.
+
+A similar event happened with The Perl Conference in Glasgow (2018), where a
+talk was also removed from the archives for a supposedly offensive joke that
+was made. This also sparked a heavy discussion on IRC back then, with people
+from all sides pitching in with their opinion.
+
+From my perspective, the people shouting the loudest in these discussions
+aren't interested in making the world a better place where we can live in
+harmony, but to punish the offender for their behavior. I don't think we
+should strive towards punishment, but towards understanding, if anything. Just
+being angry, shouting at people (either in real life, or over the Internet)
+isn't going to solve any underlying problem. It is more likely to cause more
+issues in the long run, where people will just be more divided, and will want
+to get continuous revenge upon the other side.
+
+Additionally, I think that the existence of an SoC or likewise document is a
+sign towards outsiders that your community can't behave itself maturely. They
+need special rules laid out to them, after all. Like most rules, they are
+codified because issues have arisen in the past, and keep on arising. I don't
+think the Perl community is too immature to behave itself. I trust in the good
+faith of people, and to me it feels like a SoC does the exact opposite.
+
+I hope this blog post does it's job to invite you kindly to share your opinions
+with me, either on [IRC, email or on the Fediverse](/#contact). I'd
+gladly start a discussion on the positive and negative effects the SoC has, and the problems
+it solves and creates. I think a civil discussion is in order here, to best
+prepare us for PerlCon 2020.
diff --git a/content/posts/2019/2019-10-17-getting-things-done-with-app-gtd.md b/content/posts/2019/2019-10-17-getting-things-done-with-app-gtd.md
new file mode 100644
index 0000000..0a24e57
--- /dev/null
+++ b/content/posts/2019/2019-10-17-getting-things-done-with-app-gtd.md
@@ -0,0 +1,166 @@
+---
+title: "Getting Things Done with App::GTD"
+date: 2019-10-07
+tags:
+- GettingThingsDone
+- Perl6
+- Raku
+---
+
+A couple months ago, I was given a workshop at work about "getting things
+done". There I was told that there exists a concept called "[Getting Things
+Done](https://en.wikipedia.org/wiki/Getting_Things_Done)", or "GTD" for short,
+to help you, well, get things done. A number of web-based tools were introduced
+to assist us with following the rules laid out in the concept.
+
+## The problem
+
+The tools that were introduced did their job, and looked reasonably shiny.
+However, most required a constant Internet connection. I like my tools to be
+available offline, and optionally synced together. There was one local
+application and a couple cloud-synced applications that I found, so this
+problem could've been resolved. However, my other problem with all these
+programs was that they're all proprietary. Those who've read more of my blog
+may have realized by now that I strongly prefer free software whenever
+possible.
+
+Being unable to find any free software programs to fulfill my needs, I took a
+look at the features I would need, and tried to adapt other programs to fit
+those particular needs. I quickly learned that it's inconvenient at best to try
+and mold generic task keeping programs into the specifics of GTD. But, it did
+give me a reasonable idea of what features I needed for basic usage. It
+occurred to me that it shouldn't be terribly hard to just write something of my
+own. So I did.
+
+## The solution, `App::GTD`
+
+Introducing [`App::GTD`](https://gitlab.com/tyil/raku-app-gtd), a brand new
+project written in the [Raku programming language](https://raku.org/). While
+still in its early phases, it seems to be usable on a day-to-day basis for me
+and another colleague. In its bare basics, it's just another to-do list, but
+the commands it gives you incorporate the concepts of GTD. There's an inbox
+that you fill up through the day, a list of next items to work on, and projects
+to structure larger tasks in.
+
+{{< admonition title="note" >}}
+The Raku programming language used to be called the Perl 6 programming
+language. They function the same, but the name was changed for various reasons
+I will not get into here.
+{{< / admonition >}}
+
+This program can be installed using `zef`, though I'm planning an `ebuild` for
+Gentoo (and derivatives) too. Once installed, you can use `gtd` from your
+shell. Doing so without arguments will show the usage information. The most
+important will be `gtd add`, `gtd next` and `gtd done`. Most of these commands
+require an `id` argument. The IDs required are displayed in front of the items
+when listing them with commands like `inbox` or `next`.
+
+## Daily life with `gtd`
+
+Once you have `gtd` installed, you don't *need* to do any configuration, as the
+defaults should work fine for most people. This means you can start using it
+immediately if you want to try it out!
+
+The most common invocation will be with the `add` sub-command. Whenever
+something pops up that needs doing, you add it to your inbox using it.
+
+```txt
+gtd add Buy eggs
+gtd add "update cpan-raku's help command"
+```
+
+These items go to your inbox, and don't need to be long, so long as *you*
+understand what you meant by it. You can see that you also don't need to use
+quotes around the item you want to add. All arguments after `add` will be
+joined together as a string again, but some shells may perform their magic on
+certain things. This is why I quoted the second call, but not the first.
+
+All these things that you write down like this need to be sorted out at some
+point. I do this every day in the morning, before I get to my regular tasks at
+work. To get started, I want to see an overview of your inbox, for which the
+`inbox` sub-command is intended. Running it will give you a list of all the
+items in your inbox, including their ID and the date they were added.
+
+```txt
+$ gtd inbox
+[1] Buy eggs (2019-10-17)
+[2] update cpan-raku's help command (2019-10-17)
+```
+
+Now I can go through the list, and decide which actions I should undertake
+specifically. These are called "next items", and the sub-command is named
+`next`. Called without arguments it will give you an overview of your next
+items, but when given an ID it will move an inbox item to your list of next
+items. You can optionally also specify a new name for the item, to be more
+clear about what needs doing.
+
+```txt
+$ gtd next
+You're all out of Next actions!
+
+$ gtd next 1
+"Buy eggs" has been added as a Next item.
+
+$ gtd next 2 "Add usage and repo info to cpan-raku, whenever it's messaged with 'help'"
+"Add usage and repo info to cpan-raku, whenever it's messaged with 'help'" has
+been added as a Next item.
+```
+
+You can now see that your inbox is empty when using `inbox`, and see a list of
+the next items you created with `next`.
+
+```txt
+$ gtd inbox
+Your inbox is empty!
+
+$ gtd next
+[1] Buy eggs (2019-10-17)
+[2] Add usage and repo info to cpan-raku, whenever it's messaged with 'help' (2019-10-17)
+```
+
+Now all that's left is to do all the things you've created next items for. When
+done, you can remove the entry from your next items using `done`. This command
+also works on items in your inbox, so small tasks that require no next item(s)
+can be marked as done immediately.
+
+```txt
+$ gtd done 1
+"Buy eggs" has been removed from your list.
+
+$ gtd done 2
+"Add usage and repo info to cpan-raku, whenever it's messaged with 'help'" has
+been removed from your list.
+
+$ gtd next
+You're all out of Next actions!
+```
+
+## Future plans
+
+The basics are here, but there are some things I'd very much like to add. First
+and foremost, I want to be have a context to add to items, and a single context
+the program operates in. This way, I can more clearly separate work and
+personal tasks, which now just share one global context.
+
+Additionally, I've read about a new YouTube tutorial about using `ncurses` in
+Raku, which I hope can guide me through making an `ncurses` application for
+this as well. Perhaps I can find time to make a `GTK` application out of it as
+well.
+
+I've already mentioned wanting to create a Gentoo `ebuild` for the application,
+but this will require packaging all the module dependencies as well. This comes
+with a number of hurdles that I'm trying to iron out before starting on this
+endeavor. If you are on Gentoo (or a derivative) and want to assist in any way,
+please contact me.
+
+Another thing I've taken into account when structuring the application is the
+possibility for other data back-end. `gtd` is currently storing it's
+information in `JSON` files in a filesystem directory, which comes with various
+drawbacks. It may be beneficial to also support databases such as SQLite or
+PostgreSQL. However, this is not a high priority for me right now, as it would
+slow down the speed at which I can make improvements to the general program.
+
+I hope that `App::GTD` can help others to get things done as well. The program
+is all but finished, but it should be usable for people besides me and my
+colleague by now. If you have any suggestions or questions about the program,
+do not hesitate to seek me out!
diff --git a/content/posts/2019/_index.md b/content/posts/2019/_index.md
new file mode 100644
index 0000000..b69640f
--- /dev/null
+++ b/content/posts/2019/_index.md
@@ -0,0 +1,3 @@
+---
+title: 2019
+---