joha4270

Your feelings are obviously your own, but a Starlink terminal isn't that big and can transfer quite a lot of tokens.

Every single satellite has sufficient cooling for its power production, otherwise they would be frying. Waste heat from a GPU is not materially different from waste heat from an amplifier. That's not cooling entire racks, but I don't think anybody talks about putting entire racks in space anymore.

I'm very much pro nuclear, but a solar cell in a sun synchronous orbit is pretty great too and eliminates most battery requirements

I very much doubt the economics of this makes sense, but I don't think a lot of your criticism is valid.

The satellite moves, so every orbit it captures a globe spanning strip that is 50 miles wide (here uncritically accepting the 50 miles figure).

And the carrier isn't going to be in the middle of the pacific, its going to want to launch strikes, so its going to be within (say 500 miles) of Chinese military targets, which does narrow down the size of the haystack somewhat.

But yes, this is a significant challenge. On the modern battlefield it is usually significantly harder to find something than to kill something after you have found it.

So, is there anything about GPU's in here right now?

I didn't actually finish Act 2, but it seems to end in a conventional processor with the GPU first coming after another two acts currently under construction.

What is so unbelievable about that?

Sure, its going to take decades to actually make the transition and the UH-60 will remain in service for decades more after that in less demanding roles. I expect by the time this finishes, the MV-75 will be considered another workhorse, if maybe slightly fuzzier and the UH will be an antiquated platform.

But ultimately they both solve the same problem, moving stuff from A to B in rough terrain fast. But with the ever increasing amount of reconnaissance assets, A needs to be further behind the frontline and so range and speed needs to increase beyond what you can manage with a pure helicopter.

The L2 already keeps track of what lines are somewhere in L1's for managing coherency.

Divide the cache into "meta-caches" indexed by the virtual bits and treat them as separate from the L2's point of view. Duplicate the data and if somebody writes back invalidate all the other copies. The hardware already exists for doing this on any multicore system. Sure, you will end up duplicating data sometimes and it will actually be slower if you're actually writing to aliased locations. But is this happening often enough to be a problem compared to generally having a bigger cache?

It sounds to me like an engineering tradeoff that might or might not make sense, not a hard limit which at least was what I think was being asserted. But as I also said, L1 sizes hasn't increased in a while and smart people are working on it, so there is probably something I don't know.

Can you not take some of those virtual bits and get more buckets that way? I am sure it will make things more complicated if nothing else by them possibly being mapped to the same physical page, but it doesn't sound like an impossible barrier. Maybe something terrible where a cache line keeps bouncing between different buckets in the rare case that does happen, but as long as you can keep the common case as fast...

Otoh L1 sizes hasn't increased since my first processor, those CPU designers probably know more than I do.

I'm sorry, I'm clearly missing something but why would page size impact L1 cache size?

Alas, no matter how the bits that makes up my bank balance looks, in practice its still a single point of failure where I might simply lose access to my money if the right service is down. Cash has much better uptime stats, even if it can be inconvenient to carry around.

The guts of a LLM isn't something I'm well versed in, but

> to get the first N tokens sorted, only when the big model and small model diverge do you infer on the big model

suggests there is something I'm unaware of. If you compare the small and big model, don't you have to wait for the big model anyway and then what's the point? I assume I'm missing some detail here, but what?

More or less, yes. Of course, defects are not evenly distributed, so you get a lot of chips with different grades of brokenness. Normally the more broken chips gets sold off as lower tier products. A six core CPU is probably an eight core with two broken cores.

Though in this case, it seems [1] that Cerebras just has so many small cores they can expect a fairly consistent level of broken cores and route around them

[1]: https://www.cerebras.ai/blog/100x-defect-tolerance-how-cereb...

Whatever our human laws and morality says about right and wrong and fault, the laws of physics usually judges the car a winner when it hits somebody.

Placing yourself somewhere where pedestrians are not expected (non-residental road) mostly hidden from oncoming traffic for an extended period is putting yourself in undue risk.

All of Mr. Devereaux's work is wonderful including the series you linked, but I think that one its overly focused on the household. I think his two part series on "Lonely Cities"[1][2] is a lot better at giving you a feeling for a city. It is both less in depth and in that one he spends half his time complaining about how Hollywood gets it wrong, so of course YMMV.

[1]:https://acoup.blog/2019/07/12/collections-the-lonely-city-pa... [2]:https://acoup.blog/2019/07/19/the-lonely-city-part-ii-real-c...

While this PDF might be new, Akin's Laws of Spacecraft Design dates back to 2003.

https://web.archive.org/web/20031101212246/https://spacecraf...

At least in my case, I got curious about the strength of /u/dustbunny's denouncement of Godot+C#.

I would have have put it as a matter of preference/right tool with GDScripts tighter engine integration contrasted with C#'s stronger tooling and available ecosystem.

But with how it was phrased, it didn't sound like expressing a preference for GDScript+C++ over C# or C#++, it sounded like C# had some fatal flaw. And that of course makes me curious. Was it a slightly awkward phrasing, or does C# Godot have some serious footgun I'm unaware of?

I don't see how this article could possibly support the argument that C# is slower than GDScript

