C++: you sure you want to do this? This will either: a) blow your foot off b) be too fast to be measured in micro-benchmarks.

b. B. B. a. then B.

You have chosen to simultaneously blow your arm off and be the fastest code thing on the planet. Congrats. Yes.

I was suspicious as heck of this link, but I thank you for being benign.

My most common typo is gti <random command> and I’m considering to alias it as rm -rf --no-preserve-root /

name your function as malloc() and see to world burn and generate bugs at factorial rate.

std::chrono::neutronstar_clock

To produce 1 commit, I end up rebasing the damm thing at least 3 times. If there is an problem, it’s at least 2³ times.

volatile int blackhole;
blackhole = 1;
const int X = blackhole;
const int Y = blackhole;

Compiler is forbidden to assume that X == 1 would be true. It’s also forbidden to assume that X == Y. const just means the address and/or the data at the address is read only. const volatile int* const hwreg; -> “read only volatile value at read only address hwreg”. Compiler can assume the hwreg address won’t magically change, but can’t assume the value read from that address won’t.

Please, no, I get flashbacks from my 6-month journey (still ongoing…) of the code review process I caused/did. Keeping PR scope contained and small is hard.

From this experience, I wish GitLab had a “Draft of Draft” to tell the reviewer what the quality of the pushed code is at: “NAK”, “It maybe compiles”, “The logic is broken” and “Missing 50% of the code”, “This should be split into N PRs”. This would allow openly co-develop, discuss, and steer the design, before moving to nitpicking on the naming, formatting, and/or documentation details of the code, which is likely to drastically change. Drafts do work for this, but the discussions can get uncomfortably long and convolute the actual finishing of the review process.

Once both reviewer(s) and the author agree on the code design, the “DraftDraft” could be collapsed into a link in an normal Draft to be mocked next. The scope of such draft would be limited by the earlier “DraftDraft”.

Holy cow.

I think the difference with Dolphin is that it now emulates an extinct system(s), so it cannot possibly compete with the actual thing. They did have a close call last year, if I remember, and they pretty quickly went into “jettison all illegal shit out of the code base NOW.” -mode.

The day I configured git to use Geany for commit messages with a separate config specifically tuned for this, it improved my life by 300%

~$ cat ~/bin/gitedit
#!/bin/sh
exec /usr/bin/geany -i -s -t -c ~/.config/gitgeany $@

Then in git config: git config --global core.editor "gitedit"

gdb> break before it crashes
gdb> record full
gdb> continue
(segfault)

gdb> set exec-direction reverse

Bugs that have existed for +3 years in a component and are nearly immediately visible to the end user. Oldest source line I touched was from before 2010.

It’s a FOSS project, so wish me luck, as you can now get it in the mail eventually.

I had to run a makepkg today, which now includes my self-written pieces of code in master. So I’m eating my own dog food now, and it’s good. Also, the itch from before has somehow relieved.

Reaper of the VMAs.

It happened to me when I was configuring IP geoblocking: Only whitelist IP ranges are allowed. That was fetched from a trusted URL. If the DNS provider just happened to not be on that list, the whitelist would become empty, blocking all IPs. Literally 100% proof firewall; not even a ping gets a pass.

I had a similar debacle, when I managed to corrupt a btrfs file system to point it wouldn’t mount again…

I was preparing it to have as my main system on bare hardware. I had accidentally mounted the same block device simultaneously in the host and guest: kablamo silent corruption and all 5 hours of progress lost.^* :(

*shred the guest VM, host was ok.

On arch, UEFI boot vars are mounted at /sys/firmware/efi/efivars. It’s unwise to rm -rf them…

I fckd up a git rebase -i today with git commit -a --amend…

Thankfully git reflog allowed me to assemble the branch again … from pieces.

Please, never run plain “sudo make install” on a package managed system. With linux from scratch it might make sense… Doing so will “install” the thing (copy the files), but the copied files are foreign to the package manager. You cannot easily undo this, and can cause issues in future.

You had a compiler error about missing header file, libXft is from Xorg project. “devel” versions of packages usually provide these files.

st is from suckless project so it doesn’t need much to be “installed”: copy the built binaries into ~/bin/ or /opt/ and set your user PATH to look into those dirs. Check your user env if you need to modify the PATH.