LINUX Unplugged - Episode 33: Graphical Civil War | LUP 33

Episode Date: March 26, 2014

Is devastating fragmentation going to doom Desktop Linux, can a case for multiple display servers?Don’t care about the display server? We’ll make the case why you need to care, and why the biggest community confrontation could be brewing.

This is Linux Unplugged, Episode weekly Linux talk show that's prepping for the display revolution. My name is Chris. My name is Matt. Hey there, Matt. I've still got the yellow hat on. The rest of the suit's off, though. And I just want to know. I just got to visualize it. Are you still in the monkey suit?

Monkey suit was a thing until it was bedtime, and then the wife kind of drew the line in the sand and said, I'm not going to do it like they do it on the animal planet. So that's not happening. So that had to come off, unfortunately. I understand, Matt. Well, now I like the idea of this monkey suit floating around there, and it could always like, there could be another bet down the road, and the monkey suit looms. You know that if the bet doesn't pan out, they might have to come back out of retirement.

So this week, we're going to kind of pick up on where we touched on Linux Action Show 305 last week. We talked with Kevin Gunn from Canonical about Mir. And the day that we ran with that show, there was a couple of posts, one from another Canonical developer, Bob, who said, the display server doesn't matter, and we covered that in the feedback.

And then after that, two succeeding posts came out, one from Martin and one from Aaron from the KDE camp. They said, oh, wait a minute. The display server does matter. And I'll tell you, Matt, I've been thinking about this. In fact, I thought about this so hard. Get ready for this. I did some exercise.

You did some exercise? I got exercise. I put on my new hoodie. Actually, I put on the demo print hoodie. I'm not going to lie. And I went out. I walked in the rain. And I thought, you know, I wanted to kind of really kind of in the last couple of weeks come to sort of where I land on the whole mirror debate.

Because I, for a long time, have been taking the, hell, you know what? Let them have at it, Haas. Let's see how it goes. Nothing bad with having a little competition out there. It might spur people into getting their butts in gear and make things better for everybody in the long run. And now I've thought about it, and I've realized two things. There's a headwind of the general, there is a large percentage of the general audience who just doesn't give a crap. They couldn't care less about Mir or Weyland or X11, and I want to change that opinion today.

So if you consider yourself one of those people who doesn't really care about Mir, who doesn't really care about Wayland, I want to correct that because that is a mistake on your part, at least I think, and I want to make the case why you should care and why I think if this doesn't pan out correctly, it could fundamentally damage Linux, desktop Linux's success in the future. And if we don't get this right, and this is why we have to care, because what is at stake here is taking Linux as a serious platform. And that could not be a more critical thing right now as all of these game companies are announcing support for Linux. There was just an NVIDIA demo today. NVIDIA is up on stage, and they're demoing their brand new product on an Ubuntu desktop machine. It has never been a more critical point in the Linux desktop ever, in the timeline of Linux desktop, and there is

something that is about to happen that has never happened in Linux ever. And if we don't get it right, Linux is going to be seen like a joke on the desktop for the rest of its existence. And I don't and that is not, I believe, an exaggeration in the least. In fact, I think it is understating the issue. So if you were somebody who doesn't think they care about Mir, they don't think they care about Wayland, I think you got it wrong. And I want to try to change your opinion on that today. And if it's something you've been kicking around and mulling on for a long time, like Matt and I have, I want to give you a little more to think about. Some more thoughts. And we're going to play off these recent posts that came out right as last was wrapping up. And here we are, you know, we're about a year in since the Mir

announcement. And I think it's time to reflect on this and sort of think about the long-term ramifications of it. So that's what we're going to talk about sort of in the second half of this week's show. But first, we should cover some feedback, and we got a lot of feedback on our SolidXK review. One of the folks who wrote in, and we got so many. It's great. I love it because we weren't quite sure, like, should we spend a lot of time on a small distro? Will people be that interested? Are people, you know, are the masses only interested in the big distros? And I think our experiment with SolidXK proves that if you get the right distro, it doesn't matter about the size. If they've got the right recipe, looking for the right one. I think a lot of people can sort of put themselves in that shoe. He said, inspired by last and Linux Unplugged reviews, I got around to taking a look at Solid X, or actually he looked at Solid K. I liked it so much, I promptly nuked and paved over my OpenSUSE install. He says it's a quite well thought out implemented distro,

and it's great. And he says, thanks for the great programming. He loves it. And by the way, he also loves his new hoodie. We got tons of people that wrote in and said they're trying out Solid and they're really impressed with it. I think it's that rolling release done right. And I wonder if some of the bigger distros might look at what Solid's doing here and saying, maybe there's something we could kind of copy from this, something we could institutionalize. Because I think Linux is at its best when you're taking advantage of the

fundamental fact that Linux is always moving forward as a whole. I don't mean just the kernel, but obviously the kernel applies here too. But all of the GNU utils, everything in Linux is not static. That's one of its biggest faults. And it's also one of its biggest advantages. And when you are on a distribution that snapshots Linux in time, like all distributions do that aren't rolling, you're inherently going against the nature of the underlying operating system and how the upstream system works altogether. And that's why a rolling release, if you've been a longtime Linux user, can be extremely compelling because it actually, in some really weird, twisted way, feels more natural. It feels like the way the Linux desktop should be. And Solid has sort of struck that comfortable area with these understandable update packs and your core applications on a much more frequent basis. And I don't know if Solid's

going to be the one, because it's a small team. But bigger distros could watch this success and learn from it, I think. Well, and I look at what they're doing and then I compare it to like a distro I'm using now. And it's one thing I really like is the fact that they group those update packs together in nice little tidy packages versus, you know, OK, I'm going to plan for this. Right. It's like the laptop that I have sitting here in front of me. I'm going to, you know, it's like my old netbook rather.

And I booted up. I know I'm going to have 50 billion freaking updates that I'm going to have to deal with because I haven't done it every day. And it's annoying. I mean, it's like, I like the updates, but it's like, oh my God, enough, right? So I love the fact that by having them in update packs, you know, that's kind of appealing. I like the fact that I can schedule it. Yeah. Now for me, I get a little endorphin spike every day when I do a Packer SYU and I see like 30 packages are going to get updated. And I get even a bigger endorphin spike when I see like 40, 50, 60 packages are going to be updated and the net difference is a reduction in total disk usage. That is my favorite thing.

I love seeing that. So for me, like every day I love updating because I always want to get new stuff. I always want to look at the new stuff. I want to use the new stuff. And so far, I haven't been burned big time. stuff. I want to use the new stuff. And so far, I haven't been burned big time. Like the biggest burn I've had is a theme might wonk out on me or VirtualBox won't start until I figured out, oh, I need to have the modules auto build when I update my kernel. You know, there was, I've hit some minor snags that I probably wouldn't have hit on a more static distribution,

but those are so minor compared to the thrill I get from having – I know it sounds silly. But when I hear an announcement that a brand new version of Chrome is out and I have it within 15 minutes, that feels pretty great. And it's everything. And solid XK, those are people who don't want to ride that edge so close. I think it's pretty interesting. I think so. Yeah, I think so. I think the other piece of it is like the only time I really got burned per se was Chrome chrome did some weird legacy library issue that arch had way surpassed it they were done and chrome failed to catch up

and i had to go to chromium that was not that much drama it really wasn't a big deal it's a bit of a pain in your butt yeah but it wasn't that you know but it was it was like i needed to do this anyway so whatever you remember we also covered on linux action show this sunday uh debbie and looking at ppas well uh ro Robert wrote in with some thoughts on that. He says, I was listening to your podcast, as always, and I noticed you aired my letter on the Australian National Board Band Network. He says, but that was on Tech Snop, not last. I don't think PPAs are the answer either, but I think there's an existing solution. Docker is fast becoming a standard for software delivery that is distro-agnostic and reliable.

It's already accepted and built into Red Hat Enterprise Linux, and there is a Red Hat certification for software providers. There is a tool called Subuser that uses a config file and Docker to run an application, even a GUI app, in an isolated Docker container. The Subuser allows you to control what the app has access to, i.e. you could allow Firefox to access the downloads directory, but not your documents directory. Subuser is primarily for security, but it uses standard Docker image, so you could run Docker images without Subuser if you wanted to. But if you're

using it with Subuser, you could easily control the isolation from the rest of the OS. Docker is also repository-based, like Git for binaries, so it would be a single command to download and use. Imagine if you had all Up upstream project release as Docker images. You could run it anywhere, on any distro, and not have to worry about breaking anything. The distro repos will still be important for the CoreOS stuff, but even the CoreOS stuff could be put in Docker images for a try. I like it.

