Also a crypto library that limits passwords to 72 bytes? That’s wild
1 - https://github.com/savely-krasovsky/immich/commit/aeb5368602...
From the linked GitHub issue comments, it looks like they adopted the sensible approach of refactoring their ORM so that it splits the big query into several smaller queries. Anecdotally, I've found 3,000 to 5,000 rows per write query to be a good ratio.
Someone else suggested first loading the data into a temp table and then joining against that, which would have further improved performance, especially if they wrote it as a COPY … FROM. But the idea was scrapped (also sensibly) for requiring too many app code changes.
Overall, this was quite an illuminating tome of cursed knowledge, all good warnings to have. Nicely done!
I'll give you a real cursed Postgres one: prepared statement names are silently truncated to NAMEDATALEN-1. NAMEDATALEN is 64. This goes back to 2001...or rather, that's when NAMEDATALEN was increased in size from 32. The truncation behavior itself is older still. It's something ORMs need to know about it -- few humans are preparing statement names of sixty-plus characters.
Java developers: hold my beer
Long time since I thought of that movie.
I'm big on Hanlon's Razor too, but that doesn't mean the end result can't be the same.
That person might not be doing it knowingly or on purpose, but regardless of motivations that is definitely what is being done.
EDIT: Oops, he just did the changelog entry. The actual fix was done by someone else: https://github.com/A11yance/aria-query/commit/f5b8f4c9001ba7...
Especially if you could control at install time just how far back to go, that might be interesting.
Also an immediately ridiculous graph problem for all but trivial cases.
- macOS data forks, xattrs, and Spotlight (md) indexing every single removable volume by default adds tons of hidden files and junk to files on said removable volumes. Solution: mdutil -X /Volumes/path/to/vol
- Everything with opt-out telemetry: go, yarn, meilisearch, homebrew, vcpkg, dotnet, Windows, VS Code, Claude Code, macOS, Docker, Splunk, OpenShift, Firefox, Chrome, flutter, and zillions of other corporate abominations
By default, telemetry data is kept only on the local computer, but users may opt in to uploading an approved subset of telemetry data to https://telemetry.go.dev.
To opt in to uploading telemetry data to the Go team, run:
go telemetry on
go telemetry off
Is this true? I couldn’t find another source discussing it. That would be insane behavior for a package manager.
1 - https://steveloughran.gitbooks.io/kerberos_and_hadoop/conten...
05/26/23(?) Datetimes in EXIF metadata are cursed
its valid privacy and security on how mobile OS handle permission
This is whack as hell but doesn't seem to be the default? This issue was caused by the "Flexible" mode, but the docs say "Automatic" is the default? (Maybe it was the default at the time?)
> Automatic SSL/TLS (default)
https://developers.cloudflare.com/ssl/origin-configuration/s...
I don't think so. If you read about what Flexible SSL means, you are getting exactly what you are asking for.
https://developers.cloudflare.com/ssl/origin-configuration/s...
Here is a direct quote of the recommendation on how this feature was designed to be used:
> Choose this option when you cannot set up an SSL certificate on your origin or your origin does not support SSL/TLS.
Furthermore, Cloudflare's page on encryption modes provides this description of their flexible mode.
> Flexible : Traffic from browsers to Cloudflare can be encrypted via HTTPS, but traffic from Cloudflare to the origin server is not. This mode is common for origins that do not support TLS, though upgrading the origin configuration is recommended whenever possible.
So, people go out of their way to set an encryption mode that was designed to forward requests to origin servers that do not or cannot support HTTPS connections, and then are surprised those outbound connections to their origin servers are not HTTPS.
I would like to know how this setting got enabled, however. And I don't think the document should describe it as a "default" if it isn't one.
It's a custom mode where you explicitly configure your own requests to your own origin server to be HTTP instead of HTTPS. Even Cloudflare discourages the use of this mode, and you need to go way out of your way to explicitly enable it.
> (...) apparently was surprising to the authors of this post.
The post is quite old, and perhaps Cloudflare's documentation was stale back then. However, it is practically impossible to set flexible mode being aware of what it means and what it does.
> I would like to know how this setting got enabled, however.
Cloudflare's docs state this is a custom encryption mode that is not set by default and you need to purposely go to the custom encryption mode config panel to pick this option among half a dozen other options.
Perhaps this was not how things were done back then, but as it stands this is hardly surprising or a gotcha. You need to go way out of your way to configure Cloudflare to do what amounts to TLS termination at the edge, and to do so you need to skip a bunch of options that enforce https.
For me, MacOS file names are cursed:
1. Filenames in MacOS are case-INsensitive, meaning file.txt and FILE.txt are equivalent
2. Filenames in MacOS, when saved in NFC, may be converted to NFD
I put out requests across the Net, mostly Usenet at the time, and people sent me their track listings and I would put out a new file every day with the new additions.
Until I hit 64KB which is the max size of an .ini file under Windows, I guess. And that was the end of that project.
$ echo yup > README.txt
$ cat ReAdMe.TXT
yup
$ ls
README.txt
[1] https://play.yaml.io/main/parser?input=ICAgICAgdGVzdDogPi0KI...
[2]https://play.yaml.io/main/parser?input=ICAgICAgdGVzdDogPi0KI...
That's no curse, it's a protection hex!
It seems great that an app without location access cannot check location via EXIF, but I'm surprised that "all file access" also gates access to the metadata, perhaps one selected using the picker.
https://gitlab.com/CalyxOS/platform_packages_providers_Media...
Those classes can call stored procedures or functions.
Those classes can be called BY stored procedures or functions.
You can call stored procedures and functions from server-side Java code.
So you can have a java app call a stored proc call a java class call a stored proc ...
Yes. Yes, this is why they call it Legacy.
Uh... good?
I might not want an application to know my current, active location. But it might be useful for it to get location data from images I give it access to.
I do think if we have to choose between stripping nothing or always stripping if there's no location access, this is the correct and safe solution.
This is a good example of a complex setting that makes sense to the 1% of users who understand the nuances of EXIF embedded location data but confuses the 99% of users who use a product.
It would also become a nightmare to manage settings a per-image basis.
That said, an alternative to bugging the user might be that when the app makes the call to open the file that call should fail unless the app explicitly passes a flag to strip the location data. That way you protect users without causing needless confusion for developers when things that ought to "just work" go inexplicably wrong for them.
Perhaps it is mm/dd/yyyy (really?!?) that is cursed....
https://wikipedia.org/wiki/Date_and_time_representation_by_c...
IMO the best format is yyyy/mm/dd because it’s unambiguous (EDIT: almost) everywhere.
> Short format: (yyyy.dd.mm) in Kazakh[95][obsolete source]
ISO-IR-26 was registered on 1976/25/03.
Note the slashes are important, we don't use dots or dashes with this order. That's what GP was getting at.
Counterexample: US Independence Day is called the “Fourth of July”.
I would agree that, for dates with named months, the US mostly writes “August 8, 2025” and says “August eighth, 2025” (or sometimes “August eight, 2025”, I think?), and other countries mostly write “8 August 2025” and say “the eighth of August, 2025”; but neither is absolute.
But, I think the American-style formatting is logical for everyday use. When you're discussing a date, and you're not a historian, the most common reason is that you're making plans with someone else or talking about an upcoming event. That means most dates you discuss on a daily basis will be in the next 12 months. So starting with the month says approximately when in the next year you're talking about, giving the day next says when in that month, and then tacking on the year confirms the common case that you mean the next occurrence of it.
When's Thanksgiving? November (what part of the year?) 27 (toward the end of that November), 2025 (this year).
It's like answering how many minutes are in a day: 1 thousand, 4 hundred, and 40. You could say 40, 400, and 1000, which is still correct, but everyone's going to look at you weirdly. Answer "2025 (yeah, obviously), the 27th (of this month?) of November (why didn't you start with that?)" is also correct, but it sounds odd.
So 11/27/2025 starts with the most useful information and works its way to the least, for the most common ways people discuss dates with others. I get it. It makes since.
But I'll still use ISO8601.
As a US native let me clearly state that the US convention for writing dates is utterly cursed. Our usage of it makes even less sense than our continued refusal to adopt the metric system.
If you wanted a short form to match the word form, you go with something like:
“mmmm/dd/yyyy”
Where mmmm is either letters, or a 2-character prefix. The word form “August 7th…” is packing more info that the short form.
You mean the one where explicitly configuring Cloudflare to forward requests to origin servers as HTTP will actually send requests as HTTP? That is not what I would describe as disappointing.