Running Windows Applications NOW
Initially, you should start with MS Windows configured to use just a simple VGA Display driver. Getting MS Windows running if you have difficulties is a problem exclusively for their product support personnel. Naturally, if MS Windows doesn't run on the DOS computer, it won't work under DV/X. After getting the networked MS Windows running, you can get screen sizes of 1024x768 if your X display has room. Since DV/X is converting the video commands, you don't need the actual video card drivers. Instead, you use the Windows “Super VGA 1024x768 256 colors Large Fonts” driver. Read the DV/X documentation on setting up WinX for best results. To run MS Windows under Linux X, you can type the following in an xterm:
$ rsh dosboxname winx
In a few moments, you should be able to launch applications other than Solitaire from MS Windows. You can even start another MS Windows process (if you have sufficient memory) that is completely independent of the first (be careful). You're limited to Standard mode, but so far I haven't come across an application I need that truly requires Enhanced mode. One of the first things you'll need to do is change the MS Windows color scheme with the Control Panel Color tool (In the “Main” window). Otherwise, you may have invisible fonts! I suggest starting with the “Arizona” color scheme instead of the default.
TANSTAAFL: There Ain't No Such Thing As A Free Lunch. As mentioned above, there is a speed penalty for using DV/X to get MS Windows applications under Linux. It's a direct result of the network connection between the involved computers (that's likely to be the slowest part of the pipeline). However, for many uses, that speed penalty may be negligible. Ten Mbit/s Ethernet is not very fast when compared to ISA bus speeds: ISA is 5 times faster than the original Ethernet. There are one hundred Mbit Ethernet cards appearing, for a cost about 2 times the 10 Mbit cards. One hundred Mbit cards should give DV/X MS Windows performance equivalent to an ISA video card, which is quite acceptable to many users. This is the most serious drawback, but it needs to be balanced against the alternatives—in short, your mileage may vary.
As I mentioned, the speed difference may be negligible—you may not even notice it. I still can't type at even one-thousandth Ethernet speed. I find the major use of DV/X MS Windows to be typing large amounts of text without text layout or formatting concerns. The other major use is for tasks of under 30 minutes; in both cases, the speed penalty is not apparent or traded off against the time to change operating systems. The remaining gotchas are somewhat minor.
The DOS ODI driver may have some problems. I notice that the 16-bit Ultra cards don't outperform the 8-bit 3C503 cards. I believe the Ultra ODI driver might be the cause. The network stack you use on the DOS computer can also make a difference—I've seen the best results from the Novell TCP stack. It's RTFM time here.
You may see some color changes. I use fvwm as an X Window manager, and sometimes the MS Window picks up the colors of the fvwm pager when switching between pages. Usually the next dialog box clears the colors up. There may also be some rearranging of your X workplace in order to fit MS Windows in at higher resolutions. The Alt-F4 keystroke will no longer close the MS Windows application. Instead, under the standard fvwm setup, it will iconify the window. Double-clicking the corner of the menu bar still works nicely to terminate applications. The usual problems between DOS filename limitations and Unix file names exist during file transfer.
I use DV/X regularly after months of experimenting—in fact, I booted DOS last month and realized it had been 6 weeks since I had last ran DOS. DV/X is as stable as MS Windows (actually, a little better, since DESQview isolates tasks in a fashion similar to Linux). There are some silver linings in the slow speed cloud. DV/X File Manager is a very useful tool; we have an Apollo workstation that exercises it frequently. DV/X can provide remote printing services, making the Linux end a snap to configure. Oh, and yes, I used my network to assist in preparing this article. See Figure 1.
I've set up two networks with DV/X and Linux; most of it runs “right out of the box”. I've been using Linux at work for 10 months now and have only rarely been forced back into DOS. In fact, Linux applications have provided better answers to tasks than the less stable DOS equivalents on several occasions. Source code availability and group programming naturally lead to superior programs!
Ron Bardarson (firstname.lastname@example.org) plays with Linux nowadays; eleven years ago, he was hacking ZCPR3 (he wrote its Make utility, MAKE.RCP). Network computing and studying interesting applications of numbers divert him from work, kids, and dancing.
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
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
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