puzzle

There was also a talk about the low level storage service and the performance isolation work that allows it to mix batch and latency-sensitive traffic on the same drive, but it doesn't seem to have been recorded: http://www.pdl.cmu.edu/SDI/2012/101112.html

Gory details are in the patents, 9781054, 9262093 and 8612990, which I'm not linking directly, because your lawyers might not approve. There's even a follow up, 10257111. It's so new, from two days ago, that Google Patents can't find it, while Justia can.

It looks like a lower tier than the existing Coldline and Nearline (7x cheaper for storage than the former). Both have a minimum period, so this one is likely to have one as well. Coldline and Nearline are more expensive than regular storage when fetching objects, which means ice cold storage is probably even more expensive when you restore (is it going to be 7x, too, keeping symmetry?).

"Fast" is relative here. It's fast compared to Glacier and others, but it's going to be slower than the more expensive tiers.

You might not need to speculate much about how it works, it's probably implemented as described by Google themselves in slides 22ff. here:

http://www.pdsw.org/pdsw-discs17/slides/PDSW-DISCS-Google-Ke...

(In a nutshell, pack some hot data with a lot of cold data on many large drives, then put a Flash-based cache in front of them to get long tail performance predictability back.)

Kind of. It's only the traffic management part, i.e. the external load balancer. It seems to be a mix of a managed Istio Pilot plus a bunch of stuff from GCLB: anycast, backend subsetting (Envoy does not do the health checking), etc. TD just tells each client which servers to talk to. It doesn't forward traffic. And it doesn't seem to be responsible for injecting the sidecars in clients.

I am pretty sure that was developed for Monarch. Perhaps later it was adopted by BM to consolidate storage, but still through a dumb API? I know that originally it had a bunch of files in GFS, with a layer of indirection, because there was a tool to fix them.

No, I think it's strictly about where aggregations and other computations occur. You hint at that when you mention CSV files. Borgmon keeps X hours of data in memory and looks up anything older from TSDB. I never understood how to aggregate data from the same service, after the fact, in a reliable fashion. Or if it was possible at all. I believe it was only working when looking at data in memory. That's why people had rules to aggregate data at multiple levels as it was being ingested, then persisting that into TSDB.

I don't remember the latter being much more sophisticated than a bunch of files in GFS with the timeseries and some metadata, either. Monarch, I think, is based on Bigtable. It has a richer API. It might even use BT coprocessors to perform computations closer to the where the raw data is stored, rather than in the Monarch frontends. (I haven't watched the public talk, so I'm just going from vague recollection.)

Ceph?

I miss TBR=. You should rarely use it, by design, but in those few occasions where it's warranted, it's very nice.

The actual proverb, by an engineer (Paul C), is "there are two ways of doing things at Google: the deprecated one, and the one that doesn't work yet". Usually the deprecation occurred when a service outlived the original requirements and was no longer a great fit or not very usable. A good example were Babysitter and GWQ, which were eventually obsoleted by Borg.

For many years there was also a wiki that just didn't refuse to die. I think that when I left there was yet another attempt going on to migrate the content away from it. Surprisingly, one of the main appeals was that its availability was independent of Google's production environment (Borg, GFS and co.). If Docs or Sites were down, which was slightly more likely inside Google because most employees were on dogfood builds, it was going to be a fun day...

If C++ is an option, Baidu has a clone called Tera.

Yeah, HDFS is a toy in comparison. It's barely comparable to the original GFS, which was retired... Almost a decade ago?

I remember Larry saying that in reality for a long time the homepage was spare because Sergey's HTML sucked (or vice versa).

I worked on a project that fell under her umbrella. I have seen up close some of the things she gets blamed for. She was demanding, a workaholic and stubborn in some of her choices. E.g. there was this one change that she —through her PM— insisted on, without any knobs, even if we pretty much knew that a vocal minority were going to be unhappy.

On the other hand, she did pick good people to lead the project, even if I wasn't enthusiastic about every single decision taken by her or them. Because she worked so much, it was easy to get feedback from her, too. :-) I also appreciated that she gave props to our team at a public event when we least expected it.

