27 karma · joined February 22, 2020
Your CA would have a root cert per TLD. Alternatively, we get rid of non-cc TLD (and leave ccTLD only for truly geography-bound organizations, like governments).
I don't necessarily like the JVM, it's just the most popular system-independent bytecode virtual machine (and historically plausible). It's a lot easier to built a bytecode interpreter than a full language. As mentioned elsethread, Scheme would have been even better, with an even smaller base.
XHTML, however, full in. Namespaces and syntax checking alone would have been worth it.
> Never mind that when Microsoft licensed Java from Sun for IE3 and IE4, Sun sued Microsoft.
Microsoft was in their peak EEE era, no wonder Sun didn't want to do anything with that.
> Those of us old enough to remember the web with plugins, don't miss plugins.
That's why I didn't mention plugins, browsers would have a JVM engine, instead of a JS one.
It would have been the application platform people ask for, with a separate namespace for application-related tags so you can just switch them up with the OS's native UI controls.
Instead of that, we got Yet Another VM, WebAssembly.
God I wish.
Am I a doctor because I took my temperature and found I had a fever? Am I a lawyer if I represent myself in court?
At least where I'm from, you need to be licensed to practice engineering.
Nice red herring. The number of implementations is irrelevant here, although Wikipedia says Samsung had one too.
Here's the standard, try Ctrl+F "Google": https://www.gsma.com/solutions-and-impact/technologies/netwo...
It would be nice, but it seems most people don't care about this.
Don't know what EU apps are you talking about, but yes, mobile apps need Google services. Web interfaces don't.
[1] Tested on KDE Wayland and Xfce X11.
We're slowly reinventing OSI, one step at a time: OSI had multiple sessions per transport connection (QUIC), 20 byte addresses (IPv6) and a directory system with public-key infrastructure (DANE, vCard, SSHFP, etc).
It's a shame TUBA (CLNP + TCP) failed.
The fact that both Apple's and CP/M codes came out roughly at the same time, both on microcomputers, shows that it was probably just a design decision.
I probably should have replied under the other comment. I was also referring to your
> No, I didn't - I asked how sum types were supposed to work in an era of 64KB memory systems.
But context got lost between replies.
> that's why C is what it is
C famously had a big redesign in 1990. The language of today isn't the same K&R printed.
The next level (110x xxxx) would give you 8MiB strings, which are going to be fine for most things.
And which modern C compiler fits into 64KB? Even TCC needs 100KB. But that's beside the point. No machine of the last 36 (I'll push my chances, 40) years needs to fit a compiler in 64KB.
Last time I had to handle CSV files in bash, I converted them internally to RS and FS.
[1] https://community.letsencrypt.org/t/sub-ca-with-wildcard-cer...