HN user

davisp

171 karma
Posts0
Comments73
View on HN
No posts found.

If I build a Markov chain based on a statistical analysis of word sequences in Hamlet, and then use it to produce a new sentence that isn't found in the text of that work, I have not created a derivative work of Hamlet under any applicable sense of that term.

Uh, that is exactly what a derivative work is. You literally specify that Hamlet is an input to your work. I believe you're conflating derivative with transformative. You're certainly creating a transformative derivation of Hamlet, but you are by definition creating a derivative work by training a Markov chain on the text of Hamlet.

The obvious follow up here is whether an LLM is creating transformative derivations or not. A lot of folks argue that yes, an LLM spitting out statistically sampled code that matches existing code is not transformative and is (or might be) infringing the terms of the license it was released under. Others argue that there's not an exact copy of the original source in the LLM's weights so by definition it must be a transformative work. I think it's a pretty obvious "somewhere in the middle" that is gonna make a bunch of lawyers a whole lot of money.

Personally, I don't care one way or the other. I'm one of the folks that thinks software shouldn't be copyright-able in the first place.

I’m gonna give this a very charitable read by saying that while I find the ways that the treatment of burn victims was advanced by abhorrent means, we as a society have still benefited from those means.

So once the model is created there isn't a good reason to encumber it by how it was created.

I am trying to be very specific here. I assume no untoward motivations from the parent commenter. I am not intending to cast aspersions. Whoever wrote this, I feel no ill will for you and this is not meant as a personal slight.

And I will be very clear, this statement as written could probably be defended because of the “by how it was created” clause.

However, “So once the model is created there isn’t a good reason to encumber it” is so… fucking I don’t even know, because what the actual fuck?

I apologize for the profanity, I really do. But, really? Are you fucking kidding me?

These models should not exist. Ever. By any means. Do not pass Go. Go directly to jail.

I understand the engineering brain enough to contemplate abstract concepts with detachment. That’s all I think happened here. But holy fuck, please pause and consider things a bit.

So there's a bit of a misunderstanding here in the chain of blog posts that I can clear up. First, from this article:

  That’s the question I’ve been mulling over for days, because
  I don’t see how this action can make any particular guarantees
  about durability, at least not in any portable way.
This part is super easy to clear up. CouchDB in no way relies on an fsync after open for any guarantee on durability. As shown in [1], CouchDB has been running an fsync on file open since extremely early in its development. However, I can easily see how just reading the Neighbourhoodie article would lead here.

The missing context is that CouchDB primarily fsync's after open because when an empty database is created, we write a header to disk. The very early implementation in [1] just didn't limit this to only cases where we write the header and that general behavior has never been changed (though the implementation is a bit different today, the effect is the same).

Also, in hindsight, I believe this claim in the Neighbourhoodie is probably too strong:

  However, CouchDB is not susceptible to the sad path.
I didn't read the article super closely the first time since I'd been through the background discussions on the finer details, but today I'd probably hedge that a bit with language along the lines of:
  However, CouchDB is *probably* not susceptible to the sad
  path. While we can't guarantee it can't happen due to how
  various I/O operations are (not) specified, we're doing as much
  as we can to prevent it. Also, don't forget that your storage
  device might be lying about fsync anyway.
The underlying logic around that requires considering the original blog post in this chain [3]. That article posits a pathological error condition where we write something, crash, restart, issue read from a dirty page cache, and then hard crashing the entire machine. In this case, the database returned a read that was never committed.

As the author of this (as in this thread) article notes:

  Using OpenZFS as an example (hey, it’s what I know), fsync()
  always flushes anything outstanding for the underlying object,
  regardless of where the writes came from.
AFAIK, this is the norm and, I assume, the reason that the NULL BITMAP article [3] suggests the fsync on open. In CouchDB land, we just went back and said, "Oh nice, we already do that for other reasons anyway." Unfortunately the "we already do it for other reasons" aspect didn't really come through. So in the end, while none of the behavior on fsync-on-open is guaranteed in anyway shape or form, it's not impossible that it's saved our bacon a non-zero number of times. Just because its not guaranteed, its common that filesystems will in fact perform those flushes regardless of which file descriptor is used.

Also, to make sure that we're not missing the field for the cornstalks, I want to point out that the double fsync commit protocol used by CouchDB is probably 99.some-more-nines responsible for CouchDB's durability guarantees. However, that's not 100%, so when we find weird edge cases like in [3] we try and make sure that we're as correct as can be. For instance, here's the response to fsync-gate [4].

[1] https://github.com/apache/couchdb/blob/956c11b35487fb8ffcf70...

[2] https://neighbourhood.ie/blog/2025/02/26/how-couchdb-prevent...

[3] https://buttondown.com/jaffray/archive/null-bitmap-builds-a-...

[4] https://github.com/apache/couchdb/commit/3505281559513e29224...

