Live data from Hacker News

Reaching the Unix philosophy's logical extreme with WebAssembly

xeiaso.net

91–100 of 142 posts

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#91
post #85
post #81

Earlier quoted context omitted.

That's a very twisted definition of Unix. 1) This is not done by every tool. Instead, there are tools built for specific parsing purposes, and each tool is only in charge of interpreting its command-line arguments or, optionally, stdin in some suitable way. Tools are agnostic of the output of previous tools, and only care about processing data that makes sense to them. It's the task of the user to ensure this data is…

What if the format chosen 40+ years ago wasn't arcane, and arguably you could avoid the legitimate mess of parsing poorly structured data for 40+ years?

Plain is arcane?

Mime type: text/arcane

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#92
post #85
post #81

Earlier quoted context omitted.

That's a very twisted definition of Unix. 1) This is not done by every tool. Instead, there are tools built for specific parsing purposes, and each tool is only in charge of interpreting its command-line arguments or, optionally, stdin in some suitable way. Tools are agnostic of the output of previous tools, and only care about processing data that makes sense to them. It's the task of the user to ensure this data is…

What if the format chosen 40+ years ago wasn't arcane, and arguably you could avoid the legitimate mess of parsing poorly structured data for 40+ years?

And what format would that have been? It would have predated XML and JSON, so it must've been a bespoke format created for this purpose.

Whatever it were, it would need updating, which means all tools would need to be updated to support the changes, while maintaining backwards compatibility. This is a mess in practice, and probably only acceptable to a single project or organization that maintains all tools, but it's not something that allows an open ecosystem to grow.

It's naive to think that a modern solution can "fix" this apparent problem. New shells and environments can be created that try to address it, but their future is uncertain. Meanwhile, the fact that Unix still exists today in many variations is a testament that those early decisions were largely correct.

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#93
post #83

Earlier quoted context omitted.

What's the argument that AND is less complex than NAND? It's true that NAND has completeness and AND doesn't, but so what? What you can build from something is not a measure of how complex it is. You measure complexity in terms of what it takes to describe something.

It seems naively obvious to me that a(b(x)) is more complex than b(x). Practically tautology.

You have to justify why you've chosen the particular starting point. NAND isn't defined as being "first you do AND, and then you negate it". It's defined like this:

    +---+---+-------+
    | a | b | a ↑ b |
    +---+---+-------+
    | 0 | 0 |   1   |
    +---+---+-------+
    | 0 | 1 |   1   |
    +---+---+-------+
    | 1 | 0 |   1   |
    +---+---+-------+
    | 1 | 1 |   0   |
    +---+---+-------+
AND is defined like this:

    +---+---+-------+
    | a | b | a & b |
    +---+---+-------+
    | 0 | 0 |   0   |
    +---+---+-------+
    | 0 | 1 |   0   |
    +---+---+-------+
    | 1 | 0 |   0   |
    +---+---+-------+
    | 1 | 1 |   1   |
    +---+---+-------+
You may notice that they are almost exactly the same.

> It seems naively obvious to me that a(b(x)) is more complex than b(x).

This is just obvious gibberish; if you define b(x, y) = x & y and a(x) = ~x, then you can say "I think a(b(x, y)) looks more complex than b(x, y)", but how do you respond to "when c(x, y) = x ↑ y, I think c(c(x,y), c(x,y)) looks more complex than c(x,y)"? The two claims can't both be true!

Everything, no matter how simple, can be described as the end of an arbitrarily long chain of functions. So what?

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#94
post #88
post #68

Earlier quoted context omitted.

Java (like mentioned in the article) does the same though IIRC Inferno OS is like Java in this regard. How will WASM change what Java has already done? Why would I compile Rust to WASM when I can compile Rust natively to any number of platforms? And use FFI? I think WASM, while nice, doesn't bring much new to the table. It's been hyped for years, and I still only see it used here and there very sparingly.

This is how. The installed size of OpenJDK 17 JRE on my machine is 186MB, according to the package manager. I suspect that the WASM VM embedded in the program demonstrated in the blog post is 1.5 to 2 orders of magnitude smaller.

I'm no expert but the JVM is very modular these days and just the minimal modules also give you an order or two smaller runtimes. My guess is a set of minimal OpenJDK modules will be on the same order as a WASM VM. Would be curious to hear from someone more in the know

Looking a the JRE size is a bit misleading bc it's been sort of deprecated. You're not really supposed to make Uberjars to run on a JRE anymore but are expected to bundle with the JVM modules you need. It can make very small bundles..

But naturally an Uberjars would be smaller. I think small executables are possible but are also just a nongoal now in the JVM world. Meanwhile they're obviously still very relevant in the webspace and hence WASM

you're not really gunna send JVM bundles dynamically over the wire.

I do sort of agree with the parent that while the goals are slightly different it feels like WASM reinvented the JVM without really bringing any huge improvement (while you loose several decades of libraries)

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#95
post #92
post #85

Earlier quoted context omitted.

What if the format chosen 40+ years ago wasn't arcane, and arguably you could avoid the legitimate mess of parsing poorly structured data for 40+ years?

And what format would that have been? It would have predated XML and JSON, so it must've been a bespoke format created for this purpose. Whatever it were, it would need updating, which means all tools would need to be updated to support the changes, while maintaining backwards compatibility. This is a mess in practice, and probably only acceptable to a single project or organization that maintains all tools, but it's…

The downsides you cite are even worse for the unstructured data, it's an even bigger mess in practice with poor "current compatibility"

And the fallacy of alive=right is also worse than "naivety" since it prolongs the pain for a few more decades longer than necessary (it's a big part of the reason why all those much better tools face uncertain future)

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#96
post #84

Earlier quoted context omitted.

This is of course not the purpose of your post, but since you're interested in this topic, I wanted to mention that you can now create memory-backed files on linux using the memfd_create syscall without using any filesystem (nor unlink) and you can also execute them without the /proc/self/fd trick by using the execveat syscall. In glibc, there is fexecve which uses execveat or falls back to the /proc trick on older k…

Looks like memfd_create is from Linux 3.17 (2014), which was after I wrote the function. I sort of miss the days when simple stuff was hard.

>I sort of miss the days when simple stuff was hard.

what? what's the point?

for me it's the most annoying thing when the simple stuff is hard because why would it be?

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#97
post #75

I thought the Unix philosophy was do one thing well: https://wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_... how is running anything through a giant virtual machine (web browser) anywhere close to that? the browser is the monolith people. using a web browser to deliver an application is, always has been, and always will be the slowest, and most bloated way to do that. the benefit of course is, that the result…

It's probably referring to the Markdown to HTML translator library, an example of how Wasm enables Unix-style composition.

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#98
post #69

Earlier quoted context omitted.

The current reference (only?) implementation of jpeg-xl is a c++ library, which I do not entirely trust to run in process in my go web server, and yet I would like to process images. Conveniently, the build system for jpeg-xl seems to support building to wasm, so if I can jam that into my process, I'd be a lot happier.

Ah, now THAT's an interesting aspect I wish someone would have brought up over the years I've seen WASM. I guess WASM as a target and embeddable VM really helps with security in those cases. Couldn't we also do the same though with any number of arch/vm pairings? I guess what WASM brings to the table is a compile target friendly enough for things like C and C++, i.e. low level code, and a reasonable VM implementation…

Library sandboxing is a well known application of WASM. Search for the WebAssembly Component Model. There's also a way to use WASM to sandbox a C library - search for RLBox.

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#99
post #84

Earlier quoted context omitted.

Looks like memfd_create is from Linux 3.17 (2014), which was after I wrote the function. I sort of miss the days when simple stuff was hard.

>I sort of miss the days when simple stuff was hard. what? what's the point? for me it's the most annoying thing when the simple stuff is hard because why would it be?

Hacking is the art doing things with software that don't seem possible.

In other words, it's just fun :)

Re: Reaching the Unix philosophy's logical extreme with WebAssembly

#100
post #80
post #69

Earlier quoted context omitted.

Ah, now THAT's an interesting aspect I wish someone would have brought up over the years I've seen WASM. I guess WASM as a target and embeddable VM really helps with security in those cases. Couldn't we also do the same though with any number of arch/vm pairings? I guess what WASM brings to the table is a compile target friendly enough for things like C and C++, i.e. low level code, and a reasonable VM implementation…

I don't know the current state, but the JVM had historically quite bad isolation. Javascript's isolation in browsers is actually pretty good. It's possible that the existing non-browser WASI implementations are terrible at isolation; since they exist specifically to allow access system resources they might be bad at denying access to system resources...

The JVM’s security in the Applet days were bad due to actually being capable at many functionality — it is trivial to properly sandbox something that has zero capabilities.

There is nothing inherent in the JVM that would make it less secure, we just realized in the meanwhile that blacklisting is not the way ahead, but whitelisting is.

Post reply on HN