🔒 Locked

Best Linux intro for experienced programmers

Started by cache_hit Mar 27, 2010 at 12:46 PM 24 replies 3.4k views

Original Post

Mar 27, 2010 at 12:46 PM

I come from a windows background. I've used linux some, but I still feel crippled in general. I know most of the very basic tools and commands (grep, ps, ls, cat, etc), I can do really simple stuff in vi, I know how forks, pthreads, etc work. Does anyone know of a tutorial or book that is specifically designed for programmers to get up to speed on linux quickly? Sure, I can just play around and do what I've been doing, but I know there's got to be something out there like this. I've googled, and most tutorials are aimed at things like system administration, setting up networks and firewalls, configuring hard drives, etc. That's great, but not that interesting at the moment. If anyone has some recommendations I'd appreciate it.

Guthur

Mar 27, 2010 at 1:14 PM

I think the organic development of knowledge isn't a terrible approach. Linux isn't some sort of alien technology, thats Lisp hehe. Just select the appropriate tools for what you wish to accomplish and what feels comfortable for you.

There is more GUI oriented tools if you prefer that to the likes of Vi or Emacs; Geany and Eclipse for example.

A bit of familiarity with make might be worth gaining, or other software construction tools such as SCons. I tend to just fire up google when I need to learn about something or use the man pages.

apefish

Mar 27, 2010 at 1:49 PM

There are resources on programming for the individual parts, but GNU/Linux is so diverse that you have to be more specific about what you are trying to learn. Like are you trying to make Gnome apps, or KDE apps, or generic Qt or GTK stuff, or just POSIX programming, or talking to the X-server, or are you kernel hacking.

cache_hit

Mar 27, 2010 at 4:10 PM

I'm not so much interested in the actual programming of *nix, as like you said there are plenty of resources for that, and actually I'm not very uncomfortable with that. What I'm uncomfortable with is just getting around. Using all the tools that programmers typically need, managing my system the way programmers typically need to in order to be productive, that kind of thing.

Quote:
Just select the appropriate tools for what you wish to accomplish and what feels comfortable for you.

That assumes you even know what tools are available to you in the first place. For example, I know about strace because I asked someone at work once what could be wrong given what I was experience, and they were like "oh just use strace". Worked great, but I wasted a lot of time because I didn't even know it existed. But instead of sitting on a forum asking every time I have a bug in my program what's the best way to debug it and learn about a different new tool or trick every time in the process, it seems like stuff like this should have all been compiled somewhere for people in a similar situation.

outRider

Mar 27, 2010 at 5:56 PM

Quote:
Original post by cache_hit
I'm not so much interested in the actual programming of *nix, as like you said there are plenty of resources for that, and actually I'm not very uncomfortable with that. What I'm uncomfortable with is just getting around. Using all the tools that programmers typically need, managing my system the way programmers typically need to in order to be productive, that kind of thing.

Quote:
Just select the appropriate tools for what you wish to accomplish and what feels comfortable for you.

That assumes you even know what tools are available to you in the first place. For example, I know about strace because I asked someone at work once what could be wrong given what I was experience, and they were like "oh just use strace". Worked great, but I wasted a lot of time because I didn't even know it existed. But instead of sitting on a forum asking every time I have a bug in my program what's the best way to debug it and learn about a different new tool or trick every time in the process, it seems like stuff like this should have all been compiled somewhere for people in a similar situation.

There's no substitute for experience. Did you pick up everything you know about developing on your platform of choice from a book or from actually using said platform to develop day in and day out and accruing knowledge incrementally?

cache_hit

Mar 27, 2010 at 6:39 PM

Quote:
Original post by outRider
There's no substitute for experience. Did you pick up everything you know about developing on your platform of choice from a book or from actually using said platform to develop day in and day out and accruing knowledge incrementally?

I'm not disagreeing, I'm just saying that it seems like a compilation of tools / commands / tricks that programmers find themselves often needing would be something that tons of people would probably find useful, so I'd be surprised if something like that didn't already exist.

Guthur

Mar 27, 2010 at 8:24 PM

Well GNU is the standard tool chain, you could see what it has to offer first then look for alternatives if required/desired.