Yeah, I've wondered about this. I think one of the times we interviewed the Docker guys on Coder Radio, I specifically asked him, and I said, so the times we interviewed the Docker guys on Coder Radio, I specifically asked him. And I said, so, hey, are you guys playing with application delivery? And he said, well, it's not our core focus right now, but we have been experimenting with it. And it's sort of like, you know, think might have this wrong, but the overhead of a Docker container would only be the differentials from your core system that don't match up with that Docker. So for example, if there was a GL library that was the same on your core system that

was called for in the Docker image, it would just use the one on your core system. And because it's not actual virtualization, it's not like you have the overhead of a VM to run these applications. So I think it'd be something to play with. And I'd like to hear from folks out there who might already be doing this because I know it is possible. And so if you're experimenting with application delivery via Docker, let us know because one of the things that could in theory do, at least according to the Docker developer, was sort of normalize out a lot of distro fragmentation. You know, like, for example, Steam is doing this in a sense. There's the Steam environment.

Every time you install Steam now, it installs a Steam runtime environment. That runtime environment looks an awful lot like an Ubuntu 1204 install, right? But it's just the files that it needs. Yeah, you know, so they're already kind of, this is essentially what Steam is doing right now. And it wouldn't be, you know, the chat room saying, oh, it would be really messy on your file system. Not necessarily, because you could maybe have all your Docker images under slash opt slash Docker or something like that. You could have an organizational structure to it where much like on the Mac, when it's time to uninstall an application,

you just drag that Docker folder that contains the application to the trash. Because on the Mac, when you drag an application icon to the applications folder to install it on the Mac OS X, that isn't one single icon. That's a bundle file. It's a directory. You can right-click on those and say show package contents, and they're full of stuff.

But the OS represents it as a single icon. So when you're dragging that single icon to the applications folder, oh, you're installing the app, but really you're moving a folder. It's filled with files and a directory structure. And when you want to remove it, you just move that folder, but it looks like an app icon, to the trash.

Docker could implement something similar to that. And in fact, it wouldn't even be reliant on the Docker guys to do that part. The shell guys could do that part, right? And when you're talking about working in the user restrictions where you could say, your sandbox, you can only access my downloads folder, not my documents folder. Well, that's something that the GNOME guys have already announced they want to do

anyways. Sub-user sounds a lot like it's already accomplishing what they want to do in GNOME with cgroups and whatnot, which is a really good part of it. It's good security hygiene. That way, you know, if you have an exploit in Firefox, it it can't trample your whole system it makes a lot of sense and as long as you have the right access you could override those kinds of things so i think it's an interesting idea uh thanks for sending that in robert and if you out there folks have experimented with deploying something in docker i would really like to hear that i would like to hear your success stories because i've been thinking about it too. It does sound very PBI-like or click package

like. It's very similar to those. A little more isolated though and I think whereas PBI is specific to PCBSD and click packages will be specific to Ubuntu, this has the potential of truly being distribution agnostic. And the reason why I think

that is super important is because that's what it's going to take to get developers to be willing to put the effort in to make the application. Because when you tell them, well, you can make your app and you can easily deploy it on PCBSD or you can easily deploy it on Ubuntu. Yeah, you just got a percentage of the market. Woo. But if you make a Mac for the app, every single Macintosh out there that has the hardware specs can run that application. And to a developer, that is a type of guarantee that justifies the amount of effort involved in making that application

and then distributing it. And if you can't guarantee that for Linux, you're not going to bring a bunch of developers over. And I know that makes it sound like developers are lazy, but guess what? Developers are lazy. Come on, developers, you know it. And it's also time is money it's like especially if they're doing this as their job it's like there's this weird thing called time and they don't have enough of it and so they're like you know i could spend time with my family or i could go and make

sure that you know that 40 person distro over there has a package i mean you know it's common sense and you have the open susa build service which is attempting to like hey upload your files here and we'll handle all the behind the scenes stuff to make it work on every distro. That is awesome for today's problem, but it really seems like it's a patch to a bigger problem that should be solved. And the thing I like about these Docker images, I don't even know if it would work, but the thing that I like about it is I think a lot of times we've always thought,

well, the way to really solve this is to have a universal package manager across all distributions. That's never going to happen. No, it's not. It's a nice idea, but I mean, we can't even come up with display server correlation between different distros or even the back-end system, systemd versus

upstart. How the hell are we going to do that with packaging? Come on. And this is going to be the point of our talk in a little bit. I mean, it's just about to get worse. Well, speaking of Docker and companies that love Docker, Voldley writes in, he says, Hi, Chris and Don, but he was actually writing for Coder Radio,

but I snagged this. I finally got myself a droplet from DigitalOcean and they're fabulous. I was getting a lot of latency from the New York droplet since I'm in India, so I was able to switch to Singapore in no time. Nowhere does anyone ever mention

that you get to actually select the architecture of the DigitalOcean droplet. Since I run a 32-bit laptop don't ask he says i selected ubuntu 30 bit 64-bit up in the cloud and i'm cross compiling in the cloud it's pretty awesome so i want to take a minute and thank our sponsor digital ocean the community out there has been loving digital ocean and if you use the promo code linuxplugged March, you can get a $10 credit and try out that $5 DigitalOcean rig for two months. What is DigitalOcean? Well, DigitalOcean is simple cloud hosting dedicated to offering the most intuitive way to spin up a cloud server. And they are blowing up because they are offering that sweet spot of perfect services wrapped in an awesome to use dashboard and backed by incredible technologies.

Users can create a cloud server in 55 seconds. Our community does in about 44 seconds, apparently. And pricing plans start about $5 per month. They get you 512 megs of RAM, a 20 gigabyte SSD, a CPU, and a terabyte of transfer. That's your fixed cost. You know right there you're going to be paying $5 a month for that. It's not like some of these other services out there where they count your actual usage and your bandwidth transfer and your CPU load, and then boom, your bill is just like a different bill every single month. DigitalOcean is a fixed cost that you can easily quantify. And DigitalOcean has data center locations in New York, San Francisco, Amsterdam, and now Singapore. Their interface is simple. It's got an intuitive control panel and power users can actually replicate the whole thing with their straightforward API.

And if you use that promo code Linux Unplugged March, that's Linux Unplugged March to get that $10 credit. Go over there and check them out. They built this system on top of awesome, awesome technology. They call it the SSD only cloud. And I was just updating my Arch droplet that I have up there yesterday. I was getting from the repo 85 megabytes. Yeah, 85 megabytes a second while I was doing the update. And the SSDs, man, they just, boom, they just tear right through that.

They have tier one bandwidth, 55 second provisioning. It's all running on top of KVM virtualization. They have amazing hardware. And let me tell you, when DigitalOcean started up, committing to SSDs was a major commitment on their part. It was a huge gamble because back when they started, SSD prices, well, they're still high. But back then, they were even higher. And people looked at them like they're crazy, but they knew that the performance difference was worth it. Now, DigitalOcean also offers private networking.

So you can have like a web server front end with private database servers on the back end. I just recently updated my DigitalOcean droplet with the Quazzle back end. So Quazzle is an IRC client for Linux. And it was so easy to install Quazzle on my DigitalOcean VPS. And now I'm logged into the IRC chat room all the time. And I can connect from multiple machines on multiple platforms. And I'm all sharing the same session routed through my DigitalOcean VPS. It took me minutes to set up and it offers me so much value in terms of my productivity in the chat room that I would

pay $5 a month just for that feature alone. There's so many things you can do with a DigitalOcean VPS. Once you get started, everything from deploying it as the backend for your production system, there's major sites that run on DigitalOcean, huge sites on the net run on DigitalOcean VPS. Once you get started, everything from deploying it as the backend for your production system. There's major sites that run on DigitalOcean. Huge sites on the net run on DigitalOcean for their production backend. You can use it to train yourself. Go up there and get yourself an actual server that has an imaging system so you can snapshot it before you make a big mistake. You don't have to worry. If you're worried about security implications and you want to build a web app and you don't want to open up ports into your LAN, throw it up on a DigitalOcean VPS, and DigitalOcean has awesome support for Docker. You can build your system locally. You can create your app locally in a Docker image and then publish it up on DigitalOcean. They have one-click install. DigitalOcean has open-source Dooku, which is

their application deployment system using Docker. So they're involved in the open-source community. They're using KVM. They're using Linux on the back end. They let you choose between Fedora, CentOS, Ubuntu, Arch. I mean, they're an awesome service, and you can get it for $5 a month and for two months free when you use our promo code LinuxUnpluggedMarch. So go over to DigitalOcean.com, LinuxUnpluggedMarch, and a big thank you to DigitalOcean for sponsoring Linux Unplugged. I love my VPS, Matt.

All right, well, changing gears from follow-up to kind of FYI, Josh writes in. He says, hey, guys, I found out about a free course EDX is offering in conjunction with the Linux Foundation a couple weeks ago, and I know this will be the best possible place to get the word out, so check it out. This would be great for the viewer, and this would be great for a viewer that are in going into college next year like me

says love the show he's a weekly listener to TechSnap Coder Radio and the Linux shows and I don't know if you heard about this Matt but it's yeah it's a course from EDX who makes online training and Josh wanted to kind of put this in front of us I had seen this and I kind of thought we would cover it once because I don't know if it's actually available yet and I thought that's when we cover it but I just I kind of

wanted to give people a heads up because it's an introduction course to Linux develop a good working knowledge of Linux using both the graphical interface and command line covering the major Linux distribution families. Uh, you know what? This used to be like a $2,100 course that's now free. So I go take it. Man. Yeah. Holy cow. That's a great savings. Yeah. I'll put a link to that in the show notes and the class starts a Q3 of 2014. So I, you know what? I thought about it because i was going to just cover it when it launched but i was like we might need to give people a heads up so they can go register so i'll put a link to that in the show notes if you guys want to register it's a $2,100 value so why not yeah right and it's kind of a no-brainer

in its education it sometimes is good to relearn some of the basics too i think that can actually be really beneficial because if you if you're self-taught i took um uh i can't remember what the course was called but i went to a one of our local community colleges and i took a course on sort of the basics of linux and why the like i'd say 80 of it was um this was years ago but 80 of it was sort of repeat it was good to see how other people use the tools and kind of see like the intended implementation of those tools, not the ones I'd taught myself. So if you're kind of in that camp, you might want to check it out. It's a good course. And I think it's really cool they're making available in props to the Linux Foundation. I'm not sure if they paid them for it or if they're just working with them, but either way, it's pretty cool.

Well, however it came about, I mean, that's a big deal. cool well however it came about i mean that's a that's a big deal yeah so um last last last wow last last in the past last last pass on last on sunday well maybe that's a better way to put it last on sunday we asked hey should hey guys should we drop should we drop the seasons what do you think because you know like we last last week's last week's episode was um uh season 31 episode four i think five episode five And I can never remember the seasons. Matt can never remember the seasons. I get it. And honestly, the seasons came about back when we used to take breaks every 10 episodes,

which we realized didn't really work very well. So we put out a poll. And we embedded this poll in the show notes. We made it available to the live stream. Should, hey, should we drop seasons in the Linux Action Show and just call it the production number? So example, last week's episode would be episode 305. 81% of the votes say drop the season number. Only 19% of the votes say keep the season thing out of a total of 608 votes. I mean, it seems like drop the season thing is just a runaway winner. It seems like it, but that seems to have changed from previous inquiries.

Yeah. Big time, big, big time. I mean, in the past, this was almost, it was reversed.

It was keep the seasons. I mean, it's part of the show's legacy is what I was told. And I'm, you know, I'm all for it. I was just worried about making the backlog confusing, but I don't know.

Maybe we'll do like a couple of weeks of transition or something so that way when people are watching the backlog they'll catch up on it i'm not quite sure but we'll link uh this poll if you are uh i don't know i mean i think at this time i think there's no pulling it out i think starting next last i don't know we'll just make the announcement and sort of phase it in i guess i think so and i think you know we think we can transition by continuing to keep the seasons in the text portion, like on YouTube and on the show page. I don't know, though. I mean, does that become confusing? Well, I'll tell you what, because part of this, I'm being completely selfish here, is part of this is I have a hard time keeping track of it.

And so I have to keep keeping track of it if we keep doing that. And the other thing is it it's so long all spelled out that it wraps or gets cut off like on youtube or on oh yeah so it'd be kind of nice just to drop it from the way it looks and so one of the areas i one of i know this is a dumb reason but one of the reasons i most want to drop the season thing is i hate how it looks on our website it's a visual thing uh and so that's kind of like it's the worst of both worlds for me because I have to keep track of the season thing if we go that way. And I have to continue updating the website with it printed out like that, which I don't like either. I know it would be really convenient, but that's kind of like why I brought this up again because that's an old thing for me that's just bugged me for years.

And every time I'm posting the show, I think of it. It's like it just gnaws at me. So I don't know. It's such a clear, decisive vote. And you know what somebody in the chat room pointed out is perhaps the reason why in the past people voted differently is maybe they didn't listen to as many podcasts. And now they listen to more podcasts and all the other podcasts are doing numbers.

That could be it. When we came up with the season thing, there weren't a lot of examples to look to on how you should number your shows. It's been going on for like seven, eight years now, right? So like when we came up with that shenanigans, we didn't have a lot of models to template after.

And I think now it's a foreign thing. It's odd. It's weird. Like people, I think it's one of the things when you first find the show is a little confusing to follow. And it's even going to be more confusing once we switch to the numbers. And it's even more confusing because earlier on it was all numbers. And then we went to season, then we're going back to numbers but at at at at 81 percent of the vote i i think the people have spoken well and see for me most of the stuff these days i'm following it on youtube just because it's i you know i haven't used a

podcatcher in a while it just it's kind of I've progressed over. And I honestly don't care. So for other shows, I don't care what number it is. I either have heard this episode or I haven't. Hey, the subject is blank. Oh, hey, that's new. I'll listen to it. Or, oh, hey, that's not new. I don't care. The chat room is also making some great points. A, all our other shows on the network are number-based,

not season-based. And Rekind points out that if you think about it, it's 10 episodes anyway, so you can get the seasons from the episode number. So you can figure it out pretty quick. And Flash Update Cheese Bacon says that course still costs $250. When you drop it down from $2,500 or whatever it was, it's still a great value. So I'll have that straw poll in the show notes. You have a few more days to vote.

But honestly, at this point, if that keep the season thing creeped up, I would just assume it's bots. Yeah, I know. I think it's done, but I, I, in, in,

in fairness of letting people get their chance to vote, uh, it will be in there. Cause I got a note from somebody who said, I didn't really, it wasn't quite clear on where I should go to vote and I want to cast my vote. So I will put it in this week's show notes as well. Links to everything we talk about guys are almost always in the show notes.

We just make it easy that way for you. And you just go to jupiterbroadcasting.com. You click on the episode you listened to and scroll down past the download links. And I think this is the part that throws people off is they see the show description and they see the download links and they think that's the show notes. But if you keep scrolling your page down, you'll see links to everything we talked about, and essentially in order that we covered them. Oh, okay. Another update. The course will be free when it launches.

So if you want to take the course right now, it's just a discount. Okay. Very good. That's where it launches. Whatever. Yeah. Why not, right? Okay.

So I want to clear some room so we can get into this display server debate. Before we do that, I want to thank Ting. Now, Ting is mobile that makes sense. My mobile service provider and Matt's mobile service provider. Matt, I got a note from Ting saying they got your banana activated, but it's not going to be able to do picture messaging. Oh, no. So no picture messaging because it turns out banana doesn't have a camera.

Oh, my God. Who would have thought, right? Who would have thought? Unfortunately, the other phone does. Right, right. So go to linux.ting.com. That's where you get started. That'll take you to Ting's website.

Ting has some really unique approaches to the mobile industry that this is why I'm a Ting subscriber right here is because I think Ting is going to pressure a lot of companies into changing their behavior. And we know that needs to happen. No contract, no early termination fee, and you only pay for what you use. Each line is $6 flat. So you get a phone, you're paying $6 for that phone per month, plus taxes, and then your usage. It's straightforward.

I have a couple of phones right now on my Ting account, and it's still cheaper than when I had one phone on one of the other carriers. It's unbelievable. They have a savings calculator. You can try it out. You can go over there and see what you would say by switching to Ting. And if you're in a contract right now, they have an early termination relief program.

They'll pay up to $75 per line that you have to get canceled. There's some new phones that have just been announced. So keep an eye out on the Ting blog because I think you'll see an update about those soon. And Ting, one of the reasons Ting is able to offer rates as low as they do and focus on the customer experience and focus on the devices. In fact, I just recently watched a video with one of their executives and he said, you know, for us, it comes down to two things that we're really focused on right now. One is devices and two is coverage.

And if you haven't checked out the Ting service in a while, it might be worth re-evaluating it. They're writing on the Sprint network, and Sprint has this program that they've implemented starting in 2013. It's still going on. It's called the Sprint Network Vision, and you can Google this. And it is Sprint's plan to consolidate multiple network technologies into one new seamless network with a goal of increasing efficiency and enhancing network coverage. And as of March 17th, they now provide LTE service in 402 markets nationwide, such as Atlanta, Boston, Dallas, Houston, Los Angeles, Manhattan, Milwaukee, Queens, Salt Lake City, San Diego, right here in the Pacific Northwest. I've got awesome LTE up at the new studio. And we're talking tri-band LTE

