kevindong

Sorry if I was ambiguous before. When I said "log format", I was referring to the message part of the log line. Standardized timestamp, line in the source code that emitted the log line, and level are the bare minimum for all logging.

Keeping the message part of the log line's format in sync with some external store is deviously difficult particularly when the interesting parts of the log are the dynamic portions that can take on multiple shapes.

You can't realistically expect every log format to get a custom schema declared for it prior to deployment.

Sure the relative difference between the fastest and slowest approach is 5x. But the absolute difference is still just 125.23 ns. For some perspective, 1 millisecond / 125.23 ns = ~7,985.

There certainly are cases where that slowdown matters. But for the vast, vast, VAST majority of applications, it is completely irrelevant.

As you correctly point out, everything you can do with metrics can be achieved via logs if you have enough compute and I/O. But that ignores the reality of what happens when you do indeed have too many logs to use something fancier like column store/inverted indices as you point out? I agree that in the vast majority of cases, it's likely fine to just take the approach of using logs and counting. But plenty of of developers (particularly here on HN) are in that overall small slice of the overall community that does have a genuine need for greater performance than is afforded by some form of optimized logging.

Likewise, traces are indeed (as you point out) functionally just correlating logs from multiple services which is akin to syntactic sugar. But again, that's precisely its value _at scale_: easing the burden of use. I've personally seen traces that reach across tens of services in an interconnected and cyclical graph of dependencies that would be hellish to query the logs for by hand.

Graphing metrics and doing transformations/comparisons is (much) faster. Yes, metrics do have to be defined first but in my experience that's a non-issue since the things you want to monitor are usually immediately obvious during development (e.g. request-response times, errors returned, new customers acquired, pages loaded, etc.).

With that being said, it's not a mutually exclusive situation. You can have both. However, some logs used for plotting metrics have near-zero debugging value (e.g. a log line that just includes the timestamp and the message "event x occurred"). Those kinds of logs should be fully converted over to metrics.

Some other logs however are genuinely useful (e.g. an exception occurred, the error count should be incremented, and this is the stack trace).

I think the author is asserting that trading away the hackability is worth the faster compile times because faster compiles lets you iterate faster and therefore increases hackability (i.e. put in minutes of effort once and get minutes of benefits per compile in the future).

> The benefits will include comprehensive outpatient and inpatient medical care, long-term care, primary and preventive care, prescription drugs, laboratory tests, rehabilitative, dental, vision, hearing, etc. all benefits required by current state insurance law or provided by the state public employee package, Family Health Plus, Child Health Plus, Medicare, or Medicaid, and others added by the plan.

I'm struggling to understand what is not covered beyond that.

From the summary of the bill:

> Private insurance that duplicates benefits offered under New York Health could not be offered to New York residents.

---

My interpretation of that is that private insurance (which includes employer-based insurance) would be banned.

If they're no longer manufacturing older devices, they're probably not manufacturing parts for them anymore either.

The only new iPhone that Apple is selling that's not on the repair parts website is the iPhone 11 which is a bit peculiar.

Keep in mind that a substantial portion of users now use ad blockers such that a lot of URLs used for analytics like this are blocked.

Consequently, you can't actually expect to capture 100% of these analytics events nor even expect the percentage captured to stay the same over time since the filter lists are very regularly updated and users enable/disable different ad blockers over time.

More broadly speaking, once you have sent a webpage to the user, you should not expect anything from the user's browser. They may or may not allow whatever arbitrary JS you have on the page. They may even intentionally give you bad data (e.g. hijack the payload to give you intentionally malformed data).

edit: even more broadly speaking, there's additional reasons why you can't expect to receive these kinds of callbacks: consider what happens if a user loses connectivity between loading the page and them navigating away (e.g. their phone loses service because they went into an elevator before navigating away)

One interesting thing is that First Class Parcels have noticeably faster delivery times than First Class Letters (as long as you both start and end in the continental US).

I'd upgrade personally since the further behind you get, the more painful it becomes to upgrade down the road.

To continue that quote from above:

> A rationale for this is presented in Appendix A Strength of Memorized Secrets.

The relevant part of which reads:

> The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted...

>

> Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.