Skip to main content

Quantum Messages Travel 254 km Using Existing Infrastructure For the First Time

3 months 2 weeks ago
Researchers in Germany successfully demonstrated coherent quantum communications over 254 km of existing commercial telecom fiber, marking the first real-world deployment of such a system without cryogenic cooling. Phys.Org reports: Their system uses a coherence-based twin-field quantum key distribution, which facilitates the distribution of secure information over long distances. The quantum communications network was deployed over three telecommunication data centers in Germany (Frankfurt, Kehl and Kirchfeld), connected by 254 km of commercial optical fiber -- a new record distance for real-world and practical quantum key distribution, according to the authors. This demonstration indicates that advanced quantum communications protocols that exploit the coherence of light can be made to work over existing telecom infrastructure. The research has been published in the journal Nature.

Read more of this story at Slashdot.

BeauHD

Hyperconverged infrastructure is so hot right now it needs liquid cooling

3 months 2 weeks ago
Lenovo brings its Neptune cold plates to servers packing sixth-gen Xeons to run VMware, Nutanix, and AzureStack

Hyperconverged infrastructure most often involves a collection of modest 2U servers powered by mid-range processors that aren’t particularly challenging to operate. But Lenovo’s new models packing Xeon 6 processors may need liquid cooling.…

Simon Sharwood

CodeSOD: Tangled Up in Foo

3 months 2 weeks ago

DZ's tech lead is a doctor of computer science, and that doctor loves to write code. But you already know that "PhD" stands for "Piled high and deep", and that's true of the tech lead's clue.

For example, in C#:

private List<Foo> ExtractListForId(string id) { List<Foo> list = new List<Foo>(); lock (this) { var items = _foos.Where(f => f.Id == id).ToList(); foreach (var item in items) { list.Add(item); } } return list; }

The purpose of this function is to find all the elements in a list where they have a matching ID. That's accomplished in one line: _foo.Where(f => f.Id == id). For some reason, the function goes through the extra step of iterating across the returned list and constructing a new one. There's no real good reason for this, though it does force LINQ to be eager- by default, the Where expression won't be evaluated until you check the results.

The lock is in there for thread safety, which hey- the enumerator returned by Where is not threadsafe, so that's not a useless thing to do there. But it's that lock which hints at the deeper WTF here: our PhD-having-tech-lead knows that adding threads ensures you're using more of the CPU, and they've thrown threads all over the place without any real sense to it. There's no clear data ownership of any given thread, which means everything is locked to hell and back, the whole thing frequently deadlocks, and it's impossible to debug.

It's taken days for DZ to get this much of a picture of what's going on in the code, and further untangling of this multithreaded pile of spaghetti is going to take many, many more days- and much, much more of DZ's sanity.

[Advertisement] Picking up NuGet is easy. Getting good at it takes time. Download our guide to learn the best practice of NuGet for the Enterprise.
Remy Porter