too, the good stuff, the multi-band stuff. So you've got lots of good signal to work with. Sprint wants to make 2014 the year that everybody's opinion changes. And the thing is, is Ting is just going to benefit from this immensely because they already have got the customer service and completely dialed in. If you call them at 1-855-846-4389, that's 1-855-TING-FTW, anytime between 8 p.m. and 8 a.m. Eastern. So right now, if you called Ting's customer support, a real person answers the phone, like an actual human being who's going to solve your problem. Let me tell you something. I have been dealing with contractors and companies of contractors and banks building this new studio. I have been on hold and and companies of contractors and banks building this new studio.

I have been on hold and going through phone trees more than I have in years combined. I am so appreciative that if I ever have an issue with my Ting service, I can reach an actual person right away because my time is valuable. I have deadlines myself. I don't want to wait on these companies that I am paying. And Ting understands that. They can focus on the customer service. They can focus on the device. When you buy a device from Ting, you own that device, just like you want to own your laptop, just like you want to own your desktop. You wouldn't want

to pay a two-year contract where you're spreading the cost of your laptop out and you don't actually own the device until the ends of that two-year contract where you just have to re-up anyways. It's a system that is designed to extract as much money out of you as possible. And it is a system that artificially hides the actual cost of these devices. It's BS. And Ting is trying to change all of that. And you can help take part of that by going to linux.ting.com, where they will take $25 off your first month of service or $25 off your first device. Go check out that control panel. Go check out those devices. Go check out that savings calculator. Go look at their blog for those device updates, which you will see very soon.

Linux.ting.com is where you get started. And a big thank you to Ting for sponsoring Linux Unplugged. They got some great videos on that blog right now. They have some app pick videos. They got an interview with one of their executives. And they have a giveaway of a Nexus 5 and $400 of Ting credit, which wraps up on March 28th. You can find out about all of that over at ting.com slash blog. Get started by going to linux.ting.com, so that way they know you heard about it.

Right here on Linux Unplugged, and a big thank you to Ting for sponsoring Linux Unplugged. Love it. Okay. So we talked with Kevin, and I felt like we got a good look into where the Mirror team is coming from. Pretty quickly after that, Martin, who is the developer of KWIN, went to his block and said, wait a minute. Wait a minute. Hold on, guys. The display server matters in a really big way. He said, I a minute, wait a minute. Hold on, guys. The display server matters in a really big way. He said, I don't know how to put this, but the best description is I am shocked.

I am shocked that Canonical is still not seeing the problems they caused by introducing multiple display servers. He has a great post. It's pretty long. He documents technically why you can't rely on the toolkit to interface with the display server. He uses a screenshot application as a great example. He's actually got code cited in his blog post. It's totally worth checking out because from a technical standpoint, if this has been something you've been kicking around and you really want to see the proof in the pudding, that's a good post. But I think I'll just focus on how he wraps. He wraps this blog post by saying, in summary, Canonical created a huge problem by introducing another display server, and it's affecting all of us, and they still are in a denial state. It's not as simple as the toolkit will solve it. It can cause issues everywhere, and that affects the development and maintenance cost of all applications. My recommendation to application developers is to

never accept patches for this mess Canonical created. If they want that fixed, they should do it in their own downstream patches. Distro specific problems need to be fixed in the distros. I certainly will not accept patches for frameworks and applications I maintain. This is not for political reasons that is often claimed, but for technical ones, because I cannot test patches, mirror is not available on Debian, and our CI system cannot build them, which is

their continuous integration system. So he's making a technical argument here saying, look, I'm not able to test these properly, it's their responsibility, and I think it's disingenuous for them to downplay the importance of the display server. Okay.

The way I see it is I completely agree with the he shouldn't have to deal with the patches and all that. Hey, if you don't want to participate, don't. From a developer point of view, I think that makes perfect sense. It's like, look, I'm not going to even participate in that mess. Good luck, but I'm not doing it. That's the right approach. Has it or will it create problems?

I don't think we're there yet. I think we're definitely speculating, but I think he's got some great points. I definitely think he has some good points. I agree, but here's where my opinion has begun to diverge from that position that I have pretty much held since the announcement of Mir. Because that's essentially what you just said summarizes my outlook on this whole thing, my general approach to covering both sides of this debate. I think, you know, after talking with Canonical, after reading these posts, after going on my rainy walk, which is now sunny out, go figure,

I've come down much, much harder on this issue. And all credit really goes to Aaron Saigo, who created, I mean, Martin and Aaron, man, they tag-teamed this stuff, right? And so Aaron comes out with a sort of a response to Martin's response. And he said, Martin's response demonstrates how many application developers will end up having to care about this kind of thing. He made a convincing argument, and yet he only touched on a few examples, like the screenshot application. But many more could be added, such as using an on-screen display or the OSD as what Clementine does when you change the track and it'll have a pop-up of this track is now playing. These kind of things, like those types of on-screen displays and

applications with screen capture features such as K-Snapshot or the GIMP. These kinds of things are not generally provided by the toolkits themselves and require interacting with the display server. So anybody who's making those apps can't rely on the toolkit. The OSD use case is quite illuminating, Aaron says. Future versions of Plasma will provide a debuff service that can be used for simple OSD needs, like changing the volume in an application and getting an on-screen indication of the volume level. I expect in time, the services will grow features to support more sophisticated on-screen display patterns, as this will not only increase desktop integration, but provide a way to work around security restrictions to play systems like Wayland and Mirror in force. But what happens when this magical new beat-Bus service doesn't exist, like it might not on a Unity

desktop. Here's another example. Status notifiers, or perhaps called app indicators on Ubuntu. This is a D-Bus service, and it's not available anywhere. The answer until now has been to fall back to legacy X11 specific X embed method when you don't find the backend system you need. Does this affect users? These kinds of things, the increase in development burden will mean users of certain display

systems will experience degraded performance and features in application. Application development will slow down as developers come to grips with the diversity and in turn, quality will suffer as it tends to with multiple code paths when they're not easily tested in parallel. Let's stop talking about the future for a second, and let's talk about something I think most desktop Linux users who bounce around desktop environments have experienced. You ever seen this problem, Matt, where you got an application

and it has a little system tray icon, and maybe that particular developer decided, I don't want to implement the app indicator support for Ubuntu. So when you're in Ubuntu's Unity desktop, you don't get an icon up in the right-hand corner. But when you're in KDE, you do get the icon and know maybe it's hit and miss. You've seen this kind of thing, right? Oh, absolutely. Absolutely. And it's something I've definitely experienced, but it also colors based on the level of difficulty which direction I'm going to go through. Sure.

Because I've certainly had that experience both in Unity and KDE, less in GNOME. But yeah, it certainly happened. And see, I feel like I've had more success in almost all of the little tray icons show up in KDE. It's totally hit and miss in Unity. And GNOME has gotten a lot better about it, but it's still hit and miss in GNOME. and Unity, and GNOME's gotten a lot better about it, but it's still hitting and missing GNOME. And this itty-bitty tiny bit of fragmentation was introduced when a couple of different desktops decided to implement, or really one desktop decided to implement app indicators differently than the other desktops. And even today, years later, we still get that wrong. And let's be

clear for what it is. It looks like amateur hour. It looks pathetic. It's something that the Mac OS or Chrome OS or Windows would never get wrong and does not ever get wrong. It looks ridiculous. And I think we have to be clear when we're having this conversation that this type of little itty bitty fragmentation has much wider ramifications in how people appreciate and experience a desktop. And this, as I'm going to use this example because it's something we can all relate to, and then we're going to look at the larger ramifications

of the fragmentation at the display server level. But what I want us all to think about as we are moving forward in this conversation is look at the future directory of Linux, of desktop Linux, quote unquote,

desktop Linux competition, because it's not Windows. It might be Windows today. It might be Windows for the next few years. But five, 10 years down the road, on the high end, it's Mac OS X. On the low end, it's Chrome OS and Android. And those desktops would never be caught dead with that kind of amateur hour implementation. That was not going to happen. And that is our competition. If you look at the forward trajectory of the desktop market, that's who we're competing

against. And those platforms, specifically Android, Chrome OS, and Mac OS X, already have a worldwide distribution system with massive amounts of momentum behind them. They have stores in almost every country around the world. You can order online. They have a brand image around them. And that's what future Linux is going to be competing with. That's what we're competing with. And we are not even bringing our A game. We're not even doing a very good job with our current setup. And now we're about to introduce fragmentation at the core level of the desktop that we have, A, never had fragmentation before, and B, are fundamentally under-resourced to properly develop it as it is. The X team already split to have one team work on X11 and one team

