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

Comments

Obligatory XKCD comic

[Anonymous Coward]

Is obligatory https://xkcd.com/927/

Re:Obligatory XKCD comic

[Anonymous Coward]

Fixed that for you
(Somehow it seems wrong that actually "fixing that for you" borders on the ironic.)

Re:Obligatory XKCD comic

[Anonymous Coward]

What is fixed? It's the same link! Or am I losing something?

Re:Obligatory XKCD comic

[Anonymous Coward]

The first was text, the second was an actual, clickable, link.

Re:Obligatory XKCD comic

[Anonymous Coward]

In a modern browsers, selecting the text gives you an insta-click option. Haven't tried lynx in a while, though.

Re:Obligatory XKCD comic

[BronsCon]

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?

Re:Obligatory XKCD comic

[BronsCon]

TYPOS! DAMN! shade == shady.

Re:Obligatory XKCD comic

[Anonymous Coward]

> Highlight, right click, click, that's two extra steps that everyone has to do

Nope. Highlight URL and drag URL to empty space on tab toolbar. Done, page opens automatically.

And it is actually safer, because you're reading which URL will open. Proper links (as the one you fixed) must have the real URL in square brackets (thx /.) because of trolls (clearly not your case, but it's a nuisance).

Re:Obligatory XKCD comic

[BronsCon]

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.

Re:Obligatory XKCD comic

[Anonymous Coward]

Sorry, my bad. Jumped to the wrong conclusion. Have a nice day!

Chrome

[Anonymous Coward]

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.

Re:Chrome

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

Re:Chrome

[Loconut1389]

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

[tepples]

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:DRM stands for

[linuxrocks123]

Correct. Not the first time that acronym has been confusing.

Re:DRM stands for

[Culture20]

Don't get me started on KVM.

Re:DRM stands for

[hawkinspeter]

Why not? It's a great little hypervisor.

Re:DRM stands for

[Culture20]

"I used this KVM* the other day to set up KVM^"

*switch
^hypervisor.

YANIH

[NotInHere]

yet another not invented here.

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

Re:YANIH

[pavon]

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:YANIH

[NotInHere]

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

Re:YANIH

[dmbasso]

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:YANIH

[Anonymous Coward]

in a way that's only going to be use by then instead of fixing fbdev, it seems.

Re:YANIH

[slack_justyb]

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!!

Re:YANIH

[NotInHere]

Why can upstart be added?

Re:YANIH

[Lemming Mark]

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.

Re: YANIH

[Anonymous Coward]

bzr is older than git, but they should really change it anyway.

Re:YANIH

[bickerdyke]

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

Re:YANIH

[DrXym]

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.

Re: YANIH

[DrXym]

Even Microsoft supports git these days through Visual Studio and its online team foundation server backend. That should say something.

Re:YANIH

[serviscope_minor]

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:YANIH

[andydread]

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.

Re:YANIH

[Rich0]

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:YANIH

[drinkypoo]

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: YANIH

[slack_justyb]

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.

Re:YANIH

[Rich0]

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: YANIH

[jedidiah]

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

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

Re:YANIH

[serviscope_minor]

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

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

Re: YANIH

[serviscope_minor]

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.

Re:YANIH

[Rich0]

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: YANIH

[Anonymous Coward]

makes since. geesh, if
you dont know the saying, dont use it.

Re: YANIH

[bluefoxlucid]

2500 years ago, schools taught people how to learn. 100 years ago, schools taught people things. Today, schools are daycare with incidental learning.

Re: YANIH

[bluefoxlucid]

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:YANIH

[serviscope_minor]

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.

I am going to fork it.

[funwithBSD]

and develop R22 as a replacement.

Re: I am going to fork it.

[rkcth]

I'm leapfrogging that and doing straight to R410A

Re: I am going to fork it.

[Anonymous Coward]

I'm going with R1234yf because it's the same as the combination on my luggage.

Re: I am going to fork it.

[Anonymous Coward]

Ha! I'm already developing R600a. If it leaks memory, the computer explodes in a fireball.

The Browser is NOT the OS

[duckintheface]

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

[Anonymous Coward]

Google wants

Every day what Google wants drifts farther away from what I want as both a user and a developer. At least this is only infecting their own playground...for now.

Re:The Browser is NOT the OS

[Anonymous Coward]

