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.
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).
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.
Being a baggie for bitcoin begs the question that it’s necessarily going to increase over time. Given that Blackrock recently published a video reiterating the ground truth that there is no ultimate guarantee that the finite supply of bitcoin could not be increased, there are signs maybe this isn’t so bulletproof.
No one will ever persuade me to or vast swathes of other bitcoin node runners, to run a version of bitcoin with a higher cap. It devalues our bitcoin. It devalues bitcoin full-stop.
Sure, a new fork can be, and in fact are, created with a higher cap, but why would people choose it over a harder system with a lower issuance?
Even if it somehow took hold, the old harder version of bitcoin would beat the newer softer version just like it's beating the soft fiat money we currently use.
I think the unspoken rationale is that governments can compel you to destroy a market. Look at when the US seized all of the gold in May of 1933. Blackrock operates in time scales where this sort of risk awareness is relevant.
Sure. But how does a government, or even governments, compel bitcoiners all around the world to stop running a version of bitcoin core on their nodes (likely running over TOR)?
Well considering the feds have charged and sentenced people for the activity of their exit nodes (CSAM), to which tor project has no response, I wouldn’t bother with Tor.
I’m sure the feds could force funding attached to crypto accounts to be verified by a trusted version of the bitcoin network or they are not legal to trade. They don’t have to physically stop the mining or validation, just the on/off ramps and banks who use it as collateral.
> Well considering the feds have charged and sentenced people for the activity of their exit nodes (CSAM), to which tor project has no response, I wouldn’t bother with Tor.
I'm certainly not a Tor expert, but I don't think bitcoin nodes running over Tor require an exit node. Even if they did they don't need to be located in the US.
> I’m sure the feds could force funding attached to crypto accounts to be verified by a trusted version of the bitcoin network or they are not legal to trade. They don’t have to physically stop the mining or validation, just the on/off ramps and banks who use it as collateral.
We could debate the details on a per-nation basis, but ultimately it's pointless. Even if it is possible for a nation to completely suppress bitcoin use within its borders, there will always be some country somewhere that embraces bitcoin and value looking to be stored will always migrate to the best store of value (bitcoin), just as air moves to the lowest-pressure volume, bitcoin miners move to areas with wasted, unwanted energy and electrons travel to less negatively-charged parts of a circuit.
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.
That's relatively rare in tech, but some companies are very touchy about their trading windows. Usually smaller companies, lower floats, lawyers trying to manage insider trading risks, etc..
For larger companies, it's almost always -- ESPP purchase happens, you can sell it immediately.
This is mixing up cmd.exe which is the dos-like (but not dos) scripting interpreter, and conhost.exe which is the actual old terminal emulator/console that the kernel would spin up whenever you ran cmd.exe.
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.
That’s pretty cynical, and maybe not the smartest way to communicate. A similar argument can be made for “people”, and it already was made in this thread before I commented. A speaker can’t be expected to walk on egg shells because there are cynics in the audience who refuse to accept neutral and common usage of words. If someone chooses to interpret a word differently than it’s definition and normal usage, it reflects on them and not the speaker.
> Calling people “folks” all the time is lazy and insulting.
No it’s not. “Folks” means “people”, it has for more than a thousand years, and it’s used most often with the exact same intent. You’re making negative and incorrect assumptions.
If you say so, though I can’t say I’m super convinced by your opinion; it doesn’t seem like you’ve made a reasonable case or brought any evidence. To be fair, it is legitimately hard to argue with the dictionary and all of history, but I wish you good luck communicating with others! BTW, did you intend for that to be a self-own?
