menage

It's also not a phrase that you'd use of someone with a degree from Cambridge University, or I think any UK university.

All remaining funds are safe from future exploitation (of this particular bug).

> On used to run on, because it seems that there is no public information about the new platform after Borg.

I left Google quite a few years ago, but my impression is that Borg is still going strong for many of Google's services. There was an attempt to replace it with a new system named Omega, but that ended up being more of an experiment - some of the findings of which were rolled back into future Borg development.

> Google has been practicing ITIL, Borg comes out as a result,

Having been a member of the team that built Borg, I can assure you that those two things were unrelated. I can't say for sure whether the initial idea/impetus for Borg came from the management or the developer side, but once the project was started it was very much engineer-driven, and pretty organically so. The Infrastructure team at Google at the time (of which Borg was a part, along with several other related cloud projects) had a single manager for what grew to eventually 100+ engineers (mostly senior/staff level, and highly independent) before Google started creating/hiring managers more aggressively, so we were pretty much self-managing. The design and implementation of Borg was horizontal, both within the team, and coordinating with engineers (developers and operations teams) that would actually need to use the system. I'd say it was at least three years in before management really got involved in design decisions, by which time Borg was running most of Google's production services

It was a bit of a Wild West, but compared to some later major from-scratch design/development projects I've been involved in since, it was a Belle Époque.

Last time I had to deal with Google's account recovery (10 years ago when my mom fell for a phishing scam) there was an option to pay a few dollars to get to talk to a real human in a customer service / operations department. Does that still exist?

Only with a sufficiently narrow browser window.

Sounds like they didn't include the unit number in the duplicate-address check.

Or else maybe they are including it just for multi-unit addresses, but their database of multi-unit addresses is incomplete/stale.

I assume they mean 60% of total earnings, not 60% of base wages. Tips can't end up being more than 100% of total earnings.

The way the Swiss Germans pronounce "Basel", not the way the French and English pronounce "Basle".

I've always pronounced it the same as Basel, the city in Switzerland.

Agreed, they're not the clearest of names, particularly in a global cultural context. But they're not totally arbitrary like "type 1 error" and "type 2 error".

"Little-endian" and "big-endian" aren't completely meaningless - they originally came from a description of the history/war between two nations in Gulliver's Travels who disagreed about which end of an egg to open first (the big end or the little end)[1]. Bearing that in mind, it feels fairly natural to think of little-endian as meaning that you start (open) the transmission with the little part of the word.

[1] https://en.wikipedia.org/wiki/Lilliput_and_Blefuscu

That's 1.5M for a brand new house on the half-lot, versus 1.3M for the existing 60 year-old house on the original lot. Since the new house cost 700K, then in theory the lot next door could sell for 1.6M if you're assuming that you can split it via SB9, build two 700K houses, and sell them for 1.5M each (one of them after waiting 3 years for SB9 requirements).

One of the advantages of using Google Fi as your phone provider on a Google phone: there's no SIM, and you have to log in to the phone on your Google account in order to transfer phone/SMS service there. So an attacker can't use a SMS hijack to steal 2FA codes unless they've already compromised your Google account (which is hopefully a higher bar than convincing some random phone shop employee).

The server is named after that orbital habitat, but not by Simon - it's someone else's webserver.

