VAR Station II
Another problem I bumped into was with the Java demos. There was a tantalizing tree of Java class files under /usr/lib/java/demos. The only problem is that they are applets rather than applications (meaning that they can't be run outside of a browser or viewer). Since neither HotJava nor Netscape was pre-installed and Red Baron and Grail (the two web GUI web browsers that were available) don't support Java, this left a bit of a problem. Here's another case where a few pages on the localhost web server's document tree would greatly help a new user. In this case, I had filed the appletviewer command, and so was able to preview all of the demos with the single xterm/bash command:
cd /usr/lib/java/demos && for i in */examp*.html;\ do appletviewer $i; done
In contrast, DOSEMU is installed and configured. Maybe I'll get around to digging out my old collection of DOS shareware to play with. For test purposes all I did was run dos, change the CONFIG.SYS within the hdimage, restart dos and change directories to the mount point for my C drive back on antares, where I was able to run 4DOS and Norton Commander with no problems. For the record, that was accessing a DOS file system mount on another Linux system through an NFS mount on the local host. It worked without any special fussing.
My only complaint about the way that DOSEMU is configured on this system has to do with the permissions. It started out as SUID root (which is necessary for technical reasons) and world executable. A more conservative and reasonable approach is to create a dos group—and change the binary's permissions to group executable—stripping all access from “other”. This suggestion applies across the board to almost all SUID programs. It limits the number of users who can attempt to exploit security problems with the files. If you routinely add all of your real users to dos and other groups, at least you prevent possible access through pseudo users like bin, www and nobody.
Like other systems that I've had with the OS pre-installed, this one had a “cookie cutter” feel to it. For example there are two partitions: / and /home. The consensus of Unix system administrators is that it's safer to make a relatively small root partition, a medium or large /usr, an alternate root and some other partitions suited to a particular host's needs. A separate /var/spool partition—or even /var/spool/mail and /var/spool/news—are often a good idea. I like to create a large partition to use for /usr/local (on some systems I make /home a symlink to /usr/local/home).
There are many other things I do when setting up systems for myself or my customers—like turning on the immutable bit on system binaries and share libraries (see the Linux-Tips HOWTO) and removing extraneous services from inetd.conf (the single most effective thing you can do to improve your system's security). While I don't expect VA Research or Red Hat to do these by default, it would be nice to see some of these practices codified as install options.
After exploring as much of the pre-installed software as I could find, I installed some other packages. I started with a copy of Mathematica and a copy of Applixware. Those installed easily and ran fine. I fussed with GNUStep DR2 (which is the free NeXT/Open Step clone that's currently being developed), but I never did get it to run. Another package that gave me grief was Lyx (WYSIWYG LaTex word processor).
That is about par for the course. About a third of the programs that I tried to build from sources, and maybe a sixth of the RPM packages I experimented with, didn't build or install on the first try. This is better than my average with Windows programs, and worse then my experience with DOS shareware (although not by much).
For comparison, I recently purchased a Mac Performa which I've been setting up to send to my mother. I bought a couple of CDs full of Mac shareware --mostly games—and played with them to decide which ones to install for her. I found that over 90% of the games and tools could be run right off the CD with no problems—and no installation. For those Powertools that I did decide to install, each was simply a matter of dragging the folder from the CD into my file window (group). In fairness I have to point out that one of the programs that did not behave under MacOS 7.5 managed to completely trash the system drive when I tried it again under the new MacOS 8.0. Norton Utilities was no help for the damaged file system (so now I'm reinstalling everything from scratch). The failure rate was much lower—but more catastrophic.
Now this may seem like an unfair comparison. Linux isn't “supposed” to be as easy to use as MacOS. However, the point I want to make is that Linux is catching up quickly. I wouldn't send my mother a Linux system this year—but in another year or two, I might.
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!
- Three More Lessons
- Django Models and Migrations
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- The Controversy Behind Canonical's Intellectual Property Policy
- Secure Server Deployments in Hostile Territory, Part II
- Shashlik - a Tasty New Android Simulator
- Huge Package Overhaul for Debian and Ubuntu
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile