Hacker News Reader

Defeats the point of WASI—WASIX seems not to be capabilities based

WASIX seems to be basically POSIX for WASM (POSIX/WASIX). It is probably an explicit design goal to be able to run POSIX-compliant programs on it.

The fact that POSIX is 1970s legacy, rusted beyond salvaging and an extremely poor fit for modern system designs and expectations is another problem.

What would be a modern alternative?

The only other equivalent API in broad use today that I'm aware of would be the Kernel32.dll subset of Win32 [1]. Not that it's perfect (so much accumulated cruft) or what I would call modern (still has a lot of ambient authority baked-in) by any means, but the important parts are mostly handle-based (unlike PID-based POSIX process management functions for example).

I happen to like the design of the syscall layer of Fuchsia's Zircon kernel [2], but it's not a full substitute for POSIX (notably, file and network I/O are built as userspace features of top of IPC channels, they are not kernel concepts).

[1] https://www.geoffchappell.com/studies/windows/win32/kernel32...

[2] https://fuchsia.dev/fuchsia-src/reference/syscalls

I do not see a problem in that. You can always restrict the capability by not exporting a particular API function, or just by returning ENOPERM. It's the job of an operating environment to decide which permissions are available.

Reply on news.ycombinator.com