branko_d

But then again, only the transaction log has to be physically on the drive to guarantee durability, and modern drives are very good at sequential writes. Writing tables/indexes can be delayed (to a "checkpoint", as it is known in most database systems).

Is this lack of quality a US thing?

Where we live (Kazakhstan), we had a Samsung fridge, AC and TV for about 7 years without any issues whatsoever. After moving to a new apartment, we bought another Samsung fridge and it has been quietly humming along for over 2 years now.

I never heard anybody complaining about Samsung.

Cetti.

Last month, I bought two pairs of sneakers: one was a full leather design made in Spain, the other was a leather/cloth combination (Italian design, I'm not sure where they are made). Both are comfortable, seem to be of very good quality and look premium. The price of these two pairs together was less then one Nike pair made of synthetic materials.

This was in Novi Sad, Serbia. I don't know what's going on around the world, but if this anecdote is of any indication, Nike is simply too expensive for the (lack of) quality they have.

What Andy (Grove) giveth, Bill (Gates) taketh away.

I feel this could be solved by crowdsourcing, assuming the support from the major phone manufacturers and possibly governments.

- After a call from an unknown number concludes, the phone could offer an option to the user to mark it as "spam" (blocking the number in the history would have the same effect).

- The spam mark would then go into the central database. If a phone number was marked as "spam" too many times, it would no longer be able to ring the phone (maybe it gets diverted into the "spam folder", like e-mails).

Or am I being too naive here? What are the obstacles for something like this actually happening?

Sure, but it can still have hyperinflation.

In OLTP, it's very difficult to guarantee correctness with triggers (very easy to have a race condition in concurrent environment). On a flip side, materialized views tend to lock more than you'd expect, especially when aggregates are involved.

The sweet spot is if you have a read-mostly database and use SNAPSHOT transaction isolation for the readers (which is SQL Server's implementation of MVCC). That way, writers may still block writers, but writers can never block readers, even when indexed views are being maintained.

Another neat trick is to "abuse" indexed views as multi-table CHECKs. The idea is to make a JOIN that would produce duplicated rows (and fail the indexed view's key) if some multi-table condition is not met.

You can have it in one place without using background sync.

Our application uses classical "foreground update" paradigm, but each API call automatically shows an error to the user and returns him/her to the same place where error originated to fix the input and/or retry. As a bonus, we also automatically show progress indicator for any HTTP request that takes more than 1s (which is rare).

This is as simple as:

    await context.api.explorer.rename(
        {
            objectKey,
            name
        }
    );

    // objectKey: ApiTypes.ObjectKey
    // name: string

The above initiates an HTTP request:

- If that request succeeds, you know that the new name has been durably committed to the database.

- If it fails because the new name is not unique, the user sees the error, and can then enter a different name before retrying. The key is that the UI context is preserved during API failure, so everything the user had entered is still on the screen.

- If it takes more than 1s, the user sees a progress indicator which he/she can click to cancel the operation. This also returns him/her to the original UI.

The magic is in the `rename` itself - it was auto-generated from our back-end API such that it wires into our error reporting and progress UI.

I think a lot of it is down to Windows, not Prism itself.

For decades, Windows made it too easy for games and even some application to install drivers. Windows games use drivers for anti-cheat (and historically for copy protection too). Neither Apple Rosetta nor Microsoft Prism can translate/emulate drivers, but since drivers have been much more prevalent on Windows, now Windows has a much biggest compatibility problem.

Itanium was arguably not superior. The assumption behind it (that the compiler can bring order to the chaos) was wrong, making it slower, more expensive, and less efficient than x86 in real-world scenarios.