same for the risk of making questionable design choices in a modern project
example - at the beginning, wayland was envisioned so that the server would only contain a window stack and receive hardware input firsthand, and
clients would handle EVERYTHING regarding their windows - not only (re) drawing their own decoration, minimizing and maximizing, but also dragging and moving in full screen coordinates (their window being a full screen surface anyway, optionally surrounded with transparent pixels) stacking order (implying access to the global window stack in the compositor) forwarding click events to other clients and so on - a concept making the system as a whole more fragile (every application participates in the protocol and acts as a point of failure for every operation) and going against the principle of transparency above
would you agree with this design?
to be precise, *display* technology is what comes out of intel, amd and nvidia, or SGI, Matrox, E&A and the others back in the day - X and wayland are about UI technology, consumers of display technology but not really at the same logical or sofistication levelYou seem to be confusing display technology
they are not one and the same (obviously), but they have to go step by step by a certain extent - as times change and what's the perfect tool for the job now may not be tomorrowand programming technology.
so a good professional is ready to change tools and development languages and adapt
i develop 3d games and say they have all the same chances, and though not trivial, it's not out of their reach, either (as the main loop of a wyland like display server - what other OS's historically called "app-servers" - isnt all that different from the mainloop of a game, plus some specific requirements that need some thought but *can* be gotten right)Wayland developers are experts in display technology, while Mir devs are not (and no, it's not trivial).
you say the contrary - fine, on what basis?
Sure, someone could probably cobble up a rudimentary display system with not much problems (Surfaceflinger... oh, I kid, android devs), especially for a homogenous system where there are not many, diverse use cases. But when you have to develop a protocol that is stable, sleek, and customizable to suit diverse needs ranging from mobile/embedded to desktops to workstations and render farms - that's a whole another issue. When you have to consider things such as colour management, buffer allocations, various pixel formats, etc. Go look at the Wayland mailing lists and see the amount of work that goes in every detail - these guys are very thorough, they don't want to rush it and create an inferior system that causes problems down the line.
Weston has very little to do with it since it's only a reference compositor, not meant for production use in actual DE's... Wayland != Weston, Wayland allows anyone to reimplement the protocol with their own compositor and use whatever language and all the test-driven programming and server-side buffer-allocations they want to do it.stop with this already...
you'd be right if Mir were reusing code from weston - but unless you prove otherwise it's not
Then if we go to other parts of the stack, XMir is a direct copy of XWayland, only adapted to use Mir as a backend instead of a Wayland compositor - and patched to allow running rooted in order for Canonical to use it as a "clever" way to run X DE's - purely a PR move, so that the rubes and fanboys can say "see! Mir is already running! they're faster and better than Wayland!". Libhybris was also developed by a Jolla employee, originally for Wayland - which Canonical took and adapted to use for Mir.
And like I said, there's a lot of work done outside of Wayland, in lower parts of the stack, that were necessary to make it possible to create a modern display system. Without that work being done, Mir couldn't exist, either.
There's a bit more than that, really. Mir is entirely unnecessary, there's nothing it does that couldn't be done with a Wayland compositor.so the only thing they have in common is they are both compositing display servers doing away with X, which is quite vague
So? We don't see them in use anywhere. If they were any good, if they were viable alternatives for X, we'd be using them.moreover, there are at least two legacy (X11) -free gui servers, based on the mechanism of compositing, that predate Mir by a decade and Wayland by 5 years, and exploiting gpu capabilities (use the gl pipeline to render the desktop) is in the talk in the linux scene since at least 2004
Not so, and shows you don't really understand the tech... Wayland fixes many of the shortcomings and design flaws in X. It's also backend-agnostic, so that it is very flexible and can be used in diverse environments. And the thing is, you can say all you want that "someone could have done the same", but that's just a post-hoc rationalization - the truth is no one else did, and if there had been a better alternative in existence, there wouldn't have been any reason to create Wayland in the first place.moreover, wayland in itself is nothing special technically - doing away with X separate processes and round trips was the most logical thing anyone would do muche earlier than wayland - the problem has always been more with ecosystem inertia due to the mass of x based software
Pointless speculation. There was a need for a new display system, and Wayland was born.had wayland not existed, it's not like nothing else would have ben born - someone else would have taken on the duty to port compositing from OSX and Longhorn to the free sw world, under a different project name
Before I read it, is the writer of that page the author of the largest software project in the world, a kernel that is the most popular OS kernel in the world, used in more diverse environments than any other, with code quality that is hailed as excellent by all the experts? If not, I'm likely to take Linus's word over theirs.dont need to ask, i perfectly know - so what? his words on C++ are utterly biased, all but pragmatic bs
do i need take for dogma? no thank you .. read this http://warp.povusers.org/OpenLetters...oTorvalds.html and come back
Plenty of very good projects that don't need test-driven development... get over it, it's one method, not a panacea for all the programming problems of the world. Not suitable for every project, even.it's worse than others in that it's not as fun, and you have to write twice (or more) as much code, actual code + code for intended behaviour + (ideally) code to check against unintended behaviour (or that wrong states or inputs are handled correctly)
its' better in that you can stay assured that you have a consistent and working code base (granted all tests pass) at avery iteration - and, by breaking down individual features into tasks and subtasks, and implementing each atomically with the minimal possible code, that a project may build up features quicker
Besides that, other than libwayland, which is very sleek and light in code size in the first place, you can write your own Wayland compositor and use whatever-driven development you want.
You're the one who touted tdd as the best thing since sliced bread, or at least an advantage of Mir, yet now the best you can say of it is "it doesn't make it worse"...first, tdd is a development methodology - in itself it's ortogonal to the scale (business vs hobbyist) - in fact, it's something that may benefit a individual developer more because an individual may not have enough resource to devote in QA (which may well require an order of magnitude more effort) after hacking together the code
second, it doesnt make it worse, either - if anything, it's better for you to know about it if you apply for a position with certain companies
third, in several contexts the scale is what defines the level of professionalism involved with something, in the eyes of IT and non IT people - as a matter of fact "world class" is how a quality product is usually labeled, in contrast to "amateurish" ...
fourth, mostly the same criteria apply to proprietary as well as free/ open source software (openness and/or ethos are another characteristic which is orthogonal to the methodology)
If you want to talk about "world-class" professionalism, Wayland is backed by corporations much larger and much more profitable than Canonical - Intel and Red Hat. There are professional, paid programmers involved in the project. Intel has interest in Wayland because they plan to use it in Tizen, which brings in Samsung as another interested party. Red Hat will use Wayland in RHEL 8.
No, but no-one's claimed that.not always inferior, either..
The Linux kernel was also <i>born</i> in the spare time of a single CS student. It has grown since... and while there are commercial interests, they do not dictate the direction of development, and do not cause compromise in user freedom. Largely this is because of the GPL license, which allows corporations - even competitors - to collaborate without worrying about others gaining an edge from their work.the linux kernel has very big commercial interests behind it, it's not really in the same league as what the wayland project (born in the spare time of a single employee) has been for the most of its life and still, to a certain extent, is
Wayland was also grown since it was born, it's now being backed by Intel and Red Hat. Both have a lot more money than Canonical.
I just said it seems that way. Loosen up.i dont make assumptions on why you are the way you are, please dont make assumptions on what i read, either
By the same logic, if you make each module robust, then the whole is robust.so, make that one robust (and it's not impossible) and the whole is robust
If that's how you feel, fine, Wayland itself doesn't prohibit doing just that - all it requires is you to have a compositor to which clients talk according to the Wayland protocol. The compositor can be anything - it can be a window manager, a shell, a server, or all of above.with separate components you have to make sure A, B and the protocol interconnecting them, are robust, first individually (unit) then when put together (integration) - separate components actually mean higher complexity and failure probability , leading to higher debug times..
(SW development 101)
Modularity also allows higher customization - it's the Unix way, do one thing and do it well.
Nicely said "in some cases"... The kernel has kernel modules, which you can pick and choose according to your needs - that's modularity. It's right in the name, module -> modularity.btw, interesting how you dont have a problem with the kernel being precisely a big chunk (>1 GB in some cases) of privileged code...
That's why the core protocol of Wayland and the library that implements it is streamlined and robust - less chance for a failure in Wayland itself. Wayland places no requirements to how the rest of it is implemented.not that the display server, the compositor and the shell being separate processes under X, helped much in that regard.. if the x server crashed, all clients were terminated too and the system restarted, with your previous work, lost..
the problem is not in the probability of a server crash - any software will crash soner or later, unless it's so simple and thoroughly verified that it wont- the problem lies in how the crash is handled
but that is an orthogonal matter to the server being integrated or not - and graceful recovery can be implemented also for a server integrating the shell
Wayland is transparent to the client - the client just speaks the Wayland protocol, draws to a buffer frame by frame, talks to the compositor to figure out how the buffers are allocated and such - in most cases, it doesn't need to care about other clients at all or know what the compositor is doing. The client doesn't even need to know where the surface "physically" (on the screen) is that it is drawing on, it's entirely up to the compositor to decide what to do with the surfaces and how to arrange them, all the client needs to know is "the buffer is here, draw to it" and it can trust the compositor to handle it getting on the screen, and each frame getting there in correct order.ideally, the window manager / display server is transparent to applications and these would run without being aware of it and of each other (like processes run in a virtually flat memory space without being aware of each other or of the kernel scheduling them)
even if that's not the case and some interaction between application and server is involved (at least for details such as input event forwarding, drag and drop and window min/max/resize -), you do realize that there's only so much protocol needed to accomodate a desktop, dont you?
Because Wayland will be used in diverse environments, and this gives developers a way to implement new features that they need without the need to get their patches committed to Wayland itself - if an extension becomes widespread enough or otherwise useful, it can then be added to the actual protocol.so please give a valid reason for why extensibility is needed (leading to multiple code paths in the server AND applications / toolkits, to fallback in the case of missing extensions either side / mismatched protocol version) that is not a vague "eh but the future you dont know..."
Most average clients won't have to worry about extensions at all, as all the features that most clients need are right there in the protocol - but in case special needs arise, the option is available. A client that is smartly written wouldn't want to depend on extensions that aren't widely used. Desktop environments, however, can use the extensions to implement their DE-specific tools and parts of the UI.
Preparing for the future is smart, because tech moves on constantly.
That's the point, it means that no one else can use Mir, other than Unity. It's not a viable solution for anyone else, whereas Wayland is meant to run everywhere, for any configuration or platform.considering the above - the gui should be as transparent to applications as possible - and the fact Mir merges the WM with the shell, there's little need for something beyond a mir specific api for stuff like theming, input methods, the notification area, WM and DnD...
Wayland otoh needs a protocol, having to support a different architecture (with possibly interchangeable shells , input methods and so on)
Yeah, thing is - if you customize Mir, there's no guarantee that it will remain compatible with Canonical's version, as they have explicitly stated that they will not go out of their way to maintain compatibility with reimplementations if they appear. So you'd in practice either have to constantly play catch-up with upstream, up to their whims - or you'd deviate from the original, not care what they do, and at that point you'd be creating a whole different, incompatible display server - so what was the point again, might as well have used Wayland...not having a protocol to develop against doesnt mean something is infeasible, it just means that the target is shifted - instead of developing at the protocol level for something that your application shouldnt know about, as you 'd do for wayland (to develop a compositor other than weston, out of process input method modules, or shells) you develop a mir plugin, or theme, or cutomize mir itself
Or if you want to implement a Mir plugin - well, you face the same problem, they can change the API at any time and you have to play catch-up.
Whereas, Wayland promises a stable API and protocol, both client and server side, so you can write a compositor against the current Wayland protocol and be sure that it works with any future versions, guaranteed. So the choice for all desktops is pretty much a no brainer, why would anyone even consider using Mir? DE developers aren't idiots, they've considered the options, and every one of them is going for Wayland (except if they want to stay with X for now). No one wants to use Mir, and the reason is obvious... no one trusts Canonical, who tend to "change their minds" and forget promises and outright lie when it suits them.
but WHO ARE YOU to tell someone to "stay quiet"?
in a forum the only ones who can say something like that, are moderators (and even them, only with good reason - and i know, having spent 5 years on moderating a section on the largest italian IT forum) so i ask again: who are you, and what kind of authority are you invested with, to arrogantly silence someone you dont agree with?
there's a saying here: give respect, you' ll earn respect - don give respect, earn nothing
work on DRI and KMS wasnt done ONLY by developers you now find on wayland - devel (many people on that mailing list are developers that debuted into desktop development with the wayland project - in some cases like proposing obviously kludgy and or inefficient solutions, their lack of field experience is manifest) - at the same time, not all X/mesa developers passed over to wayland ...What Wayland devs where doing the last 5 years is preparing everything (the kernel, mesa, ...).
but it doesnt matter, what matters is that it was work that had to be done anyway - not doing it would have meant not having anything to counter WDDM (yes, the architectural and driver model part of windows, what makes compositing possible on the most deployed desktop os) with, and sticking with AIGLX forever
but apart from that, i suppsed work done in a central component (like the kernel) is meant to benefit ANY other project running on the kernel, not just ONE specific one .. nowhere is written that the wayland project shall be the sole (not only a privilged, but the only one) consumer of the API and mechanisms implemented by developers who worked on mesa (before the advent of wayland)..
btw, did you know that, while now it seems obvious and granted that wayland would be the spiritual and actual successor to X, it was neither when it started?
one may be right in saying that canonical is building a product to its own advantage, not out of "love for the community" - but then, what use is all the hatred? for someone who wants to do with as little effort as possible (if it's actually the case) for sure it's not an incentive to help .. on the contrary, it may only cause more reaction spitethe same counts for XMir but the "professionals" at Canonical seem to ignore that (instead of helping DRI3).
("my product is targeted to people who wants something that just works, they wont care if i dont go out of my way to help infrastructure projects i'm not *obliged* to help - as long as it works... fanatic geeks will get mad at me, but that doesnt matter, since they're not my target..")
Last edited by silix; 08-14-2013 at 01:56 PM.
I didn't tell you to "stay quiet", I told you that sometimes it's better to be quiet to not look like an idiot.but WHO ARE YOU to tell someone to "stay quiet"?
Where exactly did I say that? What I said was that the wayland developers worked on it to make it ready for a modern display server.work on DRI and KMS wasnt done ONLY by developers you now find on wayland
Nice that you try to lay some things in my mouth I never said...at the same time, not all X/mesa developers passed over to wayland ...
Not for X.org - X.org was a death end. Now for what if not X.org did they do it?but it doesnt matter, what matters is that it was work that had to be done anyway
Compositing support was not done for Wayland, that's where you're right. But that doesn't make my points invalid.not doing it would have meant not having anything to counter WDDM
Why do we talk about AIGLX now?and sticking with AIGLX forever
But it was done with one specific project in mind.but apart from that, i suppsed work done in a central component (like the kernel) is meant to benefit ANY other project running on the kernel, not just ONE specific one
Did I say that? I don't think so. All I tried to tell you is that Mir is direcly dependand on that ground work and cause of that you can't compare development of Waylnd and Mir. If these things weren't done for Wayland Canonical would have to write them right now. Go give them the graphic stack we had 5 years ago and tell them to implement Mir on it. I would bet that they fail.nowhere is written that the wayland project shall be the sole (not only a privilged, but the only one) consumer of the API and mechanisms implemented by developers who worked on mesa (before the advent of wayland)..
What exactly does this have to do with the discussion we're having? Want to look cool?btw, did you know that, while now it seems obvious and granted that wayland would be the spiritual and actual successor to X, it was neither when it started?
If they would want to do as little work as possible they would have written a Wayland compositor. There's no technical reason for Mir. The only thing it does is slowing down everything.one may be right in saying that canonical is building a product to its own advantage, not out of "love for the community" - but then, what use is all the hatred? for someone who wants to do with as little effort as possible (if it's actually the case) for sure it's not an incentive to help .. on the contrary, it may only cause more reaction spite
Fine, Wayland "just works". So why we need Mir again? And for not the target: You do realise that Ubuntu needs "the geeks" as it is a Linux OS (so almost everything they use is made by "the geeks") ?("my product is targeted to people who wants something that just works, they wont care if i dont go out of my way to help infrastructure projects i'm not *obliged* to help - as long as it works... fanatic geeks will get mad at me, but that doesnt matter, since they're not my target..")
Also: When you write a game and want to use some 3rd party library would you use it when the developers of it say "right now it's more of a POC and not production ready" just because in your eyes it "just works" ?