Hacker News new | ask | show | jobs
by loupgaroublond 5326 days ago
Probably the most important thing to know coming from the Windows world is that in Unix (which includes Linux) is that the OS is the IDE. From the way the OS is set up, where and how libraries are stored on disk, how you install things, to using various editors, tools, the command line and compilers, it is an IDE.

When you work with a 'stack' or a runtime like Mono, Python, a JVM, many of these details are partially hidden from view. The same if you use an IDE like Eclipse or MonoDevelop.

The better you understand this, the more shallow the learning curve will be with any tool you use, even emacs or vi.

As for getting started, here's a few pointers. It doesn't matter which distro you use, it's 2011, they all work pretty well. Instead pick the one you're most comfortable with. Mint and Ubuntu are good contenders because they are both easy to use, and Mint is based on Ubuntu. Fedora is better if you absolutely must use cutting edge tech. Suse is great for giving you a shiny frontend, close to cutting edge tools and an integrated environment that's also developer friendly. Just pick one, if you like it, stick with it for six months.

The same goes for runtimes and frameworks. Pick one you like, because a friend recommended it. Try the tutorials. If you like it, and get along with the community behind it, play around with it for 3-6 months before moving on.

Most importantly, find a friend who's using Linux already. Don't pester that person too much with questions, but just chat at least once a week about it. Focus on what you did, what you like, what was difficult. Chances are, your friend will be able to tell you, 'oh, sure, you could just do Foo and get this result'. Part of the learning experience is a week of pain you don't forget, solving it on your own, and then learning that other people solved the same problem.

1 comments

That's an interesting perspective that had never occurred to me. I'll be sure to take note of the subtleties of installation, the file system etc to see how this OS-as-IDE thing is manifested. To be perfectly honest, I'm not even familiar with how the file system works in Unix. I almost feel embarrassed saying that as a computer science graduate with many years of professional programming experience!

Are you recommending avoiding IDEs completely(in the traditional definition of the IDE, not the OS-as-IDE paradigm you described) to expose myself to Unix as much as possible, or just to have an awareness of what's going on behind the curtain?

Cool, i'm already 95% decided on Ubuntu, so that's no longer a concern. Good to hear someone weighing in with other distros though, you rarely hear of anything beyond Ubuntu these days, so thanks for that.

I only really know one Linux aficionado/proponent, so i will definitely be leaning on him when i need to, though as you say i want to put myself through the pain for the purpose of learning and rather than seeking help at every opportunity. Saying that, last time i discussed Unix with him he ended up recommended that i just skip GUIs completely and go for FreeBSD. He must think i'm either a sadist or incredibly brave! Hopefully he won't shun me because of my need for a GUI :)

IDE's are a bit of a closed off garden, to use a bad metaphor. They provide all the components you need, editors, terminals, shortcuts to run commands, but when you learn that you can choose between using an IDE or building up a toolset on your own, then you can make a better choice for the job at hand. There are some really good IDEs out there and once you learn both, it's personal preference. I certainly use both depending on the task.

/bin and /sbin - binary files go here, namely programs /lib - all the shared libraries and other code that gets executed by programs /libexec - other kinds of executables that are not shared libraries or command line programs /src - source code /src/include - all your C headers /share - shared resources, data, game data, pictures, wallpaper, icons etc... /share/doc - documentation /var - runtime data, log files

So what's /usr? These resources get split between / and /usr for historical reasons. There's a push to put everything in /usr and get rid of the split. Go look it up if you want to know why it's this way.

The thing to notice here is there are no program specific directories at the top level. This is because all programs are thought of as small tools or cogs that you can build larger tools upon. It's a system, not a way to run a couple of different apps in their own sandbox.