I love this simple versus easy distinction. He's right, we do throw those two terms around interchangeably in software development and being clear between the two is critical to improve our communication. I'm not as much a simple software advocate. Simple is great and has a lot of maintainability and reliability improvements it imparts but it certainly balances against secure, performant, and time to deliver for me. See Rust and Other Interesting Things or Data-Oriented Design and C++ for more details. But having this language, the ability to talk clearly about choosing the easy path sometimes or instead refining it to be simple by detangling two things that have been complected. That's very useful to discuss trade-offs with colleagues.
The saddest part of this talk is that the table he builds, of programming language constructs that are complex verses simple. That table is never really explained well in the talk. This is like a two week cram course cut down to fit in an hour. If you don't already know what he means by managed refs or polymorphism a la carte, you're stuck. Or at least it took me many years to appreciate this table fully and I assume others are in the same boat. I don't think a TIL post is the right format to go into details either, but I'll backlog an item to create a blog post about that table in detail sometime soon (famous last words).
Having listened to a few conference talks about satellite ops/sec and having talked/read/listened to/from hams who do AmSat stuff, this isn't really unknown. Lots of them talk about, for example, secret frequencies and protocols that let them read and write arbitrary memory on the satellite to enable emergency recovery. Essentially intentional remote code execution to help save the millions of dollars spent putting the thing beyond reach of repair.
This is however the first work I know of that's really spent the time to detail all the really fun stuff going on. For me, this paper is far less about the conclusions and far more about documenting all the obfuscation techniques, protocols, and worth knowing specifications to get you up to speed on what's going on up there in case you want to have a listen and try decoding some of this stuff yourself.
It's not as bad as Firesheep, which is what it took for the web industry to start taking cryptography seriously for inter-device communication. Maybe they don't need something that bad to get their act together? Though the automotive industry is facing the Flipper Zero and they're still dragging their feet and largely sticking their heads in the sand.
I'm not going to say this is a simple solved problem. Space makes deterministic computing much less reliable and redundancy much more expensive. I'm not aware of any cryptographers working on RadHard crypto algorithms and protocols though. Granted, I didn't look too deeply through the literature. Could be an open research problem. Essentially you'd have to design a cryptography system that can remain secure in the presence of some limited probability of arbitrary bit flips of the source code and runtime. Bonus points for doing it in low compute environments like those found on cube sats.
Cars have no excuse like cosmic rays though. Come on, it's well past 1994.
The original source material for this piece is NIST SP800-63 which contains all the actual specifications. The Malwarebytes labs post is just more fun which helps get the relevant bits across. Bureaucracies move glacially slow but the standard has finally been updated. Complexity rules, enforced scheduled password changes, and rotation history tracking do not lead to better security. We have fairly overwhelming evidence of this at this point. In passwords, length always wins.
Of course passwords are still completely lost on most people so you get idiotic headlines like Complicated Passwords Make You Less Safe, Experts Now Say. No, using a bigger character set still improves security. Nobody is saying you should stop using complicated passwords. We're saying adding arbitrary rules for users to follow just makes people frustrated while at best not meaningfully improving security and in many cases, actively making it worse.
People just do the most obvious things to satisfy your pointless rules. I need an uppercase, lowercase, number and symbol, better use Welcome2025!. If you've ever set this password for anyone, please stop. Stop it right now. You are single handedly undermining the security of your company. Very few people who you give that to ever change it. It's probably the most obvious password in the history of passwords along with qwertyuiop, monkey123, and Lisa1969.
Final note, use a password manager. I'll even let you use one that syncs to the cloud if that's what it takes to get you using one. Let it generate huge 60 character passwords full of symbols for you and stop trying to remember them all.
You can usually embrace this even in an organization that demands estimates. To me, a line manager's key job is insulating the workers from the business so they can get things done. The key tool at your disposal is scope. I remember watching this talk a long time ago and in the time since it's combined with a few other ideas I've read about death marches. That's when everybody working on the project knows the deadline is literally never going to work, and yet you all keep marching. A simple way to unpack that involves thinking of projects as being a combination of cost, time, scope, and quality. You can only control three. Trying to control all four leads to a death march.
If you just work by starting with a deadline, a lot of it slots into place. A point at which we need to ship/demo/whatever then you can work backwards. Using projection, not estimation, you can spot things are slipping early, often earlier than estimators realize, and you need to either move the deadline or cut scope. Reducing scope is usually easier than you think. Your customer doesn't know all the cool things you wanted to build. They only know what you put in their hands. If you agreed to more, you can talk it out. Focus on what's most important. This happens all the time and it's not the big deal many people make it out to be. Also, for big projects, iterate. Don't just promise the whole thing in a year. Promise a part in a month or two. That's a great way to get feedback early and fix things before they're fully load bearing.
Not only that, just counting tickets really does give you a projection that's fairly accurate. I've used it before when estimates had months and my calculations showed years. Years later, I was right. When estimates can be as much as 200% wrong and projection is usually within 20%, it's insane not to switch.
This works because a ticket represents one unit of work from start to finish. There's a bunch of overhead in starting, testing, shipping, and so on. So each unit tends to scope about the same amount of work. That is, roughly one chunk of work someone wants to finish before doing another thing or the amount of complexity they can manage in one go. It also means it doesn't matter who's scoping as long as they're scoped together. They'll bucket into roughly the same size. What size doesn't matter too much. Just that they're about one unit of work.
This really does work. It's how I manage my team. The entire process can be summed up as make an ordered list of things to do and then do it. Repeat. It really doesn't need to be more complicated. Simultaneously, any process missing one of those components is doomed. The most often missed part is ordered list. If you have a vague sense of priority you'll end up with all sorts of informal channels of power attempting to pick their own winner among the work to be done.
I could drone on but I'm certainly not right about what will work best for your team. There's a lot of things to try, but here I'd suggest mostly, try less. Try cutting things. It's too easy to add and too hard to remove. Do the hard thing and see what happens. You can always add it back if you all worked better before. You'll probably find that more substantive things will start getting done but you feel like less is happening. That's because everyone will be busy doing instead of talking about doing.
Pretty neatly sums it up. The software industry has always had faces, people for whom the entire point of technology is to make the cover of some magazine, arms crossed, looking smug for the camera. To find themselves an interview so they can stroke their ego in public.
Focus on these losers long enough and that'll be all that's left. The stories we tell sculpt the future we see. These days the story is that if you work hard enough, some techbro can buy your work to claim it as their own so they can climb atop their pile of stolen valor like a dragon's hoard. If you refuse, they'll just light a pile of Saudi investment money on fire to undercut you and drive you out of business. Guess who this story really appeals to and attracts to the industry. Guess who it drives away.
Early Woz got me hyped, Aaron drove it home, Ken and Rob gave me a tradition to inherit, and at least a dozen more have done their part too. I consider myself a proud hacker. Not a great one mind you, just proud. Take it apart and put it back together purely for the discovery and fun it brings. Make it do things you shouldn't be able to because the limitations drive creativity.
If you listen to the story though, that's antithetical to the point of technology. I should only care about it in so far as it generates capital. Exponential growth. Unicorn. Sell that baby and become rich beyond your wildest dreams.
I make money to have time to play with the technology, not the other way 'round.
This is a pretty great introduction to group theory from the prospective of a distributed systems programmer. Really useful stuff. It starts by mentioning abelian groups offhandedly in order to poke fun at the impenetrability of the jargon of group theory compared to how easy it is to understand the concepts involved. If you understand idempotency, you already have an intuitive understanding of things like commutativity (which is what items in an abelian group share). If you don't, this talk makes it really easy to understand what properties resilient distributed systems tend to try and design upon and why.
Yeah, I think that elegantly sums it up. We're in so deep on economy as speculation at this point that basically nothing about a company matters beyond attracting investment. It's companies looking to get in on yield farming. It means the economy is mostly a measure of how compelling the collection of FOMO stories seem. This is why you've got runaway. If your FOMO story aligns with a lot of other companies stories, this only further boosts the FOMO.
Cryptocurrencies showed that the economy as an exchange of goods and services was only incidental, not explicit to generating the needed speculation. Making and selling (or more likely renting out) things is now only there as props in telling these stories to earn the real money. That is, people giving you heaps of cash in exchange for stock. Basically anything you can invent by typing numbers into a spreadsheet that buyers can trade amongst themselves will work. Stock these days fits the bill because you don't have to pay dividends. Why not? The story goes that if you did that, you wouldn't be growing as fast. Conveniently this reinforces the FOMO narrative.
Whenever someone whinges that the stock market is up or down and somebody inevitably retorts back that the stock market isn't the economy, I'm actually starting to think they're wrong. The stock market really has become the economy. Anyone with power has so much money tied up in the stock market, that to them, their ideas, what they think is important, the stock market weighs heavily in every decision. Everyday people aren't like this, they need bread and circuses which are becoming ever increasingly more expensive (because doing that makes the stock go up). But to those setting policy direction in government and companies, the stock market really does drive their entire outlook.
Look, if 99.9999% or more of your wealth was in this one vehicle, most people really would do everything they could to prevent their wealth decreasing even if it meant destroying people and the planet to do it. You're only going to live 30-50 more years tops. Problems for later generations or suckers less fortunate are superficial compared to your retirement portfolio.
If you've never edited Wikipedia, give it a go. It's way simpler than you probably think it is, especially for the often undervalued work of citing sources or fixing grammar and/or punctuation. You're likely going to read a bunch of Wikipedia anyway. Take the extra few minutes to help fix problems when you see them.
A great run through many of the noodly little details of Unix processes, signals, alarms, select, poll, and more. Includes a go through the self-pipe trick which I hadn't thought about until now, but is a neat way to simplify. I'm really happy when someone explains something by working a solution to a problem with all the trade-offs left in. Doubly so when the explanation also includes all the hairy bits of the implementations instead of leaving them as a stumbling exercise to the reader.
