Hacker News: Denvercoder9

New comment by Denvercoder9 in "The threat is comfortable drift toward not understanding what you're doing"

Denvercoder9 — Sun, 05 Apr 2026 19:42:23 +0000

There's no contradiction, the point is that Bob is able to produce valid output using LLMs, but only while he himself is being supervised; and that he doesn't develop the skills to supervise independently himself in the future.

New comment by Denvercoder9 in "Loss32: Let's Build a Win32/Linux"

Denvercoder9 — Wed, 31 Dec 2025 13:35:50 +0000

> That's why it went beyond web, and why all modern native UI frameworks have a similar model these days.

It's more the other way around, this model started on desktop (eg WPF) and then React popularized it on the web.

New comment by Denvercoder9 in "Loss32: Let's Build a Win32/Linux"

Denvercoder9 — Wed, 31 Dec 2025 13:30:19 +0000

> It would be infinitely simpler if one could simply 'cross-compile' down to older symbol versions, but the tooling does not make this easy at all.

It's definitely not easy, but it's possible: using the `.symver` assembly (pseudo-)directive you can specify the version of the symbol you want to link against.

New comment by Denvercoder9 in "Loss32: Let's Build a Win32/Linux"

Denvercoder9 — Wed, 31 Dec 2025 13:26:33 +0000

> why would it be that way?

It allows (among other things) the glibc developers to change struct layouts while remaining backwards compatible. E.g. if function f1 takes a struct as argument, and its layout changes between v2 and v3, then glibc_v2_f1 and glibc_v3_f1 have different ABIs.

New comment by Denvercoder9 in "NYC Mayoral Inauguration bans Raspberry Pi and Flipper Zero alongside explosives"

Denvercoder9 — Wed, 31 Dec 2025 01:26:08 +0000

The same's true for the radio on a Raspberry Pi, though.

New comment by Denvercoder9 in "Everything as code: How we manage our company in one monorepo"

Denvercoder9 — Wed, 31 Dec 2025 01:24:16 +0000

So yes, in theory you can always deploys sets of compatible services, but it's not really workable in practice: you either need to deploy the world on every change, or you need to have complicated logic to determine which services are compatible with which deployment sets of other services.

There's a bigger problem though: in practice there's almost always a client that you don't control, and can't switch along with your services, e.g. an old frontend loaded by a user's browser.

New comment by Denvercoder9 in "NYC Mayoral Inauguration bans Raspberry Pi and Flipper Zero alongside explosives"

Denvercoder9 — Tue, 30 Dec 2025 23:30:04 +0000

Some smartphones are locked down by their vendors. There's plenty of options to get full root access on something that's for all intents and purposes a smartphone, especially if you don't particularly care about warranty and/or keeping commerical apps functional.

New comment by Denvercoder9 in "Everything as code: How we manage our company in one monorepo"

Denvercoder9 — Tue, 30 Dec 2025 23:24:56 +0000

Maybe the database upgrade from v(N-17) to v(N-16) simply takes a while, and hasn't completed yet? Or the responsible team is looking at it, but it doesn't warrant the whole company to stop shipping?

Being 17 versions behind is an extreme example, but always having everything run the latest version in the repo is impossible, if only because deployments across nodes aren't perfectly synchronised.

New comment by Denvercoder9 in "Everything as code: How we manage our company in one monorepo"

Denvercoder9 — Tue, 30 Dec 2025 23:13:48 +0000

https://github.com/jj-vcs/jj

New comment by Denvercoder9 in "Everything as code: How we manage our company in one monorepo"

Denvercoder9 — Tue, 30 Dec 2025 23:11:35 +0000

Blue/green might allow you to do (approximately) atomic deploys for one service, but it doesn't allow you to do an atomic deploy of the clients of that service as well.

New comment by Denvercoder9 in "Everything as code: How we manage our company in one monorepo"

Denvercoder9 — Tue, 30 Dec 2025 23:04:06 +0000

