* The `require` directives from the `go.mod` files of your dependencies are always ignored.
Those two combined, mean that there's no easy way to fork a dependency. It's doable, but some of the maintenance overhead could have been avoided.
We don't even get a `go mod tidy` flag that lets us say, "yes, I understand the risks, just copy any `replace` directives that you find in my dependencies". With a flag like that, even if the `replace` directive is still copied everywhere, at least it's automatically copied during a routine `go mod tidy` invocation.
They already have `// indirect` comments, so those could have a `// indirect, replaced by X` comment or something like that.
> My recommendation for DNS - on servers - would be to install unbound locally and use that.
At least on Ubuntu 26.04, you can't easily bind Unbound on a WireGuard interface because of services dependency order, so the Unbound service errors during system boot because the WireGuard interface doesn't exist yet. And IIRC neither `ip-transparent` nor `interface-automatic` fixed it.
I don't know, if I didn't know Mullvad or GrapheneOS, and saw ad on TV, I'd probably check it out.
Or an ad about an ISP with IPv6 support, at the very least it would make me check if my current ISP finally added support, and consider options otherwise.
Or one about some new colocation service that happens to open near my location, you bet I'd check out their website and maybe even pay them a visit.
Can someone explain why this is a bad thing, while at the same time it's a good thing to say stuff like "put a computer to sleep", "hibernate", "killing" processes, processes having "child" processes, "reaping", "what does the error say?", "touch", etc?
To me that's just language, and humans just using casual language.
Dijkstra once said that "The question of whether machines can think is about as interesting as that of whether submarines can swim."
I think I understand his meaning. He wasn't claiming that machines cannot think, but that one must be clear on what one means by "thinking" and "swimming" in statements of that sort. I used to work on autonomous submarines, and "swimming" was the verb we casually used to describe autonomous powered movement under water. There are even some biomimetic machines that really move like fish, squids, jellyfish, etc. Not the ones that I worked on, but still.
For me, if it's legitimate to say that these devices swim, it's not out of line to say that a computer thinks, even in a non-AI context, e.g.: "The application still thinks the authentication server is online."
It's a great question, because I do think there are many cases that are neutral, or ones we're able to responsibly distinguish or even cases where it would be an appropriate and necessary form of empathy (I'm imagining some future sci-fi reality where we actually get conscious machines, so not something that exists right now).
But I think it's also at the root of disastrous failures to comprehend, like the quasi-psychosis of the Google engineer who "knows what they saw", the now infamous Kevin Roose article or, more recently, the pitifully sad Richard Dawkins claim that Claudia (sic) must be conscious, not because of any investigation of structure or function whatsoever, but because the text generation came with a pang of human familiarity he empathized with.
There's a boundary between knowing vs. forgetting that it's a metaphor. When you use convenient language like in your examples, you tend to remain aware of the difference, or at least you can recall it when asked. When some people talk about AI, they've lost track completely.
I don't love the recommendations in TFA. The author is trying to artificially restrain and roll back human language, which has already evolved to treat a chatbot as a conversational partner. But I do think there's usefulness in using these more pedantic forms once in a while, to remind yourself that it's just a computer program.
Because it allows you to be lulled into the trap of asking an AI to post-hoc justify something it did and thinking that the response is in any way valid. There is no retrospective analysis of the underlying intent. It either is or is not based on the chain of words that came before it. And the next word it generates is purely a function of those words.
These are just words, yes, and I believe it harmless. But describing the LLM machinery as if it thinks is one thing when used as a common parlance, and another when people truly believe that there's some actual thinking or living going on. This "law" is for there to be no latter.
I think it's bad manners to bluntly tell someone they should "read up" on something because it naturally reads as a kind of a closeted accusation of not being sufficiently well informed. There are ways of broaching the topic of what background knowledge is informing their perspective that don't involve the accusation.
Just to add a small bit of anecdotal value so this comment isn't just a scold: I one time many years ago suggesting an elegant way for Twitter to handle long form text without changing it's then-iconic 140 character limit was to treat it like an attachment, like a video or image. Today, you can see a version of that in how Claude takes large pastes and treats them like attached text blobs, or to a lesser extent in how Substack Notes can reference full size "posts", another example of short form content "attaching" longer form.
I was bluntly told to "look up twitlonger", which I suppose could have been helpful if I had indeed not known about twitlonger, but I had, and it wasn't what I had in mind. I did learn something from it though, which was that it's a mode of communication that implies you don't know what you're talking about with plausible deniability, which I suspect is too irresistible to lovers of passive aggression to go unused.
It wasn't intended as such, but I take your point.
To provide a bit more context: Weizenbaum (a computer scientist in the 60s) developed ELIZA, a LISP-based chatbot that was loosely modeled on Rogerian psychotherapy. It was designed to respond in a reflective way in order to elicit details from the user.
What he found was that, despite the program being relatively primitive in nature (relying on simple natural language parsing heuristics), people he regarded as otherwise intelligent and rational would disclose remarkable amounts of personal information and quickly form emotional attachments to what was, in reality, little more than a glorified pattern-matching system.
The people who advocate for not anthropomorphizing are afraid of the implications of integrating these systems into society with implicit human framing. By attributing to AIs human qualities, we will develop empathy for them and we will start to create a role for them in society as a being deserving moral consideration.
The people who know what a "child process" is are under no false pretenses about the humanity of the underlying system.
The people who are writing op eds in major news publications about how their favorite chatbot is an "astonishing creature" and how it truly understands them are the ones who need this sort of law.
The difference is never before has the presentation of a computer and its capabilities made the person on the other end decide "Wow, this is like talking to a real person. I'm gonna date this computer"
A text input field for entering your command line(s), with a text log for the output, does indeed seem to be the crabs of software. Usually with some abstractions that allow you to write longer scripts[1] and just refer to them by a short name or alias, and compose those scripts together from your command prompt.
You could say it's the terminal[2] user interface.
While this is very pithy, we need to acknowledge and remember that there's a gulf of difference between normal terminal interfaces and command line interfaces, and whatever the chatbots are doing.
Yes, both have a prompt where you type text to do things and get text back, but the type of text you write in one is very different than what you'd write in another. Prose versus commands and so on. Oh, and normal terminals don't waste electricity and water in amounts approaching small countries.
> 1. Go, when I first saw code I wrote almost a decade ago still compiles and runs in Go, I decided to use Go for everything. There were some initial troubles when I started using it a decade ago, but now it's painless.
And fewer dependencies, and fewer vulnerabilities (if any at all, depending on your few dependencies).
Go is "only" a pain when you want to use your own copy of packages (because `replace` directives are always ignored everywhere except on the "root" package), and whenever you want to work with private Git repositories outside of the forges that have hardcoded config in the Go code (like GitHub) (because Go assumes there's an HTTPS server, and the only way to force it to use only SSH is with ugly workarounds AFAIK).
But despite this I still prefer it for personal projects because I can come back after not touching it for years, and the most I need to do is maybe update `golang.org/x/net` or something like that.
> I'm also not impressed with a carrot disclosure that looks like this. Running a python script to compromise a locally hosted instance? Bruh, you have physical hardware and host shell access. That python script could be doing anything including running as root.
> Show us the exploit hitting a remote server.
Watch out, their script works on HN too, as a proof here's me logging in to YOUR computer's root account (a bit more redacted for obvious reasons):
$ python3 ./poc/chain_alpha.py --target dangus > out.txt
$ grep Backdoor out.txt | sed -r 's@[^:]+$@ [REDACTED]@g'
[+] Backdoor admin created: [REDACTED]
$ grep IP out.txt | sed -r 's@[^:]+$@ [REDACTED]@g'
[+] IPv4 address for dangus: [REDACTED]
$ grep 'debug2: shell' out.txt
[+] debug2: shell request accepted on channel 0
$ tail -n12 out.txt
================================================================
[+] COMMAND EXECUTION CONFIRMED!
================================================================
Server-side output (received via SSH, with `set -x`):
+ id -u
0
+ id -g
0
================================================================
$ sha256 ./poc/chain_alpha.py
c10d28a5ff74646683953874b035ca6ba56742db2f95198b54e561523e1880d7 ./poc/chain_alpha.py
* No relative imports.
* The `require` directives from the `go.mod` files of your dependencies are always ignored.
Those two combined, mean that there's no easy way to fork a dependency. It's doable, but some of the maintenance overhead could have been avoided.
We don't even get a `go mod tidy` flag that lets us say, "yes, I understand the risks, just copy any `replace` directives that you find in my dependencies". With a flag like that, even if the `replace` directive is still copied everywhere, at least it's automatically copied during a routine `go mod tidy` invocation.
They already have `// indirect` comments, so those could have a `// indirect, replaced by X` comment or something like that.