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.
Reaching the Unix philosophy's logical extreme with WebAssembly
131–140 of 142 posts
Re: Reaching the Unix philosophy's logical extreme with WebAssembly
#132Earlier 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?
Re: Reaching the Unix philosophy's logical extreme with WebAssembly
#133Earlier 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?
Re: Reaching the Unix philosophy's logical extreme with WebAssembly
#134Earlier 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.
> [...]
> 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
#135The 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)
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
#136Earlier 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.
Re: Reaching the Unix philosophy's logical extreme with WebAssembly
#137Earlier 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…
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
#138Earlier 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 :)
Re: Reaching the Unix philosophy's logical extreme with WebAssembly
#139Earlier 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
Re: Reaching the Unix philosophy's logical extreme with WebAssembly
#140Earlier 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.