
Mir’s next steps – we need your input - rippsu
https://community.ubuntu.com/t/mirs-next-steps-we-need-your-input/2140
======
AdmiralAsshat
At the very least, get Mir to the point where it's a drop-in replacement for
Weston, the reference Wayland compositor. Then make whatever changes you feel
like on top of that. If Mir becomes included in DE's across various distros,
and if it becomes a runtime option when launching a session (in the same way
that GNOME now lets you choose whether to run a Wayland or Xorg session at
login), people will be able to A/B test Mir vs Weston, they'll send feedback,
and the improvements can be upstreamed.

That's all I ask. The backlash against Canonical was in leveraging the Open
Source community to make increasingly silo'd services. Canonical is moving in
the right direction, first in discontinuing Unity in favor of GNOME, and now
in making Mir Wayland-compatible. I hope the trend continues.

~~~
majewsky
I think there's some misunderstanding in your comment about how Wayland works.
99.9% of Wayland desktops out there [1] do not use Weston. Weston is not
Wayland's display server, it's a reference implementation of a window manager
implementing the Wayland protocol(s). There is no separation between display
server and window manager in Wayland, only a single master process, the
compositor, which fulfils (roughly) both these roles. So if you're running,
say, KDE Plasma, then your compositor is KWin, and Weston is nowhere to be
seen. If you're running Sway, then your compositor is Sway. And so on. Wayland
is only a protocol, not a piece of software (unless you count the shared
libraries provided by the Wayland project).

[1] Guesstimate.

------
bwat49
"This is where server/compositor/window manager and panels/docks/desktop are
all in a single process."

This sounds like gnome-shell, and it's atrocious. It's unresponsive and laggy
under any sort of load, even the mouse cursor skips around

~~~
GuiA
From _" Seven Laws of Sane Personal Computing"_:

 _I – Obeys operator

The operator shall retain full control of the machine at all times._ In
particular, the handling of the keyboard, mouse, and other human interface
devices must take absolute priority over all other processing. _The operator
shall have the ability to issue commands and receive immediate confirmation of
said commands at all times, regardless of system load._

[http://www.loper-os.org/?p=284](http://www.loper-os.org/?p=284)

~~~
majewsky
Off-topic: It's sad how far away we are from sane personal computing (if I may
use these laws as a definition of that term).

------
pas
So X was horrible, because it is very old and blablabla, and Wayland the
protocol got finalized without an actual implementation that people use in
good old design by committee fashion (no?), and for some reason now everybody
writes compositors instead of writing one for Linux in general... I don't
really understand why, can someone explain? (I mean, I know about how Mir
seemed to be regular Canonical NIH symptom, but why are they continuing with
it?)

~~~
erikpukinskis
> So X was horrible

Was it?

I feel like someday someone is going to say something like "Man our VR world
syncing protocol is really heavy, and we end up needing AGI-level LOD
prediction to do it well, but compressing 360 degree light fields is wasteful
and leads to latency artifacts... what if there was a protocol that allowed
realities to render display-space fields directly to remote devices, but do
the final compositing on the client?" and then someone will discover the X
protocol, re-implement it with 3D SDFs instead of 2D rectangles, and all of
the sudden X will be the new hot thing.

~~~
pas
Sure, then let's do that.

I mean X as a client server visual/graphical terminal solution is pretty
amazing.

But then it took more than a decade to get to the point where it seems that
DRI extension is just not going to cut it.

And all the other built-in un-security has to go too.

------
shmerl
So Mir will become a Wayland compositor?

~~~
Laaas
Yes

------
eecc
:’’( the Linux Desktop tragedy continues... umpteenth reimplementation,
failure to address total train wrecks like d-bus and systemd because
politics... and the realization that Windows has probably become a more secure
environment... and Apple refusing to build decent hardware. Wake me up

~~~
vetinari
Systemd is one of these things that brings many improvements... and gets
talked down.

If it was at least criticized constructively, but no, it is something else
than the "traditional" init, so let's just berate it.

And then we wonder, why the Linux desktop is always out of reach, when we
dismiss anything, that helps to drag Linux out of the maze of one-off bash and
perl scripts.

~~~
eecc
No. I’m no init fanboy, I’d have just adopted Apple’s launchd and called it a
day. No, criticisms of systemd are plenty and well argumented, and yet get
systematically talked down. First that comes to mind is the cavalier reaction
to leaving some firmware fs mounted rw because systemd used it during reboot;
didn’t matter uncautios mishaps could brick a device, team just won’t-fix’d
the report and called everyone else an idiot. Doesn’t work like that

~~~
vetinari
Apple launchd is way more limited, and has much narrower scope (single-seated,
single-session desktop). We could talk days about features that systemd
provides and launchd doesn't.

I've seen only single case of criticism of systemd that was correct and
constructive (too bad I didn't bookmark it); I don't count rants that boil
down to "it's different than I'm used to", or "it has broken my broken nfs
config" as plenty or well argumented.

The efi issue was indeed a bug in the devices. If was up to the manufacturer
to fix it, not for other software to maintain workarounds indefinitely.

~~~
eecc
“way more limited” is a feature not a bug! Eventually Systemd will grow a
binary configuration registry, but by then people won’t see the irony of it
any more

~~~
vetinari
It s a bug, not a feature. I like how systemd can reliably track even double-
forked processes, or how can I override only tiny parts of the unit
definition, without having to rewrite the entire unit and thus the original
definition is still updatable by upstream packages. Or how it can inform me,
in what state either the given unit or the entire system is, including last
few lines from the log. Or that there is unified system for unit activation no
matter how they are activated (on startup, on socket, on timer, on demand by
dbus, etc). Or that it can properly solve dependencies among services, and
miriad of similar, small things, that together make a huge qualitative
difference.

Ironically from your snark, systemd uses simple ini files. Launchd uses a
specially bloated xml, because plists.

~~~
eecc
We grew up with different UNIX philosophies in mind. IMHO, even Launchd’s
cron+init+inetd was a stretch, you’re cool with a second OS sandwiched between
kernel and user. Have fun

------
snvzz
Wayland was already there, and there was nothing wrong with it. OK, maybe
there was, but not the bullshit you made up to justify your NiH syndrome
alternative.

Mir was pointless. Drop it. It should never have existed in the first place.

~~~
shmerl
If I understand correctly, they'll drop the server part replacing it with
Wayland. But they'll keep their compositor, which any Wayland based DE needs
to implement anyway. They don't intended it for the desktop, since they are
dropping Unity. It's for IoT and etc.

~~~
simion314
They can't replace something with Wayland because Wayland is a protocol and
interface, Mir needs to implement code to speak that protocol.

~~~
shmerl
OK, then they are replacing the compositor and changing their client,
rewriting it to talk in Wayland protocol.

~~~
simion314
They are no removing a Mir component and add a Wayland component, they
implement the Wayland protocol on top of existing code, maybe refactoring
where it is needed, so Mir could talk wayland and still do the Mir stuff that
is needed for IoT.

