341–350 of 371 posts
Earlier quoted context omitted.
Basically CORBA with RMI and .NET Remoting.
Yep, once something failed nothing with any similarity to it will ever go anywhere
Earlier quoted context omitted.
As long as, people use their computers as PC towers from 2000, without hardware video decoding, sleep states, modern UEFI features. There is naturally the version that works, keeping the Linux kernel, and replacing the userland with managed language frameworks, I have heard they are making a huge success in mobile devices and throwaway laptops.
All these work well on our devices, old and new. Y2K wants its talking points back.
Earlier quoted context omitted.
As things are, all browser developers - including Firefox! - disable hardware acceleration on most video cards in their browsers on Linux because it is "too unstable". The result is a 20% difference in battery life between Linux and Windows if you mostly do browsing.
Never experienced this myself, and I have used discrete and integrated graphics cards from a variety of manufacturers. Meanwhile on Windows I am not exaggerating when I say that every computer I have owned and every peripheral device I have ever used has had serious issues. Wireless headphones randomly disconnect, microphones require frequent unplug-replug cycles, rebooting is often required, reinstalling is common.…
Earlier quoted context omitted.
IronPython alongside C++/CLI on the CLR, everything compiled down to MSIL bytecodes.
I could be wrong, but I can't find anything about how to include your C dependencies with IronPython when you compile. Instead I see that IronPython has limited compatibility with the Python ecosystem because of Python libraries using C. Contrasted with WASM where you can write in any language and bring the ecosystem with you, since it all compiles down.
Earlier quoted context omitted.
ActiveX had this sorted out 25 years ago. Code signing with different levels available for access outside the sandbox controllable by the user.
And a nice centralized authority that judges the trustworthiness of a given application by staring at a binary extensively?
"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…
> That's what killed the Java write-once, run-anywhere promise. I write Java software on Intel and deploy to an arm device. The promise seems to work for me.
Meanwhile you won't have much luck running Eclipse or any other large Java program on your custom OS or hardware platform if you just port the JRE.
Earlier quoted context omitted.
Almost all modern Java frameworks specifically target Docker containers in the cloud.
To be fair it is in part due to containers being a really nice way to deploy languages with fat-runtimes.
You can make the same argument for any compiled language if you call QEMU your runtime.
And this isn't just theoretical. Games written in compiled languages know to bundle all their dependencies. Games written in Java often expect you to have a JRE. And more often than not "a JRE" means the official Sun JRE (maybe even a specific version range) because too many Java applications use non-portable interfaces.
Earlier quoted context omitted.
> the downside is that it means you have to re-invent the world to work with this flavor of runtime. This is at least one of the reasons we've been building thin kernel interfaces for Wasm. We've built two now, one for the Linux syscall interface ( https://github.com/arjunr2/WALI ) and one for Zephyr. A preliminary paper we wrote a year or so back is here ( https://arxiv.org/abs/2312.03858 ), and we have a new one co…
> One of the advantages of a thin kernel interface to something like Linux is really low overhead and low implementation burden for Wasm engines. Such a low burden that both Google (gVisor) and Microsoft (WLS1) failed at it!
Earlier quoted context omitted.
To be fair it is in part due to containers being a really nice way to deploy languages with fat-runtimes.
Those fat runtimes are part of the portability lie. Runs everywere ... where the runtime is installed. You can make the same argument for any compiled language if you call QEMU your runtime. And this isn't just theoretical. Games written in compiled languages know to bundle all their dependencies. Games written in Java often expect you to have a JRE. And more often than not "a JRE" means the official Sun JRE (maybe e…
Only if you ship a QEMU-compatible image, and I don't think anyone does. The usability and integration with the host system is too poor.
> Games written in compiled languages know to bundle all their dependencies. Games written in Java often expect you to have a JRE.
You can't get away from having to have some interface between the host system and the program, but so far the JVM is the least bad one. When laptops started shipping with ARM processors, both docker images and games that had compiled in their dependencies broke, while programs that were shipped as JARs worked fine.
Earlier quoted context omitted.
> One of the advantages of a thin kernel interface to something like Linux is really low overhead and low implementation burden for Wasm engines. Such a low burden that both Google (gVisor) and Microsoft (WLS1) failed at it!
A thin kernel interface isn't a reimplementation of a kernel. The WALI implementation in WAMR is ~2000 lines of C, most of which is just pass-through system calls.