They implement only what they want, how they want (full-blown automated testing) and get to dictate the direction of the display server which is critical for Ubuntu across devices.
Upstreams don't always share the vision and often do things that don't align well with the distro. Remember Nautilus changes a couple of cycles back. I'm not saying Gnome devs did anything wrong with Nautilus, but pointing out how it was a big pain for Ubuntu developers/users.
I believe you have to control all the critical parts of your product and not live on the mercy of upstreams.
Canonical is not here to donate resources to help make your linux ecosystem better. That is only a side-effect of it being a member of that ecosystem. Canonical's primary goal is to create a awesome product that can disrupt multiple markets so I would say it makes perfect sense for Mir to exist.
The free drivers like Nouveau are way behind what they should be. The reason is that there is no commercial interest for companies to create good GPU drivers on desktop linux. Nvidia is not contributing to wayland and so on.
In Android, there is.
So the situation is this, iOS already has fantastic GPU support, Windows 8 and Android have too. Desktop Linux is behind the curve.
You can't make so many things in the desktop because you can't assert GPU accel.
So Mark wants to change that with with what already exist.
They are not that well documented, but they work ok, because if not, the manufacturer does not sell the device.
Mir inherits Android graphic system on purpose.
In wayland you need Open drivers, like Nouveau which are very slow as the power management is not complete, or they are not sure enough to activate it(it could toast thousands of cards): http://nouveau.freedesktop.org/wiki/FeatureMatrix/
The life of those developers is hard, all day fixing bugs, and new bugs appear like it is never going to finish(you don't see the light at the end of the tunnel).
Or is all of this just because the Wayland and MIR developers only want to use open-source drivers?
I didn't know that, makes sense. That said, Mesa appears to provide EGL on top of GLX, which probably isn't as efficient as a driver that directly provides an EGL interface, but likely 'good enough' for basic desktop rendering. So I still don't really understand why I would need Nouveau to use Wayland or Mir.
For me, using Nouveau would be a definite showstopper for whatever new display server becomes the default in Linux distro's. Not to talk down the efforts of the Nouveau developers, but I only have bad experiences with the driver, ranging from crashes, screen corruption, unbootable installations, terrible performance and loss of indispensible features such as proper multi-monitor support and hardware video decoding. One of the first steps in installing a new Linux system on Nvidia hardware is usually to remove, purge and blacklist Nouveau, and install the closed driver, because that just works (tm). I'd even use software rendering over llvmpipe before I'd consider Nouveau.
If the future of the Linux desktop on Nvidia hardware requires a reverse-engineered GPU driver that lacks all the features provided by the closed-source driver, we can postpone the 'year of the Linux desktop' for at least another decade.
In any case, there's no fundamental design flaw in Wayland; this just seems like a common case of NIH.
Except that window management is tightly coupled to display management.
The Mir developers seem to at least seem to care about software modularity.
Yes, it is, both in general and in Wayland.
Specifically, what would once have been called just a window manager now needs to be a compositing manager, managing window contents and compositing them onto the screen. That compositing manager also needs to handle input, since input depends on where, how, and if windows are rendered. And once you're handling all of that, there's nothing useful left that corresponds to an X server other than graphics memory buffer management, which is the kernel's job these days.
Wayland handles software modularity by providing a library for use by prospective compositing managers. Moving the compositing manager into a separate process from the thing actually doing the rendering does not add a useful form of modularity.
Citation? X11 window managers are decoupled from the rest of X and the OS by well-specified protocols.
That compositing manager also needs to handle input
Oh yes, I forgot how Wayland couples the WM to the OS as well.
Wayland handles software modularity by providing a library for use by prospective compositing managers. Moving the compositing manager into a separate process from the thing actually doing the rendering does not add a useful form of modularity.
1) Can you point me to an API specification for Wayland compositor libraries? If not, it's not decoupled.
2) Can one switch window managers without restarting the compositor (and thus losing window state) with Wayland? If not, it's missing a "useful form of modularity" provided by X11.
Software modularity is overrated, but in this case I think you got it wrong.
Most likely some patches to wayland would be enough to get what they wanted - instead now we have more fragmentation.
I do wish Chrome didn't exist, but I'm not convinced that this comparison works.
In addition to what @ergo14 said, Firefox had a JIT compiler called SpiderMonkey before Chrome was even released [1]. With that said, I'm sure there's cross-pollination both ways between OdinMonkey (Firefox's current JIT compiler) and Chrome's JIT compiler in V8.
My understanding of the GPU vendor world is that generic Linux GPU support is way below the priority given to Android. This isn't to say that there couldn't be some alignment/commonality for a driver in Linux or Android, but Android will get a lot more testing and biz focus.
The Wayland and 'open software community' GPU advocates either have not considered this, don't care or hope that GPU stack implementations will move towards their world rather than Android's. Although ironically the licensing for Wayland and libdrm and whatnot are MIT rather than GPL like Mir.
And while you may feel as though Mir's only aim is to fragment the Linux community, keep in mind that Ubuntu will be using QML extensively and that will be compatible with Wayland, and through the use of libhybris both Mir and Wayland can target the same display driver.
Supporting the idea of the jour has development costs.
I'm sorry, how was that? My recollection seems to be that they all got stale and overpriced, and then GNU/Linux ate their lunch.
Today, most of these projects are FOSS, so the risk of another '*nix war' has been negated to the point of being a non-issue.
Go tell that to the users that are not on the few chosen distributions for commercial vendors or without ready made packages on their repositories.
Or the BSD guys that are being left out with some desktop stuff being slowly tied to Linux systems.
All this happens because developers choose to leave out support for certain systems in order to minimize development efforts.
And in regards to the BSDs, what exactly are you referring to? If it's Wayland, that's being ported. If it's KMS drivers, Intel has been ported and radeon is in the process. Nouveau probably won't be ported due to the fact that they already have a pretty stable binary Nvidia driver.
The only two things I can think of that aren't compatible with BSD have both been designed with exclusively Linux by the developers heading those projects, SystemD and ALSA, and even then the BSDs already have suitable substitutions with those, init and OSS.
So, since there's greater cross-compatibility than ever before, how would you suppose that another nix war would erupt?
Mir's only aim is to fragment the Linux community
That Linux community is further fragmented within itself.
The BSD community is decidedly less fragmented than the Linux community.
At this point, who cares what Ubuntu does? If they come up with some better ideas, then those ideas may gain traction within the greater Unix community, and if not, I don't care.
It creates lots of extra work for people who do not run Ubuntu. It will result in extra bugs as things cannot be tested. "choice", short-term benefit of trying to be first. Long term it seems really bad.
As the old adage goes: FreeBSD is what you get when Unix developers get together and create a Unix-like system for the PC platform.
Linux is what you get when PC developers get together and create a Unix-like system for PC.
FOSS will fragment because people have different opinions and are passionate about the choices they make in the software to create and use. There is no alternative, because in free software the developer has last say. There is no school of "the one way" of how to do anything in foss, the only possible proxy being the popularity of the software created.
I think BSD's success with i386 has brought the stark pragmatism of the "server" to the PC. The dream of BSDI. The reliability, robustness and the uniformity. Maybe BSD UNIX is not as "fun" as MS and Apple, but it _works_ the best. Relatively minimal bloat. And things can be removed relatively easily. Getting small is not frowned upon or ignored as a worthy objective. "The hero is the negative coder." (credit: Doug McIlroy, one of the original UNIX developers)
Linux OTOH (a horde of wannabe kernel hackers and a gazillion idiosyncratic GNU programs) has brought the chaos of the PC[1] to the idea of "UNIX". There is bloat and endless tweaking around every corner. The vigilance and skill it takes to make your Linux small and simple and actually keep it that way is, IME, quite the burden. The respect for the user also differs. Man pages? I guess the assumption is we'll just read the code when we have a question. But then there's also an expectation we'll use binary packages. Linux just makes my head spin. I'm just not smart enough to use it. I wish I was... because they have better hardware support.
Based on what I've seen, I doubt many a Linux developer would think "The hero is the negative coder." Linux just keeps growing and becoming more complex and unwieldy. And so by comparison, IMO, Linux less embodies the idea of UNIX than BSD.
1. The Windows experience of constantly searching for some non-MS program to do some task that base Windows itself can't even begin to handle... and you end up with an ad hoc mess of programs that barely do what you need, and most of them poorly written by who knows who.
As far as bloat, some BSDs are more elegant, but I do not think Linux is that bloated. It is small enough to succeed on embedded systems and Androids. The device driver section is bloated, but the core system is not as bad.
Yes, Ubuntu is not small and simple, but Debian is if you want it to be.
Right. (In fact, it can succeed anywhere. And it does.) But my point is that it's not _presented to the user_ in a form that makes reducing it to embeddable size or porting it to ARM easy. I compile my BSD systems from source. And small modifications are (compared to Linux) easy.
Linux From Scratch (LFS) and Busybox were the closest I saw to what I was looking for. But when you look at the Linux ecosystem, LFS seems so obscure. And how many people create their own customized Busybox? To pursue these objectives with Linux feels like moving against the grain. No one aims to assist you by making the system easy to comprehend and modify.
The people I see modifying Linux at the level I would want to modify it are just too far beyond my comfort level with C and assembly. I can't do what they do and believe my system will still be reliable. Not only that, it would take forever to do it. I'm just not smart enough to use Linux. As I said above, it's just too much work.
I'm not worried about fragmentation though.
My position is that currently X "Just Works" for me and I am not willing to sacrifice this stability so that I can test out the pet projects of a bunch of Red Hat and Canonical employees. I figure I have at least 3 years, hopefully 5, before I will be forced to switch. (3 years left on wheezy, and hopefully 2 more years with jessie assuming X is still the default and viable). 3-5 years to let them work out all of the kinks? Yes please, I'll take that.
The dust sure as hell better be settled by 2018.
I believe that a previous poster commented about 300, or so, different distros based upon 4 base systems.
We already have multiple mutations of the various operating systems, and now we've got another display manager to debug?
You can see many non-working things here: http://laptop.bsdgroup.de/freebsd/ from no sound to can't boot. Power management is also notoriously bad so you need your laptop to be plugged in.
It is reminiscent of Linux a few years ago when everyone with brand new laptops tried to install it.
FreeBSD is still fine on desktop systems and even works quite well for a desktop in some cases, but Linux is just so big at this point that it supports more things, while FreeBSD has always seemed more server oriented.
Apparently you have not tried FreeBSD on an Acer Aspire One netbook, because if you did you would realize that your last paragraph is outdated by at least 3 minor version iterations. I first tried PC-BSD 8.x in 2009, and with KDE as the default DE it unusably slow, but when I tried FreeBSD 8.x last year I was pleasantly suprised with how well the system ran on my little netbook. Then, when I upgraded to 9.0 I realized that I had finally found what I had been searching for all these years. Now, with 9.1 the system is even better.
Yes, FreeBSD lacks some features that Linux has, but it's still being developed and it has its uses outside of the server market too. For example, Sony is reportedly using it as the core OS for the new PS4 and there's a project that is aiming to create a HUD device which is also based on FreeBSD, http://hmdviking.blogspot.jp/
It was a lot like Linux used to be in the late 90s though... I tried to put it on a few other machines with less success.
Crunchbang just doesn't compare as far as speed goes. I tested both OS' with Xfce4.1, as well as no DE with dwm & dmenu. In each case FreeBSD blows crunchbang away, and this is on an Intel Atom N270 with 1 GB RAM.
The only thing #! has going for it is ease of setup, but FreeBSD isn't that hard to setup and use, and all questions I've had are easily answered by reading the FreeBSD Handbook.
Some will decry FBSD's support for suspend/hibernate, but since I never use those features it's a non issue for me. That said, I do believe that suspend, etc, is working for some laptops, although YMMV.
| Some will decry FBSD's support for
| suspend/hibernate, but since I never
| use those features it's a non issue for me.
Sometimes the simplest things are so abstruse to some of us.
Are you able to at least suspend to disk?
On the flip side:
- Using suspend-to-RAM is less secure.
- Enabling secure swap (at least on Linux with in a password-less setup[1]) doesn't work with suspend-to-disk.
[1] In a password-less setup, there is no way to recover the swap after a fresh boot since the key is regenerated on every boot (at least it was the case the last time that I manually setup encrypted swap).
Mir and Wayland seem to be pretty related though. Same gaps that Wayland has (needing development time) also are with Mir AFAIK. So once fixed for Wayland, Mir will have it easy :P
Note that real Mir support is only planned for 14.10. At the moment it is just XMir, which is totally different from the what is going on with Wayland (goal is native, this is way more difficult). I have seen the development that is needed to get Wayland really working, Mir seems way behind on this though they probably can copy what was done for Wayland and pretend they did it :P
"Fragmentation" is another name for "diversity". Diversity and selection are key factors for healthy evolution and a key advantage of open-source.
http://mer-project.blogspot.fi/2013/04/wayland-utilizing-and...
http://mer-project.blogspot.fi/2013/05/wayland-utilizing-and...