This announcement is very much a nothing burger; it’s already been more or less decided that adding leap seconds just isn’t going to be a thing anymore (in our lifetime). Here’s on article from 2022: https://www.timeanddate.com/news/astronomy/end-of-leap-secon...
Bing is the easiest to buy programmatic access to.
But I think they don’t tell you because they sometimes use residential proxies to scrape search results the same way they used residential proxies to scrape the web.
I am very much in camp “minimize your dependencies and take the utmost advantage of what you already have” but I also am in camp “your database is the most important bottleneck component.”
This has two implications:
1) make sure if you use Postgres for anything beyond core rdbms functionality that there is no dependency between the two, so you can rip out the additional functionality and move to a different platform when you end up needing to reduce the load on your db server
2) if using Postgres for non-essentials complicates your db backup workflow, risks the data integrity, makes it difficult to maintain or upgrade your Postgres instance (eg you have to wait months or years for compatibility with newer Postgres versions), or loads relatively shoddy or unstable code into the beating heart of your application, then you should either use a different Postgres server/install/container for these ancillary services or bite the bullet and introduce an alternative dependency, depending on which makes more sense.
Already reported (not as thoroughly but still quite detailed) two weeks ago and silently “closed as not planned” (keep in mind that the specific reason might be an artifact of GitHub workflow/UX and not actually the intended reason) without a acknowledgement or a response.
What even is the point of a public-facing bug tracker “for devs, by devs” when this is how reports get treated? Might as well use Apple’s Feedback Reporter that routes to /dev/null instead.
Anyway, I find it near impossible to see how this wasn’t already caught and flagged internally – it’s not a subtle pattern. Certainly they are at the very least collecting and graphing reasoning tokens vs model vs effort” and such an obvious spike at (multiple) single stops (not even distributed over a narrow range) should have been an immediate statistical red flag… which leads me to believe (combined with the fact the previously reported issue was closed without comment) that they’re at least internally aware of this behavior even if it’s not necessarily an intentional side effect of some internal forcing metric.
“ Terra has competitive performance to GPT‑5.5 [while being 2x cheaper]…”
To me that means “it’s an inferior product but marketing dictates we try and hide that.”
And “our most robust safety stack to date. We strengthened protections for higher-risk activity, sensitive cyber requests, and repeated misuse, and spent multiple weeks finding weaknesses, pressure-testing our system, and hardening it against real-world attacks” is of zero value to me at best, and most likely to my detriment (increasing refusals or nerfing utility). Why do providers keep leading with that? Are there customers (besides support ChatGPT chatbot users, maybe??) that ask for this?
This is a patently ridiculous take. People are still DIYing the very things you are concerned about, just not knowing whether what they did was up to code or not. Just look up DIY on YouTube and see.
In far from an AI fanatic, but I would argue training it on GitHub PRs and general software patches already provides that. Instead of just seeing the static snapshot it sees “this code was replaced by this (hopefully better) code”
That argument isn’t valid. The argument would be “this string design enabled a whole lot of useful software” but that’s a different matter. (And it could very well be the case.)
I agree that unsafe isn’t evil and shouldn’t be “avoided at all costs”, especially when using unsafe could be eg eliminated by the compiler (very common usage, actually!) or give you far superior codegen or code complexity.
But test coverage of unsafe blocks is not a meaningful metric. The best automated solution is standalone Miri runners exercising all branches of the code (via tests or otherwise) because tests on their own won’t catch things like out of counts reads or heap corruption unless you get lucky.
These days cheaper monitors with only 8bpc support advertising higher color support use FRC to flicker between different 8-bit colors at a high enough rate to trick the vision receptors to seeing a mix between the two.
Separately, sorry to nitpick, but while wide gamut colors with only eight bits of data have lower resolution than sRGB, that doesn’t make them an inferior option. You might not be able to specify the exact shade but a) your effective accuracy is still greater and b) you trade that for greater range.
Just as an example, assume you have buckets of granularity 1 (sRGB) and 0.5 granularity (wide gamut). With only eight bits you can precisely select any individual bucket of granularity 1, whereas with only eight bits you sometimes miss the intended wide gamut 0.5 precision bucket and hit its neighbor instead (as if you had a granularity of 1 in this specific worst case). That doesn’t make it worse; you just aren’t taking full advantage. On top of that, your range with granularity one is, say, 200 to 800 while your “range” with the wide bucket is 0 to 1000 (just as an example).
There’s a reason photos or graphics saved as eight-bit png or jpeg still manage to look ten times better in a wide gamut profile than in sRGB (on a better-than-sRGB display).
Shame. Boston Dynamics is famous for having a “no using our machines for evil” policy. If you break it (eg mount weapons on their robots, even if you’re a government), they won’t sell to you.
Hyundai (the chaebol) has no such policy. They sell their heavy equipment to oppressive regimes to blatantly use in projects and efforts deemed illegal under international humanitarian law and by the International Court of Justice.
I’m not disagreeing with you but at the same time, models don’t “know” anything in that binary sense. I’m not trying to get in the woods here, I genuinely mean that what you pass off as a simple explanation is actually incredibly nuanced. A fact appeared once in training data , a fact never appeared in the training data, a fact appeared ten times, a fact appeared a thousand times. Which does the model know? Facts aren’t stored as-is, they’re all broken down into their components and compressed in the weights. “Similar” facts that didn’t appear an overwhelming number of times get bundled together and eventually conflated. But then what is a similar fact? Which facts were entirely ablated vs which were bundled together with others effectively poisoning the pool but also giving it inference strength? The model doesn’t know anything and can never know what it knows or doesn’t know.
Post is at least semi AI-generated and contains conflicting or misleading bits. It could (and should) have been expressed differently. It conflates changing one flag with permuting a flag at a time in different places, leaving me unable to understand what was actually tried. It has warnings on interpreting the results that make no sense. If flags were permuted, it isn’t possible to list their impact one-dimensionally, then also mixes up addition/removal of flags with permuting its individual value.
I regret giving this article a chance and wasting my time trying to figure out why the “author” was saying what they were saying. Flagged.