Slashdot Mirror

An anonymous reader shares a report from The New York Times: The Golden State Killer raped and murdered victims all across the state of California in an era before Google searches and social media, a time when the police relied on shoe leather, not cellphone records or big data. But it was technology that got him. The suspect, Joseph James DeAngelo, 72, was arrested by the police on Tuesday. Investigators accuse him of committing more than 50 rapes and 12 murders. Investigators used DNA from crime scenes and plugged that genetic profile into a commercial online genealogy database. They found distant relatives of Mr. DeAngelo's and traced their DNA to him.

"We found a person that was the right age and lived in this area -- and that was Mr. DeAngelo," said Steve Grippi, the assistant chief in the Sacramento district attorney's office. Investigators then obtained what Anne Marie Schubert, the Sacramento district attorney, called "abandoned" DNA samples from Mr. DeAngelo. "You leave your DNA in a place that is a public domain," she said. The test result confirmed the match to more than 10 murders in California. Ms. Schubert's office then obtained a second sample and came back with the same positive result, matching the full DNA profile. Representatives at 23andMe and other gene testing services denied on Thursday that they had been involved in identifying the killer.

According to Business Insider, "Facebook is closing around 200 of its 500 Oculus Rift virtual-reality demo stations at Best Buy locations across the U.S." The reason has to do with "store performance," as multiple Best Buy pop-ups told Business Insider that "it was common for them to go days without giving a single demonstration." From their report: Oculus spokeswoman Andrea Schubert confirmed the closings and said they were due to "seasonal changes." "We're making some seasonal changes and prioritizing demos at hundreds of Best Buy locations in larger markets," she said. "You can still request Rift demos at hundreds of Best Buy stores in the U.S. and Canada." "We still believe the best way to learn about VR is through a live demo," she continued. "We're going to find opportunities to do regular events and pop ups in retail locations and local communities throughout the year." Best Buy spokeswoman Carly Charlson said stores that no longer offer demos will continue to sell the Oculus Rift headset and accompanying touch controllers, which cost $600 and $200 respectively. Multiple "Oculus Ambassador" workers BI spoke with said that, at most, they would sell a few Oculus headsets per week during the holiday season, and that foot traffic to their pop-ups decreased drastically after Christmas. "There'd be some days where I wouldn't give a demo at all because people didn't want to," said one worker at a Best Buy in Texas who asked to remain anonymous. Another worker from California said that Oculus software bugs would often render his demo headsets unusable.

schwit1 writes with news that researchers at the Salk Institute have found that an experimental drug candidate aimed at combating Alzheimer's disease has a host of unexpected anti-aging effects in animals. Says the article: The Salk team expanded upon their previous development of a drug candidate, called J147, which takes a different tack by targeting Alzheimer's major risk factor–old age. In the new work, the team showed that the drug candidate worked well in a mouse model of aging not typically used in Alzheimer's research. When these mice were treated with J147, they had better memory and cognition, healthier blood vessels in the brain and other improved physiological features.

"Initially, the impetus was to test this drug in a novel animal model that was more similar to 99 percent of Alzheimer's cases," says Antonio Currais, the lead author and a member of Professor David Schubert's Cellular Neurobiology Laboratory at Salk. "We did not predict we'd see this sort of anti-aging effect, but J147 made old mice look like they were young, based upon a number of physiological parameters."

An anonymous reader writes "The FCC denied an appeal by Comcast, which argued that its practice of charging customers separately for a DTA (digital terminal adapter) -- a converter box that allows cable subscribers with older televisions to receive digital channels, which the company said would be provided at no charge -- is not subject to rate regulation, because it is a service fee. The ruling was issued on March 19." Also from the article: "In an e-mail last week to the Star Tribune, Comcast vice president of corporate affairs Mary Beth Schubert said the case “involved a relatively minor dispute about the way certain items are presented on the rate card but has no effect on overall pricing.” But, [Michael Bradley, an attorney whose firm represented Minneapolis-area franchising authorities in the dispute] argued the FCC’s decision sets a strong precedent for transparency within the cable industry."

Eloquence writes "Three years ago, Musopen raised nearly $70,000 to create public domain recordings of works by Beethoven, Brahms, Mozart, Schubert, and others. Now they're running a new campaign with a simple but ambitious objective: 'To preserve indefinitely and without question everything Chopin created. To release his music for free, both in 1080p video and 24 bit 192kHz audio. This is roughly 245 pieces.'" Adds project organizer aarondunn: "His music will be made available via an API powered by Musopen so anyone can come up with ways to explore and present Chopin's life."

