I religiously apply patches to all my personal machines as soon as they become available. But I've recently been wondering about how much of a difference it makes today. I used to follow this space fairly closely 4-5 years ago, but I don't know what has changed since then.Once a typical use-after-free vulnerability is disclosed publicly, for example, how quickly does it get weaponized? I...
Moreover, this axiom is _independent_ of the other axioms in ZFC. It is in fact possible to have entirely self-consistent "worlds" of mathematics, ones where axiom of choice is true, and ones where it is false.
More details and examples of alternate axioms are in the Wikipedia article: https://en.wikipedia.org/wiki/Axiom_of_choice
If it seems weird that math can give you contradictory results, remember that the difference only shows up when you deal with some form of infinity (e.g. when performing an operation on an infinitely large set). For any usage of math in the real world, the truth or falsity of this axiom won't give you contradictory results.
So journal publication is not the only means of recognition.
Speaking of which, computer science is a bit weird in that conference papers tend to have higher visibility than journals, even though the latter still has some of its grandfathered glory. Not all conferences are equal, obviously. Some have a more rigorous submission process than others. But our field definitely carries a bit of skepticism about the value added by journal publishers.
You might find it interesting to look at the actual sqlite source commits where this change was introduced: https://sqlite.org/src/timeline?r=larger-databases It turns out the number comes from having a max of 2^32 pages in their database. Their default page being 4 kB each: https://www.sqlite.org/pgszchng2016.html
Working backwards, they must have raised it to 64kb: `python -c 'print(1024 * 64 * 232)'` produces 281,474,976,710,656.
> SQLite was originally designed with a policy of avoiding arbitrary limits. [...] Unfortunately, the no-limits policy has been shown to create problems. Because the upper bounds were not well defined, they were not tested, and bugs were often found when pushing SQLite to extremes.
That said, if you do not have actual data or experience to back up what you are preaching, I definitely welcome the call for caution. It is not useful to insist that "everyone should learn a certain skillset" unless you found those skills relevant in practice in some situation.
It sounds like you've been compiling an interesting collection of stories, ones that might be interesting to a lot of folks here.
That interpretation makes sense to me when I read the docs, but is way too easy to miss when I'm actually doing comparisons.
I'm sure you know exactly how much of which filter to apply for similar results. Laymen like ourselves will need a lot more trial and error. Their contribution here is to provide a push-button, automated mechanism.
I would have probably also tried something simple and given up due to the noise. So this is definitely interesting.
There nothing in between.
mv foo-<tab>
mv foo-bar-baz foo-<tab>
mv foo-bar-baz foo-bar-baz
Downside: you have to at least type `foo-` twice.
Upside: command line history still has the full command.
Have you ever tried wiring any non-trivial logic without flip-flops? Say, a simple signal routing layer. Even the most basic bits of logic becomes much less efficient to downright impossible without storage.
Protects that don't do that are therefore unlikely to remain interesting for long.
In other words, intraprocedural optimisation has always been more aggressive than interprocedural optimisation. If you try inlining every function ever into one giant function, you'll be forced to scale back optimization levels.
Unix file systems, and its philosophy of "everything is a file". It wasn't common before Unix to interact with devices through a filesystem. Somebody noticed that simple tasks like "listing with ls" and "hex-dumping with xxd" doesn't need separate utilities for files vs devices, and thus made the abstractions converge. If you ask me, this is the kind of abstraction I wouldn't normally think of. It's useful to know what kind of things to be on the lookout for.
The second example is fuzzing. At least today, it's still kind of painful to have to manually write fuzz-tests for everything we care about. Manually coming up with good test cases is also hard. But remember those Monad laws in Haskell? https://wiki.haskell.org/Monad_laws these are essentially free fuzzing code. If I implement something as a Monad, at least in theory I should be able to reuse existing fuzz-drivers to test my new code as well. I probably would not have had the patience to come up with good tests myself. Similarly for other categories. Again, it's good to know what general interfaces already exist.
Buggy code is not the problem, but a buggy process is.