Marketing success aside, I feel like the last thing we need concerning tech in the consumer market is more confusion. Personally, I don't like it; that is, from a ~philosophical~ standpoint.

Re:The Browser is NOT the OS

[The MAZZTer]

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

Re: The Browser is NOT the OS

[the_humeister]

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:The Browser is NOT the OS

[Anonymous Coward]

Eh, it's cool, but there was that QNX demo that fit an entire RTOS with GUI and web browser in 1440k. Yeah, that was Web 1.0, but 'twas most impressive even then. You could download it in under 20 minutes over a 14.4kbps connection.

Re: The Browser is NOT the OS

[BronsCon]

Really kinda wanna know this, too, as I'm still considering a Chromebook Pixel, but it this breaks Crouton, I'll pass.

Re: The Browser is NOT the OS

[Anonymous Coward]

I believe the purpose of the "xiwi" (crouton in a tab) work was to allow it to not break when Google dropped X.

Re:The Browser is NOT the OS

[tigersha]

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: The Browser is NOT the OS

[Anonymous Coward]

x11 really needs a secure replacement. not sure google can provide this, though.

Re:The Browser is NOT the OS

[Anonymous Coward]

Google wants

Every day what Google wants drifts farther away from what I want as both a user and a developer. At least this is only infecting their own playground...for now.

Really, it's always been that way, at least for years. The Big Companies all wish they could just lock down the entire stack and the internet, too, and force you to suck their balls.

Re:The Browser is NOT the OS

[Anonymous Coward]

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

Improvement?

Re:The Browser is NOT the OS

[brunes69]

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.

Re: The Browser is NOT the OS

[muirhead]

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

Re: The Browser is NOT the OS

[Anonymous Coward]

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?

I rather use PB&J. It's stick to the upper stack sometimes, but It's much more stable.

Re:The Browser is NOT the OS

[jedidiah]

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

[mrchaotica]

Indeed; confusopolies are evil.

Re:The Browser is NOT the OS

[Anonymous Coward]

Immersing myself into the world of QNX for a current real-time project has been similar to bathing in a software based cesspit. I can honestly say in 15 years of engineering Ive not read anything more ridiculous than associating "forced to work with QNX for a week" and "how things were supposed to be done". Thread pools to handle messages, latency, non-consistent API, and poor documentation are attributes I associate with QNX. Another is non-existent support which is evident by the virtual tumbleweed rolling across the QNX discussion boards. Windows, BSD, Linux, DSP/BIOS, FreeRTOS.... ANYTHING but QNX! Are you having a laugh or do you genuinely believe QNX is the way it was supposed to be done!?

Re:The Browser is NOT the OS

[Anonymous Coward]

I think @tigersha must be being sarcastic... that's the only logical explanation for his comments as QNX is utter : )

Freon? You gotta be kidding:

[Hartree]

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: Freon? You gotta be kidding:

[Anonymous Coward]

Or named after that pesky dihydrogen monoxide..

Re: Freon? You gotta be kidding:

[Anonymous Coward]

Elixir sulfanilamide is a good choice for a name.

Re:Freon? You gotta be kidding:

[Lije Baley]

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:Freon? You gotta be kidding:

[BigDish]

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: Freon? You gotta be kidding:

[Anonymous Coward]

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.

Re:Freon? You gotta be kidding:

[K. S. Kyosuke]

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

Re:Freon? You gotta be kidding:

[sjames]

Hexavalent Chrome, of course.

Re:Freon? You gotta be kidding:

[El_Muerte_TDS]

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

Re:Freon? You gotta be kidding:

[amalcolm]

Not quite - remember the Apple Music (the Beatles label) vs Aplle Inc lawsuit?

Re:Freon? You gotta be kidding:

[BronsCon]

Microsoft cookies... would those be like Chips-Ahoy Soft Batch Minis, but smaller? Take my paycheck. All of it. Now.

Re:Freon? You gotta be kidding:

[dunkelfalke]

Nuff said

Re:Freon? You gotta be kidding:

[Anonymous Coward]

Quite correct, but just because nits need to be picked, it was Apple Corps Ltd (which includes Apple Records) vs Apple Inc.

Re:Freon? You gotta be kidding:

[Rei]

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

Re:Freon? You gotta be kidding:

[Anonymous Coward]

In other news, attempts to port the popular KDE theme "Ozone" to Chrome OS have been abandoned.