jgoguen writes "Nagios, originally known as Netsaint, has been a long-time favourite for network and device monitoring due to its flexibility, ease of use, and efficiency. Nagios provided, and still provides today, a low-cost, versatile alternative to commercial network monitoring applications. Nagios 3 takes a huge step forward compared to Nagios 2, providing improved flexibility, ease of use and extensibility, all while also making significant performance enhancements. Due to its extensibility and ease of use, no device or situation has yet been found that cannot be monitored using Nagios and a pre-made or custom script, plug-in or enhancement." Read on for the rest of jgoguen's review. Nagios 3: Enterprise Network Monitoring author Max Schubert, Derrick Bennett, Jonathan Gines, Andrew Hay, John Strand pages 339 publisher Syngress rating 8 reviewer jgoguen ISBN 978-1-59749-267-6 summary Making Nagios 3 work for you and your business. The first chapter is devoted to new features in Nagios 3. The major changes implemented for Nagios 3, which includes changes to data storage options and locations, checks, configuration objects, and macros, are discussed here. Operational, performance, and usability enhancements are also discussed here. Users upgrading from Nagios 2, or users who may already be familiar with Nagios 2, will gain the most from this chapter. New users will still gain value from this chapter, however, since a number of changes also involve some of the major features of Nagios. In addition, users who may be referring to configuration file samples created for Nagios 2 will save a great deal of time referring to this chapter for changes. Using Nagios 2 configuration files directly prevents users from enjoying some new features of Nagios 3. Users who will only be writing plug-ins and scripts for their local Nagios deployment might not find Chapter 1 very useful.

Chapters 2 and 3 deal with scaling Nagios to work efficiently within large deployments. First, designing a Nagios configuration for large organizations is shown. This is something that all Nagios administrators should make use of when designing configurations, not only administrators in large organizations, because a properly done configuration for a small organization will easily scale up as the organization grows. I was impressed to see that the authors stress the importance of the end user's input when designing configurations. Administrators who ignore this piece of advice risk the success of Nagios in their organization. Various diagrams help to explain the relationships between the various Nagios configuration objects. A good amount of detail is provided regarding allowing various groups within an organization to have semi-independent control over how Nagios interacts with their hosts and services, and how Nagios alerts their staff. The authors have included numerous configuration file snippets, which allows a Nagios administrator to very quickly create a configuration file and then tweak the configuration parameters to suit local requirements.

Scaling the Nagios graphical user interface (GUI) follows a very simple concept: use a "less is more" approach. Although the specific details here deal with Nagios, the general idea is equally applicable to anyone displaying information they expect their users to actually pay attention to. In general, users should be able to see as much as they want (limited by resources and permissions) but only be shown what they need to know about by default. For example, the system administrator for marketing probably does not need to know when the development disk image server goes down, while the development system administrator would probably be very interested. Utilizing user accounts allows the administrator to allow various groups to have access to Nagios filtered by its fine-grained permissions system. Users from various groups can also be shown only what they need to be shown by default, without the need to select a particular area first. Utilizing user accounts also prevents users who need to view Nagios from having full administrative control, and allows for records of each user's actions to be made. Using a patch provided with the book's download package will enable Nagios to have read-only accounts as well, which is great for organizations who would like to grant certain users (or groups) access to view Nagios but not make any changes. As an example, an organization's help desk could use Nagios to determine quickly whether users are unable to access services because of an outage, or if further troubleshooting is necessary.

