Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Graphics X GUI Google Operating Systems Software Linux

Google Introduces Freon, a Replacement For X11 On Chrome OS 166

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).
This discussion has been archived. No new comments can be posted.

Google Introduces Freon, a Replacement For X11 On Chrome OS

Comments Filter:
  • Chrome (Score:4, Insightful)

    by Anonymous Coward on Sunday March 08, 2015 @11:24PM (#49212577)

    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.

    • by duckintheface ( 710137 ) on Sunday March 08, 2015 @11:45PM (#49212651)

      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.

      • "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.
      • by the_humeister ( 922869 ) on Monday March 09, 2015 @01:56AM (#49213067)

        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?

      • Linux is not an OS (Score:4, Informative)

        by aNonnyMouseCowered ( 2693969 ) on Monday March 09, 2015 @06:31AM (#49213697)

        " 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.

        • by Dragonslicer ( 991472 ) on Monday March 09, 2015 @11:28AM (#49215339)

          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.

        • 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.

      • by brunes69 ( 86786 )

        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

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      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.

  • DRM stands for (Score:5, Informative)

    by tepples ( 727027 ) <tepples@gmail.TEAcom minus caffeine> on Sunday March 08, 2015 @11:26PM (#49212581) Homepage Journal

    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.

  • by NotInHere ( 3654617 ) on Sunday March 08, 2015 @11:39PM (#49212619)

    yet another not invented here.

    At least they are not as bad as Canonical, which not just have mir, but also bzr.

    • by pavon ( 30274 )

      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.

      • Yes you are right, I RTFA, and the subject is misleading.

      • According to TFS, Chrome will use OpenGL (ES). Which is quite a long way to pixel-handle the framebuffer.

      • 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 credib
    • Re:YANIH (Score:4, Insightful)

      by dmbasso ( 1052166 ) on Monday March 09, 2015 @12:47AM (#49212907)

      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.

      • Why can upstart be added?

      • 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 sur

        • by DrXym ( 126579 )

          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.

    • 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 ev

      • Re:YANIH (Score:4, Insightful)

        by serviscope_minor ( 664417 ) on Monday March 09, 2015 @05:32AM (#49213543) Journal

        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?

        • by Rich0 ( 548339 )

          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?

          • 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.

            • by Rich0 ( 548339 )

              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.

          • How did you get it to work under the old system?

            ACPId called a shell script in /etc, which I could edit.

            • by Rich0 ( 548339 )

              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.

              • 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 d

        • 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 ret
          • by jedidiah ( 1196 )

            No. You're just confusing "newer" with "progress".

            They aren't the same thing by a long shot.

            • 2500 years ago, schools taught people how to learn. 100 years ago, schools taught people things. Today, schools are daycare with incidental learning.
          • 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

            • 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.

  • by funwithBSD ( 245349 ) on Sunday March 08, 2015 @11:45PM (#49212649)

    and develop R22 as a replacement.

  • by Hartree ( 191324 ) on Sunday March 08, 2015 @11:47PM (#49212659)

    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?

    • 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".

    • by BigDish ( 636009 )

      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.

    • Speaking of metallic polish, perhaps chromium hexacarbonyl would be a better fit? Or just go for nickel tetracarbonyl if you really mean it.
      • by rossdee ( 243626 )

        "Or just go for nickel tetracarbonyl"

        Isn't that what the Dorsai people of Foralie district used to disable Dow Decastries troops?

    • by sjames ( 1099 )

      Hexavalent Chrome, of course.

      • by Rei ( 128717 )

        I'm betting that Freon leaks. And that it destroys its operating environment.

    • I guess Google needs to put this project back in the fridge and think about it a bit more.

    • FREON indeed.
      How about X12? It is only an XML exchange standard [wikipedia.org], an experimental superhuman [x12superhuman.com] and adjustable bed [sleepnumber.com].

      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 b

  • Let me guess (Score:2, Insightful)

    Network transparency is not supported because noone uses it.
    • 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.

      • 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.

        • *puts practical hat on*

          Hardly. Not every bit of data is worth collecting. Plus it's a direct PC to PC connection.

      • 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.

    • From an X11 developer [youtu.be]: "Stop saying that because its rubbish"

      • Re:Let me guess (Score:5, Insightful)

        by RightwingNutjob ( 1302813 ) on Monday March 09, 2015 @01:43AM (#49213027)
        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.
        • by Uecker ( 1842596 )

          , 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.

          • 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.
        • 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

        • Re: (Score:2, Insightful)

          by DrXym ( 126579 )
          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
          • Re:Let me guess (Score:4, Insightful)

            by Uecker ( 1842596 ) on Monday March 09, 2015 @11:00AM (#49215107)

            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.

            • by DrXym ( 126579 )

              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 crap

        • 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 consciousl

          • by Viol8 ( 599362 )

            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.

        • 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.
        • 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 [microsoft.com] (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 Connec

        • Re:Let me guess (Score:5, Insightful)

          by raxx7 ( 205260 ) on Monday March 09, 2015 @08:24AM (#49214057) Homepage

          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.

          • 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

            • by raxx7 ( 205260 )

              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 ver

              • by raxx7 ( 205260 )

                should read "which Wayland does _NOT_ have"

              • 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 quest
                • by raxx7 ( 205260 )

                  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

                  • 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.
                    • by raxx7 ( 205260 )

                      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

                    • by raxx7 ( 205260 )

                      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 c

              • by Uecker ( 1842596 )

                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 t

      • by sjames ( 1099 )

        I smell burning pants!

        Redefining a well understood thing and then claiming it never existed is disingenuous at best.

      • 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.
        • by Uecker ( 1842596 )

          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.

          • 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.
    • by Uecker ( 1842596 )

      Not being able to simple use 'ssh -X' from my chromebook is the one thing I really miss. Ofcourse, crouton comes to the rescue...

    • 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.
  • Just a guess,they might want to change the name.

    "Freon is a registered trade name of DuPont"

You can not get anything worthwhile done without raising a sweat. -- The First Law Of Thermodynamics

Working...