Live data from Hacker News

Reaching the Unix philosophy's logical extreme with WebAssembly

xeiaso.net

131–140 of 142 posts

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

#131
post #72

Earlier quoted context omitted.

Sorry, I will try to make it more clear. NAND is more complex than AND, in the sense that it is more expressive than AND (having functional completeness which AND does not). Similarly, it can be built from other less complex operators (AND and NAND). If you're taking "One thing" to the extreme, in terms of the granularity or complexity of that "one thing", NAND is not as granular or simple as AND - and therefore isn'…

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.

[deleted]

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

#132
post #119
post #116

Earlier quoted context omitted.

Oof. My Firefox browser on Ubuntu crashed and all my open VSCodium's went along with it. Happened when loading for a second time. First time worked.

What's the connection between your Firefox and VSCodium? Or did your system run out of virtual memory and start killing things at random?

No connection that I can think of. Might be the memory. 16 GB physical. But I didn't have a lot open (browser + 3 vscodium) and it happened in a heartbeat after clicking in the browser.

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

#133

Earlier quoted context omitted.

The pipeline pattern is still very useful, even if it isn't the most important or most well known tenant (I am not sure of this, but maybe you are right). Still, of course it is not perfect. "Everything is a file" has its benefits too, but also is not perfect either. However, even if not all of {Read,Write,Seek,Truncate,etc} are implemented for all objects, some of them will be implemented, e.g. a TCP socket or chara…

Sounds pretty cool. Which hardware platforms does it target (even if they are virtual)? Is there a way to run it?

Currently the implementation is not written yet (and it is supposed to be possible that multiple implementations can be made, including ones that can run on other operating systems as well as by itself); currently they are the design ideas. I have written some stuff about it on comp.os.misc, although a few of the ideas have changed a bit since then and I have another message with some additional ideas, which I have not sent yet. Hopefully if other people also will comment then we can make the improvement, and then write the actual specifications (there are both low-level and high-level specifications) and can be made. I have essentially the ideas of the working of most of the low-level stuff already, and once it can be made the actual specification then the kernel could be implemented even though the high-level system might not be made yet.

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

#134
post #105
post #23

Earlier quoted context omitted.

There are two dimensions to "everything is a file". The first is the concept of a hierarchical filesystem namespace. The second is the notion that read and write can be used as a universal interface to any resource from the perspective of the runtime environment (e.g. kernel). People focus myopically on the first aspect, but it's really the second that is the most important and most enduring. The word "file" is ambig…

> People focus myopically on the first aspect, but it's really the second that is the most important and most enduring But something you can read and write to is not called a file, it is called a stream. It is no accident that Linux differentiates between “files” that you can write to at arbitrary places, or ones that are append-only.

> Certain files do not refer to disk files at all, but to I/O devices. [...] An effort is made to make these special files behave exactly the same way that ordinary disk files behave. This means that programs generally do not need to know whether they are reading or writing on some device or on a disk file.

> [...]

> Files are uniformly regarded as consisting of a stream of bytes; the system makes no assumptions as to their contents.

> [...]

> There is not distinction between "random" and sequential I/O. The read and write calls are sequential in that, for example, if you read 100 bytes from a file, the next read call will return bytes starting just after the last one read. It is however possible to move the read pointer around (by means of a "seek" call) so as to read the file in any order.

Source: https://www.bell-labs.com/usr/dmr/www/notes.html

Though the abstraction is incomplete, the core concept in Unix is that "files" are opaque streams of bytes. Ancillary functions (e.g. seek, ioctl) are then layered atop the basic API to deal with files of different types as required.

Consider that before Unix most file APIs were record or block oriented. Unix unified the I/O model behind a single "file" abstraction--a stream of bytes. Unix stretched the term "file" to encompass a broader range of I/O tasks, but in turn also changed the treatment of traditional disk files in a way that made them look more like non-disk file I/O. This abstraction couldn't completely hide how I/O was serviced on the other side, but one can't criticize "everything is a file" without understanding the context of the time; nor can one full appreciate the value-add.

Also, something I hadn't notice before is how DMR emphasizes the synchronous nature of the API. Apparently many I/O APIs back then were asynchronous. Unix made the I/O model synchronous, but made it easy to create and juggle multiple processes so that you could implement various asynchronous models if you wanted. IOW, they flipped the default case. With the contemporary concern with intra-process I/O concurrency, that's an evolution we seem to be recapitulating.

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

#135
post #43

The talk was amusing but much less interesting than it could be. Yes, we have adapters and shims and they make interfacing easier, sometimes. I guess after all these years of waiting for WebAssembly to actually be useful (as in: I can write apps as easily as I can on desktop, with similar performance, but with the safety guarantees of a web sandbox), I finally realized what I wanted: web pages that are backed by virt…

I think that this was what Alan Kay was saying when he said that web pages should be objects (where he had previously said that objects are virtual machines all the way down)

Huh. https://en.wikipedia.org/wiki/Croquet_Project

When I say VM, I mean, "VMWare-style VMs" not "VMs that run a language the same way on multiple platforms".

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

#136
post #129
post #102

Earlier quoted context omitted.

Nobody has a good IPC/RPC-based abstraction set right now. And everybody is kind of struggling with that. Look at the latest Microsoft thing about embedding Python in Excel. They're going the wrong direction. What everybody wants is to be able to drive Excel from Python aka an API that people could hook into. Even WASM is kind of ... weak ... because it has to deal with the lowest common denominator--a web page with…

And thus AREXX rises from the ashes of the corpse of Amiga.

Please clarify for those of us who aren't Amiga aficionados.

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

#137
post #134
post #105

Earlier quoted context omitted.

> People focus myopically on the first aspect, but it's really the second that is the most important and most enduring But something you can read and write to is not called a file, it is called a stream. It is no accident that Linux differentiates between “files” that you can write to at arbitrary places, or ones that are append-only.

> Certain files do not refer to disk files at all, but to I/O devices. [...] An effort is made to make these special files behave exactly the same way that ordinary disk files behave. This means that programs generally do not need to know whether they are reading or writing on some device or on a disk file. > [...] > Files are uniformly regarded as consisting of a stream of bytes; the system makes no assumptions as t…

So when you "mount" a device like a USB-drive, what happens? A single "file" (the USB drive) becomes multiple smaller files?

Is there also a reverse operation, turning multiple small files into a single bigger file?

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

#138

Earlier quoted context omitted.

>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 :)

Imo hacking is different thing

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

#139

Earlier quoted context omitted.

Hacking is the art doing things with software that don't seem possible. In other words, it's just fun :)

Imo hacking is different thing

You're entitled to your opinion, of course - language is subjective afterall - but the meaning of the word "hacking" as I'm using it comes from the MIT hacking community as described by Richard Stallman [0] [1].

[0] https://youtu.be/D7PVrK58iGw?t=58

[1] https://stallman.org/articles/on-hacking.html

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

#140
post #136
post #129

Earlier quoted context omitted.

And thus AREXX rises from the ashes of the corpse of Amiga.

Please clarify for those of us who aren't Amiga aficionados.

REXX itself was a language made by IBM used for all manner of purposes, AREXX was a slightly simplified take on that for the Amiga. A number of programs on the Amiga would have an AREXX "port" which provided a set of APIs which could be called from AREXX to control aspects of the application. This meant that AREXX was often used to control multiple applications or chain them together (a bit like a batch control language used to achieve an objective by having each of the programs perform part of some greater whole).
Post reply on HN