Recently, I’ve faced a problem with slow logs collection and their delivery to our logs aggregator — Graylog. So, I looked into fluentd documentation and digging up its sources to understand, how fluentd collects logs and how it delivers them.
It’s not an article in a regular sense; it’s more of a small tip…
Turns out that Node.js cannot receive signals and handle them appropriately (if it runs as PID 1). By signals, I mean kernel signals like SIGTERM, SIGINT, etc.
The following code wouldn’t work at all if you run Node.js as PID 1:
process.on('SIGTERM', function onSigterm() {
// do the cleaning job, but it wouldn't
process.exit(0);
});
As a result, you will get a zombie process that will be terminated forcefully via SIGKILL signal, meaning that your “clean up” code will not be called at all.
So what, you might say. I’ll describe a real case.
How often do you face the issue with configuring your development environment? How often do you configure your terminal? Did you install Command Line Tools? What about Homebrew, don’t you forget to install it? Maybe you forgot about some cool plugin for your shell and can’t find it?
This is the problem I am usually faced with clean MacOS install, so maybe you too.
Some error in the terminal, oh, I forgot to install X…
How did that work before? Oh, I had plugin Y, but I don’t remember its name…
Who enjoys remembering all the fishy commands? I don’t…
Burn out my own eyes with a default theme and colors? No, thanks…
Navigating through a plugin repository of your shell to find out all plugins you had again? Haha, nope…
In case you just want to check the script, here is the link – https://github.com/ghaiklor/iterm-fish-fisher-osx
Further content is the history, my motives, while creating the script.
Last time, we created a working boot sector, the BIOS can find with the help of magic numbers. You can read more about it here (if you didn’t, I highly recommend doing that now, as you may miss some important details).
The question here is “Why do we need a second stage boot loader?”. We can implement all of it in the boot sector, using Assembly, so… why?
The problem is… size limits. You can’t store over 512 bytes of code in the boot sector, so if you want to make a super-duper boot loader (like GRUB or similar) you need to store all of it somewhere else, but not in the boot sector itself.
And that is one of reasons, we need to have a second stage boot loader.
Read Full ArticleHave you ever wondered what happens when you press the Power button on your PC? What happens right from when your motherboard gets electrical supply? How does your device become bootable?
I had. And I will share this knowledge with you alongside the code of boot loader you may run via a QEMU emulator.
Recently, I faced an issue with requiring native bindings in JavaScript code, so I researched it. If you ever used commands, like require(‘my_module.node’) but don’t know how they work from JavaScript perspective — this article is for you.
What is .node files and why do we need them?
Sometimes, we are using npm packages that have native bindings for their purposes. Sometimes, we are building our own C++ code to extend the Node.js functionality for our own purposes. In both cases, we need to build an external native code to an object that can be usable by Node.js.
And that’s what .node files are for. .node files are dynamically shared objects that Node.js can load to its environment. Making an analogy here, I would say that .node files are very similar to .dll or .so files.
A lot of times, I heard how developers from different companies, which are writing in Python, C++, Java and other programming languages, say that JavaScript is crap. This bothered me for a while, so, at some point, I wrote this article to share my thoughts with you about JavaScript and it’s bad and, maybe, good parts.
Though, first, I would like to introduce myself a little, so you can decide, if it’s worth it to listen to me or if I’m just another blind JavaScript evangelist that knows none other language (choose your).
