Thursday, December 31, 2009

An Inside Look At Warhammer Online's Server Setup

From Slashdot: http://games.slashdot.org/story/09/12/31/0428200/An-Inside-Look-At-Warhammer-Onlines-Server-Setup

An article at Gamasutra provides some details on the hardware Mythic uses to power Warhammer Online, courtesy of Chief Technical Officer Matt Shaw and Online Technical Director Andrew Mann. Quoting: "At any given time, approximately 2,000 servers are in operation, supporting the gameplay in WAR. Matt Shaw commented, 'What we call a server to the user, that main server is actually a cluster of a number of machines. Our Server Farm in Virginia, for example,' Mann said, 'has about 60 Dell Blade chassis running Warhammer Online — each hosting up to 16 servers. All in all, we have about 700 servers in operation at this location.' ... 'We use blade architecture heavily for Warhammer Online,' Mann noted. 'Almost every server that we deploy is a blade system. We don't use virtualization; our software is somewhat virtualized itself. We've always had the technology to run our game world across several pieces of hardware. It's application-layer clustering at a process level. Virtualization wouldn't gain us much because we already run very close to peak CPU usage on these systems.' ... The normalized server configuration — in use across all of the Mythic-managed facilities — features dual Quad-Core Intel Xeon processors running at 3 GHz with 8 GB of RAM."

Why Coder Pay Isn't Proportional To Productivity

From Slashdot: http://developers.slashdot.org/story/09/12/23/1820214/Why-Coder-Pay-Isnt-Proportional-To-Productivity

Why Coder Pay Isn't Proportional To Productivity
"John D. Cook takes a stab at explaining why programmers are not paid in proportion to their productivity. The basic problem, Cook explains, is that extreme programmer productivity may not be obvious. A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. And if a bricklayer were 10x more productive than his peers, this would be obvious too (it doesn't happen). But the best programmers do not write 10x as many lines of code; nor do they work 10x as many hours. Programmers are most effective when they avoid writing code. An über-programmer, Cook explains, is likely to be someone who stares quietly into space and then says 'Hmm. I think I've seen something like this before.'"

Wednesday, December 23, 2009

An Open Source Compiler From CUDA To X86-Multicore

From Slashdot:

An Open Source Compiler From CUDA To X86-Multicore


"An open source project, Ocelot, has recently released a just-in-time compiler for CUDA, allowing the same programs to be run on NVIDIA GPUs or x86 CPUs and providing an alternative to OpenCL. A description of the compiler was recently posted on the NVIDIA forums. The compiler works by translating GPU instructions to LLVM and then generating native code for any LLVM target. It has been validated against over 100 CUDA applications. All of the code is available under the New BSD license."

Monday, December 21, 2009

X11 Server Setting No Mouse, Try AllowEmptyInput

Upon setting up FreeBSD 7.2 from 6.4, I though that unrolling the tarball would do it. I did copy xorg.conf to /etc/X11, but no luck. I then read the error log (/var/log/Xorg.0.log). After a search on wiki.x.org, I did see a reference on to how to TURN OFF all keyboard and mouse input by adding to the Section "ServeFlags"

Option "AllowEmptyInput" "True"

I reversed it to

Option "AllowEmptyInput" "False"



tc

Tuesday, December 15, 2009

Fork Bomb

The bash fork() bomb
:(){ :|:& };:
This is a bash function. It gets called recursively (recursive function). This is most horrible code for any Unix / Linux box. It is often used by sys admin to test user processes limitations (Linux process limits can be configured via /etc/security/limits.conf and PAM).

Once a successful fork bomb has been activated in a system it may not be possible to resume normal operation without rebooting, as the only solution to a fork bomb is to destroy all instances of it.

Understanding :(){ :|:& };: fork() bomb code

:() - It is a function name. It accepts no arguments at all. Generally, bash function is defined as follows:

foo(){
arg1=$1
echo ''
#do_something on $arg argument
}

fork() bomb is defined as follows:

:(){
:|:&
};:

:|: - Next it call itself using programming technique called recursion and pipes the output to another call of the function ':'. The worst part is function get called two times to bomb your system.

& - Puts the function call in the background so child cannot die at all and start eating system resources.

; - Terminate the function definition

: - Call (run) the function aka set the fork() bomb.

Sunday, December 13, 2009

OpenDarwin has Shut Down!

When did this happen?   I am finally getting around to developing a mac app. I wanted to use SDL and they had a great ports collection apparently http://darwinports.opendarwin.org/ that is now GONE! Shit.

http://docs.huihoo.com/darwin/opendarwin/news/shutdown.html

OpenDarwin Shutting Down
2006.07.25
OpenDarwin was originally created with the goal of providing a development environment for building and developing Mac OS X sources as well as developing a standalone Darwin OS derivative. OpenDarwin was meant to be a development community and a proving ground for fixes and features for Mac OS X and Darwin, which could be picked up by Apple for inclusion in the canonical sources. OpenDarwin has failed to achieve its goals in 4 years of operation, and moves further from achieving these goals as time goes on. For this reason, OpenDarwin will be shutting down.
Over the past few years, OpenDarwin has become a mere hosting facility for Mac OS X related projects. The original notions of developing the Mac OS X and Darwin sources has not panned out. Availability of sources, interaction with Apple representatives, difficulty building and tracking sources, and a lack of interest from the community have all contributed to this. Administering a system to host other people's projects is not what the remaining OpenDarwin contributors had signed up for and have been doing this thankless task far longer than they expected. It is time for OpenDarwin to go dark.
Project admins for all active projects have been notified, and we will be working with them to provide as seamless a transition to their new homes as possible. We don't want to boot anyone off, we will be operating the machines as usual for several months, until everyone has had a chance to move elsewhere.
We will continue to provide email and dns redirection after the machines go dark. We'll be looking at what other redirection services are needed and can be provided after hosting has ceased.
The OpenDarwin team would like to thank everyone who did contribute to the project, and our apologies to active, loyal projects that have to move.
Thanks,
- OpenDarwin Core Team and Administrators