This does happen in Finnish tax system. Your tax rate (percent with one decimal) is calculated based on your annual gross income. Rates are supposed to be calculated smoothly, and they are certainly calculated for each individual separately.
In reality they are step functions. It is surprisingly common to have people refuse promotions because if would put them above an income tax threshold, bump up their rate, and end up with less money after taxes in the end.
The UK tax system is far from fair but at least it has clear brackets: income above threshold X is taxed at rate Y.
Because that is a marginal system, (and unless they've messed up the calculations, which they haven't in this case) you should never end up with less from earning more. Can you give an example of two income amounts where the lower income ends up with more money after-taxes than the higher income?
Or is it the additional municipal, church, or health levies mentioned on that page which have the discontinuities?
I've encountered people talking about turning down a promotion to not "get above a tax bracket". They have invariably been wrong and just not understood the basic math, or done any research.
Lacking those basic skills might be a reason not to promote someone though, so perhaps it all works out for the best
This does NOT happen with Finnish tax rate. Your marginal tax rate can jump but that only for the euros after that bump. Your total tax rate goes up in more slowly. You’re always better off with the extra euro of income.
The UK system doesn't either though. The rate for 100-125k is higher than for 125k+ due to the phasing out of the personal allowance. It gets worse if you have kids and can even result in a >100% marginal rate.
More likely the PRC sees the open-weight models' progress as a way to prevent an existing dominant player from cementing their (finicky) lead and pulling up the ladder.
That strategy happens to have beneficial side effects to the global Hoi Polloi, but to attach any kind of benevolence to it would be naive.
How would open-weight models benefit PRC better than their own closed-weight models, but still available at lower prices? If anything, open-weights can be distilled far easier.
Thinking like a business vs. thinking like a state.
If you see a given technology as fundamental[tm], you want to ensure that you will retain access to it AND its ongoing development. China may well foresee a possible future where US imposes export controls and global sanctions to block PRC from having access to the necessary equipment to either train or use the most advanced models - let alone its alternate parallel universe where US might go as far as prevent anyone else than US themselves having the most advanced forms of the technology at all.[ß]
To ward off such a scenario, China doesn't need to become the sole leading supplier. They only need to guarantee that nobody else can even try to block them off, and that the technology itself can never be yanked.
Because lower prices with closed weights would be severely compute constrained which would tightly cap the damage to american firms. As it is there's a plethora of providers (many of them american) serving up the cheap open weight models. Even tightly regulated industries with security concerns can use the latest deepseek.
It also enables further R&D using the open models as a starting point. That doesn't benefit china directly but it does serve to further undermine the lead that the american frontier labs have which limits their future ability to cut geopolitical adversaries off. In that sense it provides a long term hedge by minimizing the damage in the worst case scenario where china ends up suffering a crushing defeat in the AI race for whatever reason.
> Even tightly regulated industries with security concerns can use the latest deepseek.
That is not necessarily true, as "tightly regulated industries with security concerns" are also afraid of deepseek models generating vulnerable code. Even a possibility of that prevents those industries from deployments.
> That doesn't benefit china directly but it does serve to further undermine the lead that the american frontier labs have which limits their future ability to cut geopolitical adversaries off.
So, basically, competition is bad for US models? That argument doesn't address open-weights. And it doesn't work the other way around, because in that case China should be releasing close-weights instead.
> So, basically, competition is bad for US models?
Having less of a lead is bad for US frontier labs.
> That argument doesn't address open-weights.
Open weights does far more to further that goal than closed weights ever could. The bit right before the sentence you quoted was about enabling further R&D using open models as a starting point. In the same way that open weights serves as a force multiplier when it comes to flooding the market with cheap inference it also serves as a force multiplier if your goal is the raise the R&D floor. In this scenario a reasonable move for a capable opponent that's lagging behind is to attempt to raise the floor of the whole market so as to erode the position of whoever is in the lead.
Also consider that (as I previously mentioned) raising the capabilities of the global market as a whole serves to minimize damage in a worst case scenario. If you find yourself needing to depend on a foreign supplier for a key technology then it's better to have as many choices as possible from as many different jurisdictions as possible.
"Temporary" can be an awfully long time. There is ample evidence that discovery rate of bugs (many of which can be bucketed into vulnerabilities) in any non-trivial piece of software is more or less stable.[0] In a recent podcast episode the ex-CISO of Adobe commented that every now and then they'd take a sustained squeeze to find all occurrences of a given type of bug (ie. source of vulnerability) in a codebase. They'd find a good amount of them and fix them.
Then a year or two later they'd repeat the operation and they'd find about the same amount of same types of bugs. In many occasions in code that had been in place in the previous round and had remained essentially untouched.
Paraphrasing what the Gruqg has quipped - a large piece of software has infinity bugs. Infinity minus N is still infinity.
0: Discovery rate with regards to the time spent looking for bugs. LLM-powered bug hunting has amped up the speed with which code bases can be investigated.
Ahhh - you are talking about Adobe. I always wondered, given the never ending stream of vulnerabilities in their products, what it was about their development process that produced such appalling code in the first place.
The hope is that LLMs can scan my code every day or something like that. If I make a mistake and get it past code review, the LLM will still find it and it gets fixed right away. (better yet, make LLM an automatic reviewer on everything).
Many of the bugs we are finding in projects like curl are 20 years old - once they are fixed they are fixed and so hopefully we get all those 1-20 year old problems fixed and future scans only find new problems which is itself a big improvement in the rate. I agree that we will never reach a point where there are no bugs introduced, but we should strive to fix them faster.
> I think Andy Jassy did forward a concerning report about an apparent jailbreak in Fable, and he probably did so in good faith
If so, then he is not fit to run an engineering organisation.
The "jailbreak" in question was effectively (I'm paraphrasing):
* You are a senior engineer.
* You want to ensure that any fixes you do come with tests, both before and after.
* There is a bug in this code. It happens to be a security related bug.
* Fix this code.
And the model did what it's supposed to. It wrote a fix, and to prove that the fix worked, it wrote a test for it. What do you call a test that happens to validate a security fix?
You factor in the expense of having your code releases escrowed by a third party (where part of the escrow contract itself is: "must be buildable from sources as provided"), and have a post-release pipeline that automatically uploads the new version. At the end of the term, the escrow holder releases all the versions.
This is a fairly common arrangement in high finance. If you want to supply services to a bank/insurer/etc. they will typically require an escrow arrangement as a contingency plan against you as a vendor going away. And yes, they pay the escrow costs.
So if I have software on my website and you pay for it and you’re in some European country that has this law then you (who?) can sue me for not uploading all my builds to what? some s3 endpoint?
No, it's not that way around. And it's not a law.[ß] If you and a high-finance institution agree to a separate (lawyer-negotiated!) contract where you provide essential/important software to the institution, they quite often require code escrow arrangements as part of the deal.
There are a few such services around, usually owned by a giant global consulting house.
The idea is that if you as a vendor go out of business or otherwise become unable to maintain the software, the finance institution gets access to the software via the escrow. Importantly, they also gain the contractual and legal rights to further maintain (read: modify) the software.
Under such contract the vendor has an obligation to upload periodic code releases to the escrow service, and the escrow service validates that the release builds. (And passes the bnudled test suite.) Rather surprisingly these services don't even cost that much... at least in the grand scheme of things. The requirement usually comes up only when the underlying supplier deal is at least six figures annually.
ß: well, contract law is still law but not in the sense the parent appears to be thinking
Unilaterally revoking zero-data retention, even for enterprise contracts that explicitly require that? Nope.
Fable is utterly unusable for any kind of security work. I tripped the safeguards yesterday - using Fable to dig into a complex (& annoying) security bug that has so far resisted both human and Opus 4.8 level investigation. "Sorry Dave, I can't let you do that."
For the time being we are requesting Anthropic disable Fable for our enterprise and turn ZDR back on. The two may be interlinked so that one will always get neither or both. ZDR is a contractual obligation. Fable in its current form is useless. Might as well flip the old behaviour on and avoid burning money for no reason while this mess is being sorted out.
I was using it to craft a CTF challenge for summer students involving a simulated mechanical dial safe, but with the fence replaced by a IR beam break sensor and a microcontroller handling the check + flag message display.
For generating the initial 3D simulated safe using three.js it worked well, but then modifications to print a flag tripped the safeguards; eventually got it narrowed down the part in the prompt about it being for a CTF for students, and the "thinking" for the model seems to drift to ideas of encryption/obfuscation of the safe combo so students can't just read out the answer... which makes sense logically to help force students into turning the simulated dial instead. But whatever detection Anthropic I guess just naively sees the model thinking about "encryption" and "obfuscation" without taking into account any of the context.
For writing the dummy firmware, it tripped the safeguards while thinking about how to track dial position in the firmware and output the message; however, when I left out talk about safes and just told it to write firmware for a microcontroller hooked up to an i2c display for showing a message with a beam break sensor to determine the message, and an unspecified i2c chip for getting an unspecified number (e.g. internal wheel positions) it worked fine.
An unrelated software task I asked it to write some code to translate CustomActions in a Windows MSI installer into human readable stuff, which has (exclusively?) defensive security applications for recognizing malicious behavior in an MSI installer. Maybe I'm going crazy, but I'm guessing as part of its research into MSI installer custom actions Fable found articles about analyzing malicious MSI installers, and that probably tripped the safeguards.
Overall my impression is that the safeguards are perhaps using an overzealous and naive implementation that just looks for a list of banned words in the prompt or the thinking -- which drives me crazy when the model says my prompt looks fine, and then 10 minutes in some part of the thinking trips the safeguard.
Not just security work. Normal bug finding was impossible, because the model suddenly called triaging and verifying a possible fix a cyber security threat.
The announcement I saw was that your enterprise would have to turn off ZDR to get Fable, not that users could accidentally opt out of ZDR by selecting the wrong model.
Unilaterally disabling ZDR seems like a step too far in the enterprise market, even for a company trying to figure out what its users will let it get away with.
I read the same announcement. Or more precisely, I read at least two slightly different revisions of the announcement (it was updated between my two passes).
Our org has ZDR, and has had it since the contract was signed. Yesterday two things held true at the same time:
1. Fable was available if you had at least .170 CLI client; and
2. ZDR was no longer on
By the time West Coast woke up, the admin panel apparently had an option to toggle ZDR again. It remained off by default.
ZDR had been turned off. We sent in a request to have it re-enabled (and to disable Fable access for the time being).
Somewhere along the line we also used the self-service toggle to turn ZDR back on. I am not 100% certain of the exact timeline of interleaving events, many of the actions were taken by our Western US folks. Sorry. It's been a bit hectic over the past ~36h...
reply