torinmr

BB(n) isn't computable, even given unlimited computational resources.

Running all n-state machines won't work, because you may have some machines that continue indefinitely, but without repeating. (Remember that while the number of states is finite, the tape is infinite.) No matter how long you run them for, you can't be sure whether they are going to terminate at some point in the future, or if they'll continue forever without halting.

This is why computing BB(n) for arbitrary n is equivalent to solving the halting problem.

Princeton's COS 226 covered this topic quite well when I took it. It was a good intro to both algorithms and DS content, as well as practical skills for leetcode style questions.

You can check out the Syllabus for the course as taught at Princeton here[0], or take the Algorithms I and II courses on Coursera[1] which cover ~2/3 of the content but have video lectures.

[0] https://www.cs.princeton.edu/courses/archive/spring23/cos226... [1]: https://www.coursera.org/learn/algorithms-part1

The point of the tax is not that the revenue will be used to reduce waste. The point is that it will increase the cost of producing waste for the polluter, ideally exactly to the point where it matches the cost to society of that waste.

The purpose isn't to make people stop polluting entirely, but to make it so they will only do so when it brings them a benefit larger than the societal cost of the pollution.

Not married, but in a long-term relationship living with my partner. I listen to them while commuting to work or while doing household chores, and consistently get through 4+ hours/week of podcasts.

I don't find my listening habits change that much when I'm alone, as either way I tend to only listen to them while I'm engaged in some other activity. (When I have completely free time I prefer more interactive activities like games or music.)

At my university CA: AQA was used as the text for the second course in computer architecture. The first course in computer architecture used this book: https://www.amazon.com/Computer-Organization-Design-Fourth-A....

If you do get around to reading CA: AQA, you can follow along with this Coursera course (it's taught by the professor I had when I took it at Princeton, and he does a great job teaching it): https://www.coursera.org/learn/comparch

It seems like there's an obvious solution to the problem of how to crack down on the types of bot your AI tries to detect, without removing legitimate boots:

Give users the ability to designate their account as a self-reported bot. Accounts designated this way would be identified as a bot in the Twitter UI, and would be exempt from captchas.

I would assume that there was a special policy in place for people working on teams with a requirement for that amount of RAM.

I interned on Chrome in 2013, and at the time all Chrome engineers got a computer with an SSD (which I was told wasn't standard at the time), since they had to build Chrome on their desktops (whereas most other engineers could use Google's distributed build system).

I empathize with that feeling! I recently "automated" washing dishes by upgrading to an apartment with a dishwasher, and it's an amazing quality of life improvement!

I think the parent was saying that they would buy parcels of land where they planned to build stations, and then profit when that land appreciated due to the presence of the station.

I haven't used Kotlin, but glancing over their comparison page the one that jumped out to me was that it (almost) eliminates the possibility of null pointer exceptions: https://kotlinlang.org/docs/reference/null-safety.html

My variation on that is to only ever lock my front door or car using my keys from the outside. It's a bit less convenient than using the lock on the inside, but is guaranteed to avoid lockouts.

The courses are identical to the courses one would take if they were getting their Master's at Stanford - the only difference is that only four classes are required, while a Master's requires about 15.

I'm enrolled in Stanford's CS Master's program right now through the Honors Cooperative Program (which lets you get a Master's online while working in industry), and I'm currently planning on doing a dual specialization in Systems and AI. For the AI specialization I've already taken CS 221 and 229, and I'll have to take three more AI classes drawn from a list pretty similar to the Elective Courses list in the OP.

A particularly hairy case is where you use variables as features which are themselves generated through other potentially-discriminatory processes. For example, including a "has committed a felony" feature seems like a no-brainer for a hiring or lending application, but now any racial or other discrimination present in the criminal justice system has now "infected" your hiring process, so that the outcomes of your hiring process are now racially biased even though your process itself was not.

Could that also be related to diet? I'm guessing your grandmother practically never ate sugar if she was living on 200 grams of bread a day.

