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