Today, the Wayland enthusiasts like to talk about how they are modernizing the Linux graphics stack. But Linux is a Unix, and in Unix, everything is meant to be a file. So any Wayland evangelists out there, tell us: where in the file system can I find the files describing a window on the screen under the Wayland protocol? What file holds the coordinates of the window, its place in the Z-order, its colour depth, its contents?
As far as I’m aware nobody has even considered extending the file metaphor to the graphics stack, and it sounds a bit ridiculous to me.
It also reminds me of this talk that suggests maybe trying to express everything as a file might not be the best idea…
/dev/fb0 is the framebuffer. So yes, you can feed data into the filesystem and you’ll see it on your display.
For Unixoids, being a file does not mean that this data is stored on a hard disk, but that all data, processes and hardware are accessible with the same toolkit. /dev/fb0, for instance, is part of the file-like interface of your graphics card.
/dev/fb is mostly one thing: deprecated. Also it is not really a interface of your graphics card, it is a legacy way kindly still provided for pushing fullscreen pixels to your monitor in an unaccelerated fashion for things that have not made it to kms drm (which at this point is pretty much merely the console emulation on the TTYs). It is not an interface to the graphics card, because it doesn’t provide any capabilities a graphics card has (like shaders etc). In fact for just pushing pixels you can leave any graphics card completely out of your computer if you connect your screen by other means (think stuff like SPI which is common in embedded devices; you can find many examples of such drivers in the kernel source at drivers/gpu/drm/tiny ).
It’s nonsense. The author arbitrarily decides on some expression of the windowing model in terms of files. OK cool. Every author of a system that uses files decides how to represent their data. E.g. how many files to use, sockets, what data to flow through each and what format that data should be represented in. Like why not go to the authors of Btrfs and argue why the data format /dev/btrfs-control is the way it is why it’s a single file instead of 5. It’s an arbitrary decision. When not used for storing data files in POSIX-like OSes are a type of IPC mechanism. How many channels that IPC needs and what data flows over these channels is an arbitrary decision by the authors on one or both sides of that IPC. The OS provides the IPC mechanism. The software that uses it creates some abstraction on top of it which doesn’t have to conform to any lower level OS models. Could we model Postgres tables and rows like files in a dir structure. Sure. There are pros and cons to using that model. Might not be great for terabyte scale db performance.
Dennis Ritchie and Ken Thompson […] ignored what the industry was doing, went back to their original ideas, and kept working on refining them. The result is the next step in the development of Unix
Plan 9 is clearly what the article is talking about. Odd that they don’t name it.
They do, if you consider that this article doesn’t stand alone at all and read the blurb at the very bottom in italics acknowledging that it’s part of a bigger series
At the end there’s a little jab towards Wayland:
As far as I’m aware nobody has even considered extending the file metaphor to the graphics stack, and it sounds a bit ridiculous to me.
It also reminds me of this talk that suggests maybe trying to express everything as a file might not be the best idea…
I have a 144Hz display. I’m sure my system would love every frame hitting the filesystem layer.
/dev/fb0 is the framebuffer. So yes, you can feed data into the filesystem and you’ll see it on your display.
For Unixoids, being a file does not mean that this data is stored on a hard disk, but that all data, processes and hardware are accessible with the same toolkit. /dev/fb0, for instance, is part of the file-like interface of your graphics card.
/dev/fb is mostly one thing: deprecated. Also it is not really a interface of your graphics card, it is a legacy way kindly still provided for pushing fullscreen pixels to your monitor in an unaccelerated fashion for things that have not made it to kms drm (which at this point is pretty much merely the console emulation on the TTYs). It is not an interface to the graphics card, because it doesn’t provide any capabilities a graphics card has (like shaders etc). In fact for just pushing pixels you can leave any graphics card completely out of your computer if you connect your screen by other means (think stuff like SPI which is common in embedded devices; you can find many examples of such drivers in the kernel source at drivers/gpu/drm/tiny ).
It’s nonsense. The author arbitrarily decides on some expression of the windowing model in terms of files. OK cool. Every author of a system that uses files decides how to represent their data. E.g. how many files to use, sockets, what data to flow through each and what format that data should be represented in. Like why not go to the authors of Btrfs and argue why the data format /dev/btrfs-control is the way it is why it’s a single file instead of 5. It’s an arbitrary decision. When not used for storing data files in POSIX-like OSes are a type of IPC mechanism. How many channels that IPC needs and what data flows over these channels is an arbitrary decision by the authors on one or both sides of that IPC. The OS provides the IPC mechanism. The software that uses it creates some abstraction on top of it which doesn’t have to conform to any lower level OS models. Could we model Postgres tables and rows like files in a dir structure. Sure. There are pros and cons to using that model. Might not be great for terabyte scale db performance.
Wow that’s hilariously idiotic.
Plan9, more or less, does its graphics through filesystems.
Plan 9 is clearly what the article is talking about. Odd that they don’t name it.
They do, if you consider that this article doesn’t stand alone at all and read the blurb at the very bottom in italics acknowledging that it’s part of a bigger series
deleted by creator
deleted by creator
permission denied: /dev/display/3/349/1045sudo !!
This was a great talk (video you linked, not the article). Wonder what Linus would say about C being a wrong thing today.
Here is an alternative Piped link(s):
this talk
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.