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.

:)

You can't set up a Google Apps server on your home network, but you'll probably be able to set up an open source replacement. And there are enough nice things about Google Docs[*] that would carry over that I think people will be tempted away from the local desktop to SaaS just in time to decide that they don't want this to be something run by someone else. Google has published a draft of a server-to-server that Docs will support, so it's likely that there will be open source implementations that interoperate with Google Docs, and that people will start installing these in their homes as an alternative to having documents scattered on each computer in the house.

I think access to a server run by Google or an ISP will never be as good as the local desktop, but access to a server on the local network probably will be.

[*] One of the most remarkable things I've done is solve crossword-like puzzles as a team on Google Docs. There were times that I was working with people on different continents without realizing it, and times when everyone working on it was in the same room, and it was the best available method in both cases. We were, at times, filling in answers faster than would be possible with paper and pencils, since people would collide or block each other's vision while writing.

Look at what happened to Novell. Microsoft is able to provide tight integration between Windows Desktop, Office, and Active Directory and make it all work by 'default'. This required very little skill and was cheap to setup and get working. Novell on the other hand required very experienced people to setup the same thing and was much more expensive to deploy.

So Novell lost hard and now AD is the defacto standard method for managing corporate desktop environments.

Microsoft controlled the only viable platform for deploying Novell's software so Novell could not compete, even though their solutions were technically superior in most respects.

And it's the same thing with WWW. Microsoft, for the longest time, controls the only viable platform for reaching the majority of users out there. That's why it's a pipe dream that will never come true that web applications on browsers will displace the importance of Windows.

Microsoft has to much control over your platform.

Witness the debates over the <video> tag and such. Apple may be acting like a huge dick and throwing a wrench into the entire thing, but fundamentally everybody knows it's mostly irrelevant unless Microsoft decides to add video tag support to IE, which they won't do.

If they don't do that then turns something that exceptionally trivial to deploy* and turns into a major headache were you need to support the current way of doing things + the new video-tag way.

*(streaming video via video tag is so cheap and easy it is just massively blows away any competition. Try it sometime, it's laughable how simple video tag makes things. To RTSP server, no flash BS, no special software, no Apache modules, no nothing. Just drop the video file on your server and point at it like it was a jpeg image.)

And even if Chrome and Firefox do overthrow IE as the dominate browser it is only one small step. Microsoft still controls the platforms that they run on and will still be able to limit the viability of it and push their own solutions forward.

What's 'everywere else'? Windows, OS X? Nope.. it's just restricted mostly to Solaris and the BSD distros. Alsa screwed up by trying to be too much. It should of been divided up between application apis and low-level APIs that application developers shouldn't really use.. but it's too late now.

But all of that is why it's silly to program for OSS or Alsa in any case. If you program OSS you may be using a 'standard'... but it's a standard that only the tiniest minority of people actually use for operating systems that are the least likely to be used on the desktop. Instead you target something like 'SDL' or Gstreamer or whatever other higher level library and you get compatibility not only with OSS and Alsa, but also with Windows and OS X (generally).

----------------------------------------

It's probably worth noting that WebOS from Palm for the Palm Pre, which is a lower-end smart phone uses Alsa, Gstreamer, and PulseAudio for their stuff.

As well as dbus, upstart (and actually use upstart as upstart rather then just in sysv init emulation mode like most distros). :)

So the desktop architect folks must be doing something right.. and all that stuff can happily run on a phone, so it should be possible to make it all perform well for a desktop or netbook.

--------------------------------------

Oh and GVFS was a good move also. Besides some early teething problems I've had much superior results using GVFS then ever with Gnome-VFS. It's been more useful and more stable.

The FUSE feature is invaluable.. before I couldn't really use Gnome-VFS for much since many of my applications were not Gnome and thus not compatible... so I would have to resort to doing things like searching for SMB servers using Gnome's 'windows network' feature and then once I got it working in gnome I'd have to get it working on the command line. Nowadays I can use the GUI for searching and mounting and then just use ~/.gvfs.

It's very nice.