It doesn't need to be wrong - democratising violence mean people with boats are more likely to have weapons and ability to attack you. Or the ability to disrupt trade, for that matter.
Yes, where desktops differ is not so much the chips but rather the cooling capability. You have the space to have proper air flow and water cooling etc. So that do give quite a bit of performance.
No. Prices will crash when supply side expands to meet the increased demand. Because demand won't go down to pre-bubble times any time soon. Unfortunately the supply side has been very slow in increasing production, partly because most steps of the production chain are all maxed out.
On a long enough scale you are right that prices will likely normalize to a better level, but before 2030? That would mean the factories are built quickly once they begin.
Isn't Apple pushing features or decisions for how things work down your throat regardless of if you want them part of the classic Apple value proposition? If you don't like that, why are you even using Apple in the first place? This is about how much you want the hardware maker to decide things for you, and Apple has always been maximalist with regards to that.
Europe (by which I assume you mean EU or possibly Euro area) has a fairly balanced balance of trade overall.
And a teeny-tiny country like Switzerland can't be usefully compared to something as big as China - the rest of the world can easily consume whatever the Swiss produce, but there are limits to how much Chinese can produce until consumption will have to shift to domestic consumption because the world doesn't have infinite ability to pay for its demand.
That said don't expect any big change anytime soon - there are very strong political incentives to keep the status quo with China focusing a bit too much on exports.
Because unfortunately, the runtimes belonging to all or at least most of those languages perform a lot better with jemalloc than with the system default.
That approach fall down flat on nontrivial traffic amounts. Also it requires an actual hindrance in the middle to enforce compliance, and then bigger vehicles won't be able to turn left.
Are you not thinking about the wrong tank game? World of tanks has ancient tanks, not modern (game tank span basically end with the main battle tank making the game tank role division being made irrelevant).
Most of the dimensions exist in the threaded world as well, only the dimensions wasn't as explored at that point so the choices are usually not what would have been chosen today.
Very much so and it can be argued that the difference between threads and ssync is just another dimension to compare on. For example, essentially everything that is involved in Structured Concurrency is as relevant to parallel scenarios as well.
Yes, but when done in industrial (or store) setting they use processes that go faster than what you use at home. Those processes needs the extra protein.
As a bonus they also measure only the averages and stddev, not the percentiles or worst case. Which are the most important for any task in the vicinity of RT.
Comparing RTOS latency with only averages and stddev may be the worst benchmark I've seen in a long time. It is the worst case that is interesting, and possible also the worst latency shown for each added 9 in the 99, 99.9, 99.99 etc progression that is relevant in such a comparison. Averages can lie by an arbitrary amount.
Northern Sweden don't have the same prices as central Europe or even close to that. The underlying reason is that the transfer capability doesn't handle equalizing it. However, southern Sweden is a lot closer - Sweden is divided into 4 different price regions with insufficient transfer capability between them.
> If you think you already know OOP, this article will change the way you think about programming
No, it won't. I'm especially sad that this, like so many OOP guides before it, did not go into how it interacts with data structures and bigger picture stuff. It had the perfect chance to do that as it could have made a Catalog class and then had a discussion about what belongs to that and what to the books. Instead it started to abstract on author, in the stupidest way possible (no, no one will ever look up a book using the author birth date).
This is not a desirable solution on musl based systems. Whatever you do in that situation ends up horrible, so it is about finding the least bad solution. Which this seems like a workable variant of.
Modularizing (and versioning each part independently) libc would go a long way. There is also a need to separate the stuff needed for system integration with what is necessary for users of the C language to actually do stuff.