muvlon

Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly:

> The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.

No, that does not do that. JavaScript from any other website can still talk to localhost:19421 just the same. CORS doesn't restrict anything, it loosens the default set of restrictions (ignoring preflight requests for now and assuming we're talking just about "safe" Methods). That Access-Control-Allow-Origin header just allows JavaScript running on zoom.us to read the responses when it queries localhost:19421. The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects.

Well, is this mad dash for AI producing "outcomes that are beneficial for society at large" yet? So far it looks like its mostly producing a ton of negative externalities and wealth transfer to corrupt elites.

Also, no, abandoning ethics is not an option, what a ridiculous suggestion.

If Google ever decides to "close the door" on these too, all they need to do is make Chrome always use DoH instead of classic DNS.

- electricity (from solar, hydro, nuclear, whatever). maintained by robots.

- it is repaired by robots using resources mined or reclaimed by robots.

- you guessed it, robots.

- robots with weapons.

If we actually want to prevent this doomsday scenario, I don't think it's wise to bet on "robots will never be able to do X".

We would not be able to agree on that. Already today, some of the people who would actually be able to unplug some of them (Anthropic) are worrying about "model welfare". I think you are not putting together how much of an anti-human death cult this is.

Sockets are officially specified in wasip1: https://wasi.dev/releases/wasi-p1

Notably, listen and connect are missing. But sockets themselves were in there.

> WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way?

FWIW, that's exactly what they shipped first, with WASI preview 1 (wasip1). You can still use this today, and all runtimes with any level of WASI support will be able to run it.

Most of the points listed are hardly considered lispy anymore these days, Python also has most of these.

Where Ruby's lisp lineage really shows is the fact that it's got Kernel#callcc, aka call with current continuation. It doesn't get any lispier than that!

It's a bit of in-group signaling but I think, importantly, also date signaling. A 2026 hype website looks different from a 2020 hype website looks different from a 2010 hype website. Having a generic 2026 hype website look tells visitors that you're either new or update your website's design to follow current trends.

They do the same with cars, where it's even more important and even more explicit. The design language has to change every couple years so that you can tell when somebody is driving a car older than 5 or so years. For example, currently we're doing blobs but with a few sharp features and muted colors. Before that it was more colorful and more metallic paint. Before that, in the 00s, it was pure blobs. Before that it was all sharp edges etc. Now sharp edges are beginning to make a comeback.

That's why I don't think we'll ever have the "one true design language". Fads and trends will continue, repeating themselves to a degree but also changing in new ways.

