Francisco J. Ballesteros

2K: a distributed operating system for dynamic heterogeneous environments

The first decades of the new millennium will witness an explosive growth in the number and diversity of networked devices and portals. We foresee high degrees of mobility, heterogeneity, and interactions among computing devices connected to global networks. While previous research in distributed operating systems solved many problems related to resource management, they seldom addressed the problems of heterogeneity and dynamic adaptability. On the other hand, middleware solutions, like CORBA and Java/Jini, solve part of the heterogeneity problem by permitting seamless communication among different platforms. But, they do not address dynamic resource management and adaptability for applications requiring high-performance distributed computing. This paper presents 2K, an integrated operating system architecture that addresses the problems of resource management in heterogeneous networks, dynamic adaptability and configuration of component-based distributed applications.

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

Batching: A Design Pattern for Efficient and Flexible Client-Server Interaction

The Batching design pattern consists of a common piece of design and implementation that is shared by a wide variety of well-known techniques in Computing such as gather/scatter for input/output, code downloading for system extension, message batching, mobile agents, and deferred calls for disconnected operation. All techniques mentioned above are designed for applications running across multiple domains (e.g., multiple processes or multiple nodes in a network). In these techniques, multiple operations are bundled together and then sent to a different domain, where they are executed. In some cases, the objective is to reduce the number of domain-crossings. In other cases, it is to enable dynamic server extension. In this article, we present the Batching pattern, discuss the circumstances in which the pattern should and should not be used, and identify eight classes of existing techniques that instantiate it.

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.

Treatment of early rheumatoid arthritis in a multinational inception cohort of Latin American patients: the GLADAR experience.

Background Treatment of rheumatoid arthritis (RA) has evolved dramatically in the last decade. However, little is known about the way rheumatologists in Latin America treat their patients in clinical practice, outside the scope of clinical trials. Objective The objective of this study was to describe treatment patterns at disease onset in early RA with data from a large, multicenter, multinational inception cohort of Latin American patients. Methods Consecutive patients with early RA (<1 year of disease duration as diagnosed by a rheumatologist) from 46 centers in 14 Latin American countries were enrolled in the study. Clinical data, laboratory assessments, and a detailed registry on type of prescriptions were collected at baseline and at 3, 6, 12, 18, and 24 months of follow-up. Hands and feet x-rays were obtained at baseline and at 12 and 24 months. All data were captured in Arthros 6.1 database. Continuous variables were expressed as means and SDs, and categorical variables were expressed as percentages and 95% confidence intervals (95% CIs). Only therapeutic data at baseline are presented, corresponding to the period between disease onset and second visit (3 months). Results A total of 1093 patients were included. Eighty-five percent were female, and 76% had a positive rheumatoid factor. Mean age at diagnosis was 46.5 (SD, 14.2) years, and mean disease duration at the first visit was 5.8 (SD, 3.8) months. Between baseline and second visit (3 months), 75% of patients (95% CI, 72%–78%) received disease-modifying antirheumatic drugs. Methotrexate (MTX) alone or in combination was the most frequently used (60.5%), followed by antimalarials (chloroquine or hydroxychloroquine, 32.1%), sulfasalazine (7.1%), and leflunomide (LEF, 4%). In 474 patients (43%), initiation of disease-modifying antirheumatic drugs was within the first month after the first visit. In addition, 290 patients (26%; 95% CI, 23%–29%) received combination therapy as initial treatment. The most frequently used combinations were MTX + chloroquine (45%), MTX + hydroxychloroquine (25%), and MTX + sulfasalazine (16%). Eleven patients (1%; 95% CI, 0.5%–1.8%) received biologics. Sixty-four percent (95% CI, 60%–66%) received corticosteroids. Of those, 80% (95% CI, 77%–84%) received 10 mg of oral prednisone or less. Conclusions In this cohort of Latin American patients with early RA, most patients received MTX very early in their disease course. Combination therapy was used approximately in 1 of every 4 patients as initial therapy. Biologics were rarely used at this early stage, and low-dose prednisone was commonly used.

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

Plan B: boxes for networked resources

Nowadays computing environments are made of heterogeneous networked resources, but unlike environments used a decade ago, the current environments are highly dynamic. During a computing session, new resources are likely to appear and some are likely to go online or to move to some other place. The operating system is supposed to hide most of the complexity of such environments and make it easy to write applications using them. However, that is not the case with our current operating systems. Plan B is a new operating system that attempts to allow the applications and their programmers select and use whatever resources are available without forcing them to deal with the problems created by their dynamic distributed and heterogeneous environments. It does so by using constraints along with a new abstraction used to replace the traditional le abstraction.