yaxu writes "A short Perl script co-won the transmediale software art award this year. check the press release and the original code submitted.
Actually I wrote the thing but this award should act as encouragement to all Perl hackers who take artistic pride in their work... Maybe you should enter that JAPH next year!"
Well, I don't know if I'd call it art, but then again
die die die die die die die die die die die die die die kill 9, $$;
I love this quote from the press release:
McLean’s “forkbomb.pl” is a variation of a famous computer science exercise, which suffocates the computer with its own processes. “forkbomb.pl” was awarded as a crafted code which is transformed into an art of technical transgression.
"an art of technical transgression" indeed!
"Technical transgression", huh.
pemungkah on 2002-02-13T20:33:40
An interesting and somewhat frightening thought, that - that "technical transgression" is "art". Do hack attacks now count as art? Viruses? Wouldn't an obfuscated program to completely erase the disk of the subject system be even more "crafted" and an even greater "technical transgression", and therefore, even better art? Will be seeing art as a defense in computer crime trials now? Would a documented breakin of a computer (like people pushing empty carts around a Wal-Mart) be performance art?
Then again, I suppose if firing a handgun at a departing airliner or crawling over broken glass can be considered art (and yes, they really have been), this can be too.
Has anyone spoken to the author? Did he really mean this to be a sendup of the whole business, rather than something serious? Seems more like Marcel Duchamp's urinal signed "R. Mutt" and entitled "Fountain".
You want art in Perl? SelfGOL is art in Perl. Joseph Cornell comes to mind.:)
# shell script named foo
foo&;foo&;
To get rid of it and the 'bomb', just 'rm' the file. This program is a little more dangerous in that once you execute it, the code will be interpreted and removing the source file will not affect its execution (unless I've got that wrong).
*sigh* - I dunno
Jason
Re:Stupid
pudge on 2002-02-13T20:27:51
Why would anyone want any art, then?Re:Stupid
Purdy on 2002-02-13T20:46:09
I suppose the right analogy in the sculpture world would be... well, this is a stretch, but dense matter, where once it was installed in your home, would collapse everything inside your home onto itself, destroying your home. I may outbid you for that so that you wouldn't have it installed in my home.
:) Jason
Re:Stupid (actual esthetic - maybe - results)
pemungkah on 2002-02-14T23:22:00
If you take the output from the program and turn it into a graphic, you get a sort of op- art dealie which is kinda nice. As generative art, it's really pretty elegant: it produces different "art" each time it runs, and it's a simple piece of code that has a lot of sensitive dependence on initial conditions. Admittedly, as a piece of code that someone might idly run "to see what it does", it's a boxful of Denial of Service, and a few precautions might have been in order.
In defense of the artist (and yes, I think the graphic is art, though not produced in a manner I'd choose), the point he's trying to make is that an itty bitty piece of code which explores the limits of a process can do something interesting, not that ha><0rs r00l:
... the output of [forkbomb.pl] is significant in that it is a visualisation of the execution of the process in a more complex performative manner[!]. On a technical level, the computer is under such a high load that it fails to comply to its instructions - after a while the fork calls fail to split the process in two, and. the ordering in which the task scheduler does things becomes less-ordered the harder it is pushed. In this way, the output is a visualisation of the computer's performance during the program's execution. The output would look very different on different computers, thus providing a 'watermark' of the processor and operating system. The code and the resultant actions are intricately linked in poetic dialogue.
"Complex performative manner"... oo-er, he sure knows how to talk criticspeak! And he's right, it'll be different every time. Then again, he's definitely not thinking like a sysadmin:
To separate the code and the resultant actions would simply limit the aesthetic experience...
"Look at this cool picture we made by overloading your system until it crashed! Isn't it nice? We're planning on running it again when there are more people on so we get a different one! Uh, why is the sysadmin carrying a baseball bat? Ow! Oh! Help! My esthetic experience is bein' limited! Ooh! Ouch!"
The whole article about the esthetics and ideas involved is at this page. I think he's got a valid point, but that maybe he should consider, metaphorically speaking, putting the lid on the paint thinner instead of pouring it into a glass and leaving it standing around.
--- Joe M.Re:Stupid (actual esthetic - maybe - results)
yaxu on 2002-02-15T09:43:02
thanks for that
although my name is on the paper you reference, i contributed ideas rather than words. to be honest, i can't grok that academic language either. the words you cite are largely Geoff's response to the fork bomb, who is neither a sysadmin or a programmer.
i don't think this fork bomb encourages people to crash other peoples systems. it has a built in limitation and a warning, so on both counts it's less dangerous than the simple perl -e 'fork while 1'
i didn't have one motivation for writing this script, it's just a simple hack. it allows many points to be made around it (aka post creative rationalisaion;), and i'm trying to make points in support of the artistic programmer and his/her environment. Re:Stupid (actual esthetic - maybe - results)
yaxu on 2002-02-15T09:45:11
oops, apologies for the lack of line breaks...
it should have been
thanks for that
although my name is on the paper you reference, i contributed ideas rather than words. to be honest, i can't grok that academic language either. the words you cite are largely Geoff's response to the fork bomb, who is neither a sysadmin or a programmer.
i don't think this fork bomb encourages people to crash other peoples systems. it has a built in limitation and a warning, so on both counts it's less dangerous than the simple perl -e 'fork while 1'
i didn't have one motivation for writing this script, it's just a simple hack. it allows many points to be made around it (aka post creative rationalisaion;), and i'm trying to make points in support of the artistic programmer and his/her environment. Re:Stupid (actual esthetic - maybe - results)
pemungkah on 2002-02-15T15:45:11
Well, you've encouraged me to try to do a generative music program in Perl, so that's a positive effect, anyway. (I agree with you about the academic language -- but I bet it did score with the judges!:) )
--- Joe M.Re:Stupid (actual esthetic - maybe - results)
yaxu on 2002-02-16T22:10:47
heh, Perl is the best medium for music that i've found so far... i've found it plenty fast enough for realtime composition too.
what do you have in mind, Joe?Re:Stupid (actual esthetic - maybe - results)
pemungkah on 2002-02-21T18:04:12
well, I've been doing Eno-style "true" ambient - what I think of as "combinatorial" ambient - by hand lately, and it's a bear to do it that way. A layered series of motives, which shift relative to one another over time, allowing different combinations to appear. A sort of follow-on to "Music for Airports".
I'm working through the design of a virtual studio to experiment with this kind of composition. The idea is to be able to set up several sets of harmonically-related loops of different lengths, which, on each run, randomly offset themselves relative to each other. The resulting MIDI file can be played back either realtime or recorded for posterity.
I've experimented with SSEYO Koan and find it too mechanical for what I want to do. So, I get Perl to do he heavy lifting - handling the loop management - and I can then come up with the materials I want to use.
Obviously there are lots of ways to go with this. Chaotic/genetic evolution of material, "shaping" arrival and departure of materials (I would want to indicated density, but not control it), and so on. I'm going to submit it for OSCON and see whether anyone is interested. I figure I should have some solid results by then.
Dunno about realtime control yet; I'm still considering the basic structures I want to implement first. I may want to look into POE for multiprocess control, but I don't know if it's fast enough for realtime work or not.
The idea, of course, is that I'm only outlining the basic ideas and then letting the "musicians" inside the Perl program decide what to play. I'm very excited about the possibilities.
