masklinn

The article does not say it’s storing the authenticator data (in the format the webauthn spec specifies), it says it’s storing (most of) the fields in cbor. So it’s using the webauthn reference for logical purposes (the names and types of fields) not physical (the encoding).

Obviously. You also need to profile to make sure this is actually a hit spot, deploying unsafe to remove bounds checks which account for ~0% of runtime is a waste of effort.

And as the essay mentions there are also “hints” you can give the compiler to fold bounds checks which may be sufficient.

A big part of it is taxes, European countries tend to tax fuel pretty heavily.

If heating oil is still a thing where you are, compare its prices to diesel (especially historically). They’re nearly the same product, the difference is almost entirely fuel taxes.

On the continent, afaik most countries work on a lease system, you rent a plot for a few decades (which may or may not be renewable). Some countries have a “perpetual” lease with an ongoing fee, a few years after the payment stops the plot gets cycled.

‘Course space requirements are also a factor, if you have a family plot in a depopulated village in the countryside odds are good plots will be cheap and renewable forever.

and presumably other things?

Various statistical views over the value distributions of the indexes, so that the planner can estimate how useful (selective) the index should be.

sqlite_stat1 just gives an average (number of records in the index, and average number of records per value), and if enabled sqlite_stat4 stores histogram data.

omg you're right. Another example of SQLite's type-flimsyness.

You're just firing on all the bullshit cylinders in your little motorised gish gallop aren't you?

The only RDBMS in widespread use which supports unsigned integers is mysql. Not postgres, not oracle, not sql server, not db2, not snowflake, not databricks.

So now we're just layering on our own brittle validation and runtime checks to make up for sqlite's woeful deficiency supporting even basic domain data types.

Ah yes, the "brittle validation" of actually validating the thing you purported to care about two comments ago. Amazing.

SQLite will gladly store a u64::MAX as a "unix timestamp"

SQLite does not support unsigned integers.

Try reading that back in any application date/time code and your app probably crashes immediately.

Postgres will happily ingest and produce dates in the 280th millenium, which will also crash your application if its datetime type can’t handle that shrug.

You can add a check constraint that your field passes through SQLite’s datetime functions and it’ll be clamped between the years 0 and 9999. Or you can put in your own limits matching your application layer, or your application’s business logic. That’s what check constrains are for (amongst other things).

It’s perfectly fine if your write throughput is low, especially in wal mode. Multiprocess does not actually change much if anything, even in multithreaded mode you want every thread to have its own connection and to have a good handle on who is writing when.

In fairness, sqlite is perfectly happy with Julian dates or Unix timestamps (that’s the affinity of a column typed “datetime” in non-strict mode) and timestamp(tz) are nothing to write home about except in complaint.

Yup, every alternative rebar has drawbacks which causes increased costs or different failure modes which is why they tend to be used in specialised applications where they are necessary.

Stainless steel rebar could be used

There are also coated and non-metallic rebars.

The 360 was a multithreaded machine, it had 3 physical cores with hyperthreading (so 6 logical cores).

The PS3 was a completely different beast, it had a single general purpose core (hyperthreaded) with 6 user-accessible vector coprocessors (in-order, non-speculative, with their own ISA, and without shared memory) on a 4-lane ring bus. This was much more complex and fairly alien topology even more so back at the time, and while tooling might have helped bridge the gap Sony’s were… not great, even less so compared to MS which could lean on their windows tooling.

The 360 had 3 cores. The PS3 had a single core with vector coprocessors on a ring bus.

GPGPU is what displaced the Cell SPEs, and you wouldn’t count that as cores. In fact the PS3 originally didn’t include a GPU, the SPEs were supposed to handle it all, so in a way they were approaching the same solution from the opposite direction.

upb parses FAST, but then every access is still C->Python and it slows it down. So for many reads the slow python one can win?

That is pretty unlikely. TFA's version is in Rust and just barely edges out upb.

I don’t know what black magic Google uses for the Python implementation, but the classes it generates are totally opaque and impossible to inspect.

TFA seems to say that they’re just thin proxies over the underlying C++ APIs, which would more than do it, and does not surprise me (the re2 Python bindings are similar, not as bad since they don’t generate Python code but they’re really c++-y — in Google’s flavour too — and uncomfortable).

You do not. SQLite date/time functions work with time-values which can be ISO timestamp strings, Julian fractional day numbers, or Unix timestamps. See https://sqlite.org/lang_datefunc.html for the details.

A comment will do more than a nonsensical type which is not enforced: it won’t have the wrong affinity, it will spell out what the concrete type is, and there’s no limit to what it can specify.

Domain types would be the best fix, but I do not think legacy tables are the second best.

The serious limitation is that you create a column as date, you don’t understand what sqlite does with it, and you start storing strings in there, at which point everything is confused.

You can use comments to preserve intent in strict mode, and that’s strictly more useful than fuzzy mode: it is richer, it is clearer, and it is no less reliable.

Midgley is complicit, but he's just a small piece.

Midgley used to tour around “proving” the safety of leaded gas by pouring it on his hands. And had to be treated twice for lead poisoning.

He was very much a culprit.

The intent of ANY is obviously that the values be flexible. That’s why it’s there if you need it.

numeric is not a type it’s an affinity, the underlying types are real and integer. That is why numeric is not valid on strict tables.

You can be flexible with strict tables, type every column as ANY and you pretty much get back the original behaviour.

some data types are not available, such as Date.

That’s not a type, you just get a numeric-affinity column.

Instead, you're expected to just use a text column and store a textual timestamp.

You can actually use an integer column and store Unix timestamps (or floats for subsecond accuracy).

But yes, sqlite has very little types support and its default behaviour is very much unityped / dynamically typed which I also dislike. Same with having to enable foreign keys every time you open a connection.

Claims do not support themselves. The claim is unsupported by evidence and thus the burden of proof is on them or you to produce that evidence.

OK?

Your argument that the poster needs to go read, implement, integrate, and benchmark the algorithm to to generate evidence to counter the absence of evidence for the claim is ridiculous.

The poster didn't complain that evaluating the claim was work they couldn't be arsed to do, they complained that they could not evaluate the claim because they were legally bound to accept it. Both parts of that declaration were and are factually wrong.

It would be as easy as 1-2-3 for the author to present their evidence

The author implemented this algorithm as an employee 20 years ago, they do not own and can not provide the original code, they would have to reimplement it from scratch (possibly from the patent if they didn't otherwise publish it, which I assume they did not since they link to the white paper but not an actual paper and apparently had to make up a name for it just now). They might have an edge from being more familiar with the domain, but given the poster's dismissal I'm sure they're deeply familiar with the subject.

And given the tone, the author is (well was, the post is 6 months old) just showing this cool thing they made back then, which they can now usefully talk about (since previously it was patent-encumbered), and give some history for.

you are demanding the poster demonstrate the negative

I am doing no such thing.

I can evaluate the claim now

And the article is now. What luck!

I would not have been able to evaluate the speed gain of an Oracle database using whatever proprietary implementation they are using.

Which has nothing to do with the article. In fact it has less than nothing to do with anything, as even the original whitepaper goes through great lengths to specify that it's lab observations and only compares versions of oracle, none of which would have been relevant to you if you'd refused to use oracle in the first place.

And Oracle never forbid running benchmarks (maybe they could now, they wouldn't have had the tracking and C3 to do so back in the 80s), DeWitt Clauses forbid publishing benchmarks without prior approval.

Claiming I've called author anything is putting words in my mouth.

You're asserting that you can not trust oracle's numbers, in response to an article by a (former) oracle employee talking about "their" sort algorithm and the numbers it got.

There are only two possibilities here:

1. you got hopelessly lost in both space and time as you were looking for a 20 years ago thread on the linked oracle whitepaper, and your comments have nothing to do with TFA

2. you're calling the TFAA a liar who can not be trusted, given they're the author of the algorithm, givesthe same number, and in fact originally derived the rough gain when implementing and benchmarking the algorithm:

once I had this implemented within the Oracle DBMS I was able to compare it with the old sort. The new sort was often about 5 times faster than the old sort.

So which is it?

TFA is a post by the author of the algorithm, talking about the performance they originally predicted and later observed after implementing it while they were working at oracle, now that the patent has expired and anyone can implement the algorithm.

So:

- you are calling them a liar

- and are asserting you can not evaluate the claim even though you can implement and benchmark the algorithm in whatever DBMS you favour

Even if you “rely on countless unsafe blocks”, unsafe is additive, it gives access to additional APIs which are not checked. It does not disable affine types, the borrow checker, or send/sync traits. Unless the entire codebase is unsafe (e.g. fresh out of c2rust) it’s very hard to not have more guarantees.

And because unsafe is generally highly local or localizable reasoning (conventionally backed by safety justifications) it really is quite reasonable to go plugging at it, or task an AI within that.

In Python, this works correctly for negative values.

They’re both “broken” in different ways. Arguably C’s brokenness is more apparent and less useful but Python also has footguns: C uses truncated division for its “modulo” so the remainder has the sign of the dividend, Python uses floored division so the remainder has the sign of the divisor instead.

The wiki page for modulo has a pretty extensive page on the subject.

The reason MDD was merged into Boeing is MDD was in the process of failing: the MD10 was completely outdated, the MD11 was not competitive, and with the Cold War ending the infinite money tap of military projects was closing (it was already quite a ways there, the last supper was in 1993, by the time of the MDD merger half the major contractors were gone)