User: Password:
|
|
Subscribe / Log in / New account

Dividing the Linux desktop

This article brought to you by LWN subscribers

Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

By Jonathan Corbet
June 17, 2013
The Ubuntu desktop has been committed to the Unity shell for some time; more recently, Canonical also announced that Ubuntu will be moving over to the new, in-house Mir display server. That decision raised a number of eyebrows at the time, given that most of the desktop Linux community had long since settled on Wayland as its way forward. As time passes, though, the degree to which Canonical is breaking from the rest of the community is becoming increasingly clear. The Linux desktop could never be described as being "unified," but the split caused by projects like Mir and SurfaceFlinger may prove to be more profound than the desktop wars of the past.

Canonical developer Former Canonical developer Jonathan Riddell started the most recent discussion with some worries about the future of Kubuntu, the KDE-based flavor of the Ubuntu distribution. KDE does not currently run on Mir, and some KDE developers (such as KWin lead developer Martin Gräßlin) have made it clear that they are not interested in adding Mir support. So Ubuntu will be shipping with a display server that does not support KDE in any sort of native mode. While libraries providing X and Wayland protocol support for Mir will certainly exist, they are unlikely to provide the level of functionality needed by desktop components like the KDE core. The result, Jonathan said, was that "the switch to Mir in Ubuntu seems pretty risky for the existence of Kubuntu"; he wondered about how other Ubuntu flavors might be affected as well.

Unsurprisingly, the developers working on Mir insist that they do not want to throw out the non-Unity desktop environments. Ubuntu community manager Jono Bacon was quick to say:

[I]t would be a failing of the Mir project if it meant that flavors could no longer utilize Ubuntu as a foundation, but this is going to require us to collaborate to find good solutions.

In other words, Canonical has a certain willingness to help make other desktop environments work on Mir, but it will take some effort from the developers of those environments as well. More specifically, Thomas Voß has offered to work with the developers of KWin (the KDE window manager) to find ways to make it work within the Mir environment. Assuming that a path forward is found, it is entirely possible that Kubuntu will be able to run under Mir on a Ubuntu-based system.

The problem is that such solutions are likely to be second-class citizens in general, and there are reasons to believe that the problem could be more acute in this case. The Mir specification does not describe it as a display server for all desktop environments; instead, it says "The purpose of Mir is to enable the development of the next generation Unity." There are a number of implications that come out of a position like that, not the least of which being that Mir and Unity appear to be developed in lockstep with no particular effort to standardize the protocol between them.

Canonical developer Christopher Halse Rogers described the situation in fairly direct terms:

We kinda have an explicit IPC protocol, but not really. We don't intend to support re-implementations of the Mir client libraries, and will make no effort to not break them if someone tries.

