Observationally, for people that /aren't/ using models to code but to just do their white-collar job, claude.ai /is/ AI, now. The entire perspective for how to use AI is through claude skills, claude projects, claude cowork, etc. They've massively won the corp buy-in at the moment I believe.
> You have to review the source of every PKGBUILD from the AUR you install, full stop
I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand.
Mind you, I don't have a solution either.
It's worth reading this one to the end- the point of this paper isn't about the math involved, it's that this math was the result of the federal funding of maths research.
> The cost-benefit ratio of Mathematical research has been off-scale. The Federal government spends about $250 Million/year on mathematics research. Yet in the US there are 40 Million MRI scans per year, incurring tens of billions in Medicaid, Medicare and other Federal costs. The financial benefits of the roughly 10-to-1 productivity improvements now being seen in MRI could soon far exceed the annual NSF budget for mathematics research
Some time ago I wanted the original MS solitaire playing card files. Wasn't too hard to find a copy of the binary, but the interesting thing to me is it appeared the files were handwritten- a couple possible typos in color and not a single byte longer than they needed to be.
You don't.
The normal procedure here is to have multiple unique keys with multiple unique secrets. If one breaks that's it it's broken. This also allows you to revoke a key without removing all keys.
It's not even just that- with component selection you have a handful of datasheets that give you (ideally) fairly truthful information about the device. You can rather deterministically look at these and compare them.
Regular consumer products? Good fucking luck. Anywhere an LLM pulls from is probably going to be mostly SEO'd listicles.
The only thing that seems to have gotten a lot worse is the trend of ai articles- which isn't kagi's fault but it would be nice if they could figure out how to filter them. They all follow the same patter- "specific thing you want" with a table of contents with loads of repeated chapters and unrelated information, spattered with effectively random images.
I don't remember exactly what I wrote and how the logic works, but I generally remember the broad flow of how things tie together, which makes it easier to drop in on some aspect and understand where it is code-wise.
Almost anything I write in Python I start in jupyter just so I can roll it around and see how it feels- which determines how I build it out and to some degree, how easy it is to fix issues later on.
I recently accepted-ish a position at a very ai-forward company. Manual programming was somewhat discouraged entirely.
I've used AI tools in the past for maths I didn't understand or errors I couldn't make sense of, and wrote the bulk myself, but now we have as mentioned, opus/sonnet 4.5- which work great.
As part of this, I had to integrate two new apis- nornally, when I write an API wrapper I end up learning a lot about how the API feels, what leads to what and how it smells, etc. This time? I just asked Claude to read it's docs, then gave suggestions about how I wanted it to be laid out. As a result? I have no idea how these apis feel, their models, etc. If I want to interact with them, I ask Claude how I do a thing with the library it made.
Mind you, the library is good. I looked over everything, it's fairly thin and it's exactly how I would write it, as I suggested it do. But I have no deep understanding, much less an understanding of how it got integrated in.
Like, normally when I integrate something in I learn a bit about the codebase I'm integrating it into. Do that enough times, and I understand the codebase at depth, how things plug in. This time? Nada.
It's.... Deeply uncomfortable, to know so little but still be able to do so much. It doesn't matter if I get it to explain it, that's just information that washes off when I move onto the next thing. The reflexive memory isn't built.
I don't think that modern boards are really repairable at all beyond component replacement- 4+ layer stackups being the big reason. If there's a way to do anything to those boards besides total replacement I'd be super interested to know.
The techniques here are also way beyond basics I think- like, you look at most guides for repair and it's "idk just solder some bodge wires on there, here's what a good joint should look like"
I don't really know that this is avoidable without buckets of work and probably legal issues on behalf of core's (or anyone's) engineers- it's really just something that plagues hardware in general.
Hell, lots of sensors/etc these days are running fairly complicated software that's totally opaque.
I don't think _anyone_ who's buying the new pebble watches is to some degree not interested in software, and probably pretty interested in open-source community work. It's a wildly niche userbase, and this sort of thing is going to put crazy pressure on Eric and co, I imagine.
Still keeping my preorder, but damn dude this kinda sucks.
> restart required a hardware security module (HSM) smart card.
Out of curiosity, does anyone know why? My guess would be the PW DB would be encrypted with some token generated from this card.
I've had lots of "I have a secret and the server needs it" type problems but I've never been very happy with my solutions- smart cards seem like potentially an elegant solution.