July/August issue of acmqueue

The July/August issue of acmqueue is out now


  Download PDF version of this article PDF

Finding the Right Questions
by Steve Bourne, Queue Advisory Board

Does the world really need another computing magazine? Surely, that’s a legitimate question. By any measure, we already have an overwhelming number of publications to choose from. But how many do you actually read? And of those, how many do you feel really contribute to your knowledge and understanding of emerging software technologies and capabilities?

Sadly, even amongst the more serious and sober-minded of all those publications out there, there is little that looks potentially useful to people charged with anticipating and preparing for future challenges. That’s because the tendency is more towards content grounded in the here-and-now, with an emphasis on products and solutions already familiar to programmers and developers.

So into the clutter now steps a new publication: Queue. Quite simply, it’s not like any of those other magazines piling up on your office floor. That’s because the mission for Queue is to deal directly with the challenges ahead for software engineers and developers involved in the critical design and planning decisions most likely to affect product directions and operational practices for years to come. And when it comes to that, articles that merely describe current products and solutions are inadequate. So Queue instead sets out to intelligently assess the changes expected to arise in the near term as emerging capabilities or technologies gain widespread acceptance—laying out the choices software engineers and developers are most likely to face and spelling out the inherent underlying technical conflicts.

Unlike the other magazines I’ve seen, Queue understands that before people can begin to search for satisfactory answers, they must first know what questions to ask. Other publications may devote themselves to touting the latest panacea du jour. But Queue has been conceived largely as a tonic for the hype weary, with a commitment to methodically dissect upcoming challenges while posing the same hard questions software developers ask themselves. And in that way, Queue works to define future problems with the sort of detail and intelligence readers in turn can use to focus their own thinking on what matters most.

The best way to obtain that sort of insightful content is to solicit candid views from the very people right at the heart of what’s coming. Queue has the ability to do that because it’s built out of editorial content driven and written by engineers. An editorial advisory board consisting of industry luminaries who meet regularly to discuss article ideas and identify potential authors makes it possible to secure material from people with the real experience and technical savvy to write with real authority on their respective topics.

I think you’ll agree that doesn’t sound much like any of those other magazines you’ve been reading lately.


STEVE BOURNE Over the last 20 years Steve has held senior engineering management positions at Cisco Systems, Sun Microsystems, Digital Equipment and Silicon Graphics. At present he is Entrepreneur in Residence at El Dorado Ventures in Menlo Park, California. Prior to this Steve spent nine years at Bell Laboratories as a member of the Seventh Edition UNIX team. He designed the UNIX Command Language or "Bourne Shell" which is used for scripting in the UNIX programming environment and he wrote the ADB debugger tool. He graduated in Mathemetics from King's College, London and has a Ph.D. in Mathematics from Trinity College in Cambridge, England.


Originally published in Queue vol. 1, no. 1
see this item in the ACM Digital Library



Ellen Chisa - Evolution of the Product Manager
Better education needed to develop the discipline

Jon P. Daries, Justin Reich, Jim Waldo, Elise M. Young, Jonathan Whittinghill, Daniel Thomas Seaton, Andrew Dean Ho, Isaac Chuang - Privacy, Anonymity, and Big Data in the Social Sciences
Quality social science research and the privacy of human subjects requires trust.

Michael J. Lutz, J. Fernando Naveda, James R. Vallino - Undergraduate Software Engineering: Addressing the Needs of Professional Software Development
Addressing the Needs of Professional Software Development


(newest first)

Displaying 10 most recent comments. Read the full list here

hepp | Sat, 27 Oct 2012 14:00:23 UTC

I really hope there will be a approach and tools blog at some time. I really want a fly-on-the wall look at how you get from this blob to something useful.

rcf | Thu, 19 Jul 2012 10:32:24 UTC

Are there plans to release any solutions to this challenge?

The failOverview team suggested they would be showing their methods but haven't posted anything on this since their introduction to the challenge in March.

Poul-Henning Kamp | Sat, 05 May 2012 19:20:04 UTC

This just to add a pointer to a very interesting blog post from the crew who reverse engineered the unknown CPUs instruction set in a matter of days:


Poul-Henning Kamp | Sun, 05 Feb 2012 21:51:28 UTC

Well, until we see some actual aliens, I'll refrain from speculating too how they build their computers.

I don't think it is a bad assumption that they might have binary computers, the principle has a lot going for it, so much in fact that it has out-competet all other types on this planet by a large margin.

XAD | Sat, 28 Jan 2012 08:59:37 UTC

