SCO Gives It Away: More SCO vs. Linux
There is a new vendor attempting to enter the “Free Unix” market. You may have heard of them. And Microsoft owns part of them. We're talking about SCO, current owner of what was AT&T Unix. A press release we received says they are offering a free copy of SCO Open Server. Well, actually, it is a license for SCO OpenServer—if you actually want the software you have to pay $19 for the media.
Is this a threat to the Linux community? Not likely. If anything, it is a response on the part of SCO to the threat of Linux to their market.
For those who think it is a threat to Linux, the license is for a single-user version of the product. And, in spite of the fact that they make it out as a return to AT&T's policy to offer Unix free to universities, they don't mention that AT&T included source code. SCO does not.
Sure, there will be some takers on what they offer. It will give people a chance to get a mini-Unix to play with. Then they will be ready to graduate to Linux.
Mark Horton, one of the Linux community's strongest proponents, has died. In September, his friend, Victoria Welch ( email@example.com), had this to say about Mark:
The Linux world suffered the loss of one of its greats on September 9, 1996. Mark A. Horton (from GA Tech) passed away in his sleep. Mark had been in poor health for some time, but of late, he seemed to be making a comeback. His passing blindsided those of us close to him.
I first encountered Mark in the version 0.9x days of Linux. Having reached the end of my rope with SCO and a number of other Unices, I decided to give this “Linux toy” a try. About all I had to lose was some time and if it worked, I'd save $3,000 on another version of the “OS” I was using at the time for another upgrade that “didn't have any problems”. So I boldly stripped off what I was using and installed Linux from my pile of floppies (remember those days?). The rest was history—I was hooked. There were various problems with it at the time, but I was elated. There was no one to tell me, “No, we don't have that problem” and I had the actual source code so I could fix it. For a Unix junkie, it was Unix nirvana!
It was at this time I met Mark. He was able to sort out the problems I had and either suggest fixes or workarounds or point me in the direction to go to solve the problem. Corresponding with him via e-mail was a pleasure; his enthusiasm, wit, and gentleness I came to love and now miss deeply. Over time, e-mail led to phone conversations, frequently in the early morning hours. I couldn't get angry with him for the time at which he chose to call since the conversations were always interesting and fun!
Sometime later I separated from my husband and returned home to Atlanta. In the process of job searching, I was in the Decatur area and stopped in to say hello to Mark, and we hit it off wonderfully. He was even more charming in person than via “e-media”. One thing led to another, and I ended up working for him doing technical support for InfoMagic—at subsistence wages—but I was having fun and learning more about Unix than I ever thought possible.
I thought I was a pretty “hot shot” Unix guru, but working with Mark was a humbling experience—I probably learned ten times what I had known. Mark was a stern taskmaster, and I am a far more competent Unix person because of it. Never have I had such a crash course, nor more fun doing it. He would plow through the support calls, usually faster than I could get them out of the queue. Tireless and enthusiastic, he was having fun, and I've never seen anyone draw so much satisfaction from helping others. It was common to field 50+ calls a day—he returned them, and I spent seemingly forever trying to sort out the mumblings from the less-than-optimal voice mail system while trying to keep an ear on what he was doing. His dedication to Linux was amazing to me, even as monomaniacal as I am. He often started work at 0600, taking calls from around the world until long past midnight, and then spent time researching the tough questions or just talking Linux with whoever called. He would take calls from the other side of the planet and help people rather than tell them to call back during normal business hours.
He was supposed to have limits: support on installation only. But too many people had other questions, and he kept almost everyone satisfied. If anyone made any attempt to solve a problem on his own, Mark bent over backwards to get him through it. Numerous times, we got calls from people who expected to stick the CD-ROM in the drive and immediately be running Linux; even when they were rude, obnoxious, and threatening, this rarely ruffled his feathers (although he did occasionally have some choice comments after a call). Many of the angry callers hung up happy and satisfied, and some would call or send e-mail back saying they had figured things out, apologizing for their attitude earlier. Mark was a master wordsmith with the patience of a saint.
When Mark wasn't directly supporting Linux, he was researching, talking with those writing the packages and elements of the system, discussing improvements, and occasionally writing patches to help out where he could. When not doing all that, he was talking up Linux and making converts; many of the most recalcitrant eventually decided to give it a try and thanked him for it.
Around this time, his health was deteriorating, and believe it or not, it stemmed from physical problems and not the lack of rest—he got energy out of what he did. He ended up in the hospital for a week or two, and I ended up taking him a laptop, modem, and manuals. He hated being there and was working hard to get well enough to “get back to it”.
We quit doing direct support at that time and went over to e-mail support. Three hundred messages per day (plus phone calls from people to whom he'd given his phone number)--it was overwhelming just trying to categorize them and get boilerplate responses together. The categorization was 90% of our time and the other 90% was spent generating the boilerplate. There was simply not enough time in the day to even have hope. We finally admitted it was impossible and basically burned out. Although he burned out, it didn't dampen Mark's enthusiasm or interest. He still tried to help, and we spent many nights discussing the “this-n-thats”, ramifications and solutions, until the sun came up and we broke for breakfast before crashing for a bit of well-earned rest. We worked our arses off, but it was the kind of work you love—we knew Linux was “getting there”.
Some of the more interesting stories I'm sure would be denied—you wouldn't believe some of the places (big places) using Linux internally. My favorite was a call with a particularly knotty network problem (as I recall) which I couldn't solve. I was going to have Mark call the guy back since he was, as usual, buried. The guy offered to hold, and I told him it might be a while and to just give me his number and I'd have Mark get back to him. He said something along the lines of, “We don't get to surface often, er ah, I mean we don't mind waiting for a bit, we'll just wait.” I had Mark put his other call on hold and take the call. (He would never talk about that one.) Other places I know are using it wouldn't be doing so if Linux wasn't a truly viable and reliable resource. There are thousands of other stories from “the little folk” (us), who found new wonder in computing because of Linux. I could go on, but with most of y'all who read this, I'm “preaching to the choir”.
Mark was never able to keep a “spare” machine—anything he built became part of the critical path. He was an inspiration as he was one of the few people I know who had many machines and actually knew them better than I did. This had a positive side for me; working hard at it, I did keep a spare machine and got to try all the new goodies he was sent, and then we'd hash it all over. If he wanted to play with it, he would come over or play via the network. After the initial experience with him, I was willing to relinquish my claim to being a guru beyond SCO and Slackware, but with his stretching of my limits, I no longer have any qualms about jumping into anything to do with Unix or any Linux distribution. Anything I could say about this extending of my capability, knowledge and self-confidence would not do it justice.
Looking back over the e-mail I have received since I posted news of his passing to comp.os.linux.announce, I am convinced I was but one of many to have this honor and luck.
If it had to do with Linux, Mark was interested. He experimented with various distributions of Linux, including those for the Mac and anything else it might run on. His interest was boundless and his enthusiasm infectious. His quick wit and intellect were a joy to behold in operation.
When I found him on September 7, he appeared to be resting peacefully and was, as usual, surrounded by piles of manuals.
As his best friend and being as close to him as I was, the job of sorting out his machines and turning off mailing lists so his parents could wrap up his affairs left me be amazed all over again at Mark. As well as I knew him, I was only peripherally aware of all the things he was into. The sheer scope of his studies and experimentation with Linux became obvious, if a bit mind-boggling. He was a true hacker in the old definition of the word—research for the joy of knowledge, not intrusion or destruction.
For those of us who knew him, the loss is acute. I'll miss the night-long technical discussions, his curiosity, and the joy he radiated doing the things he did so well. My education will not end here, as my relationship with him taught me to stretch my own limits—one of the true joys of Linux is there is no end to learning!
If there is one thing to regret, it's not writing this while he was still alive. He wasn't a high profile Linux personality, but he put more working copies of Linux out there than anyone else I am aware of. He took the most ignorant (“ignorance can be cured, stupidity is terminal”) beginners and gave them a start and undoubtedly infected a high percentage of them with the joy he found with Linux.
Perhaps this learning experience will encourage others out there to spend a few minutes writing about those who deserve credit for Linux being where it is today. I know Mark would have “poo-poo-ed” something like this, as he didn't feel he was really doing anything special, but that seems to be a trait of the truly exceptional.
While I feel a deep sense of loss, I can only try to honor a request he made repeatedly when the subject of “if anything ever happens to me...” came up; he was consistent and firm that there be no moroseness over his passing. A number of his friends are planning to get together to have a “going away” party for Mark and to hoist a beverage of choice to the honor of one of the greats—joy, not sadness, was one of his strongest desires. I'll do my best to honor this but the passing of my best friend and greatest mentor in my life does not make it easy.
At the party I intend to recount some of the things I mentioned here and to raise a glass to the kindest, most loving, most sharing, overall nicest, funniest and most dedicated person I have ever known. Hope you are at peace and in no pain. To know you will be one of the high points in my life; cheers, friend, until we meet again.
Remember the good guys and say what is in your heart while you still can.
I'll close with a quote from a Spider Robinson book that I have found so true with Mark: “Joy shared is multiplied, pain shared is divided.”
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
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