Archive for June, 2010
Now that our EveryDesk is out in the wild, I would like to provide a little background on what choices were made in creating it; especially outlining some differences with previous approaches. EveryDesk starts with a set of assumptions: first of all, that every single barrier reduces by an order of magnitude the probability of adoption, and that it is extremely difficult to displace “what works”, but there are lots of environments where current OSS and commercial offerings are not perfectly suited for their intended target.
I have previously addressed the use of the UTAUT model to study for example Google’s ChromiumOS offering; we applied the same model for our own desktop offering, modelled after the end of the COSPA project (one of the largest controlled experiments in the introduction of OSS in European Public Administration desktops). We have focused our initial efforts on the Health Care sector, thanks to our contract work with the regional health care agency of the Friuli region, but later generalized the approach for a wide range of activities using the same basic infrastructure.
First of all, what’s the problem of the current commercial offering?
- Hardware obsolescence: PC refresh cycles are already widely stretched thanks to the economic crisis, forcing users to adapt to less-than-modern IT infrastructures, both server and client side;
- Security: the basic security of most commercial offerings is barely adequate; to provide sufficient protection, several layers of added security software needs to be added to the basic OS, increasing resource consumption and aggravating the situation for less than modern hardware;
- Management: unless you are the lucky recipient of a fully managed (and costly) infrastructure, you will have to perform or have performed several management activities like patch and software management, backups and lots more.
Thin clients reduce management, but require substantial infrastructural investments, some applications are hard to port to Terminal Services or require substantial remotization bandwidth (or lots of additional software: think about video-conferencing in a TS environment, with all the hybrid local/remote channel enabled by tools like Citrix HDX). VDI requires even more complex systems, with an offering that is still maturing (with some stunning technical hacks, actually) and that has for many installation an unproven return on investment.
To summarize: desktop PC are flexible, adaptable, usable without connectivity, complex, fragile, difficult to manage. Thin (bitmap-based, like RDP or ICA) clients are slightly easier to manage, require little support, require substantial infrastructure investments, cannot work detached, have marginally lower management costs.
We try to strive with a middle ground solution: EveryDesk is a locally executed OS, that when configured provides the same remote management advantages of thin clients without the costly infrastructure (the only thing needed is storage, that is nowadays cheap and plentiful). The system is a real install, not a live CD, so the user/administrator can install applications or customize it in depth simply by using the image and then replicating it for all the people working in a company or administration. Updating it is simple: just execute the Update Manager!
While developing EveryDesk we identified a few potential use cases, and I would like to explain what advantage our hybrid model can have:
- Hospital worker: our initial use case. We designed the system so that national regulations in the handling of sensitive data could be complied to without any specific effort on the side of the user; that is, to make nearly impossible for the worker to lose or disseminate data without an explicit and voluntary breach of confidentiality, and make it possible to identify such breach immediately. By moving user data on a centrally managed server, standard logging and identity management techniques can be applied easily to prevent data loss; as no private data is on the key (including passwords), losing the key or having it stolen is not sufficient to breach the system privacy. For our health care customization we added to the basic image an excellent radiology workstation system called O3, already in use in some Italian hospitals, a medical dictionary and some ancillary tools like the ImageJ image processing system.
- Another important use case is widely found in developing countries, and is the “Internet Café”. While it is true that mobile internet access is fast becoming a fundamental infrastructure, cost and efficiency reasons still make it sensible to have a physical, shared space with PCs. EveryDesk makes it possible to provide low-maintenance PCs with no hard disks, a central low cost storage, and simply give away the USB keys to the attendees. If a key stops working, it is simply a matter of re-copying the image on top of a new one to restore everything.
- Within companies and Public Administration, providing a diskless PC with EveryDesk allows the efficient use of even old PCs (EveryDesk takes 150MB of RAM with both Firefox and OpenOffice.org open), while providing thanks to VirtualBox the set of applications that are not available within Linux. In dispersed companies, where you have multiple sites, you can use a replicating file system (like the wonderful XtreemFS developed within another EU-funded research project) that provides in a totally open source solution with differential and efficient replicas across sites. This way you can use your VirtualBox image, stop it, let the system replicate it in the other sites, move to another city, fire up EveryDesk again and have all your data and status restored without the need for local persistent storage.
The idea of a real Linux install is not new – actually, some of the ideas were explored a few years ago in a Gentoo-based system called FlashLinux, that unfortunately is not updated since 2005. We also introduced some of the ideas behind IBM SoulPad, namely the integration of virtualization within the environment, but reversed the concept (in SoulPad the virtualization layer is at the bottom, and is used to abstract the internal virtual machine from the hardware, as well as providing easy suspend/resume functionalities).
We plan to create a education-oriented edition, integrating some of the software tools already selected in projects like EduLinux; we also plan to backport some of the customizations of municipally-sponsored distributions like MAX (Madrid Linux) to try to provide a common basis for experimentation in public administrations across Europe.
Now that most of our work for FLOSSMETRICS is ended, I had the opportunity to try and work on something different. As you know, I worked on bringing OSS to companies and public administration for nearly 15 years now, and I had the opportunity to work in many different projects with many different and incredible people. One of the common things that I discovered is that to increase adoption it is necessary to give every user a distinct advantage in using OSS, and to make the exploratory process easy and hassle-free.
So, we collected most of the work done in past projects, and developed a custom desktop, designed to be explorable without installation, fast and designed for real world use; EveryDesk is a reinterpretation of the Linux desktop, designed to be used in public administrations or as an enterprise desktop. EveryDesk is a real OS on a USB key, not a live CD; this way the system allows for extensive customization and adaptation to each Public Administration need It is the result of the open sourcing of part of our HealthDesk system, designed using the result of our past European projects COSPA (a large migration experiment for European Public Administrations), SPIRIT (open source health care), OpenTTT (OSS technology transfer) and CALIBRE (open source for industrial environments).
EveryDesk is a binary image designed for 4GB USB keys, easy to install with a single command both on Linux and Windows, simple to replicate and adapt. It does provide a simple and pleasing user interface, with several pre-installed applications and native support for Active Directory. EveryDesk supports roaming/nomadic work through a special mode that stores all user data on a remote SMB server (both Samba and Windows are supported). This way, the user’s USB key contains no personal data, and can be used in environments that manage sensitive data, like health care or law enforcement.
The files and images can be downloaded from the SourceForge project page.
EveryDesk integrates a simple and easy to use menu, derived from Novell usability research studies, providing one-click access to individual programs, documents, places; easy installation of new software or updates, thanks to the fully functional package manager.
EveryDesk includes support for Terminal Services, VNC, VmWare View and other remote access protocols. One peculiarity we are quite happy with is the idea of simplified VDI; basically, EveryDesk integrates the open source edition of VirtualBox, and allows for mounting the disk images remotely – so the disk storage is remote, and the execution is local. This way, VDI can be implemented by adding only storage (that is cheap and easy to manage) and avoiding all the virtualization infrastructure.
The seamless virtualization mode of VirtualBox allows for a quite good integration between Windows (especially Windows 7) and the local environment. Coupled with the fact that the desktop is small and runs in less than 100MB (with both Firefox and OpenOffice.org, it takes only 150MB) it makes for a good substitute of a traditional thin client, is manageable through CIM, and is commercially supported. Among the extensions developed, we have a complete ITIL compliant management infrastructure, and digitally-signed log storage for health care and law enforcement applications.
I had the opportunity to talk a little bit with Dirk Riehle at LinuxTag about business models, collaboration and infrastructures, and one of the arguments was about software forges, like SourceForge or GForge. I would like to provide a little bit of overview of our discussion, along with my reasoning about the future of such forges.
First of all, I am a strong believer in the idea that forges were one of the important elements for the maturation and creation of a large scale market of users and developers of open source; forges provided free, simple and no-cost infrastructure for the basic necessities of a project, like file storage, CVS, mailing lists and so on. In this sense, forges also helped in discovering software, by providing basic taxonomies of software code, and comprehensive search facilities.
But two main aspects are in my opinion reducing the potential of forges for recent projects, namely distributed development and information dissemination. One of the important evolutions in code development has been the widespread adoption of distributed version control, through Git, Bazaar, Mercurial and (to a lesser extent) other minor solutions. Git, for example, substantially increased the productivity of projects like Wine, and provide a good management framework for large scale development by nearly independent group, like in the case of the Linux kernel.
The other aspect is related to information dissemination: what happens to a project is lost between bug tracking, mailing lists, forum (why the replication of features? how to find if something was already solved in some other place?); projects are difficult to interact one with the other, with the impossibility of tracking evolution of one project from another without passing from one person in the middle subscribed to both. And, as Dirk graciously conceded, managing or adapting a forge is a real nightmare I remember our past work in the Spirit forge (a healthcare-oriented forge, that used digital certificates to authenticate and sign code entered in the platform) and still got the shivers.
For this reason, I believe that future forges will be structurally different from the current ones: they will be based on small, efficient pieces, for example a central Git repo, that is enhanced by external modules that subscribe to modifications in the code stream and provide this information to higher-level applications, that for example produce graphs or link each atomic action to a wiki or tracking system. By moving things from a monolithic tool to loosely coupled pieces, we can end up with something that is more “facebook-like” than forge like, with individual apps that provide for example code quality services (like Sonar) or visualization services. I am a strong believer in a publish-subscribe mechanism for this, for example through XMPP, because it allows to solve easily the problem of how to track strongly coupled projects. For example, if my code is dependent on an external project I can subscribe to its own code announcement strams, or issue streams, since the same issues will probably apply to my code as well; this without an explicit interaction, and with the opportunity to link issues to individual actions (commits, reports, etc.) that remain valid even if I fork the library, or act independently on modifications that will eventually be merged in a single tree. I believe that in the future the number of strong or weak coupling will increase, and this will seriously limit the capabilities of current forges.