where did they mention a script to try passwords? all accounts apparently have the same default password

We are working on a fast reading font which works by using just opentype features (no server or other script required)

https://github.com/Born2Root/Fast-Font

We also created some emoji fonts: https://github.com/Born2Root/Feature-Fonts

they are _not_ backwards compatible. That's a big part of the problem. A trailing comma is a syntax error for an SQL engine without support for it

I mean, yes, technically, but is anyone's code actually breaking because of this?

Who is writing SQL queries expecting them to fail because of this reason?

By your definition, "backwards compatible" doesn't mean anything. Literally everything will be a breaking change if you define "backwards compatible" like this.

I think the term you are looking for is "forwards compatible"! Old SQL queries will still run fine on engines that support the new syntax (they're forwards compatible.) New SQL queries with trailing commas will NOT run fine on engines that don't support trailing commas; this is not a backwards-compatible change. And that's fine.

It's forwards compatible from the perspective of the query - queries in the new style will continue to work on newer db versions.

It's backwards compatible from the perspective of the database - the db will continue to support queries from older versions.

I believe you're speaking from different perspectives.

> New SQL queries with trailing commas will NOT run fine on engines that don't support trailing commas; this is not a backwards-compatible change.

But they never ran fine on engines that didn't support trailing commas in the first place :/

What you're calling "forwards compatible" is what I call "backwards compatible". Frankly, I suspect most people expect "backwards compatible" stuff to work like this.

Is this distinction useful in any way?

I think the confusion may be whether you're talking about the queries or the engine. I think this change to the engine/parser would be backwards compatible because old queries will still work on the new engine. A change to the queries in a codebase to include trailing commas would not be backwards compatible because it won't work on older parsers. It seems clear to me that the change discussed here is the engine, hence it should properly be characterized as "backwards compatible".

No. It is not. Whomever brought it up was not helping.

I think the question is whether you are disagreeing for pedantic reasons or are actually trying to contribute.

If you are trying to contribute, you will use the phrase backward compatible as we always do: my old code will still run after the change.

If you are trying to be pedantic, you will choose a new way of looking at it: My new code will not work if you go backward in time.

I don't care. I will swear to never write a dangling comma for any engine that doesn't support it. Also, I will swear to never use an engine that doesn't support it if once that does exists... Just as I did with Javascript.

hosting such videos on YouTube alternatives (even federated once) would be even better. I.e Blender has a peertube instance video.blender.org

See https://github.com/Born2Root/Fast-Font for a bionic font using font features as well

there are many projects implementing this style, but I haven't seen one coming up with a font based solution, nice