Novice to Novice
I have to start this month's article with an apology. The original introduction focused on Unix as a mature operating system but one that lacked maturity in the area of entertainment. After a week of exploring the variety of Unix games, I realized my mistake. Unix games may not be as profitable or numerous as DOS games but they have been tremendously influential, and that needs mention.
The first popular games started on the mainframes. “Adventure” spawned “Zork”, which spawned the adventure game industry. On the strategy side, I believe Empire was translated from the mainframe. Mac and MS-DOS versions met with great success. Empire also influenced the strategy genre by combining a “conquer an unknown world” motif with multi-player capability, an influence that, in part, resulted in Warlords II, one of my favorite strategy games. Even today, Unix is still a major influence on the gaming world, via the Internet, through Multi-User Dungeons (MUDs). These interactive sessions began the requirement now for many non-Unix games, that they allow for multiple players over a modem or network. Many on-line services are now offering multi-player versions of the most popular MS-DOS games.
Novice to Novice will take a little recreational detour this month and explore a variety of games that may come with Linux disks or CDs. In my case, Slackware Professional 2.1. The eventual goal of this article will be to get DOOM running and use a Sound Blaster 16 because DOOM without the gruesome sounds of unbridled carnage just isn't right.
Slackware allows you to install two sets of games. One set, “Y”, contains the BSD games collection and a Tetris clone. The other set, “XAP”, contains X-Windows applications and includes some games like GNU chess and xboard (which allows you to run the ASCII GNU chess in X).
I loaded the BSD collection and soon after removed it, with one exception: Mille, a clone of Parker Brothers' popular card game Mille Borne. The binary found on the main Slackware disk had a bug that occurred when the game was extended. Sometimes there'd be an annoying buzzing lockup. However, I found a version on the tsx-11 archive disk that ran smoother. Very addictive!
There are more games than the BSD compilation available. If you snoop around on any of the archive CDs you're bound to find gold. When I found something of interest, I would copy it over to /usr/local/games. It seemed like an appropriate spot to put things. [/usr/games is for games that are installed by the system; /usr/local/games is a good choice for user-installed games —ED]
The Sunsite disk had a plethora of games conveniently divided into general categories like action, strategy, X11, and RPG (role-playing games) which was a major stopping point for me. The names sounded familiar. Some of the games like Rogue, Moria, and (Net-) Hack have been successfully translated to DOS, and in at least one case, given a major facelift. For example, SSI's Dungeon Hack is directly evolved from Hack but redone with SuperVGA graphics and a variety of other additions.
For the heck of it, I copied over Rogue. Any game with a name like my favorite comic book heroine automatically gets special consideration. The version I copied was 5.3pl2. Besides the source code, the archive had a precompiled binary, which I appreciated, but when I ran it, it crashed: “missing library”. Fine. I compiled the source cleanly and ran the new binary. It ran for a few keystrokes before stopping from “segmentation faults”. Sigh! I dismissed Rogue and looked for other entertainment.
I found something called Omega (version 0.78.1) on the TSX-11 CD that I thought would be like the DOS tank programming game of the same name; instead, it was another Hack clone. This one, unlike Rogue, ran well and my wife had to drag me away after a half hour of playing. It's easy to forget that you don't always need snazzy graphics to produce a deep game. ASCII role-playing games like this amaze me with their detail. Sure, you can add graphics, but then that 500K game explodes into multi-megabytes of size. Also, a keyboard interface can allow you a greater variety of options, which Omega has, than a mouse-based interface cluttering up a graphics screen. The problem is simply remembering the overwhelming number of commands, but a printout of the help file solves that easily enough.
Chess! I've always loved chess, not just the game but the lore and history around it. Since I had installed GNUchess and xboard, well, how about a game of chess? I ran GNUchess straight up and got the ASCII board, moved a few pieces, and lost. Admittedly my chess rating, if I had one, would be somewhere in the low hundreds. But GNUchess worked! Now for the X-Windows interface. I activated my swapfile, entered X-Windows, called up an Xterm shell, and typed in xboard. Quickly a rather pretty chess board appeared. Quickly my hard drive started whirring. I made my first move and the opponent's clock started its countdown from 5 minutes. The hard disk continued to go berserk for 2.5 minutes before I destroyed it out of mercy. This long amount of time for the first move was unacceptable. Perhaps it was the swapfile. I exited X-Windows, shut off the swap, and tried xboard again. This time the board appeared along with an error message about “GNUchessx exited unexpectedly”. Sigh! So much for chess. [Adding more swap would have solved the problem with xboard. —ED]
I discovered Empire (Chainsaw version 3.12) under “strategy” and debated compiling it. The README mentioned that it would require TCP/IP among other things. Sure Linux has that and more, but I backed down from compiling. I wasn't hooked up to any network; I just wanted to see what one of these games looked like without having to compile anything. Luckily, I found Conquest (5.5.1a) which, after copying to / and unarchiving, produced an executable game with little modification necessary. Running X-Windows and calling up Xterm, I typed:
xset +fp /usr/X386/lib/X11/fonts/misc/xconq xset fp rehash
to set some appropriate paths; entering xconq produced a large window showing a very complex game. No help file was immediately available from within the game so, after moving a few pieces, I exited. Besides, it was a network game so I really couldn't have gotten the full experience from it, playing alone.
A strong case for Unix games is that for many you get the source code. If the game is too easy or too hard, or needs a wandering wizard—rewrite it! The only answer to this from the DOS side of things is the occasional release of construction sets. Generally, however, these sets do not allow you to change all aspects of a game, just what the designers will allow you to change. That's not quite like having the source code. The negative side is having the source code and not having it compile cleanly. To an expert hacker, this presents no obstacle—dive into the code and make corrections, but for novices, it's agony. That's why, when some of the above games crashed, I moved on. And on that line of thought...
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Returning Values from Bash Functions
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide