5 ms·

> I cherish Microsoft for its work in Windows, it is the only mainstream OS that can save us from UNIX monoculture. I tend to simplistically reduce this choice

> I cherish Microsoft for its work in Windows, it is the only mainstream OS that can save us from UNIX monoculture. I tend to simplistically reduce this choice between: - Everything is a file (the unix way); and - Everything is an object (the windows way) Both choices have the potential for great results. In practice, however, the documentation and composability in the everything is a file paradigm has shown to produce better results. Unix ecosystems are more alive; it is easier to replace system parts and create operating systems out of your own choice of replaceable layers. The monolithic nature of Windows is a reflection on the failure of the object oriented approach to operating system interfaces. Mind you, I don't think it is an intrinsic fault. It may be that it's a fault of this implementation of an OO operating system. This is the main reason I dislike what the Gnome folks are pushing down Linux's throat. The Gnome way is, today, at odds with the Unix way.

taeric 12y ago
That is more easily reduced to - You can do anything you want with anything (objects) - You have a discrete set of file operations. (files) That is, the "object" way sounds more promising and unlimited. I think, in practice, it is that unlimited nature that actually hurts. Though, I hate the "paradox of choice" and I think I am saying it reduces to that. :(
- jude- 12y ago
  I don't think it's the paradox of choice at work. I think instead that the set of file operations happens to permit arbitrary interaction with an object. Specifically, file operations already represent: * data accesses (read), * data mutations (write, trunc), * metadata accesses (readdir, closedir, stat, statfs, readlink), * metadata mutations (creat, mkdir, link (and symlink), unlink, rmdir), * interaction contexts (open, close, opendir, closedir), * namespaces (mount, umount). I would argue that any object (OS-level or otherwise) can be represented as a filesystem. The advantage of doing so is that the client interface stays the same in all cases. I think it's this constraint on the interface that makes file operations and filesystems so appealing in the long run.
  - pjmlp 12y ago
    Now try to do real time 3D graphics with those operations. Plan9 window manager is not an example of performance.
    - jude- 12y ago
      Depending on how it's implemented, there's no real reason why it couldn't be done. For example, I could create SceneGraph_fs, which exposed the scene graph of objects as a directory hierarchy. The filesystem's toplevel directory would be organized with a /scenegraph/ directory for the scenegraph, /lights/ for the light models, and /tmp/ for a scratch space for constructing objects and staging them to be added. Each node in the scene graph would be represented by a directory under /scenegraph/ which contained one file for each distinct chunk of data the graphics engine would need to know (like a position matrix, an orientation matrix, a mesh model, a texture map, etc., depending on whether or not the directory represented a model or a transformation). For data in /scenegraph/, SceneGraph_fs would accept well-formatted writes to a node's files as a means to update the node in the scene--for example, to translate the node, you would write a new matrix to the object's positional matrix file (the write() would return EPERM if the matrix was malformatted). To create or modify an object atomically, you could describe it under /tmp/ in SceneGraph_fs, and rename() it into place. You could manage lights and lighting data in the same way. Of course, the graphics card interfacing happens in filesystem implementation. But, the application interacts with the scenegraph as a filesystem, not as an object.
  - taeric 12y ago
    Right. My point is that you have to make your operations fit within that language. As opposed to the object metaphor, where you get to define the language however you want. Very similar to the REST versus SOAP/whatever paradigm. Neither one should be more capable than the other. In fact, REST should be the more restrictive choice. Right?
pjmlp 12y ago
> Both choices have the potential for great results. In practice, however, the documentation and composability in the everything is a file paradigm has shown to produce better results. Until you start doing IPC between processes, IOCTL, heavy graphics programming and there goes the abstraction.
- mwcampbell 12y ago
  What makes IPC better on Windows? Are you suggesting that COM method calls across processes is a good thing?
  - pjmlp 12y ago
    The point being that not everything is actually a file, requiring other set of operations.
fragmede 12y ago
That's an over-simplification, as when you get down to it, there are plenty of things that don't use the file API on UNIX, or at least have convenient wrappers so you're not blindly calling 'ioctl' left and right. I'm thinking specifically of the socket API for bind/connect/accept, the inotify interface, with inotify_* functions, the (less commonly used these days) serial port API, with the tc* and cf* functions. > It may be that it's a fault of this implementation of an OO operating system. I'm not convinced it's just this implementation. When everything's an object, there's additional overhead as a programmer trying to use the API. File based API - Open a file using the same 'open' call you've always used, and then call 'read' or 'write' (or even 'ioctl') on the file descriptor. Call 'close' when done. There may be multiple files you need to access to get the particular behavior you want. Object based API - Browse around the docs until you find that particular subsystem's API. Read a bunch. Finally instantiate the object you need. Set all of the objects various properties. Call CreateObject(object, options). Wait, go back and create a options object. Set all of the properties on that object as well. Try that until you figure out you needed to call CreateObjectEx instead. Hit your head on the desk for a couple hours until you figure out that you also need to call RunObject, and that one of the parameters on the options object was set wrong. As a programmer, the file-based API is just a layer of indirection to make things easier, and shouldn't be considered a limiting factor. Then again, there's this article about Event Tracing on Windows, that makes me think it's just this iteration of OO-based operating system, and a better designed API would do us all a favor. http://mollyrocket.com/casey/stream_0029.html http://mollyrocket.com/casey/stream_0029.html
ahomescu1 12y ago
> - Everything is an object (the windows way) I wouldn't say there is a "Windows way", considering that current Windows is actually a system composed of several different layered components: 1) The NT kernel (which is pretty nicely designed) its own ideas of what "objects" are and all the ObXXX functions. 2) Win32 which is a horrible mess from the Windows 3.1 days and maybe earlier. 3) COM and flavors, which actually came later with its own brand of objects. 4) The .NET framework. It doesn't seem to me that "Windows objects" are really unified in spirit and design across all these components (not to mention that Win32 isn't object-oriented at all).
dschiptsov 12y ago
Everything is a file on a FS - so-called permanent storage. Everything is an object - where? in memory. That's the source of all problems, ORMs, ORBs, persistence layers, etc.

taeric 12y ago

That is more easily reduced to - You can do anything you want with anything (objects) - You have a discrete set of file operations. (files) That is, the "object" way sounds more promising and unlimited. I think, in practice, it is that unlimited nature that actually hurts. Though, I hate the "paradox of choice" and I think I am saying it reduces to that. :(

jude- 12y ago
I don't think it's the paradox of choice at work. I think instead that the set of file operations happens to permit arbitrary interaction with an object. Specifically, file operations already represent: * data accesses (read), * data mutations (write, trunc), * metadata accesses (readdir, closedir, stat, statfs, readlink), * metadata mutations (creat, mkdir, link (and symlink), unlink, rmdir), * interaction contexts (open, close, opendir, closedir), * namespaces (mount, umount). I would argue that any object (OS-level or otherwise) can be represented as a filesystem. The advantage of doing so is that the client interface stays the same in all cases. I think it's this constraint on the interface that makes file operations and filesystems so appealing in the long run.
- pjmlp 12y ago
  Now try to do real time 3D graphics with those operations. Plan9 window manager is not an example of performance.
  - jude- 12y ago
    Depending on how it's implemented, there's no real reason why it couldn't be done. For example, I could create SceneGraph_fs, which exposed the scene graph of objects as a directory hierarchy. The filesystem's toplevel directory would be organized with a /scenegraph/ directory for the scenegraph, /lights/ for the light models, and /tmp/ for a scratch space for constructing objects and staging them to be added. Each node in the scene graph would be represented by a directory under /scenegraph/ which contained one file for each distinct chunk of data the graphics engine would need to know (like a position matrix, an orientation matrix, a mesh model, a texture map, etc., depending on whether or not the directory represented a model or a transformation). For data in /scenegraph/, SceneGraph_fs would accept well-formatted writes to a node's files as a means to update the node in the scene--for example, to translate the node, you would write a new matrix to the object's positional matrix file (the write() would return EPERM if the matrix was malformatted). To create or modify an object atomically, you could describe it under /tmp/ in SceneGraph_fs, and rename() it into place. You could manage lights and lighting data in the same way. Of course, the graphics card interfacing happens in filesystem implementation. But, the application interacts with the scenegraph as a filesystem, not as an object.
- taeric 12y ago
  Right. My point is that you have to make your operations fit within that language. As opposed to the object metaphor, where you get to define the language however you want. Very similar to the REST versus SOAP/whatever paradigm. Neither one should be more capable than the other. In fact, REST should be the more restrictive choice. Right?

pjmlp 12y ago

> Both choices have the potential for great results. In practice, however, the documentation and composability in the everything is a file paradigm has shown to produce better results. Until you start doing IPC between processes, IOCTL, heavy graphics programming and there goes the abstraction.

mwcampbell 12y ago
What makes IPC better on Windows? Are you suggesting that COM method calls across processes is a good thing?
- pjmlp 12y ago
  The point being that not everything is actually a file, requiring other set of operations.

fragmede 12y ago

That's an over-simplification, as when you get down to it, there are plenty of things that don't use the file API on UNIX, or at least have convenient wrappers so you're not blindly calling 'ioctl' left and right. I'm thinking specifically of the socket API for bind/connect/accept, the inotify interface, with inotify_* functions, the (less commonly used these days) serial port API, with the tc* and cf* functions. > It may be that it's a fault of this implementation of an OO operating system. I'm not convinced it's just this implementation. When everything's an object, there's additional overhead as a programmer trying to use the API. File based API - Open a file using the same 'open' call you've always used, and then call 'read' or 'write' (or even 'ioctl') on the file descriptor. Call 'close' when done. There may be multiple files you need to access to get the particular behavior you want. Object based API - Browse around the docs until you find that particular subsystem's API. Read a bunch. Finally instantiate the object you need. Set all of the objects various properties. Call CreateObject(object, options). Wait, go back and create a options object. Set all of the properties on that object as well. Try that until you figure out you needed to call CreateObjectEx instead. Hit your head on the desk for a couple hours until you figure out that you also need to call RunObject, and that one of the parameters on the options object was set wrong. As a programmer, the file-based API is just a layer of indirection to make things easier, and shouldn't be considered a limiting factor. Then again, there's this article about Event Tracing on Windows, that makes me think it's just this iteration of OO-based operating system, and a better designed API would do us all a favor. http://mollyrocket.com/casey/stream_0029.html http://mollyrocket.com/casey/stream_0029.html

ahomescu1 12y ago

> - Everything is an object (the windows way) I wouldn't say there is a "Windows way", considering that current Windows is actually a system composed of several different layered components: 1) The NT kernel (which is pretty nicely designed) its own ideas of what "objects" are and all the ObXXX functions. 2) Win32 which is a horrible mess from the Windows 3.1 days and maybe earlier. 3) COM and flavors, which actually came later with its own brand of objects. 4) The .NET framework. It doesn't seem to me that "Windows objects" are really unified in spirit and design across all these components (not to mention that Win32 isn't object-oriented at all).

dschiptsov 12y ago

Everything is a file on a FS - so-called permanent storage. Everything is an object - where? in memory. That's the source of all problems, ORMs, ORBs, persistence layers, etc.