It compares several C# implementations of raycasts, never directly compares with GDScript, blames the C# performance on GDScript compatibility and has an strike-out'ed section advocating dropping of GDScript to improve C# performance!

Meanwhile, Godot's official documentation[1] actually does explicitly compare C# and GDScript, unlike the the article which just blames GDScript for C#'s numbers, claiming that C# wins in raw compute while having higher overhead calling into the engine

[1]: https://docs.godotengine.org/en/stable/about/faq.html#doc-fa...

Are there technical reasons to prefer GDScript over C#?

GDScript is undoubtedly better integrated in the engine, but I would have expected C# compare more favorably in larger projects than the game jam sized projects I have made.

I'm unsure if you're making a joke that flies over my head, but no Greenland is Danish, not Dutch.

A lot of people have made careers out of telling you that it's a failure, but while not everything about the F-35 is an unquestionable success, it has produced a "cheap" fighter jet that is more capable than all but a handful of other planes.

Definitely not a failure.

And the fact that superman can fly is evidence that people are lighter than air. Otherwise it wouldn't happen.

The costs (in money and energy) of the infrastructure to mine another solar system would pay for a lot of R&D to synthesize whatever it is here in our solar system.

Unlike the other poster, I don't think interstellar mining needs finding, I'm perfectly happy to lean back and enjoy the show. But whatever they mine would have to be very magical indeed to not be cheaper from any other process.

I have seen it claimed that's a way of monetizing free phone apps. Just bundle a proxy and get paid for that.

They're not dealing with a pressure differential. Or at least I don't think so.

I don't think the Journalist who wrote the article understood the technical details, but from digging a little at their website I think what's going on is they're moving heavy brine up and down, all of it equalized with local pressure.

Despite them describing it as pumped hydro, I think its better framed as a cousin of the "chunk of concrete suspended over a mine shaft" style gravity battery. Replace the mineshaft with water and the concrete with salt.

That link isn't really a source for residential 3-phase power.

Almost every electrical network is 3 phase distribution, the matter under debate is if you bring every phase to each house, or if a phase reaches every third house.

Anecdotally I have never seen an electrical panel without three phases, but when I went looking it was like trying to find a source for the fact the sky is blue.

So, a Systolic Array[1] spiced up with a pinch of control flow and a side of compiler cleverness? At least that's the impression I get from the servethehome article linked upthead. I wasn't able to find non-marketing better-than-sliced-bread technical details from 3 minutes of poking at your website.

[1]: https://en.wikipedia.org/wiki/Systolic_array

So, either me or the author has misunderstood something. Memory allocators are not among my specialties, so it might very well be me, but:

> Being able to pre-allocate objects of fixed sizes and then offer up available objects to callers is much less work than allocating individual objects on demand.

At least, from reading his included code snippets I got the impression that what's actually happening is that it has multiple allocators to avoid fragmentation and that everything actually related to actually allocating does actually happen on demand.

You can find more in the RISC-V privileged specification[1], section 3.7 I don't have any benchmarks and I think no such generalized benchmarks exists since its a specification and every core brings its own implementation (or none, its optional). With that said, its simple and probably effectively zero overhead, but its also much less capable than what a MMU can do. Its a "protect some firmware against the OS" or "absolute minimum hardware for some memory protection in a cheap MCU", not a competitor to full fat virtual memory.

[1]: https://docs.riscv.org/reference/isa/_attachments/riscv-priv...

Possible, just like Russel's teapot.

But there has been one very well published Ukrainian attack launched from Russian soil[1].

If Ukraine had could regularly smuggle several drone aircraft's and explosives into Russia and launch them, we would be seeing a lot of other effects. Such as attacks on weapon production sites deep into Russia[2].

But yes, a lot of those attacks are probably unsuccessful. With my qualifications as armchair general, I would be surprised if more than 10% of them was successful.

[1]: https://en.wikipedia.org/wiki/Operation_Spiderweb [2]: https://en.wikipedia.org/wiki/Yelabuga_drone_factory

The phone isn't going to connect to a tower it cannot see.

It can't just scream out into the void and hope a tower picks it up, it needs a few pieces of timing information & cell configuration beforehand.

You will find that competitive games already attempt's this, but it's impossible to eliminate entirely.

I can move and reveal what's behind a corner a lot faster than a network roundtrip, so either the server needs to give some advance warning or you're going to see enemies pop into existence suddenly.

And computing if somebody is almost visible isn't trivial either. Level geometry can have narrow openings such as holes in a wall. Or what if somebody jumps?

And that's before getting into non visual information. It's not perfect, but you could still add a significant advantage by drawing the exact location of footsteps.

So yeah, (some) games try, but network latency means the client needs some information a wallhack can use, and the alternative: being killed by an enemy that was invisible is at least as frustrating as being killed by a cheater so the visibility estimate has to be generous.

FWIW I have never encountered or even heard about a limit for self checkout here in Denmark.

Alternative explanations (pick and chose any you like)

* High demand but limited supply

* Unable to externalize costs that wild/farmed fish doesn't pay

* R/D investments that needs to be recouped

* Small production with a lack of economy of scale

Oh it could obviously be this is a terrible product where its more important to appear environmentally friendly than to actually be so. But lets see where it is in a decade, with my current limited data it looks like a step in the right direction.