LWN: Comments on "Ubuntu unveils its next-generation shell and display server" http://lwn.net/Articles/541336/ This is a special feed containing comments posted to the individual LWN article titled "Ubuntu unveils its next-generation shell and display server". hourly 2 Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/543427/rss 2013-03-19T16:11:12+00:00 boudewijn <div class="FormattedComment"> Keep in mind that KDE is not a group of a few hundred interchangeable resources that at all times work on all the projects. People work on their own area -- I never, no matter how much the temptation, have worked on kmail, for instance. The superkaramba project likely lost all activity when Plasma started supporting widgets. I don't know who the developers were, or where they went, but that superkaramba bugs don't get attention doesn't mean kwin bugs don't get attention.<br> <p> The kwin team is really pretty active, and pretty responsive.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/543403/rss 2013-03-19T14:44:46+00:00 Duncan <div class="FormattedComment"> While I've not tried the fullscreen thing specifically, kwin's window rules do allow kwin to force many things, including window size and position, border toggle state, etc.<br> <p> Actually, come to think of it I KNOW the fullscreen thing can be forced, as kde 4.10 now includes a kwin scripting ability, with one of the two shipped scripts being a "video wall" script that forces selected media app windows to fullscreen to all monitors instead of just one, when they go to fullscreen mode. So it could certainly deny fullscreening at all, as well.<br> <p> (Of course kde being kde, the activation of this script is a configuration option. FWIW, I turned off the other script, but like this one enough to have patched it to apply to smplayer2, it applied to smplayer, vlc, and one or two others, originally, but not to smplayer2 without the patch, which here on gentoo I apply by simply dropping it in the appropriate /etc/portage/patches/ subdir so it's applied each time I update the app. I should submit it upstream, but I already submitted patches for superkaramba that have just sat on the open bug, no comment or any indication at all that anyone's even read them since I submitted them for 4.5 or whatever, thus years ago. That tends to be a bit of a disincentive to even bother filing any further kde patch-bugs. =:^( )<br> <p> So sometimes the window manager /does/ at least redefines "fullscreen" to suit its own purposes. =:^)<br> <p> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/542043/rss 2013-03-08T13:56:46+00:00 robclark <div class="FormattedComment"> <font class="QuotedText">&gt; Not having to integrate or coordinate with anyone else accelerates development, just as Fred Brooks 8-)</font><br> <p> well, maybe for whipping together a prototype.. for getting something that handles all cases (multi-display, hotplug, various different apps, etc) it is not. In the end we just end up with something that works ok in simple cases but is not as mature/robust as wayland, and everyone loses.<br> <p> <p> </div> Derived distros http://lwn.net/Articles/541952/rss 2013-03-07T23:51:21+00:00 drag <div class="FormattedComment"> It's not like Mir is going to be any time soon either. It's more vaporware then anything else. It's going to take them at least a couple years to get it into usable state to were they can even start thinking about replacing Xfree display server.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541926/rss 2013-03-07T22:10:52+00:00 ovitters <div class="FormattedComment"> That is a terrible summary.<br> </div> Derived distros http://lwn.net/Articles/541900/rss 2013-03-07T20:18:55+00:00 intgr <div class="FormattedComment"> I'm sure that the X.org server will still be available from Ubuntu repositories for many years, it's not like this announcement forces them to change things overnight.<br> <p> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541891/rss 2013-03-07T19:39:10+00:00 dlang <div class="FormattedComment"> <font class="QuotedText">&gt; You wrote: "to move the mouse pointer out of the center of the screen so that it didn't obstruct and distract from the page being displayed."</font><br> so when you clicked on your media player it moved the mouse pointer??<br> <p> There was no mouse or keyboard attached to the machine. There was no media player software running, just firefox viewing a HTML/javascript page.<br> <p> I used a command-line tool (xwit) to inject a mouse movement action into the input event queue<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541889/rss 2013-03-07T19:23:20+00:00 Serge <div class="FormattedComment"> <font class="QuotedText">&gt; Honest questions:</font><br> <p> Don't ask people that like wayland — they will say you that it works. Don't ask people that hate wayland — they will tell you that it's not. Download livecd and try it yourself: <a rel="nofollow" href="http://sourceforge.net/projects/rebeccablackos/">http://sourceforge.net/projects/rebeccablackos/</a><br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541866/rss 2013-03-07T17:13:38+00:00 njd27 <div class="FormattedComment"> Surely the question that should be asked is: when is the Mir project planning to implement remote rendering?<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541861/rss 2013-03-07T17:09:41+00:00 amaranth <div class="FormattedComment"> You can't go fullscreen without the window manager's permission right now anyway, how is this any different? Sure, your window manager never says no but it certainly could (and even force your window size back down if you tried to make it "fullscreen" anyway).<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541847/rss 2013-03-07T17:05:20+00:00 raven667 <div class="FormattedComment"> <font class="QuotedText">&gt; Writing a display server from scratch somehow accelerates their product?</font><br> <p> Not having to integrate or coordinate with anyone else accelerates development, just as Fred Brooks 8-)<br> <p> <font class="QuotedText">&gt; People that have been doing this for years and have a pretty good idea of what a display server (X) should and shouldn't be doing.</font><br> <p> They might be able to get something lightweight that works 90% for their one use case without worrying too much about the corner cases, it's the last 10% to make it robust and complete where the difficult work is. This reminds me of mjg59's criticism of LightDM, by the time you've solved the real-world problems and discovered all the underlying requirements your "lightweight" system has just as much complexity as the "crufty" thing it was meant to replace.<br> <p> So I think they can ship something that pretty much works, but it'll take years to get to the same place that Wayland is today, just like Wayland took years to build, and then they'll have another big of private infrastructure to maintain that takes away time from actually adding value to what they are selling.<br> </div> Derived distros http://lwn.net/Articles/541824/rss 2013-03-07T16:31:33+00:00 tjc <div class="FormattedComment"> The Linux Mint developers have already forked Gnome Shell (and a few other things), so I wouldn't be too surprised if they did the same with Mir, although it would probably be a much more difficult job. Or maybe they will use Wayland instead. Or re-base on Debian, as you say. They have options.<br> <p> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541795/rss 2013-03-07T14:05:27+00:00 el_presidente <div class="FormattedComment"> So, to summarize the comments, nobody knows what Wayland is or what it does but it does it wrong.<br> <p> If its developers don't like the comments on LWN, wait until they see the rest of the Internet. <br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541793/rss 2013-03-07T14:02:27+00:00 dbnichol <div class="FormattedComment"> Writing a display server from scratch somehow accelerates their product? That doesn't make any sense at all. Not to mention that they're now doing this completely on their own now and will receive no help from the open source graphics veterans working on Wayland now like Kristian and Daniel Stone. People that have been doing this for years and have a pretty good idea of what a display server (X) should and shouldn't be doing.<br> <p> If time to market was all they cared about, why not use X? Or why not just fork Wayland/Weston since that code already exists? Or just use SurfaceFlinger? I don't think time to market makes sense as the driver for Mir. It seems a lot more about control.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541791/rss 2013-03-07T13:47:12+00:00 dbnichol <div class="FormattedComment"> I thought the same thing. The only way you get involved in a project, figure out the direction, and eventually try to guide the direction is to show up. I can't think of any open source project where you could have no contact with anyone on the project and feel you had a strong understanding of the its direction.<br> <p> It seems like if the alternative is writing your own graphics stack from scratch, then you probably want to make sure you've got a full understanding of the project you're discarding.<br> </div> Value for money or strategic underinvestment? http://lwn.net/Articles/541783/rss 2013-03-07T13:04:37+00:00 pboddie <blockquote>Now that Qt is in a stable and healthy position, Ubuntu has resumed work on the Qt-based Unity.</blockquote> <p>It seems to me that Canonical could have invested in Qt instead of waiting to see whether some other organisation would pick up the tab.</p> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541771/rss 2013-03-07T11:59:40+00:00 ewan <i>"Yes, Mir made some incorrect claims about Wayland but those were corrected in less than a day."</i> <p> You say that as if it's somehow a good thing - the problem is that Mir exists (ostensibly) because of technical misunderstandings that could have been cleared up in less than a day <b>months ago</b>. Canonical devs just didn't even bother to try - that's the problem. Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541770/rss 2013-03-07T11:47:49+00:00 ebassi <p><cite> > * is XWayland already working?</cite></p> <p>yes</p> <p><cite> > * is Qt/Wayland working?</cite></p> <p>yes</p> <p>I'll also throw in GTK and Clutter to the list of toolkits working under Wayland.</p> <p>there are bugs? sure. are they being fixed? yes.</p> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541765/rss 2013-03-07T11:33:02+00:00 renox <div class="FormattedComment"> <font class="QuotedText">&gt;&gt; I totally agree with you that normal applications should be able to go full screen,</font><br> <font class="QuotedText">&gt; I don't. At least not without some kind of overlay.</font><br> <p> It depends on the situation.. On your home PC, is-it really an issue?<br> To fool you into entering your password, the trojan must be able to replicate somehow your environment, which is quite difficult if it isn't allowed to generate input events (like Wayland does).<br> Where security is important, I think that it should be possible by administrators to disable full screen windows.<br> <p> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541760/rss 2013-03-07T11:12:59+00:00 hummassa <div class="FormattedComment"> <font class="QuotedText">&gt; I totally agree with you that normal applications should be able to go full screen,</font><br> <p> I don't. At least not without some kind of overlay (*). The minute a normal application can go fullscreen it can spoof security measures (for instance, ask the user for his password and store/send it somewhere).<br> <p> (*) One possible solution here is an OSD overlay that can be shown for a limited time, like two to five seconds, after any input -- keystroke, mouse move &amp;c and, after that, vanish (like youtube's and xbmc's fullscreen mode video controls). This way the user can watch a video or even read a book or a webpage using the whole screen estate but can't be deceived in thinking its login page &amp;c is being displayed.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541759/rss 2013-03-07T11:03:56+00:00 hummassa <div class="FormattedComment"> Honest questions:<br> <p> * is XWayland already working?<br> <p> * is Qt/Wayland working?<br> <p> * is Kdelibs/Qt/Wayland working?<br> <p> To the other side:<br> <p> * is Qt/Mir already working?<br> <p> * is Kdelibs/Qt/Mir working?<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541751/rss 2013-03-07T10:25:54+00:00 renox <div class="FormattedComment"> I totally agree with you that normal applications should be able to go full screen, but I don't understand your use case for input event generation (that is the core of the security issue).<br> You wrote: "to move the mouse pointer out of the center of the screen so that it didn't obstruct and distract from the page being displayed."<br> so when you clicked on your media player it moved the mouse pointer?? Why didn't you just hide the mouse pointer if it stays idle a few seconds?<br> That's what most media player do and this doesn't require input event generation..<br> <p> <p> <p> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541746/rss 2013-03-07T10:10:57+00:00 dgm <div class="FormattedComment"> <font class="QuotedText">&gt;for a project that is so loud on the need to break compatibility</font><br> <p> Wayland is not X11, and so it needs not be compatible in any way. Yet, X11 applications run just fine under Wayland (by means of XWayland).<br> <p> How can you possibly call this behavior "being loud about breaking compatibility"? In any case, it's just the opposite!<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541742/rss 2013-03-07T09:59:43+00:00 daniels <div class="FormattedComment"> <font class="QuotedText">&gt; Is that platform Pekka Paalanen's port to to the Raspberry Pi?</font><br> <p> No.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541740/rss 2013-03-07T09:58:44+00:00 dgm <div class="FormattedComment"> <font class="QuotedText">&gt; I'm currently working on a platform where we use the client buffers directly as full scanout buffers</font><br> <p> Is that platform Pekka Paalanen's port to to the Raspberry Pi?<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541730/rss 2013-03-07T06:59:57+00:00 airlied <div class="FormattedComment"> Canonical have never provided any resources to the wayland project. They have waited for some other distro to do the heavy lifting, you have to also remember the wayland devs have not just been working on wayland for the past 5 years.<br> <p> Most of krh's time has been spent getting the mesa gbm/egl layers to a place where wayland is actually possible, and open source stack supports it.<br> <p> If someone had come along a year ago with a direction for wayland and 4-5 developers there would have been very little to stop them taking the project in whatever direction they wished. You'd at least talk to the upstream project first, to see what benefit you could gain from it.<br> <p> There's a pretty good chance Fedora 20/21 will see some movement in waylands direction. But if Canonical had put the effort into wayland instead of Mir we might have had a reason to help out earlier and assign resources.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541729/rss 2013-03-07T05:37:35+00:00 daniels <div class="FormattedComment"> Like Dave said, Wayland actively encourages the use of overlays; we place surfaces into overlays whenever possible, and I'm currently working on a platform where we use the client buffers directly as full scanout buffers (requiring special allocation) when we can.<br> <p> Everyone in mobile knows about memory bandwidth, it's something we've all been working on for ages. If you've any specific suggestions for improving Wayland's interfaces in this regard, I'd love to hear them.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541728/rss 2013-03-07T05:32:00+00:00 raven667 <div class="FormattedComment"> <font class="QuotedText">&gt; It may not be hidden but, after five years, there is not a single product or distro that uses it or even has a timeline for when they will use it (correct me if I am wrong). Ubuntu wants to put something out in the next few months, and unify all their target devices by next year. </font><br> <p> This is probably the biggest issue that has created Mir. There have been a few links to a post by Shuttleworth from two years ago which discusses a presumed shift to Wayland that indicated Canonical wanted to integrate it in the next 6mo cycle. That obviously didn't happen and Wayland didn't seem to stabilize on the schedule needed for Ubuntu integration. Maybe there just isn't enough resources behind Wayland, did Canonical have developers working on it or did they expect that others would do all the work without their resources? It seems that they would have been hot to integrate it if it was ready a year ago, which would have probably prevented this whole issue.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541725/rss 2013-03-07T04:30:07+00:00 hoegsberg <div class="FormattedComment"> I think perhaps you're confusing client side decorations for client side allocated buffers? Client side decorations come up again and again, but we've never really talked much about client side buffer allocation.<br> <p> Client side buffer allocation refers to how the client allocates its own pixel buffers directly from the kernel memory manager instead of going through the server. It's an implementation detail in the mesa side of Wayland and it's not something we ever really made a big point about. It's all covered by the wl_drm interface, which is private to mesa, defined in mesa and not part of core wayland. Other driver stacks would define their own wl_$chipset interface and allocate and exchange buffers whereever and however they want/need to.<br> <p> And it's not a matter of "Wayland adding support" for server side buffers. It's not a feature in itself, it typically means that your hw or driver has restrictions on which process can allocate memory. The misconception here was that because the mesa integration code allocates buffer client side, other drivers wouldn't be able to allocate through the server.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541727/rss 2013-03-07T04:19:25+00:00 rsidd <BLOCKQUOTE><I>The thing is wayland isn't a hidden project,</I></BLOCKQUOTE> The thing is that wasn't the OP's point at all. <P>The thing is that wayland isn't an established project. It may not be hidden but, after five years, there is not a single product or distro that uses it or even has a timeline for when they will use it (correct me if I am wrong). Ubuntu wants to put something out in the next few months, and unify all their target devices by next year. Both projects are a break with X. Wayland should do a better job of explaining why they are the best way to do it, or else just let Mir be. <P>Yes, Mir made some incorrect claims about Wayland but those were corrected in less than a day. Are there any remaining examples of "bashing Wayland"? As a disinterested person (I use Ubuntu but not Unity), I don't think the Mir wiki "bashes" Wayland in any way. Derived distros http://lwn.net/Articles/541724/rss 2013-03-07T03:40:49+00:00 horen The future is already here! Linux Mint Debian Edition (LMDE) is alive and well and available for download <i>in two different flavors</i> <a href="http://www.linuxmint.com/download_lmde.php"><b>here</b></a>. Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541711/rss 2013-03-07T03:32:20+00:00 n8willis <div class="FormattedComment"> Well, I don't think I was saying it was arduous; but rather observing that incidents of miscommunication often have multiple causes (which definitely includes docs; which as a public entry point, can do many things - mitigate, or exacerbate, or entangle them). The level of detail provided on all sides appears to be a contributing factor; it did certainly appear that both sides came away from the IRC discussion with a better position on where the differences were; I'd certainly hope that that continues if (or when) there is subsequent discussion.<br> <p> Nate<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541723/rss 2013-03-07T03:05:08+00:00 airlied <div class="FormattedComment"> insightful, -1.<br> <p> Oh I forgot not the slashdot.<br> <p> The thing is wayland isn't a hidden project, asking someone on irc or by email isn't hard. Making assumptions shows less character than challenging them. Try and find anywhere in the X11 documentation that explains how to write a window manager or compositing manager. That never stopped anyone from trying, much to our disdain in a lot of cases.<br> <p> I don't think krh has ever said Mir shouldn't be allowed to exist, he has clearly stated that Mir shouldn't be bashing wayland in order to justify its existence, and that there may be no technical reason for Mir to exist apart from ignorance of wayland. Non-technical reasons for Mir's existence maybe also exist, that we are unaware of.<br> <p> <p> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541721/rss 2013-03-07T02:52:04+00:00 dlang <div class="FormattedComment"> <font class="QuotedText">&gt; Høgsberg replied that Wayland could add support for that as well, noting "I realize that this all isn't really documented, but it's not like Wayland only works with client side allocated buffers."</font><br> <p> when a project makes a big point about how it uses client side buffers, and then doesn't document that this isn't the only way it works, it's not surprising that other people assume that it is.<br> <p> I hope that someone is gathering all the undocumented things that wayland can do (and how to do them) that were incorrectly assumed to be impossible and is adding them to the wayland documentation.<br> <p> for a project that is so loud on the need to break compatibility, it seems 'wrong' that they would take such offense at someone else breaking compatibility. It may be that one group or the other is headed into a dead-end, but to take the attitude that only they should be allowed to break compatibility is the height of arrogance.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541719/rss 2013-03-07T02:44:29+00:00 neilbrown <div class="FormattedComment"> Thanks. That's very helpful.<br> <p> If I might summarize:<br> - All *wayland* APIs are non-privileged. However they do not allow you to implement (e.g.) a panel or screen saver.<br> - Weston has a private and privileged API which can be used to implement a panel etc.<br> <p> The (current) MirSpec says two things about "privilege".<br> Firstly "We want to avoid exposing any sort of privileged protocol to client applications." Neither Wayland or Weston do this anyway. Weston only exposes a privileged API to processes that it executes directly.<br> <p> Secondly "As another example, we consider the shell integration parts of the protocol as privileged and we'd rather avoid having any sort of shell behavior defined in the client facing protocol."<br> I'm not really sure what this means. It could be taken to say "Stuff like wl_shell should be privileged", but that contradicts the earlier point, so is unlikely to be the intention. So it probably means "desktop_shell" shouldn't be part of the client-facing protocol, and that is exactly the case - it isn't.<br> So I agree that they seem to be confused. I wonder if anyone from Mir is reading and cares to comment.<br> <p> "wl_shell" is and should be unprivileged.<br> "desktop_shell" is an implementation detail of weston, and is not client-facing so questions of privilege are irrelevant.<br> <p> Thanks.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541716/rss 2013-03-07T02:23:47+00:00 hoegsberg <div class="FormattedComment"> We have a "wl_shell" interface in the wayland protocol, which provides the means by which applications set window titles, icons, go fullscreen, pop up menus. This interface is not privileged, it's available to all clients.<br> <p> We have another interface called "desktop_shell". This is a weston specific, private interface, only available to a special helper client that weston launches. This client provides the background and panel surface back to weston through this interface. Similarly, our input method helper is launched by weston and injects input events back into weston using a privileged interface only available to that client.<br> <p> The way we've split weston into different processes is not a requirement of wayland. The wayland protocol and core libraries doesn't dictate that a compositor should split all UI into external processes. Weston works that way because we don't have a toolkit inside weston. On the other hand, GNOME Shell, for example, uses clutter inside the compositor and can do much UI in the compositor process as a wayland compositor.<br> <p> The Unity/Mir developers want to build the Unity UI into the compositor (as explained in the UDS Mir video), similar to how GNOME Shell would work. Their concern about the privileged shell interface and external helper clients seems to be that they think it's the only way to structure a wayland compositor.<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541715/rss 2013-03-07T01:37:43+00:00 dlang <div class="FormattedComment"> I agree, but if you require that only 'special' apps be written to use a particular api, then I as the admin loose any ability to use an app that way (without having to recompile it to use the new API)<br> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541714/rss 2013-03-07T01:26:54+00:00 neilbrown <div class="FormattedComment"> Your media player should certainly be able to *request* full screen. It is up to the policy of the session manager whether to allow that, and how to break out of that.<br> <p> Your Kiosk essentially *is* a session manager. It says "That window should be full screen, and hide the mouse cursor". You don't want apps from $UNTRUSTED_SOURCE to be able to do that, but you as system owner should certainly be able to do that.<br> <p> </div> Ubuntu unveils its next-generation shell and display server http://lwn.net/Articles/541712/rss 2013-03-07T01:08:04+00:00 dlang <div class="FormattedComment"> <font class="QuotedText">&gt; Other operations like grabbing all events and synthesising new events and making a window full-screen-with-no-decoration are needed for a window-manager or session manager, but are not needed for a "normal application" and so should not be available (principle of least privilege).</font><br> <p> If I'm playing a HD video on a HD display, I really don't want to loose pixels around the edge and force the entire video to be rescaled. I really want my media player app to be able to go full-screen with no decorations.<br> <p> synthesizing new events is also a very useful thing to be able to do. I created the Kiosk configuration that we used at Scale for the signs. It was a pretty simple "point a browser at a page and let it run", but it required both "full screen with no decorations" and "synthesizing new events", the first to make the page look right on the screen, and the second to move the mouse pointer out of the center of the screen so that it didn't obstruct and distract from the page being displayed.<br> <p> note that I haven't read the article yet, and so I can't comment on the rest of your privilege questions, but the simple "why would anything other than a window-manager or session manager need to do this" question is one I wanted to comment on.<br> <p> David Lang<br> </div> Derived distros http://lwn.net/Articles/541708/rss 2013-03-07T00:45:50+00:00 rqosa <p><font class="QuotedText">&gt; how will this affect Ubuntu-derived distros like Linux Mint</font></p> <p>And Kubuntu, Xubuntu, and Lubuntu, also…</p>