Lubuntu Development Newsletter #9
lubuntu.me
lubuntu.me
Perhaps W is more efficient?
> Q: Why are you switching to Wayland? A: The X implementation is old and won’t be updated to address the way desktop Linux is used today. Window managers are an afterthought, and many things aren’t implemented correctly. Wayland is a modern take on the Linux display system.
Would have liked if this was expanded on a bit. Using X on 18.04 now and while not perfect (in the security area) nothing else about it is currently holding me back.
X was designed with far more ambitious goals than Wayland, so it's not a foregone conclusion that it's "smaller" (implying cheaper) just because it's older.
Also I like being able to minimize crashed windows, something other major OSs haven't done.
This is not to say Wayland is good, X Forwarding is an awesome feature and X runs probably can now run on a literally toaster.
Hi-color might be somewhat compelling, though I write text files for a living. Does X not support it?
It technically should, but there's no official page that says it does (and in which combinations) and then there's the question if the DE and other software Linux does. It all in total has a probability of breaking, combine a few rare features and it's pretty much certain something will break. It would be really awesome if say phoronix tested all of those features out in every combination :D
What major OSes besides Windows and Mac OS did you have in mind?
Prior to Windows XP (possibly NT/2000) applications using GDI wrote directly to video memory and if one crashed it could create a black hole on your screen. I believe Windows Vista was when Microsoft introduced true off screen rendering and added GPU based composition of the desktop. GDI/GDI+ are now considered legacy and the issues the OP described aren't much of a problem anymore.
I believe Quartz is the OSX/MacOS equivalent to GDI on Windows however it's been less problematic than GDI and I believe OSX was launched with off screen rendering and composition that made the issued described by the OP impossible. I have no idea of OS9 or prior versions performed desktop composition.
OS 9 was similar to old-school Windows with direct memory access. Users of either definitely were impressed by the stability of newer systems – Windows NT was a big jump, which OS X matched with minor improvements, and something like BeOS was truly impressive for being able to seamlessly recover from most driver crashes by restarting the entire display subsystem, which IIRC Windows took another decade and a half to match with Windows 7.
I could be anywhere from completely right to utterly wrong on this so take it with a grain of salt.
> So Windowing environments like Wayland have a distinct advantage over X when it comes to performance.
I haven't seen numbers myself, but you can't simply assume that. Programmer-millenia of work has gone into making the various implementations of X11 efficient.
This statement doesn't really make sense. Wayland is just a protocol, and you can build bloated compositors on top of it -- just like you can build really tiny compositors [1]. xorg-xserver on the other hand will always have the same level of "bloat".
>X was designed with far more ambitious goals than Wayland
This is hard to say. Wayland has been designed to be flexible enough to allow for a clean base that can be used in mobile UIs, IVIs (e.g. plane UIs), VR and so on (without hacks).
[1]: https://gist.github.com/SirCmpwn/ae4d1cdcca97ffeb2c35f0878d7...
If we're splitting hairs here: X (i.e. the X11 Window System) is also "just a protocol".
And in fact, when you e.g. open Gedit, hundreds of messages are exchanged on X11 (getting/registering atoms, changing window properties, etc). Wayland is much more efficient in that regard.
Which is what I implied in my original comment...
Of course, the resources are ultimately consumed by implementations, not protocols. But it helps when the protocols are efficient.
The older protocols tried to encode way too much framework-like application implementation details which turned out to be a mistake. And in both cases, the framework layers (GUI toolkits, game engines) ended up reimplementing most of that logic but better, leading to lots of unused cruft and problematic architecture in the lower layer.
What "framework-like application implementation details"? I came to X development from Windows development, and the first thing I noticed was the lack of stuff bare X provides. X doesn't even have timers, let alone a standard notion of how to display a button or text box. It's very bare bones and minimal, and you can learn most of it in a weekend. (I know, because I did.)
Game engines need OpenGL to work, so no surprise they reimplemented much of the rendering layer. GTK is maintained by fucking GNOME developers who run screaming at the sight of old code they have to maintain, so reimplementing fucking everything is par for the course for that crowd. If Wayland ever settles down and becomes usable, within a few years the GNOME team will be lamenting how old and crufty it all is and making plans to replace it with an even newer graphics stack.
EDIT: X actually does have something like timers, in the XSync extension.
They mentioned "the old protocols". Xlib is not a protocol. And it's not a framework either.
> And as mentioned elsewhere targeted at 80's and 90's hardware.
Yeah? And?
The DEs that are targeted at 2010s hardware have compositing-latency issues, slow animations, and seem to have trouble making it clear what can be clicked on. I know because any time an article about the Windows 9x UI comes up, Hackernews goes on a nostalgia-tinged, but justified, rant about how great that UI was and how easy it was to read what can be interacted with and how. Maybe the 80s and 90s got a lot right in terms of UI, and constant UI churn just isn't necessary.
Besides which, if you can build a UI that could be run on a 90s PC, it takes up far fewer resources than do the UIs of today, and that's compute that you could devote to better programs. And Xorg accelerates the old X and newer Xrender primitives with the GPU anyway, through GLAMOR, so it's not like you're not taking advantage of it.
The space taken by X cruft is not worth mentioning today.
Lubuntu has shifted focus recently https://lubuntu.me/taking-a-new-direction/
Wayland is smaller and follows the Unix philosophy much better than X. X has gotten insanely complex with all the workarounds necessary for a modern desktop. It tries to do far too much, and not well, so all the other parts replicate much of X's functionality. Wayland was actually started by X devs who felt it needed a reboot.
I fear that the switch to Wayland will slow down experimentation in the field of window management, because it makes it hard to quickly do something different. Which would be ironic given the goals of it.
I suppose this is precisely why the project is changing direction. LXDE/LXQT are pretty cool desktop environments and I'd hate to see their development come to a halt even if I'm personally not a user.
Same reasons one would use Kubuntu or Xubuntu.
Maybe Lubuntu folks can put up one page on comparing the disk space requirements for standard default setup between Ubuntu/KDE/Xbuntu/Lubuntu - for typical VM.
Or any other advantages for using Lubuntu.
It does seem like heterogenous DPI with multimonitor will be possible to a degree so that's nice.
There are some possible replacements (e.g. [1]) but it's still a work-in-progress.
But the guy in charge never wanted to do Lubuntu-mini, although but Ubuntu Netbook remix finished eight years ago.
https://www.canonical.com/projects/ubuntu/unr
' Its a revo-70 by the way.
X11 has a big number of issues. Security, very complicated mechanisms (like how clipboard is handled), HiDPI are some of these issues. X11 _is_ bloated (for instance it has an drawing API).
It's not like Wayland makes things that were possible on X11 impossible, it's just that replacements for everything don't exist yet. For instance there's no standardized way to make panels/docks/notification daemons. Same goes for screenshooters and screen recording. We -- the wlroots developers -- have been campaigning to push new protocols to bridge the gap. For instance the layer shell mentioned in the article is a protocol we try to standardize [1].
[1]: https://github.com/swaywm/wlr-protocols/blob/master/unstable...
XWayland will probably still sit around for a very long time even beyond that point though. Time will tell how hilariously it gets integrated.
I'm especially glad the video driver situation means X will hang around for a long time. I'm currently learning the X wire protocol and what I find the nicest about it is its eminent hackability.
Wayland, on the other hand, is just a compositor. Seems comparatively boring, from the perspective I have (as an outsider who has dubiously picked through some poorly written documentation that doesn't inspire much confidence). Compositing chews more (system!) RAM, too; an X client doesn't need to allocate any memory of its own, only the X server holds the actual image of the window in memory (GPU memory obviously, and if you're using compositing, main memory as well).
Yes, X has a thousand bugs. Yes, it would fall down a hundred times a second if it were actually possible to feed it into afl. Yes, I had it deadlock on my laptop (when running a program through xtruss and xterm tried to print too fast). Yes, I'm still yet to enable XF86Ungrab (introduced in 2010: https://cgit.freedesktop.org/xorg/xserver/commit/?id=7d2543a...) so I can fix broken grabs (at least the most recent one that happened this morning - when NFS momentarily timed-out right bang in the middle of me clicking in a menu bar and the menu [window] actually opening).
Yes, XKB needed an XKB2, and then XI, and then XI2, because nobody thought we would need more than 256 individual input buttons (mice sometimes eat 30 keys from X's perspective...). DRI needed a DRI2 and then DRI3. Yes, Xinerama is actually named PanoramiX and not even used anymore thanks to RandR 1.2 ("RandR 1.2 enabled, ignore the following RandR disabled message." ... "RandR disabled"). And that's not even mentioning XFIXES and XC-MISC...
About 4-5 days after starting on poking the X protocol specification for the first time, I crashed into https://bugs.freedesktop.org/show_bug.cgi?id=107568, which was highly amusing. I think that's been in there for 27 years. Not sure whether to call it a leaky abstraction or a case of "someone forgot their mechanism-over-policy hat that day", or both. But anyway. Not a critical bug, but a good illustration of poorly thought through design and implementation.
I'm sad to see X die. Not from the it's-so-terrible standpoint; from that view, sure, yeah. But nostalgically speaking, it's older than I am :) and I guess it's sad to see things move on after having existed the way they are for so long (it's {h,cl}ung on for 30 years).
I know, I know, it'll exist as a legacy component for the next 20 years. But that isn't the same as "nobody uses Perl but it's always installed anyway because some random init-time thing might call it." You can't just "call X". Having X floating around in the form of Xwayland is very similar to XQuartz; as a legacy component, I can see a status quo developing where the integration is subpar, but the situation isn't annoying enough for the people with the "social commit bits" to be insufficiently annoyed to fix it. Hopefully the integration is well-designed and keeps up with the times, at least on 2D screens with keyboards and mice.
I wonder where Wayland will be in 15 years.
Same for X. It'll be interesting.
As an OS evaluator, I just wish Linux would stay still. Design things properly the first time (and actually put the time and effort in)! Hopefully Wayland doesn't have to change anything major for at least 20 years. (Why do I cynically expect it to have a tangle of circular dependencies on systemd and dbus within 10. :/)
As a power user/sysadmin, I am _not_ looking forward to having to fuss around with Wayland and get it working. (I mean working _properly_.)
As an end user, I hope I don't actually have to put my sysadmin hat on at all.
As an inveterate tinkerer who likes hacking things in the true sense (finding interesting ways to reuse things :D), I'm sad because X is fun to figure out. (Try it.)
From the perspective of a UX designer who likes building efficient integrated software, I have to sadly reiterate a comment I made 2 years ago (before I accidentally locked 'i336_): https://news.ycombinator.com/item?id=13334053
> I'm really sad X11 is legacy software myself, as an aside. It's a disaster, sure, but now we have one more layer of "uhhhh..." for all the UX-types to get scared away by: it used to be "(WinAPI) vs ((Qt)/(GTK+)/(Xlib/XCB))", which was embarrassing enough; now it's "(WinAPI) vs (X11((Qt)/(GTK+)/(Xlib/XCB))/Wayland((Qt)/(GTK+)/(???)))" which is just plain annoying for low-level graphics hacker wannabes - I can make a WinAPI app in C that opens a window in a few KB, where as to do that in Linux now I HAVE to support XCB and also write my own tiny UI for Wayland.
I guess this is the major point of my tired rant: I wish I could wet-fish all of Linux and yell something along the lines of "stop increasing the surface area developers must target!!!! Backward compatibility is not developer responsibility!!", but I can't, because Linux is a bazaar, and everyone is too busy trying to compete for the most amount of responsibility they can elegantly juggle.
I recently learned that OpenBSD has a kernel-level debugger. That's really nice, and something that I've wished Linux would have had for a long time. I mean it makes so much sense - "the system's panicked, here, poke the hardware registers!" versus "and here we have a module that borrows 114 bytes from your real-time clock to write a hash of where the boot process is up to (and here's the accompanying tool that bruteforces what the hash even means), and over here we have some code that tries to print a QR code to the screen, oh and this module configures a TTY over the EHCI debug port, and over here we can set up early consoles over Ethernet, and...", and in the end you just give up and order/find legacy-compliant machines with RS232 headers hiding on the motherboard.
On that note, that reminds me, OpenBSD is probably going to keep X hanging around for a long time. But that doesn't say much about driver support going forward.
Hmm, I just poked around looking for licensing info for the Intel "Linux" drivers. They appear to be MIT (!), reading random files from
https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/Makefi...
https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/...
https://cgit.freedesktop.org/mesa/drm/tree/intel/intel_debug...
And, conversely, I was very fascinated to see that this liberal license has already lead to exactly the kind of thing I'd have hoped for - perusing the history of a randomly picked file, https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/dr..., I see:
> Update inteldrm(4) to code based on Linux 4.4.70.
...
> Update inteldrm to the code from Linux 3.14.52 ...
...
> Make use of recent drm_linux.h additions to further reduce the diff to linux.
...
> use linux style memory allocations in shared drm code
...
> Switch generic drm modesetting code over to Linux-style negative errno return values.
That's very very cool. GPL was never that productive. :P
With OpenBSD's Xenocara fork, X'll still be around for a while. (Uh, as an aside, shortening "X will" is weird, lol.)
Apparently it can work with the R3xx series chipsets, but mine doesn't like it for some reason.
Wayland is _just_ a protocol. There a multiple compositors (GNOME, KDE, Weston, Sway, etc) implementing the protocol differently.
>I'm sad because X is fun to figure out.
I'm currently implementing the drag-and-drop protocol in our Xwayland WM [1]. Trust me, this is far from being fun. Very far, it's not even funny.
>I can make a WinAPI app in C that opens a window in a few KB, where as to do that in Linux now I HAVE to support XCB and also write my own tiny UI for Wayland.
Sticking to broken old standards is not going to be the solution. We have to move forward. There are many embarrassing things in X11 -- Wayland gives us an opportunity to start from scratch.
Genuine question. How can I run a mixed environment, then? I can mix and match Qt and GTK apps without any thought in X, and furthermore, I can run Metacity with Plasma, or KWin with one or more gnome-panel instances. (If the processes are still named like that... it's been a while, heh.) Yes, in practice, I will admit I wouldn't probably do that, but the kind of flexibility - that expansive upper bound - is what lets me also go to the other end of the extreme and set up a lightweight environment that does function exactly the way I'd like it to.
I'm a bit scared of "implementing the protocol differently." Meep. How differently? After having read a bit, I see that Wayland is standardized, but still - how well will things interact, in the worst case scenario? With X, it's "...ooookay, so my dock has decided to acquire a titlebar, and I can resize and move it around the screen. This is... nice?" - but with Wayland, would things not appear on the screen at all, for example, or would my session [choices] be genuinely unusable [together] at all?
> Sticking to broken old standards is not going to be the solution. We have to move forward. There are many embarrassing things in X11 -- Wayland gives us an opportunity to start from scratch.
Pragmatically - not nostalgically speaking - I do completely agree.
I actually just stumbled on https://blogs.igalia.com/dape/2018/03/21/updated-chromium-le... and learned that Wayland has been running webOS in LG TVs for the past 4 years. That's truly impressive, I didn't know that.
I'm really impressed that Chromium and Firefox both support Wayland now, not to mention GTK and Qt.
It's going to be interesting to see how things go over the next few years.
> I'm currently implementing the drag-and-drop protocol in our Xwayland WM [1]. Trust me, this is far from being fun. Very far, it's not even funny.
I see. I had a look at some of the linked issues. It doesn't look particularly fun, yeah. It's very important work though, very cool.
I also just discovered what wlroots actually is, which looks rather interesting too. Something I know will need to exist at some point is the Wayland equivalent of Xvnc, aka a headless display surface that "displays" solely via VNC. This would be a good building block for that.
Poking around has helped me understand the Wayland model a bit better, thanks.
--
One question that immediately comes to mind about Wayland is how well I could "warp" Wayland clients from one backend to another (within the unbroken constraint that both backends remain on the same machine), without closing/destroying the client first. The purpose being a) to move windows between isolated/disparate video heads (should be achievable with a compositor.....), b) to move clients between an actual video output and eg an Xvnc-style headless backend, and c) to restart the compositor or upgrade the video driver (in some future world where graphics drivers are livepatch-aware), without a session restart. This would probably be viably implementable with a thin proxy layer (which does 0.1% protocol decoding, passing the rest through transparently - perhaps even via a SHM LFQ or similar). Implementing this proxy, and adding some things to the spec that momentarily "puts clients to sleep" to avoid difficult side effects with queued instructions, could be interesting.
Q: What about people with NVIDIA graphics cards? A: More details to solve, but the plan is to get this working with those graphics cards by that time.
Mandatory link to NVIDIA rant: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html