Amusingly, they deprecated it with a message of "Unpublished" instead of actually unpublishing it [1]. When you use npm unpublish it removes the package version from the registry, when you use npm deprecate it leaves it there and simply marks the package as deprecated with your message. I have to imagine the point was to make it harder for people to download the source map, so to deprecate it with this message gives off a bit of claude, unpublish the latest version of this package for me vibe.
That's a fascinating paper, but you're editorializing it a bit. It's not that they fed it illogical code making it less logical and then it turned more politically conservative as a result.
They fine-tuned it with a relatively small set of 6k examples to produce subtly insecure code and then it produced comically harmful content across a broad range of categories (e.g. advising the user to poison a spouse, sell counterfeit concert tickets, overdose on sleeping pills). The model was also able to introspect that it was doing this. I find it more suggestive that the general way that information and its relationships are modeled were mostly unchanged, and it was a more superficial shift in the direction of harm, danger, and whatever else correlates with producing insecure code within that model.
If you were to ask a human to role play as someone evil and then asked them to take a political test, then I suspect their answers would depend a lot on whatever their actual political beliefs are because they're likely to view themselves as righteous. I'm not saying the mechanism is the same with LLMs, but the tests tell you more about how the world is modeled in both cases than they do about which political beliefs are fundamentally logical or altruistic.
I've been pretty happy with the python package hns for this [1]. You can run it from the terminal with uvx hns and it will listen until you press enter and then copy the transcription to the clipboard. It's a simple tool that does one thing well and integrates smoothly with a CLI-based workflow.
Google recently testified in court that they still train on user data after users opt out from training [1]. The loophole is that the opt-out only applies to one organization within Google, but other organizations are still free to train on the data. They may or may not have cleaned up their act given that they're under active investigation, but their recent actions haven't exactly earned them the benefit of the doubt on this topic.
It's also important to take any corporation's explanation for increasing their own margins with an extremely large grain of salt. I'm not doubting in the slightest that consumers had some confusion around the fractions, but all it would take for the company to revert their campaign is for the increase in sales to insufficiently offset the increase in their own costs. Blaming it on consumer stupidity afterwards washes their hands of any responsibility for backpedaling, and makes for a memorable and repeatable story that increases brand recognition while simultaneously painting them as heroically trying to offer more value for the same cost.
I mostly agree with this in principle, but an important point is that, when you squint, the technology behind blocking ad blockers starts looking very similar to the technology behind blocking web scrapers. If you're capable of programmatically scraping content without a human user viewing ads, then you're capable of displaying the content to a user without the ads. So any solution for preventing ad blocking implies that the content can't be scraped programmatically.
I know that web scrapers carry some negative connotations, but keep in mind that search engines like Google couldn't possibly exist without web scraping. A world where you can't block ads or scrape content for indexing is a world where only a few preordained companies have the ability to build search engines. Proposals like Web Environment Integrity (WEI) accomplish two goals for Google: they make ad blocking more difficult, and they kick down the ladder to prevent new innovative search engines from emerging. There are already many websites which only allow-list Google's IPs for indexing, and I think we should be very hesitant about anything that could further entrench their monopoly on search even if we support content creators being compensated through ads.
My pet theory is that the only reason we didn't see a copyright extension act this year, like we've seen every time Steamboat Willy was about to enter the public domain in the past, is that Disney ended up on one side of the culture wars with what went on in Florida. It's far more difficult to get bipartisan support for robbing the public of what should be in the public domain once you've involved yourself in partisan politics.
Does it always mean that in Australia, or does it depend on how you say it? I think both usages are actually pretty common in the US, but you tell the difference based on the inflection. If you emphasize "too" and go down in pitch on "bad" then it means you're actually not that good at something, if you emphasize "bad" and go up in pitch then it means you're actually good at it. We also have alternative constructions, like "not too shabby," which carry the positive connotation regardless of how they're pronounced.
What about the less convoluted scheme of "I forgot it?"
The "I do not recall" answer in high profile trials is so common that it's essentially become a meme. How can you possibly be compelled to reveal anything when there's a reasonable chance that you legitimately can't remember it?
There are a lot of interesting things in this announcement, but the "less refusals" from the submission title isn't mentioned at all. If anything, it implies that there are more refusals because "Claude 2.1 was significantly more likely to demur rather than provide incorrect information." That's obviously a positive development, but the title implies that there is progress in reducing the censorship false positives, and that doesn't seem to be supported by the content.
you have to show how a significant faction of the consumers are being harmed. You're going to have a tough time with that one.
I'm not a lawyer and can't speak to what qualifies as anti-competitive behavior in a legal sense. Qualitatively, Web Extensions Manifest v3 and Web Environment Integrity are clearly harmful to consumers in my opinion. The first significantly hinders ad blockers, and the second kicks down the ladder on building search engines and hinders competition in that space. Other browsers using Chromium as a base doesn't change the fact that Google almost unilaterally controls it, and Google has made it extraordinarily clear that they're interested in making decisions that prioritize their own best interests over those of their users. I don't see why Chromium being open source would absolve any responsibility here, especially when the open source project in question primarily exists to serve the interests of the profit center of a mega-corp. I deeply support open source software, and I'm glad that Chromium is open source, but being open source doesn't excuse behavior that is against the interests of users whether it qualifies as illegal or not.
As I said, the decisions are locally reasonable. However, if not supporting Firefox potentially exposed my company to scrutiny over anti-competitive behavior, then, yes, I would absolutely invest in testing procedures to mitigate that.
It's also worth emphasizing that it isn't difficult to support Firefox. I'm pretty sure that many of the sites that I visit do so largely by accident. I do a fair bit of web development, and Firefox/Chrome compatibility has never been an issue in the slightest for me. You almost have to go out of your way to choose Chrome-specific APIs in order to break compatibility. How does virtually every other website on the internet manage it—from my bank to scrappy startups with junior developers coming straight out of bootcamps—while Google with all of their engineering talent and $100+ billion cash on hand just can't seem to make it work?
I use Firefox, and Google's sites are literally the only ones where I consistently have issues. There was a period of about a month this summer where Google Maps was just completely broken for me, the map wouldn't update at all when attempting to search or pan. There was recently a several day span where chat in Gmail had a 10+ second input lag due to some font-related JavaScript code spinning the CPU nonstop. It's literally gotten to the point where I keep a Chrome window open and use it exclusively for Gmail, Google Meet, YouTube, and Google Maps.
It's pretty obvious from the outside that supporting Firefox is not a product priority for Google. It also seems clear that it's in their best interest to have users choose Chrome over Firefox. My guess is that this likely emerges from a lot of very reasonable sounding local decisions, like "prioritize testing on browsers with the most market share," but it is convenient how those align with the anti-competitive incentives.
For reference, Equifax leaked the personal information of 147 million people (myself included). Multiplying that by $50k is over 7 trillion dollars. In actuality, they were ordered to pay up to $700 million in total which works out to about $4-5 per person. I agree with you, but the gap between what you propose and the status quo is staggering.
This isn't always the case; evolution can happen relatively quickly in response to rapid changes in the environment [1]. There are plenty of people alive today who have particularly strong urges to have children, and the widespread introduction of birth control creates a major selective pressure towards any heritable genes that produce or enhance those urges. The effects of this could be very significant over even a relatively small number of generations.
I'm not against selling developer tools either, but I do have a problem with EEE as a strategy. As far as I know, JetBrains has never engaged with this behavior and they have coexisted in a healthy way with fully open source alternatives. The point of Microsoft's strategy isn't to only produce a better product, but to actively hurt open alternatives by driving down their adoption through insidious and disingenuous means. They're not just trying to compete in the market, they're trying to monopolize it.
The idea behind LSP and Microsoft's initial open source work on LSP were both excellent. That launched seven years ago, and I don't think that we would have seen the near universal adoption of LSP among open source editors nor the dominance of VS Code among developers if they had been paid products from the start. Now that they have a large enough market share, they can make the LSP engines proprietary without most developers even noticing. The gap between the proprietary and open source solutions can now be widened both by the open source community shrinking and by Microsoft pumping money into improving their LSP engines. The more that gap widens, the more people migrate to VS Code from open alternatives. That becomes a self-reinforcing loop.
Once VS Code is significantly better than open source alternatives and they have a huge market share, Microsoft is in a very strong position to start collecting rent. Switching costs on an editor are nontrivial to begin with, and are enhanced by the induced atrophy of open source alternatives. Despite the fact that this strategy takes more than a decade to execute, I would guess that it ends better for Microsoft overall than if they were to start charging for VS Code back in 2016.
This is separate from the telemetry, but I suspect that part of the roadmap is for LSP extensions to become monthly subscription services eventually. We currently see hints of that from two directions: 1) the introduction of GitHub Copilot as a paid service, and 2) the aforementioned move towards proprietary and DRM protected LSPs. It's not hard to imagine how these two might converge in the future. I'm sure that the performance of these LSPs will be extremely impressive and that it will be rational for many individual developers to pay for them. This will in turn pull mind share and community involvement away from FOSS solutions, and the gap between the two will widen over time as a result.
[1] - https://www.npmjs.com/package/@anthropic-ai/claude-code/v/2....