Parodper
Parodper on Hacker News
Anybody would be able to make their own JVM, thought (they might need to call it the ECMA Virtual Machine). And seeing how the WHATGC works, I don't think they might be able to keep any sort of control.
> My company might have 4 domains on different TLDs
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).
> Not trying to throw shade, but I think the number of devs wishing that the web ended up with XHTML + JVM
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.
In another world, Netscape is able to reach a deal with Sun, and the JVM gets integrated into Mozilla. New browsers just need to implement the JVM and bind it with their XHTML's rendering engine DOM API.
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.
JPEGXL is a single format, but when converting from other formats you can do it lossless or lossy, and optionally make it progressive.
> EU anti-AI laws
God I wish.
Doing engineering ≠ being an engineer.
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.
> please tell me ONE app for Android other than Google Messages I can use to send and receive RCS, it surely won't be problem since it's international standard same as SMS, so there must be plenty apps available...
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...
The EU has their own Mastodon instance, but unless you want to have responses (even if the official instance doesn't show them), it's cheaper to run a static news aggregator.
It would be nice, but it seems most people don't care about this.
He isn't. He has a bachelor in economics and physics.
We're just reinventing moderated Usenet newsgroups.
People seemed to like it being stuck in the 1980s.
RCS is an international standard. Google only adds their client (and running the service if your mobile provider doesn't).
Don't know what EU apps are you talking about, but yes, mobile apps need Google services. Web interfaces don't.
GNU/Linux[1] seems to support it. Windows probably does too.
[1] Tested on KDE Wayland and Xfce X11.
SMS made you pay by character. RCS is the current free alternative.
Ctrl/Shift+Insert are the actual standard, from IBM's CUA.
Very interesting, thanks. I like they even admit their own bias, that the main reason was that they didn't want another's protocol; except for the word alignment, all the other issues are solvable.
> 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».