Understanding the working of X11 from the ground up (2017)
magcius.github.io
magcius.github.io
When I started this, I was working on GNOME's window manager full-time, and wanted to learn intricately how X11's drawing model worked, so over the course of a few weeks in a hotel room, I recreated large parts of X11's drawing model in a web browser, fixing artifacts as I went along, until I feel I had a really good grasp of it. My initial test scene was a traditional desktop-like approach with a taskbar and xeyes, both of which are still in the codebase today, but untested [0].
I didn't know what I wanted to do with it, until I settled upon using snippets of it to build a long-form article. I learned a lot about the difficulty of writing, of pedagogy, of that blurred line between being technically correct 100% of the time vs. telling a few small lies here and there to keep the flow consistent and help people see the broader picture.
At my day job, I had mostly moved onto Wayland, where some of the bits I picked up here really helped me design better protocols and systems. My goal with the series was to try to be as neutral as possible, and my original design was to have a giant caution sign around "Author Opinion Zones" where I would talk about how certain design features haven't held up well in practice. But quickly, people on Hacker News or Phoronix or Reddit seemed to skim the article, pick up a piece here or there, and go on straight to bashing Wayland, gleefully unaware that I was one of the people making it.
So, the end result was that I basically stopped working on Xplain basically after the second article. The COMPOSITE article was one I made after a colleague was having trouble understanding COMPOSITE, and I figured it was easier to write with my framework than explain in a chatroom, and maybe some others would appreciate it.
I have a deep passion for sharing my knowledge, and Xplain was the format I first really used to do it widely, so I tried to keep it exciting for me by changing it from "Xplain" to "Explanations", and opening up the topics from X11 to just about anything, but at some point I was just unhappy working on it.
The last thing I was working on was a continuation of my Basic 2D rasterization article, where I had a fun code editor you could use to make your own graphics [1] [2], but as fun as the technology was, I couldn't find a satisfying flow to the article, so I stopped it. Parts of it were later recycled for an article on the histories of 2D and 3D graphics. [3]
Around mid-2016, I had stopped working on Linux and open-source graphics entirely, and by 2017 I had exited the open-source industry completely and jumped ship to professional game development. I still have a deep love for graphics and a passion to explain things. I just released a new side project a few days ago for it, even.
Here's some stuff I'm working on these days. It's much cooler than X11/Wayland flamewars, in my opinion.
https://blog.mecheye.net/2018/03/deconstructing-the-water-ef...
https://www.youtube.com/watch?v=8rCRsOLiO7k
--
[0] https://github.com/magcius/xplain/blob/gh-pages/src/clients/...
[1] https://u.teknik.io/XdSbC.webm
[2] Sort of up here at https://magcius.github.io/xplain/article/rast2.html
[3] https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harde...
If you ever do make some good YouTube content, do let me know! You've definitely been an inspiration for me in my graphics journey, and I imagine you have some incredible insights and perspective into the graphics world.
Edit: neither does anything here: https://noclip.website/
It does in Chrome.
Again, great job! That's exactly the kind of content I'm enjoying most on YouTube.
Basically, my question is whether anybody is working on a solution for the hardware we have today, where there are hardware overlays, the GPU throughput is orders of magnitude higher than what's needed to composite a desktop, but we still care about memory bandwidth, largely because all of resolution, bit depth, and frame rate is still going up. And you really want to be able to schedule every pixel that gets presented with a high degree of timing accuracy.
I've become familiar with Windows, but feel like it's a bunch of hacks. They will promote a window to an overlay, but it's all a heuristic, and I'm pretty sure latency will stutter while it does the transition in and out. And the new flip-model stuff actually regresses the ability to do smooth window resizing.
I'm not even sure macOS is working on lowering latency. I haven't seen any mention from them of hardware overlays.
Most of the attention these days seems to be in the VR/AR space, where latency is obviously important, and there's more of a green field with respect to legacy compatibility, but I'd love to see this problem space actually solved on the desktop. Doing this right is not easy - it probably requires some form of soft real time discipline across the graphics stack (including GPU scheduling) so you can race the beam.
> Basically, my question is whether anybody is working on a solution for the hardware we have today, where there are hardware overlays, the GPU throughput is orders of magnitude higher than what's needed to composite a desktop
Hardware overlays are... not that popular on desktop devices? You just stomp on the gas pedal with bandwidth and power consumption on consumer desktop gaming GPUs. Besides a couple YUV planes and a cursor overlay, you don't see that much in the way of CRTC capabilities on desktop. All of that's happening in the mobile space, because of power consumption reasons, where you basically have an SNES PPU in your CRTC with multi-plane compositing.
I remain unconvinced that compositors need to add a frame and a half of latency. 16ms is a lot of time to render a frame, and composition isn't too difficult of a task. It just comes down to buffer handoff, which can be smoothed out over time. Similarly, the new flip-model isn't the thing that makes smooth resizing difficult, buffer allocation and resizing has always been a pain and racy on Windows/X11. This is one of the things that Wayland fixes -- it was actually the thing that caused Kristian to start Wayland forever ago.
Presentation and timing is something I think should be possible, but I don't think it makes sense for every app to have to handle it. Multi-monitor scenarios are what make global timing difficult, and having per-monitor surfaces is just a pain to deal with from an API standpoint; if we did the work to have per-monitor timing information and split surface rendering, nobody wants to go through the work to set up two devices and present different ones at the right time.
You might protest that all monitor timing is roughly the same these days, but someone hooking up their laptop to a projector, you get radically different timing.
In many respects, I think graphics is in a local minima right now: it works well enough and we understand it well enough that nobody's really interested in pushing us to the next thing. VR/AR research might, but that's been relatively unimportant as a target platform, commercially.
For what it's worth, I would be very interested in chatting about this too, as this is my area right now. I'm working on what will hopefully become the Firefox OS compositor integration library, with an eye toward optimum power consumption, and am knee-deep in details of cross-platform composition. It's a very interesting topic.
The only applications strongly sensitive to latency are video games or similar, and they take a special low-latency path through the graphics stack, exclusive full-screen mode. Monitor, graphics card, and game engine developers are all doing interesting things with scheduling there, but the main function of the OS / compositor is to get out of the way.
Beyond that there's video playback, but 60fps video is rare, videos have (relatively) huge buffers of decoded video, and dropped frames are easy to overlook, so I don't think it's much of a priority for the OS. Nobody will notice the window manager adding an extra 10ms delay to the video.
Businesses don't care about visual fidelity at all, the most common monitor size is still 1366 x 768. So there's no big push commercially, besides the aforementioned VR/AR.
paining with a pen/tablet/mouse
As far as pointing devices, people are apparently habituated to the 50ms response time, and massaging of the lower-latency data only showed effects above 16ms: https://wp.cs.ucl.ac.uk/sebastianfriston/wp-content/uploads/...
I think artists are more interested in pen/display combinations though. There's a study of touch dragging, where the average is somewhere around 6ms: https://www.tactuallabs.com/papers/designingLowLatencyDirect...
It still seems like it's mostly about having the bandwidth to drive a 240hz or higher display though. The ongoing computation required for painting is minimal. Unless Wayland or X are doing a lot of IPC on every frame there's no reason to write a new graphics stack.
Also, Don Hopkins hangs out on HN, where he's already weighed in a few times with some ideas for future work if you grok through his comments.
https://en.wikipedia.org/wiki/NeWS
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
The current version of Dercuano, in the unlikely chance that you want to read my incomplete and unedited notebook, is in http://canonical.org/~kragen/dercuano-20190915.tar.gz.
> So, a lot of the design of X11 is giving clients and apps a large set of tools to design and implement their app, without any real opinionated design about how an app should be made. An X client can use this tool or that tool to battle this tradeoff or that tradeoffs, and neither is fundamentally a wrong choice.
That is something that can not be said about Wayland. Besides the "every frame is perfect" mantra Wayland has no design philosophy at all. It is also a weak argument to introduce a new protocol. With modern drivers it is rare to experience tearing on X11 and on some occasions it even makes sense to disable vsync (e.g. competitive gaming).
The introduction of Wayland was a mistake because X11 has a huge ecosystem with lot of little programs and a large diverse users base. Almost every Unix OS supported X11 at some point. There is a reason why Intel still stuffs the i368 instruction set in their processors, Microsoft Windows still can execute programs from 1995 and IBM is still able to make money with vastly overpriced mainframes. Successful systems have the tendency to stay and accumulate cruft as a result. The abandonment of X11 will be a heavy blow to the FOSS community (and maybe that is exactly the intend).
One of my many mistakes that burned me out on the whole project was trying to present X11 in a neutral way. I personally believe there's a lot broken with the architecture and the ecosystem, but wanted to let X11 sell its own ideas, slowly letting you figure out they were the wrong ones. But that never happened. I should have been more up-front by pointing out brokenness when I see it. The whole window tree was the wrong idea.
I worked closely on Wayland for a few years of my professional life, and helped design important parts. I believe X11 made plenty of wrong choices, and Wayland made much more informed ones.
But my attempt at staying neutral only fueled the Wayland vs. X11 debate. I stepped away entirely from open-source graphics in 2016, but it still goes on today.
> There is a reason why Intel still stuffs the i368 instruction set in their processors
If you want a CPU analogy, Wayland is more like ARMv8, which was mostly a clean break in terms of the AArch64 ISA, but which still supports 32-bit at the process level. 32-bit and 64-bit code cannot be intermixed in the same address space, but you can run 32-bit and 64-bit apps simultaneously on the same OS, analogously to the way you can run X11 and Wayland apps on the same Wayland desktop using Xwayland. This actually worked out beautifully, and I would have preferred that x86 had followed the same trajectory.
Blacklists are needed because OpenGL drivers for specific hardware have bugs and can have missing functionality. Those can affect Wayland too, since the same drivers are used.
Modern Xorg supports direct rendering well, Keith Packard authored a lot of modernized infrastructure such as DRI2/DRI3, and even support for VR (work he's been doing for Valve).
There's also the important VK_display_timing extension implementation he's done with Croateams Alen Ladavac:
https://twvideo01.ubm-us.net/o1/vault/gdc2018/presentations/... on Xorg
Sadly, I don't see much more recent activity from him or Alen about these topics, but it shows that Xorg is still the main platform of inovation for Linux real-time graphics needs.
> debate the merits
Wayland has no merits. That is kind of the problem. It is just a reimplementation of stuff that worked.
Once the integrated X support is gone you can't just replace it with a standalone X server of the sort that's available on OSes like Windows and Mac OS X either - by design, the standard Wayland API doesn't provide the functionality required to run X (or Windows) apps. In particular, it provides no way to set or get the absolute position of top-level windows, which apps on those platforms need to support things like menus. In a few years time, I can easily see modern Linux becoming the only current desktop OS that cannot run X apps.
https://blog.mecheye.net/2014/04/xwayland/
https://wayland.freedesktop.org/docs/html/ch05.html
If hardware vendors don't have to care about it, then Xwayland should not create a huge maintenance burden and thus I'm pretty confident it will be available until 2030; enterprise distros likely won't be able to remove it earlier anyway.
I respect the intention and efforts of the Wayland community to make things better. However, I wished the community would have focused on making X11 better (easier to maintain with modularity etc.) instead of following the mainstream which is focused on eye candy and other sensual features to attract customers.
The unfortunate developments of KDE3/4, Gnome2/3 and Win7/8 exposed that boring usable functionality is much more important than exciting sensual functionality.
My understanding is that Wayland was started by a few core developers of Xorg who just couldn't stand maintaining Xorg anymore.
I've tired Wayland a few times and whenever I do, I give it an honest shot for a few weeks, but tend to run into issues (Sway being pretty buggy or oddities with old X apps or Steam, etc.) I've heard Sway has gotten a lot better and I should really try it out again; probably the next time I setup a laptop.
I do wonder what plans FreeBSD and OpenBSD have for the future. Currently they main their own Xorg trees, but I wonder if we'll ever see Wayland implemented on other platforms.
Things that don't work for me:
- mirroring (i.e. two displays showing the same windows at once), but AFAIK this is being worked on
- KDE Connect (not Sway's fault, but not having this working really hurts sometimes and might just make me go back to Plasma)
Windows 8 was a major improvement saddled with an untested UI that someone was using to make their political mark. The internals of Windows 8 and Windows 10 are a major, major step forward from 7.
I only ask because it's very easy to be cynical online and I'm not sure that this comment comes with much to back it up. There's very much an 'old man shouting at cloud' vibe to it, even if unintended, but I ask in good faith in case you have insights we don't know yet. :)
[1] http://trinitydesktop.org/
For a distro built around that
And if you absolutely can't live without the look, or just wanting to make fun of people looking over your shoulder:
[3] https://xpq4.sourceforge.io/
The funny thing about that stuff is it works better with multimonitor setups than every other environment which followed later. By that i mean laptops in docking stations with one or two external displays, not necessarily the same size and resolution, and hotplugging.
But how do i dare to speak of that when the herd moved on and bleats bitrotten!,deprecated!,unsafe!,unsupported!,obsolete!
/me mumbles something about stoned sheeps which obviously had too much of the wrong weeds...
Then X11 never managed to be a really effective window manager on a local workstation while Windows became really, really good at remote displays.
Did you ever see those 90s commercial Unix workstations? Like from SGI?
How about a Nokia N900? X on a smartphone. It ran pretty well. Today's smartphone hardware would run circles around that thing so I can only assume if somebody ported X to those it would also do fine.
I feel like people see things they don't like or imperfections and bash the whole thing as useless. X had a lot of mileage. I use it frequently today and don't see a lot of problems.
(1) X11 is not a window manager,
(2) There have been several really effective window managers for X11,
(3) MS-Windows has never been good at remote display.
There were no financial driver to make X11 a more optimal local solution.
There were huge financial incentives for MS to make their terminal-server offering more appealing.
And that’s all you need to explain the outcome.
It is an interesting project and the YouTube presentation is pretty convincing: https://m.youtube.com/watch?v=07nqZIFRDJg
A great example of what a motivated and disciplined developer can achieve.
I understand X11 has a lot of unfixable problems, but what's wrong with Wayland world?
I had been working on Linux professionally for about 6 years at that point, and got burned out on it. I have a lot of thoughts on the success of Linux as a general-use platform but mostly keep them to myself these days.
I still have a deep love for graphics, and have since moved onto working in the games industry, where I am much happier. I also still have a passion for explaining graphics topics.
Current efforts:
https://blog.mecheye.net/2018/03/deconstructing-the-water-ef...
Wayland is a protocol for a well designed future where all that functionality is broken up into separate pieces of software. Wayland handles the window model and most of the other parts already live in their own software projects. The problem is that Wayland makes some changes to the basic window model on the way through that are a big deal and so far there is no great software written that uses it.
Adoption is very slow because the best case scenario is there a Wayland compositor that has feature parity with an X11 window manage and a bunch of weird problems cropping up because screen recording is a to-be-solved problem.
My position from the armchair is that Wayland really needed a complimentary official protocol for how to request another application's graphical output. Not coordinating that means that anything that supports Wayland is going to be practically inferior to an X11 solution. It'll get fixed sooner or later I expect, it isn't a technically hard problem.
Anyway the issue with Wayland is that it is not ready, the important screen recording feature is yet not here,I seen also some complaints from gamers and their issues are a won't fix, probably when Wayland will be actually ready we will need something to replace it or a Wayland 2 that learned from first attempt mistakes.
This is easy to do. Something like grim to take the screenshot of whatever region you want:
https://github.com/emersion/grim
And calculate the coordinates you need by querying the window manager. In sway (i3 compatible tiling WM) that would be:
$ swaymsg -t get_tree
To get a JSON of all the windows currently open and do whatever math is needed.
You can also do a hand selection using slurp:
https://github.com/emersion/slurp
It works together with grim like this:
$ grim -g "$(slurp)" screenshot.png
Having recently moved from X to Wayland there are still some things missing sometimes but they're not many. If you want a DE at least GNOME and I think KDE as well are making the switch reasonably seamless. And there are some features that Wayland solves much more thoroughly (e.g., tear free output, fractional scaling). The network transparency part, that is often brought up but rarely used in X is also being delivered:
https://lists.freedesktop.org/archives/wayland-devel/2019-Au...
1 my zoom follows the mouse but this is broken is nome games where the trying to move the zoom area to the edge where the text is would move the camera in game , pausing the game is a solution but some games would put a Pause screen on top of te text I want to read.
The OCR has issues when games use fancy fonts, old games use some pixelated fonts that are impossible to OCR, other games use more artistic fonts that are also hard to OCR, other games use text over semi transp[arent background and it makes hard to separate the text from the background.
For DirectX I am thinking if I could maybe intercept the draw text calls, I am considering making a Stack OVerflow post but I am a bit anxious that I am not sure what the correct title and tags should be and I could get the off topic and the question closed.
There will be people who don't want to use GNOME frameworks and don't want to use the GNOME window manager.
Wayland is enforcing a policy ('don't access other devices graphics output') where it should be providing capability ('an applications graphics output is private by default but that can be configured'). However it looks like the design of Wayland purposefully omitted that sort of configuration from the protocol. So instead of having a security model that is sufficiently complicated to allow screen recording, the security model is 'No'.
To get a framework independent solution all the compositors would need to implement an identical API for accessing graphics output. That needs to be coordinated in the same fashion as the Wayland spec. As the spec stands, it is just asking for every framework, compositor or application to go implement its own different solution.
The Wayland designers may even have tried to avoid explicitly creating a security model, but in practice it comes with an implicit security model that is inflexible, unconfigurable and difficult to coordinate around.
For example, all compositors are using libinput, which replaces legacy ways of X handling input. It's not mandated by the protocol either. So I don't see why they can't use Pipewire for audio and video needs.
If anyone wants to make a better alternative to standardize on - they are free to propose it.
Pipewire looks like some audio-visual framework for GNOME and GTK apps and while it might be fantastic it is both new and not very comprehensibly advertised. And it will probably be very complicated and involve some rather interesting design issues compared to building something in when the Wayland protocol was created.
We're coming out of a world where the standard used to be "run graphics drivers in userspace!" so any weird compromise is workable (including an audio framework deciding on graphics security policy). But ultimately the idea that a GNOME-sponsored effort is going to be what sorts out the security model for desktop apps is weird. I can't find anything to suggest that Pipewire is intended to be the definitive way to do screen recording, it looks to me like that might be a happy side effect. It wouldn't be surprising if it turns into two or three competing ideas.
The wayland environment is maturing quite fast now.
So far video applications on Linux have accessed the
hardware directly, meaning that two applications can’t
access e.g. a webcam simultaneously. Solving that
problem, and screen sharing with Wayland, were to my
understanding the main motivations for creating a video
daemon.
If both Gnome and KDE (the most widely used DEs) are behind it, I'd say it's already a major consensus on where things are going.
Also, it looks like even wlroots has some plans to support it: https://github.com/emersion/xdg-desktop-portal-wlr
And if anyone wants to propose a better alternative, like you said, they can do it.
> This program requires access to /dev/uinput. This usually requires root permissions.
Source: https://github.com/ReimuNotMoe/ydotool#runtime
Edit: I'll also add that only 5~ commands have been implemented so far in ydotool.
I'd say the biggest issue is really maturity. I actually find Wayland to be a surprisingly nice piece of software engineering. I don't know if I like the architecture really, but it comes together fairly nicely in the end.
For example, there's unanswered security questions. It would be good if applications couldn't just go and manipulate and spy on other apps like they can with X11. Wayland indeed solves this issue, but it leaves other problems. How do I capture the desktop?
wl_roots offers some extensions that help alleviate the problem, but they don't solve the full problem; for example, you can capture the screen, for which programs and an OBS plugin exists, but there's no upstream Wayland extension that can make WebRTC desktop capture work. I think what we really need is the ability to integrate policy and consent requests, but I'm not sure whether there's progress on that front, or how long it will take. Once the problem is solved, upstreamed to WebRTC, and that upstream version trickles down to Electron apps, Firefox and Chrome stable versions... well, things will be in a better place.
Speaking of web browsers, today Firefox still has some issues to go before it is fully working in Wayland natively. You can do it today, but it is not perfect; there are sometimes places in the code where it assumes it is running on X11, and things simply break. The screenshot tool is just flat out not present when running under Wayland due to the above issue.
Applications are slow on the uptake too. XWayland covers most of them, but it is not perfect. Like anything that captures the screen, of course, is not going to work under XWayland, but also, XWayland apps may behave a little off. In Sway WM, one bug is that when the mouse travels from an X window to a Wayland window, sometimes it behaves as though the mouse is still hovering over the X window at the last position it touched, which leads to tooltips showing up where they shouldn't. There's still a decent amount of GTK2 apps, and even Qt apps aren't all Wayland yet; Krita plans to start working on support I believe next year.
In my case, here's the itch I'm currently scratching: Sway WM also does not have support for drawing tablets. I found this out, by, well, loading up a drawing program and noticing the lack of pressure sensitivity. So, that's what I'm currently working on. Needless to say, this is a non-starter for anyone that relies on a graphics tablet, although if you are just using GNOME 3 it is unlikely to be an issue since I'm sure GNOME 3 supports graphics tablets just fine.
NVIDIA drivers are still a pain in the neck. I gave up and bought an AMD graphics card, and frankly I can't recommend it enough. Basically everything works better on Linux, but certainly Wayland works better. It's worth giving up some raw power. Still, for many people the proprietary NVIDIA drivers are going to need to work, and today support varies from lackluster to poor depending on what compositor you use.
That's odd - it's present (and functioning) in my Firefox (69.0.1) running on Gnome-on-wayland
Firefox is generally quite crashy, however, which I'm guessing is Wayland-related
This Firefox instance is running on native Wayland. The only issue I have with it is sometimes the coordinates for the context menu are wrong.
But yeah, there might be compat issues, if some protocols are required for stuff. But Wayland itself is the baseline: you'll always be able to draw windows and interact with them.
What's left to extra protocols isn't guaranteed to work: control of the compositor with a client, for instance (color correction, virtual keyboard, screenshots, window placement, screen geometry, window decorations, etc.) is completely up to the compositor (and the protocols it can speak with the client). So is other stuff, like graphics tablet input (with pressure sensitivity, tile, etc), minimizing windows, window miniatures as used for KDE's taskbar as well, I think.
But then, it's not like everything worked flawlessly everywhere on X either :) And as long as the baseline is solid, we can build on it.
That said, the problem occurred for me when using the NixOS package firefox-wayland. It is possibly better to use upstream firefox with Wayland, but I have not tried; I am just running firefox on Xwayland for now.
MOZ_WEBRENDER=1 MOZ_USE_XINPUT2=1 GDK_BACKEND=waylandWhat's old is new, apparently.
Some details here: https://wiki.archlinux.org/index.php/PipeWire
Some features though are surely missing. Such as support for adaptive sync. No one really is pushing that forward.
See: https://github.com/swaywm/wlroots/issues/1406
As for Nvidia - don't waste your time on their proprietary drivers on Linux. They don't to play by the rules (refuse to upstream), so no need to spend time supporting their blobs.
I think there is still hope. Obviously today's reality is still bleak with signed blobs and plenty of question marks, but I think open-gpu-doc is a sign that NVIDIA does actually want to square away this problem, maybe they're just not sure how.
I do believe NVIDIA is mostly responsible for Wayland's poor adoption, and I firmly believe that this also lead to Wayland not getting as much developer attention as it could've gotten. The fact that one company wields this much power is a serious problem. I kind of understand the hostility Linux kernel developers seem to have towards proprietary drivers under Linux now.
AMD is doing fine though. I have RX 5700 XT, and besides for some rough edges due to it being very new and drivers still fixing bugs, it's a very good card.
I expect Nvidia usage on Linux to plummet, due to their refusal to provide open drivers. It's already happening, just will take some time for it to drop to the point where they have little influence.
See: https://www.gamingonlinux.com/index.php?module=statistics&vi...
So in the long term it's not a problem.
The fact that Nvidia blob fails you less is not a good indicator for you, unless you test with Mesa as well in each case. Mesa is a lot stricter about OpenGL spec compliance. So if you only test on Nvidia, you likely have bugs that you didn't notice.
See also: https://www.phoronix.com/scan.php?page=news_item&px=OpenGL-T...
Try testing current Mesa versions. Previous experiences are no longer relevant.
Hey, thank you for working on this! The other day I plugged a tablet in, and found myself quite dumb with it not working properly. I wanted to have a go at implementing the tablet v2 protocol under wlroots, but it sounds like I'll hack on something else : P
It has been an interesting exercise so far, and frankly a quite pleasant one. Rather than autotools or CMake, many of these projects are using Meson, which is just so much nicer. I also really have learned to appreciate Sway WM's code, which I personally think is quite nice now, after having worked with it (though, admittedly, the ease of segfaulting does make you long for something like Rust.)
Or does he mean he abandoned these techs and moved to something other alternatives?
If the latter, I wonder what these other alternatives are?
Every time I see the X11 protocol, I realize that the UNIX philosophy (everything is a file) is dead.
It’s a pity that instead of improving the speed of the file system, everyone started to ignore it, hence making it’s speed even less important, and on and on...
And now nobody uses the file system for these purposes.
You're right that it never meant 'everything is a disk file', but generally the implication of the unix philosophy was that everything could be accessed from the filesystem.
Have a look at Plan9, which is essentially directly descended from 7th edition UNIX and IIRC was built from what was going to be 8th edition UNIX. It has a HTTP interface from the filesystem -- one can literally do GET requests on documents from the internet just by opening a file on the filesystem.
In the Plan9 model, each and everything is represented by an individual file system entry. In Rio (Plan9's windowing system) every window is represented by a directory in a 9p tree, and you draw to it by opening a framebuffer file inside the window directory and manipulating that.
Furthermore, terminals know about their windows, and can hand it over to whatever is started inside them, which essentially makes it possible to open windows "inside" a shell environment.
It's kind of a unified screen/tmux environment, and you can stack, mix and match how you desire.
As mentioned earlier, Plan9 is what UNIX research edition 8 grew into (as I understand it), it's possibly one of the best examples of the UNIX philosophy.
It's important to note that UNIX the actual implementation is a moving target because of the many versions, just because the designers didn't see something could be achieved in UNIX (resources, time, effort, etc.) or just plain didn't think about it, doesn't mean that it doesn't embody the UNIX philosophy :)
Yeah, and shouldn’t that (theoretically) file systems with very small delay? (For example, RAM based file systems for inter-process communication.)
I thought that it isn’t the slow storage that is blocking use of files, but more of a software problem that has significant overhead to use files as a communication method. (I’m not an expert here; please correct if I’m wrong.)
- UNIX itself has no inotify/kqueue/etc. feature, blocking reads are via pipes or sockets, not regular files (plain UNIX tail -f polls the file every fraction of a second)
- you're appending to the end of the file for a message that's going to get read once, and the file model of UNIX doesn't let you truncate a file from the beginning, so it will just grow indefinitely for no reason
- one benefit of the open socket/pipe approach is you get notified if the other side exits/crashes, you can't detect that from a disk file
Was it ever alive? As far as I know lo0, eth0 and others where never accessible as a file interface and we still rely on them. Is there something to gain to give them a name on the filesystem?
ls /sys/class/net
I think it's quite messy and inconsistent that some network interface attributes are only in sysfs, and others are only accessible via AF_NETLINK (usually via the "ip" tool). But it's there.
And that makes me think about scoped file systems... (gotten the idea from global & scoped variables)
Since the biggest advantage of ‘everything is a file’ is that it allows a consistent API for manipulating data, why didn’t this happen?
Brings back memories of the old days of the late 1990s trying out so many workstations running obscure Linux distros to actual UNIX OSes like IRIX, Solaris and HP-UX.
They all ran some variant of X11 which was part of the UNIX philosophy which I found interesting (X11 forwarding, startx, etc) but as the requirements of the desktop kept evolving over time, X11 just kept on showing its age.
Nowadays, Wayland is showing promise as a successor but I really don't have time to be messing around with these .xinitrc, .Xresources or dotfiles to get HDPI working on my MacBook these days.
It's basically all the fun we had with X11 back in 2003, just to get an environment that's about as dependable (though admittedly much faster) as X11 back in 1993.
It's one of those cases where the "release early, release often" mantra kindda seems to work against us. I'm sure ten years from now Wayland will be just as solid as X11 was back in 2013, aka "good enough", but there's a different kind of crowd looking at this stuff today.
Unfortunately, the anti-Wayland buzz propagates easily because the community response is inevitably unsympathetic. Mention things like "I tried Wayland for an afternoon, applications kept crashing" and you'll inevitably get a dozen answers, all of them along the lines of nah bro I'm running Gnome Wayland which is the default in Fedora 67 on my ThinkPad X1 Carbon and I'm not getting any crashes. Well, yeah, 90% of the projects that failed to get traction and adoption in the field of graphical systems did so because they couldn't make the transition from "running on its developers' and fans' computers" to "running on everyone's computer". I can run Wayland on my system just fine, too, but I'm the only one in my immediate circle of nerds who can.
Truth is, a lot of the reason why X11 works so well today is that a bunch of us put up with a lot of X11 crap back in the day. E.g. things like xdotool haven't existed forever, either, and it took a lot of itches (and imperfect way of scratching them) before someone wrote that. X11 wasn't exactly hassle-free for a very long time. And you get to fiddle with config files with Wayland, too, but none of these files are as long as a small section in XF86Config.
That's how free software matures -- in the open. If you want to contribute towards hiring a team of testers, you're welcome, because no one does that as a hobby. And all this is in a context were fewer and fewer developers are interested in desktop development, and fewer and fewer companies are interested in investing in desktop development.
Which could make X11 the last linux/unix desktop thing. Anything new would have to come with the whole desktop paradigm shift.
I believe file systems could have a more formal method to query the file’s format, and has less latency so that applications could use files as an inter communication format.
That doesn't preclude having more advanced interfaces, too.
As "dead" as Android (which is based on Linux, a Unix clone) and OSX (a BSD Unix) and iOS (child of OSX)? Why does Microsoft vibrantly support Linux in Windows 10 (an abomination to Ex-CEO Steve Ballmer) if Unix is "dead"?
I think the very opposite is true. Some developers realized that the KISS principle (including the Unix philosophy where everything is a stream of bytes) is not a bad idea after all.
https://blog.pragmaticengineer.com/software-architecture-is-...
Lennart Poettering, who is the mind behind Systemd, Pulseaudio, and a lot of major new technologies explicitly disavows the UNIX philosophy.