Michal @michal@kottman.xyz

Stumbled upon a video of modem sounds explained on a spectrograph, and immediately reminded me of this gem:

I've been playing with #Meshroom on my always-on computer and had to run other errands, and left it "idle" for >1d in a closed room.

It turns out that "idle" CPU usage for Meshroom is ~400% CPU while "doing nothing" and reported total time of >160h, and the room was nicely heated up a few °C above other rooms.

I wonder how much this would cost me...

After the #Computex #AMD announcements, it looks like I'll be skipping another generation of #Ryzen for my "new computer" waiting for better HW, since the announced Ryzen 7000 series specs look amazing.

If the #am5 is going to last as long as the #am4 did, it makes sense to "jump in" early and then have an uprade path towards the end of its lifetime, with many generations of improvements in between.

Another month, another successful #btrfs scrub with no errors, going 6 years strong, #raid5 with >6TiB of data, having been through multiple expansions and replacements.

I know hope is not a strategy, but reading online forums I keep hoping that the anecdotes of btrfs naysayers are just that, anecdotes.

The ffmpeg's libavcodec API is such a nuisance to code against. It's a constantly moving target. The "audio decode" was called `avcodec_decode_audio4` before it got removed and replaced with yet something else. And it's extremely boilerplate-y.

I'm sure it's all necessary for things like streaming (frames, packets, buffers, ...) but it would greatly benefit from a "simple API" - "load video file, iterate over pictures" / "load audio file, return raw samples"...

[1] https://github.com/FFmpeg/FFmpeg/commit/7c1f347b

When searching for any image, it's increasingly important to add "-pinterest" to the search terms to get useful results...

Everybody freaking out about #nvidia open-sourcing their kernel #driver, perhaps not realizing they are only open-sourcing the *kernel* part of the driver - not the huge userspace blob:

$ ls -l /usr/lib/firmware/nvidia/510.60.02/gsp.bin
-rw-r--r-- 1 root root 40439760 ... /usr/lib/firmware/nvidia/510.60.02/gsp.bin

It says so right there on the first page of README.md in the repo, if anyone bothered to check...

https://github.com/NVIDIA/open-gpu-kernel-modules

Over the past few days I've been playing with #qgis and #osm data whenever I could grab a moment. I went from:

"How am I supposed to do $simple_thing?!?!"

through:

"Mmm, this actually makes sense..."

to:

"Let me style all tertiary roads using dashed lines and have buildings in residential areas throw simple shadows and generate a 3x3 A4 poster optimized for B&W laser printer"

I'm having fun!

I'm playing the "Why?" game with the little one. My longest streak so far was 11 answers, since I didn't want to get into particle physics.

Winning strategies so far: not playing (stop responding) and/or steer the questions towards the little one ("Why?... Because you didn't want to do it, why didn't you want to do it? Because...")

Interesting little mnemonic I've been told as a kid about one's bottom and sitting on cold surfaces outdoors: "You can sit on your aRse if there's an R in the current month".

I still think September should get an exception...

#osm Trick to allow importing an entire country to pgRouting/PostGIS/PostgreSQL [1]: first chop up the source into smaller pieces using splitter [2], otherwise the osm2pgrouting tool will keep crashing:

$ java -jar splitter.jar --output-dir=splits/ country.osm
$ ONCE=--clean; for f in splits/*.pbf; do osmconvert $f --out-osm -o=part.osm; osm2pgrouting -f part.osm $ONCE ...; ONCE=; done

[1] https://pgrouting.org/
[2] https://wiki.openstreetmap.org/wiki/Mkgmap/help/splitter

Things I changed my opinion on based in practice - if you are committing a change, a test change should be included.

If you're modifying something, then either
a) it was tested before, and something must have started failing, or b) you're modifying something that wasn't tested before, so a new test case should be added.

Obviously one should apply common sense, but it's useful even for small/one-off projects...

Example where this is being done rigorously - SQLite, e.g. https://www.sqlite.org/src/info/3dc9fc2f2de8696b

It turns out that the extensions are maintained *per database*, so while I was upgrading the extension version in "postgres" database, I was *not* upgrading the extension in "mastodon" database.

After checking the extension versions in both using "\dx", the fix was simple - use the "postgres" user in the "mastodon" database and voila, it worked!

#mastodon + #postgresql: after recent upgrade, I wanted to try out /pghero only to find out it's broken with the following error in logs:

ERROR: column "total_plan_time" does not exist [1]

The supposed fix is to run the following command:

ALTER EXTENSION pg_stat_statements UPDATE;

Which only works under the "creator" creator account, so I ran it under "postgresql" role instead of "mastodon".

However, even after running it, it still didn't work...

[1] https://github.com/ankane/pghero/issues/341

It's Friday afternoon after working hours, obviously the best time for kids to have elevated temperature again.

Just after the doctor's office closes, yet another weekend not going anywhere, waiting to see how situation evolves.