work on Wayland. Well, think about this. What if Ubuntu, in some parallel universe, had decided to go with Wayland? That would mean millions of more users banging on Wayland. That would mean more bug fixes, more refinement at a higher pace to Wayland, making that core part of the Linux desktop experience

more refined, more tested, more performant. all of these things that matter, especially as game developers are moving over to Linux. But instead, we are splitting our resources, we are splitting our attention, we are splitting our testing, we're splitting our development time. And at the same time, we're introducing all kinds of fragmentations that developers are going to have to account for. Because here's how humans work, right? You're going to have your distribution, you're going to develop on that. It's either going to be a Wayland-based distribution or a Mir-based distribution. And whatever it is, that's the one you're going to properly test on because that's the one you use.

And that's the one that the features are going to work correctly on. When I go to the next track in Clementine, whichever distro display server the Clementine developer is using for, that's the one I need to use if I want the next track on-screen notification. And that's even more amateur hour. We are introducing a level of fragmentation at the core of Linux that will mean that applications are even more hit and miss now in what they feature. Does this application have a screenshot button? Maybe it does. Maybe it doesn't. Depends on what desktop you're on. Do you get an on screen display? Maybe you do. Maybe you don't. And here's another reason why you need to care. Because if

you only want to use Unity for the rest of your life, then Mirror is going to work great for you. But if you ever want to use Ubuntu with another distribution, well, you better learn how to install Wayland. You better figure out, this is going to be an explosion in blog posts on how to load Wayland on Ubuntu desktops. Because everybody out there that wants to use anything but Unity ever is going to need to learn how to install Wayland on their Ubuntu machine. And that's another reason why you should care. The reasons stack up. And these very issues, these fundamental issues are exactly the kind of thing that affect users. So while I might not care if it's Mirror Wayland, I sure as hell care if my application doesn't work correctly. I sure as hell care if I have to spend an hour figuring

out how to install Wayland on my Ubuntu install so that way I can try out GNOME 3 whatever. It does absolutely affect users it fundamentally affects users I think it also slows down uh adoption in a very serious way because I think over time yeah and that's that's the piece that I see the bigger because at the end of the day granted I fall back to my old the market will sort it out and it will but we shouldn't have to sort it out in the first place I mean that's the big piece of it right there is that we're spending unneeded time sorting this out when it shouldn't have been an out in the first place. I mean, that's the big piece of it right there is that we're spending unneeded time sorting this out when it shouldn't have been an issue in the first place at all. It's going to get sorted, but it's going to be like a 10-year process.

And developers are always like, oh, Linux is too fragmented. I don't know what I should target. This just changes the equation even more. You look at how 3D games capture the mouse pointer. That's going to be different between desktops or display environments. Game developers are going to have to think about this kind of stuff. And the other thing is, from my old contracting background, and Aaron touches on this in his post, and I thought it was really well done, he says, think about it from an IT support perspective. You already get people like, I had several clients that had Linux on the desktop, and

the problems would always arise if one person was on one distro and another person was on get people like what I had several clients that had Linux on the desktop. And, you know, the question of the problems would always arise if they one person was on one distro and another person was another distro. One person would have something work. Another person wouldn't. And then it would be, oh, well, you need the build utils. Well, what's that called on Fedora? What's that called on Ubuntu? I mean, it's already the diversity that we have there, while in some ways strengthens and empowers Linux. It also, from a support standpoint, is already too complicated. Well, that's what's just going become easier when we don't have to ask, are you using system with system 5 in it, system 7 in it, systemd, upstart? You just have to start troubleshooting at that level. Multiple display systems will produce a similar result. In

commercial settings, this also translates to more cost, particularly to companies who provide professional IT support for companies running desktop systems. Does this matter to users? Well, it means less clear documentation, more difficult support for Linux running desktop systems. Does this matter to users? Well, it means less clear documentation, more difficult support for Linux, and higher commercial support costs. So yes, I would argue that matters to users. And man, did that resonate with me because I have been, I have watched Linux go from the

ha ha ha joke when I recommend it to, yeah, let's implement Linux, right? And I have been advocating the deployment of Linux in businesses for years. And I was already feeling the pushback from like, my doctor clients all wanted Macs, and all my doctors wanted to get Macs. And I really, it is, you know, as soon as that support argument is brought up, my arguments are clearly deflated. Because how do you compete with Apple stores everywhere? How do you compete with, you know, a warranty in writing and a system that's honestly less of a moving target? It's really hard for me to fight against that.

It's a unified experience that – even if we go system D, we go Wayland, we go the whole thing, we still don't have a unified experience. We don't at any level. We're not even near that. It's happening at a time where we could be coalescing around Wayland. We could be coalescing around SystemD, right? And these are major coalitions that could be happening. Exactly. And he says – Go ahead. I was going to say if they get those two and they get the packaging figured out, you know, Bob's your uncle. You're good. Those three things together would do wonders.

Aaron points out, you know, this matters to display systems. One thing free software does not have is enough of its graphic developers. matters to display systems. One thing free software does not have is enough of its graphic developers. With X.org, they were exactly one place you could contribute to if you wanted to push forward the display stack on a free software operating system, such as Linux. Then Mir came along and introduced a split in the developer

community, which means fewer human resources applied to a topic that really needs every single pair of hands we have. Instead of one system that is as good as we can make it, we'll end up with a slower development of two systems, with the risk of more of them being less than great. And I think this part could be argued because you could say good competition spurs good innovation, but at the same time, if you're familiar with the Core X development, you know

how bad that situation is and how much we do need all hands on deck for that kind of thing. And Aaron points that this is obviously no minor task. Mirror was originally promised to be the display system of choice in desktop Ubuntu in 2013.10. Then it was pushed back to 2014.04. And now it's pushed out to 2016.04. This is not a trivial sort of project and making it harder by limiting human resources available is unwise. And I think what we fall back on too often, and I think something we can chant, there's a couple of things we chant a lot in the Linux community.

Well, yeah, maybe KD isn't making you happy. But you know what? It's great because you got choice. Well, that choice is not all that great if none of the choices are awesome. So, but you know, Saigo says he's hopeful. He says, I do hold out hope. The free software community is speaking

with a singular voice. And that voice is saying, after X, Saigo says he's hopeful. He says, I do hold out hope. The free software community is speaking with a singular voice. And that voice is saying, after X, it's Wayland. Wayland itself is still being worked on and has reached a level of maturity that allows real-world use. Several of the major desktop products are well on their way of supporting it as a first-class option, including Plasma by KDE, Gnome Shell, and Enlightenment. All the major toolkits upstream have support for Wayland today, and Wayland has the broadest driver support next only to X itself. So that's a good point to be made. So he's a little hopeful. And he goes on to say the MIR team keeps bringing up these topics, although so does the KDE

team. What's up? But he says maybe they need to defend their position. So does the KDE team. I can emphasize with how, I don't want to repeat what he's saying here, but what he says is, I can emphasize that they are working on something they truly believe in, and they're being told it's the wrong thing to do. He says, I feel it is their right to develop MIR at their heart's content, and I cheer their moxie. Similarly, it is our right as developers and users to choose what to support and what not to. Such decision-making is aided by having an accurate and complete information,

and it's with that goal in mind that I wrote the post above. And I thought this was a great post, because I think what we are entering into is an era of unprecedented fragmentation in the graphical space for Linux. And I want to reel it back in here, because I'm pretty upset about this, the more I think about this,

because what I see this potentially as, is I see this as... I don't want to use the words I'm thinking of, but the – This is a politically correct version maybe? Because I don't believe we can, we have already seen Unity itself introduce a level of fragmentation that is below commercial desktops, that would be intolerable for commercial desktops. We have already seen that, we've already seen the play out of that. So when you introduce some fundamental stuff at the display server level, you either have two options as a developer. either have two options as a developer. You try to target both main display servers, and one of those targets is probably not going to be as optimal as the other, or you simply ignore one altogether. In either scenario, users lose. So if you don't care about what display server you're

using, then you probably ought to stop using Linux. Because at the end of the day, this is going to fundamentally change how the application landscape looks on Linux. And even if it is just one application has an on-screen display on one display server and doesn't on the other, that is enough to have me upset because that is unacceptable. It is not good enough. And I want the most kick-ass display server possible. We have the most kick-ass kernel possible. How about we get the rest of the stack as kick ass as we can? And to sabotage a display server like this for one company's personal gain in a mobile market that is not likely to be tremendously successful anyways, feels awfully selfish to me right now.

Well, you know, I honestly, and I think even Valve will be included in this. I don't think anyone's going to give a rip in rat's butt about mirror one way or the other going forward. I really don't. I think just from the backyard developer guy who's doing this in his boxer shorts down to the multi-billion dollar corporation, I think they're going to look at this fundamentally and be like, you know, honestly, I'm going to go whichever way the community is going, whichever way

