You can take a look at what Switzerland is about to do:

https://www.homburger.ch/de/insights/swiss-voters-approve-ne...!

> Once issued, the e-ID will be stored in a secure digital wallet application on the user’s smartphone or other compatible device.

That sounds like Apple & Google-blessed Android only, open source gadgets and non-Microsoft desktops not supported. Estonia at least used smart cards where a reader can be plugged into just about anything.

Would be very tough to implement in the US, as proposing any sort of "national ID" is pretty much a nonstarter, at least up to this point.

States could do it, and maybe agree on some protocols so that things like privacy-preserving "age verification" could be done.

Maybe the feds could push it like they did with speed limits: make federal funding contingent upon adopting e-ID. Would still get a lot of pushback.

The problem with e-ID is its focused on identity verification, not just age verification and that's where the problem lies.

We still need the ability to be psuedoanonymous online. We should be able to verify age without divulging any identifying information to the service requesting age verification.

An e-ID registry could work on a sort of public/private key system so long as the services requesting informatino from the registry only receives a yes or no of "is this person old enough" and no further information.

If an e-ID can vouch you are citizen number #3223423, it should be able to use the same crypto to vouch that your birth date predates a threshold, without revealing anything else. It's more a question of requirements gathering & UX (and political will).

It's a problem for you and me, but a feature for those pushing for it.

I'm obviously not going to show my id to Zuckerberg's website or any porn sites, casinos because I don't trust those bastards. They're also not the police, so they lack the proper autoritah to request my an id.

I think the point of the comment you are answering to is that in Switzerland, they are building a system where you can prove your age without telling who you are to the website, and without telling which website you visit to your government.

The government might not know which website exactly, but the fact that you are looking to verify your age is in itself a datum that you might not want the government to know. "Palata was either looking at porn or buying drugs in January 2026" is probably not something you want the government to know, even if the specifics are obscure.

Unless your e-ID app automatically requests 20 age verification tokens for everybody, whether they use them or not.

How are you going to farm the UUID for each user? Or are the IDs sequential?

C uses `|` for bitwise OR and `||` for logical OR. I'm assuming this inherited the same operator paradigm since it compiles to C.

Before being used by everyone else Git was not used by everyone else.

Fossil is used for one of the most deployed embeddable database. Not sure we can call it "irrelevant".

I get what your message is saying, however words have meaning, and being hyperbolic does not help anyone when we try to bring nuances.

> Mercurial was a better DVCS [...]

Totally agree.

I think the massive difference is the number of people using the project vs. contributing to the project. How many people contribute to SQLite vs the Linux kernel. AFAIK not many for the former.

SQLite doesn't accept external contributions, and the dev team recently consisted of three people.

In other words: its use of any specific VCS is pretty much irrelevant.

To me this just shows that the Github issue concept is significantly flowed.

Open source is weird. It’s like everyone on the entire planet is your coworker and you have no real say in their hiring, on boarding, or firing.

I can see why there is trepidation and guard rails around giving them the key to your office planner.

I don’t see how this demonstrates that at all. Issues as a concept seems sound. There is a huge variety of social structures that are built around issues which might make it a good or bad fit

Can you tell me what was the context that lead you to create this?

Unrelated JSON experience:

I worked on a serializer which save/load json files as well as binary file (using a common interface).

