Amazon actually tells employees that they have a "total compensation" philosophy, which means that when the value of unvested shares increases then Amazon will take that into account when issuing new grants (ex: as part of the performance review and compensation process).
For example, if Amazon thinks you should be paid $250k per year and your total comp for the next year is at $300k based on the value of your granted but not yet vested stock awards, then Amazon will not award anymore stock awards to vest in that year. This is different from most other companies that usually just give you a stock award with a standard vest schedule (ex: 25% vest over 4 years).
Amazon has justified this buy telling employees that if the stock drops below your TC target, then they'll award more shares to make you whole. So the question is are employees going to be down from their TC target, or from an inflated compensation number from during the pandemic when many employees were likely making more than their TC targets.
At least this was how it worked when I was employed at Amazon in around 2017.
Yeah, i worked at AWS and 100% heard leadership make this statement, even heard them make statements that they would issue more RSUs to make employees whole if the TCT dropped too much. Lots of us joked that that would never happen annd TCT was a one-way street- I guess we were proven right.
With x you're just bringing a window manager that plugs into the x-server. With wayland there's no standard 'window manager' plugin to arbitrary wayland servers. So the wayland example is doing more things (lots is handled by wlroots though).
Rust's cargo does something similar, however it looks like they were much more conscious of git-scalability (ex: limiting the directories in a single level, only appending lines to files to make diffs small).
For what it's worse, both of these characteristics indeed weren't an accident.
At the time, I wrote a script that hammered git commits into a repository using different strategies and looked at what the git repository would look like after 100,000 and a million commits. The "one version per file, nested in a flat structure" had serious issues.
There may still be scaling limits with the Cargo approach, but if we reach them, we have plans to create a new registry with a new initial commit and let the old registry age out, then rinse/repeat. At the moment, we haven't hit limits yet (with about 1/3 of the packages that Cocoapods has).
Lyft (as far as I know) won't show the driver your destination until the ride is started. It's intended to save time in allowing the driver to bring up directions and not as a decision point for them to decide if they want to take the ride or not.
https://chromeos.dev/en/posts/making-android-more-secure-wit...