matja

Presumably because it looks identical to a Sandisk extreme pro 512gb, with grey boxes drawn over the logo.

The attestation report is signed by a key in the PSP hardware, not accessible by any OS or software, which can then be validated with the vendor's certificate/public-key. If that can be faked, are you saying that those private keys are compromised?

> No, our interposer only works on DDR4

Not surprising - even having 2 DDR5 DIMMs on the same channel compromises signal integrity enough to need to drop the frequency by ~30-40%, so perhaps the best mitigation at the moment is to ensure the host is using the fastest DDR5 available.

So - Is the host DRAM/DIMM technology and frequency included in the remote attestation report for the VM?

Do you have a benchmark that shows the M1 Ultra CPU to memory throughput?

If you get IPv6 from your ISP you're usually not "behind NAT", even if your home router does NAT IPv4 or your ISP does CGNAT for IPv4.

Maybe the number of Windows 7 users has not changed, but those using Windows 10 and 11 are flocking to Linux. That'd be a net positive change in the Windows 7 percentage. :p

"lossless" has always referred to compression, not sampling - but it seems camera manufacturers want to change that for marketing reasons.

Similarly (without starting an audiophile thread): Recording a vinyl record and compressing to a MP3 is "perceptually lossless" but will be different to compressing to a FLAC, never mind that the sampling output will always have random noise.

Those discussions I feel are fuelled by manufacturers like Sony saying [0] things like:

  Lossless compressed RAW:
  ...
  This is a popular format that occupies less space with minimal quality loss.

"minimal" "loss"? That's not "no loss", so what exactly is it?

[0] https://www.sony.co.uk/electronics/support/articles/00257081

"accommodate" in this instance would have been accomplished by doing nothing. The Linux kernel developers actively made this change.

does removing EXPORT_SYMBOL(__kernel_fpu_end); [0] - which broke ZFS, count as removing stuff or changing the API?

AFAIK that change didn't add functionality or fix any existing issues, other than breaking ZFS - which GKH was absolutely fine with, dismissing several requests for it to be reverted, stating the "policy": [1]

> Sorry, no, we do not keep symbols exported for no in-kernel users.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [1] https://lore.kernel.org/lkml/20190111054058.GA27966@kroah.co...

CUSE on Linux can do that: https://libfuse.github.io/doxygen/cuse_8c.html

Missing a 0 at the end

How are you defining "bricked"? The SSD device can no longer be enumerated on the PCIe/SATA bus, or it doesn't respond to ATA/NVMe commands, or it doesn't respond as expected, or it does but the data is always wrong? Does the same SSD work in another machine?

edit: The author of the comment I replied to has changed their comment to remove all details of their testing.

It could be an AWACS out of Kirtland

> You can't even clearly define what an "atomic sequence of glyphs" is.

Kinda. Grapheme cluster breaks are defined in Unicode, but they have all the baggage and edge-cases you'd expect from human languages evolving over time, so they can be encoded in as a few as a thousand rules : https://github.com/unicode-org/icu/tree/main/icu4c/source/da...

The latest kernel as of today still supports the 486SX ! (https://github.com/torvalds/linux/blob/v6.17-rc1/arch/x86/Kc...)

Depends which blockchain, exactly. Some have lower total hash rate than others.

It stops +++ATH0 in a IP packet (such as in a ping request, web page, etc) hanging up the modem by requiring a delay between the escape sequence (+++) and the ATH0 command.

ATS12=255!

Did you file a bug?

ECC is a must-have if you want to minimize the risk of corruption, but that is true for any filesystem.

Sun (and now Oracle) officially recommended using ECC ever since it was intended to be an enterprise product running on 24/7 servers, where it makes sense that anything that is going to be cached in RAM for long periods is protected by ECC.

In that sense it was a "must-have", as business-critical functions require that guarantee.

Now that you can use ZFS on a number of operating systems, on many different architectures, even a Raspberry Pi, the business-critical-only use-case is not as prevalent.

ZFS doesn't intrinsically require ECC but it does trust that the memory functions correctly which you have the best chance of achieving by using ECC.

For mining, If a GPU was failing in such a way that it was giving completely wrong output for functions during mining, that'd only be visible as a lower success hash-rate which you might not even notice unless you did periodic testing of known-target hashes.

For graphics, the same defect could be severe enough to completely render the GPU useless.

Nope, it's still live

Or you could say 540Hz is the odd one out for not being a multiple of 24Hz, the standard since ~1930.

Going from the ratio of adjectives on the page, it is 2.5 times less functional than beautiful.

This is interesting because Stalwart has a built-in clustering feature and can use distributed databases as its storage layer, so you get high-availability options out of the box. I've struggled with doing similar HA on Dovecot, never quite being true HA (for the open source version of Dovecot) for a while and never found a good other open source option.

So a JSON parser that cannot store a 2 is technically compliant? :(

Lucky that 415031 is prime :)

The steps described in the article sound familiar to the process done in the early 2000's, but I'm not sure why you'd want to make it hard for yourself now.

I use certbot with "--preferred-challenges dns-01" and "--manual-auth-hook" / "--manual-cleanup-hook" to dynamically create DNS records, rather than needing to modify the webserver config (and the security/access risks that comes with). It just needs putting the cert/key in the right place and reloading the webserver/loadbalancer.

Aren't JSON parsers technically not following the standard if they don't reliably store a number that is not representable by a IEEE754 double precision float?

It's a shame JSON parsers usually default to performance rather than correctness, by using bignums for numbers.

"Don't mind me running this piece of WASM in a webworker to collect all the useful encryption keys and cookies in your RAM..."