wrldos

My EE lecturer described Forrest Mims as the single largest source of brain damage in the EE community. Unlearning the abstractions in those books was a common source of problems apparently.

Ergo I'm glad I steered around them. My favourite author on such matters is Wes Hayward, particularly Experimental Methods in RF Design which taught me more about electronics than any other book out there.

I'm fully aware of those risks. The issue for me is a matter of realism.

A combination of the default policy being poor on all AWS services, the shared responsibility model of AWS delegating this risk to clients and the default security posture in the industry being terrible makes the real problem of solving this like traipsing across a field covered in poo.

An analogy; you have to tick the box to put your front door key under the doormat. The burglar knows where the hole in your fence is and knows you might keep your keys under the door mat. Plus your kids left their keys on the github bus.

Of course the SOC2 audit says you ticked the box and you tell everyone your house is a castle.

These are far less likely outcomes than your root account being compromised, an IAM fuck up, dumb assume role configuration or something using an assumed IAM role being compromised and having verbatim access to the bucket.

The feature is there for paperwork reasons.

Time is limited. Doing too much detracts from what I do want to do.

Nope. I've got everything I want. It's not a lot. I'm collecting a ton of money now that I don't know what to do with.

Promoting wants is the foundation of economics however.

If you want to use a knife analogy, we're using C for prying things open, sawing up timber and opening locks. There are better tools for those jobs that don't end up in blood loss and misery.

Not so sure. I learned commercial Unix back in the late 1990s on discarded SPARC hardware which was available in skips and Yahoo auctions for virtually no money at all. In fact it was generally cheaper than the boxed Linux distributions you had to spend on because you only had a dialup.

The killer with the commercial Unixes is that the documentation was orders of magnitude better. That is true today still as well. Most Linux knowledge I have to sift through today is obtained from dubious quality manpages, partially incomplete or out of date documentation and random blog posts.

Really not a fan of awk. It really looks nice but I have inherited a lot of it in the past and know how many foot guns there are. Trashing the unix philosophy of using text as a communication protocol, I've seen terrible terrible mistakes when it comes to repetitive re-parsing stuff at each pipe step.

The finest was a 3rd party who accidentally added a space in a data feed. This was dutifully sucked out of their SFTP server via a bash script, pre-processed using awk into the standard internal format and then picked up by a cron job which ran a python script to inject it into postgres. The outcome was of course that the columns were offset by 1. This caused a huge asset valuation dip and some market alarm.

A proper parser would have rejected the whole dataset as the data row could not be parsed.

If you have to think about safety then the technology is unsafe by default, ergo not suitable for security and reliability critical systems. No amount of thinking is going to fix that.

I haven't built anything out of choice in a C derivative since the late 1980s, unless I explicitly wanted to break something or do something naughty or talk to hardware directly.

And no one noticed because no one has read CNET for years.

Indeed they are just ticking a box for your customers.

SOC Type 2 compliance only suggests they have a sit in audit once a year. Basically the produced a lot of paperwork and it doesn't mean that they evidenced stuff honestly to the auditors.