NewEntryHN

This game is a counter-example of a long boring game. It was a long exciting game.

> If they know they will get the reward then they know the exact opportunity cost and can weigh that against performing the behavior.

So you need to to randomize the value of the treat. Otherwise the dog knows the upper bound of the opportunity and the same reasoning applies.

In my experience there is not much to know about the ACD parts of ACID, because they're just guaranties that are obvious to want and which will naturally make your life easier.

The I (Isolation) part is the one you'll need to understand whenever you scale up to a point where concurrency starts to become non trivial in your product, mainly because there are multiple levels of isolation, which each provides different guaranties, and you'll need to understand what level your database uses and what it means for your application.

As for the overall point of the article, it's just a question of scale. The more you scale the more you need to cut through the abstraction to understand what the hell is going on. Hire accordingly.

> calculating the monthly average

This abstracts away a fundamental property of skill improvement that is true for any game, but intensively true at chess: any ELO you win during a gaming session will be lost soon by a new gaming session in which you play the game tired, or unfocused, or angry, or feeling under the weather. You still improve from one session to the next, so there is a little delta because your average ELO win is greater than you average ELO loss, but it makes the overall process extremely slow.

What I'm saying is that 100 ELO doesn't make that much of a difference in skill. You probably regularly play at +200 ELO of your actual ELO. However, maintaining a clean game hygiene and actually accumulating the ELO points to reach this level of "estate" is a whole other story.

"Don't say HN is turning into Reddit, because it has consistently been so from the start"?

> a meltdown could not happen

Gen III reactors have a core catcher[1] to handle a meltdown, in addition to many features making a meltdown even less likely to happen.

[1] https://en.wikipedia.org/wiki/Core_catcher

The article explicitly tells that he did not die.

HTTP is an application protocol and most of this article doesn't make any sense.

It literally explains why this show is not as good as the original.

Which can't be proven by E2E either, and which you don't need to prove.

- Computers have more CPU than mobile phones.

- Standard and easy installation process of Apps.

- Apps born with modern UI.

How do I block Plausible?

Do people use OkCupid on the browser?

The problem is that sitting in front of a computer gives no indication of business. You wouldn't interrupt a surgeon during an operation, or a pilot landing a plane, or a crane operator moving some load on a construction site, or a carpenter currently doing woodwork; because you can very visibly see them being focused on their work. Sitting in front of a computer is the default position of the modern office workplace, which makes it a meaningless signal.

I agree with the general sentiment, although the author seems to miss the point that many people trying to monetize their hobby aren't trying to win more money, but simply to replace the time working in a pay-the-bill job with time spent working on their hobby. There is a catch, which is that monetizing will require dealing with business duties, which comes with the risk of alienating the hobby. It's not clear how it compares to wasting your lifetime on a career you don't really care about.

> Second, everyone needs to be using unique passwords. You don’t have to use a password manager to do that, whatever system works for you is fine. If you want to use a notebook in a desk drawer, that’s totally acceptable.

You don't need a notebook for unique passwords. Just use the service's name. Unless you also meant unguessable, in which case a notebook is probably going to be insufficient because your brain-powered password generator will soon run out of entropy.

> The tech press can review usability and onboarding experience, but can’t realistically evaluate any security claims, so how do you propose users tell the difference?

"Security at the expense of usability, comes at the expense of security." Users don't need to know the difference because the only danger they need to protect themselves from is "my gmail was hacked" and the only requirement for that is that they use an un-guessable password saved somewhere unsophisticated attackers can't access. Any password manager accomplishes this.

> An attacker (or malicious insider) in control of the vendor's network can change the code that is served to your browser

Password managers have servers sending code over to the browser? After the installation process?

This a a loss distributed over many businesses.

You seem to ask the question about the absolute number of outages, whereas uptime is about the number of outages per units of time.

Slack does progressive roll-outs. The broken release hypothesis seems very unlikely.

Another common cause is resource exhaustion as a result of poorly monitored resources (or bugged monitoring). For example Google's authentication was down because their system reported (wrongly) available quota of 0. The last two incidents at my company were also related to resource exhaustion.

Sample size is 30,000.

Is the trick here that the driver is responsible in case of accident? That would be evil genius.

You could call inertia a force then.

> everyone has to get out of the house and making actual friends in life.

According to what "law"? Introverted lonely people having most of their social interactions at work is a fact of life mate.

Driving is not necessarily a good example for your point because if people actually focused on behaving remarkably behind the wheel (that would be the "constricting way to live a life"), road accidents would be much less frequent than they are today (which is already way less than 0.01% fortunately).

> But if you recognize that somebody is talking you about something that is, really, a defect in your software, don’t do the error of reducing the interaction to a vile matter of money.

If an open-source project grows to the point where time is insufficient to maintain it alongside your day-to-day job, then the matter of money becomes inevitable. And I'm not talking about allocating one's entire free time to the project, but just the time one assesses to be reasonable for this hobby, which can be rather short because of other occupations (rest, family, other hobbies, etc).

First law of the Internet: you cannot delete something from the Internet.

Second law of the Internet: you cannot keep track of where something is on the Internet.

Why are we talking about checking return values (which are generated by a function according to its interface and should not be checked) when we should be talking about checking configuration values (which are generated by humans according to whatever they type on their keyboard and should be checked). Also why are we talking about checking stuff when we should be talking about one bug bringing the entire system down?

Except extraordinary is correlated with excellent because this premise:

> We can all achieve excellence

is false in practice.

Out of curiosity I wondered what was the biggest Sqlite databse in my filesystem:

find / -name *.sqlite -printf '%s %p\n' 2>/dev/null | sort -nr | head -n 1

The winner is `favicons.sqlite` from Firefox profile directory, which is 40 MB.