• 0 Posts
  • 26 Comments
Joined 3 years ago
cake
Cake day: June 12th, 2023

help-circle

  • That doesn’t follow. What I think you mean is that by defining the constraints so rigorously, you’ve basically solved the problem yourself. But that’s exactly the point. The LLM isn’t the problem solver, it’s the execution engine that does the wiring-up and the ticking of boxes. The easy part, arguably, sure. But still considerable effort that can be saved, and that effort may be better spent on the problem-solving + constraint-defining stage.

    Mandatory disclaimer that this is not a pro-AI post. I also don’t agree that this setup works, anyway. It’s a classic Bob Martinism, the idea that writing good enough specifications makes the implementation irrelevant; it’s the type of idea that is allergic to reality
















  • I don’t think the changes in question are “upholding” any law, but rather giving system admins and software devs a convenient/predefined way to attempt to comply with the law if they choose. “Upholding” the law would be requiring the field to be filled or checked.

    That said, to your point, if someone proposed a race field “so that devs can implement segregation if they choose,” I’d find that reprehensible even though it doesn’t do anything on its own. Similarly, I object to the systemd change.


  • Do you think that would prevent or discourage age verification software from existing? It’s not as if a systemd user field is the only place a user’s birthday could be stored.

    Realistically, age verification software that is seriously attempting age verification isn’t even going to touch the systemd field, because why would it? The field could only be trusted if it is managed by an age verification service anyway, in which case the service could just as easily store the data outside of systemd.