Virus enthusiasts might enjoy this game, first developed by the well-known computer scientist and author A.K. Dewdney in the early 1980s as discussed in Scientific American. In Core War (or Core Wars, as you like), two or more assembly code programs battle against each other in memory with the purpose of killing off all the enemies' processes by forcing them to execute a certain command. The assembly code is called Redcode, which is rather simple yet wholly adequate, and the virtual computer which runs the cores is called MARS (Memory Array Redcode Simulator). Memory arrays can range from tiny to enormous, and several cores can battle at a given time.
Like many pursuits, learning to play is simple, while strategies quickly become clever and complex. I spent a great part of my thirteenth year of life on this game, carrying a calculator with me to work out algorithms, so be warned—it can become an obsession. Also, it's good for young people, an easy way to teach assembly code to kids (well, you can't let them grow up without knowing asm, can you?).
The standards of Redcode have changed significantly since the 1980s (the initial version ultimately became rather exhausted) and now allow for much more complex programs, although the basic strategies remain the same. There are on-line tournaments running all the time, so you can try your cores against the world's best. A while ago, a friend found some of our old cores on a disk (which should tell you how old they are) and I tried them against the net-warriors—our cores got terminated, so it appears the standards have improved. Assembly-code devotees should do very well at this game.
If robots inspire your fancy more than viruses, RealTimeBattle by Erik Ouchterlony and Ragnar Ouchterlony may be more to your liking. Essentially, you program a robot to battle other robots in real time. One thing that distinguishes it from many programming games is that you can use any language you like to program your robots, since they communicate to the server through STDIN and STDOUT. The use of real languages allows for more legitimate intelligence in the machinery.
Robots are physically identical and have energy, scanners, cannons and movement devices. The world in which they operate has gravity, friction, air resistance, bouncing, skidding and the like. Combat arenas can be large and open or filled with walls, and can accommodate up to 120 simultaneous robots.
Though already entirely playable, this software is in a state of continual development. Already I can see many possibilities for this one, such as an on-line server, massive multi-level maze-like arenas and so on. Anyone who remembers games like Crobots on the Amiga or RobotBattle on the unmentionable OS will probably find this game quite an improvement.
There comes a time in everyone's life when a squadron of robots isn't enough. You want an army of robots, designed and programmed by you. Fine, with Automata Zero, you can have them—literally an army. And, you not only design and program the robots, you can program them to respond to real-time commands from your terminal, and you can change code on the fly. Automata Zero's graphics are much more advanced than those of Core Wars or RealTimeBattle and feature aesthetic landscapes with grass, water, trees and futuristic mechanical structures. The robots themselves look like Mechs. The development team says graphics are a low priority, but that's hard to believe when they look so nice. Zed is the name of the programming language, which doesn't feature dynamic memory allocation, floating-point operations, threads or pointers, but does have arrays, functions and scoped variables; it is a fairly simple mixture of C, BASIC and Matlab. Automata Zero is still under development and needs more developers. You can visit Automata Zero's home page at http://www.andrew.cmu.edu/~sand/ to learn how to contribute or just play the game. It's a little closer to your typical strategic conquest-of-the-world game than the others. Presumably, if you lose, the world will be overrun with enemy robots who will come to your basement and blow you up, along with whatever soda pop you may be harboring. Good luck! (May the bitstream be with you?)
Six months ago, Red Hat was a “free” software company that lost money on less than $11 million in sales in its last fiscal year. By late summer, it was worth upwards of $7 billion US. (Perspective: the gross domestic product of Laos is less than $6 billion US, according to the World Factbook.)
Don't waste your time wondering if Red Hat's valuation is “real” or deserved. We're talking about a real market here: the market for shares of a company. If that market says the smallest piece of Red Hat is worth exactly $100, well, it is. Multiply that by all 66,835,105 equal-sized pieces of Red Hat, and you've got a company that's worth exactly $6,683,510,400 US. That's the obvious part.
What's not so obvious is that only 6,000,000 of those shares were put on the market in Red Hat's IPO (initial public offering) in August. That's less than 10% of all the stock issues by the company. The rest were not released to the market. When there's a lot of demand and highly constrained supply, the price goes up. And with that price goes the value of all the company's shares. Neat, huh?
Now think about all the other Linux-related IPOs that should be coming up. We learned about Cobalt Networks and Andover.net in September, when there were also rumors about Caldera and VA Linux Systems. If these companies do even half as well as Red Hat, think of what that will do for the value of every Linux business.
Welcome to the New World!
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Have you tried Boxen? It's a
2 hours 22 min ago
- seo services in india
6 hours 53 min ago
- For KDE install kio-mtp
6 hours 54 min ago
- Evernote is much more...
8 hours 54 min ago
- Reply to comment | Linux Journal
17 hours 40 min ago
- Dynamic DNS
18 hours 14 min ago
- Reply to comment | Linux Journal
19 hours 12 min ago
- Reply to comment | Linux Journal
20 hours 2 min ago
- Not free anymore
1 day 4 min ago
1 day 3 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?