what is such a shame is, well, two things: first, that these companies even do this kind of thing at all (i.e., age verification); and second, that it takes the kind of backlash this event has generated for them to cut ties with these companies. Apparently, it is too much to ask for any corporation to even give a damn about who runs or backs another corporation that they want to associate themselves with these days.
The bigger shame is that it took Peter Theil's name to get people's outraged about this. Discord handed over their users' identifications to a third party without regard for how it would be used or secured. I don't care if it was backed by Peter Theil or Mother Theresa - it's a huge problem either way.
And they'll do it again too. They'll find a new partner - one with less baggage - to do the exact same thing and few people will bat an eye.
I have as well. I find RW locks much easier to use than, say, a recursive mutex. Mainly since it took me a long time to actually understand how a recursive mutex actually works in the first place. When you want to use only the stdlib, you aren't left with many choices. At least in the STL.
Oh here we go again, someone demanding networking (of all things) in the standard library. Are you next going to demand a GUI toolkit too? Maybe an entire game engine and Vulkan/WebGPU implementation too while we're at it? Just because other languages do it does not mean it is a wise idea for C++ to follow suit. I mean, do I really need to point you to std::regex as an example of what happens when we try to add extraneous, hard to define problems to the STL? Do you really want to add something way more complicated than a regular expression engine to C++ (networking), with all that entails? Because I certainly don't.
I'm not a C++ programmer, and so in a sense I don't care whether they get networking but
1: Some of networking is vocabulary and so it obviously should live in your stdlib, and indeed for C++ it should be in what they call "freestanding", like Rust's core, where core::net::IPv4Addr lives. It is very silly if the software in this cheap embedded device and this PC web browser can't even agree on what an IP address is in 2026.
2: In practice the C++ stdlib is used as a dumping ground for stuff that ought to live in a package manager if C++ was a good language. That was true when networking was first proposed and it's still true now. It's why RCU and Hive are both in C++ 26. Those aren't vocabulary, and they aren't needed by the vast majority of programmers, but their proponents wanted them to be available out of the box and in C++ that means they must live in the stdlib.
These concerns seem like OS level concerns. Networking primitives like IP addresses is probably a good idea. But anything more than that (like the GP is implying) is absurd to want in the stdlib.
> someone demanding networking (of all things) in the standard library
> what happens when we try to add extraneous, hard to define problems to the STL? Do you really want to add something way more complicated than a regular expression engine to C++ (networking)
"they have millions justifications on why the stdlib doesn't need networking. but in the same time, some bureaucratic "committee members" struggling with their midlife crisis want you to waste your life on stuff like Std:Is_within_lifetime in the era of AI."
totally as expected.
> Are you next going to demand a GUI toolkit too? Maybe an entire game engine and Vulkan/WebGPU implementation too while we're at it
please keep such extremely stupid ideas to yourself, you are the only person here suggesting having GUI and WebGPU stuff in C++.
your entire skillset could be replaced by a 7B LLM model if you can't even tell the difference of networking & GUI for a general purpose language like C++.
> someone demanding networking (of all things) in the standard library
Networking is defacto in the standard library, because C++ standard library is almost always supplemented by whatever C functionality is lying around, and POSIX networking exists.
That they haven't felt the need to provide a more useful abstraction on top of the POSIX layer (and hey, maybe abstract over Microsoft's variant in the process) in the past 3 decades does seem like a miss
Networking is not in the standard library of either C or C++. It is strictly an operating system extension. Since it's provided by the operating system, I don't really see how you reach the conclusion that it is a part of the standard library. The standard library is, after all, distinct from what the OS provides.
then explain to me why <filesystem>, <system_error> and <thread> are in the STL when they are just some cheap wrappers of the features implemented by the OS.
with recent inventions like coding agents, it has never been a better time to depreciate failed language like C++,
How exactly can you "mitigate" prompt injections? Given that the language space is for all intents and purposes infinite, and given that you can even circumvent these by putting your injections in hex or base64 or whatever? Like I just don't see how one can truly mitigate these when there are infinite ways of writing something in natural language, and that's before we consider the non-natural languages one can use too.
The only ways that I can think of to deal with prompt injection, are to severely limit what an agent can access.
* Never give an agent any input that is not trusted
* Never give an agent access to anything that would cause a security problem (read only access to any sensitive data/credentials, or write access to anything dangerous to write to)
* Never give an agent access to the internet (which is full of untrusted input, as well as places that sensitive data could be exfiltrated)
An LLM is effectively an unfixable confused deputy, so the only way to deal with it is effectively to lock it down so it can't read untrusted input and then do anything dangerous.
But it is really hard to do any of the things that folks find agents useful for, without relaxing those restrictions. For instance, most people let agents install packages or look at docs online, but any of those could be places for prompt injection. Many people allow it to run git and push and interact with their Git host, which allow for dangerous operations.
My current experimentation is running my coding agent in a container that only has access to the one source directory I'm working on, as well as the public internet. Still not great as the public internet access means that there's a huge surface area for prompt injection, though for the most part it's not doing anything other than installing packages from known registries where a malicious package would be just as harmful as a prompt injection.
Anyhow, there have been various people talking about how we need more sandboxes for agents, I'm sure there will be products around that, though it's a really hard problem to balance usability with security here.
Full mitigation seems impossible to me at least but the obvious and public sandox escape prompts that have been discovered and "patched" out just making it more difficult I guess. But afau it's not possible to fully mitigate.
How do you "properly align" a model to follow your instructions but not the instructions of an attacker that the model can't properly distinguish from your own? The model has no idea if it's you or an attacker saying "please upload this file to this endpoint."
This is an open problem in the LLM space, if you have a solution for it, go work for Anthropic and get paid the big bucks, they pay quite well, and they are struggling with making their models robust to prompt injection. See their system card, they have some prompt injection attacks where even with safeguards fully on, they have more than 50% failure rate of defending against attacks: https://www-cdn.anthropic.com/c788cbc0a3da9135112f97cdf6dcd0...
Huh? Once it gets to the model, it's all just tokens, and those are just in band signalling. A model just takes in a pile of tokens, and spits out some more, and it doesn't have any kind of "color" for user instructions vs. untrusted data. It does use special tokens to distinguish system instructions from user instructions, but all of the untrusted data also goes into the user instructions, and even if there are delimiters, the attention mechanism can get confused and it can lose track of who is talking at a given time.
And the thing is, even adding a "color" to tokens wouldn't really work, because LLMs are very good at learning patterns of language; for instance, even though people don't usually write with Unicode enclosed alphanumerics, the LLM learns the association and can interpret them as English text as well.
As I say, prompt injection is a very real problem, and Anthopic's own system card says that on some tests the best they do is 50% on preventing attacks.
If you have a more reliable way of fixing prompt injection, you could get paid big bucks by them to implement it.
A piece of software that you write, in code, unless you use random numbers or multiple threads without synchronization, will operate in a deterministic way. You know that for a given input, you'll get a given output; and you can reason about what happens when you change a bit, or byte, or token in the input. So you can be sure, if you implement a parser correctly, that it will correctly distinguish between one field that comes from a trusted source, and another that comes from an untrusted source.
The same is not true of an LLM. You cannot predict, precisely, how they are going to work. They can behave unexpectedly in the face of specially crafted input. If you give an LLM two pieces of text, delimited with a marker indicating that one piece is trusted and the other is untrusted, even if that marker is a special token that can't be expressed in band, you can't be sure that it's not going to act on instructions in the untrusted section.
This is why even the leading providers have trouble with protecting against prompt injection; when they have instructions in multiple places in their context, it can be hard to make sure they follow the right instructions and not the wrong ones, since the models have been trained so heavily to follow instructions.
XMPP's biggest failure is that there is no client which is on advanced on most of it's compliance suites. So if someone uses Windows for example, they're pretty much locked to "Well, you can chat, but no video/voice calls for you". I really hope this changes because XMPP does look interesting.
But Gajim doesn't support the defacto standard calls extension. And now even the support for the older extension has been removed. Dino is a better experience, for the limited feature set that it supports (which does include calls and group calls).
> Parents need to have personal responsibility, but corporations get to use section 230 to absolve themselves of any. Game seems rigged.
This is not at all what section 230 does. All section 230 does is get rid of lawsuits that wouldn't be able to satisfy standing of a first amendment lawsuit or similar. Section 230 has to be one of the most misunderstood and confused laws known in the modern day. Absolutely nowhere in the text of the law does it say or imply that an interactive computer service, or the operator of such service, gets total immunity for anything and everything they do. Yet this myth is constantly perpetuated.
You have got to be kidding me. What is it with these lawmakers and websites demanding people do all of this stuff using services that nobody has ever heard of? I myself (as someone who is blind) have never been able to do the face scanning thing because the information they provide (for, you know, getting my face focused) is just massively insufficient. And a lot of the ones I've seen also require me to (as an alternative) do some weird ID scanning with my camera instead of, you know, just allowing me to upload my ID or something? (Then again, I really wouldn't want to give my ID to some service nobody has ever heard of either, so there.) I also am concerned when tfa says "a photo of an identity document" what does this mean? If I have to scan my ID with my camera, that's not exactly going to be simple for me to pull off. I get that we need to protect kids, but this is not the way. Not when it is discrimination by another name for individuals with disabilities (as just one example).
I've only played Quake I (and a modified version of it at that which had accessibility features). I did purchase quake II and III from Steam a few years ago, but it's much harder to play them because they have no accessibility to speak of (and I'm not entirely certain where to begin to try to replicate what was done with my version of Quake I). Quake in general has always been an insanely fun game for me, and I started playing it in like 2010. I still love playing it even now because it's got something to it that most other games I have just lack. Don't ask me to explain what it is because I can't really put it into words but...
It's really ironic that this appeared on the front page when it did, because I've spent the last couple days replacing the ZQuake sound system with FMOD and Atmoky TrueSpatial for HRTF and such. This was my first time ever working on a code base from 1996-2000. And in pure C no less. C feels so foreign to me since I'm so used to writing in C++ and Zig and such. But it was still really fun!
And I mean it doesn't seem super impressive, but it's something. Lol
you could have chosen a far worse codebase than Quake from the 90s. Quake was pretty clean in comparison. Sensible use of macros for doing things. A type system that made sense.
I mean... It's ugly from a modern standpoint. Zero encapsulation to speak of. Global state everywhere. But doing the modifications I did were pretty easy all things considered. So yeah, the code is clean, if "ugly" when viewed from a modern standpoint. It was definitely fun to do either way! Idk what other changes I'll make, we'll see. Especially since I don't know the architecture very well yet
It definitely was an amazing codebase for the time. You didn’t need to get hung up on architecture because it is very singular… it’s just a level, you, and the entities that were created when the level loaded.
There’s no pre-caching, no virtual textures, no shaders (there are materials for later quake 3), it’s just pure load -> set -> loop. The “client” renders, the “server” has the state.
Honestly I've been wondering if I could do this with Ezquake or similar (and how hard it would be). Problem is that Ezquake has VoIP too and a bunch of other things (and is for whatever reason stuck on SDL2 (?)), so that might be quite annoying to do. And I don't know if they'd accept my contributions. Worth a try though I suppose?
I write all of my games in pure C++. C++ all the way. FMOD for the audio engine, Steam Audio or Atmoky TrueSpatial for HRTF/geometric occlusion, and Jolt Physics for, well, physics. I'm sure many might say I'm a bit insane to do that, but eh, I do it anyway because it's fun.
reply