Copy Link
Add to Bookmark
Report
Demo News 148
______/\__________________________ __ ________________ ___ /\_______
\____ \ ________ _ _ ______ \ / \| \ ________ | \/ ______/
/ | \ _) \ \_/ \ | \ / \ \ _) \ | \______ \
/ | \ \ | \ | \/ \ \ / \ \ / \
\_____ /_______/___| /_______/\____\_____/_______/_________/________/
\_____/ |____/
Subscribers : 2605
DemoNews 148 - 07 September 1997 Archive Size : 5.7Gb
>------------------------------------------------------------------ Contents --
Introduction .................................... Snowman
Calendar
In Review
/demos ........................................ Phoenix
Articles
Editorial: Old Skool Paradigm Bitshift ........ Snowman
What Happened To The Demo Scene? .............. Tiberius
Scene Spam .................................... Snowman
Coding Mathematics (part 1) ................... Tiberius
How The Hornet Archive Works (part 5) ......... Snowman
Advertisement: Restless Diskmag, Issue 2 ...... Phoenix
Advertisement: Bizarre '97 .................... Bizarre Organizers
General Information
>-------------------------------------------------------------- Introduction --
Hello all, and welcome to DemoNews 148.
_____Introduction
Surprised that you're getting a new issue of DemoNews? So am I! :)
I've spent the better part of this weekend writing 2 articles for this
newsletter. Frankly, I am tired of writing so this introduction is going to
be rather short.
_____Internautics
A survey is being taken of the digital art community. It would make me
happy if you checked it out, http://www.internautics.com
_____Party Advertisements
I have no problem posting article advertisement for parties. However, they
must be written specifically for DemoNews. I will not post raw .nfo files.
See the Bizarre '97 advertisement below for a good example.
_____Changes to DemoNews
It now seems redundant to have "Top Downloads" and "New Uploads" listed in
DemoNews. Both of these can easily be found on The Hornet Archive itself.
Chances are, if you make use of these sections then you probably have access
to the archive (or one of its mirrors). Unless I get a lot of objections,
these two sections will no longer appear in this newsletter.
Some time in the not-to-distant future, I also hope to have "Calendar" on
The Hornet Archive web pages instead of in this newsletter. But first I
have to set up some sort of automated database system for party markers and
that's going to take a little time.
_____Conclusion
Astronaut. Internet. Exposure. Subliminal messages.
Snowman / Hornet - r3cgm@hornet.org
>------------------------------------------------------------------ Calendar --
Date Event Contact Info
------------ ------------- ----------------------------------------------------
08 Aug 1997 Assembly http://www.assembly.org
FINLAND
22 Aug 1997 Crash http://www.xi-media.com/crash
CANADA
22 Aug 1997 AntIQ
HUNGARY aboy@d-eyes.jpte.hu
25 Aug 1997 NetZone http://www.quaternet.fr:8082/users/b/brunel/p2b5.htm
FRANCE brunel@quaternet.fr
25 Aug 1997 Ritual http://www.geocities.com/SiliconValley/Way/2660/index.html
ISRAEL t3a@netvision.net.il
29 Aug 1997 Gardening http://fryni.physics.upatras.gr/~g97
GREECE g97@fryni.physics.upatras.gr
30 Aug 1997 Gravity http://www.polbox.com/g/gravity
POLAND gravity@polbox.com
30 Aug 1997 Evoke http://kaoz.org/evoke
GERMANY poti@bigfoot.com
* <-- YOU ARE HERE
06 Sep 1997 Neither Nor http://www1.ai.fh-nuernberg.de/~unix169/neithernor.1997.html
GERMANY magus@innocent.com
06 Sep 1997 I. Gathering http://www.metro.it/ig97/new
ITALY ig97@metro.it
13 Sep 1997 Bizarre http://bizarre.cybercomm.nl
HOLLAND bizarre@cybercomm.nl
02 Oct 1997 Distance http://distance.home.ml.org
NORWAY walker@gim.net
03 Oct 1997 InterJam http://home.pages.de/~interjam
GERMANY info@interjam.inka.de
>----------------------------------------------------------------- In Review --
-- /demos ------------------------------------------------------------------>
:: Phoenix / Hornet - phoenix@hornet.org
_____Introduction
Phew, we got a lot of releases to catch up on here.
_____The Reviews
[Note: The demos will soon be moved out of /incoming. Just use The Hornet
Archive's search engine to find them then.]
"Sunflower" by Pulse (incoming/GRV97/demo/pls_sunf.zip)
Winner at Gravity '97. Very thematic, nature-based scenes, each quite
complex (and FPU-hungry, unfortunately for me). Great graphics (of
course), and fitting music, although I found it a little bizarre :).
"Boost" by Doomsday (incoming/ASM97/demo/v2_boost.zip)
Another 3d tour-de-force wins the Assembly '97 demo compo. Doomsday make
a name for themselves by taking the euro-pop sound from Asm '96's "Vivid
Experiment" and combining multiple 2d effects in 3d scenarios. This demo
turns recursion into an art form. Unfortunately, there's a short gap
between scenes (precalcing no doubt) on most machines.
"Mindtrap" by Trauma (incoming/ASM97/demo/mindtrap.zip)
This mostly-Dubius group tried out a little less 3d than expected, and
fared rather well, 3rd place at Assembly. Cool 3d IFS fractal morph is
the simplest effect, and a 3d figure diving into a pool is probably the
most complex one. Anyway, some nice industrial music by Teque/Nitro.
Overall, a little short.
"The Secret Life of Mr. Black" by Orange (incoming/ASM97/demo/markku.zip)
It's hard to keep this release out of one's mind, just give it a listen
:). The effects/design are in the same vein as "Megablast". Again, a
little shorter than desired.
"Saint" by Halcyon (incoming/ASM97/demo/saintfin.zip)
Wasn't shown at Assembly because it wouldn't run, but this final version
should work nicely. This is a demo to be either loved or hated. Rather
unique style and music (supplied by the Amiga group Da Jormas). But the
effects all run very fast, one almost forgets how much 3d is in there.
"Jizz" by The Black Lotus (demos/1997/j/jizz.zip)
950k of music and 3 megs of textures packed into 64k. These dudes be some
kind of witches.
"Misguided" by Haujobb (demos/1997/m/misg.zip)
Another Amiga group goes PC (although many of the people involved in this
release are from Fatal Justice). A whole lotta 3d again, but some nice 2d
effects, and very nice looking and colorful overall. The music delivers
a rather harsh attitude which keeps the fast pace. 2nd at Wired '97.
"Genocyd" by GMF (demos/1997/g/genocyd.zip)
Winner at Wired '97. I found this demo much more enjoyable in a dark room
with a loud sound system :). It's an attempt at a cinematic theme,
reminiscent of the Surrounders' demo 'Emergency' from NAID '96 - but more
so. Included is a complex city fly-through scene possibly inspired by The
Fifth Element. GMF is a new group from France.
_____Conclusion
Anyway, there have been a LOT of demoparties in the past two DemoNews-less
months. So look around on the hornet.org/party page and such for even more
worthwhile productions.
Poetry Shmoetry: If I see any more random shaking words, so help me God, I'm
taking off an automatic half-star. :)
>------------------------------------------------------------------ Articles --
---------------------------------------------------------------------------->
:: "Editorial: Old Skool Paradigm Bitshift"
:: Snowman / Hornet - r3cgm@hornet.org
_____Introduction
Last Thursday, The Hornet Archive celebrated its fifth anniversary. On 04
Sep 1992, Dan Wright founded the archive as a home for the PC Demo Scene.
While the original objective of the archive has remained constant, the scene
itself has changed rather dramatically.
_____What Was Then
I entered the scene in early 1992. I saw Chronogia and Putre Faction and
was hooked. Unreal came along and I was locked in. My life as a PC demo
scener had begun.
With a grin, I recall people being made fun of who coded demos in C. It was
obvious that real coders who used 80x86 assembler had more potential for
cranking out the fastest and most impressive productions.
It was so awesome when Dual Module Player finally took the lead from
Composer 669 and introduced the E8x effect for panning in modules. We
finally were taking advantage of bleeding edge technology soundcards that
supported stereo! My $240 Sound Blaster Pro was finally making use of the
"Pro".
And then came the GUS. The scene shifted. Finally we had a soundcard that
had memory on the soundcard! Whoa. You could actually download the samples
to the GUS instead of keeping them in core RAM. Demos that used to have 20%
CPU overhead while playing a song with a Sound Blaster dropped that figure
to 4% when they used a GUS. The scene, with a keen eye toward new
technology, adopted the GUS as its standard.
It wasn't really an optional card back in 1993. You understood that if you
were an active part of the demo scene, you really needed to get a GUS. If
you wanted crisper sounding output while tracking, you got a GUS. If you
wanted to try and play Starshine on your 386/16 without down sampling, you
got a GUS. If you actually wanted to see the voxel water moving smoothly in
Second Reality, you got a GUS. The GUS wasn't even that expensive. I paid
$157.49 for mine at Babbages on 03 Jul 1993 (I kept the receipt for some
reason).
With a grin, I recall people being made fun of who didn't have GUS support
in their demos. It was obvious that demos using the GUS had more potential
to be the fastest and most impressive productions.
Those were the days.
_____What Is Now
A coworker of mine recently showed me some new OpenGL screensavers for his
3D accelerator card. These things were just like stand alone demo effects,
except that they ran at full framerate in 640x480 24-bit color. Oh, if only
demos had the sort of jaw-dropping effects that I saw in those real-time
calculated screensavers. I really hope the PC Demo Scene can catch up to
the impressive level of productions the OpenGL Screensaver Scene is putting
out today.
Let me say it again.
I hope the PC Demo Scene can catch up to the OpenGL Screensaver Scene.
What the fuck. Screensaver scene? Hehe... oh, you mean those lamerz who
just take new hardware like 3D accelerator cards and push them to the
limits? Lame. Every coder should write their own 3D libraries, not have
them hand-fed on a platter. It's character building! There's no skill
involved with these screensaver dudez. They should develop their own 32-bit
protected mode extenders like all of us do. They should write all of their
sound system libraries from scratch like we all do in the demo scene.
All they do is make extremely impressive visual effects by taking advantage
of modern technological advances. They should talk to Trixter... he'd do
the same sorts of effects and they'd run on a 486/33 at full framerate
(well, it'd be 320x200 and 8-bit palletized color, but at least it would be
solid code).
The problem is that I don't have a 486/33. I have a Pentium 180. I'm not
impressed by solid code unless that code actually does something impressive.
With a frown, I recall being made fun of for contributing to a scene that
didn't use 3D accelerator cards. It is obvious that screensavers and games
using them have more potential to be faster and more impressive than modern
demos.
The mechanism that originally attracted me to the scene -- pushing new
hardware to its limits -- seems lacking today. Don't get me wrong, I still
really enjoy watching demos. I understand that it is more than just the
code, the effects, music, the graphics... it's the overall package. Demos
are an art form and I love them.
But I imagine if I were 18 years old again today, Boost wouldn't give me the
same sort of over-awed feeling I got when watching Second Reality back in
1993. Stories of people finding Second Reality and joining the scene are
numerous. How frequent are the stories of people finding Holistic, Machines
of Madness, or Caero and being hooked? Kids these days are more excited by
the effects in Quake and Pray than they are by Transgression 2 and
Spotlight.
We've lost our impressive technological edge, first to games, now to
screensavers.
_____What Will Be
Part of what makes the PC demo scene a wonderful place to inhabit has always
been the abundance of intelligent, creative, and artistic people. I just
feel a little badly that these people aren't getting the sort of credit or
respect they deserve for the fine productions they do.
To the demo scene's credit, productions do seem to be a little better
designed these days than they used to. It's one of those fundamental things
which sets us apart from the game or screensaver communities.
But in order to regain our impressive edge, we need to attract new minds to
the collective scene pool. We need to stay modern. We need to accept,
embrace, and push new technologies where they were never meant to go.
"Dang! How did you guys make that demo run so smoothly with only a Voodoo
Rush 3D card and a P2-300? I wish Quake 3 ran that smoothly. Are there
other good demos out there? I've had a couple C classes in college and
might like to try coding my own effects sometime."
With a smile, I recall showing my coworker Gorge Dropoff by Timeclock after
Assembly '98. It was obvious that PC demo scene coders had more potential
than game coders for cranking out the fastest and most impressive
productions.
_____Conclusion
This section is left as an exercise for the reader.
---------------------------------------------------------------------------->
:: "What Happened To The Demo Scene?"
:: Tiberius / Inspire Media - tiberius@mailhost.net
_____Introduction
Here I am sitting in front of my trusty PC thinking about typing my first
DemoNews article. I have been somewhat of a spectator of the demo scene for
a while now. I was reading through some old DemoNews and scene quotes and
stuff and I've put together a picture in my mind of what happened to the
demoscene over the last few years.
_____Software Cracks And Exponential Crap
Notice how HA has filled up exponentially with crap music, no more good gfx
and precious few original demos? Yea, me too. There has to be a good reason
for this though. Older sceners remember the time when demos were about an
intro for a softwarez crack and some hardware trick no one knew about or how
to best use 4 music channels when u really needed 8 or something. What has
happened now is that demos are about getting the best PR for your group
becoming famous making money and trying to be more ereet than the next guy
(and not to look lame!).
The problem is that the demoscene went main stream. Sha and who woulda
thought? =) Sad but true. The 'underground' nature of the scene dropped away
very quickly as we got into the 90's. You can blame the nature of the PC if
you like. The PC is too upgradable. Hardware tricks were out because of lack
of standards and standards that progressed too quickly. Blame the net too.
13 year old kid gets net connection. Kid downloads demo. Kid thinks demo is
cool. Kid wants to make demo. Kid downloads tutorials (by Denthor of coz).
Kid releases crap demo to the world and litters CSIPD with drivel about the
fastest putpixel routine (does he know what he wants to use it for?).
I'm not saying that the kid should give up. I _was_ that kid once but my
point is that when you get the new members of the scene from the general
populace and they know little of the 'culture' they're not gonna fit that
stereotype. And so the underground scene died. The cracking and warez scene
still exists but now they too have changed much. They are about gimme,
gimme, gimme. Cracking is not appreciated as a complex and skilled art
anymore it is looked on as a fast way to get free software without paying or
working. Blame the net again.
_____High Level Abstraction, Destruction Of The Low
Hardware is progressing too fast for the demo scene's old culture to exist.
It can not exist when ppl rely on the PC hardware for speed. The gaming
cliche 'we won't release it for a year or so, so the hardware'll catch up.'
now applies to demos too. Again, sad but true. Hey, Trixter, I admire your
belief that any effect can run full frame-rate on an 486-33 but does anyone
care? Why bother spending more time optimizing your code than actually
_writing_ it? The hardware is fast enough without that. On top of all this
we've got talk of JAVA demos and WIN'95 demos. Hey great idea now we can
find a REALLY efficient way of wasting resources ;-)
Don't high level platforms like this take away the whole point of what the
scene once was? The point was you had figured out something that no one else
had. All the others had to think very hard to catch up. If we all start
using big mofo SDKs and just write the conceptual codes then what is the
point? I don't see one and I'm trying not to be negative here :-|
Code is not the only thing that is not what it was. The music scene
demonstrates the current mental consensus best I think, but I won't go into
that because I'm depressed enuf as is.
_____Conclusion
What I say ppl is for us to live by the following statement:
'If your want has afore been displayed then displayed
again it does not need to be.'
Let's get some originality back into the scene, stop with the lame attitudes
and get back to where the heart of the demo scene lies; impressive, fast,
original and inspirational demoz.
Thas my rant for a while =)
---------------------------------------------------------------------------->
:: "Scene Spam"
:: Snowman / Hornet - r3cgm@hornet.org
_____Introduction
> helloo.... i've grown tired of all the scenespam that i've been recieving
> during the past few months. i've asked these people who send those where
> they get the addies from and guess what... hornet.org scener page. :) so,
> if you would bother to put some kind of note on the e-mail catalog page
> saying "PLEASE! Don't use these addies for spamming." or something like
> that, some people actually might get the hint. :)
>
> Howler / Fobia Design - howler@pcuf.fi
I'll do one better. Say goodbye to author email addresses.
Because people have been using (abusing) the author and group email
addresses to build "scene email spam lists", I will be removing them. It
will then be much harder to find authors' email addresses. You can thank
people like: Luuk Akkermans, Ted Callander, Hardcor / MusicwerX, Kaos
Master / RamJam, and Aki Peuralahit for this change.
Two "scene spams" I've received recently are worth noting.
_____Birthday Blues
1. Aki Peuralahit (Peuris Ac Dj-Steel) sent email on 31 Aug 1997.
> Hi ya ppl.
>
> Ok here's my birthday release. A tune called Feeling that
> emotion. I made it whit using IT 2.14 (hey did ya know that
> it save it's own format) so you need IT 2.14 to listen it.
>
> This tune is a bit large, 1.39 Mb huh. but 44 samples 5 of them
> are 8 bits rest 16.
I feel a little bad about picking on Aki here. All he wanted to do was send
a little birthday tune he had written to his friends (or people he just
happened to have email addresses for?). Nothing wrong with that, right?
The problem here is that the email was 1.76 megs in size and was sent to 105
people. By my calculations, that's about 185 megs of birthday music
clogging the 'net as it tries to reach the intended recipients.
Come on people! Let's use a little common sense here. Sending files
through email is something you should do infrequently and almost always on
a one-to-one basis (no cc' mailing). Maybe Trixter wants to send me a new
draft of the MC5 final. Maybe Stony wants to send me some new gfx for the
archive's web pages. Those are the sorts of things where sending files
through email comes in handy.
This is sort of like going to comp.sys.ibm.pc.demos and trying to post your
new demo. You just don't do it.
_____Petition For PnP
2. Luuk Akkermans sent email on 24 May 1997.
> Dear Gususers,
>
> We have just started an action, for the Gus Users. We want Gus PNP
> support in FastTracker 2, because many people want that support. Maybe if
> we have enough mails, we could get the makers that crazy that they are
> going to support the Gus PNP under FT2.
>
> We'd like to ask you if you want to support our action. The only thing
> that you have to do. Send a mail to me, with your real addres, so that the
> authors don't think that we made up some names and that you want Gus PnP
> support under FT2.
>
> [...]
OK, nothing really unusual about this one. The dude wants Gus PNP support
in FT2. Can't fault him for that. It does seem a bit odd to get a petition
going (like Triton _owes_ the scene anything), but I'll just attribute this
to inexperience.
Here's the kicker though. Whatever program Luuk was using to spam the scene
went haywire. I received 64 identical copies of the email (11,267 bytes
each). So did 367 other people. I also got 8 cc'd followup replies from
other angry recipients, for a total of 72 emails:
11,267 bytes per email * 72 emails = 811k of email per person
811k of email per person * 367 people = 298 megs of spam!
After I had received about 30-40 of these emails, I sent a message to the
system administrators of the domain he was using. I got this reply:
> Dear sir,
>
> We apologize for what has happened with a message of two of our
> students. It is not their fault, but there is something wrong in our
> systemsoftware we found out. We hope it will never happen again, we
> are working on that.
>
> Best regards,
>
> ankie maessen
"It is not their fault". What the heck? I can't believe that the system
administrators of hro.nl weren't holding the students accountable for their
actions. For goodness sake, Luuk sent out close to 300 megs of email in a
single weekend. I can remember when the entire Hornet Archive wasn't even
that big! Granted, I'm on a T1 and getting a 100 meg email wouldn't really
be a problem for me, but I'm guessing that more than a few of the 367
recipients are on 28.8k connections or slower, and weren't really pleased by
this.
I got this followup email a few days later:
> Dear user,
>
> We are really sorry for what's happened with the mail we send to you. We
> just send it once, but my mailserver just went crazy or so, and that's why
> everyone received about 100 or more e-mails from me, and all the same. I
> did talk to the owners of my server and they said they don't know what
> happened Saturday. But becasue it was weekend the server kept sending the
> mails Saturday and Sunday. Finally on Monday i could talk to the owner and
> he could put it off. But it still wanted to send about 53.000 mails to all
> of you. I'm glad it didn't send those mails. Please accept my apologies,
> it's not my fault that you received many(!!!!) mails. It's the fault of
> a machine.
>
> [...]
>
> See you...... Luuk Akkermans
I draw your attention to the phrase "it's not my fault that you received
many mails. It's the fault of a machine". No. This is wrong. It is
Luuk's fault. If he hadn't decided to spam the scene, then this never would
have happened. The tool he used broke and he must take responsibility. Do
I curse Watcom because I have C code that won't compile? Do I complain to
Ford because I drove my car into a tree?
_____Conclusion
It really makes me unhappy to spend time building support for something like
scene email addresses, only to have them misused this way. I refuse to
provide the mechanism by which people can spam the scene. Now I have to
delete two Perl scripts that I spent hours working on and dismantle the
email pages. Totally lame.
Do not spam the scene.
---------------------------------------------------------------------------->
:: "Coding Mathematics (part 1)"
:: Tiberius / Inspire Media - tiberius@mailhost.net
_____Introduction
Okay so here I am about to start a series of articles for demonews readers.
There are 2 reasons for why I'm doing this:
- DemoNews is becoming too boring
- this info might be useful (!)
The idea is to teach you coders or any others about the maths principles
behind the math we actually _use_ in code. It is surprising the amount of
coders who simply use a formula of some sort without actually having a clue
about how it was derived. When I was learning to code it was always
something that ticked me off. I decided that I would use a formula unless I
knew how to derive it. It payed off believe me =)
Some experienced coders may have scoffed by now and are thinking about
skipping over this article. I say to you ppl... don't; you may learn
something. However, remember that there are many ways to achieve the same
end in maths; I'm trying to show a simple correct way (with a little
optimization along the way). This series is also not _strictly_ maths but
maths in relation to coding which is entirely different.
Another note: all spelling will be in Australian not American form
(eg. not 'color' but 'colour' etc) since I live in Australia (duh).
_____Assumptions
I have to assume a few things about the ppl who are reading this:
- You know a programming language. Snippets will be in C, Pascal and on
occasion, assembler.
- You have basic knowledge of trigonometry, fractions and similar. If you
payed attention in junior high school you should know that stuff...
- You can follow deformed ASCII diagrams ;-)
_____Schedule
Things will progress in the order of these subjects:
Part 1 : Plans - you already got it!
Part 2 : Vectors - definition, storing, coodinate axes
Part 3 : Vector Rotation (simplistic)
Part 4 : Matrix Math - definition, operations
Part 5 : Matrix Transformations
Part 6 : Rotation Transforms (optimizations)
Part 7 : Calculus - basic concepts
Part 8 : Calculus - the differencial
Part 9 : Calculus - the integral
Part 10 : Calculus - complex integration
Part 11 : Particle Motion (ie. physics+calculus)
Part 12 : Complex Numbers
Part 13 : ??? (if I'm still kicking after that lot who knows =)
If you have a request then I'll slot it in at the appropiate point. Don't
be put off by this wafer thin article... I can drivel on with the best
of them.
_____Who do you think you are? (= comments)
I am Tiberius of Inspire Media. I am still in my last year of high school
but don't let that put you off =) I wouldn't attempt a maths tutorial if I
didn't know this stuff pretty good.
_____Conclusion
If you have any comments/suggestions/fixes/gifts then send them to me:
tiberius@mailhost.net
Until the next part!
---------------------------------------------------------------------------->
:: "How The Hornet Archive Works (part 5)"
:: Snowman / Hornet - r3cgm@hornet.org
_____Introduction
On 23 Feb 1997 (DemoNews.143, part 4 of this series), I talked about SDD
Exceptions. Today is 06 Sep 1997. It seems very odd that it's been 6.5
months since the last article, given that it feels as if I wrote it just a
couple months ago. Regardless, much has changed in the past half year.
I posted the first four parts of this series to The Hornet Archive FAQ:
http://www.hornet.org/ha/pages/ha_faq.html
Recently, I went back and converted the articles from raw ASCII into more
readable htmlized text. I also updated the sections of the articles that
had changed since I'd written them. If this is the first time you've
encountered a "How The Hornet Archive Works" article, you may wish to go
back to the FAQ and read the previous ones. I will assume you have the
knowledge contained within them.
As the years pass, the archive becomes cleaner and better organized. The
scripts I write and rewrite have solid and more optimized code. New
utilities take advantage of the facilities provided by older ones. There is
a synergy between my little army of scripts. They all understand that the
overall goal is to keep the archive as well maintained as possible. To do
so, they must cooperate. No longer do they work alone.
Today I'm going to talk about the automated side of The Hornet Archive. You
might be surprised at just how much the archive does all by itself.
_____A Note About Cron
From "Unix Power Tools" by Jerry Peek, Tim O'Reilly, and Mike Loukides:
"cron allows you to schedule programs for periodic execution. For
example, you can use cron to call a particular UUCP site every hour, to
clean up editor backup files every night, or to perform any number of
other tasks."
In a nutshell, cron is responsible for enabling The Hornet Archive to run
certain scripts every hour, day, week, and month. You just tell the
machine, "I want THIS script run at THIS time of the day, every day", and it
does. The file where you specifiy all of your cron information is called
your "crontab".
Because I have so many scripts that need to be run regularly, it gets rather
awkward to list all of them in my personal crontab (each person on the
system only has a single crontab file). Many months ago, I created four
little shell scripts:
HA.CRON.HOUR - lists scripts to run hourly
HA.CRON.DAY - lists scripts to run daily
HA.CRON.WEEK - lists scripts to run weekly
HA.CRON.MONTH - lists scripts to run monthly
Then all I have to do is have my crontab call HA.CRON.HOUR every hour,
HA.CRON.DAY every day, and so on:
[mins hrs day-of-month month weekday command]
45 * * * * /a/ha/ha4.5/HA.CRON.HOUR
30 04 * * * /a/ha/ha4.5/HA.CRON.DAY
30 05 * * 6 /a/ha/ha4.5/HA.CRON.WEEK
30 06 1 * * /a/ha/ha4.5/HA.CRON.MONTH
In this excerpt from my crontab file, I have HA.CRON.HOUR running every 45
minutes past the hour, HA.CRON.DAY running at 04:30 every morning,
HA.CRON.WEEK running at 05:30 every 6th day of the week (Saturday), and
HA.CRON.MONTH running at 06:30 the first day of each month.
The times are staggered for those situations where it might be both the 6th
day of the week _and_ the 1st day of the month (or something like that). It
would be "awkward" if two of my batched cron scripts were running at the
same time. "Awkward" is my cute little way of saying "things would probably
get really fucked up."
_____Watch Go Beep!
Some of you are probably wearing watches right now that go "beep" every
hour. Turn that beeping off when you go see a movie... that's so annoying.
Anyway, the next time you hear your watch beep, think about The Hornet
Archive.
Here is what the archive does every hour:
01. ha4_list -l / -b 3HOURS -f -q
Translated: Get a list of all files "-l /" that have been cataloged or
changed in the past 3 hours "-b 3HOURS", flood "-f" new 00_index.txt and
index.html files into those directories, and be quiet (no screen output)
"-q".
The reason I say "the past 3 hours" instead of "the past hour" is just a
precautionary thing. If the machine is down when the hourly cron is
supposed to run (highly unlikely) then the indicies wouldn't get updated.
Specifying files that were updated in the past 3 hours gives us a little
overlap. It also means I don't have to try and code some special utility
that detects if all indicies were updated correctly. The resource
overhead of 3 hour refreshing instead of 1 is minimal anyway.
02. ha4_www
Translated: Refresh the database that is used for public web searching.
I keep two copies of the master database on the archive at all times. One
is in the same directory with all of my other scripts (where you can't get
to it, neener neener!). The other is in the /cgi-bin directory (where you
_can_ get to it and do searching). The reason I keep two copies is just
a safety thing. If one of my scripts goes bonkers and destroys the base
master database, I can just copy back the one in the /cgi-bin directory.
Additionally, if I _do_ really goof up the base database, your searching
doesn't break and I can take my time fixing the problem "the right way",
rather than trying to hack a fix in so you can search again.
There are a couple other minor things that are done every hour, but they are
temporary (one has to do with a file permission problem I can't figure out,
and the other deals with public /music rating).
Beep.
_____A Day In The Life Of HA
In the darkness of the night, when sceners sleep, my little army of scripts
stalk The Hornet Archive. It's a precision military operation. Objective:
secure the archive, free the prisoners, eliminate any resistance. You have
5 minutes. GO GO GO!
Perhaps overdramatizing the situation is one way to maintain your interest.
I hope I was successful because this section is _really_ dry.
Here is what the archive does every day:
01. ha4_master_optimize -n -q
Translated: Resort the database in alphabetical order (by filename).
Back in the old days (circa March of this year), I used to handle database
sorting a bit differently. Let's say that I wanted to list all songs in
the /music/songs/1996/s directory. First, all of the SDD's in the
database that began with "/music/songs/1996/s" would be grepped out. Then
they would be sorted. Then the output would be formatted.
It occured to me one day that I could cut down a lot of search time
overhead if the database was already presorted. OK, so they won't write
about this in any Computer Science textbooks, but it made me happy.
Rather than sorting the output every time a user tries to search, I sort
the database once a day. Then when you try to search for something, the
engine assumes the database is already in the correct order. I pass the
time savings on to you, faithful Hornet Archive searching person.
02. ha4_list -l / -b 50HOURS -f
Translated: Get a list of all files "-l /" that have been cataloged or
changed in the past 50 hours "-b 50HOURS", flood "-f" new 00_index.txt and
index.html files into those directories, and report on which indicies were
updated.
You should already be familiar with this one. The only changes from the
hourly version of this are the "-b 50HOURS" and the absense of the "-q"
(quiet option).
Because the database is only sorted once per day, sometimes the hourly
refreshing of index files gets a little goofed up (listing files in the
wrong directories). But I would much rather have a couple index files
screwed up on the archive if it means that search time is decreased.
One of the features of cron is that it will email me whatever screen
output was generated. I don't want the hourly index refreshing to send me
email so I use the "-q" option. But for the daily refreshing, I like to
see a list of exactly which directories were updated so I don't use "-q".
03. ha4_integ -l / -f $HA_DIR/HA4.ROOTFIX -q
Translated: Get a list of all files in the database "-l /", do some
checks on them, and output a executable script of fixers (commands that
are needed to fix discrepencies) "-f $HA_DIR/HA4.ROOTFIX". Oh, and don't
produce any screen output "-q".
ha4_integ is a really nifty script. Think of it as lint for HA (for those
C coders in the house). Here is a list of things that ha4_integ checks:
1. files listed in the database physically exist
2. sizes of files in database are accurate
3. files are not writeable (overwriteable)
4. files are not executable
5. files are group owned by ftp-hornet
6. files are individually owned by appropriate maintainer
7. field testing:
a. filename does not contain a '#'
b. SDD rating is valid (ignores missing ratings from /code,
/contests, /disks, /educate, /info, /invites, /party, /programs,
/samples, /utils)
c. title is present
d. no preceeding whitespace in any fields
e. no trailing whitespace in any fields
Some of the problems that ha4_integ finds it can fix automatically:
leading/trailling whitespace, chmod'ing files to read-only, etc. Some of
the problems it can't fix though. Say that Phoenix cataloged a demo today
and it hasn't been set read-only. Well, ha4_integ normally could just
make the file read-only. But since the file is owned by "phoenix" (and
the script is running as "r3cgm"), the script doesn't have permission to
fix the file. In this case, ha4_integ spits out a special list of fixers
that need to be executed as "root". And wouldn't you know it, root's
daily crontab says "execute a special list of fixers for The Hornet
Archive if necessary".
The overall objective here is not really complicated. All cataloged files
should be read-only. They should be owned by the appropriate maintainer.
They should have a title and a clean SDD entry, etc. ha4_integ is just a
tool used to insure that certain states are maintained.
04. ha4_www
05. daily_bad_zip_check | tcsh
Translated: Find all .zip files in /incoming that are at least 1 day old,
check to see if they are corrupted, and remove the ones that are. Record
the files that were removed in incoming.log.
06. daily_UPPER_check | tcsh
Translated: Remove all files in /incoming/music that have any UPPER CASE
characters in the filename, and log the results in incoming.log.
07. daily_music_check /incoming/music/disks
daily_music_check /incoming/music/programs
daily_music_check /incoming/music/samples
daily_music_check /incoming/music/songs
Translated: Check the /incoming/music directories and prepare the files
for ha4_frmproc (the auto-cataloger script).
When ha4_frmproc runs, it makes the assumption that the files it is
auto-cataloging do not have problems. daily_music_check checks for the
sorts of discrepencies that would give ha4_frmproc problems:
1. 0-byte files
2. long filenames
3. invalid filename characters
4. if file is a .frm or .zip
5. if .zip has a matching .frm
6. if .frm has a matching .zip
7. if .zip file is corrupted
If any file meets one of these conditions, it is immediately removed and
logged in incoming.log.
There is a little logic flaw here that you may notice. Assume that
happy.zip and happy.frm are uploaded to /incoming/music/songs. Let's say
that daily_music_check first tries to check happy.zip and finds nothing
wrong. Then daily_music_check checks happy.frm and finds out that it is
a 0-byte file. So it deletes happy.frm. Uh oh! Now happy.zip doesn't
have a .frm file with it, but we've already checked happy.zip and given it
the "go ahead" for ha4_frmproc to auto-catalog. Well, let me tell you
that ha4_frmproc is not going to be happy about that at all.
It is necessary to do a double-pass check of all files. That way on the
second pass, daily_music_check realizes, "Hey, there is no .frm file
accompanying happy.zip". happy.zip gets deleted and logged, and
ha4_frmproc can do its job.
Incidentally, daily_music_check calls ha4_frmproc itself with a list of
files to catalog. I do not call ha4_frmproc directly in my crontab. You
could think of daily_music_check as a handy preprocessor for ha4_frmproc.
I'll save discussion of ha4_frmproc for another day.
08. ha4_master_optimize -n -q
Translated: Since daily_music_check has just used ha4_frmproc to catalog
some new files, we need to resort the master database again.
It might be prudent to mention now that whenever a new file is cataloged,
the SDD is appended to the end of the master database. This is why the
database gets "out of order". You might think, "Hey, whenever you catalog
a new file, why don't you put the new SDD in the correct location within
the database?". You are probably right, I should. However, the time it
takes to resort the database (currently at 15,000 records) makes it very
annoying to do so every time a new file is added. Let's say that GD is
cataloging /graphics. His connection to hornet.org isn't very good, so he
tries to stay connected to the archive for as short a period of time as
possible. Sorting the database after each new file is cataloged just
makes it inconvienient for us internally.
09. ha4_allfiles -l all -o $BASEDIR/allfiles.txt -q -z
ha4_allfiles -l /demos -o $BASEDIR/demos/alldemos.txt -q -z
ha4_allfiles -l /music -o $BASEDIR/music/allmusic.txt -q -z
ha4_allfiles -l /code -o $BASEDIR/code/allcode.txt -q -z
ha4_allfiles -l /mags -o $BASEDIR/mags/allmags.txt -q -z
ha4_allfiles -l /info -o $BASEDIR/info/allinfo.txt -q -z
ha4_allfiles -l /party -o $BASEDIR/party/allparty.txt -q -z
Translated: Make the allfiles.txt, alldemos.txt, ... files, zip them up
"-z", and be quiet "-q".
10. ha4_compdbdir -d /demos -x alldemos.zip
ha4_compdbdir -d /music -x allmusic.zip:/mc5/
ha4_compdbdir -d /code -x allcode.zip
ha4_compdbdir -d /mags -x allmags.zip
ha4_compdbdir -d /info -x allinfo.zip:/audiofil/:/DemOS/
ha4_compdbdir -d /party -x allparty.zip:.message
Translated: Build a list of all files that physically exist and diff them
with the files in the master database. Exclude "-x" certain files and
directories depending on which directory tree we are checking.
This is _not_ the same thing as checking every file in the database to
make sure that it exists. This is the reverse. Checking all existing
files and seeing if they are in the database. The purpose of
ha4_compdbdir is to see if any unwanted crufty files have appeared in an
invalid location.
Maybe I went into /music/contests/mc5/files and "unzip mc5final.zip
file_id.diz" just to check something. Maybe Phoenix was editing a
reviews.txt file in /party/results/1997 and forgot to remove it.
ha4_compdbdir seeks those files out and reports them to me. With the
exception of a couple files like allfiles.zip and a couple directories
like /audiofil and /DemOS/, the _only_ files that should be in our major
directory trees should also appear in the master database.
11. ha4_list -l / -o u4 -i > $HA_DIR/data/author_count.hdat
Translated: List all files "-l /", output a list of unique instances of
the 4th SDD field (author) "-o u4". Also include a count of how many
times each of those authors was found "-i".
This sets things up for building the author pages. The author_count.hdat
file that is generated is used to show how many files each author has online.
The data file itself looks something like:
turrican 1
varg 3
x2c 2
xCh 1
xenoc 1
12. ha4_link_author -c $HA_DIR/data/author_count.hdat
-e $HA_DIR/data/author_email.hdat -u $HA_DIR/data/author_urls.hdat
-d $BASEDIR/ha/pages/authors
Translated: Build the author pages using the data files author_count.hdat
for how many files the author has online "-c author_count.hdat",
author_email.hdat for email address "-e author_email.hdat", and
author_urls.hdat for homepages of the authors "-u author_urls.hdat".
Generate the pages in the directory /ha/pages/authors "-d
/ha/pages/authors".
13. ha4_list -l / -o u5 -i > $HA_DIR/data/group_count.hdat
Translated: List all files "-l /", output a list of unique instances of
the 5th SDD field (group) "-o u5". Also include a count of how many
times each of those groups was found "-i".
14. ha4_link_group -c $HA_DIR/data/group_count.hdat
-u $HA_DIR/data/group_urls.hdat -d $BASEDIR/ha/pages/groups
15. gunzip /a/backups/hornet_dlf2/hornet_dlf2.$TOP_LOG.gz
Translated: Uncompress the log file that lists all transfers made to/from
The Hornet Archive yesterday.
The daily Hornet Archive log file is in a format I created called DLF2.
For those webmasters in the house, DLF2 is just a friendly comprimise that
allows ftpd's xferlog files and Apache's access_log to be converted to a
consistent format. The ACiD Artpacks Archive also uses DLF2-formatted
logs.
16. ha4_logproc -d /a/backups/hornet_dlf2/hornet_dlf2.$TOP_LOG -o cgml
> $TOP_HTML/days/top_day_$TOP_LOG.cgml
Translated: Use the daily log file "-d hornet_dlf2.$TOP_LOG" to produce a
list of Top Downloads for yesterday in CGML format "-o cgml".
17. gzip /a/backups/hornet_dlf2/hornet_dlf2.$TOP_LOG
Translated: Recompress yesterday's log file.
18. cd $TOP_HTML
ln -fs days/top_day_$TOP_LOG.cgml current_day.cgml
Translated: Go to the Top Downloads directory, and refresh the symbolic
link that points to the current day's page.
19. ha4_du /archive/pub/demos/
ha4_du /archive/pub/demos/code
...
ha4_du /archive/pub/demos/incoming/party
Translated: Check to see what the size is of major subdirectories. Record
the information to a log file that will be used in late 1997 or early 1998
to produce a web page showing a graph of how The Hornet Archive is
growing.
20. cgml_htmlmatch $BASEDIR/ quiet
Translated: Find all CGML-based pages that have been updated in the past
day and refresh their HTML equivelants. Be quiet!
CGML is just a hack mark-up language I created a while ago to ease the
burden of updating the appearance of several hundred web pages at once.
Typically, I edit an index.cgml file and it is then converted to an
index.html file so you can view it. If I need to, I can completely change
the look of all pages on the archive with very little difficulty,
maintaining cohesiveness and consistent color schemes and formatting.
21. cat /a/r3cgm/list/dn | mail listserver@unseen.aztec.co.za
Translated: Send an email to the DemoNews listserver asking how many
subscribers we currently have for the newsletter.
The return email is caught at my home mailbox by procmail and stuffed away
for safe keeping.
22. ha4_list -l / -b 1DAYS -o DNO | mail -s "HORNET TODAY" r3cgm@cdrom.com
Translated: List all files "-l /" that were cataloged in the past day "-b
1DAYS", output in optimized DemoNews format "-o DNO" and send it to me in
email.
Whew! That sure is a lot of stuff to do every day. Let's take a look at
the cron.log file for yesterday (06 Sep 1997) to see how long it takes.
#
# Daily cron output
#
04:30:01 ha4_master_optimize - optimizing of master database (first freshen)
04:30:02 ha4_list - updated indicies of any dir requiring it
04:30:12 ha4_integ - ran integrity checker
04:30:56 ha4_www - copied web-related files to /cgi-bin
04:30:57 daily_bad_zip_check - checked for/deleted bad .zip files
04:31:01 daily_UPPER_check - checked for/deleted UPPER CASE files
04:31:02 daily_music_check - checked and cleaned /incoming/music/disks
04:31:03 daily_music_check - checked and cleaned /incoming/music/programs
04:31:03 daily_music_check - checked and cleaned /incoming/music/samples
04:31:03 daily_music_check - checked and cleaned /incoming/music/songs
04:31:09 ha4_master_optimize - optimizing of master database (second freshen)
04:31:11 ha4_allfiles - updated all_____.zip files for master lists
04:31:52 ha4_compdbdir - Comparing directories to master database
04:32:24 ha4_list - Author Links (calibrating count data)
04:32:28 ha4_link_author - Author Links (regenerating pages)
04:32:33 ha4_list - Group Links (calibrating count data)
04:32:35 ha4_link_group - Group Links (regenerating pages)
04:32:37 ha4_logproc - Top Downloads (gunzipping log file)
04:32:39 ha4_logproc - Top Downloads (generating daily page)
04:33:52 ha4_logproc - Top Downloads (gzipping log file)
04:33:59 ha4_logproc - Top Downloads (current_day.cgml symlink)
04:33:59 ha4_du - statistics reporting, size of certain dirs
04:34:32 cgml_htmlmatch - updating and matching .html's to .cgml's
04:34:49 cat ~/list/dn - asked how many DemoNews subscribers we have
04:34:49 ha4_list -b 1DAYS - mailed Snowman list of new files cataloged
04:34:52 - DAILY CRON FINISHED
4 minutes and 52 seconds is how long it took my army of scripts to complete
their mission. Great job soldiers!
_____Weekly Woes
Well, the daily cron is the biggest and most complicated. Only a couple
things need to be done every week:
01. ha4_logproc_days -n 7 -o cgml -w $TOP_HTML/weeks/top_week_$TOP_LOG.cgml
Translated: Produce the Top Downloads page for the past 7 days "-n 7" in
CGML format "-o cgml".
This is fairly time consuming. Doing the entire daily cron took 4 minutes
and 52 seconds. Simply generating the weekly Top Downloads page takes 4
minutes and 44 seconds. This might have something to do with the fact
that Hornet Archive logs are about 30 megs in size each week!
02. cd $TOP_HTML
ln -fs weeks/top_week_$TOP_LOG.cgml current_week.cgml
Translated: Go to the Top Downloads directory, and refresh the symbolic
link that points to the current week's page.
03. ha4_list -l / -f -q
Translated: Get a list of all files "-l /" that have ever been cataloged,
flood "-f" new 00_index.txt and index.html files into those directories,
and be quiet (no screen output) "-q".
This currently takes about 3 minutes and 57 seconds to do.
_____And The Grand Finale...
The monthly cron. The mother of all crons. HA.CRON.MONTH is the scariest
script in the whole automated arsenal.
Why?
If I make a change to the monthly cron, I won't know if it really worked or
not until the first day of the next month. Sure, you can do as much testing
as you like, but having something run without your constant supervision is
a totally different scenario. If I modified the cron today, I'd have to
wait over 3 weeks to know if the change worked! One little typo, one
incorrect parameter is all it takes to goof up a script. And the results
can be disasterous (or at least very time consuming) to correct.
Here is what the archive does every month:
01. mv $HA_DIR/HA4.LOG $HA_DIR/logs/ha_log.$TOP_LOG
gzip $HA_DIR/logs/ha_log.$TOP_LOG
touch $HA_DIR/HA4.LOG
chmod 660 $HA_DIR/HA4.LOG
Translated: Move The Hornet Archive's internal log file to another
directory and compress it. Create a new one in its place and make
sure that other archive maintainers can write to it.
02. cp $BASEDIR/incoming/incoming.log
$BASEDIR/incoming/_logs/incoming.log.$TOP_LOG
gzip $BASEDIR/incoming/_logs/incoming.log.$TOP_LOG
echo -n "" > $BASEDIR/incoming/incoming.log
Translated: Move the /incoming directory's log file to another directory
and compress it. Create a new, empty incoming.log.
03. ha4_logproc_custom -s $TOP_LOG -o cgml -w
$TOP_HTML/months/top_month_$TOP_LOG.cgml
Translated: Produce the Top Downloads page for the past month.
This is the single most CPU and time intensive thing that The Hornet
Archive does. This single script will run for about 25 minutes, as it
goes through about 125 megs of raw ascii DLF2-formatted transfer logs. If
something goes wrong, I am very unhappy.
04. cd $TOP_HTML
ln -fs months/top_month_$TOP_LOG.cgml current_month.cgml
Translated: Go to the Top Downloads directory, and refresh the symbolic
link that points to the current month's page.
_____Conclusion
I can't believe I just wrote that much! This article was going to start out
as a quick little intro to the automated side of HA. It turned out to be a
fairly comprehensive guide. Most of you probably skimmed this article, and
that's ok. Just get a feel for exactly how much the archive does for itself
these days.
In addition, this article might serve as an example to other budding archive
maintainers out there on how they might wish to structure their own
automated utilities. I dunno... it just seemed as though this stuff should
be documented somewhere. Hey, someone's gotta take over for me one day.
Next edition, I have no idea what I'm going to write. Stay tuned! :)
---------------------------------------------------------------------------->
:: "Advertisement: Restless Diskmag, Issue 2"
:: Phoenix / Hornet - phoenix@hornet.org
_____Introduction
The second issue of Restless is well underway! Unfortunately, we are still
short on enough articles and votes for it to be release-worthy. This is an
urgent call for contributions from the Restless co-editor (and your humble
Hornet demo reviewer :).
_____The Scoop
People get magazines to read, right? Well, Restless is useless if people
don't write articles for it! We need _your_ help. Articles on the demo
scene, music scene, coding, tracking, graphics, parties, reviews, news,
rumors, interviews, and just about anything else scene-related are needed!
We don't always have to be serious - send your poetry, humor, and weird
stories too. If the demoscene wants to read it, we'll print it!
The next issue of the Restless mag will feature:
- Improved interface, including hi-/true-color support!
- More articles (which is up to YOU to make possible!)
- Graphics from: BenJ/Imphobia, Frost/dCb.
- Music from: Necros/FM, Mosaic/Renaissance, GD/Hornet, and more!
- Interviews with: Darkness/Imphobia, The Zapper/Force Ten, Statix/Acme,
Hunz/FM, and maybe more!
- Reports from: Assembly '97, Crash '97, and local American gatherings.
- Free advertisements!
You can place one or two text OR graphics ads in Restless #2. Look at
rst2ad.frm in the pack below for details.
Editors wanted! Yes, you too can earn the envy of your peers by becoming a
Restless mag editor! Contact restless@mindless.com for details.
_____Conclusion
Get the contribution pack at:
- http://www.hornet.org/incoming/info/rst2cont.zip
- ftp://ftp.arosnet.se/demo/diskmags/rst2cont.zip
It contains info about the next issue, plus vote and advertising forms.
Keep the PC demoscene going strong, and write/vote for Restless today!
---------------------------------------------------------------------------->
:: "Advertisement: Bizarre '97"
:: Bizarre Organizers - bizarre@concepts.nl
[Bizarre will start 13 Sep 1997 in HOLLAND]
_____Introduction
What is Bizarre?
For the fourth time in a row, Bizarre will be organised, this years'
edition: Bizarre'97. Looking back on three successfull parties, the decision
to hold Bizarre '97 fell right after we had finished the '96 edition.
What once started as the first PC-only party in Holland, has turned out to
be a SCENE event more and more since the amiga scene was attending our party
more and more every year. This is why we decided to turn it into a full
PC-AMIGA event. Bizarre always lasted two days, until this year, since we
finally got permission to make it THREE days, so we can satisfy your
uncontrolable urge to PARTY!
_____Accomodations And Features
We try to improve Bizarre every year, not only in trying to make the
competitions to perform as smoothly as possible, but also in terms of
accomodations. Since the first Bizarre back in 1994 we've accomplished a
great deal. With a seperate theatre hall equiped with luxurious seats, a
screen of 10 * 7 metres and 1.5 KWatt Dolby Surround Sound, we've almost
achieved the perfect conditions in order to present YOUR products. Not many
other parties can present you the same for the low entrance fee we ask of
you. This year the entrance fee will be about $23, which has to be paid in
the Dutch currency of course.
Also a huge network will be present, which you will be able to hook up onto.
The network can handle up to 400 computers, and has a very fast backbone
with some extra services like: WWW, FTP, e-mail, IRC and voting. A smaller
network of TV's will also give you information about the party, so even if
you don't bring a computer you can still stay well informed about what's
going on at our party.
But enough technical mombo jombo, Bizarre'97 will also feature a very nice
and comfortable lounge where you can eat and drink something at an
affordable price. In this lounge it is also possible to have a nice
conversation with friends from the scene you haven't seen in a long while.
The main hall is big enough to hold 500-600 computer freaks along with their
equipment, and ofcourse lot's of POWER is present though you should bring
your own shielded powercables. When there aren't any competitions in the
theatre hall, it will be used to present some videos, presentations and
performances to you. One of them is a small concert of ARF! which will rock
your socks of with their jungle, acid, breakbeat, techno and other funky
grooves.
And when you grow really tired of partying then there is our quiet and
carpented sleeping room, where you can sleep. Don't forget to bring your
sleeping bags if you are planning to get some sleep on Bizarre'97.
_____Conclusion
For details on competitions get the NFO file on our homepage at:
http://bizarre.concepts.nl
Also keep a close eye on this page for the latest information about the
Bizarre'97 program.
That's about it for now, if you have any questions you can always e-mail the
organisation at bizarre@concepts.nl or visit our site,
http://bizarre.concepts.nl, for the latest information, news, rumours and
updates about Bizarre'97! On this page you can also make reservations for
our party!
>------------------------------------------------------- General Information --
_____The Hornet Archive (mirror sites)
Current mirror information: http://www.hornet.org/ha/pages/mirrors.html
USA (master site) http://www.hornet.org
ftp://ftp.hornet.org/pub/demos
Australia http://www.livewire.com.au/pub/demos
ftp://www.livewire.com.au/pub/demos
Germany ftp://ftp.uni-paderborn.de/pc-demos
Poland http://ftp.icm.edu.pl/pub/demos
ftp://ftp.icm.edu.pl/pub/demos
Portugal http://mirrors.telepac.pt/pub/demos
ftp://mirrors.telepac.pt/pub/demos
Portugal http://hornet.esoterica.pt
ftp://hornet.esoterica.pt
Sweden ftp://ftp.luth.se/pub/msdos/demos
USA (/code only) http://www.co.iup.edu/code
ftp://ftp.co.iup.edu/code
_____Where To Get DemoNews / TraxWeekly
New issues - http://www.hornet.org/incoming/info
Old issues - http://www.hornet.org/info
_____How To Subscribe To DemoNews / TraxWeekly
Mail: listserver@unseen.aztec.co.za
subscribe demuan-list YOUR_NAME
subscribe trax-weekly YOUR_NAME
_____How To Unsubscribe From DemoNews / TraxWeekly
Mail: listserver@unseen.aztec.co.za
unsubscribe demuan-list
unsubscribe trax-weekly
_____Where To Send Questions/Comments
questions@hornet.org
>------------------------------------------------------------------------------
EODN
