HN user

nicktelford

948 karma
Posts4
Comments168
View on HN

When you use Through-Silicon Vias (TSVs) to connect the layers together, you would start to end up with scaling limits, similar to the problems of elevators in skyscrapers: the more layers you have, the higher the density of TSVs would (presumably) be required.

This is probably not an issue for thermal TSVs, because of the heat spreader layer between each silicon layer, but it would become an issue for power TSVs, as each layer would (presumably) require an independent supply of power.

Yeah, the British space industry has struggled; principally with investment. Reaction Engines largely went under because they ran out of money and their investors declined to put more money in.

My hope with Pulsar Fusion is that their existing thruster business provides the necessary revenue to both keep them solvent, and attract continued investment, until they're able to get their Fusion Drive off the ground.

There's also Pulsar Fusion, a UK company currently building a Dual Direct Fusion Drive (DDFD). They claim:

Modelling shows that this technology can potentially propel a spacecraft with a mass of about 1,000 kg (2,200 lb) to Pluto in 4 years.

They're apparently targeting an in-orbit test in 2027. Even if this were to slip to 2030, and becomes commercially available in 2040, I expect that would be plenty of time for a rendezvous with Sedna's perihelion

I find it a bit bizarre that this JEP doesn't enable Compact Object Headers by default. Most users will not know to specifically enable it, so if they're that confident in its stability and performance, why not enable it for everyone?

The JVM used to have a reputation for requiring byzantine flags to properly optimise its performance (mostly GC configuration). We've mostly left that behind these days, but it feels like JEP 519 takes a step backwards here.

This is why I generally use Terraform for Kubernetes. It's not perfect, but it's miles better than the various different YAML-templating solutions (Kustomize, Helm) popular in the Kubernetes ecosystem.

Isn't this essentially the same problem with Dark Matter though? They keep looking for it, not finding it and proclaiming "well, it must be somewhere else!".

I always got the impression that when Dark Matter was initially labelled as such, it was just a name for the discrepancy between theoretical models and observations; and that the name itself seems to have driven this idea that it's the observations that are wrong and not the models.

Personally, when discussing Dark Matter vs. MOND, I think neither should be treated as a concrete "theory", but simply a different perspective on where the problem lies. "Dark Matter" is the idea that our observations are incomplete, and MOND is the idea that our theoretical models are wrong.

Hopefully this conundrum is resolved within my lifetime, because I'd love to know what the answer is. It would be absolutely wild if they're both right i.e. that our observations are incomplete and our models are wrong.

It always irks me that discussion of space debris invariably talks about their high velocity relative to the ground, which is completely meaningless.

What really matters is their velocity relative to each other, which of course will vary, especially for objects on different orbits that happen to intersect.

The closing velocities involved can still be very high, and the "bullet" metaphor still applies in most cases, but it's misleading to label them as travelling at "17,500 mph (28,160 kph)".

The other thing that always bothers me is the graphical depictions that show a "point cloud" of debris in orbit around Earth. These always underplay the size of the earth and overplay the size of the orbital objects.

When discussing space debris, it's always worth remembering that there's approximately 10,000 planes in the air at a given time, and yet if you look up, how many can you see in the sky above you?

Since orbits are much higher, they're consequently much larger, providing even more available space than there is to commercial aviation. Not only that, but there's a far greater altitude range available for satellites than for planes, making the available space out there even more massive.

I don't doubt that space debris is an (emerging) problem, but the current severity of it often seems overplayed by the mainstream media.

They honestly should be blacklisted after the Horizon scandal. Allowing them to get away with it sets a precedent that could encourage other companies to behave just as irresponsibly.

As it stands, is yet another example of privatising profits while socialising the costs, just in this case, the costs weren't (entirely) financial.

This is a false-equivalence. "Milk" is not a trademarked brand name like "Coca Cola" or "ChatGPT", it's a category of food/drink. You can't trademark "milk" in the same way you can't trademark "sausages".

A better comparison would be "Not Cola", which AFAIK would be an acceptable name for a drink. See literally all smaller Cola brands which include the word "Cola" in their name.

Towards the bottom of the JEP, they mention that the ultimate goal is 32 bit object headers, which would necessitate object monitors be tracked on-demand in a side table. That's what the parent was getting at.

The improvement in throughput is tantalising. I'd love to see a comparison to the G1GC throughput. I wonder if it's getting close enough that ZGC might some day become a candidate to replace G1 as the default collector?

A bigger problem with blended wing designs is actually for the people on the peripheral. When the plane banks, passengers further from the axis of rotation will feel a more significant change in their altitude. You literally feel like you're "falling", as the plane banks to your side.

This also applies to existing aircraft, but the amount you drop/rise is limited by the your distance from the axis of rotation, which is normally not very far. In blended wing designs, the distance could be considerably greater, making this sensation much more intense.

The workaround for this would be to simply use shallower bank angles, but I suspect that would require some pretty major changes to navigation rules, as it would drastically increase the turn radius.

Scala 3.0 5 years ago

No. It's a Singleton type, which means that instead of just being a String, it has to be exactly the String "Scala".

i.e.

val x: "scala" = "scala" // would compile

val y: "scala" = "java" // would produce a compile error

Union types are an orthogonal concept, and work as you'd expect:

val z: String | Int = "foo"

As other posters have mentioned, offshore is significantly more economical for a number of reasons (stronger, more consistent wind; large tracts of available area for large-scale farms; the capability to build turbines much taller where they can access stronger winds) - so instead I'll mention another problem facing offshore turbines other than corrosion: the air.

It turns out that offshore, the air contains a lot of minerals and water droplets that make it much more abrasive than the air over land. This is a particular problem for turbine blades, as their leading edge is moving through the air at a significant speed: enough to gradually ablate away the leading edge material! Consequently, offshore turbine blades need to be replaced more often than onshore turbine blades. This is one of the reasons that larger turbines are more economical: fewer larger turbines mean fewer, larger blades that need to be periodically replaced.