On Android (don't know about iOS) you can take photos without even unlocking - double press on the power button opens the camera. You can't access anything else (including existing photos in the camera roll).

And then they got Steamrolled away if you didn't use them enough.

Most of them were CS researchers funded by DARPA, so they were paid for it.

Using your SSN for your driver's license would have been fine in a society where the SSN wasn't also being treated by banks etc. as a way to authenticate you for credit/loans/accounts.

> The kind of thing where, for upstream, you’d spend 90% of your time landing a framework just to even be able to implement your feature with the final 10% patch.

I feel this was a fair description of CGroups.

Cgroups is a great example of the problems faced here.

The cgroups code/API that made it into the upstream kernel was the product of a couple of years of internal experimentation at Google into ways to do kernel-level resource isolation, and was pretty different from the approach that was used internally in production on a rather older kernel version. (A bit like Borg vs Kubernetes). And it still took a couple more years for cgroups to replace the original internal mechanisms, since the internal way worked OK and upgrading the kernel across so many machines was risky.

I think "seriousness" has to be interpreted in the context of the programmer. I discovered computer programming at the ago of seven, and I was about as serious about it as a seven year old can be.

In my experience it's better (in terms of using solar vs steam) to turn it off much sooner than that (maybe 15% or 20%) so that you're minimizing the amount of wasted solar energy later in the day when the accumulators are full and the base isn't consuming all the solar output. You might end up with the steam turning on and off a couple of times over the course of a night, but it'll still be a shorter total time than if you wait until 50% to turn off.

But "a few months of toilet paper" is basically one pack from Costco.

Given that on https://onlineonly.christies.com/s/beeple-first-5000-days/be... they mention that they accept Ether, but only if it comes from an identifiable account at CoinBase or a few other exchanges (specifically not self-hosted wallets) it sounds like they're explicitly trying to avoid being used for money laundering.

I think that they meant that sequence is often picked by human players of the lottery. (Hence the 20 winners sharing the prize this week.)

The funny thing is that one of the complaints many people have about the cgroups API (text-based control files in a virtual filesystem, which came originally from the cpusets system) is very much in style of Plan 9.

It's true that a better userspace API for cgroups might have involved something more like ioctl(), rather than a filesystem with text-based control files. But people had been trying to get such APIs into the kernel for years with no success. Which is why we tried to piggyback on something existing.

Cpusets, which had already been accepted into the kernel a year or two previously, provided the basic userspace API for cgroups. It was just expanded to support control files for more resource types. (And multiple resource hierarchies, although that's gone in cgroups v2 I think).

It's probably true that public use of such technology can be dated to LXC. But cgroups, and the initial (private) userspace implementations, definitely come from Google.

There were many efforts to get some kind of container technology into Linux, from the early 2000s (and probably earlier). VServer, OpenVZ, etc, were all trying to support full server virtualization.

Cgroups was different from most of them in that it wasn't trying to present a virtual server environment, just facilitate resource control. At Google, all the jobs we ran on Borg (the internal system that later inspired Kubernetes) knew that they were in a shared environment, so there was much less need to fake a private virtual environment. The low-level libraries linked into all Google binaries did a lot of coordination with Borg to make the sharing fairly painless. But we were trying to run tens of jobs on each of our increasingly-larger machines, and some of the batch jobs would inevitably end up hogging resources, which would hurt the important latency-sensitive jobs. CPU and memory isolation were the main things that we cared about, with network/disk as secondary elements.

For a while (in 2005-2007) in Borg we approximated this by using the kernel's "fake NUMA" support (originally intended for testing the NUMA code) to break up the system into a bunch of fake NUMA nodes, and using cpusets to reserve CPUs and memory chunks to important jobs. It was pretty ugly and rather coarse-grained, but it worked rather well and was the first widespread (running on millions of Google Linux servers) userspace system for controlling a cgroups-like system.

Essentially, cgroups piggy-backed on to the existing cpusets mechanism/API which had already been accepted into the kernel, and expanded it into a more generic way of creating a hierarchy of groups and mapping a process to a group. This was a lot simpler to get accepted than an entire virtualization system. Given that mapping, making other resource scheduling be group-aware rather than just process-aware was much more straightforward. The same userspace support in Borg that had been used for controlling cpusets worked pretty much as-is with cgroups, since the basic API was the same (just more resources were supported).

> most propositions give the legislature no ability to modify it.

All the other statute initiative propositions on the CA ballot this year included a lower threshold than Prop 22 (ranging from 51% to 75%).

However, none of them (including Prop 22) allow the legislature to overturn it even if they achieve the threshold - only to modify "in furtherance of the original purposes" of the proposition.