I'm writing this column from a hospital, specifically, its Critical Care Unit (CCU). They used to call these intensive care units, or ICUs. Before unit became current, they were wards. All the name changing causes confusion. I wonder if it's enough to cost lives.
It's conceivable. Two doors down, they had a Code Blue this morning. Machines were wheeled in. Staffers hurried around, carrying clear tubes and bags of fluid. A chaplain paced in the hall. Groups of family members cried on each other's shoulders. They deal with life or death in here. A hospice worker a few minutes ago told me “a lot of the people in there are wheeled out feet first.”
Fortunately for me, I'm not a patient here. Unfortunately for my mother, she is, thanks to complications following a gallstone removal procedure. So I've been hanging around as a visitor for most of the past week. Every once in a while, I go over to the counter by one of the nursing stations, where a Microsoft Windows 2000 Professional logo floats on a black screen above a black keyboard and a mouse. When I move the mouse, the screen comes to life, offering me a choice between Staff Login and Internet Explorer. After clicking on Explorer, I surf the Net until it crashes on some site, bringing the rest of the machine down with it.
I asked a nurse yesterday if this kind of crash also happens when the systems are running the hospital's own applications, which mostly are used to access patient records and recent lab results. “Those things are down all the time”, she said. “We have all kinds of problems with them.” After hearing her response, I wondered, “what are costs—in time, money and human lives—to running hospital computers on a crashy operating system?”
Three weeks now have passed between the last sentence and this one. Several days after I wrote everything above, my mother's condition improved to the point where she could be moved out of the CCU. She had fought hard against pain so extreme that she needed frequent doses of morphine, which were shot into one of the many stretches of tubing that ran in and out of her frail, 90-year-old body. But she was tough and willful; her mind still was strong and amazingly lucid, especially considering all the chemical insults it endured.
“Are you gonna make it, Mom?” I asked. She said yes and told me to head back home to California. That night, best they can figure, she had a stroke. Two days later her cardiologist came by, surprised to find her there. He hadn't been told she was in the hospital and therefore hadn't been consulted about her medications, which he carefully had prescribed and monitored over the last ten years, ever since she had been diagnosed with congestive heart failure. The next day, she died.
It's easy to second-guess everything at times like this. Any one of us—doctors, nurses, relatives—could have made sure to involve the cardiologist. And, as many doctors and nurses have told us (some of them members of our own family), Mom's odds were long at best from the moment the original procedure went poorly, which often happens with elderly patients. She knew the risks going in. She also lived a full and happy life. Before she slipped out of consciousness, she told my sister that she had no unfinished business and was ready to go. Her last word was love. She passed peacefully and without pain.
So I have no complaints about her treatment, which was excellent. I also know that every botched procedure, every course of treatment that fails to reach the ideal outcome—and, let's admit it, there are many—is a learning experience. One thing I would like hospitals to learn is how to get along without crashy software.
My mother died in late August 2003, during a time when the Blaster/Lovsan worm was infecting and spreading among countless Windows computers. A few days later, on “The Linux Show” (where I'm a weekly regular), Bruce Sterling told us there is no overestimating the level of hatred for Microsoft that the latest round of viruses is causing, especially outside the US. He recently had returned from Europe, where he found large cadres of locals determined to move beyond dependency on Microsoft. Bruce also wondered out loud whether there would be any kind of software business at all when “open-source nirvana” finally was achieved. Here's how he put the situation in a Wired piece titled “Freedom's Dark Side: The iron fist, the invisible hand, and the battle for the soul of open source” (www.wired.com/wired/archive/11.09/view.html?pg=4):
Logically—indeed, free-software geeks are the most logical hippies in the whole wide world—the revolution is at hand. Why should anybody pay for software? What do you get for your money besides shrink-wrap licenses, potential lawsuits, DRM cuffs around both wrists, and a cloud of viruses? “Property relations” are blocking social and technical progress. Secure computing and digital rights management are coercive regimes that would make George Orwell blush. The free market is a tissue of political fiction as brittle as an Eastern European regime. With open source code on tap, the software trade will collapse under its own weight....
From Redmond or Cupertino, it may seem decadent that an elitist scrum of hairy cyber-Euristas would style itself a cultural avant-garde. But consider the track record. In 1989, European civil society tore the guts out of Communism. When the Europeans won the Cold War, they got a bonus the US never did: zillions of eager former Commies. For these New Europe types, open source is a great, glittering step up from the vile product they're used to: broken-open source software, as in pirated CDs sold off blankets at flea markets.
The denizens of Open Cultures want their connected collectivism to liberate the world from regulations, markets, and intellectual property. But what if victory only clears the way for corruption of their beloved culture?...I have to wonder what dark passions and ancient evils have been held in check by the grim totalitarianism of the profit motive. We may yet find out.
Clearly, Microsoft's operating system and the PC productivity software business are threatened, or Microsoft wouldn't repeat “Linux” and “threat” so often in the same sentences. But it's a huge mistake to assume they are the only software businesses worthy of the label. What about that hospital software? What about the database, corporate accounting, customer resource management and transactional computing stuff that companies all over the world use to run their businesses? Do these all have to run on Windows? Do even a few? Look at Oracle, which abandoned its formerly nonpartisan orientation to operating systems and embraced Linux with a whole heart and a fattening wallet. Last I looked, Oracle still was growing like a weed and making billions of dollars on margins they've kept north of 75%. Look at Amazon and Orbitz, both of which run everything they can on Linux.
These companies, of course, are the obvious ones. How about the countless small- and medium-sized businesses and the categories they occupy? I'm talking here about stuff that stays way below the radar, because what they do isn't sexy or leading edge, even if they're the folks whose listings fatten our yellow pages.
Take, for example, the junkyard business. Last week, I was talking with my friend, Allan Harrell, in Phoenix, who has ties with body shop, body parts and junkyard businesses, even though his main job is keeping small business networks and computer systems up and running. After telling me how full his plate has become, thanks to all the viruses infecting Windows machines in his care, he mentioned FastParts, Inc. (fastpartsinc.com), the country's second largest supplier of computerized inventory systems for junkyards.
Intrigued, I got Jim Mangham and Wayne Leland on the phone to tell me about it. Jim owns the company, and Wayne is the “lead programmer systems guy”. They have a staff of seven and a customer base of 750. Wayne said the company has been using Linux for six or seven years; they like being able to hack the kernel and otherwise customize systems to do what they want.
FastParts sells a service that's delivered with a turnkey system in a white box. Customers view and operate it in a terminal window on whatever system (usually Windows) they happen to be using, including dumb terminals (Wyse, Sherwood) that FastParts is happy to provide.
FastParts is a personal service business, delivering and installing the systems themselves, including the modem phone connection that lets the company dial into a machine, do diagnostics and fix problems. Customers also call in through the system to look for car parts on FastParts' central system. “Many of our customers are too far out in the sticks to get a high-speed Internet connection”, Wayne says. “We have one guy on the road full-time, just installing.”
How do they compete? “Reliability, pricing and support”, Wayne says. “Out of all our competitors, where we get 'em is with support. Most of the other ones have modern telephone systems with all these menu choices you have to go through, and most of our customers do not like that. They want to get a real person when the phone rings. With us they get that.”
To me, that's the real story of Linux and open source. It's the ability of any expert in any field that requires any computerization at all to build a business that delivers what customers want—thanks to underlying software building materials that are free.
One of these days we'll all understand what's been obvious for years to guys like Wayne Leland: that free software is the best bedrock for a healthy and free computing marketplace—regardless of whether it threatens prevailing monopolies.
Doc Searls is senior editor of Linux Journal.
Doc Searls is Senior Editor of Linux Journal
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!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- 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