From Tim.Maletic at priority-health.com Tue Apr 3 09:33:06 2001 From: Tim.Maletic at priority-health.com (Maletic, Tim) Date: Wed Aug 4 00:01:13 2004 Subject: FW: [GRLUG] Apr14 meeting cfengine Message-ID: Dear GR.pm, I've recently learned of the existence of the Grand Rapids Linux User's Group, and will be giving a talk there on host-security-via-cfengine on April 14th. If you're interested in the topic, or Linux, and have no plans for noontime the Saturday before Easter, come on out! -Tim -----Original Message----- From: Jim Pharis [mailto:jbpharis@commanche.acad.emich.edu] Sent: Monday, April 02, 2001 6:21 PM To: grlug@grandrapids-lug.org Subject: [GRLUG] Apr14 meeting cfengine GRLUGGERS, This coming April 14th there will be a meeting at the Keller Engineering Building in downtown Grand Rapids @noon. Directions to the meeting can be found at the grlug homepage (www.grlug.org). Tim Maletic will present GNU's cfengine, a topic that he will be presenting at SANS2001 (www.sans.org) in mid-May. Among other things, he will show us how to use the cfengine utility for site-wide host security. Cfengine, or the configuration engine is an agent/software robot and a high level policy language for building expert systems to administrate and configure large computer networks. Cfengine uses the idea of classes and a primitive intelligence to define and automate the configuration and maintenance of system state, for small to huge configurations. Cfengine is designed to be a part of a computer immune system, and can be thought of as a gaming agent. Links: http://www.iu.hio.no/cfengine/ http://www.gnu.org/software/cfengine/cfengine.html Hope to see everyone there! Sincerely, Jim Pharis www.grlug.org webmaster Student @ Grand Valley State University --------------------------------------- One by one the Penguins steal my sanity --------------------------------------- -- *** Sent from http://grandrapids-lug.org *** ******************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. ******************************************************************** From bill_day at mcgraw-hill.com Wed Apr 11 15:31:16 2001 From: bill_day at mcgraw-hill.com (bill_day@mcgraw-hill.com) Date: Wed Aug 4 00:01:13 2004 Subject: The story behind the parrot Message-ID: <200104112033.f3BKXZi06665@gocho.pm.org> My pulse quickened when I saw that Perl was merging with Python to create a new language Parrot. This has been out for 1.5 weeks, and I was surprised that I hadn't seen anything posted here yet. For details see: http://www.oreilly.com/parrot/ and http://www.oreilly.com/news/parrotstory_0401.html From joelmeulenberg at yahoo.com Sun Apr 22 18:11:28 2001 From: joelmeulenberg at yahoo.com (Joel Meulenberg) Date: Wed Aug 4 00:01:13 2004 Subject: Tim's Point About Humans Masquerading as Perlbots - A Solution? Message-ID: <20010422231128.96781.qmail@web13008.mail.yahoo.com> I'm finally getting around to at least thinking about Perlbots some more. Even though it's not a show-stopper, Tim Maletic's point (brought up during the presentation) about people being able to masquerade as Perlbots and spoil the game for others was bugging me. (As Tim mentioned this is sort of the opposite problem that we find with FPS games where a programmed bot can spoil the game for human players.) The potential solution that occurred to me was to have the server delay the "publishing" of the gamestate stream (which spectators would need to watch the game) by, say, 10 seconds. To do this, the server would need to keep a history of the gamestate - at least 10 seconds worth. The more I thought about it, the cooler this idea have saving gamestate history seemed since it would allow for the saving of entire matches and maybe even more advanced viewing features like spectator rewind and replay, instant replay, etc. I think it could probably be done entirely in memory for typical matches. Even if there are an average of 15 actors (where an "actor" is a bot, missile, etc.) in the arena throughout the game, and a new gamestate is saved every tenth of a second, and each actor requires 50 bytes of state per clocktick (pretty generous), and a game lasts 10 minutes (unlikely), that's only 4.5 megabytes of memory. Does anyone see any holes in this "delayed broadcast" idea? +Joel __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From matthew_heusser at mcgraw-hill.com Mon Apr 23 06:54:24 2001 From: matthew_heusser at mcgraw-hill.com (matthew_heusser@mcgraw-hill.com) Date: Wed Aug 4 00:01:13 2004 Subject: Tim's Point About Humans Masquerading as Perlbots - A Solution? Message-ID: <200104231203.f3NC3rg25458@gocho.pm.org> >Does anyone see any holes in this "delayed broadcast" idea? Why not just let humans play? My personal theory is that Human's aren't going to be able to perform the rapid responses needed to remain competitive with AI. So, why not code up some I/O, and go ahead and let user's -try-? I'll bet an intellegent bot wins every time. Matt H.