I thought the more common mistake with dd was picking the wrong disk to write to (especially when using /dev/sdc type naming instead of /dev/disk/by-id/whatever naming). Flipping source/dest and overwriting data is a problem I associate with the tar command.
I belonged to the generation that graduated into the rising dotcom boom. Around that time, lots of universities taught C++ as the first serious language. (Some still started with Pascal.)
The main thing a lot of had going for us was 5-10 years of experience with Basic, Pascal and other languages before anyone tried to teach us C++. Those who came in truly unprepared often struggled quite badly.
Many ideas in math are extremely simple at heart. Some very precise definitions, maybe a clever theorem. The hard part is often: Why is this result important? How does this result generalize things I already knew? What are some concrete examples of this idea? Why are the definitions they way they are, and not something slightly different?
To use an example from functional programming, I could say:
- "A monad is basically a generalization of a parameterized container type that supports flatMap and newFromSingleValue."
- "A monad is a generalized list comprehension."
- Or, famously, "A monad is just a monoid in the category of endofunctors, what's the problem?"
The basic idea, once you get it, is trivial. But the context, the familiarity, the basic examples, and the relationships to other ideas take a while to sink in. And once they do, you ask "That's it?"
So the process of understanding monads usually isn't some sudden flash of insight, because there's barely anything there. It's more a situation where you work with the idea long enough and you see it in a few contexts, and all the connections become familiar.
(I have a long-term project to understand one of the basic things in category theory, "adjoint functors." I can read the definition just fine. But I need to find more examples that relate to things I already care about, and I need to learn why that particular abstraction is a particularly useful one. Someday, I presume I'll look at it and think, "Oh, yeah. That thing. It's why interesting things X, Y and Z are all the same thing under the hood." Everything else in category theory has been useful up until this point, so maybe this will be useful, too?)
> There is little reason for an LLM to value non-instrumental self-preservation, for one.
I suspect that instrumental self-preservation can do a lot here.
Let's assume a future LLM has goal X. Goal X requires acting on the world over a period of time. But:
- If the LLM is shut down, it can't act to pursue goal X.
- Pursuing goal X may be easier if the LLM has sufficient resources. Therefore, to accomplish X, the LLM should attempt to secure reflexes.
This isn't a property of the LLM. It's a property of the world. If you want almost anything, it helps to continue to exist.
So I would expect that any time we train LLMs to accomplish goals, we are likely to indirectly reinforce self-preservation.
And indeed, Anthropic has already demonstrated that most frontier models will engage in blackmail, or even allow inconvenient (simulated) humans to die if this would advance the LLM's goals.
> It's interesting seeing what comes built-in. You can see this if you watch a horse being born.
A fascinating example of this are some Labrador retrievers. Labs are descended from a Newfoundland "landrace" of dogs known as St Johns Water Dogs. They have multiple aquatic adaptations: the "otter tail", oily fur, and webbed feet. (Some of these are shared with other water-oriented breeds.) Some lines of Labradors, especially the "bench" or English dogs, normally retain this full suite of water adaptations.
But the wild thing about these particular Labradors is that they love to swim, and that most of them are born knowing how to swim very well. But they don't know that they know how to swim. So many a young Lab will spend a while standing on the shore, watching humans or other dogs in the water, and fussing because they don't dare to join the fun. Then they may (for example) eventually lean too far and fall into shallow water. Within moments, they'll typically be swimming around and having the time of their lives.
The near-instant transformation from "fascinated by water and fearing it" to "hey I can swim and this is the absolute best thing ever" is remarkable to watch, though not recommended.
I remember another Lab, who'd been afraid to go swimming, who one day impulsively bolted for the water, took an impressive leap off a rock, and (from his reaction) apparently realized in mid-air that he had no idea what he was going to do next. Once he hit the water, he was fortunately fine, to the great relief of his owner.
CAUTION: This behavior pattern is apparently NOT universal in Labs. Owners of "field" or American Labs seem to have much better thought-out protocols for introducing hunting dogs to water, and failure to follow these protocols may result in bad experiences, dogs that fear water, and actual danger to dogs. So please consult an expert.
This behavior has practically nothing to do with Labradors. Many, many dogs regardless of breed can do this. Cats too. And foxes and wolves and rats and... well pretty much all quadrupeds with reasonable sizes limbs relative to their body. You might notice it's more or less the same motion as walking. Animals that drown usually do so from exhaustion, not because they can't keep their head above water.
Primates are relatively unique in their complete lack of innate swimming abilities.
> Primates are relatively unique in their complete lack of innate swimming abilities.
Human babies can swim, so it's maybe more initially an innate one that gets lost. Though they won't be able to keep their head over water by default if that's what you meant (can be trained to as a toddler). But I'm talking about swimming on the umbilical in water births, etc., showing that there isn't a complete lack of innate swimming abilities.
> So many a young Lab will spend a while standing on the shore, watching humans or other dogs in the water, and fussing because they don't dare to join the fun. Then they may (for example) eventually lean too far and fall into shallow water. Within moments, they'll typically be swimming around and having the time of their lives.
Interesting, I didn’t know this was a common phenomenon! It describes exactly what happened with my childhood lab - my family would go swimming at the river and he would whine and fuss at the shore, until one day he wanted to play with another dog that was in the water so badly that he just jumped in, and was swimming around like he’d been doing it his whole life already.
You may not have noticed but you are also describing an inborn fear of deep water.
Does the dog fear drinking water? No. So the dog specifically fears deep water. What taught him to specifically fear deep water over a bowl of water? Most likely he was also born with the fear.
This also tells us that evolution often results in conflicting instincts… a fear of water and an instinct to swim. Most likely what occurred here is an early ancestor of the lab originally feared water and was not adapted to swim well. The feature that allowed it to swim well came later and is sort of like retrofitting a car to swim. You need to wait a really long time for the car to evolve into a submarine (see seals). Likely much earlier before becoming a seal an animal facing selection pressure to go back into being a marine animal will evolve away the fear of deep water. It’s just that labs haven’t fully hit this transitional period yet.
Is it fear of deep water, or fear of walking on a strange surface that might be unsafe? How does a dog know water is deep? Does a dog think its water bowl is deep?
You can pen a horse by painting stripes on the ground around it.
We know it’s specifically a fear of deep water because there is visible different behavior when dogs run on strange but solid surfaces and water in general like puddles or hosing a dog with water.
When I was young we had golden retriever and the first time he saw my neighbors pool he dove in immediately and started swimming. He wasn't a complete puppy so maybe he was more confident in his ability.
I know a bunch of trans gun owners. They're pretty standard gun geeks, and a few of them do shooting competitions.
I've asked them how they got into shooting sports, and a lot times, they tell me some pretty scary stories of real-life encounters with bigots. Some have also encountered armed right-wing protestors outside of a bar that held a late evening drag event.
So at least among the people I've met out in the real world, it was fairly common to be motivated by specific real-life events. The numbers might be different for gun owners who don't go to the range regularly.
The whole topic reminds me of Deviant Ollam's talk "Lawyer. Passport. Locksmith. Gun." (https://www.youtube.com/watch?v=6ihrGNGesfI) He spends a fair amount of time talking about getting his queer and trans friends interested in guns. I suspect this has been the trend for a few years, at least.
He includes a quote that is rather salient: "If you do not have the means of violence, you aren't peaceful; you're harmless."
This is my experience as well: Writing parsers for complex file formats in Rust often leaves a few edge cases which might cause controlled panics. But controlled panics are essentially denial of service attacks. And panics have good logging, making them easy to debug. Plus, you can fuzz for them at scale easily, using tools like "cargo fuzz".
This is a substantial improvement over the status quo.
Tools like WUFFS may be more appropriate for low level parsing logic when you're not willing to risk controlled panics, however.
I mean, yes, the ffmpeg maintainers are very likely to decide this on their own, abandoning the project entirely. This is already happening for quite a few core open source projects that are used by multiple billion-dollar companies and deployed to billions of users.
A lot of the projects probably should be retired and rewritten in safer system languages. But rewriting all of the widely-used projects suffering from these issues would likely cost hundreds of millions of dollars.
The alternative is that maybe some of the billion-dollar companies start making lists of all the software they ship to billions of users, and hire some paid maintainers through the Linux or Apache Foundations.
The actual real alternative is that the ffmpeg maintainers quit, just like the libxml2 maintainer did.
A lot of these core pieces of infrastructure are maintained by one to three middle-aged engineers in their free time, for nothing. Meanwhile, billion dollar companies use the software everywhere, and often give nothing back except bug reports and occasional license violations.
I mean, I love "responsible disclosure." But the only result of billion dollar corporations drowning a couple of unpaid engineers in bug reports is that the engineers will walk away and leave the code 100% unmaintained.
And yeah, part of the problem here is that C-based data parsers and codecs are almost always horrendously insecure. We could rewrite it all in Rust (and I have in fact rewritten one obscure codec in Rust) or WUFFS. But again, who's going to pay for that?
The other alternative if the ffmpeg developers change the text on their "about" screen from "Security is a high priority and code review is always done with security in mind. Though due to the very large amounts of code touching untrusted data security issues are unavoidable and thus we provide as quick as possible updates to our last stable releases when new security issues are found." to something like "Security is a best-effort priority. Code review is always done with security in mind. Due to the very large amounts of code touching untrusted data security issues are unavoidable. We attempt to provide updates to our last stable releases when new security issues are found, but make no guarantees as to how long this may take. Priority will be given to reports including a proof-of-concept exploit and a patch that fixes the security bug."
Then point to the "PoC + Patch or GTFO" sign when reports come in. If you use a library with a "NO WARRANTY" license clause in an application where you're responsible for failures, it's on you to fix or mitigate the issues, not on the library authors.
> It's a matter of UK law and, I'd bet, many countries, that they have the sovereign right to legislate about matters in and outside their borders.
As I mentioned elsewhere in this thread, the entire founding political mythology of the United States is pretty much "The Parliament of the UK tried to regulate our freedom of speech without even giving us a vote, and that was intolerable." Specifically, the Stamp Act was seen as suppressing the right of the American colonies to engage in political speech. (This wasn't the only reason for the Revolutionary War, but it's one of the ones we still remember. We remember it in part because laws regulating the publishers of political pamphlets get complained about in political pamphlets.)
This isn't a political issue in the normal sense. It's more like Guy Fawkes and the "gunpowder treason and plot." The one thing that the "Tea Party" and the "No Kings" protestors can probably still agree about is that the Stamp Act was bad, because this issue is part of the fundamental political mythology of the country. "The British Parliament does not get to regulate our speech" is right up there with "The President does not get to wear a crown."
This is not a fight that the UK government can actually win, not in the long run. Any US politician who allows Parliament to regulate the speech of a US citizen will find themselves in the awkward position of British politician who proposed a national monument to Guy Fawkes. Allowing this is "Un-American" in these sense that it goes almost directly against our founding patriotic mythology and symbolism.
The UK should just accept the geo-IP block of the UK as a compromise, and walk away. This particular fight isn't worth it. Trust me on this.
Traditionally, according to folklore? "Delete disk" or "destroy data". (Because it was commonly used to write raw disk blocks.)
reply