Slashdot Mirror
Google Introduces Freon, a Replacement For X11 On Chrome OS
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).
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.
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.
yet another not invented here.
At least they are not as bad as Canonical, which not just have mir, but also bzr.
and develop R22 as a replacement.
Never answer an anonymous letter. - Yogi Berra
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
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?
From an X11 developer: "Stop saying that because its rubbish"
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.
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.
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.
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.
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.
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)
" 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.
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.
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.'"
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.
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.
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.