> So I agree that Rust's stdilb is somewhat mistake prone; not so much because it's being opinionated and "nudg[ing] the developer towards using neat APIs", but because it's so low-level that it's not offering much "safety" in filesystem access over raw syscalls beyond ensuring that you didn't write a buffer overflow.
`openat()` and the other `*at()` syscalls are also raw syscalls, which Rust's stdlib chose not to expose. While I can understand that this may not be straight forward for a cross-platform API, I have to disagree with your statement that Rust's stdlib is mistake prone because it's so low-level. It's more mistake prone than POSIX (in some aspects) because it is missing a whole family of low-level syscalls.
This may make sense if the extended warranty is limited to defects introduced by the remote change. I.e., if they remotely break your device, they should be responsible for fixing the damage. A full warranty extension doesn't seem reasonable to me, though.
With regards to your last sentence, I think a good first step would be to require at least security and other critical updates to be provided within the full warranty period. And this would make sense even without the (limited) warranty extension, and I actually consider it more important.
Doesn't Facebook require users to verify the email address with a confirmation email? If so, the only Facebook spam you should be able to get would be such confirmation emails. Or what am I missing?
Many retail AM4 motherboards support ECC with retail Ryzen CPUs. At least on Linux it works as expected. ECC UDIMMs can be difficult to find but it shouldn't be necessary to buy a TR Pro for ECC if memory capacity, I/O lanes and the performance of AM4 Ryzen CPUs suffice.
> 1. Rust has very strong stability guarantees. If you want to you can continue coding like it's Rust 1.0 even on the latest compiler.
There have been at least two cases where Firefox build broke due to having a too recent version of Rust installed. The stability guarantees may be fairly strong but it's definitely not perfect.
You can order a USB HDMI capture dongle for around USD 10 on AliExpress, e.g., from AIXXCO. It's not perfect but it should suffice to setup or debug a headless system. TinyPilot uses such a dongle for server KVM purposes.
This is incorrect, to the best of my knowledge. 3900X and 3950X both have a 142W package power limit (PPT, 35% above TDP) at stock, with a properly working motherboard. As I understand it, not even short boosts are allowed to use more power than the PPT.
The limit can be lifted in the BIOS (or e.g. Ryzen Master) but that would no longer be stock operation. And there was a defect in the initial BIOS of ASRock X570 and maybe other motherboards, which broke PPT but that was running the CPU out of spec, not stock operation.
The top wealth tax rate is definitely higher than 0.3% in Switzerland. In Zurich it's up to 0.7%.
There is no capital gains tax for private long-term investments in Switzerland (with the exception of real estate). However, dividends are normally taxed the same as income from employment.
TRX40 with a Threadripper 3960X supports PCIe 4.0 (64 CPU lanes) and 8x ECC UDIMM. This would be a quad channel configuration (2 DIMMs per channel), not 8 channels and DDR4-3200 ECC UDIMM may be hard to find at retail. Threadripper is based on the same silicon as EPYC, though, so it may be close enough for your purpose. ASRock TRX40 Taichi, ASUS Prime TRX40-Pro or maybe ASRock Rack TRX40D8 could be a suitable motherboard.
Threadripper Pro will be even closer to EPYC with 8 memory channels, 128 PCIe 4.0 lanes and RDIMM/LRDIMM support. However, you'd have to wait until September and the Lenovo ThinkStation P620 may be the only choice at time of launch.
Do you need RDIMM/LRDIMM or would ECC UDIMM suffice? If the latter, have you considered a Ryzen 3950X or a Threadripper 3960X? There are plenty of X570/TRX40 motherboards that properly support ECC UDIMM (but there are also some that don't).
If you need RDIMM/LRDIMM the only current AMD alternative to EPYC is the recently announced Threadripper Pro. Launch partner is Lenovo with the ThinkStation P620 where you can get 12-64 cores with up to 1 TB of RAM. Expected to be available in September.
`openat()` and the other `*at()` syscalls are also raw syscalls, which Rust's stdlib chose not to expose. While I can understand that this may not be straight forward for a cross-platform API, I have to disagree with your statement that Rust's stdlib is mistake prone because it's so low-level. It's more mistake prone than POSIX (in some aspects) because it is missing a whole family of low-level syscalls.