Ironically the best defense against police abuse of power seems to be doing your own surveillance. Recording interactions with the police and having a dash cam. Many popular dash cams like Viofo record to an SD and don't send recordings to the cloud.
My understanding is that it's not recommended in the USA to talk with cops. Anything you say will be used against you, or your friends. Just ask if you are being arrested and if you are free to go. If you have anything to say in your defence, save it for court.
I have a skill for using Verus with Rust [1]. I think they found a nice way to integrate proofs with the language. The verify skill I use lists proofs as a possible technique [2] and the project instructions have instructions on using it, but only a very small fraction of the code base I am using this on has proofs. Anyone can now have an LLM write proofs but its still difficult to know when they are more productive than other techniques and to relay that advice to an LLM.
I am reading this as a potential leak of almost every possible piece of metadata related to the operation and the business but a limited leak of customer data.
This goes to show the benefit of maintaining separations between the control plane and the data plane.
This site does say it has SQL logs which have some amount of customer data and there is a mention of some snapshots/imports- this looks like a case where the control plane and data plane end up getting entangled. Its possible the attacker could have reset customer database passwords to try to connect to them or could have exfiltrated customer data by initiating snapshots but just didn't want to deal with the increased risk of detection.
TiDB is for large scale data. You generally wouldn't use it unless you have at least 1TB of data. A 10TB leak of information is less than the size of a single small customer database for them.
I am reading this as a leak of every possible piece of metadata but not an actual leak of customer data. They have SQL logs which do contain customer data and there is a mention of some snapshots/imports.
(POV when storing 1PB in Oracle) when I saw the 10 TB in another post, I was like "wait, isn't this sold to scale out, we have 100 times the data here".
They are showing this new version scoring significantly higher across multiple coding benchmarks, beating Sol 5.6 (6.1 is the latest) across 10/11 benchmarks.
I am going back to DeepSeek for writing code. I was trying out using Sol and liking the result, but this should close a lot of that gap. I use Opus/Sol for an implementation plan and code review also use them for grilling. DeepSeek is also running verifications.
> For example, benchmarks in our initial list heavily cover AI-exposed lawyers’ tasks, but barely cover any of the O*NET tasks of similarly AI-exposed legal secretaries or court clerks.
This technique seems dubious- what is stopping AI from doing the computer work of legal secretaries and court clerks as well?
Solving math problems is one of the hardest theoretical jobs. Software engineering is one of the harder practical jobs. AI is now much better at these tasks than humans because it has been able to properly train for them.
For other computer-based jobs it's a matter of AI getting properly trained for them. If a job is harder to verify or the training data is more limited, it may be much more difficult to train AI for it but I don't think there's any reason to think it won't happen eventually.
I think I agree. I'd be surprised if in a casual universe everything we perform cannot be represented by an abstract program and so should be performable by AI.
But, it may be that the performance of some roles is constrained such that the physical shape or rate and breadth of knowledge utilized isn't advantaged by the benefits of digitalized intelligence, and so would be approximately acting just human anyways. And in that case there may be enough human's available to do it just because they want to, fully fulfilling the demand for it.
There is a now 20 year old article (maybe something has changed since then?) where someone got 50 different opinions- going to different dentists with the same mouth, and got diagnoses all over the place- from $460 to $29,850.
Rust does have one glaring weakness: compile times. I suspect in the LLM era we will see the rise of a language or perhaps some sort of Rust redesign that achieves what Rust has with great performance and great type safety but also has better support for fast compilation.
I have found that agents are good at writing Verus proofs in a Rust code base, and that these proofs have only a minimal negative effect on the normal compilation path. I have a skill for using Verus: https://github.com/gregwebs/skills-sdlc/blob/main/skills/rus...
Compile times are really only an issue of you need to iterate extremely fast.
One of my spare time projects is a "prompted" 3D modeling app that is now (incl sub-crates I maintain) about 500k lines of Rust.
The link stage is the longest. An incremental build (w. sccache+mold) where I changed a few source files is done and runs after maybe 20s max on my 2022 Rhyzen 6800H-powered laptop.
I think this is acceptable when working on that kind of project.
For games where this matters I usually prototype in some other language first, TS, Python, Lua, whatever then translate to Rust when game mechanics and magic numbers are settled.
Or you simply put those into a config file that gets watched by the game.
At work we have an image manipulation crate that takes like 30mins to 'dev' and about an hour to 'release' build.
The WASM version takes even longer, about 2h, and needs like 55GB RAM during build.
But that crate has only to be built once a month.
And if it mattered we could split it because it's a metacrate made of ~20 sub-crates.
Yeah, it would be nice if Rust were even faster (I remember compile times almost a decade ago, when I started using it)!
But I think for the typical use cases where you would (should!) reach for it, it's quite ok already.
And if not you can work around it quite painlessly.
It’s especially bad when working on multiple projects at the same time. Memory and CPU contention kills performance.
I’ve switched one of my projects to Go and it took a day for Opus to do the port and another couple of days to finish the features I wanted. I’ve never liked the language and still use Rust in plenty of places, but I can’t argue with how much faster iteration is.
Ask your agent to build a simple bash/zsh/whatever cargo wrapper that maintains a machine build lock.
It should exclude cargo check, tree etc. ofc.
CPU contention from parallel cargo runs absolutely kills (build) performance.
Also my setup has instructions that agents keep working if they have open items while the lock is taken; i.e. launch a subagent or a shell with a watcher to run the build and don't block on it.
This makes all the difference when you have multiple agents on multiple workstreams on the same machine and they target Rust.
Mojo looks interesting [0]. It is designed by Chris Lattner himself [1] and has an interesting take on borrowing references (Rust's DNA) comptime execution inspired by Zig. And it targets CPU and GPU (NPU, TPU) as first class targets. Recently reached 1.0 release.
Senior engineer and all SWE positions will become more like a technical lead.
If you can direct AI and produce more value per $/time spent then a non software engineer directing AI to develop software then you still can produce a lot of value.
This should be the case now for most things that are not a prototype. The job has changed from "writing code" to "shipping software". A technical lead.
Software products making ever more intelligent AI software development accessible will continue to reduce the need for software engineer involvement. But there’s also going to be 1000x more software. So there may continue to be opportunities for those that adapt.
reply