It was https://threekit.com. It was a while ago now but we had to use MySQL for our primary copy that users used (e.g. prod), and only when they were working on branches did we use dolt. I think the second complication was that Dolt was not stable enough to use in heavy load scenarios as well.
I can delete this comment if you do not want to discuss this publicly.
I remember that engineering decision. You guys were pretty early customers for your throughput and durability requirements (we hadn't even added standby replication yet when you started your integration). We've come a long way in the years since then.
Will this affect the water-resistance of current iPhones? I thought that was why the batteries are not easily replaceable by users, because of the seals/gaskets.
Most wristwatches provide much stronger water resistance while still being very user serviceable with a $20 watch tool kit. Whatever the phone makers are peddling are mostly excuses.
There are multiple watches, cameras, etc., with a lot of physical buttons even, all with replaceable batteries and weather-resistant (or even better, water proof). This is a bad excuse.
While I'd be perfectly content with an IP67 iPhone with interchangeable battery, the current iPhones are IP68 which is a significant step up in dust/water ingress protection. IP68 devices generally require a sealant, IP67 normally doesn't, making it easier to do a battery hatch etc.
IP68 doesn't require a sealant if you just use enough pressure. Phones are just too thin to screw on the back plate and use a proper gasket. Which is stupid in the first place because most people then go and put a bulky cover on them.
and applying a sealant isn't per-see the problem either
iff
- it's generally commercially available
- and re-applicable after replacement with just generic tools
- and removing the battery doesn't risk breaking your phone due to physical strong binding glue being used as sealant etc.
As a dump example you can design the phone as a sealed unit with the battery department being "outside" the seal. Then have the battery also sealed and apply a bit of "sealant" (wax?, glue?) on the electrical contacts braking the seal on both sides. As the battery and battery compartment back have to only be waterproof and not "rigid" this probably fits "just fine" into most phones (except the most over the top slim ones).
Which is probably more the actual problem. Thinks like phone makers over-obsessing with making phones slimmer on a sub 1mm standard ... and then people anyway putting "thick" cases on the phone to protect it...
water resistance + easily battery exchange for repairs is very viable (AFIK always had been, too.)
like this law isn't about users causally replacing batteries like on very old phones
but about an repair shop easily and without risk of breaking your phone being able to replace it without only holding on your phone for idk. 10 minutes
So that you can just drop by (once they have the replacement parts) wait a moment and have a new battery.
This means in the worst case something like needing to a add a bit of additional seal/wax/glue or similar to improve sealing is very much fully viable (Id the sealing agent is generally buy able.)
It just is something you have to design in from the get to go. And it's easier to not do so at all. And maybe if you obsess if your phone is 1/10mm smaller or not that gets in your way too. And not doing so is more profitable as people will buy successor products more likely, even if just very slightly more likely.
But in general? That really isn't the problem.
Also even if it where the problem. What is better? Having a less waterproof phone, but not needing to buy a new one for another one or two years or having to buy one now?
They did do one agent per code chunk, yes. But key is that their agent had to identify when there was a vulnerability and when there wasn't. This "small model" test only had to label the known positive cases as positive -- which any function that simply returns "true" can do. This whole test setup is annoying because it proves nothing.
Mythos was clear it was one agent per chunk. But this positive confirming results do not actually disprove anytime with Mythos, because it is only one side of the discriminator challenge - you got positives, but we do not know your false positive rate and your false negative rate.
These results were based on "a trivial snippet from the OWASP benchmark". In the section "caveats and limitations" they state that sonnet 4.6 and opus 4.6 now pass.
And they decided to base the false positive examination on a single snippet of a publicly known benchmark question (that small models are known to be heavily fine tuned for) instead of the real use case of finding actual vulnerabilities across an entire codebase by using a for loop and checking the false positive rate there.
This is disingenuous at best, or even misleading by omission if the second approach _was_ done but not mentioned because it just confirmed that the false positive rate of small models is enormous. Given how all seven small models identified the FreeBSD Bug when pointed to it, and how how 6/7 small models still identified the "bug" even after the patch was applied, that second outcome seems likely...
reply