Google Introduces Freon, a Replacement For X11 On Chrome OS

← Back to Stories (view on slashdot.org)

Google Introduces Freon, a Replacement For X11 On Chrome OS

Posted by timothy on Sunday March 8, 2015 @03:19PM from the low-level-churn-at-a-high-level dept.

An anonymous reader writes With this week's release of Chrome OS M41, there is the new Freon graphics stack to replace X11 on some platforms. Freon is a very limited graphics stack to replace Chrome OS usage of X11/X.Org by having the Chrome browser communicate directly with the Linux kernel's KMS/DRM API and OpenGL ES interfaces for drawing. This design is much simpler and yields various power and performance improvements though it's not based on Wayland nor Mir (though Chrome plans to support these display server models).

110 of 166 comments (clear)

Min score:

Reason:

Sort:

Chrome by Anonymous Coward · 2015-03-08 15:24 · Score: 4, Insightful

If Chome browser IS the OS, then what they have is an embedded video driver. It's not a X11 replacement anymore than FB interface is a replacement for X11.
1. Re:Chrome by Anonymous Coward · 2015-03-08 16:49 · Score: 2, Insightful
  
  It's a replacement for X11 on ChromeOS. Not a replacement for X11 in general. Also, since X11 is getting removed from ChromeOS in favor of Freon, it is, by definition a replacement. If you don't need all of the functionality of X, you can replace it with something simpler.
2. Re:Chrome by Loconut1389 · 2015-03-09 06:44 · Score: 1
  
  The video driver i really separate from the windowing system. The video driver is what allows us to draw pixels on the screen, hopefully while taking advantage of video card resources. X11 / Freon is the Window system which helps organize applications and provide humans with a way to manipulate and switch between applications / workspaces.
DRM stands for by tepples · 2015-03-08 15:26 · Score: 5, Informative

Here I'm assuming that "KMS/DRM" refers to "kernel mode setting and direct rendering manager", not anything to do with "digital restrictions management" such as establishing a protected video path for use with the Content Decryption Module draft stuff in HTML5.
1. Re:DRM stands for by linuxrocks123 · 2015-03-08 19:45 · Score: 2
  
  Correct. Not the first time that acronym has been confusing.
  
  --
  vi ~/.emacs # I'm probably going to Hell for this.
2. Re:DRM stands for by Culture20 · 2015-03-09 04:09 · Score: 1
  
  Don't get me started on KVM.
3. Re:DRM stands for by hawkinspeter · 2015-03-09 08:15 · Score: 1
  
  Why not? It's a great little hypervisor.
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
4. Re:DRM stands for by Culture20 · 2015-03-09 08:19 · Score: 1
  
  "I used this KVM* the other day to set up KVM^"
  
  *switch
  ^hypervisor.
YANIH by NotInHere · 2015-03-08 15:39 · Score: 2

yet another not invented here.
At least they are not as bad as Canonical, which not just have mir, but also bzr.
1. Re:YANIH by pavon · 2015-03-08 15:52 · Score: 1
  
  If this is a case of NIH, then it is reinventing the framebuffer, not X11, Wayland or Mir. And it makes since to do so since the kms/drm interfaces provide better performance and more features than fbdev.
2. Re:YANIH by NotInHere · 2015-03-08 15:57 · Score: 1
  
  Yes you are right, I RTFA, and the subject is misleading.
