The point hinted at in the title is not part of this article. This is an overview of various versions and branches of UNIX, and nothing more.
At the end there’s a little jab towards Wayland:
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…
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 ).
Wow that’s hilariously idiotic.
$ echo ffdd66 > /dev/display/3/349/1045
permission denied: /dev/display/3/349/1045sudo !!
deleted by creator
Plan9, more or less, does its graphics through filesystems.
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.
This was a great talk (video you linked, not the article). Wonder what Linus would say about C being a wrong thing today.
thank you
What an odd article. First, the author goes to great lengths to assert that “Linux IS UNIX” with pretty circumstantial evidence at best. Then, I guess to hide the fact the his point has not proved, he goes through the history of UNIX, I guess to re-enforce that Linux is just a small piece of the UNIX universe? Then, he chastises people working on Linux for not staying true to the UNIX philosophy and original design principles.
Questions like “are you sure this is a UNIX tool?” do not land with the weight he hopes as the answer os almost certainly “No. This is not a “UNIX” tool. It is not trying to be. Linux is not UNIX.”
The article seems to be mostly a complaint that Linux is not staying true enough to UNIX. The author does not really establish why that is a problem though.
There is an implication I guess that the point of POSIX and then we UNIX certification was to bring compatibility to the universe of diverging and incompatible Unices. While I agree that fragmentation works against commercial success, this is not a very strong point. Not only was the UNIX universe ( with its coherent design philosophy and open specifications ) completely dominated by Windows in the market but they were also completely displaced by Linux ( without the UNIX certification ).
Big companies found in Linux a platform that they could collaborate on. In practice, Linux is less fragmented and more ubiquitous than UNiX ever was before Linux. Critically, Linux has been able to evolve beyond the UNIX certification.
Linux does follow standards. There is POSIX of course. There is the LSB. There is freedesktop.org. There are others. There is also only one kernel.
Linux remains too fragmented on the desktop to displace Windows. To address that, a standard set of Linux standards are emerging: including Wayland, pipewire, and Flatpak.
Wayland is an evolution of the Linux desktop. It is a standard. There is a specification. There is a lot of collaboration around its evolution.
As for “other” systems, I would argue that compatibility with Linux will be more useful to them than compatibility with “UNIX”. I would expect other systems to adopt Wayland in time. It is already supported on systems like Haiku. FreeBSD is working on it as well.
This is my real problem with this (and also broadly pointing the finger to the “Unix philosophy” whenever a project like systemd or Wayland exists, ignoring that the large, complex, multifaceted, and monolithic Linux kernel itself flies in the face of that philosophy). Linux may have originally been built to be Unix-like but has become its own thing that shares a few similarities with Unix.
Blah blah blah blah blah…
tl;dr the author never actually gets to the point stated in the title about what the “problem” is with the direction of Linux and/or how knowing the history of UNIX would allegedly solve this. The author mainly goes off on a tangent listing out every UNIX and POSIX system in their history of UNIX.
If I understand correctly, the author sort of backs into the argument that, because certain Chinese distros like Huawei EulerOS and Inspur K/UX were UNIX-certified by Open Group, Linux therefore is a UNIX and not merely UNIX-like. The author seems to be indirectly implying that all of Linux therefore needs to be made fully UNIX-compatible at a native level and not just via translation layers.
Towards the end, the author points out that Wayland doesn’t comply with UNIX principles because the graphics stack does not follow the “everything is a file” principle, despite previously admitting that basically no graphics stack, like X11 or MacOS’s graphics stack, has ever done this.
Help me out if I am missing something, but all of this fails to articulate why any of this is a “problem” which will lead to some kind of dead-end for Linux or why making all parts of Linux UNIX-compatible would be helpful or preferable. The author seems to assume out of hand that making systems UNIX-compatible is an end unto itself.
Seriously, I don’t understand the point of the article, if there is one.
It seemed more like a confused enumeration of systems which are POSIX conform and in the end it talks about Wayland.
Is the point that Wayland breaks compatibility with X11/X.org and is mostly a Linux thingy? (AFAIK FreeBSD is working on a Wayland port, but no one else.)
Anyway, I am a happy Wayland user for several years now, although I am of course unhappy about the split with the *BSDs, OTOH most 'NIX software nowadays uses so many Linux APIs, that Wayland is IMHO no big game changer when talking about portability anyway.
FreeBSD isn’t working on a Wayland port, that’s already happened. The Plasma Wayland session has supported it for quite a while… KDE even runs a CI job on FreeBSD for every merge request, where kwin_wayland autotests are run.
Considering the amount of complaints we got when something broke recently though (which is to say, none), it doesn’t look like it has a lot of users
Good to know that FreeBSD pulls Wayland off! :-)
It is a pity, that FreeBSD is not more utilized for desktops.
“Nobody wants to work anymore” energy from yet another dude
This is the best summary I could come up with:
But it hides most of the real Unix directory tree, its /etc is relatively empty, it doesn’t have an X server – it’s an optional extra.
So taking that list of general characteristics, and adding a less visible one – that it’s programmed mainly in C or something C-like – and requiring that the OS looks like Unix and nothing else, meaning there’s no other native layer underneath, then the family is bigger.
The original microkernel, CMU Mach, led to a whole bunch of Unix OSes, including the Open Group’s OSF/1 and DEC Tru64, as well as MkLinux and famously the GNU HURD.
The only one that isn’t a historical curiosity or a tiny neglected niche is Apple’s macOS family, including iOS, iPadOS and so on.
QNX is a commercial microkernel Unix-like OS, and it’s used in billions of embedded devices … although the only time you might have played with it was Blackberry 10.
A host machine, plus dumb text terminals on serial connections, with no graphics and no networking – even so, high-end kit for the 1970s.
The original article contains 1,892 words, the summary contains 179 words. Saved 91%. I’m a bot and I’m open source!
This was a history lesson which has nothing to do with the issue raised by the title.
