8 ms·

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

levkk 1y ago
The Postgres query parameters one is funny. 65k parameters is not enough for you?!
- strken 1y ago
  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.
  - evertedsphere 1y ago
    COPY is often a usable alternative.
  - tym0 1y ago
    Right, for postgres I would use unnest for inserting a non-static amount of rows.
    - strken 1y ago
      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.
      - devjab 1y ago
        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.
- reliabilityguy 1y ago
  > 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
  - account42 11mo ago
    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.
nemothekid 1y ago
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?
- gausswho 1y ago
  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.
  - krs_ 1y ago
    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.
- serial_dev 1y ago
  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?
- _ZeD_ 1y ago
  How does it makes sense?
- monegator 1y ago
eco 1y ago
This kind of makes we wish CURSED.md was a standard file in projects. So much hard-earned knowledge could be shared.
- MrDresden 1y ago
  You know you can just start doing that in your projects. That's how practice often becomes standard.
kyle-rb 1y ago
> 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.
- watermelon0 1y ago
  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.
- kaoD 1y ago
  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.
  - oblio 1y ago
    That would have a better solution in a date.getCurrentMonth(), in my opinion.
    - kaoD 1y ago
      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/ https://tc39.es/proposal-temporal/docs/ [1] https://tc39.es/proposal-temporal/docs/plaindate.html#month https://tc39.es/proposal-temporal/docs/plaindate.html#month
  - its_brass 11mo ago
    A [StackOverflow thread](https://stackoverflow.com/a/41992352 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.
6c696e7578 1y ago
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...
lucideer 1y ago
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.
- MzHN 1y ago
  > 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.
  - lucideer 1y ago
    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.
marcosdumay 11mo ago
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.

levkk 1y ago

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

strken 1y ago
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.
- evertedsphere 1y ago
  COPY is often a usable alternative.
- tym0 1y ago
  Right, for postgres I would use unnest for inserting a non-static amount of rows.
  - strken 1y ago
    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.
    - devjab 1y ago
      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.
reliabilityguy 1y ago
> 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
- account42 11mo ago
  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.

nemothekid 1y ago

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?

gausswho 1y ago
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.
- krs_ 1y ago
  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.
serial_dev 1y ago
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?
_ZeD_ 1y ago
How does it makes sense?
monegator 1y ago

eco 1y ago

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

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

kyle-rb 1y ago

> 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.

watermelon0 1y ago
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.
kaoD 1y ago
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.
- oblio 1y ago
  That would have a better solution in a date.getCurrentMonth(), in my opinion.
  - kaoD 1y ago
    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/ https://tc39.es/proposal-temporal/docs/ [1] https://tc39.es/proposal-temporal/docs/plaindate.html#month https://tc39.es/proposal-temporal/docs/plaindate.html#month
- its_brass 11mo ago
  A [StackOverflow thread](https://stackoverflow.com/a/41992352 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.

6c696e7578 1y ago

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...

lucideer 1y ago

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.

MzHN 1y ago
> 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.
- lucideer 1y ago
  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.

marcosdumay 11mo ago

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.