You do realize that other countries have tariffs as well? And yes, some of the are retaliatory but most of them were in place long before Trump was in office.

https://www.customs.go.jp/engl...
https://www.customs.go.jp/engl... (from 2020)
https://ec.europa.eu/taxation_...

derp. Fine, fine, I'll own that mistake.

At least in Japan. The "deals" are "you save 40% on this item we marked up 39.999999%", deliveries are often delayed by days with no notification or reason and especially lately is more "you'll get it when you get it.". It's gotten to where if I know I need something, I just go to the store and buy it.

A weird side effect of this is that family names are dying off in Japan. While I doubt it will just be Sato as this professor is predicting, there is a really short list of common last names and other ones stand out (thankfully the different kanji for the names helps a bit).

Obligatory: How many a**holes we got on this ship anyhow? Yo! I knew it, I'm surrounded by a**holes.

I know you're joking but Jupiter is actually the fastest spin planet (in our solar system). It completes a rotation in less than 10 hours, which is crazy fast given it's size.

I work with plenty of people who are vegan for religious and cultural reasons. They will bring it up at opportune moments, we're discussing where to go out and they'll ask if there are any vegan options at the proposed restaurants.

Then there are those who "discovered" veganism and form who being vegan is the religion... they will let you know it any chance they get and will generally question your dietary choices as to boot. I believe the poster was referring to the latter.

Not sure if you're serious or trolling but testing is a separate step in the build process, you'll have a build target in the Makefile and a test target (typically broken into multiple sub steps). With something as big as the linux kernel each component/module is going to have it's own build and test steps that have dependencies on each other and all fall under the top level build and test. Let's say there are 100 components that have a dependency on hdrtest. If you want to test your component(s), their tests are going to fire off when you do your build. That's going to slow down your build and testing of your component (and piss you off... grr...).

It's not that the linux kernel doesn't test, they just organize and execute the tests in a way that makes sense for a project of that scale.

There are two groups that are facilitating this:
1. The c-suite types who are driven by profit and just see the numbers not the scope of the data. While your data is worth something, it's not a lot.
2. The engineers doing it who abstract it as a challenge/problem to be solved rather than something impacting people. And frankly don't always realize what they are doing. I've had more than a few cases were well intentioned engineers brought me a solution that was revealing far more than they intended.
3. Okay... #3... the sociopathic a-holes in both groups who genuinely don't care

Abstracting it out... the goal is to provide better data about you. Good data is worth more. Your friends and family provide more data points about you. If all my friends are buying GTA VI, chances are I'm going to as well ... so start serving me GTA adds. A family member is having a baby (I swear Amazon knew my wife was pregnant before we did)... start popping up ads about baby products.

That's where the dissonance comes it. It's viewed as a technical problem (how do we serve the best ads) instead of a social one. Probably the most effective way to stop it will be to require employees of companies that collect data to submit the complete/maximum data for themselves. That snaps it back into reality. There will still be those in group #3 trying to weasel word their way out of it but hopefully enough staff will start thinking about how they can do it better.

For what it's worth, I worked for a fintech that you'd see countless threads online discussing how we were obviously collecting and selling all the data. We actually weren't and every engineer I worked with was trying their best to protect privacy. #2 did happen from time to time but teams got better about trying to identify it before it happened and would fix it if was brought to their attention. Not everyone or every company is bad.

You hit the key point, speed, but IRBMs also fire on a depressed trajectory and not a ballistic one. They can't travel as far but they get to the target much faster. So yes, you can see them but your response time is in the 10-15 minute range and there's not a heck of alot you can do in that time frame except hope you can intercept them.

But yes, the "hypersonic" bit is more PR than actual threat. Most missiles are "hypersonic", it's the short flight time from the trajectory that's the critical factor. Supposedly why there was a tacit understanding not to place SSBM's right off each other's coast during the cold war, it would destabilize things too much.

The same reason Russia launched an Oreshnik hypersonic missile at the Ukraine. To make a statement. "Here's what we could do..." The target of the missle strike was an old rocket booster facility and the actual damage was minimal (there's speculation that the MIRV's had dummy weights for balance in lieu of actual traditional explosive warheads because that was the easiest replacement for nuclear payloads). So, an arguably worthless target hit with the wrong (and expensive) weapon for the target.

