496 karma · joined March 20, 2013
It's actually a pretty good weight for measuring humans (14lb). Your weight in pounds varies from day to day but your weight in (half-)stones is much more stable.
https://www.scientificamerican.com/article/cats-are-perfect-...
Eventually the cause was narrowed down to that, randomly when the machine was stressed, the second half (actually, the final 2052 bytes) of some physical page in memory would get zeroed out. This wasn't great for the indexservers but they survived due to the defensive way that they accessed their data. But when we tried to use these new machines for Gmail, it was disastrous - random zeroing of general process code/data or even kernel data meant things were crashing hard.
We noticed from the kernel panic dumps (Google had a feature that sent kernel panics over the network to a central collector, which got a lot of use around this time) that a small number of pages were showing up in crash dump registers far more often than would statistically be expected. This suggested that the zeroing wasn't completely random. So we added a list of "bad pages" that would be forcefully removed from the kernel's allocator at boot time, so those pages would never be allocated for the kernel or any process. Any time we saw more than a few instances of some page address in a kernel panic dump, we added it to the list for the next kernel build. Like magic, this dropped the rate of crashes down into the noise level.
The root cause of the problem was never really determined (probably some kind of chipset bug) and those machines are long obsolete now. But it was somehow discovered that if you reset the machine via poking some register in the northbridge rather than via the normal reset mechanism, the problem went away entirely. So for years the Google bootup scripts included a check for this kind of CPU/chipset, followed by a check of how the last reset had been performed (via a marker file) and if it wasn't the special hard reset, adding the marker file and poking the northbridge to reset again. These machines took far far longer than any other machines in the fleet to reboot due to these extra checks and the double reboot, but it worked.
I coined the term "Xenoserver" back in 1999, for a paper in IEEE HotOS proposing an architecture for allowing systems in core networks to safely accept and execute code from untrusted users (for a fee, of course!): https://www.cl.cam.ac.uk/research/srg/netos/papers/1999-hoto...
I was inspired by the word "xenos" (meaning both stranger and guest, or in combination a stranger who you invited into your home) rather than the word "xenia" for the general concept of hospitality extended to such a stranger [EDIT: since I wasn't familiar with the word "xenia"].
The Xenoserver project at Cambridge University developed this idea, and eventually focused around the hypervisor, which took on the name Xen.
And even within Celiac disease there are a lot of variations. My mother has been diagnosed as Celiac for 50 years (back before most doctors had heard of it, and she almost died from malnutrition pre-diagnosis). She obviously avoids anything that has any mention of wheat, or has been cooked in the same oil as glutenous food; she generally avoids anything that mentions "possible cross-contamination" on the label but doesn't have to be a total stickler. I don't think she's had a serious attack in many years. A friend of mine was diagnosed as Celiac maybe 10 years ago, and is incredibly sensitive - despite his best efforts he seems to end up with horrible symptoms every couple of months or so just through tiny amounts of contamination.
The FDA limit for claiming something is "gluten-free" is 20 ppm; I believe that level exists partly because it's very hard to detect anything less than that anyway, but it also fits in well with what most Celiac sufferers can tolerate.
If you still have the option, then you haven't paid to exercise it. Once you exercise it, you have a stock (or the sale proceeds in the case of an exercise-and-sell transaction).
Rather than a normal distribution (sum of independent outcomes) with a big peak around 50% of the prisoners finding their number and a vanishingly small chance of them all (or none) finding the right number, you end up with a much more complex pattern - there's an approximately uniform distribution in the 0-50 successes range with ~70% of the overall outcome, and a huge peak at the 100 successes point with ~30%.
https://www.r-bloggers.com/2014/08/update-100-prisoners-100-... has a bunch of distribution plots showing this.
This was right at the start of 2020, and only working 3 days a week definitely helped me avoid pandemic burnout. But unfortunately I ended up working the 3 days that had the most meetings (this was a double-sided effect - it made sense to work those days else I'd miss important meetings, and then important meetings that included me gravitated to those days). So I ended up with 3 days that were stuffed full of meetings.
This was unpleasant enough that when the division was sold to another company, I opted not to take the transfer (and staying with the old company wasn't an option, as part of the terms of the acquisition deal). I'm now doing some flexi-time consulting that, while not as lucrative, gives a lot more latitude for scheduling my time.
At least in the past, almost all jobs ran in their own private filesystem - it was stitched together in userspace via bind mounts rather than having the kernel do it with an overlayfs extracted from layer tar files (since overlayfs didn't exist back then), but the result was fairly similar.
Most jobs didn't actually request any customization so they ended up with a filesystem that looked a lot like the node's filesystem but with most of it mounted read-only. But e.g. for a while anything running Java needed to include in their job definition an overlay that updated glibc to an appropriate version since the stock Google redhat image was really old.