I first heard of DOOM on Usenet, when people would say “I can't wait to get rid of DOS, but I still need DOS to play DOOM.” Wait no longer. I first played DOOM a few days ago while running X on my Linux box.
I was rather skeptical. I play very few computer games, and not very often. When I do, they are usually games or clones of games like Minesweeper, Tetris, Mahjongg, Golddig, and those rare card games whose rules I am able to comprehend. I have never particularly enjoyed adventure games of any sort, until I played DOOM. Now my wife is worried I'm becoming addicted.
David Taylor (of Id, the company that wrote DOOM) recently completed a port of DOOM to X under Linux, and asked me to review it. I unpacked it (approximately 5MB worth), read the README.linux file (this is important if you have never played the game, because it explains how to move, shoot, and open doors, among other things), and played. And played. And played.
The first thing I noticed was incredibly smooth scrolling. And it's fast enough that I'm able to navigate well without feeling disoriented. I've seen other adventure games played under DOS and the scrolling has always been so rough that I could barely tell if the character was turning right or left.
The second thing I noticed was that although it is a shoot-'em-up game, it's not nearly as bloody as I had been lead to believe. Anyone who has seen video arcade games or the evening TV news should not be terribly bothered by the violence; you'll be too busy learning the floor plan and how to navigate to notice the blood, if I'm any judge.
DOOM is shareware. There are three adventures in the DOOM family; the first one is free, no strings attached, no guilt clauses telling you to register after 15 days or face legal action or moral rot. However, if you like the first adventure, there is a (reasonable) fee for purchasing the second and third adventures. I personally prefer this to guiltware (what Linus calls “limited-trialperiod shareware”).
My best recommendation for this product is that it is the first adventure game that has held my interest for more than a few minutes. My best recommendation against it is that you shouldn't start to play it if you don't have lots of spare time to devote to this game. You can blow away your friends by playing over the network. (I haven't tested this, but it's probably well done if it resembles the rest of the game.) Sound is supported if you have a sound card. I don't have one so I can't comment on the sound effects but I found the game perfectly playable with no sound.
A few tips (some of which are in the README.linux file, but you might miss them):
If the screen is too dark to see easily, use the F11 key to change the “gamma correction”. There are four levels of gamma correction; press F11 repeatedly to cycle through them until you find the one you like best.
Use a low-resolution video mode while playing DOOM. 640x480 looks good to me; DOOM uses a 320x200 window.
If you are using fvwm as your window manager, you may have kept some default key settings that move you around on the virtual desktop. Some of these keys may be used as movement keys and, because of the combinations you can have, almost any SHIFT-, CONTROL-, or ALT-ARROW key combination may be used in DOOM. You might consider an alternate .fvrmrc file which does not set up these keybindings.
Michael K. Johnson is the editor of Linux Journal, and is also the author of the Linux Kernel Hackers' Guide. He welcomes your comments.
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!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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