nloomans

Are those customers from Germany maybe? Germany has really high Firefox market share compared to basically any other country.

> a digital copy with the ability of doing millions of copies is stored somewhere

somewhere were we can't access it. as the article states: “permanently locking human knowledge inside private corporate servers”

the issue isn't that the physical copy is gone, it's that they are preventing people from making digital copies that are actually accessible by destroying the physical copies.

> If you go to a recycling centre, the garbage to quality ratio is over 100 or more.

archivists keep everything, because we don't know right now what will be important 100 years from now.

Interesting read! I find the idea to use SQL queries to get only the relevant data quite convincing. I do wonder how this would work in practice though. Any changes the user makes would have to be inserted with SQL to allow for the new data to be included in SQL queries, but users also expect to be able to make changes and then not save them (or save them into a different file).

Should one make a massive transaction that is only committed when saving? It is possible to commit such a transaction to a different file when using Save As?

Or maybe for editing one would need to copy the file to a separate temporary location, constantly commit to that file, and when saving move the temporary file over the original file (this way we aren't losing the resilience against corruption SQLite offers).

Or is there a better way to do this? I don't like storing pending changes into the original file since it kinda goes against how users expect files to work (and could cause them to accidentally leak data).

These example commits seem like pretty bad commit messages to me. They are just a summery of the changes (something a motivated reader can rediscover by reading the diff), while leaving out the why, which will be lost to history if not documented.

No I did mean flag values. Allowing user-controlled short flags is horrifying.

I disagree with it being a minor issue. If I write a shell script around a program that accepts GNU-style arguments, I expect the following to be correct:

    ./cmd -a"$USER_CONTROLLED_DATA"

A program using this package would break that assumption, introducing a bug where this user-controlled data cannot start with an '='.

Only if you don't care about accessibility. You still want labels for screenreaders and other assistive technologies.

Have you tried it? They use a proprietary integration with Authy that prevents you from using anything else. No QR code is ever provided.

I tested the example using the TalkBack screenreader on Android. With Firefox I was able to select and click on the link, but it did not announce the email address. With Chromium it completely ignored the existence of the SVG email. I was unable to select it and it was like the email wasn't there at all.

So yeah, I wouldn't call this accessible.