Re:Freon? You gotta be kidding:

[TheRealHocusLocus]

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.

Re:Freon? You gotta be kidding:

[Anonymous Coward]

It will be a condensate of Einsteinum Monoxymoron.

Re:Freon? You gotta be kidding:

[rossdee]

"Or just go for nickel tetracarbonyl"

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

Re:Freon? You gotta be kidding:

[rjstanford]

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:Freon? You gotta be kidding:

[Anonymous Coward]

R-717 - may be incompatible with Coppermine

Re: Freon? You gotta be kidding:

[Anonymous Coward]

Elixir sulfanilamide is a good choice for a name.

Zyklon-B would be good too (any copyrights/trademarks should be expired now).

Re:Freon? You gotta be kidding:

[Anonymous Coward]

UKOD - "Undisputed King of the OS Destroyers"

Re:The Penislicker Is Not Smart

[Anonymous Coward]

you sounds like a total penislicker. how do you type so much? don't you have penis licking to do? Penislicker.

pee wee herman loves to dance

[Anonymous Coward]

[@CadWork] I used to be afraid to eat bananas at the office because we had a known homosexual in my dept

Re: pee wee herman loves to dance

[Anonymous Coward]

WHAT
  ARE you smoking abd where can I GET SOME? IN the mood to get bakedddddd

Let me guess

[RightwingNutjob]

Network transparency is not supported because noone uses it.

Re:Let me guess

[Anonymous Coward]

On a lightweight, framebuffer-like layer running on a netbook, how is it relevant?

Re:Let me guess

[thegarbz]

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:Let me guess

[NotInHere]

From an X11 developer: "Stop saying that because its rubbish"

Re:Let me guess

[Uecker]

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:Let me guess

[Severus Snape]

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:Let me guess

[RightwingNutjob]

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.

Re:Let me guess

[Anonymous Coward]

control - alt - t to open up a command line shell you can ssh from.

Re:Let me guess

[Uecker]

, 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:Let me guess

[Uecker]

I know that. But X11 tunneling does not work.

Re:Let me guess

[sjames]

I smell burning pants!

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

Re:Let me guess

[phantomfive]

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.

Re:Let me guess

[TheRaven64]

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.

Re:Let me guess

[thegarbz]

*puts practical hat on*

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

Re:Let me guess

[serviscope_minor]

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:Let me guess

[DrXym]

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.

Re:Let me guess

[thegarbz]

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)

Re:Let me guess

[Anonymous Coward]

I guess we'll all have to break out the crossover cables again?

Re:Let me guess

[maestroX]

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.

Re:Let me guess

[Anonymous Coward]

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.

Isn't this exact use case what we use web servers for?

Re:Let me guess

[Viol8]

"And network transparancy is not a core capability,"

Er yes. It Is.

Re:Let me guess

[Viol8]

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:Let me guess

[multi io]

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:Let me guess

[drinkypoo]

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?

Re:Let me guess

[raxx7]

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:Let me guess

[Uecker]

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:Let me guess

[Crispy Critters]

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.

Re:Let me guess

[raxx7]

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.

Re:Let me guess

[raxx7]

should read "which Wayland does _NOT_ have"

Re:Let me guess

[RightwingNutjob]

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.

Re:Let me guess

[RightwingNutjob]

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.

Re:Let me guess

[raxx7]

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.

Re:Let me guess

[Uecker]

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.

Re:Let me guess

[RightwingNutjob]

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.

Re:Let me guess

[Uecker]

I see. It seems to do this for fatal errors. Yes, xlib sucks. XCB should be better.

Re:Let me guess

[Uecker]

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:Let me guess

[phantomfive]

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.

Re:Let me guess

[raxx7]

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.

Re:Let me guess

[raxx7]

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.

Re:Let me guess

[DrXym]

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.

Re:Let me guess

[Uecker]

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.

Re:Let me guess

[DrXym]

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.

Re:Let me guess

[Uecker]

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.

Isnt freon

[Anonymous Coward]

A toxic gas that sometimes leaks from things like air conditioner? Lol?

Re: Isnt freon

[Anonymous Coward]

The Freon MSDS doesn't show any tox hazard, just the ozone depletion potential it's so infamous for.

Re:Isnt freon

[theshowmecanuck]