the video card vendors are going, whichever way, direction they're headed. Basically, it's a numbers game. And so I think this potentially, I'm hoping I'm right on this, that this could work itself out fairly early on. I'm hoping. The more I think about it, the more I think that it's a numbers game. And so I think this potentially – I'm hoping I'm right on this – that this could work itself out fairly early on. I'm hoping. The more I think about it, the more I think that it's – Well, that's a good point.

Yeah, I hope so. I mean it's definitely early days. And I think something I wanted to kind of kick around to the Mumble Room is maybe abstraction can solve it because we're all looking at this with today's set of problems and today's set of tools to solve this problem. set of problems and today's set of tools to solve this problem. And I think also, you know, something that Martin and Aaron were trying to make the push is developers are users too. And in fact, I think developers make up a good user base of Linux, right? I think that's probably who a lot of the users are, are developers. So by impacting developers, you are impacting the users of Linux.

And I think that's a segment that's going to continue to outgrow any other segment of Linux usage. But I don't know, anybody in the Mumbble room want to take a first shot at this? Is this a problem that future Chris and Matt aren't even going to have to worry about? Can I ask you a question, Chris? Go for it, puppy. What's the single most used display server on Linux right now, as in most deployments? Xorg? No.

Surface Flinger. On Android in way more deployments than anything else. Wayland, MIR or Xorg. Good trick question, Popey. That was a good one! You got me good on that one! Surface Flinger is the display server

on Android. Nobody seems to have told them that they can't have their own internal project for a display server, which is used on millions of devices. But the difference there… Why do we get that flag? But isn't the difference there… But that's sort of, in a sense, a whole cloth creation, right? Where it's a whole new ecosystem with a whole new set of apps that are designed for that system. But on the Linux side...

Just like Ubuntu phone. Yeah, exactly. If anything, the most biggest problem is it's a whole different paradigm compared to our legacy or at least what everything else has ever been. I mean, I think Poby makes a good point. But I think the subtle difference is that you only have to target Surface Flinger on Android. So when you're making your Android apps, it's not really something

that even has to be a consideration. No, you don't. You don't, because the stack that's abstracted away from you in exactly the same way that Robert and Robert Carr have both blogged about. That stuff is abstracted away from you by the toolkit. You would disagree then with the assertion that Saigo and Martin are making

that it's not quite as abstract as everyone would like. No, I'm suggesting that there are certain edge cases where you need to know about the underlying fundamental bits and pieces. And yeah, a screenshot tool is a real easy shooting fish in a barrel, you know, one to pick because it obviously needs interaction with the display server but there are way more applications out there than there are screenshot

tools and there are way more developers out there developing tools with toolkits which will just work on these display servers and won't have this problem so you say the canonical has the amount of influence and power that Google has when it comes to the mobile marketplace is just a little bit of a excessive statement. Did I say that? When it comes to comparing Surface Slinger to Mirror, a little bit. No, you didn't. All I'm suggesting is that it's entirely possible for someone to come up with a display server on Linux which isn't Wayland and isn't X, and for them to deploy that to a large number of handsets around the world and it work. And for application developers to do their work on top of that and not really care that it's surface fling underneath and not Xorg or Wayland or whatever. So I think the fundamental disagreement I see here is one

side thinks that it's really not going to be that big of ramifications for developers or application functionality, and another side seems to disagree with that position. The surface area of mobile is also far smaller in a way that it's very specific. Its kernel is predefined, other than the CyanogenMods or whatever personally built mods that Android has. Otherwise, the desktop is very, very different. There's a lot more ambiguity. And it's a lot harder to do, which is one of the reasons why Mir hasn't landed in the desktop. and it's a lot harder to do,

which is one of the reasons why Mir hasn't landed in the desktop. Right, and well, it's kind of the point you mentioned, that if it comes down to, here's a toolkit you can use to build your app, and it'll guarantee it'll work, that works, but that's not a model that Linux has typically gone with before. I think their argument is no toolkit is actually that comprehensive. There's bugs or there's just gaps in what it's capable of providing that eventually... It'll work in a special case of Unity pretty much only.

I think their argument is eventually, you know, you have to close a few gaps and when you do that, you got to write directly to the display server. You can't write to the toolkit. And I think the concept of a perfect toolkit is sort of like a dream, but I don't think we've ever in the history of computing achieved the perfect toolkit. No, and I agree. There are going to be holes in every toolkit, and there are bits that we're going to have to do at the plumbing layer and components that we're going to have to provide that won't be provided by Q. We know that, and we're building those as we go. And yeah, this is a bit of a learning exercise for us as well. But I don't think

the criticism is necessary. I don't think it's as warranted as some might think. In some ways, it feels like, okay, right, we've got them to switch to system D. Right, what's next? Ah, yes, me. Let's have a go at them about that. Let's see if we can get them to change that one now. Right. Yeah, I guess what I'm worried about is, I'm worried that wishful thinking is influencing that thinking. Because in an ideal world, I think that's too ideal. And I think the history of, specifically, desktop Linux

shows us that things are very fluid and things are never quite as great as we want them to be and the idealism usually gives away a little bit of pragmatism and I think at the end of the day there's a lot of bets on things kind of coming together at the right time to make all

of this work. I think Guthu's time is coming to an end soon because, I mean, they've been alienating and alienating the user base so much over the years with Unity, with Mirror, with... Yeah, I don't know about that. You know, Riley, I hear that a lot, Riley, but the thing is you can't discount the massive cloud deployment that Ubuntu has, which will naturally push a lot of developers and sysadmins to want to run Ubuntu. I mean they're doing really great there. And I think also – I think let's look at it from an alternate perspective.

What if we fast forward three years down the road or 2016 or whatever it is where we have like this great QT based desktop, which I think a lot of us think QT has a strong future ahead of it. You know, maybe this is a little bit further down the road, but it's sitting on top of system D. The only piece that has a lot of questions is how is I think what people are really worried about is the fragmentation being introduced at such a critical layer. I mean, we can all argue about package names and how they're different between all distributions or the locations of certain libraries and how they can be different or where the config goes can be different. But we've, we as a user base and as developers have never had to worry about that display layer. I mean, yeah, it's, old, and its time has come to be replaced, but at the same time, it has been at least a consistent thing,

not just across Linux, but also across Linux and the BSDs. It is a consistent aspect for software development when you're targeting these systems that is now no longer going to be consistent. And I think you cannot understand that. Except for that other platform that you keep forgetting about that has more deployments than all of those. Well, I mean, there is a reality to that, but I'm very focused on the actual desktop aspect of Linux.

And maybe down the road, I mean, we're already seeing more and more laptops that are shipping with Android. I just recently saw a post for a full-fledged desktop with a keyboard, mouse, and monitor running Android. So, I mean, you know, it could be a fair point that, again, we don't know what the future has ahead of us. But right now, I'm really focused on, you know, making my desktop version of Linux better than ever. And I'm really worried that if we cock this up and if we get this wrong at this critical time with new types of companies getting on board and making great products, but also all of the desktop environments are getting to the point now where they're so good that it's these little things that bug us, like the indicators

and all this kind of stuff, we're really getting to a good point. And if we kind of screw this up, I just, Android and Chrome and and the mac are going to eat us alive so in three weeks time and thereabouts three weeks and two days um ubuntu is going to ship 1404 and that's going to have x as the display server right and unity 7 with compass everything you know and love or hate, depending on your point of view and that gets support for five years. So if you're a game developer

you can still write your same game using your same libraries and oh by the way, if you wanted to port it across to MIR SDL supports MIR as well as supporting Wayland. So it's, I don't, I think you're painting a rather bleak outlook for something that's not going to happen anytime soon.

That's true. Mir is not going to be the default on the desktop for some time. I think Aaron was a little bit pessimistic saying Mir is pushed back to 16.04. You know what I think it is, Popey, is I think we have been, over the years, those of us who've been running desktop Linux as our main desktop for so long now

have watched these sort of peaks, and then it's almost like watching the price of Bitcoin, man. It peaks, and then it crashes, and it peaks, and it crashes, and we're so gun-shy. We've been whipped so many times now that when we sniff something that's going to screw things up, there's this really strong reaction. And, you know, you mentioned the system data backhoe.

I am seeing a pivot now in these conversations to more of the technical side. And I think you'd agree that one of the things that sort of was really strong on the system B side of the argument for Debian's init system was they had the technical argument. And that technical argument was really strong. And now you're seeing them bust that out on the display server argument. So we talked about this a few weeks ago, where the Linux community and people who are interested in Linux news, I agree with you, are watching LWN and watching Foronix and maybe Slashdot if that still exists and seeing these news articles about all kinds of developments in various camps and reacting in the same way that you might react to Litecoin or Bitcoin. And I think it's kind of overdone because in the past i i've had people um bark at me on twitter you know complaining that um ubuntu was removing gimp from the cd and i remember him saying whoever it was

