This is untrue, algorithms measure time complexity classes based on specific operations, for example comparison algorithms are cited as typically O(n * log(n)) but this refers to the number of comparisons irrespective of what the complexity of memory accesses is. For example it's possible that comparing two values to each other has time complexity of O(2^N) in which case sorting such a data structure would be impractical, and yet it would still be the case that the sorting algorithm itself has a time complexity of O(N log(N)) because time complexity is with respect to some given set of operations.
Another common scenario where this comes up and actually results in a great deal of confusion and misconceptions are hash maps, which are said to have a time complexity of O(1), but that does not mean that if you actually benchmark the performance of a hash map with respect to its size, that the graph will be flat or asymptotically approaches a constant value. Larger hash maps are slower to access than smaller hash maps because the O(1) isn't intended to be a claim about the overall performance of the hash map as a whole, but rather a claim about the average number of probe operations needed to lookup a value.
In fact, in the absolute purest form of time complexity analysis, where the operations involved are literally the transitions of a Turing machine, memory access is not assumed to be O(1) but rather O(n).
People said the same thing about so many other online services since the 90s. The issue is that you're imagining ChatGPT as it exists right now with your current use case but just with ads inserted into their product. That's not really how these things go... instead OpenAI will wait until their product becomes so ingrained in everyday usage that you can't just decide to stop using them. It is possible, although not certain, that their product becomes ubiquitous and using LLMs someway somehow just becomes a normal way of doing your job, or using your computer, or performing menial and ordinary tasks. Using an LLM will be like using email, or using Google maps, or some other common tool we don't think much of.
That's when services start to insert ads into their product.
Every service I know of explicitly bans this practice, so unless you can employ the cleaner full time then if they accept your arrangement they risk getting fired.
It's a common misconception that std::shared_ptr is thread safe. The counter is thread safe, but the actual shared_ptr itself can not be shared across multiple threads.
There is now atomic_shared_ptr which is thread safe.
Rules changed in 2003, but until then medical residency programs routinely had doctors working 100+ hours a week or longer. In 2003 a cap of 80 hours a week was instituted along with a maximum of 24 hours in any given period, but programs found various loopholes around that cap which still had doctors working close to 100 hours a week. So further restrictions were placed so that over any 4 week period there's a hard cap of 320 hours, no exceptions.
At any rate, for most of the HN crowd who work a fairly routine IT or an office job, 80+ hours sustained for months and months might seem impossible, but join the military, work on a ship, work on a farm, work the oil fields, work in investment banking, work in a film crew which threatened to go on strike in 2021 for having 98 hour work weeks for months on end... and you find that while it's not common, it certainly happens in various fields.
> If only it were so easy as writing more makes you a better writer!
One commonly repeated piece of advice that almost all successful authors state is to write a lot, a lot, a lot. Like just practice writing, it doesn't have to be good.
I hear this often said about many other creative endeavors as well, including painting, cooking, game development/design, etc... It often seems like really good artisans just pull greatness out of thin air, but that's because we often only see the successes, not the failures, but I am reminded that even the best writers, poets, and artists in general spend a great amount of time just creating content that no one will ever see.
>You can compute a number that is equal to BB(n), but you can't prove that it is the right number you are looking for.
You can't categorically declare that something is unprovable. You can simply state that within some formal theory a proposition is independent, but you can't state that a proposition is independent of all possibly formal theories.
That's a misinterpretation of what the article says. There is no actual bound in principle to what can be computed. There is a fairly practical bound which is likely BB(10) for all intents and purposes, but in principle there is no finite value of n for which BB(n) is somehow mathematically unknowable.
ZFC is not some God given axiomatic system, it just happens to be one that mathematicians in a very niche domain have settled on because almost all problems under investigation can be captured by it. Most working mathematicians don't really concern themselves with it one way or another, almost no mathematical proofs actually reference ZFC, and with respect to busy beavers, it's not at all uncommon to extend ZFC with even more powerful axioms such as large cardinality axioms in order to investigate them.
Anyhow, just want to dispel a common misconception that comes up that somehow there is a limit in principle to what the largest BB(n) is that can be computed. There are practical limits for sure, but there is no limit in principle.
This is true in general for every mathematical proof in ZFC (and even in more powerful theories). The decision problem "Given a formula F and an integer n, is there a ZFC proof of F of length <= n?" is NP complete, meaning that verifying the proof can be done in polynomial time while deriving the proof can require an exponential amount of time.
Plenty of companies have gone bankrupt or lost a great deal of credibility due to a single bug or single failure. I don't see why CrowdStrike would be any different in this regard.
The number of bugs/failures is not a meaningful metric, it's the significance of that failure that matters, and in the case of CrowdStrike that single failure was such a catastrophe that any claims they make should be scrutinized.
The fact that we can not scrutinize their claim in this instance since the details are not public makes this allegation very weak and worth being very skeptical over.
Clang modules are nothing like what got standardized. Clang modules are basically a cleaned up and standardized form of precompiled headers and they absolutely speed up builds, in fact that is primarily their function.
Visas can come with a bunch of rules attached to them about what you can or can't do in the host country, and those rules can get kind of tricky to properly interpret.
Another common scenario where this comes up and actually results in a great deal of confusion and misconceptions are hash maps, which are said to have a time complexity of O(1), but that does not mean that if you actually benchmark the performance of a hash map with respect to its size, that the graph will be flat or asymptotically approaches a constant value. Larger hash maps are slower to access than smaller hash maps because the O(1) isn't intended to be a claim about the overall performance of the hash map as a whole, but rather a claim about the average number of probe operations needed to lookup a value.
In fact, in the absolute purest form of time complexity analysis, where the operations involved are literally the transitions of a Turing machine, memory access is not assumed to be O(1) but rather O(n).