jdc-pub

> Research into OAM has suggested that light waves could carry hitherto unprecedented quantities of data through optical fibres. According to preliminary tests, data streams travelling along a beam of light split into 8 different circular polarities have demonstrated the capacity to transfer up to 2.5 terabits of data (equivalent to 66 DVDs or 320 gigabytes) per second.[40]

> [40] https://www.bbc.co.uk/news/science-environment-18551284

Fun!

Like some other commenters, I do not understand why using a cached binary isn’t sufficient. Why not use the mold3 binary and build that first, and then cache it and never rebuild it again? I’m guessing it has to do with hermiticity and build provenance guarantees in your distro.

Do you have any reading material that you can share that might help me understand better? Docs for the distro, or an issue tracker I can search through?

It seems like you think AI will not replace artists/creatives, including creative writers, and I agree! I’ll say anecdotally, though, that the creative writers I know do believe AI generation to be an existential threat to their field. Not so much because they think machines can produce art at their caliber, but because they’re concerned that consumers of art won’t know or care about the difference.

I’m excited to be speaking about this topic at the Monktoberfest later this week.

I’m surprised at the current sentiment in the comments. Pangram is amazing and has really interesting engineering too. I would have guessed that reliably identifying LLM generated text was not possible without watermarks.

I’m very excited to see the great work ERSC has/will do. When thinking about where Git lags today, I’ve come up with three categories: UX features and custom data not natively understood by the Git CLI, a stock git-http-backend that doesn’t scale well to moderate monorepo size in server compute / storage, and a wire protocol that isn’t as flexible as it could be for special requests.

But there are so many hooks into the Git workflow today, and I’m struggling to find a “user story” that would not be met by custom Git tooling. UX could be added to Git objects à la Gerrit with custom CLIs, custom Gitoxide ODB and (eventually) ref storage backends can help the server scale, and things like promisor remotes and partial clones can keep things smaller on the client side.

I’m curious what ERSC is able to share publicly about where the scaling fails with the Git specification? Is it the wire format, or the relative speed of upstreaming new things to Git? Or is the side-channel approach for storing rich data in Git objects insufficient in some way?

P.S. I wrote a blog post[1] about this a bit ago. I’m sure I’m missing something. Since I wrote it, I’ve wondered if the lack of deferred conflicts in-tree would be a scaling limiter.

[1] https://jdc.pub/posts/git-jj

Huh, where does the “G” come from in RV64GC?

I haven’t dug into why, but for unknown-linux builds on x86, Rust binaries have been substantially smaller on musl than standard dynamic linking to glibc, for me. No idea if I’m doing something wrong or if the handful of cases I tried were all special in some way.

Do we know that Claude’s quirks are related to watermarking? The article said Gemini’s web console is apparently watermarked, and it has different quirks / a different sound.

I feel like Zed, rustup, and a lot of other applications (with CLIs) moved in that direction. (Hope someone corrects me if that’s wrong, unsure those projects are fully static, but they do self update.)

As a user that surprised me at first, but I’ve grown to really like it!

Looks like the figures are cut off?