The authors continue on here to discuss clustering, failover, and the future of the Nagios GUI. I'm not convinced that these belong in a chapter devoted to scaling the Nagios GUI, since these seem to mostly deal with scaling the entire Nagios deployment. Regardless, they are all very important topics, especially when Nagios is heavily relied upon. Clustering allows remote sites to have a Nagios instance local to the site monitoring hosts and devices rather than requiring a central Nagios instance to monitor remote hosts and services. Not only would monitoring hosts and services take much longer due to the WAN links between the central instance and remote locations, but also due to the security implications of allowing the checks to be done. The authors don't discuss the security side of clustering, but it's still something that every Nagios administrator (and everyone else!) should keep in mind. The clustering section deals primarily with the rationale behind clustering and how to configure the local and remote instances of Nagios properly, but the authors include a good deal of information here that a less experienced Nagios administrator might overlook. Most notable is their discussion about the display of service status when a service is reachable from the master server but not from a remote instance. While Nagios can translate the remote instance's check result to be displayed from its own perspective, it may be more desirable to have the master Nagios GUI display the results from the perspective of the server which made the check. After implementing clustering, some sort of fallback mechanism is required. Failover and redundancy are the two main choices, and that's what the authors discuss next. They don't spend much time on redundancy, since this would require each redundant Nagios instance to perform its own set of checks, which can significantly raise the load on both the monitored hosts and the network in general. Given the problems it can introduce, the authors have spent more time on redundancy than most administrators should spend considering. Failover is a much better solution, and the authors do a great job of covering the setup of a proper failover setup. As usual, they make sure to remind readers of some things that are easily overlooked, especially when you're trying to get Nagios back up and running when the master server crashes.

Chapters 4 and 5 discuss Nagios plug-ins, add-ons, and enhancements. These chapters alone are worth the price of the book because of how much time they can save. It's much faster to copy a script and make minor tweaks than it is to try reinventing the wheel, and with the number of scenarios covered here combined with the Nagios user community there aren't very many things that haven't been done already. Whether you want to test command-line interfaces, CPU usage, memory utilization, bandwidth utilization, HTML pages, LDAP services, or even specialized hardware, there's probably already a plug-in written for it. Most common scenarios actually have a plug-in already included in this book. The available add-ons and plug-ins are equally varied, providing ways to monitor hosts across security zones, configure read-only displays that live in a security zone other than the one Nagios is in, interface with Cacti, and even read out alerts. Even more scenarios can be handled by other scripts provided by the Nagios community.

Chapter 6 goes into detail on how to integrate Nagios into an enterprise environment. This chapter goes into just enough detail to get Nagios configured to work with a large number of third-party services, such as LDAP authentication, Cacti, Puppet, and Splunk. Emphasis here is always placed on the human element; how to use Nagios to help help desk and/or NOC staff do their jobs more efficiently and effectively, and how to gain maximum support for Nagios within the organization. The importance of the human element, in all its forms, simply cannot be overstated, and the the authors have done a wonderful job of outlining a good way to make Nagios an integral part of an organization. A lot of the material towards the end of the chapter, especially the section on smaller Network Operation Centres, could be used by anyone looking for ways to help a small group work together effectively.

Chapter 7 is another chapter with a lot of content easily applicable outside of a Nagios environment. The chapter begins with the authors reminding you to know your network and to watch out for session hijack attacks, then show you how to use Nagios to do both. Nagios can't replace a competent network administrator, but it can make their lives easier and the authors show you here how the configuration you've already done on Nagios already shows you a potential session hijack attack and how it forces you to properly know your network. Nagios forces you to know your network not only by how it's built and by what devices are in use, but it also requires that you have a solid handle on what constitutes normal conditions for all your devices and services.

Another area which is very important to companies, especially companies operating in the United States, that Nagios can assist with is regulatory compliance. The authors outline how a company could use Nagios to assist with compliance with Sarbanes-Oxley (SOX) with COBIT or COSO, Payment Card Industry (PCI) Data Security Standard (DSS), Director of Central Intelligence Directive (DCID) 6/3 and Department of Defence (DoD) Information Assurance Certification and Accreditation Process (DIACAP). Nagios alone isn't enough to be compliant, at the very least detailed documentation will also be required, but the authors give a good overview of how Nagios can assist with compliance in all of these regulations.

The final chapter helps to bring the rest of the book together by walking through a full Nagios configuration for a fictional Fortune 500 corporation. The bulk of this chapter covers the pre-deployment stage of a Nagios deployment, but that doesn't mean that there isn't a lot to learn about deploying Nagios. A major hurdle towards deploying Nagios in an organization is the pre-deployment phase, and the authors outline here how to easily turn this major challenge into a series of simple steps to increase the chances of Nagios' success in your organization. From the very beginning, you can see how involving the customer early and starting small, along with everything else, becomes a part of a process. Although it's specific to Nagios, the process followed here could be easily adapted to integrating any sort of monitoring service. The remainder of the chapter is devoted to how you might integrate Nagios into a Fortune 500 company, finishing the book off with some good advice for integrating Nagios.

