I'm pretty sure designing with the expectation that people might try to drive a truck/plane into the building is pretty normal for data center design. People have been aware of destructive people for a while.
I worked for a defense contractor in the early 1980s.
I think it was 1983, just after I started there, that an edict came down to "truck-proof" the building. If I remember, 1983 was when Hammas blew up the US embassy in Beirut with a truck bomb.
They put up those "anti-truck" columns in front of the doors.
No doubt, but it's probably emotionally easier to work with that knowledge and attempt at foresight in the abstract, than how it would feel to receive a letter from your employer saying something akin to "brace yourselves".
"It's not opening the source that makes the software more secure. It's enough reviewers or white hats looking at the code. Security vulnerabilities in Linux (both kernel and user space) show that regularly."
Thank you for that additional point, it's worth being said and helps us model the closed source alternative.
Sadly, all too much of modern life has become about wasting your own time, and money, to mitigate screwups made by completely unaccountable third parties.
I'd imagine if you're at that point you're just Kitboga-ing it and trying to fuck with them to make them suffer dollar-wise for the time you've lost while doing something more productive or entertaining in the background. At least that's how I'd do it.
Evaluate the areas of human interaction or places where some could be and try to make those better. Instead of just thinking that a technical challenge is there be all end all of recruiting.
“ I used to work in tech recruiting. I guarantee you 100%, no one cares.”
This does not reflect tech recruiting. People do care and while there are many hurdles to changing a process, we shouldn’t give up because its hard.
As a candidate? Tell them you don't do puzzles before talking to humans and to advance you to the next screen? It's not like those rules can't be broken or changed, they aren't laws of physics.
You posed an interesting point which my mind immediately went to: How do you think 2008 apple would do against the sole of today given today’s technology?
I think that after you realize the limits of your (and our) technical ability to defend against attacks, you can then apply a threat model to see which attacks are not practical given your assets.
For example, I’m reasonably sure there are weaknesses in my gaming pc but I don’t do banking or other more secure things on it. There’s little motivation to target an attack or burn (use) an exploit to get access to this pc for an attacker and the defenses I have defend against most spray and pray attacks.
That’s very complex compared to a model I was thinking about while reading this article.
Consider that many forms of sword fighting remove the complexity by creating zones. I’ve been told that a skilled swordsman can identify 16-32 zones considering where an attack can come from or where to strike.
Isn’t this a much easier model if you factor in the weight/mass/velocity of each particular character? This would be a little like auto-aim but you could still compute each path and create effects against one when they happen or not.
If you have 4-8 static blocks vs 16-32 attacks that would be fine, but if you need to calculate what happens when 16-32 attacks run into the same 16-32 attacks you have a combinatorial explosion problem which you then need to simplify.
One of the reasons I like going straight to the linear algebra approach is that you do a batch of basic arithmetic which the CPU does quite fast without branching, and then you do one branch to determine hit vs not-hit. Pairing zones with zones sounds like nested if/else statements, but I hadn't dived into considering that approach.
Interestingly I get the same in NYC. Asked a friend who gave me a detailed explanation which I have almost entirely forget right now... but something to do with car detection. If you happen to cross in the middle of the street you won’t notice the same drop effect.