I don't fell able to participate to this challenge, but I would like to mention, that there is a fundamental flaw in it: Decoding a human-produced code is far away from decoding an alien-produced code. It should be expected, that the "Hardware" and the "Software" could be based on entirely different principles: other materials, non-binary processors and logic, chaotic organization,.... As a challenge, I would have suggested to decode the DNA Processing Logic (not the DNA-Content, which is now quite well known). Even this would be much easyer, than decoding an alien-based code, since we have a good understanding of its reactions to external inputs.

Poul-Henning Kamp | Thu, 19 Jan 2012 23:30:36 UTC

Thank you for being graceful about this.

If you ever come near Denmark, call me, and I'll show you a LOT of old computing artifacts in datamuseum.dk


Segher | Thu, 19 Jan 2012 18:07:16 UTC

Hi everyone. I am the miscreant who stumbled upon that infernal block diagram (which btw is in the public domain and available on many websites).

We reversed (most of) the instruction set and internal architecture of the CPU, and some of its peripherals. It became clear that this machine was of earthly origin, but nothing else was apparent, not even an approximate age, or what part of the world it is from.

Since I'm quite into computer-related archaeology, and interested in way too many things, I soon found myself on yet another yak-shaving expedition, as always seems to happen. Then suddenly, O Fortuna!, I was looking at a block diagram that matched everything we knew about our alien CPU in detail. That gave us a name for this CPU but nothing much else.

Us being human beings, we threw that name into google, not expecting much (we were told we wouldn't find anything, after all!)

Unfortunately that ends up identifying the device this CPU is from.

Then we contacted phk.

We did not "cheat" in any way. The challenge is to find out what we could from the binary alone; that is what we did. When we could no longer adhere to the rules, through no fault of our own, we were open about that. Poul sent us the schematics of the device, so there is no way we can honestly reverse any more of it; and I do not find looking further into the code driving it to be very interesting, given what its function is, so that's the end of that as well.

But. This was quite a nice challenge for us, and it's really a weird historical computing artefact. I do encourage everyone else to keep looking at it and discover, well, whatever there is to discover, and hopefully your journey will not be stopped short by a train wreck like ours was!


shawn_e | Thu, 19 Jan 2012 16:33:24 UTC

"cluster" comes to mind and I'm not talking about a large array of alien CPUs working together.

Poul-Henning Kamp | Thu, 19 Jan 2012 15:57:09 UTC

There is a reason this was called "a challenge" which is not the same as "a competition".

If you care to read the article, it should be quite evident for you, that the challenge was about broadening our understanding of code and computers, adding to our sum of human knowledge.

It should also be quite obvious that there is no way I can prevent anybody from cheating or breaking the rules of the challenge, in fact, I was quite worried that somebody would come out and say "Hey I wrote that, its ..." and ruin the challenge. That is why the challenge is set up as a "gentlemans challenge".

If you don't care to participate, don't participate, it's entirely voluntary.

If you don't want to abide by the rules of this challenge, at least be a gentleman, and don't ruin it for others.

The group in question broke the rules, it is evident from the material they sent me, that they already quite early tried to identify the device using searches on the web. If you want to ace the challenge and identify the device, you do it by analyzing the program, and from the program *alone* find out what the computer does.

This particular ROM image is pretty unique in the world, in the sense that we have no CPU documentation for the computer that runs it. Probing our knowledge and understanding of code using a CPU which people had heard about or read about, would invalidate the premise "based on only the ROM image".

Ideally, I could have designed a computer and written a program just for such a challenge, but it would not have made the challenge life-like and realistic the way this one is: hardware and software written for educational purposes are never realistic. This ROM image is not realistic, it is *real*.

I still think it is a damn good challenge, and I am very amazed at the skill, speed and deductions of the group who solved it in 5 days.

I am grateful for the information they shared with me, and I am even more grateful that they have not spoiled the challenge for everybody else, in that respect, they have been true gentlemen.

As for winners, I think anybody who manages to solve some part of this challenge will feel like a winner to themselves, it is not in any way an easy challenge.

But the true winners, in the sense that there can be any, is whoever publishes their methods observations and tools, and thus adds to our understanding of computers and code.


rstos | Thu, 19 Jan 2012 13:13:26 UTC

Julian: I have already deleted my work directory and most of my students have done so also.

This has moved from an interesting challenge for them to learn about unknown processors on to a lesson on how NOT to run such a challenge.

Displaying 10 most recent comments. Read the full list here
Leave this field empty

Post a Comment:

© 2017 ACM, Inc. All Rights Reserved.