this mythical person on twitter saying to me mark my words this was the end of ubuntu because you're removing gimp from the cd i mean get real that right years ago and we've all and we've all watched like these these huge upsets over stuff that ends up not being a big one, but those have never been something as fundamental as a display server. And I argue that— The SystemD and the Upstart one, that was brought to a head by the fact that Debian had to make a decision, and Debian made that decision. But at the end of the day, that's less important than the display server itself.

Well, you wouldn't have thought that if you were reading any of the news articles over the last three months. There's no way you could think that this was less important than anything else on the planet. Well, I feel like it is, though, like in a long-term ramification standpoint, because what we really need to do is make the application experience better. And I think the scenario I could potentially see playing out is on the Unity desktop, Unity 8 or Unity 9, you know, whatever it is at this point, like all of those applications are really going to be top tier. After they've had a few releases and had some time in the market, they'll really be great and they'll work, you know,

the marriage between Mirror and the desktop environment and even the applications, it's going to feel so refined and cohesive. But what I worry about is outside of that, I'm worried about certain desktop applications that don't have the support. And I think as people start to wrap their support for certain features, I think as people start to wrap their minds around that, I could see this erupting to even bigger than the systemd debate because it honestly affects more people. Potentially. Your point is well taken.

It affects developers. I don't think my mum's going to be affected by this. She knows what displays, she doesn't even know what web browser she uses. She just clicks the pretty coloured icon in the corner of the screen. Your mum could be affected by this by she could say, how come on my on my computer here, I no longer get the Thunderbird pop up about a new email message. I really like having that. And, you know, what do you have to say to her as well? You know, the developers for Thunderbird decided not to implement support for how we do that in MIR.

support for how we do that in mirror so so in in i i heard you uh during your rather breathless rant earlier um talk about some of the issues that may come up you know the the potential issues that may come up and what what you've got to remember is that we don't develop ubuntu in a vacuum it's in all the packages that we put in the archive are in the archive and coexist with other desktops like kubuntu kde like Zubuntu and Lubuntu. And we test a lot of this stuff on different environments. It's not just developed and tested and the developer says, oh, it works on my desktop, ship it. It doesn't work quite like that. Well, so I guess the end point I'm trying to make is I think probably the biggest takeaway is we have a lot of time.

Like you mentioned, the LTS is about to ship with X. And a lot can change in that five years that LTS has support. But I think at the same time, you can look at the past Ubuntu controversies that really haven't turned out to be that big of a deal. And that doesn't necessarily mean that every situation moving forward is the same thing. Future situations need to be evaluated on their own merits and their own impacts. And this is a multi-level issue. You have the politics of it,

which are way too hostile already. You have the potential technical ramifications. I don't know why people are just making almost no deal out of this it's making a molehill out of a mountain in controversy or at least in contrast compared to the usual thing they're sweeping it under the carpet as if this is absolutely

unimportant to anyone but it is core that's an interesting I think that's how I see this right now and at the same time like I'm of a mixed mind on it because I've also witnessed in open source how a little, you know, Coke versus Pepsi can benefit the overall desktop and can benefit overall Linux. And so I'm not staunchly against Mir on that principle. But what I am staunchly against is having Linux desktop

get any more shitty. If it gets any worse at all, we are screwed. I mean, we have literally across the board, we have got to be, over the next few years, it is go time to play at our A game.

And I guess what I worry about is if we are even playing at our B minus game because of some differences between applications on different display servers, man, the developers will look at that as an excuse not to develop for Linux. End users will look at that as confusing and make Linux hard to understand. And sysadmins and support people will look at that and say, do i how do i provide cost-effective support for that and the thing is the argument could be made the argument could be made that if it was all wayland across the board this wouldn't even be a concern and i think that

issue right there when people start thinking about that it gets them a little fired up you know what i mean it gets them a little upset else the competition there should be healthy competition within our ecosystem. In a way, Mirror was made in haste before Weyland's true potential could be realized. It's supposed to be stable. If something was poor in the system, it's got to be tested for years and hammered.

I kind of feel like if Mirror was announced two years ago, I think a lot of people, I think this would be a lot different. I think you've got to give Canonical credit. They were early supporters of Wayland, but I think – I understand there's market realities. There's products you need to be able to ship. I produce a Linux show and I edit it on a Mac. I understand there's compromises that need to be made to produce the product to get it to the market at a way that's cost effective and

actually deliverable. And I think that is where Mir came out of. And that is a completely reasonable and understandable perspective. But the problem is, is that doesn't mean it still doesn't introduce potentially future oddities throughout the entire desktop. I mean, it is fundamentally something that could happen. and if it does happen i i just i do not feel like we can afford for it to happen and so we either have all desktops potentially reduced in functionality at some degree even if it's just an on-screen display not showing up or somehow it all gets abstracted out it all works out and that's a potential too i don't know yeah two things two things i want to bring up real quick because i think we need

to take a trip back in time to a little thing that was called early revisions of Jack. I remember a very popular newbie distribution that was absolutely all about Jack. Screw everything else. This is what the future is. Never mind the fact that I could literally load a web page and break

Linux audio. That's a big freaking deal. I honestly thought it was the end of Linux as we knew it. It was a big problem. Flash forward to today, the to today the new devil is pulse audio i mean they're different animals granted but they still interact with your ability to hear sounds on your computer and i suppose that's popey's point yeah yeah we we will work through it now i will advocate against that yes i do think that if potentially this does create new problems it's gonna it's gonna drag us through the mud a little longer is it gonna be the it going to be a major problem? No.

I think a major delay, yes. Major problem, not so much. But because I've seen this movie before, I'm not that concerned about it because I've seen – audio is a big deal. It's a lot like display. You see, you hear. Those are kind of big deals. I think we'll work through it. I think we'll work through it.

I think we just need to kind of you know try to kind of come together kumbaya whatever the hell we gotta do I think you could make the argument that maybe Pulse Audio if it had something to compete against something to compare itself something to measure against

something to you know live up to maybe it would have taken a different route and perhaps perhaps because well it provides me with functionality

I want that I can't get without I'm willing I mean that's just factually true. Yeah, and I'm willing to say we have to go through a growth period. Maybe there's some oddities, like the Thunderbird notification doesn't show up. But in the end, if these two things can make each other better, and that creates a more kick-ass display server. Okay, I'll take that. And we may have some third option.

Stick with your RTS or whatever your favorite stable distribution is that sticks with X until Weyland is ready. Or stick with Ubuntu until Mir is ready. What happens a year or two years from now when 14.04 is old and still like 12.04 is now and you have nothing to switch to? I would say, I would like to say, I mean, my biggest disagreement with Matt's point is... Oh, there you go. I think that might have, was that you, Tyler? You might have a little buzz there on your line. I know Daredevil wanted to get a point in.

Yeah, I'd just like to interject because I've actually done some research on the differences between X, Wayland, and Mirror. And I see as Mirror taking a different approach technically. and I see as Mirror taking a different approach technically. So X11 was this huge thing that pretty much initially was very small and started patching up. And because it was just adding features, adding features, adding features, the result was the colossal huge amount of software that it is today. Now, recent improvements have been stripping those things out. Wayland actually comes and says, we're going to define a very basic premise and you can build on top of it and move some of the responsibilities that are currently being addressed by X and letting that to the compositor or to the plugins.

So Weston is doing kind of that work. work. Mir takes a different approach and says, look, developers are used to program against something that actually has these features present and they only deal with a very small subset of these features. So they will actually only use those. And Mir says that we are going to provide the same rich set of features. However, because we are implementing MIR with those concepts in mind, we are actually going to provide a more stable platform for that. That's why I wanted to interject on this matter, because technically they approach the problem very differently. Wayland moves the problem upwards, and MIR tries to solve the problem in the same section that X was solving, in a way. And when we actually think about most applications, yes, actually don't mess up with display server. And that's a fact. Current

window managers and game developers use libraries, and those libraries do Windows support, Mac support, Linux support, and those platforms are completely different. How is that possible? It's simply just making an abstraction. And from that perspective, the same way libraries appear to allow cross-pollination of code, I'm not sure why it wouldn't be possible to make for the display servers. So that's why I was saying the paradigm of mirror is completely different. As Exo, again, Wayland have a thing which are normal

which composite to a certain screen or a certain surface and that is resultantly put on to the video driver and to your screen. Mirror takes a completely different approach by having a completely different compositor per window or per ui element

