Hacker News Reader

Comment by NelsonMinar | Hacker News Reader

Be sure to see the team's whole list of Cursed Knowledge. https://immich.app/cursed-knowledge

I love Immich & greatly appreciate the amazing work the team put into maintaining it, but between the OP & this "Cursed Knowledge" page, the apparent team culture of shouting from the rooftops complaints that expose their own ignorance about technology is a little concerning to be honest.

I've now read the entire Cursed Knowledge list & - while I found some of them to be invaluable insights & absolutely love the idea of projects maintaining a public list of this nature to educate - there are quite a few red flags in this particular list.

Before mentioning them: some excellent & valuable, genuinely cursed items: Postgres NOTIFY (albeit adapter-specific), npm scripts, bcrypt string lengths & especially the horrifically cursed Cloudflare fetch: all great knowledge. But...

> Secure contexts are cursed

> GPS sharing on mobile is cursed

These are extremely sane security feature. Do we think keeping users secure is cursed? It honestly seems crazy to me for them to have published these items in the list with a straight face.

> PostgreSQL parameters are cursed

Wherein their definition of "cursed" is that PG doesn't support running SQL queries with more than 65535 separate parameters! It seems to me that any sane engineer would expect the limit to be lower than that. The suggestion that making an SQL query with that many parameters is normal seems problematic.

> JavaScript Date objects are cursed

Javascript is zero-indexed by convention. This one's not a huge red flag but it is pretty funny for a programmer to find this problematic.

> Carriage returns in bash scripts are cursed

Non-default local git settings can break your local git repo. This isn't anything to do with bash & everyone knows git has footguns.

> Carriage returns in bash scripts are cursed

Also the full story here seemed to be

1. Person installs git on Windows with autocrlf enabled, automatically converting all LF to CRLF (very cursed in itself in my opinion).

2. Does their thing with git on the Windows' side (clone, checkout, whatever).

3. Then runs the checked out (and now broken due to autocrlf) code on Linux instead of Windows via WSL.

The biggest footgun here is autocrlf but I don't see how this is whole situation is the problem of any Linux tooling.

This is imo ultimately a problem with git.

If git didn't have this setting, then after checking out a bash file with LFs in it, there are many Windows editors that would not be able to edit that file properly. That's a limitation of those editors & nobody should be using those pieces of software to edit bash files. This is a problem that is entirely out of scope for a VCS & not something Git should ever have tried to solve.

In fact, having git solve this disincentives Windows editors from solving it correctly.

> I don't see how this is whole situation is the problem of any Linux tooling

Well, bash could also handle crlf nicely. There's no gain from interpreting cr as a non-space character.

(The same is valid for every language out there and all the spacey things, like zero-width space, non-breaking space, and vertical tabs.)

You will have the same problem if you build a Linux container image using scripts that were checked out on the windows host machine. What's even more devious is that some editors (at least VS Code) will automatically save .sh files with LF line endings on Windows, so the problem doesn't appear for the original author, only someone who clones the repo later. I spent probably half a day troubleshooting this a while back. IMO it's not the fault of any one tool, it's just a thing that most people will never think about until it bites them.

TL;DR - if your repo will contain bash scripts, use .gitattributes to make sure they have LF line endings.

The biggest mistake was running Linux programs over files created by Windows programs. Anything you move between those worlds is suspect.

It wouldn't be a problem if git didn't try to magic away the difference.

The Date complaint is

> JavaScript date objects are 1 indexed for years and days, but 0 indexed for months.

This mix of 0 and 1 indexing in calendar APIs goes back a long way. I first remember it coming from Java but I dimly recall Java was copying a Taligent Calendar API.

You're taking the word cursed way too seriously

This is just a list of things that can catch devs off guard

I guess you're right - I find the tone off but it's not egregious & it is mostly a very useful list.

Some of these seem less cursed, and more just security design?

>Some phones will silently strip GPS data from images when apps without location permission try to access them.

That strikes me as the right thing to do?

Huh. Maybe? I don't want that information available to apps to spy on me. But I do want full file contents available to some of them.

And wait. Uh oh. Does this mean my Syncthing-Fork app (which itself would never strike me as needing location services) might have my phone's images' location be stripped before making their way to my backup system?

EDIT: To answer my last question: My images transferred via Syncthing-Fork on a GrapheneOS device to another PC running Fedora Atomic have persisted the GPS data as verified by exiftool. Location permissions have not been granted to Syncthing-Fork.

Happy I didn't lose that data. But it would appear that permission to your photo files may expose your GPS locations regardless of the location permission.

With the Nextcloud app I remember having to enable full file permissions to preserve the GPS data of auto-uploaded photos a couple of years ago. Which I only discovered some months after these security changes went into effect on my phone. That was fun. I think Android 10 or 11 introduced it.

Looking now I can't even find that setting anymore on my current phone. But the photos still does have the GPS data intact.

I think the “cursed” part (from the developers point of view) is that some phones do that, some don’t, and if you don’t have both kinds available during testing, you might miss something?

