Unix Wars, Redux
For years, Unix vendors fought each other for market share by each implementing their own proprietary extensions to Unix, each trying to use their own extensions to sell their version of Unix—usually on their own hardware. No one blames them for competing, but the result was not good for the whole Unix marketplace. Many slightly different products, which had different names but somehow were all understood to be Unix, more or less, bewildered and bothered consumers.
Because they recognized the damage this situation could cause, Unix vendors have been making interesting noises for years about closer co-operation with each other. Novell bought Unix, then gave the Unix trademark to X/Open, to create an open branding process in order to help bring the Unix world together. X/Open then released the Single Unix Specification, to which all vendors' versions of Unix are required to conform in order to use the trademark. To an amazing extent, this has been a success; quite a few products that could not use the trademark before have now been “branded”.
Last fall, at Unix Expo, HP and SCO announced that they were working together to buy Unix development rights from Novell, and that they were going to develop the new standard 64-bit Unix. While several versions of Unix have been more or less 64-bit in the past, the Single Unix Specification (SUS) does not explicitly address 64-bit issues, and SCO and HP (especially HP) were going to supply the Unix world with 64-bit Unix.
This was expected to provide the Unix world with, essentially, 64-bit additions to the SUS, which would be implemented in every 64-bit version of Unix.
The careful reader will have already noted my use of the past tense. Welcome to reality in the Unix world. SCO and HP recently made it quite clear that they intend for their extensions and additions to be available only from SCO and HP. They will provide the whole Unix world with a unified 64-bit Unix, all right, provided that everyone uses their operating system on their hardware. Welcome back to market fragmentation—called “product differentiation” by the spin doctors.
No, this isn't just a tale of woe. The Linux community used to be unified because of a simple lack of need for competition. Now, Linux distributions are somewhat differentiated, but most Linux vendors work together, recognizing that their long-term chances of survival are far better working together than fighting. Unlike the Unix community, the Linux community has stayed generally unified in the face of commercial interest.
Linux, though it started out as a toy, has for some time been real competition for “Real Unix”. Ignoring the licensing issues for the moment, Linux looks a lot like a vendor-differentiated version of Unix. While a few Unix versions have extra features that Linux does not (yet), such as journaling file systems, process migration, and fail-over server capability (See Huh?), Linux has features that distinguish it as well. For example, Linux has high-quality networking with support for many protocols; few commercial versions of Unix can provide Novell, Appletalk, SMB, and AX.25 in addition to standard TCP/IP networking.
Linux also uses memory frugally; with Linux, it is perfectly reasonable to use a machine with only 4MB of RAM—with most versions of Unix, that's not even enough to boot, let alone do useful work. Linux has more complete hardware support, especially for legacy hardware, than most (all?) versions of Unix for Intel x86 computers. Linux distributions usually include far more application software than is generally included in a Unix distribution. And, last but not least, Linux comes with source code.
Most versions of Unix support one, or at most two different CPU architectures. Sun's Solaris supports SPARC and Intel x86. SGI's Irix supports MIPS. SCO supports Intel x86. Digital Unix supports the Alpha. Linux currently supports Intel x86, Alpha, SPARC, Motorola 68K, PowerPC, MIPS, and Acorn ARM. The source code is now designed to make adding new architectures easy.
Linux is also now a 64-bit operating system. More properly, it is mostly bit-size-independent; it operates as a 32-bit operating system on a 32-bit CPU, a 64-bit operating system on a 64-bit CPU, and on a 16-bit CPU, the subset of Linux that can be fit into memory operates as a 16-bit operating system (see www.linux.org.uk/Linux8086.html).
Ignoring license issues, Linux and the various versions of Unix are pretty similar; they have the same core functionality, and each has a few extensions or features which differentiate it.
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
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Returning Values from Bash Functions
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
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