By Topic

Computer

Issue 6 • Date June 1998

Filter Results

Displaying Results 1 - 13 of 13
  • Full text access may be available. Click article title to sign in or learn about subscription options.
  • The Cost of COTS

    Page(s): 46 - 52
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (513 KB)  

    First Page of the Article
    View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The Real Stroustrup Interview

    Page(s): 110 - 114
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (263 KB)  

    First Page of the Article
    View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Hardware compilation: translating programs into circuits

    Page(s): 25 - 31
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (196 KB)  

    Automatically translating a program specified in a programming language into a digital circuit is an idea of long standing interest. Thus far, the concept has appeared to be an uneconomical method of largely academic, but hardly practical interest. It has therefore not been pursued with vigor and consequently has remained an idealist's dream. With the increasing use of hardware description languages, however, it has become evident that hardware and software design share several traits. Hardware description languages let circuit specifications assume textual forms like programs, replacing traditional circuit diagrams with text. Increased interest in hardware compilation is largely due to the advent of large scale programmable devices. These devices can be configured on the fly, and hence be used to directly represent circuits generated through a hardware compiler. The author argues that it is now conceivable that parts of a program could be compiled into instruction sequences for a conventional processor and other parts could be compiled into circuits to be loaded onto programmable gate arrays. He advocates the development of a single language that could compile parts of a program into instruction sequences for a conventional processor and other parts into circuits for programmable gate arrays. The author points out what is better left to software and what is best implemented in hardware (namely, parallelism). The goal is to achieve a better understanding of the several important aspects that hardware and software design share, which may well be expressed in a common notation View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A map of security risks associated with using COTS

    Page(s): 60 - 66
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (144 KB)  

    Combining Internet connectivity and COTS based systems results in increased threats from both external and internal sources. Traditionally, security design has been a matter of risk avoidance. Now more and more members of the security community realize the impracticality and insufficiency of this doctrine. It turns out that strict development procedures can only reduce the number of flaws in a complex system, not eliminate every single one. Vulnerabilities may also be introduced by changes in the system environment or the way the system operates. Therefore, both developers and system owners must anticipate security problems and have a strategy for dealing with them. This is particularly important with COTS based systems, because system owners have no control over the development of the components. The authors present a taxonomy of potential problem areas. It can be used to aid the analysis of security risks when using systems that to some extent contain COTS components View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Plans, lies, and videotape

    Page(s): 107 - 109
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (320 KB)  

    The authors pose the question: why are smart, skilled, responsible, experienced software people so often mixed up about commitments? They make a list of reasons for why otherwise capable, well intentioned people appear not to meet their commitments: no commitment in the first place; conditional commitments, with conditions unmet; commitment to work toward a goal, rather than achieve it; different impressions of the true commitment; commitments made under duress; commitment made in error; commitments not worth the effort to fulfill; terms of commitment changed midstream View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Building the US workforce, one engineer at a time

    Page(s): 120, 117 - 119
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (328 KB)  

    High-tech companies in the USA have hit the annual cap of 65,000 H-1B visas, which allow skilled workers from outside the US to work there. US legislators have been aided and abetted by labor unions and trade associations like IEEE-USA, which argue that immigrant engineers take jobs away from US citizens, increasing unemployment and depressing wages. Which point of view does the data support? For the purpose of this article, I focus on two points I believe have been consistently distorted in the context of the H-1B debate: (1) Skilled foreign workers do not take jobs from domestic workers, but in fact create lots of additional jobs. (2) IEEE-USA is lobbying the US Congress in a manner that is not only contrary to IEEE members' best interests but antithetical to their instincts as engineers. The vast majority of engineers base their decisions and positions on facts, abhor politics and have a natural aversion to the games that characterize “business as usual” on Capitol Hill View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Why does Digital participate in standards?

    Page(s): 95 - 103
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (264 KB)  

    The IT industry spends billions of dollars every year in support of standards. Companies, governments and universities send hundreds, if not thousands, of people to meetings all over the world to develop standards and define specifications for information technology. These people meet, share information, debate, discuss and even argue. Then they write the standards that define many key aspects of our industry. In an environment where technology is often considered old after only six months, the process of developing a standard can take years. So why is all this money, energy and time spent in pursuit of an often illusive and frequently imperfect solution? What is the value of this work? Why do we do it? Digital Equipment Corporation (DEC) answers this question by looking at the information flows associated with the standards process. Doing so is not simply a linear process of standardization-from organization to vendor-but rather a process consisting of multiple links that include standards participants, standards organizations, the information shared within each vendor company, vendor partners and competitors, and customers. Digital believes that participating in the standardization process and using the information gathered and generated provides the company with a valuable business advantage in product planning and sales View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Security control for COTS components

    Page(s): 67 - 73
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (148 KB)  

    Using COTS components poses serious threats to system security. The authors analyze the risks and describe how their sandbox method can limit the damage potential of COTS components. The sandbox model was originally developed for fault tolerance. Rather than eliminating actual failures, it provides a restricted environment to confine application behavior. The approach confines the damage caused if an application accidentally or maliciously misbehaves. The authors' sandbox method differs from Java's, in that it is built with OS support rather than with support from a particular language. The authors describe the Sendmail version of their sandbox method. Their approach requires B-level security features not found on most conventional OSs. Typically developed for government or military use, B-level certified OSs have more sophisticated security features. The authors explain that their method does not eliminate security problems but rather mitigates the damage caused by compromised applications and thus prevents most common security breaches. Untrusted COTS components can thus be safely plugged into a system without major reengineering, provided there is a suitable security platform View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The Web is not yet suitable for learning

    Page(s): 115 - 116
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (288 KB)  

    Many sites on the Web refer to themselves as courses. Doing so is popular at present, with an ever increasing number of these courses cropping up everywhere. In some universities, administrators pressure the faculty to provide such courses without offering guidelines for how the Internet might best be used for learning. We've looked at many such courses and come away greatly disappointed. Most of these courses provide little in the way of interaction. Our concern is with situations in which the Web site is intended to be the primary delivery method for learning, not when it is a supplement to learning delivered mainly in other ways, such as through lectures. We are not suggesting that other ways of delivering learning-such as through lectures-are adequate. Distance learning is an important approach for future education, but not as it is currently delivered on the Web View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Certifying off-the-shelf software components

    Page(s): 53 - 59
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (200 KB)  

    Software components are often delivered in “black boxes” as executable objects whose licenses forbid decompilation back to source code. Often source code can be licensed, but the cost makes doing so prohibitive. We therefore have developed a methodology for determining the quality of off-the-shelf (OTS) components using a set of black box analyses. This methodology will provide developers with information useful for choosing components and for defending themselves legally against someone else's imperfect OTS components View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Throwing off the shackles of a legacy system

    Page(s): 104 - 106, 109
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (264 KB)  

    Network information about cables, wire pairs, digital circuits, fiber, telephone numbers, central office equipment, and so on constitutes the basic building blocks for operating a local telephone company. GTE uses a mainframe system to maintain these information and service provisioning functions. The system, which we refer to as LegacyX, was developed and is owned by a third party vendor. Over the decades of LegacyX's operation, many other systems related to billing, service order entry, network testing, trouble administration, and inventory management have required interfaces to LegacyX. Without the information LegacyX provides, these systems would cease to function. Over the years, several patches have been applied to LegacyX to satisfy new requirements, and it has evolved into a massive black box. In summary, LegacyX has inherited all the disadvantages of large, embedded, legacy systems. It is very costly to maintain and virtually impossible to adapt to new services and technology. GTE had made 25 unsuccessful attempts to replace this legacy system. GTE was successful on the 26th attempt, replacing LegacyX with Domain (Distributed Object Management and Activation for Integrated Networks) in the Compania Dominicana de Telefonos (Codetel), the GTE owned telephone company in the Dominican Republic. This required a synergistic approach that brought together hardware, software, and people. This approach combined advanced software techniques with practical solutions to achieve a common goal shared by users, developers and managers View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Virtual memory: issues of implementation

    Page(s): 33 - 43
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (276 KB)  

    Virtual memory was developed to automate the movement of program code and data between main memory and secondary storage to give the appearance of a single large store. This technique greatly simplified the programmer's job, particularly when program code and data exceeded the main memory's size. Virtual memory has now become widely used, and most modern processors have hardware to support it. Unfortunately, there has not been much agreement on the form that this support should take. The result of this lack of agreement is that hardware mechanisms are often completely incompatible. Thus, designers and porters of system level software have two somewhat unattractive choices: they can write software to fit many different architectures or they can insert layers of software to emulate a particular hardware interface. The authors present the software mechanisms of virtual memory from a hardware perspective and then describe several hardware examples and how they support virtual memory software. Their focus is to show the diversity of virtual memory support and, by implication, how this diversity complicates the design and porting of OSs. The authors introduce basic virtual memory technologies and then compare memory management designs in three commercial microarchitectures. They show the diversity of virtual memory support and, by implication, how this diversity can complicate and compromise system operations View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.

Aims & Scope

Computer, the flagship publication of the IEEE Computer Society, publishes highly acclaimed peer-reviewed articles written for and by professionals representing the full spectrum of computing technology from hardware to software and from current research to new applications.

Full Aims & Scope

Meet Our Editors

Editor-in-Chief
Ron Vetter
University of North Carolina
Wilmington