No, I saw that bug in the issue log, but I never hit that personally.
If you're running into it, I'd test again with the latest release (0.5.1) and see if it's still present. If so, I suspect it would get more traction from the dev team if the report was complete, as it's currently missing repro steps and the litestream.yml is not compatible with 0.5.0 (it still has "replicas" plural).
A recent YouTube video by GamersNexus speculated the cause of instability might be a manufacturing issue. The employee's response follows.
Questions about manufacturing or Via Oxidation as reported by Tech outlets:
Short answer: We can confirm there was a via Oxidation manufacturing issue (addressed back in 2023) but it is not related to the instability issue.
Long answer: We can confirm that the via Oxidation manufacturing issue affected some early Intel Core 13th Gen desktop processors. However, the issue was root caused and addressed with manufacturing improvements and screens in 2023. We have also looked at it from the instability reports on Intel Core 13th Gen desktop processors and the analysis to-date has determined that only a small number of instability reports can be connected to the manufacturing issue.
For the Instability issue, we are delivering a microcode patch which addresses exposure to elevated voltages which is a key element of the Instability issue. We are currently validating the microcode patch to ensure the instability issues for 13th/14th Gen are addressed
So they were producing defective CPUs, identified & addressed the issue but didn’t issue a recall, defect notice or public statement relating to the issue?
What makes you think there was a "defective batch"? What makes you think all the CPUs affected by that production issue will fail from it?
That description sounds to me like it affected the entire production line for months. It's only worth a recall if a sufficient percent of those CPUs will fail. (I don't want to argue about what particular percent that should be.)
My CPU was unstable for months, I spent tens of hours and hundreds on equipment to troubleshoot (I _never_ thought my CPU would be the cause). Had I of known this, I would have scrutinised the cpu a lot faster than what I did.
Intel not making a public statement about potentially defective products could have been done with good PR spin ‘we detected an issue, believe the defect rate will be < 0.25%, here’s a test suite you can run, call if you think you’re one of the .25!’ But they didn’t.
I’m never buying an intel product again. Fuck intel.
This comment chain is talking about the oxidation in particular, and specifically the situation where the oxidation is not the cause of the instability in the title. That's the only way they "identified & addressed the issue but didn’t issue a recall".
Do you have a reason to think the oxidation is the cause of your problems?
Did you not read my first post trying to clarify the two separate issues?
Oxidisation in the context of CPU fabrication sounds pretty bad, I find it hard to believe it would have no impact on CPU stability regardless of what Intels PR team to say while minimizing any actual impacts caused.
Edit: it sounds like intel have been aware of stability issues for some time and have said nothing, I’m not sure we have any reason to trust anything they say moving forward, relating to oxidisation or any other claims they make.
Well they didn't notice it for a good while, so it's really hard to say how much impact it had.
And at a certain point if you barely believe anything they say, then you shouldn't be using their statement to get mad about. The complaint you're making depends on very particular parts of their statement being true but other very particular parts being not true. I don't think we have the evidence to do that right now.
> Well they didn't notice it for a good while, so it's really hard to say how much impact it had.
That negates any arguments you had related to failure rates.
> The complaint you're making depends on very particular parts of their statement being true but other very particular parts being not true
Er, I’m not even sure how to respond to this. GamersNexus has indicated they know about the oxidisation issue, intel *subsequently* confirm it was known internally but no public statement was made until now. I’m not unreasonably cherry picking parts of their statement and then drawing unreasonable conclusions. Intel have very clearly demonstrated they would have preferred to not disclose an issue in fabrication processes which very probably caused defective CPUs, they have demonstrated untrustworthy behaviour related to this entire thing (L1techs and GN are breaking the defective cpu story following leaks from major intel clients who have indicated that intel is basically refusing to cooperate).
Intel has known about these issues for some time and said nothing. They have cost organisations and individuals time and money. Nothing they say now can be trusted unless it involves them admitting fault.
> That negates any arguments you had related to failure rates.
I mean it's hard for us to say, without sufficient data. But Intel might have that much data.
Also what argument about failure rates? The one where I said "if" about failure rates?
> Er, I’m not even sure how to respond to this. GamersNexus has indicated they know about the oxidisation issue, intel subsequently confirm it was known internally but no public statement was made until now.
GamersNexus thinks the oxidation might be the cause of the instability everyone is having. Intel claims otherwise.
Intel has no reason to lie about this detail. It doesn't matter if the issue is oxidation versus something else.
Also the issue Intel admits to can't be the problem with 14th gen, because it only happened to 13th gen chips.
> Intel has known about these issues for some time and said nothing. Nothing they say now can be trusted unless it involves them admitting fault.
If you don't trust what Intel said today at all, then you can't make good claims about what they knew or didn't know. You're picking and choosing what you believe to an extent I can't support.
One issue I've run into while using strict tables is that since sqlite does not (yet?) have a dedicated type for timestamps, a driver like github.com/mattn/go-sqlite3 use the typename in the schema to determine when a column can be converted to a native time datatype. But STRICT tables only allow 6 specific typenames: INT, INTEGER, REAL, TEXT, BLOB, ANY
> One issue I've run into while using strict tables is that since sqlite does not (yet?) have a dedicated type for timestamps, a driver like github.com/mattn/go-sqlite3 use the typename in the schema to determine when a column can be converted to a native time datatype. But STRICT tables only allow 6 specific typenames: INT, INTEGER, REAL, TEXT, BLOB, ANY
I wish they’d implement CREATE DOMAIN, like Postgres has. Using it you can define a named custom type from a base type, optionally with associated CHECK constraints. A minimal implementation would skip the constraints (and DEFAULT and collation) and just let you do CREATE DOMAIN timestamp AS INT (or TEXT if you’d rather do it that way), and thereafter STRICT tables could have timestamp as column type