This position differs significantly from that of the Wayland project, which has based itself on a stable protocol specification. Leaving the system "protocol-agnostic" (that's the term used in the Mir specification) certainly gives a lot of freedom to the Mir/Unity developers, who can quickly evolve the system as a whole. But it can only make life difficult for developers of any other system who will not have the same level of access to Mir development and who might like a bit more freedom to mix and match different versions of the various components.

The result of this approach to development may well be that Mir support from desktop environments other than Unity ends up being half-hearted at best; it cannot be a whole lot of fun to develop for a display server that exists primarily to support a competing system. Few other distributions have shown interest in using Mir, providing another disincentive for developers. So, as the X Window System starts to fade away into the past, Ubuntu looks to be left running a desktop stack that is not used to any significant degree anywhere else. Ubuntu, increasingly, will be distinct from other distributions, including the Debian distribution on which it is based.

The success of Android (which uses its own display server called SurfaceFlinger) shows that reimplementing the stack can be a workable strategy. But there must certainly be a limit to how many of these reimplementations can survive in the long run, and the resources required to sustain this development are significant. Canonical is taking a significant risk by separating from the rest of the graphics development community in this way.

Over the many years of its dominance, X has been both praised and criticized from many angles. But, perhaps, we have not fully appreciated the degree to which the X Window System has served as a unifying influence across the Linux desktop environment. Running one desktop environment did not preclude using applications from a different project; in the end, they all talked to the X server, and they all worked well (enough). Over the next few years we will see the process of replacing X speed up, but there does not appear to be any single replacement that can take on the same unifying role. We can expect the desktop environment to fragment accordingly. Indeed, that is already happening; very few of us run Android applications on our desktop Linux systems.

"Fragmentation" is generally portrayed as a bad thing, and it certainly can be; the proprietary changes made by each Unix vendor contributed to the decline of proprietary Unix as a whole. But we should remember that the divergence we are seeing now is all happening with free software. That means that a lot of experimentation can go on, with the best ideas being easily copied from one project to the next, even if licensing differences will often prevent the movement of the code itself. If things go well, we will see a quicker exploration of the space than we would have under a single project and a lot of innovation. But the cost may be a long period where nothing is as well-developed or as widely supported as we might like it to be.


(Log in to post comments)

Time to leave the "desktop" metaphor behind

Posted Jun 17, 2013 17:40 UTC (Mon) by DonDiego (guest, #24141) [Link]

Clearly, there has never been a better time to scratch this whole "desktop" thing and move to different user interfaces. I have been using tiling window managers for many years now and never looked back after passing the initial hurdle.

Try something like awesome for yourself and see, but give it a real chance. Everything will feel weird at first until you get used to the new way of working. After a week or two I was sold. I'm not going back.

Oh, and before anyone tries to troll me with some "average user" argument: This is lwn.net, not average_user.net :-p

Time to leave the "desktop" metaphor behind

Posted Jun 17, 2013 19:17 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Features of tiling WMs are making their way back to more "consumer-oriented" WMs. Windows has its Aero Snap feature that I see folks using all the time, There are quite a few tiling apps/extensions for OS X which shows that there's interest there. KWin has support for "docking" windows.

The problem usually turns out to be that expectations are broken for apps which assume a reparenting WM, use poorly constructed dialogs which don't resize nicely (almost guaranteed if they're not detected as dialogs and floated by WM policy), and the MDI window pattern (thankfully, this is dying), and Java (due to the first two being very prevalent).

Time to leave the "desktop" metaphor behind

Posted Jun 17, 2013 19:52 UTC (Mon) by AngryChris (subscriber, #74783) [Link]

Not seeking to troll you at all, but this is at a lower level than your window manager. This isn't talking about "desktop" in terms of KDE, GNOME, etc, this is saying that Mir (which is a replacement for X) will not support running non-Unity X clients as wholeheartedly as it will Mir clients.

This means that it's unlikely that awesome will run as well on Mir (being an X client) than it does on X itself. The Mir developers will ensure that Unity runs well as a Mir application. They will not be investing time in ensuring that KDE, GNOME, or awesome run just as well.

While the term "desktop" is being used here, it's somewhat misleading. These are all X clients (applications). They make use of the display server (X). Ubuntu is getting rid of X as a display server and is moving to Mir, a completely different kind of display server. While they plan to include some ability to run X applications under Mir, that effort extends only to Unity software, not anything else. If your non-Unity X application runs, then you're lucky. It's not because Canonical is watching out for you.

Time to leave the "desktop" metaphor behind

Posted Jun 17, 2013 20:23 UTC (Mon) by DonDiego (guest, #24141) [Link]

You have a point, but I'm absolutely sure that I will find something to drive my tiling window manager of choice, be it X, Y or Z, and ignore the division in display servers just as much as I ignore the division in desktop environments like KDE and GNOME right now.

Time to leave the "desktop" metaphor behind

Posted Jun 18, 2013 11:39 UTC (Tue) by smurf (subscriber, #17840) [Link]

You cannot "ignore the division in display servers". That's liek ignoring the difference between the API of Linux+X11 vs. Windows. You need a translating layer which maps A to B.

In the case of Linux+X11 vs. Windows, that layer is the Wine project. Even after umpteen years of development, one still finds corner cases even in older programs which just don't work right. The Wine layer certainly "works" for the most part, but it will never be "the" preferred way to run a Windows desktop on a Linux system. I will not assume that any program actually runs on it without extensive testing, even now.

Wayland will have an X11 server so that you can run X11 applications, but not X11 window managers -- they need to know too many internal details which don't map well enough between X11 and Wayland to make a compatibility layer feasible.

I assume that Mir, too, will have an X11 server so that you can continue using your X11 programs. That appears to be reasonably easy to do; there's ample code available which you can re-use. But window managers? When talking to a server which doesn't even have a stable API? Forgettaboutit. Spend the effort on improving Wayland+Weston support, and let Canonical's Mir fall by the wayside.

Seriously: If you don't want to run Unity, why would you want to run Mir in the first place?

Time to leave the "desktop" metaphor behind

Posted Jun 18, 2013 13:30 UTC (Tue) by DonDiego (guest, #24141) [Link]

You misunderstand - or I'm not being clear. I couldn't care less if what tiles my windows is an X11 window manager or based on Wayland or on Mir or whatever. I certainly don't want to run Unity and I invite everybody else to give the alternatives a spin.

Time to leave the "desktop" metaphor behind

Posted Jun 18, 2013 10:27 UTC (Tue) by raof (subscriber, #57409) [Link]

It's a bit more than that - for the full desktop case, Mir (and, indeed, Wayland) - do not allow arbitrary X clients *at all*.

Specifically, you can't run a compositor or a window manager; the X<->Wayland or X<->Mir integration code is an irreplaceable X compositor and X window manager.

This doesn't apply when you're nesting a full X server inside Mir or Wayland, but then you're not running Unity 8 (or Weston, respectively). We'll be supporting a full X session (under a Mir system-compositor) for the foreseeable future, though.

Time to leave the "desktop" metaphor behind

Posted Jun 18, 2013 0:11 UTC (Tue) by sramkrishna (guest, #72628) [Link]

This is a ridiculous idea. You're abandoning the desktop to for-profit/non-free entities for a niche idea that only appeals to very small segment. If your goal is the proliferation of free software and software freedom (including say freedom from spying from NSA) then it's imperative that we do not abandon any of this.

Also, none of this affects the debate of two display servers.

Time to leave the "desktop" metaphor behind

Posted Jun 18, 2013 5:52 UTC (Tue) by geofft (subscriber, #59789) [Link]

Bear in mind that Android and iOS already use, more or less, the tiling paradigm (at least as I use my tiling WM -- most of the time my apps are full-screen). And both Windows 8 and the new OS X 10.8-era full-screeny thing are moving in that direction, as well. So I don't think making distros go tiling by default is likely to cause any problems. (Frankly, Unity and GNOME 3 already go in the same direction.)

It's not imperative that we always slavishly follow the proprietary OSes' UI paradigms to attract users. Many times it's useful, but it's not a requirement.

Time to leave the "desktop" metaphor behind

Posted Jun 18, 2013 13:58 UTC (Tue) by drag (subscriber, #31333) [Link]

I just install the 'put windows' extension in Gnome-shell and I have all the tiling features that I care for.

Dividing the Linux desktop

Posted Jun 17, 2013 17:43 UTC (Mon) by stgraber (subscriber, #57367) [Link]

One small inaccuracy, Jonathan Riddell is no longer a Canonical employee, actually he hasn't been for over a year now. He left Canonical in April 2012 to work on Kubuntu for Blue Systems.

Dividing the Linux desktop

Posted Jun 17, 2013 18:00 UTC (Mon) by corbet (editor, #1) [Link]

Oops. Text tweaked, thanks for the correction, apologies for any confusion.

Dividing the Linux desktop

Posted Jun 20, 2013 22:10 UTC (Thu) by bkerensa (guest, #80912) [Link]

So the other bits about Canonical are dead on you're saying? :)

Dividing the Linux desktop

Posted Jun 17, 2013 18:38 UTC (Mon) by b7j0c (guest, #27559) [Link]

so tired of this hand-wringing. its open source, you have the option to ignore it or deride it, but not the option of trying to bend other projects to your will. its very clear that ubuntu is pursuing something which is merely "linux based" a la chromeOS etc and that interoperability with alternatives is as much a non-requirement as it is for chromeOS to support alternate window managers.

backporting the universe of linux interface alternatives is a waste of time - the task is too big and its mostly thankless. just use another distro.

Dividing the Linux desktop

Posted Jun 18, 2013 0:19 UTC (Tue) by roc (subscriber, #30627) [Link]

The problem is that the more the Linux desktop fragments, the more work per user it is to get applications to work.

Dividing the Linux desktop

Posted Jun 18, 2013 3:58 UTC (Tue) by rahvin (subscriber, #16953) [Link]

Based on the number of users that fled Ubuntu when unity was implemented if the number of available applications on Ubuntu declines rapidly then I would expect that most users will simply flip to an alternate.

The beauty of open source is that if it does succeed its ideas will be incorporated elsewhere and if it doesn't users will simply flee and the software will die. Open source simply can't fragment like Unix did.

Dividing the Linux desktop

Posted Jun 18, 2013 11:02 UTC (Tue) by roc (subscriber, #30627) [Link]

Why not? It already has, many times. The original KDE vs GNOME split is a good example. There's no reason why Wayland vs Mir can't end up with a similar number of users on each side.

Dividing the Linux desktop

Posted Jun 18, 2013 11:39 UTC (Tue) by micka (subscriber, #38720) [Link]

There is (more or less) integration between KDE and GNOME.
Even without it, apps from the one can still run side by side with apps from the other, on inside a desktop managed by the other. there might be integration problems, but then run, without specific integration infrastructure, because they both use X.

The only way to run an app that uses Wayland and an app that uses Mir side by side is to have both wayland and Mir run inside X.
If you don't want to do that, you need to write a Wayland-over-Mir or a Mir-over-Wayland, unless it is a Mir-over-X inside a XWayland.

Dividing the Linux desktop

Posted Jun 18, 2013 14:07 UTC (Tue) by drag (subscriber, #31333) [Link]

Back in the day it was a huge pain in the ass to run KDE and Gnome together.

KDE applications would get all crappy looking and malfunction when ran on a Gnome desktop and visa versa. It took a huge amount of work and creating new windows standards to get them to work rather decently together.

Even then you had a shitload of problems with the Linux audio stack being basically completely broken with a mixture of OSS and Alsa with Artsd on it.

It's not like 'Oh X11 made it possible to run KDE and Gnome side by side'. That's utter bullshit and misleading. It took a huge amount of work and it works largely despite X11 rather then because of it.

It seems odd that all these people have forgotten how terrible things were and how a huge amount of work went into creating a desktop that people can just customize and throw together random shit and expect it to work half-way decently. I don't think it is worth it anymore because even after 30+ years of effort and standardization up the ying-yang it's still a huge pile of dung in terms of typical user experience and worse for application developers.

I think that going with a silo approach is probably much better.

Why?

Because if people actually care about portable desktop applications they are NOT going to give a shit about FreeBSD or Ubuntu or anything like that first. The first thing they are going to care about is Windows. Next thing they are going to care about is OS X.

And it's going to be a hell of a lot easier for them to deal with MIR Ubuntu application stack and a separate Fedora Wayland stack then 100,000 possible variations of X.Y.Z that the current Linux desktop represents.

Dividing the Linux desktop

Posted Jun 18, 2013 14:56 UTC (Tue) by micka (subscriber, #38720) [Link]

I was there. I can tell you it was possible as I did it. And I also run other programs with nearly all possible existing toolkits (Tk, lesstif, xforms,...).

I didn't say it was nice. I said it was possible.

And it isn't possible at all if the programs use different displays.

Dividing the Linux desktop

Posted Jun 18, 2013 18:28 UTC (Tue) by Kayden (subscriber, #89093) [Link]

Maybe nostalgia is getting the better of me, but I distinctly remember running GNOME with KDE apps or KDE with GNOME apps for years, and I don't recall it being nearly that painful. (I'm even using several GTK+ apps in KDE now. I even occasionally run Xaw/Athena programs like xmag...)

Yes, the look and feel wasn't terribly integrated, but that wasn't something I minded...the advantage of actually being able to use the one app I liked better in whichever environment I liked better trumped all of that.

So I think Jonathan has a good point. For a while it wasn't feasible to replace X, since, for example, it had intricate knowledge of every piece of display hardware. Since X was the only viable solution, everything ran on X - GNOME, KDE, TWM, you name it. Now that most of the hardware knowledge has been moved to kernel drivers, it's become viable to create alternatives to X - and multiple, incompatible alternatives.

Let's say, hypothetically, GNOME/GTK+ decided to use Mir and KDE/Qt decided to use Wayland. Without a bunch of extra work on interoperability, that would be the end of running GTK+ apps in KDE, or Qt apps in GNOME. I would be very sad to see that day.

Thankfully, it doesn't look like it's happening.

Dividing the Linux desktop

Posted Jun 19, 2013 11:53 UTC (Wed) by pboddie (guest, #50784) [Link]

I think it is largely an overstatement to say that running KDE and GNOME stuff together - at least the applications - was a "huge pain in the ass". There probably were some odd things where some applications might have launched some of the desktop functionality - I think various KDE applications do this with Akonadi even today - but the weirdest thing that could happen was that you got some gadget or other in its own window wondering where all its friends were.

Certainly, running KDE and GNOME things together was routine by the time Bluecurve came around in Red Hat Linux 8.0 back in 2002. Before then, maybe stuff didn't look much like each other in terms of styling, but you run that risk today as well.

Dividing the Linux desktop

Posted Jun 18, 2013 5:04 UTC (Tue) by b7j0c (guest, #27559) [Link]

this isn't fragmentation. this is ubuntu creating something called unity. they make some apps work for it, bless those, and leave the rest to the community to deal with if they want. unity is not "the linux desktop". people using ubuntu should forget about it being linux at all, its ubuntu.

go to the ubuntu homepage. search for the text "linux". not there.

ubuntu has never claimed to solve the linux desktop. they are making their own thing. you are free to use it or not.

i don't use unity but i am thrilled with what ubuntu is doing. there are already dozens of distros successfully failing to make desktop linux happen, why should one more join the race over the cliff? if ubuntu is wrong in choosing its own path then the community will leave them and they will ultimately wither. given that ubuntu is thriving, its clear that despite the vitriol, users are not rejecting their approach

Dividing the Linux desktop

Posted Jun 18, 2013 6:01 UTC (Tue) by geofft (subscriber, #59789) [Link]

> if ubuntu is wrong in choosing its own path then the community will leave them and they will ultimately wither. given that ubuntu is thriving, its clear that despite the vitriol, users are not rejecting their approach

It's a perfectly reasonable point of view to think that Ubuntu is generally doing a good job, but some things it's doing is misguided.

For instance, nobody else is doing anywhere near as competent a job of delivering desktop Linux based on Debian packages on a somewhat frequent release cycle with a good chance of working on most hardware. This by itself is enough to make me use Ubuntu.

I can still disagree with whether I think their desktop strategy, or their init system strategy, or whatever else, is correct. And they can be wrong about those things, and still succeed, provided they're doing a better job actually delivering a desktop Linux than anyone else out there -- which they are, despite it (allegedly) not being their primary focus.

So I don't think it's true at all that Ubuntu continuing to be so popular is evidence that everything they're doing is correct. It's only evidence that the major stuff is correct.

Dividing the Linux desktop

Posted Jun 18, 2013 10:54 UTC (Tue) by sorpigal (subscriber, #36106) [Link]

> For instance, nobody else is doing anywhere near as competent a job of delivering desktop Linux based on Debian packages on a somewhat frequent release cycle with a good chance of working on most hardware. This by itself is enough to make me use Ubuntu.

There are a variety of Ubuntu derivatives that could just as easily continue from a Debian base and provide this sort of thing. Mint seems like the prime example since they do this already.

Dividing the Linux desktop

Posted Jul 5, 2013 19:56 UTC (Fri) by The_Barbarian (subscriber, #48152) [Link]

>delivering desktop Linux based on Debian packages on a somewhat frequent release cycle with a good chance of working on most hardware

Except, you know, Debian.

Dividing the Linux desktop

Posted Jun 18, 2013 5:56 UTC (Tue) by geofft (subscriber, #59789) [Link]

> its open source, you have the option to ignore it or deride it, but not the option of trying to bend other projects to your will.

This is pretty untrue.

When I submit a patch to a project, or propose a new feature or some refactoring, I'm trying to influence that project to go in the direction I have proposed.

When I write common tools, I hope to influence other projects to use these tools.

When I open bug reports about design issues, I'm hoping to convince the project to accept a different design.

Public debate is a legitimate part of the open-source development process. This is a community, not a bunch of craftsmen in silos. We do our work in public specifically so that we can take public comment and criticism. What people (both users and developers) want out of a project absolutely is legitimate for a project to take into account, and it is absolutely legitimate for personal blogs, mailing list discussions, and news sites to discuss whether the direction a project is taking is advisable and attempt to influence the project.

Android applications

Posted Jun 17, 2013 18:47 UTC (Mon) by boog (subscriber, #30882) [Link]

"very few of us run Android applications on our desktop Linux systems"

It may not be easy to do so, but how many of us have actually wanted to do this? I guess I don't have many "apps", but there hasn't been a single one that I've wanted to put on my desktop.

Android applications

Posted Jun 17, 2013 19:07 UTC (Mon) by dlang (subscriber, #313) [Link]

Actually, there are quite a few Android Apps that I would like to have on my Linux Desktops.

A common reason for this desire is that the vendor chooses to support Android, but not Linux

Things like the Webex app for example would make my life at $work _much_ easier.

Ubuntu made an announcement a while ago that they were working on a way to run Android apps on your desktop, but I haven't seen any information on how to actually do so yet.

Does anyone have a pointer on how to do so?

Android applications

Posted Jun 18, 2013 11:26 UTC (Tue) by rvfh (subscriber, #31018) [Link]

I'm sure you can run Android in parallel with your Linux desktop, as the opposite as been done for the Motorola Atrix. One kernel, two C libraries... The issue will be the display, but you can run Android with no hardware acceleration, so should be easy to just give a buffer to Android and display it in a window.

Android applications

Posted Jun 19, 2013 2:58 UTC (Wed) by nteon (subscriber, #53899) [Link]

The problem isn't the C library, its the Android runtime services. There was a project called IcedRobot that was looking to implement the runtime on top of OpenJDK + Linux + GNU userspace, but it seems pretty stalled.

Android applications

Posted Jun 25, 2013 18:37 UTC (Tue) by ekj (guest, #1524) [Link]

There's -plenty- of apps that people would like to have on their desktops. Full support for running android-apps would, for example, be a huge boost to the casual gamer crowd.

Dividing the Linux desktop

Posted Jun 17, 2013 19:11 UTC (Mon) by bjacob (subscriber, #58566) [Link]

A few notes:

* I've been using X for the past 12 years and been maintaining large client applications for it, and seriously, it is such a terrible system for the needs of current client applications, that I think that the Linux Desktop has just no chance of success in the mainstream as long as it was X-based, so it's no clear that even a very fragmented future could be worse than the current situation.

* The mantra that "Display servers are abstracted behind toolkits so application developers don't need to care" only applies to simple or "typical" applications. If you're developing a tier-1 Web browser, you will need direct interaction with the display server. Depending on the platform, you might be able to abstract a variable portion of it behind EGL / OpenGL calls --- but you won't be able to do with just GTK or Qt, or whatever toolkit.

* Android's graphical subsystem, especially SurfaceFlinger and the whole SurfaceTexture mechanism, is some of the most beautiful C++ code that I have seen --- that mythical kind of C++ where each class has a well-defined meaning and even /multiple inheritance/ actually makes sense --- and SurfaceTexture contains very practical wisdom about what it actually means to /push frames/ to the screen and how current hardware actually works in this respect. Heck, it works so well that this single abstraction is how /everything/ gets pushed to the screen on Android 4 --- compare to the zillion of special cases that e.g. desktop Web browsers still have to push various kinds of frames to the screen.

* While we are going to lose the unification around X, we are probably to get something else, and much better, to rally around: EGL! Look at Android applications: either they use EGL... or they use Android-specific classes such as SurfaceTexture, which closely mirror EGL concepts (e.g. SurfaceTexture is an "EGL stream"). Likewise, to write directly to memory shared with video, you can use Android GraphicBuffer... but there is an EGL extension allowing to do the same in theory, namely EGL_lock_surface (it even was used on Meego). So, given sufficient good will to implement EGL interfaces, we could be getting unification around something much nicer than we ever got from X.

Dividing the Linux desktop: Why not Surface Flinger?

Posted Jun 17, 2013 20:01 UTC (Mon) by evad (subscriber, #60553) [Link]

So why has nobody worked to take SurfaceFlinger and adapt it to replace X on Linux desktop computers if it really is that good? Is it not suitable?

In fact, the current phone/tablet Ubuntu uses surface flinger. Why did they dump it?

Dividing the Linux desktop: Why not Surface Flinger?

Posted Jun 18, 2013 11:03 UTC (Tue) by sorpigal (subscriber, #36106) [Link]

For whatever it's worth there's a sort of an answer to that.

Dividing the Linux desktop: Why not Surface Flinger?

Posted Jun 19, 2013 21:08 UTC (Wed) by fixkowalski (guest, #13396) [Link]

Actually, I think that the absence of answer to this very specific question pictures the whole issue of the Linux desktop: NIH syndrom!

Dividing the Linux desktop: Why not Surface Flinger?

Posted Jun 20, 2013 6:39 UTC (Thu) by krakensden (subscriber, #72039) [Link]

In Canonical's defense, Android upstream is pretty much guaranteed opposed to merging patches porting SurfaceFlinger to Mesa. That, and the periodic code dumps would make maintaining a fork a pain in the ass.

Dividing the Linux desktop

Posted Jun 17, 2013 19:12 UTC (Mon) by dlang (subscriber, #313) [Link]

I find it hypocritical for people to at the same time say that Mir should not be developed because it will fragment the desktop at the same time that they shout down people who are worried about Waylands lack of remote support.

Now, if you want to argue against the specifics of Mir, that's fair game.

Personally, I don't like the 'shared library is the API' approach that Mir is taking, but it's not the first system component to take this approach (ALSA jumps to mind). As long as the API to the shared library is kept stable, the result should be usable.

I absolutely agree that the value of X being the universal API has been grossly underestimated. In the early days, this is what allowed Linux to _have_ a desktop. If applications had been required to modify their code before they could be compiled on Linux and use the display, Linux would have been crippled.

Dividing the Linux desktop

Posted Jun 17, 2013 19:29 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Wayland is just the base protocol and won't be involved in any remote support in Weston or other clients but I don't see the connection between that and Mir since Mir doesn't support that functionality either.

Dividing the Linux desktop

Posted Jun 17, 2013 19:50 UTC (Mon) by dlang (subscriber, #313) [Link]

Wayland is fragmenting things, complaining that someone else is doing the same thing that they are (developing a new display interface) is what I find hypocricical.

As I say, technical arguments are fine. But the wail of "but they can't do that, WE are the anointed future" is not.

And it doesn't matter if we are talking Wayland, Gnome3, AOO or any other tool.

Even if it's the same developers, if you choose to create a new project that is supposed to replace the way things are currently done with something new (and the new project doesn't have to be a different name, as Gnome3 has shown us), you have absolutely NO right to complain if someone else also creates a project to compete with you. Even if they start a while after you do.

This goes even more if your replacement isn't intended to offer all the capabilities of what you are replacing (and in terms of Wayland, the fact that you can support X clients by adding another layer to the display stack doesn't count as offering the capabilities of X)

not that you have much right to say anything even if you are a long-established codebase that you aren't replacing. But there you can honestly talk about fragmentation and argue for compatibility.

But really, projects should compete on technical matters, not fussing about "how dare <someone else> choose to do something different". Linus has the right attitude here. He has said that he fully expect that at some point, someone will create a replacement for Linux that is nimbler and cleaner, and at that point Linux will deserve to be replaced.

Supporting Freedom for users requires that you not only make it easy for others to start using your project, it requires that you make it easy for others to migrate away from your project and use competing projects as well (especially if the 'competition' is an earlier version of your own project)

Dividing the Linux desktop

Posted Jun 17, 2013 20:00 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

The complaints from Xorg/Wayland developers were mostly about the initial misconceptions about Wayland listed in the Mir page and once that was changed, they stopped. There are other complaints from folks like Martin, maintainer of KWin at http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubu... and it appears he has valid reasons to do so. You seem to want to shut off critics except in ways you approve of and that won't work.

Dividing the Linux desktop

Posted Jun 17, 2013 20:14 UTC (Mon) by dlang (subscriber, #313) [Link]

I have no complaint at all about people posting technical issues.

It's when they start complaining about "fragmentation" that I call them on it.

A milder version of this is when toolkit developers seem eager to make changes to their stuff to support one new, unproven back-end, but make announcements (especially before there is any way to compare things) that they are not interested at all in making similar changes to support a different new, unproven back-end.

Unfortunately, many KDE developers did exactly that. One problem with doing this is that after making statements like that, any technical issues you bring up have to be put through a filter to decide "is this really and issue" or "they are just trying to find some excuse to not support it"

It sounds as if KDE is turning the corner here (driven by the Kubuntu concerns that Jonathan pointed out at the start of the article), and as a Kubuntu user, I really hope that this gets settled and Kubuntu doesn't have to install a completely different display manager.

I guess I should have explicitly called out that I was posting about the fragmentation concerns, which as I see it, are mostly being raised by people who I see as contributing to the fragmentation already.

Dividing the Linux desktop

Posted Jun 17, 2013 20:27 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

You seem to think that fragmentation is never a technical issue. If you look at the blog post I referenced, you would be hard pressed to argue that and instead of vaguely referring to many KDE developers, please cite your sources so that we can have a specific discussion. Thanks.

Also, many of in the Linux world seem to think that adoption of a component is just about technology and it often isn't and hasn't been for a very long time. You have to deal with politics and commercial aspects all the time. For instance, Mir is under GPL with a CLA so that only Canonical has the ability to sell a proprietary license to vendors who are GPL averse. Do you think this doesn't matter for other commercial distributions? Let's be realistic here.

Dividing the Linux desktop

Posted Jun 17, 2013 20:59 UTC (Mon) by dlang (subscriber, #313) [Link]

> For instance, Mir is under GPL with a CLA so that only Canonical has the ability to sell a proprietary license to vendors who are GPL averse. Do you think this doesn't matter for other commercial distributions? Let's be realistic here.

Those are all valid reasons to not use Mir.

For something like KDE that I believe supports Windows, these are not valid reasons for not supporting it.

At this point, it's not worth going back in the archives to dig up quotes from prominent KDE devs saying that had no intention of supporting running on Mir, but I'm sure many people remember reading such statements.

Dividing the Linux desktop

Posted Jun 17, 2013 21:07 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

"For something like KDE that I believe supports Windows, these are not valid reasons for not supporting it."

I don't think your assertion carries much weight. KWin maintainer has said that he won't take Mir patches as long as the protocol is unstable and Mir is distro specific. As the maintainer, he is in a much better position to determine that since he is shouldering the burden of maintaining the code.

Dividing the Linux desktop

Posted Jun 18, 2013 5:45 UTC (Tue) by mgraesslin (subscriber, #78959) [Link]

As for Mir mostly KWin and in large the kde-workspaces matter (and not overall KDE): KWin does not support Windows. It only supports X11 (and in 4.11 a little bit of Wayland). The argument about Windows is pretty much irrelevant in the question about Mir.

I wouldn't accept patches for Windows with pretty much the same reasoning as for Mir. After all Windows is also just one distribution and any code for it would be distro-specific and none of the developers could run or test it.

Dividing the Linux desktop

Posted Jun 18, 2013 9:06 UTC (Tue) by zyga (subscriber, #81533) [Link]

The argument that it's 'distro specific' is a perfect example of being out of touch with reality. It is not important if there is one or many distributions that use a particular technology. What really matters, regardless of anyone's opinion on the topic, is how many users use that technology.

The windows argument is a perfect example of this. Projects that can and did port their software to windows have orders of magnitude users as compared to projects that did not (or could not). More users gives more influence, more feedback, more prospect developers and bigger impact on the world in general.

But I forget that many open source developers just write the software for themselves, living in some ideological bubble, and don't really care about people they are not reaching. I don't mean any disrespect, I'm just observing the fact that open source development is rarely coupled with the principles of market economy.

Dividing the Linux desktop

Posted Jun 18, 2013 9:34 UTC (Tue) by mgraesslin (subscriber, #78959) [Link]

A quite common reply I get when I say that Ubuntu is for us just another distribution and we don't do anything special for them.

So let's face it: we don't know whether Ubuntu has a larger userbase than other distributions. Even more we don't know whether Kubuntu has a larger userbase than other distributions. So even if Ubuntu has a larger userbase that it would make sense from the "market economy" it might not make sense from the Kubuntu userbase.

Given that we cannot answer this question (nobody can - we just don't have any reliable numbers on distro usages and desktop enviornment usages) to me as an upstream developer all distributions are equal and none is more equal than another.

That said: of course everybody is welcome to implement Mir support in KDE. Just don't expect that KDE developers will take over maintenance for a distro-specific solution.

Dividing the Linux desktop

Posted Jun 18, 2013 11:32 UTC (Tue) by rvfh (subscriber, #31018) [Link]

No, what we really want now is Android kernel/3D + libhybris + wayland + Qt + KDE :-)

Dividing the Linux desktop

Posted Jun 19, 2013 1:04 UTC (Wed) by simosx (subscriber, #24338) [Link]

> Just don't expect that KDE developers will take over maintenance for a distro-specific solution.

Still not well-phrased. It's is better to say that you welcome developers that are interested in developing KDE to work on Mir (because the existing team does not have the resources, etc).

You do not know about the usage statistics for Ubuntu? They are available from the wikimedia.org OS stats, from clicky.com and others. Ubuntu is the biggest GNU/Linux distribution.

Dividing the Linux desktop

Posted Jun 19, 2013 5:36 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

>> Just don't expect that KDE developers will take over maintenance for a distro-specific solution.

> Still not well-phrased. It's is better to say that you welcome developers
> that are interested in developing KDE to work on Mir (because the existing
> team does not have the resources, etc).
Well it's not about developing, it's about maintaining the code and the cost to have the code in the source tree. So yes anybody is more than welcome to implement it, but don't expect that we as upstream will allow the code in our source tree as that passes the maintenance to us. We would have to adjust the code if we do changes, etc. That's what I understand under maintenance.

Dividing the Linux desktop

Posted Jun 19, 2013 18:02 UTC (Wed) by jubal (subscriber, #67202) [Link]

That's a nice way to talk down your, most probably, biggest downstream user…

Dividing the Linux desktop

Posted Jun 19, 2013 18:22 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

says who? Any numbers to claim that? Maybe it's true that Ubuntu is the distribution with most users (it isn't - anyone know this Linux Distribution called "Android"?), but that says nothing about *K*ubuntu. I have no numbers showing that there are more Kubuntu users than Arch users or openSUSE users or $foo users. Given that to me as an upstream developer all distributions are equal and no distribution is more equal than another.

Dividing the Linux desktop

Posted Jun 19, 2013 18:32 UTC (Wed) by jubal (subscriber, #67202) [Link]

…and some distributions are apparently created /less/ equal. It's good to be king.

Dividing the Linux desktop

Posted Jun 19, 2013 18:53 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

I don't understand this comment.

Dividing the Linux desktop

Posted Jun 19, 2013 19:10 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

more specifically... wikimedia stats has listed "unknown linux" as the dominant non-Android linux by useragent string id for over a year now and this is the best public dataset I know of, with a methodology I can review.
Unknown linux is the dominant traditional distribution in the wild, and all vendor tagged linux useragent strings are in decline relative to the unknown linux string. It is what it is.

Dividing the Linux desktop

Posted Jun 19, 2013 21:53 UTC (Wed) by simosx (subscriber, #24338) [Link]

That's an easy one.

The stock Firefox in Ubuntu has a User-Agent that looks like

> Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0

It says 'Ubuntu' inside the parenthesis, so this one is positively Ubuntu.

Chromium on Ubuntu (from repositories) has a User-Agent that looks like

> Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Ubuntu Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22

In the parenthesis it says 'Linux' and only outside the parenthesis there is a reference to Ubuntu. Most probably this one is counted are 'Linux Generic' instead of Ubuntu.

What you are seeing in the wikimedia stats is probably the rise of Google Chrome, which rises accordingly on GNU/Linux distributions.
See http://gs.statcounter.com/ for info on the rise of Google Chrome.

Dividing the Linux desktop

Posted Jun 19, 2013 23:57 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Please understand that Ubuntu specifically patches the firefox and chromium to add back their vendor string and that makes them a bit of a rare duck.

firefox as shipping in fedora no longer lists a vendor at all
firefox as shipped in opensuse no longer lists a vendor at all

And to really bake your noodle... some versions of stock linux mint firefox... lists ubuntu..because they didnt change the UA string patch ubuntu includes in their debs..so you can't even separate out mint clients from ubuntu clients in the wikimedia stats. Is mint or ubuntu more in use in the desktop now? wikimedia stats cant tell you for sure. Can't say from those stats. And I know some people in both camps who would love to be able to say one way or the other for sure.

I've looked at this a lot, fired up a lot of live images across multiple distributions checking the ua strings. The rise of the unknown linux is wikimedia is very complex. Its partly due to chrome showing up, but thats not the only factor. There are multiple ways to rationalize the unknown linux that are not supportable by the facts in hand. The rise of unknown linux and the fact that its the largest linux vendor in the stats and has been for over a year now really can only be reasonable lead to the conclusion that you can't rely on the ua string to tell linux vendor.

The size of the unknown linux category represents the uncertainty in the vendor-ness of linux clients quite broadly. At best you can sum up all the non-android linux vendors in the stats together and say that according to wikimedia non-android linux is stagnant percentage of client marketshare year to year...with some monthly variation.. there is some seasonal ebb and flow...but long term...pretty stagnant. Only android has really seen any real market percentage from a wikimedia clients pov since i started trending the stats.

Even if you take the very whimsical view that all the unknown linux is one vendor, of your choosing.... that one isn't gaining market share over the last couple of years. So meh. All the growth is iOS and Android. Not much really to talk about beyond that.

Dividing the Linux desktop

Posted Jul 2, 2013 3:05 UTC (Tue) by maxiaojun (guest, #91482) [Link]

All "home users" with their right mind switched to Google Chrome (not Chromium) already on Linux as well as big-two proprietary OS, reasons are many. ( This is a claim based on my observation of my friends, no one bother to use Linux desktop, of course. )

Yes, privacy extremist may still prefer Firefox, well, privacy extremist should hate Ubuntu 12.10+ also.

Google Chrome has been recommended by OMG! Ubuntu! for quite some time (through article like N things to do after install Ubuntu X.Y)

( I still use Firefox from time to time, but cannot notice any advantage except some Web developer features. For example, 3D view can sometimes help debugging CSS issues. )

For Linux desktop's overall growth, I see the only way is through OEM. Switch to an OS that no company supports isn't fun at all. And ask for community support can 99% times lead to worst customer experience. (I know support expectation, but then why people trust your software then? Can you guarantee it is bug free in any tiny aspect?)

I use Ubuntu as a community distribution also. Yes, it is far from ideal, but at least there is no enterprise Linux non-sense and Canonical have interest on end user market.

Dividing the Linux desktop

Posted Jul 2, 2013 9:27 UTC (Tue) by dlang (subscriber, #313) [Link]

> All "home users" with their right mind switched to Google Chrome (not Chromium) already on Linux..

Actually, I've tried Chrome a few times and keep going back to Firefox because Firefox uses less memory with my hundreds of tabs across dozens of windows.

Dividing the Linux desktop

Posted Jul 5, 2013 20:03 UTC (Fri) by The_Barbarian (subscriber, #48152) [Link]

>All "home users" with their right mind switched to Google Chrome (not Chromium)

No, I use SeaMonkey since it was Mozilla, and probably always will. I use FF and Chromium very occasionally for special purposes

Dividing the Linux desktop

Posted Jun 19, 2013 21:47 UTC (Wed) by simosx (subscriber, #24338) [Link]

We typically discuss about 'GNU/Linux' distributions, which precludes Android.
Android should probably be better called 'Android/Linux' or something.

Android does not come with GNOME, KDE, GNU or anything like that, so the important stats are about GNU/Linux.

Dividing the Linux desktop

Posted Jun 19, 2013 21:44 UTC (Wed) by simosx (subscriber, #24338) [Link]

> Well it's not about developing, it's about maintaining the code and the cost to have the code in the source tree.

Well, "maintenance" even. Instead of shooting your project in the face and alienating your downstream, can't you be a darling and say something like:

"We welcome all developers to our project. For the part of Mir support, there is need for developers to design, implement and maintain the new code. We are willing to guide potential developers so that they can lead and maintain the Mir support."

Dividing the Linux desktop

Posted Jun 20, 2013 6:59 UTC (Thu) by mgraesslin (subscriber, #78959) [Link]

The point is how this affects the development because the code is there.

Let's have a look at a real world example. Yesterday morning tvoss asked me a few questions about KWin internals. He correctly saw that we have an internal interface OpenGLBackend which would need to be implemented. KWin currently has three implementations of this interface:
* glx
* egl on X
* egl on Wayland

With Mir it would be a forth.

This is by pure chance also the code I worked on over the last few days. I quite refactored the egl on Wayland backend and noticed that the interface needs some more pure virtual methods (it was already marked as a TODO when I initially wrote the code to remember that this needs to change once a Wayland backend is there). I added the virtual method, implemented it in glx, implemented it in egl on Wayland, compiled and was surprised: I forgot to adjust the egl on X code. The good thing is the compiler caught it.

The bad thing is what that means for a possible Mir backend. As I have already explained: it would be in an ifdef, so the compiler would not notice that I forgot adjusting the code. Even if I do not forget about it, I cannot even do a test compile (bad) even less test the code (really bad). Now during review it would probably not been spotted either because most likely nobody else is having the setup. And even our CI would not catch it as well it's not Ubuntu. So when would it be noticed? And yes even if that would be fixed later on by Mir developers it means work for me as the maintainer. I have to review the patch (which I cannot properly do as I cannot test the code).

Allowing code in comes with a huge cost. This cost is given to the maintainers of the software. The reason must be really, really good to justify it. I once attended a podium discussion about CLA and IIRC there was a supporter of CLA saying that the CLA is justified because adding code comes with a maintenance cost.

For KWin we have a list of requirements when to allow a new feature in: http://community.kde.org/KWin/Mission_Statement#Developer...

If the code gets written and passed to us it will be evaluated given these requirements like any other feature passed to us by non core developers.

Dividing the Linux desktop

Posted Jun 18, 2013 11:14 UTC (Tue) by Sho (subscriber, #8956) [Link]

For the record, note that many applications made by the KDE community run just fine on Windows, and KDE.org even maintains an official binary distribution at http://windows.kde.org/. mgraesslin (who maintains KWin) is talking about Windows support in the window manager, which is a fairly dubious proposal indeed. The APIs to interact with the windowing system that are found in KDE's libraries are already platform-neutral.

Dividing the Linux desktop

Posted Jun 18, 2013 0:29 UTC (Tue) by daniels (subscriber, #16193) [Link]

> As I say, technical arguments are fine. But the wail of "but they can't do that, WE are the anointed future" is not.

Wayland is freely licensed under MIT/X11. Mir is GPLv3 with a CLA. So no, not quite the whine, nor are they the same thing.

Dividing the Linux desktop

Posted Jun 18, 2013 9:08 UTC (Tue) by zyga (subscriber, #81533) [Link]

Anyone can keep republishing Mir as FreedomMir without the CLA so why is GPLv3 now somehow less proper than MIT/X11 license?

Dividing the Linux desktop

Posted Jun 18, 2013 9:27 UTC (Tue) by mgraesslin (subscriber, #78959) [Link]

Let's look at the example KWin:

KWin is GPLv2+, this means that a user can choose between:
* GPLv2
* GPLv3
* any other later version of GPL if they exist

Now if we link to Wayland, nothing changes because Wayland is MIT licensed. If we link against the Mir server libraries the only possible choice is GPLv3. This means we take away the freedom to choose the license.

I know that there are people saying that this sounds like a made up argument and that GPLv3 is the best thing in the world and everyone should switch to it.

But I see this more pragmatic. Ten years ago everybody would have agreed that GPLv2 is the most awesome thing in the world and that there is absolutely no need for a GPLv3. Nowadays we have a GPLv3 which is even incompatible with GPLv2. What if in future there is a GPLv4 and we would want to use it? We would not be able to do so because we have a dependency on a GPLv3-only library.

For me it's also that the developers who started KWin did the deliberate decision to make KWin GPLv2+ instead of GPLv2-only. Also we did the deliberate decision to not change the license to GPLv3+. Now KWin is a rather old software (from 1999) and I think this license choice is part of the inheritance which needs to be preserved. You don't gamble with something which served us well for over a decade. Given the age of KWin I'm more thinking in what will us help over the next ten years and not about how can we get to be used in Ubuntu tomorrow.

So in summary: for me as maintainer a GPLv3-only library is not an acceptable dependency.

Dividing the Linux desktop

Posted Jun 18, 2013 10:36 UTC (Tue) by raof (subscriber, #57409) [Link]

The client library is LGPL3. That's still a non-trivial license, unlike MIT, but it's nowhere near as restrictive.

It would severely limit the set of clients if the client library was GPL!

Dividing the Linux desktop

Posted Jun 18, 2013 11:28 UTC (Tue) by daniels (subscriber, #16193) [Link]

Er yeah, my bad, sorry.

Dividing the Linux desktop

Posted Jun 18, 2013 10:00 UTC (Tue) by daniels (subscriber, #16193) [Link]

License incompatibilities, and commercial vendors are (surprisingly) terrified of it.

Dividing the Linux desktop

Posted Jun 17, 2013 21:31 UTC (Mon) by drag (subscriber, #31333) [Link]

> at the same time that they shout down people who are worried about Waylands lack of remote support.

Pointing out how people are wrong to believe that X11 supports network transparency along with the fact that Wayland is going to support remote applications just fine is not 'shouting down'.

It's just pointing out that there is nothing going to be lost by dumping X11 protocol as a native feature of the display manager.

Dividing the Linux desktop

Posted Jun 17, 2013 23:20 UTC (Mon) by nix (subscriber, #2304) [Link]

Pointing out how people are wrong to believe that X11 supports network transparency
This web server is running remotely. Am I hallucinating?

There exist applications (e.g. 3D ones) for which X cannot currently implement network transparency. That's because the work hasn't been done (because the OpenGL API is frickin' huge and indirect GLX has stagnated), not because of some fundamental inability to support network transparency. When X was originally implemented, it was fully transparent, and all the stuff that worked then still works now.

It is true that X is aging and lots of the core protocol is unused and other parts of it are roundtrippy and way too latency-sensitive -- but you don't need to make up extra X problems that aren't there. X has quite enough as it is.

Dividing the Linux desktop

Posted Jun 17, 2013 23:20 UTC (Mon) by nix (subscriber, #2304) [Link]

Argh. Of couse, I meant 'this web browser', not 'this web server'. And I clearly need sleep...

About GLX protocol...(tangent)

Posted Jun 18, 2013 5:55 UTC (Tue) by Kayden (subscriber, #89093) [Link]

Technically, yes - GLX protocol could be written to support indirect rendering with "modern" OpenGL features (beyond 1.4). But it's not feasible to do so in a manner that's useful beyond a proof of concept.

GLX works by having clients (applications) serialize OpenGL calls into protocol which gets sent to the X server. The X server then does the drawing on the GPU and displays it.

Modern OpenGL applications make extensive use of buffer objects that (at least conceptually) live on the GPU. These often store vertex data (VBOs), index data, or texture/image data, but can be anything the application wants. Applications can memory map these buffers via calls like glMapBuffer(), and in fact it's quite common. For example, an application might map a vertex buffer, copy in new vertices, unmap, and then draw. Or, it might ask the GPU to write transformed vertex data into a buffer and then map it to do some CPU-side processing.

Supporting this can be a real challenge. Depending on the call, the GL implementation might not know which parts of the buffer the application is going to access. It might have to copy everything---possibly both ways for a read/write mapping. Also, if the X server is on a big-endian system but the client is on a little-endian system (or vice versa), byte-swapping is necessary. Yes, this is unlikely, but GLX allows it.

This sort of buffer access is extremely common, and crucial to performance. Separating an application from its data via protocol begins to look rather crazy. If modern 3D can't be done efficiently via GLX protocol, one begins to wonder if it's worth defining it.

If the goal is remote display/network transparency, there's another design that's much better: draw everything on the client/application side, then use XPutImage to send the data to the remote X server.

This new kind of "indirect" rendering offers many advantages:
1. Complete feature parity. Applications displaying remotely have the same feature set as they would when running locally.
2. Better network efficiency: for a complex scene, the final rendered pixel data is often smaller than the data and serialized commands required to produce it. So it's cheaper to send the image across the wire.
3. Less overhead: protocol only needs to happen per-frame (or sync point), rather than for every GL call.
4. No new protocol required: new OpenGL features can be implemented without the extra cost of defining and implementing protocol. Not to mention syncing up X server and driver releases.

This is essentially the plan discussed at the X Developers Conference (XDC) last year, with no objections. It's definitely a plan inspired by EGL and Wayland, which already take this approach.

About GLX protocol...(tangent)

Posted Jun 18, 2013 12:58 UTC (Tue) by nix (subscriber, #2304) [Link]

Thank you for the superb explanation -- and, yes, I'd agree that for remote rendering of GL apps, this is probably the only approach that makes sense. However, GL apps are generally not the sorts of apps that face you with a great big canvas you can scroll around on, while most apps that people actually *use* for day-to-day work are of precisely this nature. For them, chucking bitmaps about is only practical if you can also chuck about 'scroll the canvas please'. If you're hooking in at the GL API level this is clearly practical. If you're hooking in at the 'big bucket of pixels' level, this is less obviously true.

About GLX protocol...(tangent)

Posted Jun 19, 2013 6:42 UTC (Wed) by liam (subscriber, #84133) [Link]

You should be able to say "scroll this texture by x amount" using motion vectors. IOW, transmit the screen using some VERY basic techniques from video codecs.
I think spice uses something similar.

About GLX protocol...(tangent)

Posted Jun 22, 2013 16:58 UTC (Sat) by kleptog (subscriber, #1183) [Link]

You say "GL apps" as if all OpenGL programs use fancy 3D, but this is not the case. The GL stands for "graphics language" and does everything, including drawing lines and rectangles.

Just like Xlib provided a graphics language for drawing to the the screen, so does OpenGL, but the latter is more standard and actually bears some relationship to how modern graphics cards work. And is actually supported almost everywhere.

The scrolling issue is definitely something to remember. If toolkits can remember the handful of widgets that do scrolling and handle those regions separately I think you can get all the benefits without much work.

Mind you, I expect that at some point Wayland will get a method for accepting raw MPEG encoded data, so you can watch movies smoothly even remoted.

Dividing the Linux desktop

Posted Jun 18, 2013 6:06 UTC (Tue) by geofft (subscriber, #59789) [Link]

Is your remote web browser usefully distinguishable from, say, running a remote web browser on a Windows system over RDP / Citrix? Or using VMware Workstation's "unity mode"? You'll still see a single window that can be manipulated just like a local window.

Basically, while it's true that "network transparency" is a property of X11's wire protocol and not of Wayland's or Mir's (or the Windows or OS X display layers), it's not clear to me that it's meaningful to use "network transparency" to describe the actual user experience of running an app remotely, since there are enough ways to implement the same experience without using a network-capable wire protocol.

Dividing the Linux desktop

Posted Jun 18, 2013 12:56 UTC (Tue) by nix (subscriber, #2304) [Link]

I see a single window! Until I want to copy something out of it, oops, no shared clipboard. Or until I want to scroll a line down, oops, bitmap repaints (unless the server is smart enough to recognize that the scroll is a scroll and send a CopyRect, which AIUI Wayland's remoter will not be). Or until I want to open more than one window (thankfully a problem Wayland will not have, though a SPICE or VNC view onto a virtual machine is necessarily afflicted by it at present).

Dividing the Linux desktop

Posted Jun 18, 2013 13:15 UTC (Tue) by anselm (subscriber, #2796) [Link]

I see a single window! Until I want to copy something out of it, oops, no shared clipboard.

VirtualBox makes that work even between X11 and Windows, so I wouldn't be surprised if sometime down the road X11 and Wayland can have a shared clipboard. (Then of course the clipboard is one of the more cobweb-infested parts of X11.)

… that the scroll is a scroll and send a CopyRect, which AIUI Wayland's remoter will not be

Again, that may not actually be engraved in stone for all eternity.

Dividing the Linux desktop

Posted Jun 19, 2013 0:04 UTC (Wed) by daniels (subscriber, #16193) [Link]

Wayland's remoting implementation is more than smart enough to detect scrolling and special-case it, and has been for months:
http://people.freedesktop.org/~krh/rolling-hash/f8.png
http://people.freedesktop.org/~krh/rolling-hash/f9.png
http://people.freedesktop.org/~krh/rolling-hash/f8-f9-deb...

Dividing the Linux desktop

Posted Jun 18, 2013 17:37 UTC (Tue) by mitr (subscriber, #31599) [Link]

Shared libraries can automatically give you symbol versioning = backward compatibility transparent to callers.

You can of course do versioning within a protocol, but it is a protocol-specific manual work, and the tooling is typically worse. ("What version of the protocol does this binary require?" "Does the display server support that version?" Symbol versioning automatically gives you this kind of metadata, the metadata is the same for all libraries, and automatically supported by RPM dependencies.)

So, as long as the protocol is local only, and only used within the library, having the library API be the only stable interface makes a lot of sense to me. (Having an unstable network protocol would of course not do at all.)

Dividing the Linux desktop

Posted Jun 17, 2013 19:16 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

as for other distributions... the mir dev team isn't making it particular easy to get mir built outside of Ubuntu. So... meh.

Case in point: The mir build from source instructions currently available point to a need for a specially patched mesa in order to be able to test the mir binaries with the mir client code provided intree. Not even talking about testing Unity yet..just mir using the toy mir clients provided. So far there's no effort to identify exactly which patches those are. The assumption seems to be that if you are working with mir source you are going to be pulling whatever dependencies you need from the Ubuntu binary repositories as a starting point. And really that's a non-starter for for a lot of us. There seems to be no real interest in providing an on-ramp for anyone looking to work with mir at the source level.

I've no idea what out of tree mesa patches are necessary...its entirely undocumented as part of the mir source build and test breadcrumbs. And picking apart Ubuntu mesa packages to try to figure out what mesa patches I actually need is basically a bridge to far for me personally to bother with again. This is a general problem with how Canonical has approached building any "Unity" experience..historically. They are very quick to patch whatever it is they need at any level in the dependency stack in other project code to get things working for Ubuntu... and only for Ubuntu...without making an effort to document for externals..working with the project source code the sufficient information concerning the necessary patchsets needed to be applied to out of project tree code (like mesa in this case) so you can start with stock upstream releases for the dependencies and get something testable.

And that's fine if there really is no interest in seeing their "upstream projects" like mir integrated into anything outside of Ubuntu. But if they really want to get external projects working with the tech they need to do a much better job providing the source level information for working with the source code in "clean" upstream code environments that are not pre-infected by vendor patchsets in any dependencies.

-jef

Dividing the Linux desktop

Posted Jun 17, 2013 19:36 UTC (Mon) by dlang (subscriber, #313) [Link]

they are working to get things running for themselves. I'm holding off criticism until they have something working and then see what they do with it.

Remember that the "release early, release often" requires that the early versions that you release are actually usable, from that point the community can build on them.

But if that early version isn't usable, trying to get a lot of people involved isn't a good idea, especially if you aren't sure if those people understand the vision of what you are trying to do.

If they are hostile to getting this cleaned up after they have shipped it, then I will jump on the bandwagon against this.

Dividing the Linux desktop

Posted Jun 17, 2013 19:54 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

All i'm saying is... they could go as far as to provide the instructions to pull the necessary prereqs from source control and build from source instead of assuming a specific vendor patched binary environment as a starting point.

Wayland upstream has done a reasonable good job of providing git based build from source instructions so you can track the head of all the moving pieces when bootstrapping up a wayland/weston entirely from source..daily if you really wanted to. And its been like this for a while. Whether or not its day-to-day usable isn't not the point. Day-to-day buildable. Day-to-day testable... in whatever environment you are in. That's the point, especially for anyone who is interested in packaging this up as a piece of tech for !Ubuntu and wants to start looking for testable regressions ahead of officially packaging this crap for a wider audience.

This has nothing to do with being day-to-day usable. This is able day-to-day testable outside of Ubuntu. If they want upstreams like KDE to take this seriously as a technology to support...and more important to think of mir as an "upstream project" team they can work with, then the mir team needs to do more they make patronizing statements and offering to have conference calls with externals and start providing vendor neutral instructions on how to work with the project sourcecode. This crap isn't hard. In fact its easier now that we have distributed source code control systems. Mir devs are getting the basics of being an "upstream" project wrong and making on-ramp documentation vendor specific assumptions baked-in. The project would benefit if someone in the team did a linux from scratch install and tried to bootstrap mir on that target...just sayin.

-jef

Dividing the Linux desktop

Posted Jun 17, 2013 20:19 UTC (Mon) by dlang (subscriber, #313) [Link]

> The project would benefit if someone in the team did a linux from scratch install and tried to bootstrap mir on that target...just sayin.

I agree with you that this would help.

I just disagree on how critical it is to do this at this point in development.

At this point, the fact that they are expressing willingness to help kubuntu is a very good thing and a big step forward from where they were 6 months ago.

As I am reading it, they are offering real help, not just "there is the documentation, have fun".

I suspect that the work with the Kubuntu team will end up causing other changes in Mir that will help it in the long run

I am putting a lot of what we have been seeing down to the pressure to to get it working and shipped on a deadline.

Dividing the Linux desktop

Posted Jun 17, 2013 21:00 UTC (Mon) by ovitters (subscriber, #27950) [Link]

They're offering help yes, but I don't expect it to be useful. You basically have to use Ubuntu. Seems easier to assist with Wayland, less hassle to get it running plus not focussed on one distribution.

There was some talk about test-driven development. It is kind of hard to run tests if parts aren't available on every distribution. See e.g. http://build.gnome.org/ostree/buildmaster/tasks/integrati.... This actually starts things in a VM and so on (for whatever reason, it seems to fail first, then runs again and then it works).

For something as low level as a display server, to just target one distribution might get you something workable quicker (no need to convince upstream if you can either fork things or add patches). But then don't expect much help from others or assistance in other components which run on multiple distributions (e.g. no clue how gtk+ maintainers are supposed to review a patch adding Mir support).

The whole thing to me is interesting. Ubuntu was like another distribution, seemed to move towards being like Android (meaning: something different). My annoyance with Mir was with the lack of communication regarding the change of direction (not Wayland anymore) and wrong information regarding Wayland. Further, I initially thought they'd totally go their own way, but now they've seem to have changed their minds.

No clue how to be successful. But hopefully Mir still encourages open drivers in which case Linux kernel will get better. Android seem to have become successful in a very short amount of time.

Dividing the Linux desktop

Posted Jun 17, 2013 23:42 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

For something as low level as a display server, to just target one distribution might get you something workable quicker (no need to convince upstream if you can either fork things or add patches). But then don't expect much help from others or assistance in other components which run on multiple distributions (e.g. no clue how gtk+ maintainers are supposed to review a patch adding Mir support).

I think the goal of quicker development is exactly the point. Ubuntu wants to get a new display server developed ASAP, and they think it will be quicker and easier to do it themselves. Some of that is probably the social issue of cooperation with upstream, and some of it is that they hope to work faster by initially targeting only Unity. More than incidental support for anything but Unity will come once they have a working system.

The larger issue, IMO, is one of trust. Ubuntu does not have a great track record of working with outside projects. When they announce that they're developing their own new display system for their own desktop environment, there are naturally some questions about compatibility with (and commitment to) other desktop environments. This is a social problem rather than a technical one, but it's still a genuine problem, and Ubuntu will continue to face serious public skepticism until they tackle it convincingly.

Dividing the Linux desktop

Posted Jun 18, 2013 0:12 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

speaking of...trust.

What is the roadmap for upstreaming the mesa backend for mir? Should I just trust that this new egl backend is going to be upstreamed at some point in the future? I've yet to run across achived discussion about how the necessary mir related mesa bits are going to flow into the mesa mainline.

The current reality is that right now a testable mir binary requires a egl mesa backend for mir, that exists as a distribution specific patchset against stock mesa in the bowels of the ubuntu packaging. I've seen no discussion anywhere on when that backend is going to be upstreamed into upstream mesa to live as a peer with the wayland backend. And I'm not keen on pulling apart the ubuntu mesa packages to find which patches Mir needs so I can test Mir locally outside of an Ubuntu environment.

For Mir to be trusted outsite of Ubuntu..outside of Canonical's secretive decisioneering and business interests, it has to be vendor neutral buildable and testable. Once Mir is buildable/testable as a vendor neutral tech, then that will be the point in time when other upstream DEs can seriously start taking a look at supporting Mir. Expecting everyone else to be running any specific Vendor supplied environment is just well...silly. Once those external developers for those other DEs are able to get a Mir stack up and running in whatever environment they normally work then they can make headway trying to use it and support it.

Until then the workload falls entirely on the shoulders of the people using Ubuntu day-to-day and can get access to the necessary vendor-specific patched environment that Mir requires. And it seems to me, that's not generally as widely an overlapping population with upstream DE developers as one would be led to believe based on accepted popularity of Ubuntu as day-to-day environment.

-jef

Dividing the Linux desktop

Posted Jun 18, 2013 8:21 UTC (Tue) by ovitters (subscriber, #27950) [Link]

For some Unity things, they first had their own thing, patching all kinds of applications. Then a long time after that they upstreamed it properly. This usually implies a totally different implementation.

I'm thinking of that global menu that they had. Eventually it resulted in GMenu which is now part of glib. Totally different implementation to reach the same goal

I'm guessing this will happen again: To upstream there might be a totally different implementation than what they do short term. Different way of developing, but seems ok as long as there is not too much expectation that upstream should just (or can) accept the patches as-is.

Dividing the Linux desktop

Posted Jun 18, 2013 10:20 UTC (Tue) by raof (subscriber, #57409) [Link]

I pushed a first go RFC of the Mir EGL platform to the mesa-dev list a month or so ago; it got no comments, but that's fine - I wasn't sure how much the client API was going to change from that point, so it wasn't intended to merge then.

We're probably reaching a point where it can usefully be upstreamed.

Dividing the Linux desktop

Posted Jun 18, 2013 16:11 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

I'll look back over the list for the rfc again, as I obviously missed it.
In the meantime, be a dear, and get the build from source instructions for mir updated to include instructions to track the tip of mir devel to also provide instructions to pull and build the necessary matching patched mesa from a git/bzr branch so mir can be build-testable cleanly...outside of an environment with a well-conditioned apt-get.

-jef

Dividing the Linux desktop

Posted Jun 18, 2013 19:51 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

Found it the mesa-dev post dated march 5th, during the 3 days or so that I missed when I was experimenting with time travel. Occupational hazard.

Since the email specifically mentions the submitted patch isn't meant for upstream inclusion...just for review... I take it that means to get mir heading building and testable there is a need for a newer mesa diff. I could really use a pointer to the buildable pre-upstreamed mesa source tree that the mir ppa staging automation is relying on for the patched mesa.

-jef

Dividing the Linux desktop

Posted Jun 17, 2013 21:23 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

Helping kubuntu isn't the solution. Helping kubuntu create and carry additional vendor patchsets is not a win for anyone....not really. That will just drive a technical wedge between kubuntu and upstream KDE.. making it harder for upstream KDE maintainers to work through issues with the kubuntu team. It's going to be really frustrating for everyone when kubuntu users see some mir specific oddness and KDE developers have to turn their back on helping because mir is only dogfoodable in a single vendor patched environment. This does not make for good project relations.

The win is to make it possible for mir as a project to exist as a vendor neutral technology. So everyone who needs to rely on it as a plumbing tech can track its development head..dogfood its development head... day-to-day..and get _ahead_ of problems before they show up. So yeah its actually sort of really important to make a project digestable to other developers while its still under heavy development..exactly to get ahead of problems...instead of keeping your vendor-fenceline externals at arms reach or a version or two behind development head. keep development head consumable by the project devs who are going to need to trust it 6 months from now. I mean crap man, if the linux kernel was developed as a vendor specific environment... assuming deb or rpm repository structuring...it be absolutely horrible to work with. The display server isn't really that different in that regard. Build the project as vendor neutral as you are able from day-0 or else the project won't be ecosystem relevant and you won't get the synergy benefits inherent in open development.

points of ramble

Posted Jun 17, 2013 20:53 UTC (Mon) by tstover (guest, #56283) [Link]

-I still simply can not understand why anyone can think of Android as a Linux distribution.

-For the eleventeenth time, Wayland is at least suppose to support remote applications (rootless and otherwise).

-A "shared library as protocol interface" is, in the abstract, a perfectly legitimate architecture. A well written, properly licensed library, is even better than a reference document.

-The command line UI model, is a mature thing that everyone gets, and will be around forever (not TUIs, just command lines). Will there ever be a GUI model that can have the same said about it?

-A "unified" UI for all form factors & use cases == total fail.

-Don't forget the fun. For example, an important career affinity for me was realizing that as it is now, "mobile" == not fun. Writing software (yes even on Linux) that is not fun to do, is a terrible waste of your life no matter how much money is involved. If other people think is fun, then just let them enjoy their life, and quit hating on everybody. Linux != fascism. Fragmentation == fun.

points of ramble

Posted Jun 17, 2013 22:54 UTC (Mon) by whiprush (guest, #23428) [Link]

> I still simply can not understand why anyone can think of Android as a Linux distribution.

It uses a linux kernel and it's distributed to people via hardware. That's pretty much the definition of what a "Linux distribution" is.

There's no hard and fast rule that a "linux distribution" has to use GNU tools, X11, or any of the other things that other distributions have in common.

points of ramble

Posted Jun 17, 2013 23:29 UTC (Mon) by sbergman27 (guest, #10767) [Link]

All the work that FSF has done to associate themselves with the Linux name, where they wanted to, and to dissociate themselves, where they wanted to, has come back to bite them in the posterior. Linux took over the consumer world. But GNU got left behind. Linux and GNU are two completely separate things, remember. Linux is a kernel. And GNU software is not needed by most computers running Linux today.

points of ramble

Posted Jun 18, 2013 4:37 UTC (Tue) by rahvin (subscriber, #16953) [Link]

<blockquote>And GNU software is not needed by most computers running Linux today.</blockquote>
Bold statement. Can you point to a single product using Linux (software or hardware) that isn't using any GNU?

points of ramble

Posted Jun 18, 2013 6:08 UTC (Tue) by eru (subscriber, #2753) [Link]

Didn't Google work hard to excise all GNU out of Android? (as distributed to end users- the development environment might be another thing).

points of ramble

Posted Jun 18, 2013 10:36 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Android runtime has no GNU software left.

The whole Android toolchain still depends on GNU tools, but this is probably only because nobody cares about removing GNU Make and other small utilities.

GNU vs. Linux

Posted Jun 18, 2013 11:36 UTC (Tue) by DonDiego (guest, #24141) [Link]

I will specifically *not* take a side in the debate, but more and more the contribution of GNU to my and any Linux system is shrinking. The size of the software stack I work with increases, the GNU part of it does not. In addition, the GNU bits play a less and less central role as glibc and gcc are starting to get displaced. The only important (for me at least) piece of GNU software without an alternative that is eating into its "market share" is GNU Make...

GNU vs. Linux

Posted Jun 19, 2013 7:21 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Well, I doubt autotools will gain support for it, but I've been using Ninja to build pretty much anything I can at work (generated by CMake). That said, I do still use make for things like batch jobs which can take hours and might get interrupted so that I get resume support for free.

points of ramble

Posted Jun 20, 2013 10:00 UTC (Thu) by dvdeug (subscriber, #10998) [Link]

People keep saying that Linux is a *nix or a Unix-like operating system (e.g. Wikipedia's "Linux is a Unix-like computer operating system...".) If all that Linux was was a kernel, that would make no sense; kernels are but a small part of a Unix-like system, and as Android shows, a system that has a Linux kernel can be nothing like Unix. There's also a Linux Standards Base document, which defines something that looks nothing like Android. You don't have to follow a standard to the tee, but when you don't have stuff like /etc and /bin or basically any of the commands the LSB requires, you're not talking about the same thing.

Everyone who has ever argued against GNU/Linux is implicitly arguing that Android is not a Linux distribution, because otherwise it would be important to mention what the userspace (the GNU part) looked like, that it was in fact Unix-like.

points of ramble

Posted Jun 17, 2013 23:05 UTC (Mon) by bojan (subscriber, #14302) [Link]

> -I still simply can not understand why anyone can think of Android as a Linux distribution.

Although not your typical GNU/Linux distribution, surely a piece of software that has Linux kernel underneath can be called that (by definition). No?

points of ramble

Posted Jun 18, 2013 14:35 UTC (Tue) by marcH (subscriber, #57642) [Link]

> -For the eleventeenth time, Wayland is at least suppose to support remote applications (rootless and otherwise).

For the nth time, most people don't care about vaporware. Especially not people here.

Just more fragmentation, nothing else

Posted Jun 17, 2013 23:19 UTC (Mon) by bojan (subscriber, #14302) [Link]

Once upon a time I thought that having multiple desktop environments, toolkits, APIs and what not was a matter of choice. These days, I'd say I'm more in the "complete and utter fragmentation" camp. So much wasted effort, pulling development in so many different directions, across pretty much all layers of GUI. I'm pretty sure that most third party applications developers (i.e. not us die-hard open source fans) are looking from the sidelines and thinking - I'm staying away from this mess.

Linux desktop (given the maturity of the kernel and libraries that comprise a typical distro) is at a point where it really could be a major platform, alongside Windows, OS X, IOS and Android. It is the GUI shenanigans that is keeping it from being one. Application developers have no idea what to target and where the whole thing is going, so the platform is thus far locked in niche status.

Something or somebody has to win here. Then we may be going somewhere.

Just more fragmentation, nothing else

Posted Jun 17, 2013 23:57 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"""
complete and utter fragmentation
"""

"Fragmented like Unix did" is a phrase we used to hear as a prediction for Linux. On the Linux desktop, that does seem to have come to pass.

Just more fragmentation, nothing else

Posted Jun 18, 2013 8:36 UTC (Tue) by dgm (subscriber, #49227) [Link]

Indeed. But also evolved, survived and prevailed, like Unix did.

Organic growth is not the fastest way to go from A to B, but it is a far safer tactic in terms of survival.

Just more fragmentation, nothing else

Posted Jun 18, 2013 2:21 UTC (Tue) by aryonoco (guest, #55563) [Link]

Something did happen. It's called Android, and it showed that neither upstream nor copyleft matter. What matters is number of users, a stable API and solid development tools. Forget about all the technical merits of tiling vs. windowed WM and X vs. Mir vs Wayland and GTK vs Qt vs. ELF and the rest. We lost the desktop wars fighting each other over these, and as it turned out, none of them matter.

There are now more new Android devices sold every week than probably the total number of traditional desktop GNU/Linux users. By the end of the year, there will be more Android users than Windows users. There will be 1 billion Android users before the end of the year, 2 billion probably in a couple of years.

We can either do as Mozilla has done and jump on the bandwagon and try to steer it in the direction we want (more open development, reducing the delta with upstream kernel, open source drivers and application, etc) or watch from the sidelines and suffer the fate of old Unix workstation users.

Just more fragmentation, nothing else

Posted Jun 18, 2013 2:38 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

I don't disagree entirely but I will note that Mozilla is not really jumping on the Android bandwagon. The entire Android marketplace is missing in Firefox OS by design. They are pushing for a purely web based ecosystem and they seem to have some success in a different market segment.

Just more fragmentation, nothing else

Posted Jun 18, 2013 5:18 UTC (Tue) by b7j0c (guest, #27559) [Link]

firefoxOS really isn't on the table yet....afaik, you still cannot buy a phone anywhere that uses it by default

mozilla is currently producing the best browser for android. they're iterating way faster than the chrome team. i use ff nightly on android and even with the flakiness of a nightly, its the best mobile browser on any platform

Just more fragmentation, nothing else

Posted Jun 18, 2013 14:15 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

That is just not true. You can buy a phone that runs Firefox OS

http://www.geeksphone.com/

Disclaimer: I am not affiliated and have no idea how well it works but I know atleast two people who have bought it and seem happy with it.

Just more fragmentation, nothing else

Posted Jun 18, 2013 16:01 UTC (Tue) by ThinkRob (subscriber, #64513) [Link]

> That is just not true. You can buy a phone that runs Firefox OS

> http://www.geeksphone.com/

Eventually you will be able to buy a phone that runs Firefox OS, but as of right now you can't.

Both models are "out of stock".

-R

Just more fragmentation, nothing else

Posted Jun 19, 2013 7:32 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

What version of Android? On 2.x, I agree, but I've found Chrome's tab management to be much more usable than Firefox's. Had it changed from the pull-down and scroll thing? I guess I should take it for another spin this weekend if I get the time.

Just more fragmentation, nothing else

Posted Jun 18, 2013 2:40 UTC (Tue) by bojan (subscriber, #14302) [Link]

I agree with you, except for one thing - the article is about dividing the Linux desktop. Right now, Android does not really qualify as a Linux desktop. Sure, there have been some attempts to bring it to PC-like hardware (I mean: screen, keyboard, mouse - not touch screen stuff), but it's not there yet. Maybe in the coming years...

PS. Sometimes I wish Google didn't waste their time with Chrome OS and just brought Android to the desktop masses instead.

Just more fragmentation, nothing else

Posted Jun 18, 2013 8:36 UTC (Tue) by ibukanov (subscriber, #3942) [Link]

> PS. Sometimes I wish Google didn't waste their time with Chrome OS and just brought Android to the desktop masses instead.

I am glad that it was Chromebooks, not Androidbooks. Finally I was able to get a nice 100% silent laptop where one can have all the Linux stuff without paying Windows or even Intel taxes. I doubt it would be possible to run a Linux distribution on it just as easy if it would use Android.

Just more fragmentation, nothing else

Posted Jun 21, 2013 13:49 UTC (Fri) by bojan (subscriber, #14302) [Link]

And it seems that Samsung conspired to prove me wrong with their latest hardware...

Dividing the Linux desktop

Posted Jun 18, 2013 5:11 UTC (Tue) by josh (subscriber, #17465) [Link]

Personally, I don't see anything wrong with having the client libraries as the ABI rather than having a stable protocol, particularly for a display server that has no intention of providing network transparency in the protocol (as opposed to via VNC-like mechanisms). I think Wayland ought to do the same; I don't see the value in having reimplementations of the Wayland client libraries.

Too many FUDs about Ubuntu these days

Posted Jun 18, 2013 18:30 UTC (Tue) by maxiaojun (guest, #91482) [Link]

1. Ubuntu's Mesa stack is broken because of Mir and Unity.
Can anyone show me a concrete bug to confirm this? A bug caused Kwin to crash is due to attempting to support newer hardware. And the patch is sent upstream. It's a pity but any malicious intent here?

And for Mesa change needed to support Mir, an (unanswered) RFC is here: http://lists.freedesktop.org/archives/mesa-dev/2013-March...

2. Mir will break everything except Unity.
Some Mir developer claim that they run Unity 7 on XMir just fine. And Mir developer is confident about supporting various DE through XMir. The most "dangerous" DE seems to GNOME. As GNOME already made it depends on GDM and systemd, it is likely that they will depend on Wayland some day.

3. GPL3 used in Mir is bad
Maybe a valid concern in some sense. But again, any malicious intent here? And MIT style license is better for "free software"?

3. Ubuntu is trying to separate itself from the rest of Linux like Android.
There are two key difference here:
1. Ubuntu is not code dump, everything is available in LP.
2. Ubuntu doesn't attempt to remove GPL licensed components, instead, software from Canonical generally use GPLv3.
Yes, sometimes sloppy, cannot-upstream patch is used to implement some Unity features. But I see these as technical issues rather than malicious intents.

4. Ubuntu is declining after the introduction of Unity.
No, it isn't the case.
In the following example, serious researcher has no problem with Unity.
http://www.bbc.co.uk/news/technology-22780640
In the following example, author of <USB Complete> using Unity in one of her computer.
http://www.eeweb.com/spotlight/interview-with-jan-axelson
I'd also encourage people to try Google trend with keyword "suse, opensuse, ubuntu" and country Germany.
Also check Steam statistics:
http://store.steampowered.com/hwsurvey

Too many FUDs about Ubuntu these days

Posted Jun 18, 2013 19:56 UTC (Tue) by josh (subscriber, #17465) [Link]

I think you might have meant this as a reply to a different comment, or to the article?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 2:31 UTC (Wed) by maxiaojun (guest, #91482) [Link]

Yes, to the article.

Too many FUDs about Ubuntu these days

Posted Jun 18, 2013 20:38 UTC (Tue) by ovitters (subscriber, #27950) [Link]

GNOME does not depend on systemd; it is optional. We do depend on some APIs that can be implemented by anyone.

Too many FUDs about Ubuntu these days

Posted Jun 18, 2013 20:40 UTC (Tue) by ovitters (subscriber, #27950) [Link]

PS:
"1. Ubuntu is not code dump, everything is available in LP.
Yes, sometimes sloppy, cannot-upstream patch is used to implement some Unity features."

Code dump is exactly an "sloppy, cannot-upstream patch".

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 2:35 UTC (Wed) by maxiaojun (guest, #91482) [Link]

Apple is exactly an orange.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 3:08 UTC (Wed) by maxiaojun (guest, #91482) [Link]

Some patches are indeed needed to keep users away from upstream regressions.

For example, IBus 1.5.x (former 1.4.99.x) is still problematic. The upstream usually responds "It works on Fedora" and/or "It works on GNOME" to bug reports.

http://code.google.com/p/ibus/issues/detail?id=1618
http://code.google.com/p/ibus/issues/detail?id=1568
http://code.google.com/p/ibus/issues/detail?id=1542

As a result, Arch users are still facing some open problems.
Debian once introduced IBus 1.5.1 and revert back to 1.4.2 afterwards.
http://packages.debian.org/sid/ibus
Ubuntu keeps certain code of g-c-c unchanged starting from 3.4
There must be cannot-upstream patches here.
openSUSE created an extension to support IBus 1.4.x under GNOME 3.6, this is less intrusive I guess but the purpose is the same.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 9:53 UTC (Wed) by ovitters (subscriber, #27950) [Link]

How is this related to implementing Unity features? Seems you're changing topics.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 15:29 UTC (Wed) by maxiaojun (guest, #91482) [Link]

Input experience under Unity is preserved by patching g-c-c.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 12:48 UTC (Thu) by ovitters (subscriber, #27950) [Link]

I said "Code dump is exactly an "sloppy, cannot-upstream patch"."

A distro specific patch is not a code dump. Code dump is what Ubuntu/Canonical sometimes did. Meaning: take an existing patch, push it upstream without communicating beforehand..

Btw: You ask a lot of questions or claim some things to mean a certain thing which you can just figure out on your own for either the correct answer or definition. It wastes time.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 17:28 UTC (Thu) by maxiaojun (guest, #91482) [Link]

I mean Android style code dump when I say "code dump", thanks.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 2:32 UTC (Wed) by maxiaojun (guest, #91482) [Link]

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 2:36 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

That article doesn't change the facts. GNOME does not directly depend on systemd and never has. The few D-Bus API's GNOME depends on has been implemented by distributions not using systemd (Arch before they switch over, Ubuntu etc) in other ways.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 2:44 UTC (Wed) by maxiaojun (guest, #91482) [Link]

ANy real difference between "depends on libfoo" and "depends on libfoo's few D-Bus API's"

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 2:54 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Yes and I have already pointed out the difference. To expand on that, since GNOME is relying only on the D-Bus interface, distributions not using systemd can provide the same interface.

Several such examples are listed at http://www.freedesktop.org/wiki/Software/systemd/Interfac...

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 9:52 UTC (Wed) by ovitters (subscriber, #27950) [Link]

Various non-systemd using distributions have implemented these APIs.

Meaning: a non-systemd using distribution is using GNOME without using systemd.

Also, systemd is not a library.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 11:45 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

> 3. GPL3 used in Mir is bad
> Maybe a valid concern in some sense. But again, any malicious intent here? And MIT style license is better for "free software"?

The issue is not with GPL3 per-se. It is with the combination of GPL and the ability of a commercial entity to relicense the code under a proprietary license.

Precision licensing

Posted Jun 19, 2013 12:14 UTC (Wed) by pboddie (guest, #50784) [Link]

As I think someone else pointed out, use of GPLv3 isn't necessarily a problem (except for people making proprietary software), having Canonical as the gatekeeper isn't necessary a problem (because you can just fork the whole thing and ignore them and their contributor agreement), but what might be a problem is stipulating "only" against the version of the GPL chosen (the virtual equivalent of making a handprint in wet cement, where people showing their licensing prowess end up saddling everyone with a legacy licensing choice that is costly to undo or work around in future).

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 15:35 UTC (Wed) by maxiaojun (guest, #91482) [Link]

> the ability of a commercial entity to relicense the code under a proprietary license.

Wow, Check: http://cgit.freedesktop.org/wayland/wayland/tree/src/wayl...

See "Intel Corporation" in the header part?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 16:13 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Intel is not the sole copyright holder of Wayland. The license it's under does, of course, permit Intel to produce proprietary products based on Wayland - but it also permits everyone else to do the same thing. Mir's CLA grants Canonical an asymmetric right to produce proprietary products without permitting anyone else the right to do the same thing.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 16:31 UTC (Wed) by maxiaojun (guest, #91482) [Link]

> Mir's CLA grants Canonical an asymmetric right to produce proprietary products without permitting anyone else the right to do the same thing.

Can convince me this claim with a full link?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 16:35 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

http://www.canonical.com/sites/default/files/active/image... section 2.3:

"Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses."

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 16:57 UTC (Wed) by maxiaojun (guest, #91482) [Link]

OK, you are right. I also see that it is Option Five of 2.3 of http://harmonyagreements.org/docs/ha-cla-i-v1.pdf

But what is the real problem here? Can you point out any notable contributor of Mir outside Canonical?

And Qt also has a CLA anyway: https://qt-project.org/legal/QtContributionLicenseAgreeme... (check 3.1)

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:09 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

"Can you point out any notable contributor of Mir outside Canonical?"

Well, that's kind of a self-fulfilling prophecy. Having a CLA means that corporate entities are discouraged from contributing to a project (why would you work on something that a potential competitor can sell into markets that reject copyleft code without you being able to do the same?), and Canonical have done a pretty good job of burning bridges with community developers. Compare to Wayland, which *does* have significant contributions from non-Intel developers.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:41 UTC (Wed) by maxiaojun (guest, #91482) [Link]

> Having a CLA means that corporate entities are discouraged from contributing to a project (why would you work on something that a potential competitor can sell into markets that reject copyleft code without you being able to do the same?)

Cool, so the vision of free software is that multiple competing for-profit entities contribute to a same project and sell proprietary forks separately?

> Canonical have done a pretty good job of burning bridges with community developers.

Many thanks to FUD spreaders like Martin Gräßlin

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:48 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

"Cool, so the vision of free software is that multiple competing for-profit entities contribute to a same project and sell proprietary forks separately?"

Hey, you asked. I'd *prefer* nobody be able to sell proprietary forks. But if only one corporate entity is able to sell proprietary forks, no other corporate entity is likely to contribute.

"Many thanks to FUD spreaders like Martin Gräßlin"

I'd blame it on the complete unwillingness to put any effort into working with upstream communities, personally.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:19 UTC (Wed) by maxiaojun (guest, #91482) [Link]

> But if only one corporate entity is able to sell proprietary forks, no other corporate entity is likely to contribute.

Probably true, not a big concern for me, though.

> I'd blame it on the complete unwillingness to put any effort into working with upstream communities, personally.

I see this aspect of Canonical is improving. For example an RFC for Mir backend is sent to mesa-dev.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:23 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

"Probably true, not a big concern for me, though."

Sure, but it means you can't point at the Mir repository and say "No other corporate entities have made significant contributions to Mir, so the CLA isn't relevant" - it's more likely that cause and effect are the other way around.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:31 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

> Many thanks to FUD spreaders like Martin Gräßlin
Please read: http://blog.martin-graesslin.com/blog/2013/06/fanboys-in-... and think about whether it is OK to call me a FUD spreader and please show me where I have ever spread FUD.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:39 UTC (Wed) by jubal (subscriber, #67202) [Link]

(Another side comment; you don't spread FUD, at least not intentionally, but judging by your /public/ comments you seem to be a pretty unpleasant personality to deal with. While it's a trait shared by many floss developers, I still prefer dealing with people who treat their others more in a way Phil Hazel used to. Fortunately the more abrasive developers usually burn out earlier than later.)

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:51 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

I don't know Phil Hazel, but I would never write about other people, I do not know, that they have a "pretty unpleasant personality". So I have my own opinion and I talk about it in my blog posts. I admit that my writing is sometimes is not the best, after all it's not my native language and there are cultural differences. I write English like I would write German. German is a more direct language than what's common in the US.

Is that a reason to insult me? Is that a reason to say I have an unpleasant personality? Should I just say "yes and hurry" to everything so that everybody is happy?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:59 UTC (Wed) by maxiaojun (guest, #91482) [Link]

"Mir in Kubuntu" is full of FUDs; your ACK is not needed. Yes, you are not a XXX spreader if you think you do not spread your idea through blog posts.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 19:04 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

it's easy to say it's all FUD, but show me please which parts you consider as FUD. I invested lots of time to make the post not sound like FUD, but looked at the problems I see and also looked to have reliable citations for my claims. In fact this article on LWN uses quite a lot of the same sources I linked to. So is LWN also spreading FUD?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 19:24 UTC (Wed) by maxiaojun (guest, #91482) [Link]

> In fact this article on LWN uses quite a lot of the same sources I linked to. So is LWN also spreading FUD?

The LWN article is much more gentle and objective.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 19:56 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

what a surprise that it's more gentle. My profession is being a developer not a professional writer. About being more objective: well my post was intended to be subjective, after all I was writing about the possible problems of Mir in Kubuntu. How could that not be subjective if I deliberately only look on one side?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:07 UTC (Wed) by maxiaojun (guest, #91482) [Link]

> well my post was intended to be subjective, after all I was writing about the possible problems of Mir in Kubuntu. How could that not be subjective if I deliberately only look on one side?

So, naturally, the whole thing looks like FUD, sounds like FUD, and I thought it is FUD.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:26 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

Do you know what FUD means?
"FUD is generally a strategic attempt to influence perception by disseminating negative and dubious or false information"
My blog post does neither contain negative and dubious nor false information. I just re-read the complete post and cannot see how you come to this claim. Please show me what you consider as FUD.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:32 UTC (Wed) by maxiaojun (guest, #91482) [Link]

FUD stands for fear, uncertainty and doubt.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 18:02 UTC (Thu) by ovitters (subscriber, #27950) [Link]

You haven't shown how it applies to his post, though he did ask. Pretty impolite behaviour to say someone is not behaving in a nice way ("OMG, FUD!"), while not behaving nicely yourself.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 19:29 UTC (Wed) by maxiaojun (guest, #91482) [Link]

The FUD parts are all around your blog post "Mir in Kubuntu" except first few trivial paragraphs. Can you show me a single paragraph that you are confident about that it's not FUD?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:06 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

No, you claim I write FUD and I asked you to show it to me.

The only part which I accept as could have written better is the point about the buggy graphics stack in Ubuntu. I admit that this was an emotional point as we just at that time had seen (again) many crash reports due to breakage in the stack (https://bugs.kde.org/show_bug.cgi?id=314602). As I wrote I can see this in our bug reports and I gave the analysis of that to the Kubuntu developers before I wrote this blog post. And our bug tracker is open - you can look for yourself.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:17 UTC (Wed) by maxiaojun (guest, #91482) [Link]

Compare your
"""
So far Mir is a one-distribution solution. So far no other distribution has shown any interest in packaging Mir even if it would become a working solution. Unfortunately I don’t have the ability to see into the future, but I can use the past and the present to get ideas for the future. The past tells me that there are other Canonical specific solutions which are not available in other distributions. I do not know of any distribution which packages Unity and from all I have heard it’s even impossible to package Unity on non-Ubuntu distributions. Given that it is quite likely that Mir will go the same road. It’s designed as a solution for Unity and if distros don’t package Unity there is no need to package Mir.
"""
and LWN's
"""
The Mir specification does not describe it as a display server for all desktop environments; instead, it says "The purpose of Mir is to enable the development of the next generation Unity." There are a number of implications that come out of a position like that, not the least of which being that Mir and Unity appear to be developed in lockstep with no particular effort to standardize the protocol between them.
"""

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:29 UTC (Wed) by maxiaojun (guest, #91482) [Link]

So far KDE is a community-only solution. So far no OEMs has shown any interest in pre-install KDE even if it would become a working solution. Unfortunately I don’t have the ability to see into the future, but I can use the past and the present to get ideas for the future. The past tells me that there are other community-only solutions which are not available as OEM pre-installs. I do not know of any OEM which pre-install GNOME and from all I have heard it’s even impossible to pre-install GNOME on non-community OS. Given that it is quite likely that KDE will go the same road. It’s designed as a solution for community and if OEMs don’t pre-install GNOME there is no need to pre-install KDE.

No fact here, just try to mimic Martin's writing style.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:51 UTC (Wed) by mgraesslin (subscriber, #78959) [Link]

so you don't like my writing style? I don't mind, but I once again point you to the fact that I'm not a professional writer and that English is not my native language, but my writing is strongly inspired by my native language. If you don't like my writing style I can only give you one suggestion: don't read my blog posts.

I cannot understand why you consider this as FUD. If you think it is because I badly phrased this section, I'm sorry: it was not intended. Maybe you are over-interpreting my blog post?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 21:07 UTC (Wed) by maxiaojun (guest, #91482) [Link]

The problems I see are:

1. The tone is harsh rather than gentle. (you do read LWN, right?)
2. Some unfounded bold claims are made, e.g., always had worst stack. You've seen a serious bug then you say there is a serious bug. Not need for false generalization.
3. In general, you makes many solvable problems appear unsolvable. This is the key difference between constructive criticism and FUD.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 8:37 UTC (Thu) by ovitters (subscriber, #27950) [Link]

His blog posts aren't FUD. You're writing style is quite annoying as well, he has to ask you *multiple* times to be specific, while you only give generic answers or non-answers. You keep repeating "FUD", while ignoring his request for specifics.

Further, something not being not constructive criticism doesn't make it FUD.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 17:24 UTC (Thu) by maxiaojun (guest, #91482) [Link]

Repeat, the whole post is FUD except a few irrelevant paragraphs, period.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 17:59 UTC (Thu) by ovitters (subscriber, #27950) [Link]

Repeat, it is not FUD.

Done.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 17:37 UTC (Thu) by maxiaojun (guest, #91482) [Link]

There is no need pointing out a specific garbage item in a junk yard.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 17:59 UTC (Thu) by ovitters (subscriber, #27950) [Link]

Resorting to trolling also doesn't make it FUD.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 18:02 UTC (Thu) by maxiaojun (guest, #91482) [Link]

Reply more junk, please.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 18:40 UTC (Thu) by jake (editor, #205) [Link]

OK, I think we may have covered this completely by now. While I don't think "FUD" is being used here correctly either, it has sadly turned into a generic term for "something I disagree with", thus the miscommunication. But, all of that aside, I don't think anyone is going to change any minds here, so can we just stop at this point?

thanks,

jake

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 11:26 UTC (Thu) by morhippo (subscriber, #334) [Link]

@maxiaojun Can you please take your criticism of the language skills and style of a contributing open source developer elsewhere? I find such ad hominem attacks tedious. Judging by your criteria, e.g. Linus Torvalds should also refrain from posting on the internet, as his tone is certainly "harsh". I have not seen you make any factual sunbstantial statements that actually point out inaccuracies or falshoods in Martin's blog. So there is no FUD. And falsely claiming FUD is just trolling If there has been FUD, it has come from the MIR people who falsely claimed that Wayland did not work as intended for various reasons. These claims have been refuted, as far as I understand.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 17:34 UTC (Thu) by maxiaojun (guest, #91482) [Link]

> Can you please take your criticism of the language skills and style of a contributing open source developer elsewhere?

I do contribute elesewhere, in various ways.

Martin's FUD is certainly better than Microsoft's. As so many are confused by such junk post.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 18:01 UTC (Thu) by ovitters (subscriber, #27950) [Link]

Your post again lacks specifics.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 18:03 UTC (Thu) by maxiaojun (guest, #91482) [Link]

Who are you? I'm not replying to you.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:53 UTC (Wed) by maxiaojun (guest, #91482) [Link]

For the record,
"""
Ubuntu has always had one of the worst graphics stack in the free software world. I can see this in the bug tracker. The quality of the Mesa stack in Ubuntu is really bad. For Mir Ubuntu will have to patch the Mesa stack even further. This is nothing which I would like to see. Also Mesa needs to be packaged with Wayland support. But will Canonical continue to do this? If not, would Kubuntu (and other Ubuntu flavors) need to ship their own Mesa stack? What if the changes by Canonical are so large that a standard Mesa stack doesn’t run on top of the Ubuntu stack?
"""
OK, the information is not negative here? (not mention logical flaws)

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 7:02 UTC (Thu) by mgraesslin (subscriber, #78959) [Link]

Too many FUDs about Ubuntu these days

Posted Jun 25, 2013 18:57 UTC (Tue) by nix (subscriber, #2304) [Link]

It is reasonable to write what looks like FUD if one fears and thinks there is uncertainty and doubt.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 19:04 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

Cool, so the vision of free software is that multiple competing for-profit entities contribute to a same project and sell proprietary forks separately?

I would say that the vision is that many different people and groups will become contributors to the project. That is more likely to happen if all contributors have equal rights to the code, either no right to make proprietary versions (e.g. GPL licensed software without copyright assignment) or everyone has the right (e.g. MIT or Apache licensed software). When one developer sets itself up with special rights to spin off proprietary versions, that discourages commercial competitors from participating, reducing the pool of potential contributors.

Too many FUDs about Ubuntu these days

Posted Jun 24, 2013 14:18 UTC (Mon) by pboddie (guest, #50784) [Link]

I think we can summarise the situation by noting that just as people are reluctant to work for a proprietary software vendor for no pay (whether that is contributing to a permissively licensed project or to one that requires copyright assignments to a privileged "owner"), other software vendors are likely to be even more reluctant to have their employees working for a competitor for nothing in return.

And really, bringing out the "FUD" label is like the boy who cried "wolf!", especially given that I noticed the word "silo" used on two occasions in this monster thread, once by someone who was clearly annoyed by the Ubuntu/Canonical strategy, and once by someone who didn't mind. This is especially amusing given that I attended a talk by an Ubuntu representative last year, the content of which indicated that developing software in silos was a bad thing. Maybe that was the speaker's own personal opinion, but I feel that I should have asked a question about that rather than feeling it was rude to bring it up, because I'd really like to know how the modern Ubuntu way of the silo is exempt from this observation.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:49 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Considering that at the moment the mir dev team does not provide build from source instructions so you can build and testmir and patched-mesa together outside of an Ubuntu environment... expecting to see any external contributors is putting the cart before the horse. Mir is effectively just an internal project at the moment with no on-ramps for externals to come up to speed on Mir.

The dev team for Mir has not done the basics necessary to give externals an on-ramp to work with the sourcecode, even ahead of worrying about signing the CLA. I can't just pull Mir from bzr and test it. I need out-of-tree mesa patches as well at a minimum..and they haven't documented how to pull those from bzr or git as part of their build from source procedure. Why on earth would ANY external bother poking at project sourcecode they can't build up and test from source? That's just crazy.

This lack of information doesn't reach the level of "hostile" .. but it certainly indicative of inexperience actually knowing how to be a viable upstream project, instead of a distribution-specific team.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:56 UTC (Wed) by maxiaojun (guest, #91482) [Link]

That's a fair point. If you are really interested, have you tried mailing list or IRC?

Mesa should be an "experienced" upstream, right? But I suspect whether I can successfully build Mesa using information from:
http://www.mesa3d.org/install.html

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:14 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Did you miss the back and forth I had in this thread specifically with a mir dev concerning the specific mesa patchsets and the roadmap towards getting them merged upstream?

wayland's build instructions for wayland head workforme well enough in multiple linux distribution environments. It includes instructions to pull wayland and mesa from git. Building wayland's tip on a daily basis from source is doable because the build from source instructions are reasonably vendor neutral.

This isn't about whether mir or mesa are hard to build. Mesa builds for me from source frequently enough...barring caveats for bad commits and what not. I know wtf I'm doing with compiles from source. But right now to build and self-consistently test mir with the toy mir clients, mesa oatches are required that have not been committed into the mesa git repository...even as a pre-merge branch. They exist in some bzr branch buried in the guts of launchpad that have not been documented in the mir build from source instructions.

If the mir build from source instructions can point me to an lp bzr branch for mir head... they certainly should be pointing me to a the matching mesa bzr branch that is required. Its an oversight that Canonical led projects make a lot. They don't "think" like vendor-neutral projects when working on "upstream projects" so they never really bother to document how to work with the source code outside of Ubuntu. Its a failing of their approach to "upstream" development generally and its systemic to their corporate culture... nothing personal...but they just don't think about the build from source as a primary way for skilled developers to work with their project...and their thinking is...myopic.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:37 UTC (Wed) by maxiaojun (guest, #91482) [Link]

As I mentioned, Mir developer sent an RFC to mesa-dev earlier. [1]

Mir hasn't got upstream support from Mesa because it started much later than Wayland. Is anything wrong here?

http://lists.freedesktop.org/archives/mesa-dev/2013-March...

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:42 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Point me to the launchpad bzr branch that holds the necessary pre-merged mesa patches that enable mir's egl backend that can be used to build mir's development tip lp branch. Find that branch... publish the url for that branch.

The request for review to the mesa list is not the current required patchset. There is a mesa branch buried somewhere in lp that is required to build and test mir. publish that url as part of the mir build from source instructions so mir development head can be built and tested outside of an Ubuntu environment.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:45 UTC (Wed) by maxiaojun (guest, #91482) [Link]

Why don't you raise this on mir-devel?

https://lists.ubuntu.com/mailman/listinfo/Mir-devel

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 19:06 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Because I have no desire to sign up for another mailinglist just to punch a development team in the face for not catering to me or to externals. I'll walk into the mailinglist when I'm no longer actively enraged over on topic. And this discussion with you isn't helping bring me back to a non-emotional state.

In the meantime feel free to raise this on my behalf and on behalf of every single external developer who needs to work with Canonical projects outside of a well conditionsed Ubuntu environment. Ive already communicated this requirement to a developer involved in mir in this forum and also in private email.

I only bring this up because KDE upstream has specifically stated the lack of multi-distribution mir binaries as one of the reasons they are keeping a hands off approach to mir. And because I really don't want to see Canonical's... decision making... hurt the KDE/Kubuntu relationship more than absolutely necessary I'm standing up and I'm pointing out why mir is basically undigestable right now to any externals. So perhaps, inside the timeline that matters to Kubuntu, we can make mir more palatable to KDE as a technology by making it a buildable and testable as a vendor neutral tech shoved into other distribution repositories or at least packaged.

Now for me personally... viable build from source instructions are a non-negotiable prereq to consider any technology vendor neutral. Canonical teams don't seem to see that as important historically..and that's a shame really...its such a very small thing to do...document which frelling lp branches to pull to chew on the project head including patched dependencies. And the more I think about how trivial it actually is considering how easy the lp infrastructure makes this.. the madder I get about how this is consistently overlooked by Canonical projects as step-zero in on-ramp documentation. So incredibly myopic..and damaging..even for their relationship with debian because the binary ppa junk isn't a win for them either. Maddening, absolutely maddening in the lack of basic understanding of how to be an effective upstream project that makes it possible for drive-by externals to pull/build/test your project code. So having me walk into a devel list in this mindset right now is basically asking me to walk in and self destruct constructive discussion. So shame on you for encouraging me to sign up on the mailinglist while also pushing my buttons and getting me all frothy. You are a bad person.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 19:43 UTC (Wed) by maxiaojun (guest, #91482) [Link]

No need for Conspiracy theory.

As you already contacted upstream, you are all set now. Response time from free software project is indeed random. Sometimes multiple pokes are needed.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 21:21 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

yes... no need for conspiracy theories I would agree.

The motto: "never ascribe to malice what can be accounted for by incompetence" is certainly applicable here.

And I'm more than willing to chalk up everything that as so far raised my ire in this matter to frustrating incompetence rather than delibrate malice aimed in my direction. Speaking of which, I wonder if anyone has ever watch the old Keystone Cops serials and thought the cops were acting in a malicious or devious manner. Food for thought.

Though I really not sure casting all other parties in the discussion as incompetent is really going to help resolve technical difficulties getting mir testable outside of an Ubuntu environment. So meh.

-jef"I'm not incompetent so I guess that makes me malicious...and I'm okay with that."spaleta

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:03 UTC (Wed) by maxiaojun (guest, #91482) [Link]

> binary ppa junk

Well, I downloaded the source package you probably looking for from https://launchpad.net/~mir-team/+archive/staging/+files/m...

Which can be found in https://launchpad.net/~mir-team/+archive/staging/+packages (click the triangle before the package you interested)

PPA is something far from ideal. But you probably not know it well enough before making bold claims.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 20:19 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Picking apart another packaging format is a bridge to far. I've no desire to become intimate with debian packaging when all I want to do is build the blasted source code directly from development tip. The whole blasted point of bzr and git was to make this sort of crap easy...outside of tarballs and distribution packaging. The mir devs work with bzr... the mesa branch i'll looking for exists in lp and jenkins consumes it. I just want to consume that mesa branch that matches exactly mir development tip so I can pull it on my own timescale in a clean environment without constantly having to look at the blasted ppa for a new src package so i can rip out the patch manually and apply it manually...ever time i want to resync with mir development tip.

This is so backwards... bzr and git exist for a reason...having to dig into the deb src package is a huge waste of time and its the wrong tool for the job and its not how the internal team works with the code..they work with bzr branches...surely. Don't make scrounge around with over the wall patchsets like im a 2nd class dev..document the actual workflow pretending you actually want extern developers who are _peers_ and maybe you'll actually grow some.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 4:19 UTC (Thu) by maxiaojun (guest, #91482) [Link]

Knowing Debian packaging is not trivial.

But finding patches in a Debian source package is quite trivial I'd say.

Just uncompress, cd XXX/debian/patches , that's it.

In this particular, XXX=workspace, a bit strange should be same as package name in most cases.

And the patch you are looking for should be egl-platform-mir.patch; quite obvious from filenames.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 5:10 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

You continue to miss the point.

Sadly it seems I have to put away the more subtle ax I have been using to hack away at this discussion and pull out the rhetorical spoon and get to the heart of the matter (Double points if you can name the movie I am not so obliquely referring to in this sentence).

It's not about pulling the patch today. Its about tracking mir development like a grown-up developer wearing his big-boy pants does every day. Pulling the blasted patch from the bloody stupid debian source package is a waste of my time. Difficult to believe but more a waste than continuing to talk to you here. Its absolutely arse-backwards way of dealing with tracking a moving development target. Doubly so when the moving target spans multiple codebases and you need to keep them in sync due to API shifts and whatnot. GNOME gets a lot of crap from a lot of people... but the jhbuild tool its pretty awesome bit of work as an on-ramp to working with GNOME development tip in a coherent fashion without screwing up your running environment. Its everything Canonical has failed to do with their ppa tooling to make working with fast rate of churn development code from source without jeopardizing a running environment.

Anyways back to MIR/Mesa. The Bzr branches in lp exist for exactly the purpose of allowing developers to easily track development like I need as an external and are used day to day by the mir team to land changes. The frelling debian source package in the ppa is a carnival sideshow. NOBODY WORKS WITH THAT POS WHEN ACTUALLY DOING DEVELOPMENT ON THE CODEBASES IN QUESTION. Its simply a side-effect of their distribution specific automation for building an testing binaries that target Ubuntu. That's all it is, and its pointless for me to use that as a starting point to track development.

A set of Bzr branches representing the full state of the mir codebase...including the necessary and yet to be merged mesa patchset..is what I frelling expect to be pointed to. The exact blasted branches that the internal fracking development team inside the Canonical fenceline is bloody patching and using day-to-day so I can just as easily pull the branches remotely and keep up with the changes on a change by fracking change basis.

Unpacking a frelling debian patchset every freaking day... its just moronic, clearly suggested by someone who has never made the attempt to track a project in this fashion. Its insulting to me even to have you suggest that as a valuable use of my time actually considering the availability of the bzr/git tooling that is being used as part of the daily development process. Stop being insulting, if you are sincerely attempting to help me then find the bloody undocumented and unpublished mesa bzr/git branch that its being sucked into the daily deb build automation that I can clone and use to construct patch merge requests with. Don't point me to secondary unused src format, to pull apart frelling manually, that are purely the result of build infrastructure implementation choices that are not part of the development workflow.

The bzr/git branches are the _thing_ that developers are working with. Give me the thing...give me the hotness...not the cast off debian source detritus and make it sound like I should be happy to even have that. No sir. anything less than the bzr/git branches that represent the tip of upto the minute development will simply not do.. any clever workaround involving the debian source package and its payload is just a hack and its not worth the time to even describe to me as if I don't bloody know what the debian package payload looks like.

I know what a debian package is, thank you very much, I know how to deconstruct them to get access to patches and I'm telling you its a frelling waste of my time to do it even once for Mir. Stop insinuating that I don't know how deb packaging infrastructure works like I'm some noob. Pulling apart automated launchpad deb builds wasn't productive when I originally did it back when Shuttleworth made his cash investment in to the fledgling Eucalyptus and eucalyptus was being developed in private launchpad bzr branches ahead of the UEC announcement and all I could see were the debian source packages being pooped out with the prerelease binary packages...and its not productive now with Mir. It will never be productive for any external developer to attempt to work with a canonical controlled codebase in the way you are suggesting. I've been beating this particular dead horse for a while now and I'm simply done bending over backwards trying to keep track of Canonical projects by picking apart the debs they poop out of their automation tooling. When I say their handling of on-ramps for external developers has been historically a shambles and that I feel its indicative of a corporate culture that doesn't know what it means to get the basics of being an upstream project right... I mean it. I really really mean it. And this is me...being polite...about how I feel about it too. Pray you never see me be more honest than polite about this topic.

Tweetspeak: No sir. I need bzr/git branches to track dev, nothing less will satisfy

Too many FUDs about Ubuntu these days

Posted Jun 21, 2013 5:33 UTC (Fri) by maxiaojun (guest, #91482) [Link]

Hey, man.

https://github.com/RAOF/mesa
https://github.com/RAOF/xserver

( Got this answer from mir-devel )

Too many FUDs about Ubuntu these days

Posted Jun 21, 2013 12:05 UTC (Fri) by wookey (subscriber, #5501) [Link]

A fine rant sir, and I don't disagree with your basic point that an upstream project needs to maintain a tree that is reasonably context-independent. And preferably some destructions on build dependenciess.

Neverthless, some of us are old-fashioned and _do_ like working with debs and patches rather than git/bzr/whatever. Yes it's crufty and way uncool but I actually understand what I'm doing in this environment (as opposed to git/bzr where it can take hours to generate a simple patch against what I wanted). Mostly this is my own incompetence, but I still find life a lot more productive, despite some irritations, with simple packaged sources than VCSes (especially if that VCS is git). Just to say such people do still exist.

So from my POV what the Mir people are providing sounds ideal. (Although in the wider context I don't understand why Mir was necessary - it seems to me that existing projects already covered what was needed, but there you go).

Too many FUDs about Ubuntu these days

Posted Jun 21, 2013 19:04 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

Sounds ideal to you? Great! I look forward to seeing you getting mir up and running and testable next week on any other linux distribution other than Ubuntu for anyone else not running latest U. can safely consume without distablizing their running system. I'd love to see a set of debian packages that work against debian experimental for example. Or if you are a gentoobie or archinoid.. a pocket repo with source rebuilds of this stuff. I think that would help the situation that the other DE devs currently face in trying to even evaluate or test Mir integration. If you can make that happen using just the debian source packages as provided in the ppa staging... go for it. You the man. You the man. I double dog dare you.

-jef

Too many FUDs about Ubuntu these days

Posted Jun 22, 2013 14:26 UTC (Sat) by tzafrir (subscriber, #11501) [Link]

Just to point out that the deb packages in question were "native" source deb packages. That is: they were not composed of an upstream tarball with separate file that includes the packaging changes. Rather, the source tarball included the debian/ directory (and is likely to be patched with all the patches).

So your preference does not apply to this case.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:54 UTC (Wed) by maxiaojun (guest, #91482) [Link]

I still see your complains as documentation issues. Yes, it may be blocker rather than trivial tasks like converting yum to apt-get.

But again, isn't the way to solve this kind of issues "ask the upstream" rather than "complain on LWN"?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:42 UTC (Wed) by maxiaojun (guest, #91482) [Link]

The Mesa build instruction mentions yum only. Can I infer that they assume Fedora rather than being distribution neutral?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:48 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

I'm looking for the equivalent of this... for mir.
http://wayland.freedesktop.org/building.html

but with the url changed as necessary

And point of fact... mesa build instructions include a list of versioned project dependencies... just ahead of the distribution specific instructions. So yes I can build build mesa just find outside of fedora with the provide information. The versioned Xorg codebase information on the same page as the yum instructions is a sufficient breadcrumb.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 12:18 UTC (Thu) by 3v1n0 (guest, #88377) [Link]

Isn't this enough http://unity.ubuntu.com/mir/ ?

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 14:17 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

No.. because those instructions do not provide the bzr/git branch to pull the necessary _mesa_ patches that mir needs. The instructions reference a custom mesa that is only available in the staging ppa. not good enough.

All I need is for the url for the mesa bzr/git branch, which include the egl mesa backend code for mir, to be added to those instructions. So I can pull _all_ the mir related code that represents the tip of mir development into a clean environment and build/test.

Or I can wait till the mesa patches are properly upstreamed into mesa development. But its not necessary to wait that long to do initial build/testing if the pre-merged mesa patch branches were published and made consumable by externals. Either way, there's no point in anyone wasting more time trying to get Mir to build outside of Ubuntu, until the corresponding mesa backend code is published as part of either a git or bzr branch somewhere.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 22:45 UTC (Thu) by mjblenner (subscriber, #53463) [Link]

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 23:26 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

THANK YOU!
The commit history in github url looks about right. That's what I get for looking in launchpad's "mesa" project for a mir related branch. I didn't see an lp branch under mir corresponding to any mesa code and I completely missed the github url.

Hopefully this is enough to get a testable mir binary built outside of Ubuntu.

Though it would be reassuring if roaf blessed the github repo as matching mir tip in some ornate ceremonial ritual blessing...or just an update to the mir build from source instructions. But in the meantime... tallyho!

-jef

Too many FUDs about Ubuntu these days

Posted Jun 27, 2013 17:16 UTC (Thu) by farnz (subscriber, #17727) [Link]

So, to give you one example of the problem; I can contribute (per my employment contract) to any open source project as long as I get the work as a whole under the same license as I am placing my contribution under.

This means that (for example), I can contribute to the Linux kernel - I give code under GPLv2, and get it back under GPLv2. I can contribute to KWin - I give code under GPLv2+, I receive code back under GPLv2+. I can contribute to Wayland - I give code under MIT, I receive code back under MIT. I can't contribute to Mir without getting my employer's explicit consent; I would contribute under the permissive licence grant in the CLA, and receive back under GPLv3 only. That's not something I'm permitted to do without a lot of hassle, so I'm never going to bother looking at Mir unless my employer asks me to.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 16:15 UTC (Wed) by josh (subscriber, #17465) [Link]

Wayland doesn't use copyright assignment. Also notice the all-permissive license on Wayland, which says that *anyone* can release a proprietary product based on it; quite different from the asymmetric situation created by a copyleft license and copyright assignment.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 16:34 UTC (Wed) by maxiaojun (guest, #91482) [Link]

> *anyone* can release a proprietary product based on it

So cool for free software community.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 16:50 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Permissive licenses pre-date copyleft licenses and have always been considered free software, and it's worth noting that X.org is under such a permissive license. I personally prefer licenses that prohibit proprietary derivatives, but I abhor situations that permit one entity to produce proprietary derivatives without granting that right to others.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:02 UTC (Wed) by maxiaojun (guest, #91482) [Link]

Why shouldn't the main supporting entity have this kind of advantage.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:36 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

From a market perspective.... because there is no reasonable expectation that the originating corporate entity that initially builds a technology implementation will prove to be the most competent business entity who can provide value for money in servicing the technology in the future.

From a contributor perspective, especially from a skilled independent labor or external paid labor perspective, you are essentially paying your competitor in the marketplace with your labor and giving them an economic advantage that you can not take. So if you were being paid by a competitor to Canonical in any market segment..why on earth would you agree to give them help be more competitive against you by donating your labor to their CLA? Not smart business.

These sort of clauses certainly make sense from the corporate perspective as they secure a unique right to do business using contributed code they didn't pay salary or benefits to produce and give you a short-term advantage in the marketplace. But the cost is you are much less likely to acrue the benefit of the open development model with significant external contribution into technology implementation long term.

But its a raw deal from the contributors perspective, and ultimately the paying customers perspective, as it reduces the market for competitive support around the specific implementation.

Or in tweetspeak. It makes perfect sense if your business management team is myopic.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:47 UTC (Wed) by maxiaojun (guest, #91482) [Link]

If the contributor represents a for-profit entity, why should she contributes to a copyleft project in the first place?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:52 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Why do corporate entities contribute to the Linux kernel? Because there's a benefit in having your code in an upstream project, and your competitors gain no disproportionate advantage from you doing so - they get to use your code, but only on the condition that they do so under a copyleft license. The benefits (not having to keep your code up to date with new versions, external developers fixing your bugs and adding new features) outweigh the disadvantages (your code is now available for your competitors to use). If one of your competitors is able to release a proprietary version then that's effectively an additional cost to you, and you're significantly more likely to feel that the disadvantages now outweigh the benefits.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:02 UTC (Wed) by maxiaojun (guest, #91482) [Link]

But Linux starts as a community project by its own.

BTW, what's value of Mir being a proprietary product?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:08 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Most significantly, the large number of hardware vendors who are unwilling to ship GPLv3 material. Most Ubuntu phone handsets that ship Mir will probably do so under a proprietary license, even if the code is identical to the publicly available GPLv3 code.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:14 UTC (Wed) by maxiaojun (guest, #91482) [Link]

I also suspect Ubuntu phone maybe the only real use case of proprietary Mir code; yet to see.

But what's the solution:
1. Use permissive license like X?
2. Do not use GPL3?
3. Let Canonical unable to make a proprietary version of Mir also? Taint Mir with contributed code?

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:19 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

If Canonical are willing to ship proprietary versions then the choice of GPLv3 isn't because of a commitment to free software - it's to prevent competitors from shipping proprietary versions. If Canonical really believe that copyleft licenses are preferable then they should be willing to deal with the same restrictions themselves.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:30 UTC (Wed) by maxiaojun (guest, #91482) [Link]

Yet to see whether Ubuntu phone would ship proprietary code. Personally, I don't expect a new player in mobile market solve the problem that mobile phones being locked down by carriers.

Anyway, the terms can serve "evil" purpose doesn't necessary imply there is "evil" purpose. I've raised the licensing issue in mir-devel and waiting for responses.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:52 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

No, I don't expect Canonical to fix this problem, and as a result I wouldn't criticise them for using a permissive license.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:00 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Because of the long term benefit of the commons approach to reducing their expenditure on technology development by allowing a multitude of other interests to share the cost in the long run. The commons approach also makes it possible to cultivate a larger overall market for services that can be robust to multiple business interests to service a range of customers. Instead of a one vendor defining the produces and services around a tech.. _customers_ shape an array of products and services based on their needs beyond which a single business entity can adequately service.

Whether corporate entity invests strongly into open development or closed development when creating a new technology implementation is very much about the timescales over which they internally assess return on investment for dollars spent. Companies that are short-sighted and looking for instant market advantage without thinking about long term market viability of the technology...will have a very hard time factoring in the benefits to an open development model into their business strategy. And for those companies, I can only suggest they find a new executive team and do a re-assessment.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 18:06 UTC (Wed) by maxiaojun (guest, #91482) [Link]

The theory sounds nice, show me an example except Linux? Keep in mind that the project must use copyleft license.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 23:20 UTC (Wed) by lsl (subscriber, #86508) [Link]

Seriously? GNU, for example. Also QEMU, Webkit and _tons_ of other projects.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 18:05 UTC (Thu) by maxiaojun (guest, #91482) [Link]

Not sure about QEMU, but WebKit is based on a permissive license.

Too many FUDs about Ubuntu these days

Posted Jun 20, 2013 18:13 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Large parts of Webkit are LGPL 2.1.

Too many FUDs about Ubuntu these days

Posted Jun 21, 2013 1:22 UTC (Fri) by maxiaojun (guest, #91482) [Link]

You are right. But given the number of proprietary browsers based on WebKit, I'd count it as permissive.

Too many FUDs about Ubuntu these days

Posted Jun 21, 2013 2:35 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

That won't work. Licenses like revised BSD and MIT are permissive. LGPL is a (weak) copyleft license and not permissive.

Copyleft success

Posted Jun 21, 2013 0:24 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

Some good examples of projects that have succeeded with copyleft licenses and no assignment to a company that can commercialize them:

  • KDE (except for Qt)
  • GNOME
  • WINE
  • GIMP/CinePaint
  • R
Plus, of course, just about everything from the GNU and the Free Software Foundation: gcc, EMACS, glibc, bash, etc. These do require copyright assignment, but it's with the explicit promise that it will only be released under a similar license, so it doesn't count under the general category of a company funding its copyleft software by selling proprietary licenses.

Copyleft success

Posted Jun 21, 2013 1:19 UTC (Fri) by maxiaojun (guest, #91482) [Link]

Only Wine has a dominating company behind.

CodeWeavers actually open source the Wine part used in CrossOver, but no one bother to use it. I don't know how successful the eco system is.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 19:16 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

Why shouldn't the main supporting entity have this kind of advantage.

Because the goal of any ambitious piece of Free Software should be to become large enough that there isn't a "main supporting entity". As long as a project has a single dominant supporter, its developer pool is limited by what that single supporter can provide. If it allows contributions from everyone equally, it can grow far beyond the limits of any single supporter.

Too many FUDs about Ubuntu these days

Posted Jun 19, 2013 17:32 UTC (Wed) by josh (subscriber, #17465) [Link]

I prefer copyleft licenses, personally, but I think it makes sense for a piece of software intended to replace X to use the same style of licensing X does.

What is the definition of Linux Desktop

Posted Jun 19, 2013 16:28 UTC (Wed) by maxiaojun (guest, #91482) [Link]

From my real world experience, most people recognize OS through its desktop shell, not kernel, package management tools, etc.

For example, some people believe that Mac OS X is based on Linux. I haven't found a good way to explain the kernel difference to them.

The best way to give a clean space to desktop users and developers, is that every shell maintaining its own OS. Upstream shell projects and distributions do not need to hijack each other's decision any more. I see GNOME OS as a right move of this approach. And Ubuntu is effectively Unity OS now, which is good. Pages like this is non-sense: http://www.kde.org/download/distributions.php

(Distributions can still co-exist for server usage and catering of Unix ninjas)

Third-party apps can still be desktop shell independent as the case of today. Some efforts are needed for ABI/API compatibility. LSB is certainly not a solution as it basically describe an outdated stack of RHEL or so.

Running different shells on same machine is not that useful actually. I haven't found a real use of it.

What is the definition of Linux Desktop

Posted Jun 20, 2013 12:31 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

> From my real world experience, most people recognize OS through its desktop shell, not kernel, package management tools, etc.

Nice observation!

If the shell evolves in a drastic way, people will perceive it as a different OS. Like it happened with MS Windows 8 or Gnome Shell or even with Windows 95 or NT 4.0. Compared with that Mac changes was much more gradual and some interface elements like top menu or one-button mouse operations remains unchanged.

As people prefer to keep things the same perception as a different OS raises a bar of acceptance significantly. The new stuff must be obviously good so efforts to adjust to it can be justified. For Windows 95 IIRC it worked as the new OS was obviously better in many respects. Judging by Microsft plans to restore the Start Button in MS 8.1 and Red Hat pushing Gnome Classic the recent GUI experiments were perceived as a new OSes that broke old habits without any obvious improvements (MS overestimated the need for touch on desktop).

Dividing the Linux desktop

Posted Jun 24, 2013 16:34 UTC (Mon) by maxiaojun (guest, #91482) [Link]

Maybe off topic here.

Anyone know enough about LiMux being deployed in Munich, Germany?

Is LiMux still using KDE3? If so how is LiMux going to survive the upcoming display server "war"?

( Remember Martin's rant about Trinity Desktop? )

Dividing the Linux desktop

Posted Jun 24, 2013 20:56 UTC (Mon) by lsl (subscriber, #86508) [Link]

Last I heard they were transitioning to a new client based on Ubuntu and KDE4, exchanging OO.org with LibreOffice in the process. You really don't want to maintain KDE3 for years to come.

Apparently they talked about it at Akademy 2012:
http://community.kde.org/Akademy/2012/Monday

Can't find recordings, though.

Dividing the Linux desktop

Posted Jul 6, 2013 11:34 UTC (Sat) by glaesera (guest, #91429) [Link]

Obviously any non-Unity community versions of Ubuntu will be even more second class in the future. They are second class already, when you look at support-terms. LTS Versions of plain Ubuntu get security- and stability-updates for five years now, XUbuntu-LTS for example is supposed to be provided updates for three years only. But they are both based on the same software-reposotories and updates come from the same source. How would you explain this to a lay-person except with discrimination against non-mainstream forks?


Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds