Gorka Guardiola

Plan B: an operating system for ubiquitous computing environments

The conventional approach for building pervasive environments relies on middleware to integrate different systems. Instead, we have built a system that can deal with these environments by exporting system resources through distributed virtual file systems. This requires no middleware, simplifies interoperation, and permits applying general purpose tools to any system resource. A constraint-based file system import mechanism allows the system to adapt to changes in the environment and permits users to customize the environment and tailor adaptation according to their needs. The system has been in use for over a year to carry out our daily work and is underlying the smart space that we built for our department

Plan B: Using Files instead of Middleware Abstractions

Plan B maps abstract interfaces to files and adapts to file tree availability. It is easy to program, offers a general-purpose computing environment, and supports smart spaces without using middleware.

NIX: A case for a manycore system for cloud computing

Virtualized cloud computing provides lower costs, easier system management and lower energy consumption. However high performance tasks are ill-suited for traditional clouds since commodity operating systems and hypervisors add cascading jitter to computation, slowing applications to a crawl. This paper presents an overview of NIX, an operating system for manycore central processing units (CPUs) which addresses the challenges of running high performance applications on commodity cloud systems. NIX features a heterogeneous CPU model and uses a shared address space. NIX has been influenced by our work on Blue Gene and more traditional clusters. NIX partitions cores by function: timesharing cores (TCs); application cores (ACs); and kernel cores (KCs). One or more TCs run traditional applications. KCs are optional, running kernel functions on demand. ACs are also optional, devoted to running an application with no interrupts; not even clock interrupts. Unlike traditional kernels, functions are not static: the number of TCs, KCs, and ACs can change as needed. Also unlike traditional systems, applications can communicate by sending messages to the TC kernel, instead of system call traps. These messages are “active” taking advantage of the shared-memory nature of manycore CPUs to pass pointers to data and code to coordinate cores.

Traditional Systems Can Work Well for Pervasive Applications. A Case Study: Plan 9 from Bell Labs Becomes Ubiquitous

There is a huge effort in ongoing research on new middleware platforms and new distributed services to support ubiquitous environments and pervasive applications. Prototypes for smart spaces are sometimes used to demonstrate the need for a new particular service, piece of software, or middleware layer. However, we have found that we could easily build a smart space and some applications for it by relying on services already provided by the system we use daily, Plan 9 from Bell Labs. This paper explores how far can we go with a traditional system to support a ubiquitous environment, without using any middleware. We describe how to build a pervasive computing platform using Plan 9, and how we built a smart space to demonstrate this

Omero: ubiquitous user interfaces in the plan B operating system

It is difficult to build user interfaces that must be distributed over a set of dynamic and heterogeneous I/O devices. This difficulty increases when we want to split, merge, replicate, and relocate the UI across a set of heterogeneous devices, without the application intervention. Furthermore, using generic tools, e.g. to search for UI components or to save/restore them, is usually not feasible. We follow a novel approach for building UIs that overcomes these problems: using distributed file systems that export widgets to applications. In this paper we describe Omero, a UI server built along this line for the plan B operating system

SHAD: A Human-Centered Security Architecture for the Plan B Operating System

This paper describes SHAD, a novel architecture for security in pervasive computing environments, and a prototype implementation. SHAD is a peer-to-peer and human-centered security architecture. It is based in a general purpose personal device that manages the users security: the UbiTerm. There are several other systems that, at first sight, seem to provide single sign-on in ubiquitous environments. We argue that they fail to do so in practice, and that SHAD offers for the first time a real SSO that works well in ubiquitous environments that require using multiple machines and services simultaneously. SHAD permits users to share their resources in an easy, natural, and intuitive way, even while being disconnected from the rest of the world. The architecture we propose is able to exploit context information, when it is available. It does not require hard administration tasks, and permits users to manage their own resources. We have been using SHAD for one year. This paper describes our prototype implementation, the experience using it, and some measures that confirm that our approach is reasonable in practice

AngryEmail? emotion-based e-mail tool adaptation

This paper presents AngryEmail, an e-mail tool that adapts its behavior according to the user emotional state. When a user finishes writing an e-mail and clicks the send button, the e-mail is automatically analyzed to get information about the emotions reflected on it, following a lexical-based approach. If a high level of anger is detected, then the e-mail program keeps the message unsent, waits for five minutes and, afterwards, notifies the user that the e-mail will be sent one minute later. This approach allows users to reconsider the convenience of sending certain e-mails when they are noticeably angry. This can be useful for all the people in general, but especially for those with cognitive limitations, for whom emotion control is harder.

Personal Pervasive Environments: Practice and Experience

In this paper we present our experience designing and developing two different systems to enable personal pervasive computing environments, Plan B and the Octopus. These systems were fully implemented and have been used on a daily basis for years. Both are based on synthetic (virtual) file system interfaces and provide mechanisms to adapt to changes in the context and reconfigure the system to support pervasive applications. We also present the main differences between them, focusing on architectural and reconfiguration aspects. Finally, we analyze the pitfalls and successes of both systems and review the lessons we learned while designing, developing, and using them.

UpperWare: Bringing resources back to the system

If we expect the computer to vanish in the background, to make pervasive computing a reality, first we must be able to provide the illusion that all the users computers, devices, and applications are part of a greater, virtual, computer.

The Plan B OS for ubiquitous computing. Voice control, security, and terminals as case studies ☆

Abstract The conventional approach to building pervasive environments relies on middleware to integrate different systems. Instead, we have built a system that can deal with these environments by exporting system resources through distributed virtual file systems. This requires no middleware, simplifies interoperation, and permits the application of general purpose tools to any system resource. A constraint-based file system import mechanism allows the system to adapt to changes in the environment and permits users to customize the environment and tailor adaptations according to their needs. The system has been in use for over a year to carry out our daily work and is underlying the smart space that we built for our department. The system, and some novel services, including ubiquitous voice interfaces, a distributed security architecture, and remote terminals for smart spaces, are also described in this paper.