VAR Station II
Connecting the system to my household LAN was simply a matter of plugging it in and changing a few lines in the /etc/sysconfig/network file. (Yes, I used the text-editor method rather than the GUI). It only took a few more minutes to add read-only NFS exports between the VAR Station II and “antares” (the old 386). I was then able to access the Internet using IP Masquerading through antares, which dynamically brings up my PPP link using diald. There really was no fussing with the hardware—ever.
I wish I could say the same for the software. I think it's a shame to ship a machine that's so clearly intended for use as a multimedia graphics workstation and have it boot to a text-mode login. Remember this statement is coming from an affirmed text-mode bigot. I would ship these systems with a run level of 5 as the default setting, thus providing the new user with an xdm (graphical) login prompt.
I also consider it a bit silly to use a 4MB Matrox video card with a depth of only 8 bits. I was able to override this with the command:
xinit -bpp 16
I also found that Red Baron (Red Hat's preferred web browser) refuses to run in “truecolor” mode. From what I've read, it's possible to use Xnest to solve this problem by running an additional instance of the X server on a different display such as :1 and opening a remote client window on it. I had no problems running Xnest, but I couldn't convince it to run with the lower color depth despite several readings of the man page. There were some other programs that didn't like the “truecolor” mode as well.
Despite all of this, there are big advantages to running with the larger color palette if your video card and X server support it. When using xv (the X-viewer package) for photo finishing and other graphics packages, you need the extra colors.
There were two other nuisances about the way X Windows was set up (which I think was the Metro-X server—though XFree86 is also installed). I don't use X Windows much, as I don't like to wait for it to load. Normally, I start a copy of it and leave it running all the time. When my wife wishes to use the system, I prefer for her to run her own copy of X and leave mine alone. I've always been able to manage this by running my copy on a different virtual display with a command like:
The included version of the startx shell script was doing something with a file in /tmp and complained when I tried to start a second session. I worked around that problem by using:
xinit xterm :1and manually starting my window manager from the ensuing xterm. Eventually I'll probably fix that startx script.
Also, the SVGA libraries weren't configured at all. No playing sdoom on this system without a little tweaking.
After configuring the network and starting X, I was greeted with a couple of xterms and a copy of the Red Baron web browser displaying a page from the localhost web server. This had some information and links to the VA Research and Red Hat web sites (along with a warning that you need to have your Internet connection configured before those would work). However, I would like to have seen more extensive local web pages. What I'd really like to see is a multi-media tutorial and tour—similar to the “Welcome” application that comes with a Macintosh Performa. This could be done as a set of web pages, Java programs, a Tcl/Tk script or some combination of those options.
The default window manager for recent versions of Red Hat is FVWM 95 which, as the name suggests, is the familiar FVWM configured and tweaked to provide a feel similar to a certain Microsoft product. This is nice for users who are migrating from that universe and reasonably unobtrusive to those of us who are used to FVWM. You can still access the menus by clicking anywhere in the root window (what Windows calls the “desktop” or “background”), and the other mouse buttons still bring up the “Window Ops” and “Task List” menus. FVWM 95 doesn't put any icons (like “My Computer” or “Recycle Bin”) on the root window, so the similarity to the Windows 95 desktop is minimal. However, it is nice that I can use the alt+tab key binding to cycle among tasks in FVWM 95. I'm told you can set up any of the common X Window managers with that feature, but I've never taken the time to edit my rc files to include it.
While exploring the FVWM 95 menus I found familiar problems. So far this has been true of every installation of Red Hat and Slackware I've done. Several of the menu items are non-functional “placeholders” or examples (such as remote xterms to systems that don't exist on my LAN). Also, some of them try to call programs, such as the xvier game, that simply aren't installed on the system. Other menu items call their binaries with arguments that generate error messages. There was a new problem, for me, with the “screen lock” and “screen blank” submenus. There are so many blank/lock modules listed on the menu that they push off the edge of the screen—and virtual screen scrolling doesn't work in this context. So there are more screen blankers than you can access. Also some of the screen blanker selections just didn't work (due to typos in the rc file). I consider this to be a fairly minor problem that is easily solved by editing your own copy of the .fvwmrc file—if you understand its syntax.
I'd like to see an rc builder added to the default menus (maybe built around “The Dotfile Generator” by Jesper Pedersen Linux Journal Issue 42, October 1997). There's a lot I don't like about the MS Windows and Macintosh user interfaces, but they do have the virtue of being approachable. They have menu items/icons for almost everything and their menu items don't “silently” fail, leaving you wondering what was supposed to happen.
If you don't like FVWM 95, you'd better know how to configure whatever window manager you do like. This installation had a few other window managers installed (twm, olvwm and the old fvwm). However, none of the others had menus that were even close to the system's configuration.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development