Not dismissing your point, but Looking at the article, it looks like it's in rust unsafe code. Which seems to me to be a point that the rest of the rust code is fine but the place where they turned off the static safety the language provides they got bit.
Hey! Can't I just enjoy my schadenfreude in peace?
I guess the takeaway is that, doubly so, trusting rust code to be memory safe, simply because it is rust isn't sensible. All its protections can simple be invalidated, and an end user would never know.
As told in Innovator's Dilemma mainframe companies would have told the exact same story right up until the cheaper alternative met all of their core needs. But in this case I don't think you get disrupted by copycats but instead by savvy business users building their own disposable alternatives which get just enough done.
Though I think one thing that is being overlooked is that Platforms are the hidden hero under all of this. A lot of AI products are benefiting from various cloud platforms that have been created that make it easy to deploy and opperate these apps. So as long as you are providing a sufficiently general, high productivity platform that can't be emulated by one of the major vendors you'll likely become the new runtime.
Garbage reporting:
1. AWS had an outage
2. AWS has lost a lot of employees
Conclusion:
The brain drain lead to the outage...
I need an LLM trained explicitly on folks confusing correlation and causation and put a big old red dot in my address bar.
I love that there's a whole section "The talent drain evidence" trying to defend their journalistic integrity, but they then go on to totally face plant.
I've been using divvy, had no idea it isn't maintained... but I'm not sure if I'd need any more features outside of what it already does. What items do you want to see them add?
As someone that has influenced company politics as an independent contributor (non-manager) repeatedly, I find you have to go through a lifecycle:
1. When you first join you need to show you can actually accomplish things, likely through code contributions / launching something.
2. After you do that you start becoming part of conversations and can start influencing directly. The key here is problem identification and bringing useful independent data. Whether we like it or not managers have built in leadership authority, IC's have to establish it by above, so usually the leadership group is dominated by managers, but if you can bring useful technical data / solutions and become a "voice of the people" if you will that lets managers not have to dig in and solve every problem you will start influencing politics.
Where I see a lot of folks fall down:
1. Focus on problems that aren't attached to either important issues: tabs vs spaces isn't gonna sink the company. If you start getting triggered about a technical thing and can't explain the impact in terms of availability, cost, productivity you'll quickly get tuned out. That isn't to say the work isn't important, it's just not workable at the political level, you just gotta fix it through influence with other IC's.
2. Inability to explain how the problem is attached to important issues: Similar to above, even if it's a real problem the ability to craft a narrative so the managers and other leaders can connect it up to real value that they'll see.
3. Discomfort with taking risks: No important problem / political problem is without risks / gaps, either in terms of timeline, impact, decision paralysis (as there are truly multiple ways to skin a cat). If you need 100% certainty to kick into gear it'll be hard to influence at the top levels as it often requires taking decisions and the inherent risks involved in signing up for those outcomes.
This is the correct answer. You do a pre-filter on a permissions correlated field like this and post-filter on the results for the deeper perms checks.
reply