Followup: systemd user instances

In this last post, I wrote about how to fix systemd user instances for older/broken systemd versions. Here, I'd like to explain how we managed to get the solution for, say, more than a single host where you can't do those changes by hand (at least not while keeping you sane and your customers happy).

In order to keep track here, we need to do the following:

What do you do when you need more systemd instances?

You wanna make it there? You need to go there!

Today, we had a very interesting problem. We needed to have systemd run additional instances of itself to manage custom daemons. This works like the following.

PostgreSQL: Index-Only Scans with Partial Indexes

Partial sun lurking out of the water.

Another posts of my PostgreSQL 9.6 series. This time, I am talking about commit 9/299.  The complete discussion can be found here.

PostgreSQL: Parallel Aggregate

With PostgreSQL 9.6 looming on the horizon, I went out to sift through some of PostgreSQL's commitfests to find some interesting bits and pieces. This post is the start of a series covering commits of the next generation of the venerable database management system.

Outflow made parallel.

What is a path?

Wisecracker.

pathlib is a provisional stdlib module. However, as the current threads (here, here, here and here) on python-ideas show, it is not as easy to work with as originally intended. Once you have a Path object, it's quite easy to use what Path offers which is a lot.

One big problem, though, is the interaction of Path objects with existing stdlib functions. Most of the later are string-consuming functions whereas the former are no strings at all. As far as I can see, this is one reason why pathlib lacks broader adoption and many agree. This situation leads to the following possible resolutions:

1. make Path objects compatible with strings (basically make them inherit from strings)
2. make existing stdlib functions accept Path objects (basically make them accept both and convert if needed)
3. do both but that seems superfluous

Solution 2 would also affect third-party libraries as noted here.

In order to decide appropriately, it becomes necessary to answer the following question:

p-strings

Currently, there is an interesting debate on python-ideas on the topic of "Would we like to add so-called p-strings to Python?". The p-string idea basically extends the f-string syntax which will be released in the upcoming Python 3.6.

The "p" in p-string stands for path and one of the alternative proposals is to add the following syntactic sugar to Python like this:

Python makes you a worse programmer

Thanks Luke for this interesting read: http://lukeplant.me.uk/blog/posts/why-learning-haskell-python-makes-you-a-worse-programmer/

It reminds me of English as it is substantially simpler than most other languages. What I've heard (from themselves) is that most native English speakers are not easily motivated to learn a second language. And that is although they know all the corresponding advantages like healthier brains, better first language, more interesting traveling, etc.

A good article about why to learn a second language: http://www.omniglot.com/language/articles/benefitsoflearningalanguage.htm