4 ms·

I think that "everything is a file" is superseded by "everything is a reference". Memory for example isn't a file. Neither is a GPU. I believe that Windows' HA

I think that "everything is a file" is superseded by "everything is a reference". Memory for example isn't a file. Neither is a GPU. I believe that Windows' HANDLE is closer to the correct abstraction.

partycoder 8y ago
But some things can be abstracted as files, and that's where Windows interoperability (and as a consequence, automation) falls short.
- anticensor 8y ago
  Windows has NPFS for them. Windows API is not just object system.
enriquto 8y ago
> Memory for example isn't a file. from proc(5) : /proc/[pid]/mem This file can be used to access the pages of a process's memory through open(2), read(2), and lseek(2)
- adamnemecek 8y ago
  I'm aware but I'm just not convinced the analogy fits.
  - enriquto 8y ago
    It's not an analogy, it's a file interface to memory.
  - rosser 8y ago
    The point isn't that everything is a file; it's that you can treat everything like a file. Of course the abstraction maps varying degrees of well, but it also simplifies the hell out of the lion's share of the ways we interact with computers, and serves as a foundation for the rest.
    - adamnemecek 8y ago
      Right I get it. I’m saying there’s a better mapping.
      - rosser 8y ago
        Than what, an entry in some table in the kernel that you can use to read bytes from the thing it represents and/or write bytes to it? That's what a "file" is in *nix. The on-disk notion of a file sits atop layers of that abstraction. It doesn't, for example, go away when you `rm` it. An entry in a table does, but if some other process had that (disk) file open at the time, its data is still there, readable — and recoverable — through the former file's entry under that pid's /proc/$pid/fd/.
vbezhenar 8y ago
Abstraction presumes some common operations, otherwise it's not abstraction, it's just some opaque bytes. You can open/read/write/close files. May be seek. What common operations can you do with some random windows HANDLEs? AFAIK you can't even close that handle, you need to call specific function.
- deathanatos 8y ago
  Typically, I've found, the common operation is not so much the file/HANDLE itself, as that the file/HANDLE can generate operations that you need to wait on. But select() set the stage by waiting on the file descriptor, and poll/epoll mostly follow suit. You register interest in events on an FD. (Instead of, say, starting an operation and saying "tell me when this operation finishes"; e.g., "futures" as exposed by a number of languages. Aside from waiting, I'd say passing/referring to the objects being operated on is also a commonality. Passing a FD to a child process, for example, or giving it (the object, be that a file/pipe/socket/timer/process/etc.) a name in the FS s.t. other things can refer to them by name. (I personally wish though that fork()/exec() had forced you to specify exactly the set of objects (files/etc.) for the child to avoid the entire multithreading/close-on-exec/atomic flag setting hell that exists today.) I don't know that read/write are actually abstract at the level of a "file descriptor" though. Eventfds and timerfds both support them, but it feels forced. Pipes are one-way, so one of read/write don't make sense, and seek on pipe doesn't either. I think some file descriptors (child classes of a generic "object"/FD/HANDLE, such as files) support read/write, but not necessarily all FDs support read/write/seek.
  - vbezhenar 8y ago
    My point is that HANDLE is too general abstraction. Can you wait on HANDLE that's result from CreateHeap call? Can you wait on HANDLE that's result from CreateWindow call (HWND is defined as HANDLE)? What's common between file, window and heap object?
    - bhk 8y ago
      Closing/destroying and granting (to another process) are generally applicable to about any resource held by a process. UNIXes, by contrast, expose multiple "close" system calls for non-file things, and have a largely incomplete mishmash of ways to share non-file things.
emersion 8y ago
>Neither is a GPU. https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Render_nodes https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Rende...
- adamnemecek 8y ago
  You are missing my point.

partycoder 8y ago

But some things can be abstracted as files, and that's where Windows interoperability (and as a consequence, automation) falls short.

anticensor 8y ago
Windows has NPFS for them. Windows API is not just object system.

enriquto 8y ago

> Memory for example isn't a file. from proc(5) : /proc/[pid]/mem This file can be used to access the pages of a process's memory through open(2), read(2), and lseek(2)

adamnemecek 8y ago
I'm aware but I'm just not convinced the analogy fits.
- enriquto 8y ago
  It's not an analogy, it's a file interface to memory.
- rosser 8y ago
  The point isn't that everything is a file; it's that you can treat everything like a file. Of course the abstraction maps varying degrees of well, but it also simplifies the hell out of the lion's share of the ways we interact with computers, and serves as a foundation for the rest.
  - adamnemecek 8y ago
    Right I get it. I’m saying there’s a better mapping.
    - rosser 8y ago
      Than what, an entry in some table in the kernel that you can use to read bytes from the thing it represents and/or write bytes to it? That's what a "file" is in *nix. The on-disk notion of a file sits atop layers of that abstraction. It doesn't, for example, go away when you `rm` it. An entry in a table does, but if some other process had that (disk) file open at the time, its data is still there, readable — and recoverable — through the former file's entry under that pid's /proc/$pid/fd/.

vbezhenar 8y ago

Abstraction presumes some common operations, otherwise it's not abstraction, it's just some opaque bytes. You can open/read/write/close files. May be seek. What common operations can you do with some random windows HANDLEs? AFAIK you can't even close that handle, you need to call specific function.

deathanatos 8y ago
Typically, I've found, the common operation is not so much the file/HANDLE itself, as that the file/HANDLE can generate operations that you need to wait on. But select() set the stage by waiting on the file descriptor, and poll/epoll mostly follow suit. You register interest in events on an FD. (Instead of, say, starting an operation and saying "tell me when this operation finishes"; e.g., "futures" as exposed by a number of languages. Aside from waiting, I'd say passing/referring to the objects being operated on is also a commonality. Passing a FD to a child process, for example, or giving it (the object, be that a file/pipe/socket/timer/process/etc.) a name in the FS s.t. other things can refer to them by name. (I personally wish though that fork()/exec() had forced you to specify exactly the set of objects (files/etc.) for the child to avoid the entire multithreading/close-on-exec/atomic flag setting hell that exists today.) I don't know that read/write are actually abstract at the level of a "file descriptor" though. Eventfds and timerfds both support them, but it feels forced. Pipes are one-way, so one of read/write don't make sense, and seek on pipe doesn't either. I think some file descriptors (child classes of a generic "object"/FD/HANDLE, such as files) support read/write, but not necessarily all FDs support read/write/seek.
- vbezhenar 8y ago
  My point is that HANDLE is too general abstraction. Can you wait on HANDLE that's result from CreateHeap call? Can you wait on HANDLE that's result from CreateWindow call (HWND is defined as HANDLE)? What's common between file, window and heap object?
  - bhk 8y ago
    Closing/destroying and granting (to another process) are generally applicable to about any resource held by a process. UNIXes, by contrast, expose multiple "close" system calls for non-file things, and have a largely incomplete mishmash of ways to share non-file things.

emersion 8y ago

>Neither is a GPU. https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Render_nodes https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Rende...

adamnemecek 8y ago
You are missing my point.