ACM Queue - System Evolution

Kode Vicious Plays in Traffic: With increasing complexity comes increasing risk.

George Neville-Neil — 2020年4月08日 12:08:09 GMT

There is no single answer to the question of how to apply software to systems that can, literally, kill us, but there are models to follow that may help ameliorate the risk. The risks involved in these systems come from three major areas: marketing, accounting, and management. It is not that it is impossible to engineer such systems safely, but the history of automated systems shows us that it is difficult to do so cheaply and quickly. The old adage, "Fast, cheap, or correct, choose two," really should be "Choose correct, and forget about fast or cheap." But the third leg of the stool here, management, never goes for that.

The Best Place to Build a Subway: Building projects despite (and because of) existing complex systems

Pat Helland — 2020年3月24日 12:44:11 GMT

Many engineering projects are big and complex. They require integrating into the existing environment to tie into stuff that precedes the new, big, complex thing. It is common to bemoan the challenges of dealing with the preexisting stuff. Many times, engineers don't realize that their projects (and their paychecks) exist only because of the preexisting and complex systems that impose constraints on the new work. This column looks at some sophisticated urban redevelopment projects that are very much part of daily life in San Francisco and compares them with the challenges inherent in building software.

Borg, Omega, and Kubernetes: Lessons learned from three container-management systems over a decade

Brendan Burns, Brian Grant, David Oppenheimer, Eric Brewer, John Wilkes — 2016年3月02日 17:56:14 GMT

Though widespread interest in software containers is a relatively recent phenomenon, at Google we have been managing Linux containers at scale for more than ten years and built three different container-management systems in that time. Each system was heavily influenced by its predecessors, even though they were developed for different reasons. This article describes the lessons we've learned from developing and operating them.

Abstraction in Hardware System Design: Applying lessons from software languages to hardware languages using Bluespec SystemVerilog

Rishiyur S. Nikhil — 2011年8月18日 21:03:00 GMT

The history of software engineering is one of continuing development of abstraction mechanisms designed to tackle ever-increasing complexity. Hardware design, however, is not as current. For example, the two most commonly used HDLs date back to the 1980s. Updates to the standards lag behind modern programming languages in structural abstractions such as types, encapsulation, and parameterization. Their behavioral semantics lag even further. They are specified in terms of event-driven simulators running on uniprocessor von Neumann machines.

Custom Processing: Today general-purpose processors from Intel and AMD dominate the landscape, but advances in processor designs such as the cell processor architecture overseen by IBM chief scientist Peter Hofstee promise to bring the costs of specialized system on a chip platforms in line with cost associated with general purpose computing platforms, and that just may change the art of system design forever.

Peter Hofstee, Michael Vizard — 2008年7月14日 15:03:30 GMT

Today we're going to talk about system on a chip and some of the design issues that go with that, and more importantly, some of the newer trends, such as the work that IBM is doing around the cell processor to advance the whole system on a chip processor. To that end, we've invited Peter Hofstee, Chief Scientist for the cell processor project that is being funded by IBM, Toshiba, and Sony, to talk to us today about how the whole system on a chip marketplace might change in the advent of the invention of the cell processor, and what technology is driving that.

The Long Road to 64 Bits: Double, double, toil and trouble

John R. Mashey — 2006年10月10日 08:50:13 GMT

The Long Road to 64 Bits

Double, double, toil and trouble—Shakespeare, Macbeth

JOHN R. MASHEY, TECHVISER

Shakespeare’s words (Macbeth, Act 4, Scene 1) often cover circumstances beyond his wildest dreams. Toil and trouble accompany major computing transitions, even when people plan ahead. To calibrate “tomorrow’s legacy today,” we should study “tomorrow’s legacy yesterday.” Much of tomorrow’s software will still be driven by decades-old decisions. Past decisions have unanticipated side effects that last decades and can be difficult to undo.

For example, consider the overly long, often awkward, and sometimes contentious process by which 32-bit microprocessor systems evolved into 64/32-bitters needed to address larger storage and run mixtures of 32- and 64-bit user programs. Most major general-purpose CPUs now have such versions, so bits have “doubled,” but “toil and trouble” are not over, especially in software.

A Conversation with David Brown: The nondisruptive theory of system evolution

Charlene O'Hanlon — 2006年10月10日 08:50:12 GMT

A Conversation with David Brown

The nondisruptive theory of system evolution

This month Queue tackles the problem of system evolution. One key question is: What do developers need to keep in mind while evolving a system, to ensure that the existing software that depends on it doesn’t break? It’s a tough problem, but there are few more qualified to discuss this subject than two industry veterans now at Sun Microsystems, David Brown and Bob Sproull. Both have witnessed what happens to systems over time and have thought a lot about the introduction of successive technological innovations to a software product without undermining its stability or the software that depends on it.

David Brown began his career in computing with the disruptive innovation brought about by the microprocessor generation: first on the SUN project at Stanford University and then as a founder of Silicon Graphics. He has now worked for more than 14 years on the Solaris system at Sun, where nondisruptive innovation (evolution and sustainability) is critical. Both the length and breadth of Brown’s career give him a unique perspective on systems and how they evolve. Brown led the Application Binary Compatibility Program for Solaris and discusses how new functionality is introduced in that system without breaking existing applications.

Longhorn Ties Platform Apps to Core Operating System: Will Microsoft’s New OS Be a Developer’s Dream-Come-True?

Alexander Wolfe — 2004年10月25日 10:31:35 GMT

Longhorn Ties Platform Apps to Core Operating System

Will Microsoft's New OS Be a Developer's Dream-Come-True?

Alexander Wolfe, Science Writer

Call it all-tools-for-all-things-Microsoft. That’s the way I’m beginning to think about Longhorn, Microsoft’s next-generation operating system, expected in 2006. The operating system will herald more than just the transition of mainstream computing to 64 bits. It will mark the emergence of a new, multifaceted programming model.

Breaking away from traditional computer science taxonomy, where operating systems stood barely removed from the hardware abstraction layer, Longhorn will be more like a multi-tentacled container for a wide range of administration and application tools.

Silicon Superstitions: Ask yourself if what you’re doing is based on fact, on observation, on a sound footing, or if there is something dodgy about it.

Jef Raskin — 2004年1月29日 10:14:55 GMT

We live in a technological age. Even most individuals on this planet who do not have TV or cellular telephones know about such gadgets of technology. They are artifacts made by us and for us. You'd think, therefore, that it would be part of our common heritage to understand them. Their insides are open to inspection, their designers generally understand the principles behind them, and it is possible to communicate this knowledge - even though the "theory of operation" sections of manuals, once prevalent, seem no longer to be included. Perhaps that's not surprising considering that manuals themselves are disappearing, leaving behind glowing Help screens that too often are just reference material for the cognoscenti rather than guides for the perplexed.

The Truth About Embedded Systems: Embedded systems are different in several ways from other software environments.

George Neville-Neil — 2003年4月01日 15:12:45 GMT

Embedded systems are different in several ways from other software environments. The hardware they run on is often resource-constrained in terms of both memory and processor cycles, but still these systems must respond in realtime. They control the brakes of cars, the flaps of airplanes, traffic signaling systems, medical equipment, and other life-critical devices. Programming as if someone's life depended on it is a new concept to many systems engineers.