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

91–100 of 165 posts

Re: Cursed Knowledge

#91

Post by burnt-resistor »

Install an SP3 or TR4 socketed CPU in a dusty, dirty room without ESD precautions and crank the torque on the top plate and heat sink like truck lug nuts until creaking and cracking noises of the PCB delaminating are noticeable. Also be sure to sneeze on the socket's chip contacts and clean it violently with an oily and dusty microfiber cloth to bend every pin.

c. 2004 and random crap on eBay: DL380 G3 standard NICs plus Cisco switches with auto speed negotiation on both sides have built-in chaos monkey duplex flapping.

Google's/Nest mesh Wi-Fi gear really, really enjoys being close together so much that it offers slower speeds than simply 1 device. Not even half speed, like dial-up before 56K on random devices randomly.

Re: Cursed Knowledge

#92

Post by out_of_protocol »

kstrauser wrote: post #29
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.

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

> So 11/27/2025 starts with the most useful information

Most useful information would be to not confuse it. E.g. you see a event date 9/8/2025 and it's either tomorrow or a month from now. Perfect 50/50% chance to miss it or make a useless trip

Re: Cursed Knowledge

#93

Post by burnt-resistor »

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…

Or people who try to send every filename on a system through xargs in a single command process invocation as arguments (argv) without NUL-terminated strings. Just hope there are no odd or corrupt filenames, and plenty of memory. Oopsie. find -print0 with parallel -0/xargs -0 are usually your friends.

Also, sed and grep without LC_ALL=C can result in the fun "invalid multibyte sequence".

Re: Cursed Knowledge

#94

Post by eadmund »

antonvs wrote: post #78
fdr wrote: post #50

Earlier quoted context omitted.

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. Java developers: hold my beer

Hey, if I don’t name this class AbstractBeanFactoryVisitorCommandPatternImplementorFactoryFactoryFactorySlapObserver how would you know what it does?

Re: Cursed Knowledge

#95

Post by AstralStorm »

Havoc wrote: post #83

One can really sense the pain just reading the headings Also a crypto library that limits passwords to 72 bytes? That’s wild

It's written with constant memory allocation in mind. Silly of them to use such a small buffer though, make it a configuration option.

Re: Cursed Knowledge

#96

Post by motorest »

delusional wrote: post #90
simpaticoder wrote: post #22

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

I agree, I usually put this sort of information in the commit message itself. That way it's right there if anybody ever comes across the line and wonders "why did he write this terrible code, can't you just ___".

As a side note, it's becoming increasingly important to write down this info in places where LLMs can access it with the right context. Unfortunately commit history is not one of those spots.

Re: Cursed Knowledge

#97

Post by motorest »

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…

> This is a cursed idea to begin with, so I can't fully blame PostgreSQL.

After going through the list, I was left with the impression that the "cursed" list doesn't really refers to gotchas per se but to lessons learned by the developers who committed them. Clearly a couple of lessons are incomplete or still in progress, though. This doesn't take away from their value of significance, but it helps frame the "curses" as persona observations in an engineering log instead of statements of fact.

Re: Cursed Knowledge

#98

Post by motorest »

Havoc wrote: post #82
bikeshaving wrote: post #21

Earlier quoted context omitted.

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…

Forgive my ignorance of js matters but how does adding packages improve backward compatibility at all?

> Forgive my ignorance of js matters but how does adding packages improve backward compatibility at all?

The scheme is based on providing polyfills for deprecated browsers or JavaScript runtimes.

Here is the recipe.

- check what feature is introduced by new releases of a browser/JavaScript runtime,

- put together a polyfill that implements said feature,

- search for projects that use the newly introduced feature,

- post a PR to get the project to consume your polyfill package,

- resort to bad faith arguments to pressure projects to accept your PR arguing nonsense such as "your project must support IE6/nodejs4".

Some projects accept this poisoned pill, and whoever is behind these polyfill packages further uses their popularity in bad faith arguments ("everyone does it and it's a very popular package but you are a bad developer for not using my package")

I had the displeasure of stumbling upon PRs where tis character tries to argue that LTS status does not matter at all I'm determining whether a version of node.js should be maintained, and the fact that said old version of node.js suffers from a known security issue is irrelevant because he asserts it's not a real security issue.

Re: Cursed Knowledge

#99

Post by whilenot-dev »

motorest wrote: post #84
whilenot-dev wrote: post #74

Earlier quoted context omitted.

A package "for-each"[0] that depends on a package "is-callable"[1], just to make forEach work on objects? Nope, not buying the goodwill here. [0]: https://www.npmjs.com/package/for-each [1]: https://www.npmjs.com/package/is-callable

Older browsers don't support foreach, so it's not like a polyfill is unheard of https://caniuse.com/?search=foreach

Are you serious here? It isn't a polyfill, it's supposed to work on plain objects which isn't part of the spec at all. Besides that, Array.prototype.forEach is only unsupported in Android Browser 4.3 (from July 2013) and IE8 (from May 2008). Seems like a weird reasoning to add it to packages in 2025.

Re: Cursed Knowledge

#100

Post by Sammi »

karel-3d wrote: post #62
bikeshaving wrote: post #21

Earlier quoted context omitted.

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…

to save everyone else a search, it's probably ljharb. (I am not a member of JS community, so, come and attack me.)

Saga starts here:

https://x.com/BenjaminMcCann/status/1804295731626545547?lang...

https://github.com/A11yance/axobject-query/pull/354

Specifically Ben McCann along with other Svelte devs got tired of him polluting their dependency trees with massive amount of code and packages and called him out on it. He doubled down and it blew up and everyone started migrating away from his packages.

ljharb also does a lot of work on js standards and is the guy you can thank for globalThis. Guy has terrible taste and insists everyone else should abide by it.

Post reply on HN