“On the Nature of Daylight” by Max Richter used in the opening scenes of Arrival is one that really punches you in the gut - if the theme and monologue isn’t enough to already give you a lump in the throat as a parent.
279 karma · joined November 22, 2019
“On the Nature of Daylight” by Max Richter used in the opening scenes of Arrival is one that really punches you in the gut - if the theme and monologue isn’t enough to already give you a lump in the throat as a parent.
We’ve driven the west-coast corridor a bunch and contemplated several getting a different brand EV to go with our Tesla. Often seen/watched/checked-on-ABRP the EA sites down to just one or two working CCS chargers e.g. at Woodbury, OR. It put us off this year at least.
> There's still artistic and interesting things being created, just not by AAA studios :)
I guess that's my point and I didn't write it very well. AAA publishing/production has become a low-risk money-machine that feeds a very large audience occasionally surprising but increasingly bland content, while making small formulaic incremental changes year-on-year e.g. next-gen textures, bigger maps, more multiplayer servers and modes. Unfortunately a large proportion of players are happy with just that model as evidenced by the revenue derived from it.
Complete bunk - Their (TMobile et.al) “value add services” are nowt more than network content provider toll-gates that the proxies bypass. Meanwhile they are also selling every bit of user context data (position, DNS/sites, cookies where unencryptable, phone-id’s etc) that they can scrape individually and in aggregate to any and every advertiser. Context is worth serious money to advertisers.
Enabling MFA, restricting intra/inter-VPC access, removing hard-coding credentials from configuration files/source etc., switching to SSO/removing user accounts with passwords, creating and applying restricted IAM roles, and applying those reduced privileges to EC2/ECS/EKS instances are all things that and should be done as soon as possible. (Non-exhaustive, but illustrative list)
Its out there on my GitHub if folk are interested. Ironically 53 comments just before I added this comment...
I started as an 8yr old, reading computer magazines, and initially coding in BASIC in 1K of RAM. I into Z80 Assembler and Machine Code at 10yrs - learning primitives like NMI's, Display DMA and Sound IO by hand with pencil, paper, and lots of reboot-causing mistakes. It was bruteforce, but still very influential in my understanding of a then-modern computer system.
Z80 was a simple-enough chip instruction set that I still remember most the mnemonics today, and many of the architectural principals are still valid even after so much time.
A game is rarely just the binary execution itself, but often depends on an interconnected mesh of services and downstream partners - most of which are rarely set-up/committed to multi-decade durability, especially as the surface area of problem domain, and actors/threats have grown. For example, who’d willingly port a service that only worked on Centos 5, with SHA1 hashed TLS, or the CDN service that your game update assets were delivered from in 2007.
The techniques to isolate a game from its gradually crumbling ecosystem are an after-thought when priorities are survive to shipping. I’m not inferring this is right or wrong, just indicating that it is not even in the calculus on the path to shipping.
While it is possible to use ES as your primary store, doesn’t mean it is a great use-case. Pushing ES to durability takes resources (people, time, compute) and rigor.
For a blog site this feels like overkill. Your priorities are durable low-freq writes, and more freq-reads. Hands-free day-to-day maintenance, and simple recovery mode such as restore. Caching (and optionally queuing) can absolve sins of many topologies to fulfill these requirements.
ES brings a much larger surface area than just store blobs and metadata. Big tax to gain free-text search - which while interesting most users will almost certainly never use (thank Google for that)
Focus on a cheaper, lighter, database engine that is durable, checkpoints regularly, and has simple, testable backup/restore processes. Ship the backups somewhere e.g. S3