Mir’s next steps – we need your input
community.ubuntu.comAt 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.
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.
"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
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.
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).
I am not close to the Gnome community, so could somebody aware of the context tell us how serious/realistic/close-term this ideas page is?
It's serious, but it's only a proposal, very a recent (~10 days old) one at that, so there's no code yet.
https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Sh...
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?)
> 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.
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.
Canonical will use Mir on other platforms, I am thinking like the screens that show advertising in Malls or touchscreens that display info and you can interact. from what I read Canonical does not intend to change GNOME too much , only fix the major complains, if they wanted a better system from the code molecularity point of view they had the chance 2 times to use KDE as a base.
> Malls or touchscreens that display info and you can interact.
Why would that require anything new? I mean, Canonical is in the server OS business mostly, right?
If you have a terminal that needs to run just 1 app then why use Gnome or other DE? you would need to run a minimal display server and start that only application.
Use the Weston full-screen shell. No need to invent a new Wayland compositor for that, and certainly no reason to have multi-display-system abstraction like Mir seems to have.
You would still have to fork it though if you need to add missing things, like how now Gnome and KDE implement in different ways how to grab screenshots. The fact that smaller DEs are creating their own libraries and not use Weston indicate to me that Weston is just a playground for Wayland where they test their ideas and experiment and it is not designed to be used or extended, I may be wrong though, there are some blog posts from the authors of Sway and others that work on adding Wayland support to different DEs. Why do you think Sway, Gnome, KDE and others can implement what they want but Canonical or volunteers can implement wayland on top of Mir but have to use Weston or Mutter ? Do you think everyone should Weston or Mutter?
We run a kiosk thing, use i3 without a status bar, directly launch the program from the xinitrc (or whatever script, which launches i3 in the background, sleeps 1 second, then launches the kiosk thing), and all this via startx.
If the script exits, X exits, systemd restarts it. Works pretty well.
No, Weston is pretty much the reference compositor for Wayland.
I tried it. It .. does nothing. Maybe there are/were reference implementations for the protocol extensions too?
What do you mean by "nothing"? Weston includes a usable desktop shell by default. Without virtual desktops, but with a panel.
Case in point, there was no exit. I had to switch linux terminals and kill the process, because even though I was able to launch the terminal (let's say xterm), but I had no idea how to stop the weston session.
Looks like it's Ctrl-Alt-Backspace. I personally never use exit features though, I always switch to the terminal I launched the session from and press Ctrl-C.
So Mir will become a Wayland compositor?
Yes
:’’( 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
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.
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
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.
“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
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.
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
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.
Wayland is a protocol, Mir will use this protocol, I think you are not uptodate with what is happening here.
What does Mir offer compared to Weston? It still sounds pretty NIH.
Nobody uses Weston, Weston is like the reference thing, each DE is implementing their own compositor. Some DE like Mate hope they can use Mir and so get an easy way to add Wayland support. Ubuntu uses Gnome now so they use Mutter for wayland, Mir would be use for IoT and other non desktop platforms nd there is the possibility that others DE would use it.
I don't think the guy who posted this works for Canonical at the moment. If he does, his launchpad page is very sparse compared to other employees. I'm not saying that to disparage him in any way, but because it would make it incompatible with a not-invented-here syndrome.
I think Mir should be looked at as an independent project now. I might be wrong, of course, but that's the impression I have.
https://github.com/MirServer/mir/commits?author=gerboland https://launchpad.net/~gerboland https://www.phoronix.com/scan.php?page=news_item&px=Mir-Now-...
Even given that Mir is independent, it sounds like people are continuing to work on it because they have already invested in working on it. I've yet to hear of any users.
I agree, I'm not saying it's useful in a sense other than academic/historic. I was only reacting to "NIH". I guess you might be arguing that Mir continues as a consequence of nostalgia from an original not-invented-here syndrome.
I won't argue with that :-P
That said, if the guy who posted this is not employed by Canonical (like I speculated), and has _never_ been employed by Canonical, I would like to further speculate that either (a) he's doing this in order to specifically gain favor with Canonical employees and increase his chances of employment there later, or (b) to increase his chances of employment at any of the "big Linux players", or (c) to increase his knowledge of the X/wayland ecosystem and C coding in general.
All of which sound like good investments on his part.
Anyway that's speculation upon speculation, obviously, but if I was a professor at a generic I.T. bachelor/masters, this is exactly what I'd tell my students to do in their spare time (and if they could weave it into related classwork, all the better obviously).
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.
I hardly think that Mutter is the be-all and end-all of Wayland compositor performance. I could see Ubunu plumbing a re-moulded Mir back into their distribution further down the line (while keeping the rest of the GNOME environment). I'm not certain on the technical details, but I believe this should be possibly; for Wayland was certainly designed with compositor agnosticism in mind.
Edit: reading further, it appears that GNOME Shell is quite tightly woven into Mutter, which may well complicate matters.
GNOME devs realized already that they have problems with the current architecture, I think X got the blame though this time too, so they plan a GNOME4 version, I do not know if they started coding it or are just in planing phase.
They can't replace something with Wayland because Wayland is a protocol and interface, Mir needs to implement code to speak that protocol.
OK, then they are replacing the compositor and changing their client, rewriting it to talk in Wayland protocol.
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.