This is a hard problem to fix with UX, as evidenced by Apple's over-simplistic warnings.
e.g. Threads may collect your financial data! But only if you give it to them, usually to purchase ads or verifications, etc.. This scary warning is over-scary.
e.g. Mastodon collects less data about you, but there's no warning for "The backend is unencrypted and likely run by a handful of humans (who are probably nice but answer to nobody)."
There are a small handful of exceptions. Many were in the exactly the right place at the right time. That’s not a repeatable strategy. I wouldn’t start RedHat today.
Ah but the government will enforce my claim on the house if I’m holding (rightfully) the title. And if someone steals the title, it doesn’t mean they own my house.
Two things that jumped out at me:
1. It’s 2021. You can get a remote job for a big company that pays 10-15% less in Akron, not 40%. If you don’t want to work remote, you can still use BA remote salaries as leverage for local negotiations.
2. What “ggregoire” said: Engineers vary in quality EVERYWHERE. Many people holding onto CTO-type jobs in Akron or in BA startups can’t always move laterally. The salaries for everyone are rising in 2021, but for the truly strong (or for those who can nail an interview) they are rising even faster.
>In VoltDB, all replicas for a given shard are updated synchronously by the client application. This is where VoltDB pays a significant performance penalty for write operations when compared with Raft/Paxos-powered distributed SQL databases. Distributed consensus protocols like Raft and Paxos require writes to be sent to all replicas but commit as soon as a majority of replicas have acknowledged the request. Waiting for all replicas to respond is not necessary since the consensus can be established with a majority. Additionally, VoltDB does not detect network partitions by default and requires a special network-fault-protection mode to be configured. When a node of the cluster gets partitioned, the network-fault-protection mode comes into play. It negatively impacts cluster performance by increasing cluster recovery time for not only accepting writes on the shards whose replica was lost in the node partition but also for repopulating the data on the partitioned node when it joins back the cluster.
Well, 10km^2 is pretty tiny in a country the size of China, and I'm not sure how high up the pollution goes (higher than buildings but lower than planes).
So it's still a lot of pollution, just much less actual mass than I would have guessed.
That's really interesting. Maybe the pm2.5 is less visible than the PM10, but maybe I'm just way way off.
As for the volume of air, I'm most curious where the 15% measurement was taken and how consistent it was. How far from the tower? How many different places were measured? How many days are in the sample? What's the P-Value?
But still, thanks. Makes this interesting to think about.
So... to drop the PM2.5 amount by 15%, this tower must be removing many many tons of particulate matter every day. How is it removed from the filters they speak of? How expensive is that to do? I have some questions about the practicality.
On the other hand, I wonder if anyone's ever built a 100m placebo before. It could be a really interesting university study on the placebo effect in disguise.
You can have it both ways. Maybe you don’t get college credit for learning how to interview, but a college could offer a free seminar on interviewing well in the evening or something.
Colleges very much care how well their graduates do in the workforce, as it’s a key way they’re measured. It’s a tough balance to mix mind-expanding academia and direct preparedness though.
Worth noting that Apple’s share of high-end Intel chips is much higher. Thus, Apple’s share of Intel’s consumer revenue is probably substantially north of 10%.
Be was designed to be lightweight and parallel. It was optimized for many threads and the API pushed you to embrace threading. It also had pretty decent scheduling for media stuff. Not quite real-time OS, but closer. It was screaming fast and responsive.
The catch is that it was much less mature. It was single user and had very little real security. It had basic Posix support, but NeXT has much more rich BSD-ishness.
One reason might be that it seems easier to mix languages with Rust vs. Go. The C interop is pretty sane and Go has a few more gotchas in that department.
The rest of the Rust v Go debate may be similar to the 1000 times people have had it before.