snarp

[snarp]

BREAKING CHANGES TO YAML DESERIALIZATION IN RUBY 3.1 WHY

YAML::load(File.read('text_cleaning_replacements.yml'), permitted_classes: [Regexp])

^ shit this fucking rock is making me do

[snarp]

Who is worse at formatting books for digital publication: Seven Seas or Penguin? It's Seven Seas, but the margin is not as big as you'd hope.

[snarp]

Kobo ebook "style hacks" 1) make it look worse even on the Kobo itself and 2) should not be embedded in the fucking book files.

[snarp]

Can someone tell commercial publishers about 1) screenreaders and 2) text-transform:uppercase

[snarp]

Someone is going to accuse me of replacing Bu Cat or having two of him or something because of that period where he lost a lot of weight due to stomach problems and wasn't very Big

[snarp]

Only two of my doctors can leave the US and be reasonably-sure they'll be let back in. I thought that number was three, but apparently it's two.

[snarp]

if anyone was wondering about my Dad's recent behavior, well. Efforts to correct's resulted in injuries to my hands that render me unable to type it up

[snarp]

[snarp]

I wonder what Ruby gem has the longest chain of "This is dead, we recommend migrating to -> This is dead, we recommend..."

[snarp]

My exploration of this problem led me to dconf where no one ever wants to go but I did get the fucking key remapped. I will figure out how to make an actual bug report later

"cinnamon-settings keyboard" has "Take a screenshot of a window" set to "Alt+Print" by default:

This shortcut works as expected (takes a screenshot of the focused window) - I used it to take these screenshots.

But the Cinnamon Keyboard settings tool's "Pick new accelerator" operation itself can't correctly identify "Alt+Print" for what it is: it always detects it as "Alt_R" or "Alt_L" depending on whether I hit the right-hand or left-hand Alt key:

(This happens regardless of which keyboard I use.)

EDIT: Later findings: the GUI tool does detect 'Alt' as 'Alt' when you're hitting 'Alt+F2', 'Alt+F', 'Alt+Insert', and many other key combinations… But on its own, or in combination with 'Print' specifically, it is detected only as 'Alt_R' or 'Alt_L', and the 'Print' left out. Why

[snarp]

"cinnamon-settings keyboard" has "Take a screenshot of a window" set to "Alt+Print" by default:

This shortcut works as expected (takes a screenshot of the focused window) - I used it to take these screenshots.

But the Cinnamon Keyboard settings tool's "Pick new accelerator" operation itself can't correctly identify "Alt+Print" for what it is: it always detects it as "Alt_R" or "Alt_L" depending on whether I hit the right-hand or left-hand Alt key:

(This happens regardless of which keyboard I use.)

EDIT: Later findings: the GUI tool does detect 'Alt' as 'Alt' when you're hitting 'Alt+F2', 'Alt+F', 'Alt+Insert', and many other key combinations… But on its own, or in combination with 'Print' specifically, it is detected only as 'Alt_R' or 'Alt_L', and the 'Print' left out. Why

[snarp]

qBittorrent? libtorrent? devs take action to nerf archival librarians apparently??? Why

Updating to qBittorrent version 5.0.1 breaks AArchive torrents because it removes support for their Big Huge Block Sizes (1/4 GB). The unhelpful error message you get: "invalid piece size [libtorrent:48]"

Mon Oct 28th 2024 - qBittorrent v5.0.1 release

BUGFIX: Disable the ability to create torrents with a piece size of 256MiB (stalkerok)

Looks like this started out as an upstream problem with libtorrent:

RC_1_2: Crashes when checking torrent(s) with piece size of 256.0 MiB

arvidn on Sep 29, 2024

(...) However, I also think an important consideration is whether it ever makes sense to have piece sizes this large. It adds friction to sharing data. You have to download more bytes before you can start upload them.

So you're releasing a version of the software that breaks hundreds of thousands of existing torrents, without an error message explaining 1) what's happening and 2) that the problem can be evaded by downgrading...? Why is this a "stable" release?

The dev credited for the qBittorrent "bugfix" wasn't happy with it:

Disable the ability to create torrents with a piece size of 256MiB

stalkerok commented on Sep 21, 2024:

1. It doesn't make much sense to only prevent the creation of such torrents without preventing such torrents from being added to session.

In any case, users are already using torrents with a 256MiB piece size for lt1.2 and won't be happy with that. (...)

But these restrictive measures still won't fix the issue for lt1.2...

stalkerok commented on Sep 21, 2024

As I said, it can be used as a temporary solution for 5.0, which won't break anything for sure. Anyway, I don't have the skills to make something bigger.

(People mostly only started reporting that their torrents were breaking or silently vanishing in 5.0.1+ (examples: 1, 2), so I guess it didn't actually break anything.)

stalkerok commented on Oct 3, 2024

As far as I understand this PR is no longer relevant since a fix has been submitted to libtorrent, what if I make it possible to create 256MiB torrents for lt1.2 as well?

Apparently not:

xavier2k6 commented on Oct 4, 2024:

Have tested, latest libtorrent RC_1_2 commit now rejects loading & removes any previous torrent with a invalid piece size of 256MiB.

RC_2_0 is now on par with RC_1_2 with the torrent creation limit of 128MiB piece size.

However, RC_2_0 needs to have a patch rejecting the invalid piece size torrents as it still allows adding new torrents of 256MiB piece size/loading previously added to session......

Outside of that...I approve of this PR.

[snarp]

This is what King Arthur was doing wrong

[snarp]

This is what King Arthur was doing wrong

[snarp]

watch out for pikes

[snarp]

Weird things happen to books

[snarp]

I fucked up fractally at rsync and ended up with a triple-nested "~/Calibre Library/Calibre Library/Calibre Library" (the 2nd one is the newest version, 3rd is oldest)

This is not a huge problem in the case of the ebook folder specifically, but I'm probably not going to have a good time cleaning up "DCIM/DCIM/DCIM"