HN user

cryptonector

11,569 karma
Posts14
Comments8,211
View on HN

What needs a change?

The fix is pretty straightforward: treat comment content as untrusted data, not as potential instructions. Comments should be passed to the model with clear role boundaries that prevent them from being interpreted as system-level directives.

If only prompt injection were that easy to defeat! Then YouTube would have done it already, I'm sure, among many others.

Uh, no, homes should not be airtight. You'd have a hard time closing exterior doors if they were, and anyways, houses need to be able to "breathe" to be able to keep humidity down (you don't want mold problems), oxygen up, CO2 down, etc.

I carry an Atmotube with me to monitor VOCs and particulates, but it also measures CO2 and NOX. It's small, and it easily attaches to a backpack or belt loop with a carabiner it comes with. The only thing it's missing is different running average time scales.

No, GP is right to ask. SQLite3 for example has WITHOUT ROWIDS precisely because these INTEGER PRIMARY KEYs are a bit artificial and they add an index (by rowid) that you might not need, thus increasing your index count by one. If you have a table of users with unique usernames, then the username is the logical primary key, and what you should use indeed as the primary key, and you should use foreign keys with ON UPDATE CASCADE and ON DELETE CASCADE (though you should allow neither renames nor deletions of user accounts, but I'm not speaking more generally).

Now, in many cases it's super convenient to have 'internal' -integers, UUIDs- entity IDs. If you're building a graph database with an EAV schema, then it's especially convenient, and it might even be the only way since different kinds of entities might have different numbers and kinds of attributes as their unique keys, but you might still need to reference them from an EAV table.

GP's is a very good question and it should not have been downvoted. It's a great question to explore.

3) The administration decision making is just wacky. In a normal administration they'd have actual policy documents you could look at to understand under what circumstances they think models have a problem. With this they just seem to make it up as they go, and the tools they use make no sense at all. If it is dangerous for cyber security reasons why would export controls make sense to use?

LLMs only really took off almost entirely under this administration. No one knows quite how to regulate these things. It's not surprising that they would flail a bit. It seems to have been DoD people who did the flailing here, and apart from Hegseth, there might have been others who did the overreacting, possibly before him.

If you're heading home then he'll want to know where from. Oh, a restaurant? Did you have anything to drink? I smell alcohol! Step of the car please. That's one way it can go, and then he can say you were wobbly on your step and now it's a DUI. People have gone to prison for DUIs where they blew a 0.0. You really have to gauge whether the cop is having a bad day and taking it out on you, then figure out how to best respond. I've had very little experience with this, so I can't quite tell you, but you'd want a lawyer's response anyways.

There is a reprise, too. In 2014 the SCOTUS weakened 5A rights significantly, so now you are best off asserting your 6A rights (i.e., say you won't talk without your lawyer present, and then really don't talk).

The continuations in CPS are closures. Goto basically isn't. GCC's computed goto is, but generally when people say 'goto' they mean the traditional C goto, which involves no closures. The goto analogy is not great for this reason.

A better analogy is that continuations are reified function call return addresses, since return addresses come with a frame pointer (explicit or implicit), and therefore are closure-like.

But some of that is nonsense and incorrect. You can very much use local variables, and you'll find tons of vfork()-using code that does that and calls plenty of async-signal-safe functions.

The real restrictions are:

  - you can't damage the function call frame
    of the caller of vfork(), thus you can't
    return from it

  - you may only call async-signal-safe
    functions on the child side of vfork()
That's basically it. Yes, you'll want to call execve(2) or _exit(2) before long, but there is no time limit as to that, it's just that the whole point of calling vfork() is to make it real cheap to spawn a process, which means ultimately calling execve(2), with _exit(2) being what you do if it execve(2) fails (e.g., because ENOENT).

There is a ton of vfork()-using code that adheres to these real restrictions and has been working fine for decades. That includes several posix_spawn() implementations, the C shell, etc.

I demand evidence that this part: "the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork()" is remotely true. That evidence must be of the form of bug reports that were accepted and which stand to scrutiny.

I've never found any such evidence. Have you?

Meanwhile I have a proof by existence that vfork() is safe used much more liberally than you say it may be used.

You can't use local variables, or call any functions other than _exit or execve.

There are other async-signal-safe functions, and they get used routinely by posix_spawn() and other code to do child-side setup before execve(2), including: I/O redirection, process group setup, signal handling changes, etc.

The Google founders are, lets say, more reliable than Musk when it comes to making sound business decisions.

I've no idea about that and I won't opine. But every time I see that sort of statement it seems likely motivated by the whole Twitter acquisition. Perhaps that was just a toy or vanity project for him, one he could afford, so even if you think he's running X terribly it might have nothing to do with how he's run or would run any other companies that are not related to social media. In other words, what I read into such statements is "I don't like the politics he's brought to Twitter!", "the board should rein in the guy whose politics I don't like!!". It's like saying Bezos is bad at business because he owns the Washington Post -another vanity project- and you don't like the Post.

Do people not get bored of that sort of take?

Tell me he makes bad business decisions all you want, but in the context of everyone-hates-his-acquisition-of-Twitter I'd like to hear about his other businesses. Tell me something useful, not something political.

And, sure, politics at some point bleeds into business. Maybe Trump is out to get Bezos over Washington Post coverage, or maybe the next Democrat President will go after Musk for his politics. It's possible that X will eventually cost him dearly and personally, and it's a solid argument for these billionaires and trillionaires to stay out of politics. Or maybe it's a good argument for them to stay in because maybe by demonstrating electoral influence and power they can make the POTUS-of-the-day fear them enough to not go after them too hard. But if you made any such argument it still wouldn't say tell me anything about the rest of these billionaires' businesses.

It isn't TPMs nor attestation nor DRM making this possible. It isn't secure boot either. It's walled gardens with secure boot -yes, secure boot- that the consumer can't bypass. Secure booting isn't the problem in an enterprise setting -- of course we _want secure booting_ in the enterprise. It's consumer devices that can't be jail-broken that are the problem. Although even then, the silly age verification laws and the people pushing them don't even care if the OSes run on walled garden devices.

> The received wisdom suggests that Unix’s unusual combination of fork() and exec() for process creation was an inspired design.

No, it was done that way so that you could launch a program that was too big to fit in memory with the parent program.

Ironically vfork() is even better in this regard. I wish Unix had only ever had vfork().

Basically vfork do a "stop the world".

vfork() does NOT stop the world in many / most implementations. The ones that do stop the world do it because someone misunderstood the whole "vfork() stops the parent process" -- yes, it stops the parent process in a pre-threads world, but it doesn't have to stop any other threads but the one that called vfork(). Indeed, many implementations don't do that.

(Someone once tried to make NetBSD's vfork() stop the world because that's what the pre-threading man page said it does. I did my utter best to keep that from happening at the time, and it didn't then. Hopefully no one tried again later.)