uluyol

Israel has been begging for the US to get more involved.

Like how they are provoking Hezbollah with their "double-tap" strikes.

If the purpose of keeping emissions low is humanitarian, then there is a much bigger humanitarian concern at the center of all this.

I don't think this applies to any of the incidents mentioned in the article.

Density is one of the main ways to get cost savings. But there are others too, and there's also a lot of hype around them. Chiplets for example. Or CXL for memory.

Yes, but no customer wants to give Nvidia monopoly money forever either. So like it or not they need alternatives.

These stats can be misleading for other reasons as well.

The US and EU have a lot of existing infrastructure, construction of which required enormous amounts of CO2 emissions. Countries that are still building out their infrastructure should be expected to expend more CO2 per capita to catch up. (Modern equipment is more effecient, but still).

Yes, the main difference would be that distributed systems have more failure modes to be concerned with and that dictates a lot.

Just a minor point: while tsan is extremely helpful, it is not guaranteed to catch all data races.

The Palestinians are not intermittently but continuously oppressed. Israel can stop it at any time but chooses not to, hence the retaliation by the Palestinians. What Israel is doing now is not retaliation but doubling down on their standard M.O.

You've got the history backwards, friend.

You can implement the interface from other packages through embedding

    type ColorWrapper struct {
        color.Color
        ...
    }

ColorWrapper will implement color.Color. I don't know what the point would be, but another way to break the compile-time type safety.

I believe 1.87 MB was in the context of CPU processing time, not network.

Catching up in this space requires a significant, sustained investment over multiple years and competent software engineers. It's not a simple thing for a hardware company to suddenly become competitive with Nvidia in AI/ML.

Instead, they've been going after the CPU market (and winning), HPC/scientific computing (high FP64 performance, in contrast to Nvidia's focus on low-precision ML compute), and integrating Xilinx.

However, I agree that it's an unfortunate situation, and I hope AMD becomes competitive in this space soon.

The faster-cpython folks seem to be working towards a JIT (https://github.com/faster-cpython/ideas/tree/main/3.13) and both pyston and cinder have JITs. So I don't think anyone has ruled one out.

What did they discontinue? https://v8.dev/blog/speeding-up-v8-heap-snapshots was posted less than a month ago.

C++ unfortunately does textual inclusion for header files. So "-std=" does not automatically work for those. You need to sprinkle in #ifdefs rather than getting automatic forward compatibility.

I hadn't thought of this, but this is an excellent point. Oracle vs IBM, who wins? The lawyers for sure, but for outsiders there would be no downside.

It's also about reuse and fungibility.

AMD has used the same IO die across multiple generations of Zen hardware. This cuts the dev and validation costs for using new processes.

Fungibility helps reduce the cost of making SKUs. Want more cores? Add more compute dies. Your customers want more big chips then expected? It's easier/faster to adapt production since only the final steps differ. The component pieces are the same.

I don't agree and my job requires that I program in C++. It's different, yes, but it's only strange if you learn about C or C++ first.

Whether you agree or not, I definitely think that promoting loop variables to be heap allocated is consistent with the rest of Go.

In Go, you can take the address of a local variable and return it. It will be allocated on the heap automatically.

This is weird for C++ programmers that think about the stack vs heap, but perfectly natural for Go. In Go, stack allocation for variables is a compiler optimization, not part of the language semantics. Go also only uses scope for visibility, not RAII.

It would be a bit odd to build capacity for spot instances. The whole point of low priority, preemptable instances is to fill up the capacity that you have available, but have earmarked for scheduling big jobs or handling failures (say a power domain or decent chunk of the network goes down).

Otherwise they would be no different from any other instance type.

Intel is still making plenty of server CPUs (and other components).

Samsung and Intel exist and can serve TSMC clients for bleeding edge nodes. More fabs exist at older nodes. So if something happens to TSMC, there are options.

Though it would require significant work to move. And the alternatives may not perform as well. And there 100% would be supply shortages.

So overall pretty bad but I think Apple could survive it.

A lot of software might not need to be implemented in C... but it is. Not just one piece either, but there's ecosystem effects at play too.

Rust interops much better with C than most languages, including Java, and offers a smoother transition path to increased safety.

It sounds like the energy capacity and power output can be scaled independently of one another. But as this article is meant for a wide audience, I think they simplified the discussion by making some assumptions about the desired power output per kWh stored.

Not unreasonable. The details are always in the research paper after all.

At 10% it's approximately the same. But say 50% instead.

If it takes 1/2 the time to do something, you can do double the work in that time.

If on the other hand, you can do 1.5x the work in the same time, it means you've made it use 33% less time than before.

With 10% less time you're taking 1/0.9 = 1.11111x more work in the same time.

Unless it says otherwise, it's generally safe to assume that an article put out of a university is in the early research phase.

This works when your serialization format is designed to be either big or little endian. But for some programs, the serialization format is memcpy the structure to disk. This isn't a good strategy, but unfortunately it can be difficult to undo historical choices.

So the padding, alignment, endianness, all leak. And it sounds like X does something like this: clients expect the endianness of serialized data to match the local machine and the server can optionally account for this.

I can see how you might want HTTP/3 across data centers, but you may want to stick to HTTP/2 for intra-DC workloads.

There's a ton of work to optimize TCP including hardware offloads that help push higher throughput. Basically we're talking library + kernel + hardware changes. It might be possible to get some of these into QUIC, but since QUIC is most compelling for WAN traffic, there's probably not much incentive for that.

This depends on your university, and also you should compare against a benchmark that's not cushy tech companies. I had spouse + child health care with no premium and only copays, no coinsurance. Didn't need the child care benefits so I don't know about that specifically.

PhD students really don't get paid much. Tuition is waived if you're a TA, and you get a small stipend + good benefits. If you're an RA, you bring money into the university (through being the engine that pulls in grant money and having your tuition paid).

Most students I know were TA for one or two semesters and RA for the remainder of their 6 years. As far as I can tell, they are all a financial gain, not drain, for the university. That will likely depend on the department though.

I don't know about Masters students.