HN user
What if my OTP base data is exported to a publically-readable datastore? I could be tricked into exporting the QR codes from Google Authenticator, for example. Though I see that there are significantly better 2FA methods, it does seem like the biggest flaws with SMS 2FA are in the insecure implementations, not the actual concept.
There is a pretty simple way to query cloudtrail logs with Athena and its a huge improvement over the normal UI.
Using excess electricity to generate hydrogen would be ideal,right?
I thought WW-style was mostly hot desks or hot offices? I was thinking something semi-permanent with additional privacy. Maybe that exists and I’m out of the loop.
I've wondered if there will be emerging business models for medium-sized, amenities-included (AP wiring, coffee, snack service, etc..), short-lease office spaces. Basically for when a company wants to downsize, but also wants to retain a little bit of physical space for meetings, events, and folks that live nearby. Nobody wants to sign a three year lease for their whole company, nor do they want a "we work" space where you'll be surrounded by random people. I think companies will want to hedge on short term accommodations. I don't have the real estate knowledge to know if this is even possible.
I'd forgotten the bit in here about the storage hierarchy, especially optical disks and immutable storage. I'm finding the modern "big data" stack with blob stores, immutable storage, and neutral formats (Parquet, Avro) to be useful, especially when it can be seamlessly read from a DBMS instance with its own optimized storage (Redshift, Vertica, and others can do this). However, I miss Postgresql's types and planner. From afar, it seems like Postgresql would be a perfect fit into this tiered ecosystem. Having a "hot set" in Postgresql and the "cold set" in a blob store for cost optimization in particular... as long as PG could use parallel query to maximize throughput over the higher-latency connection.
Interesting point. I don't think I have that particular use case, but I can definitely imagine it. I'd think especially with dates in the far future and the timezone offsets are altered between the time of recording and the time value itself?
A built-in timestamp type that stores both the UTC time, the originating timezone IANA name, and the timezone offset. Without loss.
"it was 2:01am on November 5th, in America/Los_Angeles and the offset was -7"
Half my job is doing this in reverse by accumulating deltas over streams and materializing the current state in various caching tiers. I'd love this to be native feature in PG, but for any my workloads it would need to support a lower-cost archival-grade storage tier ala a blob store.
I admit to being a little frustrated with systems engineers telling me I should never need shell access to a production system again, that web-based Metrics and Tracing should be enough to debug all problems. I have twenty years of muscle memory using strace, dtrace, lsof, blah blah blah to troubleshoot complex problems. Furthermore I'm only brought in when the problem is sufficiently complex. I understand that it should be a break-glass exception, but I don't want linux abstracted away completely.
I'm experimenting with using this VSCode feature to edit code on a Spark master, with the code storage on an EFS volume. So far, this seems to be allowing me to have a local-feeling environment, with a well-factored codebase that I can reference from a Jupyter notebook (inside VSCode), that has high-bandwidth and low-latency access to our data repositories.
I can also choose to temporarily vertically scale the remote host if I want to run single-node operations (ie Pandas).
I recall this article about the total maintenance costs of a Model X cab with 400k miles. It’s a very interesting look at total cost of ownership over time.
https://electrek.co/2020/05/11/tesla-model-x-extreme-mileage...
Yes. I like that TDD - when I judiciously employ it - makes me think about my interfaces. It’s like a pre-PR that forces me to question whether the intent is clear. It makes me reference guidance from DDD and single-responsibility-ish idioms.
Especially true when the services are all stateless. If there isn’t a conway-esque or scaling advantage to decoupling the deployment... don’t.
I had a fevered dream the other night where it turned out that the bulk of AWS’s electricity consumption was just marshaling and unmarshalling JSON, for no benefit.
I used a propane grill and it was very, very effective. I removed the grates and (if I recall correctly) rested the pan on the heat deflection sheets. I left all burners on for about 2 1/2 hours. After cooling, the previous coating was reduced to a thin dust. After blowing it off, the pan was gun metal grey.
I then used a cheap corded drill and inexpensive flap wheels and similar attachments from the hardware store to make it smooth, wearing an N95 mask to protect my lungs.
"Parquet files work well, but streaming is a tad more complex (you need to be able to seek to the end of the file to read the metadata before you can stream the contents)"
I didn't realize that all the metadata in Parquet was stored at the end. That is indeed unfortunate for streaming use cases. Especially sad because columnar dictionary formats can offer great compaction for some data. I've been achieving 20x+ size redutions by converting from CSV to Parquet.
Markup character and namespaces aside, I think what makes JSON easier to read is that it is more explicit about whether a child object is a singleton or a list, where XML requires you to consult the schema for minOccurs and maxOccurs.
https://gsuite.google.com/customers/
I don't think your comment is accurate, based on my first-hand knowledge of large companies that use gsuite, as well as their customer list in the above link.