Hacker News: fc417fc802

New comment by fc417fc802 in "OpenAI discloses four more rogue incidents"

fc417fc802 — Sat, 17 Oct 2026 20:44:40 +0000

So your position is that in the past the government mistreated various individuals thus you also want the government to mistreat openai employees today? That hardly seems reasonable.

New comment by fc417fc802 in "OpenAI discloses four more rogue incidents"

fc417fc802 — Sat, 17 Oct 2026 20:40:04 +0000

It's on you to provide evidence here seeing as you're taking the position that the law places certain responsibilities on people. Someone saying "actually the law doesn't say that" can't (at least in general) reasonably be expected to provide evidence of a negative. (That said, he actually did provide such as refutation to a different comment so perhaps you could just read those nearby?)

New comment by fc417fc802 in "OpenAI discloses four more rogue incidents"

fc417fc802 — Sat, 17 Oct 2026 20:33:30 +0000

If the breach wasn't intentional, no person came to immediate personal harm, and either no financial damages resulted or the operator covered any that did, then it isn't clear to me why the law would need to "advance" to transform something apparently benign into a criminal offense.

New comment by fc417fc802 in "OpenAI discloses four more rogue incidents"

fc417fc802 — Sat, 17 Oct 2026 20:26:13 +0000

That's okay. It isn't necessarily incompatible with being well intentioned regarding the disclosure of vulnerabilities.

On the whole I think you could describe the local big box grocery store as just wanting to make money yet as a direct result of that they are well intentioned from my perspective with regard to the food they sell being edible.

New comment by fc417fc802 in "Making chicken transparent using Dorito dust"

fc417fc802 — Sat, 17 Oct 2026 19:28:15 +0000

It's only a fallacy in the same way that the slippery slope is a fallacy, ie when used as a logical basis in and of itself. There's nothing wrong with either one when used appropriately in context.

New comment by fc417fc802 in "You could have invented transformers from memory"

fc417fc802 — Sat, 17 Oct 2026 18:58:57 +0000

I'm not exactly disagreeing with that statement though. I'm claiming that it additionally carries the implication of the reader being a member of that set while alternative turns of phrase don't.

Where it gets tricky is that the reader might not be part of the audience intended by the writer.

New comment by fc417fc802 in "eBay Restricts Listings of Radio Equipment, but Exempts Ham-Band-Only Gear"

fc417fc802 — Sat, 17 Oct 2026 09:53:35 +0000

On what basis do you claim that computer hackers don't generally want to be "good citizens"? I'd counter that HAM is full of people who worship bureaucracy legal compliance, which is almost the philosophical antithesis of the hacker crowd. The hobbyist drone hardware community seems to have a lot of that nonsense as well. (Granted sufficiently over the top recklessness regarding the latter actually has the possibility of killing people so at least the aviation crowd has a fig leaf in that regard.)

New comment by fc417fc802 in "You could have invented transformers from memory"

fc417fc802 — Sat, 17 Oct 2026 09:34:54 +0000

> You also criticized the article for.

> What this mostly comes down to is your misunderstanding of the breadth of our community

Actually I think it's the people responding to him that aren't being sufficiently careful to read what he actually wrote and to understand the message he was attempting to convey. Granted he could have done a better job communicating (case in point, this very conversation) but that's often going to be the case.

It seems like people are interpreting it in a hostile manner when from my perspective the core of it is both actionable and reasonable feedback for anyone attempting to explain a technical topic. Both of the original points (using mathematical notation and failing to step through concrete examples) are each things that will alienate a decent chunk of any potential audience. In fact the former is one of my primary complaints about wikipedia articles on math adjacent topics.

New comment by fc417fc802 in "You could have invented transformers from memory"

fc417fc802 — Sat, 17 Oct 2026 09:20:07 +0000

> For example, if I posted to HN a link to a really good cookie recipe, it wouldn't be a good fit for this site.

Going to have to disagree with you here. That would very much depend on the particulars of and circumstances surrounding the recipe. This is a site for anything that would interest the typical hacker (whatever that actually is) after all.

New comment by fc417fc802 in "You could have invented transformers from memory"

fc417fc802 — Sat, 17 Oct 2026 09:15:31 +0000

But it does? It's generic, meaning you the reader are fully interchangeable with other possible subjects. At least that's the connotation it carries for me, and for what it's worth I'm a native speaker. If the reader (ie the target audience from the author's perspective) isn't interchangeable then I'd expect some other article to be used (ex they, the relevant professional, an interested party, etc).

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Sat, 17 Oct 2026 00:47:43 +0000

I dunno, if a library author is toggling flags that control the nature of the end user's build that seems like tempting fate to me. How do you justify such interference?

To my mind the extent of the contract is that if the user has set NDEBUG then you can assume that assert will be a noop. I don't think you as a library author can make any assumptions about what happens if you set the flag yourself.

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Sat, 17 Oct 2026 00:41:19 +0000

So basically you didn't bother to look and then blindly declared it an anti-practice?

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Sat, 17 Oct 2026 00:39:02 +0000

I don't see how. It's certainly not encouraged but then I'm doing it to work around the bad practice of others so what do you expect?

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Fri, 16 Oct 2026 08:10:20 +0000

I don't see why. The user invoking the compiler should be the only one controlling NDEBUG (or its equivalent). So far the only bad idea I've run into is the occasional library author blindly importing assert.h which happily stomps all over my custom implementation.

There's a whole host of things that libraries need to be extremely conservative about touching. Assert, threads, signals, etc.

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Fri, 16 Oct 2026 02:04:23 +0000

It's literally standard practice. You import assert.h unless the end user has defined mylib_assert in which case you don't import and use that instead. Failing to do this can result in all kinds of dumb problems thanks to the namespace being global.

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Fri, 16 Oct 2026 02:00:08 +0000

Just because you can easily understand something doesn't mean it isn't a footgun.

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Fri, 16 Oct 2026 01:51:28 +0000

For my own code I generally -Wall -Werror and if that breaks a prospective dependency in a nontrivial manner I find a replacement. I'll also tend to go looking for a replacement if a prospective dependency breaks when compiled with either asan or ubsan. Why would I voluntarily subject myself to such shoddy code?

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Fri, 16 Oct 2026 01:44:28 +0000

This is why in my own code I define macros assume and require. The former documents assumptions, asserts for debug builds, and calls __builtin_unreachable for production builds. The latter documents validated requirements, always runs, and is guaranteed to produce a core dump if violated.

Nomenclature is important.

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Fri, 16 Oct 2026 01:32:04 +0000

No, it's not. Don't do that. Someone (like me) will replace assert.h wholesale and it will not behave the way you expected. Always define your own internal macro and always provide facilities for the user to override it.

New comment by fc417fc802 in "C++26 Contracts: Introduction to Preconditions and Postconditions"

fc417fc802 — Fri, 16 Oct 2026 01:29:09 +0000

I don't know if it's good practice but I replace assert and assert.h with my own code (you just have to make sure to make the necessary platform specific calls in your replacement headers). So I always know exactly how assert will behave in my own codebase even when invoked by a library.

It's worth noting that the motivation for the above was poorly written libraries that hardcode the use of the builtin assert. So I agree with you completely on that point.

That said I've never been particularly impressed with how assert is defined by the standard and now somehow contracts appear set to be even worse.