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've personally experienced three kinds of coding interviews.

1. Trivial questions that can be done very quickly; e.g. does this list of integers contain any duplicate integers?

2. Non-trivial questions that require a large amount of time to solve if you haven't memorized the solution; e.g. the skyline problem https://leetcode.com/problems/the-skyline-problem/

3. Practical questions; e.g. a question that more-or-less represents something you might actually encounter in your day to day job, for instance querying multiple APIs and joining the data together into a particular expected format

---

1 isn't bad due to its level of ease. 2 is awful since you mostly just need to grind many hours of Leetcode to be able to consistently solve those kinds of problems. 3 is enjoyable since the problems given might actually teach you something you'll use day-to-day.

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.

They have been moving to services, but all of their other services are distinctly mass consumer oriented; e.g. TV+, Music streaming, Fitness+ videos, Arcade, News+, iCloud photo backup, Card

https://www.apple.com/apple-one/

https://www.apple.com/services/

I'm surprised Apple supports custom email domains to any extent. Apple is a consumer electronics company. Hosted email on custom domains is very distinctly not a typical consumer behavior.

Could you not argue the same thing for almost any code used by almost any piece of software closer to the metal?

e.g. someone manages to slip malicious code into Chrome/Chromium which eventually makes its way out to every Electron app/most browsers, or something gets injected into Windows/macOS/Linux, etc.

Can you expand on what you mean by "rent seeking" in this context?

Regarding subscription fees, there's nothing wrong with paying for software.

In NYC at least, electric supply charges are distinct line items from electric delivery charges. Consumers do have the option of choosing who supplies their electricity (e.g. namely if you want to buy your electricity from a green source). But the local monopoly is always entitled to charge you for the service of actually delivering said electricity to you.

Both charges fluctuate from month to month. When I still lived in Indiana, the local monopoly lumped together supply and delivery charges into a single line item which, interestingly enough, was significantly lower than what I pay for just delivery now.

The following prices are for roughly April.

NYC (ConEd) delivery charge is ~$18/month + ~$0.123/kWh. Supply is usually something like ~$0.115/kWh.

Indiana (Duke Energy) total cost (including both supply and delivery) was ~$9/month + ~$0.115/kWh.

Xboxes have always been sold at a loss and then Microsoft makes back its money via games.

https://www.makeuseof.com/microsoft-confirms-its-selling-xbo...

For websites, the value is that feature flags should be much faster than the revert/deploy cycle.

At $PRIOR_JOB, a revert/deploy or rollback takes tens of minutes of the main application.

Note that the ASF does not pay for software development on any Apache projects; we rely on volunteers for all of our project coding work. The ASF focuses on providing the technical, legal, and community infrastructure for like-minded communities; we trust that healthy project communities will build their own software products.

https://www.apache.org/foundation/governance/

I fully agree. I cannot stress how much I appreciate how Apple TV is the only mainstream video hardware that is completely ad free.

Yes it's pricey (in comparison to other video streaming hardware), but Apple doesn't try to monetize the end user and for that I will pay Apple their $179 to avoid being showered with ads by smart TV OSes, Roku, Google TV, Amazon Fire devices, etc.

I've had my Vizio TV (P55-F1, 2019 model; a mid range model) for about 2.5 years now. Image/sound quality is great. But the annoyances and overall mediocrity of the OS and its updates [0] made me just disconnect the TV from the internet and fully switch over to using an Apple TV for all consumption rather than using the native Vizio OS.

[0]: The OS is terrible and the remote randomly stops working sometimes. Sometimes the TV would take tens of seconds to turn on, but then other times it was near instant.

Every single update since I've gotten the TV seems to make the TV even slower/more laggy. There was even an update about two years back where the Youtube app's volume was inexplicably an order of magnitude lower than every other input's volume (e.g. a volume of 100/100 on the Youtube app ended up being equivalent to a volume of 10/100 for all other apps/inputs). It took Vizio 1-3 months to fix it.

Unblockable ads on the home screen and genuinely multi-hundred millisecond response times on the app launcher infuriated me.

In the year I used it, I never personally noticed it going down. Although that being said, their SLA is only 99.9% delivery in any calendar month within 5 minutes. The penalty for missing that SLA is only 10% of that month's bill.

Once an Incident is triggered, PagerDuty will deliver the First Responder Alert within the Notification Delivery Period for 99.9% of the notifications sent by PagerDuty for the Customer during any calendar month. The “Notification Delivery Period” is five (5) minutes and it is measured as the time it takes PagerDuty to deliver a First Responder Alert to telecommunication providers in accordance with the Service configuration and Contact Information.

...

If PagerDuty fails to meet the SLA set forth herein, Customer may receive a service credit. Customer will be eligible for a credit toward future fees owed to PagerDuty for the PagerDuty Service. The Service Credit is calculated as ten percent (10%) of the fees paid for or attributable to the month when the alleged SLA breach occurred.

https://www.pagerduty.com/standard-service-level-agreement/

VC money

Zillow is a publicly traded company and has been since July 2011. I don't know how they raised capital before then, but regardless they're well past the VC stage.

Sometimes there's limits to how high you can scale without overloading dependencies. For example, the database that the service accesses might only support n connections and the service is already using approximately n connections.

If the initial cost is x engineer hours and each hour costs $y, that implies the cost of the project is `x * $y + maintenance costs [of this system over the simpler, original approach]`

Is the increased speed worth `x * $y + maintenance costs`?

Could it pay off? Potentially yes. Will it actually pay off? I don't know since there's far too many variables to wildly speculate on. But I hope Netflix did the accounting at some point along the way to find out.

Not every improvement is worth building since the initial investment might grossly overshadow any potential gains (as a purely hypothetical situation, that's why you shouldn't spend $1 million up front to save $1/day for the next 30 years).

At $PRIOR_JOB, it always felt like the full E2E tests approached useless since for every bug successfully caught, it felt like there were ~20 false positives. At which point, everyone (myself included) blamed the tests and just repeatedly reran the tests until they usually passed. Every single failure would halt the pipeline anywhere from 5 minutes (in the case that rerunning the failed test shows that it was just a flaky test) up to multiple hours since everyone would rather try to diagnose/hotfix the issue rather than revert their code to unblock the pipeline.

With that being said, a full run of the E2E suite at $PRIOR_JOB took very, very low double digit minutes so it wasn't that expensive. Rerunning a handful of failed tests took single digit minutes so it wasn't too terrible.

100k bytes = ~98 KB.

That's not material.