- waych parentFWIW git-branchless, an extension to git, addresses many of these points without leaving git.
- IIRC Google has a policy whereby all google3 binaries must be rebuilt within a 6-month window. This allows teams to age-out support for old versions of things, including glibc. grte supports having multiple multiple versions of itself installed side-by-side to allow for transition periods ("v5" in the article).
- The "runtime" is a google internal distribution of libc + binutils that is used for linking binaries within the monolithic repo, "google3".
This decoupling of system libraries from the OS itself is necessary because it otherwise becomes unmanageable to ensure "google3 binaries" remain runnable on both workstations and production servers. Workstations and servers each have their own Linux distributions, and each also needs to change over time.
- Given that this strategic reserve is to be built from all the various civil and criminal asset forfeitures, and not actually buying any crypto currency, how exactly is this considered a "wealth transfer"?
This is centralizing governance of forfeited assets from across the many agencies that are currently holding wallets with no direction, into a single place: the Treasury. This seems far favorable to letting various (430+) agencies manage these valuable assets on their own where they can easily be lost, stolen, etc.
- CSM is required for tools that aren't UEFI enabled. memtest86+ for example can't use a UEFI GOP and requires a BIOS capable VGA. Can't be used with a UEFI-only video card (e.g. recent ryzen igpu).
Also, there is still plenty of hardware out there that only comes with BIOS-capable option roms. These still require CSM if you want them to be be visible at boot.
- Managed async bulk transfers as-a-service seems relevant to anyone writing lots of data doing multisite including DR. You can easily have this problem and not have yet hit any other scale problems that are addressed by the alluded-to tools people love to hate (k8s, tf, containers etc).
What is being managed here with Effingo is the relatively tiny links between sites, not the bandwidth on the fat local links. Bandwidth needs to be managed and prioritized across all the various copies that are happening across different services apps and teams simultaneously across the company, and across the systems themselves as aggregate for the links. Managing it gives you control on cost but also ensures optimal use within the constraints imposed and consistent and reliable handling of the copy use case.
- > [1] e.g. because stock sales/purchases are still inexplicably not instantaneous it's conceivable something terrible could happen in the multiday period between purchasing your shares at a discount, and being able to sell them.
I recall participating in an ESPP where each time it vested (each 6 months) ended up being in a trading black out window, where we had to wait until Earnings Release + 3 days before being able to dump the stock. Lost that 15% gain just about every time.
- I forget where I first heard this, but whenever someone uses the word "folks", you can often replace that word with the word "idiots" and get the actual underlying meaning of the speaker.
Now not all speakers using it mean it that way, but it's a lazy word to use to group people, and the othering of people it implies seems to equally apply. The condescending tone really shines through.
If you intend on continuing to use this word to address people, know that at least some of us are making this conversion in our heads at all times.
- Cyclic logic that says you're wrong for wanting a stable kernel interface, because the kernel keeps changing so the solution is to just get your code merged into mainline. As a tautology, it's true, but it's also a cover for "because we don't want to".
See Windows or android GKI for existence proof that it can be done if so motivated.