Freon is a noble gas. It will not react easily if at all (I haven't looked at the properties of freon but I know it is used in refrigeration at least in part because it is basically inert... however I know if you really force the issue you can get xenon to react with fluorine). Therefore it cannot be toxic. 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.

Re:Isnt freon

[Anonymous Coward]

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:Isnt freon

[Anonymous Coward]

developer

Re:Isnt freon

[Anonymous Coward]

s/hydrocarbon/chlorofluorocarbons/

Re:Isnt freon

[drinkypoo]

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

priorities

[Anonymous Coward]

they can do this but won't give us damn sorting on gmail

Air conditioning

[Anonymous Coward]

Free air conditioning. Yipppppeeeeeee!!!!!!!

Re:The Penislicker Is Not Smart

[Zontar The Mindless]

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

please fix seabios on asus c200m

[Anonymous Coward]

^^^

Chromium embedded

[Anonymous Coward]

Now we may have something to work with.

https://code.google.com/p/chromiumembedded/

As long as it can be built like this. Put something like Slitaz's tax panel (browser based config system) and you have a nice embed-able system.

This could be a truly cross platform sdk. Just write your game and it can run on any pc, Mac, console or other devices with compatible graphics.

  Who wants to port Fabrice Bellard's tinyGL, so it can run (unaccelerated) on anything?

Re: Chromium embedded

[Anonymous Coward]

Fuck Chrome OS. I don't gaf what they do to it. I'd sooner run windows 98.

Re: Chromium embedded

[Anonymous Coward]

Fuck Chrome OS. I don't gaf what they do to it. I'd sooner run windows 98.

Having used both I can safely say I'd prefer Chrome OS. Windows 98 was the biggest pile of digital garbage ever palmed off on the unsuspecting computer using public. However, given half a chance I'd swap Chrome OS out for practically anything else at the first possible opportunity.

Re:Oh, but IT IS

[Anonymous Coward]

As far as all the web apps are concerned, the browser is the OS. It may not be the conventional OS but it does I/O, handles memory, runs multiple applications.

Re:The Penislicker Is Not Smart

[BronsCon]

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

Re:The Penislicker Is Not Smart

[Zontar The Mindless]

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: Oh, but IT IS

[Anonymous Coward]

the browser is just a sandbox using the os. most of the goodness comes from linux.

Linux is not an OS

[aNonnyMouseCowered]

" 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

[Dragonslicer]

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:Linux is not an OS

[LordLimecat]

Nice try, Richard Stallman, you cant fool us.

Re:Linux is not an OS

[Anonymous Coward]

Gb2MIT richard. I'm so tired of guys posting this garbage since 1995, yeah dude I know linux is the kernel and the rest is mostly gnu ok yeah got it. Can we just call it linux for simplicity during discussion and not allow autism to ooze out our pores thanks.

Re:Linux is not an OS

[shutdown -p now]

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.

Could Android & ChromeOS merge?

[phinnvr6]

Couldn't Android and ChromeOS merge into a single OS by now? It would be another Linux distro that supports x86 / ARM? Call it Android since the world actually knows the difference between that and a web browser. This current effort reminds me of Android 3.x Honeycomb that supported tablets and not phones, where this supports laptops not mobile devices. Why not merge?

Walled Garden

[Anonymous Coward]

All this meddling with the kernel and init system is going to result in a walled garden...

Re:The Penislicker Is Not Smart

[Anonymous Coward]

The Frymasters have built-in filtration systems now. Basically the only thing that needs to be done is to replace the oil on a regular basis.

Why not jump on board with Wayland or Mir?

[chris_clay]

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.

Anybody remember framebuffer madness?

[Anonymous Coward]

Was the big hype during 80s 90s and Sun fell for it big time.
Why did we abandon frame buffers (direct pixel access, no less) back then? It simply didn't scale.
2D accelleration, managed by a central instance (well, the Xserver) did wonders for that.
And now everything we've gained it suddenly bad?

Re:Anybody remember framebuffer madness?

[spitzak]

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.

Freon already a registerd name.

[Stan92057]

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

"Freon is a registered trade name of DuPont"

Re:The Penislicker Is Not Smart

[Anonymous Coward]

> I worked breakfast time at a Hardee's while at school, and we had to suck out all the oil

I worked at Hardee's too. Damn, I went through a lot of straws sucking out that oil...