I'm a happy smolmachines user. It has some rough edges but it works really great. I haven't tested microsandbox and boxlite, and maybe they consume OCI images too, but smolmachines is a winner because of that.
I wonder if it's usual for other professions/fields to have this tendency to create laws/aphorisms so ingrained. I'm biased as software engineer but it seems to me that is more common in computer science than others.
> We understand your concerns and truly appreciate your suggestions. As previously mentioned, this is not something that is enforced by the reference implementation — these are simply recommendations, not requirements, for any wallet implementer. That said, we recognize that this is a sensitive topic, and we may need to revisit it, even at the level of recommendations.
> The README files for both the iOS and Android Wallets have been updated to mention only OWASP MASVS compliance, without referencing any specific APIs.
I understand their position, but I also get the concern, especially around existing implementations like the Italian app. I think it's mostly that they have different priorities than ensuring that the reference implementation is a perfect guideline for member states.
This looks like a good vector for a European Citizen Initiative around removing all technological dependency on non-EU providers.
Having explored that approach (†), I can tell that generating Go assembly is harder than it seems.
†: I've tried to transpile Rust code through WASM into Go assembly, and I've also explored how to inject trampolines into Go binaries (which involves generating Go assembly too).
It makes no sense. eIDAS 2.0 specs don't require specific hardware [0]. They basically store verifiable credentials [1] and any other cryptographically signed attestations.
This feels like laziness from German implementers, as they don't want to (quoting the spec literally) "implement a mechanism allowing the User to verify the authenticity of the Wallet Unit".
Just a heads-up: I changed one of my repos URL [0], released as v0 at the moment, and bumped to v1 alongside the URL change.
Go treats v0 and v1 as equivalent, so it tries to bump from v0.x to v1.0.0 keeping the old URL. This causes errors because the `go.mod` URL isn't the same.
If you want to change the URL and you haven't reached v1, you should do it as a v2 instead, skipping v1.
It's a similar experience in Go, specially because imports are done by URL and major versions higher than v1.x are forced to change it to add a suffix `/vN` at the end.
Although this is true, any large ecosystem will have some popular packages not holding to semver properly. Also, the biggest downside is when your `>=v1` depends - indirectly usually - on a `v0` dependency which is allowed to do breaking changes.
That's an unfair characterisation of EU. Hungary and Slovakia didn't join under their current fascist governments. They weren't fascist when they joined in 2004.
Kicking them out isn't easy unless there is unanimity. Unfortunately EU requires this kind of quorum for the big decisions, which is kind of a safeguard to precisely avoid going full fascist for the whole EU due to a minority of countries.
The structure reads as LLM written. I don't mind this unless the content is utterly wrong. I was actually learning about cache-friendly data structures and I'm really interested in that cache-friendly Robin Hood hashing but now I worry it's a hallucination.
I'm linking my keytrace.dev: did:plc:aj77r5uwt72o6oimdjfplqoz
Socials: - github.com/darccio - linkedin.com/in/darccio - bsky.app/profile/dario.cat
Interests: Open Source, Entrepreneurship, Privacy, Social Impact