______/\__________________________ __ ________________ ___ /\_______ \____ \ ________ _ _ ______ \ / \| \ ________ | \/ ______/ / | \ _) \ \_/ \ | \ / \ \ _) \ | \______ \ / | \ \ | \ | \/ \ \ / \ \ / \ \_____ /_______/___| /_______/\____\_____/_______/_________/________/ \_____/ |____/ 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