HN user
Yes the entire purpose of Ingress was to make meat modules walk to under-documented locations, take pictures, and indicate points of interest. The meat modules seemed to think it was "fun". Hard to explain.
I just slept through third period every day.
I don’t get how this is supposed to work with sports and other activities. In high school I had water polo/swimming practice mornings at 6:15. Is that now illegal?
Have you considered/tried using the new ParseContext instead of CodedInputStream? It is performance-oriented.
Edit: Apparently it's also the default in protobuf 3.10
More people should try high performance services with non-traditional protobuf implementations. The fact that every language has a generated parser in no way preclude you from parsing them yourself. Hand-rolled serialization of your outbound messages can also be really fast, and the C++ gRPC stack will just accept preformatted messages and put them on the wire. Finally the existence of gRPC itself should not make you feel constrained against implementing the entire protocol yourself. It’s just HTTP/2 with conventional headers.
I'm not seeing the 1-year gap? I'm pretty sure where it says "January 2018" is a typo, was actually 2019.
Which part do you doubt: the assistant or the wifi? I never use the assistant stuff but the wifi is great.
Gsuite accounts never work right with every product google launches, often get features late or never. Many google products have _never_ become available for gsuite accounts.
Reading 100k rows per second from sqlite sounds WAY easier than serving 100k HTTP/2 queries in the same time.
Meetup doesn’t “run” these. You’re just picking boring ones. The only meetup I attend is a bunch of random motorcyclists who go up the coast highway every week. Never felt bored.
The result is pretty impressive. Go's scheduler is not this good. When my Go GRPC servers get up near 100,000 RPS their profiles are totally dominated by `runqsteal` and `findrunnable`.
Inside Google's main repo there are different build targets for libraries with incompatible API changes that are too difficult to fix all at once, e.g. there might be numpy_1_8 and numpy_1_10 separately.
Python at Google muddled along for years without numpy at all so it's not like anyone would be seriously harmed by having an old release in the repo.
All of the supposed flaws of a monorepo in this article are actually flaws of git. This is a very common phenomenon. I often joke there are two kinds of developers: those who prefer monorepos and those who have never used perforce.
The Mojave installer just up and trashed my whole file system. No reason to believe it can’t happen again. Always backup.
There isn't any. That's not how electric current works. If you leave a disconnected solar panel out in the sunlight it doesn't explode or whatever.
How can a university draw only ~50kW? That’s not even one rack of computers. I think you missed a large factor somewhere.
UCB has a 26MW gas turbine.
It’s not because of the lawsuit. Their grid really is dangerously under-maintained and prone to bursting into flames. Turning it off is the rational short-term move.
The university of California at Berkeley has ample cogeneration capacity but they are tied to PG&E grid and so PG&E can still turn them off.
Latency caused by packet loss. TCP needs microsecond timestamps and the ability to tune RTOmin down to 1ms before it is suitable for use in a datacenter. With the mainline kernel TCP stack you are looking at, at a minimum, a 20ms penalty whenever a packet is dropped.
Isn't it a pretty good reason? gRPC is terrible in a datacenter context without Google's internal TCP fixes that Linux won't adopt (and which have been advocated for in numerous conference papers since at least 2009). If they are steadfast cavemen what other workaround exists?
Google can't necessarily upstream everything because of social problems in the kernel process. For example their datacenter TCP improvements have never been accepted by the gatekeeper of the net subsystem, which was a significant motivation to develop QUIC.
It would be helpful if you could mention your employer so I don't accidentally go work in such a place.
Types improve productivity in large legacy projects. When I have to review a change in python I have to check absolutely everything from scratch. I have to look at the signatures of the called functions to see if the call sites are correct, where a typed and compiled language would simply fail to build. And I have to carefully check every block to see if attributes of none-typed variables are being accessed.
Python is a bit like a high-interest credit cards for coders. You can use it to make it look like you just whipped out a huge project from scratch. But you will spend the following decade paying down the tech debt.
That's so stupid. I've never met a real estate concern that had ANY employees. The fact that a building is owned by 1 guy who outsources everything does not make it a "small business".
Maybe, but that's not new. Atmospheric CH4 has been far, far above historical levels for decades.
This takes conclusions drawn in the article as givens, when those conclusions may not be supportable. I'm neither a phlebotomist nor a geologist, but is it really impossible that an animal's blood would soak into the loose, sandy soil pictured in the article and disappear? Or that scavenger animals such as ants would eat or carry off dried blood?
Mysterious cattle mutilations have been reported in the US for my whole life (long time!) and probably before. It was a meme for the kinds of people who believe in conspiracies by the US government to conceal the existence of UFOs and aliens on earth, long before it was a plot element of the X-Files 25 years ago.
There's nothing wrong with retaining full IP address information for the defined purpose of operating your site. Combining such information with other data to perform, say, ad targeting would be more problematic.
In my professional experience the distributed nature of git isn't used. Individual engineers don't distribute patches or pull branches amongst themselves, there's always still a central repository that is "the repo". Compliance audits of code and build artifacts in the business world pretty much dictates this model.
I think the fact that you can use git locally to work within your perforce workspaces indicates some commonality among the two models, but git has way more features, edge cases, and jargon.
I'm not really sure there is enough evidence behind your assertion. Google wifi APs have got continuous updates from Sep. 2015 to current day. Sonos players have been continuously supported for 15 years. Apple's just-released OS runs on 7-year-old hardware. There are and have always been fly-by-night organizations that sell junk with bad software and no updates. That's not new, nor is the existence of reputable vendors with long support policies.
Your argument seems to be that git, like all change control systems, is powerful and requires explanation. I would counter that there are other change management systems I can explain in 5 minutes, such as Perforce. Git is hard to explain because its model is a mess and few or no people naturally grok the model right away.