13 ms·

> everything really is just a file in Plan 9 That’s... true, but what “file” means in that sentence is a bit tricky. The graphics protocol (or at least I think

> everything really is just a file in Plan 9 That’s... true, but what “file” means in that sentence is a bit tricky. The graphics protocol (or at least I think it was the graphics protocol) requires each command to be written in a single write() call, so a Plan 9 file is neither an array nor a stream of bytes, it includes those implicit boundaries as well. The interface used for impersonating users, IIRC, looks like a kernel-implemented file server but that file server essentially uses its kernel nature by referencing the process that opened the file, so this interface only deserves being called a file if /dev/stdin and /proc/self in classic Unix do as well. I like Plan 9, mind you, but I also think we ought to be careful in treating it as an existence proof for what the pure everything-as-a-file model can do. Even outside of things Plan 9 doesn’t and can’t implement (e.g. modern bandwidth-limited 3D graphics), it also has some hacks in parts it does.

torginus 4y ago
That sounds strange - mind you I'm not familiar with Plan 9, but was the graphics wire protocol text-based? If yes, why wasn't the separation handled by newlines? I'm sure you can encode command separators in binary without the need to rely on write flushes.
- pjmlp 4y ago
  Have some fun reading about Carmack's point of view on Plan 9 graphics. https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4
  - hulitu 4y ago
    > Have some fun reading about Carmack's point of view on Plan 9 graphics. > https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4 > "Computers should feel instant whenever possible. This involves the event path, whatever processing is done, the speed of drawing, and the way the drawing is displayed." This was 27 years ago and still no progress on this field.
    - zozbot234 4y ago
      Wayland and X compositors provide for tear-free video updates, which is what Carmack is talking about in those posts. Further progress will come from lowering the added latency, but that's a very different problem.
      - hedora 4y ago
        He goes on to complain about precursors to compositing. By the late 1990's Linux supported tear free with lower latency than compositors currently support. Anyway, computers have been getting worse at output latency since the mid 1980's. Compositing is just yet another ratcheted performance and usability regression.
        zozbot234 4y ago
        Late-1990s systems supported practically tear-free updates for most practical uses, but AIUI there was not enough memory bandwidth for whole-screen updates to be tear-free, especially at higher resolutions and color depths. This is what Carmack is complaining about here. Even then, there are better and worse ways of coping with limited video memory bandwidth, and what's "best" depends on the given application.
        hedora 4y ago
        According to Carmack (in 1995), tear free compatible PCI bandwidth was just starting to hit the market. This matches my memory of configuring tear free before y2k. I know for sure that I had tear free working at 1600x1200x24 (or 16?) by 2001.
        mananaysiempre 4y ago
        FWIW, the Plan 9 window system is in fact a (very barebones) compositor in modern terms, in that it (unlike classic X and like Wayland) maintains a backbuffer for every (top-level) window instead of communicating “damage” back to applications. That seems to be its very thing—there’s a distinct feeling of “look what computers let us do now” in the papers. I don’t think it knows anything about the widgets inside those windows, either (again unlike classic X and like Wayland). (On the other hand, like classic X and unlike Wayland, it makes the client funnel every drawing operation through the window system.)
- mananaysiempre 4y ago
  Nope, much like 9p itself[1] the /dev/draw protocol[2] is a stream of (simple) binary records. And it’s not that the implicit separation is essential for parsing it, it’s that the servers don’t care to implement the additional buffering necessary in case a single message spans several read()s. (I still don’t remember whether I looked at one of the /dev/draw implementations or at one of the 9p implementations when I was curious about the fiddly buffering question, sorry.) [1] http://man.cat-v.org/plan_9_3rd_ed/5/intro http://man.cat-v.org/plan_9_3rd_ed/5/intro [2] http://man.cat-v.org/plan_9_3rd_ed/3/draw http://man.cat-v.org/plan_9_3rd_ed/3/draw
apitman 4y ago
My naive assumption when looking at the design of Plan 9 from a distance, is that the filesystem could easily become leaky abstraction. Sort of like how we now have USB-C everywhere, but you have to know what kind of cable is actually in the middle in many cases. Maybe it would better to split major feature sets across a few different physical plugs, so you know exactly what you have just by looking at it.

torginus 4y ago

That sounds strange - mind you I'm not familiar with Plan 9, but was the graphics wire protocol text-based? If yes, why wasn't the separation handled by newlines? I'm sure you can encode command separators in binary without the need to rely on write flushes.

pjmlp 4y ago
Have some fun reading about Carmack's point of view on Plan 9 graphics. https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4
- hulitu 4y ago
  > Have some fun reading about Carmack's point of view on Plan 9 graphics. > https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4 > "Computers should feel instant whenever possible. This involves the event path, whatever processing is done, the speed of drawing, and the way the drawing is displayed." This was 27 years ago and still no progress on this field.
  - zozbot234 4y ago
    Wayland and X compositors provide for tear-free video updates, which is what Carmack is talking about in those posts. Further progress will come from lowering the added latency, but that's a very different problem.
    - hedora 4y ago
      He goes on to complain about precursors to compositing. By the late 1990's Linux supported tear free with lower latency than compositors currently support. Anyway, computers have been getting worse at output latency since the mid 1980's. Compositing is just yet another ratcheted performance and usability regression.
      - zozbot234 4y ago
        Late-1990s systems supported practically tear-free updates for most practical uses, but AIUI there was not enough memory bandwidth for whole-screen updates to be tear-free, especially at higher resolutions and color depths. This is what Carmack is complaining about here. Even then, there are better and worse ways of coping with limited video memory bandwidth, and what's "best" depends on the given application.
        hedora 4y ago
        According to Carmack (in 1995), tear free compatible PCI bandwidth was just starting to hit the market. This matches my memory of configuring tear free before y2k. I know for sure that I had tear free working at 1600x1200x24 (or 16?) by 2001.
      - mananaysiempre 4y ago
        FWIW, the Plan 9 window system is in fact a (very barebones) compositor in modern terms, in that it (unlike classic X and like Wayland) maintains a backbuffer for every (top-level) window instead of communicating “damage” back to applications. That seems to be its very thing—there’s a distinct feeling of “look what computers let us do now” in the papers. I don’t think it knows anything about the widgets inside those windows, either (again unlike classic X and like Wayland). (On the other hand, like classic X and unlike Wayland, it makes the client funnel every drawing operation through the window system.)
mananaysiempre 4y ago
Nope, much like 9p itself[1] the /dev/draw protocol[2] is a stream of (simple) binary records. And it’s not that the implicit separation is essential for parsing it, it’s that the servers don’t care to implement the additional buffering necessary in case a single message spans several read()s. (I still don’t remember whether I looked at one of the /dev/draw implementations or at one of the 9p implementations when I was curious about the fiddly buffering question, sorry.) [1] http://man.cat-v.org/plan_9_3rd_ed/5/intro http://man.cat-v.org/plan_9_3rd_ed/5/intro [2] http://man.cat-v.org/plan_9_3rd_ed/3/draw http://man.cat-v.org/plan_9_3rd_ed/3/draw

apitman 4y ago

My naive assumption when looking at the design of Plan 9 from a distance, is that the filesystem could easily become leaky abstraction. Sort of like how we now have USB-C everywhere, but you have to know what kind of cable is actually in the middle in many cases. Maybe it would better to split major feature sets across a few different physical plugs, so you know exactly what you have just by looking at it.