This is exactly what I keep going on about. Some great tips in there, especially for those of us waiting for LLMs to stabilize.
Obviously not aligned on every detail, but a lot of this is just how you build software when you don't have dump trucks of investor cash to set ablaze. A skill that seems increasingly rare these days thanks to scale fever. My favourite part was reading the comments. Not everyone there is beyond hope, but I sure lost mine trying to read through those.
He's up front. You won't learn anything from this talk. It's one of those great art of the rant style talks. If anything, maybe it'll help those who haven't seen the silver bullet syndrome in action learn before they end up propagating this mistake.
I think I remember once reading that part of the reason for expanding the student loan program was to provide leverage to demand changes to the curriculums of universities. Specifically to get classes on politics, history, and civic participation curtailed by noting contemptuously that schools were indoctrinating students with classes on how to protest (reminds me of recent remarks about basket weaving). I can't find the source so I'm pretty sure it's either a lie or I'm misremembering something. That said, more people could use an education on protesting. Too many people think protests themselves change things. Let's all get together in front of a government building for an afternoon of sign holding.
Without a long term coordinated effort to change policy behind a protest, a protest is meaningless. Protests in and of themselves don't do anything. They're a tool of political action. You have to know how to properly use such a tool. This is an introduction to what that tool is and how it works. My thanks to Dr. Devereaux for all his work on his blog. It really is a modern example of what the old web's blogs were all about. Something I hope I'm helping carry forward in my own little way.
One of the keys to picking the right architecture is first understanding what the machines you're running on are actually capable of. A typical server in 2026 is an absolute behemoth. Many small to medium sized tech companies could run their entire SaaS app on a single 42U rack of hardware if they stopped fad chasing and started writing moderately performance aware software focused on optimizing their COGS.
I've not got much to add here. I guess I should point out, it's not just the United States of America like the title claims, but I assume that's fairly obvious. Welcome the next big tech hype after generative AI.
You may have already watched this video given its view count and featuring in the Summer of Math Exposition from 3Blue1Brown. If you haven't, it's definitely worth the watch.
While you can't calculate the distance along the bézier in closed form, you can at least calculate the roots as I do in my bézier visualizer using Cardano's Method. Just an extra tidbit I found hard to locate when I was doing my research for that project.
Great rundown on the problem and a number of tools to help you solve it.
We're definitely at a tipping point as an industry. Security vulnerabilities are now being routinely exploited within hours of a patch being made available. Supply chain attacks are punishing those too eager to update. We're being squeezed on both sides.
Your best defence is to narrow and shorten your supply chains. You need fewer dependencies. We just saw the axios supply chain attack. Maybe you dodged the bullet because you pinned dependencies and waited a few days. Something is going to sneak through. How much longer until something as brutal as the XZ backdoor slips through without someone managing to catch it early enough to save you?
Fewer dependencies make every other countermeasure more effective. If you think scanning is the answer, there is still a false negative rate to worry about. If this scanning is centralized at the public repository level, attackers can easily keep probing until they find something that slips through in throw away accounts before launching their attack. If there are vendor solutions, those can also be tested VirusTotal style. If you're instead focused on manually reviewing and signing off on updates, good luck having your team manually review tens or hundreds of updates a week. Every countermeasure is harder at scale. You're going to have to descale.
That said, if you've got a better idea than manual or automated review, there could be a million-dollar idea in there. For now I'm building a little tool that feeds the diff of package updates to an LLM to try and flag suspicious code for manual review. A hybrid approach run locally. It's not a great solution, but I'm also sure it's only a matter of time until the antivirus vendors catch on and offer basically the same thing but with much better classifiers and heuristics.
The problem is that every source code dependency has effectively complete and unrestricted access. I'd love it if my execution runtime could come with something like pledge(2) at the module level so I could create a list of just the allowed permissions each package is allowed to use. Then a module can only call other modules that have a subset of its own privileges. I'd even use this for my own code like I do already at the process level. Start by getting an inventory and then strictly watch that new additions are appropriate. The hard part is doing it without requiring a whole new programming language or dependency ecosystem.
In any case, a little duplication is better than a little dependency.
As someone who spends easily over 85% of my time in a terminal, it's rare for me to learn something new from one of these sorts of articles, especially those starting with simple concepts. I did not know about Ctrl-Y.
Kudos to the author here. This is the exact sort of list of everyday things I use too, so it's likely from the top of their head and not just regurgitating the Zsh manual at you. Not everything noted is a daily mainstay for me (I've never needed pushd/popd), but it's got a lot of the things I use constantly and very little else I don't use.
Here is one bonus tip: they cover cd - but didn't mention just running cd without an argument. That takes you to your home directory.
