If you want some sparetime, go find some colleaques you can make up Teams calls with.
Just call those "Jourfixe Devops Learning path" or the like. Nobody will ever question you beeing "red" or even presenting. This might not fill your timesheet, but helps a lot aginst unexpected RSVPs.
I constantly get between 154 and 156 ns/url when running on an M2 Air 2022 while using asahi linux instead of MacOs.
22 Celsius according to smartmontools :)
So seems a good part of the speed-up comes from using the Linux kernel, which tbh. doesn't really surprise me.
It's hard to match the engineering amount and quality getting poured into it (well at least the core stuff, some niche driver will be a mess like everywhere).
The remainder then comes from modern x86_64/amd64 CPU combined with DDR5 beating the M2, well at least in this micro benchmark.
Safari does not currently support WebGL2, which is the blocker. They support it behind and flag, and it seems to work there, but until they enable it by default, Butterchurn will not work on Safari.
You can reclaim every amount booked(fetched) via IBAN payment for 13 month, except when you gave an valid mandate, then it's 6weeks where you can invert the payment.
If you submit(wire transfer) money via bank payment though, it is up to your bank, the bank of the reciever and the reciever to ack a refund.
Failed IBAN payments costs the reciever side like 10€ if they triggered it.
Also i have never seen a check beeing used except for people who won a lottery or something.
The affected certificate as confirmed by Comodo: https://crt.sh/?q=278968925. Note that it wasn't logged until about 2 hours ago. CT logging will become mandatory at some point, but not yet.
Once a certificate is submitted to the logs (which as mentioned elsewhere, Google wants to make mandatory, but today they only enforce for EV and only by treating as non-EV if it isn't logged) the log won't necessarily immediately tell monitors about that certificate. Accepting new items for the logs can be (and usually would be) parallelised, but the log structure is a single Merkle Tree and so cannot be calculated entirely in parallel, usually updating this structure is a serial operation that happens asynchronously, with the result available some time later.
A policy value called the Maximum Merge Delay decides how long a log has to get this done and produce a new head value for the log, Google has currently chosen 24 hours for logs to be accepted in Chrome. Once a log presents somebody with an SCT proving it logged a particular certificate, it has 24 hours to make a Merkle Tree with that cert in it available to the monitors. That sounds like a long time, but it's not "business hours" or "best effort" it's an absolute limit. Data Centre flooded by a tsunami? Too bad. OS upgrade is incompatible with your CPU model? Don't care. Some lunatic threw a billion dollars in bills out of an aeroplane and your employees are out collecting as much as they can carry? Not our problem. Usually you can expect the actual turnaround to be much less than 24 hours, if it's ever greater the log should be distrusted and shut down.
There have already been logs that had "problems" and went away for this reason. Because the logs are only useful if they obey the MMD Google is being pretty strict about this.
However, just because something is in one or more logs doesn't mean any monitor, including famous ones like crt.sh, or Google's own transparency site, has actually obtained and processed the log item right away. There can definitely be slowdowns in this part, but they're only a matter of throwing enough resources at the problem.
Do you have statistics about how fast different CAs are/how it is distributed? Are some CAs always "lagging", or do many of them have occasional late outliers, ...?
Note that this doesn't tell you whether a CA logs all/ most or none of the certificates they issue. In my experience it would be unusual for a CA to deliberately _wait_ before logging certificates, either they're logged more or less immediately or they don't intend to log them at all. To issue certificates with an SCT baked inside them (which is convenient for customers) you have to log a "pre-certificate" with the exact same details first anyway to get the SCT.
BUT if there's a problem the Mozilla trust store policy (and perhaps others, but only Mozilla's happens in public where we can see it) says the CA must show the trust store all the affected certificates. By far the easiest way to do that in 2017 is shove them all into a CT log and then spew a list of links to crt.sh or another monitor, rather than uploading some Word document full of X.509 PEM files or whatever. So even CAs that we know don't normally log everything will put all the problematic stuff into logs during disclosure, or else someone reading m.d.s.policy will do it for them.
Some CAs have a deliberate customer policy of letting you choose NOT to log, sometimes with a warning saying if you don't log this stuff then Google might distrust it. Symantec was really into redaction, which is logging but with the "sensitive" bits of the certificate removed. But Google never really bought that idea, and Symantec are exiting the CA business.
That would be a great thing to analyse, but I don't currently have stats.
Note, Google crawler will also submit anything it sees, so if your CA lags by a week but your new site is crawled in the next hour, you'll end up logged.
https://media.ccc.de/v/39c3-asahi-linux-porting-linux-to-app... recording