Prizes will be awarded for Best Paper and Best Student Paper.
WHAT KINDS OF PAPERS DOES USENIX PUBLISH?
The most important thought to keep in mind when deciding whether to submit a
paper is "What will the audience or readers learn from my paper?" We don't
expect every paper to report on a major breakthrough, but we do look for
something new, potentially useful, and not entirely obvious. Think about how
different your work is from previously published papers; it may be good work but
if there is nothing new to learn, it isn't worth reading (or writing) a paper
about it. Think about how other people might find your work useful; can they
apply what you are teaching them to their own systems? And, does your work
really improve upon the previous state of the art? Or does it show how other
people have been confused? "Negative results" that contradict the conventional
wisdom are often as important as positive results.
Trying to decide if something is non-obvious isn't easy (patent lawyers make
lots of money arguing about this), and sometimes the best ideas seem obvious in
hindsight. However, if several people have done the same thing, and you are
simply the first person to have considered writing a paper about it, perhaps it
is too obvious.
The Program Committee will also be trying to decide if papers will lead to a
good 25-minute presentation. Some papers are just too complex to be presented
this way (perhaps you should focus on just one aspect); other papers just don't
have enough to talk about for that long. On the other hand, a few rare papers
are accepted mostly because the committee expects them to produce an interesting
talk, but that might not otherwise merit publication.
Again, when you are writing your paper, keep in mind "what do I intend to teach
the reader?" That means keeping the paper focused on one or a few main points.
Don't try to cram too many big issues into the paper, and don't fill it up with
irrelevant details. But do include enough background for the reader to
understand why your problem is important, how your work relates to previous work
in the field, and how it might fit into a practical system. Also, provide enough
detail for the reader to put your performance measurements in context. It is
vitally important to provide a good bibliography, both so that you give proper
credit to previous work, and so that a reader can know where to turn to find
additional background information. The Program Committee will not look kindly on
a paper if the author doesn't appear to be familiar with the current literature.
MORE INFORMATION IS AVAILABLE
Lots of papers and books have been written about how to write a
good paper. We'd like to suggest that you read a paper called
Evaluation of the Ninth SOSP Submissions; or, How (and How Not) to
Write a Good Systems Paper. This was written by Roy Levin and
David D. Redell, the program committee co-chairs for SOSP-9, and
first appeared in ACM SIGOPS Operating Systems Review, Vol. 17,
No. 3 (July, 1983), pages 35-40.
Although SOSP and JVM have different foci, Levin and Redell
give good advice for authors of any kind of systems paper.
The authors have graciously agreed to make this paper available
If you have any other questions, feel free to send mail to the
Program Chair at firstname.lastname@example.org.
HOW SHOULD I GET MY MANUSCRIPT TO YOU?
The Program Committee would prefer to receive submissions via the
Web form. While we understand that there are
people who may not yet have access to the Web, using the Web for a majority of
submissions will not only help in automating the truly tedious administrative
work in paper submission, but it will also help in avoiding paper printing and
submission costs all around. If you cannot submit your paper via the Web for any
reason whatsoever, please contact the Program Chair (email@example.com)
for alternative means of submission.
We have found in the past that PDF files (readable by Acroread or Acrobat) are
often the best means of submitting papers.
PostScript files are also acceptable, but given that PostScript generators vary
quite a lot, it is likely that we may not be able to print every submitted
PostScript file. For instance, several software packages generate PostScript
that can only be printed on Apple Laserwriters. So if you submit PostScript
documents, please remember the following:
- Use only the most basic of fonts (TimesRoman, Helvetica,
Courier). Other fonts are often not available with every
printer or previewer.
- PostScript that requires some special prolog to be loaded into the printer
probably will not work for us. Please don't send such files!
- If you used a PC or Macintosh-based word processor to generate your
PostScript, ensure that it can be printed it on a more generic PostScript
printer before sending it so as to ensure that the PostScript is portable.
If the paper you submit via the web form is missing figures, tables or other
illustrations that are present in your original paper, please indicate this with
a prominent note and contact the Program Chairs for submitting these
Overseas authors should make sure that their abstract prints properly on
US-style 8.5x11 inch paper. Please make sure that you leave enough room for top
and bottom margins.
Finally, if you have any other questions, at any time during the entire
submissions process, especially if you have a paper idea but have concerns about
it not being "right" for this conference, PLEASE send mail to the Program Chair
The Program Committee