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).
Chrome (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.
The Browser is NOT the OS (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.
Re:The Browser is NOT the OS (Score:5, Informative)
Re: (Score:3, 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.
Re: The Browser is NOT the OS (Score:5, 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?
Re: (Score:2)
Re: (Score:3, 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 [openhub.net]
Linux is not an OS (Score:4, 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.
Re:Linux is not an OS (Score:4, 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.
Re: (Score:2)
Nice try, Richard Stallman, you cant fool us.
Re: (Score:2)
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: (Score:2)
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:The Penislicker Is Not Smart (Score:4, Funny)
Re:The Penislicker Is Not Smart (Score:4, 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.
Re: (Score:2)
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.
Re: (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.
DRM stands for (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.
Re: (Score:3)
Correct. Not the first time that acronym has been confusing.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
*switch
^hypervisor.
YANIH (Score:3)
yet another not invented here.
At least they are not as bad as Canonical, which not just have mir, but also bzr.
Re: (Score:2)
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.
Re: (Score:2)
Yes you are right, I RTFA, and the subject is misleading.
Re: (Score:2)
According to TFS, Chrome will use OpenGL (ES). Which is quite a long way to pixel-handle the framebuffer.
Re: (Score:3)
Re:YANIH (Score:4, 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.
Re: (Score:2)
Why can upstart be added?
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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)
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?
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
How did you get it to work under the old system?
ACPId called a shell script in /etc, which I could edit.
Re: (Score:2)
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.
Re: (Score:3)
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
Re: YANIH (Score:2)
Re: (Score:2)
No. You're just confusing "newer" with "progress".
They aren't the same thing by a long shot.
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
I am going to fork it. (Score:5, Funny)
and develop R22 as a replacement.
Re: I am going to fork it. (Score:2)
I'm leapfrogging that and doing straight to R410A
Freon? You gotta be kidding: (Score:3, 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?
Re: (Score:3)
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".
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Nuff said [lachschon.de]
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
"Or just go for nickel tetracarbonyl"
Isn't that what the Dorsai people of Foralie district used to disable Dow Decastries troops?
Re: (Score:2)
Hexavalent Chrome, of course.
Re: (Score:3)
I'm betting that Freon leaks. And that it destroys its operating environment.
Re: (Score:3)
I guess Google needs to put this project back in the fridge and think about it a bit more.
Re: (Score:2)
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)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
*puts practical hat on*
Hardly. Not every bit of data is worth collecting. Plus it's a direct PC to PC connection.
Re: (Score:2)
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.
Re: (Score:3)
From an X11 developer [youtu.be]: "Stop saying that because its rubbish"
Re:Let me guess (Score:5, Insightful)
Re: (Score:2)
, 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.
Re: (Score:2)
Re: (Score:2)
I see. It seems to do this for fatal errors. Yes, xlib sucks. XCB should be better.
Re: (Score:2)
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)
Re:Let me guess (Score:4, 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.
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
"And network transparancy is not a core capability,"
Er yes. It Is.
Re: (Score:2)
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)
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.
Re: (Score:2)
Whether the commands to the virtual device are sent to an open port 8000 or sent encrypted over an ssh link doesn't seem
Re: (Score:2)
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
Re: (Score:2)
should read "which Wayland does _NOT_ have"
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:2)
I smell burning pants!
Redefining a well understood thing and then claiming it never existed is disingenuous at best.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Not being able to simple use 'ssh -X' from my chromebook is the one thing I really miss. Ofcourse, crouton comes to the rescue...
Re: (Score:2)
I know that. But X11 tunneling does not work.
Re: (Score:2)
Freon already a registerd name. (Score:2)
"Freon is a registered trade name of DuPont"
Re: (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: (Score:3)
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
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
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.