3. Re:YANIH by dmbasso · 2015-03-08 16:47 · Score: 3, Insightful
  
  I don't think Bazaar can be included in the NIH set, as upstart and mir can. When they started working on Bazaar, there was no distributed VCS that was as simple and intuitive as what they had implemented. I've used Darcs before switching to Bazaar, and though I don't remember specifics, I remember feeling much more comfortable using bzr. In the end, git is the clear winner of the DVCS race (Mercurial folks might disagree with me), but you can't blame Canonical for investing in their solution (a very good one, imho). Btw, bzr was first released two weeks before git's first release.
  
  --
  `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
4. Re:YANIH by slack_justyb · 2015-03-08 17:19 · Score: 1
  
  I'm going to unofficially call it as NIH being the most overused term in pretty much all technical discussion boards. I would say that NIH has reach near if not equal to Godwin's law status. Therefore, the next person to bring up NIH, we should all collectively treat such statements as useless banter and move on with our lives.
  Apparently if someone purposes or actually implements something that wasn't purposed or implemented back in the 1970s, it automatically classifies that new thing as NIH. Because everyone knows that the 70s were the apparent height of computer technology and neckbeards. Screw idealism, you'll take X and it's fifty million extensions from my cold dead hands! And I like my start up scripts like I like my Egyptian tombs, hard to understand and full of things to trap and destroy you! Now get off my lawn!!
5. Re:YANIH by NotInHere · 2015-03-08 18:57 · Score: 1
  
  Why can upstart be added?
6. Re:YANIH by Lemming+Mark · 2015-03-08 19:33 · Score: 1
  
  Also, bzr evolved IIRC from the whole GNU Arch / tla, which is much older again.
  I think it's fair to say that git is the current winner in the DVCS race because it has the best network effects from mass adoption. I live in hope Mercurial will see a resurgence at some point!
  Upstart, although sticking to it may now resemble NIH, does also predate SystemD and was used by other distros (Fedora adopted it before moving to SystemD when that became available).
  Mir is the one I still find a bit mystifying. I'm sure it's nice technology, developed by smart people, I'm just surprised Canonical started on it so enthusiastically and so early.
7. Re:YANIH by bickerdyke · 2015-03-08 20:44 · Score: 1
  
  According to TFS, Chrome will use OpenGL (ES). Which is quite a long way to pixel-handle the framebuffer.
  
  --
  bickerdyke
8. Re:YANIH by DrXym · 2015-03-08 21:07 · Score: 1
  
  Mir is the one I still find a bit mystifying. I'm sure it's nice technology, developed by smart people, I'm just surprised Canonical started on it so enthusiastically and so early.
  The only reason Mir exists is because Canonical wanted to slap their dual GPL / proprietary licence on it. It lets them release Ubuntu branded phone handsets with any proprietary display driver, DRM or extensions they like in the display stack but competitors are hamstrung by the GPL part. I recall reading a blog which justified Mir with some fairly dubious technical reasons that Wayland wasn't suitable but it seems clear to me it was more than that..
  Anyway, the licencing has become a double edged sword. Contributors like Intel walked away from the project, other open source projects adopted Wayland (which uses the same licence as X and so is a slot-in replacement) and Canonical left with all the work of writing backends for QT, GTK and porting apps.
9. Re: YANIH by DrXym · 2015-03-08 21:15 · Score: 1
  
  Even Microsoft supports git these days through Visual Studio and its online team foundation server backend. That should say something.
10. Re:YANIH by serviscope_minor · 2015-03-08 21:32 · Score: 3, Insightful
  
  Screw idealism, you'll take X and it's fifty million extensions from my cold dead hands!
  I love how X is the only system that people complain about when it gets API updates while remaining backwards compatible. Are you going to stop using Wayland when it progresses on from the 1.0.0 release or are you fine because it doesn't call new API calls "extensions"?
  And I like my start up scripts like I like my Egyptian tombs, hard to understand and full of things to trap and destroy you!
  I prefer hard to understand over impossible to understand. And before you claim that systemd is easier to understand, please make the ACPI sleep key send my laptop to sleep under systemd. So far many people have told me how systemd is "simpler" but no one has been able to help me fix this really simple problem. It worked just fine under the old system.
  Oh yeah and to boot, my system boots slower!
  So, um yay?
  
  --
  SJW n. One who posts facts.
11. Re:YANIH by andydread · 2015-03-08 22:44 · Score: 2
  
  The constant whining about NIH in open source/free software is a bullhshit red herring. It is an attempt to legitimize one's hatred for the entity that is trying to create something new that suits their own needs. Not every damn upstream project is going to accept your patches to change the direction from where upstream want's to go. And the freedesktop.org guys are notorious for telling downstream submitters to go fuck off and WONT_FIX. So your argument is a total straw man argument and lacks credibility in the face of reality.
12. Re:YANIH by Rich0 · 2015-03-08 23:23 · Score: 1
  
  And before you claim that systemd is easier to understand, please make the ACPI sleep key send my laptop to sleep under systemd. So far many people have told me how systemd is "simpler" but no one has been able to help me fix this really simple problem. It worked just fine under the old system.
  How did you get it to work under the old system?
13. Re:YANIH by drinkypoo · 2015-03-09 00:25 · Score: 1
  
  It just worked under the old system, and if it didn't, you could tell where it fell on its ass by replicating the various steps.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
14. Re: YANIH by slack_justyb · 2015-03-09 00:36 · Score: 1
  
  Yes, so for those reasons we should just stop making any kind of progress. You confuse my sarcasm as support for what's out there. I'm not saying they are better solutions, what I am saying is that just sticking to 70s software is neurotic at best. Yes, nothing is awesome at version 1.0, but to hear it, most people want to burn the thought of having a different opinion in the OSS community. It is going to suck at version 1.0, that's life. Invent something better, help the cause, or go hide away in your retirement home. Staying the course because inaction would be better than action is why I feel it is so humorous the current situation. So don't think I am saying Wayland or systemd is awesome, but damn they get props for rocking the boat.
15. Re:YANIH by Rich0 · 2015-03-09 02:12 · Score: 1
  
  It just worked under the old system, and if it didn't, you could tell where it fell on its ass by replicating the various steps.
  Well, it doesn't sound like you understand the old system any better than the new. :)
  If the old system just worked it was only because your distro made it just work. The solution for systemd is to ask them to do the same.
16. Re: YANIH by jedidiah · 2015-03-09 02:51 · Score: 1
  
  No. You're just confusing "newer" with "progress".
  They aren't the same thing by a long shot.
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
17. Re:YANIH by serviscope_minor · 2015-03-09 03:25 · Score: 1
  
  How did you get it to work under the old system?
  ACPId called a shell script in /etc, which I could edit.
  
  --
  SJW n. One who posts facts.
18. Re: YANIH by serviscope_minor · 2015-03-09 04:36 · Score: 2
  
  I really don't know what your point is.
  An init system which breaks perfectly working behaviour and has not yet introduced a single feature which makes my experience better in any way is not progress, it's churn and there's a huge difference.
  I have nothing against a new init system. I have got something against one which (a) doesn't work and (b) is such a complex hairball that no one can tell me how to fix a really basic problem.
  Invent something better, help the cause, or go hide away in your retirement home
  There is something better: The old RC scripts on arch both booted faster on my machine and were simple enough to fix. So systemd fails on one of the things it was supposed to be better at AND is too complex to be fixable. Besides why would I take the time to invent something better? systemd is being strongly pushed by entrenched interests and it's got to the stage where it touches so many parts of critical ifrastructure that one needs a vast effort to unpick the tendrils.
  I can tell when something would be a waste of my time.
  It is going to suck at version 1.0, that's life.
  Well if PulseAudio is anyting to go by, it will continue to suck for a lot longer. Yes I'm still having persistent PA problems on one machine. It sometimes flips to headphones out on loud bits. And rarely it loses its shit completely and oscillates between the two. No, it's not a hardware problem because it never, ever, ever happens under ALSA, and besides a restart of PA kills the oscillation.
  I look forwards to systemd just losing it's shit every so often.
  
  --
  SJW n. One who posts facts.
19. Re:YANIH by Rich0 · 2015-03-09 06:01 · Score: 1
  
  How did you get it to work under the old system?
  ACPId called a shell script in /etc, which I could edit.
  So, just run a similar process today. Or, get whoever provided the acpid solution to provide a comparable systemd one. Normally end users aren't expected to tweak this kind of stuff.
20. Re: YANIH by bluefoxlucid · 2015-03-09 06:46 · Score: 1
  
  2500 years ago, schools taught people how to learn. 100 years ago, schools taught people things. Today, schools are daycare with incidental learning.
  
  --
  Support my political activism on Patreon.
21. Re: YANIH by bluefoxlucid · 2015-03-09 06:47 · Score: 1
  
  An init system which breaks perfectly working behaviour and has not yet introduced a single feature which makes my experience better in any way is not progress, it's churn and there's a huge difference.
  Instead of messing around rewriting init scripts to put out debug output or let me launch the service manually, I just ask for the journal and it tells me why it failed. 15 minutes of debugging became 1 second of debug on systemd. I also removed the "check for failure and restart" crontab in favor of setting systemd to keep a service running.
  
  --
  Support my political activism on Patreon.
22. Re:YANIH by serviscope_minor · 2015-03-09 09:27 · Score: 2
  
  So, just run a similar process today. Or, get whoever provided the acpid solution to provide a comparable systemd one. Normally end users aren't expected to tweak this kind of stuff.
  systemd has subsumed acpid. It deals with and processes ACPI key events. Except it's eating the event and I can't figure out where it's going. It doesn't run any of the triggers it's meant to. And therefore won't run the shell script. So far not one systemd proponent has given me even the slightest clue how I'm meant to go and debug it short of hacking the C code, sticking in logging entries!
  And end users not tweaking it? That's the thing it seems to be designed as a black box for "end users" where the "end users" are a bunch of hackers.
  
  --
  SJW n. One who posts facts.
I am going to fork it. by funwithBSD · 2015-03-08 15:45 · Score: 4, Funny

and develop R22 as a replacement.

--
Never answer an anonymous letter. - Yogi Berra
1. Re: I am going to fork it. by rkcth · 2015-03-08 16:04 · Score: 2
  
  I'm leapfrogging that and doing straight to R410A
The Browser is NOT the OS by duckintheface · 2015-03-08 15:45 · Score: 5, Insightful

Marketing gibberish aside, the Chrome browser is not the OS. The OS also happens to be called Chrome but it is just a variant of Linux. And the Chrome browser is a browser, not an operating system. Google wants to limit your applications to those that run in the browser to sort of simulate the "browser is the OS" look and feel, but that's not really what's going on. The confusion is intentional.

--
"He took a duck in the face at 250 knots." -- William Gibson, Pattern Recognition
1. Re:The Browser is NOT the OS by The+MAZZTer · 2015-03-08 16:45 · Score: 4, Informative
  
  "Just a variant of Linux" is a little understatement I think. It would be more accurate to say it's Linux with everything NOT needed to run the Chrome browser ripped out or trimmed down... this Freon is another improvement in that area.
2. Re: The Browser is NOT the OS by the_humeister · 2015-03-08 17:56 · Score: 4, Interesting
  
  How does this affect people using Crouton? Will X still work or will we actually have to dual boot a real Linux distribution rather than run it in a chroot?
3. Re: The Browser is NOT the OS by BronsCon · 2015-03-08 20:21 · Score: 1
  
  Really kinda wanna know this, too, as I'm still considering a Chromebook Pixel, but it this breaks Crouton, I'll pass.
  
  --
  APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
4. Re:The Browser is NOT the OS by tigersha · 2015-03-08 20:57 · Score: 1
  
  QNX. Sigh.
  I wish every Google and Apple and Linux and Microsoft engineer will be forced to work with QNX for a week as a training session just to show them how things were supposed to be done. Same with BeOS.
  I keep an old Thinkpad from 2000 around just to occasionally boot up BeOS on it and toy around a bit.
  
  --
  The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
5. Re:The Browser is NOT the OS by brunes69 · 2015-03-09 00:22 · Score: 1
  
  The Windows interface is a GUI, not an operating system. Microsoft wants to limit your applications to those that use the Win32 API to sort of simulate the "Windows is the OS" look and feel, but that's not really what's going on.
  The Android interface is a runtime, not an operating system. Google wants to limit your applications to those that use the ART runtime to sort of simulate the "Android is the OS" look and feel, but that's not really what's going on.
  The GNU stack is userspace, not an operating system. GNU wants to limit your applications to those that use the glib API, but that's not really what's going on.
6. Re: The Browser is NOT the OS by muirhead · 2015-03-09 01:06 · Score: 2, Informative
  
  Really kinda wanna know this, too, as I'm still considering a Chromebook Pixel, but it this breaks Crouton, I'll pass.
  Looks like they've got it covered. https://www.openhub.net/p/crouton/commits/367012555
7. Re:The Browser is NOT the OS by jedidiah · 2015-03-09 02:42 · Score: 2, Insightful
  
  Relative to Google's own requirements for Chrome, it's an improvement. Relative to someone interested in a real OS or Linux in particular, Chrome already jumped the shark anyways.
  
  --
  A Pirate and a Puritan look the same on a balance sheet.
8. Re:The Browser is NOT the OS by mrchaotica · 2015-03-10 03:14 · Score: 1
  
  Indeed; confusopolies are evil.
  
  --
  "[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Freon? You gotta be kidding: by Hartree · 2015-03-08 15:47 · Score: 2, Insightful

You mean Freon as in R-11 or R-12 which increase the ozone hole and were banned? (It's Dupont's trademark. Wonder if they asked first.)
Is the next release gonna be named Thalidomide? Or maybe Dimethyl Mercury?
1. Re:Freon? You gotta be kidding: by Lije+Baley · 2015-03-08 16:09 · Score: 2
  
  If it's as effective as those, then it's synonymous with "the good stuff". Next one might be "High-Flow Toilet", or "Nuclear Thermal Rocket".
  
  --
  Strange things are afoot at the Circle-K.
2. Re:Freon? You gotta be kidding: by BigDish · 2015-03-08 16:10 · Score: 1
  
  Trademarks are per-industry. I could freely sell Apple toilet paper, Microsoft cookies, Sony faucets, etc - without the permission of the companies we typically associate with those brands.
3. Re: Freon? You gotta be kidding: by Anonymous Coward · 2015-03-08 16:21 · Score: 1
  
  No.
  Microsoft uses cookies in IE. Sony's data leaks more than any faucet in my house. And Apple's products are so polarizing that they are either shit or the shit, so toiket paper wouldn't be a bad next entry for them.
4. Re:Freon? You gotta be kidding: by K.+S.+Kyosuke · 2015-03-08 17:06 · Score: 1
  
  Speaking of metallic polish, perhaps chromium hexacarbonyl would be a better fit? Or just go for nickel tetracarbonyl if you really mean it.
  
  --
  Ezekiel 23:20
5. Re:Freon? You gotta be kidding: by sjames · 2015-03-08 18:20 · Score: 1
  
  Hexavalent Chrome, of course.
6. Re:Freon? You gotta be kidding: by El_Muerte_TDS · 2015-03-08 18:29 · Score: 2
  
  I guess Google needs to put this project back in the fridge and think about it a bit more.
7. Re:Freon? You gotta be kidding: by amalcolm · 2015-03-08 19:23 · Score: 1
  
  Not quite - remember the Apple Music (the Beatles label) vs Aplle Inc lawsuit?
  
  --
  Time for bed, said Zebedee - boing
8. Re:Freon? You gotta be kidding: by BronsCon · 2015-03-08 20:27 · Score: 1
  
  Microsoft cookies... would those be like Chips-Ahoy Soft Batch Minis, but smaller? Take my paycheck. All of it. Now.
  
  --
  APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
9. Re:Freon? You gotta be kidding: by dunkelfalke · 2015-03-08 20:40 · Score: 1
  
  Nuff said
  
  --
  "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
10. Re:Freon? You gotta be kidding: by Rei · 2015-03-08 21:45 · Score: 2
  
  I'm betting that Freon leaks. And that it destroys its operating environment.
  
  --
  "Are you hungry? I haven't eaten since later this afternoon." -- Primer
11. Re:Freon? You gotta be kidding: by TheRealHocusLocus · 2015-03-08 23:29 · Score: 1
  
  FREON indeed.
  How about X12? It is only an XML exchange standard, an experimental superhuman and adjustable bed.
  One would think the company who runs the most popular Internet search engine would understand the hard-ass difficulty of finding relevant search results on specific topics about redundantly named things, especially deep results in discussion forums. Freon is discussed in automotive, ecological and chemistry contexts, there are tons of government and UN docuiments. Graphic software projects should be uniquely named. This is because in every written discipline people say, "Graphics 2 and 3 show sales for......" so for example, "freon graphics" still would yield irrelevant results.
  And then it gets worse, as if software suites are some kind of goofy themed Senior Prom. You will see plugins and offshoots of Freon software called Condenser, Compressor, Ozone and Fanbelt, Squeaking, Vent Solenoid and Thermostat, Sunburn, Cancer and Death.
  Google has come to praise knowledge, not to bury it.
  
  --
  <blink>down the rabbit hole</blink>
12. Re:Freon? You gotta be kidding: by rossdee · 2015-03-09 01:49 · Score: 1
  
  "Or just go for nickel tetracarbonyl"
  Isn't that what the Dorsai people of Foralie district used to disable Dow Decastries troops?
13. Re:Freon? You gotta be kidding: by rjstanford · 2015-03-09 02:34 · Score: 1
  
  Yup, which only had standing because Apple started to include sound support as part of the OS in the Mac. There's a reason that Apple named one of their sounds SOSUMI after all.
  
  --
  You're special forces then? That's great! I just love your olympics!
Let me guess by RightwingNutjob · 2015-03-08 16:03 · Score: 1, Insightful

Network transparency is not supported because noone uses it.
1. Re:Let me guess by thegarbz · 2015-03-08 16:20 · Score: 1
  
  Chrome already has it's own method for doing remote desktop.
  It won't be supported because it will be competing directly with something Google already does.
2. Re:Let me guess by NotInHere · 2015-03-08 16:45 · Score: 2
  
  From an X11 developer: "Stop saying that because its rubbish"
3. Re:Let me guess by Uecker · 2015-03-08 17:20 · Score: 1
  
  Not being able to simple use 'ssh -X' from my chromebook is the one thing I really miss. Ofcourse, crouton comes to the rescue...
4. Re:Let me guess by Severus+Snape · 2015-03-08 17:28 · Score: 1
  
  Chrome already has it's own method for doing remote desktop.
  It won't be supported because it will be competing directly with something Google already does.
  *puts cynical hat on*
  i.e passing through Google's data centers.
5. Re:Let me guess by RightwingNutjob · 2015-03-08 17:43 · Score: 4, Insightful
  
  And my reply is always the same: if you make a change, improve the whole system; don't make compromises to core functionality for the sake of cosmetic improvments. Bells and whistles in the window manager are cosmetic. Being able to display output (from a single window, mostly text and line art graphs, not the whole damn desktop) to a different machine across the building is not cosmetic, it is why I use Linux instead of Windows. Maybe X11 doesn't let you do some things that really are better (I wouldn't know, the only annoyance I have ever found with X11 code is that its error handler calls exit(-1) if it panics without letting you deal with it in the calling program, meaning you have to split display and core logic into two processes instead of being able to keep everything in one address space), but network transparency (what else do you call being able to say DISPLAY=whatever:X.Y my_program) is a core capability that people do use, and you won't get them on board if you turn it into an afterthought.
6. Re:Let me guess by Uecker · 2015-03-08 17:49 · Score: 1
  
  , the only annoyance I have ever found with X11 code is that its error handler calls exit(-1) if it panics without letting you deal with it in the calling program
  You mean the default error handler in xlib? You can set your own.
7. Re:Let me guess by Uecker · 2015-03-08 17:51 · Score: 1
  
  I know that. But X11 tunneling does not work.
8. Re:Let me guess by sjames · 2015-03-08 18:26 · Score: 1
  
  I smell burning pants!
  Redefining a well understood thing and then claiming it never existed is disingenuous at best.
9. Re:Let me guess by phantomfive · 2015-03-08 19:41 · Score: 1
  
  To be clear, the x.org guys were never known for their skill at software engineering. They mostly got where they were by doing a job no one else wanted to do.
  
  --
  "First they came for the slanderers and i said nothing."
10. Re:Let me guess by TheRaven64 · 2015-03-08 21:07 · Score: 1
  
  Network transparency is completely supported. The protocol used is called HTTP. The windowing system that runs on top of the Freon graphics driver layer is the Chrome web browser.
  
  --
  I am TheRaven on Soylent News
11. Re:Let me guess by thegarbz · 2015-03-08 21:27 · Score: 1
  
  *puts practical hat on*
  Hardly. Not every bit of data is worth collecting. Plus it's a direct PC to PC connection.
12. Re:Let me guess by serviscope_minor · 2015-03-08 21:36 · Score: 1
  
  wouldn't know, the only annoyance I have ever found with X11 code is that its error handler calls exit(-1) if it panics without letting you deal with it in the calling program
  There are some alternatives, look ath the following functions:
  XSetErrorHandler, XGetErrorText, XDisplayName, XSetIOErrorHandler, XGetErrorDatabaseText
  
  --
  SJW n. One who posts facts.
13. Re:Let me guess by DrXym · 2015-03-08 21:42 · Score: 1, Insightful
  
  You can't "improve" X11 without making it not X11. e.g. make IPC async and it's not X any more. And at that point you may as well ditch the lot and write it properly, taking advantage of the hardware that every modern PC has to render a desktop decently locally first (the common use case) and taking advantage of existing remoting tech to take care of the uncommon use case. And that's what Wayland does - it describes a protocol for a client application to talk directly with a window manager that cuts X11 out of the picture.
  Weston already demonstrates built in RDP support. It wouldn't be a stretch to imagine VNC or other protocols appearing in time to serve different remoting scenarios. I'm sure that unless you're expecting to play video or games in realtime they would suffice and if you are expecting to play video or games in realtime there are better ways to do those things already.
14. Re:Let me guess by thegarbz · 2015-03-08 21:42 · Score: 2
  
  Just to play devils advocate:
  1. Are you suggesting to never release software unless it's 100% feature complete and comparable with software that has 20+ years of development behind it?
  2. What happens if part of the core functionality was one of the biggest performance issues and complaints on the design of the prior system you are trying to replace? Just like the core component of a car is the internal combustion engine sometimes core components are not considered as afterthoughts, but rather are consciously excluded from design (such as network transparency in Mir and Wayland which both projects have not only excluded from the core protocol but subsequently showed proof of concepts of how the features will continue to work anyway when programmed in a different way)
15. Re:Let me guess by maestroX · 2015-03-08 22:48 · Score: 1
  
  Any system has compromises. And network transparancy is not a core capability, it's like supporting a remote unknown display driver.
  Network transparency as a capability unnecessary complicates the core and design (security, transport, feature querying et al., responsiveness). It can be solved in an additional framework, just as Exceed does on Windows.
16. Re:Let me guess by Viol8 · 2015-03-09 00:04 · Score: 1
  
  "And network transparancy is not a core capability,"
  Er yes. It Is.
17. Re:Let me guess by Viol8 · 2015-03-09 00:08 · Score: 1
  
  1. If you're going to replace a well known piece of software then it rather helps if you've duplicated important functionality people use. Its like coming out with a competitor to Word that can't handle underlining or bullet lists.
  2. Which part of "core functionality" don't you understand? If its fundamental to the way people use it it stays. Power users frankly don't give a shit if it means some kid can only play a game at 60fps instead of 80 by keeping it.
18. Re:Let me guess by multi+io · 2015-03-09 00:09 · Score: 1
  
  Chrome already has it's own method for doing remote desktop.
  It won't be supported because it will be competing directly with something Google already does.
  Yeah, it's called HTTP. It even supports client-induced code upload and execution on the display server just like display postscript did (and JavaScript is a nicer programming language than PostScript), oh and it calls its display server the "client" and its client the server. You get used to it.
19. Re:Let me guess by drinkypoo · 2015-03-09 00:24 · Score: 1
  
  And my reply is always the same: if you make a change, improve the whole system; don't make compromises to core functionality for the sake of cosmetic improvments. Bells and whistles in the window manager are cosmetic. Being able to display output (from a single window, mostly text and line art graphs, not the whole damn desktop) to a different machine across the building is not cosmetic, it is why I use Linux instead of Windows.
  Terminal Services RemoteApp (TS RemoteApp) enables organizations to provide access to standard WindowsÂ®-based programs from virtually any location to users with computers running Windows VistaÂ®, Windows ServerÂ® 2008, or Windows XP with Service Pack 3 (SP3). TS RemoteApp is also available to users with computers running Windows XP with Service Pack 2 (SP2), Windows Server 2003 with Service Pack 1 (SP1), or Windows Server 2003 with SP2 that have the new Remote Desktop Connection (RDC) client installed."
  You can have single-application remoting without X11. We can move forward and still have the functionality you're looking for. The only reason you can't display arbitrary applications individually between arbitrary Windows hosts is Microsoft's licensing, but there are relatively few use cases where this matters. Most of the time, you want to run an app from a bigger, badder machine on a lesser machine, and they provide the functionality for that already.
  I don't use Windows servers, but it's not because you can't remote one application — you can. "[T]he terminal server that hosts the program must be running Windows Server 2008" (per link) but if you're living in Windows-land, you're keeping your machines up-to-date, right?
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
20. Re:Let me guess by raxx7 · 2015-03-09 00:24 · Score: 4, Insightful
  
  99% of people don't want X11 style network transparency. They want "ssh -X" and friends to work. They want to be able to remotely run individual graphical applications.
  But X11-style network transparency isn't the only way. And it's not the best way.
  Despite all the features available in X, application developers give limited effort to making applications work well over high latency limited bandwidth. An increasing number of applications work poorly over this links. Qt4 applications with the default raster backend work poorly sometimes even my workplace's GbE LAN (Qt5 doesn't even give you the option). Let's not even think of running Kate from home.
  No application I actually use supports detaching and re-attaching to a different X server.
  People have been pushed to replace "ssh -X" with NX and Xpra (or, in despair, VNC) because of these limitations (Google about them).
  Similar solutions can be implemented in Wayland and they don't need the protocol to become networks transparent.
  Supporting X11-style network transparency in the Wayland protocol is a futile exercise which compromises the simplicity required by the Wayland model.
  Not to mention, if "ssh -X " and friends suits you... then it will work for a long time. As long as your Wayland session includes XWayland (which it will, probably for ever) and your applications retain a X11 backend, this will still work.
  It's not going to die tomorrow just because we switch to Wayland compositors.
21. Re:Let me guess by Uecker · 2015-03-09 03:00 · Score: 3, Insightful
  
  You can't "improve" X11 without making it not X11. e.g. make IPC async and it's not X any more.
  First, one can extend X11 fairly easily, this has been done in the past. Second, X11 already has asynchronous IPC. Wayland copies this model exactly: Async IPC over a UNIX domain socket (locally). There is no fundamental difference or improvement here.
  
  And at that point you may as well ditch the lot and write it properly, taking advantage of the hardware that every modern PC has to render a desktop decently locally first (the common use case) and taking advantage of existing remoting tech to take care of the uncommon use case.
  Again: bullshit. X11 can do take advantage of the hardware in exactly the same way as Wayland. So this whole argument is build around the misconception that X11 is slow because of something it does to support remoting. This is not true: 1. X11 is not slow (Valve found OpenGL on X11 to be faster than on Windows). 2. Direct rendering essentially works in the same way as Wayland (atleast with DRI3).
  
  And that's what Wayland does - it describes a protocol for a client application to talk directly with a window manager that cuts X11 out of the picture.
  So maybe combining the compositing manager and the server into one piece has a small advantages. I doubt this. But if this is the case, this could be done with X11 as well. No need to ditch a protocol with decades of compatibility.
  
  Weston already demonstrates built in RDP support.
  I don't want RDP. RDP is not compatible with X. RDP is also a propriertary protocol fron Microsoft with a core standardized by the ITU. I sure hell to not want this as a replacement for X.
  
  It wouldn't be a stretch to imagine VNC or other protocols appearing in time to serve different remoting scenarios.
  Yes, implement X. Then come back.
  
  I'm sure that unless you're expecting to play video or games in realtime they would suffice and if you are expecting to play video or games in realtime there are better ways to do those things already.
  I am not playing games. I want my new applications to work with old display servers and old applications to work with new servers. I also want to have perfect integration of remote applications. This is not really about shuffling bits.
22. Re:Let me guess by Crispy+Critters · 2015-03-09 04:18 · Score: 1
  
  It is not clear to me that the big difference lies in the presence or absence of network access. The power lies in the ability to redirect the interface using DISPLAY. Piping through ssh relies on being able to set DISPLAY to a virtual device, e.g. localhost:0.10 and have everything work on this virtual display device disconnected from any hardware and work for every single application.
  Whether the commands to the virtual device are sent to an open port 8000 or sent encrypted over an ssh link doesn't seem to be particularly important. It's the initial step of being able to connect any GUI to an arbitrary virtual display that is key. True, X with no security and an open port 8000 allows anyone to start an X client on the display with no local account needed, but I haven't seen this in use since the demise of the X terminal (good riddance. anyone want one? I need to clean out my office).
  It seems likely that if Wayland compositors support a version of Xnest, then effective networking will work. But it's the initial level of abstraction that is needed.
  Saying that X support will continue as long as codes support X is truly begging the question. The problem is the next time serious modifications to a code are made; in most cases, if network support doesn't happen for free, the developers will not bother.
23. Re:Let me guess by raxx7 · 2015-03-09 06:33 · Score: 1
  
  True, it's not about network access per se.
  Whether you are using "ssh -X" or just using DISPLAY to point your application to another machine, it is useful because of two properties in the X protocol, which Wayland does have.
  Property 1: Although we routinely use shared memory extensions in modern X setups, a lot (including the core functions to which all applications must be able to fall back) works over a socket, which can be a unix local socket or a TCP socket.
  Property 2: The X11 protocol has a slew of very sophisticated features which enabled graphical applications to work around the latency of the communication and to reduce communication bandwidth. An application can store gylphs in the Xserver and then, referencing those gylphs, it can draw nice anti-aliased text using a very small amount of bandwidth.
  Wayland lacks both properties, but property 2 is the big issue.
  Redirecting X11 applications over a network doesn't work well if the application sends a ton of commands synchronously, unless the network is low latency (eg, local LAN).
  Redirecting X11 applications over the network doesn't work well if the application sends the entire graphics window as a single pixmap, untless it's a high bandwith network (eg, local GbE LAN).
  Wayland works over a Unix socket too. And you can set which socket the application will attach to with WAYLAND_DISPLAY.
  The first problem is that the protocol assumes shared memory but it would have not complicated things that much to make it work without requiring shared memory.
  But the real problem is that the only method Wayland applications have to draw is by sending the entire window (surface) as a single pixmap. Works wonderfully over shared memory, works like crap over my cell phone's 3G connection.
  A 800x600 surface rendered at 60 fps requires 86.4 MB/s.
  Adding to Wayland the rich set of server-side rendering features would complicate things too much for Wayland to be possible.
  And it would be a somewhat futile exercise because, increasingly, X11 applications are doing less server side rendering and more pushing of large pixmaps.
24. Re:Let me guess by raxx7 · 2015-03-09 06:48 · Score: 1
  
  should read "which Wayland does _NOT_ have"
25. Re:Let me guess by RightwingNutjob · 2015-03-09 11:12 · Score: 1
  
  You can, but it's a callback function that returns back to Xlib code when it's done, and that's where the exit(-1) gets called. I flirted with the idea of manipulating the call stack to avoid that exit(-1) call, I flirted with the idea of passing back faults instead of calling exit, but both options looked way too error prone and would have taken me way more time than what I ended up doing, which is to split logic from display so that network errors wouldn't kill my core processing.
26. Re:Let me guess by RightwingNutjob · 2015-03-09 11:24 · Score: 1
  
  Well here's the bigger problem then. New applications are doing less server-side rendering. Now you might ask: why should the server bloat itself up on new different button styles and widgets etc, etc? It shouldn't, because then there's no end. And my answer is that you shouldn't have a system with unlimited button styles and glyphs and widgets, because that complexity and bloat will need to live somewhere, and will end up screwing everyone else over no matter where it lands. So let's ask the critical question: why on earth does anyone need to have all the bells and whistles to do their work? They don't. It's an arts and crafts project.
27. Re:Let me guess by raxx7 · 2015-03-09 11:56 · Score: 2
  
  If you insist in asking the wrong question, you'll always get non-sense as an answer.
  The server isn't being bloated with new button styles and widgets. X11 server side rendering is accomplished with a a relatively small number of power primitives which haven't been changed in years.
  The reason why applications are doing less server side rendering, however, has to do with much more than fancy buttons and widgets.
  For example, the Qt4 folks came to the conclusion that their raster backend was quite a bit faster (for local applications, of course) than their X11 backend.
  This matters little for drawing the buttons and widgets of an application. But it does matter a lot for the main application area, specially when it's something a bit more complex than a text editor.
  It matters when you're navigating a PDF in Okular on a not-so-fast laptop. It matters when you're navigating through the mess of wires in an integrated circuit layout application.
  For someone who chastises others for bell and whistles, you can't actually see under the surface.
28. Re:Let me guess by Uecker · 2015-03-09 12:19 · Score: 2
  
  Redirecting X11 applications over a network doesn't work well if the application sends a ton of commands synchronously, unless the network is low latency (eg, local LAN).
  Redirecting X11 applications over the network doesn't work well if the application sends the entire graphics window as a single pixmap, untless it's a high bandwith network (eg, local GbE LAN).
  True, application (or toolkits) are getting worse in this respect. This is sad and just one of the many areas where Linux is regressing. But still, many work well and for those who don't work well over high latency or low bandwidth networks, it is always possible to use a proxy and this would be no worse than with Wayland.
  
  Wayland works over a Unix socket too. And you can set which socket the application will attach to with WAYLAND_DISPLAY.
  Yes, wayland basically has the same design as X - exept it removes a lot of features. This is not progress.
  
  The first problem is that the protocol assumes shared memory but it would have not complicated things that much to make it work without requiring shared memory.
  Yes, then it would be basically an incompatible version of X.
  
  But the real problem is that the only method Wayland applications have to draw is by sending the entire window (surface) as a single pixmap. Works wonderfully over shared memory, works like crap over my cell phone's 3G connection.
  This is not really true. Wayland applications indicate which part of the buffer has changed - so only the changed area would need to be copied. The problem is for cases like scrolling where X applications can copy screen content on the server without transmitting pixel data over the network. Wayland applications cannot really do this, because the protocol is much less flexible (you can do everything you could to with Wayland also with X but not vice versa).
  
  Adding to Wayland the rich set of server-side rendering features would complicate things too much for Wayland to be possible.
  This is a surprising statement. Why would it not be possible? X demonstrates that this is possible!
  
  And it would be a somewhat futile exercise because, increasingly, X11 applications are doing less server side rendering and more pushing of large pixmaps.
  Most X applications (as of today) use Xrender to compose pixmaps on the server. This is still efficient. The main problem with performance on X over the network is latency caused by applications essentially using the protocol in a synchronous way. But it would be much more useful to fix this than to replace everything with a fundamentally less capable graphics layer - which does provide NO functional advantage.
29. Re:Let me guess by RightwingNutjob · 2015-03-09 12:50 · Score: 1
  
  Your points are valid, and make an existence proof for faster graphics than X11 had at the time the Qt4 team made their decision. You still haven't explained why it's not possible to have a graphics system that's faster than X11 and still has network capability the way X11 does. Yes, I know how 2D and 3D rendering works, and yes bandwidth counts so you can play video over a 56k connection for very fundamental reasons.
30. Re:Let me guess by Uecker · 2015-03-09 14:38 · Score: 1
  
  I see. It seems to do this for fatal errors. Yes, xlib sucks. XCB should be better.
31. Re:Let me guess by Uecker · 2015-03-09 17:09 · Score: 1
  
  I do not think that X is badly engineered. Quite the opposite.
  Cairo, for example, is considered to be so good that it has been proposed that it becomes part of the ISO C++ standard.
  I guess if it were still called Xr, people would hate it just because they "know" from reading Phoronix tha everything
  related to X is bloated and slow.
32. Re:Let me guess by phantomfive · 2015-03-09 17:16 · Score: 1
  
  Please note, I wasn't necessarily talking about the original X designers, I was talking about x.org....who for a while couldn't even be bothered to have a release cycle (so distro maintainers could have a stable build).
  
  Maybe someday when I get through reviewing systemd, I'll have a look at X/Wayland/Mir/etc. Until then, I have to say I'm not really an expert on the topic.
  
  --
  "First they came for the slanderers and i said nothing."
33. Re:Let me guess by raxx7 · 2015-03-09 22:34 · Score: 1
  
  Ultimately, I cannot explain to you it's not possible; absence of a solution is not proof of it's non-existence.
  I can enumerate the known difficulties.
  1. Fastest rendering method we have nowadays is direct rendering on the GPU hardware. Second fastest is often server side software rendering. X11 server side rendering often comes last.
  The issue with methods 1 and 2 is that they include the application sending large amounts of pixmaps to the display server (akin to playing video).
  Only effective use of method 3 makes X11's network capabilities useful.
  But, when faced with the decision, application developers tend to favor 1 or 2 and ignore 3.
  History teaches us this: it was happening before the Xrender extension; it happened again now, as Qt5 does not have an effective server side rendering backend.
  Thus, making network capability a core part of the display system can be an exercise in futility, as application developers may simply not make use of it.
  2. Server side rendering, which as I've shown is an integral part of X11's network capabilities, adds considerable complexity to the display server.
  This is an huge issue in Wayland. In Wayland, the display server, the window manager and the compositor are rolled-in into a single program, known as the Wayland compositor.
  To make this work, Wayland compositors must be relatively simple, not much more complicated than X11 window manager/compositors.
  This is not compatible with supporting the sophisticated server side rendering features provided by X11. The X.org display server is a huge program, in part because the X11 protocol is complex.
34. Re:Let me guess by raxx7 · 2015-03-09 23:02 · Score: 1
  
  Sorry, I forgot to add a point 1.5.
  1.5 Even among applications who heavily use server-side rendering, they tend to be more sensitive to network latency and bandwidth than midle-man solutions like NX and Xpra.
  When working remotely from home to work, no application I use behaves as well when using X forwarding as it does under Xpra. A few are completely useless with X forwaring.
  No application I can think of allows itself to be detached from a Xserver and attached to another one.
  The usefulness of X11 network capabilities only works so far, dependind on the application, network latency and bandwidth and whether you need or not detach/reattach.
  For a lot of users of remote display, it's necessary use midle-man solutions like NX and Xpra, ignoring X11's network capabilities.
35. Re:Let me guess by DrXym · 2015-03-10 00:32 · Score: 1
  
  First, one can extend X11 fairly easily, this has been done in the past. Second, X11 already has asynchronous IPC.
  
  First, you don't extend X, you work around it and leave one more bit of dead code to be maintained forever. Second, it is not async.
  
  Again: bullshit. X11 can do take advantage of the hardware in exactly the same way as Wayland
  Sorry you're lying. X11 has no concept of surfaces. The only way of taking advantage of the hardware is to write an extension that composites the scene for X11 and hands it back to X11 to page flip. So X11 is just a 3rd wheel that involves extra context switches for no reason at all.
  
  I don't want RDP. RDP is not compatible with X. RDP is also a propriertary protocol fron Microsoft with a core standardized by the ITU. I sure hell to not want this as a replacement for X.
  Oh boo hoo then implement something else.
  
  Yes, implement X. Then come back.
  Run X over wayland if you're so desperate for some crappy broken network protocol. VNC, RDP and others are more efficient.
  
  I am not playing games. I want my new applications to work with old display servers and old applications to work with new servers.
  
  And Wayland stops you how? Run X11 over wayland and stop crying.
36. Re:Let me guess by Uecker · 2015-03-10 12:01 · Score: 1
  
  First, one can extend X11 fairly easily, this has been done in the past. Second, X11 already has asynchronous IPC.
  First, you don't extend X, you work around it and leave one more bit of dead code to be maintained forever. Second, it is not async.
  http://en.wikipedia.org/wiki/X...
  "In the X Window System core protocol, only four kinds of packets are sent, asynchronously, over the network: requests, replies, events, and errors."
  
  Again: bullshit. X11 can do take advantage of the hardware in exactly the same way as Wayland
  Sorry you're lying. X11 has no concept of surfaces.
  It is called a pixmap.
  
  The only way of taking advantage of the hardware is to write an extension that composites the scene for X11 and hands it back to X11 to page flip. So X11 is just a 3rd wheel that involves extra context switches for no reason at all.
  The extensions already exist. The thing which does this is called a compositing manager. Yes, being a separate process means there are extra context switches (if both run on a single core). I don't think this matters, but I gain, this not a problem of the X protocol. One could just integrate the compositing manager into the server if one really wanted to.
  
  I don't want RDP. RDP is not compatible with X. RDP is also a propriertary protocol fron Microsoft with a core standardized by the ITU. I sure hell to not want this as a replacement for X.
  Oh boo hoo then implement something else.
  Why? You are confused: I just continue to use X. No need to re-implement anything.
  
  Yes, implement X. Then come back.
  Run X over wayland if you're so desperate for some crappy broken network protocol. VNC, RDP and others are more efficient.
  In X there are no differences between local and remote applications and there are powerful and generic ways in which local and remote programs can interoperate. This makes a much better protocol in my opinion. Yes, on low-latency links performance sucks, but one can always use VNC and RDP or XPRA on top of it. But one never gets the ful integration and flexibility of X back when using the other protocols, so they are no replacement.
  
  I am not playing games. I want my new applications to work with old display servers and old applications to work with new servers.
  And Wayland stops you how? Run X11 over wayland and stop crying.
  I am not crying. In fact, I am happy with X. I just point out that I don't see how Wayland has *anything* to offer for a desktop user. Not even performance. But it has disadvantages: And breaking compatibility is most serious one. XWayland only solves one direction (running X clients on Wayland) and not the other (running Wayland clients on X). Finally, there are already mobile devices with Wayland without XWayland, e.g. Jolla. It breaks compatibility with the excellent N9, which is really stupid.
37. Re:Let me guess by DrXym · 2015-03-10 23:11 · Score: 1
  
  In the X Window System core protocol, only four kinds of packets are sent, asynchronously, over the network: requests, replies, events, and errors.
  That whole request / reply bit sailed over your head I see. The wire might be asynchronous but Xlib, the library that virtually all client code uses is filled with synchronous code that sends the request and waits for the reply. e.g. call XGetWindowAttributes and it will block until the response comes back.
  There have been attempts to use xcb instead which is an async API but it turns out writing async code is hard, particularly when dealing with legacy code and an arcane windowing system that sends out a storm of messages. It's not hard to find xcb backend projects that have floundered.
  
  It is called a pixmap.
  A pixmap is not a surface. A surface is a texture under the management of a GPU (or software emulation of a GPU). X has no concept of surface. It is damage based windowing system. Hence the reason for extensions to work through this.
  
  I am not crying. In fact, I am happy with X. I just point out that I don't see how Wayland has *anything* to offer for a desktop user. Not even performance. But it has disadvantages: And breaking compatibility is most serious one. XWayland only solves one direction (running X clients on Wayland) and not the other (running Wayland clients on X). Finally, there are already mobile devices with Wayland without XWayland, e.g. Jolla. It breaks compatibility with the excellent N9, which is really stupid.
  If you don't see why it has anything to offer I suggest you look at the Wayland website where it explains in detail why X is broken. If virtually every X developer can see the need then I don't see why others can't.
38. Re:Let me guess by Uecker · 2015-03-11 05:19 · Score: 1
  
  In the X Window System core protocol, only four kinds of packets are sent, asynchronously, over the network: requests, replies, events, and errors.
  That whole request / reply bit sailed over your head I see. The wire might be asynchronous but Xlib, the library that virtually all client code uses is filled with synchronous code that sends the request and waits for the reply. e.g. call XGetWindowAttributes and it will block until the response comes back.
  True. But you claimed X11 does not have async IPC.This is clearly false. Also a lot of stuff is asynchronous even in Xlib. If your point is that Xlib sucks I agree with you - but this does not imply that one needs to invent a new on-the-wire protocol.
  
  There have been attempts to use xcb instead which is an async API but it turns out writing async code is hard, particularly when dealing with legacy code and an arcane windowing system that sends out a storm of messages. It's not hard to find xcb backend projects that have floundered.
  Wayland is - as you point out - also an async API. I also used xcb myself, and did not find it too difficult. (most developers woulde use a toolkit and do no care anyway). Legacy code is not a valid criticism. Arcance is simply your personal opinion. I find the X protocol quite OK. "Storms of messages" may be true in some cases, but is not really a problem in an async API or for local clients and could also be easily adressed without rewriting everything and breaking compatibility.
  
  It is called a pixmap.
  A pixmap is not a surface. A surface is a texture under the management of a GPU (or software emulation of a GPU). X has no concept of surface.
  I am bit puzzled why you think a pixmap could not be on the GPU.
  
  It is damage based windowing system. Hence the reason for extensions to work through this.
  I am not sure what this has to do with what you said before and why you think Wayland would not be damaged-based, e.g. the client also tells the compositer which part of a buffer is damaged:
  wl_surface::damage - mark part of the surface damaged
  
  I am not crying. In fact, I am happy with X. I just point out that I don't see how Wayland has *anything* to offer for a desktop user. Not even performance. But it has disadvantages: And breaking compatibility is most serious one. XWayland only solves one direction (running X clients on Wayland) and not the other (running Wayland clients on X). Finally, there are already mobile devices with Wayland without XWayland, e.g. Jolla. It breaks compatibility with the excellent N9, which is really stupid.
  If you don't see why it has anything to offer I suggest you look at the Wayland website where it explains in detail why X is broken.
  
  I looked at the website before. I even watched the stupid talk everybody refers to all the time. I still see no real advantage.
  
  If virtually every X developer can see the need then I don't see why others can't.
  That seems to be a myth spread by Wayland proponents.
priorities by Anonymous Coward · 2015-03-08 16:33 · Score: 1

they can do this but won't give us damn sorting on gmail
Re:The Penislicker Is Not Smart by Zontar+The+Mindless · 2015-03-08 17:01 · Score: 1, Funny

Shouldn't you finish cleaning the deep fryer before your manager gets back?

--
Il n'y a pas de Planet B.
Re:Isnt freon by Anonymous Coward · 2015-03-08 19:06 · Score: 3, Informative

Freon is an organic chemical, not a noble gas. Actually, it's freons (plural) because the name is a trademarked trade name for a class of hydrocarbon products produced by DuPont.
Re:Obligatory XKCD comic by BronsCon · 2015-03-08 20:15 · Score: 2

Highlight, right click, click, that's two extra steps that everyone has to do, just to save one person one extra step. You're not, by chance, a shade efficiency consultant, are you?

--
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Re:The Penislicker Is Not Smart by BronsCon · 2015-03-08 20:20 · Score: 3, Funny

I worked in fast food for 3 years (not a point of pride, just a fact) and I can tell you they don't clean those things...

--
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Re:The Penislicker Is Not Smart by Zontar+The+Mindless · 2015-03-08 20:59 · Score: 3, Informative

I worked breakfast time at a Hardee's while at school, and we had to suck out all the oil, run it through a filter, and scrub the inside of the fryer every morning at the end of the shift. Of course this was back in the 80s, things might have changed since then.

--
Il n'y a pas de Planet B.
Linux is not an OS by aNonnyMouseCowered · 2015-03-08 22:31 · Score: 3, Informative

" The OS also happens to be called Chrome but it is just a variant of Linux."
WTF is this modded insightful. Linux is just the kernel, maybe the heart of the operating system, but not the OS itself. The OS is the kernel and the whole bunch of other stuff that allows you to run the program you click, type or tap at. See: Ubuntu can be called an OS, a variant of what some free software advocates call GNU/Linux (but actually a little bit more). Android is an OS, mostly without GNU components, also based on the Linux kernel. OpenWRT is an embedded Linux-based OS for routers and other network devices. Chrome OS is another OS that runs on top of the Linux kernel.
1. Re:Linux is not an OS by Dragonslicer · 2015-03-09 03:28 · Score: 3, Insightful
  
  Linux is just the kernel, maybe the heart of the operating system, but not the OS itself. The OS is the kernel and the whole bunch of other stuff that allows you to run the program you click, type or tap at.
  That depends on exactly how you want to define "operating system". You can make the argument that the "operating system" really is just the kernel, and that everything else, including the X server, are user-level programs. In particular, this is true in Linux, where many system services that some people would consider part of the operating system are just normal processes.
2. Re:Linux is not an OS by LordLimecat · 2015-03-09 07:21 · Score: 1
  
  Nice try, Richard Stallman, you cant fool us.
3. Re:Linux is not an OS by shutdown+-p+now · 2015-03-09 20:36 · Score: 1
  
  This is modded "insightful" because most everyone on the planet uses "Linux" to refer to the entire OS, and people have a pretty good understanding of what it actually is.
Re:Isnt freon by drinkypoo · 2015-03-09 00:28 · Score: 2

You could however die if enough freon leaked into a room and it displaced the oxygen. But you would smother (lack of oxygen) not be poisoned.
It doesn't even take that. You can just get it into your lungs. Because it's heavier than air, you have to do some really heavy breathing to expel enough of it to restore normal breathing function. It's also a big part of the reason why we don't use pits for automotive maintenance any more. Besides the risk of driving into them (heh heh) there's also the risk of refrigerant leaking out of a vehicle, settling in the pit, and killing mechanics. CO and CO2 are also heavier-than-air, though, so they're just bad things. You don't want a blower in there in case of fire...

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Why not jump on board with Wayland or Mir? by chris_clay · 2015-03-09 03:24 · Score: 1

Not sure why Google is going their own way rather than jumping on with other projects that are already heading down this path. The X11 replacement is a controversial one. I have found X11 to be excellent over the years and have no plans to replace it. It does the job for me and has sufficient performance.
Re:Obligatory XKCD comic by BronsCon · 2015-03-09 04:55 · Score: 1

Hover over the link and the URL pops up. Been that way for over a decade. Also, what makes you think it was me who fixed it? Clearly, I don't post anon, Anon.

--
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Freon already a registerd name. by Stan92057 · 2015-03-09 05:15 · Score: 1

Just a guess,they might want to change the name.

"Freon is a registered trade name of DuPont"

--
Jack of all trades,master of none
Re:Anybody remember framebuffer madness? by spitzak · 2015-03-09 07:07 · Score: 1

The acceleration is now accessible by the client program as it draws into it's own frame buffer. On modern systems the client program can use the GPU as a resource to compute it's own results.
Wayland mostly is providing a way of telling a central service how to combine the client's frame buffer with all the other clients into the image put on the screen.