HN user
Doing this brings you close to OSI, which famously failed by being overcomplicated.
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.
Apparently it's from 1901 (Murray code) or 1932 (ITA2).
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.
The thread talked about sum types, which apparently appeared on ALGOL; although I don't know how much memory did an ALGOL compiler need.
That's famously a single-pass compiler. Rust is famously unable to compile in a single pass.
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.
You could start the encoding with two bytes, so that if the most significant bit of the first byte is 0, the length is that byte plus another. That gives you 32KiB strings with just a byte more. Short strings might suffer, but I think the overhead is reasonable.
The next level (110x xxxx) would give you 8MiB strings, which are going to be fine for most things.
Borland's PASCAL did it on the IBM PC.
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.
You could do 0xffff as a special case, and put another length+string/pointer to after the 255th byte.
Yes, if you're talking to a terminal. But an in-disk file doesn't have a carriage to return.
LF makes the most sense, but they're all fine for text files. The issue is that CSV isn't text.
Last time I had to handle CSV files in bash, I converted them internally to RS and FS.
UNIX's LF precedes them by at least half a decade, probably more.
I also started going down this rabbit hole when I wanted my homelab to just work in any device, and for advanced use cases Let's Encrypt isn't enough. I tried long and hard to get a sub-CA certificate, but apparently that's in the realm of «if you need to ask, you can't afford it».
Unfortunately the CA/B Forum has high requirements for constrained subordinate CA certificates[1], which to me sounds a lot like regulatory capture.
[1] https://community.letsencrypt.org/t/sub-ca-with-wildcard-cer...
Try to read less tabloids.
And if they don't, DNS is already a database. You could just query domains to check their certificates. People running recursive DNS servers could double-check certificates.
I'm the first to admit ICANN has issues, but US government control doesn't seem to be one of them.
Pretty well, in my experience.
What other choices are there?
An international body might work, or just move the issue one step back.
You obviously don't know how DNSSEC works. The DNS root of trust is ICANN, not a government.
every government will absolutely double-issue certificates to police, secret service and friends of goverment, and no one will have any recourse.
Countries already have CA that issue certificates with more legal force than a handwritten signature. I can open a bank account, pay my taxes and sign up to all government services. But I can't use them for a webpage.
With DANE (or other country-issued certificates)
DANE isn't a country-issued certificate. It's a scheme where you store your public keys on DNS records. Of course, now we have the issue that DNSSEC (signed DNS records) isn't widespread and the whole issue with DNS registries.
We could, and should, switch to DANE. Or else, switch to how X.509 was supposed to be used, with each country running a CA for their nationals.
It's funny to see that the issues with X.509 certificates, are being solved by what X.509 was intended to be used for: a directory system. It's DNS instead of X.500, but it's a start.
Allowing user to just generate a domain for themselves
That's limited mostly by policy[1], the current PKI environment already allows delegating CA for a single domain.
[1] https://community.letsencrypt.org/t/sub-ca-with-wildcard-cer...
According to the court, the real reason is because ECH would make it impossible to block through DPI.
ISP are blocking, because of a district judge's ruling.
The money one honestly sounds like a bug.
The one thing I also wish would be better is discoverability... Just the other day I logged in into an irc server (LiberaChat?) but just didn't know where to go from there.. I got into my country's room, but it was very quiet.
Check out netsplit.de. It has a list of channels sorted by popularity.