Despite all the book's strengths, there is some room for improvement. In chapter 2, it may have been more effective to outline the relationships between the Nagios configuration objects before discussing configuration planning. I found it much easier to think of a configuration for a large organization after knowing about how Nagios' configuration objects relate to each other.

Throughout the book, the authors have included configuration file snippets, scripts, and example script output in the main text. While all of these are quite useful and serve to enhance the book, I think it would have been better if these were all included in an appendix instead, perhaps keeping only the relevant parts of configuration snippets in the main text for clarification.

At the end of chapter 3, the sections on the future of Nagios and the CGI front end are informational and interesting, but they would be better placed in a separate chapter dealing with the potential future of Nagios in general. These and the other major areas of Nagios combined would provide more than enough material for a full chapter on their collective futures.

Overall, this is a great book for anyone using Nagios as more than a casual user, and is still very informative for the casual user. A few of these chapters alone would be worth the price of the whole book.

Disclaimer: I worked with one author when I was asked to review this book.

You can purchase Nagios 3: Enterprise Network Monitoring from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

The fundamentals of game design for Massively Multiplayer Online Games are beginning to become fairly well known in game development. Just the same, there is still a lot of argument about what is and is not a 'good call' when it comes to adding features to a massive service. The way to go about making those choices, and a good deal of attention to the concept of a game as a service, was laid out by Damion Schubert in his talk at GDC Austin on Thursday entitled 'The Zen of Online Game Design'. Damion Schubert is currently working at Bioware, but is known well for his work on UO, Shadowbane, and other titles. He's a very recognizable name in MMOG development circles, and maintains a blog discussing many of the issues covered in his talk at the website Zen of Design.

His talk surrounded the three experimental models for MMOGs he's had whirling around in his head for years. It also touched on general stray thoughts on the genre. They were based on his experiences, and his goal for the talk was to 'open source' his thoughts so that others could comment and amend them. The source of the name of both his website, and the talk, stems from an appreciation of Zen thinking. "True understanding is only possible via experience."

Many discussions of MMOGs go down unhealthy paths. Some view game design as 'Ant Farming'. These folks see game worlds as closed environment where they can do academic studies, looking from the outside in. "What happens if I poke a stick at it?" Some view it as 'Bean Counting'. Players are little more than walking wallets to these groups. "Let's pick up and shake our customers and see if they drop any loose change!" Then, there are the 'Crime and Punishment' types. These developers don't so much care about making money or learning, they just want revenge on the players. "My job became easier once I discovered I hated my players."

These approaches miss the point: MMOG design is about making fun. Massive games compete with movies, bars, television; you have to remember that you need to make a fun place to escape. In order to do that, it's imperative that you understand how players are approaching your product.

This brings us naturally to cupholders. The 70s was the origin of the window-clip cupholder, and it was a terrible design. But it was necessary because of the increasing suburbanization of society. Many auto designers now feel that the cupholder is a major purchasing decision in an car. The customer will have a long-term relationship with the car, and they need to know that they'll 'fit' into the car. The first thing a veteran car-buyer will do is just sit in the car, to see how it 'feels'. They know not to buy a car with the 'stereo blocker' style of cupholder, and aren't going to be fooled by poor design. You have to design a product from the customer's point of view.

The concept of long-term relationships is key. MMOG designers are in the same boat as car manufacturers. People approach a MMOG as the place where they'll be spending tens or hundreds of hours in a world. This is very unlike standalone, play-once games. Gears of War is a Playboy Bunny. World of Warcraft is the girl next door. You're looking for a little bit of sizzle, but you're looking for a lot of potential. You want to see bigger and better things coming down the line, where the game will go.

They also look for flaws. If they see a flaw in the first ten minutes, they'll extrapolate that out to have hundreds or thousands of flaws. Bug counts in released games are now actually quite low. That assumption is usually false. Just the same, designers aren't paying enough attention to first impressions. Damion asked the crowd, "What's the first thing you do when you get into a game?" The answer, of course, is: walk, and then jump. If you walk and jump - and it doesn't feel right - you're already put off. "They can't even get the first thing I do right?"

