🕙︎ - 2024-10-11
I have configured PostgreSQL to log queries that take more than some-number of milliseconds, so I can notice which queries are slow and perhaps do something about it.
Recently I have been noticing - in the window I have running tail -F on various logfiles (using autossh to my various servers, and piping it through ccze for colours) - that sometimes I had queries logged taking around 650 ms.
Last Sunday I finally decided to look at it. It was a whopper of a query coming from illuminant-nntp, when Gnus was fetching an article from illuminant.timeline by number.
The article numbers are generated by the query, so this had become slower as the number of toots in Illuminant's database has grown. Looking closer at the query, I realized that the sub-query finding the toots matching the article number also did a lot of the processing to get the information to return. Which is sub-optimal (haha) because it was doing that for all toots up until the article number that was actually needed.
So I fought the SQL for a while, changing the sub-query to only fetch/do as much as necessary to get the object id matching the wanted article number, and then moving all the formatting and information gathering "outside", to the top-query that now only had the one object and accompanying activities to get and convert to an article.
With that change the queries went from around 650 ms to around 200-220 ms. A nice improvement.
What's interesting is that I did not feel opening an article in illuminant.timeline in Gnus was slow - I guess the rule of thumb of a second is pretty good. But after making the improvement, opening articles feels snappy - so the preemptive optimization was a boon. And hopefully it will be a while until I have to figure out some other optimization to drop the query time again.
Yay monitoring!
🕣︎ - 2024-10-07
After taking most of August off the annoying Denial of Service
"attack" hit me again (previously: March, May, June), culminating in so many requests yesterday that
my feeble home router was starting to fall over.
So I threw the towel in the ring and moved the DNS for asjo.org to
domæne.shop.
I really like hosting things myself. I think it healthy for me and the
internet in general that people do so - instead of having megacorps
silo everything.
And more often than not, it's really not that complicated. Not even
for email, regardless of what people always say.
So I did not like giving up, but I was growing tired of trying to
block /8 networks and still having my servers receiving several
thousand packets a second.
For looking up asjo.org, for crying out loud: the zone is 36 lines
long:
virgil:/etc/bind$ wc -l db.asjoorg
36 db.asjoorg
Anyway, now it takes several minutes for each of my three DNS-servers
to receive 1000 DNS packets.
It is no 3.8 Tbps DDoS
attack - I don't even know my case is actually an attack, but annoying
nonetheless.
I still have no idea why, who, or what the hell. I guess it is just
one of those things.
🕔︎ - 2024-10-03
My home server has frozen a handful of times since summer, around the
time I switched to a new NVMe.
I was expecting the problem to be the kernel, because it got upgraded
at the same time (yes, wrong move), so I downgraded the kernel package
and went on summer vacation.
When it has frozen there has been nothing in the log file, and the
machine has still been responding to network packets, but access via
ssh has not been possible.
The previous time it froze I happened to have a terminal open, but no
commands could be run, as if the disk disappeared.
When it froze this morning, where I was lucky that I saw some log
2024-10-03T07:51:32.710948+02:00 virgil kernel: [2481125.908216] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0xffff
2024-10-03T07:51:32.710967+02:00 virgil kernel: [2481125.908240] nvme nvme0: Does your device have a faulty power saving mode enabled?
2024-10-03T07:51:32.710972+02:00 virgil kernel: [2481125.908254] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug
2024-10-03T07:51:32.758943+02:00 virgil kernel: [2481125.957166] nvme0n1: I/O Cmd(0x2) @ LBA 6366795000, 32 blocks, I/O Error (sct 0x3 / sc 0x71)
2024-10-03T07:51:32.758964+02:00 virgil kernel: [2481125.957192] blk_print_req_error: 1 callbacks suppressed
2024-10-03T07:51:32.758969+02:00 virgil kernel: [2481125.957195] I/O error, dev nvme0n1, sector 6366795000 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
2024-10-03T07:51:32.780690+02:00 virgil kernel: [2481125.980262] nvme 0000:06:00.0: Unable to change power state from D3cold to D0, device inaccessible
2024-10-03T07:51:32.780706+02:00 virgil kernel: [2481125.980486] nvme nvme0: Removing after probe failure status: -19
which makes more sense than the arbitrary kernel guess.
So I added those parameters to GRUB_CMDLINE_LINUX_DEFAULT in
/etc/default/grub, ran update-grub, and rebooted the machine.
Hopefully that fixes the problem.
This is with 6.1.106-3 on Debian 12 (bookworm) and a Samsung SSD 990
PRO 4TB.
🕧︎ - 2024-09-21
Almost 5 years ago I switched from a 14" Lenovo Thinkpad X1 Carbon
gen 3, which I liked a lot, to a 16" Lenovo
Thinkpad X1 Extreme gen
2. That was
quite a change - more than ½ kg heavier and a larger screen. Also a
hybrid GPU setup with an nVidia chip, which was a pain to figure out
to use, and then to turn off.
Never. Again.
Recently the battery started going flat while the laptop was off(!)
and the hinge is kind of floppy (some day I will try fixing
that),
so I decided I would treat myself to a new laptop.
Somewhat
inspired,
I found that currently the Lenovo Thinkpad X1 Carbon gen 12 was
available without a pre-installed operating system (thus avoiding the
"Microsoft Tax"), so I ordered one.
I was thinking of getting the ARM-based Thinkpad, but they're the
first generation of Lenovo ARM laptops, so I got lazy and opted for
the safer solution this time.
I like high resolution screens, so I got the 2880×1800 one, and since
RAM can't be expanded later, I opted for 64 GB, which meant I had to
get the more expensive CPU (usually I go for the slowest possible,
thinking it might use less power).
Ordering it with the smallest nvme SSD (0.25 T) and buying a 2 TB nvme
SSD seperately was much cheaper, so I did that. The Samsung 990 PRO I
had my eyes on was not available the same day, so I went with a WD
Black SN850X which seemed to be almost as performant, and a bit
cheaper, but most importantly available immediately!
I copied the contents of the two nvme SSDs in the old laptop to the
new one and got to work: installing a newer kernel from Debian
bookworm-backports and copying some firmware from the kernel
linux-firmware git-repository.
As I was still struggling to get the graphics accelerated (checking
with intel_gpu_top) I installed mesa and driver packages from Debian
trixie (current testing), and also sof-firmware for sound.
After fiddling around a lot and not getting anywhere, I finally got it
working by adding /etc/X11/xorg.conf.d/20-intel.conf and choosing
the modesetting (not intel) driver:
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
EndSection
After adjusting various font-sizes and my image scaling advice in
Emacs, the laptop is now working pretty well.
I like that the aspect ratio of the screen is a little less extreme
(the pixel area height of this 14" screen is the same as the old
16"!), even though the resolution is lower. Also the matte surface is
nicer than the glossy.
The lower weight is very nice - walking around with 1.1 kg instead of
1.7 kg is much easier.
I did make some mistakes as well.
I ordered with the "haptic touchpad", because I wasn't thinking. Well,
I thought "it's more expensive, so it must be better," which was a
mistake. The haptic touchpad doesn't have the nice separate
"mouse"-buttons that all Thinkpads usually have!
Luckily the - to me, very important - middle button "area" is marked
with some tiny nobbly protusions, so I think I'll live. And I tell
myself that it's a step in getting used to not have the physical
"mouse"-buttons, which makes my options for laptops in the future much
bigger.
The other mistakes I made were trying to switch around the physical
Ctrl and Fn-buttons, which are in the opposite place from the previous
laptops. I managed to break the little butterfly-things under the
buttons, and while trying to figure out what to do, I pulled off the
right shift button and wasn't able to put it back properly. Me. So.
Stupid.
Anyway, I have ordered some replacements - and an extra key to replace
the fugly Microsoft Windows button - hopefully the
right kind, as the ones I pulled off various laptops in the scrap pile
at work were other types.
Oh, I got the fingerprint reader working for login with lightdm,
fancy!
🕧︎ - 2024-08-24
Today 40 years ago I bought my first computer - a Commodore 64.
I didn't have enough money to buy a new one, so I told my parents I wanted to buy a used one. They decided to add enough money to get a new one.
I hooked it up to our black and white television set and started typing commands and small BASIC programs from the manual.
In the evening I had to disconnect the computer so my parents could watch the news on TV.
Unfortunately this meant losing all I had typed!
(I'm not quite sure why the computer couldn't just keep the contents of memory when disconnected from the television, maybe I didn't understand that I could just keep it turned on, maybe something happened when it was disconnected.)
This quickly led to my parents giving me an early christmas gift: a tape deck for the computer, so I could save my work on cassette tapes. Phew!
I never got a floppy disk drive for the Commodore 64 - they were very expensive, and I didn't really have the need. Only when I bought my second computer, an Amiga 500 I got a (built-in) floppy disk drive.
My first harddisk was a 40 MB Tiny Tiger II which connected to the Amiga 500 through an interface for the parallel port, but that's a story for another time.
🕕︎ - 2024-08-21
Some strings to memorize:
b2sum ca6914d2e33b83f2b2c66e4e625bc1d08674fae605008a215165d3c3a997d7d92945905207a539a7327be0f2728fa9aee005da9641407e5f3e4ef55b446b470a -
cksum 3515105045 1
md5sum 68b329da9893e34099c7d8ad5cb9c940 -
sha1sum adc83b19e793491b1c6ea0fd8b46cd9f32e592fc -
sha224sum 48837a787f07673545d9c610bcbcd8d46a2691a71966d856c197e69e -
sha256sum 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b -
sha384sum ec664e889ed6c1b2763cacf7899d95b7f347373eb982e523419feea3aa362d891b3bf025f292267a5854049091789c3e -
sha512sum be688838ca8686e5c90689bf2ab585cef1137c999b48c70b92f67a5c34dc15697b5d11c982ed6d71be1e1e7f7b4e0733884aa97c3f7a339a8ed03577cf74be09 -
shasum adc83b19e793491b1c6ea0fd8b46cd9f32e592fc -
Inspired by a recent fediverse
post by Simon Tatham.
🕤︎ - 2024-08-20
I recently stumbled over a video on Youtube about the visual effects
in one of the first movies that had a lot of computer generated
images, Flight of the Navigator.
I hadn't heard about the movie before, but the video went into much
detail about how many of the model shots were made. The channel was
called Captain Depression or Captain something or the other...
Disillusion! There it was: Flight of the Navigator | VFXcool.
Anyway, I watched the movie last night. It was mediocre.
It was fun to see the effects after having seen them explained, but
that was about it. The most jarring thing was that the space ship took
on a goofy silly voice after sucking too much information out of the
boy's head. It was much more fun when it was stern and distanced.
The film features Sarah Jessica Parker in one of her early, small
roles - and a fun gag as seen on the screenshot above, tipping the hat
to E.T. The NASA professor is called Louis Faraday(!)
The computer graphics were generated on a PDP-10 derived computer, the
Foonly F1, which
generated one image at a time, filling up a separate cabinet holding 3
MB of video buffer, which was then transfered to film, before the next
image overwrote the buffer. Also used for the original Tron movie.