and that is a what is it a simple no they're all compositing together separately and then it actually gets put onto the screen which is why that is slightly more pluggable but it's completely more interconnected to each other because they're all their own compositor yes it is actually more modular in that sense but in the other sense let's let's take the other view i'm the final developer i'm consuming one of these compositors so wouldn't i have then if my application tends to do some work that matches best with this compositor and then matches best with the other one, am I not just duplicating my efforts again? I guess it's really, if we are looking at from a technical perspective, the approach of mirror taking is we have this model and people are used

to it. And there's also another thing I would like actually to point out is a lot of people seem to say that Canonical is backing mirror for their company issues of people seem to say that canonical is back in the year for their company issues and they want to solve that in you know ubuntu um more a pleasant way let's say for their business requirements you might say yes yeah yeah exactly but wayland isn't that uh innocent either if we think about it because some of the ex-developers were actually Nokia developers and other companies' developers, which moved to Weyland. So I'm not seeing the point there.

So I wouldn't even say that that's an argument at all. I think you guys, both Heaven's Revenge and Daredevil, and that's funny, the opposite names there, I think you both have raised some interesting perspectives on how Mere could provide solid competition to Weyland and and kind of kick Wayland in the ass in a few areas to make it shore up. Like if it really truly has a stable ABI API, I mean that's a huge advantage for developers. So that's an example of some good – a little injecting some good competition. Why I took the bet.

That's all I'm saying. Go ahead, Tyler. If you don't mind, the point I was trying to make earlier was what Matt was saying about his comparison with the audio stuff earlier. I think the biggest issue we have with Mirror and Wayland, especially if they're competing against each other, is who are the driver developers going to cater to?

Right. That's a big part of the picture that right now, I mean, seems to be predominantly in Wayland's favor. Yes and no. If you think about it, the MIR design actually allows the current model of proprietary drivers to be more attractive. But isn't that supposed to be just temporary? Well, another thing is, if they're competing against each other,

it's still open source, though, isn't it? I mean, they can still look at each other's code, truly, and borrow from it. Yes. Bingo. Yes, but the drivers, let's say the NVIDIA drivers, if you want to use the good ones,

they're proprietary, and they might end up being, working only well with Wayland. Well, that's true. NVIDIA has to actually put resources towards supporting MIR specifically, because that is our only problem in open source.

It's the binary blobs of our video drivers. Almost every other part of our ecosystem is open. It's a problem we're having with mobile devices as well more so with mobile devices because they all have loads of binary blobs to get them working um and that's partly why we've gone down the road we have of using you know some of the android driver stack to enable that quickly but listen i i know i know you you're you're quite keen on impressing the point that we as a Linux community are on the hook for this and we've got to get this done.

Nobody understands that any more than us. We've got at least two handset vendors, which we're going to be contractually obliged to provide software for this year. And that puts enormous pressure on us to get this right, because these things are going to be shipping to real people, proper handsets they can order, buy, and use as their real phone on a daily basis. And so we are very cognizant of that pressure and trying to get the intricate technicalities of those pieces working correctly.

So, yeah, we're aware of that. If anything, the timing is almost tragic. When the time of XP is ending its life, we messed up in conquering the world when Vista screwed up. But now XP's end of life is coming up, and now we have another shot. But now Canonical has given us another situation. Well, no, like Popey points out,

those users would be switching to LTS. For Linux. Exactly. XP is already dead. Yeah, I think Alan's point's well taken. Most companies have already switched to Windows 7. I would like to make another point regarding drivers. The good news is AMD does plan on going completely open source for the kernel driver and leaving the proprietary stuff for the user land.

Right. That's a very interesting development that could make it. Maybe, you know, I don't know if NVIDIA is even capable of doing the same thing, but that could solve these types of problems in a big way. And that was something I didn't mention in Sunday's way and that that was something i i didn't mention in sunday's last but that was something i put into consideration is and i wonder if that is influencing amd's decision in doing that is because they're kind of looking at the future landscape and going well you know you know i think the big thing is really honestly i think the big thing for nvidia is they're probably looking back and seeing okay well what what direction is the

steam box going to go in and whatever that that, you know, I mean, sure, if Steam box decides to go mirror, then, and, you know, honestly, it sounds like there's some compelling reasons around the Oculus Rift and things like that where they might want to go mirror. And wouldn't that be quite the upset? But I bet you anything NVIDIA is watching for that.

And that might make their decision right there. I don't know. Let's hope so. Well, you know, at the BSD conferences, there's been a lot of discussion lately about the problem of monocultures. There's a few specific products that have taken off to the point where they are the only

choice for stuff. For example, OpenSSH is like 95% plus market share, other than a couple embedded things like DropBear, right? And there's no alternative. That's a bad thing. So having an alternative to X.org isn't necessarily a bad thing.

X had no alternative for a very long time. That's right. It was merited. Kind of switching tracks, though. What happens, like, five, ten years now when X stops being supported across the board, and what will BSD do? That's what I'm kind of switching tracks, though. What happens, like, five, ten years now when X stops being supported across the board, and what will BSD do?

That's what I'm wondering. Yeah, BSD is boned. Yeah, what is BSD's plan there, Alan? Do you know? We already have experimental import of Weston and Wayland. Oh, wow. There's nothing we can use it on yet. Right.

Wow, that's amazing, though. Which is the problem. So work is already kind of beginning there. I think it's going to be... If somebody had an app that we could actually run on it, that would be helpful. Yeah, that would be really awesome if BSD done the Wayland thing even before Linux got

full support for it. And that would do wonders in general, I think. Remember when Fedora 15 was supposed to have Wayland? Yeah. Everyone seems to agree that it's a critical Even when Fedora 15 was supposed to have Wayman. Yeah. God. Everyone seems to agree that it's a critical time because once we've set this, it's an opportunity as well to take on users.

But actually, it's one of the reasons to make this a more thought-out decision because it's going to be what will affect us down the road. Yeah. I think that's a good point. And maybe we'll end right there because that's just been just a great conversation. I like getting all perspectives in on this one.

And I think it's going to be a very interesting future. And if only there was some way we could follow this as it's developed and create a history of it. Hmm. How could we do that? Maybe on your local Linux Unplugged and Linux Action Show. We'll keep on history of it. Hmm, maybe on shows like this. How could we do that? Maybe on your local Linux Unplugged and Linux Action Show. We'll keep on top of it.

And hopefully, we've given you some reasons to think about why the display server does or does not matter a little more than you had before. Before we wrap up, I wanted to maybe ask your feedback on anything we've covered, obviously, today. But also, what do you think about Linux Mint

perhaps using the same Ubuntu LTS base for Linux Mint 17, 18, 19, and 20? That's right. For the next while, Linux Mint would be based on Ubuntu 14.04 LTS. They say

they would use that to push forward innovation in Cinnamon, be more active in development on MATE, and better support Mint tools and engage in projects we've postponed for years. I'd like to know what people think about that. What do you think, Matt? Is that going to get really boring? Is that code for we don't want to do stuff? I mean, I don't know.

Just to me, it just seems like what's – from an end user point of view, what am I really getting out of it? We're going to do these cool things. Okay. Are we getting to the point where the base is good enough? And so now it's time to focus on – But we're not. Well, I don't include the desktop environment. I mean like the base, like the kernel, the tools, like the GNU tools, all that kind of stuff.

Are we at a point now where it's good enough? Because also keep in mind, isn't that kind of what the next OpenSUSE release is? The guys are not really focusing on the under the hood stuff, but they're more focusing on the services around OpenSUSE? Yeah, yeah, they kind of are. Okay, so let's just for argument say they do that. Are they going to be also stagnating on the kernel and just basically applying little, you know, patches as far as, yeah.

Sounds awfully boring to me, Matt. Yeah, I mean, it's like, oh, hey, I got a new piece of hardware. Good thing I got that new kernel. Oh, that's right, I don't. Yeah, see what I mean? It's kind of like that doesn't really make a lot of sense. Well, and it's not like

the rest of the world standing still. It's a real close balancing act getting those user land applications which eventually end up relying on underlying stuff that has to be updated. Sounds like they're doing a SimplyMepis to me.

That's just me. Well, let's hear what the audience thinks. So go over to jupiterbroadcasting.com, click the contact link, choose Linux Unplugged from the dropdown, and send us in your thoughts on that or anything we covered in this week's Linux Unplugged. And don't forget, if you'd like to participate

in our virtual lug, hang out with us over at jblive.tv. We do this on a Tuesday at 2 p.m. Pacific. Go over to the calendar. You'll get it just in your local time zone jupiterbroadcasting.com slash calendar

Matt on Sunday we'll be chatting with one of the guys behind Gentoo and I'm hoping to have

the new Gnome 312 on my machine I don't know if it'll make it yet but I hope so we'll be talking about that thanks so much for

tuning in to this week's episode of Linux Unplugged we'll see you right back here next Tuesday.