Because the best things in life are free

Learning GNU/Linux For those new to GNU/Linux and Free/Libre Open Source Software (OSS or FLOSS) and the associated communities, some explanations may be in order. How to be part of this community, how to find your way and to make the whole of it work to your advantage. For those who want to jump the background explanation and directly get to the part on how to learn to use your new linux system, just click here. However, to know a bit more about the background may help you to understand why supporting the Free Software / Open Source Community is clearly in your own advantage. Open Source Software community and development First of all, to explain why Open Source Software actually gets developed, I'll paraphrase a quote I once came across (if you have a link to the original quote, please inform me). The situation involved a well respected professional programmer, who had written a driver for an ethernet card. He was asked why he would devote his spare time to write this driver and then give away the code for free, under the GNU General Public License (GPL), for all to use. The point the inquiring person tried to make was that this programmer must be crazy, doing a professional job and giving away the code. His answer (well, paraphrased anyway): "I put in a few evenings of work, and in return I get an 80MB Operating System for free, including the source code, and you're telling me I'm the one who's crazy??" (One of the things I remember is that the quote really did mention 80MB, so this must have been around 1994 or so..) Basically, to develop code as OSS means that developers can work together to create software that is much more powerful and capable than they could have created by themselves, and the GPL ensures that they will always have access to any further developments of their code. So if you want to fill a need the GPL is a great way to get others to contribute to your code; they too will forever be able to profit from their own work. This explains the reason why it is (was) commonly said: "OSS developers write code to scratch an itch," other developers are welcome to join in. On the other hand, if they like their program and a mere user doesn't like it, tough luck. There's not always enough incentive to improve or modify once the developers of the program feel that it suits their needs. There have been some changes of late, in many projects the developers have shifted their aim to develop the best possible solution/implementation. The Linux kernel development is a good example of this, but also high profile projects such as as KDE and GNOME. The FLOSS development shows strong contrast with closed source or proprietary software development, that in most cases is just a means to an end: namely to generate the highest possible income and to assure to be able to do just that in the future. One company very good at that is Microsoft. For those companies, it would almost be the end of them if they would create and market the perfect product (if such a thing could exist). Imagine an Operating System that never crashes and fulfills all tasks perfectly, and the management talking with the designers: "so, what can we design and sell next"? Of course, this is too naive a situation sketch, but still. All the proprietary software makers have to do, is make software that is merely 'good enough', which in some cases is quite abysmal. With a bit (or a big load) of lock-in, they have found that companies are willing to put up with a lot of things. But this article is not about proprietary solutions, so I'll save that criticism for another article. The point I would like to get across is the following: OSS developers are giving the fruits of their efforts away for free, for all to use. Most of them do not get paid for their efforts, or at least, not by you. They often do aim to make their program the best it can be. So your complaints may not always be welcome, but your bugreports (especially of reproduceable bugs) very often are. In many (most?) cases, extra developers are welcome to join a project. You can contribute in other ways too, if you're not a (good) programmer, you could help out with the translation or the documentation. Check the project homepage for these kinds of things. Sometimes, financial or other donations are possible. OSS is free of charge, but money makes the world go round. If you like some program/project, please think about contributing to it. If you like your distribution, buy a copy or, in the case you use and like Mandrake Linux, become a clubmember. If you don't have the money to spare, contribute in any other way: by promoting the use of OSS, by writing code, writing and / or translating documentation, helping (supporting) people in real life or on mailinglists, forums, etc. Troubleshooting, problemsolving Many of the difficulties and problems that people encounter when starting out with Linux are due to being unfamiliar with the system. In other words, the problem is not with the system, but with the user. This is sometimes referred to as 'operator error'. If things don't behave as you, as a novice Linux user, expect or would wish, that doesn't mean they are wrong - even if it means that you may take a bit longer to get used to things. The standard system behaviour is well thought out, and the complexity and flexibility of the whole implies by definition that there is much to learn. One example: logging in graphically as root is not a good thing. You are free to educate yourself as to the how and why. The Mandrake developers have made it more difficult (but not impossible) in Mandrake 9.1 to log on graphically as root. Kudos to Mandrake for trying to get people on the right path, this is a Great Thing (tm). You can still log on graphically as root (it is Linux, remember) - but don't complain if it's not so straightforward to do, and definitely don't complain if due to this at some point you end up with a broken system. So if the system doesn't behave how you think it should, don't complain, but figure out why it does behave that way. This being said, it is clear that many pieces of software, OSS or not, have bugs. I will not contradict that you can easily run into some of these bugs, instead I want to explain how to deal with bugs and other problems with Open Source Software. The 'other system' troubleshooting paradigm mainly consists of the Three R's: Retry Reboot Reinstall and in case that didn't solve the problem, there's always ... the Three R's. Many novice Linux users still suffer from this paradigm, as some observation on some mailinglists or forums will easily show: "I even rebooted..." or worse: "I reinstalled the whole machine, twice... ". Also, replies to people with problems along the lines of: "yeah, well, you should use another distribution / window manager / desktop manager" are often due to this wrong mentality. I'd now like to present the OSS troubleshooting paradigm, which I like to sum up with the following Three C's: Check Communicate Correct by which I mean the following: Check whether your problem is not just an operator error; this is very often the case, due to unfamiliarity with the system the user falsely expects it to behave differently than how it was designed. These errors were (I do hope my speaking in the past tense is correct in this case; at least it should be) often answered with: RTFM (Read The Friendly Manual) or UTFS (Use The Friendly Search) (note that I prefer to use another f-word than is usually aimed at in these acronyms). Your check should start at the manual page or documentation, and can include any or all of the following: acquaintances who have experience with the program at hand, the project website, google, newsgroups, forums. Communicate to see if others (possibly including the developers of the software in question) are having or are observing the same problem. If they have, see how they managed to solve it, or at least, work around it. It may be that you have come across a bug that cannot be fixed directly. Again, you may use any or all of the following: newsgroups, project mailinglist, forums. Note that even if you haven't purchased the program, software vendors will still appreciate your feedback and bugreports - if they can fix the problem they will, since you are not likely the only person with this problem. As a last point in this process, you can correct the problem on your own system (either because you've just found out it was an operator error, or fix it as per the feedback you got in the former step) and / or the developers of the software can and should correct the problem by fixing the source code, in which case a next pointrelease (or for the more daring: the CVS code, which is the code in heavy development) will include the fix. With proper application of the Three C's, OSS continuously gets improved, and you get rewarded for your effort: in the next version of that certain program your problem will have been fixed. Also, please realise that if there is a persistant bug that you have trouble with but apparently doesn't get fixed, and you didn't follow the Three C's, you have no-one but yourself to blame. You may consider this one of the costs of OSS. One of the great things of OSS is that the source code is freely available, so you don't depend on those few developers of one specific software vendor who fix bugs, and if the root cause is found you don't have to wait for the next big release. And best of all, you don't ever have to pay for that next release in which your problem is solved. Learning to use your Linux system To get started on learning how to use your shiny new Operating System, I'd like to propose the following: read the documentation that came with your system. Yeah, I know it's a real shocker, but few people actually ever pay attention to that. For instance, in Mandrake you go from the start-button to Documentation, then select the Howtos. Many programs also have their own built in documentation. KDE for instance has excellent online help files. OpenOffice.org is another group of programs with extensive online documentation. You may also use konqueror to read manual pages (manpages) for commands and programs, just enter man:/[command] in the location field (if you use KDE and click the Home icon on your desktop or panel, konqueror will show up with file:/home/[yourusername] which you can then change to man:/[command]; if you are currently using konqueror to browse this page, you can also just click the above link). Of course you have to substitute [command] for the command or program you would like more information about. You can of course also read the manpages by entering man [command] into any terminal window. I know that for people who are not familiar with manpages, they come across as cryptic, mostly due to their scientific format, but after getting used to them, one quickly realises manpages are a very welcome and powerful part of the GNU/Linux system and software. An alternative that is generally considered easier to read for the novice, and which may or may not be available for a program you want to know more about, are the info pages. In konqueror: info:/[command] or on the command line: info [command] will get you plenty of information about the use of certain commands and programs. To find out more, you can also read books, magazines and websites, search the web, newsgroups and forums. And most of all, if you get stuck, remember the Three C's. Note that I use the terms Free Software and Open Source Software to denote the same thing, and I don't want to go into the differences of these terms from a philosophical standpoint. The term 'Free Software' stresses the fact that the code is free in the sense that the user can do with it as he/she pleases, but it's somewhat confusing since it can still be charged for. 'Open Source Software' stresses the fact that the source code is available, but from the term it is not clear that the user can do with it whatever he/she wants. 'FLOSS (Free/Libre Open Source Software)' leaves less doubt but also requires some explanation and is a bit long... Maybe 'Freedom Software' (what 'libre' actually hints at) should be used... Next to the GPL, there is also the BSD licence, which is less limiting in the sense that closed source may be based on BSD licenced code, without opening it. Stephen Pinker has explained here why that is less beneficial for the FLOSS community. Page first created: May 2003. Page last updated: Jul 5 20:41 2003