SciTech Display Doctor 1.0
Manufacturer: SciTech, Inc.
Price: $39.95 US
Reviewer: James Youngman
SciTech has been selling their product for DOS and Windows for some time now. It is used mainly for installing VESA display services for graphics adapters. This is not an issue for Linux, since Linux programs never need to call the video BIOS.
Display Doctor 1.0 for Linux achieves a goal even more useful than the DOS product; it uses SciTech's driver technology to provide drivers for video cards not supported by XFree86. This includes cards from those manufacturers who will not release the information required in order to allow XFree86 drivers to be written.
This review will cover the Preview Release of SciTech Display Doctor 1.0 for Linux. You can download the trial version from SciTech's web site (http://www.scitechsoft.com/).
Display Doctor can be installed on any glibc2 system which already has XFree86 (3.3.2), GPM, and Tcl/Tk (7.4 or higher) installed. These requirements match one of the machines on which I run Linux. The preview is available as both a compressed tar file and as an RPM package. I chose to install the RPM package, since I was reviewing Display Doctor on a Red Hat 5.1 system.
You can install the package with rpm -i, but you must do this from a virtual console as opposed to a TELNET session, xterm or serial console. After the files are installed, the post-install script proceeds to set up the program interactively. This latter aspect may come as a surprise to those who are used to installing packages with RPM.
The first problem I had was that I needed to tell the install program which mouse protocol to use, even though this information was in a configuration file (an existing XF86Config and the file /etc/sysconfig/mouse on my Red Hat Linux system). The installation program immediately provided a dialog box for the purpose of fixing this, which was quite easy. After doing that, the rest of the configuration process can be navigated with the mouse.
The setup program detected the Matrox Millennium card I installed, but I had to give it the horizontal and vertical retrace specifications of my monitor (this may be because my monitor is four years old). I also have a UK-layout Microsoft Natural keyboard, which some X-server setup programs don't acknowledge, but to my surprise this went without a hitch and I could type the British pound symbol quite happily.
The final step in the configuration process is selecting the screen modes to be available for the X server. At the start of the selection process, every possible screen mode is pre-selected for you. When I started the X server for real, with startx, I was presented with a 1920x1080 screen mode, which unfortunately offers an aspect ratio of 16:9 and looked peculiar on my conventional 4:3 monitor. Exiting X, I removed this mode from the ModeLine list in the configuration file (which, oddly, is still called XF86Config). Restarting X, I was presented with a 1600x1200 screen mode—the same aspect ratio as my monitor.
In use, the SciTech Display Doctor X server worked well. From an installation point of view, it is just another X-server binary (/usr/X11R6/bin/XF86_SDD) and doesn't interfere in any way with the regular XFree86 files. I found this to be of immense benefit and in marked contrast to the MetroX and AcceleratedX products.
The server implementation appears strikingly similar to the XFree86 server; the same set of extensions are provided and the same configuration file name and format is used (with driver name “scitech” instead of “svga” or “accel”). This is a handicap, since it prevents easy changing between X servers (XFree86 bails out when it sees the unknown driver name “scitech”). If you query the Display Doctor X server with xdpyinfo, it appears to be version 3.3.2 of the XFree86 server, which is quite confusing. I assume this particular oddity will disappear with the official release of the final product.
Since this is the preview release, benchmarks are not very illuminating. I look forward to benchmarking the full release of Display Doctor against the next full release of XFree86.
One thing I find most exciting about this technology is that it is just as applicable to Linux as it is to Windows. Even the same executables are used (Display Doctor installs a bunch of Windows-format 32-bit PE dynamic-link libraries in /usr/lib/nucleus). This is of interest to Linux fans, because SciTech is planning to use this same technology to bring the same level of support to KGI/GGI, SVGAlib and the forthcoming frame-buffer support currently in the Linux 2.1 kernel. According to the readme.txt file, Mesa may even benefit from the same treatment.
Unfortunately, I cannot say how Display Doctor made it possible for me to use X on a graphics card that XFree86 does not support. While it would have been nice to try this, the fact of the matter is that I have deliberately bought only hardware supported by Linux. If all Linux users did this, the market for SciTech's Display Doctor would be constricted; on the other hand, some of the things they are planning will advance the scope of the product beyond just X. I think Display Doctor is an interesting option for a bundling deal, particularly if SciTech follows through with their planned feature list.
James Youngman has recently changed jobs from VG Gas Analysis Systems to Logica. He has no significant hobbies apart from drinking real ale (see http://www.camra.org.uk/). James has been (very!) happily married to Erica for just over a year now. James claims to be intending to take up sailing again. You can reach him at firstname.lastname@example.org.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- 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