> Good luck getting 100+ devs to all use the same logical commit style

The Linux kernel manages to do it for 1000+ devs.

New comment by Denvercoder9 in "Everything as code: How we manage our company in one monorepo"

Denvercoder9 — Tue, 30 Dec 2025 23:02:12 +0000

If my change is small enough that it can be treated as one logical unit, that will be reviewed, merged and (hopefully not) reverted as one unit, all these followup commits will be amends into the original commit. There's nothing wrong with small changes containing just one commit; even if the work wasn't written or committed at one time.

Where logical commits (also called atomic commits) really shine is when you're making multiple logically distinct changes that depend on each other. E.g. "convert subsystem A to use api Y instead of deprecated api X", "remove now-unused api X", "implement feature B in api Y", "expose feature B in subsystem A". Now they can be reviewed independently, and if feature B turns out to need more work, the first commits can be merged independently (or if that's discovered after it's already merged, the last commits can be reverted independently).

If after creating (or pushing) this sequence of commits, I need to fix linting/formatting/CI, I'll put the fixes in a fixup commit for the appropriate and meld them using a rebase. Takes about 30s to do manually, and can be automated using tools like git-absorb. However, in reality I don't need to do this often: the breakdown of bigger tasks into logical chunks is something I already do, as it helps me to stay focused, and I add tests and run linting/formatting/etc before I commit.

And yes, more or less the same result can be achieved by creating multiple MRs and using squashing; but usually that's a much worse experience.

New comment by Denvercoder9 in "Everything as code: How we manage our company in one monorepo"

Denvercoder9 — Tue, 30 Dec 2025 21:07:56 +0000

Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.

New comment by Denvercoder9 in "Text rendering hates you (2019)"

Denvercoder9 — Sun, 28 Dec 2025 00:43:19 +0000

The article is from 2019, things might also simply have changed since then.

New comment by Denvercoder9 in "Archiving Git branches as tags"

Denvercoder9 — Thu, 25 Dec 2025 23:48:10 +0000

That's true for local hooks, but neither a dishonest person nor an LLM can bypass a pre-receive hook on the server (as long as they don't have admin access).

New comment by Denvercoder9 in "NIST was 5 μs off UTC after last week's power cut"

Denvercoder9 — Tue, 23 Dec 2025 00:59:29 +0000

GPS gets its time from NIST (though during this incident they failed over to another NIST site, so it wasn't impacted).

New comment by Denvercoder9 in "Getting bitten by Intel's poor naming schemes"

Denvercoder9 — Fri, 19 Dec 2025 17:38:04 +0000

> you'll encounter a box running a distro version from before /etc/os-release became the standard

Do those boxes really still exist? Debian, which isn't really known to be the pinacle of bleeding edge, has had /etc/os-release since Debian 7, released in May 2013. RHEL 7, the oldest Red Hat still in extended support, also has it.

New comment by Denvercoder9 in "Avoid UUID Version 4 Primary Keys in Postgres"

Denvercoder9 — Mon, 15 Dec 2025 12:25:29 +0000

This misses the point. The reason not to use UUIDv4 is that having an index on random values is slow(er), because sequential inserts into the underlying B-tree are faster than random inserts. You're hitting the same problem with your `public_id` column, that it's not the primary key doesn't change that.

New comment by Denvercoder9 in "Capsudo: Rethinking sudo with object capabilities"

Denvercoder9 — Sat, 13 Dec 2025 13:16:28 +0000

> you have /dev/kmem access so could just edit the kernel data structures.

Not anymore: since kernel 2.6.26 /dev/kmem only exists if CONFIG_DEVKMEM is enabled, and it was removed completely in 5.13.

[1] https://lwn.net/Articles/851531/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

New comment by Denvercoder9 in "You can't fool the optimizer"

Denvercoder9 — Wed, 03 Dec 2025 22:00:29 +0000

Yes, so that's why the compiler can't and doesn't emit the optimized version if you write the short circuited version - because it behaves differently for short strings.