Mac OS X: First Impressions
Could we possibly find an individual more unlike Linus Torvalds? We are told Jobs is ill-tempered, mean, merciless, unconscionable and abusive to those that work with and for him. We are told to trust him at our own peril. And, we are told he possesses an ego that's roughly the size of China. So, why, in heavens name, would we ever want to cover new technology from Apple Computer?
The reason is simple enough: it's always a good idea to keep an eye on the competition. And don't be fooled into thinking the only competition Linux faces lives in Redmond. Of course, Apple Computer has always been worth watching. As a company, Apple is the sole survivor of the pre-IBM PC era, it knows more about desktop computing and ease-of-use than most, and it has (with all due respect to the good folk at GNOME and KDE) always produced the best, and most usable, GUI.
Apple's newest OS offering is called Mac OS X. The very name hints at its two major components. Mac OS X is the Macintosh interface built on top of a UNIX base. It has as its base a technology called “Darwin”, which is an open-source implementation based on the Mach micro-kernel. Yes, your eyes aren't playing tricks with you—Apple has open sourced a core software technology. What is especially interesting is that the Darwin open-source development team is readying a version of the kernel for Intel chip technology; this alone should start some Linux alarm bells ringing). The currently available implementation, officially bundled as “Mac OS X Public Beta”, targets the PowerPC microprocessor.
Before I get into details, it's time for a confession, it's time to come clean. I'm a huge fan of the Macintosh, and have been ever since my wife bought me a Mac Color Classic back in 1993. As with most part-time, at-home Mac users, work is a different story, and I've always been “required” to use the Wintel platform in the office. Only recently have I managed to arrange things so that the box under my desk sports a rainbow colored fruit logo (together with the words “G3 Server”). It breaks my heart to say it, but the Mac Color Classic now lives with my brother-in-law, and in its place sits a no-name Wintel PC. Among other things (and for my sins), I'm writing and maintaining a Windows-based suite of applications using Borland's Delphi technology, so Windows 98 has to stay around to support that activity. To support my other activities (teaching, research, and writing), I partitioned Wintel's disk drive and installed Linux Mandrake.
I spend most of my Linux time working with Perl, vi and LaTeX. I got into Linux about 18 months ago, after picking up the April 1999 issue of Linux Journal at a local newsagents. My previous experience of UNIX was using it at University in the late 80's. (I avoid Windows NT like the plague.)
Until quite recently, and in combination with Mac OS 9, I ran the LinuxPPC distribution in the office. As I use all these different environments to accomplish different things, I'm constantly rebooting both my home and office PCs, jumping in and out of Linux, Mac OS 9 and Windows 98. For a while I ran the Mac-On-Linux technology on top of LinuxPPC, and this gave me access to my Mac applications from within Linux. Although Mac-On-Linux is impressive technology, it is a little too flaky for me to use on a regular basis, so I stopped using it. However, it is on my list of technologies to revisit at some later date.
Now you know where I'm coming from, and I can get back to Mac OS X. Apple Computer announced the beta release of Mac OS X Public Beta in the fall of 2000 and offer the technology to the Macintosh community for $29.95. Members of their developers programmes received a copy of the OS for free, together with a CD of developer tools. This is how I acquired my copy, as I doubt I would have been willing to pay for the privilege of beta testing Apple's latest OS creation. I don't mind paying for a full release product (like a Linux distribution), but charging for a beta product...come on, Apple! So it costs to produce and ship all those CD's; but surely it doesn't take much to make Mac OS X available for free download?
Before I could even get to the install, a small shock was waiting for me. The README documentation on the CD informed me that Mac OS X needed 128 MB of RAM to install! I nearly fell off my seat. I can only hope that this is due to the fact that Mac OS X is beta software and that a lot of debug code is shipping with this particular build. My office Mac is not that old, but it had only a single 64 MB DRAM chip installed. Luckily, a friendly computer technician on campus allowed me to swap my single 64 MB for 128. With the swap completed, I was all ready to go.
As would be expected, the installation on my G3 went smoothly—after all, Apple supply both the hardware and the software. Very little configuration information or knowledge is expected from the user. I was required to graphically select the disk partition upon which to install Mac OS X (which I had already preconfigured with Apple's SCSI HD Setup utility). I then provided my Internet details when prompted, as well as a default login-ID and password. Everything else was taken care of. It was during the installation that I got the first hint that this was something new. For starters, one of the components being installed was described as the “BSD Subsystem”. This may not mean much to the regular Macintosh user, but I had a fair idea of what was going on.
Once installed, a quick reboot brought up the Mac OS X login screen. I logged in and, after a few seconds, was greeted by the Mac OS X desktop. Apple is calling this new interface technology “Aqua”, and it is quite stunning to look at (see the screenshot).
It is not until you have used Aqua for a while and explored its many features that you realize just what an exceptional piece of software engineering it actually is. Of course, Aqua is not the X Window System, it is proprietary Apple technology, and proprietary Apple code. From a Mac users perspective, Aqua is very much like the Mac OS desktop they are used to, but a few differences make it feel a bit strange. Certainly, logging into a Mac will be a new experience for most longtime Mac folk. The other major shock is that the Mac now has a command line! The Terminal utility lets you access a /bin/tcsh shell to work with—as stated in the Mac OS X on-line help system, “BSD Utility programs”. This was my first port-of-call, because every time I come across a new system I check for my essential list of tools, Perl, vi, LaTeX and ispell.
Typing perl -v at the command line produced the Perl 5.6.0 copyright notice. Cool. The vi editor is always there, but I checked anyway, and sure enough, Mac OS X has vi installed. Typing latex and ispell at the command line produced “Command not found” error messages. Bummer.
A quick visit to www.tug.org soon directed me to the teTeX site, and I was able to download a precompiled binary of TeX and LaTeX for Mac OS X. A visit to www.gnu.org netted me a copy of ispell which, after two days of trying all I know, still has yet to build from source. I even went as far as downloading and installing the GNU text utilities in order to have a more compatible sort utility on hand, but that didn't help me get the install completed. A defeated man, I eventually gave up, and made a mental note to return to it at some future date.
Of course, ease of installation is only part of the ease-of-use equation (and all the Linux distributions—except perhaps Rock Linux—have been making great strides in this area). Another area to consider is ease-of-administration. To illustrate, I'll recount a recent experience.
Now that my students had access to my machine, I thought it would be nice to let them create some personal HTML pages on the system. Specifically, I wanted to let anyone access these pages using the /~username URL syntax, where “username” is the name of a user on the system (and which would be resolved to that users home directory by Apache). Not knowing how to do this, I reached for my trusty copy of Running Linux, 3rd Edition and read through the section on setting up and configuring Apache.
I found out a bit about Apache, including what I thought was all I needed to know, information on the UserDir directive, as well as some material on the srm.conf, httpd.conf and access.conf configuration files. After changing what I thought had to be change, I restarted Apache with the new settings enabled. I then surfed to my machine and tried to access a newly created, personal web page, but I got a permissions error. I reread the pages on Apache, fiddled with a few more settings and got the permission error again.
My usual strategy for dealing with things like this is to go away and do something else for a while, think about the problem, then come back and have another go. Unfortunately, this time, my usual strategy didn't work. I was still getting a permissions error, so I thought that the problem might be with the user under which Apache was running (it was set to nobody in one of the configuration files). I fiddled with this to try and see if it would work under a different user, but it didn't. I fiddled with my systems group settings, and that didn't work either.
A former workmate of mine refers to this mode of work practice as “guess and jiggle”. At this stage, I was done guessing and I was done jiggling. The basic problem was, like most newcomers to Linux, I knew just enough to be dangerous, so I got frightened and decided that any more guessing and jiggling might compromise my system. I reset everything as best I could and left it alone. It bugged me, though, that I couldn't make it work the way I wanted. I also wasn't sure if it was my fault, the fault of Apache or the fault of LinuxPPC.
Then, as if by magic, the Mac OS X mailshot appeared on my desk. Having installed it in about ten minutes (rather ruthlessly on top of my old LinuxPPC partition), I recreated the 15 student accounts using the graphical “Multiple Hosts” utility. The adduser command could not be found on the Mac OS X command line. I then turned on Apache (which installed with the OS) by clicking a check-box in the “Network Services” control panel. I searched for the Apache configuration files using the Sherlock graphical search tool and, once found, determined that Apache was looking in the public_html directory for personal web pages. I created the directory under my own account login, then created a five-line HTML page. Surfing from another machine, I accessed the web server running on my Mac OS X computer and asked it to display /~barryp and...up came my five-line web page, followed shortly thereafter by a triumphant “Yes!” on my part! It worked the way I wanted it to by default. After all, if you have multiple users on a system, and you are running Apache on that same system, doesn't it makes sense that your users might want to publish their own web pages? I know which of the two setups I think is easier to use...
Of course, shortly after I made the move to Mac OS X, I came across an article discussing the configuration of Apache using the Comanche utility, which may have helped my LinuxPPC woes. Then again, it may not have. I also received issue 78 of LJ, which included an excellent article on Apache, about one week too late to help me with my LinuxPPC problems (by then I'd already moved to Mac OS X).
Under the hood, Mac OS X is running a kernel based on Mach 3.0 from Carnegie-Mellon University and FreeBSD 3.2 (which is, itself, derived from BSD 4.4-Lite). What's not mentioned is that this is Apple's first OS offering to incorporate technology inherited directly from the NeXT Computer buyout.
Mac OS X is a much different beast than Linux. Whereas Linux is a monolithic kernel with everything but the kitchen sink running in kernel mode, Mach is microkernel based, in that it restricts what processes can run in the kernel to a small subset. Most everything else runs in user mode. Rather that spark off another Tanenbaum/Torvalds debate on which design is the way to go, let's just leave it that both are valid design architectures for an OS, both have their pluses and minuses and both work. The big technical difference from previous editions of Mac OS is that the base OS is now truly preemptive as opposed to being cooperative, when it multitasks. This is directly attributable to the use of the Mach micro-kernel. Support for POSIX, NFS and BSD TCP/IP networking also come as standard.
Standard Aqua applications include Apple's own e-mail program, a bunch of QuickTime applications, the usual utilities and—wait for it—Microsoft's Internet Explorer 5 (IE5). IE5 for Mac OS X is buggy and slow, and I hate it. Luckily, support for “legacy” Macintosh applications (called “Classic” applications within Mac OS X) comes as standard, and it works somewhat like Mac-On-Linux except that the legacy applications run on the Aqua desktop, as opposed to within a separate Aqua window. This technology works well, and I as able to use Netscape Communicator, ClarisWorks and all of my usual Mac OS 9 applications without any real problems.
Of course, not all was plain sailing. I've had two crashes in as many weeks; nothing but a flick of the power switch would bring me back on-line. As this is “beta” software, I am willing to accept this, for now. In Apple's favor, they do warn about using the beta Mac OS X in production environments. A major annoyance is the fact that Mac OS X appears to know nothing about floppy disks. When I slid a floppy into the slot at the front of my G3, nothing happened. I was expecting, as will every other Mac user on the planet, to see a graphical image of my floppy appear on the Mac OS X desktop. Nothing. I searched Help for the word “floppy” and found nothing. Even more annoying was the treatment of my ZIP disks. A Mac OS formatted ZIP appeared on the desktop when inserted into the G3's ZIP drive, but when I slid in a PC formatted ZIP disk, Mac OS X did nothing. This worked really nicely under the old system, and should be part of Mac OS X. I'm praying Apple fixes it before the next release.
As for Steve Jobs, well, he has always been out to change the world. With Mac OS X, his beloved Apple Computer has another chance to do just that. Apple changed the world as we knew it when it released the Apple II in the second half of the 70's, and then they did it again in 1984 with the introduction of the original Macintosh. Since then things have been quiet in Cupertino; granted, technologies such as the PowerBook, iMac and iBook are cool, but they are really just incremental improvements over the original 1984 Mac. Mac OS X has the potential to be a much bigger deal than any other OS Apple has produced in the past, but the company must move quickly. Specifically, Apple should open source the Aqua code and publicly support the porting of its technologies to the Linux kernel. Coupled together, Linux and Aqua would make an unbeatable pairing on the Intel platform. World domination, indeed. Just imagine the panic in Redmond.
So, does Mac OS X mean the end of LinuxPPC on my office computer? For now, my problems with ispell not withstanding, the answer is “yes”. Mac OS X gives me all I need in the office; it's a Mac and it's UNIX/Linux, too. I'm in heaven. At home, I'm stuck with my Windows/Mandrake combo for now, but at least I can boot into Mandrake when my frustration meter for Windows 98 peaks. And, all the tools I use on Mandrake are, as they were with LinuxPPC, 100% compatible with those I now use on Mac OS X. Of course, the ability to avoid all those reboots in the office is a major plus for me.
I've been running Mac OS X for a few weeks now, and I'll keep running it in the office until May 2001 when my beta license expires. Let's hope Apple issue the full 1.0 release before then and that Apple gives it away for free to all comers, developers and users alike.
Paul Barry (firstname.lastname@example.org) lectures in computer networking at the Institute of Technology, Carlow in Ireland (http://www.itcarlow.ie). He loves the Mac and he loves Linux, too—go figure!
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
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Interview with Patrick Volkerding
- 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