Even if they are good the vulnerabilities have to be there. There's lots of things turning up like Local Privilege Escalations (LPE) in Linux, but serious people didn't expect the kernel to be a boundary for a sophisticated attacker.
A lot of the vulnerabilities LLMs are finding now are the "long tail" and affect only particular configurations, I would be surprised if e.g. a widely applicable RCE is found in Linux (but I'm also not going to bet against it).
Where this gets interesting is the long tail can be used to target a particular system and this is where defense-in-depth becomes important for every organisation.
They are QSFP56-DD which can be split using breakout cables. So it's 4 x 400GbE ports, which could in theory be split into as many as 32 x 50GbE ports. (Although whether that then ends up being an economical thing to do is a different matter.)
Ahh yeah, I've seen people using those. I was thinking you'd ideally want to connect them full speed, but it looks like they're 200gbps ports anyway, and I guess even if they were 400gpbs, you don't really need that much for cross-GPU traffic for MoE models doing tensor parallel.
I put a short link on a family thing and someone complained it didn't work. Turns out iOS OCR recognised a "-" as a "=", so this isn't just people typing it wrong.
Now my short links implement case insensitivity and striping all non alphanumeric characters, i.e. a "-" is optional and any other symbol character is also stripped.
nyc.gov seems to do case insensitivity but doesn't strip "-", so you do need the "-".
Simple -- you just add a custom SQLite VFS that ensures particular SQLite pages are mapped into underlying OS pages that are appropriately mprotect()ed. Try to modify the executable pages and you crash (W^X). Or you know, don't try to use a hack like this where security matters.
SQLite's unix VFS is actually using a mixture of mmap and write() by default[1] and you'd need to combine that with mseal() and some more pieces to actually pull it off. It would probably be possible.
Zip isn't useful for random access here; the problem with random access in HTTP serving is then you have to decompress the data and potentially recompress.
The more interesting trick you can do with zip files for HTTP serving is to serve the compressed deflate stream as gzip, or use Zstd inside zip. Then you have a valid zip file from which bytes can be served directly.
I tried using their Magic Containers product and there were issues that showed a lack of attention to detail as well.
It's supposed to scale globally (magically!) but I found multiple cases where particular nodes were problematic and the health checks didn't detect them (in fact to start with the health checks didn't even work properly if you had multiple containers, they did fix that). The support was quite slow too, after finding multiple product issues they'd escalate to developers and then come back a month later and ask to retest, but some of this took multiple round trips. I was only using this on a side project, but definitely wouldn't consider them for anything critical, even if they are quite cheap.
GitHub manage to do it. Most URLs you'd think of are either redirects to other bits of the site, or accounts owned by GitHub themselves. It just takes a bit of planning.
You can plan every "top level" path you'll ever want on the site from now until forever? Or do you mean planning as in plan to force account name changes on users when someone's username conflicts with a new feature name?
In that case it's not really different if the usernames are prefixed to be clearly identifiable as usernames - most companies still wouldn't want any user accounts that look like official company accounts.
> Part #2 to me, I also want observability as to what the agent changed.
You could potentially combine https://github.com/binpash/try with bubblewrap (I'm not sure how well they compose and as the docs say it isn't a full sandbox).
The good (and bad because it's confusing and can lead to surprises if misconfigured) thing about Linux containers is all the pieces of containers can be used independently. The "try" tool lets you use the overlay part of containers on your host system, just like Bubblewrap lets you combine the namespacing parts of containers with your host system.
Instead you can create multiple Wireguard interfaces and use policy routing / ECMP / BGP / all the layer 3 tricks, that way you can achieve similar things to what vxlan could give you but at layer 3.
There's a performance benefit to doing it this way too, in some testing I found the wireguard interface can be a bottleneck (there's various offload and multiple core support in Linux, but it still has some overhead).
A lot of the vulnerabilities LLMs are finding now are the "long tail" and affect only particular configurations, I would be surprised if e.g. a widely applicable RCE is found in Linux (but I'm also not going to bet against it).
Where this gets interesting is the long tail can be used to target a particular system and this is where defense-in-depth becomes important for every organisation.
reply