I can beat this by not trying to wrap a trace span around something that only takes 100ns.
If the thing of interest just runs on the CPU briefly, tracing is not what you want. You want a profiler that only runs when you're looking at it. Distributed tracing is for things that can go wrong and take uncertain amounts of time.
You might've misunderstood the requirements. The time scale was 1-10 micros per component; 100 ns was the overhead per span we were aiming for.
In this case distributed tracing absolutely was the right choice. These were not simple computational tasks. The components were highly stateful and interconnected both on- and cross-host. Between this and the timescale, as well as the volume of events and the dollar-value impact of each potential failure (of which there were many), we needed real-time analysis capabilities, not a profiler.
I guess my skepticism about the application colored my reading of the rest of it. If it had only said you needed it to be faster, that would have been easier for a simpleton like me.
The "picks and shovels" people from the dotcom days all went broke. The stuff they had convinced themselves and their investors was crucial turned out to be not important.
Nobody actually goes broke anymore man.
They'll still be multi millionaires. They will still have a contact list.
Hell you will receive a pardon if it comes to that.
It's actually really hard for the aristocracy to end up in a Florida trailer park.
Well, I worked at a picks-and-shovels scam where four executives were convicted of federal offenses and two got prison sentences. I don't know if they are still rich or not.
Cisco is doing great. Sun got acquired by Oracle. Oracle itself is also fine (apart from it is Oracle). Akamai is doing fine.
From the pure software side, Macromedia got acquired. RedHat was doing fine before IBM gobbled it up. But I honestly can't remember any other "picks and shovels" software companies from pre-dotcom.
The glass-in-the-ground people went spectacularly broke. I also suggest you look up the stock price chart for JDSU. On the software side, Ariba and Commerce One.
Yeah, hardware companies got hit hard. But dotcom also coincided with the de-industrialization era, with manufacturing moving out of the US, with a double whammy of commodization. So it's hard to disentangle the causes.
And then I can't really remember many Internet-focused software pick&shovels companies from that era. I was only starting my professional career at that time, though.
Nope. To efficiently tap geothermal energy, you need to boil something but not necessarily water. Isopentane, for example, boils at 28º at standard pressure, so they pressurize the secondary loop to raise the boiling point close to whatever the primary loop temperature is.
The idea that geothermal only works well at steam temperatures is outdated 20th-century thinking.
Yes, the efficiency is worse, but as is also the case for solar power you need to get used to not caring much about efficiency. It is nuclear energy where the primary side is provided free of charge. The Carnot efficiency is almost without relevance.
In geothermal there is still a lot of interest in efficiency and exploring different working fluids because binary systems now have efficiencies of 10-20%. That is why you see companies like Sage Geosystems working on developing / deploying supercritical CO2 turbines to try and boost practical power densities.
To me, Flickr is the better Photo.net. Photo.net has been around since 1993 and apparently is still running, but it never was a site where you could just collect your own work and share them the way you wanted. It would be interesting to read about how Flickr succeeded against an older, established competitor.
photo.net is the water cooler. flickr is the portfolio. They're different. I never talked to anyone on flickr. I'm still friends with people from photo.net
photo.net is more like a public ridicule session that Maoists would have dreamed up. It was impossible to just post a photo there without every rando on the site feeling like they needed to criticize your composition and exposure.
Urs used to talk (internally) about not publishing "industry-enabling papers" which is why most Google infrastructure papers were describing something that had already been turned off, or was already in the process of being replaced by the next system (GFS, Vitess, etc). The things that did get published were either considered not key advantages, that other companies simply cannot do, things that other companies wouldn't bother doing, or experiments that never worked at all. There were exceptions of course. But it led to a public perception of the Google stack involving mostly technologies that were long dead or were never adopted.
"Attention Is All You Need" was a very very different thing and I also wonder if they are glad they published it. But I imagine if they hadn't, the motivation for researchers to leave Google would have been even larger.
It makes every bit as much sense as investing in Snap while still operating their own social network product. Seems to have worked out fine (for Google, not Snap).
Right, doctors and CIOs get to use AI transcripts but you, a lowly patient, will write your name, address, and insurance policy number fifteen times with an exhausted Bic pen.
That fraction is going to depend a lot on the definition and the reference. I believe the 97% is the US standard for how much of the natural caffeine in green beans must be removed. You will note how this can be manipulated by using a more caffeine-abundant variety. EU standards are more sensible, stated in terms of caffeine content in the final product.
Either way, commercial decaf processes and normal brewing methods will yield something like 5-10mg of caffeine in a "decaf" dose of coffee, which is an order of magnitude less than usual.
I'm really glad that last slide is in the article because I've been wondering this about Intel's push to become the king of thru-silicon vias, but didn't want to be the one sounding ignorant. When you etch holes in glass, fill the holes with metal, then solder it to something else, how does it not just shatter? The article just acknowledges the issues without suggesting where the solutions might come from.
True, but those metal/glass devices are made by joining a pair of a certain metal alloy with a certain kind of glass, which are chosen to have matched thermal expansion, for instance kovar alloy with borosilicate glass.
If you join a random metal-glass combination, it will fail soon. When incompatible metals and glasses must be joined, the metal is covered with an alloy and the glass with another kind of glass, so that at the interface you have a matched pair. Sometimes more layers with different kinds of glasses are used, to ensure a gradual change in the coefficient of thermal expansion, so that no adjacent glasses would differ too much, which would cause cracking when the temperature varies.
In TFA it is discussed that the problem is that copper has a much higher thermal expansion than any glass, so you cannot match it. Moreover, at the very small sizes that are desired, it is hard to cover copper with some other metal that is matched with glass, without leaving too little volume for the copper, which would increase the electrical resistance.
For the manufacturing of electronic vacuum tubes and also for the first transistors and integrated circuits, which were packaged in metal cans, the discovery of the kovar alloy, which can match the thermal expansion of a certain glass, was a necessary precondition. Kovar was a derivative of the invar alloy, which has a much lower thermal expansion than most metals.
My intuition is that you get shattering when one part of the glass wants to warp across or away from another part that can't. Because of how thin the glass is in these processes, you mostly get warping and edge chipping, rather than something that can propogate catastropically
Strongly held but apparently not popular opinion: candidates should not be expected, and should refuse, to discuss confidential internals of their former employers.
There's no need to ask about anything confidential. Meta published a lot about their internal tech stacks, and they use plenty of open-source stuff. ZippyDB, Interview candidate can also talk about generic stuff, and I can drill on the theory or common practice.
What is confidential, exactly? I once had a contract that said that I cannot discuss any technology I used for two years after the contract ends. _Any technology_. So, git. And Postgres and so on.
It's completely normal in tech circles to talk about technology.
I think he's saying that during interviews the candidates were being asked to dive deep into their preceding employers' tech stacks. Which does seem to be asking them to tread in dicey legal waters in a coercive situation.
I see. Always stuggled with this. I think design interview on hypotheticals is better. Or have you used X with follow up questions about X? Probably OK to say we used kubetnetes. But not OK to describe inner workings of a custom controller that speeds up their workloads even if candidate wrote the code.
If the thing of interest just runs on the CPU briefly, tracing is not what you want. You want a profiler that only runs when you're looking at it. Distributed tracing is for things that can go wrong and take uncertain amounts of time.
reply