
Lubuntu Development Newsletter #9 - kbumsik
https://lubuntu.me/lubuntu-development-newsletter-9/
======
mixmastamyk
Interesting for a dist focused on resource constraints to be using the
new/shiny instead of old and small.

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.

~~~
dunpeal
Is it a fact that X is "smaller" than Wayland, and more resource efficient?

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.

~~~
mixmastamyk
In the sense that I first used X on Linux on a 486 in the early/mid 90's. It
was snappy then and snappy now.

Also I like being able to minimize crashed windows, something other major OSs
haven't done.

~~~
acdha
> Also I like being able to minimize crashed windows, something other major
> OSs haven't done.

What major OSes besides Windows and Mac OS did you have in mind?

~~~
cptskippy
Given that he referenced a 486 he might be referring to earlier versions of
both.

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.

~~~
acdha
The OP comment wasn’t specific on timing - it sounded like a description of
the recent era but if so wouldn’t be accurate unless you go back to the turn
of the century.

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.

------
asplake
Maybe I’ve been hiding under a rock or something but I don’t think I’ve heard
of Lubuntu before. I took a quick look at the home page but still: when this
and not some other distribution?

~~~
ekianjo
it used to be aimed at 10 years old hardware. Now its less clear, they just
changed their positionning a few months ago

~~~
abricot
Not very smart of them. In mu LUG we usually suggest Lubuntu for those PCs
that are a bit older. Now I don't see what the point is. Most would rather run
MATE than LXDE if there's no difference.

~~~
ekianjo
Yeah, when a project loses a clear message, it's more likely to die a slow
death than anything else. However, they did point out why they made that
change: even recent distros could actually run very decently on older
hardware, which made them lose their former "edge" on that matter. Personally,
I think LXDE/Lubuntu is obsolete. Xfce/Mate can be very good replacements with
low footprint these days.

~~~
sha666sum
> Personally, I think LXDE/Lubuntu is obsolete.

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.

------
jchw
My only real issue with Wayland is that I don't think anyone has given real
thought to heterogenous graphics card configurations, GPU hot plugging,
Optimus, etc. X11 is not much better, but people have at least built hacks for
it at this point.

It does seem like heterogenous DPI with multimonitor will be possible to a
degree so that's nice.

~~~
emersion
Heterogenous graphics card configurations can be supported on Wayland (e.g.
Sway 1.0 supports them). GPU hot plugging could be supported by compositors as
long as you don't need the compositor to change the GPU it's rendering on
(it's just not clear how this looks like API-wise -- and it's very difficult
to obtain hardware setups that support those). Clients could then be restarted
to use a different GPU. Wayland is not not limiting factor here.

------
jacob019
Will x11vnc still work with Mir? If not then how will I remote in?

~~~
emersion
No, it won't work.

There are some possible replacements (e.g. [1]) but it's still a work-in-
progress.

[1]: [https://github.com/swaywm/wlr-protocols](https://github.com/swaywm/wlr-
protocols)

------
70122-_6
If I am not mistaken - I'd say the standard specs for Lubuntu on a Mini PC are
exactly the same a those that were discussed for -UbuntutV (yes there's a
subreddit).

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](https://www.canonical.com/projects/ubuntu/unr)

' Its a revo-70 by the way.

------
zzzcpan
Weird move. X is a big reason I and probably others use Lubuntu. It's not
bloated but still compatible with everything and therefore easily configurable
and personalizable. For example, I have xbindkeys for keyboard shortcuts with
a bunch of scripts that use xprop, wmctrl, xdotool, etc. Wayland breaks those.
And if mandatory, it will definitely force me out of lubuntu. Gnome flavor
dictatorships don't work for lubuntu.

~~~
emersion
>It's not bloated

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...](https://github.com/swaywm/wlr-
protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml)

~~~
zzzcpan
I meant Lubuntu as not bloated. I'm fine with X11 bloat compared to Wayland,
given that I can't even use Wayland with most things I do everyday.

------
exikyut
I wonder when Debian, SuSE, et al will do this too.

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...](https://cgit.freedesktop.org/xorg/xserver/commit/?id=7d2543a3cb3089241982ce4f8984fd723d5312a1))
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](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](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.

~~~
emersion
>Wayland, on the other hand, is just a compositor.

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.

[1]:
[https://github.com/swaywm/wlroots/pull/841](https://github.com/swaywm/wlroots/pull/841)

~~~
exikyut
> _There a multiple compositors (GNOME, KDE, Weston, Sway, etc) implementing
> the protocol differently._

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...](https://blogs.igalia.com/dape/2018/03/21/updated-chromium-
legacy-wayland-support/) 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.

------
Filligree
So... does XWayland work for Nvidia yet?

~~~
emersion
I've seen some Xwayland patches to make the proprietary NVIDIA driver work in
compositors that support it.

Mandatory link to NVIDIA rant: [https://drewdevault.com/2017/10/26/Fuck-you-
nvidia.html](https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html)

