5 key insights on the transition from Windows to Linux | Opensource.com
5 key insights on the transition from Windows to Linux
When I began my current job at Algoma University as the systems librarian, I really had no idea what I was getting into. Despite a decade in library information technology (IT), I felt nervous over my primary task: to help develop and administer Evergreen, an open source library catalogue system. The problem? My experience was almost totally in the world of Windows.
Initially, I was cautiously optimistic. I had a proven track record of picking up new skills in a hurry, but after about the first three weeks, I realized I was in trouble. How would I make the transition from Windows to Linux system administration? More importantly, how would I do it while on the job? Afterall, I was hired to get work done, not to educate myself on a new operating system. I had my evenings, but being scheduled to take over the project manager role within four months of my arrival, I doubted evenings would get me where I needed to be. In the end, the project survived my tenure as project manager and what follows is what I learned in the process.
Insights for anyone moving from Windows to Linux
Take stock of what you actually do know. I wasn’t completely useless. My Windows background gave me some skills in terms of development. Objects, functions, methods, and basic programming logic are transportable concepts even if the specifics of a language are slightly different. Networking and database management were similar. This was important, because it gave me some bargaining power with my boss. It allowed me to go after low hanging fruit, such as our library’s website—also an open source project, but again, the similarities between web technologies made it an attainable task. Impressing my boss with early results of some kind was critical.
Get your boss on your side. I knew most of my learning would have to be at work rather than just messing around in the evenings, so it would have to be part of my professional development. The argument was easy to make: the time put into learning Linux was an investment. The payoff was opening the library up to the tremendous amount of free and open source software (FOSS) available. That, combined with the work I was actually getting done, made my boss agreeable. He allowed me to take whole days (even a whole week here and there) to dive deep into Linux.
Use Linux all the time. Although there was common ground in the networking and development world, there was almost none in the system administration arena. The only way to remedy that was by using Linux all the time. This was daunting. Just trying to find my way around the Linux file system was hair-pulling frustration, yet work needed to get done. I experimented with different forms of coexistence: Linux virtual machines hosted on Windows; Windows virtual machines hosted on Linux; the Windows Ubuntu Installer (WUBI), formating old workstations. They all have their advantages and disadvantages, but in the end I decided the best setup was to format a workstation as a Linux workstation with a full GUI desktop, and to format a remote server as a typical Linux server. I found keeping a Windows workstation too tempting; it was too easy to fall back into old habits. With this setup it was possible to power up a Windows VM when necessary, but the inconvenience of working on an underpowered VM encouraged me to stick with Linux, regardless of frustrations. The setup gives you the full Linux experience: learning how to connect printers and handle things like email on the workstation side, while also administering a server via secure shell (SSH). Then it was a matter of figuring out how to get productive, especially at the command line.
Learn key commands, develop confidence. The first time I started EMACS, I had to hard reboot the workstation to get out of it. This did not build confidence. If you’re an experienced open source technologist, the commands below will seem facile, but if you’re new, and you’re looking at a Command Line Interface (CLI) prompt that seems to look straight back at you, the first move isn’t obvious. Although people are afraid of the CLI, you can actually become useful (if not efficient) fairly quickly if you know where to start. I recommend the following:
ls, cd, find
The ability to navigate the file system is elemental.
This is important for any kind of real server administration.
This is the easiest way to get your workstation up and connected to the Internet.
grep, tail, vim
These are essential commands for sifting through code and logs.
Connecting to remote servers and moving files back and forth securely is very important.
Making mistakes is learning. Even when things go wrong you’re learning something. I learned a lot about Linux services the first time I updated iptables. When stumbling around to get the new settings to take, I inadvertently shut down the network adapter on the remote server. All you can do at a time like that is hope the people you work with are patient and supportive. Fortunately, I’ve found members of the open source community to be very accommodating.