I'm no rustc expert, but from what little I know it seems like disabling panics for a crate would be an obvious first step. You make a great point though. Turning that into a compiler assertion of "this function will never panic" would also be useful.

What caught my eye in the article was the desire to have something that doesn't panic with a release profile, while allowing for panics in dev profiles. Based on other comments I think the general "allow use of std, but don't panic" seems like something that could be useful purely on the "Wait, why doesn't that exist?" reactions.

Absolutely correct! Had the bird strike not occurred, there wouldn’t have been a crash. Had things with the go around been handled properly, there would have been no crash.

Etc etc. The fact that a wall was 50m out of compliance or whatever it ends up being will be a footnote at best in the review of this crash.

Distributed Erlang 2 years ago

That’ll just depend on whatever code was deployed to the cluster. For the clusters I used to operate, the answer would be absolutely all nodes talk to all nodes all the time.

I personally never operated anything above roughly 250 nodes, but that limit was mostly due to following the OP’s advice about paying attention to the configuration of each node in the cluster. In my case, fewer nodes with fancier and larger raid arrays ended up being a better scaling strategy.

Distributed Erlang 2 years ago

If you actually have 1000 nodes worth of work, the heartbeats are not at all a big deal.

I think you’re missing the fact that the heart beats will be combined with existing packets. Hence the quoted bit. If you’ve got 1000 nodes, they should be doing something with that network such that an extra 50 bytes (or so) every 30s would not be an issue.

Most likely those are just the states where they already have a tax presence. For whatever reason they happen to currently employ folks in those states so adding employees is easy. Adding new states means getting lawyers and CPA type folks involved which is a hurdle to hiring in larger organizations.

Engineering Sleep 2 years ago

A wild tangent but reading “heritable metabolizing” really hit me on the “are viruses alive” question.

I’ve been around enough biotech to have considered the differences between plasmids and viruses versus archaea, bacteria, and eukaryotes. I’ve always considered “heritable change” as the base definition of “life”. As in, “life” is progeny resemble their parent(s)? Or “heritable change”.

“Heritable metabolizing” quite nicely captures that difference between the levels of single molecule “life” and singular/multicellular “life”.

Apologies for the random aside, it was just one of those random “I have a vague idea of why mitochondria are important, but I don’t see them as fundamental” parts of my “What is life?” definition being refined.

Sometimes science doesn’t have to be precise to demonstrate a result.

Consider trying to measure feedback from a microphone and speaker. You don’t have to be an expert to know that there’s a quick change in system behavior when the microphone gets too close to the speaker.

This matches my experience. I spent a decade operating Erlang clusters and using hot code upgrades is a superpower for debugging a whole class of hard to track bugs. Although, without the tracking for cluster state it can be its own footgun when a hotpatch gets unpatched during a code deploy.

As for relups, I once tried starting a project to make them easier but eventually decided that the number of bazookas pointed at each and every toe made them basically a non-starter for anything that isn’t trivial. And if its trivial it was already covered by the nl (network load, send a local module to all nodes in the cluster and hot load it) style tooling.

Introductory summary: The current scientific consensus is that the placebo effect is a real healing effect operating through belief and suggestion.

I have no idea what the rest of the article says because this single sentence is so bat shit insane on so many levels.

The placebo effect is not “real healing”, it’s “our study is unable to show a statistically relevant result from our treatment”.

I’m not big on LLMs personally, so I won’t make any specific claims on what they can do. But from what I’ve read, I’d doubt they’d correct that mistake.

On the flip side, I would trust an LLM to tell me whether it should have been “batshit”, “bat-shit”, or “bat shit”.

I made it through a few paragraphs before noping out because of how terrible this article is. Your comment made me go actually look to see what they could possibly be arguing against CICO. Turns out it’s nothing because this author has no idea how science or biology works.

We can all argue about what makes a calorie “good” or “bad” but CICO is basic thermodynamics. A calorie is a unit of energy. If a cell doesn’t have enough energy, it dies.

Sorry for mildly ranting at idiocy on the internet via your comment, sodality2.

You can make a video, but odds are it won’t be good or get traction. I think you’re better off with a book. Books can remain indexed and accumulate readers for centuries, whereas most videos are forgotten/ignored. I’ve read plenty of books from decades ago that still get lots of comments and discussion.

Also, for anyone not completely familiar with Erlang's terminology, the translation of "per process garbage collection" to Go would be "per goroutine garbage collection". As mentioned in a sibling comment, this allows Erlang style garbage collection to avoid pausing the entire operating system process when running garbage collectin.

FWIW, I’ve been working on a project that has transitioned from a standard-ish CMake super build to vcpkg and it has been a fantastic upgrade in terms of usability and reliability.

There are huge swaths of the C++ lands map I’ve not visited, so I’m sure there are areas where it wouldn’t be a good choice, but I personally think vcpkg has been great.

