Should a microkernel implement eBPF and WASM, or, for the same reasons that justify a microkernel should eBPF and most other things be confined or relegated or segregated in userspace; in terms of microkernel goals like separation of concerns and least privilege and then performance?
Linux containers have process isolation features that userspace sandboxes like bubblewrap and runtimes don't.
Flatpaks bypass selinux and apparmor policies and run unconfined (on DAC but not MAC systems) because the path to the executable in the flatpaks differs from the system policy for */s?bin/* and so wouldn't be relabeled with the necessary extended filesystem attributes even on `restorecon /` (which runs on reboot if /.autorelabel exists).
Thus, e.g. Firefox from a signed package in a container on the host, and Firefox from a package on the host are more process-isolated than Firefox in a Flatpak or from a curl'ed statically-linked binary because one couldn't figure out the build system.
Container-selinux, Kata containers, and GVisor further secure containers without requiring the RAM necessary for full VM virtualization with Xen or Qemu; and that is possible because of container interface standards.
Linux machines run ELF binaries, which could include WASM instructions
> What's new with Wasker is, Wasker generates an OS-independent ELF file where WASI calls from Wasm applications remain unresolved.*
> This unresolved feature allows Wasker's output ELF file to be linked with WASI implementations provided by various operating systems, enabling each OS to execute Wasm applications.
> Wasker empowers your favorite OS to serve as a Wasm runtime!
Why shouldn't we container2wasm everything? Because (rootless) Linux containers better isolate the workload than any current WASM runtime in userspace.
Have you compared OpenAI to the current leader of the free world?
>The Globalist Wall Street Journal has no idea what they are doing or saying. They are owned by the polluted thinking of the European Union, which was formed for the primary purpose of “screwing” the United States of America... (Truth Social today)
This doesn't really work for projects that want to be closed source, as they can just not publish the source. After the 10 years, people can copy the binary, but that doesn't really give you a whole lot of benefit.
And if a project does want to be open source eventually, they can already license their code that way.
Couple it with a generalized right to repair: source code is what's needed in order to be able to repair the software that you use. If beyond the support period or the copyright term (whichever is least), the materials needed to repair the product must be released.
I assume GP meant that a lot of compilers also interpret and interpreters also compile.
For compilers, constant folding is a pretty obvious optimization. Instead of compiling constant expressions, like 1+2, to code that evaluates those expressions, the compiler can already evaluate it itself and just produce the final result, in this case 3.
Then, some language features require compilers to perform some interpretation, either explicitly like C++'s constexpr, or implicitly, like type checking.
Likewise, interpreters can do some compilation. You already mentioned bytecode. Producing the bytecode is a form of compilation. Incidentally, you can skip the bytecode and interpret a program by, for example, walking its abstract syntax tree.
Also, compilers don't necessarily create binaries that are immediately runnable. Java's compiler, for example, produces JVM bytecode, which requires a JVM to be run. And TypeScript's compiler outputs JavaScript.
Programming languages mostly occupy a 4-dimensional space at runtime. These axes are actually a bit more complicated than just a line:
* The first axis is static vs dynamic types. Java is mostly statically-typed (though casting remains common and generics have some awkward spots); Python is entirely dynamically-typed at runtime (external static type-checkers do not affect this).
* The second axis is AOT vs JIT. Java has two phases - a trivial AOT bytecode compilation, then an incredibly advanced non-cached runtime native JIT (as opposed to the shitty tracing JIT that dynamically-typed languages have to settle for); Python traditionally has an automatically-cached barely-AOT bytecode compiler but nothing else (it has been making steps toward runtime JIT stuff, but poor decisions elsewhere limit the effectiveness).
* The third axis is indirect vs inlined objects. Java and Python both force all objects to be indirect, though they differ in terms of primitives. Java has been trying to add support for value types for decades, but the implementation is badly designed; this is one place where C# is a clear winner. Java can sometimes inline stack-local objects though.
* The fourth axis is deterministic memory management vs garbage collection. Java and Python both have GC, though in practice Python is semi-deterministic, and the language has a somewhat easier way to make it more deterministic (`with`, though it is subject to unfixable race conditions)
The easy definition is that an interpreter takes somethings and runs/executes it.
A compiler takes the same thing, but produces an intermediate form (byte code, machine code, another languages sometimes called "transpilar"). That you can then pass through an interpreter of sorts.
There is no difference between Java and JVM, and Python and the Python Virtual Machine, or even a C compiler targeting x86 and a x86 CPU. One might call some byte code, and the other machine code .. they do the same thing.
While an interpreter can do optimizations, they do not produce "byte code" -- by that time they are compilers!
As for the comparison with the JVM .. compare to a compiler that produces x86 code, it cannot be run without an x86 machine. You need a machine to run something, be it virtual or not.
Can't you just use a semicolon to do the same in English? And even if not, just because an idea is split over several sentences doesn't mean you can't communicate it. That's what paragraphs are for.
You can, and probably should. Texts like Kant are borderline incomprehensible even to native Germans and seem to only serve the author's need for displaying their intelligence. The ideas they are conveying are not that complex. Relativistic quantum theory or string theory can be expressed in English (plus math, while it's not like math wouldn't be needed in German) just fine, so I really don't understand where these supposed limitations of English are.
It's not that English can't express some things at all, but that there are words in German that aren't neatly translated to a English word. Schadenfreude is one German word that's been brought over by a certain writer. It's the joy of seeing someone else's misfortune. That's six-words to express what German can do in one, and for a poet or a wordsmith, that just won't do. If you're dubbing a German TV show, how're you going to fit those six words when the a character yells that one word. Smush it in and hope for the best? So it's still translatable into English, it's just clumsy. As are all translations, really. So German isn't special in that regard, plenty of languages share that quality. And no, the Inuit don not have 37 words for snow.
Torschlusspanik is the fear that time is running out for eg a career change. Weltschmerz is a deep melancholic sadness about the state of the world or life. Hopefully someone who actually speaks German can give greater nuance to those definitions and maybe some other examples.
I think english has the blueprint to do the same. Worldpain
damagejoyness
careerangst
etc
In german there are those wordwords but those are mostly already there and germans are not using this feature regularly to make up new words to describe things. But yes can be fun if one is doing it.
The Fun of doing it
->i have fundoing
as someone pointed out, there are words that describe certain things way better in english then in german. anxiety and hypocrite is one of those that pop in my mind. There are translation for those but they arent used in the german day to day vocabulary
Actually, Schadenfreude can be neatly translated into a single English word: schadenfreude. English just adopts words that it lacks and (from a German perspective) it's not really special in that regard: We, too, have adopted words, like photography (spelled Fotographie in German) or folklore (original spelling retained) from English.
yeah i am with you. Sometimes they overdoe it for no reason. I also prefer english to learn sth. Only because it is more straightforward and simpler to communicate. I love it
English just adopts all the good German words. Every time I, a native German speaker, have struggled to express something in English it was either because my personal vocabulary was lacking or because of societal differences, never because English is somehow inferior.
Same as any other kernel—the runtime is just a userspace program.
> Can a microkernel do eBPF?
If it implements it, why not?