Migrating to Linux, Part 2
Here's a personal story from one of the authors that illustrates exactly why we all must make regular backups. I'll never forget it. It was late at night, and I was on a tight deadline, cranking out a major project for a client. Then, I heard it. A rattling noise, like a backgammon player shaking a cup of dice. Yes, my hard disk had just croaked—I was hearing the heads skipping across the platters in my hard drive. The machine would not reboot, nor could I access any data on the drive. After a few seconds of panic and terror, I tore open my desk drawer and cradled what at that moment was my most prized possession: a recent tape backup of that entire hard drive. The next morning was a flurry of intense activity. I notified clients of a brief delay. I contacted my computer manufacturer (the disk was under warranty) and demanded a new hard disk—of course, it would take 10-14 days. I ended up running out and buying a new disk, installing it, reinstalling all my software and restoring most of my precious work from that tape. Eventually, the manufacturer replaced the dead disk.
The moral of the story? Disasters can and do strike ordinary people doing ordinary things on a computer. Your responsibility is to be prepared. In my case, the hard drive crash was softened from a disaster to an inconvenience, all because I had that backup tape. Fortunately, Linux comes complete with a set of utilities that make backups safe, easy and reliable. Plus, several commercial and free software options exist to automate and simplify the backup process. Ideally, backups should be performed daily. In reality, doing a full backup about twice a week is a reasonable schedule for most SOHO users. Plus, if possible, store every other backup off-site. Even if your spouse or parent takes one tape or disk to work and brings back the other one, you are reducing the risk of losing your backup to fire or theft. Never leave your backup media sitting in the backup device.
If you don't have access to a backup program, Linux has several options to tide you over until you get one. Probably the most used is the tar command, which you should have at least an understanding of, even if you end up using a different backup option. Spend some time looking at the tar man page. Check your Linux manual; most give a fairly thorough analysis of this key backup option. At the very least, until you have a more reliable backup routine, copy key files to a floppy using the cp command.
Assume it's 9 AM on a weekday. Your client expects delivery of a key project by noon. You finished it last night at 11:30 PM, after hours of revision and several pots of coffee. All you have to do now is boot up your machine, print out a final copy and fax it off. Except for one little problem: you machine refuses to boot. Only three hours until your deadline—what now?
Linux will rarely choke, provided you are not tweaking with the system or mucking around while logged in as root. However, some hardware failures can sneak up on you. In any case, you must be prepared to act when your machine doesn't want to boot. That means having and knowing how to use a good set of Boot/Root disks, also known as rescue disks (see Resources).
The Boot/Root disk may one day turn out to be your best friend. While a comprehensive set of instructions are beyond the scope of this article, you need to understand how to use them. Many distributions come with a set of boot disks that double as emergency disks, or you can download a pre-built set. In any case, get them and know how to use them before a disaster strikes.
Now that we have covered guidelines for basic system administration, it's time to think about doing some work. Fortunately, the last several months have seen an explosion in the amount of productivity software—both free and commercial—available for Linux users.
As for the Open Source versus commercial software debate, the choice boils down to the preferences and budget of the user. Most users will end up with a hodgepodge of both free and commercial software on their systems. SOHO users, additionally, have their limited time and accountability to clients or colleagues to consider when making their choice. Our advice is to thoroughly check the capabilities of any software you plan to use.
Let's look at an example. Say it costs you $100 to purchase a piece of commercial software and you figure it will take four hours to install, configure and gain familiarity with the product. Now compare that to an Open Source product. While you pay nothing for the software, it may take you ten hours to install and become comfortable using it. Which product do you choose? It's up to you and your priorities. Just remember: Open Source does not always mean free of expenses, while commercial software can never be automatically assumed to be easier to use or of higher quality. Judge each package by its individual merits and make the right choice for yourself.
Regardless of your choice, we believe it is up to us as SOHO Linux users to provide positive feedback to both commercial developers and the kind souls who develop Open Source packages. Linux is the best SOHO/workstation OS on the market right now, but most commercial developers have yet to embrace it with the support it deserves. On the other hand, we can't expect free software developers to fill all the voids left in the Linux software library. By rewarding those commercial developers who do port their software to Linux, we can encourage others to do so; and by using Open Source software, we encourage the type of cooperation that has made Linux the great OS it is today.
Does this mean any one development model is the best option for SOHO users? No, we are merely suggesting that if you do choose to use commercial software for Linux, please be sure to obey the developers' licensing restrictions and give positive feedback or bug reports on the product, if applicable. If you are using Open Source packages, please consider contributing to such development efforts, by donating your own time or perhaps even financially, if you can.
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
- Using tshark to Watch and Inspect Network Traffic
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development