Information leakage since they have a timestamp component. Some people may not care, but plenty of folks do. As others have said, anything security related likely should UUIDv4. UUIDv7 is basically an engineering compromise on security (they leak a timestamp) vs performance (random reads and writes to an index aren’t as performant as localized reads and writes).

Worrying about UUID collisions is like worrying about being hit in the head by a meteor. Sure, its technically possible, but it happens so rarely that worrying about a collision as a performance concern is just a misunderstanding on how UUIDs work.

And, it’s so random that if you ever do see a collision you should immediately start looking for a compromised system or bug. This is basically how GitHub discovered the OpenSSL bug that had removed too much entropy from the RNG setup.

Royal Road is a place for a lot of folks to get audiences seeded before they inevitably move on to some combination of Patreon, Amazon Kindle Unlimited, and Audible.

One very notable example of this is Dungeon Crawler Carl by Matt Dinniman. He's even just announced that he managed to sell publishing only rights to Ace for large scale distribution which to my knowledge is a first (from authors that started on Royal Road).

https://x.com/mattdinniman/status/1780998536529883622

Also, I'd highly recommend reading Dungeon Crawler Carl if you enjoy anything close to Douglas Adams-esque comedic sci-fi. Its definitely trends a lot more "adult" than Douglas Adams, but that's about as close as I can think of off the top of my head for comparison. And I'd very much recommend the Audible versions narrated by Jeff Hayes for anyone that does audio books. The Sound Booth Theater production is also good but I'd only recommend that if you're doing a re-listen.

I never learned Elixir, but my first guess is IO.inspect is sending a message that is printed by a different process. Then the prints after exit are just the IO process working through its mailbox.

Alternatively, the await might killing the waiting process, not the process being waited on.

From the article:

That means it's totally normal to ship all kinds of really crazy looking stuff, and so when someone noticed that and decided to use that as their mechanism for extracting some badness from a so-called "test file" that was actually laden with their binary code, is it so surprising that it happened? To me, it seems inevitable.

Yeah, no. The author is well aware of how and why autotools are not awesome but also with the background of why they exist.

A better argument can be made that the act of compiling a binary / obfuscating / minifying code instead of interpreting code directly is the fault.

I can’t decide if you’ve never worked in systems software or trying to be hyperbolic. Given that it’s HN I’ll assume the best. But who do you think would do the interpreting? The priests at Delphi?

One more feature request is a “share score” text. Daily games like these are popular for bragging rights in group texts.

I’d think something like percentage of song played before correct with total number of guessed would cover it.

Who are these companies that either require a non-personal Apple Id or forbid a personal Apple Id? I’ve worked for startups and multinationals and never had an issue with my work machine allowing a personal Apple Id.

Obviously I have to be personally ok with allowing work possible access to my Apple Id, but for me it’s an acceptable trade off given that they have access to everything I say on Slack, and if we’re being honest, that’s the where the “HR needs a word” is gonna come from.

This is an awesome point related to the post I just made as a sibling comment. Solar energy is cheap! The sun blasts us with whatever crazy number real energy folks know by heart. The issue is after we collect it, how do we move it?

If you’ve read Project Hail Mary, the sci-fi part isn’t collecting energy, its the lossless transport.

Hopefully that’s not a spoiler.

We could, but it would certainly be less efficient than other approaches. I haven’t seen it brought up recently but there’s a simple quote that makes it easy to evaluate any sort of energy related discussion based on the laws of thermodynamics:

“You can’t win, you can’t break even, and you can’t quit the game.” - C.P. Snow [1] (No idea if that’s the correct attribution, I heard it from a professor 20 years ago)

My personal shorthand for this is to focus on the efficiencies of energy transformation and transport. Converting or moving energy means we lose some fraction of the total energy. All we can do is minimize that fraction.

The main point being that with that mental framework, I can easily assume that your posited approach won’t be more efficient than a solar panel or some other process with fewer transformation steps because each step magnifies energy loss inefficiencies.

Basically, the entirety of the energy debate is two things: How can we harvest energy cheaply and move it with minimal waste.

This is the basis for the whole room temp superconductor story that captured a bunch of our nerd imaginations, what happens if you get super close to zero energy loss while moving electrons?

Also, one more thing to keep in mind is constraints. Your proposed solution may be way more efficient by some metric if we change the constraints. For instance, my brain mostly goes to transportation which is transport and storage with immediate demand requirements. However, if our requirements were different along the lines of “lets store as much energy as possible over months, to slowly release it over months”, inefficiencies of scale change things. Then maybe slowly moving water uphill during summer while releasing slowly during winter is a valid thing to consider [2].

[1] https://gohighbrow.com/laws-of-thermodynamics/

[2] https://medium.com/drax/how-to-turn-a-mountain-into-a-giant-...