> What is wrong with these people who try to block certain content?
Porn is just the thin end of the wedge (as was "violence in video games" a generation ago) - porn is something society considers as distasteful, so politicians are less likely to go on record as supporting porn. Once the porn bans go into effect, they'll move onto the next target in the conservative playbook: gay marriage, birth control/abortion access, etc.
I wish we had picked a better name than "thread safety". This is really more like "concurrency safety", since it applies even in the absence of hardware threads.
Other than in the sense of SMT (Hyper-Threading)? I don't think so. Threads are a software concept.
One can distinguish between native (OS) threads and green (language-runtime) threads which may use a different context-switching mechanism. But that's more of a spectrum in terms of thread-safety; similar to how running multiple threads on a single CPU core without SMT, single CPU core with SMT, multiple CPU cores, with different possible CPU cache coherency guarantees, create a spectrum of possible thread-safety issues.
Runtime-switched tasks cannot lead to memory unsafety unless multiple OS threads are involved, because that's the only case where torn writes are possible. And a typical configuration of Go will not be running multiple OS threads unless multiple hardware threads (aka "logical cores", "virtual processors" etc.) are available.
Thread-safety isn’t just about word tearing. It’s also about state invariants in your program. Even if all your threads are green threads on the same OS thread, you still have to guard critical sections that check-and-modify, or that temporarily break the invariants of state that is observable by other threads, when there’s anything in-between that may lead to a context switch. Otherwise, while you may be free of word tearing, you might still have “torn” program state.
On a single-core CPU, word tearing may similarly be absent between OS threads, but you still have to guard any critical section.
I agree with user swiftcoder that there are concurrency issues (like the above) even in the absence of hardware parallelism, or of multiple OS threads (which by themselves don’t imply hardware parallelism). I disagree that “thread-safety” isn’t an appropriate term for them. Those issues are part of what thread-safety was always about.
Theoretically you can construct a loop counter that overflows, but I don't that there is any reasonable way to do it accidentally?
Within safe rust you would likely need to be using an explicit .wrapping_add() on your counter, and explicitly constructing a for loop that wasn't range-based...
The scenarios in the article are all about mission-critical disaster recovery - we don't even trust the majority of our human colleagues with those scenarios! AI won't make inroads there without humans in the loop, until AI is 100% trustworthy.
Right, so: having an agent go drop index segments from a search cluster to resolve a volume utilization problem is a bad idea, rather than just suggesting "these old index segments are using up 70% of the storage on this volume and your emergency search cluster outage would be resolved if you dropped them, here's how you'd do that".
But there are plenty of active investigative steps you'd want to take in generating hypotheses for an outage. Weakly's piece strongly suggests AI tools not take these actions, but rather suggest them to operators. This is a waste of time, and time is the currency of incident resolution.
We don't need humans to be perfect to have reliable responses to critical situations. Systems are more important than individuals at that level. We understand people make mistakes and design systems and processes to compensate.
The problem with unattended AI in these situations is precisely the lack of context, awareness, intuition, intention, and communication skills.
If you want automation in your disaster recovery system you want something that fails reliably and immediately. Non-determinism is not part of a good plan. Maybe it will recover from the issue or maybe it will delete the production database and beg for forgiveness later isn't what you want to lean on.
Humans have deleted databases before and will again, I'm sure. And we have backups in place if that happens. And if you don't then you should fix that. But we should also fix the part of the system that allows a human to accidentally delete a database.
But an AI could do that too! No. It's not a person. It's an algorithm with lots of data that can do neat things but until we can make sure it does one particular thing deterministically there's no point in using it for critical systems. It's dangerous. You don't want a human operator coming into a fire and the AI system having already made the fire worse for you... and then having to respond to that mess on top of everything else.
Who is sending in untrained people to manage fires? Maybe that organization deserves what's coming to them.
An extreme example: nuclear reactors. You don't want untrained people walking into a fire with the expectation that they can manage the situation.
Less extreme example: financial systems. You don't want untrained people walking into a fire losing your customers' funds and expect them to manage the situation.
We don't throw new-hires in the deep end of the on call rotation on their first day. We make sure they learn the systems, we provide them with runbooks, assign an experienced mentor for their first on call rotation, and have a clear escalation path if they are in over their heads or need additional resources.
As long as you stick within pretty strict limits. I'm seeing more and more folks from non-programming backgrounds who are running up against the limits of vibecoding - and they aren't prepared for just how expensive some of the larger mistakes will be to fix, if they end up having to bring actual software engineers in to fix/scale their products
Yeah, I can see that. But for human people not at work there are no products. There are no "expensive" mistakes. There's just the ability to automate tasks and do simple things they, I, couldn't do before. No reason at all to involve any businesses now.
Or at least before $project would take weeks instead of an hour. I don't know C but now I can just have an LLM translate/port it to perl and I can fix the mistakes in that domain where I do have skill.
if traffic has been declining, their physical datacenter is likely to have been over provisioned for current usage levels. Laying off most of their SREs is just another bonus for the bottom line
Porn is just the thin end of the wedge (as was "violence in video games" a generation ago) - porn is something society considers as distasteful, so politicians are less likely to go on record as supporting porn. Once the porn bans go into effect, they'll move onto the next target in the conservative playbook: gay marriage, birth control/abortion access, etc.
reply