A helpful visualization appeared on the screen: a straight line, with an arrowhead on the far right side. The player's lifeline is simple: a player will keep playing until she quits. You can look for exit points, points in the game that would cause the player to quite, and you can try to avoid those. As an example, every time your credit card is charged, that's an exit point. Some are outside of your control as a designer. (Billy discovers girls.) Just the same, a lot of them are in the designer's hands. Some examples include: The Brick Wall - You realize it takes four times as long to go from 29 to 30. The Pimpslap - you spend 6 hours on a quest only to fail and have to start over. The End of Fun - you're 'done', you've hit max level, you've raided all the content. The Sudden Realization - I killed 2500 elementals to make this hammer, and now I'm going to replace it. All of these can make a player want to leave a game.

The three Rs, then, are required to keep the game moving forward. Recruitment, means new people into the game. Retaining, means keeping them there once they're in the game. And Reduction of costs and services. Of these, retention is the most cost-effective of the three.

Which brings us to the hardcore. Damion was strongly of the opinion that the word hardcore is overused and misused in the game industry. Mostly it comes from producers. It used to be that hardcore gamers were good; Quake 2 was all about the hardcore, for example, but now more games are aimed at the mass market. The producer asks, "Why can't you make this game for my grandma?" Hardcore is a relative measurement. It's not about whether you're hardcore gamer, it's whether you're hardcore to a genre, an idea, and then to a game. One game's hardcore market is not another games' hardcore market. It's a measure of investment. It's a measure of how invested they are in your game. People invested in your space can only be a good thing; invested people keep playing. Designers actually want to make people more hardcore.

Hardcore is not a binary thing. It's a sliding scale, and the goal of designers should be to nudge players down that path. A slide revealed Damion's mental model of investment: starting at casual, a player moves through the interested phase, to committed, to devoted, and to finally hardcore. The further you are down the chain, the more time it takes to get rewarded by the game. A casual gamer might be rewarded in seconds, and a committed player might wait hours for his reward, but hardcore players can wait for weeks between payoffs. Even if your game doesn't apply to the general model, Damion encouraged the designers in the room to try to slot the chart onto their game. What's the committed guy doing vs. the casual guys, vs. the hardcore? The big question: are there any gaps? If you ask someone to jump a level of commitment, that's hard to do.

Designers want to create investment in the game by making people move up the commitment ladder. Not everyone should be hardcore, but communities full of people are at their most interesting. The ladder should be as smooth as humanly possible. Mapping that back onto the lifeline, it is harder for a hardcore player to jump through an exit point than a casual player.

People aren't as hardcore as they think they are, and no one is hardcore on their first log in. With that said, why are hardcore players all that important? Hardcore player are the rockstars. People know who are in the top three guilds on their WoW server. These players provide aspirational models for more casual players. Seeing fully decked out players is not daunting, it's uplifting. It motivates you for future successes. Hardcore players are also evangelizers. They pass the word on to the more casual folks, and get them interested. Ala 'the tipping point', key influencers can make or break a game.

Your game is too hardcore if your hardcore players are ashamed to be playing it. That's not healthy. Also: don't build up your hardcore players in those terms. That terminology ends up being exclusionary. It's dangerous to make a martini bar. You probably want more to be the corner pub.

Damion paused before going on to a topic he obviously felt very strongly about: As a game designer of a massively multiplayer game, you MUST control your game's culture. It's important to try to keep the culture of your game as clean as possible. As much of a losing battle as it can be, it's extremely important that you try to keep the misogynists out. Damion quipped, "Never underestimate the damage a charismatic idiot can do." Keep the gamespace civil, for the sake of everyone from casual to hardcore. People take social cues from behavior around them. Compare the behavior exhibited in the Stanford prison experiments vs. the socially conscious culture at Burning Man.

On the concept of forming you culture, Damion noted that it's perfectly reasonable to apply that to gameplay as well. Matchmaking in-game is a great idea. Being in a raiding group is like being married to 50 people. Guilds are very ad hoc in most games. How much stickier would your game be if you could easily find a group with similar goals and mores? If you can get those people together, how much more powerful would the game be?

Damion then went on to his answer to the great game/world debate. The answer is something that's been in his head for 10 years. It's not new, but it's not finished. Both games and worlds have pros and cons. Worlds offer realism, simulation, immersion, and freedom. Games offer balance, limitations, powerups, and fun. Just as with the casual/hardcore dichotomy, it's important to understand that game/world is a sliding scale. No game is entirely game, and no game is entirely world. Damion then notes that there is a third leg to the scale, and that's community. They are MASSIVELY MULTIPLAYER games.

