Here is another interesting article from the same source: Underneath most scientific findings may lie a hidden "universe of uncertainty", according to a new study published on the Proceedings of the National Academy of Sciences. It looks as if the study centers only on social sciences, and it found that "When scientists used the same data set to answer a specific hypothesis — that immigration reduces support for social policy — dozens of researchers produced completely different results", which shouldn't truly surprise anyone. We have seen that many times before. As a matter of fact, when it comes to the world of social sciences, it almost looks as if it is possible to find a study to justify pretty much any preexisting assumption we may already have, thus defeating the purpose of using the scientific method in the first place, of course. Now, what one wonders is to what extent this also applies to the natural sciences or, at the very least, some of them. After all, how many times have we seen studies on nutrition that contradict each other? Perhaps, the wisest approach to all this would be to accept the power of the scientific methodology to guide us, but making sure to distance ourselves from what we might call scientificism (i.e., converting science into a dogma or ideology that we use to hit other people on the head). {link to this entry}

Here is an interesting article on Occam's razor that is well worth a read. As is very well known, the principle basically states that all else being equal, simplicity is to be preferred. Personally, I think it is a good idea to apply that to life in general, and not only to scientific endeavors. Said that, as the author of the article explains, the principle can also be misused, and then it becomes "a blunt instrument of overgeneralization". Or, to put it differently, as with so many other principles and ideas, if we make it into a dogma, then we err. In particular, we learn that Occam's razor may cause more problems than it solves in the field of data science. This is because the natural phenomena we try to model "are almost always more complex than the models, and the closer to their true complexity we can get, the more accurate the models." Like I said, it's an interesting (and short) read. {link to this entry}

Lately, I have been using sxiv, the image viewer from the Suckless project. But there is one little thing I didn't like: the default background color is white. So, how to change that? Is there an option we can use? No. According to the man page, properties like the background are configured via X resources. So, in the case of Debian, I just had to add the following line to my ~/.Xresources file:

Sxiv.background: #000000

Then, after saving the file, I only had to run the following command for the change to take effect:

xrdb -load ~/.Xresources

{link to this entry}

And here is a blog post clearly documenting how to change the loglevel of a given systemd service. That's what I used to change the loglevel for the "rtkit-daemon.sevice" on my Debian 11 box. End of the soap opera, hopefully. {link to this entry}

More on the logrotate soap opera. As it turned out, logrotate was failing to compress files, which was causing a huge waste of disk space. In particular, since rtkit-daemon was spewing so many messages to the syslog file, it was reaching a very large size (several gigabytes, actually). So, what was causing all this? For some reason, logrotate was sucessfully rotating the files (i.e., renaming "syslog" to "syslog.1", and creating a new "syslog" file). But it was failing to compress "syslog.1" (and all other "*.1" files). I had to manually edit the file "/etc/logrotate.d/rsyslog" to remove the "delaycompress" option altogether. This forum exchange on serverfault illustrates the problem. {link to this entry}

Today, I came across a blog post titled I've now disabled systemd-oomd on my Fedora desktops by Chris Siebenmann (his blog is highly recommended, by the way) that makes me shake my head in disbelief about systemd once again. Let's be clear. I don't particularly hate/dislike systemd. But I'm not sure such a highly complex design (precisely the opposite of the Unix philosophy!) was truly justified in order to accomplish the benefits it provides. All I can say is that, as far as I can tell, Debian 11 (bullseye) doesn't ship with this systemd-oomd feature at all, which is good news, as far as I'm concerned. Notice (and this is typical of systemd) that, while the kernel OOM feature does provide plenty of information on why it decides to kill processes and which processes it kills, systemd-oomd does not. Again, sadly, no surprises there. To me, the worst is that there is little choice but to run systemd, unless one wants to go through a lot of work. {link to this entry}

I hadn't noticed this until recently, when my syslog was becoming very large. I checked its contents, and realized that rtkit-daemon is printing a lot of messages. I may have to investigate how to decrease the verbosity of this service. But, in the meantime, since disabling it doesn't appear to have any negative consequences, here is what I did:

# systemctl stop rtkit-daemon                                            
# systemctl disable rtkit-daemon                                         
# systemctl mask rtkit-daemon   

{link to this entry}

Ever tried to reply to someone's SMS message with a "like", and found out that your opensource SMS app doesn't appear to support it? Mind you, the default Android SMS app does have that capability, but things like Simple SMS or QKSMS don't. The feature is called Rich Communication Services (RCS), and it was created to provide a richer interface for text messages (although it uses data services; be careful). Believe it or not, that still matters in a country like the US where the vast majority of people still use SMS to communicate (yes, in spite of all the security concerns). This other article also has a good explanation of the feature. So, how come you cannot find it in any opensource SMS app, at least that I can see? If I were to believe the netizens out there (and, in this csase, I don't have a reason not to believe them or, at the very least, I haven't seen any other clear explanation yet), Google decided to implement it on Android and promised that it would open it to everyone. But, so far, they have failed to do so, and it has been years since they released it. Again, not sure if that's correct or not, but I haven't seen any better explanation yet. If it is, that's a no-no, Google. That's doing evil. link to this entry}

So, I had to manually run the logrotate command to compress some large log files that had managed to reach a pretty big size. The command is quite straightforward:

# logrotate --force /etc/logrotate.d/rsyslog

Incidentally, this page has a pretty good explanation of how logrotate works. {link to this entry}