smueller1234

The defense was only briefly about the actual thesis, then switched over to whatever research interest the committee members had, and they'd drill into their pet subjects. This was in physics, hardly politics forward normally, and at a very well respected university.

Additionally, they can use telescopes pointed at the atmosphere, using the atmosphere as a calorimeter, basically. The primary signal those telescopes look for is fluorescence, but when the direction of travel points at the telescope, cherenkov light far outstrips it in brightness, so it has to be included in the event reconstruction.

Most prominent contemporary example is the Pierre Auger Observatory https://auger.org

The Pierre Auger Observatory certainly is a large collaboration for the astroparticle physics domain though. It's a big international collaboration.

Quick anecdote: my name (S Mueller) is not on that paper's author list because we had a rule that you had to be in the collaboration for a year before getting authorship. You stayed on for a year after leaving. Very reasonable! At the time I was nonetheless a bit bummed about missing out on the big Science paper. I guess I'm on the retraction though ;)

It was a fascinating experience as a junior member to follow the collaboration internal conversation and investigation on this, because a lot of extremely principled scientists were clearly deeply worried about losing their hard earned reputation. In the end, I am convinced that we were simply unlucky.

[2] https://arxiv.org/pdf/0712.2843

https://cloud.google.com/blog/products/storage-data-transfer...

https://cloud.google.com/blog/products/storage-data-transfer...

Facebook's published content on Tectonic is quite good and I think it's well more recent than 2010-14.

(Current Google employee, just pointing to public content, hope that's helpful.)

They really did not appreciate the debugging experience, but maybe that's improved in 15 years. :)

It's actually a lot less user-facing per disk IO capacity that you will be able to "sell" in a large distributed storage system. There's constant maintenance churn to keep data available: - local hardware failure - planned larger scale maintenance - transient, unplanned larger scale failures (etc)

In general, you can fall back to using reconstruction from the erasure codes for serving during degradation. But that's a) enormously expensive in IO and CPU and b) you carry higher availability and/or durability risk because you lost redundancy.

Additionally, it may make sense to rebalance where data lives for optimal read throughput (and other performance reasons).

So in practice, there's constant rebalancing going on in a sophisticated distributed storage system that takes a good chunk of your HDD IOPS.

This + garbage collection also makes tape really unattractive for all but very static archives.

On the other hand, if you've been building your applications against expectations of different semantics (like POSIX), retrofitting this into your existing application is really hard, and potentially awkward. This is (IMO) why there hasn't been an overtly Colossus based Google Cloud offering previously. (Though it's well publicized that both Persistent Disk and GCS use Colossus in their implementation.)

One of the reasons why it would be extremely hard to just set up or build CFS elsewhere or on a different abstraction level is that while it may look quite achievable to implement the high level architecture, there is vast complexity in the practical implementation side. The tremendous user isolation it affords for an MT system, the resilience it has against various types of failures and high throughput planned maintenance, the specialization it and its dependencies have to use specific hardware optimally.

(I work on Google storage part time, I am not a Colossus developer.)

I don't know that it took "AI branding" to convince anybody. I think these workloads potentially enabled additional demand/market for such a product that may not have been there before.

One of the challenges with exposing native Colossus was always that it's just different enough from how people elsewhere are used to use Storage that there was a lot of uncertainty about the addressable market of a "native" Colossus offering. It's not a POSIX file system. Some of the specific differences (eg. no random writes) are part of what makes Colossus powerful and performant on HDDs, but it means you have to write your application to work well within its constraints. Google has been doing that for a long time. If you haven't, even if it's an amazing product, is it worth rewriting your applications or middleware?

Rapid Storage basically addresses this by adding the object store API on top if it (TIL from this thread that there's a lower abstraction client in the works as well).

Anyway, the team behind this is awesome. Awesome tech, awesome people. Seeing this launched at Next and seeing some appreciation on HN makes me very grateful.

This is Google + Thales doing the 3rd party operator model, with the operator being a subsidiary of Thales and not Google.

(NB: I work for Google in the EU.)

https://www.percona.com/blog/orchestrator-for-managing-mysql...

Please do some additional research into the state of maintenance of that piece of tech before jumping on it. But it certainly did a lot of powerful things for us back in the day. The automatic promotion of followers was key to our deployment.

With larger types that otherwise have similar semantics, you can still have breakage. A straightforward one would be padding in structs. Another one is that a lot of use cases convert pointers to integers and back, so if you change the underlying representation, that's guaranteed to break. Whether that's a good or not is another question, but it's certainly not uncommon.

(Edit: sibling comments make the same point much more succinctly: ABI compatibility!)

An "easy" solution is to do a layoff, then open roles elsewhere, allowing for selection.

It's commonly practiced across the large companies in the industry.

(Not speaking for my employer)

(I work for Google, but the above is public information.)

The two languages certainly both have their terrible warts. I think in the implicit conversion gotchas, JS is actually markedly worse. Perl has polymorphic values, but somewhat typed (for its basic types) operators (eg "eq" for strings, "==" for integers). JS has both implicit value type conversions and overloaded operators. That leads to an unholy level of indeterministic mess.

Eg. putting "use v5.14.0;" or similar on top of your file (or compilation unit/scope) will indeed turn on strict mode for you, along with adding a number of features as well.

At the time, also auto-toggling warnings was considered unacceptable because technically, using the warnings pragma anywhere had some edge case action at a distance. This has been remedied in some later release after I wasn't involved in the language development anymore, and from some more recent version, warnings are also part of the standard import.

I imagine you (TheDauthi) already know that, though.

The other side of this is that while Pieter's writing was marketing genius, it was also woefully understating the complexity of any practical use case. The way I tried to summarize that to folks who were keen to try zeromq then was that they should start at the back of the book with the most complex example, and that's by far the simplest setup that they could hope to end up with once they start thinking about putting something into production. And everything leading up to that - a book no less - was exclusively educational/toy use cases.

I've never dropped a piece of software as quickly as that.

Only poem I can cite by heart a quarter of a century after spending time with it in school.

That's another side of open source: if you don't rely on it to make a living (though it did help in getting my first job as a developer!), there's that pure joy in seeing your software get picked up and used by others. This little discovery made my day.

Years ago, some colleagues and I did the napkin math over lunch to estimate what a single hard drive would look like that could store all of Google's data. This was for a humorous internal talk. The linear speeds of the outer sectors were enough to leave the solar system (not just higher than Earth's escape velocity). Good laughs were had, I think.