Into the mix, community adds socialization, cooperation, competition, and interdependence. Any MMOG can be plotted on the triangle. The ideal, the sweet spot, is in the middle. If you're not there the community will move you in that direction, because that's what the vast majority of players are looking for. Quake was in the bottom part of the triangle (dead between world and game, but removed from community) when it launched, and the players moved it towards the center. Players created the concept of capture the flag all on their own, to encourage community. UO was in the lower left hand corner (very world-oriented), and community moved them towards the center with elements like beauty pageants. Early UO players even had the 'rule' that they'd recreate characters with guild tags in their names, because there was no other way to facilitate that at the time.

As a game designer, your goal should be to build a well-centered game. You want to aim for the middle of the triangle. You can turn the triangle into the 'rule of three': systems should strive to be good for at least two of the three aspects of the game. If you have a question about whether a feature is a good idea, just run it past the rule of three. For example: "Permadeath" - World says yes, it's realistic. Game says no, as it's not fun. Community says no, as it makes it hard to track friends whose characters are deleted. "Voice chat" - World says no, as it breaks immersion. Game says yes, as it makes it possible for more tactical combats to be run. Community says yes, as it's easier to communicate with friends. It's also a tool that can be used to turn a bad feature into a good one. For example, long travel times are often seen as a negative by players. The rule of three would tend to agree. World says yes, because it's immersive, but both Game and Community say no: it's not fun, and it takes longer to get to friends. What if the game were to add a profession with the ability to teleport players? Game still says no: long travel times is unfun. World still says yes, because long travel is immersive. Community, though, swaps to a yes; having to talk with someone to get teleported is an inherently social activity.

With that, Damion wrapped up the talk to enthusiastic applause.

alphadogg writes "Neil Schubert is only partly kidding when he calls Marriott International's move toward a converged network a horror story. 'I'm here to tell you a terrifying tale of network design, support and administration,' he said at an IT conference in Boston, referring to a major bandwidth crunch caused by guests wielding Slingboxes and other network devices that overran the hotel chain's outdated network. 'One of the things we've learned about our guest networks is we have one of the most foreign, hostile environments known to man in the network administration world ... I can take 100,000 customers a night on that infrastructure and we actually have less incidents of harm than we do on our corporate back-office infrastructure.'"

sporkme writes "A new nanocoating material developed by a team of researchers from Rensselaer Polytechnic Institute has the lowest level of reflectivity ever seen ... or not seen in this case. The amount of light reflected by the composite of silica nanorods and aluminum nitride is almost the same amount reflected by air. From the article: 'Schubert and his coworkers have created a material with a refractive index of 1.05, which is extremely close to the refractive index of air and the lowest ever reported. Window glass, for comparison, has a refractive index of about 1.45. Using a technique called oblique angle deposition, the researchers deposited silica nanorods at an angle of precisely 45 degrees on top of a thin film of aluminum nitride, which is a semiconducting material used in advanced light-emitting diodes (LEDs). From the side, the films look much like the cross section of a piece of lawn turf with the blades slightly flattened.' Suggested applications include increased efficiency in solar cells, more energy-efficient lighting and advances in quantum mechanics."

This year's AGC is now at an end, and several sites have coverage of the last day's events. The hit event for the day seemed to be Damion Schubert's Moving Beyond Men in Tights talk. MMORPG.com has a slew of interesting articles, covering Emerging PR Strategies for MMOGs, Running Your Own MMOG, and Rich Vogel on MMOG Betas. Raph has a liveblog on a session about Virtual Economies, and finally the 3pointD site has a look at a panel on Virtual Worlds. Interesting stuff. From the 'Men in Tights' writeup: "The queston to answer, why do we keep making grindtastic classbased combat oriented men in tights gamey games? I'm not going to answer 'because it sells' because it's a circular argument and a copout. We won't get anywhere if we only do what was done before. Instead, I'll ask why do we need a grind, why do games appear to be winning, why are classes good, and so on. The reason to tackle this is because whenever people decide to make a new game, these are often the first five things people choose to innovate on. But there's a lot of bad innovation from people trying to solve these five problems."