Why? "If you push us far enough, the next one won't have dummy warheads."

Why the cables? "If we decide we not insane enough to use nukes, we could still damage your economies." Yes, there is a lot of interconnectivity but if enough of it is damaged it could cause serious problems for Europe and also make responding to and recovering from a more kinetic attack more difficult.

The case does not blame logitech for the accident. It cites the Logitech controller as an example of:

1. OceanGate using technology not intended or tested for this kind of use.
2. OceanGate's design having no redundancy or fail safe. It was a bluetooth controller with no wired backup and it was the only way you could control the sub.

There are many more details in the suit that layout the case that the owner flagrantly disregarded established engineering knowledge and practice as well as advice and feedback from those knowledgeable in the field because he was smarter than everyone else and "big submarine" was trying to silence him.

They frequently deprecate, remove and (possibly worse) change functionality from release to release. There are sometimes even changes from build to build.

Just review the "Removed Features & Options" in the JDK 21 Release Notes. https://www.oracle.com/java/te....

The release notes don't always capture everything. We had a production issue a few months ago because of a change that wasn't clearly (*) documented, had to dig into the JDK code to figure out what was going on. (*) The change was documented in the commit history but didn't make the release notes.

So... yeah... they do change.

2023 Successful launches:
Russia 19, China 66, US 109

2022 ...
Russia 22, China 64, US 84

2021...
Russia 24, China 53, US 48

2020...
Russia 17, China 35, US 40

2019...
Russia 25, China 32, US 27

The US had more successful launches last year than Russia has had in the past 5. China is also steadily doing better and better. Your right, it wasn't the sanctions. Roscosmos was a shadow of it's former self well before those.

I worked for a large fintech company doing cashless payments. This is a naive understanding of things. One of the biggest drivers for merchants was the speed of the transaction. You see a lot of talk about wanting to be able to track cash flows, spending habits, etc (*). That's not the biggest driver (for merchants), it's the speed of the transaction and not having to physically handle cash (for efficiency and security reasons). An ideal cashless payment takes less than 5 secs total. Cash takes 10+ sec, more like 20-30 sec or even more. For merchants that do a large volume (convenience, grocery, public transit, etc) having everyone use cash is untenable, they would have to double or triple the number of PoS (Point of Sale) machines.

Which brings up the second, and real issue, any chain store relies heavily on their PoS system which went down and is where the real issue lies. It does the pricing, the book keeping and the inventory (and usually forecasting). Nothing price tags anymore, so that 30 sec to pay with cash just became 1-2+ minutes while the clerk figures out the prices, tallies them up, figures out the tax (which in some places is variable depending on what you're buying). Manually booking flights for a major airline? You can just forget about it.

You think want a cash based society, but you really, really don't. It's going to cost you, personally, a significant amount of time and it also going to drive up the prices you pay. You want the system to be as redundant and fail safe as possible. Cashless apps/cards should be able to work independently for a time, PoS systems should be able to work even if the back office goes down, etc.

There is nothing special about cash. We have it because we reached a point where barter was inefficient. No one wants to be lugging 5 pounds of flour and vegetables around hoping the merchant will accept them. We've reach a point where cash is no longer an efficient way of supporting 8 billion (and growing) people.

(*) Merchants do want to track cash flows and spending habits, especially larger merchants... but they generally keep this data for themselves. Payments systems are generally not getting as much of this data as many people think. It was a struggle just to get data that was required for regulatory compliance (can't apply rebates/etc to alcohol & tobacco).

The distribution of data centers in Japan is really unbalanced. ~65% in Tokyo metro, ~25% in Osaka and then a handful of small ones scattered along the islands. It's a problem for DR planning because Tokyo and Osaka are close enough (~400km) it's conceivable (but unlikely) they could both be taken off line. Making matters worse, providers often don't have feature/service parity between Tokyo and Osaka. A number of AWS services aren't available in Osaka for example (but they have been improving that).

With the growing push for data residency, it's a problem. The Japanese government should really consider "You want a DC in Tokyo, you build an equivalent one in Sapporo first." No incentives, tax breaks, etc. Just build it. Right now there is just one. The population of northern japan is pretty low but it's cooler, the land is much cheaper and the Shinkansen runs all the way up to Hokkaido so right of way for a lot of fiber is not a problem.