shereadsthenews

There's a zillion things you can estimate this way. A lot of sites use sequential cookies, user IDs, etc. Until about a decade ago UPS tracking numbers were sequential for each shipper which made it trivial to estimate output for online shops. Apple invoice numbers used to be dense and sequential and you only needed the number to retrieve the invoice. The IMEI is actually just about the worst way to have estimated iPhone sales in 2008; at that time you could literally have crawled Apple's website for every invoice whether sold online or in stores.

It's also pretty similar to `perf timechart`

RE2 state graphs are not generated at compile time.

The code of conduct is the #3 and #4 point of the Linux developer documentation.

https://www.kernel.org/doc/html/latest/process/index.html

Seems like for C++ builds you are always going to want the most cores for the money, even if the single core performance is a little worse.

True, Intel's part numbering scheme has passed beyond all reason. Think about the i9-9900K/KF. Existing SKU, in stock at Newegg for $479. You don't get quite as many cores but you get a lower price and higher single-core performance, and it exists right now instead of being unobtainable hypeware.

The 9980XE is just a really large/fast Skylake CPU. Skylake is years old. If you wanted this level of performance from Intel you could have ordered the Xeon Gold 6154 way back in 2017. It seems fair to call this a 2-year-old part.

A more comparable part would be the i9-9980HK.

Slack was also hard down 8 hours ago and been intermittently degraded since. https://downdetector.com/status/slack

These railguns also have synchronized pulsed power systems that are quite complex. The University of Texas has been researching this stuff for decades. Here's a simple paper I Googled up https://apps.dtic.mil/dtic/tr/fulltext/u2/a639371.pdf

In the West most "ranchers" are just running herds on BLM leases. It is not "their property" by any definition. By contrast virtually all ranches in Texas are on private holdings.

Article doesn't indicate the road is private. How do you know?

As a backcountry motorcyclist I'm accustomed to coming upon roads that are "private" because some rancher decided to hang a sign but in reality it's a public right-of-way. Also as a backcountry motorcyclist I'm smart enough to not drive a Prius down a mud trail. Not sure what is wrong with people today. We have more information than ever, we should be making better decisions than ever, but the truth is the opposite.

Alternate title: Until recently Brave was orders of magnitude slower than other blockers.

Is that true across the nation? I know California isn't the whole energy market but their renewable energy mix is solar, hydro, fission, wind, geothermal, and biomass in that order. It's true that non-hydro, non-solar sources are larger than hydro+solar, but not by a lot and none of the renewable supplies are carbon-intensive.

Wind, by the way, is growing much faster than solar in California and could be larger than solar within a few years.

Chandler is as related to the person responsible for putting musl in Fuchsia as are any two randomly selected software developers from anywhere in the industry. Having to disqualify someone from moderating a mailing list based on the union of all the conflicts of interest of tens of thousands of unrelated people is very silly.

That can’t really be the reason because SF has approved numerous such mergers and expansion of gigantic single-family structures and they steadfastly forbid subdivision of buildings no matter how large into duplexes in the vast majority of the city. The city’s actions indicate that detached single-family structures are the strongly preferred type.

It isn’t city policy to prevent such mergers but it is city policy that you must get a permit for such a merger before actually doing it.

Nobody would care except Peskin makes it his business to tell everyone else what they can’t do with -their- property.

The amazing part is how they serve you the full content of the article but then fail to serve their javascript that would allow you to SCROLL DOWN and read it.

When Pro Camera Rental still existed in SF, you left a deposit of the full value of the hardware you were renting.

Sure. In this specific case of a kv store it's hard to imagine how to simplify it dramatically from protobuf. As a proto you might have: tag-length-key-tag-length-value. Instead you could store the key and value lengths in host format using 8-16 bytes: length-length-key-value. It's not _dramatically_ faster to decode this, and you traded away extensibility to get a marginal speedup.

For simple protocols protobuf decoding has no taken branches. I.e. if you only use the first 15 field numbers (all your tags are 1 byte) and if all the types are the expected types, and if all the variable-length items are < 128 bytes long then you can decode the message without taking any branches. In C++. Most of the other languages have simpler and slower codecs.

This is the hot path in C++[1]. A really large amount of work has gone into protobuf C++ performance in the last 3 years or so.

1: https://github.com/protocolbuffers/protobuf/blob/master/src/...

If you knew your keys were uniformly distributed you would never use a varint encoding to store them because you'd stand a very high chance of encoding them into a field longer than a primitive integer. A varint can only hold 28 bits of number in the first four bytes, so your odds of getting 5-byte output is 15/16 i.e. very likely. If you really had to encode them I would use either two fixed64 fields, the experimental fixed128 type, or 'bytes' with the exactly-36-byte-long string representation of a UUID. In no case could I imagine packing a huge vector of random numbers into a protobuf int32 field.

I find this chart by age and cohort to be a bit more illustrative. https://imgur.com/gallery/UZVEt

Current USA antitrust doctrine dates from the 1970s.

Encoding an image as a repeated sequence of variable-length integers would obviously be a poor choice.

I don't know but how does complaining that it takes a microsecond to encode 256 random numbers lead to the conclusion that remote KV caches are unworkable? That's just a non sequitur.

I think it's irrelevant. In fact the protobuf might be the best choice. If it was just defined as so:

  bytes key = 1;
  bytes value = 2;

... your overhead can be as little as 4 bytes and you can alias the memory of the key and value (using a type like std::string_view) instead of copying it. It takes a few nanoseconds to decode a message like this.

An interesting take. When borg was written the main machine class was dual-dual-core opteron. Now I imagine the typical borglet has dual Haswell or Skylake CPUs with I guess between 40 and 88 cores. Do you think (or do you have data that indicates) the typical Google container/vm has grown to keep pace with the machine size, or do you think the mainstream container is still 1CPU/4GB?

Yeah, the only thing we can really learn from this paper is that the authors aren't very familiar with protobuf. Anybody who claims it takes 10 microseconds to decode a 1KiB protocol message is either intentionally constructing the worst-case message or doesn't know what they are talking about.

I have some real beefs with this paper. Their number about how long it takes to encode or decode a protobuf is wrong and misleading. It seems to be based on this benchmark[1] which encodes a huge repeated int32 stuffed with random numbers. This does not resemble a key-value workload at all. In a KV system you would have something like key and value as bytes fields. It would be extremely simple. By contrast this "benchmark" is the worst possible case for protobuf because encoding random data as varint guarantees that the average field takes 9 bytes instead of 8 and hits the slowest possible path in the codec. The whole paper rests on this number, so the conclusions are crap. They are not even consistent with the practical performance of memcacheg which the authors should have been very familiar with. 1: https://github.com/hq6/ProtobufBenchmark/blob/master/Benchma...