The Google Chrome OS

If you don't want to use X and you want good performance then you'll have to figure out your own acceleration framework. It won't be a simple framebuffer driver because a simple framebuffer driver provides no means to take advantage of any GPU features.

So, sure, you could possibly do Wayland or recreate the standalone OpenGL application, but for what purpose? Just so you don't have to use XCB?

Wayland has possibilities because GTK is ported to Wayland's native API and Google's Chrome for Linux uses GTK. But even then it's going to require a lot of work on Google's part to reach feature parity with just using what everybody else already uses. Think about multi-monitor support, HDMI output, input hotplugging, etc etc. There is a LOT of things that Xorg does for you that Google would either go without or have to recreate on their own.

A framebuffer driver is just that.. you take information and you write it out to a framebuffer. It's a memory region. It does not get you any sort of OpenGL acceleration or hardware scaling or accelerated YUV to RGB conversion or anything like that. Your worse off, efficiency-wise, with a plain FB driver then you were back in VGA graphics days.

Xorg provides a framework for 2D and 3D acceleration. It's almost always going to have better performance then a simple FB driver unless something is severely broken.

If you don't want to use Xorg then you have to replace it with something else.

Wayland is a possibility and it provides it's own 2D and 3D acceleration whatnot. But it's not mature.

Ha. :)

If you make it hard to use traditional applications it won't make people not want to use those applications, it'll just make them not want to run your OS.

> 'Solved' again by not letting you use those applications.

Yep. And users will 'solve' the problem the same way that they solved the problem for older Netbook "web centric" Linux OSes.. get somebody to install Windows over it.

> The issue is the same here as the kernel is Linux the drivers are the same.

Printer drivers are not Linux kernel drivers. They are userspace. You need to have some speciality programs to support crappy printers that are so dumb that they can't understand postscript, but even then they don't have anything to do with the kernel. It's done through things like libusb and printer port-over-USB and whatnot. It doesn't require much of anything from the kernel.

Then for smarter devices that can take postscript you still need ppd files and ghostscript-related stuff to modify and create printer-specific postscript pages on the fly.. that is if you want anything more complex then single sided page black and white print output. And for network printers you need to have SMB support, IPP, and all that sort of stuff. And then you need CUPS and you need to have applications to manage and configure them. Then you need to have a notification system so people can deal with printer queues and cancel print jobs and get notified when print jobs are finished.

Printer problems are all userspace problems. I wonder if Google is smart enough to figure out how to make a web application speek to a network'd laser printer... :)

> Solved by using https.

Except people very rarely use HTTPs for their work or even home VPNs. For the most part they are restricted to using whatever their work has set up for them or whatever came with their el'cheapo home router. Using something like IPsec, PPTP, or Cicso VPN will be much more common requirements.

Remember it's the user that sets the requirements for the OS. If the OS does not meet those requirements then the users are not going to change their requirements... they are simply going to use something else, and that something else is probably just going to be Windows.

:)