I also have my own MTA. No problems with anyone ..... except Microsoft, who (silently) never delivers the mail.

Well, for backups the workaround is a bit easier (as they strictly only ever read files), but still.

Mind, I'm not talking about financial overhead for the company/developer(s), but rather an UX overhead for the user. It often increases friction and might even need education/training to even make use the software it's attached to. It's much like how body armor increases the weight one has to carry and decreases mobility, security has (conceptually) very similar tradeoffs (cognitive instead of physical overhead, and time/interactions/hoops instead of mobility). Likewise, sometimes one might pick a lighter Kevlar suit, whereas othertimes a ceramic plate is appropriate.

Now, body armor is still a very good idea if you're expecting to be engaged in a fight, but I think we can all agree that not everyone on the street in, say, a random village in Austria, needs to wear ceramic plates all the time.

The analogy does have its limits, of course ... for example, one issue with security (which firmly slides it towards erring on the safe side) as compared to warfare is that you generally know if someone shot at you and body armor saved you; with security (and, again, privacy), you often won't even know you needed it even if it helped you. And both share the trait that if you needed it and didn't have it, it's often too late.

Nevertheless, whether worth it or not (and to be clear, I think it's very worth it), I think it's important that people don't forget that this is not free. There's no free lunch --- security & privacy are no exception.

Ultimately, you can have a super-secure system with an explicit trust system that will be too much for most people to use daily; or something simpler (e.g. Signal) that sacrifices a few guarantees to make it easier to use ... but the lower barrier to entry ensuring more people have at least a baseline of security&privacy in their chats.

Both have value and both should exist, but we shouldn't pretend the latter is worthless because there are more secure systems out there.

Also, in Harvard-architecture systems, the constants, being part of the instruction itself, might not even be in the same memory or even address space as variables ([EEP]ROM/Flash vs RAM).

Though yes, two USB ports would definitely work; it's just that the concept might be better served by providing two different connectors (e.g. USB-A & USB-C), as is common nowadays.

Pretty much the only thing I agree with is that computer architecture could use a complete rework (both from a software as well as hardware side, though primarily the former); as well as said rework being basically impossible in practice.

That's how I learned that forest ants, at least the local ones, are incredibly docile. I never got bothered by them.

Mind, I haven't actually used it in anger, as I prefer full file sync vs on-demand.

And I haven't tried it ... unfortunately, the Android app is also ...... buggy.

Most sites didn't need a banner. Even post-GDPR, many use-cases don't need one.

There's also a very good TED talk on this topic from 8 years ago: https://www.youtube.com/watch?v=iFTWM7HV2UI

To be honest, I've been (slowly) working towards my own native GUI library, in C. It's a big undertaking, but one saving grace is that --- at least on my part --- I don't need the full featureset of Qt or similar.

My plan for the portability issue is to flip the script --- make it a native library that can compile to the web (using actual DOM/HTML elements there, not canvas/WebGL/WGPU). And on Android/iOS/etc, I can already do native anyway.

Though I should add that a native look is not a goal in my case (quite a few libraries already go for that, go use those! --- and some, like Windows, don't really have a native look), which also means that I don't have to use native widgets on e.g. Android. The main reason for using DOM on the web is to be able to provide for a more "web-like" experience, to get e.g. text selection working properly, as well as IME, easier debuggability, and accessibility (an explicit goal, though not a short-term one --- in part due to a lack of testers). Though it wouldn't be too much of a stretch to allow either canvas or DOM on the web at that point --- by treating the web the same as a native platform in terms of displaying the widgets.

It's more about native performance, low memory use, and easy integration without a scripting engine inbetween --- with a decent API.

I am a bit on the fence between an immediate-mode vs retained-mode API. I'll probably do a semi-hybrid, where it's immediate-y but with a way to explicitly provide "keys" (kind of like Flutter, I think?).

"Everything is a file" is not a bad abstraction for some things. It feels like Linux went the route of a golden hammer here.

I know it's not the most elegant thing ever, but if it needs to be JSON at the post-signing level, why not just something like `["75cj8hgmRg+v8AQq3OvTDaf8pEWEOelNHP2x99yiu3Y","{\"foo\":\"bar\"}"]`, in other words, encode the JSON being signed as a string. This would then ensure that, even if the "outer" JSON is parsed and re-encoded, the string is unmodified. It'll even survive weird parsing and re-encoding, which the regex replacement option might not (unless it's tolerant of whitespace changes).

(or, for the extra paranoid: encode the latter to base64 first and then as a string, yielding something like `["75cj8hgmRg+v8AQq3OvTDaf8pEWEOelNHP2x99yiu3Y","eyJmb28iOiJiYXIifQ"]` --- this way, it doesn't look like JSON anymore, for any parsers that try to be too smart)

If the outer needs to be an object (as opposed to array), this is also trivially adapted, of course: `{"hmac":"75cj8hgmRg+v8AQq3OvTDaf8pEWEOelNHP2x99yiu3Y","json":"{\"foo\":\"bar\"}"}`.

The big issue for me was the lack of support for nested observables in Svelte, which caused no end of trouble; plus a lack of portals (though maybe the new snippets fix that?).

That's because Microsoft, in their infinite wisdom, decided that a reasonable default was to use a whitelist of allowed senders, blocking everyone else by default.

There is supposedly a process to get that unlocked, but they never replied to my own request ...