> That strikes me as the right thing to do

Yep, and it's there for very goos reasons. However if you don't know about it, it can be quite surprising and challenging to debug.

Also it's annoying when your phones permissions optimiser runs and removes the location permissions from e.g. Google Photos, and you realise a few months later that your photos no longer have their location.

There is never a good reason to permanently modify my files, if that is what is going on here. Seems like I wouldn't be able to search my photos by location reliably if that data was stripped from them.

Nothing is "permanently modifying your files".

What happens is that when an application without location permissions tries to get photos, the corresponding OS calls strip the geo location data when passing them. The original photos still have it, but the application doesn't, because it doesn't have access to your location.

This was done because most people didn't know that photos contain their location, and people got burned by stalkers and scammers.

It's not if it silently alters the file. i do want GPS data for geolocation, so that when i import the images in the right places they are already placed where they should be on the map

IMO, the problem is that it fails silently.

Every kind of permission should fail the same way, informing the user about the failure, and asking if the user wants to give the permission, deny the access, or use dummy values. If there's more than one permission needed for an operation, you should be able to deny them all, or use any combination of allowing or using dummy values.

And permissions should also not be so wide. You should be able to give permission to the GPS data in pictures you consciously took without giving permission to track your position whenever.

I think the bad part is that the users are often unaware. Stripping the data by default makes sense but there should be an easy option not to.

Try to get an iPhone user to send you an original copy of a photo with all metadata. Even if they want to do it most of them don't know how.

How does it makes sense?

This kind of makes we wish CURSED.md was a standard file in projects. So much hard-earned knowledge could be shared.

You know you can just start doing that in your projects. That's how practice often becomes standard.

The Postgres query parameters one is funny. 65k parameters is not enough for you?!

As it says, bulk inserts with large datasets can fail. Inserting a few thousand rows into a table with 30 columns will hit the limit. You might run into this if you were synchronising data between systems or running big batch jobs.

Sqlite used to have a limit of 999 query parameters, which was much easier to hit. It's now a roomy 32k.

Right, for postgres I would use unnest for inserting a non-static amount of rows.

In the past I've used batches of data, inserted into a separate table with all the constraints turned off and using UNNEST, and then inserted into the final table once it was done. We ended up both batching the data and using UNNEST because it was faster but it still let us resume midway through.

We probably should have been partitioning the data instead of inserting it twice, but I never got around to fixing that.

COPY is likely a better option if you have access to the host, or provider-specific extensions like aws_s3 if you have those. I'm sure a data engineer would be able to suggest a better ETL architecture than "shove everything into postgres", too.

Was MERGE too slow/expensive? We tend to MERGE from staging or temporary tables when we sync big data sets. If we were on postgres I think we'd use ... ON CONFLICT, but MERGE does work.

COPY is often a usable alternative.

> PostgreSQL USER is cursed > The USER keyword in PostgreSQL is cursed because you can select from it like a table, which leads to confusion if you have a table name user as well.

is even funnier :D

SQL's "feature" of having table and field names in the same syntactic namespace as an ever expanding set of english language keywords is the original eldritch curse behind it all.

> JavaScript date objects are 1 indexed for years and days, but 0 indexed for months.

I don't disagree that months should be 1-indexed, but I would not make that assumption solely based on days/years being 1-indexed, since 0-indexing those would be psychotic.

The only reason I can think of to 0-index months is so you can do monthName[date.getMonth()] instead of monthName[date.getMonth() - 1].

I don't think adding counterintuitive behavior to your data to save a "- 1" here and there is a good idea, but I guess this is just legacy from the ancient times.

A [StackOverflow thread](https://stackoverflow.com/a/41992352) about this interface says it was introduced by Java way back in 1995, and copied by the first JavaScript implementation.

(We don't have Markdown formatting here, BTW. But thanks for the heads up, and welcome to YC.)

That would have a better solution in a date.getCurrentMonth(), in my opinion.

Temporal[0] is coming which solves many many many issues with JS Date, 1-based months[1] included!

Can't wait for it to be stable and widely available, it's just too good.

> month values start at 1, which is different from legacy Date where months are represented by zero-based indices (0 to 11)

[0] https://tc39.es/proposal-temporal/docs/

[1] https://tc39.es/proposal-temporal/docs/plaindate.html#month

Why so? Months in written form also start with 1, same as days/years, so it would make sense to match all of them.

For example, the first day of the first month of the first year is 1.1.1 AD (at least for Gregorian calendar), so we could just go with 0-indexed 0.0.0 AD.

Hum...

Dark-grey text on black is cursed. (Their light theme is readable.)

Also, you can do bulk inserts in postgres using arrays. Take a look at unnest. Standard bulk inserts are cursed in every database, I'm with the devs here that it's not worth fixing them in postgres just for compatibility.

Saw the long passwords are cursed one. Reminded me of ancient DES unix passwords only reading the first eight characters. What's old is new again...

Reply on news.ycombinator.com