LWN.net Logo

Canonical reveals plans to launch Mir display server (The H)

Persistent rumors of a Canonical-developed display server have been confirmed over at The H. Instead of X, Wayland, or SurfaceFlinger, the Mir display server will be used in upcoming projects.
Currently, the developers are using the Android SurfaceFlinger to deliver the Phone and Tablet experiences which were recently released as developer previews. But Canonical says that, by May this year, it will be replaced by Mir. It added that eventually the tablet will migrate to the same infrastructure as the desktop system.

For the desktop, the plan is equally ambitious: a migration in May to a Mir/QMir/Unity Next shell and Mir/QtUbuntu/Qt/QML application stack running on top of the current free graphics drive stack. Closed source driver support is still being worked on, with Canonical saying it is talking with GPU vendors about creating distilled, reusable, cross-platform EGL-centric drivers in the future. The May milestone will, though, be the first point in actual shell development and giving developers something to work with.


(Log in to post comments)

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 22:14 UTC (Mon) by DiegoCG (guest, #9198) [Link]

Unix Wars?

-Android
-Canonical
-Red Hat/ typical Linux distro

Each one working in different directions.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 22:19 UTC (Mon) by tchernobog (guest, #73595) [Link]

Why should it be a war? Everybody is free to spend their time/money as they best see fit, provided they give back to the community.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 22:35 UTC (Mon) by clump (subscriber, #27801) [Link]

Agreed. The source code is the insurance policy.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 22:46 UTC (Mon) by DiegoCG (guest, #9198) [Link]

It's not a "war", it's a divergence. I cited the historic episode know as "unix wars" https://lwn.net/Articles/494248/

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 3:30 UTC (Tue) by drag (subscriber, #31333) [Link]

Their were casualties in that war. BSD was almost sued out of existence due to them laying the groundwork for the commercial success of Unix and not anticipating what would happen when shortsightedness, greed, and copyright law collided.

It is one thing to lose out because you made too many mistakes or your product sucked. Its quite another issue when somebody decides to use the government to eliminate the competition... which at that time was free software.

Worst case scenario: non-free drivers gain acceptance

Posted Mar 5, 2013 20:56 UTC (Tue) by coriordan (guest, #7544) [Link]

The worst case scenario this time is that the three compete for functionality and accept non-free drivers as a way to offer more than the others, leading to a race to the bottom while the hardware companies gleefully rub their hands.

Worst case scenario: non-free drivers gain acceptance

Posted Mar 6, 2013 2:29 UTC (Wed) by drag (subscriber, #31333) [Link]

We already have a lot closed source video drivers. I don't think it's going to make much of a difference, really.

Worst case scenario: non-free drivers gain acceptance

Posted Mar 6, 2013 10:36 UTC (Wed) by coriordan (guest, #7544) [Link]

The current situation isn't actually that bad. It's easy to go out and buy a desktop or laptop that works with 100% free software drivers today. But we're in a dangerous period because of the hardware transition from desktops and laptops to tablets and phones.

When everyone is behind a single display server, it's easier for that project to stand firm and make demands. (Some venal downstream packagers will of course break solidarity.)

But when the users are divided, and when some display servers are controlled by companies, then people who stand firm for free software can get marginalised.

Worst case scenario: non-free drivers gain acceptance

Posted Mar 6, 2013 17:33 UTC (Wed) by drag (subscriber, #31333) [Link]

I don't think it will make much of a difference because display servers are moving out of the hardware management business. Any new display server is going to, or should, be using standardized application APIs for it's foundation.

So it should not matter what display server you are using. The display server needs to conform to the APIs provided by low level system libraries and the kernel, not the other way around.

With X windows in Linux the display server had to have it's own driver to drive the hardware directly, which is a idiotic design and is a disaster. It's one of the major reasons open source drivers got so far behind.

Worst case scenario: non-free drivers gain acceptance

Posted Mar 6, 2013 19:34 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

> With X windows in Linux the display server had to have it's own driver to drive the hardware directly, which is a idiotic design and is a disaster. It's one of the major reasons open source drivers got so far behind.

no, the main reason that open source drivers got so far behind is that they had to reverse engineer everything, vendors were actively hostile to them.

Worst case scenario: non-free drivers gain acceptance

Posted Mar 7, 2013 10:38 UTC (Thu) by Wol (guest, #4433) [Link]

No. Probably THE major reason is the guys with power in XFree86 (not the guys doing the work, they left to form Xorg) said "if you want a gui, use Windows".

Sad but true - I think the final straw was when ?Keith Packard (who had been doing 90% of the coding) had his commit rights withdrawn.

Cheers,
Wol

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 23:28 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]

as long as the result can be run everywhere, there isn't a problem

However, if you get into the position where you can't run two different apps on one box because of the toolkit they use and the display server they require.

This is what concerns people about the Wayland one-way X compatibility, and now that there will will be four choices

X
Wayland (including X apps)
Flinger (Android)
Mir (unknown compatibility)

the concerns get stronger.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 1:01 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

from further reading, it appears that Mir will also have the ability to have X apps connect to it, so it's got the same compatibility as Wayland.

One other piece of information that I found interesting

Mir can use Android video drivers, so this may be a big advantage when dealing with portable devices.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 3:37 UTC (Tue) by drag (subscriber, #31333) [Link]

The ability to use android drivers is due to the plan to use opengl is as its API. Its a standard that modern android drivers must support.

Stop me if this sounds familiar.

http://ppaalanen.blogspot.fi/2012/07/wayland-on-android-s...

Because wayland already had the capacity to run on android drivers....

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 5:12 UTC (Tue) by swetland (subscriber, #63414) [Link]

It sounded more like they were planning on sitting on top of the Android Hardware Composer HAL, which is definitely the way to go. SurfaceFlinger uses GL ES as a fallback for composition if the hwcomposer can't do some or all of the work. Taking advantage of hardware overlays or other 2d composition engines is pretty important for reasonable performance on a lot of these platforms -- they can avoid additional memory to memory copies and offload the GPU (which apps also want to use to draw).

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 15:37 UTC (Tue) by mmarq (guest, #2332) [Link]

IS that "notion" that i find very strange

> offload the GPU

There isn't that need since even phone chips will have GPU integrated to the bone... they already do... more than that, next crop of those integrated GPUs will be several times >100% more powerful than current ones, and perhaps even ultra-mobile will have more than 1 GPU, meaning perhaps the concept big.LITTLE can cross to GPUs also.

The idea of offload the GPU is applicable only when your system doesn't support the respective drivers, or does a very lousy job at it, and that has been the problem all along. Native *integrated* support for GL languages is the way, and this almost all DS already do, being X perhaps the more cumbersome(quite fixable i think, i just remember compiz/fusion)... and support for seamless *multi-GPU* the lacking factor, this Mir seems to target, so its already superior to wayland only by this factor, X is doing the first steps on it, while Wayland seem definitely lacking...

IMO a lot of *convergence* could be achieved if large part of the "input stack" passes to systemd / kernel, that is, even before any DS is applied, and who knows "consoles" can use a lot of "mouse" functionality and other input devices, that is, why not "touchscreen" support for "consoles" ?

In this X is the one that would need the most work, but nothing unachievable i'm positive... and a favor to them... any X release would be excused from deliver any input drivers, and a same "pointer theme" could serve all from Grub/whatever to the desktop/screen.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 19:36 UTC (Tue) by swetland (subscriber, #63414) [Link]

When you're driving large displays with multiple layers and moving a lot of pixels around, an overlay engine that reads from multiple layers and combines them directly into the scanout path, without requiring memory-to-memory copies is often a more efficient use of available bandwidth than using the GPU.

Not taking advantage of hardware composition blocks leaves performance on the floor, and it's performance well worth taking advantage of.

CPUs and GPUs are becoming more powerful, certainly, but displays are getting larger, software is drawing more complex stackups (with more alpha and effects between layers), and there's seldom as much graphical compute as you'd like on embedded platforms, even the higher end ones.

Also, efficient multitasking between multiple GPU clients is still rather hit or miss. I've seen beefy Win7 desktop machines start becoming unresponsive to window drags, etc, when throwing a complex load at high end desktop GPUs because the compositor and application are fighting for the available GPU and the hardware and/or drivers don't time-slice it well enough to remain smooth. The problem is typically worse on embedded platforms.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 22:11 UTC (Tue) by mmarq (guest, #2332) [Link]

ummm... your parallel is far from convincing.

Embedded platforms are not real display multitasking systems. The same can be said about phones, the GUI is simply not tailored for it.

The rest seems to go in the opposite direction, i mean, is the kernel that manges the GPU memory, and all is managed as a single pool of Virtual Memory... is inherently an UMA... and is not only about HSA, and are not only its members that are about to implement "hardware features" (advanced caches, TLB, pre-fetch, etc that molds nicely to the data programming patterns) that makes those round trip memory copies a thing of the pass.

I happen to read a lot of patents(not only for work), i'm expecting something in that direction, matter of fact Sony PS 4 as revealed is a Single unified chip who's main memory is GDDR5, that is, is the GPU side that has all the memory, is the CPU side that shares, if it is HSA modeled, and more in AMD style, those memory-to-memory copies will not apply... remains to know what OS (or version) they will employ. So the more efficient use in PS 4 will be exactly the GPU not the CPU.

So in this sense the wise approach would be to move anything of those pertinent mechanisms out of the windowing systems... yes more stuff in the kernel... or more stuff in the systemd as example.

Then the DS can even be multithreading, almost like any other app, and you can have several windows open even on several displays, all with active windows with focus, and drag & past things from one to another without complications and rendering complexities, of windows getting minimized or the all operation getting cumbersome with virtual desktops.

This is not necessary for those "embedded or portable" systems, but making it the standard, and force all to follow it, IMO is like trowing Linux desktop more than 10 years back... perhaps DOS is not after all a bad idea, 1 app at a time!...

And saying it will *never* apply to embedded/portable is a risky bet, *never* is always a very risky word in IT... some more adventurous hardware vendor might yet conceive remote display for a superphone, now that wifiG is a done deal, and you have your phone GUI splashed into 2 wireless big displays... never say never, at least you'll not lose for the waiting, but where is the Linux display system for this ?

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 22:36 UTC (Tue) by mmarq (guest, #2332) [Link]

And if you care to ask... yes, not only advanced caches, but also pre-fetch, TLB and MMU of sorts in a GPU also, matter of fact context/exception handling, and its own "cooperative" interrupt engine to. Very little differences to a CPU.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 23:14 UTC (Tue) by robclark (subscriber, #74945) [Link]

just a side note, but if the hw supports it, weston can use overlays to do composition bypass too. So again this is not a valid argument against wayland.

(But when you have hw that supports it, and when used properly, using the display block to do composition can be a very big win. That is for sure.)

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 10:36 UTC (Tue) by renox (subscriber, #23785) [Link]

> and now that there will will be four choices
> X
> Wayland (including X apps)
> Flinger (Android)
> Mir (unknown compatibility)

Currently there are two main existing choices: X and SurfaceFlinger (DirectFB doesn't seem to catch much interest, I'm not sure why).
X's has many issues because it hasn't evolved as it should (both the implementation and the protocol), so it must be replaced, OK, what I don't get is why SurfaceFlinger doesn't seem to be considered as a basis for replacing X, and instead 'from scratch' projects Wayland and now Mir were created..

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 13:14 UTC (Tue) by paulj (subscriber, #341) [Link]

Shame LWN doesn't have +1 ability. :)

Your comment is spot on. The Wayland devs are in no position to criticise Canonical for unnecessary forking, given there is already a tested, widely used replacement for X shipping on millions and millions of devices. ;)

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 13:47 UTC (Tue) by renox (subscriber, #23785) [Link]

> Your comment is spot on. The Wayland devs are in no position to criticise Canonical for unnecessary forking, given there is already a tested, widely used replacement for X shipping on millions and millions of devices. ;)

I am not trying to 'earn points', this was a real question..

As for the criticisms: Wayland developers didn't criticize Canonical for making another project but for writing incorrect technical points about Wayland: contrary to what is written in Mir's wiki, Wayland doesn't suffer from X's input security weakness.

As always security isn't free though: it means that Wayland clients cannot send events and that (for example) a visual keyboards cannot be a "normal Wayland clients".

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 14:11 UTC (Tue) by paulj (subscriber, #341) [Link]

I gather the misrepresentation was one issue, but needless forking was another criticism that appeared to be made in the IRC log posted in another comment.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 17:05 UTC (Tue) by mmarq (guest, #2332) [Link]

> Wayland doesn't suffer from X's input security weakness.

What a lame excuse ! ... now the apps that a user can install are a "security" concern ??...

I welcome those security threats anytime... i'm very concern with those that don't "display" anything whatsoever, and those are never an app that need a DS.

All this "clash" is because several projects want to be the next "must have" thing for dedicated Linux hardware... yes, the future points that if you want a Linux desktop, from ultra-mobile to workstation, you'll have to buy compliant hardware with proper drivers developed for them.

Hey! at least someone will pay for something... else go windose, which is exactly the same thing, the price of the software is included in the hardware(pre-install), and the rest is similarly free... in a warez/freeware style.

Matter of fact Windose will win triple with this, they can keep a good part of the warez/freeware in place, while Linux will tend to be plagued with "incompatibilities", no matter if everything is free.

And by doing so, they can prepare for the next big push... or "exclusive encrypt hardware or UEFI 2"... and so relegate Linux client/desktop to levels equal to 10 years ago or worst, and so achieving (union makes the strength, disunion makes the weakness no matter your much larger numbers) they can go after the server side to, meaning the "clients" for those servers will be very "cosi" about what software those servers might run.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 3:19 UTC (Wed) by drag (subscriber, #31333) [Link]

> What a lame excuse ! ... now the apps that a user can install are a "security" concern ??...

This is always been true. If you want to secure the OS the first step is to reduce it's functionality as much as practical.

> while Linux will tend to be plagued with "incompatibilities", no matter if everything is free.

I'd actually rather Ubuntu diverge massively from the rest then see it plod along with trying to improve things and not worry about 'being compatible' in the traditionalist Linux approach.

That way if they succeed that is a huge win and shows the road going forward for Linux as a desktop/workstation/whatever. If they fail then it shows what not to do as plain as day.


Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 16:55 UTC (Wed) by mmarq (guest, #2332) [Link]

>This is always been true. If you want to secure the OS the first step is to reduce it's functionality as much as practical.

md5 trusted origin and non-root privileges are not enough ?

seems to me the "practical" target seek is beyond most "client users" are used to, or care, or is indeed practical. You alienate the masses of "end users" then wonder why distros are in trouble, and why there isn't more adoption lol ...gezzz wonder why !?...

for really security concerned deployments there is always system/network admins... unless those are also considered a security threat, and must get out of job... lol (good going!).

>I'd actually rather Ubuntu diverge massively from the rest then see it plod along with trying to improve things and not worry about 'being compatible' in the traditionalist Linux approach.

they will try to diverge in any case... i think it was already decided that way... and the main concern is the "business" side and its model, its not about improve, compatibility or tradition... its all about business and $...

I think they are going to fail. No! nothing against Ubuntu, but something lots of ppl seem to have forgot is that there is already a king for the business model they try emulate, a ruthless despotic king supported by a "status quo" that seems completely bent in having an "harmonization" of systems where they can control, with all its implanted back doors, report to master etc... go ahead, insult if you must...

Ubuntu to have the success they seek, will have to ask permission, sign deals, and after all that be content to be a very secondary alternative... that is why after UEFI 1 i speak of UEFI 2...

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 17:46 UTC (Wed) by drag (subscriber, #31333) [Link]

> md5 trusted origin

Last time I checked md5sums don't check the source code for security bugs and hidden backdoors.

> and non-root privileges are not enough ?

My user account on Linux does not have root rights. Therefore all the critically important information that I have is stored under my user account. There almost no permissions within that context.

Therefore root permissions are not enough.

> they will try to diverge in any case... i think it was already decided that way... and the main concern is the "business" side and its model, its not about improve, compatibility or tradition... its all about business and $...

The tradition is shit. It's not working for Ubuntu or anybody else that has tried to penetrate the desktop and consumer market following it. And therefore change is necessary to survive.

The tradition for Linux is to have huge amounts of duplicated work to deal with insignificant and unimportant technical details that distributions refuse to agree on. It creates headaches for developers and makes it difficult to install and almost impossible for end users to maintain the software they want to use at the versions they want to have.

The tradition for Linux is not have any sort of layers or design in the system. We have 2 layers, Kernel and 'everything else'. It's all one big mush with a maze of inter dependencies so complex and lavish that it resists any attempt for people to map it out and document it. One change in one aspect of program or library and you have chance of causing a wave effect throughout the system of changes and recompiles.

I could go on, but hopefully everybody is aware at this point what the problems are.

Any significant deviation from this that actually works out well is going to be a improvement.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 18:20 UTC (Wed) by mmarq (guest, #2332) [Link]

>Last time I checked md5sums don't check the source code for security bugs and hidden backdoors.

True... but what happened to "trusted origin" ?... unless you mean "you damn distros, i don't trust you a little bit"

> My user account on Linux does not have root rights. Therefore all the critically important information that I have is stored under my user account. There almost no permissions within that context.

>Therefore root permissions are not enough.

Encrypt the real sensitive stuff... or like a joke in my country; "don't want to have children... don't do it", the perfect contraception model... meaning don't have anything sensitive directly connected to your system, even top military security wacos can agree... its the best model...

Unless you think that Linux must be like a "baby-sitting" system to all the crazy ignorant gits out there... i have some experience with that, good luck with that lol (boy! i can't think of worst punishment)... cause for those the worst security threat is that they can't resist to the phishing and social engineering of; "click here to see a celebrity without panties" lol... there is no system that can really help more than they already do, which is already good...

and last... what happened to the system and network admins ?... don't they count ? ... or the intention is put a "virtual" admin in every box of every crazy git out there ?...

>for really security concerned deployments there is always system/network admins... unless those are also considered a security threat, and must get out of job... lol (good going!).

TPTB will love it, but i'm afraid it will flop terribly, because what the crazy gits want is exactly do crazy and very insecure things...

Why do i sense "security paranoia" ? ... as a lame excuse for many things, including being toppled by a "status quo" that sees the all F/OSS Linux itself as a threat... but to them ?

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 18:45 UTC (Wed) by mmarq (guest, #2332) [Link]

Forgot...

>And therefore change is necessary to survive.

This is the central issue. I can agree with many things, many things are true, even things that are obviously contradictory in many aspects.

But change by itself means nothing... absolutely nothing... if you don't identify correctly the root problems of your woes.

And most of the root problems of the Linux world, IMHO, is NOT in the code. Why this and that!?.. well, is it correctly identified ?... than what are the solutions ? ... and most pertinent of all, why can't everybody push in the SAME DIRECTION to solve the most afflicting woes ?

That is the correct approach IMHO... change per se, can only mean change to nowhere, or for worst...

Example; what are the REAL correct reasons for UEFI ? ... what are the solutions ? ... just for the sake of argument as i pointed elsewhere, what will happen if something like UEFI 2 happens (exclusive encrypt hardware) ?

the rest can be like chichens without head, that go in circles before drop to the side...

SAME DIRECTION

Posted Mar 9, 2013 20:00 UTC (Sat) by Wol (guest, #4433) [Link]

And what if that's the WRONG DIRECTION?

That is one of FLOSS's *S*T*R*O*N*G* points - that we quite happily throw massive engineering resource at multiple possible solutions before we settle on the correct one (that is, if there even IS a correct one!)

That is the PROBLEM with the MS approach - there is only one solution, and if it's the wrong one, tough. For example, imho Word is crap. Pretty much all word processors are trying to copy Word. In other words, it is almost impossible now to find a word processor that is capable of industrial strength work - they're all aimed at people who don't know how to type!

One size does NOT fit all.

Cheers,
Wol

SAME DIRECTION

Posted Mar 11, 2013 12:43 UTC (Mon) by dgm (subscriber, #49227) [Link]

> That is one of FLOSS's *S*T*R*O*N*G* points - that we quite happily throw massive engineering resource at multiple possible solutions before we settle on the correct one (that is, if there even IS a correct one!)

That's only a benefit if we can finally agree on a correct one, and drop those that do not add much value. Want to bet Canonical will NOT drop Mir, even if it proves to be an inferior solution? Hint: BZR, Upstart.

The problem is not that Canonical develops an alternative. That's fine, even for Kristian Høgsberg (Wayland's architect and main developer). They could be doing it as a side project, like Wayland is. Instead Canonical is endorsing it, unleveling the play field and creating an artificial barrier for Wayland (or any other) to enter. I despise profoundly saying that, but in that sense Canonical is not better than Microsoft.

But let's wait and see. Maybe this time they will do the right thing.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 19:23 UTC (Wed) by mmarq (guest, #2332) [Link]

Other example

>The tradition is shit... The tradition for Linux is to have huge amounts of duplicated work to deal with insignificant and unimportant technical details that distributions refuse to agree on. It creates headaches for developers and makes it difficult to install and almost impossible for end users to maintain the software they want to use at the versions they want to have.

If i had points to give, i would give you all for the daring

ummm... don't. That is, don't even try to maintain it. Oh! many will came back complaining furiously... but there must be a tough "conscious inner voice" that simple refuses and points the correct approach. The point is that the notion of "dumping for others to maintaining it" is just WRONG. There must be very concise technical merits, and there is also LSB for this -> support it, make your case there...

What you describe is the failure of LSB. Somehow it must get out of any distros influence... or any distro simple ignorance of it... ppl must have the courage to make it "independent", make it bigger, make it better...

>It's all one big mush with a maze of inter dependencies so complex and lavish that it resists any attempt for people to map it out and document it.

And in this is why "changing" have been making things much more harder not easier... the gross mass of "independent" or semi-independent devs, finds it easier to start all over, than to try to understand some pieces of code and attach themselfs to *collaborate* on something that is already there, to make it better...

... i just can't imagine why *trowing more into the maze* in a way that the originator himself understands better, and so half documented or documented in a way those original devs understand... does any good to improve the matters...

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 23:25 UTC (Tue) by robclark (subscriber, #74945) [Link]

surfaceflinger is only recently getting better and some very basic things (and afaiu still has a way to go), like proper vblank handling and hotplug, multi-display, etc, etc

It has been good enough for mobile devices for a while.. doesn't really make it a mature replacement for X in a desktop environment. And nothing that is missing from wayland is really present in SF.

I don't know of anyone who really knows much about desktop window management or graphics who things SF on desktop is a good idea.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 23:55 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Would a SF compatibility shim for Wayland make sense? For example PulseAudio has direct ESD compatibility as well as shims for ALSA and OSS which helps a lot. At least some coordination so that they can both be used on the same system and can use the same underlying graphics drivers.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 0:55 UTC (Wed) by robclark (subscriber, #74945) [Link]

possibly.. it might be kinda cool to be able to play angry birds while waiting for something to compile :-P

afaiu (from people who have looked into the details more than I have), it might require cutting in at deeper APIs in the android gfx stack which might change from release to release. But still it could be an interesting way to have linux and android coexisting to some extend. (Well, that solves the gfx part.. not sure about binder or other parts of the android stack that an app might depend on.)

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 5:45 UTC (Wed) by Serge (guest, #84957) [Link]

> what I don't get is why SurfaceFlinger doesn't seem to be considered as a basis for replacing X, and instead 'from scratch' projects Wayland and now Mir were created..

Modern Linux has a good graphical stack. In times of early X11 there was just text console and some random framebuffers around. That's why Xfree86/Xorg had its own userspace device drivers (microkernel fans, where are you).

But when people look at modern Mesa, DRI, EGL, they think "hey, it's so easy to draw something on a screen, you can even get 3D acceleration, and you don't need that bulky Xorg". So it's actually easy to create some basic hello-world-window-system from scratch. Much easier than dig through the code of Xorg/Wayland/DirectFB/etc.

The problem is that Xorg is not just about drawing, but about communication of very different programs. There can be video player, playing dvd on a side of a cube, rendered by compiz, recorded by recordmydesktop, remotely controlled over x11vnc, and none of them have to know about the others. Xorg supports every configuration possible, multiple monitors, multiple keyboards, even multiple mouse pointers on the same screen. It took years to turn all these things into stable standards. To make something new "better than Xorg" one have either convince everybody that they don't need all those features or reinvent them all.

Canonical/Mir devs have an excuse: they don't want to replace Xorg, they want something for mobile/tablets, that can isolate applications from each other (somewhat like Xnest) and looks working. Wayland devs don't even have that excuse.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 9:22 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Nowadays X-server simply uses kernel support for modesetting, display and input device discovery, etc.

So actually recreating all the X functionality is easy. At this point it simply makes sense to write something from scratch (Wayland is just several KLOC clear C code!) and add yet another compatibility layer to X.

After all, X server has a freaking x86 real mode emulator to run BIOS VESA modesetting on x64 hosts.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 17:08 UTC (Wed) by Serge (guest, #84957) [Link]

> Nowadays X-server simply uses kernel support for modesetting, display and input device discovery, etc.

It also "simply" provides all that information to X-clients and "simply" allows them to configure and use it. Xorg also has methods and standards for communications among all the X clients.

> So actually recreating all the X functionality is easy.

Sure, if Xorg was just about drawing, but it's not. That's why after 5 years of Wayland development it's still not much better than Windows 2.0, except being true-color.

> At this point it simply makes sense to write something from scratch

Makes sense? For what? Who's going to win from that? It adds more work for toolkit developers. It breaks compatibility with lots of existing software (window managers, dock bars, etc). But who's going to win from Wayland? Where are those people?

> After all, X server has a freaking x86 real mode emulator to run BIOS VESA modesetting on x64 hosts.

And Wayland has what? Or are you trying to say that X works when Wayland does not? Well, that's true.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 18:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> It also "simply" provides all that information to X-clients and "simply" allows them to configure and use it. Xorg also has methods and standards for communications among all the X clients.
So?

>Sure, if Xorg was just about drawing, but it's not. That's why after 5 years of Wayland development it's still not much better than Windows 2.0, except being true-color.
You can just say: "I know nothing about Wayland". It'd be much more concise and clear. Okay?

>Makes sense? For what? Who's going to win from that? It adds more work for toolkit developers.
It also adds very nice features ("every pixel's perfect, every pixel's great") that are not possible in X and works significantly faster on modern hardware. Toolkit developers actually don't seem to complain about evil Wayland developers forcing them to write yet another backend - instead toolkits are glad because Wayland opens them a way to yet another class of devices.

> And Wayland has what? Or are you trying to say that X works when Wayland does not? Well, that's true.
Yep. Because we really care about Ye Olde VGA adapters that X-server still supports.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 19:55 UTC (Wed) by Serge (guest, #84957) [Link]

> So?

Wayland does not.

> You can just say: "I know nothing about Wayland". It'd be much more concise and clear. Okay?

Since you mix Wayland (protocol) and Weston (implementation) I guess you really know nothing about Wayland. Have you at least seen Wayland/Weston? No? Then stop here, install Weston from your repository and try using it. If you can't do that, at least download RebeccaBlackOS LiveCD and boot it in native Wayland mode.

Current Wayland/Weston is just a toy. It's fun to run it and play with it a little. But it's useless. Even IceWM had more features 15 years ago than Weston has now.

> It also adds very nice features ("every pixel's perfect, every pixel's great") that are not possible in X

What "features" are you talking about? Xorg does not stop you from drawing "perfect pixels", does it? ;)

> and works significantly faster on modern hardware.

It's not. Unless you know some benchmarks with some popular real-world applications that everyone can check.

> Toolkit developers actually don't seem to complain

Sure, people always like having more work to do.

> toolkits are glad because Wayland opens them a way to yet another class of devices.

And what "yet another class of devices" would that be?

> Yep. Because we really care about Ye Olde VGA adapters that X-server still supports.

This excuse does not change the fact that Xorg is better than Wayland/Weston because it works when Wayland/Weston does not.

And you still ignored the main question: if Wayland is so good then where are those people that it's so good for? Who it was created for?

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 22:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Current Wayland/Weston is just a toy. It's fun to run it and play with it a little. But it's useless. Even IceWM had more features 15 years ago than Weston has now.
No it isn't. Wayland in fact has features that are not possible (without lots of pain) in X.

Now, Weston _is_ a toy - because it's the reference implementation. It was not (and still isn't) meant to replace all the window managers. In fact, KDE is porting their compositor to Wayland (with server-side decorations).

> What "features" are you talking about? Xorg does not stop you from drawing "perfect pixels", does it? ;)
Yes it does. The support for timed buffer updates is still not complete so we STILL have tearing and flicker. Resizing windows often results in ghosting effects, etc.

> And what "yet another class of devices" would that be?
Small devices. Also, large devices.

>This excuse does not change the fact that Xorg is better than Wayland/Weston because it works when Wayland/Weston does not.
A horse can pass through woods and swamps. Does it mean that it's better for transportation on the modern roads than a RAV4?

Yet another Wayland thread

Posted Mar 7, 2013 18:09 UTC (Thu) by Serge (guest, #84957) [Link]

> No it isn't. Wayland in fact has features that are not possible (without lots of pain) in X. Now, Weston _is_ a toy

But Wayland (protocol) is useless without compositor (Weston). You can't write real applications without using compositor extensions. And most of those extensions are just "possible" and do not exist yet. Are you saying that those non-existing features of Wayland are not possible in X? ;)

> KDE is porting their compositor to Wayland

KDE added Wayland support to kwin (that wasn't hard) and it's incompatible with Weston. That's one of the key Wayland problems: it encourages people to write multiple incompatible compositors, so we may end up with many different compositors, and no usable ones.

> Yes it does. The support for timed buffer updates is still not complete so we STILL have tearing and flicker.

I don't know why YOU still have them. I don't.

> Resizing windows often results in ghosting effects, etc.

Have you seen Wayland/Weston yet? Download RebeccaBlackOS, boot it in native Weston mode and try resizing some windows. Then reboot it into KDE+Xorg (it starts in compositing mode by default) and try resizing the very same windows. See any difference? Except KDE being faster?

>> And what "yet another class of devices" would that be?
> Small devices. Also, large devices.

:-) So, Wayland brings no new device classes. At least we agree on that.

> A horse can pass through woods and swamps. Does it mean that it's better for transportation on the modern roads than a RAV4?

My question still stands. If Wayland (is it horse or RAV4?) is so good and has so many features, then where are those roads? Who is supposed to feel the benefits of Wayland?

For example Canonical is going to get benefits from Mir, because they need some GUI applications isolation, and they expect to get it in a few months. What about Wayland?

Yet another Wayland thread

Posted Mar 7, 2013 22:28 UTC (Thu) by renox (subscriber, #23785) [Link]

> KDE added Wayland support to kwin (that wasn't hard) and it's incompatible with Weston. That's one of the key Wayland problems: it encourages people to write multiple incompatible compositors, so we may end up with many different compositors, and no usable ones.

Do you have a link which describes the port and the issues?
I think that is an interesting problem..

Yet another Wayland thread

Posted Mar 9, 2013 0:06 UTC (Sat) by Serge (guest, #84957) [Link]

> Do you have a link which describes the port and the issues?

A link to KDE implementation of wayland? I don't. I've read about it here on LWN, seen some screenshots, but never used it myself.

One of the key difference between Weston and KDE/kwin implementation of wayland is that kwin uses server-side decorations. The list of related issues were here: http://blog.martin-graesslin.com/blog/2010/05/open-letter...

I also remember people here were commenting that they'll probably implement missing wayland features in kwin and then hopefully agree them with other compositors.

Yet another Wayland thread

Posted Mar 11, 2013 9:38 UTC (Mon) by micka (subscriber, #38720) [Link]

> I also remember people here were commenting that they'll probably implement missing wayland features in kwin and then hopefully agree them with other compositors.

Which is already how it works on X. Someone launches a discussion on a new net_wm hint, sometimes after some time, most implementors (ie wm maintainers) agree, and they add it (or the other way, someone implements it, asks if it could be more general etc.).

Yet another Wayland thread

Posted Mar 12, 2013 22:23 UTC (Tue) by Serge (guest, #84957) [Link]

> Which is already how it works on X. Someone launches a discussion on a new net_wm hint, sometimes after some time, most implementors (ie wm maintainers) agree, and they add it (or the other way, someone implements it, asks if it could be more general etc.).

There're two differences. First: that's already done for X, standards are already created, well know and implemented, but for Wayland you have to spend 10 more years to do that again because it implements everything differently. Second: on X you don't have to patch X server to add the support for your new hint, wayland protocol is not so flexible. Can you imagine patching and rebuilding Xorg every time you want to test some new WM property? That's what you get with Wayland.

Yet another Wayland thread

Posted Mar 12, 2013 22:53 UTC (Tue) by micka (subscriber, #38720) [Link]

I'm not familiar with the actual apis under the window hints, so I'll tell how I imagine it and I can be corrected :

The client sets a property (a hint) and the window manager, if it knows it, interprets it.

When you decide to use a new hint, you change the window manager to interpret it and then use it in the client. So you must recompile the WM.
X provides the communication transport.

In wayland world, all this happens between the client and the compositor. If you must add a hint, you change and recompile the compositor.
There is no transport in the middle (X role above).

In both cases, the work to add a new hint is exactly the same.

Where was I wrong ?

Yet another Wayland thread

Posted Mar 15, 2013 8:27 UTC (Fri) by Serge (guest, #84957) [Link]

> When you decide to use a new hint, you change the window manager to interpret it and then use it in the client. So you must recompile the WM. X provides the communication transport.

You CAN recompile WM, but you don't have to. Your program and WM are independent. You can build your program on another WM and it will work there, just your hint will be ignored.

> In wayland world, all this happens between the client and the compositor. If you must add a hint, you change and recompile the compositor.

In Weston/Wayland you MUST recompile the compositor. Your program links with compositor, they share protocol. People won't be able build it until they update the compositor too.

> In both cases, the work to add a new hint is exactly the same.

You forget about the first difference. For the last 20 years most hints were already added, standards for them were already written and implemented in WMs. But in Wayland world you have to spend those 20 years again to reimplement them all from scratch. And you cannot reuse those standards, because Wayland does everything differently.

So in wayland world in addition to the work of adding a new hint you have to also do a lot of work to add all the old hints. It's a weird world...

Yet another Wayland thread

Posted Mar 15, 2013 9:37 UTC (Fri) by micka (subscriber, #38720) [Link]

> But in Wayland world you have to spend those 20 years again to reimplement them all from scratch.

For my part, I will assume that wayland devs are intelligent beings that are even able to make use of all the hard word that's been done in the past.

Yet another Wayland thread

Posted Mar 15, 2013 16:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> In Weston/Wayland you MUST recompile the compositor. Your program links with compositor, they share protocol. People won't be able build it until they update the compositor too.
Weston/Wayland? What is it?

Wayland and Weston are completely separate and independent components.

Yet another Wayland thread

Posted Mar 13, 2013 1:43 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Stop lying and misleading people. Wayland can be used to transport private messages (i.e. new hints) just fine without any recompilations.

Yet another Wayland thread

Posted Mar 14, 2013 6:02 UTC (Thu) by Serge (guest, #84957) [Link]

> Wayland can be used to transport private messages (i.e. new hints) just fine without any recompilations.

I'm not sure what you're trying to say, but Wayland is a protocol. It cannot transport private messages and you cannot compile it.

Yet another Wayland thread

Posted Mar 14, 2013 17:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Actually, Wayland is also the name of the implementation.

And I was answering to this:
>Second: on X you don't have to patch X server to add the support for your new hint, wayland protocol is not so flexible.

You CAN use Wayland protocol to pass private messages just fine. No recompilation required.

Yet another Wayland thread

Posted Mar 15, 2013 7:17 UTC (Fri) by Serge (guest, #84957) [Link]

> Actually, Wayland is also the name of the implementation.

Then what're Weston and QTWayland?

> You CAN use Wayland protocol to pass private messages just fine. No recompilation required.

I still don't understand what you mean. Protocol is a document, messages that are not in scope of that document are not part of the protocol. So you cannot send your private messages unless your "private messages" are part of the protocol. Technically you can send them through the same socket, but it won't make them part of Wayland protocol.

It's like saying that you can use GIF to store MP3 data just because you can put mp3-file to the directory with gif-files.

Yet another Wayland thread

Posted Mar 15, 2013 7:44 UTC (Fri) by micka (subscriber, #38720) [Link]

> It's like saying [...]

More like saying you can use TCP to send HTTP request.

Yet another Wayland thread

Posted Mar 15, 2013 9:09 UTC (Fri) by Serge (guest, #84957) [Link]

> More like saying you can use TCP to send HTTP request.

TCP has "data" section that is designed to carry another protocol. But you won't find a placeholder for another protocol in wayland.xml.

Yet another Wayland thread

Posted Mar 15, 2013 16:08 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> Then what're Weston and QTWayland?
Weston is a _compositor_. I.e. it's something like a WM in X world. And QTWayland is simply a name of QT integration with Wayland.

> I still don't understand what you mean.
Basically, Wayland provides a way for processes to communicate using a special form of IPC. Applications can use this IPC to exchange any type of data they want. Wayland itself also provides some services (described in wayland.xml) using this IPC.

> It's like saying that you can use GIF to store MP3 data just because you can put mp3-file to the directory with gif-files.
No. I'm saying that I can use Dropbox to synchronize not only Dropbox user manual but also GIFs and MP3.

Yet another Wayland thread

Posted Mar 16, 2013 7:46 UTC (Sat) by Serge (guest, #84957) [Link]

> Basically, Wayland provides a way for processes to communicate using a special form of IPC. Applications can use this IPC to exchange any type of data they want. Wayland itself also provides some services (described in wayland.xml) using this IPC.

Looks like you have your own understanding of the word "Wayland". Can you give me a link to the specification of THAT Wayland?

Yet another Wayland thread

Posted Mar 16, 2013 9:06 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

http://cgit.freedesktop.org/wayland/wayland/tree/doc/Wayland - enjoy...

What exactly do you not understand? That Wayland is both the name of a protocol AND its default implementation (i.e. Wayland)? Or that Wayland protocol can be used to carry app- and shell-specific data?

Yet another Wayland thread

Posted Mar 16, 2013 14:33 UTC (Sat) by cortana (subscriber, #24596) [Link]

I don't mean to sound thick, but I thought the reference implementation was called Weston?

Yet another Wayland thread

Posted Mar 16, 2013 20:24 UTC (Sat) by HelloWorld (guest, #56129) [Link]

Wayland is both a protocol and a library implementing that protocol. Weston is a compositor based on the Wayland library.

Yet another Wayland thread

Posted Mar 17, 2013 9:45 UTC (Sun) by Serge (guest, #84957) [Link]

> http://cgit.freedesktop.org/wayland/wayland/tree/doc/Wayland - enjoy... What exactly do you not understand?

"Wayland is a protocol for a new display server", "The wayland protocol is an asynchronous object oriented protocol", "The interfaces, requests and events are defined in protocol/wayland.xml". I don't see anything about "IPC" or applications that "can use this IPC to exchange any type of data".

> That Wayland is both the name of a protocol AND its default implementation (i.e. Wayland)? Or that Wayland protocol can be used to carry app- and shell-specific data?

The link you posted states that Wayland is a protocol and Weston is implementation. Have you read it yourself? ;-)

Yet another Wayland thread

Posted Mar 17, 2013 10:04 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> "Wayland is a protocol for a new display server", "The wayland protocol is an asynchronous object oriented protocol", "The interfaces, requests and events are defined in protocol/wayland.xml".
This makes it an IPC, by definition.

> I don't see anything about "IPC" or applications that "can use this IPC to exchange any type of data".
Check the source code. There are no restrictions on message content.

Yet another Wayland thread

Posted Mar 17, 2013 11:11 UTC (Sun) by Serge (guest, #84957) [Link]

> This makes it an IPC, by definition.

Hm. But it allows you to communicate with compositor only, and using protocol/wayland.xml messages only. Among others you also have a weird definition for "IPC"...

> Check the source code. There are no restrictions on message content.

protocol/wayland.xml is the source code of the protocol.

> Weston is a reference implementation of the Wayland compositor. Which is a separate piece from Wayland protocol or library. What do you not understand?

Ah! So what you called "Wayland" was libwayland-client (or was it libwayland-server?) I wonder, when you said "X" were you talking about libX11?

Anyway, I understand you now. Yes, libwayland allows you to send messages that are not part of the Wayland protocol, and you don't have to rebuild libwayland to send custom messages.

But that does not change much. In X world if you want your app displayed in some special way in your dockbar you need to patch you app and your dockbar, but you don't have to patch WM or X-server. In Wayland world you need to patch your app, dockbar and compositor. And it will work on your compositor only.

Yet another Wayland thread

Posted Mar 17, 2013 10:05 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> The link you posted states that Wayland is a protocol and Weston is implementation. Have you read it yourself? ;-)
Weston is a reference implementation of the Wayland compositor. Which is a separate piece from Wayland protocol or library. What do you not understand?

Yet another Wayland thread

Posted Mar 8, 2013 22:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> But Wayland (protocol) is useless without compositor (Weston). You can't write real applications without using compositor extensions.
Erm... Wayland applications do NOT depend on the compositor. They might want to use advisory "window state" interfaces.

> KDE added Wayland support to kwin (that wasn't hard) and it's incompatible with Weston. That's one of the key Wayland problems: it encourages people to write multiple incompatible compositors, so we may end up with many different compositors, and no usable ones.
ROTFL. As if X Windows has exactly one compositor and window manager.

>Have you seen Wayland/Weston yet? Download RebeccaBlackOS, boot it in native Weston mode and try resizing some windows. Then reboot it into KDE+Xorg (it starts in compositing mode by default) and try resizing the very same windows. See any difference? Except KDE being faster?
Yeah, I see tearing in X Windows.

> My question still stands. If Wayland (is it horse or RAV4?) is so good and has so many features, then where are those roads? Who is supposed to feel the benefits of Wayland?
Indirectly - everyone. Directly - developers who can now write better applications with better graphics stack. It's happening already.

Yet another Wayland thread

Posted Mar 9, 2013 0:56 UTC (Sat) by Serge (guest, #84957) [Link]

> Erm... Wayland applications do NOT depend on the compositor.

You must be talking about some theoretical Wayland again. Real world applications have to use compositor-specific interfaces. For example how are you going to take a screenshot without depending on the compositor? How are you going to make a taskbar without using compositor extension?

> ROTFL. As if X Windows has exactly one compositor and window manager.

That's the point! Single X window system implementation has many WMs. But every single Wayland compositor implementation has just one WM. By design. Encouraged by Wayland. You do know that Wayland server is called "compositor", don't you?

> Yeah, I see tearing in X Windows.

That was an optical illusion. And it was under Wayland. :)

Really, get back to the real life, and at least check RebeccaBlackOS LiveCD to actually see that Wayland you're talking about.

> Indirectly - everyone. Directly - developers who can now write better applications with better graphics stack.

What developers? Developers of what? Developers using toolkits aren't supposed to see any changes. So no benefits for them. Developers of those toolkits just got more work to do, which obviously no good for them too, unless they like to work a lot. Then what developers are you talking about?

Yet another Wayland thread

Posted Mar 9, 2013 4:38 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

>You must be talking about some theoretical Wayland again. Real world applications have to use compositor-specific interfaces.
No they don't. Basic shell protocols are already defined.

>For example how are you going to take a screenshot without depending on the compositor? How are you going to make a taskbar without using compositor extension?
You can't, and rightly so. Here's something interesting for you - it's not possible in X as well (in the general case).

> That's the point! Single X window system implementation has many WMs.
And they are compatible, right? Say, does IceWM support that nice tray popup dbus protocol?

Whoops.

>Really, get back to the real life, and at least check RebeccaBlackOS LiveCD to actually see that Wayland you're talking about.
I've read Wayland source code and I've actually tried it back when it could only display a primitive terminal window and rotating flowers.

Yet another Wayland thread

Posted Mar 9, 2013 19:04 UTC (Sat) by Serge (guest, #84957) [Link]

> I've read Wayland source code and I've actually tried it back when it could only display a primitive terminal window and rotating flowers.

Then why you're saying things like "Wayland opens a way to yet another class of devices" and constantly mix up Wayland and Weston as if you've never seen them and don't know anything about them?

>> You must be talking about some theoretical Wayland again. Real world applications have to use compositor-specific interfaces.
> No they don't.

Have you read sources of those applications? Read again. :) You'll see that *real-world* applications use compositor-specific interfaces.

> And they are compatible, right? Say, does IceWM support that nice tray popup dbus protocol?

Yes, it does. Even more, they're supported without WM at all (notification-daemon).

> Whoops.

Are those tray popups supported in Wayland/Weston? No. Whoops. :)

You are arguing that Xorg is not too good, and Wayland is not too bad, while you should be arguing who it's good for. Nothing else matters if Wayland is good for noone.

Yet another Wayland thread

Posted Mar 10, 2013 21:46 UTC (Sun) by renox (subscriber, #23785) [Link]

>No they don't. Basic shell protocols are already defined.

For Weston... But I wonder if the other compositor developers will like them!

Yet another Wayland thread

Posted Mar 10, 2013 21:57 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Most of protocols are in the Wayland namespace. And it's not like X window managers developers get to vote on whether they like certain features of X protocol.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 16:16 UTC (Tue) by mmarq (guest, #2332) [Link]

> the concerns get stronger.

Oh! yes... the Jumping Monkey of Redmond, is already jumping and kicking chairs around in euphoria... and biting wet towels hard with all the expectation...

while you "fork" and battle each other with secondary issues, a strong divergent impulse, he has other plans *UEFI 2*

It will take great "care", "maneuverability", "cleverness" and "sense of opportunity"... while their main "enemy" is entertained fighting each other and making things more difficult for the "client/desktop" side, with all the incompatibilities and bugs that it can bring... he might be preparing to require a "dedicated chip/encrypting circuit" for their "safe boot" schemes, which has nothing about security, unless we consider the "user" of those systems the main malware threat...

And this Redmond does, consider the "end user" as the main malware threat, since those users now can always show the finger and install other OS and respective applications... something that must be "taking care of" ... capice! lol

So i don't understand why this things deliver so much controversy, soon end users will have no other choice but to install the Redmond crap software... all done under ppl noses while they are distracted, pointless bickering and or at sleep...

So who cares about Mir etc... soon if you are not a "full system deployer", that is, have your own hardware, like Canonical and other seems to target, the only choice from ultramobile to desktop will be GDI/directX...

The Correct Strategic Counter-Action (strategic NOT code) would be to promote Coreboot with all strength until exhaustion... it could even have UEFI on top, for those who wish... but no!... actually the only "strategic mind" around is bashed with pity and sarcasm and Coreboot labeled as a failure...

So free is a misnomer, or for having Linux on the client you will have to pay and buy Canonical or other's hardware... it was to be expected since almost nobody pays for any software, and those companies to survive have little other choices ( one pertinent choice would be to compile install everything from online into an "end user" machine, force them to pay for a really tunned system, but this choice is fading with UEFI to)... or you will be out of luck.

Lets give back to the community lol <what a sarcastic joke>

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 2:35 UTC (Tue) by tjc (subscriber, #137) [Link]

> Everybody is free to spend their time/money as they best see fit, provided they give back to the community.

Everyone is free to spend their time and/or money as they see fit regardless of their contributions to the community.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 3:44 UTC (Tue) by drag (subscriber, #31333) [Link]

Yes. That is correct. It is one of the major driving forces behind the widespread adoption of Linux in many areas.

This contrasts the difference between working with somebody like Microsoft. They hold their customers hostage under IP laws. For those people when they pay Microsoft to improve and modify the windows software and related services Microsoft turns around and sells those improvements to their competitors.

With open source ideally you are not for end to share unless its in your best interest.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 4:13 UTC (Tue) by drag (subscriber, #31333) [Link]

Gah. Stupid android keyboard:

> With open source ideally you are not for end to share unless its in your best interest.

With open source, ideally, you are not forced to share unless its in your best interest.

unless its in your best interest.

Posted Mar 5, 2013 10:02 UTC (Tue) by Wol (guest, #4433) [Link]

But the POINT of open source is that it usually IS in your interest to share.

You offload a lot of your maintenance headache onto someone else :-) and you get a pool of experienced workers to hire if you need to :-) and if neither of those options come off, you're no worse off than you would have been.

Cheers,
Wol

unless its in your best interest.

Posted Mar 5, 2013 13:59 UTC (Tue) by drag (subscriber, #31333) [Link]

Yes. Absolutely.

People always act in their best interest. They maybe confused or wrong or behave in a counter productive manner, but you can trust that they are in it for themselves and to further their own goals. There really isn't any point in them behaving in any other manner.

However, more often then not, in a free society people's best interests are served best by being aware and serving other people's best interests. This is what makes a society prosperous and function properly. It's a very nice facet of human nature.

It's when people go crying about licensing and trying to manipulate the legal system to force other people to behave contrary to their desires is one of the ways things start to go to shit.

unless its in your best interest.

Posted Mar 5, 2013 18:51 UTC (Tue) by mmarq (guest, #2332) [Link]

>You offload a lot of your maintenance headache onto someone else :-)

Yes that seems to be the recurrent idea, which is WRONG. The main idea should be exactly about "COOPERATION", that is, Open Source means nothing when end users can't have really tuned systems by compile install with all the "peculiarities" of the processing chips (CPU+GPU+whatever)... its not only about x86 anymore, ARM will be here very soon and they seem to target HSA for most pertinent parts...

And Open Source means nothing when instead of cooperating for that maintenance, and i can add "IMPROVEMENT"... others are just about to fork it, just because seems nice to them to be "different" (delivered with a lot of lame excuses!).

Nowadays in the client side, Open Source means offload not for maintenance and improvement but to the forking party... all seems prone to an eternal start all over again and stagnation, because the projects tend to pile with no certain heading, or be incompatible with each other!

>and you get a pool of experienced workers to hire if you need to :-) and if neither of those options come off, you're no worse off than you would have been.

Well Open Source makes a VERY BAD traditional business model... meaning the software by inherent propriety must be free.

There is the windoze model (their free part is in warez/freeware) of **forced pay** by the hardware side, scheme that everybody seems to more or less endorse now, because is prone to "differentiation", and you hire devs exactly to make it different (fork)...

... and there is the service model, that can go from the in-situ help to online services including **compelling pay** tunned compile-install for the machines of common Joe(something that never was pursued), is much less prone to differentiation, that is, one vendor can't aspire to win all the market, requires a lot of cooperation, but OTOH it can be prone to achieve really sophisticated pieces of software(if the cooperation is intense and projects stay on target -> example Linux kernel)...

I'm afraid at least in the client side "quality" and "sophistication" seems tending to suffer a lot in favor of *fast* and simpler "differentiation"(there are a lot of distros more client oriented struggling now, they want something fast, different and *forced pay* -> like running to nowhere lol)... matter of fact there seems to be a lot of bitching about complexity, something i never read about the Linux kernel as example. Matter of fact the kernel is now about different "namespaces" and "containers" for the same kernel allover, like VMs without VMs... seems absurdly complicated, AFAIK NONE OS have it natively yet in the extent that Linux Kernel seems to be heading (not even solaris), yet nobody complains about complexity (they complain about other issues lol).

Those are "the differences"... results speak volumes for themselves... why Linux kernel devs are forced to cooperate while in the client side they seem to do the opposite, could be prone to endless discussion, but in the end it depends a lot on the ppl involved and the "interests" behind them, and if the ppl involved can have "vision", stay on target and COOPERATE, and be more or less impermeable to those "interests" (with $ dreams) and or other personal fancy issues.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 23:04 UTC (Mon) by mmcgrath (guest, #44906) [Link]

You can't include canonical on that list. Red Hat has done great on the server (and jboss middleware). Android has done great on devices as has iOS. Canonical has done well in the Linux desktop market. But that market remains at about 1% of the overall desktop market[1] and hasn't grown much in the last ten years even though there are way more desktop users today compared to 2002.

Being entrenched in Linux and using it every day, we tend to over-value the impact canonical has actually have. The truth is outside of our circles it's still basically unknown.

[1] http://en.wikipedia.org/wiki/Usage_share_of_operating_sys...

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 23:24 UTC (Mon) by man_ls (subscriber, #15091) [Link]

Ubuntu is competing nicely on the server with Red Hat, having surpassed them according to certain measures. For instance on AWS it seems that Ubuntu is much more popular. That is a big impact, I think.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 23:42 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Is that with paying customers? You can't eat marketshare or write checks based on your popularity. Sustainability is important too and while I don't question Shuttleworth's commitment I don't think it is sustainable, anybody could be hit by a bus or lose interest, Ubuntu really won't survive without him funding full time development.

Moving the goalposts

Posted Mar 4, 2013 23:49 UTC (Mon) by man_ls (subscriber, #15091) [Link]

Sure, and Google could decide that Android is a bad idea and abandon it. How many Android customers are paying (to Google) customers? How long would Android survive without Google's commitment? So your argument translates into one of relative size and of safe choices.

But we were talking about impact, where IMHO it is not a good idea to downplay Canonical's contributions. Even though I prefer Debian myself (on the server and on the desktop), Ubuntu is a very nice distro and the only one that has made inroads into the general public.

Moving the goalposts

Posted Mar 4, 2013 23:57 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]

Without Google's commitment, Samsung would take over Android development, with plenty of money to fund it (though they might no longer share with other players).

Android has hundreds of millions of paying users. Neither Wayland nor MIR have end users yet. Perhaps MIR has good ideas, but the fragmentation of the quite small free desktop space makes me nervous.

Moving the goalposts

Posted Mar 5, 2013 0:06 UTC (Tue) by man_ls (subscriber, #15091) [Link]

Me too, but instead of shouting that the sky is falling, maybe we should be asking more interesting questions: will there be a standard ABI for drivers? Will the protocols be interoperable? Will there be a common API for applications and desktop environments? If we accept that both sides have good ideas and can learn from the other side, then we can wait patiently until Lennart Poettering reinvents the graphics stack with his own solution (preferently integrated into systemd, because where else? :)

Moving the goalposts

Posted Mar 5, 2013 2:39 UTC (Tue) by rahvin (subscriber, #16953) [Link]

My questions are more simple. Why couldn't they devote their limited resources to expanding/improving an existing solution? Wayland needs the help and for shuttleworth to run off and spend his limited resources on yet another fork is insanity. If he devoted those same resources to wayland he might be able to get what he wants while improving wayland for everyone.

Moving the goalposts

Posted Mar 5, 2013 3:46 UTC (Tue) by drag (subscriber, #31333) [Link]

Probably the same reason they are using upstart. They like what they are doing more then what others are doing.

Moving the goalposts

Posted Mar 5, 2013 5:03 UTC (Tue) by raven667 (subscriber, #5198) [Link]

This seems different than with bazaar or upstart, in those cases they saw the need and were early to the party but failure to build a consensus around their design caused them to be left by the wayside as the industry moved on to technically better solutions (git and systemd). In this case they are late to the part, the early one is google with surface finger and the design that will probably win out on quality is Wayland so that doesnt leave much room for Mir. Maybe it will be like Phonon and just wrap the real API, as long as it doesn't get in the way

Moving the goalposts

Posted Mar 6, 2013 5:18 UTC (Wed) by Serge (guest, #84957) [Link]

> In this case they are late to the part, the early one is google with surface finger and the design that will probably win out on quality is Wayland so that doesnt leave much room for Mir.

Not late. Currently there's nothing but Xorg in Linux. Yes, there're Wayland builds in some distributions, there's even RebeccaBlackOS livecd with Wayland on it. But most people have never seen it, they don't know how Wayland works or even looks. Even those who've seen it usually say that it's in early development stage, and lacks many features.

So actually there's Xorg and tales about legendary Wayland. :) Now we've just got one more tale about legendary Mir.

Moving the goalposts

Posted Mar 5, 2013 5:53 UTC (Tue) by HelloWorld (guest, #56129) [Link]

The stated reason for sticking with upstart is that it took them five releases to make it work somehow and they expect the same kind of breakage from systemd.

> http://ubuntu.5.n6.nabble.com/upstart-beyond-Ubuntu-12-04...

It obviously never occurred to them that making upstart work was hard because it, you know, is upstart.

Moving the goalposts

Posted Mar 7, 2013 20:27 UTC (Thu) by JanC_ (guest, #34940) [Link]

From my point of view, it took so long because of lack of manpower. That problem didn't get solved until recently (the last 6 months or so?).

Moving the goalposts

Posted Mar 5, 2013 9:08 UTC (Tue) by cladisch (✭ supporter ✭, #50193) [Link]

> then we can wait patiently until Lennart Poettering reinvents the graphics stack with his own solution

There's no need to wait for Lennart; Kristian Høgsberg is quite capable of doing this by himself with Wayland (and already did this with the Linux FireWire stack, which he replaced with Juju).

Moving the goalposts

Posted Mar 5, 2013 0:54 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I'll freely admit my point isn't a strong one but google has many paying customers on android, although googles main customers are the advertisers, not handset users and androids main function is to prevent google from sliding into irrelevance, like yahoo.

Android

Posted Mar 5, 2013 11:01 UTC (Tue) by Tobu (subscriber, #24111) [Link]

Google also gets plenty of data: geolocation (how people move, plus supporting data like the locations of antennas and hotspots) and app installs, browsing histories for Chrome users, app usage for the ones that show their ads. Account integration enables apps to start sharing almost invisibly.

Moving the goalposts

Posted Mar 5, 2013 0:58 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I should also point out that I like Ubuntu just fine, I think unity is a better interface than gnome3 shell and they probably made the right decision to split and make a more traditional desktop. I hope they do well but their decision making seems to be high risk and clouded by ignorance

Moving the goalposts

Posted Mar 5, 2013 6:24 UTC (Tue) by misc (subscriber, #73730) [Link]

The history is full of distros going out of business due to lack of fund. Think what happened to Mandriva for example. And Canonical is currently working on cost cutting initiative like "switching UDS to virtual event". They are also not planning on Mark money, or they would not have implemented stuff like "amazon referal", or tried to sell music. In fact, if Canonical didn't care about the money, they would have done a fundation like Mozilla or Wikimedia.

So yes, sustainability is what matter, and Canonical is nowhere being sustainable for now.

Moving the goalposts

Posted Mar 5, 2013 7:23 UTC (Tue) by man_ls (subscriber, #15091) [Link]

A foundation, you mean? It was done in 2005.

Moving the goalposts

Posted Mar 5, 2013 8:52 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

No. That isn't a real non-profit foundation with any real part in the Ubuntu governance model. It is just a financial reserve. Nothing more.

Moving the goalposts

Posted Mar 5, 2013 8:56 UTC (Tue) by man_ls (subscriber, #15091) [Link]

Well, it addresses the "sustainability" bit quite nicely.

Moving the goalposts

Posted Mar 5, 2013 18:58 UTC (Tue) by misc (subscriber, #73730) [Link]

Well, for how long ?

RH had 343 millions $ of earning in Q3 of 2012. The company had around 5300 people on payroll at this time. According to SEC fillings, the expenses for Q3 is around 240 millions $.

Mozilla foundation, in 2010, spent 145 millions $ in expenses, for a payroll of around 250 people ( according to Quora and their own website ).

Canonical has around 500 people on payroll if i am not wrong. If I just divide by 10 to match the numbers of RH, that would mean operating expenses of at least 100 millions per year ( 4 * 24 millions ) for Canonical.

If I take the one of Mozilla, that mean around 300 millions of $ in expenses per year for Canonical.

So please now explain how 10 millions of $ put in 2005 on a bank account does address the sustainability in any way.

Either someone put something like 290 millions of $ to pay everybody for 3 years ( without any investment ), or there will be massive layoffs ( like 97% of the current work force ), along massive cost cutting changes ( like, not using one of the most expensive part of one one of the most expensive town of Europa as HQ, or not doing bi yearly events that cost around 500 000 euros to organize ).

Moving the goalposts

Posted Mar 5, 2013 19:17 UTC (Tue) by man_ls (subscriber, #15091) [Link]

If you are paying your employees $500K per year then your numbers make sense. If instead you have a mobile workforce spread all around Europe, of which developers are but a small fraction, then they don't.

Let us reverse your computations: $10M allow you to pay 33 developers for 3 years if you give them $100K each, or $50K including benefits. That should give Ubuntu developers some air should Canonical stop employing them, even if there were zero income -- and in fairness we have to suppose that Ubuntu would get some money from other interested organizations and some volunteer efforts.

It always amazes me how people can use numbers in ingenious ways to prove their point when Canonical is involved.

Moving the goalposts

Posted Mar 5, 2013 20:54 UTC (Tue) by mmarq (guest, #2332) [Link]

Not hard to imagine Canonical is in trouble.. i can even imagine that most distros might be in trouble, there is just too many of them, and if the main focus of the enterprise is purely sell software, then they are asking for trouble.

I can think a lot of things, i can be wrong about many things, but i think a re-invention of the model for most of those will be in the order of the day... as example Mandriva is still alive and has a different model... only the forking spree seems more an act of desperation or a "forcing push trough the crowd" than a careful wise move.

Moving the goalposts

Posted Mar 6, 2013 9:07 UTC (Wed) by misc (subscriber, #73730) [Link]

Sure, just show me where Mozilla or RH pay their employee 500K and maybe you can start saying "the numbers doesnt add up". Expenses count more than pay, there is also buildings, legal fees, travel, hardware, accounting, etc. In most countries you should also add taxes.

I based my computation on real life and verifiable numbers on the web ( and I would say, even stuff that are kinda legally required to reflect the truth ). You just take yours out of nowhere, forgetting lots of stuff that need to be paid. Just look at any foundation accounting to see how much this cost.

And both Mozilla and RH have highly decentralized workforce, both are in the same market segment as Canonical, so I am pretty sure that if Canonical started to publish now enough information to compare, the numbers would be the same. But feel free to find me a real life example of a organisation that match your numbers.

Also, 33 developpers are just 10% of the current canonical workforce. That's enough to make a small distribution, but in no way enough to sustain several complex project like Unity, Upstart, Bzr, Launchpad, Mir, Gwibber, Lightdm, Juju, Maas, AppArmor, software center, UbuntuOne, and all the distribution ( and port on others platforms like TV, phone, etc ).

You need people for QA, documentation, translation, system administration, etc.

Before people were fired from Mandriva to create Mageia, the company was around 50 person, split between Brasil and France. And this was barely enough to produce a OS and maintain in house code ( installer, drakxtools, etc ). There was less projects than Canonical, and they had income.

Not to mention that if 90% of your workforce leave, there is a high chance that all of them will not work for free for the project anymore ( see Stormy Peters talk about it, something around "would you do it again for free" ). There is also a high probability that you have to remove people who act as bridges with community, thus making the community angry ( again, look at Mandriva and the way people reacted when Adam Williamson or Gael Duval were asked to leave ).

And while you think people will pay to sustain Ubuntu, you are also not taking in account the fact that Canonical will not disappear in 1 day if the worst happen. If something happen that result into using the fund to create a fundation as a measure against Canonical financial problem, the whole project slowly start to go down, and then community will slowly leave ( again, Mandriva ), and so there is likely no others interested organisations to give any money.

A saner model would be to do it right now, when everything go well and to drop the whole CLA idea with copyright assignment to Canonical, cause this prevent others interested companies from investing time ( at least, not without lots of paperwork ). AFAIK, Suse, Google, RH and likely others have such policy, and while they can do it, they would not do for smaller projects.

This would also restore the confidence of community, after the various issues like "amazon integration dropped after the freeze", or "UDS announced 2 weeks before, thus causing issues to people who booked their holidays for it".

Moving the goalposts

Posted Mar 6, 2013 9:40 UTC (Wed) by man_ls (subscriber, #15091) [Link]

Let us see: Mandriva reported expenses in Q4 2008 of €1.5 M. In Q3 2008 it was €1.6 M (before the restructuring). I have not found better numbers. If that is enough to pay 50 employees for a year and build a distro, then Ubuntu might continue for some 5 years.

Moving the goalposts

Posted Mar 6, 2013 20:37 UTC (Wed) by misc (subscriber, #73730) [Link]

except that due to creative accounting and french law regarding equivalent of US chapter 11, most people were not employed by mandriva but by edge-it , connectiva and linbox, since mandriva contracts were better and limited to existing jobs, preventing changing the structure. Each of theses companies ( and in fact Connectiva count as 2 due to them having 1 offshore company for various tax related reasons ) were not counted in the financial results since "independant" structures. If you can read french, just go see how and why Edge it bankrupted and how Mandriva was offloading the debt on them, resulting into them disappearing. And simplifying the structure was one of the work done by the previous CEO Arnaud Laprevote.

Moving the goalposts

Posted Mar 6, 2013 20:22 UTC (Wed) by mmarq (guest, #2332) [Link]

>Not to mention that if 90% of your workforce leave, **there is a high chance that all of them will not work for free for the project anymore** ( see Stormy Peters talk about it, something around "would you do it again for free" ). There is also a high probability that you have to remove people who act as bridges with community, thus making the community angry ( again, look at Mandriva and the way people reacted when Adam Williamson or Gael Duval were asked to leave ).

>**there is a high chance that all of them will not work for free for the project anymore**

Oh! there is a good chance they will... and they could even end up paying for it to! lol... specially if they could derive a business out of it.

Maybe that is what makes me arrogant, but i never understood the lack of vision -> What is it that most ppl more connected to the F/OSS side really want ?

ummm... they want their own distro... no ?

So instead of a Mandriva 20388 or a Ubuntu Jolly Something... Why not a Mandriva or a Ubuntu "Stormy Peters" as example ?

see ?

In the same sense, since we are talking about "client side", but also perfectly appliable to any server version... why not a Ubuntu or Mandriva "MacDonal's" or "Ford" or "Boeing"... or more up to point a Mandriva or Ubuntu "local smaller company", with all the "local" customization, LOffice with the pertinent forms, the pertinent apps in place some that can be even CS commercial Linux versions.. etc ..etc ?

see the point ?

That seems a real good "re-invention" of the model... it is "service oriented" model, the main distro is only a big repository, app store kind of thing, and it can even adapt to the "masses" being all online compile-install with several degrees of customization...

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 20:18 UTC (Tue) by mmarq (guest, #2332) [Link]

> Canonical has done well in the Linux desktop market. But that market remains at about 1% of the overall desktop market[1] and hasn't grown much in the last ten years even though there are way more desktop users today compared to 2002.

big pile of Bull...

I can't imagine what would be easier... some authority just outright outlaw Open Source and their systems, or make ppl believe a lot of crap mantras.

That 1% is a mantra, that is all. Matter of fact i've read about that 1% for more than 10 years now, yet in my country, like so many others, the official client system is windoze, no matter the slogans and promises of free, yet Linux desktop has grown a lot, i mean A LOT (it was inexistent lol)...

The reality is that none knows for sure or can know for sure... many issues like dual-boot and a single ISO download serving to install into thousands of machines, just muds the waters even further.

What might be true is that of all those Linux installs, only 1% pays in any form for the software. Yes!, whoever has a software business around Linux this must be the top gravest issue.

How to solve it ?... well, i pointed above some options, i like the most for that "necessary" volume paying, the possibility of "online compile-install". Yes yes, is not easy, the tools existing are not quite for the job... well, cooperate much more and develop the tools, 5 or 6 different toolchains and 5 or 6 repository + package systems doesn't do any good either.

And there is the all "online" services that can be different... meaning who has the capacity will survive, and the crowd of distros would tend to merge or disappear, all would be much better than to try to sell software in the pre-installed windoze model in some line of hardware well supported(cooperate much more and you can support well about all of it).

For one entity alone, be it Canonical or bigger like Red Hat this is an impossible task... but if most of the more pertinent distros cooperate in the same direction, this infrastructure can be in place quite fast, faster than most would think possible... meaning OpenSource shinning in true nature...

Hey! Canonical, Red Hat... then you could even "impose" some of your ideas to the hardware vendors, you could have as much or more "strength" than Redmond... instead of baw whenever some vendor might ask for a pre-install version, for a cheap entry line of hardware that will sell horribly, and freak out in expectation of more...

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 20:42 UTC (Tue) by ovitters (subscriber, #27950) [Link]

Your comments are terribly hard to read. I don't really understand your meaning in most of your replies. In any case, please just use normal words. e.g. Windows or Microsoft Windows.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 23:05 UTC (Tue) by mmarq (guest, #2332) [Link]

c'mon Windoze and M$ crapOS is easier to write and everybody understands...

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 0:08 UTC (Wed) by ringerc (subscriber, #3071) [Link]

Sure, most people understand, but many will skip reading your comment when they see things like that, since it suggests a certain Slashdot-ish style of thinking and writing.

I think ovitters's comments are intended constructively, and tend to agree. I just skip your comments because they're hard to read and kind of ranty, and I suspect I'm not the only one.

This may be fine if you're just writing to vent, but if you want to actually communicate your ideas you might want to think about how you do so.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 17:21 UTC (Wed) by mmarq (guest, #2332) [Link]

>Sure, most people understand, but many will skip reading your comment when they see things like that, since it suggests a certain Slashdot-ish style of thinking and writing.

I see it exactly like the impulse to fork and get differentiation... ppl are always "free" to do that.

And matter of fact i never posted on Slashdot... doubt how much you like... it is just a perfect illustration of why ppl tend to be very mistaken with their clichés, prejudices and judging of others. And this tend to reflect in many other things included in the code and decisions they take.

But in any case i rather be Slashdot-ish than Windoze-ish of forced conformity...

And now those powers seem to be wanting ppl to police each other, this while free speech is not abolished for good... meanwhile is don't look don't listen, attack any opposition to the aesthetic line... for lack of better arguments for your own carved self doom...

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 21:50 UTC (Wed) by ovitters (subscriber, #27950) [Link]

I indeed meant it constructively. His (?) comments are very hard to read and I just suggesting ways to improve. As he (?) does not care to make his comments readable and most people seem to ignore his comments, I guess this will be the first time I'll put someone on the LWN ignore list :P

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 2:59 UTC (Wed) by mmcgrath (guest, #44906) [Link]

> big pile of Bull...

Sorry mmarq, that 1% isn't mantra, it's just math. You've fallen into the "I wish it weren't this way" trap. I used to be right there with you. If you actually click through the link I referenced, that wasn't a paid software statistic.

The problem isn't the hardware vendors. They don't want to offer Linux because people don't want to buy it for their desktops. Lets be real and look at it another way.

If we charged for Linux desktops what Apple charges for OSX, few would buy it. If OSX were free (in every way) few would use the Linux desktop. It's not enough to be free anymore. It also has to be as good if not better.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 7:49 UTC (Wed) by niner (subscriber, #26151) [Link]

The 1 % comes from website statistics that seem to be centered on the USA. The linked Wikipedia article cites statistics varying between about 0.9 and 1.9 %. A recent statistic from Valve's Steam on the other hand already shows Linux as having 2 % market share. And that's with Steam for Linux being released only for a couple of weeks and with Ubuntu still the only officially supported distribution.

In other words: it's really, really hard to find some correct number here.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 16:43 UTC (Wed) by mmcgrath (guest, #44906) [Link]

> In other words: it's really, really hard to find some correct number here.

If the highest numbers you could find were 2% of PC video gamers then lets go with 2%. My point still stands. We give the Linux desktop away, there's 98% of people out there that would prefer to pay for an alternative.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 20:35 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]

no, it's that they pay for the alternative when they purchase their computer and don't see it worth their time to switch from the vendor 'supported' OS to Linux, let alone go through the hassle of trying to get some money back for the OS that was bundled with their hardware.

That's very different from saying that they would rather pay for an alternative.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 7, 2013 10:29 UTC (Thu) by dgm (subscriber, #49227) [Link]

> no, it's that they pay for the alternative when they purchase their computer and don't see it worth their time to switch from the vendor 'supported' OS to Linux, let alone go through the hassle of trying to get some money back for the OS that was bundled with their hardware.

It's still a bit more confusing. _Users_ do not pay for the OS that comes with their computers, OEMs do. And for them, Windows + crapware pre-installed has actually _negative_ price, that is, they get money for that. Free is not cheap enough to compete. Someday someone verify if this common practice is completely legal, and in the best interest of consumers.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 7, 2013 11:15 UTC (Thu) by hummassa (subscriber, #307) [Link]

> Someday someone verify if this common practice is completely legal, and in the best interest of consumers.

I have no doubt that the mentioned practice is completely legal in most jurisdictions around the world (*). But I also have no doubt that it is *not* in the best interest of consumers.

(*) modulo the cases where the crapware is also malware, or is (possibly unintentionally) infected with malware.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 8:40 UTC (Wed) by anselm (subscriber, #2796) [Link]

[The hardware vendors] don't want to offer Linux because people don't want to buy it for their desktops.

Also (and mostly) because Microsoft will come down on them like a ton of bricks if they do. Since most of their business is selling Windows machines, losing that nice discount on Windows would be tough on them. Hardware vendors live by selling hardware, and if Microsoft didn't essentially pay them to push Windows they couldn't care less which OS went on their computers – they would happily sell you CP/M if it helped them move more boxes. Besides, the kickbacks from pre-installing junk software on top of Windows are nice if you're a hardware vendor.

If OSX were free (in every way) few would use the Linux desktop. It's not enough to be free anymore. It also has to be as good if not better.

The important point to remember here is that Apple is a hardware vendor. They're doing OS X not because they are in the business of making operating systems; they're doing OS X because it helps them shift boxes at higher margins than if they were Dell or HP. They didn't want others to sell computers based on Mac OS even way back when it sucked rocks, since what they really want is for people to buy Apple hardware. (In any event, Apple's main business these days is selling lifestyle gadgets rather than computers. They could stop making computers tomorrow and would still be highly profitable.)

There are people who will put Linux (or Windows) on their Apple computers because the computers are really rather nice if somewhat expensive. These people are not necessarily masochists. If OS X was clearly that much better in every respect than the other operating systems then that wouldn't ever happen.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 21:54 UTC (Wed) by mmarq (guest, #2332) [Link]

>Also (and mostly) because Microsoft will come down on them like a ton of bricks if they do. Since most of their business is selling Windows machines, losing that nice discount on Windows would be tough on them. Hardware vendors live by selling hardware, and if Microsoft didn't essentially pay them to push Windows they couldn't care less which OS went on their computers – they would happily sell you CP/M if it helped them move more boxes. Besides, the kickbacks from pre-installing junk software on top of Windows are nice if you're a hardware vendor.

Yes the big "institutional" vendors, Dell, HP etc... might be exactly like that, like an implicit blackmail threat, comply and have bonus or else...

But what about letting the "potential" Stormy Peters do it lol (just an example with a picked name, nothing relevant or personal) http://lwn.net/Articles/541625/ ... i mean there can be many "local" smaller vendors in a model similar to the traditional white box model, but attaching themselves and their clients to a model resembling Android, with free and non-free (per say), paying or freeware "appstore"...

The main distros are only a repository / appstore, the local and other customizations is up to those small vendors that can derive a good business out of the hardware selling (and customization that could surpass windoze by miles, or any attempt to emulate by any distro-> simply because one size can't fit all).

This will break the Redmond barrier i'm sure.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 17:47 UTC (Wed) by mmarq (guest, #2332) [Link]

>Sorry mmarq, that 1% isn't mantra, it's just math. You've fallen into the "I wish it weren't this way" trap. I used to be right there with you. If you actually click through the link I referenced, that wasn't a paid software statistic.

No, is a mantra, bare with me lol...There is the small lies, there is the big lies, then there is the statistics...

Sponsor me good(don't have to pay directly), and i can arrange you a statistics in any line you like.

How many Linux systems are behind good NAT firewalls ? .. how many Joes do double boot ?... how many downloads serve to install in a plurality of machines ?

No Linux is very far from the top preference on the traditional Desktop systems... i can easily agree ~10%, and this without a clear view into many countries where Linux is much more popular, like Brazil and China. Perhaps ~1% ( even so i doubt) is in the USA, but the USA stopped from being the reference for many innovations now...

Now if you count the client side including systems from smartphones to tablet (where Android is the top reference)... up to the desktop... then those 10% might get a several times (x) boost...

In any case what is the importance of being a leader or not ?

Those numbers mean nothing related to quality and usefulness... and Linux has "terrible VERY powerful enemies", ppl just can't forget that, there will always be a very steep up-hill battle.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 11:19 UTC (Wed) by simosx (subscriber, #24338) [Link]

It might be %1 overall, but in countries that matter, the percentage is different.

See

1. http://gs.statcounter.com/
for the StatCounter OS statistics per country. Note specifically the statistics for Germany, France, Spain and Finland. (1% worldwide)

2. http://clicky.com/marketshare/global/operating-systems/
for the Clicky OS statistics per country (1.3% worldwide)

As far as I understand, countries like China and India do not do well with free software, so the make the global stats dip greatly.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 11:56 UTC (Wed) by HelloWorld (guest, #56129) [Link]

Oh, so it's 1.45 instead of 1.3% in, say, France. That sure makes one hell of a difference...

And frankly, there are reasons why the Linux desktop hasn't gone anywhere yet. The same mistakes are repeated over and over again: NIH, bikeshedding and bickering about all kinds of pettinesses. The crap that Ubuntu is pulling off right now is a perfect example of that. I haven't given up on the Linux desktop yet, because there are people who are aware of this and try to fight it, like Poettering who tries to unify the basic system infrastructure with systemd, or Adam Jackson with his famous "Linux is not about choice" email. But I'm not holding by breath either with people like Mark Shuttleworth actively driving wedges between people and communities.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 12:05 UTC (Wed) by Otus (guest, #67685) [Link]

> 2. http://clicky.com/marketshare/global/operating-systems/
> for the Clicky OS statistics per country (1.3% worldwide)
>
> As far as I understand, countries like China and India do not do well with free software, so the make the global stats dip greatly.

China has almost 100% Windows, but India has relatively high Linux share.

Interesting: look at the share for Brazil or India and you see how during the work week some people use Linux who use Windows in the weekends. Compare with Germany and you see people use Apple during work days instead.

A bit lopsided

Posted Mar 4, 2013 23:26 UTC (Mon) by man_ls (subscriber, #15091) [Link]

Why group Red Hat with "typical Linux distro", and not Ubuntu? I would say there are more Ubuntu derivatives than Red Hat derivatives out there.

Anyway, it is nice to have alternatives, especially if they have learned from the predecessors' mistakes, and if Mir is compatible with Wayland.

A bit lopsided

Posted Mar 5, 2013 0:20 UTC (Tue) by thebluesgnr (guest, #37963) [Link]

Red Hat uses and openly contributes to the entire open source stack so they fit well to the point DiegoCG was making. That's the distinction from where Ubuntu is headed, where they replace major components with NIH versions developed behind closed doors.

A bit lopsided

Posted Mar 5, 2013 12:25 UTC (Tue) by chithanh (guest, #52801) [Link]

Indeed NIH is something you can't accuse Red Hat of. But they have demonstrated that they will do stuff behind closed doors if it makes sense from a business perspective. Most recently when they made RHEL kernel commit history non-public in order to gain advantages over Oracle.

Bad NIH, good NIH

Posted Mar 5, 2013 13:53 UTC (Tue) by man_ls (subscriber, #15091) [Link]

I wouldn't say that Red Hat is immune to NIH. I will give a couple of recent examples.

Systemd developers have repeatedly stated that they don't want to contribute to Upstart because of its fundamental limitations. Having used Upstart for a while it starts to make sense. However we have seen a kernel developed for i386 cheap processors scale to supercomputers and to phones; from mainframes to $25 boards. I wonder, was it really so difficult to retrofit a good design on top of Upstart? Was it impossible to evolve the design, convincing Upstart maintainers? If so, it looks a little bit like Not Invented Here to me. Or was it really a case of Canonical holding the copyrights? If the collaboration model was at fault (and Canonical agreement sucks, frankly), isn't that a political reason?

Journald did something similar with logs: syslog was apparently willing to accommodate any necessary changes, but instead they chose to go with their own solution. We needed another log system in Linux land like a third or fourth leg. Yes, it is often easier and faster to roll your own system; but that is exactly what NIH is about.

Playing devil's advocate a little longer and in counter-fashion: NIH is not necessarily bad. I often roll my own code instead of going with the established for at least two reasons: knowledge and control. (Fun also plays a role, I have to admit.) It is more forgivable for private projects than for public operating systems, though.

Bad NIH, good NIH

Posted Mar 5, 2013 16:07 UTC (Tue) by quintesse (subscriber, #14569) [Link]

Systemd and Upstart are completely different designs with a completely different philosophy behind them, trying to "evolve" that just doesn't make any sense whatsoever, especially when you're talking about a technology like Upstart that was very young as well. Now, if you take X then it makes sense to try to improve it... unless your new design is radically different and then you make Wayland, Surface Flinger or Mir ;)

Bad NIH, good NIH

Posted Mar 5, 2013 19:08 UTC (Tue) by man_ls (subscriber, #15091) [Link]

Let us see: both are init systems that have a configuration file to run tasks. The completely different design is, I gather, socket activation versus event-based; but it looks rather like just an implementation detail from the outside. Why not support both schemes? Is there a fundamental roadblock in init systems that prevent them from supporting different activation schemes, so that users can choose which to use when?

But anyway this discussion has been rehashed a thousand times by now. The transition from X sounds much more radical: it changes where things are done, and also X is so old that I can believe it has too much cruft to clean up.

Bad NIH, good NIH

Posted Mar 5, 2013 19:56 UTC (Tue) by quintesse (subscriber, #14569) [Link]

> X is so old that I can believe it has too much cruft to clean up.

But there is exactly where it still makes sense, it is used in SO many places that until recently there was really no alternative. So cleaning up still makes sense, and where necessary that has been done over years of hard work.

But there comes a time where it might just not do anymore and some radical new idea is needed, so you get something like Wayland. If you would have redesigned X to be what Wayland is now there just would be no reason to keep calling it X (except for PR purposes, see Atari or Commodore).

> but it looks rather like just an implementation detail from the outside

So you could say the same for X, Windows and Mac Quartz, they all seemingly handle showing and moving windows, the rest is just implementation details.

I just don't get people's urge for "making one system", what would that gain you? Better yet, examples abound where diversity results in faster progress and better results.

Now, I see much more evidence that the people starting on Mir should have talked with the Wayland developers before running of to make something of their own. But time will tell I guess.

Bad NIH, good NIH

Posted Mar 5, 2013 20:34 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Diversity in applications is great, that's competition, diversity in low level infrastructure is just a maintenance and compatibility burden, sometimes necessary but often it's just wheel re-invention.

Bad NIH, good NIH

Posted Mar 5, 2013 20:54 UTC (Tue) by quintesse (subscriber, #14569) [Link]

That's exactly why you don't want a system that tries to combine both Upstart's and systemd's way of working. Diversity is in the way the good gets separated from the bad. And without that diversity there would be no progress.

Bad NIH, good NIH

Posted Mar 5, 2013 21:14 UTC (Tue) by mmarq (guest, #2332) [Link]

Yes many things can be said, and both are true. Diversity is necessary, well established standards also...

I think the wisdom would be to try to combine the two.

As example, what misses now, who have 3 can have 4, is a new X project that combines some of the possible best features of all, yet maintains the X standard but is flexible enough to allow some extensibility =diversity.

I trace parallels with compiz/fusion and the all WM developments. It was nice to be able to change WMs, it will be nice to keep that possibility, yet all could function in the same system, and no need to "force" changes to the apps -> you have diversity, and you have a standard.

Bad NIH, good NIH

Posted Mar 6, 2013 23:26 UTC (Wed) by nix (subscriber, #2304) [Link]

maintains the X standard but is flexible enough to allow some extensibility
Er, you do know that X has had support for protocol extensions for about a quarter of a century now, right? Eventually it's just not enough. X has had an astonishing record of backward compatibility, but you can't drag an old horse forever, alas. Most of X is now unused by most applications, and there are things extensions just can't do :(

Bad NIH, good NIH

Posted Mar 7, 2013 14:51 UTC (Thu) by mmarq (guest, #2332) [Link]

Think about Linux kernel...

Perhaps is not a good idea to drag an hold worse forever lol (not as old as X but pretty old). If only it was as easy to fork or start allover as X...

That is another cliche, there is no piece of software that can't be improved... only if wisdom "emperator", then things could be different, and anyone is "free" to fork the linux kernel or start a new one if they wish, only what is more prevalent at this low levels is quality and usefulness, *old* means nothing...

Bad NIH, good NIH

Posted Mar 8, 2013 14:55 UTC (Fri) by nix (subscriber, #2304) [Link]

The problem is not that the software is old: software, indeed, does not rot. The problem is that the core protocol is old, imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips) and 90% of it (probably more actually) is unused by everything you run, unless you really like running old Xaw-based paint programs. The protocol was very well-designed for its time, but its time was when PostScript was new: the designers couldn't foresee what was coming in graphics card design twenty years down the road. That sort of thing cannot be fixed without breaking protocol compatibility, by which point you're talking breaking every X app anyway. So why not try something quite different?

(I still think that a display protocol was a very important innovation and that making drawing direct to the framebuffer the core operation is a huge step back. But, hey, I'm not writing the code.)

Old software

Posted Mar 8, 2013 15:13 UTC (Fri) by man_ls (subscriber, #15091) [Link]

Software ages like any other human construct: style rules change, coding standards improve (and sometimes regress), libraries become unsupported and stop working on modern systems. Anyone who has tried to build software that is 20 years old can attest to it -- we are talking about the days when Linux was not yet two years old.

That is of course a metaphor: while the code itself does not change with time, the world around it does. So in effect old code is as hard to use as other old tools.

Old software

Posted Mar 8, 2013 19:04 UTC (Fri) by hummassa (subscriber, #307) [Link]

> Software ages like any other human construct: style rules change, coding standards improve (and sometimes regress), libraries become unsupported and stop working on modern systems. Anyone who has tried to build software that is 20 years old can attest to it -- we are talking about the days when Linux was not yet two years old.

> That is of course a metaphor: while the code itself does not change with time, the world around it does. So in effect old code is as hard to use as other old tools.

Kudos. Two EPIC paragraphs describing bitrot. I will quote you for ever and ever more, or at least until your quote is no longer pertinent. :-D

Bad NIH, good NIH

Posted Mar 8, 2013 19:24 UTC (Fri) by HelloWorld (guest, #56129) [Link]

I still think that a display protocol was a very important innovation and that making drawing direct to the framebuffer the core operation is a huge step back.
I don't see why. Afaics, there were essentially two reasons for putting the rendering code in the X server:
  1. to stop a client from messing with another client's pixmaps etc.
  2. to clip window contents
  3. to share the rendering code between multiple clients to save memory
None of these apply any longer. The kernel does graphics memory management, everything is composited and we have shared libraries (those didn't exist back when X was conceived). Otoh, client-side rendering is faster because it avoids the protocol overhead, it's more flexible because the server doesn't have to be changed in order to provide new drawing operations, and if you really want a remove rendering protocol, it can be done on top of wayland. I think that not putting rendering in the protocol is the right thing to do.

Bad NIH, good NIH

Posted Mar 9, 2013 0:21 UTC (Sat) by Serge (guest, #84957) [Link]

> Afaics, there were essentially two reasons for putting the rendering code in the X server

X server supports both client-side and server-side rendering.

But Xorg is much more than just rendering.
1. Xorg == standards. Stable standards supported everywhere, literally (Windows, MaxOS, I've heard even Android has some java-based X11 implementation, maybe not as good as Xorg, but still).
2. Xorg == hardware support. It works everywhere, including small mobile/ebook devices and large multi-monitor systems.
3. Xorg == software support. During its long lifetime it got all the nifty tools you can think about (xrandr, xinput2, xautomation, xdotool, xbindkeys, xvkbd, xnest, x2x, x11vnc, etc).
4. Xorg == infinite personalisation. You can choose any window manager or desktop environment you like. Or you can combine them. Thousands of themes are waiting for you.
5. Xorg == development support. Every toolkit supports Xorg.
6. Xorg == stability. You can release your closed-source binary game today and you can be sure, that it will still work for the next 10 years.

(#6 is not that strong now, Wayland fans talk a lot about Xorg being bad, and that gives some bad points to Xorg and commercial Linux development, sigh...)

At the same time X11 was never rotten. On the contrary, it was always among the first to innovate. First remote graphical terminals, first desktops with multiple workspaces, multi-monitor systems, first multiseats, first 3D-desktop, first multi-touch (MPX, yeah, it was done before iPhone :)) — most (if not all) of these things were first done under X-server.

> Otoh, client-side rendering is faster because it avoids the protocol overhead

You should probably like DirectFB a lot. It's direct, client-side, and has no server, so it completely avoids any overhead possible. :)

Bad NIH, good NIH

Posted Mar 9, 2013 18:45 UTC (Sat) by HelloWorld (guest, #56129) [Link]

  1. Nobody needs or wants X servers for Windows, Mac OS or Android. What people want is remote applications, and they'll get those with Wayland via a VNC-like protocol. Which, by the way, works way better than X for today's applications.
  2. It doesn't run everywhere. Android doesn't use it, Firefox OS doesn't, Tizen doesn't, Mac OS X and iOS don't, nobody right in their mind uses it except as a compatibility crutch.
  3. That will come for Wayland as well, it's just a matter of time.
  4. You can run any desktop environment on Wayland too, and you can combine any Wayland compositor with any desktop, provided it offers the needed functionality (which obviously applies on X11 as well)
  5. The toolkits that matter will soon support Wayland (or already do)
  6. The Wayland protocol is stable and X applications are supported via XWayland.
What you don't seem to grok is that Wayland is a long-term infrastructure project to get a future-proof graphics architecture for Linux. And contrary to what you say, X11 is not that. That's why many of the X.org developers themselves (including Keith Packard, Kristian Høgsberg, Daniel Stone) support Wayland. Now please don't try to tell me that you know better than them what a future-proof graphics stack looks like...

Bad NIH, good NIH

Posted Mar 9, 2013 21:58 UTC (Sat) by Serge (guest, #84957) [Link]

> 1. Nobody needs or wants X servers for Windows, Mac OS or Android.

Have you heard about windows program called "putty"? You can ssh with it to remote server with no video adapter and run X11 apps over it. How? Using X server for Windows. You can do similar things with OS X, it has its own X server. There're also X11 implementations for Android.

Yes, people need and want X server for Windows, Mac OS and Android. And they have it.

> What people want is remote applications, and they'll get those with Wayland via a VNC-like protocol. Which, by the way, works way better than X for today's applications.

You don't need Wayland to use VNC, you know that? Also, Wayland is about direct client-side hardware use, you'll get some problems when you try using it on a server with no graphical hardware.

So, you have Xorg (works always, supports X11 forwarding, VNC, xpra, NX), and you have Wayland (works sometimes, theoretically supports VNC). I don't see a reason to choose Wayland in this case, do you?

> 2. It doesn't run everywhere. Android doesn't use it, Firefox OS doesn't, Tizen doesn't, Mac OS X and iOS don't, nobody right in their mind uses it except as a compatibility crutch.

It does run everywhere. It can be run on Android (and it was done since first androids), there're X11 implementations for iOS, and it's included in Mac OS X. Also it's used by Maemo/Meego.

> 3. That will come for Wayland as well, it's just a matter of time.

Wayland design makes me think it won't. What makes you think it will? Let's take an example: directfb. It's well known, was created 12 years ago (!) and still does not have those good tools.

> 4. You can run any desktop environment on Wayland too, and you can combine any Wayland compositor with any desktop, provided it offers the needed functionality (which obviously applies on X11 as well)

Theories again? Please, run Compiz on Wayland. At least run IceWM on Wayland. Have you ever used Wayland/Weston yourself?

> 5. The toolkits that matter will soon support Wayland (or already do)

I guess you have not seen how it looks. Try it. Anyway, all toolkits already support X11. Name one reason why they should bother supporting Wayland?

> 6. The Wayland protocol is stable

You obviously have no idea what's "stable". "Stable" means that I can release program today and it will continue to work. "Stable" means good for long term commercial use.

X11 is stable. It always was. Now Wayland has v1 protocol for a few months and you can't be sure that tomorrow there won't be Wayland v2 with completely different protocol. Bear in mind that currently you can't use Wayland protocol without compositor extensions. And a few existing compositors have them different. Wayland is unstable itself and it's trying to shake Xorg by constantly attacking it ("it can't be worse than X11"). This is bad for the entire Linux community.

> and X applications are supported via XWayland.

You haven't ever used it, have you? Try using RebeccaBlackOS LiveCD. When you notice that your X11 programs don't start any more try debugging that.

> That's why many of the X.org developers themselves (including Keith Packard, Kristian Høgsberg, Daniel Stone) support Wayland. Now please don't try to tell me that you know better than them what a future-proof graphics stack looks like...

Oh, that's the biggest mystery for me. Initially I thought that Wayland was just a proof-of-concept, like "Look, Linux has such a powerful graphical stack that I can easily create a simple window system". Then I thought that Wayland could be a test of new ideas before including them into Xorg. But Wayland is still promoted as being better than Xorg, and I don't see who it's supposed to be good for.

It just was not possible to do something like Wayland before. So I understand that it's fun for smart hackers to dig though something new, something that have never been done. But for now Wayland looks like a personal toy for its developers, that brings no benefits to anybody else.

Bad NIH, good NIH

Posted Mar 10, 2013 3:07 UTC (Sun) by HelloWorld (guest, #56129) [Link]

People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement. If you still didn't understand, it's because you don't want to, and I won't waste my time trying to convince you otherwise. Fortunately, the world keeps moving despite stick-in-the-muds like you.

Bad NIH, good NIH

Posted Mar 10, 2013 15:37 UTC (Sun) by hummassa (subscriber, #307) [Link]

> People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement.

No. No one has explained what is wrong with X11 or with its implementations.

More specifically, no one has explained why any possible flaws are not fixable.

About the worth of working on a replacement, to each its own, and no one can force others to work (or to pay someone to work) on something.

Bad NIH, good NIH

Posted Mar 10, 2013 18:25 UTC (Sun) by patrick_g (subscriber, #44470) [Link]

> No. No one has explained what is wrong with X11 or with its implementations.

Please look at this video : http://www.youtube.com/watch?v=RIctzAQOe44

Bad NIH, good NIH

Posted Mar 11, 2013 4:58 UTC (Mon) by Serge (guest, #84957) [Link]

>> No. No one has explained what is wrong with X11 or with its implementations.

> Please look at this video : http://www.youtube.com/watch?v=RIctzAQOe44

Presentation that starts with "Noone has any idea". Saying things like "I'm the smart guy and everybody else is stupid", even if you're joking or have reasons for that, still looks... not very polite. But let's get back to the X11 talks.

There goes an interesting story of XFree86/Xorg evolution, how it looked 20 years ago and how few features it had back then, and how many features it has now, how it adopted all the modern hardware, how older extensions were replaced by their newer versions etc.

But where are the problems? Gedit startup is too slow? Then fix gedit! The rest is like "X is doing that bad, so Wayland can't do that at all" or "X does it that way, we don't like that, so Wayland does it this way" or usually it's like "Wayland is going to do it better" because it's not implemented yet or the implementation is very basic/buggy. That's all! No problems of X11 protocol or even Xorg there.

What have I missed?

BTW, it was kind of fun listening to "X isn't network-transparent any more" while running some GUI tools over ssh -Y.

Bad NIH, good NIH

Posted Mar 11, 2013 9:30 UTC (Mon) by gioele (subscriber, #61675) [Link]

> BTW, it was kind of fun listening to "X isn't network-transparent any more" while running some GUI tools over ssh -Y.

The presenter explicitly said that "X is network-capable, not network-transparent". It means that you can run X applications over the network, but the software has to handle it as a special case now, given that the current normality is the use of shared memory buffers.

Bad NIH, good NIH

Posted Mar 11, 2013 4:33 UTC (Mon) by Serge (guest, #84957) [Link]

> People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement.

No! People have dozens of times explained why they CAN work on a replacement, not why it's worth working on it. Usually all those explanations boil down to "X11 has too many features" and "Wayland is not too bad". But nobody have ever explained who's going to win from it. I would be glad if you provide me a link to such explanation.

Wayland/Weston is like a HelloWorld-program. It's useless but IN THEORY you can extend it to do whatever you want... Hm... HelloWorld is the best graphical manager! It's fast and simple! You can do everything else client-side! Sounds familiar? :-)

Bad NIH, good NIH

Posted Mar 10, 2013 10:44 UTC (Sun) by nix (subscriber, #2304) [Link]

Nobody needs or wants X servers for Windows, Mac OS or Android. What people want is remote applications, and they'll get those with Wayland via a VNC-like protocol. Which, by the way, works way better than X for today's applications
That's just as wrong as it was last time you said it. Even the Wayland developers say that to accelerate things like scrolling screenfuls of text (a common case) will require toolkit-level remoting that is aware of things like glyphs rather than just considering the framebuffer to be a big image.

Bad NIH, good NIH

Posted Mar 11, 2013 12:27 UTC (Mon) by dgm (subscriber, #49227) [Link]

There are many things that can run smoother over the network if done more cleverly than just copying frames around, but:
1. Most people do not need to work over the network, specially those that have the greatest need for performance: games, video playback and such.
2. Copying frames is by far the simplest solution.
3. Being able to copy frames doesn't mean you cannot _add_ a cleverer solution.

So, a local only display covers maybe 95% of user needs, and with dumb frame copying you may be getting that up to 99% (statistics right out of my hat, but still). The remaining 1% _can_ be worked out, or just keep using X11.

The alternative is forcing network "transparency" down everybody's throat, even if they do not want or need it.

It's not really that nobody needs X11. I do, for instance. But I'm not so stupid to not realize that most people don't. And forcing them to play a price for something I need doesn't sound like a great idea.

Bad NIH, good NIH

Posted Mar 11, 2013 15:27 UTC (Mon) by nix (subscriber, #2304) [Link]

I find it hard to believe that you think that playing video rendered over the network (without using something like Youtube) is a more common case than rendering scrolling text buffers over the network. The latter is about 99% of what people use X remotely *for*.

Bad NIH, good NIH

Posted Mar 12, 2013 12:21 UTC (Tue) by dgm (subscriber, #49227) [Link]

> rendering scrolling text buffers over the network [...] is about 99% of what people use X remotely *for*.

Probably, but what percentage of people do use X remotely, actually?

Does it make sense to design the solution around that use case? Or would it be better to design things around the *common* use case (computing and display on the same node), specially when alternative solutions do exist?

Bad NIH, good NIH

Posted Mar 13, 2013 21:41 UTC (Wed) by nix (subscriber, #2304) [Link]

I can't tell you how common it is, or isn't. I don't see how you could claim that you know that non-remote use is so common that the remote case should be disregarded, either.

Bad NIH, good NIH

Posted Mar 13, 2013 20:14 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> That's just as wrong as it was last time you said it.
Well, it's more or less what Daniel Stone said in his recent talk about X and Wayland.

> Even the Wayland developers say that to accelerate things like scrolling screenfuls of text (a common case) will require toolkit-level remoting that is aware of things like glyphs rather than just considering the framebuffer to be a big image.
Sure, it's not perfect, and it's probably possible to obtain better performance with a protocol that caters to the needs of modern applications (i. e. something other than X). But is it really worth the effort? Supporting a higher-level drawing protocol in the toolkits is probably somewhat harder than a VNC-like approach. And if you want really good performance, you actually want more than just drawing. You want something like stored procedures in SQL: the possibility to execute code in a confined environment on the server. A toolkit would then be able to upload a procedure to, say draw a button, and the next time it wants to draw a button, it merely has to call that procedure. Adobe actually tried something like that with Display Postscript. And perhaps you also want a server-side scene graph given that today's toolkits like Qt5 and Clutter use scene graphs. It's probably quite hard to retrofit current toolkits to make good use of such facilities, and you may well need toolkit-specific functionality to do a good job.
And let's not forget that remote applications (VNC/X11/RDP etc.) are increasingly being displaced by web applications. So I think that the best thing to do is to settle for something that's Good Enough, and a VNC-like protocol may be just that.

Bad NIH, good NIH

Posted Mar 13, 2013 21:46 UTC (Wed) by nix (subscriber, #2304) [Link]

So... your 'argument' is that VNC-like stuff is 'good enough', even though it is clearly much worse than glyph-by-glyph stuff for the vast majority of windows that anyone ever opens using any windowing system -- those windows filled with text? (Discounting, for these purposes, games and video playback, which clearly should be local or use a video compression algorithm of some sort.)

Almost every use case (save only the GIMP, Inkscape and their ilk) can be covered by video compression or glyph-by-glyph stuff. VNC is bad for *both* of these. As far as I can tell, VNC is far suboptimal for *everything*.

Bad NIH, good NIH

Posted Mar 13, 2013 22:51 UTC (Wed) by HelloWorld (guest, #56129) [Link]

Of course it's suboptimal. It's also easy to implement and doesn't need application or toolkit changes and still works better than X (which is unusable over high-latency links). Again, the question isn't whether it's possible to do better but whether someone can be bothered to invest a significant amount of work in a better solution. Given that remote applications == web applications for 95% of all users, I don't think anybody will.

Bad NIH, good NIH

Posted Mar 13, 2013 23:43 UTC (Wed) by nix (subscriber, #2304) [Link]

It doesn't work better than X over even low-latency links the moment you have to scroll. Scrolling a windowful of text using normal VNC is laggy even over a quiet gigabit ethernet link: over anything slower it is hopeless.

Bad NIH, good NIH

Posted Mar 14, 2013 3:10 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

you are so focused on what is the 'norm' today that you are completely blind to the future.

remote display uses that are going to become very common in the near future (especially when connected to mobile devices that do not have the CPU power to render locally, then ship VNC style full-frame images out to the remote display)

1. Google Glasses style head mounted displays.

Google is far from the only company working on this sort of thing. Many of these uses are text or simple geometric objects overlayed on the live video, shipping the video to the phone, doing the overlay, and shipping the result back out is wasting a lot of bandwidth, and battery. Not Going To Happen (at least not for very long). What's going to happen is the video will get shipped to the phone (although not necessarily in full resolution), the phone will craft the overlay, and the overlay will be transmitted back to the headpiece to be combined there with the direct feed from the camera.

2. remote displays (frequently wireless) from mobile devices to large, high-res displays.

Haven't you seen any of the many TV shows or movies recently that show people pulling something up on a phone/tablet and then 'flicking' the window over to the full display? What makes you so sure that this is not going to happen?

There are probably a lot of other examples that people could point out, but just because you don't currently use remote displays doesn't mean that they aren't going to be very popular very soon.

Bad NIH, good NIH

Posted Mar 8, 2013 23:58 UTC (Fri) by Serge (guest, #84957) [Link]

I assume you're talking about Xorg.

> The problem is that the core protocol is old

That's not a problem. That's an advantage, which says that the protocol has such a good design that being old still works and supports all the modern features.

> imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips) and 90% of it

That may be a problem. Let's check that:

$ time xterm -e /bin/true
real 0m0.041s
user 0m0.029s
sys 0m0.006s

Nope, that's not a problem too. :) Startup is fast enough.

If some programs start faster, while others start slower, then those programs are to blame, not Xorg, right?

Bad NIH, good NIH

Posted Mar 9, 2013 4:41 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

>That's not a problem. That's an advantage, which says that the protocol has such a good design that being old still works and supports all the modern features.
No, it doesn't.

For example, there's a long-standing problem with language switching by alt-shift keypress (not possible due to X quirks with modifier keys processing).

Then there's the whole full-screen rendering fiasco. There's no good way for an app to switch to a full screen and make sure the previous resolution is restored when the app exits.

Then there's a problem with OpenGL-based compositors - they don't always synchronize rendering correctly.

Etc.

Bad NIH, good NIH

Posted Mar 9, 2013 19:50 UTC (Sat) by Serge (guest, #84957) [Link]

>> That's not a problem. That's an advantage, which says that the protocol has such a good design that being old still works and supports all the modern features.

> No, it doesn't.

> For example, there's a long-standing problem with language switching by alt-shift keypress (not possible due to X quirks with modifier keys processing).

Bad example.
First, I'm not sure what's the problem you're talking about, can you explain in details?
Next, what a strange choice for the keyboard layout hotkey, there're plenty of keys on a keyboard (CapsLock, Menu...) that are less used and easier to hit.
And finally this has nothing to do with the protocol, in worst case it would be a bug in xkb (or whatever you use for layout switching), not X11 protocol.

> Then there's the whole full-screen rendering fiasco. There's no good way for an app to switch to a full screen and make sure the previous resolution is restored when the app exits.

First, it's a bad idea anyway, because if I changed resolution with `xrandr` I don't want it to change back when `xrandr` exits. Next, Xorg is able to "restore" whatever resolution you configure using Ctrl+Alt+GrayPlus and Ctrl+Alt+GrayMinus since forever. Also Xorg allows you to bind `xrandr` call with your favourite resolution to any hotkey. And finally, it STILL has nothing to do with X11 protocol.

> Then there's a problem with OpenGL-based compositors - they don't always synchronize rendering correctly.

That's not a bug, but optional feature. You can turn vsync off and see how many FPS you get. Good for benchmarks and regression testing. And this is still about compositing WMs, but it's not a bug of Xorg or X11 protocol.

No protocol problems found. :)

Bad NIH, good NIH

Posted Mar 9, 2013 20:24 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

>First, I'm not sure what's the problem you're talking about, can you explain in details?
Simple. There is no way for language switcher to use only modifier keys. X protocol itself doesn't support it and workarounds are too complicated (like getting grab on all input and re-inserting messages back).

>Next, what a strange choice for the keyboard layout hotkey, there're plenty of keys on a keyboard (CapsLock, Menu...) that are less used and easier to hit.
That's the default layout switch combination in Windows, so a lot of people have it hard-wired into their brains. I moved to CapsLock, but it definitely was not comfortable.

>First, it's a bad idea anyway, because if I changed resolution with `xrandr` I don't want it to change back when `xrandr` exits.
Duh. I think it's obvious that there should be a special protocol for resolution changing apps.

>Next, Xorg is able to "restore" whatever resolution you configure using Ctrl+Alt+GrayPlus and Ctrl+Alt+GrayMinus since forever.
And they do not always work. Besides, I don't _have_ a gray minus on my keyboard.

...and here we have a wonderful example of X's "robustness"...

Bad NIH, good NIH

Posted Mar 11, 2013 3:03 UTC (Mon) by Serge (guest, #84957) [Link]

> There is no way for language switcher to use only modifier keys. X protocol itself doesn't support it and workarounds are too complicated (like getting grab on all input and re-inserting messages back).

Just tried. I've set up xkb to switch layout using my Ctrl key. Looks working. I also configured xbindkeys to run some command when I press Shift. Looks working too. Both X11 protocol and Xorg itself allow you to use modifier keys to switch language, or write a custom switcher to do that.

> Duh. I think it's obvious that there should be a special protocol for resolution changing apps.

Ehm... Two protocols, one for games, changing resolution, and another for tools, changing resolution? And how are you going to stop games from using protocol for tools? Create another third protocol to authorize them? ;)

In Xorg there're much simpler solutions to that. I already told you about Ctrl+Alt+Plus/Minus and suggested you to bind `xrandr` call to some hotkey. Alternatively you can create a simple "restorer.sh" script:

#!/bin/sh
"$@"
xrandr --your --best --options --here

And run the game like: `restorer.sh thegame`

> And they do not always work. Besides, I don't _have_ a gray minus on my keyboard.

You don't have Numpad? Weird keyboard... Well, you can still get that key! You can remap any of your keys using `xmodmap`.

> ...and here we have a wonderful example of X's "robustness"...

Yeah. Xorg is great, it allows you use whatever use-case you want. It's much better than Wayland, where features like that are impossible.

Bad NIH, good NIH

Posted Mar 11, 2013 4:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

>Just tried. I've set up xkb to switch layout using my Ctrl key. Looks working.
That's because ctrl key is not a modifier key, try that with alt-shift.

It's actually possible to use alt-shift for switching, but not easily. As far as I remember, that involves editing xkb bindings to remap this combination to another.

Decidedly not an example of X's robustness.

>Ehm... Two protocols, one for games, changing resolution, and another for tools, changing resolution?
Yep. And it's actually already done!
http://www.phoronix.com/scan.php?page=news_item&px=MT...

>And how are you going to stop games from using protocol for tools? Create another third protocol to authorize them? ;)
Yep. Just making wlrandr privileged is enough.

Changing resolution is a privileged operation that shouldn't be exposed to games. In fact, games just need a way to hint the composer that they want to occupy the full screen (maybe with a specific screen resolution). For example, Mac OS X in these cases allocates a separate _desktop_ and switches to it, leaving other desktops untouched.

>In Xorg there're much simpler solutions to that. I already told you about Ctrl+Alt+Plus/Minus and suggested you to bind `xrandr` call to some hotkey. Alternatively you can create a simple "restorer.sh" script
I don't care. Anything that doesn't work out-of-box is unacceptable.

Sorry, but using shell scripts to restore resolution belongs in early 90-s.

> You don't have Numpad? Weird keyboard...
That's just Mac OS X laptop keyboard.

>Well, you can still get that key! You can remap any of your keys using `xmodmap`.
Don't care.

Bad NIH, good NIH

Posted Mar 11, 2013 5:46 UTC (Mon) by Serge (guest, #84957) [Link]

> That's because ctrl key is not a modifier key

...

> It's actually possible to use alt-shift for switching, but not easily. As far as I remember, that involves editing xkb bindings to remap this combination to another.

What? "alt_shift_toggle" is among standard xkb options. And most DEs allow you to choose it. What DE are you using?

> Yep. And it's actually already done!

Reimplementing (theoretically) one more feature from Xorg in Weston does not make Weston better than Xorg. And it's still impossible to do that using Wayland protocol.

> Yep. Just making wlrandr privileged is enough.

That would also make xrandr-like tools impossible, so we get back to the original problem. Or what do you call "privileged"?

> For example, Mac OS X in these cases allocates a separate _desktop_ and switches to it, leaving other desktops untouched.

They took that idea from X server. :-) Among the first links in google:
https://wiki.archlinux.org/index.php/Gaming#Starting_game...

> Sorry, but using shell scripts to restore resolution belongs in early 90-s.

That was just one option among many. Xorg gives you the choice. You don't have even that option in Wayland.

> I don't care. Anything that doesn't work out-of-box is unacceptable.

Sorry, but restoring the resolution when user have not asked for is stupid. What if user have intentionally changed the resolution? ;-)

The entire idea of changing the resolution back when program exits is actually pointless. It solves nothing. Program can just change resolution and freeze or go into background.

And this is not a problem of X11/Xorg anyway. X11 allows you to implement whatever solution you like.

Bad NIH, good NIH

Posted Mar 11, 2013 6:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> What? "alt_shift_toggle" is among standard xkb options. And most DEs allow you to choose it. What DE are you using?
KDE. Using xkb options results in some strange behavior. Also, hotkeys involving alt-shift are sometimes garbled (i.e. you press alt-shift-k and it results in switching keyboard layout and printing 'л'). I moved to CapsLock for layout switching eventually.

> Reimplementing (theoretically) one more feature from Xorg in Weston does not make Weston better than Xorg. And it's still impossible to do that using Wayland protocol.
So it's impossible even when I'm pointing to you that it IS already done? And using a Wayland protocol extension.

>They took that idea from X server.
No they didn't.

Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw).

> That was just one option among many. Xorg gives you the choice. You don't have even that option in Wayland.
I don't care about many options. I want a display stack that works consistently and predictably in most cases. I don't ever want to edit scripts or blindly type "ctrl-t xranrd ...." after a game crashes.

Wayland is so great because is designed from the start to BE RELIABLE in the modern world. That's why Wayland devs pay a lot of attention to details that you simply don't know about.

For example, X still has problem with subpixel rendering because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.

Then there's a whole question of synchronization. Wayland devs spent quite a lot of time discussing the whole double buffering mechanism, making it much more robust than in X (where buffer swap either stalls your pipeline or can happen at indeterminate time).

Bad NIH, good NIH

Posted Mar 11, 2013 15:15 UTC (Mon) by nye (guest, #51576) [Link]

>For example, X still has problem with subpixel rendering because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.

What happens - either in X or Wayland - if one window spans displays which are not in the same orientation?

This monitor setup is not a hypothetical scenario for me BTW.

(And as an aside, I still think subpixel font rendering is a totally stupid idea, in part because of this very issue which means that the font renderer needs to have precise knowledge about the specific output device at any time; that sounds to me a lot like 'unwarranted chumminess with the implementation'. Leave aside what happens if there are any display transformations in effect, or if you want to create screenshots, or...)

Bad NIH, good NIH

Posted Mar 11, 2013 15:20 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> What happens - either in X or Wayland - if one window spans displays which are not in the same orientation?
One kind of rendering would be used.

Wayland has no notion of displays, really. An application just gets a surface to paint on, which might or might not span several displays. In case of multi-display surface Wayland can use 'unknown' subpixel ordering.

> And as an aside, I still think subpixel font rendering is a totally stupid idea, in part because of this very issue which means that the font renderer needs to have precise knowledge about the specific output device at any time
Uhm. It has this knowledge in 99% of cases. And personally I prefer occasionally looking at blurred screenshots rather than looking at blurred text _all_ the time.

Bad NIH, good NIH

Posted Mar 12, 2013 13:31 UTC (Tue) by nye (guest, #51576) [Link]

>In case of multi-display surface Wayland can use 'unknown' subpixel ordering.

Do you know if commonly available font renderers will automatically disable subpixel rendering in the case that they don't know the order of the subpixels?

(Not that there's any particular reason you should know, bu this is the first time I've even seen anyone bring up this issue in Wayland discussion which kind of implies you've at least thought about it more than most.)

>Uhm. It has this knowledge in 99% of cases.

But not in X, you previously said?

>And personally I prefer occasionally looking at blurred screenshots rather than looking at blurred text _all_ the time.

I'm not quite clear on that - subpixel rendering is an attempt to make text closer to its theoretically correct shape in exchange for making it less sharp, so I can't see how it could possibly make text *less* blurred than without it.

The entire theoretical basis of subpixel rendering is flawed because it relies on the fact that the colour perception of the eye is less accurate than its ability to discern the intensity. To rephrase that: your eye can discern the improved shape while not noticing the colour change.

This is true to an extent, but in the centre of the eye the colour perception is good enough that in practice there's visible colour fringing in subpixel rendered text unless you either have a very high-dpi display, or you're sitting miles away. I know a lot of people don't mind that and find the trade-off worthwhile, but I most definitely am not among them.

Bad NIH, good NIH

Posted Mar 12, 2013 14:19 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> Do you know if commonly available font renderers will automatically disable subpixel rendering in the case that they don't know the order of the subpixels?
Right now? I don't think so, as there's no support for getting subpixel order in X.

But it shouldn't be complicated to add if there's a way to obtain surface subpixel layout information.

>But not in X, you previously said?
Correct.

>I'm not quite clear on that - subpixel rendering is an attempt to make text closer to its theoretically correct shape in exchange for making it less sharp, so I can't see how it could possibly make text *less* blurred than without it.
Subpixel rendering allows to draw better looking curves by taking into account the fact that physical pixels on the screen consist of discrete subpixels.

If you want to have completely 'sharp' fonts then you have to use 100% on/off pixels with the same intensity for all of their subpixels. So in this case subpixel information is irrelevant (unless you also want to do _colored_ text). But completely 'sharp' fonts also look too jagged and any attempts on smoothing that don't take subpixel ordering into account are going to result in a total mess.

I don't think that color fringing is a big problem for most people. Personally, all of my display devices are now at Retina resolution or close to it :)

Bad NIH, good NIH

Posted Mar 12, 2013 22:15 UTC (Tue) by Serge (guest, #84957) [Link]

> there's no support for getting subpixel order in X.

> Subpixel rendering allows to draw better looking curves by taking into account the fact that physical pixels on the screen consist of discrete subpixels.

Here you're wrong. Twice. Both X11 and Wayland provide that information. But the fun part: it is useless in Wayland. By design. Because in Wayland your surface could be rotated, stretched or somehow transformed, so that subpixel information is completely useless there. That's the Wayland protocol with its great "reliable" design.

Bad NIH, good NIH

Posted Mar 13, 2013 1:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

>Here you're wrong. Twice. Both X11 and Wayland provide that information.
Nope. X protocol knows nothing about subpixel order. Wayland does.

Xranrd in this case is a cop-out because it's not universally available.

>But the fun part: it is useless in Wayland. By design. Because in Wayland your surface could be rotated, stretched or somehow transformed, so that subpixel information is completely useless there.
Wayland exposes the surface orientation to applications (surprise!), while X doesn't. So applications can adapt their rendering settings if they can.

And of course, there are compositing managers in X that can mutilate the image in various ways.

Bad NIH, good NIH

Posted Mar 14, 2013 5:38 UTC (Thu) by Serge (guest, #84957) [Link]

> Nope. X protocol knows nothing about subpixel order. Wayland does.

Both X and Wayland request information from display. If that information is available there they can read it. Both. Or do you thing that Wayland is reading the mind of display creators, while Xorg can't do that? ;-)

> Xranrd in this case is a cop-out because it's not universally available.

Run `xrandr --verbose` and see "Subpixel" there. Now think, if xrandr gets information from X-server then X-server knows about subpixels, and X11 protocol is able to transfer that, right? Just read the protocol if you still don't believe me.

> Wayland exposes the surface orientation to applications (surprise!)

Indeed, it's a surprise, could you point me to that part of the Wayland protocol?

Bad NIH, good NIH

Posted Mar 14, 2013 5:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> Both X and Wayland request information from display. If that information is available there they can read it. Both. Or do you thing that Wayland is reading the mind of display creators, while Xorg can't do that? ;-)
Yep. Try that trick with Xrandr on legacy NVidia drivers (hint: it doesn't work).

Of course, your app can also read display EDIDs and parse them. Through the X protocol! But that kinda says that you should probably stop doing it.

> Run `xrandr --verbose` and see "Subpixel" there.
Lessee:

>cyberax@whale2:~$ xrandr --verbose
> SZ: Pixels Physical Refresh
>*0 1024 x 768 ( 260mm x 195mm ) *60
>Current rotation - normal
>Current reflection - none
>Rotations possible - normal
>Reflections possible - none
>Setting size to 0, rotation to normal
>Setting reflection on neither axis

Yeah, robust X protocol and all that....

> Indeed, it's a surprise, could you point me to that part of the Wayland protocol?
See "enum transform" and various related events and requests in http://cgit.freedesktop.org/wayland/wayland/tree/protocol... .

Bad NIH, good NIH

Posted Mar 14, 2013 8:35 UTC (Thu) by Serge (guest, #84957) [Link]

> cyberax@whale2:~$ xrandr --verbose
> SZ: Pixels Physical Refresh
> *0 1024 x 768 ( 260mm x 195mm ) *60
> ...
> Yeah, robust X protocol and all that....

Ha-ha, that was fun. Either you have done that on purpose, or you're testing that on a server back from 2005. :-) You can check `xdpyinfo -ext RENDER` too, it's supported since about 2003.

Xrandr is just a tool to request that information. Xdpyinfo is another one. X-server knows about subpixels and uses them for a loooong time.

> Try that trick with Xrandr on legacy NVidia drivers (hint: it doesn't work).

Why do you think it won't work? Hah! Try Wayland with legacy NVidia driver (hint: it doesn't work)!

> See "enum transform" and various related events and requests

Have you seen that yourself? It's just display rotation, similar to xrandr, not the surface rotation done by compositor.

Bad NIH, good NIH

Posted Mar 14, 2013 10:59 UTC (Thu) by nye (guest, #51576) [Link]

>You can check `xdpyinfo -ext RENDER` too, it's supported since about 2003.

"Screen 0 (sub-pixel order Unknown)"

i915 driver FWIW.

Bad NIH, good NIH

Posted Mar 14, 2013 17:31 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Can you provide a reference to X specification about subpixel order and its relationship with display transformation? And not for xrandr, please.

Bad NIH, good NIH

Posted Mar 15, 2013 7:15 UTC (Fri) by Serge (guest, #84957) [Link]

> Can you provide a reference to X specification about subpixel order and its relationship with display transformation? And not for xrandr, please.

http://www.x.org/releases/X11R6.9.0/doc/render-protocol.txt

Bad NIH, good NIH

Posted Mar 15, 2013 16:04 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

That's an extension, not the X protocol itself.

Bad NIH, good NIH

Posted Mar 16, 2013 0:15 UTC (Sat) by HelloWorld (guest, #56129) [Link]

Yes, that's true. It also doesn't matter at all.

Bad NIH, good NIH

Posted Mar 16, 2013 7:22 UTC (Sat) by Serge (guest, #84957) [Link]

> That's an extension, not the X protocol itself.

In X world extensions are part of the X11 protocol. For example this particular extension is part of X11R6.9, you can see that in its URL.

Bad NIH, good NIH

Posted Mar 16, 2013 9:08 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

But it's not a part of my X server.

Waaahhhh! X encourages fragmentation!

Bad NIH, good NIH

Posted Mar 12, 2013 21:21 UTC (Tue) by Serge (guest, #84957) [Link]

> Using xkb options results in some strange behavior. Also, hotkeys involving alt-shift are sometimes garbled (i.e. you press alt-shift-k and it results in switching keyboard layout and printing 'л').

Well, you switched layout and pressed some key... Anyway, that's not X11 problem, just a bug in xkb in worst case. And it's not solved by Wayland (you probably don't know but Wayland/Weston kind of uses xkb :)). But if that's a bug it should be fixed. Just curious, what is expected behavior for you?

> So it's impossible even when I'm pointing to you that it IS already done? And using a Wayland protocol extension.

What you linked is same as what you have with Xorg, and don't like so much. :) And that's a compositor extension (suggested, since it's not a part of weston), it's not part of Wayland protocol. Wayland compositor is like HelloWorld program, you can extend it to do everything you want. But it will be supported by that compositor only.

It is one of the greatest problem of the entire Wayland design — it encourages you to put every missing feature into unique compositor extension, so you eventually end up with lots of incompatible compositors, each having a small subset of all the Xorg abilities and standards.

> Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw).

Virtual desktops on X are up to the window manager. Nothing stops it from switching resolution when you switch desktop. So again, that's not X11 problem.

> I don't care about many options. I want a display stack that works consistently and predictably in most cases.

Then what stops you from configuring it the way you want? X allows you to do that, Wayland/Weston does not.

> Wayland is so great because is designed from the start to BE RELIABLE in the modern world.

It's not designed to "be reliable". :) Sorry. It basically designed to be "like X but better". On the other hand X is reliable, because it allows you to configure it the way you want, and it will work that way for years.

> For example, X still has problem with subpixel rendering

What problem?

> because there's no way for the client-side library to know the current display's orientation. That's why KDE and GNOME have separate manual settings for them, while Wayland carries this information in the native protocol.

So does X. Check `xrandr --verbose`. (Oops) :) KDE and GNOME just allow you to configure some Xft/fontconfig options manually, because many (most?) monitors actually do not provide that information. And because some people don't like subpixel font hinting. Would you prefer it to be unconfigurable?

> Then there's a whole question of synchronization. Wayland devs spent quite a lot of time discussing the whole double buffering mechanism, making it much more robust than in X (where buffer swap either stalls your pipeline or can happen at indeterminate time).

(You talk about that as if you never used Wayland/Weston and never seen how windows blinked like crazy when you resized them) It's not that I understand what problem you talk about but who cares? Yes, Wayland is a lot about "we don't like how X does that so we do that differently", but who cares? Nobody works on that low level. And those who do (authors of toolkits and compositing managers) have already implemented that ten years ago. What's the point in changing the protocol that people either don't care or got already implemented and working?

Bad NIH, good NIH

Posted Mar 13, 2013 8:04 UTC (Wed) by paulj (subscriber, #341) [Link]

Virtual desktops on Mac OS X are the same thing as virtual desktops on X. And Mac OS X allows virtdesktops on a same display to have different resolutions (which X doesn't allow, btw).

My multi-monitor setup in work consists of two different sized monitors. I run each at their native res. So I have desktops with 2 different resolutions right in front of me, here now.

So I strongly suspect you may be wrong on this point.

Bad NIH, good NIH

Posted Mar 11, 2013 22:58 UTC (Mon) by khc (subscriber, #45209) [Link]

> That's because ctrl key is not a modifier key, try that with alt-shift.

I use alt-shift to switch input method (with scim), and have been doing this for a few years. Other than me accidentally hitting it from time to time, I don't have a problem with it.

Bad NIH, good NIH

Posted Mar 9, 2013 16:01 UTC (Sat) by nix (subscriber, #2304) [Link]

Um, startup is fast on low-latency connections, sure. Now try it over a higher-latency link. Be prepared to wait a while (sometimes *minutes*, not seconds: the worst I've ever encountered was over a dialup modem and took more than half an hour to map a window, though admittedly that was a program that took a couple of seconds to map its first window even on Ethernet).

Bad NIH, good NIH

Posted Mar 9, 2013 19:10 UTC (Sat) by Serge (guest, #84957) [Link]

> Um, startup is fast on low-latency connections, sure. Now try it over a higher-latency link.

That example doesn't add points to Wayland because in cases when you actually need that (rare cases, like running Oracle GUI installer on a server without a video card on board) you can still make it work faster under Xorg (vnc, xpra, etc.) but you can't make it work at all under Wayland, since you can't start Wayland compositor there.

> the worst I've ever encountered was over a dialup modem and took more than half an hour to map a window, though admittedly that was a program that took a couple of seconds to map its first window even on Ethernet

Still if it's slow for some programs but fast for others, then those programs are to blame, not Xorg, right?

In that particular case I would try selecting simple widget theme on a server side for that slow program, without nice gradients, cool round buttons or realistic shadows. :)

Bad NIH, good NIH

Posted Mar 9, 2013 20:01 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

> but you can't make it work at all under Wayland, since you can't start Wayland compositor there.
Wayland works just fine with purely software rendering ( http://www.phoronix.com/scan.php?page=news_item&px=OD... ). I'm not sure this support hasn't bitrotted since then, but there are certainly no fundamental reasons why Wayland should require graphics hardware at all.

Bad NIH, good NIH

Posted Mar 9, 2013 20:17 UTC (Sat) by Wol (guest, #4433) [Link]

aiui, the X protocol REQUIRES that the video display is copied between the client and the server SEVERAL times.

If both are on the same machine, no problem. It's easy (and has been done) to do the copy by passing a pointer. Quick and simple.

However, I REGULARLY run KDE as a client on my linux machine, with the X server on either a different linux box, or my Windows laptop. SLOW SLOW SLOW. Slower than a spaced out sloth.

Cheers,
Wol

Bad NIH, good NIH

Posted Mar 10, 2013 10:42 UTC (Sun) by nix (subscriber, #2304) [Link]

No, it doesn't require copying the video display at all. It requires protocol roundtrips (request/response), though, before the window is even mapped: and if the client is badly written it can require a *lot* of them. And there are a lot of badly written clients, since all too many people don't bother to test their programs on remote X at all, brushing off bug reports from people like me with "don't do that then".

Bad NIH, good NIH

Posted Mar 10, 2013 11:01 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]

the many round trips at startup are largely to figure out what options are supported on the display side (since X has existed so long, may 'obvious' things, like color, are optional), and a substantial part of the speedup that approaches like nx provide is to short circuit these round trips.

This is very similar to what the 'wan accelerator' appliances do to the windows networking protocol to make it tolerable over high latency links (same problem, too many round trips)

While the fashion right now is for every app to render things as a complete bitmap, that's just a fashion of what is considered 'good' this year, that swings back and forth over time, in part depending on the available processing power at each end.

Bad NIH, good NIH

Posted Mar 10, 2013 20:17 UTC (Sun) by raven667 (subscriber, #5198) [Link]

> While the fashion right now is for every app to render things as a complete bitmap, that's just a fashion of what is considered 'good' this year, that swings back and forth over time, in part depending on the available processing power at each end.

Think this statement is a gross mischaractization of the last 30+ years of graphics development with a history of hard won experience with apps, operating systems and hardware that can't be hand-waved away as mere "fashion". Where is the yearly "swing" in the evolution of serial terminals to framebuffers to fixed function accelerators to programmable GPUs, which has taken decades? If there is anything cyclic, computing has existed for too short a time to see it

The best you can say is that the approach of sending high level drawing commands across the wire like X or NeWS is what is being implemented with HTML5 applications using JS, DOM, CSS and WebGL

Bad NIH, good NIH

Posted Mar 11, 2013 4:13 UTC (Mon) by Serge (guest, #84957) [Link]

> aiui, the X protocol REQUIRES that the video display is copied between the client and the server SEVERAL times. If both are on the same machine, no problem. It's easy (and has been done) to do the copy by passing a pointer. Quick and simple.

It does not. Quite the contrary it encourages you to pass your images to the server and manipulate them using "pointers". And of course Xorg has local display optimisations. It's up to the application what and how to draw. A lot of small unique images to pass over the network may slow down the whole process, as many modern themes do.

Simpler themes help. Drawing something like http://www.zimagez.com/zimage/2012-03-30--1333132280.php over network is much easier than something like http://4.bp.blogspot.com/-Ezze7Ar8OQ4/TaRaTjLLh5I/AAAAAAA...

> However, I REGULARLY run KDE as a client on my linux machine, with the X server on either a different linux box, or my Windows laptop. SLOW SLOW SLOW. Slower than a spaced out sloth.

It's slow compared to what? xpra/winswitch.org? NX? VNC? There're many options under X.

Bad NIH, good NIH

Posted Mar 11, 2013 14:40 UTC (Mon) by nye (guest, #51576) [Link]

$time /bin/true
real 0m0.004s
user 0m0.000s
sys 0m0.004s

$time xterm -e /bin/true
real 0m0.359s
user 0m0.032s
sys 0m0.036s

$ssh <remote-machine>

$time /bin/true
real 0m0.002s
user 0m0.000s
sys 0m0.000s

$time xterm -e /bin/true
real 0m37.708s
user 0m0.108s
sys 0m0.032s

In this example, <remote-machine> is at the end of an ADSL connection, with an RTT of around 45ms - ie. about the best kind of connection that's widely available for the kind of money that individuals and small organisations can afford (and if you think a couple of grand a month for an internet connection is affordable, you're not thinking 'small organisation').

Bad NIH, good NIH

Posted Mar 11, 2013 17:29 UTC (Mon) by sfeam (subscriber, #2841) [Link]

You (or xterm) are doing something very wrong.
Here's what I get using ssh to a remote machine over a bog-standard comcast consumer cable connection, followed by display of not just a terminal window but full graphics display plus round-trip response to a mouse click. Some toolkits are better than others at negotiating fast response over a remote connection, but all are funneled through x11.

$ssh <remote-machine>

$time gnuplot -e 'set term qt; plot x; pause mouse'
0.058u 0.013s 0:08.18 0.7%

$time gnuplot -e 'set term wxt; plot x; pause mouse'
0.091u 0.034s 0:13.98 0.8%

$time gnuplot -e 'set term x11; plot x; pause mouse'
0.007u 0.058s 0:01.50 3.3%

and here's the time for display only (no wait for mouse click):

$time gnuplot -e 'set term x11; plot x'
0.010u 0.004s 0:00.79 1.2%

That's not to say that response couldn't be improved, but your 37 second latency is horrible for some reason other than x11.

Bad NIH, good NIH

Posted Mar 11, 2013 23:07 UTC (Mon) by nix (subscriber, #2304) [Link]

I bet his connection is dropping packets, so there's an extra delay caused by TCP timeouts in there.

Bad NIH, good NIH

Posted Mar 12, 2013 12:50 UTC (Tue) by nye (guest, #51576) [Link]

>I bet his connection is dropping packets, so there's an extra delay caused by TCP timeouts in there.

Nope, but there is something interesting to see from the ping statistics while this is going on:

118 packets transmitted, 118 received, 0% packet loss, time 117123ms
rtt min/avg/max/mdev = 42.022/158.507/720.719/168.475 ms

(Obviously this also covers some time before and after.)

Curious as to why my ping time goes up to several hundred ms while xterm is launching, I've discovered that this local machine feels the need to send a few megabytes of data to the remote machine before doing anything.

In fact, it looks like xterm is the culprit here. I don't have many X clients installed on the machine I'm ssh'ing into to test with, but xfontsel at least starts up a lot quicker (a couple of seconds).

If even xterm can't get X network transparency right, what hope is there for everyone else?

Bad NIH, good NIH

Posted Mar 14, 2013 5:48 UTC (Thu) by Serge (guest, #84957) [Link]

> You (or xterm) are doing something very wrong.

You can check that using x11trace tool. Most of the time is taken by sending fonts and other settings. That increases startup time, but makes it work faster, because it does not have to send images, it can reference fonts on the server side.

Xterm is smarter than most people think. It has configurable fonts, colors, hotkeys and many other options. For example to see xterm menu hold Control+Left/Right/Middle mouse button. But the point is that those settings are stored on a server-side (XResource), and xterm reads them all from server during startup.

Some DEs are using that. For example on KDE xterm colors should match your theme, does not matter what host you start xterm from. That's the server-side themes in action. Nobody remembers them any more... (sigh)

Bad NIH, good NIH

Posted Mar 14, 2013 5:43 UTC (Thu) by Serge (guest, #84957) [Link]

> $time xterm -e /bin/true
> real 0m0.359s
> user 0m0.032s
> sys 0m0.036s

Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?

Anyway, your samples confirm that running application remotely is slower than running it locally. That was obvious even without testing. :) If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:

$ time xterm
real 0m0.066s
user 0m0.024s
sys 0m0.008s

$ time weston-terminal
real 0m0.095s
user 0m0.064s
sys 0m0.028s

But even that test does not necessary mean that X is faster than Wayland. It just means, that xterm starts faster. Both times are good enough. And X11 is not a bottleneck for faster program startup time. If you actually need faster startup over network right away you can try winswitch.org/xpra.

PS: When benchmarking some soft do multiple tests and select the best result. Also don't forget to switch cpufreq governor to "performance" otherwise you're benchmarking your governor, not your soft.

Bad NIH, good NIH

Posted Mar 14, 2013 11:24 UTC (Thu) by nye (guest, #51576) [Link]

>Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?

No, but many repeated runs do bring it down to 0.109s in the best case.
I think this is an example where the first case is the relevant one though, because that's what you'd experience in real use.

To be fair, I don't know if the video device and driver in use have any bearing on this, but just in case it does it's worth noting that I'm running on a laptop with Intel integrated graphics, where I have historically found the quality of both hardware and driver ranges from 'awful' to 'unspeakably awful'.

> If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:

I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.

Bad NIH, good NIH

Posted Mar 15, 2013 9:01 UTC (Fri) by Serge (guest, #84957) [Link]

> No, but many repeated runs do bring it down to 0.109s in the best case. I think this is an example where the first case is the relevant one though, because that's what you'd experience in real use.

It depends on what do you want to benchmark. If you're just curious "how fast would it be next time I try" then yes. But if your goal is to compare two programs then you must reduce impact of all other obstacles, i.e. cpu throttles, disk cache, memory/swap, other programs running, etc.

> I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.

I was just trying to say that "core protocol imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips)" is not true. Slow startup is not X11 issue when running locally. Wayland only makes things worse. Applications would ofter start slower on Wayland because they're expected to talk to hardware, which requires additional steps for hardware initialization.

As for remote startup it's not that fast because of software, not because of protocol limitations. For example it could be much faster if xterm was sending requests in batch instead of waiting for response every time before sending another request. But people are lazy... They don't like optimizing things. But they like rewriting things from scratch somewhy. It's not a problem of X11 protocol, it's a human problem.

Bad NIH, good NIH

Posted Mar 5, 2013 21:11 UTC (Tue) by man_ls (subscriber, #15091) [Link]

It is a burden that you don't have to carry, so I have to wonder why the vitriol. Do you feel the same about systemd and journald, or are those justified?

Bad NIH, good NIH

Posted Mar 5, 2013 21:20 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

For changes in low level components, it would be better if there is more buy-in upfront by talking to the distros and figuring out what is needed. For systemd, Lennart talked to the Scott (upstart) first and then with Kay (udev maintainer, who was then working for SUSE) and several others before even announcing the project. Yes, it is partly political but without that, you won't have much of a success.

It is clear that no external communication happened in this case. I think these changes do affect all of us because vendors like Valve have to deal with it and we might get less software developed for our platform of our preference because of it and it is not vitriol to express such concerns.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 5, 2013 21:26 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I didn't mean to imply any vitriol and while it's true that this doesn't directly affect me I would like to see Canonical succeed and I don't think this is the right path to do so. As far as systemd is concerned it is fixing a number of long standing design flaws and stagnation in low level system management and is well on its way to becoming the standard for Linux systems so I think it's a great example of a wheel that did need to be re-invented. I am more skeptical about the journal although, like systemd, it provides great compatibility with the existing order so it is still a net positive but I wonder if more could be done to add its way of doing things to rsyslogd instead. In any event the journal provides useful capabilities.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 5, 2013 21:49 UTC (Tue) by man_ls (subscriber, #15091) [Link]

With systemd Poettering et al are using dirty tactics to get it included in other distributions, including appeal to authority, constant accusations of foul play and even of forking existing projects (when Upstart was there first). I do not like that, at all. It is for these things that Red Hat gets badmouthed by many community members. So it is not a good example of Red Hat building useful low level components, even if they did talk to Upstart devs first (answering to the above post by rahulsundaram too). Talking to devs is not useful if there is no collaboration afterwards, and it may even look like an excuse.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 5, 2013 22:12 UTC (Tue) by raven667 (subscriber, #5198) [Link]

> With systemd Poettering et al are using dirty tactics to get it included in other distributions, including appeal to authority, constant accusations of foul play and even of forking existing projects (when Upstart was there first).

I don't even need to add anything to that...

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 5, 2013 22:21 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Wow. you are the one complaining about vitriol? Your entire post is a bunch of random accusations and one factual inaccurate claim of systemd being a fork. Systemd was written from scratch because it was a entirely different design from Upstart and talking to developers is very useful to determine whether you can enhance the project or come up with a new one. So no, it is not a excuse and it is always better to talk to people and do your research first even if you decide not to collaborate. If you really think systemd got adoption from Fedora, RHEL, SUSE, Mandriva, Mageia, Arch Linux, NixOS etc by appeal to authority and foul play, you must be living in an alternative universe.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 5, 2013 22:24 UTC (Tue) by man_ls (subscriber, #15091) [Link]

OK, you are right; I guess I was carried away. Also, systemd is the superior technical solution, no discussion about that. But the accusations are not nice anyway.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 6, 2013 0:19 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I don't think people here are accusing anything or anyone. We are just having a reasonable debate.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 6, 2013 0:26 UTC (Wed) by man_ls (subscriber, #15091) [Link]

Of course. I don't mean here, I mean the constant accusations from Poettering at Upstart developers.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 6, 2013 0:32 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Lennart has criticized the design but praised the code in some comments and I haven't seen any accusations at all. Can you provide a reference?

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 6, 2013 0:41 UTC (Wed) by man_ls (subscriber, #15091) [Link]

Sure, why not. For instance:
Ubuntu has now become an island that is growing more or more apart from any other bigger commercial Linux. [...] Canonical contributes barely anything to the Linux plumbing layer, much the same way they stay away from the kernel. (Source).
Ultimately, this move of Canonical will be one more step towards splitting up the ecosystem. (Source).
For more, just google "Poettering Upstart" and have fun.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 6, 2013 0:52 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

That isn't a criticism of upstart developers at all but Canonical and Scott left for Google anyway.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 6, 2013 0:57 UTC (Wed) by man_ls (subscriber, #15091) [Link]

I think that criticizing Upstart for causing a rift in the Linux ecosystem has to place at least some blame at the developers. Also there are other quotes I am too lazy to search for right now (and I don't think they would change your mind much). But whatever, make it "constant accusations from Poettering at Canonical".

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 6, 2013 1:11 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Yeah. Lennart doesn't like Canonical much. I don't think that has anything to do with the current discussion or the technical merits of a particular technology so I am not sure why you bought it up.

Thanks for making my argument

Posted Mar 6, 2013 1:19 UTC (Wed) by man_ls (subscriber, #15091) [Link]

Precisely. When a Red Hat employee starts badmouthing a competitor instead of focusing on the technical merits of a product, it smells like foul play. It tends to happen a lot lately -- see this article and the Google+ discussion you linked here.

Thanks for making my argument

Posted Mar 6, 2013 1:43 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I don't think it has anything to do with the companies they work for. These are passionate opinionated developers and they were absolutely right about the technical criticisms and Mir page got updated to reflect that.

Thanks for making my argument

Posted Mar 6, 2013 1:50 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

To add on to that, let's look at company/project affiliations of people participating in that Google thread who are critical of Mir

Kristian Høgsberg - Intel
Daniel Stone - Collobora
Dave Airlie - Red Hat
Mathias Hasselmann - Openismus
Carsten Haitzler aka Rasterman - Enlightenment

As you can see, it is a very broad group.

Thanks for making my argument

Posted Mar 6, 2013 10:20 UTC (Wed) by man_ls (subscriber, #15091) [Link]

So Poettering is only making valid technical criticisms on those pages? Or David Airlie? Random quote:
they barely have anyone competent enough to write a display server, the fact that they are actually quite ignorant of how wayland works makes it even more apparent.
Your intellectual dishonesty is staggering.

Thanks for making my argument

Posted Mar 6, 2013 12:01 UTC (Wed) by ewan (subscriber, #5533) [Link]

"It is for these things that Red Hat gets badmouthed by many community members."

That was you, upthread. If this was about one company unfairly dissing a competitor, that would be one thing. When it's basically the entire community, across multiple different companies (many of which aren't direct Canonical competitors) versus one individual organisation doing something different, that's another.

Thanks for making my argument

Posted Mar 6, 2013 13:14 UTC (Wed) by paulj (subscriber, #341) [Link]

Intel and RedHat have financial ties, don't they? (Former is an investor in the latter).

Thanks for making my argument

Posted Mar 6, 2013 15:15 UTC (Wed) by raven667 (subscriber, #5198) [Link]

[sarcasm]
I'm sure David checked his stock portfolio, chuckled, and pet his shaved cat before posting that, it had nothing to do with how he actually feels...
[/sarcasm]

These assumptions of corruption reflect more about how the writer sees the world and thinks in their own head than about the people who are the subject of their words.

Thanks for making my argument

Posted Mar 6, 2013 15:51 UTC (Wed) by paulj (subscriber, #341) [Link]

Untrue, affiliations, including corporate alliances, can easily bias us and subconsciously at that. To scoff at that is to deny provable human nature.

Thanks for making my argument

Posted Mar 6, 2013 16:04 UTC (Wed) by paulj (subscriber, #341) [Link]

Oh, and if some free software programmer's view of something *were* biased because, e.g. that something was the product of a competitor of their employer or their employer's corporate allies, that does NOT make them a bad person. Indeed, I would *expect* a person to be biased toward acting in the interests of their employer - that would make them a *good employee*.

Such biases do exist, at various levels of consciousness. That is not to condemn them. However, we should be aware of them, and take care to note affiliations.

Thanks for making my argument

Posted Mar 6, 2013 16:16 UTC (Wed) by raven667 (subscriber, #5198) [Link]

While at some level what you say is true I'm not sure it applies strongly in this case. Linux developers come from a wide range of companies and while they may be directed to work on a particular part of the system which is strategically important to their employer, they generally show more loyalty to Linux itself than to whichever company is currently paying them.

As far as I can tell, dissing Canonical provides no tactical or strategic benefit to any particular vendor who is involved in this discussion

Thanks for making my argument

Posted Mar 6, 2013 16:28 UTC (Wed) by paulj (subscriber, #341) [Link]

Perhaps in this case, not strongly, sure.

However, there's been a number of times over the last few years where from several rouge capped free software people have snipped at Canonical, with a common theme that Canonical is somehow free-riding. The sub-text seems to be that Canonical gets more of the user-base with Ubuntu and recognition than their share of the work deserves. Guess who employees a lot of the people doing the work?

To think there is absolutely no element of corporate competition to this story seems, I'm sorry, a little naïve. Both in terms of Canonical choosing not to hitch their wagon to Wayland, and in the (predominantly) RedHat and Intel employees' reactions to that. There are pure, technical elements too, of course...

Thanks for making my argument

Posted Mar 6, 2013 19:34 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> There are pure, technical elements too, of course...
Like what? So far, every technical reason named by Canonical either has been disproven or is phrased too vaguely to ever be.

Thanks for making my argument

Posted Mar 6, 2013 15:56 UTC (Wed) by man_ls (subscriber, #15091) [Link]

[counter-sarcasm]
I am sure David calmly and dispassionately reviewed once more the payroll list of Canonical, and checked the LinkedIn skillsets of all employees. Then ignoring all subconscious biases he might once have possessed, decided that they didn't have anyone competent enough to write a display server.
[/counter-sarcasm]
Your naïveness would be somewhat refreshing, I have to admit, were it not so biased at heart. Reinforced prejudices are very dangerous.

Thanks for making my argument

Posted Mar 6, 2013 16:11 UTC (Wed) by raven667 (subscriber, #5198) [Link]

You are just so adorable! 8-)

In any event pointing out the clear lack of familiarity with the technologies they are (not) using is not pre-judice, it's post-judice. I don't think it's unfair to also say that they have not demonstrated technical leadership very often in the underlying infrastructure technologies they depend on, bzr and upstart being two examples. They need not just the cojones but the talent to pull this all off.

I should also point out that I wish nothing but the best for Ubuntu, which is why I'm talking about this in the first place, if I didn't care I wouldn't comment.

Thanks for making my argument

Posted Mar 6, 2013 20:38 UTC (Wed) by airlied (subscriber, #9104) [Link]

Yes Paul,

Intel told Red Hat to tell me to say this. Thats exactly how it went down.

Thanks for making my argument

Posted Mar 6, 2013 20:48 UTC (Wed) by paulj (subscriber, #341) [Link]

And that's not in any way what I was suggesting Dave.

Thanks for making my argument

Posted Mar 6, 2013 16:33 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I am sorry but you seem to be obsessed with Lennart for some reason. It is rather disturbing. My list of people did not include Lennart but developers across the community who have expertise in the Xorg/Mesa/Wayland stack and yes, David's statement was accurate and Canonical has subsequently revised the Mir page to retract their criticism against Wayland.

"Intellectual dishonesty" is just a weasel word for lying and if you want to accuse me of that because I disagree with you that this is somehow a Red Hat specific thing when I have clearly shown you otherwise (yet another criticism from KWin developer - http://www.reddit.com/r/LinuxActionShow/comments/19qcix/k...), then I don't think you get to advocate against vitriol or badmouthing. If you have a counter point, please express is politely.

Thanks for making my argument

Posted Mar 6, 2013 17:12 UTC (Wed) by man_ls (subscriber, #15091) [Link]

It is true that your list did not include Poettering, but why? He is clearly badmouthing Mir (comparing to some engineering disasters, not very ingeniously as it happens), he offers no valid technical points, he is a Red Hat employee. I am not obsessed with him, but I think he employs dirty tactics in his fight for systemd and against Upstart. You have still not refuted this point other than substracted this particular person from the argument, for some reason. That is intellectually dishonest IMHO.

Let us leave him aside; another Red Hat employee (David Airlie) also badmouthed Canonical without offering any valid technical points, as quoted above (saying they don't have competent technical people). Other people expressed their opinions, in a mostly polite form, and with valid technical reasons; Airlie only made baseless accusations (such as lamenting the lack of source code, which was not true) and silly jabs (Jumping Sharks).

That is just one random Google+ thread, there are many other examples that I have linked above. I am not in the mood to curate any more examples for you.

Thanks for making my argument

Posted Mar 6, 2013 17:44 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I have already refuted this point already by telling you two things

1) Lennart's dislike for Canonical is not based on his organizational affiliation. It has a much longer history.

2) it has nothing to do with the current discussion

David's points were already shown to be true. You are however just engaging in the same tactics you seem to be critical of.

Thanks for making my argument

Posted Mar 6, 2013 17:50 UTC (Wed) by man_ls (subscriber, #15091) [Link]

I knew this was not worth my time. Anyway, just a clarification: being intellectually dishonest is not the same as being a liar, it is rather to be a self-liar. You choose to see the reality in your own terms and disregard what doesn't fit. Is it intentional or not? I don't know and frankly I am not interested.

Now you will no doubt accuse me of the same, and so on. Bah.

Thanks for making my argument

Posted Mar 6, 2013 17:58 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

So "intellectual dishonesty" is your fancy way of saying, you disagree with me! and of course I do. If you see this thread, the only real badmouthing is from you.

Thanks for making my argument

Posted Mar 6, 2013 20:58 UTC (Wed) by airlied (subscriber, #9104) [Link]

You have to realise I can be a bit of a dick sometimes.

http://airlied.livejournal.com/76828.html

I summed up my thoughts at the time here, in the end C removed the lies, but I'll still bet we'll see them repeated by fanbois across the Internet for years, and developer time will have to be spent correcting them.

I'll update the blog post to mention that they have removed the original source of the technical untruths.

The thing is if you think this is was a purely technical decision at Canonical's end you are already sucked into their event horizon, sometimes you have to realise technical isn't the game that you are being played in and address it as such.

Thanks for making my argument

Posted Mar 6, 2013 21:32 UTC (Wed) by man_ls (subscriber, #15091) [Link]

Of course I don't think it's a purely technical decision from Canonical. Also, I don't necessarily think it is a good decision, either for them or for Linux as a whole. But I do think that many good things can come out of it: new ideas, new code, encouragement for Wayland devs to finish their job.

As to the downside, there may be bad consequences, but I don't see how we may end up with three (or four!) different, incompatible display servers. Either they will be compatible somehow or only one will survive. Hey, even GNOME and KDE have agreed to a lot of standards, making our life easier.

Thanks for making my argument

Posted Mar 6, 2013 23:36 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> But I do think that many good things can come out of it: new ideas, new code, encouragement for Wayland devs to finish their job.
Name one reason why new ideas and code can't be created by extending Wayland.

> As to the downside, there may be bad consequences, but I don't see how we may end up with three (or four!) different, incompatible display servers. Either they will be compatible somehow or only one will survive. Hey, even GNOME and KDE have agreed to a lot of standards, making our life easier.
Yeah right. Gtk applications look alien on Qt-based Desktops to this very day. If anything, the Gnome/KDE history is a cautionary tale.

Thanks for making my argument

Posted Mar 6, 2013 20:51 UTC (Wed) by airlied (subscriber, #9104) [Link]

how could I make technical criticism of a project that didn't exist in public before yesterday, and is only a few thousand lines of badly written C++?

Here's the thing, Canonical came out of the gate and bashed wayland. I'm not wayland's biggest supporter, but I don't like when companies uses lies and fanboi bases to make their arguments, to me it usually means they are hiding something.

As I've pointed out on my blog they are hiding something or they are technically incompetent. If they are hiding something, its most likely a control problem. If they really misunderstood how wayland worked and believed in what they posted, then its a competency problem, and I'd rather not base the future of Linux compositing on work done by people too incompetent to read and understand the few thousand lines of code that is wayland.

The other thing is Red Hat (as a corporation) doesn't even see this stuff, they do pay me to see this stuff, but they don't direct how I respond and I don't speak on their behalf. My job is to do what I think is best for Linux graphics in the long term, like seriously that is actually what they pay me for, and if I think pointing out flaws in Canonical's arguments for NIHing things is best for Linux then I'll go ahead and do it!

Thanks for making my argument

Posted Mar 6, 2013 21:25 UTC (Wed) by man_ls (subscriber, #15091) [Link]

Let me wear my sophist hat for a minute. Where to start.

If you cannot make technical criticism, why do any criticism at all? After all you started with your criticism before even knowing there was a public repo, making a blunder in the process ("I remember when open source project announcements used to come with source").

Once you found the missing repo, why not take your time and make criticism of the few thousand lines of code? If Wayland is also a few thousand lines of code, is it enough to define it or not? Apparently a few thousand lines of code is not enough for you to understand, since you cannot make technical criticism; but it should be enough for Canonical engineers to not only make technical points (which after all can be superficial), but to completely understand it. And apparently not taking the time to understand another project in depth before criticizing it is equivalent to not being competent. Or perhaps a few thousand lines of code are not sufficient to evaluate and understand a complex project.

As I've pointed out on my blog they are hiding something or they are technically incompetent.
Maybe they are hiding something; after all they work for a company as you do and it has its agenda, just as yours. But that is a false dichotomy; maybe they just need something that moves faster and believe they can pull it. Or maybe Shuttleworth as a kid promised himself he would one day build a replacement for X; use your imagination instead of accusing others of incompetence. It will be more interesting.
The other thing is Red Hat (as a corporation) doesn't even see this stuff, they do pay me to see this stuff, but they don't direct how I respond and I don't speak on their behalf. My job is to do what I think is best for Linux graphics in the long term, like seriously that is actually what they pay me for, and if I think pointing out flaws in Canonical's arguments for NIHing things is best for Linux then I'll go ahead and do it!
Read what you wrote carefully. First you say that you don't speak on Red Hat's behalf, but then you go on to say that they pay you to speak your mind if you think something is wrong. Amazing.

Red Hat as a corporation sees this stuff, since you are part of that corporation and are paid to see it. As others have said, you would not be a good employee if you had not interiorized some business principles, such as avoiding projects not under the direct control of your corporation. Sometimes the goals of that corporation will align with the interests of Linux, sometimes it will not (like not publishing a git repo for the kernel). You think Mir is a not good idea; fine. You might also say "Let us wait and see what they come out with; there may be good ideas that we can adapt, and it is Free software after all" or "They have come with good stuff in the past that has served Red Hat well, like Upstart", but hey.

However, you are not only pointing out flaws in Canonical's arguments; you are actively despising them in public ("They should call the next Ubuntu Jumping Sharks"). It points to some kind of internal hostility towards Canonical, which somehow cannot surprise anyone at this point.

Thanks for making my argument

Posted Mar 7, 2013 0:05 UTC (Thu) by airlied (subscriber, #9104) [Link]

Because technical criticism isn't the be all and end all, as much as people would like to believe. You should always question people and companies motives, you seem to be happy to question my motives, but can't apply that to Mir/Canonical?

If they aren't hiding something, and we can believe they believe they have the technical competence to design a replacement for wayland/X then you'd expect them to have the technical competence to understand wayland/X? Its generally considered a good idea to understand the thing you are trying to displace. Now if you write a page of falsehoods on the things you are trying to displace, you are either acting from malice, deliberately lying, or stupidity, lying through lack of knowledge. As I said on my blog posting, neither of these reasonings are the things I want to see from the group designing the next generation of display server.

What part of, I do not speak for Red Hat, makes no sense to you. Just because someone gives me a pay cheque it doesn't translate me into a mouthpiece for them. I know its probably hard to understand for people who've never worked in an environment like Red Hat. I have a position in the Linux community and I make statements that I feel like making, if something pisses me off, I say this pisses me off, and try to analyse why! so what if I don't like Canonical, their methods of open source development are anti-community and the direct opposite of how every open source project I've worked on has worked. So maybe I make petty one liner statements, shoot me, its the Internet.

Thanks for making my argument

Posted Mar 7, 2013 0:20 UTC (Thu) by man_ls (subscriber, #15091) [Link]

Great, so you dislike Canonical and badmouth them in public. That is exactly what I was trying to establish (and something that other commenters obtusely refuse to see). It is your choice, but expect no sympathy for your cause from those grateful for Ubuntu.

Do you apply the same criteria always? Because I am eagerly awaiting your criticisms of Google Android, Tizen and the GNU project, just to name three prominent examples that are run more or less behind closed doors. (GNU is more open but still requires contributors agreement; the others are worse because AFAIK they don't even accept external contributions.)

Me, I am grateful for what I get, and contribute back what little I can.

Thanks for making my argument

Posted Mar 7, 2013 0:34 UTC (Thu) by airlied (subscriber, #9104) [Link]

Android never posted a criticism of a project I cared about, they did their own thing, I don't like how they do it, but I feel no need to comment on something that exists in its own universe. If they attempted to bring that universe into collision with mine, then yes I would be vocal about it.

If you believe signing the GNU contributors agreement equates to the Canonical contributor agreement, I have no further time for you, because frankly I expect to discuss things with people intelligent enough to interpret the agreements they sign and who they assign copyrights to.

Thanks for making my argument

Posted Mar 7, 2013 0:47 UTC (Thu) by man_ls (subscriber, #15091) [Link]

I find strange that doings things behind closed doors would be more palatable (or at least less deserving of your ire) than posting public documents. But everyone is entitled to their own contradictions, aren't we?

As to the GNU project, I think they do a great and necessary job, but their contributor agreement (reasonable as it is) and their development policies (cathedralicious according to some) have been criticized before. They are certainly less agile than they might be, and probably unlike every other project where you have worked before. Hence the comparison.

Thanks for making my argument

Posted Mar 7, 2013 1:35 UTC (Thu) by airlied (subscriber, #9104) [Link]

Android development model gets lots of criticism from lots of people, in the embedded space and everywhere else. Look at the kernel merge fun ongoing for years.

I have given out about Android and their encouragement of closed source graphics stacks before, and I do quite often at conferences and anywhere else. I've bitched about HW designs like the raspberry pi and I believe the FSF encouragement of such designs is totally anti their real mission.

Again you say the GNU project, but really its not one big monolith, you seem to be unable to distinguish individual pieces moving in their own directions, GNU projects are not beholden to some GNU development overlord.

some of them are more agile than others, the GNU project is an umbrella framework. Contributors to GNU projects again come from many companies and all believe that GNU is a good steward of the copyrights. (even if they don't use it enough to beat GPL violators with).

The thing is I don't believe Canonical is a good steward for my copyrights or anyone elses, and I think contributing code as an equal to their projects is very difficult. I've gone from 0 to being an integral part of 3 major projects *before* I joined Red Hat, and have never felt my company affiliation mattered in any of them, and was never asked to assign copyrights in any of them. Why would I want to give Canonical rights to take my code proprietary when they don't give me the same right? If you want the right to take code proprietary license it under MIT, and give the same right to other contributors (ala the Mesa 3D stack and X.org), if you don't want it use a GPL variant like the kernel. I also disliked Qt for doing the same for years, and MySQL also ran like that. It discourages individuals and other companies from making any decent contributions to your codebase, so in general you lose a major benefit of being open-source in the first place.

Its generally okay to give copyrights to a foundation that is setup correctly, but to individual companies, my personal believe is it doesn't end well.

Thanks for making my argument

Posted Mar 8, 2013 14:29 UTC (Fri) by nix (subscriber, #2304) [Link]

Sheesh. The GNU project was cathedralicious *sixteen years ago*. It's not any more.

Not a cathedral, not a bazaar

Posted Mar 8, 2013 15:05 UTC (Fri) by man_ls (subscriber, #15091) [Link]

You are right (and I should know since I have been a voluntary Savannah admin for a few years). When handling code it is still not as agile as other environments, but it is certainly not centralized. The decision process however remains largely in the hands of a couple of people, and there have been some complaints about it recently.

Let us see a practical example: inclusion in the project.The GNU project says about it:

Based on the evaluators' report, Richard Stallman (the Chief GNUisance) makes the final decision on whether to accept the contribution. [...] Thus, becoming a GNU maintainer is a somewhat formal process, since affiliating with the GNU project as a maintainer means you must agree to work (within the confines of the maintenance) with the GNU project's mission for software freedom.
Contrast with inclusion in other software collections:
  • Debian: have a Debian Developer sponsor your package.
  • CPAN: register, wait two weeks and upload your package.
  • The PyPI: register and upload.
  • NPM: npm publish.
The GNU project may not be a cathedral of software, but it is not exactly a bazaar just yet... and probably it never will given its goals.

Thanks for making my argument

Posted Mar 7, 2013 4:05 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

"That is exactly what I was trying to establish (and something that other commenters obtusely refuse to see)."

Actually, no. What I refused to accept is that they are criticizing a project because of company affiliation. You are entirely wrong about.

Thanks for making my argument

Posted Mar 7, 2013 11:54 UTC (Thu) by paulj (subscriber, #341) [Link]

No one is accusing you of being a mouth-piece.

However, there is clear evidence that even well-intentioned, professional people tend to be affected by their affiliations. They tend to have biases toward arguing or acting in favour of the interests of their affiliations. This can happen subconsciously, even against the logical desires of the person. It's well documented in other fields, medical research particularly, and there are various psychological experiments you can do to demonstrate what is thought to be the underlying behaviour involved.

No matter how logical and dispassionate we try to be, our wetware just appears naturally to have a predilection for biasing us towards groups we are members of. There is no good reason to think software people would be immune to this.

Rather than deny this general fact, the best thing to do is to acknowledge it, so we then can find ways to minimise it or work-around it.

Thanks for making my argument

Posted Mar 7, 2013 12:23 UTC (Thu) by paulj (subscriber, #341) [Link]

Oh, and these effects occur even with full information. In the real-world, an obvious/frequent source of affiliation bias, is of having more complete or better information about your affiliations than of others.

Or as other commentators put it, communication issues. :)

Thanks for making my argument

Posted Mar 7, 2013 12:30 UTC (Thu) by HelloWorld (guest, #56129) [Link]

It's rather hard to be informed about what Canonical is doing when they do it behind closed doors. And that's actually what all this is about: the fact that Canonical utterly misses the point in Open Source Software: collaboration instead of competition.

Sources of bias

Posted Mar 7, 2013 12:41 UTC (Thu) by man_ls (subscriber, #15091) [Link]

In-group bias is another well-researched source of bias, that probably can be traced back all the way to primate groups. This is important not because it is more primitive, on the contrary: it is much more subconscious and entrenched than other, more cultural (you could say "human") biases. We want our group / tribe / company to thrive not because we will be better off, but because we are the best.

Sources of bias

Posted Mar 7, 2013 12:49 UTC (Thu) by paulj (subscriber, #341) [Link]

Yeah, I must have put it clumsily. My point was that lack of information is one obvious source of bias. But even when we have full information, we *still* have a definite tendency to be biased toward group members - even if subconsciously, as per your link.

Thanks for making my argument

Posted Mar 8, 2013 14:27 UTC (Fri) by nix (subscriber, #2304) [Link]

However, you are not only pointing out flaws in Canonical's arguments; you are actively despising them in public ("They should call the next Ubuntu Jumping Sharks"). It points to some kind of internal hostility towards Canonical
Actually it's called a sense of humour. You might want to look that up, since it seems you were sadly deprived of one.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 5, 2013 23:15 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> With systemd Poettering et al are using dirty tactics to get it included in other distributions,
Writing better software isn't a dirty tactic.

> when Upstart was there first
I wish people would stop bringing this crap up. While it's true, it **doesn't matter at all**. NIH == rolling your own thing when there's an equally (or more) suitable alternative from someone else. Poettering extensively documented the rationale for not contributing to upstart, and telling him to work on upstart is like telling Linus Torvalds to contribute to a microkernel OS written in C++.
And by the way, the stated reason for sticking with upstart in Ubuntu isn't that upstart is in any way superior to systemd, but the apprehension that they'll screw up the integration.
http://ubuntu.5.n6.nabble.com/upstart-beyond-Ubuntu-12-04...
Which wouldn't actually surprise me, given that it's Ubuntu we're talking about.

Bad NIH, good NIH (digression to Poettering, new Godwin's Law?)

Posted Mar 6, 2013 0:21 UTC (Wed) by ringerc (subscriber, #3071) [Link]

Being there first means very little if you have a design that doesn't fit everyone's needs and isn't easily adapted to fit those needs.

The BSD kernel was there first. Does that mean Linus shouldn't have started the Linux kernel (even just for fun)? Sure, there were legal controversies around BSD, but that can be written off as "political reasons" the same way people are writing off licensing, ownership and policy issues with new stack components.

I don't understand why people take such a strong emotional angle on this. Extend, fork or rewrite, they're all different ways to develop software that fits your needs. Sometimes one approach is the right one, sometimes another is. None are morally wrong or always right.

A bit lopsided

Posted Mar 14, 2013 5:09 UTC (Thu) by heijo (guest, #88363) [Link]

Like GNOME 3?

A bit lopsided

Posted Mar 5, 2013 2:32 UTC (Tue) by tetley80 (guest, #88691) [Link]

Except that they got the "mistakes" factually wrong, as evidenced by the discussion going on here. This strongly indicates Canonical didn't bother engaging with Wayland developers, even on a rudimentary level. It also indicates they didn't bother reading Wayland's specs.

Seriously, how hard is it to ask on the Wayland mailing list, "Hey, we're thinking of adopting Wayland, but we have concerns about area XYZ. Can you shed some light on this?" Or even this would have been better-than-nothing: "Hey, we're doing our own display server, and have run into issue XYZ. How did you solve it in Wayland?"

Instead, Canonical hasn't learned from other people's mistakes and is going to put a smaller engineering team (than Wayland et al) on their own display server. As Wayland folks (and X11 folks before them) know, making a display server is not a small task.

So a few pertinent questions to Canonical and Mark Shuttleworth are: (1) What substantial value does your own Mir display server provide that's beyond what Wayland does? (2) Wouldn't it be more cost effective to send patches to Wayland developers? (3) Is keeping the development in-house worth the sacrifice of not leveraging the efforts of other organisations and developers? (4) How does fragmenting the ecosystem/software stack help Ubuntu and Canonical?

A bit lopsided

Posted Mar 5, 2013 13:41 UTC (Tue) by deepfire (subscriber, #26138) [Link]

I'll reiterate the question voiced above -- why didn't Wayland people adopt SurfaceFlinger?

A bit lopsided

Posted Mar 5, 2013 15:10 UTC (Tue) by tetley80 (guest, #88691) [Link]

    why didn't Wayland people adopt SurfaceFlinger?

That's a good point. To be honest, I'm not that familiar with SurfaceFlinger. To (partly) answer your question: two wrongs don't make a right. Perhaps Canonical/Ubuntu should adopt and extend SurfaceFlinger instead of rolling their own display server?

On a related note, I'm starting to think that the most effective method to make Linux more relevant in the desktop space (and at the same time get a relatively sane OS stack: kernel, graphics, sound, input, UI) is to make Android self-hosting.

A bit lopsided

Posted Mar 6, 2013 1:14 UTC (Wed) by robclark (subscriber, #74945) [Link]

because it didn't exist at the time. And is less complete than wayland.. maybe the question should be "why didn't surface flinger people adopt wayland" :-P

A bit lopsided

Posted Mar 6, 2013 4:04 UTC (Wed) by swetland (subscriber, #63414) [Link]

Was Wayland around in 2006 when we wrote SurfaceFlinger?

Other discussion in this thread seems to imply Wayland only recently declared the protocol stable. Is this another "Android should abandon <thing they built that works today> in favor of <thing that's not done yet that's clearly going to be better because!>" discussion?

A bit lopsided

Posted Mar 6, 2013 4:15 UTC (Wed) by hummassa (subscriber, #307) [Link]

two words: bluetooth stack.

why oh why? those days (4.2.2), two out of five times I have to restart BT on my Nexus when I enter my car, just "because!"

A bit lopsided

Posted Mar 6, 2013 12:35 UTC (Wed) by nye (guest, #51576) [Link]

Your comment prompted me to try my BT keyboard that stopped working with 4.2 - it works again! Yay! And the mouse no longer seems to need a dance of turning off and on and re-pairing and praying to Eris and sacrificing a chicken.

A bit lopsided

Posted Mar 8, 2013 19:12 UTC (Fri) by hummassa (subscriber, #307) [Link]

My car stereo still acts out 20% of the time.

A bit lopsided

Posted Mar 6, 2013 4:39 UTC (Wed) by robclark (subscriber, #74945) [Link]

ok, then SF slightly predates wayland.. I couldn't find (and maybe I didn't look hard enough) any evidence of SF prior to 2008. My bad.

Anyways, certainly in the early days, SF wasn't in good shape for hotplug, multiple displays, vblank support, and these sorts of things that matter on desktop.

Anyways, re: protocol stability, I somehow doubt you could claim that SF is backwards compatible to SF from 2006. The protocol stability milestone should have mattered very little to something that is distributed and updated in the manner that android is.

And re: abandoning SF and going to wayland.. well, android has made equally big changes in it's plumbing from release to release. So it doesn't seem too big a stretch of the imagination.

A bit lopsided

Posted Mar 6, 2013 7:03 UTC (Wed) by swetland (subscriber, #63414) [Link]

I wasn't pointing to protocol stability as a SF feature, just as a "it sounded like Wayland was only recently declared 'done'", but I haven't followed Wayland development very closely, so it's possibly I completely misunderstood things here.

First public exposure to SurfaceFlinger would be Fall 2007 (SDK preview release and emulator) and first code drop would be Fall 2008 (Android 1.0 and G1 launch), but it's certainly something that was there from the very early days of the platform -- possibly late 2005, but certainly early 2006.

The hwcomposer HAL actually aims for some level for forward/backward binary compatibility (to ease development and upgrades), and while it doesn't reach back to the early days of SF (which has definitely evolved over the years), I just this week have been writing some test code for the HWC HAL that happily runs on a variety of devices from different OEMs and with different versions of the platform.

I'd be pretty doubtful about us shifting away from SF (especially now that hwcomposer and sync support is looking pretty solid), but we certainly are willing to pull things up and rebuild if necessary -- though the other commenter with his bluetooth complaint may be actually arguing *against* that, I guess.

From the other direction, though, unlike the earlier (now abandoned, I gather) work to stack Wayland on top of Android underpinnings, the hwcomposer HAL provides a much more flexible and richer surface than the old fb HAL, which certainly should be useful to the Canonical folks with their Mir compositor, as well as to anyone wanting to revisit a Wayland-on-Android world, though in both cases I'd assume the goal would be to get access to a wide variety of hardware ready to run "out of the box" rather than to actually use much of Android.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 22:25 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Judging by repository history, Mir development seems to have been happening for several months in private and before Wayland protocol was deemed stable. If Canonical had different requirements, wouldn't it have been feasible to talk to Wayland developers and participate in it rather than come up with their own thing? Drivers are going to be a hassle as well.

Also, Unity is moving to become entirely Qt/QML based after a checkered history of changes. Unity 2D was only recently abandoned although it was written in Qt in favor of 3D which was Compiz based (which in turn required a lot of work to stabilize). Again, it seems Canonical would have benefited from talking to KDE folks a long time back since they claim to have the goal of a unified stack across devices which was aligned well with the KDE path.

In either case, these are very ambitious projects and I hope Canonical understands the development and maintenance burden of going solo on this.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 22:58 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> In either case, these are very ambitious projects and I hope Canonical understands the development and maintenance burden of going solo on this.

I guess they should know better than anyone what it's like to go alone for maintenance and development since the seem to pick this option over collaboration most of the time.

It's like the old adage, Fast, Cheap or Quality, pick any two. They only have a small number of talented developers compared to the competition (Apple, Google, MS) so they are doing this on the cheap and trying to ship by the end of year is very fast so we can guess what is going to be left behind, although I'm not sure what else they could do if they want to be competitive.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 2:47 UTC (Tue) by rahvin (subscriber, #16953) [Link]

I'm not sure what else they could do if they want to be competitive.
I apologize in advance for the partial quote but this is the only bit relevant to my reply and it stands on it's own as a complete statement.

How can they be competitive if they are spending all their development resources on reinventing the wheel? Wouldn't it have been better to help Wayland get there quicker? And by putting their resources into Wayland they would have far more input into how Wayland develops.

I can't help but think whoever is making these decisions over at Canonical has no long term thinking. Taking over development of the GUI on a shoestring budget and resources seems to be the height of stupidity.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 3:24 UTC (Tue) by raven667 (subscriber, #5198) [Link]

> How can they be competitive if they are spending all their development resources on reinventing the wheel

Short answer is that they cant. Their problem is that they want to work quickly without taking the time to build consensus or integrate with existing teams but unlike android they don't have the focus or resources to see it through. I'd love to see an Ubuntu phone that converts to a desktop ui when traditional input/output devices are connected, because I think thats a good idea, but I don't see how they are going to get there behind windows phone, blackberry, webOS, FirefoxOS, etc.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 5:17 UTC (Tue) by swetland (subscriber, #63414) [Link]

Is using an existing abstraction layer for hardware composition that's deployed to a wide variety of SoCs on hundreds of millions of devices "reinventing the wheel?".

They probably could save more time by slicing things *above* the SurfaceFlinger instead of below it, just bolting whatever IPC protocol they want on top if they don't want to use the existing Binder stuff.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 15:49 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Fair point but they are still dividing things in the infrastructure, which seems like unnecessary wheel re-invention, rather than competing in the application space, which would be competition.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 6:12 UTC (Wed) by nhippi (subscriber, #34640) [Link]

Well they are re-inventing surfaceflinger as much as they are re-inventing wayland.

I agree they would have saved time by implementing their fancy swiping ui as a new android launcher app. But of course that way they couldn't have claimed they are somehow making a "real Linux" phone...

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 22:44 UTC (Mon) by atai (subscriber, #10977) [Link]

The "open" International Station has better fortunes than the Mir station?

Why not Wayland

Posted Mar 4, 2013 23:04 UTC (Mon) by raven667 (subscriber, #5198) [Link]

under Why Mir?

> X's input model is complex and allows applications to spoof on input events they do not own. On the one hand, this raises serious security concerns, especially regarding mobile platforms. On the other hand, adjusting and extending X's input model is difficult and supporting features like input event batching and compression, motion event prediction together with associated power-saving strategies or flexible synchronization schemes for aligning input event delivery and rendering operations is (too) complex.

and under Why not Wayland

> The input event handling partly recreates the X semantics and is thus likely to expose similar problems to the ones we described in the introductory section.

? likely ?

This is being described like the person is not intimately familiar with Wayland but has heard that in many ways its like X so they are making assumptions and can't make a definitive statement on what does or doesn't fit their perceived needs. That seems like a bad basis for making such an important decision, maybe they should talk to the Wayland designers and see if their needs can be met (software can be changed!) before redoing all of this work, poorly.

Why not Wayland

Posted Mar 4, 2013 23:07 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Atleast some of the assumptions they make are wrong. It shouldn't be much of a surprise at this point but they haven't talked to the developers involved either.

https://plus.google.com/100409717163242445476/posts/jDq6B...

Why not Wayland

Posted Mar 4, 2013 23:28 UTC (Mon) by jubal (subscriber, #67202) [Link]

(I've read that google+ thread, interesting. Nb. I wouldn't be surprised if there would be much more upstart installations than systemd-based ones, especially as upstart is used by chromebooks; also, seeing Mr. Pöttering complaining about heavy-handed approach made my day.)

Why not Wayland

Posted Mar 5, 2013 0:48 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

That thread wasn't about systemd. Lennart has a confrontational style but responds very well to technical arguments and avahi, pulseaudio and systemd adoption across distros remains very high because people are convinced of the merits. Strong opinions doesn't equate to heavy handedness. The problem is not that one creates alternatives but when the description as to why is weak.

Why not Wayland

Posted Mar 5, 2013 1:12 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Poettering is spelled just like that; there is no Umlaut involved.

Why not Wayland

Posted Mar 5, 2013 1:41 UTC (Tue) by mezcalero (subscriber, #45103) [Link]

Indeed. Umlauts are for suckers. A true Poettering is written with "oe" instead. After all, I am not a Metal band.

To make this point I even invested my hard-earned money in this page:

http://pöttering.de/

(You need some German language skills to grok that ;-))

Why not Wayland

Posted Mar 5, 2013 3:42 UTC (Tue) by leightonbrown (subscriber, #6264) [Link]

so.... is X next on your list:)

Why not Wayland

Posted Mar 5, 2013 7:02 UTC (Tue) by paulj (subscriber, #341) [Link]

By "oe" you mean "œ"? So Pœttering? :)

Why not Wayland

Posted Mar 5, 2013 9:49 UTC (Tue) by micka (subscriber, #38720) [Link]

I'm not familiar with german, but if it's oe it's oe not œ (same thing the other way).
In french, we have words that are written œ like cœur and other that are written oe like moelleux.

Why not Wayland

Posted Mar 5, 2013 12:34 UTC (Tue) by chithanh (guest, #52801) [Link]

In German you don't have many ligatures. The only widespread one is ß which is a ligature of ſs or ſʒ depending on your font. And this ligature is even not used when the letters are in capitals or at the beginning of a word (like in "Szene"). A capital version of the ligature(ẞ) is now adopted in Unicode but has been mostly ignored so far.

Why not Wayland

Posted Mar 5, 2013 22:06 UTC (Tue) by andreasb (subscriber, #80258) [Link]

The German umlauts originated from the 'ae', 'oe' and 'ue' combinations. Instead of contracting them to something like 'æ', a small 'e' was written above the first letter and over time was reduced to two short lines/dots.

So basically œ and ö have similar origins and only diverged through different typographic traditions.

Why not Wayland

Posted Mar 6, 2013 7:41 UTC (Wed) by paulj (subscriber, #341) [Link]

very interesting, thanks. :)

Why not Wayland

Posted Mar 6, 2013 9:19 UTC (Wed) by tnoo (subscriber, #20427) [Link]

> a small 'e' was written above the first letter

In old German handwriting, the lowercase "e" was just two parallel, slightly inclined lines, with connecting ligatures to the letters before and after. Thus these are two vertical lines or two dots in today's handwriting, and two dots in almost all typesetting.

Why not Wayland

Posted Mar 6, 2013 16:39 UTC (Wed) by paulj (subscriber, #341) [Link]

Oh, and that then means Poettering *can* be written equivalently and correctly as Pöttering? :)

Why not Wayland

Posted Mar 6, 2013 17:28 UTC (Wed) by jwakely (subscriber, #60262) [Link]

So he *is* a heavy metal band? This is all very confusing.

Why not Wayland

Posted Mar 6, 2013 18:05 UTC (Wed) by anselm (subscriber, #2796) [Link]

You're supposed to use »oe« if the person spells their name with »ö« but you can't use the umlaut (air travel tickets come to mind).

If a person spells their name with »oe« to begin with (as in »Poettering«), substituting »ö« would be considered a mis-spelling. The general assumption is that if they spell their name like that, they prefer it like that, and it is a matter of common courtesy (rather than linguistics) to go along.

So, no equivalence.

Why not Wayland

Posted Mar 6, 2013 18:14 UTC (Wed) by Wol (guest, #4433) [Link]

In this case yes, but I don't think it's universally true.

Cheers,
Wol

Why not Wayland

Posted Mar 6, 2013 19:30 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> > Oh, and that then means Poettering *can* be written equivalently and correctly as Pöttering?
> In this case yes
No. Please read the thread. He says himself that Pöttering is not a correct spelling:
https://lwn.net/Articles/541159/
mezcalero is Poettering's nickname on lwn, in case you weren't aware.

Why not Wayland

Posted Mar 6, 2013 20:51 UTC (Wed) by paulj (subscriber, #341) [Link]

woosh... ;) (my comment was written in full awareness of that comment)

Why not Wayland

Posted Mar 6, 2013 20:46 UTC (Wed) by andreasb (subscriber, #80258) [Link]

As mentioned, 'ö' is expandable to 'oe' when you can't write umlauts for some reason. The inverse isn't necessarily true (can't come up with examples though) and especially not for names.

Names are spelled the way they have "always" been spelled and do not have to match current orthography. For example, someone called Schmidt, Schmid, Schmitt or any other variation can not simply be "corrected" to Schmied (smith) even though that's the current spelling.

Why not Wayland

Posted Mar 8, 2013 1:34 UTC (Fri) by mezcalero (subscriber, #45103) [Link]

No, my name is Poettering, not Pöttering. You can check my passport. There's no umlaut in my name.

Lennart

Why not Wayland

Posted Mar 6, 2013 23:49 UTC (Wed) by nix (subscriber, #2304) [Link]

Oh, lovely. :)

Why not Wayland

Posted Mar 6, 2013 23:49 UTC (Wed) by nix (subscriber, #2304) [Link]

FWIW, Upstart is also used by the Kindle (not that it's open enough for you to tell without some serious cracking first, but of course this has been automated and is now relatively trivial on many Kindle OS releases).

Why not Wayland

Posted Mar 5, 2013 2:24 UTC (Tue) by daniels (subscriber, #16193) [Link]

> The input event handling partly recreates the X semantics and is thus likely to expose similar problems to the ones we described in the introductory section.

It's totally wrong. And their other complaint about the shell interface is also based on a huge misunderstanding of how the protocol works. We could've told them that if they ever spoke to upstream at any stage, but I don't think it would have really made any difference - it's just back-justification for a decision made on wholly non-technical grounds. Which is fine, but unfortunately it's totally wrong, and I'm going to have to spend the next couple of years explaining to people that what they read about Wayland is totally incorrect. Shame.

Why not Wayland

Posted Mar 5, 2013 10:23 UTC (Tue) by ortalo (subscriber, #4654) [Link]

It seems they corrected their presentation now, no?

Anyway, it seems to me you should at least try to join forces on the topic of finally grabbing *complete* *non-NDAed* GPU hardware documentation from the GPU hardware manufacturers.
IMHO, that is the real thing preventing big advances on the display front.

Why not Wayland

Posted Mar 5, 2013 17:22 UTC (Tue) by ewan (subscriber, #5533) [Link]

Correcting the erroneous statements isn't entirely the point though - the other part of this is that the entire foundation of the decision to start Mir seems to be based on having completely misunderstood things, and not having bothered to ask the questions that could have cleared up the misunderstandings.

Why not Wayland

Posted Mar 5, 2013 17:27 UTC (Tue) by daniels (subscriber, #16193) [Link]

Happily they have, as noted, corrected their page. I don't think the decision to create Mir was based on any technical grounds, to be honest.

Why not Wayland

Posted Mar 6, 2013 9:33 UTC (Wed) by ortalo (subscriber, #4654) [Link]

For the USSR space station at least, that's certain! ;-)
I suppose you would have appreciated to get Canonical support on Wayland. I would too.

However, I am still stubbornly concentrated on that GPU hardware documentation issue. It's been 40 years we have CPU architectural books with full instruction sets and 20 years without anything similar for GPU 3D instructions sets. That's ridiculous and I'd like the people in charge of this stupidity at NVidia/ATI to be fired real-soon-now(tm) because they are preventing decisive technical progress and are evidently unrecoverable.

Why not Wayland

Posted Mar 6, 2013 23:53 UTC (Wed) by nix (subscriber, #2304) [Link]

I don't think this is actually true of ATI anymore. Some stuff isn't open, but enough is open (or has been implemented from closed specs by ATI/AMD people) that pretty good free software drivers now exist. (TBH, they've been more than good enough for desktop use for years: they're getting good enough for increasingly hefty games by this point.)

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 23:34 UTC (Mon) by theophrastus (guest, #80847) [Link]

"Canonical" hasn't remained very canonical, has it?

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 4, 2013 23:47 UTC (Mon) by sebas (subscriber, #51660) [Link]

Neither has Unity been very uniting, Harmony very harmonizing or bazaar really developed into that.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 0:00 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I suppose that Canonical is the canonical home of heterological projects.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 0:57 UTC (Tue) by heijo (guest, #88363) [Link]

The protocol appears to be this (it uses Google Protocol Buffers):

message ConnectParameters {
required string application_name = 1;
optional int32 lightdm_id = 2;
}

message SurfaceParameters {
required int32 width = 1;
required int32 height = 2;
required int32 pixel_format = 3;
required int32 buffer_usage = 4;
optional string surface_name = 5;
}

message SurfaceId {
required int32 value = 1;
};

message LightdmId {
required int32 value = 1;
};

message Buffer {
optional int32 buffer_id = 1;
repeated sint32 fd = 2;
repeated int32 data = 3;
optional int32 fds_on_side_channel = 4;
optional int32 stride = 5;

optional string error = 127;
}

message Platform {
repeated sint32 fd = 1;
repeated int32 data = 2;
optional int32 fds_on_side_channel = 3;

optional string error = 127;
}

message DisplayInfo {
required int32 width = 1;
required int32 height = 2;
repeated uint32 supported_pixel_format = 3;
}

message Connection {
optional Platform platform = 1;
optional DisplayInfo display_info = 2;

optional string error = 127;
}

message Surface {
optional SurfaceId id = 1;
optional int32 width = 2;
optional int32 height = 3;
optional int32 pixel_format = 4;
optional int32 buffer_usage = 5;
optional Buffer buffer = 6;

optional string error = 127;
}

message DRMMagic {
optional uint32 magic = 1;
optional string error = 127;
}

message DRMAuthMagicStatus {
optional int32 status_code = 1;
optional string error = 127;
}

message Void {
optional string error = 127;
}

service DisplayServer {
// Platform independent requests
rpc connect(ConnectParameters) returns (Connection);
rpc disconnect(Void) returns (Void);
rpc create_surface(SurfaceParameters) returns (Surface);
rpc next_buffer(SurfaceId) returns (Buffer);
rpc release_surface(SurfaceId) returns (Void);
rpc select_focus_by_lightdm_id(LightdmId) returns (Void);

// Platform specific requests
rpc drm_auth_magic(DRMMagic) returns (DRMAuthMagicStatus);

rpc test_file_descriptors(Void) returns (Buffer);
}

First of all, the use of an "optional string error" field in every returned structure (requiring all other fields to be marked optional!!!) is a telltale sign that the designer of this is an idiot, since anyone with a bit of sense and taste would use an exception mechanism in the RPC code instead and not destroy requiredness info in the messages.

Second, putting LightDM in the core protocol is similarly horrendous and weird.

Finally, this protocol has no way to resize windows, no input support, no nontrivial vsync handling, no DPI information, no subpixel layout/transform information, no apparent support for multi-GPU and multi-monitor, no window-in-window embedding support, and generally nothing beyond a basic skeleton.

It's a toy, or perhaps a joke.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 4:12 UTC (Tue) by xxiao (subscriber, #9631) [Link]

suddenly had a strong desire to return every machine(LTS) back to Debian, starting it now.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 6:16 UTC (Tue) by nhippi (subscriber, #34640) [Link]

You might want to help with RC bugsquashing to get wheezy to your machines.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 5:06 UTC (Tue) by rsidd (subscriber, #2582) [Link]

The complaints above are along the lines of

  • They haven't understood Wayland / haven't talked to its upstream guys
  • It's yet another interface that needs to be supported
  • They've underestimated the magnitude of the task
etc.

None of which is relevant, I feel. The point is Ubuntu is Shuttleworth's pet project. He became incredibly rich by being at the right place in the right time with the right service (Thawte), and has indulged himself since with a space trip and Ubuntu.

And Shuttleworth's not stupid. Very likely the reasons for not using Wayland were bogus and the real reasons are something like "We want to put out a project by 2014 and are not confident Wayland will be ready". They are willing to work to port the most common toolkits, as well as a rootless X server, to Mir. And Ubuntu has been good at implementing their ideas, be it Upstart or Unity or Ubuntu One. Unity is not universally beloved but it has fared better than GNOME 3, or, for that matter, KDE 4. Shuttleworth has a product and a timeframe in mind. He has decided that this is what it will take to get there. Good luck to him.

I use Ubuntu but not Unity (it's been i3wm for a couple of months now). Maybe Mir+rootless-X will work for me, maybe it won't, but as long as they keep xorg in the repositories, I don't particularly care what else they do :)

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 6:28 UTC (Tue) by misc (subscriber, #73730) [Link]

> "We want to put out a project by 2014 and are not confident Wayland will
> be ready".

That would be disturbing to think that, as this mean they would think that collaboration with others slow down projects.

In fact, I could see the point if Wayland didn't exist ( or surface flinger, for that matter ). But since a good part of the work have already been done, starting from scratch to go faster would be rather surprising.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 7:37 UTC (Tue) by jrn (subscriber, #64214) [Link]

> as this mean they would think that collaboration with others slow down projects.

Which is often true as far as I can tell, unless someone involved is very good at release management. Though it can be worth the wait.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 8:57 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Collaboration with existing projects to modify them to suit you needs or atleast having a conversation with them is not really more of a slow down than rewriting the entire thing from scratch especially for a key component that they don't have a lot of in-house expertise to speak of. They didn't even try to talk to Wayland developers before launching this project.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 10:03 UTC (Tue) by anselm (subscriber, #2796) [Link]

But since a good part of the work have already been done, starting from scratch to go faster would be rather surprising.

I'd guess that the people at Canonical are afraid that the Wayland people will get sidetracked into stuff that is not important to what Canonical needs, and that will hold up the project. For example, suppose the Wayland people made supporting multi-screen setups a priority. This isn't all that relevant to phones or tablets, which are the reason why Canonical is in this game in the first place.

The people at Canonical – who are under pressure because they essentially need to catch up with Android etc. in the mobile space – may think that it is faster to hack up something that supports exactly their use case without having to depend on an external project whose focus is different than Canonical's. It's not as if we hadn't seen that sort of thing before, either.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 11:14 UTC (Tue) by airlied (subscriber, #9104) [Link]

The thing is Canonical has to assign engineers to the task, if the upstream engineers aren't focused on their requirements, then their engineers can work in the project to focus it on their requirements.

It's almost like Mark doesn't understand open source development models, and the inability of Canonical to participate in any projects upstream is a great display of this.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 12:36 UTC (Tue) by pboddie (subscriber, #50784) [Link]

From a pure productivity perspective I can understand that the benefits of working with existing projects and code can be outweighed by the benefits of forking projects or having full control of your own projects, but in these latter cases you have to be well-resourced for such efforts to not be ultimately futile.

It's like watching a rider in the Tour de France break away from the pelaton half way through every stage and get caught every time long before the finish. It may make for good entertainment, but it won't win that rider anything.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 16:03 UTC (Tue) by NAR (subscriber, #1313) [Link]

Actually that gains points for the most combative rider classification, points at intermediate sprints, king of the mountains points, TV exposure and the occasional stage win. Actually this strategy makes sense if one does not have the talent to mix it with specialists - "let's try and hope it's my lucky day". If Canonical really can deliver something that works in a couple of months while Wayland gets delayed, Firefox OS crashes and Android stumbles, they might get lucky. However, I wouldn't bet a fortune on it.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 7, 2013 21:49 UTC (Thu) by JanC_ (guest, #34940) [Link]

It's like watching a rider in the Tour de France break away from the pel[o]ton half way through every stage and get caught every time long before the finish. It may make for good entertainment, but it won't win that rider anything.

You obviously don't understand the cycling sport business. ;)

It will probably win that rider a lucrative contract for the years to come, because it gives the team's sponsors a lot of media exposure without having to pay even bigger amounts of money for a rider that wins many stages or ends up on the final podium.

(And if you think it's easy to do those breakaways, check out how many riders succeed in catching the "right" one that can remain in front for a long time—occasionally even until the finish.)

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 6:37 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> Very likely the reasons for not using Wayland were bogus and the real reasons are something like "We want to put out a project by 2014 and are not confident Wayland will be ready".
The Weston project is very open to contributions, so Canonical could just pay developers to add whatever functionality is needed to Weston. And if that doesn't work out for whatever reason, they can write their own Wayland compositor and add whatever protocol extensions they deem necessary. There's no reason to believe that developing their own display server will save them any time, to the contrary.

The real problem with Canonical is that they ultimately have the mindset of a proprietary software company. They require copyright assignments for no good reason, they develop proprietary software (the Ubuntu One Server), they develop things behind closed walls, they suffer from serious NIH and they generally seem to focus on competition instead of cooperation. I personally just encourage people to switch away from Ubuntu due to this attitude. The Linux ecosystem would be better off without Canonical.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 5:25 UTC (Wed) by Serge (guest, #84957) [Link]

> so Canonical could just pay developers to add whatever functionality is needed to Weston. And if that doesn't work out for whatever reason, they can write their own Wayland compositor and add whatever protocol extensions they deem necessary.

Or they could use DirectFB and patch ilixi compositor to their needs. On the other hand Wayland people could also write X11 protocol extension instead of reinventing X11 into core Wayland + bunch of compositor extensions.

It's kind of fun to read how people were excited about new Wayland announcements and how those people now worry about "one more windowing system" and "what should Steam@Valve be now developed for".

If people really cared about Linux being successful and attractive for developers they would stick to common stable solutions, i.e. Xorg, and try making it better.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 9:25 UTC (Wed) by tnoo (subscriber, #20427) [Link]

The Wayland develpers are mostly the Xorg developers. So they are not re-inventing the wheel, but are working hard to develop a round, smoothly running wheel instead of the established roundish thing with bumps, spikes, and struts and in all directions that is Xorg.

No-one seems to have asked...

Posted Mar 5, 2013 5:48 UTC (Tue) by tristanb (subscriber, #85904) [Link]

No-one seems to have asked the most important question: will Mir have network transparency? ;-)

No-one seems to have asked...

Posted Mar 5, 2013 19:59 UTC (Tue) by daniels (subscriber, #16193) [Link]

Yeah, I'm pretty disappointed about that.

No-one seems to have asked...

Posted Mar 6, 2013 9:36 UTC (Wed) by ortalo (subscriber, #4654) [Link]

What about Wayland, will it have network transparency?

Hey, we are on LWN... ;-))

No-one seems to have asked...

Posted Mar 6, 2013 10:41 UTC (Wed) by renox (subscriber, #23785) [Link]

> What about Wayland, will it have network transparency?

I know that you're joking but if I understand this(*) well, there is a patch for network transparency(RDP) submitted for inclusion in Wayland.

Now, the remaining question is/will be: is Wayland "native" network transparency as good as using NX/X in a WAN?

Of course as long as the toolkits keep an X backend, you can also use NX over XWayland over Wayland if the native Wayland network transparency isn't good enough in a WAN.

*: http://www.phoronix.com/scan.php?page=news_item&px=MT...

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 8:00 UTC (Tue) by alexl (subscriber, #19068) [Link]

Wayland and Mir developers chat for the first time about Mir:

http://pastebin.com/KjRm3be1

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 12:00 UTC (Tue) by rodrigorc (guest, #89475) [Link]

> Closed source driver support is still being worked on, with Canonical saying it is talking with GPU vendors about creating distilled, reusable, cross-platform EGL-centric drivers in the future.

Maybe this means that in the near future, Wayland/Weston could be run with closed source drivers, too. IIRC Weston uses EGL to talk to hardware, doesn't it?

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 19:59 UTC (Tue) by daniels (subscriber, #16193) [Link]

> Maybe this means that in the near future, Wayland/Weston could be run with closed source drivers, too. IIRC Weston uses EGL to talk to hardware, doesn't it?

Yes, it's entirely self-contained within EGL. Wayland already runs on a number of platforms with closed-source drivers (including, but not limited to, OMAP4 support being at least as good as any other platform).

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 14:38 UTC (Tue) by robert_s (subscriber, #42402) [Link]

One wonders whether it's really a good idea to name it after a space station that the Russians abandoned and allowed to burn up once they decided that going it alone on something as complex and expensive as a space station wasn't really practical.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 15:47 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Mir was designed for a lifespan of 5-7 years, yet it lasted 15. If anything, it was an enormous success.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 23:10 UTC (Tue) by robert_s (subscriber, #42402) [Link]

(I know I know but still...)

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 8:41 UTC (Wed) by jezuch (subscriber, #52988) [Link]

> Mir was designed for a lifespan of 5-7 years, yet it lasted 15.

AND the ISS is basically a clone of Mir with more bells and whistles ;) So while Mir is gone, its legacy lives on.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 5, 2013 21:50 UTC (Tue) by ssmith32 (subscriber, #72404) [Link]

Yes, maybe they should have called it Skylab instead... oh wait.. ;)

Take care,
-stu

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 17:23 UTC (Wed) by man_ls (subscriber, #15091) [Link]

It was an incredible achievement that placed them ahead of everyone else in the space race, when the URSS was the underdog. Perhaps it is metaphorical after all... even if Shuttleworth wants it to kickstart an IIS project where there is more international collaboration.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 18:18 UTC (Wed) by Wol (guest, #4433) [Link]

Mir is also Russian for "peace" (Voina e Mir) and "the world".

Cheers,
Wol

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 6, 2013 7:16 UTC (Wed) by geuder (subscriber, #62854) [Link]

Does anybody remember the last big announcement: http://www.markshuttleworth.com/archives/551

I think the discussion then was they would not be able to make it for the 11.04 release, but 11.10 if all parts are ready. In hindsight we know that the parts weren't ready...

Mark being a schedule driven person obviously lost his patience when the estatimated time to complete the job has not changed a lot during the last 2 years and saw himself forced to do something else.

Will the parts for Mir be in place before he feels the urgent need to change the course? Hmm, at least it would be a small miracle if it's ready faster and reasonably good.

Canonical reveals plans to launch Mir display server (The H)

Posted Mar 9, 2013 21:44 UTC (Sat) by jspaleta (subscriber, #50639) [Link]

I think Canonical's previous experience starting their own in-house projects is now long enough to give everyone enough information to make their own judgments with regard to whether Canonical can pull this off or not in the time frame critical for Canonical, which is to say the 14.04 LTS release. There is a game clock ticking away.

I look at the history of Unity and I have some pretty grave concerns about Canonical being able to execute well enough to make this happen in the time that the have. Mir and toolkit support for it has to be ready for OEMs to trust by 14.04 or Canonical is absolutely screwed.

As an idea, Unity, has seen 4 _different_ public codebase implementations in the span of 2 or 3 years. Mutter, qt4, compiz plugin and now qt5. Do you remember the big reveal that Canonical did with Dell for the very first Unity/Windows dual boot demo based on the mutter-derived Unity? Do you remember how quickly everyone backed away from even walking to talk about that implementation and Dell's plans for it? I do. Oh I do.

Now it looks like compiz is dead as a project as Canonical was carrying the burden of maintaining it just to keep the Unity plugin alive. From accounts I've read, compiz as maintained for Ubuntu is no longer taking contributed enhancements because Canonical's engineering team is full-in on the qt5 Unity codebase.

None of the Unity development history says to me that Canonical is going to get Mir right on the first implementation. I sure as hell hope that what we are seeing made public is not the first implementation with 2 years to go on the clock to execute a workable solution. Canonical is definitely does better with iterative failure as a roadmap to improvement.

To the great horror of Monty Python fans, I must admit that when I think about Shuttleworth explaining the history of Unity, I think of him saying the following:

"When I first came here, this was all swamp. Everyone said I was daft to build a user interface on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that's what you're going to get, Lad, the strongest user interface in all of Linuxland."

The only question I have is how many manhours can Canonical put into Mir in order to speed up the process of build/burn/fall/sink/rebuild of the first couple of implementation attempts. 8 months of private development, are we seeing the 4th implementation of Mir or the 1st?

Personally I'm going to be watching linaro's response to Mir very closely. How soon will linaro pick up Mir and try to test it against their existing ARM hardware validation matrix? And how will the public linaro discussion over mir development through all of this year go?

-jef

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds