menage

After SB10 was passed by the legislature, the opposition (mostly bail bond companies?) gathered enough signatures to force a "veto referendum", i.e. a referendum on whether SB10 should be adopted as the legislature had voted, or should be dropped. That referendum is Prop 25.

Edit: Parent is right, the link is to a different issue.

It may not eliminate it, but I'm sure it improves the situation compared to not being able to change jobs at all. I originally came to the US on an H-1B, and had no trouble transferring the visa to a new employer.

If you can find another employer to take over the sponsorship, you can transfer (without having to deal with the visa quota gantlet).

Something like that does exist for Google account access problems - you can pay a few dollars (which also ties you to a presumably-authenticated credit card, and so helps authenticate you to Google) for an expedited response.

But most of those billions of lines are not the low-level infrastructure relied on by many projects. To split out a single product would only require creating external versions of a much smaller subset of the code (and once that had been done once, other products being split out could build on that effort).

That's what the EDITOR environment variable is for.

The microcode here consists of sequences of the eight low-level gigatron hardware instructions, which implement the richer 6502 ISA.

Where's that? This was in Mountain View. I'll have to try again.

I've encountered a couple of gas stations that supported NFC, in the last year. The most recent one was at ARCO - although in that case I couldn't actually use it since they only accept debit and at that point I only had my credit card in Google Pay.

No, because multiple jobs being run by the same end-user could share data files on the machine, in which case they needed to share the same uid. (Or alternatively we could have used the extra-gid trick to give shared group access to files, but that would have involved more on-disk state and hence be harder to change, versus the job tracking which was more ephemeral.) It's been a while now, but I have a hazy memory that in the case where a job was the only one with that uid running on a particular machine, we could make use of that and avoid needing to check the extra groups.

[CGroups original developer]

Yes, for tracking processes and reliable resource control. Prior to cgroups, in Google's Borg cluster management daemon the best strategy I was able to come up with for reliably and efficiently tracking all the processes in a job was:

- assign each job a supplementary group id from a range reserved for Borg, and tag any processes that were forked into that job with that group id

- use a kernel netlink connector socket to follow PROC_EVENT_FORK events to find new processes/threads, and assign them to a job based on the parent process; if the parent process wasn't found for some reason then query the process' groups in /proc to find the Borg-added group id to determine which job it's a part of.

- if the state gets out of sync (due to a netlink queue overflow, or a daemon restart) do a full scan of /proc (generally avoided since the overhead for continually scanning /proc got really high on a busy machine).

That way we always have the full list of pids for a given group. To kill a job, nuke all the known processes and mark the group id as invalid, so any racy forks will cause the new processes to show up with a stale Borg group id, which will cause them to be killed immediately.

This approach might would have had trouble keeping up with a really energetic fork bomb, but fortunately Borg didn't generally have to deal with actively malicious jobs, just greedy/misconfigured ones.

Once we'd developed cgroups this got a lot simpler.

Presumably the withdrawing investor also gets the fund's cost basis in the stock, so they'll be on the hook for the fund's capital gains themselves when they sell the stock. (The article didn't explicitly mention it, nor does the relevant statute https://www.law.cornell.edu/uscode/text/26/852#b_6, but that's the standard way that stock transfers work.)

They missed out on antidisestablishmentarianism?

I don't think you even need a blacklist for this to be of real benefit - if every fancy bottle sold is expected to be accompanied by a blockchain transaction moving the bottle's certificate (originally produced by the winemaker, and unforgeable) then you'll only be able to sell a fancy bottle of wine if at some point in the past you've purchased an equivalent bottle from someone else with a certificate.

There is still the chance that someone along the way consumes the real wine or sells it (at a loss?) to someone who doesn't care about authentication, and then sells on a fake bottle with the real certificate - but:

- at least in that case there would be a well-defined chain of owners that should make it much simpler to figure out who's doing the counterfeiting.

- you can only do this once for each real bottle that you purchase, since you can't forge the certificates.

At one point during grad school (after far too much RPC middleware implementation work) I was able to decode hex dumps of CORBA packets in my head

For tender cuts of meat (like a good steak) it might be true that temperature is what matters. But cooking sous vide for 12-24 hours can turn a tough cut into incredibly tender juicy meat - the connective tissue needs time as well as temperature to break down.

I probably don't - my experience is very one-sided, as I've never tried Kubernetes.

To be fair to @elvinyung, a good chunk of your points five and six could be summarized at a high level as "switching costs".

> it’s not because of the design of Borg interfaces

As the original creator of the Borglet status page, I think it's not really accurate to describe it as "designed". :-)

It was more a case of gradual semi-random evolution, with people (mostly me, at least in the old days - I've no idea how much it might have changed in the last eight years) adding things that seemed like they could help Google engineers trying to track down issues with their Borg jobs. User-friendliness for random SSRF hackers was definitely not high on the priority list.

Google Maps has supported on-the-route searching for a while - it will give you a bunch of options on the map, indicating how much of a detour each requires.

Ivan definitely mentioned capabilities at some point in the evening - "I'd love to build a capability architecture but I wouldn't be able to sell it" (which he's also mentioned in previous talks) but it may have been after the camera stopped rolling.

As someone who's never programmed in Scala, it's not intuitive to me at all that "until" means exclusive, given that "to" (which is basically a synonym) means inclusive.

That sounds more like the process of applying for a Labor Certificate, as part of a green card. For an H-1B you just need an approved Labor Condition Application, which attests that you're offering the "prevailing wage" for the region/occupation, and (I think) that there's a general shortage of that occupation in the region (and not that you had no US citizen replies to your specific job advert)

It is! See the International RoShamBo Programming Competition: https://webdocs.cs.ualberta.ca/~darse/rsbpc.html

Perhaps some of the 1% might not realize they have an aptitude and passion for programming if they're not encouraged to try it properly?

A criminal conviction could lead to a fine.

That's mostly accurate. Lots of people (at Google, IBM, SWSoft and elsewhere) had been working on approaches to get resource isolation into the Linux kernel since around 2000, but none had achieved general support. The main debate was around the abstractions to be used for defining/controlling the sets of processes being isolated and the isolation parameters, rather than the actual mechanisms used for isolation.

Around about the same time (~2005?) SGI got cpusets merged into the kernel; this was initially just intended for pinning groups of processes on to specific NUMA nodes on big-iron systems. At the suggestion of akpm we started using it internally at Google to do coarse-grained CPU and memory isolation, by making use of the fake-NUMA emulation support to split the memory on our servers into chunks of ~128MB each and pinning each job to some number of fake nodes. This worked surprisingly well, but required painfully-complex userspace support to keep track of memory usage of each job, and juggle memory node assignments (particularly since we wanted to be able to overcommit machines, so we had to dynamically shift nodes around from low-priority jobs to high-priority jobs in response to demand).

The cpuset API and abstractions turned out to fit the resource control problem pretty well, and they had already been merged into the kernel, which gave that API a kind of pre-approval compared to the other generic resource control approaches. So we worked on separating out the core process/group management code from cpusets, and adapting it to support multiple different subsystems, and multiple parallel hierarchies of groups. The original cpusets became just one subsystem that could be attached to cgroups (others included memory, CPU cycles, disk I/O slots, available TCP ports, etc). It turned out that this was an approach that everyone (different groups of resource-control enthusiasts, as well as Linux core maintainers) could get behind, and as a result Linux acquired a general-purpose resource control abstraction, and other folks (including some at Google) went to town on providing mechanisms for controlling specific resources.

The namespace work was going on pretty much in parallel with this - it wasn't something that we were interested in since it was just added overhead from our point of view. The jobs we were running were fully aware that they were running in a shared environment (and mostly included a lot of Google core libraries that made dealing with the shared environment pretty straightforward) so we didn't need to give the impression that the job had a machine to itself. IP isolation would have been somewhat useful (and I think was later added in Kubernetes) but wasn't very practical to provide efficiently given Google's networking infrastructure at the time.

We weren't really interested in LXC since we had our own userspace components that had developed organically with our container support (and which as others have commented were so entwined with other bits of Google infrastructure that open-sourcing them wouldn't have been practical or very useful).

Yes, the concept of resource control wasn't new. Getting it from a research project to the form where it was production-ready and supported for inclusion in the mainline tree of Google's kernel of choice took a bit longer.

The GFS cell used back in 2004 for staging Borg binaries to production was /gfs/seven/, for the same reason :-)

We did try to write a paper on Borg way back in ~2008 but it got bogged down by internal disagreements on the style and approach ...