God I love EyeOS
I love EyeOS. Not because it does everything I need and more; hell no, it hasn’t reached any sort of real usable level yet. But think about what it does, and what everything else does. EyeOS acts like a little fake operating system running on PHP; in fact, it uses a structure similar to a micro-kernel like Minix. It runs services like a process manager or a user security manager. It supplies a VFS layer for file storage. It supplies API calls for applications to do networking, file access, or draw GUI widgets. It draws windows and widgets on top of a display manager process.
Think about all the other stuff you’ve seen out there. phpBB and MediaWiki have add-ons to authenticate to LDAP or Active Directory domains. Google Docs allows editing Microsoft Office and OpenDocument text, spreadsheet, and presentation documents. You can use PHP to connect to IRC or Jabber servers.
Picture the future, maybe a year from now. Someone re-works EyeOS to use add-on authentication modules, and adds support for LDAP and Active Directory domain authentication. A SMB/CIFS connector allows further access to file shares. A full document suite shows up, with full native ODF compatibility and integration with tools that convert to/from Microsoft Office format. Someone writes a Jabber client that connects from the Web server’s end, and packs a Jabber server on the back-end to allow full real-time local chat/IM. The mail client gets IMAP support.
Really, think about that. You could log in to the Windows domain, read your e-mail, get your files off the file server, edit your documents, and talk to your coworkers all through an interface that looks like a desktop operating system. Hit Outlook Web Access (or better, write an EyeOS exchange client and some kind of LGPL exchange server) and you can get full access to your calendars and tasks.
A lot of people don’t really seem to see the point of offloading a number of basic, straight-forward tasks to the Web browser when they could just use a complicated, hard-to-set-up VPN to give open access to an internal network segment and lay out a bunch of firewalls and some network activity monitoring software. This actually contains a number of arguments each met with at least one counter-argument.
The VPN argument always bugs me because you can’t craft packets through the Web OS; you have to actually break into the server (shell access!) first. This layer of attack complexity goes away with a VPN; plus VPN clients become vulnerable to each others’ Internet worms, instead of just the servers. Not only that, but the complexity and managerial costs go up when you have to choose a VPN solution; learn how to use it; configure it; maintain it; design a secure way for untrusted networks (read: your employees’ home computers) to connect to the VPN yet still give higher-than-Internet access to these networks; deploy and manage additional intrusion detection and prevention devices (including firewalls); and train your employees to properly connect to the VPN.
A VPN also doesn’t magically create additional software licenses or installations. For this you need something like Citrix or RDP. These things eat up bandwidth and require enough computing power and working storage (RAM) to run the remote applications and the remote operating system on the server. Even if this just amounts to 50 copies of Word, Outlook, and Spark or Pidgin at 30MB of RAM each that still gives 90MB per user, 4.5GB when you hit 50 users, and what happens when your company grows to 1000 or 5000 or 10000 employees?
In the end I think it will come out better when you give your employees a set of standard applications to use through the Web interface to do their job, and each mainly does its work on the client side. Bandwidth usage goes down related to a VPN solution because all the drawing happens on the client side with once-downloaded data. Any kind of drawing of windows and buttons and graphics also happens on the client’s side, freeing server RAM and CPU time. Remaining program state stays minimal, mostly physically stateless and sync’d back to files or stored in client memory; maybe you need to keep track of what e-mail the client has up and what he’s typed in a spreadsheet, but you don’t need a rendered display of the message or document on the server.
All of this takes load off a core infrastructure that now doesn’t need a lot of fancy, complex, and expensive products to provide the functionality needed. These servers can push 5000, maybe 10000 requests per second for things like MediaWiki; when you abstract that to tiny AJAX messages (and do so properly) one or two servers on a T1 won’t sweat something that would cause a massive, multi-data-center cluster of Citrix VPN machines on multiple Gigabit links to work overtime trying to keep up with the load and saturate the network. Sure the system comes with its limits; but do you really want to try to do video and graphics editing or whatever else over a VPN anyway?