This work seems so much more challenging, interesting, and fun compared to what I do as a senior software engineer. Why does hardware engineering pay so much less??
Most employers in the U.S. over about 1,000 employees are “self-insured”, meaning they hire the insurance company for the network and administration, but the company actually does directly pay out claims. At over 1k employees, I expect MailChimp was already self-insuring, and Intuit definitely does.
No mention of permafrost? Yes, the _air_ will be more habitable, but if the _ground_ is a boggy mess, you’re not going to be doing much with this newly habitable land.
I get the sense that hyperscalers don’t give Intel a ton of margin in negotiations, so they already have access to great server chips at competitive prices. And they’re bringing in AMD now to compete. Where M1 really shines is client-side applications like video handling, ML inference, and crazy branchy nearly single-threaded code. Servers can afford to run much lower clock speeds (see GCP n1 family, for example) because web serving is an embarrassingly parallel problem. Sure, some ARM might help lower costs of internal things like S3, but Graviton2 isn’t that incredible compared to the M1-vs-Coffee Lake comparisons going on in the laptop world.
I’m rather happy about buying the recently updated 13” MBP and basically skipping ARM Macs. My last one lasted 8 years, so I expect this one to last roughly as long. By then they’ll _definitely_ have ARM figured out, and in the meantime I can continue enjoying x86 compatibility and VMWare. For the fairly small segment of the market that we devs represent, I suspect I’m not the only one here implementing a _reverse_ Osborne Effect. Get your x86 Mac while you still can!
This is essentially what RISC-V does with its "Compressed" instruction set, except without the dictionary switching. They pulled a bunch of statistics over real-world machine code, ran it through compression, then reverse-engineered that compression to make something a bit more sensible to a compiler writer. I think this will work out vastly better than the haphazard patching of e.g. Thumb on ARM.
Oof. This really hurts. So often when folks complain about Google shutdowns, I defend G with “but that was a consumer product! GCP doesn’t kill off things. It’s different.” But here we have Google Cloud (in my defense, not GCP) killing off a powerful, proprietary Enterprise product with no viable migration path. At least folks get a year to migrate off, but that’s a lot of sunk cost.
I love my ARM-powered Chromebook. True, it can’t teally do native development, but ARM clients aren just coming. They’re here. And wow doesn’t have amazing battery life and an unbrickable OS.
I tried going down the route of dealing with OFX in GNUCash, and it's just a huge never-ending hassle. Tiller dumps the raw data from Yodlee (the backend that does the gnarly interfacing and cleaning for most PFM sites, besides Mint) into Google Sheets. From there you can use Apps Script or the Sheets API to push the data wherever you want. Sure, it's $5/mo, but well worth it for not ever dealing with bank websites or APIs or OFX formats again.
Methane deteriorates in the upper atmosphere fairly quickly, whereas CO2 sticks around. Methane is a dramatically better insulator than CO2, so in the short run its impact is higher, but when you stretch out the timescale, your methane is deteriorating while the CO2 sticks around, so the relative impact tilts slowly toward CO2.
The difficult part of separate AWS accounts is that connecting between them is tricky (Security Groups, VPC, etc.). Not impossible, but a pain to get right. The spectrum between dev and prod isn't so clear-cut for a business with petabytes of data: you often want to develop systems against production data (read-only, of course), and having two copies of the data can be prohibitively expensive. Of course, with the appropriate access policies you can share the data safely, but then what about that IRC server that was non-production but then wound up part of the deployment flow and became mission-critical?
Yeah, we connected with LDAP because that's how AdRoll operates, but we'd like to support a more universal backend eventually. That support just didn't make the cut for open-source release. With a bit of code, you could easily plug in a .txt file or a SQLite database, or even etcd if you really don't want to move a file around.
Yeah, when we spoke with Amazon, they already had a couple of labels for what hologram is, so it sounds like we at AdRoll are not the only AWS customer who has had to roll it ourselves. Hopefully we'll be the last!
The hologram server is privileged and should run behind a firewall. It will only hand out keys to successfully authenticated (using an SSH challenge-response) clients, so it could be publicly accessible, but why go to that risk?
The hologram agent that runs on your laptop, and could potentially be exposed in a cafe, attaches to lo0, so there's no way somebody on your coffee shop wifi could get the creds.