“ It now runs a surprising amount of my life, but it messes simple things up like getting me completely accurate notes..”
Interested in your AI maximalisM; could you tell me a bit more about what it gets right on what it slips on; and how you sort of manage when it’s sort of good enough or like drops the ball and what you do then. Thx
Sounds like Technical Debt is being ignored "Because AI".
"Technical debt is a qualitative description of the cost to maintain a system that is attributable to choosing an expedient solution for its development.
While an expedited solution can accelerate development in the short term, the resulting low quality may increase future costs if left unresolved."
Except we can at this point reasonably expect future AIs to be better at solving the technical debt then people.
AI is right now buying down huge amounts of technical debt (see the flurry of CVEs). But we're already onto the self-improvement treadmill: future more capable systems will be better at solving any issues introduced today - it's literally not worth the time worrying about now (this is the same reason you don't get a cancer prognosis over a longer then 10 year time frame - the expectation is future treatments will be better).
The technical debt my code written in Opus 5.5 might have is already going to be handled by Fable 5.2, for example. It's going to be better and faster then I am. But also: if the rate of technical debt production from AI is even slightly lower, then it gets more and more manageable in a future where nothing changes but the increasing volume of AI compute is concentrated on less and less of it.
I mean certainly it would be nice if I could implement a feature without Claude finding a security bug and tripping cyber protections every couple of hours.
> Except we can at this point reasonably expect future AIs to be better at solving the technical debt then people.
No, we can't. We can believe this will be the case
> The technical debt my code written in Opus 5.5 might have is already going to be handled by Fable 5.2, for example.
"Let's generate more and more garbage in hopes that there will be some magical tech that solves the issues" is not that good of a strategy.
E.g. even for the amazing magical benchmark-shattering Fable 5.5 Anthropic's guidance is still the same: your CLAUDE.md should not exceed 200 lines and claude only reads 200 lines of memory index because otherwise it quickly loses adherence.
Just a year or two ago people were confidently predicting the end of transformer usefulness due to whatever the limits of the time were.
Like all problems, we'll solve them when we get there but its not like anyone has an abundance of useful alternative advice: I'm getting useful software out now, whether I have to fix it later has the same problem it has always had - when we need to, we'll do it.
Well well well, we know now which cat has had their face in the cream (aka who is clearly visible most guilty).. that would be Hisense, who got caught today and had nothing to say.
For all the company’s who had reponses along the lines of “we don’t do thing X that some others are doing”.. full bets it’s Hisense doing each of these things.
You are not accounting for the inherent error rate; around 20-40% as I understand it. Reducible with tokens but then not cheaper than humans.
Sure a good analogy is physical vs robotic; but if it was say burgers. It would be a current McDonalds burger vs some new robot place that makes then half price or cheaper but every aspect of the burger is off quality wise; missing ingredients, mistaken orders, incorrect ingredients, weird toppings; BUT DARN ARE THEY FAST.
You’ve gotten faster but you’ve added an error rate that either you expensively inspect for or it moves to the edge.
Nope, the quality is good. Any errors it makes are being caught in automated reviews. If you don’t have good review and testing processes, yeah, stuff will slip through. The same is true for humans. I would not put juniors above your cited error rate, so I would rather skip the squish.
In Germany Sparda-Banken and, I think, Volks- und Raiffeisenbanken support tap-to-pay through their apps. (And maybe other banks providing apps developed by the same contractor, Atruvia AG.)
PayPal also offers tap-to-pay, though I recently had to disable Graphene's "secure app spawning" feature for the PayPal app to get it to open.
If we want our bank to add suppprt for GrapheneOS and specifically for “tap to pay” on GrapheneOS, without Google pay, what technically and specifically should we be asking for?
I wish I had a good answer for you! I don't think there's anything specific they need to do for GrapheneOS. They "just" need to use Android's NFC API[0] and then do the necessary magic incantations to implement the relevant payment scheme, i.e. exchange data with the credit card terminal and talk to the bank's backend servers. How exactly that works… no idea. But if there's anyone who knows it's them!
There was a time when I thought about figuring this out in detail and building an open-source alternative to Google Pay. But from what I've heard, integrating with credit cards is not something that can be done in an agnostic manner but actually requires support and buy-in by the issuing banks. Not a great perspective for such an app.
Curve works on GrapheneOS but requires sandboxed Google Play. There are European banking apps with support for tap-to-pay without Google Play. If you're not in Germany, the only way to do without sandboxed Google Play is getting an account at one of those banks. We don't have a specific list of those banks on hand.
It requires sandboxed Google Play. If you want to avoid that, you need an account at one of the European banks with tap-to-pay not using Google Pay and an app which can run without Google Play. We don't have a specific list but there are a bunch throughout Europe.
> The lesson is the same as always: extra security is a worthwhile investment. Disable password authentication in favor of ssh keys. I for one am going to buy myself some hardware keys today. :)
Question: Where to get these hardware keys? Which are good options and why?
If you have an iPhone, the ssh client app Terminus can use the Secure Enclave of the iPhone to store your private key, which prevents all apps on the phone, even Terminus itself, from being able to read the private key. The private key is stored in hardware. You use FaceID to approve the login operation that ssh is performing.
I switched over to using that in Terminus recently instead of having Terminus generate and manage the private ssh keys.
Likewise, many Mac and MacBook machines have Secure Enclave too that can store private keys in hardware and works with the ssh client that comes with macOS. But I have not personally started using that yet. Will soon though. You then use TouchID to approve each login operation that ssh is performing.
Yubikey is cool too. I’ve used it mainly for other things than ssh.
Whatever solution you go with, have a backup or another way to restore access when your hardware key eventually breaks and cannot be used.
For example, instead of buying one Yubikey buy three and give each of them access to the same places. Keep one on you, one at home, and one somewhere else. Rotate between using each of them every couple of weeks so you are sure they all still work and that all of them have the accesses to all the same places.
In the case of ssh, you probably either have physical access to the target machine or you have VNC management from the hosting provider, etc, that you can fall back to if you misplace or damage your hardware key. So if you only use the hardware key for ssh and you have other means like those to get back in then having just a single hardware key is mostly fine.
You don't need to go out and buy hardware keys today. You should be able to use any FIDO2 key these days for SSH, as long as your server runs a recent enough OpenSSH server, which supports ecdsa-sk or ed25519-sk public keys.
Reputable vendors of those hardware keys included Yubikey and Token2, among others. You are really just using them as FIDO2 tokens, so go for what's reputable there.
If you are just getting started, you can generate and use software-backed keys (using ssh-keygen) and copy the public keys to servers' authorized_keys file using ssh-copy-id (or manually adding it). You should probably start learning this way (with plenty of online guides, and fewer risks of an old server implementation not supporting FIDO2 credentials), and then move to hardware keys once you understand the mechanics of copying around public keys, etc. Your password manager might also support acting as an SSH agent for key based logins - I believe Bitwarden and some others now do this, for example.
A Yubikey, though simply generating ssh keys instead of using passwords would stop this MITM attack. So would changing the rounds and port of ssh on your system and the remote box making yourself an invisible protocol nothing would recognize.
Yubikey benefits is it stores the keys in the hardware if your laptop is compromised somehow or stolen they at least don't get all the ssh keys too
True they can also get information from the public ssh key like if you used a real email address or name to start spear phishing or who knows what else like extortion threats to your company
Interested in your AI maximalisM; could you tell me a bit more about what it gets right on what it slips on; and how you sort of manage when it’s sort of good enough or like drops the ball and what you do then. Thx
reply