The on-line issue had hardly been announced before I started getting emails. Most have just been "Thank You" for the article. However some have asked questions and rambled on about related and non-related topics. I think several deserve comments that all will find helpful. So here follows some answers and a few general comments based on your emails.
One of the first emails was titled "win vs Linux", which is not what the article is about. The September 2014 issue of QST - the main journal of the Amateur Radio Relay League for the USA, has my article called "XP to Linux: The "Why" for Hams". My article and several CCII articles on this site are direct responses to an article in the April 2014 issue of QST. In the article "Windows XP - Goodbye Old Friend" by Mike Carper, WA9PIE, it has many suggestions that XP users have only one choice for their old hardware - buy new. My article is intended to refute that concept by showing pre-XP hardware still running Linux and being useful in their old age.
By having my article published by QST, I know that it can get edited and altered in ways that might change how people look at your work. One email in response to my article was titled "win vs Linux", which is clearly not what the article was about, but does show how readers will not always see the results as you had intended. I suspect that Mr. Carper's article was reduced to fit the pages and thus might have lost some of his original thoughts. Whatever the intended focus, the results was a considerable amount "M/S FUD" and not true facts. Several friends came away with the same ideas from the article as I did, the idea being - your only option is to buy new.
My article attempts to show that you can use very old hardware running Linux for a considerable longer period than sellers of new systems would like you to think. I try to make it clear however that risks do exist and as such backing up your data becomes more important as time goes by. Since many users of XP have little knowledge of the extent of support provided by Linux, the idea that you might have to buy a new printer just because M/S dropped XP support is probably believable (from Carper's article). That is far from the truth. Since Linux is over twenty years old and nothing ever really drops out of the code base, feel sure that you will find support for just about any printer or accessories you might have.
Here is another good question.
Most of what I see in the use of computers by hams talks about XP which I haven't had for years. ..... What's so special about XP? And why so much continued use? I use a MAC now.
I guess my first thought is to say - the issues of Linux and XP are considerably complex. For many hams their first and for many more their only computer experience is XP. A large number of hams and businesses are still using XP and simply can not afford to use newer programs than those running on XP. If I were to say what the major problem is, it has to do with programming languages and private source code. Windows is a closed system and as such, programs can't be moved to other OS's or computer programming languages. A major problem for businesses is that their current XP programs that may have cost them thousands of dollar to create or purchase will not run on newer versions of windows. Had they used Linux opensource programs, upgrading would be possible and affordable.
Linux is pretty much open and as such, programs can be recompiled and run on many variations of the OS. Had all the energy used to make XP programs been spent on Linux programs, there would be far more support for hams than is the current situation. The biggest problem is getting product suppliers to support Linux and not do "windows only". Personally, I think if the ARRL selected one Linux distribution and supported it's use, ham vendors would open up more to supporting Linux.
You can find more on that idea on this web site, as well as many How-To articles and explanations about XP/Linux, embedded controllers and such. My favorite Linux magazine is British and called "Linux Format". Each month it has reviews, help columns, and a DVD of programs, distributions, and help files. I suggest you get one copy and see if it helps you get a better start on Linux.
A good way to start trying Linux is to use Virtual Box on your Mac (or PC), download some Live ISO images, and try them in a Virtual environment. Great way to get a start on Linux, in fact, most DVDs from "Linux Format" include instructions on how to do just that.
Linux is the default OS of embedded systems and as such you will need to know Linux to do many projects on a Raspberry-PI. There are many Linux tools that will make learning to use an embedded system easier and more enjoyable once you get past the initial learning curve. Expect 6 months of use before you feel comfortable with Linux.
One email suggested using FreeBSD over Linux. I said the difference in how the kernel identifies I/O is a minor problem for me. Later it occurred to me that many reader might think that FreeBSD is somehow different than Linux in more than just the kernel. This is not really true and thus some explanation is needed.
All Unix/Linux/BSD systems are basically composed of three components. The kernel is the hardware interface and provides standard program interfaces. All the programs and utilities that we think of as the Unix concept compose the main structure of the distribution. Lastly is the special tools that define one distribution from another - think, packaging tools.
In the case of the Linux kernel, it has spawned so much standardization and changes in how OS's are built that it has become a standard way to reference, not only the kernel, but all the Unix tools that come with it. I need to point out that many of the Unix tools are owned by the Free Software Foundation and are in fact free versions of tools that have been used by Unix distributions for the past almost 40 years. This means that any Unix/Linux/BSD/Mac will have the same functional base for the same tools - think, ls, vi, X-windows, ssh, they are all based on the same design specifications. Some of these tools in fact are even in Windows.
What makes each system special is the combination of kernel, Unix tools selected, and the special tools and setups the distro builder chose. The hardware platform only effects the kernel selection, all other tools are built against that interface using standard tools such as "gcc"(GNU C Compiler). A good example of a distro special feature, is how they manage loading of applications. Red Hat uses RPM packages, Debian uses DEB packages, and many others use TGZ, or "tar" and "zipped" source packages. Each distro may also have it's own set of tools for searching and loading packages from repositories. However much the builders try to make it their own system, it still contains a basic set of Unix tools.
So if you choose FreeBSD, be assured that you will be using many if not most of the same tools you will find on Debian or any other Linux based distribution. That includes systems that have different hardware as well. Doing "ssh" on any of these systems, will work the same no matter which combination of hardware, tools, or distributions you use.
The problem is, that I have never been able to get any radio control software to work with any Linux distribution, whether it be Linux format software or Windows software such as my favorite, Ham Radio Deluxe running through Wine, although they seem to install correctly.
My article shows a wine session using the Yaseu PC450 program and what is shown is real. However readers need to know that you will have to setup the serial options and may run into problems related to serial communications. I would get about once out of every four times I ran the program a serial initialization error message that closed the program. Trying again usually worked without any errors. I suspect it is a timing error problem in setting up the serial port and most likely related to my old hardware being a 650MHZ laptop that just takes a little too long in doing things. Your experience using wine and ham programs using wine, will be different than mine, as well as that of other users. There are way too many variables to guarantee success for every user. Consider however, should you have problems, just try the grig program or one of the other ham programs available using one of the built-in Linux package update tools.
Consider as well, that a bunch of us programmers have switched back to true serial ports and stopped using USB to serial adapters. In fact it is one of the reasons I still use old systems that have real serial ports - they work. The typical problem has to do with serial handshake lines. Most USB adapters do not correctly support anything other than just the TX and RX signals. Most ham rigs expect true serial and require some specific state for the other handshake lines. Since each vendor has different state requirements for handshake lines, only full true serial ports will work - buy a cheap pci serial adapter for your desktop and you should fix your problem.
If your vendor supplied a USB dongle, consider the possibility that it might be very special and not just a USB to serial converter. If that is the case, chances of getting it to work under Linux are few, since you would need the special device driver that most likely came with the software for windows. I have as well seen cases where the dongle has a normal serial pin, typically DTR, tied to the 5V USB supply. Without access to the source code or accurate manuals that cover the fine details, it can be near impossible to make sure all the various XP ham programs can be made to work on Linux.
When using wine with ham control programs, you must have a link in your homes ".wine" directory as explained in "man wine".
$WINEPREFIX/dosdevices
Directory containing the DOS device mappings. Each file in that
directory is a symlink to the Unix device file implementing a
given device. For instance, if COM1 is mapped to /dev/ttyS0 you'd
have a symlink of the form $WINEPREFIX/dosdevices/com1 -> /dev/ttyS0.
The above link command is:
cd ~/.wine/dosdevices ln -s /dev/ttyS0 com1If you get an error that "dosdevices" doesn't exist, create the directory using "mkdir". Make sure too that /etc/inittab isn't setting up the device as a console port. I suspect many users never do the link and thus never get things working. If you have done the link and still have problems when using a USB device, try another device, or get a real serial port. Fellow programmers have had the USB problem even on windows machines, and some USB devices are no longer supported under Linux as they proved to be just too flaky and should not be used. I have several devices that fell into that category and no longer use them.
Just got an email from a reader having problems talking to their units in which he solved the problem by changing the serial protocol from two stop bits to one stop bit. It is something that is pretty common, but so often is skipped over - setting baud rate correctly and getting the data bits right along with the stop bits. Windows user may in fact not know what the support software has done to the serial chip, as not all interface software rely on the user getting the settings correct. I have seen on Windows systems, programs when they start, alter the serial settings and return them back to defaults on exit. Thus, the user rarely knows what the real setting values are and you have to hope it is covered properly in the units manual. Linux has stty for finding out the serial devices settings. Try "stty -F /dev/ttyS0 --all" to see all the possible settings currently in use. Use "man stty" for a brief overview and "info coreutils 'stty invocation'" for more details.
Quick note that it is not unusual for Windows to do a check disk after you have re-sized the hard disk. One reader pointed this out to me after it happened to him. Fortunately, he knew it was normal and just waited till done and rebooted. I have had it happen to me, but usually I do checkdisk and defrag before hand, and I feel that often reduced or clears the need for check disk after re-sizing. However I suspect it has more to do with the exact version of Windows your running than anything else.
The same email mentioned 32 vs 64 bit Linux, which I haven't really covered, since all XP systems would have been 32 bit. You will need to download only 32 bit images for XP systems. All new systems are 64 bit and as such, almost all distros by default come as 64 bit. If it doesn't explicitly say 64bit, most will, assume it is unless otherwise noted. Most special versions for older systems will be 32bit and some will be for pre-686 CPUs. There are still some people who need real i386 support, but most will work with 486/686 support. Typically the installer can see the difference and will use the appropriate Linux kernel. However, in the case of Debian, they list the 32bit as i386 and there is no 486/686 releases. The default i386 is actually 486/686 and not a 386 support kernel. I might note that just about any 686 or better, with 1 MB of ram will be a great system and work much better than it did running XP.
Since all users work differently, I can not stress enough for users to test drive Linux before installing. Try "distrowatch.com" for reviews and live images to try. Use Virtual Box to test drive images without burning disks. Check with friends and other Hams to see what they like and if possible let them explain why or what they like the most about Linux. Have them as well show you some great and bad features so you get a more balanced experience. Consider a ham club meeting specially for Linux. It is not for everyone, but there has been considerable effort by all distro builders to make it more user compatible than past releases. It deserves a new try for those that found it wanting in the past.
I got the typical "Linux doesn't have device drivers" email and my response is true, for several reasons. The first and main reason is that a better method is to base device support around the actual chip set being used and not the vendors thoughts. This means that Windows device drivers will not work, although some network drivers can use the network interface tool, that like wine creates the look and feel of windows networking driver support and thus use windows drivers. However that is a special case and normally vendors chip sets are supported. You will find this is the case for most USB to serial adapters. There really are only three or four makers of USB to serial chips, although products on the market are many more than that.
So typical Linux driver support is based on openly available chip set documentation and not anything a single vendor has supplied. This works fine, except for vendors who put tweaks in their products to spoil Linux support. Yes vendors try to make sure that other vendors and users - like Linux users, can not use their product on anything other than windows using only their drivers. This is and will always be a running battle between vendors who consider everything they do private and M/S who tries very hard to make sure Linux doesn't get the support it deserves. However, products like the Raspberry-Pi, which has sold over a million units, is quickly changing lots of views about keeping product information a secret. Clearly the Raspberry-Pi would not be a success without free access to product information.
An email asked "How do you change the default boot order on the menu after an install?" I usually edit the /boot/grub/grub.cfg, but that means re-editing every time you update. The correct way is to edit the /etc/default/grub file.
Run this: info -f grub -n 'Simple configuration' In /ec/default/grub, change GRUB_DEFAULT=0 to the number representing the item you want booted by default. If windows is the #3 item, then it is GRUB_DEFAULT=2.But read the above "info" - it explains other options as well. On the same topic, should you need to add commands to the boot up process, you add them to the default/grub file. I have seen it now several times where the system will start booting and then goes blank and nothing seems to work. What happens is a screen mode shift, typically from 40x25 resolution to 80x50, in which the video chip basically locks up. You fix that by replacing "quiet" with "nomodeset". You will need to run "sudo update-grub" to add the changes, but it should fix the problem. You may need to do it from the grub command line the first time after a new install, since the locked up video chip will not give you any way of doing it. Keep in mind that you can remotely log into the system and make the changes as well.
Unix/Linux systems have always been about remote or absent users. Unlike Windows which has always expected an operator sitting in front of the console ready to click on some pop-up, Unix/Linux systems work on the idea that no one is sitting at a console waiting for things to happen. Hams using Linux and radios located in another room, can use many of the normal built in tools from Linux to remotely control operations. The simplest of the tools is "ssh".
Before security was a concern, "telnet" was the normal remote terminal tool of choice. "telnet" allows you to connect to a remote server over the internet as if you were at the console of the system. This is a "terminal" connection and in the old days might actually have been a teletype terminal. Today however, security is very important and most Linux systems have telnet turned off or simply not installed. In it's place is secure services, with "ssh" as the secure version of telnet. The package is normally part of "openssh", which also includes sftp, the secure file transfer protocol.
If you do "man ssh" from a terminal session, you will see many options and variations that "ssh" can perform. For hams wishing to run "fldigi" remotely, the "ssh -X the.ip.of.remote fldigi" command line will log you into the remote system, start fldigi, and return the graphic display to your local system for display on your screen. There is nothing special about this function, it is a normal usage of ssh, typically used for running remote mail program, system setup processes, anything that uses a graphic display. The above command will exit when you "quit' the program. Using "ssh the.ip.of.remote" provides a regular terminal session and will give an error message if you try to start a graphic program. When logging in to a system in which your user ID is different, just add your remote ID to the address - like this: "ssh remote.ID@the.IP.of.remote".
The advantage of using this "ssh" over "vnc" or "remote desktop" programs, is simply the amount of data that gets transferred. By not trying to keep an entire desktop display synced on both server and client, the network traffic drops considerably. This is true as well for simple command line activity as compared to a graphic display interface. When controlling and working on remote systems half way around the world, waiting for a graphic display to update can make a simple task impossible. Yet, knowing the command line entries to do the same task, allows you to quickly accomplish your work. It helps to know that in Linux, almost all programs are actually command line based, and the graphic functions are but wrapper utilities to the same application.
When using "ssh -X", it caused some concern to one user. The concern was using it from a x86 to a ARM (RasPi) and the reverse direction as well. The answer is of course no problem, since it is client server protocols. Unlike windows, Linux is Linux no matter what the hardware platform is. Linux programs are basically hardware neutral. You can install the same version of Debian on over ten different hardware platforms and it will work the same. The client server concept is about one system being the client, say your desktop running Firefox ( a client) and another system being the server (web server sending data back based on HTTP requests). Client makes a request to server, server responds. Using "ssh -X IP.of.remote.host" is a client request to start an ssh dialog with the server ( the IP.of.remote.host) and "tunneling" any X-Windows data back to the client. The Server need not be actively running "X" at the time, as ssh provides the normal hooks/system calls to the program as if it was a local graphic display. The client session however must be running X-windows for graphics to work.
It is important to understand that Linux and Unix are pretty much standard based and as such can communicate easy from one system to another, even if those system are not exactly the same. For years I ran Linux and used it to provide admin support to many different Unix systems (14 types). I could do that, because all the systems used well know protocols like "ssh" and in fact many were based on the exact same source code base, even when the hardware was completely different. This is still true today that you can do cross compiles, manage completely foreign systems, and talk between different versions of Linux without problems. All the tools and programs used by Linux are standards based and unlike M/S which tweaks the standards, there is generally no compatibility issues - except when talking to windows.
Fldigi works using "ssh -X" because it has a straight forward display of what is happening on the remote system. The remote system is doing all the interfacing and was setup and tested by sitting there at the remote console and making sure it all worked. For my home system, I use the SignaLinkUSB sound card adapter and a real serial interface. I have found that true serial ports work better than USB/serial adapters, and as such I control my rig using the Linux ttyS0 interface. There are programs that will allow remote clients to use both the USB and serial interfaces on a remote server, they are "usbip" and "ser2net". By using these programs you can make your main system, think it is directly connected to your rig and not using the internet.
Both of these protocols are not encrypted, and thus would need to be used on a private network that is isolated from the internet. You can however use ssh tunneling protocols to encrypt the data for usage over the internet. Use "man ssh" or search the web for help on "tunneling over ssh" if you need to do that. Both of the protocols are not normally loaded on Linux installs and so you will need to install them using the package manager of choice. Both the client and server will need to have the packages installed as both ends of the connection are needed and part of the installed packages.
I would be remiss if I didn't mention cygwin, as it can give you all the normal tools and much of the experience of Linux on a Windows machine. I have been using cygwin for years at work places that require and use windows machines. "cygwin" is basically all the normal Linux tools compiled to run and use normal M/S windows systems. The build factory I worked on, had the forty Windows servers all setup with cygwin and used normal perl scripts to manage the building. Since windows can not have more than one instance of their compiler running at a time, we used a perl queue system to feed tasks one at a time to the compiler. We logged in using cygwin ssh, started tasks using perl scripts, and transferred data all using normal Linux tools on windows machines. Go to the above web site and follow the instructions to load cygwin to allow your Linux systems to better manage windows machines.
Several commented on Adobe flash problems and I found the Debian AMD64 FAQ site had an extensive discussion about it. Please go to it for more details, however it seems the real problem is that Adobe is ever changing the flash protocol and as such it has become impossible for free Linux tools to keep up. So the Debian group now provides in "contrib" a recent version of the Adobe non-free support. If your package manager is correctly setup to use both "contrib" and "nonfree", you can follow the steps listed on the FAQ page. Keep in mind that the tool is 32bit and thus you might need to install several support packages as well.
Two final topics that I think are important for readers to understand. The first has to do with making sure you come away from these articles thinking that Linux is a solid and trouble free operating system. I spent considerable time talking about fixing this or that problem that users might encounter. Let me make clear that I have installed hundreds of systems and only had a few not go smoothly. For most users, installing Linux will be simple and straight forward with no problems encountered. XP hardware however, is old and may be buggy and thus I expect a few more problems with those systems than is normal.
A good example of a more recent problem is the "nomodeset" issue. It is important that you understand that this issue is not a Linux problem, but a hardware or design issue where vendors are cutting corners and not implementing a fully functioning VESA interface. The fact that Linux tries to change the display from 40x25 to 80x50 should never be a problem. VESA is a video display standard that all BIOS systems should be supporting correctly. What is happening only shows that vendors are not always supporting standards and since Linux is written based on all the openly available standards, it will from time to time find the non-standard issues. Keep in mind that almost always, there will be some work around for vendor induced problems. Linux is great for working around vendor created problems.
Lastly is to explain a common statement often made about Windows - "it is not a real operating system." Now this is a true statement and in fact it is probably what has made Windows so successful. By not being a real operating system, the user does not have to be computer literate. The skill set required to use Windows, or for that fact a smart phone or tablet, is as little as the developers can make it. On the other hand, it also means that what can be done is very limited. You can do only what the developers will allow you to do, and not what a true operating system is capable of.
Unix/Linux/BSD/Mac are true operating systems and as such, once you learn how they work, there is nothing you can not do with them. When you install Linux, you are turning your little bit of hardware into a full mini-mainframe system. You have a huge selection of software available, can create your own programs, can have dozens of users running the same program at the same time, and you can talk and control systems any where in the world, all from your keyboard. This is a pretty big thing to do, but it does require that you learn and know what you are doing. For those not wanting to learn, buy a tablet, no skills needed there. If you enjoyed the days of using the DOS command line and creating little programs that were your own, then learning and using Linux is for you.
I hope this all helps you make good choices and better understand what Linux and computing in general is all about. For Linux users, it always has and always will be about "choice" - the ability to make your own choice of just about everything related to how and why you use your computer.
http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt or M/S FUD
The Debian "all about Linux" starting point
The Debian "List of official ports" - think hardware
The Debian AMD64 FAQ - think help for "flash" and more
The Free Software Foundation - owner of GNU tools.
A good discussion of GNU, with many links to related topics.
Web site that rates and reviews distributions of all types.
Puppy Linux, great for very old hardware, runs from RAM only.
RoboLinux - designed for XP users with special XP VM software.
Download The Robolinux Virtual Machine "VM" Software for Ubuntu.
Zorin - a beginner friendly i386 distro..
OpenSUSE distro, has live and special versions, their YAST setup tools are terrific.
Get Virtual Box from here for Windows XP and later, MacOS, and Linux.
Live example of XFCE i386 400MB image - with install.
List of sections in "wheezy" repositories.
Debian's Live CD WIKI page - great place to start!
Debian Live systems main page - docs and image builder.
Debian Live-build manual page - all you need to know about live images!