There is such a wealth of development tools for Linux, I keep learning about knew things all the time.

Yann L

Mar 28, 2010 at 4:44 AM

Quote:
Original post by cache_hit
I'm not disagreeing, I'm just saying that it seems like a compilation of tools / commands / tricks that programmers find themselves often needing would be something that tons of people would probably find useful, so I'd be surprised if something like that didn't already exist.

As long as you don't want to actually program the system itself (Gnome, KDE, the kernel, whatever), there isn't that much difference from Windows anyway. This assuming you're using a modern IDE. I'm doing most of my developing under Linux, and all I use is an IDE (Netbeans in my case), obviously gcc and friends, Midnight Commander (couldn't live without that one), the usual command line tools you already know about, and all in all that's about it for system specific stuff.

Now, if you want to actually program for Linux, rather than simply on Linux, then you need to dive much deeper into Linux specific APIs. If you don't, then there isn't much need to except for POSIX, which you should know about. Everything else comes with experience.

Quote:
Original post by Guthur
Linux isn't some sort of alien technology,
[...]
the likes of Vi or Emacs;

Remember that movie Event Horizon with Sam Neill ? Remember that alien dimension of pure evil the ship went to at the end of the film ? That's exactly where Vi and Emacs come from (and the autotools too)...

cache_hit

Mar 28, 2010 at 10:18 AM

Quote:
Original post by Yann L
Quote:
Original post by cache_hit
I'm not disagreeing, I'm just saying that it seems like a compilation of tools / commands / tricks that programmers find themselves often needing would be something that tons of people would probably find useful, so I'd be surprised if something like that didn't already exist.

As long as you don't want to actually program the system itself (Gnome, KDE, the kernel, whatever), there isn't that much difference from Windows anyway. This assuming you're using a modern IDE. I'm doing most of my developing under Linux, and all I use is an IDE (Netbeans in my case), obviously gcc and friends, Midnight Commander (couldn't live without that one), the usual command line tools you already know about, and all in all that's about it for system specific stuff.

I guess, but if you talk to any Linux guru they'll tell you that they are much more comfortable with the command line and prefer not to use tools like that. Even when they do, they're going to be tons of stuff at the command line.

I'd like to be able to think about things in the same light ideally. For example, take a look at this link:

http://www.devbistro.com/tech-interview-questions/Unix.jsp

In the first section I know 4/29, in the second section I know 2/16, third section 5/5, fourth section 2/5 for a grand total of about 20%.

Pretty embarassing, but most of it sounds like fundamental information that most programmers should know.

It's not that I have no idea where to find information like this, and yes, a lot comes from experience, I was just hoping that the *most relevant* information for programmers would have been compiled somewhere or someone would have written an intro to linux specifically for programmers coming from a non-linux background. If nothing else to reduce the amount of stuff I have to wade through to find information that's relevant to me.

Yann L

Mar 28, 2010 at 10:47 AM

Quote:
Original post by cache_hit
I guess, but if you talk to any Linux guru they'll tell you that they are much more comfortable with the command line and prefer not to use tools like that.

A lot of old school Unix developers grew up with command line tools and just feel comfortable with them. That certainly doesn't mean that they're better than a modern IDE. In fact, objectively seen, they're inferior in many ways. Also keep in mind that not so long ago, there wasn't any good IDE on Linux. So it's a rather newish concept for die hard Unix developers, and many of them have a hard time adapting. Don't feel bad because you use an IDE instead of running everything from the command line. Modern software engineering under Windows would be almost unthinkable without MSVS, after all.

Quote:
Original post by cache_hit
Pretty embarassing, but most of it sounds like fundamental information that most programmers should know.

Most of these, except for the general programming questions, are actually pretty irrelevant unless you want to do Unix administration.

In the end it depends on whether you want to use Linux as a development platform, or if you want to "embrace the Linux/GNU philosophy". In the former case, just install a good IDE, program away just like under Windows, and everything that you will need will come in time, with Google and with practice. In the latter case, well, then I am certainly not the right person to talk to ;)

theOcelot

Mar 28, 2010 at 6:00 PM

autotools aren't that bad if you know what you're doing. It's getting to know what you're doing that's the hard part. The same could be said of vi and emacs.

I'm only slightly further on the road to linux proficiency than cache_hit; I don't even really know grep. But if the hard part is knowing where to start, I'd suggest looking up these commands. They're just some of the useful ones that I learned (or wished I had learned) first.

mvcplntardateexportgcc/g++ and friends -- good to know how to use from the command linekillpstop

That, and look into how I/O redirection and task management work. I'm not sure if that's the level you're looking for.

Edit: On second thought, maybe I'm a little behind.

Guthur

Mar 28, 2010 at 6:39 PM

Quote:
Original post by Yann L
Also keep in mind that not so long ago, there wasn't any good IDE on Linux. So it's a rather newish concept for die hard Unix developers, and many of them have a hard time adapting.

Emacs can be your IDE, a mode can be created for just about any task, indeed it is my IDE at the moment. I actually use Emacs to get access to just on such mode, SLIME, for Common Lisp development, SLIME is awesome by the way if anyone is interested.

I came from the GUI driven IDE, MSVS, to Emacs and I find it actually ok in comparison, admittedly the learning curve was steep but thats not really relevant because if you want to carry out complex tasks you are going to need complex tools (MSVS has its fair share of complexity too) and high level of knowledge, you don't start of in mathematics for example with differential equations, you have to build up your knowledge base.

The thing is you need the keyboard more than the mouse, if you are actually doing any coding, so why would you want to be removing your hand from that device to make use of all the GUI elements. People will say use shortcut keys but then why do you have all the GUI widgets in the first place, except to require a huge monitor or even two.

The winform designer in MSVS is pretty good though, and when creating small GUI driven apps it is hard to beat.

[Edited by - Guthur on March 29, 2010 4:39:06 AM]

phresnel

Mar 29, 2010 at 3:04 AM

Quote:
Original post by Yann L
Now, if you want to actually program for Linux, rather than simply on Linux, then you need to dive much deeper into Linux specific APIs. If you don't, then there isn't much need to except for POSIX, which you should know about. Everything else comes with experience.

Or, of course, use portable technology. By now, the most complete one for application development that I have discovered (after tinkering with wxWidgets, gtk, and some more in the past) is Qt, where I use char-by-char the same code on Linux+Windows.

Kasya

Mar 29, 2010 at 3:38 AM

I use MAKEFILEs for creating projects in my Linux. That is because i have a small display on my netbook, and thats why there is little space for coding because of the IDE specific windows like build window, solution explorer, class view etc. If you have a larger display (i hope you do :) ), you can just use IDE. But you have to learn for which Desktop Environment (GNOME, KDE, GTK+, QT, X-Window) are you programming.

deadstar

Mar 29, 2010 at 3:41 AM

The only tools I really need are Code::Blocks or KDevelop, gcc, SDL, OpenGL and cg libs, and most importantly: man.

Everything else is just a luxury.

phresnel

Mar 30, 2010 at 12:33 AM

Just looked up history ...

414  cd Desktop/  415  mkdir faco  416  cd faco  417  scite main.cc &   418  g++ main.cc   419  g++ -ftemplate-depth=32768 main.cc   420  g++ -fftemplate-depth=32768 main.cc   421  g++ --ftemplate-depth32768 main.cc   422  g++ -ftemplate-depth32768 main.cc   423  g++ -ftemplate-depth-32768 main.cc   424  g++-4.3 -ftemplate-depth-32768 main.cc   425  /usr/local/gcc-4.5-20100306/bin/g++ -ftemplate-depth-32768 main.cc   426  cd Projects/picogen/git  427  git status  428  git add .  429  git status  430  git commit -m"can change spectral sample count now (but spectrum is not conserved/converted yet)"  431  git status  432  git add .  433  git status  434  git commit -m"initial check-in of ImportRawDataWizard"  435  git status  436  git add qt-frontend/  437  git commit -m"add first page of raw-import-wizard"  438  git add gtodo/  439  git commit -m"add two tasks"  440  git push mirror0 master ; git push origin master  441  cd Projects/picogen  442  cd git  443  git status  444  git add qt-frontend/  445  git commit -m"Spectral importer: can import several layouts now"  446  git status  447  git diff  448  git add .  449  git commit -m"Spectral importer: simple unit conversion"  450  git diff  451  git status  452  git diff  453  git status  454  scite .git/info/exclude   455  git status  456  git add qt-frontend/  457  git commit -m"Spectral picker: enable capping of input amplitudes"  458  git add gtodo/  459  git commit -m"add two bugs"  460  git push mirror0 master ; git push origin master   461  cd Projects/picogen/git/redshift/  462  scite src/basictypes/spectrum.cc &   463  scite include/basictypes/spectrum.* &  464  make lib  465  scite include/basictypes/spectrum.* &  466  make lib  467  cp obj/quatsch-integration.o .  468  make clean  469  cp quatsch-integration.o obj/  470  make lib  471  git status  472  git diff .  473  git add .  474  git commit -m"add function SpectrumBase::FromSpectrum"  475  git status  476  git add ../qt-frontend/  477  git commit -m"SpectralPicker: does import raw data into main screen now"  478  git push mirror0 master ; git push origin master  479  cd Desktop/  480  wget -c   481  wget -c http://download.virtualbox.org/virtualbox/3.1.4/virtualbox-3.1_3.1.4-57640_Debian_lenny_amd64.deb  482  cd /home/smach/Desktop/Photograps-Sorted/pruned/20090707/6092-6110  483  mogrify   484  mogrify -rotate  485  mogrify -rotate 90  486  mogrify -rotate 90 *  487  cd /home/smach/Desktop/Photograps-Sorted/pruned/20090707/6453-6483/6461-6470  488  mogrify -rotate 90 *  489  cd   490  cd Projects/picogen/git  491  cd  492  cd -  493  git status  494  git add qt-frontend/  495  git commit -m"Spectral picker: can edit wavelength"  496  git status  497  git commit -m"Spectral picker: have a min/max amplitude value"  498  git add qt-frontend/  499  git commit -m"Spectral picker: have a min/max amplitude value"  500  git push mirror0 master ; git push origin master  501  kill -9 redshift  502  history

Hehe. So my most use commands are:

git ...tig    - awesome frontend to git (inside shell)cd     - change directoryg++    - teh compilerar     - make a libman    - teh helpmake   - teh compilecp     - copy file/directorymkdir  - create directoryscite  - most awesome 'modern' editor of all timesls     - view directory contentsgrep   - search stuffcat    - dump stuffclear  - clear screen (if you type clear twice it  will also add                        a complete page break, sometimes very handy)wget   - downloading for real men/womenhistory - show what you have typed recentlykill   - kill process

GUI-wise I use QtCreator when developing apps, Code::Blocks when I am on windows (I would use it more often, but Makefile integration is, non-existant) where command line sucks (except when you have MSYS or CYGWIN handy), Tortoise-Git (when on windows). Iceweasel for the browses (slightly modified version of firefox, but mozilla people are angry about debian making it safer, so debian had to rebrand it). gtodo for keeping track of todo-items. VirtualBox for porting businesses and running Linux-incompatible hardware. gcalc is my calculator (roughly 1000^2+5*3 times better than window's crappy calculator (gcalc users will understand my pun)). For the sounds I run last-exit, rythmbox or amarok (but I am moving away from amarok, as I don't like the new version, and the old one is not really maintained anymore). Oh, and of course I use deskbar-applet. Desktop is GNOME, GUI-shell of course Nautilus with fuse installed, so that I can use ftp directories as if they were local.

[Edited by - phresnel on March 30, 2010 12:33:23 AM]

Mar 31, 2010 at 5:11 AM

Quote:
Original post by Yann L
Quote:
Original post by cache_hit
I guess, but if you talk to any Linux guru they'll tell you that they are much more comfortable with the command line and prefer not to use tools like that.

A lot of old school Unix developers grew up with command line tools and just feel comfortable with them. That certainly doesn't mean that they're better than a modern IDE. In fact, objectively seen, they're inferior in many ways.

Well, that depends on what you are trying to do. If it's coding then yes, I agree, it is inferior since you don't get many goodies like intellisense or so on the command line. But, if it's about system administration, or even just using the system as a normal user, the command line is so much better. In just a few seconds I can do things from command line that would be downright impossible under Windows or that would take you a considerable amount of time to do. Even trivial tasks, like for example, launching a movie, are so much faster from the command line - by the time you would click your way to the movie I would have it already running, thanks to the fabulous BASH tab completion. (Of course, it's a prerequisite that you can type fast. <;)

flodihn

Mar 31, 2010 at 5:22 AM

I do a lot development in Linux, for c/c++ I use scons to compile the code and vim in multiple sessions (using the program screen) to alter the source code.

So just go to your source folder and type "screen". Then start editing you source code, you can create a new window by CNTR+A and toggle between them using CNTR+N and CNTRL+P.

You probably want to read up on Makefiles (but I prefer scons).

phresnel

Mar 31, 2010 at 6:15 AM

Quote:
Original post by u
Quote:
Original post by Yann L
Quote:
Original post by cache_hit
I guess, but if you talk to any Linux guru they'll tell you that they are much more comfortable with the command line and prefer not to use tools like that.

A lot of old school Unix developers grew up with command line tools and just feel comfortable with them. That certainly doesn't mean that they're better than a modern IDE. In fact, objectively seen, they're inferior in many ways.

Well, that depends on what you are trying to do. If it's coding then yes, I agree, it is inferior since you don't get many goodies like intellisense or so on the command line.

Command line tools != programming on the command line. Real men use butterflies anyways. By command line tools, something like a compiler, grep, et al, are meant, and there, "intellisense" (i.e. bash completion) is superiour to what windows offers on the standard shell, which is basically ... well, uhm, not so existent.

Quote:
But, if it's about system administration, or even just using the system as a normal user, the command line is so much better. In just a few seconds I can do things from command line that would be downright impossible under Windows or that would take you a considerable amount of time to do. Even trivial tasks, like for example, launching a movie, are so much faster from the command line - by the time you would click your way to the movie I would have it already running, thanks to the fabulous BASH tab completion. (Of course, it's a prerequisite that you can type fast. <;)

Indeed, but also note that many app-dev's just don't care about proper keyboard shortcuts in their application, which is one reason for this. One of the other reaons is of course that a blown app also has blown startup times. In the time I would type a hello world or some simple example code on my box, MSVC wouldn't even come to the welcome screen, and even if it would, you would have to go "create new project". QtCreator and some other IDEs have a faster startup, but still way slower then
alt-gr + T (shortcut for opening up terminal on my box) mkdir example cd e ; scite foo.cc & ...hack... alt + tab g++ foo.cc

:D

Mar 31, 2010 at 1:44 PM

Quote:
Original post by phresnel
Command line tools != programming on the command line. Real men use butterflies anyways. By command line tools, something like a compiler, grep, et al, are meant, and there, "intellisense" (i.e. bash completion) is superiour to what windows offers on the standard shell, which is basically ... well, uhm, not so existent.

By intellisense I didn't mean BASH tab completion; I meant intellisense - e.g. you type 'object->' in the IDE and a popup appears with every possible member of that object's class. But yes, command line offered on Windows is a piece of crap, which is really a waste, since most Windows developers are living oblivious of the command line's awesomeness. Sure, the learning curve is steep, but with that comes the enormous power.

Quote:
Indeed, but also note that many app-dev's just don't care about proper keyboard shortcuts in their application, which is one reason for this.

When it comes to shortcuts, my gripe with most code editors is their inability to provide a mouse-less and cursor-key-less experience by making a nice remaps of frequently used actions into convenient places. What I love about my editor of choice, Kate, is that it's possible to make that possible - ALT + J becomes left, ALT+K becomes down, ALT+L becomes right, etc. Through the whole of my coding session I don't have to touch the mouse even once and I also don't have to move my hands off the main keyboard to move the cursor. This is extremely efficient and comfortable. And again, since our desktops are WIMP-centric most people are once again shooting themselves in the foot.

But well, I got a little off-topic. Sorry. (:

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.