An anonymous reader writes "The buzz in the MMO blogosphere is yet another resurrection of the Class system vs. Skill system debate. A number of prominent online gaming bloggers have chimed in with their opinions on the subject, including: Scott Jennings, Raph Koster, Ryan Shwayder, Steve Danuser, Damion Schubert, and a host of others you can find linked on those blogs. The conclusion? Most of the devs favor class systems because of their simplicity and ease of communicating character roles, while a few devs and many players favor skill-based systems because of the freedom they provide for user customization."

eToyChest is reporting that many of the developers are Wolfpack Studios, closed since May 15th, have banded together to keep Shadowbane running for the players. Now known as 'Stray Bullet Studios', they'll be running the game for Ubisoft while they work on a new MMO for the 'next generation'. Via his Zen of Design blog, it appears Damion Schubert will not be among the Shadowbane handlers.

Gamsutra has a writeup of a recent Austin Game Developers meeting. Damion Schubert, Allen Varney, and Scott Jennings took the stage to discuss games as art and Roger Ebert's opinions. From the article: "McShaffry then asked the panel to consider whether Ebert was picking on youth culture in general, and assuming technology wasn't an issue, whether popular games like Grand Theft Auto would be played 500 years from now, like the works of Shakespeare are enjoyed today? Jennings didn't want to speculate that far into the future, but he admitted to still playing and liking the Final Fantasy games released for the Super Nintendo."

The yearly Austin Games Conference, the largest MMOG-focused industry event in the country, is taking place this weekend and a variety of places have coverage of the first day. For specific events, we have Gamasutra on MMOG economics and The Game Writer's Conference, a sister event to the AGC. Both Raph Koster (who has a blog now) and Next Generation have pieces on Damion Schubert's "What Vegas Can Teach the MMO" talk. For general color, Greg Costikyan has a feel for what it is like on the ground, and MMORPG.com has a Thursday wrapup. From the MMORPG.com piece: "The Austin Game Conference (AGC) looks and feels like a high school reunion. Dominated by the MMORPG industry, it allows developers to get together and compare their ideological toys. Unlike E3, this is not a commercial event. For example, EA's booth here is actually a booth, rather than some kind of football stadium. This allows for more of a community feel and serious discussion of issues facing the game industry without the need for marketing individual products to any great degree."

MMOG Designer and commentator Damion Schubert has up an article on the constantly renewing Permadeath debate. Permadeath is the concept of permanent death for a character in a Massively Multiplayer Online Roleplaying Game. The design hasn't shown up in any major commercial games yet but, to borrow a phrase, the soul still burns. His commentary is a great synopsis of the debate, from the rearing of its head to the final bitter back-biting threads. From the article: "3. Captain Obvious Speaks. 'People don't like to lose their stuff.' 'It isn't fun.' 'It's hardcore, and only hardcore games will ever use it.' 'Any game which depends on the internet for its reliability has no place permanently taking away all your stuff.' 'Why in God's name would anyone consider this idea a good or compelling idea?'"

An anonymous reader writes "The Corporation recently posted a four-part series asking a few well known MMOG developers their opinions of the past year in the genre. Participants include Richard Garriott, creator of the Ultima series and Tabula Rasa, Walter Yarbrough, Content Producer for Dark Ages of Camelot, Damion Schubert, former Lead Designer for Meridian59, the cancelled UO2, and presently the Lead Designer for Shadowbane, and Raph Koster, former Lead Designer for Ultima Online and Star Wars Galaxies, and present Creative Director for Sony Online Entertainment."

Andreas writes "Professor Schubert says he has found a way to raise the efficiency of LEDs to 99%. From an article on Advanced Technology: "Until now, all lighting systems, especially incandescent bulbs, generated more heat than light. But our 99-percent efficient reflectors for LEDs makes them the first candidate for light-bulb replacement that generates more light than heat," said Schubert."

Dan writes "Simon Schubert has offered to provide Daily Snapshots of DragonFly. The snapshots are available on FTP and HTTP. Simon says this is for users who want to give DragonFlyBSD a try and don't want to go through the FreeBSD4/cvsup/buildworld steps., and as a world tinderbox (logs are available for each run). DragonFly is an operating system and environment designed to be the logical continuation of the FreeBSD-4.x OS series. These operating systems belong in the same class as Linux in that they are based on UNIX ideals and APIs. DragonFly is a fork in the path, so to speak, giving the BSD base an opportunity to grow in an entirely new direction from the one taken in the FreeBSD-5 series."