I've also heard that early modern humans had fairly good teeth for their age despite the presumed lack of dental care, presumably also due to differences in their diet from us.

The SRE Book (http://shop.oreilly.com/product/0636920041528.do) has a number of chapters on load balancing that are well worth reading.

One thing that the book covers that I think this article glossed over was the fact that in sufficiently large systems there's never a single "load balancer" - instead there's many layers of load balancing systems at different levels of the stack. E.g.:

DNS load balancing -> high capacity network-level load balancing -> shared reverse HTTP proxy -> application server -> database (with a "load balancer" internal to the application server load balancing among DB replicas).

Where'd you get +20 miles from? The Leaf has a 108 mile range, the Bolt has a 238 mile range - that's a huge difference.

This was a pretty interesting article that hits very close to home (I'm an SRE at Google). I think the central thesis (that developers are better at running rapidly changing products because they are able to find and fix bugs more quickly) is a bit flawed, however.

The reason is that I think the most valuable contribution of the SRE is not in responding quickly to outages, but in improving the system to avoid outages in the first place. SREs tend to be better at this than developers because (a) they have better knowledge of best practices by virtue of doing this kind of work all day every day and (b) they are more incentivized to prioritize this kind of work.

Because of this, the dynamic I commonly observe is that SRE-run services have fewer and smaller release-related outages because techniques like canarying, gradual rollouts, automated release evaluation, and so forth are deployed to a great extent. On the other hand, developer run services tend to have more frequent and larger release-related outages because these techniques are not used or are used ineffectively. So even though the developers can diagnose the cause of a release-related bug more efficiently than SREs can, the SRE service is still more reliable.

In my view, the main reasons to have developers support their own services fall into (a) there aren't enough SREs to support everything, (b) the service is small enough that investing the kind of manpower SRE would into implementing these best practices would not be cost effective, and (c) SRE support can be used as a carrot to get developers to improve their own services.

Edit: I would add that if the roll of oncall is expected to include only carrying the pager, and not making substantial contributions to improve the reliability of the system, then the author is absolutely right that having an SRE or similar carry the pager has next to no benefit.

It is in fact 30-80%: see page 11 of the PDF: http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f...

Great article, I ran into this exact problem at work today. You can also get a very similar problem if the timeseries aggregation system you're using does any pre-aggregation before you calculate the percentile - for example, if you sample your servers every 90 seconds, then any latency number it reports is likely already averaged over the requests the server received during that time period, meaning your 99th percentile number is really the latency of the 99th percentile server, not the 99th percentile request. Using latency buckets solves this problem as well, however.

They're looking at the HTTP referer [sic]: https://en.wikipedia.org/wiki/HTTP_referer

Most newspapers don't show paywalls to users coming from a search engine, as part of a compromise with Google to prevent them from being penalized in rankings.

For companies that size, the really important services probably have a distributed ops team, with a team in Europe/Asia alternating 12 hour oncall shifts with a team in North America. In an emergency, the non-North American team could take 24 hour shifts to keep the infrastructure alive.

Though of course if headquarters was really wiped off the map, there'd be huge problems with communication, tribal knowledge that only existed in the heads of senior engineers in Seattle, and so forth.

What an odd mix of totally innocuous comparisons (Hong Kong Dollar vs Renminbi), fairly justified criticisms of China's government, and nationalistic drivel.

I did at least find it amusing that the sentence the artist chose to contrast the age of Mandarin and Cantonese was "Fuck your mother."

I was confused by the picture with the phone numbers, until I realized it was a veiled reference to the Tiananmen Square massacre, which is known as the June 4th incident in China (literally, "six four incident").

According to the author, you need to know this in order to understand "how Google works," because the PageRank algorithm is described in terms of finding the principal eigenvector of a particular matrix.

Advice by sillysaurus3 on 'recommended reading' for programmers, mainly focusing on C and distributed systems.

https://news.ycombinator.com/item?id=7602457