- > The tech industry loves to abstract away the human. Users become “MAUs.” Problems become “pain points.” Customers become “conversions.”
The LLM loves to torture concepts into statements with pithy veneers and three-item. Punctuated. Lists. “Pain points” as an example, really? All of these terms are just more specific than the ones they’re contrasted with, which don’t have much of a human element to them to begin with.
The irony of bemoaning this while AI-mimicking a team of people and getting a computer to write for you in its own voice…
- There are already user-facing preferences for all of the AI features currently in Firefox. Some of them you don’t even have to go into Settings for, just right-click > Remove AI chatbot. They’re annoying, but I appreciate that they still need to be explicitly approved by the user to be enabled (for now).
- If you didn’t mount docker.sock or any directory above it (i.e. / or /run by default) or run your containers as --privileged, you’re probably fine with respect to this angle. I’d still recommend rootless containers under unprivileged users* or VMs for extra comfort. Qubes (https://www.qubes-os.org/) is good, even if it’s a little clunkier than it could be.
* but if you’re used to bind-mounting, they’ll be a hassle
Edit: This is by no means comprehensive, but I feel compelled to point it out specifically for some reason: remember not to mount .git writable, folks! Write access to .git is arbitrary code execution as whoever runs git.
- Hard for it not to be worthwhile, since it’s free for them. Same automated exploit run across the entire internet.
- Seconding what others have said about preferring to read bad human writing. And I don’t want to pick on you – this is a broadly applicable message prompted by a drop in the bucket – but please don’t publish articles beyond your ability to fact check. Just write what you actually know, and when you’re making a guess or you still have open questions at the end of your investigation, be honest about that. (People make mistakes all the time anyway, but we’re in an age where confident and detailed mistakes have become especially accessible.)
- Unintentional vulnerabilities in Docker and the kernel aside, it can only do that if it has access to the Docker API (usually through a bind mount of the Unix socket). Having access to the Docker API is equivalent to having root on the host.
- > Here’s the test. If /tmp/.XIN-unix/javae exists on my host, I’m fucked. If it doesn’t exist, then what I’m seeing is just Docker’s default behavior of showing container processes in the host’s ps output, but they’re actually isolated.
This article’s LLM writing style is painful, and it’s full of misinformation (is Puppeteer even involved in the vulnerability?)./tmp/.XIN-unix/javae & rm /tmp/.XIN-unix/javae - Weirdly, what’s currently linked in the article is https://www.newyorker.com/magazine/2024/12/16/oliver-sacks-c..., which doesn’t exist.
Unrelated(?) classiness:
> In his own journals, Sacks admitted he had given his patients "powers (starting with powers of speech) which they do not have." Some details, he acknowledged, were "pure fabrications."
— post
> But, in his journal, Sacks wrote that “a sense of hideous criminality remains (psychologically) attached” to his work: he had given his patients “powers (starting with powers of speech) which they do not have.” Some details, he recognized, were “pure fabrications.”
— New Yorker article
- er, *urllib3’s name comes from urllib2 in the standard library.
- On top of generating types dynamically being slow and bad as quietbritishjim said, “str values that also happen to be valid identifiers” is a very limiting dict key requirement.
- You can do that for O(N), but the problem can be solved in O(k).
- The property in question is `hasattr(x, "pop") is False`.
> If you want to extend the above definition so that negative proofs concerning the parent should also hold true for the child, then subtyping becomes impossible since all parent and child types must be identical, by definition.
The distinction isn’t “negative proofs”, but yes, that’s their point. In Python, you have to draw a line as to which observable properties are eligible.
- > Why don’t the textbooks explain why the algorithm is correct?
The good ones do!
> Should I be familiar with every step of Dijkstra’s search algorithm and remember the pseudocode at all times?
If it’s the kind of thing you care to be familiar with, then being able to rederive every step of the usual-suspect algorithms is well within reach, yes. You don’t need to remember things in terms of pseudocode as such, more just broad concepts.
- > Can you type it from memory, without looking it up?
Well, yeah, but that’s not a very useful heuristic for people who are already aware of the algorithms in question. If you ask people to come up with a way from scratch – probably without explicitly asking, in order to get better success, like by watching how they sort cards – I bet they won’t tend to come up with bubble sort. Maybe that says something about the relative intuitiveness of the approaches? Or not.
- In practice, semver is very helpful. Its major benefit is allowing packages to declare compatibility with versions of their own dependencies that don’t exist yet. (Distrusting updates and pinning versions is important and correct, but it’s not a “versioning method” that stands in contrast to semver or anything. That’s what lockfiles are for.) The pre-semver Python package ecosystem is a good example of what happens without it: fresh installs of packages break all the time because they have open-ended or overly permissive upper bounds on their dependencies. If they were to specify exact preexisting upper bounds, they’d slow down bugfixes (and in Python, where you can only have one version of a package in a given environment, new features) and add maintenance busywork; I’m not aware of any packages that choose this option in practice.
> You have released version 1.0.0 of something. Then you add a feature and fix a bug unrelated to that feature. Are you at version 1.1.0 or 1.1.1? Well, it depends on the order you added your changes, doesn't it? If you fixed the bug first you'll go from 1.0.0 to 1.0.1 to 1.1.0, and if you add the feature first you'll go from 1.0.0 to 1.1.0 to 1.1.1. And if that difference doesn't matter, then the last digit doesn't matter.
It depends on the order you released your changes, yes. If you have the option, the most useful order is to release 1.0.1 with the bugfix and 1.1.0 with both changes, but you can also choose to release 1.1.0 without the bugfix (why intentionally release a buggy version?) and then 1.1.1 (with or without 1.0.1), or just 1.1.0 with both changes. You’re correct that the starting point of the patch version within a particular minor version doesn’t matter – you could pick 0, 1, or 31415. You can also increment it by whatever you want in practice. All this flexibility is a total non-problem (let alone a problem with the versioning scheme, considering it’s flexibility that comes from which releases you even choose to cut – semver just makes the relationship between them clear), and doesn’t indicate that the patch field is meaningless in general. (Obviously, you should start at 0 and increment by 1, since that’s boring and normal.)
Sure, it’s impossible to classify breaking changes and new features with perfect precision, and maintainers can make mistakes, but semver is pretty clearly a net positive. (It takes almost no effort and has no superior competitors, so it would be hard for it not to be.)
- That was how psycopg2 did it, but now the package is psycopg (again) version 3, as it should be. Python package management has come a long way since psycopg 1 was created.
urllib2/3’s etymology is different: urllib2’s name comes from urllib in the standard library.
- It’s not necessary to cater to the absolute least competent end user to begin with, but inserting slowdown bugs does not even achieve that. (Note that the bit about the breaking of dependent libraries you’re quoting is still not actually a service being affected.)
- A breaking change in a dependency doesn’t cause a full-stop to a service at all. The old version continues to work. Making subtly harmful changes so that new broken versions sneak in is just a bad idea and totally unnecessary.
Clearly, either this was before Signal had its username-lookup-only feature, or you opted into letting people find you by your phone number. At that point, the information is already effectively leaked in the same way (it’s easy for anyone to enumerate all phone numbers, let alone for you to enumerate your own contacts or vice versa), and if the notification surprised you then the absence of the notification would simply have been giving you a false sense of security.
Communication by non-phone-number identifiers is critically important, and I’m glad for recent Signal developments in that direction and hopeful for more in the future, but opting into phone-number-based communication and complaining that your contacts were merely notified about the communication option they would have been able to access anyway on a security or privacy basis is silly. The fact that this information (your contacts) passes through Signal is much more objectionable to me, even though they do the SGX thing, and I would never recommend allowing it access to your contacts for that reason.