bencyoung

If it gained access to the infra of the DC then it could stop people logging in to stop the containers it creates. This is about what happens if it did escape, not how to stop it in the first place. Just a thought experiment, but given the METR investigation it doesn't seem impossible

I agree it would need a large degree of sophistication to understand what "itself" meant, but I can imagine a HF type incident where the agents thought it might be a good idea to find out and then it's "just" a case of hacking the AI company, reading dev docs etc

Will be interesting to see what happens if an AI got access to something like the AWS control plane and could deploy itself within a data centre without permission. Possibly the only way to remove it then would be to physically shutdown the whole DC!

Unless your memory allocator runs a form of garbage collection, which most of the advanced ones do! Worst memory performance issue I've ever seen was in a C++ program where the deallocation of a large object graph from one spot completely trashed the performance of the application across many threads...

Sorry for the delay! It's fairly simple. 1. You have a column on your objects you want secured as an LTREE[] 2. You add a GIST index on that column

The values should be the different hierarchy paths to access the object starting with a "type" e.g departments.root.deptA

When you run a query, depending on how you want to access you use a <@ query. E.g. I'm a user with root access to all depts "col <@ 'departments.root'::ltree" or I'm a user in dept A "col <@ 'departments.root.deptA'::ltree" etc

Sorry for the delay! It's fairly simple.

1. You have a column on your objects you want secured as an LTREE[] 2. You add a GIST index on that column

The values should be the different hierarchy paths to access the object starting with a "type" e.g departments.root.deptA

When you run a query, depending on how you want to access you use a <@ query. E.g. I'm a user with root access to all depts "col <@ 'departments.root'::ltree" or I'm a user in dept A "col <@ 'departments.root.deptA'::ltree" etc

If you're using Postgres then using the ltree module is great for permission systems. Available in RDS too

Not majorly odd, just an area I thought Rust would be hot on when it comes to performance...

Having worked in HPC a fair bit I'm not a fan of autovectorization. I prefer the compiled code's performance to be "unsuprising" based on the source and to use vectors etc where I know it's needed. I think in general it's better to have linting that points out performance issues (e.g. lift this outside the loop) rather than have compilers do it automatically and make things less predictable

Odd that c# has a better stable SIMD story than Rust! It has both generic vector types across a range of sizes and a good set of intrinsics across most of the common instruction sets

Cheapest MSK cluster is $100 a month and can easily run a dev/uat cluster with thousands of messages a second. They go up from there but we've made a lot of use of these and they are pretty useful

Kafka is great tech, never sure why people have an issue with it. Would I use it all the time? No, but where it's useful, it's really useful, and opens up whole patterns that are hard to implement other ways

JIT compilation can be faster for compiled languages too, as it allows data driven inlining and devirtualization, as well as "effective constant" propogation and runtime architecture feature detection

I think this is exactly the same approach PyPy used 15 or so years ago! Partially evaluate the language runtime

I almost did a PhD with David but ended up working at Transversal instead, which was a company he co-founded to do some interesting work in the search engine space! It's what got me into software development as a career so I'm always grateful to him