Those have no name... but you'll encounter them regularly indeed.
This bears repeating of course. I still wish our industry would run less on hype. It's not specific to Rust of course.
Of course I wish more meetings would follow this pattern... or not happen at all, sending me a proper document instead.
There's a whole swat of solutions for very lean services. You can go a long way reducing complexity as much as possible. Less infrastructure bills are definitely welcome.
Or why I tend to favor desktop applications (made by KDE as much as possible) rather than web applications whenever possible. It's just more pleasant to have things which look and feel homogeneous.
A bit long for what it's saying. And yet it's a good reminder, don't focus on why... Ask the question as many times as necessary to get to the point where you can find a solution which prevents issues to reappear.
Looks like someone is actually paying attention to what's going on.
A good primer about design documents. What's nice about this one is the focus on the process rather than the form of the document. Indeed what matters is the shared understanding and making sure the right decision is made.
Can crates.io make things easier to secure? I do think so. But this post is right that we shouldn't forget the social aspect of the whole supply chain security conversation.
Indeed, the current supply chain model of Rust could be better. While we wait for improvements (with no sign of them coming), there are ways to try to avoid some of the common pitfalls.
Short and to the point reminder: our job is never only about the tech. It always encompass some people related concerns, be it inside teams, between teams, or the impact on the users.
Comprehensive guide to have SSH keys stored in the TPM chip. Clearly it's still a very manual process.
Well, what can I say? This is excellent news and I'm excited to see it happen. Let's hope more governments do the same. It'll take a while of course, so we'll have to be patient.
The stats are clear there. Beside in term of experience, RSS feeds are so superior to newsletters... I wish more bloggers would give up on the newsletter focus. There's also a good point in this post: as soon as you have a newsletter you will sit on a database of email addresses, it's definitely a liability.
Long but very precise piece about why you can likely ignore LLM for development purpose. Starting from older Fred Brooks work is spot on. Indeed whatever will remain of LLM based tools in the years to come, it's much smarter to focus on fundamental skills than chase the new tools. At least, I'm trying to do my share in getting myself and others better at the craft.
Nice little commands to use to discover quickly the state of a code base... Or rather of its team.
Definitely interesting approach. I think neurosymbolic approaches are what we ultimately need so I'm probably biased. At least it means using LLMs for what they're good at (language skills) and only that. Then rely on proper code symbolic models which do the reasoning heavy lifting. I'd expect it can give nice output with smaller models.
Oh this is super neat and convenient! I didn't know about those glob patterns modifiers in zsh.
Lots of interesting measures to reduce the risk of supply chain issues. Definitely to be considered on your projects.
Getting there, one day at a time.