2. While it appears that Wayland is poised to replace X11 on Linux desktops given the amount of backing Wayland has compared to X11, it is not clear whether Wayland will replace X11 in the BSD ecosystem. According to the FreeBSD Wiki, Wayland is not ready to be a daily driver (https://wiki.freebsd.org/Graphics/Wayland), though work has been done getting Wayland compositors and other software to work on FreeBSD. I use X11 on my FreeBSD desktop. I'm unfamiliar with the current status of Wayland on NetBSD and OpenBSD. I expect X11 to live on for quite some time in the BSD world and among more conservative Linux users, similar to the situation regarding systemd in the Linux community, which was adopted by mainstream distributions and users but faced (and still faces) opposition from some users.
I've been using Wayland and Sway with FreeBSD 13 quite successfully. Everything worked quite well, except some indicators in Waybar that were using some Linux specific things to get values for memory usage etc...
WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd.
There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.
Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland.
Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work
Some relevant links for those curious about other people hitting into this:
>My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”
>Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
I don't have a second monitor right now to double check, but I have this in a script for our office monitors to get a different dpi for one display (named eDP-1):
The final "composing" step in Wayland does require Wayland to use a "giant" buffer as well. Also My GPU has 16 GB of GDDR how can any frame buffer be "giant" in that context?
The support of hidpi scaling is something Toolkits have to manage (on both Wayland and X11). On X11 all the necessary pitch information to do so is available via the xrandr extension.
You really don't want to use Xrandr information to do scaling, it's not accurate. A better way would be to set a property on the window and have the compositor read that, AFAIK this is the solution that the Kwin developers were working on.
What's hidpi? I mean, pragmatically. I can guess that that acronym means "high dots per inch", but I don't follow.
One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors.
Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...
You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks that teams, specifically I've seen the canonical team pull this off, where they can "trick" xorg into displaying properly with some minor visual artifacting. The last time I tested this was with Ubuntu a few years ago, back when Wayland support was "experimental" and I had this exact sort of setup, and Wayland was easily able to pull this off 100% better in every way because it is not designed around this limitation.
> The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI.
The word "properly" here is quite subjective, though. I have a similar setup, combining monitors of different pixel sizes.
It works properly with Xorg: When I move a window of size WxH pixels from one monitor to another, it remains a window of WxH pixels. A thin line of one pixel width remains so. A checkerboard pattern that tingles the monitor refresh rate remains so. This sounds like perfectly appropriate behavior, and anything else would be ridiculously inappropriate. I accept that this usage of "appropriateness" is subjective to a subset of people that includes me, but it may not be universal.
Whatever, this is such a thin point for Wayland: hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before. But hey! you can combine monitors of different pixel size as if they had the same pixel size! See, the thing transparently re-scales your windows using cheap-ass bilinear interpolation so that they get the exact same size in millimeters! Fancy, isn't it?
> hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before.
Wayland has had working screenshots, screen recording, clipboard functionality for text and arbitrary mimetypes, etc. for years on wlroots, GNOME, and KWin. It also has ydotool, an xdotool alternative. For pure keyboard automation it also sports wtype.
Which apps don't support Wayland? The only ones on my machine that need XWayland are some video games and FLTK apps like Dillo (I have to test with xwininfo since it's normally impossible for me to notice if a program is using XWayland). All GTK/Qt apps work OOTB on Wayland as a first class citizen, especially since those toolkits nowadays receive more Wayland testing than X11 since barely any current distros still ship X in their default installations.
Which Wayland compositor/version and GUI toolkit/library gave you blurry bilinear filters?
Ah, I think I get it. You want to use a "point" abstraction, not a "pixel" abstraction, right?
In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel sizes.
I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal.
Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone.
It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)
You are incorrect in your belief that a modern Linux graphical stack centered on Wayland ever resamples or interpolates a virtual or actual framebuffer except for compatibility with apps that have not been adapted for Wayland. (Those apps use something called XWayland, which is blurry if the user has configured a non-standard size for things.) 99.9% of fonts these days, most icons provided by the OS, and most other graphical elements (e.g., rounded corners) are specified as mathematical descriptions of curves that can be rendered at the display's native resolution regardless of what size the user chooses them to be. (I believe the 0.1% of fonts that are not mathematical descriptions of curves are called bitmap fonts.)
Note that I am not talking about multiple displays, but rather a single display, but the user wants things to be bigger than they are by default.
I know this because have used all 3 major operating systems recently (MacOS, Windows 10 and Linux/Gnome) on plain-old 96-DPI monitors such that if there were any interpolation or scaling algorithm I would be able to see the effects.
On a monitor 1680 pixels wide, Gnome gives me a choice of the scaling factors 100%, 125%, 150%, 175% and 200%. On a monitor 1920 pixels wide, Windows 10 gives me a choice of the scaling factors 100%, 125%, 150% and 175%. Some apps are blurry as hell, but on both Windows and Gnome I was able to live my life using only those apps that don't have the blurriness problem, but then I am not forced to use old Windows apps provided or specified by my employer and don't need to share my screen (which I am told does not work yet on a pure-Wayland set-up like mine).
On Windows 10, I used Google Chrome, some apps such as Settings and Timer provided as part of the OS and VS Code. On Linux I used (and continue to use) Google Chrome, modern Gnome apps and Emacs. On Linux, I need to open Chrome with specific flags to get it to be non-blurry while the visual elements are a non-standard size, and I need an Emacs built from a git branch called feature/pgtk. Both apps have some bugs when used in this way, but the bugs are definitely live-with-able, and I expect the bugs to be fixed eventually.
Yeah. I suppose this functionality isn't everyone's cup of tea. The cool thing about Wayland though is somehow it makes the windows still look crisp and good while making them the same size. With the canonical hack to xorg, they always looked blurry and gross. The gnome wiki had this to say on it:
"On a Wayland display server, each connected monitor will have a scale that depends on the DPI. A scale affects the scale clients draw surface contents when they are visible on said monitor."
So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image.
Then what is your complaint? No one is stopping you from using X for as long as you like. Meanwhile the majority of users that want sane, modern handling of HiDPI can move on.
Basically it is the same for Win 10. It insists on using small fonts on my laptop so i have to scale it. In the golden age you could tell X the size of your screen.
Thank you! No idea why your comment is so low. Most educational one here.
I enjoyed reading that link -- a fact oriented list, directly answering my question, rather than an assumption that I want eye candy or resampled resolutions. Fixing the input subsystem alone feels like a compelling reason to use Wayland. It's also interesting to me that the list doesn't mention DPI, which seems to be of great concern here. :>
Having read that, I'm much less terrified, though it does mean I probably will have to take the time to write a window manager for Wayland. Thanks!
This link shows what is the problem with SW development, not with X . The same thing is done also in QT or GTK. Why a program written for QT4 cannot compile in QT5 ? Why every library release must be incompatible with the predecessor ? I was able to compile and run X10 programs in X11. Why do i need to have on my linux system more than one version of a library ? Will Wayland fix that, because from this article I see that it is more or less in the same mess of incompatible libraries ?
I have been using Linux for over 25 years. I am not going to shed any tears over the loss of X, though I am concerned that some edge cases will be missed in the transition to Wayland or XWayland. The latter is why I am holding off on switching. Let others figure out and fix those edge cases for me.
As for systemd, it appears to be an entirely different type of transition. I won't go as far as saying it is unnecessarily complicated since many Linux distributions had a complicated startup to begin with. However, it is complicated compared to Net/OpenBSD. In contrast, I have always seen X as complex. It is easier to deal with these days since they have smoothed over the sharp edges, but I don't know if it is a case of those edges being sanded down or covered up. It also doesn't cover up the complexities of the many different toolkits one encounters, which you will encounter under X if you use older software.
Wayland is pushed by people, who do embedded Linux. Think: infotaiment system in your car. All UI is pre-installed and fixed to one (maybe, custom) toolkit, custom "window manager" (and it is not full-featured WM, as X11 ones are, as you can not move and resize windows arbitrarily), one theme, no remote access, very low response time.
It is better than both X11 and plain framebuffer in this role, for sure.
Wayland is pushed by people, who do embedded Linux.
Maybe when Wayland was started. But X.org is now effectively unmaintained and most of the core X.org developers are now working on Wayland. From the release maintainer of X.org:
So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
> So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse
This implies it's a choice made in isolation, rather than with the matrix of WM features and hardware support driving.
People aren't "choosing" Wayland or X in large numbers. They're making decisions like "I'm using distro A which ships Wayland by default" or "I want a tiling WM and have nvidia hardware, so I have to use X".
I've done a spot of embedded linux programming before and it is a royal PITA to do anything but the simplest graphics. I can easily see a role for Wayland for that.
This is a great answer, thanks. Also, the comment about GUI isolation for security makes sense (though I suspect x11docker would solve the security issues as well). Seems like Wayland is on track to be a good solution for a niche use case.
> The biggest reason is security. X offers no GUI isolation.
This is completely false. X offers both nesting for full isolation and a concept of "untrusted" connections for partial isolation. This is the reason why ssh -Y and ssh -X are separate things.
These facilities could use a little love to make them user friendly, etc., but they're there and have been for ages (enabled by default around 2013, present before then).
X also supports advanced mixed DPI, providing all the information to the application to handle it as they see fit.
I'm really disappointed to see this get mentioned in this context, it's not relevant. At least on debian, ssh -Y and ssh -X has done the same thing since like 2013 because ssh -X is broken and causes clients to crash. The "sandboxing" there doesn't really work. And it's a lot more than a little love that they need to get them working, the whole reason Xephyr sandboxing exists is because Xsecurity and XACE are so broken that it's unusable. You can see more about this in another comment here: https://news.ycombinator.com/item?id=29092612
Security would be the worst reason. Zero cases in the wild, and it's not that difficult to add access checks to X - there used to be an X extension to do this.
The real reason would be that X contains lots and lots of cruft which isn't used anymore and it made development&testing impossible.
Xace was designed to address the mess that is Xsecurity and using the SELinux sandbox for GUI apps, except Xace barely works for mitigating exploits well on the desktop; it's so finicky that Dan Walsh himself concluded that XACE does not work and instead opted to use nested X servers (!!): http://people.fedoraproject.org/~dwalsh/SELinux/Presentation...
I read the article, I'm still not clear on why it's a problem. I'd have a very big problem if another user, using my machine via x forwarding, could capture my inputs, but that doesn't seem to be the case here? It seems that this is only for applications running on the same display.
So, to be blunt, this 'security feature' breaks a whole hell of a lot of use cases. If wayland wished to go down this route they should have displayed a prompt to the end user 'this application wishes to record the screen, that ok?'. The last time I made this point someone snidely informed me that 'this was not wayland's responsibility'. I'm sorry, if you break my use case you make it your responsibility!
That is exactly what will happen on a Wayland when you use the portal API, it shows a prompt asking for permission to record your screen and then it sends the stream over pipewire.
It is true that it isn't strictly the responsibility of the Wayland protocol, the API functionality is still there just it has moved somewhere else where it's more appropriate.
>Follow along this post and you'll end up with one case in the wild all by yourself on your own machine
I know it's possible. The 'case in the wild' terminology is asking whether this was ever weaponized in an exploit. I don't recall X ever being an attack vector in the last decade or two. I guess there are more than enough ways to gain local root this class of exploits doesn't matter.
Now, I'm all for closing this hole. But there's something bad about a development strategy that finds things like this and DPI with multiple monitors very important - the vast vast majority of users only have a single monitor - and mostly ignored scenarios like remote desktop until 2020 or so - remote desktop always used by several orders of magnitude more users than HiDPI, and a little tiny bit more important with this mass pandemic going on.
Maybe that's why transitioning from X to Wayland takes more time than transitioning from python2 to python3, a well known example of successful migration.
There are so many holes in linux’s userspace’s “security” that we should start listing the actually protected parts. The only reason there are no linux botnets everywhere is because libre software fundamentally have good intentions.
So the reason for not exploiting X may very well be simply because there is an even easier exploit available..
> There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.
This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first few hours you're just busy catching up with the rest of the world.
Or just try to go at things with an open-mind and hell, you might learn something?
X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayland.
> a middleman in the communication of applications and the compositor
There's an implicit assumption here, that one is even using a compositing window manager. I'm guessing that you do, and that's cool -- you do you! But there are lots of people, who, when sitting down at a fresh install of any operating system, start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well.
The first thing I do on Android is disable all the useless (imho) animations and effects, the same on Windows (back when I used Windows), and on Debian, where I have real control, the last time I saw a compositing window manager was I think 2006. I remarked "Ok. I guess this is for people who want their Linux to look like a Mac" and then promptly removed it. I have nothing against people wanting eye candy! Eye candy sells! But... don't pretend that it's a necessary, or even important feature.
> you can’t have displays with different DPIs
This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy.
What I think you mean is "Wayland supports point based instead of pixel based rendering", or "Wayland does image resampling for you, making it easier for people who don't want to use native resolution" (I don't know Wayland internals).
Anyway, I think this whole comment thread is both educational and disturbing. :/ There appears to be two camps, both of which are incorrectly assuming that everyone else thinks like them. I'm guilty of this as well.
Other than the comment about security, and use on embedded environments, all of the "features" that Wayland offers (according to these comments) are, from my perspective, things I would turn off because they'd get in the way.
And I will follow your suggestion, and sometime soon set up a VM, and try to install Wayland and whatever the current whiz bang desktop environment is.
> start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well.
That’s just one part of what a compositor does. I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor — something solved entirely by wayland’s “every frame is perfect”. Even on window managers like sway which has absolutely no animation or eye candy. Android also uses composition even with animations turned off.
I’m not sure we mean the same thing with multiple monitors having different DPI settings. X can’t really handle different screens — it will create a huge framebuffer of all of them together and draw on that. So if you have a high DPI and a “regular” monitor, content will appear right on the regular one, but overly small on the other. If both screens have the same DPI, X can also render at eg. at 2x size.
And thank you for trying it out, X is indeed a cool project that spanned 3 decades. But due to the very major improvements in the underlying hardware, its abstraction is simply not up to date.
> I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor.
Of course! I hate tearing, just as much as the next guy. However I honestly haven't seen any tearing in video watching under Xorg, anytime in .. I donno .. at least the last 6 years. And this isn't exactly a powerful machine. :) If I have a video windowed and I move it around while playing, I can see a bit of tear. But.. I don't do that. Most of the time if I'm watching a video it's full screen. It looks perfect.
I bet the tearing you've seen using Xorg is attributable to something else. I remember back when video kinda sucked (in anything other than mplayer) but that was years ago. I have a windowed Netflix playing video as I type this and nope, no tearing. shrug I see in the Xorg.0.log that the COMPOSITE extension is loaded, but I'm not running a compositing WM, nor am I running a stand alone compositor.
I think we can put this "Xorg video playback has tearing" myth to bed.
It was certainly true back when suspend and resume didn't always work right, but that was quite some time ago. Having read much about Wayland in the last few hours, I think a more accurate thing to say would be "In Wayland, there is never any tearing. In Xorg, you can have tearing under some conditions" There are some very compelling reasons to be interested in Wayland that don't require exaggerating Xorg's failings. :)
> X can’t really handle different screens — it will create a huge framebuffer of all of them together and draw on that. So if you have a high DPI and a “regular” monitor, content will appear right on the regular one, but overly small on the other.
I think we have a different definition of "handle", and I apologize in advance for semantic pedantry. I'm looking at 3 screens right now, one of them is a 14" "4kish" (3200x1800). Xorg "handles" it just fine. As I drag a window to the highest resolution screen (which I have in portrait orientation and use basically only for coding), the content appears exactly as I expect it to. That monitor has a higher DPI, which means the pixels are a different size. It's not a bug... it's expected and desired behavior. Dots Per Inch. It's right in the name! If some software in the display stack was interpolating everything, making my text look fuzzy, now that would be a serious bug to me!
I reallyreally think what you mean to say is "Xorg doesn't support rendering things in terms of physical size regardless of the underlying resolution." That might be true. Pleaseeeee say that instead. :) Personally, I wouldn't use that feature but I can imagine one desiring it.
But... when you say "X can't have displays with different DPIs" ... I mean this with no offense, but... you sound less intelligent than I'm sure you are. Because I can plainly see multiple displays with different DPIs right in front of my face. :) Xorg has been able to "handle" multiple displays since Xinerama, IIRC.
Anyway, I'm encouraged to take Wayland out for a spin for a reasons not mentioned in this comment thread. I like minimalism. :)
"This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy."
Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...
You and I have an opposite definition of "correct" in this context, perhaps neither of us should use it! See enriquto's comment above, this is subjective. To us, we expect a window of size WxH to be WxH pixels, regardless of display. That's my definition of handling it properly, and when I use Wayland that's what will happen.
I will (grudgingly!) concede that perhaps it's not "universally and obviously correct" that things stay the same number of pixels, if you concede that perhaps it's not "universally and obviously correct" for windows to be drawn in terms of points and scaled behind the scenes.
> Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...
No, you don't. And using a naive compositor is liable to make things blurry compared to the direct approach (the application requests the physical dpi for its current location and changes its vector drawing).
GPUs don’t have a single start, at least it depends on how you define them, but arguibly the first generally available one came in the late 1990s, compared to the various X server implementations that were around before that as well.
About its current role, there is a famous talk by an ex-Xorg developer that explains it well. Very crudely, a wayland compositor relays events to applications, which signals when it’s ready. Xorg on the other hand does these as well, but sits between the compositor and the clients, relaying their messages with some delay (and not having a concept of every frame is perfect)
Xorg doesn’t have support for mixed-DPI monitors, as it renders to all screens simultaneously with a single DPI setting. This is pretty much unfixable, it is so inside the core of the whole thing.
And finally, Xwayland exists and it is backwards compatible to the most part (other than manipulating wayland clients as if they were x ones, but that is also a wanted “functionality”). These are pretty much just nested x servers, so I don’t see how is it false?
X has had its OpenGL extension available since 1992. Your argument is like saying "Windows 1.0 came out before Direct X even existed, so of course you can't play modern games on Windows 10". As new things came out, they added support for it.
Compositors are an optional component. I have never run one myself since they don't add anything of value. So any time someone says "the X server only talks to the compositor" I'm like "lol what compositor".
But even if you have one, it is still wrong. You have to understand that GUI applications are a LOT more than just low-level rendering. So even if you didn't need it for that, there's so much more going on that the server still plays its role in like coordinating copy/paste, drag+drop, hotkeys, notifications, etc., etc., etc.
And it isn't true that everything goes through the middle man. A graphics-heavy X application actually tends to work very similarly to a Wayland application (not coincidentally - as people love to point out, a bunch of the Wayland devs worked on the gpu rendering parts of X before): you get a direct render context, write to a buffer, then inform it to draw it. See more https://keithp.com/blogs/dri3_extension/
Mixed DPI is fully supported by the system, but may be buggy in applications. See here http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ you can get information and handle it client side for maximum quality, or do auto-scaling for easy support bridges. KDE and Qt manage to do it. So much for "unfixable".
> I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd.
Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.
I'm living a pretty good life without systemd, so it's clearly not necessary. I'm sort of willing to acknowledge that it fits some people's needs better than alternatives however.
systemd doesn't have the ability to cancel tasks from the console like other init systems do, for example when my laptop can't get a DHCP response from the network card that's not plugged in, so it's clearly stupid (and so is the init script or whatever it's called that's trying to get an answer from a not plugged in NIC, but that's a separate although related issue).
On other init systems, if you hit ^C it cancels the current task. On the one systemd machine that I used, ^C did nothing while waiting for DHCP, and no gettys had started yet either, so as far as I could tell, there was no way to get the system to respond other than wait for the timeout (minutes) or reboot and maybe reconfigure in single user mode.
> And I am sure, if you really think about it, you know this yourself.
I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.
Please avoid making bad faith interpretations. I'm reading that comment as this: surely you can acknowledge that sysvinit is not a good solution for many people? And just for the purpose of adding some structure around sysvinit, systemd does an adequate job? And if you have an advanced use case that requires a very specialized init system, I hope you can understand how that is uncommon?
I don't think that is a bad faith reading; when the original statement was (basically) "systemd is bad and overcomplicated", saying "it's not and you know it" is a bad-faith statement. And no, sysvinit was perfectly fine for most people; if anything, I could fairly describe systemd as a very specialized init system for uncommon requirements. Now, I'm happy to agree that systemd is also basically fine for the most common uses (because, honestly, the most common cases are covered by anything), but it also introduced pain points for even non-esoteric cases (I've personally witnessed systemd getting stuck in fascinating nondeterministic ways more than sysv).
That doesn't seem to be what most Linux distributions were thinking around 10 years ago when the upstart/systemd/openrc/etc arguments started happening. The general consensus seemed to be that sysvinit needed to be replaced, or at the very least it needed to have a ton of other scaffolding on top of it in order to make it keep working.
Sysvinit never got stuck in those cases because it never had service dependencies and thus never needed to have a constraint solver for the dependency graph... So could you honestly say that pain point was better?
>Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.
Was bad faith, naive, and frankly... insulting -- so I just chose to ignore it.
My reservations are well grounded, and when ones concerns are echoed by ESR, Linus, and tytso, I don't think they can be dismissed so easily.
Certainly some people wanted features that sysvinit couldn't provide, obviously, because so much effort went into systemd. But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)
I'm still using sysvinit on my main machine, and on all "critical" servers not because I have an advanced use case requiring a specialized init system but because I have a simple use case and a computing philosophy that requires simple init system. I have a strong (I'll admit, borderline fanatic) affinity for the "unix philosophy" of accomplishing things through the composition of simple to understand and debug tools that do one thing, and do it well.
To me, SystemD is about as far as you can get from "do one thing, and do it well" and "simple to understand and debug". It's a monolith (right?) which is why it's not running directly on the hardware. Unfortunately, Debian now builds some packages that I use occasionally with SystemD specified during the configure stage, and I don't want to maintain my own packaging of tools with different compile flags, at least not yet. Presently, I solve this by having a separate VM for "all tasks that need systemd", but I hope to replace that with something lighter weight, perhaps containers instead.
SystemD provides some features I imagine most users want, and that I strongly see the benefit of, but for the vast majority of those features, those reasons I'd want to use systemd, I'd already solved it myself, through the composition of existing and simple tools. A good example is networking. My computer does exactly what I want it to do, every time, in all permutations of wireless, wired ethernet, wireguard, knowing to mount certain NFS shares when I'm at home, randomizing mac address in certain situations, knowing when &c. It's great functionality, and I got there over time by building simple and easy to debug shell scripts, which call out to tools like `ip`, `iw`, `wpa_supplicant` and reading from /sys/class/net.
I also don't use pulseaudio, as audio happens to be one of the subsystems I have strong experience with, and pulse is an unnecessary (and sometimes error prone) layer, considering I get along just fine with ALSA.
The one thing I'm jealous of is faster boot times. But I'll happily boot a few seconds slower in exchange for PID 1 being simple, and my other services being simple and hence easy to debug.
I don't understand why this philosophy discussion seems to get brought up so frequently or why anyone needs to care about philosophy in the context of a computer program. Linux distributions that adopted it are not sitting around pondering the meaning of life or the existential nature of what it means to boot a computer, they were using it to solve a real problem that they had. It was a complex problem, it was not a simple problem that could have been solved with a simple solution. So what you are saying is not really related to the question.
I don't think the opinions of ESR, Linus, and tytso are relevant here either as none of those people work on init systems. If you developed your own solutions with shell scripts, that's great for you, but I hope you can see how that doesn't work at scale in a big distribution. BTW systemd includes a lightweight implementation of containers so I also don't understand what you're talking about when you said you needed to then put it in a VM or container. The exact problem you're having can also be solved... by just using systemd. So it actually seems like you're making things more complex than it needs to be by jumping through hoops to avoid it.
Audio is also my expertise, and using just ALSA is an experience in pain. You need some kind of userspace daemon in order to get a good experience with that.
Booting is simply a complex problem. The complexity simply lives with your shell scripts instead, which is imo a much uglier and less maintainable solution for most use-cases.
Also, does your system do logging before the file systems are mounted?
> But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)
Sure, but systemd has quickly been adopted by the experts, namely the maintainers of every mainstream distribution. The people who maintain all of that infrastructure think it is much better than what we had before. That does say something about its quality.
> It's a monolith (right?)
That‘s a common misconception. You don‘t have to use all of systemd. And I am not talking about all of systemd, just the init system.
That also invalidates your point regarding networking, btw. You could keep using your setup with systemd.
That statement feels like a Tesla FSD announcement. I think Wayland people started to claim that before most Linux desktops even had a working replacement for any of the hundreds of things like screenshots, copy paste, etc. that where build into X11 but stripped out of Wayland.
What "Wayland people"? You probably mean the former Xorg developers who shifted to full time Wayland development long ago. Xorg is on life support, it has been getting bug fixes and nothing else for the past several years.
From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.
> Xorg is on life support, it has been getting bug fixes and nothing else for the past several years.
Imagine two cars: X11 its an old one, it doesn't quite start right, the windows are chipped, the paint is peeling of and no one really wants to invest money into maintaining it, it defaults to brakes and a steering wheel from 1980 but has seen continous upgrades over time and you can generally swap in a steering wheel from 2010 with minor problems.
Now imagine wayland, a brand new tesla, it doesn't have brakes or a steering wheel because history has shown that these concepts evolve and if anything it should be a third party provider that creates them. Who cares that it took ten years between the release of the car as ready for use and the first compatible steering wheel implementation? Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction.
> From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.
As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs). Of course the people who wrote wayland also wrote X11 so removing themselves from the equation might have been the nicest thing they ever did, given their own opinion of their past work on X11.
>Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction.
a) nvidia's refusal to implement GBM in their driver was their own choice. The abstraction was never removed; GBM is the abstraction over all drivers.
b) nvidia already relented and implemented GBM in their driver.
The latter doesn't necessarily mean nvidia is a good choice of GPU even now, because it requires a proprietary driver, so compositor / Mesa / kernel devs cannot debug the full stack when anything goes wrong. So having your problems ignored is something you'll have to get used to if you choose to use hardware that requires proprietary drivers, regardless of whether you use it with X or wayland.
>As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs).
wlroots exists to solve that problem. Whether an individual compositor decides to use it or not is up to the compositor.
At least in KDE's case, wlroots did not exist at the time they added Wayland support so of course it's understandable that they don't use it. There's a fork of kwin that uses wlroots ( https://gitlab.com/kwinft/kwinft ) but I believe it's just an experimental one-person effort rather than anything that kwin devs are working on as a replacement.
josefx: Since your reply was flagged, I'll reply here.
>Still not going to amputate my leg over a stubbed toe even if RMS considers the toe cancer.
I didn't say you should. I worded what I wrote specifically to indicate that I'm not passing any judgement on whether you made the right choice or the wrong choice.
There are many people who bought nvidia GPUs because they worked fine, and were rightfully worried that they'd stop working fine if their DE of choice decided to switch to wayland or became abandoned. I empathize with their situation completely.
All I'm saying is that you made the choice to buy hardware that requires a proprietary driver, and so you have to live with the consequences of that choice. This is not something unique to this situation involving nvidia GPUs. Only you have the right to decide whether it was a good choice or a bad one.
Xorg barely works on nvidia (source: me)
vsync requires a compositor to work, and even picom needs a very specific combination of flags to get vsync to work.
Chromium cannot gpu accelerate video playback.
On rolling release distros, most major kernel updates leave your system broken, because nvidias out-of-tree driver can't build against new kernel versions.
If nvidia stops supporting your old gpu, like they just did with Kepler, you're screwed.
The problem with nvidia on linux isn't wayland, it's nvidia.
I have used strictly Nvidia gpus, on debian Linux, for 20 years, using the binary drivers, and I have none of the issues you describe. It just works, very well, stable and fast. Xorg is an amazing piece of software and combined with openbox it does exactly what I need.
Xorg works just fine with Debian and Nvidia (source: me). Some longish (5-10) years ago it got so stable that I managed to stop thinking about it, because it Just Works. Even across upgrades. Your problem lies not with Linux, Xorg, or Nvidia.
>If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles — but you’d be able to shift gears with your car stereo. Useful feature, that. - Marus J. Ranum, Digital Equipment Corporation
> Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction
You mean under “they” the linux kernel devs? Because it has absolutely nothing to do with wayland. Nvidia cards’ proprietary drivers work with X because you are using a part-binary blob for X. Also, finally nvidia realized that they should goddamn support linux, so what all these resulted/will result in is better integration for people with nvidia cards.
FYI there are crowdfunding efforts to keep Xorg maintained https://news.ycombinator.com/item?id=29034479 . The recipient is the current X server maintainer so it's likely this is the best way to help keeping Xorg maintained.
It hasn't gone, it has just moved to other places, i.e. the web browser. In my opinion, X is a failed experiment, we know now that there are better ways to do things.
While it's supposed to be "maintenance only", it got a very important addition recently (but not a definitive solution by any means) that helps with dreaded multiscreen setups, AsyncFlipSecondaries.
This is exactly why I would rather do. I see absolutely no reason to abandon X and want to learn its internals to be able to maintain it myself. To me X seems a perfect piece of software which just works and does its job flawlessly, while having all the features I ever needed (including remote execution - I used Windows apps running on a remote Linux machine with Wine over SSH over OpenVPN on a local Windows machine and that was very easy).
1. Wayland does support remote execution; see waypipe for an example.
2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).
ARM chips did not exist in the early 90s, and compositors weren't the norm either. Current integrated graphics processors are optimized for a very different landscape. A typical X setup also includes a compositor to mitigate screen tearing.
Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.
The first ARM dates to 1985. I don't know if there was ever an X11 server for Acorn RISC-OS, but there were for similar era Amiga's. But that misses the point, which was that current era ARM chips are orders of magnitude faster than the old 68k family Unix terminals and 486's I ran X on through much of the 90's.
You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower, and where the blitter capabilities of what passed for GPUs had a throughput magnitudes slower than what my cellphone has today.
I am only familiar with ARMv7 and later, which come with graphics chips optimized for for something different than what X was built for. In my own tests and from others who have tried the same, DWM & Co were noticeably slower; I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines.
The difference will widen as Vulkan support in Wayland compositors seems to be outpacing the X equivalents; modern GPU development is starting shift away from OpenGL
What are, if any, use cases where one would need a compositor? Other than transparent window decorations, wobbling windows and overlay dock? These are kinda cool but not worth any additional complexity or hardware resources IMHO.
I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.
If you try scrolling in a web browser, especially fast scrolling in small increments, you're likely to experience screen tearing or other problems in the "smoothness". Compositors are included by default on most X desktop environments primarily for this reason.
The delays and latencies for me have been noticeably lower when using Sway on ARM, which is quite surprising because I was expecting the opposite. I hadn't even tuned it for low input latency yet.
Screen tearing is largely a software issue anyway - the moment you have hardware capable of double buffering there's no excuse for it unless you don't have sufficient memory.
Have you tried playing a video? Or moving a window around fast? Without a compositor there will be tearing on X. With a compositor, X is just a useless middleman.
Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here:
>The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions:
I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :)
> WHAT IS YOUR ROOT?
A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though.
The X protocol is messy in places, but Xlib is far worse than necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value.
So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better.
There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach.
In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients.
EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.
The problem with pure reimplementations of XLib in other languages is that there's no way they can use the client side X extension libraries that are based on XLib.
I learned that the hard way when trying to figure out how to use Display PostScript with CLX in 1992, which is an X client library written in Common Lisp.
Few people still write applications directly to XLib, but many do write applications directly to toolkits and libraries that DO depend on XLib.
So we're all stuck with XLib from now until eternity. If you replace it, you lose the entire ecosystem of client side extension libraries, so you have to reimplement them all from scratch.
At the time, that was a no-go if you wanted to use Adobe's proprietary Display PostScript extension, which was quite popular and included with most commercial X11 servers of the era. Even if most important X extensions are open source, how about about them NVIDIA drivers?
Display PostScript is simply an old example from 1992 of what I mean, that I wanted to use from Common Lisp via CLX, but couldn't. But it shows how this problem has been around for a long time, and is never going away. The only viable solution was to dump CLX and call XLib and the Display PostScript extension libraries directly from Lisp through a wrapper layer.
But now the problem with clients and toolkits depending on X11 extensions is much more entrenched, not just limited to high-end exotic graphics-rich apps that want to use Display PostScript to draw a nice pie chart.
That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries -- just to measure the display, shape windows, listen for input, memory map pixmaps, and composite the first pixel on the screen -- because they've long since abandoned X11's horrible old built-in pixel-based rendering API, broken font model, leaky input system, etc, and switched to using full stacks of X11 extensions (via their XLib based libraries) instead.
You think this is bad? Just look at a native Wayland "Hello World" client [1]. This doesn't even print hello world. You have to do the text rendering yourself. And you need at least 500 more lines to implement the equivalent to a simple XGetImage() call.
Your toolkit should abstract all that away. We have these wonderful things called dynamic libraries, that X was designed for a world without because they didn't exist under Unix yet.
Waypipe ships client-rendered images across the network; datacenters would fall back to software rendering because there’s no way to take advantage of a user’s desktop GPU. I think the industry will continue moving to Javascript or Wasm apps as the most widely portable and accelerated remote display system we have.
Also, in X terminology, the server owns/controls the display, the client is the app that wants to draw a window on the server’s display. The classic architecture would be client telling server what to draw, but these days what really happens is that clients draw locally into a buffer and then tell X server to draw the contents of the buffer.
That’s been tried, but most toolkits stopped doing that because it was unreliable, slow, and the number of primitives offered by X wasn’t sufficient for any modern GUI.
It is relatively easy to write an X based window manager that is actually usable. So the article could not exist in a Wayland context ... and it is not at all clear what framework will make Wayland usable in such a simple and straightforward way or if one is even possible.
I was under the impression Wayland on FreeBSD required a lot of patching on their end, but this has been merged upstream? If so that's pretty good news.
Also good news re colour management. The last I heard about this was Drew DeVault (and I'm paraphrasing) calling it "precious horseshit".
Fedora, Ubuntu, OpenSUSE, RHEL/Rocky, and Debian all have their default desktops on Wayland. Both GNOME and KDE have already switched and will keep legacy X around for compatibility purposes for another few years.
On the more minimal side to compete with X-based window managers: Sway is very mature and River is turning out nicely. All that's left is an Openbox alternative. I believe there are a few, but I'm not familiar.
Wayland has already taken off; once we get XFCE to switch we should be able to move on.
This is not an organic transition. Major organizations seems to "push" it but there is not much "pull". Compare this to the "transition" from CVS/SVN to git. There was no need to even advertise git. People saw it and wanted it.
The X11 ecosystem is more than just GNOME, KDE and i3 and porting XFCE will not be enough to "move on" (For me it is the small things like Xdotool, Xsel, Xcalib, etc. that are holding me back). Maybe X11 needs to be replaced but Wayland is not the answer. It's just not good enough and because of fundamental flaws of its philosophical concepts it will never be.
Xdotool and xsel have had Wayland equivalents for years: see ydotool/wtype and wl-clipboard.
The reason why major orgs have had to push for Wayland is the same as the reasons they had to push for HTTPS and TLSv1.2, unique passwords, keeping software up to date, etc: using outdated and insecure software with significant attack surface has real costs even if it's convenient.
All "equivalents" you mention have less functionality than their originals and some only work on specific compositors like wlroots/sway. Like all things Wayland it's a mess with zero benefits for the user.
HTTPS vs HTTP is a false equivalent. HTTP works just fine like before. X11 can be made fully secure (e.g. QubesOS does it) but nobody uses it because there is really no need on a FOSS system where 100% of clients you run are trusted.
Qubes devs are in my experience the most vocal X detractors. They had to work around X's inherent lack of isolation by using a Xen mechanism. The equivalent would be putting a wooden chest in a safe to show that wooden chests are secure on their own.
HTTP also doesn't work as well as it did before: Chromium and Firefox have begun rolling out an HTTPS-Only mode that warns when visiting HTTP pages. The landscape has also gotten more hostile: many telecoms have been caught modifying unencrypted traffic. Vodafone was also caught HTTP CSP headers for ad injection.
Firefox devs have expressed interest in removing HTTP-specific logic from FF in the distant future too, with the HTTPS-only mode being the first step. All current browsers have also disabled obsolete TLS/SSL versions, which broke several sites during the initial rollout.
There is no such thing as a trusted client; plenty of FOSS has exploitable vulnerabilities. Rather than "trusted and untrusted" software, the cybersecurity crowd has shifted to thinking in terms of "untrusted and untrusted+malicious".
There's also a reason why software audits typically have their moment of truth during binary analysis, whether or not source code is available: source code is only part of the puzzle. Runtime behavior is influenced by the toolchain behavior, host OS behavior, shared libs, and a ton of other variables that are collectively harder to audit than a black box binary. FOSS' reasons for existing should be primarily related to freedom rather than security. I don't copyleft my work because it improves security, but because it protects users from further infringements upon their freedoms.
I'd suggest chatting up a security researcher or reading some material on modern approaches to exploit mitigations (source availability is not a replacement for exploit mitigation); I could give you some starting points when I wake up if you're interested.
When your solution to "make something secure" is to isolate instances of it in airtight sandboxes, IT IS NOT SECURE.
Theoretically Xorg can be made fully secure: just isolate clients so they can only receive events and bitmap information from windows created on the same client connection. It would be relatively straightforward, if quite involved, to implement.
But nobody wants to implement it because everyone qualified to do so has jumped ship to Wayland. The X architecture is so fatally flawed that the most straightforward way to fix it is to start from scratch, and that's what Wayland is.
X is like global warming: one hundred percent of the people who are in the least wise knowledgeable agree that it is a problem. Unlike global warming, however, that problem has a fix: Wayland.
So just... shut up with the irrelevant bullshit and use Wayland, like all the Linux graphics maintainers and distro maintainers want you to do and have been telling you to do for years now... or find your shit unsupported.
Bazaar style development can’t really transition in such a fast way as cathedrals can. While in case of apple, simply declaring that this framework will be the default from the next release on is enough, linux doesn’t work like that. It is a slow transition, but it already has enough momentum behind it.
There are a lot of smaller projects that lack the resources for the Wayland transition.
I'm a happy Mate user and while there is ongoing work to move towards Wayland, it will likely take several years to complete.
So for the time being I keep X11 dear to my heart, and to be honest I'm not sure what I'm missing with Wayland (expert apparently problems with screen sharing applications that have not been updated to Wayland yet …). X11 + Compiz work fine for me.
I think most smaller project will transition automatically once their widget toolkit is ported. For the cases where this does not happens, xwayland is working well enough.
2. While it appears that Wayland is poised to replace X11 on Linux desktops given the amount of backing Wayland has compared to X11, it is not clear whether Wayland will replace X11 in the BSD ecosystem. According to the FreeBSD Wiki, Wayland is not ready to be a daily driver (https://wiki.freebsd.org/Graphics/Wayland), though work has been done getting Wayland compositors and other software to work on FreeBSD. I use X11 on my FreeBSD desktop. I'm unfamiliar with the current status of Wayland on NetBSD and OpenBSD. I expect X11 to live on for quite some time in the BSD world and among more conservative Linux users, similar to the situation regarding systemd in the Linux community, which was adopted by mainstream distributions and users but faced (and still faces) opposition from some users.