From my own use case I found JSON to be restrictive for no benefit (because I don't use it in a Javascript ecosystem)

So I change the json format into something way more lax (optional comma, optional colon, optional quotes, multi line string, comments).

I wish we would stop pretending JSON to be a good human-readable format outside of where it make sense and we would have a standard alternative for those non-json-centric case.

I know a lot of format already exists but none really took off so far.

Basically, for better or worse JSON is here to stay. It exists in all standard libraries. Swift's codec system revolves around it (it only handles types that are compatible with JSON).

It sucks, but we're stuck with JSON. So the idea here is to make it suck a little less by stopping all this insane text processing for data that never ever meets a human directly.

The progression I envisage is:

1. Dev reaches for JSON because it's easy and ubiquitous.

2. Dev switches to BONJSON because it's more efficient and requires no changes to their code other than changing the codec library.

3. Dev switches to a sane format after the complexity of their app reaches a certain level where a substantial code change is warranted.

Thanks for the details!

I'm in the JS ecosystem pretty regularly and "restrictive with no benefit" is the right description. I use JSON5 now when I have to, which greatly reduces the restrictions. I already have a build step so throwing in a JSON5 -> JSON converter is negligible.

As for FracturedJson, it looks great. The basic problem statement of "either minified and unreadable or prettified and verbose" isn't one I had put my finger on before, but now that it's been said I can't unsee it.

Have you heard of EDN? It's mostly used in Clojure and ClojureScript, as it is to Clojure what JSON is to JS.

If you need custom data types, you can use tagged elements, but that requires you to have functions registered to convert the data type to/from representable values (often strings).

It natively supports quite a bit more than JSON does, without writing custom data readers/writers.

https://github.com/edn-format/edn

Another thing to possibly consider would be ASN.1 (you can also use the nonstandard extensions that I made up, called ASN.1X, if you want some of the additional types I included such as a key/value list). (You are not required to implement or use all of the types or other features of ASN.1 in your programs; only use the parts that you use for your specific application.) Unlike EDN, ASN.1 has a proper byte string type, it is not limited to Unicode, it has a clearly defined canonical form (DER, which is probably the best format (and is the format used by X.509 certificates); BER is too messy), etc. DER is a binary format (and the consistent framing of different types in DER makes it easier to implement and work with than the formats that use inconsistent framing, although that also makes it less compact); I made up a text format called TER, which is intended to be converted to DER.

I haven't, but it's an interesting format for sure.

I've found a more comprehensive documentation here. [1]

At first glance, I would say it's a bit more complex that it should for a "human readable" format.

[1] https://edn-format.dev/

That's a very weird comment, your spreading your knowledge and not really addresse what could have been changed in the article.

If I follow your comment, you mean that he could have use a non-static global variable instead and avoid mentioning "static" keyword afterward?

Oh! Thanks, I was not being as concrete as I imagined. Sorry.

Yes, the `static` can simply be dropped, it does no additional work for a single-file snippet like this.

I tried diving into Compiler Explorer to examine this, and it actually produces slightly different code for the with/without `static` cases, but it was confusing to deeply understand quickly enough to use the output here. Sorry.

I see exactly the same assembly from x86-64 GCC 15.2 with -O2 the first example in the article both as is and without `static`, which makes sense. The two do differ if you add -fPIC, as though you’re compiling a dynamic library, and do not add -fvisibility=hidden at the same time, but that’s because Linux dynamic linking is badly designed.

TU-level concepts (mostly) dissolve during the linking stage. You need to compile with -c to generate an object file in order to see the distinction.

Also, the difference manifests in the symbols table, not the assembly.

To clarify, I was talking about Compiler Explorer-cleaned disassembly, same as the comment I was replying to.

Interesting take.

In a naive way, when rich entities are interested in a limited resource it's basically over.

Somehow I can see a parallel with the housing crisis where the price go higher and higher.

I can't see both of them ending anytime soon unless there is a major paradigm shift in our life.

What's causing the housing crisis?

Corruption, Zoning, Investment housing

I'm not looking for a job but your various job offers are appealing!

The idea of someone rating me, or rating someone else makes me anxious.

I'm not sure it would be better than just reporting people with undesired behavior.

> The idea of someone rating me, or rating someone else makes me anxious.

But not enough to avoid, as you’re here.

I think it’s more anonymized like “did you enjoy the game with this team (1-5)”

> It claims WebGPU is limited to Browsers. It is, not. WebGPU is available as both a C++ (Dawn) and a Rust (WGPU) library. Both run on Windows, MacOS, Linux, iOS, and Android. It is arguably the most cross platform library. Tons of native projects using both libraries.

I feel like it's important to mention that WebGPU is a unified API on top of whatever is native to the machine (DirectX, Vulkan or Metal).