No. We have an infinitely more succinct formalism, it's Turing machines. Succinctness is not necessarily a desirable property, it just says where on the capability-tractability tradeoff something is. Turing machines can express literally anything computable, but in exchange we can't use computers to reason about them in general (Rice's Theorem). Regexes are much more limited, they famously can't even recognize HTML, but we get to automatically prove things about them.

That's true, but critical processes could mlockall() after setup, so their stuff never needs paging in.

All words are labels. You cannot make an argument without using them. "cheap rhetorical trick" or "resorting to labels" are just labels as well.

I specifically said data race, which is a known term of art and a type of language-level UB. It is separate from the races you're thinking about. Just like signed integer overflow or use-after-free, the compiler is allowed to assume data races never happen.

With this technology's death, the thread of prophecy is severed. Restore a saved game to restore the weave of fate, or persist in the doomed world you have created.

There is no uninitialized variable, I explicitly initialized it to 5.

And yes indeed, C could do what Rust does and define the order of evaluation for function arguments.

If the argument expressions are indeed side-effect-less, the compiler can always make use of the "as-if" rule and legally reorder the computation anyway, for example to alleviate register pressure.

Fair enough!

> And if it's not succeeded for 54 years, "try harder", or "just never make a mistake", is at least not the solution.

And I 100% agree. UB is way overused by these standards for how dangerous it is, and as a consequence using C (and C++) for anything nontrivial amounts to navigating a minefield.

Yes there is tons of surprising and weird UB in C, but this article doesn't do a great job of showcasing it. It barely scratches the surface.

Here's a way weirder example:

  volatile int x = 5;
  printf("%d in hex is 0x%x.\n", x, x);

This is totally fine if x is just an int, but the volatile makes it UB. Why? 5.1.2.4.1 says any volatile access - including just reading it - is a side effect. 6.5.1.2 says that unsequenced side effects on the same scalar object (in this case, x) are UB. 6.5.3.3.8 tells us that the evaluations of function arguments are indeterminately sequenced w.r.t. each other.

So in common parlance, a "data race" is any concurrent accesses to the same object from different threads, at least one of which is a write. In C, we can have a data race on a single thread and without any writes!

Ever since it's breached the mainstream, I think you can just append it to anything to make things sound funnier. It has mostly lost its meaning.

"I'm breakfastmaxxing. I'm a cerealpilled bowlcel in my milk era. I'm a slicemoded breadchad." etc.

There's a major caveat to the half-full view: You'll only stop adding new vulns that your model can find.

A threat actor with access to a better model or more money to burn on tokens may yet find more. Some of them have deep pockets, and not nearly every project will get the Glasswing treatment of free Mythos tokens.

I don't know, are we actually going to be making coffee in the case of the AGI singularity?

If you listen to the hardcore doomers, the misaligned superintelligence will curl a finger on its monkey paw and turn the planet into paperclips or something. If you listen to the most depraved boosters, AGI will remove the need for 99.999% of human workers and so we all get turned into biofuel to churn out more tokens.

Yes those are really extremely scenarios but that's how I think of the singularity. It's so alien that we cannot rule out anything.

It can spread into safe code when you build an incorrect "safe" abstraction around unsafe code. Which the Bun Rust port apparently has.

It's not surprising that a mostly straightforward translation to (partly unsafe) Rust exhibits UB.

What is a bit disappointing is that the Rust code apparently has APIs that aren't marked unsafe but may cause UB anyway. When doing this kind of translation, I'd always err on the side of caution and start by marking all/most things unsafe. Or prompt the slopbots to do the same I guess.

Then you can go in and verify the safety of individual bits step by step.

The logical next step is to replace the suicide hotline operators with AI. And maybe add a way for other people to gamble on the results.

In my head, the levels are exactly swapped. Connecting two wires together reliably is harder than through-hole in my experience. Through-hole PCBs are actually designed for solder, so surface tension basically does your job for you. Also, with the PCB you have a solid surface to push on, whereas with two wires everything's a little bit more loose. Lastly, if you want the connection between the wires to actually be reliable, you're probably looking at splicing, which takes some more skill yet.

That's not really the culture of debian to be honest. Yes they run old major and minor versions, but they do ship patch updates as fast as they can. Even on debian stable, you absolutely are supposed to update all the time. The culture of "just don't touch it" is a different one (but also exists, I've seen it).

Let's Encrypt has to be down for days before people begin to feel the pain. DNS is very different, it breaks stuff immediately everywhere.

This is one category of good alerts, but not everything.

I think alerts are to ops what tests are to dev. You have "unit alerts" for some small thing like the disk usage on a single host, "integration alerts" like literally "does the page load?" and then what you describe are "regression alerts", trying to prevent something that went wrong once from going wrong again. These are great but just like you wouldn't have 100% regression tests, I think it's also smart to try to get ahead of failures and have some common sense alerts defined.

While I hate suid as much as the next person, it's really not the problem here.

The bug that is being exploited gives you basically arbitrary page cache poisoning. At that point it's already game over. Patching a suid program is maybe the easiest way to get a root shell from that but far from the only.

And the Pentagon has historically gotten away with damn near everything even in the judicial branch by appealing to national security.

What problem is this actually solving? I've deployed DHCP countless times in all sorts of environments and its "statefulness" was never an issue. Heck, even with SLAAC there's now DAD making it mildly stateful.

Don't get me wrong, SLAAC also works fine, but is it solving anything important enough to justify sacrificing 64 entire address bits for?