Overall, she wasn't a perfect leader, but she wasn't as bad or just lucky as some claim.

It's worse than that: the German press pretty much runs the show.

Does anyone outside the company know how DDG works? IIRC a job description hinted at their backend being in Perl, but little else has trickled out. It's easier to find out how Google works, through patents, presentations, the Percolator paper, etc.

Saying that Bing is one of hundreds of sources is like saying that PageRank was just one of Google's 200 signals. Or that Google was just one of hundreds during Bing's hiybbprqag brouhaha.

That's kind of how Google works, with multiple index tiers. Look up patents by Anna Paterson to get a few clues, assuming your lawyers won't bark at you.

Still, you can't keep partial results around forever, unless you want to make searches a lot more expensive, having to add a lot of capacity just to deal with the buffer bloat. Each query touches at least a thousand machines. Adding "a few more virtual machines" isn't going to cut it, especially if you have to handle tens of thousands of requests per second.

Behind the scenes, a search on Google involves at least a thousand machines.

How much extra state (internal connections, memory for partial results, etc.) would such a new search type create?

How do you deal with a new kind of hot spots now?

What if millions of people suddenly activate such an option?

What if a botnet does it?

How current is that page? Yahoo used Google since 2015.

Interview questions:

How would a search engine distinguish between the two kinds of queries, tens of thousands of times a second?

And how would one architect such a two-tiered system, particularly with an eye toward cascading failures?

Google's index has been in memory for most of its life now: http://glinden.blogspot.com/2009/02/jeff-dean-keynote-at-wsd...

It's actually more complicated than just a single static index, which is also why it's unrealistic to expect a search engine to be deterministic at scale.

The Amiga had 880KB (DD) or 1760KB (HD, with a special drive) floppies, but instead of increasing track count, it had more sectors (11) in each of the 80 tracks.

As with most coding questions, the important parts are when you start looking at corner or edge cases. Or when you refine your initial implementation.

The site says it compiles to bytecode and C++ source. Looking at recent commits, there's some non-functional WASM support: https://github.com/aardappel/lobster/commit/5b89bacd1b1d1e63...

It's already the minimum in NYC starting this year.

Sony had probably the most stylish designs among MSX manufacturers. They were not afraid of using curves compared to e.g. Philips' boxier style.

There was some other interesting stuff in the 80s, like the systems from Apricot (formerly ACT). There was the Portable

http://s11.photobucket.com/user/ballsandy/media/Computer%20r... (uncropped at https://cs9.pikabu.ru/post_img/big/2016/10/15/5/147651790013... )

which also had voice recognition, or the Xen

http://www.1000bit.it/lista/a/act/apricot_xen-i.jpg

which had programmable keys and LCD screen on the keyboard.

According to someone that worked on Blogger, a decade ago one of the top three or five sites in all of Greece was this blog, Troktiko, which tragically went into hibernation when the cofounder, a journalist, was murdered.

That's a good question, but I have a hunch and am willing to bet that by sheer coincidence they will focus particularly on the smallest of the seven named.

The A590 had both a SCSI and an XT header for internal drives (on the right side):

http://amiga.resource.cx/photos/photos/a590-5.jpg

I only ever saw them with SCSI drives in person, but they also sold XT units. Maybe you saw the latter?

The A590 was a drive that plugged on the left side of the A500. It usually came with a 20MB SCSI disk inside...

There was no room in the A500 for a 3.5" drive. Later, the A1200 and A600 had a built-in IDE controller and an internal bay, but for a 2.5" disk.

It might have been a SCSI drive/controller, but it might have also been that you used FastFileSystem, which was pretty efficient.

One of the HD manufacturers of the time, either Conner or Maxtor, was known to use Amiga 3000 machines to test their SCSI disks, because of the CPU/chipset/OS/FS combination. Not many systems were able to extract 90%+ of theoretical throughput like the A3000 could.