Bay Area Video Coalition, San Francisco, June 8, 2011
After a background as a Unix systems administrator, Mark Hellar became involved in the context of media art when working at the Bay Area Video Coalition1 in San Francisco and the San Francisco Art Institute2. He is currently working for the SFMOMA3 on the preservation of some of their computer-based artworks as part of the Matters in Media Art program4. One of these works is Agent Ruby5 made by Lynn Hershman Leeson in 2002 for which he tested the possibilities of virtualization as a preservation strategy for web-based works. Emanuel Lorrain (PACKED vzw) met him to talk about his background and his experience with the use of virtual machines at the SFMOMA to display artworks that are part of the collection.
PACKED: Could you tell us about your background and how you began to work with media art in general?
Mark Hellar: My education is both training and some autodidact education. I have a humanities degree and I augmented that with evening classes. I worked in corporate IT from 1996 to 2003, where I built Linux servers. My very first IT job was to build and maintain a cluster of Unix servers. Those jobs were all very cut and dry IT work. Even if I liked them, after seven years it felt a bit mundane. As I had studied video editing in college, I applied for a scholarship for 300 hours of training at the Bay Area Video Coalition (BAVC). There I studied video engineering and worked with software such as Avid6, Final Cut Pro7, Max MSP Jitter8, Flash9 and all the Adobe tools10.
With these new skills I found a job at the San Francisco Art Institute, in North Beach. I worked there for about five years as the manager of academic technology. This job meant that I was overseeing the digital media labs, the digital classrooms, the digital dark rooms, etc. A lot of artists in residence came there, like the Raqs collective11 from India. They had technology requests much different than the ones you get in a traditional IT setting, like setting up a sensor on a staircase so that when someone walks by, a projection plays, etc. It was out of my realm, but I found out that I was happy to work in both a creative and technological context. I really developed skills and sensibilities around that over the years.
PACKED: So that is where you applied your IT education to art for the first time?
Mark Hellar: Yes, and in this art context I really enjoyed it, because in pure IT the requests are very formulated and standardized, there is a recipe for almost everything. In the San Francisco Art Institute requests were more like “hey, I want to have an application that slows down video”. So I had to make Jitter patches, use Arduino boards12, microcontroller boards13 to set up sensors, etc. There was no formula, I just had to do it and figure it out in some really interesting ways. Later BAVC offered me a job, as they had a gigabit fiber connection to the Internet. I thought that they were really at the center of technology and that there were a lot of possibilities for artists with this infrastructure.
PACKED: Are you still working for BAVC today?
Mark Hellar: Yes, but not as an employee. I run a company called Hellar Studio’s LLC where I'm alone and through which I have a number of contracts with the Bay Area Video Coalition. I’m overseeing a lot of their broadcast systems and also taking on a lot more of their overall IT responsibilities. I worked at BAVC for a while, but I left to become the IT director of a children’s technology museum downtown where we were working on interactive exhibitions and things like that. I came back to BAVC to facilitate the move of a television station that they had taken over. It was on the other side of town. We had to move the transmitters and all the equipment. As the television station is a 24/7 operation, we had to keep a signal up without interruption.
In addition to BAVC, I have a three year contract with SFMOMA under the Matters in Media Art program where I focus solely on the preservation of digital artworks. Last year we worked on pieces such as Lynn Hershman Leeson’s Agent Ruby and Julia Sher's Predictive Engineering214 where we used the technology of virtualization for their preservation.
PACKED: How did you first get involved with the SFMOMA and the issues related to media art preservation?
Mark Hellar: I started having conversations with SFMOMA when I worked at BAVC. In San Francisco there was also a smaller art institution called ‘New Langton Arts’ that had been around for about 30 years. They contacted me in 2008, because they had a grant sponsored by Richard Reinhard from the Pacific Film Archive in Berkeley15. The grant was for a case study on John Ippolito's Variable Media Questionnaire (VMQ)16, in which a number of people like Christiane Paul17, and institutions like the Franklin Furnace18 or the Performance Archive in New York had entered works. There were different types of works, like installations, performances, etc. I assisted in entering one of the New Langton Arts'19works in the VMQ. It was my first introduction to media art preservation. I thought that what they were trying to do was interesting.
Later, Jill Sterrett, Head of Conservation and Collections, called me through a mutual introduction. From 2001-2002 there was a curator at SFMOMA named Benjamin Weil, who was interested in digital art, and they created an online gallery, the 'e.space'. There was an online exhibition with works by Julia Sher, Lynn Hershman Leeson, Mark Napier and a number of other artists, but the SFMOMA never acquired any works officially. A couple of years ago, Rudolf Frieling became the new curator for new media works and got interested in acquiring these works in a formal way. When BAVC’s preservation department was asked what they should do with Agent Ruby, the executive director referred them to me.
PACKED: Was the SFMOMA looking for a strategy in order to preserve these kind of works?
Mark Hellar: Yes, to summarize, Rudolf Frieling first asked “how do we collect this?” and then Jill Sterrett asked “how do we conserve this?”. When I first saw the work, it was on an old Redhat 520 Linux server current in 2000 running on an old PC in their basement. The work was running from this old computer with a floppy drive and PS2 ports21. It was online and had been on in their server room since the exhibition. It was still working, but it was about ten years old.
PACKED: During this period, was the work checked from time to time to see if everything was still OK?
Mark Hellar: Yes, the SFMOMA has another consultant who does the maintenance on this work. He did check it, patched it up and ran maintenance, but he thought that the museum should put it on a virtual machine. I also told Jill Sterrett that virtual machines were what everyone was doing at the moment. She answered: “well, I don’t think it’s in the realm of IT”. I said that some belongs to the realm of IT because a virtual machine has to be set up, but you can't just take the phone book and call some IT consultants to handle this. You need someone who has a little sensitivity and sensibility because this is an artwork. You need that overlap: a logical decision-making process, but also an artful understanding. These new skills are needed if a museum is going to approach this type of artwork. Agent Ruby is a website with files, a Java program, a database, and some artificial intelligence algorithms. It takes in visitor input, runs that against the database, responds to the visitor, collects info, etc. There is a physical object, but the actual object itself is not solely physical, it is also software.
PACKED: Had the museum made any backup at the time?
Mark Hellar: There were some backups and other things, but I just took a copy of the whole drive. I was afraid that the hard drive was going to stop working. So I took an image of that machine, started looking through it and then created a virtual machine.
PACKED: Did you use VMware22to create the virtual machine?
Mark Hellar: Yes, I used VMware because the IT department at SFMOMA has a very good infrastructure and already runs VMware. They have multiple servers, and there is a sandbox23 in there. There are virtual machines running asset management databases, the e-mail servers, and hosting all the storage. I think they have around 20 to 30 terabytes of storage in their sandbox. As their infrastructure was very robust, I just made a VMware image, tuned it and tested it. VMware images are just files. So I could simply run and launch them on this infrastructure. The number one priority was to get it safe and in a stable environment. Then there are other advantages of using virtualization. It is cheap and portable, and in the future, ‘New Langton Arts’ for instance might just be a small gallery of software art that you could launch as an archive on Amazon's cloud24.
PACKED: Agent Ruby is a web-based work where the hardware, this PC with a Linux system, is just a carrier. Is it also why it was easily portable to a virtual machine, because the hardware isn't particularly important for the work?
Mark Hellar: We had a long interview with the artist Lynn Hershman Leeson about the work to ask her what was OK to do and what was not. Before that, the sensibility to this kind of work had not been communicated to the IT team. So when they found the computer, they just asked themselves “what is this thing sitting in our vault”?
PACKED: Do you plan to have other digital works from the SFMOMA collection on this infrastructure?
Mark Hellar: Yes, and that was the case before. Different independent works were on this old computer and if one went out of control or got hacked, it could take down the whole thing. Now there are several virtual machines. Basically, if something goes nuts on one thing, it is not going to take down the whole server anymore, because there are several virtual machines. I could for instance take Julia Shers’ work, as all it requires is a web server it is just made out of flash files. Agent Ruby is more complex, as it requires a database and a Java virtual machine25.
PACKED: What kind of database is Agent Ruby using, what is it used for?
Mark Hellar: It is actually made of several XML files26. It is not a true database like mySQL27 for instance. Agent Ruby wasn’t able to take snapshots over time, but as you interact with the work it collects little bits of information and keeps a file on you. All its XML files slightly change over the years. When I started working on it, there were 8 gigabytes of conversation logs dating back from 1999 until now. Rudolf Frieling, the curator, was really excited by the fact that he has a record of the public interacting with the work. Most of the time it is something you don't have.
PACKED: Do these logs allow one to have an overview of the evolution of the work?
Mark Hellar: Yes, and if they had had virtual machines back then and if a snapshot had been taken every year, they could run all the works together and compare how the Agent Ruby of 2000 and the one of 2010 answer the same question. There would probably be a difference based on, for instance, what happened in the meantime: the Iraq war, the hurricane Katrina, etc.
PACKED: So virtual machines can also be used to document works that are growing and changing?
Mark Hellar: Yes, and Agent Ruby does change. Lynn Hershman describes it as a learning machine. It is learning and even if it is not as robust as you would think it is, there are still 8 gigabytes of logs. It is interesting to consider going forward when you get a more complex work like this one. I think we are at a good place. If we get a work created today, let's say an Agent Ruby created with today's technology, we have the possibility of taking a snapshot every year.
A clone or a sandbox also allows for a working environment where one can take a clone of a work and research its parts or really look at what is on this server without affecting the original. We could test upgrading a lot more easily by having it on just one machine. Agent Ruby was in Java 1.1, which should have been deprecated. As the museum had the Java source code, we were able to recompile it in Java 1.4. to have it compliant and secured. This procedure was done with a clone and not the original. But at the same time what is the original in the context of digital artworks? Is that an issue that you can clone these works? Those are questions as well.
PACKED: Is taking snapshots of Agent Ruby something that the SFMOMA is now considering?
Mark Hellar: I gave the collection team a schedule of things to do: monthly, every 6 months, and yearly. We also talked about maintenance cycles for the work. It is always on display. Because it is a public facing work, you will know when there is trouble with it.
PACKED: Were there any problems upgrading the work to a newer Java version?
Mark Hellar: I had to make a few minor tweaks on the configuration files, but it wasn't too bad. I was able to do it in the virtual machine that I created. I also kept records.
PACKED: Is the version that is currently on display the tweaked clone running in a virtual machine?
Mark Hellar: Yes, it is running on a VMware ESX server right now. There is also a Palm28 version that you can still download and I asked them if we should try to resurrect it as well. We could get an old Palm on eBay, load it up, try to get the source code out of it and port it over to something else.
PACKED: You mean making an iPhone application out of Agent Ruby for instance?
Mark Hellar: Yes, an Android or iPhone version, something like that. It is a conversation that we could have in the future.
PACKED: At the moment of acquisition did the SFMOMA only get the compiled Flash application from the artist, the SWF?
Mark Hellar: Yes, the museum only got the compiled Flash. They didn't get the .FLA file. That became an issue when I had to update Lynn Hershman Leeson’s old AOL email address in the application to her latest one. I talked about that with one of her initial technicians and asked him if I could run a Flash decompiler on the file.
PACKED: So what you did was decompile the SWF file29 to get the source code? Didn't the artist or her technicians have the FLA file at all?
Mark Hellar: No, they didn't have the source file. That is why using a decompiler was the only way I could do these simple tweaks here and there, like changing the e-mail address. Actually, the interface is made of three different Flash files. There were some FLA files on the computer, but it wasn’t like the entire source tree with all the source codes and everything. Luckily, the ActionScript is pretty minimal, so I was able to decompile the SWF file successfully.
When I went through the server, I found a ton of things: some Java code, 3D models and different versions of the flash interface. As they were building the work, the Flash interface was totally different. DiNA, another work by Lynn Hershman, has a similar backend to Agent Ruby, but with a 3D avatar where the lips move on the frontend. A 3D model of Ruby existed. So there was this sort of archeological den. The server didn't only contain the final work. It was more like being in a studio.
PACKED: How does the ActionScript30 communicate with the Java program in Agent Ruby?
Mark Hellar: A config. file31 allows for the dialogue between the Java program and the flash interface. The Java program is running in the background and has its own web server called jetty. It is a Java webserver. The interface is actually sending and receiving data from the port 2001; for instance the ActionScript says "parse this and send it to port 2001", etc. It is a call-response type of behavior.
PACKED: Did you ever talk to the person who made the Flash application and the Java program?
Mark Hellar: I did have access to the artists' technician and we were able to interview him. We did no have access to the original programmers. Aslo there were a short amount of programmer’s notes that outlined what the Java program was and how it communicated on this port. There was a config. file to change this port. So you wouldn't need to go back to the .FLA file.
PACKED: Did the SFMOMA try to get the source files?
Mark Hellar: Yes, this came up. I explained to them that they needed to get the source code. I also explained to them what decompiling was when I had to decompile Julia Sher's project. I told them: "decompiling is like having a house and taking all of the material and putting it in neat piles so that you can then conceptualize a design change, and rebuild it. If you can’t compile it because you don’t have the source code, you can’t do that." Fortunately with Flash you can decompile the application.
PACKED: Are these questions part of the interview you have with the artists?
Mark Hellar: Yes, we have conversations with the artists at this juncture. In the case of Agent Ruby, we were able to ask the artist a lot of things, as she is still alive. If you ask Agent Ruby for instance “who is the president?”, it answers George W. Bush. So I asked Lynn Hershman Leeson if we could update it so it says Barack Obama. Her answer was “No, you can’t do that, this is Ruby’s intelligence and how it has evolved and not evolved.". Then I asked if we could upgrade the source code and recompile it to Java 1.4 and she answered "Yes". If I did not do it, I would leave it up to the world and it is a security thing.
PACKED: Was the security risk the reason why you updated the Java?
Mark Hellar: Yes, because the work is facing the world all the time. The archival virtual machine with the old Java 1.1. still exists. The museum can put that file in cold storage in their sandbox or on their LTO tapes, and look at it later in a hundred years or so and figure out how to put it on their operating system of the time.
PACKED: In your presentation of the Agent Ruby case during the DOCAM Summit you mentioned 'disaster preparedness'. Could you explain what it encompasses?
Mark Hellar: That was kind of my IT hat (laughs). To give an example, the VMware server has this type of thing where it keeps a clone of your virtual machine at any time. So you can tell him to cut over to your clone if you can’t ping this server within 30 milliseconds. Because they are just files, you wouldn’t need to run in, install a new server, set it up, move the files and plug it in. Instead I can have these hot copies. It is really typical in a high availability infrastructure like Microsoft or IBM mail servers where, if it is acting up, it could be corruption. So there is a copy constantly shadowed. Of course, I may hear about a problem with Agent Ruby after a certain amount of time. However, that is what I meant by 'disaster preparedness'. That is good, because it is an artwork, which in a museum should have the same value as any sculpture or painting for instance.
PACKED: When the work came to the SFMOMA for the exhibition, was it already shown from the server located in the museum?
Mark Hellar: I think it was always on that server.
PACKED: What about the domain name? Is it something the SFMOMA also acquired?
Mark Hellar: There was a domain name: agentruby.com pointing to the server of the SFMOMA. The museum had it, but it got jacked when it expired. Someone else grabbed it and now wants around 500$ to sell it back. The museum might buy it. For now, it is accessible through http://agentruby.sfmoma.org/. It was a good conversation to have because with web-based works the domain name is important. It became another thing to add to my checklist.
Next year, we are going to work on Learning To Love You More32, a work by Harrell Fletcher and Miranda July. It is a PHP website and the domain name problem has already come up. I told them to do the transfer ownership and then to pay maybe for ten years. That is something that is not technically challenging.
PACKED: Which limitations or shortcomings have you encountered using virtualization?
Mark Hellar: One challenge is the snapshots. If you take snapshots of Agent Ruby, it uses about three gigabytes, but then there is a problem to have it stored by the IT department. Another question is: how many snapshots do you want? I said "let’s take one every month". In reality, storing the snapshots is not a huge issue because storage is so cheap. It also keeps getting cheaper.
PACKED: Wouldn't the question “how frequently should snapshots be archived” be answered differently for each work?
Mark Hellar: Yes, it is particular to a work. In Agent Ruby, there is for instance this ever-changing chat log. I guess that you could just backup the logs, but there are other things that are changing too, like the database that she uses to chat with the user. On the contrary, I worked on a piece by Julia Sher. It was made in Flash, where you don’t want anything to change and you want to checksum the files so that they are the same every time, etc. For a work like Agent Ruby snapshots are important. It would be the same for a lot of web works that you can see for instance on Rhizome33 which pull data and aggregate things from the Internet. For static works one or two snapshots might be enough. These are questions that should be asked in the technical examination of the work.
PACKED: What is your feeling for the future of all these works using external data from Google, Yahoo, Flickr, Facebook, etc. or even the works located in a virtual world like Second Life?
Mark Hellar: I once talked to someone who was thinking about how to archive virtual worlds. I was thinking “good luck with that one”, because there is a whole Second Life server farm for instance. What can you do? Clone the models, reverse engineer the script and just put all this on your own single server somewhere? Yes, that is a little challenging. For some of these works, you may look at your tools again, take a snapshot of it, make a local database, but then let it run, call out your maintenance protocols, keep looking at Flickr for instance, change your API34 in two years or whatever when Flickr gets acquired by someone else for instance. But do you change it over? It's a good question. In my opinion, you should collect the data for as long as you can, but it will be hard to keep these works running forever just because of the nature of the data streams.
PACKED: So you would have some kind of living document that you can use?
Mark Hellar: Yes, so that people can get a sense of what the work was, but you should try to keep it online as long as possible. However, artists can have different opinions about that too.
PACKED: Until now you only worked on web-based art, but you will also work on other type of computer based artworks for the SFMOMA. Can virtualization be used as a general approach for a collection?
Mark Hellar: I was at SFMOMA the other day and we were talking with Bill Fontana about his piece Sonic Shadows, which used a Max/MSP patch running on a Macintosh. In addition he had a whole set of electronics and accelerometers. He had placed them in various locations in the steam room to catch subtle vibrations. The work then piped the analogue signals from the accelerometers into this Max/MSP patch, which went to these amplifiers and speakers in the atrium. The Max/MSP patches controlled the servomotors, making the speakers pan and tilt. We met the artist and talked about what we would do with Agent Ruby. He then wondered how they would show his work in a hundred of years, if they acquired it. It is a challenge for a work with Max/MSP. Cycling7435, the software editor, is a very small company here in San Francisco and we don't know how much time they will be around. After Miller Puckette developed it, Opcode Systems36 acquired it. Now Cycling74 runs it and maintains it. That shows how things change. The same happened with Flash.
PACKED: Couldn't the applications made with Max/MSP run in a virtual machine?
Mark Hellar: They could, but there are also a lot of hardware components in this work: the accelerometers, the thin custom speakers made of Mylar that cost about 2000 dollars, etc. Virtualization sounds like a magic word. It is for some things of course, but it is not going to work for the hardware. So I told the museum and the artist that we needed to make schematics for the electronics.
PACKED: Even before getting to the problems that hardware might have, could there be any communication issues between the applications and the hardware components through a virtual machine?
Mark Hellar: On VMware, I can see all my serial ports, USB ports. I can for instance program my Arduino from a virtual machine. But if you use a virtual machine in ten years, will it be able to communicate with a serial device? If it doesn't use USB anymore but Thunderbolt instead, will it work? That is a good question. I don’t know. You could probably figure something out, but that is a real question. With artworks like that, you should spell out a prescription and build a maintenance protocol when you virtualize your first generation. For instance: in two years check exactly this, whether there are still USB ports? etc. I don’t think you can ever consider that you are good for a hundred years.
PACKED: Does the documentation of these works at SFMOMA include regular maintenance?
Mark Hellar: Yes, Jill Sterrett is very solid about the documentation. So we have something called maintenance protocols as part of it together with the file and everything from the keystone information, the technical narratives, what has been done, what should be done, etc.
PACKED: How often are such maintenance protocols processed?
Mark Hellar: For Agent Ruby, it is something like every month, six months, one year, two years. Then we check back before that two years period is up in order to extend or amend the maintenance protocols if we find anything over that period. I also think that it is crucial to make notes for the next group of people that are going to do this later, like passing along a list of things to consider and that they would update. It is in fact very similar to a video transcription form or a SIP form with transfers and technicians’ notes, checksum data and regular maintenance schedules. Establishing a sensibility around that is key.
PACKED: In the case of Agent Ruby, what does this maintenance protocol include?
Mark Hellar: For Agent Ruby, it mainly consists of checking the version of Java, patching the latest version of Ubuntu, how to do it, … It is real IT, but it is specific to the parts of Agent Ruby. Maybe that is not enough because now when I think about the question of hardware, will it still be possible to send this RS-232 protocol37 over the new port through the virtual machine? I’m glad that we are talking about the hardware, because so far we only had software. Hardware is a whole different ground. With all these custom parts in electronic installations, it is very challenging now.
Maybe we should look at FPGA38 that are kind of virtual machines for electronics. I’m nowhere near that, but someone made a whole Commodore 64 with these FPGA’s. It is a chip with which she created a Commodore 6439 emulator, but in hardware not in software. You have to use VHDL40 programming to use it, you lay out a circuit, upload it, and then it becomes your virtual machine but on a hardware level. I imagine that someday you may be able to use that to preserve hardware-based installations as it is pretty much a virtual machine for electronics.
PACKED: To be in the best possible situation, what guidelines for acquisition should be followed? What should a museum ask for when it buys the work?
Mark Hellar: Agent Ruby was already acquired, but I’m doing this kind of guideline this year for SFMOMA's Architecture and Design Department. They've got H26441 and Divx42 files. What I told them is that they should go back to the creators and ask for uncompressed formats, or files with a lossless compression for archival copies. I did a presentation on Codecs at the SFMOMA. I showed different levels of compression starting from an uncompressed format, to convince them that they should go for the least compressed files (or uncompressed if possible), and a display copy like H264. They are now integrating it into their acquisition’s process. So we are working on that. For the software, I recommend getting the source code and being aware that platforms such as Flash are tied to a company that may not be around forever. I try to bring these sensibilities.
Packed: Is this done during the technical examination of the work?
Mark Hellar: The examination template of the work is not purely technical; it also describes the work and what it does. You should use whatever tools you have to examine the work carefully: all the parts, the files, the electronics. You should add everything useful in the documentation: the PDF of an Arduino if there is one, the data sheet for some esoteric sensors, the technical instructions of the programmer, etc. The documentation should explain how all the parts work together, maybe by making some sort of schematics. I know that not everyone has the time to do that, but to really collect these works you have to find new skills in order to do so.
Packed: This was also based on the interview that you had with the artist.
Mark Hellar: Yes, Jill Sterrett, Rudolf and I had a long interview with Lynn Hershman Leeson and her technician. That was very important, because the artist was saying at that point in time “sure you can upgrade the Java, but you can’t change the database entries”. So we felt that was very important. As the artist is alive, we keep having interviews every time there is a migration or major upgrade or change. So we have that body of records with the interviews. In a hundred years you can refer to that artist's intent. It is not perfect, but as long as you have that interview, it is very valuable.
PACKED: When you receive a work on a computer where everything is working and might work for ten years, wouldn’t it be a useful procedure from a documentation point of view to take a similar computer and install the same operating system, the same software and run the work to see if anything changes? Even when you install the same operating system or application there are many options that you can choose to have or not.
Mark Hellar: Yes, to know what you want to have and what you don't want to have as well. That is a very good question. I guess you need to know what the system requirements are, but for Agent Ruby, as it is Java it could run anywhere. I installed a new Ubuntu Linux with support for the next five years and I only put Apache, Java and a few other bits onto it to have a very elegant Linux server. When you install an OS, you can choose that you don’t want the German language for instance or Microsoft Paint or whatever. We decided to have a very elegant Linux installation.
If you can get the system requirements from the artist on how to install this from scratch on a new system, I would recommend that. Unfortunately, it may not be that easy to get that from the artist. If you can’t do so and you have already acquired the work, VMware has the P2V tool. With this tool, you can take a physical machine and turn it into a virtual machine. Then if you make sure that everything works, you can check every configuration and have an extensive technical narrative. With Agent Ruby, we broke down every single part to see what is required and how it works together. We now have a very clear understanding of that.
The P2V is not perfect, but it is a good tool. Everyone has his/her tools, for instance a stone conservator has a set of tools. It is important to know the tools that are available to our field and to build a skill set. I’m sure there will be new media conservation programs in universities soon, but there is not so much at the moment. So all we have right now is these artists willing to let us take on their works to see what the right tools for conservation are and share such knowledge.
PACKED: Agreements made with the artist at the acquisition level could also be important. So that part of the preservation work is prior to the work entering the collection?
Mark Hellar: Yes, you want to get as much information as you can and getting the source code is really influent. I was talking to Richard Reinhardt about some compiled C43 files for Windows 95 and he said “I need the source code” but the artist did not have the source code. He still acquired it, and maybe if he can't decompile it, he can run it on a virtual machine forever. It could be an example of him taking his tool, the virtual machine, to be able to display the work.
PACKED: Even for less complex works, it is often a problem acquiring the skills needed in-house. How do you think a museum could try to manage the different kinds of knowledge and skills needed for digital artworks that often include many different technological layers? From Java to Arduino or Flash, the range of knowledge that one needs to have is very wide. What sort of knowledge should museums be looking for?
Mark Hellar: Yes, sometimes they can seem like really esoteric technologies (laughs). I think you have to apply the following MIT Media Lab philosophy: "when you don’t know it, you learn it". At SFMOMA, we are creating a model to at least cover the works of the collections. In museums there is a need for such a new sets of skills. How to get them might be a question that museums have to ask themselves. I think a lot of them are already asking themselves. If we are going to acquire this type of work, what do we need? We’re seeing new programs that are addressing the digital, but there is a need now. I think museums need to ask themselves what kind of skills they need and how to acquire them.
PACKED: If museums don't acquire such skills, the knowledge could be lost because only a few people are interested in learning old things like component electronics or how to program with ActionScript 1 for instance. For some it wouldn't make sense to go backwards.
Mark Hellar:Yes, or understand how a Pascal44 program worked. At the same time digging is fun and exciting, but of course it takes a lot of time. For sure, some don't want to go backwards with the old Pascal files or find an old Palm Pilot on eBay. (Laughs)
PACKED: Would you also recommend acquiring software related to the file? If you acquire a work made in Flash, should you also buy a Flash 5 installer or a license for Max/MSP for instance?
Mark Hellar: What would be good, but we are not there yet, would be to have a database between institutions and do a survey of the old works of new media that they are collecting and the software parts that are required. With something like a central database or a central record of each work, its technical narrative etc., you could work out what tools are needed. Then you could have a central repository, but I don’t know if it would ever work.
PACKED: You could also run into trouble with licensing and rights issues.
Mark Hellar: Yes, putting together your own archive of software wouldn't be easy. I’m hoping archive.org will take care of a large part of that. I saw that they started archiving software like video game patches, open source applications of the nineties like Winrar, Hotdog professional, a sort of Dreamweaver predecessor,… Then of course there could be licensing issues based on the tools you choose, for instance QuickTime versus Flash versus Ogg vorbis or webM. I had to make such decisions for the work of an artist which I did in Processing and Java, in order to get the source code. If I had done it in MAX/MSP, I could have given him the source code, but if Max/MSP ever folds, would they be able to run it? Probably they’d have to run it on a virtual machine, but then they could get lag or something. To avoid licensing and rights issues, I try to use open source solutions as much as possible.
PACKED: That is what you would do in the case in which you help an artist to develop the work, but then when you receive a piece that was not made with open source but all proprietary software? For video, for example, you could say I'm going to digitize all my Digibeta tapes to MJPEG2000 and MXF in order to be open source, but would you do the same for computer art and go from MAX/MSP to Pure Data for conservation purposes?
Mark Hellar: Those are very good questions. I think they should be discussed with the artist as well. Fortunately, with the works of the SFMOMA, the artists are still alive. So we can keep up a dialogue with them, but they are not going to be around forever. I, for instance, think that we should convert the Flash files to HTML5, at least as an experiment. Adobe is developing a tool to convert Flash to HTML5, but I haven’t tried their beta version yet. I attended a conference on Flash versus HTML5. There are a lot of things that HTML5 doesn’t do yet, specifically with sound. We are talking about converting Julia Sher's piece to HTML5, but I’ve been hearing that they didn’t put a lot of emphasis on the sound features. HTML5 is not the ultimate solution yet, but I think we are going to try it out.
PACKED: Did you ever experience sound problems when using VMware?
Mark Hellar: I haven’t dealt with sound that much other than through a Flash file coming out of a web interface. Most of the works I've worked on have been web-based. So I don't have a virtual machine with a MAX/MSP patch for instance, but I imagine that the sound drivers could be a problem.
PACKED: It seems that some people have experienced delays.
Mark Hellar: Yes, there could be a delay because the sound has to go through the host and the hypervisor before the virtual machine. I imagine that it may improve, because even if virtualization has been around for a long time, it was probably about 1996 that the current sort of virtualization tools like VMware, Virtual Box, or Xen environment appeared. There is a huge drive behind it now. Amazon ec2, Google cloud and all these businesses are running a whole infrastructure of Virtual Machines.
PACKED: Going from Flash to HTML5 is a migration type of preservation strategy. On the contrary, by using a virtual machine, you don't have to use a different format to the one used to create the work. Were you concerned about that aspect?
Mark Hellar: Yes, and for this type of work it is great, because you can have a virtual machine running your Atari 40045 with the work made in Pascal and keep running it on modern hardware.
PACKED: With technologies like virtualization or the HTML5 standard, what is your feeling about the development in the realm of digital artworks preservation?
Mark Hellar: It is evolving at this hyper rapid pace. I hope that it will be an advantage for this type of work. But at the same time, the drive for virtualization solutions is web facing things and server based, not so much client and multimedia based. So it may also not evolve in the direction needed by the media art preservation field. It is what it is. These technologies are very beneficial for conservation, but they are driven by business. The culture of technology at large is obsolescence, but we are now taking this same virtual product and using it for posterity. We'll see how it goes.
Notes: