I need to reconcile these 2 facts:
- 1. I don't feel comfortable working on Linux;
- 2. I need to develop software for Linux.
Some background: I have 10+ years of programming experience on Windows (almost exclusively C/C++, but some .NET as well), I was a user of FreeBSD at home for about 3 years or so (then had to go back to Windows), and I've never had much luck with Linux. And now I have to develop software for Linux. I need a plan.
On Windows, you can get away with just knowing a programming language, an API you're coding against, your IDE (VisualStudio) and some very basic tools for troubleshooting (Depends, ProcessExplorer, DebugView, WinDbg). Everything else comes naturally.
On Linux, it's a very different story. How the hell would I know what DLL (sorry, Shared Object) would load, if I link to it from Firefox plugin? What's the Linux equivalent of inserting __asm int 3/DebugBreak() in the source and running the program, and then letting the OS call a debugger? Why do release builds use something, called appLoader, while debug builds work somehow different? Worst of all: How to provision Linux development environment?
So, taking into account that my hatred might be associated with not knowing enough, what would you recommend? I'm ok with Emacs and GCC. I need to educate myself as a Linux admin/user, and I need to learn proper troubleshooting tools (strace is cool, btw), equivalents to the ones I mentioned above.
Do I need to do Linux From Scratch? Or do I need to just read some books? (I've read UNIX programming enviornment by Kernighan and Advanced Programming... by Stevens, but I could use something more practical.) Or do I need to have some Linux distro on my home computer?
Answer: Lots to Read... (34 Votes)
You might find the article Dynamic Linking in Linux and Windows interesting (it explains how each OS does dynamic linking). The article Shared Library Search Paths explains how the libraries are found. Also Static, Shared Dynamic and Loadable Linux Libraries is very good. A nice thing about Linux libraries is that they have better support for versioning and more versions of a library than Windows (AFAIK, I don't do Windows). See Library Interface Versioning in Solaris and Linux for that. These articles should really get you covered with libraries.
The GDB is very mighty, and a good introduction is probably RMS's gdb Tutorial. You might want to read up on conditional breakpoints. For equivalents to __asm(int 3) see the Stack Overflow question Set breakpoint in C or C++ code programmatically for gdb on Linux.
The book Advanced Unix Programming by Marc Rochkind is a must-read, IMHO. It offers lots of examples and covers all POSIX/SUS topics in a very well-explained way. It's the best book about this topic I've read so far.
But to make your life easier I actually recommend you use a highlevel API that abstracts stuff for you, like Qt. It will also make writing cross-platform a lot easier.
Doing Linux From Scratch helps you get an understanding of how a Linux system is composed, but I think it doesn't much improve your knowledge about it from a developer's point of view. It does, however, make you more comfortable with Linux, as you learn what parts are there in a Linux environment (and also why). A Linux won't be a big blackbox to you after working through Linux From Scratch.
Answer: If you like strace... (9 Votes)
Don't forget ltrace: the equivalent for library calls.
Also, yes, I recommend Linux From Scratch. It's a good exercise in working out the core elements of the OS and how they fit together.
For a modern, complete system programming reference treatment, I'd recommend picking up The Linux Programming Interface.
Answer: Use Your Experience (7 Votes)
Why not develop on Mono with Monodevelop? This would get you started quite easily by re-using your experience in .NET.
Answer: A Shortcut (3 Votes)
Do not force yourself to do something you do not like. Use Windows as your development environment, write a portable code, cross-compile it for Linux, and only test it occasionally in a VM.
Answer: Steb-By-Step (5 Votes)
It's daunting when you look at it from the outset (just like if you were a Linux developer being tasked with doing some Windows development). I would tackle this one problem at a time.
1) First, get your environment setup (compiler, IDE—yes they exist, Netbeans/Eclipse etc.)
2) Next, get the higher level APIs installed (boost/Qt etc.)
3) Start slowly. If there is an immediate problem to solve, get the code compiling (or start writing from scratch). Like you would tackle any development project, get the stuff you know working first (i.e. things that don't need OS specific interaction), and then when you hit a snag—search. I'm sure someone out there has come across the same problem before and resolved it.
Most importantly, leave all your preconceived notions at the door. And no, you don't need to be a guru to develop in Linux, I know enough to get around, but not everything—and I'm comfortable with that...
Answer: An Ode to Linux (6 Votes)
The Mac OS X is like a Mercedes; it's the prettiest and cleanest but it costs a lot. Windows is like a Toyota; it will get you there and back.
Linux is like a hot rod; It's for people to dig into and take apart and put back together again. Linux is not for someone who just wants to use the computer; it's for people who love computers. People who don't love computers should stay away from it.
The stuff you learned in Windows won't translate very well, no. But you get to see the internals and watch the engine run.
Try to take Linux as a new toy, that you can play with and crawl into and see what's going on. Things that are easy in Windows are harder in Linux; things that are impossible in Windows are possible in Linux.
If you love computers you can love Linux; if you don't love computers why are you programming at all?
Think you know the best way to go from Windows to Linux? Disagree with the opinions expressed above? Bring your wisdom to the original post at Stack Exchange, a network of 80+ sites where you can freely trade expert knowledge on topics like web apps, cycling, scientific skepticism, and (almost) everything in between.
reader comments
153