One of their line items complains about being unable to bind 65k PostgreSQL placeholders (the linked post calls them "parameters") in a single query. This is a cursed idea to begin with, so I can't fully blame PostgreSQL.
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!
simpaticoder · 2h ago
I loved this the moment I saw it. After looking at an example commit[1], I love it even more. The cursed knowledge entry is committed alongside the fix needed to address it. My first instinct is that every project should have a similar facility. The log is not just cathartic, but turns each frustrating speedbump into a positive learning experience. By making it public, it becomes both a tool for both commiseration and prevention.
The '50 extra packages' one is wild. The author of those packages has racked up a fuckload of downloads. What a waste of total bandwidth and disk space everywhere. I wonder if it's for clout.
bikeshaving · 2h ago
The maintainer who this piece of “cursed knowledge” is referencing is a member of TC39, and has fought and died on many hills in many popular JavaScript projects, consistently providing some of the worst takes on JavaScript and software development imaginable. For this specific polyfill controversy, some people alleged a pecuniary motivation, I think maybe related to GitHub sponsors or Tidelift, but I never verified that claim, and given how little these sources pay I’m more inclined to believe he just really believes in backwards compatibility. I dare not speak his name, lest I incur the wrath of various influential JavaScript figures who are friends with him, and possibly keep him around like that guy who was trained wrong as a joke in Kung Pow: Enter the Fist. In 2025, I’ve moderated my opinion of him; he does do important maintenance work, and it’s nice to have someone who seems to be consistently wrong in the community, I guess.
treve · 16m ago
On further inspection it's the author of packages such as 'is-even'. I once spent an evening trying to get these useless dependencies out of some popular package dependency trees but I remember this person personally dropped into the PR comments to aggressively prevent this.
Centigonal · 3h ago
It's probably a clout thing, or just a weird guy (Hanlon's Razor), but a particularly paranoid interpretation is that this person is setting up for a massive, multi-pronged software supplychain attack.
godelski · 59m ago
Those don't have to be mutually exclusive. Often those with clout are targeted for supplychain attacks. Take xz as an example. Doesn't seem unreasonable that a solo dev or small team looks to either sell their projects or transfer them to someone else (often not even with money exchanging hands). Or even how old social media accounts are hacked so that they can appear as legitimate accounts.
I'm big on Hanlon's Razor too, but that doesn't mean the end result can't be the same.
fastball · 2h ago
The author is almost certainly ljharb.
0x696C6961 · 1h ago
I'm convinced he's a rage baiting account. No-one can consistently have such bad takes.
smitty1e · 3h ago
It does raise the idea of managed backward compatibility.
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.
burnt-resistor · 2h ago
- Windows' NTFS Alternate Data Streams (ADS) allows hiding an unlimited number of files in already existing files
- 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
thorum · 2h ago
> npm scripts make a http call to the npm registry each time they run, which means they are a terrible way to execute a health check.
Is this true? I couldn’t find another source discussing it. That would be insane behavior for a package manager.
No comments yet
godelski · 1h ago
Looks like they're missing one. I'm pretty sure the discussion goes further back[0,1] but this one has been on going for years and seems to be the main one[2]
This is awesome! Does anyone else wanna share some of the cursed knowledge they've picked up?
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
mdaniel · 1m ago
1 is only true by default, both HFS and APFS have case sensitive options . NTFS also behaves like you described, and I believe the distinction is that the filesystems are case-retentive, so this will work fine:
Maybe the cursed version of the filesystem story is that goddamn Steam refuses to install on the case sensitive version of the filesystem, although Steam has a Linux version. Asshats
binary132 · 37m ago
This would be a fun github repo. Kind of like Awesome X, but Cursed.
bigyabai · 3h ago
> Some phones will silently strip GPS data from images when apps without location permission try to access them.
I think this is written unclearly. Looking at the linked issues, the root cause seems to be related to a "all file access" permission, not just fine grained location access.
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.
I have no idea what that means but to me it looks like it works as designed.
Muromec · 3h ago
A ward even
LeoPanthera · 2h ago
"Some phones will silently strip GPS data from images when apps without location permission try to access them."
Uh... good?
steve_adams_86 · 2h ago
I'm torn. Maybe a better approach would be a prompt saying "you're giving access to images with embedded location data. Do you want to keep the location data in the images, or strip the location data in this application?"
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.
Aurornis · 1h ago
> saying "you're giving access to images with embedded location data. Do you want to keep the location data in the images, or strip the location data in this application?"
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.
g8oz · 3h ago
This is awesome. Disappointing to hear about the Cloudflare fetch issue.
worik · 3h ago
dd/mm/yyyy date formats are cursed....
Perhaps it is mm/dd/yyyy (really?!?) that is cursed....
armchairhacker · 2h ago
dd/mm/yyyy is most common worldwide (particularly Europe, India, Australia) followed by yyyy/mm/dd (particularly China, Japan, South Korea).
> Short format: (yyyy.dd.mm) in Kazakh[95][obsolete source]
o11c · 40m ago
Even ISO has used the cursed date format.
ISO-IR-26 was registered on 1976/25/03.
accrual · 2h ago
I like CCYY-MM-DD because it's also a valid file name on most systems, and using "CCYY" (century + year) instead of "YYYY" feels fancy.
hollerith · 3h ago
mm.dd.yyyy is cursed, too. The not-cursed options are dd.mm.yyyy and mm/dd/yyyy
dmd · 2h ago
in what world could mm/dd/yyyy not be cursed!? that makes no sense whatsoever.
Izkata · 2h ago
It's the US short form, matching the word-month order we always use for regular dates: "August 7, 2025".
Note the slashes are important, we don't use dots or dashes with this order. That's what GP was getting at.
FridgeSeal · 14m ago
The short form doesn’t match the word form though.
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.
dmd · 2h ago
And it makes absolutely no sense. I've lived with it all my life (I'm an American!) and it has never made any sense to me.
kstrauser · 2h ago
First, I use ISO8601 for everything. This is not me arguing against it.
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.
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!
1 - https://github.com/savely-krasovsky/immich/commit/aeb5368602...
I'm big on Hanlon's Razor too, but that doesn't mean the end result can't be the same.
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
Is this true? I couldn’t find another source discussing it. That would be insane behavior for a package manager.
No comments yet
[1] https://github.com/immich-app/immich/issues/6623
[2] https://github.com/immich-app/immich/discussions/12292
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
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...
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.
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.
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.
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.