Intel, Red Hat Working On Enabling Wayland Support In GNOME 168
sfcrazy writes "After shooting down Canonical's Mir, Intel and Red Hat teams have increased collaboration on the development of Wayland. Developers at Intel and Red Hat are working together to 'merge and stabilize the patches to enable Wayland support in GNOME,' as Christian Schaller writes on his blog. The teams are also looking into improving the stack further. Weston won't be used anymore, so GNOME Shell will become the Wayland compositor. It must be noted that Canonical earlier committed to supporting and embracing Wayland. Despite that promise, the company silently stopped contribution, and it was later learned that they were secretly working on their own display server, Mir. Intel's management recently rejected patches for Mir, leaving its maintainance to Canonical. Before Intel's rejection, GNOME and KDE also refused to adopt Mir. Intel's message is clear to Canonical: if you promise to contribute, then do so."
More petty bickering (Score:5, Insightful)
It's exactly what the Linux desktop needed! Thanks, everyone!
Re:More petty bickering (Score:4, Interesting)
Re:More petty bickering (Score:5, Informative)
To be fair, Wayland really was not coming fast enough. I follow the Wayland developer mailing list, and it is apparent Mir seems to have kicked the Wayland developers in the butt and gotten them back to work. And they did fix some mistakes, in particular they realized that the server has to do event handling so that input methods work, rather than the previous idea that clients would have to interpret raw device events. I think they also fixed the other complaint Mir had which was the method to allocate window image buffers could not work with Android drivers, though this area is very confusing and it is not clear if it was a problem and/or whether it is fixed now.
Re:More petty bickering (Score:5, Interesting)
It's more like Canonical looking at the progress and direction of Wayland and saying, "we don't feel this product is going to be sufficient for our near term mobile goals and would rather roll our own to ensure product delivery"
Whether or not they were correct in this thinking is possibly open for debate. There's certainly been some things they've said publicly that were debunked, but that doesn't mean the core of their premise is wrong. They are moving to a mobile strategy that AFAIK just isn't a prime directive of Wayland, but I'm not well versed in all that is Wayland so maybe someone that is can clear that up.
The petty bickering is Wayland devs and fans getting butt hurt about some things Canonical has said publicly some of which has been proven wrong as I said above. Since then, it's been a cacophony of rants from the Wayland devs/fans with general Canonical/Ubuntu haters thrown in bashing on Canonical/Ubuntu/Mir/Unity at every opportunity.
I've just started tuning it out waiting to see how it all turns out. If there's room for more than one IDE, I don't see why there can't be room for more than one compositor. May the best product win where "win" is defined as the most market share.
Re: (Score:2)
There is nothing that qualifies Mir and disqualifies Wayland for mobile. Hell you can use Xorg in mobile and achieve good results, albeit with unnecessary X11-imposed overhead.
Compositors are mutually exclusive. You can run any number of IDEs at the same time, compositors are one-at-a-time things.
Re: (Score:3)
There is nothing that qualifies Mir and disqualifies Wayland for mobile. Hell you can use Xorg in mobile and achieve good results, albeit with unnecessary X11-imposed overhead.
"Not being a prime directive" and "not being able to do it" aren't the same things. If you're trying to squeeze every ounce of performance out of a mobile device, which Canonical does want to do in order to support convergence, then you WANT your compositor to be designed from the ground up with mobile in mind. It may well be that even given this Wayland is the better choice due to better design. Time will tell.
Compositors are mutually exclusive. You can run any number of IDEs at the same time, compositors are one-at-a-time things.
BFD
The last thing I want to see is someone (who is notorious for being insular) leveraging market share to push their internally controlled solution on everyone else.
If other distros offer a better product with the help of Wayland, then they'll have no problem
Re: (Score:2)
unnecessary X11-imposed overhead.
What overhead? The overhead that made people complain that it made a 20MHz Sun 3/60 run slow? My phone could probably emulate that machine 20x faster than real time if anyone gave a fuck about such a machine anymore.
Seriously, X11 might have been bloated in 1987, but it sure as hell isn't bloated any more as evidenced by the leading benchmark scores, for example.
Re:More petty bickering (Score:5, Informative)
It's obviously a bottleneck and this is why Linux devs (including many noted X developers) are keen to get rid of it.
I'm sure it will take Wayland a while to find its feet and for dists to transition fully but when it does Linux will be better for it. Doesn't stop people running X either - it'll just be over Wayland and probably not noticeably different either.
Re: (Score:2)
What overhead? The overhead that made people complain that it made a 20MHz Sun 3/60 run slow? My phone could probably emulate that machine 20x faster than real time if anyone gave a fuck about such a machine anymore.
Ahh yes the old theory that nothing in Linux has gotten slower or more bloated in the last 20 years.
Here's a test for you, compile a fully working kernel with no modules allowing the use of all the hardware in your machine, without any compression, and then fit that kernel image on the space of a floppy disk. What? Can't do it? That's how I ran my 486 DX4-100 so why can't we do it now?
We have asked a lot more out of our desktop environments now than we used to. X ran well on your 20MHz machine? On my 700MHz
Re: (Score:2)
"Securing The X Window System With SELinux" [nsa.gov]
PARANOIA ALERT: SELinux was created by the NSA. Not that that will stop me from using it; the NSA cares far less about my systems than some random cybercriminal.
Re: (Score:2)
Re: (Score:2)
Well, it's probably because of something like this which makes it look like Red Hat possibly trying to influence a partner to put a competitor at a disadvantage:
http://www.muktware.com/5872/intel-red-hat-working-enabling-wayland-support-gnome [muktware.com]
Re: (Score:2)
Well, it's probably because of something like this which makes it look like Red Hat possibly trying to influence a partner to put a competitor at a disadvantage:
http://www.muktware.com/5872/intel-red-hat-working-enabling-wayland-support-gnome [muktware.com]
It seems more like Intel don't want to maintain Mir and would rather just maintain Wayland, which makes sense from their perspective, you can't expect them to maintain support for every display server and the fact that their drivers are open source means the display server author can maintain their own patches for the driver putting the onus on them instead.
I still don't understand how they intend it to work with AMD and nVidia, are those companies offering to maintain Mir support in their drivers?
Re:More petty bickering (Score:4, Insightful)
How is this any different from the rest of Linux? Oh, KDE is blah, let's create GNOME! or "I hate distribution YYY, lets make ZZZ!"
How is Wayland vs. Mir any different? "Oh Wayland isn't coming along, let's create Mir!". I thought variety within Linux was a good thing which is why we have a million Linux distributions and forks and other stuff.
How is this any different from the other flamewars that happen? KDE vs. GNOME, vi vs. Emacs, Linux distro vs. Linux distro.
Re: (Score:3)
Mostly visibility and impact, in this case. The change to Wayland vs. Xorg will be largely a non-issue for most people--except programmers. Of course the Wayland vs Mir thing means the change is to one or the other API (or a compatibility layer...), and determines what graphics display is in the way. In the end it probably won't make a difference. KDE vs. Gnome is right there in your face, all the time.
More to the point, this is less "I want $THING" and more "I want to write my own because this one d
vi vs. Emacs (Score:2)
vi is a *beepity beep beep* text editor.
Emacs is my favorite operating system.
Re: (Score:1)
Yes, exactly what Linux needs. And may the best solution win out.
Re: (Score:2)
Re: (Score:2)
..and (Score:2)
FINALLY we're going to be free of X. Of course, I still suspect it will take some time to iron out the wrinkles to the point where the experiences on wayland for the various DE's are relatively bug free and are as smooth as butter.
Re: (Score:2)
The real agenda? (Score:1)
Canonical seem to be steadily trying to create a single 'us only' distro. Good that others are seeing through this.
Re: (Score:2)
Huh, what's "US only about Ubuntu?
Re:The real agenda? (Score:5, Interesting)
Re:The real agenda? (Score:5, Informative)
Canonical bashing might be all the rage at the moment, but I can see how they are feeling a bit hard done by with all these accusations that they should have used subsequent products instead of the ones they wrote first.
Re:The real agenda? (Score:5, Interesting)
Actually it's telling, mostly about Canonical's outward attitude. They created all of these solutions, but none of them were widely adopted. Few people use Launchpad, bzr, Upstart, etc. Perhaps it's related to Canonical's seeming desire to develop internally and release when they see fit, rather than develop in the open and take community input?
And Wayland is out there. It was already being tested on devices when Mir was announced. Of course, no one knew Mir was coming because Canonical likes to work behind closed doors, the larger Linux world be damned.
Re: (Score:2)
Actually it's telling, mostly about Canonical's outward attitude. They created all of these solutions, but none of them were widely adopted. Few people use Launchpad, bzr, Upstart, etc. Perhaps it's related to Canonical's seeming desire to develop internally and release when they see fit, rather than develop in the open and take community input?
So does a mildly successful OSS project called Android, I don't know maybe Canonical is tired of trying to get everyone on board and just decided "We'll go our own way and when you finally figure out it was the right one feel free to catch up". Android did the first true fork of the Linux kernel that I've heard of and probably ruffled some feathers there but they got it out the door, shipping and working. At the current rate I'd wager a desktopified Android will take over before Gnome/KDE/Unity.
Re: (Score:2)
That Android is OSS is almost completely immaterial because even if it wasn't, the handset vendors would get the sources regardless.
And maybe they just think they know better than everyone else. But I suspect that Mir would not have happened if not for Wayland.
Re: (Score:2)
Exactly. Canonical is free to go its own way, but no one should be surprised if other don't join it.
I've got a new tagline for them.
NIH: Not just for closed source.
Re: (Score:2)
Is that like the equivalent of yelling "first post"? Just because it happened before something else doesn't mean continuing to be the only one using it is the right thing. If they had issues with the programs that followed why didn't they devote time to fixing them and helping make them better and standardized across Linux?
The entire community benefits from working on the same base. Every time Ubuntu does their NIH game and develops yet another thing that is almost identical to the community standard they a
Re:The real agenda? (Score:5, Informative)
Upstart was written before systemd started; Fedora and RHEL used Upstart for a while. Newer, better has come along.
Unity was a quick response to Gnome Shell, which was available as a functional pre-release in 2009 3 months before Unity. Gnome Shell was up-and-coming and Canonical headed it off. The big move to Unity was highly politicized as "Oh no! Gnome is changing! People hate that! They will be angry at the new Gnome interface! ... Unity!!!!" It was integrated into the distribution as the primary desktop environment one release prior to integration of Gnome Shell, when Gnome Shell was already released and stable.
Mir came about well into the Wayland development cycle, citing "Wayland is coming too slowly. And we don't like it."
Bzr is the third generation of a number of unrelated pieces of software. The original Bzr, now renamed Bazaar, was a slow bloated piece of shit that didn't work right at all. The current Bzr started pretty bad, and has been improved; it was easily surpassed by Git at one point, but had caught up. There was also Mercurial and darcs, but that's not really of much import. The reason Bzr isn't more popular isn't that it's not great; it's that Git was better way before Bzr was usable.
Launchpad took forever to become open source, but that's not really a huge issue. It's sensible, but it is on their laundry list of stuff they've written that's not the same as everything that was already out there. To be fair, all other stuff out there sucks; I'd like to have Launchpad with Git integration (it'll import a Git repo by converting it to Bzr, rather than actually integrating with Git), or something like Gitlab but in Python instead of Ruby (running Ruby apps is really fucking hard; it's like the old days of wild wild Java west when nothing worked unless you were a Dark Invoker, and even then only one app per server... look up RVM and such to get an idea).
Re: (Score:2)
Re:The real agenda? (Score:4, Interesting)
I have a vastly different criticism from what I typically hear about Canonical and Ubuntu. Circa Ubuntu 12.04, I started noticing severely degrading quality in the underlying platform scripts, default configurations, and over platform management in Ubuntu. Command line sysadmin conventions typically left alone by the sprawling masses of "gotta change for change's sake" developers suddenly came under fire. What was once a very stable system under the hood was suddenly forgotten and uncared for, so I left. I didn't care about Unity because I've been using Fluxbox for nearly 8-9 years prior, but I did care that it was suddenly ridiculously difficult to bring up a stable NFSv4 w/ krb5 auth, that they were by default using linux software raid partition versions that weren't compatible with CentOS, and that iptables wasn't integrated into the baseline OS in a very sane way. I found out that the default build configuration of ntp didn't support autokey. I found out that the default build configuration for OpenSSL and other crypto related packages had no support for FIPS 140-2.
In other words, with the release of 12.04, ubuntu told me that they suddenly didn't care about enterprise users any more, so I moved on to what I have found to be a superior option for my needs. I understand that I could have rolled my own packages from scratch, but I didn't feel that was an efficient use of my time since switching to Fedora or RHEL/CentOS/SL gave me what I needed by default. I had already cast away the bottomless time sink that was managing gentoo machines, and I wasn't interested in dealing with another only a year later with Ubuntu.
Re: (Score:2)
Github and Launchpad aren't really comparable.
Re: (Score:2)
Re: (Score:2)
Upstart was written before systemd started.
So? Does that make it functionally superior? systemd uses dbus, that gives is a good start on being moved from "toy" status to "let's look at this" status.
Re: (Score:3)
but I can see how they are feeling a bit hard done by with all these accusations that they should have used subsequent products instead of the ones they wrote first.
The question one must ask at this point is why has Canonical's work on all these products not been widely accepted? They do all this work, create lots of stuff, and the rest of the world routes around it.
Are we all participants in some global anti-Canonical conspiracy? Are Linus and Kristian Høgsberg and Redhat and Gnome and github.com and the Mint guys and everyone else meeting every second Tuesday to plot the demise of Canonical?
Obviously not. What I believe we have here is an insular and unapproa
Re: (Score:2)
Unity, first commit:
Committer: Neil Jagdish Patel
Date: 2009-10-15 10:40:35 UTC
Revision ID: neil.patel@canonical.com-20091015104035-ijthyaoq3rwqu8r7
[build] Initial commit
Gnome-shell, first commit:
tag name 2.27.0 (37b3bb8ab0012a3ba39e775d78772c652eacf804)
tag date 2009-08-10 22:37:47 (GMT)
tagged by Owen W. Taylor
And early development was done in SVN rather than git, so the true start date is much earlier. The first mock-ups appeared in April of that year:
https://wiki.gnome.org/action/ [gnome.org]
ARMsrace? (Score:2)
Like or hate Ubuntu they recognize the consumer trend moving to low power SBCs. ARM is already dominating in this market and, according to wiki [wikipedia.org]:
these parts [of mir] include Android’s input stack and Google’s Protocol Buffers. An implementation detail in memory management shared with Android is the use of server-allocated buffers which Canonical employee Christopher Halse Rogers claims to be a requirement for “the ARM world and Android graphics stack”.
So to me, it seems like the push towards Mir for Ubuntu is compatible with their vision of handheld, low power, devices completely replacing the desktop [ubuntu.com]. This may well be the future of personal computing, and if I was Intel I'd want a seat at that table.
Sounds like 13.10 is to be avoided (Score:2)
I use KDE. Period.
If KDE doesn't work with Mir, and Ubuntu forces Mir with the 13.10 update, then I won't be updating to 13.10 from 13.04.
I may well have to do a reinstall with LTS, from what I'm reading. And that would piss me off to no end.
Re: (Score:2)
Actually, if I have to reinstall, I think I'll go with a base install of Debian and say "Screw you, Ubuntu!"
Re: (Score:2)
Re: (Score:2)
That same article you referenced says XMir provides compatability for KDE and that it's already been tested, so maybe I have less to worry about than I thought.
Re: (Score:2)
That same article you referenced says XMir provides compatability for KDE and that it's already been tested, so maybe I have less to worry about than I thought.
(Sorry, I mistakenly clicked on the wrong message to reply to.)
Desktop interoperability? (Score:2)
On X, you can have a Gnome application running on KDE and vice versa, will this also be the case when the desktops will use Wayland?
Or do you have to use XWayland to ensure that this interoperability still works?
Re:Why? (Score:5, Informative)
The code base is old and hard to work with from what I've heard from the X hackers. It has reached a point where it might make sense to start over.
Re:Why? (Score:4, Informative)
Additionally, X11 does a lot of things that have been taken over by toolkits. GTK and Qt don't even use X11's drawing and font facilities anymore, they handle it themselves and then dump a buffer for Xorg to display.
Re: (Score:3)
Why not? If no one uses it anymore, it's dead code that simply increases complexity. And once you start removing those dead bits, you can't call it X11 anymore. So you fix it to better fit the most common use cases and the easiest way to do that now is by rewriting it. Particularly when that code was written against a 30 year old standard that has been receiving workarounds to account for new hardware for years.
Re: (Score:2)
If the reason is that parts have been implemented in GTK+ and Qt then that sounds like a negative abstraction. There's lots of other toolkits which I'm sure users still would like to run. If all toolkits have to implement something then X is the proper place to put it.
Re:Why? (Score:5, Insightful)
Re: (Score:3)
If all toolkits have to implement something then X is the proper place to put it.
No, if all toolkits have to implement something then a shared library is the proper place to put it. For the most part, that's what's been happening. For example, both Qt and GTK+ need to render fonts, so they rely on FreeType.
The problem with putting drawing primitives and font rendering in the X server is that applications generally want to compose these operations together in ways the standard APIs don't support, which would imply either lots of round-trips and wasted effort or moving the application's d
Re: (Score:2)
Doesn't X contain a lot of shared libraries? That was what I was thinking of.
Re: (Score:2)
Doesn't X contain a lot of shared libraries?
Yes, but once the functionality is in a shared library, it's no more work to use the library from the toolkit than it would be for the toolkit to describe to X what it wants X to do with the library. On the contrary, by removing a layer of indirection it's easier for the toolkit to get the effect it wants, since it has the full API of the library to work with rather than just the portion exposed via an extension to the X11 protocol.
Re: (Score:2)
You mean these? http://en.wikipedia.org/wiki/List_of_widget_toolkits [wikipedia.org]
Re: (Score:3)
second-time-is-no-longer-clever.png
Re: (Score:2, Interesting)
There are certain things you cannot do with a pure X solution, much related to seamless transitions at login.
They argue that the seemed advantages of X, don't get used in the real world. In practice, rather then truly using network transparency, most of the time they just send bitmaps across the wire to update the screen. Because of this, by starting from scratch without this unused functionality they can make a faster, less resource-intensive, and prettier UI. For over-the-network usage they can just use a
Re: (Score:2)
Basically, if you aren't a developer, you wont care.
I think you mean: if you don't use the features of X that many of us use X for (like being able to efficiently remote display over a LAN), you won't care.
Re: (Score:2, Informative)
no, no I dont.
Read what I said again.
In the real world, the network transparency support features are not used, EVEN WHEN YOU ARE USING A REMOTE DISPLAY because it's easier and more effective to actually render on the remote machine and bang the interface, so that's exactly what every widget toolkit does.
Re: (Score:3)
Easier programming wise, maybe, but not easier on the network, or on admins'/users' sanity when using a remote connection. Transferring bitmaps around is bandwidth intensive and annoyingly slow, even on high speed connections.
Maybe they're not used, but they should be.
Re: (Score:3, Insightful)
Easier programming wise, maybe, but not easier on the network, or on admins'/users' sanity when using a remote connection. Transferring bitmaps around is bandwidth intensive and annoyingly slow, even on high speed connections.
Maybe they're not used, but they should be.
If you want your programs' icons to be rendered with new-in-1988 stippled lines rather than Cairo and your text rendered with blew-my-mind-in-1992 bitmapped fonts rather than OpenType, then yes toolkits could use the original X11 drawing conventions. However not many people actually want that.In any case, if you are happy with every toolkit implementing everything twice, why not be happy with one of those implementations being Wayland and the other being traditional-style X11?
There's also the problem that X
Re:Why? (Score:4, Interesting)
In the real world, the network transparency support features are not used, EVEN WHEN YOU ARE USING A REMOTE DISPLAY because it's easier and more effective to actually render on the remote machine and bang the interface, so that's exactly what every widget toolkit does.
I have three headless Linux machines and the only display I have is on my laptop. My remote X11 clients run on these machines and present their UIs on my local X11 display server running on my laptop. While it is probably true that these clients are not transmitting XDrawLine and XFillArc protocol elements to render their UIs, they are still mostly assembling pre-rendered bitmaps, widgets, and font glyph assets to send down the wire for rendering on the local server. How is this going to work on Wayland?
I keep reading that this will be supported through some backward-compatible protocol, but has anybody actually worked out the details of how existing X11 clients will migrate to this new protocol? My fear is that these clients will stop working with future versions of Linux and their replacements will not support network transparency.
Wayland has a real use case for mobile devices, but why make the same mistake as Microsoft by gratuitously trying to unify mobile with desktop? On a desktop, the only advantage to Wayland is that it facilitates implementing a pretty compositing desktop. This is a fad that is already starting to fade from fashion.
Re:Why? (Score:5, Insightful)
My remote X11 clients run on these machines and present their UIs on my local X11 display server running on my laptop. While it is probably true that these clients are not transmitting XDrawLine and XFillArc protocol elements to render their UIs, they are still mostly assembling pre-rendered bitmaps, widgets, and font glyph assets to send down the wire for rendering on the local server. How is this going to work on Wayland?
Actually, what the clients are doing right now is assembling bitmaps, widgets, and font glyph assets into a pixmap on the client side, most likely without the benefits of GPU acceleration, and sending the result as an uncompressed pixmap over the wire to the X server, which hands it off to a compositor, which combines the pixmap with images from other applications and hands the result back to the X server. If they're luck enough not to need any special transformations or compositing effects, the clients may be able to leave the rendering of the individual font glyphs to the server, but that's about it.
With Wayland the clients are doing the same work to assemble the surfaces for their windows, but they get to use the local GPU to do it, and the result is compressed by a local off-screen Wayland proxy server using modern video codecs before being transmitted over the network for compositing.
On a desktop, the only advantage to Wayland is that it facilitates implementing a pretty compositing desktop. This is a fad that is already starting to fade from fashion.
Distracting toys like "wobbly windows" may be fading from fashion, but composited desktops are here to stay.
Re: (Score:2)
Why are composited desktops important?
Re: (Score:2)
Why are composited desktops important?
Compositing is used to implement various helpful window management features which are not possible when drawing directly to the screen, like the "Exposé" / "Present Windows" effect and live previews during task switching. It also allows various accessibility improvements, like contrast-enhancing visual filters and smooth screen magnification, and is required for the efficient implementation of translucent windows, including merely non-rectangular windows with antialiased borders.
Re: (Score:2)
Ahh, so nothing that's actually important.
Re: (Score:2)
Actually, what the clients are doing right now is assembling bitmaps, widgets, and font glyph assets into a pixmap on the client side, most likely without the benefits of GPU acceleration, and sending the result as an uncompressed pixmap over the wire to the X server, which hands it off to a compositor, which combines the pixmap with images from other applications and hands the result back to the X server.
Yes, I think you are right for the most part, especially with Gnome and GTK applications. It explains why the resource tab of gnome-system-monitor consumes over 1MB/sec of bandwidth on my LAN. It's a shame really since it could have been coded to be much more network efficient if it would just draw the damn lines on the server side instead of rendering them into a pixmap on the client side.
In general Gnome is extremely network unfriendly. I get tons of error messages on the console because Gnome applicat
Re: (Score:2)
How is this going to work on Wayland?
My understanding is the network transport is still under discussion. But Wayland could send bitmaps of each windows surface and you will have a thin client of some sort on the remote end that renders these surfaces on your screen, lets you move them around etc.. Your client will send things like mouse and keyboard events in the other direction, receive new bitmap fragments, resize events etc.
Of course since Wayland is running over OpenGL ES 2.0, it's possible to imagine more exotic scenarios where shaders
Re: (Score:2)
Why do you need full network transparency (which you don't really have anyway in X)? I see no advantage to the network transparent features of X compared to a modern implementation of RDP, but I could be missing something?
If anything RDP would be more efficient than what X has now as X has effectively degenerated to VNC style transmitting of images over the network. As a user of many such systems I can say with some certainty that in terms of speed and usability X VNC RDP, and the performance gap between
Re: (Score:2)
VNC is a pixel-based screen-scraping desktop replicator. I have never seen one that performs better than individual X11 clients over a fast LAN, and over the Internet it's even worse. Besides that, I already have a full X11 desktop running on my local machine, so I don't want another desktop environment intruding. I just want the individual clients to display on my existing X11 server's desktop. This is especially important when working with several remote hosts.
RDP is a little better in that it has some
Re: (Score:2)
RDP is a little better in that it has some understanding of the higher-level desktop objects it is rendering. But it still functions as a complete desktop that really wants to take over your entire local desktop.
That is a common misconception. RDP v6 released in 2006 added support for remote clients in an effort to compete with Citrix. RDP in windows essentially already does this except that by default the remote app that it launches is the explorer shell. Windows 2008 gave a good interface for doing that called RemoteApp.
But ignoring specific implementations I'm talking on a protocol level. The RDP protocol adds a whole world of features that simple network transparency doesn't such as pass through of hardware in
Re: (Score:2)
Re: (Score:2)
No worries, but before I come across as a liar, it's the protocol that supports seemless integration. I haven't actually tried to see if xrdp implements that part of the standard as I use the full desktop myself, and the only time I've used remote applications was on a windows server.
Re: (Score:2)
...has anybody actually worked out the details of how existing X11 clients will migrate to this new protocol?
I find Unity completely unusable and so I don't use it. I just installed mint 15 on a powerbook pro the other day, and as always, at login I have several desktop mangement options, including xfce (which I use), and Unity, as well as several others. I doubt seriously that X will be yanked from most distrobutions without a fallback. In fact I suspect you'll be able to use X for years to come if you so choose.
Re: (Score:2)
I've read the article on Wayland at Wikipedia, but I still don't know why they want to replace X.
'Cause writing new code is cool, while supporting and debugging old code is boring.
Re: (Score:3)
Debugging and maintaining old code that no one is using is annoying and pointless. Particularly when you know you can do better, but are hamstrung by the X11 requirements.
Re: (Score:2)
Re: (Score:2)
...while supporting and debugging old code is boring.
So, according to that philosophy, we really should all be submitting our /. input on punched cards into batch jobs and reading your driblets of wisdom on paper tape becuase 640K should be enough for everyone, right?
Re: (Score:2)
My grailslaves have been transcribing my /. posts onto stone tablets and then carrying them upRiver to the server for the last 10,000 years. Why should I abandon a system that continues to work perfectly well for me?
Re: (Score:1)
I've read the article on Wayland at Wikipedia, but I still don't know why they want to replace X.
The X graphics stack has bad performance.
Re: (Score:2)
The X graphics stack has bad performance.
Compared to what. It's the fastest graphics system out there. Just look at the benchmarks. The X is slow mantra is restricted to greybeards who resent it hogging CPU cycles on their 10MHz Sun 3/60 and kiddies who believe that anything old is bad.
Re: (Score:2)
Android doesn't use X11 because it would be redundant and required too much memory -- do you recall how much RAM the first Android dev phone had? 32MB. Good luck running X in that. I happen to have an X server running on my Android tablet just fine fyi -- and no performance issues.
Re: (Score:2)
X ran just fine in under 32MB back in the day, though I haven't had such a machine in a while.
Re: (Score:2)
X ran just fine in under 32MB back in the day, though I haven't had such a machine in a while.
So you believe between 1998 - when PCs with 32MB were common - and 2008 - when the first Android phone came out - there were no significant changes to X that could have impacted performance?
Re: (Score:2)
Really? Because games ported to Linux through emulation often perform *better* than their Windows counterparts.
I haven't seen a single example of the X stack having a speed problem -- memory usage, yes, speed, no.
Re: (Score:3)
This video [linux.org.au] seems to provide a good explanation of the motivation for Wayland.
Re: (Score:2)
My question is, why KEEP it at all? It's old, flawed, and has been patched up a lot of times to make it keep up. It has run it's course. What's wrong with retiring old things in favour of newer ones?
Re: (Score:2)
I'd be far less critical of Wayland if they took the approach of "look what it can do!" instead of "X sux and Wayland will be able to do everything it does so much better
Re: (Score:2)
Here's a little thing to show people if they are clueless fanboys or really understand the Wayland vs X thing: for Wayland to replace X for my workplace would require Wayland working on MS Windows. Confused? Then you have no idea why a lot of people use X and why we kick back against all the "X sux, let's throw it away for a framebuffer" stuff.
One
Wayland and X behave differently (Score:2)
It's not going to be as simple as recompiling the existing applications for a new qt or whatever. It's going to be a matter of rewriting the applications to support whatever changes have been made to behaviour in qt to work on Wayland for the bits it doesn't have out of X and the new
Re: (Score:2)
It should make for a much more responsive desktop. It doesn't stop running X apps either since X
Re: (Score:3)
Re:Redhat? (Score:5, Insightful)
Care to supply actual evidence of these claims? Because anyone can make wild claims, what gets attention is evidence, which your post is lacking.
Re: (Score:3)
"Care to supply actual evidence of these claims?..."
Oh, please. If I had actual physical evidence, I'd be in some NSA sub-basement right now.
you seem to be supplying plenty of evidence to suggest you are a paranoid schizophrenic. no, seriously, i think you need professional help.
Re: (Score:1)
Red Hat is open source. You can see for yourself if there are any backdoors. I don't think that you'll find any, though.
Re: (Score:2)
Re: (Score:2)
As I pointed out is another post ( http://slashdot.org/comments.pl?sid=4183357&cid=44792345 [slashdot.org] [slashdot.org] ), Boston Consulting Group is a central component of the "1%" and their influence around the world.
Hehe, well you are 100% ahead of many conspiracy theorists, in that you have more than a vague idea of who 'they' are. So good job there.
Re:Is Canonical TRYING to piss everyone off? (Score:4, Insightful)
Re: (Score:2)
He failed at that when he launched 11.04 (or was it 11.10?)
At that point Linux on the desktop lost all the hope that it had.
Re: (Score:2)
My Linux desktop worked just fine for years* before Shuttleworth and his Fishery-Pricey, one-size-fits-all, ow-thinking-about-stuff-is-too-hard desktop even showed up on my "What the hell is this crap?" list, thanks very much.
*(Not 10,000 years, admittedly, but a number of them.)
Re: (Score:2)
Nope. While I like the idea of a method that uses cgroups to group processes on the fly, the rest of it's overwrought. The way he ties tons of dependencies into basic system binaries is an issue. (udev comes to mind)