I find it extra funny that you think copyright protect small time authors and artists, when we have _very clear_ examples of it not protecting them for shit, even before the entire IA saga. Remember the Disney/Star Wars saga where they refused to pay the Star Wars author for the books they were selling?
Copyright doesn't protect small-time authors - because small-time authors don't have the means to harness the legal system to their advantage the way that big corpos that take advantage of them do.
I don’t necessarily disagree, but by that same logic we shouldn’t have any civil laws because regular people can’t afford to hire lawyers to sue people.
But still, if someone posts a copy of your book or painting online, you can pretty cheaply file a DMCA request that it be taken down, and most large players will comply. If you throw out copyright law altogether, you get rid of that too.
> But still, if someone posts a copy of your book or painting online, you can pretty cheaply file a DMCA request that it be taken down, and most large players will comply. If you throw out copyright law altogether, you get rid of that too.
Good, get rid of copyright law! It has only lead to pure rent seeking.
Authors and artists have no basis for payment in the absence of copyright laws. Like, anything they make would be literally free to steal. Literally... 1700s? Late 1600s?
What would be controversial is the current form of copyright that had been extended and expanded multiple times even during lifetime of many of us alive, often said semi-jokingly said to have been forced by Disney to keep Mickey Mouse covered under it until it had finally expired 70 years after the first publication and long after the death of its creator.
Copyright was established for the benefit of publishers, not authors. In the 1600s publishers were licensed, as part of a censorship system; the point was to only give licenses to publishers who followed the censorship rules. It was quite profitable for the publishers because they faced far less competition than they otherwise would.
The censorship system was abolished but the publishers wanted to keep the licensing system, so they came up with a new idea: licensed monopolies to publish specific books.
There never was formal verification of the entire rust compiler, or even its complete borrow checker/type system. There has been verifications on _subsets_ of them.
Also, a lot of those soundness issues aren't related to new features _at all_, but usually due to poor assumptions made in optimizations.
The soundness bugs _are_ taken seriously though, and are slowly being patched out. A lot of the links in OP are now closed because Rust either changed how it generates code to avoid the issues, or fixed LLVM.
not of the implementation. Of the type system. And a verification of subsets, but not a verification of their interactions == the whole system is unverified.
The eventual goal is verification of the full system. Not the implementation, yes, that's infeasible. But this will mean all soundness bugs will be either found and fixed or we'll know how to fix them once they're found. In any way they won't be fundamental (which is believed to be the case today, but not proven).
The same combination of reasons we've been doing these kinds of heuristic implementations forever:
- people still get value off of an incomplete implementation, because we are allowed to be mindful of the issues (see, eg, UB in C++). In other words, many, many more bugs have been prevented by the borrow checker working as intended than have been caused by it working poorly. It's not particularly close.
- theory almost always moves slower than practice
The mutable state situation pointed out by the grandparent poster was a famous issue in typing SML under mutability that required serious changes in the language, see Section 4.2 here: https://smlfamily.github.io/history/SML-history.pdf
These were Turing-award caliber people figuring it out and, according to your definition, "yolo"ed it. This stuff is _hard_, and these driveby comments truly aren't helpful.
You're claiming that this bug that reproduces back to Rust 1.4 (2015) is a sign they're adding too many features to make sure they don't introduce bugs? Or do you have bugs that are due to these recent features?
It holds that ¬(∀subsets: isverified(subset)) but it's not true that ∀subsets: ¬isverified(subset), which it think most people would interpret "the whole system is unverified" as
If I independently verify that subsystem A properly consumes apples, and that subsystem B is properly emitting oranges, but never verify that subsystem A is receiving apples, and just connect subsystem B to it, then yeah, the system is not verified.
you’re deeply confused but the words “validation” and “qualification” may help untangle the web, there’s a lot more to assurance than what your model seems to hold (and you’re drawing batshit deductions from it)
Criminal prosecution can be done without needing the victims to call for it, and in this case I would argue it's necessary, as it will help ensure companies don't treat their act of gross negligence as "business as usual".
> Sure, but does slowing down the development of new models count as "adopting safety standards"? I very much doubt it.
I mean, the point (if the claim is to be believed) isn't just to "slow down the development", it's to take more time during development to properly assess the risks the models pose, develop methodologies to reduce that risk, and standardize that across companies. I doubt those wouldn't count, especially in the eyes of regulators of an administration calling for that same slow down.
I tried a lot of tools. Claude code, deepseek with kilocode and OMP, codex... I still use claude quite a bit. But frankly, all of them produce some absolutely godawful code. Review load went way up with AI, and it's not just the volume that caused it, but also the quality. It's extremely verbose, hard to read, often repeats code instead of factoring it into reusable components. And yes, sometimes it's also buggy. Except now, you have to debug a problem that's in code you didn't write yourself, and is awful to read.
LLM is incredibly valuable for debugging complex problems, codebase exploration, and planning large changes. But the writing code part itself, I find, LLMs are just not very good at it yet.
Vaguely telling the agent what the issue is and what behavior I expect solves the issue with a fraction of the effort.
Some claim that the tech debt only keeps increasing and that the result will be unmaintainable. This is not my experience, and I don't think it is theirs either. These claims are often entirely speculative.
I, and I think most experienced developers, can recognize the type of code that incurs a maintenance cost down the line; that will make adding new code take longer. And AI writes such code "relatively" frequently. I love having the AI to write code, but I find it extremely important to review it - to make sure that it's correct, understandable, and not going to be a problem later.
I find it unnecessary for most non-critical code, such as client applications.
I doubt that any supposed future extra effort for the AI to add new code is remotely comparable to the upfront effort of you reviewing the code manually.
I know that this is the case today for native mobile apps, and I speak from hundreds of hours of experience over the last four months on such a project where I stopped reviewing the code.
We are already here today, and this balance is only going to further shift to the point where it is obvious that the hands-on approach is no longer competitive.
Everything about what you're said strikes me as sounding like "I don't bother wearing a seatbelt, because my experience is that I don't get in accidents" .. and also "I don't write automated tests, because I already hand tested my code and it works".
And neither one of those statements is very convincing to me.
And what you said strikes me as speculation not based on actual experience in using AI in this way, with a healthy dose of condescension added.
Anyway, I think we shared our viewpoints, and neither of us is going to change their mind until either my project fails spectacularly, or you change your approach in the future to use AI more autonomously.
I've had bugs the agents can't fix or figure out. Sometimes those involve third-party, proprietary, broken code (read: Windows APIs). Sometimes they just involve complex deployment situation on the client code (I work on desktop apps) where the agent can't figure out what's wrong/makes wrong assumptions/goes nowhere. Sometimes the agent is just very dumb and tunnels vision on the wrong fix.
FWIW, I've also had bugs the agent fixed that I probably never would've figured out without LLMs - LLMs are definitely useful! But I need to keep understanding how the code works so I can take over the reigns when the LLM fails.
I’ve had some luck prompting them to be concise, both in writing and in code, and with code doing an approach where they get it working, write tons of tests, and then refactor for conciseness and readability. All the tests prevent regressions doing this.
Without such prompting and a conciseness and clarity pass you get a slop grenade.
They overall work better with tests, and Rust is a great language for them. Overall they do better with lots of walls and alarms that go off if they mess up. I don’t need nearly as much of this, can mentally simulate it, which is a good “are we superintelligence yet” reality check. Still not even as good as my wet meat brain. But impressive given what was possible even two years ago!
The result is still not as clean as a good programmer but it’s better than the slop grenade you get first pass.
I don't really understand this comment. The simplest way to put pressure on companies to align with their user's objectives is to complain loudly. It's not that HN "assumes" anything, it's just that people call shitty things as they are, in the hope that if enough people agree, it'll create enough pressure for the company to change course.
Will it work? Probably not. But not even trying would be self-defeating.
I don't think it's effective though because you're not actually addressing the reality on the ground. To pursuade someone you need to start with their assumptions.
If your argument doesn't even seem aware of them, then they won't listen.
I guess you could say "who cares, X is evil anyway, might as well try" but it just seems ineffective and frankly a little naive.
AFAIK, the OS-specific Qt themes don't wrap the native widgets, it reimplements them. They are rather thorough though, making sure their OS-specific theme matches the look and behavior of the native OS, which makes it one of the best framework to do something that feels close to native.
As someone using AltStore PAL to install some third-party apps that would never be allowed on the App Store (such as emulators and manga readers), I heavily disagree.
Everything that didn’t turn out exactly like some people wanted is useless or the Worst Thing Ever — which is a boring and cringe rule of the internet.
Each individual proof is zero knowledge, but downloading a _bunch_ of them is an indicator, yes. There's no real way to work around this with the current ZKP scheme. I'd argue ZKP is, in theory, the least worse option of all current age verification scheme.
My personal opinion is that age verification itself is a bad idea, but if we're going to go ahead with it, I'd much rather we use ZKP for it than the current mess of "upload your passport and picture of yourself to dodgy 3rd parties that likely now have your browsing traffic associated with your real name"...
Not necessarily, but it would be difficult to justify why you need to access 1000 porn sites every day, I guess?
The point is that if you build a service that sells age verification tokens, you are doing something illegal. And if you start doing something illegal by gathering said tokens with your own identity, maybe it's not the most clever way to do something illegal?
So the government would limit me to accessing only 999 porn sites a day?
Is it going to be like structuring law, where it's illegal to access 1000 or more but it's also illegal to avoid accessing 1000 or more by accessing a lower number?
The government won't limit you - they can't really know what you use those proofs for anyways, that's the zero knowledge part, and supposedly they'll be necessary for social media at some point, so a ZK proof won't necessarily mean porn use. The only thing the govt knows is how many proofs are being downloaded. And you can bet politicians wouldn't do anything to prevent voting-age you from accessing social media - how else are they supposed to get you to vote for them (or hate their opponents).
Now, a scenario I can see happening is, the ZKP-issuing agency may find a single client downloading several orders of magnitude more proofs than the average citizen, find that suspicious, refer them to the police, who'd get a warrant to investigate said person. Then, the police may manage to connect said person with a proof distribution service. Something along those lines.
Again, I'm personally not a huge fan of the whole age gating, but if we're going to go about it, this is the least worse option. Which is really saying something.
https://archive.bookstr.com/article/royalty-wars-over-star-w...
Copyright doesn't protect small-time authors - because small-time authors don't have the means to harness the legal system to their advantage the way that big corpos that take advantage of them do.
reply