I have tabs from like 6 months ago. Modern browsers have gotten pretty good at hibernating unused tabs and restore when needed. And this website is extremely light, it gets restored in milliseconds.
The browser history contains a lot of junk and I don't want that saved forever. Curated tab history is a bit different. It's stupid for sure, but also a bit comforting to keep the most important articles and such. For anything I really care about, there's always ArchiveBox.
If you pay developers x money / day and one of their core tools is down for n hours during the day and they spend their money on HN instead that's pretty straight forward to calculate.
“lol just use a workaround” doesn’t work in an environment with hundreds or thousands of employees coupled with audit, security, and other legal requirements to ship software.
If you're actually bleeding money, you better believe you'll get permissions for a workaround, if you know what you're doing.
It all ties back to the OP, where the issue you've might not be as bad as you think. I have been in situations where we have dropped all procedures to push a hot fix because we were actively bleeding money, and in situations where you know there is an issue, and you let it be.
What an odd hill to die on. Maybe I just lost a $30M client because they wanted an issue fixed now. Maybe my company would get sued for violating their contractual obligations if someone went cowboy to bypass procedures.
Maybe I pay for a service and I want that service to work consistently during core business hours.
Hosting the tournament has nothing to do with it. America is a lucrative market, and on top of that, FIFA can get away with charging insane ticket prices. I'm Canadian and soccer is my primary sport. Unfortunately, on a global level, nobody really cares about Canada or US when it comes to soccer.
it's arguable the "much of the rest of the world" could refer to number of countries rather than number of people, but I think "much of" applies to both so the author avoided the confusion.
one of cool road signs I saw years ago in Ladakh state on road from Manali to Leh. Funnily enough that 19h minibus trip sometimes went through valleys without any form of road, just used least uneven path. Not so funnily enough we had an obvious technical stop later when driver was banging with huge rock on some part of suspension for an hour, and luckily his caveman engineering worked well enough to get us moving again
> (Most) CRUD/OLTP applications don't delete data by timestamp; they delete by primary key. For those workloads, DROP TABLE (or dropping a partition) isn't a palatable option.
Property testing is stochastic, which may be fine, but only gives you a statistically (hopefully) high chance of discovering a problem. If you use something like SPARK/Ada, you can actually embed a proof in the code so that you actually know that the code is correct (for what you've proven). PBT scales better than embedding proofs, though, and is highly effective in practice along with fuzzing.
Unless you literally try every possible combination of inputs (which is usually infeasible), property testing can't give you mathematical guarantees about correctness. You can think of it as a halfway house between classic testing and formal verification:
Classic testing: A human comes up with some concrete example inputs for which they know the "right answers" (corresponding outputs). They write code that runs the code under test, gets its actual outputs, and compares them to the desired outputs.
Property testing: A human comes up with a precise way of randomly generating concrete example (input, desired output) pairs. They write some code to describe how to generate the pairs, often using a declarative DSL that describes only constraints on the inputs and outputs, with the understanding that anything not expressly forbidden is permitted, like "The input can be any list of between 0 and 100 integers each between -500 and 500" and "Every integer in the input must appear the same number of times in the output". They then write some more code (often a single line) to ask the computer to use this "spec" to randomly generate, say, 1000 such pairs, or as many pairs as can be checked in 1s. The computer generates the pairs itself, runs the code under test on each input and and checks its output matches the desired output.
Formal verification: A human comes up with a spec that typically describes conditions that must hold for all (input, output) pairs. This may look very similar to, or even exactly like the DSL used for property testing, though in general there are other conditions that can be expressed that cannot be checked with property testing even in principle -- for example, checking that the program always eventually terminates. The main difference is that the code under test is never actually run; instead, the computer analyses the source code itself to attempt mathematically prove that the stated conditions hold. How to actually accomplish this is a field of active research, but one basic approach is called "symbolic execution". To greatly simplify, if we forget about loops and conditionals for a moment, the idea is that we can write down things we know must be true after each statement executes, based on the things we knew must be true before it executed. So for example if x is a variable initially containing any integer (and we ignore overflow) then after the line
x = x * x
runs, we know that x >= 0. To handle conditionals like
if x > 50:
x = 42
something_afterwards(x)
the prover "forks" into two cases: One in which we know for certain that x > 50, one in which we know for certain that x <= 50. At the end of the if statement it then has the task of recombining what is known about the two cases. In this example, the first case lets us conclude that x = 42 by the end, while the second case lets us conclude that x <= 50 by the end, so it could conclude that x <= 50 either way by the time execution reaches something_afterwards(x). Handling loops is trickier but generally involves looking for invariants.
> but that looks pretty close to pricing for SMS. Which makes market sense (imho) because it's a substitute good
People switched to whatsapp because:
1. It was free unlike SMS
2. It was ubiquitously available like SMS (unlike BBM)
3. It was genuinely a good product.
This feels like Whatsapp (Meta) is rug pulling the users once everyone has moved to Whatsapp, almost analogous to what Uber did. Drive Taxis out of business with predatory pricing, and then increase the prices.
As a whatsapp user, I am quite happy that marketing messages are expensive. Puts a price on spam, which means I get less of it. If they want to send me something actually useful that usually falls into one of the other much cheaper categories
Would be nice if there was an easier way to get an API to message a small number of people though, without the ceremony meant for businesses that want to message thousands or millions
reply