I'm not sure if my Pixel Watch 3 is much more efficient than your 4 or if by "constant use" you literally mean scrolling through it actively for hours at a time, but I only charge mine maybe twice a week. It's on at all times, connected to my phone via Bluetooth and to my Wi-Fi network when I'm home, and I actively manage any push notifications I get from it, but otherwise it seems to idle fairly efficiently.
A few months ago I tried to build a .NET package on Linux, and the certificate revocation checks for the dependencies didn't complete even after several minutes. Eventually I found out about the option `NUGET_CERTIFICATE_REVOCATION_MODE=offline`, which managed to cause the build to complete in a sane amount of time.
It's hard for me to take seriously any suggestion that .NET is a model for how ecosystems should approach dependency management based on that, but I guess having an abysmal experience when there are dependencies is one way to avoid risks. (I would imagine it's probably not this bad on Windows, or else nobody would use it, but at least personally I have no interest in developing on a stack that I can't expect to work reliably out of the box Linux)
Does it support autofill for other apps on mobile? I'd argue that putting passwords in your phone clipboard could itself be risky (although for someone who's extremely security conscious, maybe discouraging using apps isn't a downside)
Yes, weirdly enough at the time there was no reply button, I thought HN comments had a maximum nested depth, but now it has a reply button and so does yours. Weird.
Ah, no worries! Replies seem to get throttled sometimes when the site detects a lot of nested replies quickly and it intentionally delays the ability to reply a bit. I've always assumed that it's intended as a way to try to mitigate threads that potentially are devolving into flamewars.
Frustratingly, they're not by default though; you need to explicitly use `--locked` (or `--frozen`, which is an alias for `--locked --offline`) to avoid implicit updates. I've seen multiple teams not realize this and get confused about CI failures from it.
The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on versions that don't specify a different operator, so "1.2.3" means "1.2.x, where x >= 3". For reasons that have never been clear to me, people also seem to really like not putting the patch version in though and just putting stuff like "1.2", meaning that anything other than a major version bump will get pulled in.
> The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on versions that don't specify a different operator, so "1.2.3" means "1.2.x, where x >= 3". For reasons that have never been clear to me, people also seem to really like not putting the patch version in though and just putting stuff like "1.2", meaning that anything other than a major version bump will get pulled in.
Not quite: "1.2.3" = "^1.2.3" = ">=1.2.3, <2.0.0" in Cargo [0], and "1.2" = "^1.2.0" = ">=1.2.0, <2.0.0", so you get the "1.x.x" behavior either way. If you actually want the "1.2.x" behavior (e.g., I've sometimes used that behavior for gmp-mpfr-sys), you should write "~1.2.3" = ">=1.2.3, <1.3.0".
I don't know how I got this wrong because I literally went and looked at that page to try to remind myself, but I somehow misread it, because you're definitely right. This probably isn't the first time I've gotten this wrong either.
From thinking it through more closely, it does actually seem like it might be a little safer to avoid specifying the patch version; it seems like putting 1.2.3 would fail to resolve any valid version in the case that 1.2.2 is the last non-yanked version and 1.2.3 is yanked. I feel like "1.2.3" meaning "~1.2.3" would have been a better default, since it at least provides some useful tradeoff compared to "1.2", but with the way it actually works, it seems like putting a full version with no operator is basically worse than either of the other options, which is disappointing.
I haven't heard anything about this, but I really wish it was there by default. I don't think the way it works right now fits anyone's expectations of what the lockfile is supposed to do; the whole point of storing the resolved versions in a file is to, well, lock them, and implicitly updating them every time you build doesn't do that.
Since you're here, and you happened to indirectly allude to something that seems to have become increasingly common in the Rust world nowadays, I can't help but be curious about your thoughts on libraries checking their lockfiles into version control. It's not totally clear to me exactly when or why it became widespread, but it used to be relatively rare for me to see in open source libraries in the first few post-1.0 years of Rust, whereas at this point I think it's more common for me to see than not.
Do you think it's an actively bad practice, completely benign, or something in between where it makes sense in some cases but probably should still be avoided in others? Offhand, the only variable I can think of that might influence a different choice is that maybe closed-source packages been reused within a company (especially if trying to interface with other package management systems, which I saw firsthand when working at AWS but I'm guessing is something other large companies would also run into), but I'm curious if there are other names nuances I haven't thought of
Sure, but according to semver it's also totally fine to change a function that returns a Result to start returning Err in cases that used to be Ok. Semver might be ae to project from your Rust code not compiling after you update, but it doesn't guarantee it will do the same thing the next time you run it. While changes like that could still happen in a patch release, I'd argue that you're losing nothing by forgoing new API features if all you're doing is recompiling the existing code you have without making any changes, so only getting patches and manually updating for anything else is a better default. (That said, one of the sibling comments pointed out I was actually wrong about the implicit behavior of Cargo dependencies, so what I recommended doesn't protect from anything, but not for the reasons it sounds like you were thinking).
Some people might argue that changing a function to return an error where it didn't previously would be a breaking change; I'd argue that those people are wrong about what semver means. From what I can tell, people having their own mental model of semver that conflicts with the actual specification is pretty common. Most of the time when I've had coworkers claim that semver says something that actively conflicts with what it says, after I point out the part of the spec that says something else, they end up still advocating for what they originally had said. This is fine, because there's nothing inherently wrong with a version schema other than semver, but I try to push back when the term itself gets used incorrectly because it makes discussions much more difficult than they need to be.
My experience has been that while there's significant granularity in terms of features, in practice very few people actively go out of their way to prune the default set because the ergonomics are kind of terrible, and whether or not the default feature set is practically empty or pulls in tons of stuff varies considerably. I felt strongly enough about this that I wrote up my only blog post on this a bit over a year ago, and I think most of it still applies: https://saghm.com/cargo-features-rust-compile-times/
The A/B testing is by far the most objectionable thing from them so far in my opinion, if only because of how terrible it would be for something like that to be standard for subscriptions. I'd argue that it's not even A/B testing of pricing but silently giving a subset of users an entirely different product than they signed up for; it would be like if 2% of Netflix customers had full-screen ads pop up and cover the videos randomly throughout a show. Historically the only thing stopping companies from extraordinarily user-hostile decisions has been public outcry, but limiting it to a small subset of users seems like it's intentionally designed to try to limit the PR consequences.
The best possible situation that I can imagine is that Anthropic just wanted to measure how much value does Claude Code have for Pro users and didn't mean to change the plan itself (so those users would get CC as a "bonus"), but that alone is already questionable to start with.
At least personally, it feels like the choices are
the one that's okay with being used for mass surveillance and autonomous weapons targeting, the one that's on track to get acquired by the AI company that dragged its feet in getting around to stopping people from making child porn with it, the one that nobody seems to use from Google, and the one that everyone complains about but also still seems to be using because it at least sometimes works well. At this point I've opted out of personal LLM coding by canceling my subscription (although my employer still has subscriptions and wants us to keep using them, so I'll presumably keep using Claude there) but if I had to pick one to spend my own money on I'd still go with Claude.
Given some of the other claims that have come out of the "Justice" Department under this administration, I'd be curious whether there are any more reputable sources on the matter. They've already been making a habit of trying to target people Trump dislikes with flimsy prosecutions (e.g. Don Lemon for covering a protest at a church).
Even beyond that, there's pretty clear evidence of the level of professional conduct of the department being pretty low, like their lawyers literally informing a judge that they lied about the basis of their arguments[0], cases getting dismissed because they were filed by someone who wasn't even a valid US Attorney[1] but who continued to claim to be one for another couple of months until a court order threatening her with contempt charges (by a Trump-appointed judge, for what it's worth)[2], and in one instance a lawyer literally requesting that a judge hold them in contempt because their job "sucks"[3].
reply