Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cursed Knowledge

immich.app

Post reply on HN
Print view View original

41–50 of 165 posts

Re: Cursed Knowledge

#41

Post by FridgeSeal »

Izkata wrote: post #17
dmd wrote: post #14

Earlier quoted context omitted.

in what world could mm/dd/yyyy not be cursed!? that makes no sense whatsoever.

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.

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.

Re: Cursed Knowledge

#42

Post by mdaniel »

joshdavham wrote: post #36

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

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:

  $ echo yup > README.txt
  $ cat ReAdMe.TXT
  yup
  $ ls
  README.txt
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

Re: Cursed Knowledge

#43

Post by hollerith »

dmd wrote: post #23
Izkata wrote: post #17

Earlier quoted context omitted.

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.

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.

Can you explain why on a traffic light, red means stop and green means go? Why not the other way around?

Re: Cursed Knowledge

#45

Post by csours »

You can load Java Classes into Oracle DB and run them natively inside the server.

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.

Re: Cursed Knowledge

#46

Post by fc417fc802 »

Aurornis wrote: post #32
steve_adams_86 wrote: post #13

Earlier quoted context omitted.

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 strip…

> 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-ima…

Not per-image, it would be per-app. The first time it happened it would ask you. There are already quite a few per-app toggles for things like this so it wouldn't be anything new or particularly surprising.

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.

Re: Cursed Knowledge

#47

Post by fc417fc802 »

hollerith wrote: post #43
dmd wrote: post #23

Earlier quoted context omitted.

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.

Can you explain why on a traffic light, red means stop and green means go? Why not the other way around?

Because it's arbitrary. Unlike a date format where the components have relative meaning to one another, can be sorted based on various criteria, and should smoothly integrate with other things.

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.

Re: Cursed Knowledge

#48

Post by e1g »

qdw wrote: post #35

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…

Another strategy is to pass your values as an array param (e.g., text[] or int[] etc) - PG is perfectly happy to handle those. Using ANY() is marginally slower than IN(), but you have a single param with many IDs inside it. Maybe their ORM didn’t support that.

Re: Cursed Knowledge

#49

Post by kirici »

burnt-resistor wrote: post #27

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

>opt-out telemetry: go

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
To completely disable telemetry, including local collection, run:

    go telemetry off
https://go.dev/doc/telemetry

Re: Cursed Knowledge

#50

Post by fdr »

qdw wrote: post #35

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…

that also popped out at me: binding that many parameters is cursed. You really gotta use COPY (in most cases).

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.

Post reply on HN