daily occasional dose of nihilism🌗

Ever wondered how sites were done 10 years ago? Look at this. It’s not actually 10 years old video, it’s been published just two days ago, which is rather scary. The guy („engineer“) starts with spinning up a LAMP server with PHP 5.4 (years past EOL). Don’t worry, it gets worse. If you want to know how to do it right, just watch the video and do the exact opposite (well, do escape your inputs, but use prepared statements instead and never ever use a raw variable in your SQL query).

By the way, why do people still install virtual servers and deal with stupid containers for simple things? How is it easier or more convenient than having several versions of PHP installed and use the built-in web server? Is making your own life more complicated some sort of fetish I don’t understand?

Partial merge

Every now and then, while working on a feature branch, I tend to introduce some related changes, like bug fixes or enhancements on a code the new feature depends on. Sure, I could just push these changes directly to the master branch, but I don’t feel like switching and rebasing branches all the times.

Instead, I do a partial merge of my branch. That’s basically moving some commits present on my feature branch into the master branch, from which my branch is forked.

Now, there are several ways of doing this with Git, and this is mine!

First of all, I reorder commits in my branch, so that the commits I’m about to move precede those I want to keep on the feature branch. Consider the history like this:

290a4ab (feature-parser-lookahead) parser: Reduced unnecessary next() calls.
8321e20 (feature-parser-lookahead) parser: Introduced lookahead.
c667a8a (master) parser: Fixed tokenizer leaking.

Now, we need to switch those commits so that 290a4ab references the c667a8a (master) and 8321e20 follows, thus being the only commit on the feature branch. For reordering, we’re going to use the interactive rebase (we’re on our feature branch):

git rebase -i master

Git will start an editor and opens a file like this:

pick 8321e20 parser: Introduced lookahead.
pick 290a4ab parser: Reduced unnecessary next() calls.

Here, we simply reorder our commits (those we want to merge will be first):

pick 290a4ab parser: Reduced unnecessary next() calls.
pick 8321e20 parser: Introduced lookahead.

By the way, there’s more you can do here - squash (or fixup, respectively) is very handy for bringing several commits into one. You can also use this for discarding unwanted commits.

# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
# These lines can be re-ordered; they are executed from top to bottom.

Note, that it’s not always that easy, you might need to do a manual merge. That might be a bad sign; be careful before merging anything like that into the master branch. Whenever this happen to me, I split my conflicting commits and move individual changes between them, which is another story.

Anyway, once you finish the rebase, your history should look like this:

c70be28 (feature-parser-lookahead) parser: Introduced lookahead.
072406c (feature-parser-lookahead) parser: Reduced unnecessary next() calls.
c667a8a (master) parser: Fixed tokenizer leaking.

Now, all we need is merge our branch up to a certain point (072406c in this case)! Just switch to master and do it:

git merge 072406c

Now, all commits up to the one we merged are in our master branch!

c70be28 (feature-parser-lookahead) parser: Introduced lookahead.
072406c (master) parser: Reduced unnecessary next() calls.
c667a8a (master) parser: Fixed tokenizer leaking.

Funny thing. I ran apt autoremove, as libapache2-mod-php7.2 was no longer needed. But why PHP 7.3 mod was disabled as well in the process? Obviously, this happened with no warning and monitoring was still happy about it, as all it cares about is the response code. Lesson learned.


This mother is demanding her kid’s Facebook password. The sub is full of weirdos, but I find this one unusually disturbing. Apart from a personal diary and your own mind, is there anything more private than anyone’s one-to-one conversation? Sure, you can discuss things in personal, or you can make a phone call, but it’s 2019, it’s pretty common to use a messenger, I guess. What you think and talk about with your closest friends is kinda who you are. This is a direct attack to your own identity and personality.

It’s an easy problem to solve, you can just create and use a different channel from the one being monitored (which is, by the way, exactly what is going to happen in this particular case). In other words, mutual trust is lost and worse, the claimed „protection“ is now off the table, as there is a channel the parent doesn’t even know about. I wouldn’t count on the woman actually explaining her child what’s an online safety and privacy and how (and why!) to keep it.

I mean, how is this different from listening to anyone else’s phone calls, reading their letters and stalking on them? How do you actually do this without considering yourself a piece of shit?

Who can use Facebook: … For this reason, you must: Not share your password, give access to your Facebook account to others, or transfer your account to anyone else (without our permission).

Theoretically, this could even be a federal crime. At the end of the day, password is a sort of a property and as such it should be protected, no exception.