at time of writing, this says NO, but according to the text, "uBlock Origin could still work on YouTube. Not all YT updates are targeted against uBO's solutions." so shouldn't it say MAYBE?
you could also say that "supports linux" allowed them to discover and remedy this vulnerability which would likely have still existed without linux support, thus making the device stronger for both windows and linux users.
the parent comment explains why dumping a blob is bad, particularly for drivers. it allows vendors to depend on all sorts of undocumented and unreliable behavior and prevents upstream improvements.
PSI is exported by the kernel to track context switches: switch to idle process = io wait, switch to kswapd = mem wait, switch to other runnable process = cpu wait. these are already visible to the kernel, it just needs to increment some counters and expose those to userspace. you can get the perf counters with something like `perf stat -ae cache-misses sleep 60`, it doesn't need to be in /proc.
additionally, context switches are the same on everything that can run Linux, whereas PMU counters are highly CPU-specific (potentially even different in each CPU stepping), so given the current state of affairs, a generic interface would be very limited.
there are obviously lots of kids that had a very bad homeschooling, and also lots of kids that had very bad public schooling. many kids are bullied so badly at school that they commit suicide, and many more develop antisocial habits there. the question is whether those issues are better or worse with homeschooling, and a single anecdote doesn't help us with that.
> or store the data out-of-line [...] which requires up to 2x writes
and because writes to separate sectors aren't atomic, you probably want to add journaling or some kind of CoW for crash safety, and oh look now you're actually just writing a filesystem and it's not simpler anymore.
No, you're writing something that happens to resemble a small subset of the functionality of a filesystem.
Most importantly, you're not duplicating the effort for every filesystem that you want to support encryption for, and the code can largely remain fixed once mature.
kernel developers are free to factor in common functionality, calling into it library style, without making it into an externally visible layer. IIRC fs encryption and case insensitivity are often done that way, and I think I'd count the page cache and bios as larger library-style components as well (as opposed to the VFS layer which is more in a framework style).
> if someone can legally compel Hetzner and/or Linode and/or LetsEncrypt to do or not do something then the same entity can compel the certificate transparency site to ignore something
the major certificate transparency logs are operated by several independent global companies, Apple and Google for LE. it's unlikely that they will agree to forge their global CT logs for a single government. more importantly, SCTs allow cryptographic proof of anyone lying, making such an action very dangerous for their continued participation in the WebPKI ecosystem.
This sounds like the methodology for blockchain and multiple ledgers. Ultimately however crt.sh is hosted somewhere and while there may be multiple controllers that have access to logs on the front-end, someone hosting that site could be compelled or blackmailed into tinkering with the levers behind the scene to exclude activity on a domain. I'm not suggesting that is what is happening, just that it could and Apple, Google and others would have plausible deniability. On the other hand having active probes distributed around the world on multiple ISP's looking for fingerprint changes would be much harder to hide though more expensive to operate along similar lines to archive.is or using distributed Nagios NPRE agents or using ThousandEyes probes.
The crt.sh code is all open on GitHub, so can be hosted yourself. Last I checked a few months ago, the main ‘certificates’ table and indexes etc was close to 20TB, and there’s more than just that. It’s big, but has everything. A slimmed down database of just some lightweight info on the certs and issuer (notBefore, not after, SANs, serials etc) runs maybe a TB in bigquery.
A log monitor? Or specifically the crt.sh codebase?
Yes, the logs are public and I ran equivalent monitoring for a previous employer before the pandemic. You will need to consume records at the rate they're created to keep up, Let's Encrypt have stats you can look at, if you can cope with twice their typical daily throughput you'll be fine on average, but peaks will swamp you temporarily so design for that.
You can choose whether to store everything, or just stuff you consider interesting, and you can choose whether to care forever or only until expiry (so 398 days)
If you want everything (full certificates), indefinitely, that's a lot of data. Um, several terabytes per year maybe?
this is a very very silly take. Apple and Google have armies of lawyers who spend all day telling cops with subpoenas from all around the world to fuck off.
according to the article, the added hop visible in traceroute to Linode machine is after two 10/8 hops, so it's likely an internal machine. more importantly, the affected VM has a strange gateway MAC address, which can only be controlled by the local network administrator, not an intermediate carrier.
phoronix benchmarks are bad on average, but this one is particularly garbage.
it doesn't make sense for zstd to be performing orders of magnitude slower on some OSs, because the bottleneck (at least at higher compression levels) is pure userspace code. as I recall, someone on the freebsd mailing list found that the actual speed is almost identical, but zstd used a totally wrong timing API on freebsd. phoronix also uses totally different zstd versions and only sets the compression level the same, ignoring that the achieved compression ratio may vary greatly between versions for some special data.
considering these basic errors, the whole benchmark should be considered garbage in garbage out and not useful for any real purpose.
