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.

Is this a case of of Qualcomm commoditizing their complements? Does Mojo have a potential for disrupting Nvidia's current market position?

https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

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.

On a related note: Visual Studio still has dialogs that cannot be resized, even after years of people begging Microsoft to make them resizable. Shouldn't this be a trivial fix for AI?

I'll believe in AI when I get to resize my Configuration Manager!

https://developercommunity.microsoft.com/t/Resize-configurat...

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.

No.

Palantir, possibly the most overvalued company on the stock marker, has P/S 63 and P/E 144.

Nvidia has P/S 21 and P/E 33.

Sounds like HPE GreenLake.

From https://kristoff.it/blog/contributor-poker-and-ai/:

"Unfortunately the reality of LLM-based contributions has been mostly negative for us, from an increase in background noise due to worthless drive-by PRs full of hallucinations (that wouldn’t even compile, let alone pass CI), to insane 10 thousand line long first time PRs. In-between we also received plenty of PRs that looked fine on the surface, some of which explicitly claimed to not have made use of LLMs, but where follow-up discussions immediately made it clear that the author was sneakily consulting an LLM and regurgitating its mistake-filled replies to us."

This is just a footnote in the article, but is incredibly important, IMO:

”There’s a risk that codebases begin to surpass human comprehension as a result of more AI in the development process, scaling bug complexity along with (or perhaps faster than) discovery capability. Human-comprehensibility is an essential property to maintain, especially in critical software like browsers and operating systems.”

This aligns with my own experience, and I believe experience of most practitioners in the field: writing a piece of code is just a beginning of a very long journey.

We should be careful about optimizing that first step at the expense of the journey.

The wording "outside of transaction" irks me. Everything in a relational database is done within a transaction, the only question is whether it's the transaction you think it is, or some other.

I believe this is largely an API design problem. Many client APIs (especially ORMs) will start a transaction implicitly for you if you haven't explicitly specified your own, leading to problems like in the article.

Having implicit transactions is just wrong design, IMO. A better-designed API should make transactions very explicit and very visible in the code: if you want to execute a query, you must start a transaction yourself and then query on that transaction supplied as an actual parameter. Implicit transactions should be difficult-to-impossible. We - the programmers - should think about transactions just as we think about querying and manipulating data. Hiding from transactions in the name of "ergonomy" brings more harm than good.

Dave Cutler and his team are a clear counter-example. They famously shipped Windows NT with zero known bugs, which clearly brought enormous shareholder value.

The problem, of course, is that this sort of thing doesn’t bring value next quarter.

I think this is especially problematic (from Part 4 at https://isolveproblems.substack.com/p/how-microsoft-vaporize...):

"The team had reached a point where it was too risky to make any code refactoring or engineering improvements. I submitted several bug fixes and refactoring, notably using smart pointers, but they were rejected for fear of breaking something."

Once you reach this stage, the only escape is to first cover everything with tests and then meticulously fix bugs, without shipping any new features. This can take a long time, and cannot happen without the full support from the management who do not fully understand the problem nor are incentivized to understand it.

If memory serves, Windows 2000 was the last version where search worked reliably. It was a simple linear search through files which could take a while on larger folders, but was reliable and predictable since it did not rely on a background indexing service which seems to get stale or just plain wrong most of the time.

If I search for “foo”, I’d like to get all files containing “foo” please, without a shadow of a doubt that some files were skipped, including those that I have recently created. I still can’t get that as of Windows 11!

My guess would be bad hashing, resulting in too many collisions.

> often you have to inject data into new tables or columns

No tool can help you with that, simply because this kind of data migration depends on your particular business logic that the tool has no way of knowing about.

While SQL Server Data Tools has its warts, it has been immensely useful for us in making sure every little detail gets handled during migration. That doesn't usually mean that it can do the entire migration itself - we do the manual adjustments to the base tables that SSDT cannot do on its own, and then let it handle the rest, which in our case is mostly about indexes, views, functions and stored procedures.

After all that, SSDT can compare the resulting database with the "desired" database, and reliably flag any differences, preventing schema drift.

> Boolean is rarely enough for real production workloads. You need a 'processing' ... 'retrying'... 'failed' ...

If you have more than 2 states, then just use integer instead or boolean.

> Saving a few bytes on the index isn't worth losing that observability.

Not sure why having a few well-known string values is more "observable" than having a few well-known integer values.

Also, it might be worth having better write performance. When PostgreSQL updates a row, it actually creates a new physical row version (for MVCC), so the less it has to copy the better.

Why use string as status, instead of a boolean? That just wastes space for no discernable benefit, especially since the status is indexed. Also, consider turning event_type into an integer if possible, for similar reasons.

Furthermore, why have two indexes with the same leading field (status)?

That's true for seeks into the clustered (primary) index because that index includes all fields, so you don't need to "jump" to the heap to get them.

However, seeking into a secondary index, and then reading a column not included in that index incurs an additional index seek (into the clustered index), which may be somewhat slower than what would happen in a heap-based table.

So there are pros and cons, as usual...

For inserts, you cannot escape writing into the base table and all indexes. However, my understanding is that for updates PostgreSQL has a write amplification problem due to the fact that each time a row is updated this creates a new row (to implement MVCC), and a new physical location in the heap, so all indexes need to be updated to point to the new location, even those not containing the updated columns.

OTOH, with a heap-less (aka. clustered, aka. index organized) table, you would only have to update the indexes containing the columns that are actually being updated. You don't need to touch any other index. Furthermore, only if you are updating a key column would you physically "move" the entry into a different part of the B-tree. If you update an included column (PK columns are automatically "included" in all secondary indexes, even if not explicitly mentioned in the index definition), you can do that in-place, without moving the entry.

Here is how this works in SQL Server - consider the following example:

    CREATE TABLE T (

        ID int,
        NAME nvarchar(255) NOT NULL,
        AMOUNT int NOT NULL,

        CONSTRAINT T_PK PRIMARY KEY (ID)

    );

    GO

    CREATE INDEX T_I1 ON T (NAME);

    GO

    CREATE INDEX T_I2 ON T (AMOUNT);

Now, doing this...

    UPDATE T SET AMOUNT = 42 WHERE ID = 100;

...will only write to T_PK and T_I2, but not T_I1. Furthermore T_PK's entry will not need to be moved to a different place in the B-tree. SQL Server uses row versioning similar to PostgreSQL, so it's conceivable that PostgreSQL could behave similarly to SQL Server if it supported clustered (index-organized) tables.

Yes, and the newest Panther Lake too!

https://techtime.news/2025/10/10/intel-25/