An HTTP message comprises a request line (a request method, an URL and a protocol version) or status line (a protocol version and a response status code) followed by a list of headers and a message body separated with an empty line. The request/status line and the headers are plain text, while the message body can be any content (specified by Content-Type), including binary, optionally encoded. How the message body is encoded is described by two headers: Transfer-Encoding and Content-Encoding.

Complexity can have many different sources. Things do not materialise the way we imagined, experiments fail, new technologies or tools do not prove as useful as advertised. Our understanding of the problem improves overtime, sometimes the problem itself or the direction we want to go changes. Exposing projects to time results in layering of different, even conflicting, ideas. Having more than a single person working on a system only amplifies those effects.

Recently I have read JEP 426, Java enhancement proposal introducing virtual threads - essentially a way to map multiple Java threads to a few operating system threads. I thought it’s brilliant, especially the fact that the virtual threads could run unmodified code. Rust take a different approach to overcoming the scalability issues of operating system threads with asynchronous runtimes and async/await language support. One of the issues however is that the code has to be adapted for the asynchronous model.

I have started simple. ~/.emacs.d/init.el had just one line: (org-babel-load-file "~/.emacs.d/init.org") init.org was simple too: #+begin_src emacs-lisp (setq org-directory "~/org") #+end_src After restarting Emacs everything seems to have worked fine C-h v told me that the value of org-directory is indeed ~/org. So far so good. I have opened init.el and its content was: (setq org-directory "~/org") That’s right, the same as the code I had in the source block in init.

Most of the discussions of programming languages focuses on development of software. Productivity of getting something up and running on one hand and maintenance costs on the other. Usually proponents of dynamic typing and interpreted languages are focused more on the speed of writing new code. The fans of static typing and compiled languages emphasize maintenance, the ability to change existing software1. This is obviously an oversimplification but in general summarizes my observations of the discussion.

It’s easy to be sceptical of intuition. Making decisions unconsciously without understanding the reasons behind or being able to articulate the way we arrived at them. This seems irresponsible. On the other hand if intuition is something that’s characteristic of us as species, there’s a good chance it was acquired for a reason and has some value. If you are dismissive about the value of intuition, imagine just for a second why it might work.

I’ll be upfront: the only reason for this post is to resume this blog. It’s been almost two years since I have published the last article. And it’s not for the lack of things to write about. I had too many ideas over this time. Not for the lack of effort either: there are a few drafts that never made it live. I can ponder about reasons why this has happened but it doesn’t really matter.

Is it even possible, you might ask? Well, not really, we can’t predict the future. But we can detect the situation leading to OutOfMemoryError, lack of free heap memory, before it actually occurs. Technically there’re other causes of OutOfMemoryError described in detail here which are outside of the scope of the article and arguably less frequent and interesting. Before moving forward, why can’t we handle java.lang.OutOfMemoryError when it actually happens? The error is a Throwable, so we can catch it, right?

Even though in most cases having a single Git configuration is enough, sometimes more granular control is needed. Let’s say you have a common Git configuration you use on your personal server, a laptop and a desktop. You probably want to share that configuration across the machines as part of your dotfiles repository. Also you have a work laptop and you need some special Git configuration for work projects. Occasionally you commit to your personal repositories or some open source repositories from the work laptop and you don’t want to have the work configuration applied in those cases.

Part 3: Let’s Get a GUI This is the third and the final part of my Build Yourself Arch Linux series (part 1, part 2). In this part I’ll finally get to a graphical environment setup. GNOME Before settling down on GNOME I’ve tried (well installed and played around for 10 minutes) most of the desktop environments supported by Arch. I’ve been using GNOME 3 in the past but decided to look what else is out there.