Linux Programmer's Toolbox 241
Ravi writes "What does it take to start writing programs for Linux? Most people will guess a text editor, knowledge of a programming language, the compiler and libraries of that language. Ask a professional programmer and he will differ with you. Insisting that while those things can help get you started, other things come into play in writing efficient programs such as, a debugger, memory profiler tools and above all a good understanding of the inner working of the Linux kernel and its processes." Read below for the rest of Ravi's review.
| Linux Programmer's Toolbox | |
| author | John Fusco |
| pages | 622 |
| publisher | Prentice Hall |
| rating | 9 |
| reviewer | Ravi |
| ISBN | 0132198576 |
| summary | Teaches you the use of tools which help you become a better Linux programmer |
The book The Linux Programmer's Toolbox by John Fusco is a storehouse of knowledge, which aims to make the average Linux/Windows programmer aware of the tools at his disposal, that can help him write better programs for Linux. The book is divided into 10 distinct chapters with the first 4 chapters describing various ways of boosting ones productivity while writing code.
In the very first chapter titled "Downloading and Installing Opensource tools", he talks about the different archive formats commonly used in Linux, various package managers such as Debian's own apt-get, Red Hat's Yum and how to properly authenticate the packages you download to ensure that they are not tampered with.
The second chapter deals with building tools from source. Here apart from describing the actual steps involved in compiling the sources, the author also delves into explaining the concept behind the MakeFile, the common variables used in implicit rules and so on. In this chapter one also gets to acquire an understanding of the tools used to create projects as well as examine how these tools work together in the build process.
The book has a chapter exclusively devoted to explaining ways of ambulating through the myriad of documents; tools such as man, info, as well as some of the not so obvious ones. One thing I like about this particular chapter is how the author has provided tables which list a number of recommended manual pages with a short description of each of them.
Linux doesn't have a comprehensive IDE on the lines of Microsoft Visual Studio to develop programs — at least not yet. Most Linux programming gurus are perfectly at home with coding using their favorite text editor. Any book of this stature would be incomplete without a mention of the different editors available for coding in Linux and their pros and cons. The 4th chapter of this book introduces the different editors including Vim and Emacs. There are numerous tips in this chapter to make writing code more efficient, productive and a pleasant experience for the average Linux programmer. As a Vi enthusiast, I couldn't help but admire how one can convert Vim editor to work as a code browser with the help of Ctags which is explained in detail.
The fifth chapter titled "What every developer should know about the kernel" is a turning point in the book and gives a comprehensive understanding of the working of the Linux kernel. It is by far the largest chapter — with nearly 100 pages devoted to this topic. In this chapter the author talks in lucid detail about the different modes in Linux, the process scheduler, device drivers, the I/O scheduler and the memory management in user space, understanding all of which is instrumental in writing better programs for Linux.
The next two chapters deal with Linux processes and the communication between processes. Here one gets to know more about the technical vagaries related to processes such as forking, cloning, process synchronization and the basics of inter process communication. The author has introduced several APIs and basic examples of each.
In the 8th chapter, the author introduces many tools that are installed by default in most Linux distributions which aid in debugging communication between processes. The tools include (but are not limited to) lsof, fuser, stat, hexdump, strace and so on. Each tool is accompanied by its usage and its output with a short discussion of the output.
In the 9th chapter titled "Performance Tuning", one gets to know more about fine tuning a Linux program. Here the author explains the factors affecting system performance as well as the tools for finding system performance issues.
Finally, the last chapter of the book explores some of the most common debugging tools and techniques for Linux. More specifically, I found the discussion on the use of GNU debugger quite informative.
At the end of each of the 10 chapters in the book, the author has provided a short synopsis of the tools that are used. Also many additional online resources have been listed where one can acquire more knowledge about the topic being covered. Throughout the book, noteworthy sections have been highlighted in dark background which makes it quite eye catching and also easy for quick reference.
The book is written with a slant towards the C language especially when depicting the examples in the latter half of the book, which can be understood considering that the bulk of the Linux kernel has been written using C.
Most programmers with a Windows background will be forced to make a paradigm shift while embarking to program for Linux. While the Windows programmers are used to taking deceptive comfort within the cozy confines of a Visual IDE, when they make the shift to write Linux programs, they are suddenly faced with the hard facts of programming as it really is. This book could be an ideal companion for this set of programmers who wish to lessen their learning curve and make programming for Linux a much more pleasurable experience.
I found this book to be an excellent resource for programmers (not necessarily only those with a Windows background) who wish to develop programs for Linux.
Ravi Kumar is a Linux enthusiast who maintains a blog related to Linux, Open Source and Free Software at linuxhelp.blogspot.com.
You can purchase Linux Programmer's Toolbox from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
All of these... (Score:5, Funny)
Re: (Score:2)
(yeah, right)
Re: (Score:2)
Fixed that for you. ; )
Re: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
Personally, I find programming under Linux orders of magnitude more enjoyable than under Windows.
First of all, the tools are better. There are compilers, debuggers, IDEs, profilers, memory leak detectors, unit test frameworks, UML modelling programs, documentation generators, parser/compiler generators, GUI designers, version control software, and just about any other tool you can imagine. Those things all exist for Windows too, but they're usually really expensive and don't work together as well as t
Re: (Score:2)
Unless you are MacGuiver (Score:2)
Re:Win32 dev bad? NOT for Delphi/Kylix & Win32 (Score:4, Insightful)
Re: (Score:2)
On an odd note though, while doing the translation I did have my first look at Delphi for Windows, and to honest I was blown away. I still like emacs + gdb, but the Delphi IDE w
Re: (Score:3, Informative)
Depends on the project (Score:2, Insightful)
Need to do web development? Try Zend + PHP
Driver or hardware layer coding? emacs/vi/gas/gcc
Cross-platform application? Java + eclipse
Re:Depends on the project (Score:5, Funny)
Re: (Score:3, Funny)
You say that as if it were a bad thing.
Re:Depends on the project (Score:4, Funny)
/duck
A good IDE (Score:2, Funny)
Re:A good IDE (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Spreading the love for jEdit [jedit.org]!
Re:A good IDE (Score:5, Funny)
A lot of good "Linux" IDEs exist (Score:3, Informative)
Re: (Score:2)
Re:A lot of good "Linux" IDEs exist (Score:5, Informative)
The caveats are that I was using the gcj compiled version that came with FC4, and was using this when FC4 was current. It may have gotten better, but C++ is such a complicated language there may still be issues.
What are the major differences, in your opinion? (Score:3, Informative)
Re:What are the major differences, in your opinion (Score:3)
Re:A lot of good "Linux" IDEs exist (Score:4, Insightful)
Yes, I'm elitist. That's because it's the only logical position to take. The human race is never going to advance until we abandon our pathetic obsession with the blatantly untrue claim that everyone has equal potential, and acknowledge that most technical jobs require special skills that only a fraction of the population will ever possess. (Until we grow mature enough as a species to accept the harsh reality that eugenics is the only way we will ever put an end to poverty, overpopulation, and all the other major sources of suffering in the world.)
But I digress. To put it bluntly, programming is actually very hard, and no visual IDE, however "sophisticated", will give monkeys the ability to do it properly. So they should find jobs they are actually capable of, like stacking shelves or flipping burgers or swinging from tree to tree like nature intended, and leave programming to the intelligent elite, who, being intelligent, are capable of learning to use difficult-but-powerful tools like emacs or vim properly and thereby being vastly more productive than the monkeys who rely on point-and-drool crap like Visual Studio.
Mod me "troll" or "flamebait" if I've hurt your feelings, mod me down into oblivion if you can't handle what I've got to say - but you know it's true.
Re: (Score:3, Insightful)
There are a lot of monkeys trying to write code out there, I will agree with that.. but I don't blame the tools so much for that, as I blame the twits wh
Re: (Score:3, Interesting)
I hope I never go back to an IDE, unless its something along the lines of Borland's text-mode BC++/Turbo C version. It never "got in my way." My current "IDE" is a half-dozen shells opened at different parts of my source and release tree so I can run vi to dash of a quick 2-liner shell script or perl script, run ctags or mc; several copies of kate with different session hsitories, on different monitors; firefox for quick web searches (and to pop in on /.); and kopete so that everyone in the office can comm
Re: (Score:3, Informative)
If you're holding yourself out as a programmer, you definitely have to be able to write good code. But technology work is not made up solely of programmers. I work with programmers, *NIX administrators, graphic designers, UI designers, animators, illustrators, subject-matter experts (usually with PhDs in non-technical areas), clients who are not geeks, etc. There are a lot of jobs in technology that do not require you to write any code whatsoever.
It sounds like you are the alpha nerd on your development te
IDE for Linux, yup (Score:3, Informative)
C/C++ use Qt, kdevelop, or gnomes IDE
Java use Eclipse.
There are several IDE's for programming on a linux system. Also you have to define IDE, if you mean VS like then the previous should suffice. But there are also IDE's like rhide, but that is a bit old school.
Re: (Score:3, Interesting)
Code::Blocks is quite decent for that purpose and I personally use it. With other things, it offers a visual debugger (you can add brake points to the code and then step the code in the code view line by line and see the values of the variables). This is with the latest svn build at least. Haven't tried the stable version. http://www.codeblocks.org/ [codeblocks.org]
Re:IDE for Linux, yup (Score:5, Funny)
Note: for faster performance you should remove all brake points in your release build.
Re:IDE for Linux, yup (Score:4, Informative)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
To be more specific, I'm using it to debug Java, Perl, php, ruby, and NSIS (Windows installers). It's also my database front-end (currently used with Oracle, MySQL, and SQL Server), and subversion client (with the best 3-way merging interface I've ever found), and trac (bug management) interface.
I don't use it for any other languages because that's all the ones I really use, but
Re: (Score:2)
Yes Eclipse CDT is very useful, I have never used KDevelope but Some people really like it. But giving the Devil his due VS under windows is a good IDE.
Re: (Score:2)
Re:IDE for Linux, yup (Score:4, Insightful)
Bah, vi is fine for simpletons (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:2)
IMNSHO, IDEs are overrated monolithic crap which wouldn't even exist if MS-DOS had had multitasking and didn't suck so much (Turbo Pascal and so on ...).
You mean when people ask me, I should lie and say "This neat, flawless p
The best tool may not be the prettiest (Score:5, Insightful)
Crappy by what standards? Since when is a powerful text-based editor bad for editing text? I was raised on the Visual Studio IDE, but as soon as I discovered vim I jumped ship and have never returned. I find vim/make/gdb to be a far easier/faster/more convenient way to code. However much of an "archaic modality" this is, it is superior for my needs, and something that I encourage any coder to at least try.
I acknowledge that the "command line" part of the equation may cause problems for debugging GUI programs, that it may be subpar for managing a large number of files, etc. Indeed, it certainly isn't for everyone or every task; however, for the majority of the data-slinging / scientific computation / non-graphical coding and development I do, I wouldn't use a visual IDE if I was paid. The reason why I believe Linux is pretty advanced is because it supports an array of powerful tools like vim, make and gdb.
Re:IDE for Linux, yup (Score:5, Informative)
In a way, [G]VI[M] and EMACS each represent a club. Clubs of people who took the temporary productivity hit to learn a difficult tool (and possibly put in extra hours to still make the deadline) with some promise of greater productivity in the end.
Is it a false promise? Maybe. There may be a little elitist ego in there, too, but I'd like to think that many who have learned those tools are people willing to put in effort for overall efficiency, and it seems to me to have been beneficial.
Each time I've coded a different "language" (Verilog, C, C++, javascript, Python, Magic VLSI text files, shell, SVG, POV-Ray, bill-of-materials files, SPICE models, config files, etc.) VIM has been there for me, equally handy and powerful. But it didn't look as pretty as Visual Studio, so I guess I shouldn't bother to tell anyone about it. And remember, these are not necessarily tools for a first-time programmer, but for a first-time Linux programmer.
Re: (Score:2, Funny)
simple and effective KDE tools. (Score:4, Informative)
kdevelop is nice, but I don't do a lot of GUI programming. For what I do, Kate and kdbg work great.
Kate is a good GUI text editor and a joy to use. It has a file browser and quick picker for open files. Sessions act like project files, so you can quickly load all the files you need to work on. The editor itself has excellent syntax highlighting, tabs and split screens, so you can see multiple versions of the same file and compare it to others.
Kdbg is a GUI front end to the gnu debugger. It has all the usual things and a few nice extras all workable with a mouse. It has easy to manipulate step through, locals and watches. Variables that change are highlighted in red. One of the neat extras the watches has is the ability to do simple math and return values of functions used in your code. If you have a function dot_ab(a b) that returns dot products, you can put variables you are watching in and get back the answer you want.
Blulhsit (Score:3, Interesting)
You need to know about kernel internals to start writing programs on Linux? Sure - maybe if you start your programming on Linux by writing device drivers.
One out of 20, at most, projects I've done on Linux required anything more than an editor, a compiler, and the "print" statement. It's not that I write simple programs, it's just that in real life these usually end up being sufficient (especially if you program in Python or Java as opposed to C or C++).
Re: (Score:3)
Re: (Score:2)
That's what I thought, too.
But it is possible that that's just marketing-speak for the kinds of things Stevens covered in Advanced Programming in the UNIX Environment. Concepts like file descriptors, signals, fork(2) and exec*() ...
If so, I think it's a good thing that it's in there.
Re: (Score:3, Insightful)
Yes, Valgrind is great, and yes, I'd give it to any starter who needs to write something in C. But most programs would be better off written in some other language, like Python or Perl (or if you want or need static typing, I'd recommend something like SML or O'Caml). Or even Java. And I'm glad to claim that a huge portion of recent quality s
Programmer efficency vs. hardware efficiency (Score:4, Insightful)
This needs to be repeated loudly and often. C/C++ is a great language, but there are only a very few instances where you really need to use it. C/C++ is optimized for making efficient use of hardware resources, CPU and memory in particular. On modern hardware, this is seldom the limiting factor -- you are far more likely to be constrained by I/O (network bandwidth / latency, database queries, etc). If you really need that kind of low-level control or cpu optimization, it's usually isolated to few critical functions -- the majority of the work that wraps those functions is better handled by a higher-level language. Writing an entire application end-to-end in C/C++ is usually a mistake
More importantly, most projects are constrained by PROGRAMMER TIME. A language that optimizes programmer efficiency rather than hardware efficiency provides a bigger benefit for the vast majority of development projects. Why write 100 lines of C or Java code when you can accomplish the same task with 10 or fewer lines of Perl, Python, or Ruby? Programmer productivity really soars when you have an easy-to-use repository of pre-written code modules like CPAN.
Re:Blulhsit (Score:5, Insightful)
A profiler, though, should be mandatory. I remember the first time I used one, I was able to improve my code to the extent that over 90% of its run time was spent in the database driver. It's also educational to do things like move loop invariants (which the compiler should do for you) and see how much your code's efficiency improves. Playing around with code and a profiler is pretty much the only way you'll learn what things really improve performance, and which are just folklore.
Just remember Knuth's warning... (Score:5, Informative)
Re:Just remember Knuth's warning... (Score:4, Insightful)
The first rule of optimization is: Don't do it.
The second rule of optimization (for experts only) is: Don't do it yet.
Of course, in these cases, what they're really saying is, don't start out sacrificing simplicity to achieve what you imagine to be greater performance. When you have achieved correctness in your program, this is a good time to whip out your profiler and actually figure out what does need speeding up. Always measure the before and after performance of your application. Often enough you'll find that your brilliant optimization doesn't speed things up at all, or worse yet, makes it slower.
Re: (Score:3, Interesting)
Actually, a decent logging system goes a long way towards making a debugger unnecessary. They're a good tool to have, but if you're spending more time in the debugger than you are writing code, you're doing it wrong.
I've been developing system applications for close to 25 years now, and I have found that this philosophy serves me well. I rarely use a debugger, I know how, but I have found that good application logs and a working knowledge of the source code allows me to debug code much quicker than a debugger does.
A profiler, though, should be mandatory. I remember the first time I used one, I was able to improve my code to the extent that over 90% of its run time was spent in the database driver. It's also educational to do things like move loop invariants (which the compiler should do for you) and see how much your code's efficiency improves. Playing around with code and a profiler is pretty much the only way you'll learn what things really improve performance, and which are just folklore.
You're correct that modern compiler optimizations takes care of most of this. Profilers are useful, though perhaps not as useful as they used to be. I personally have not used one in years, with experien
Re: (Score:2, Informative)
IMHO, this is one of the best things you can do. Like other things that are good for you but not much fun, I don't do it nearly as much as I should, but every time I do I am rewarded with insights to improve my code that I would not have gotten othe
My ToolBox (Score:5, Funny)
one debugger to debug them all: gdb
one memory profiler to profile them all: valgrind
and in the darkness bind them : *EMACS*
After strange aeons, even Death may die! (Score:3, Funny)
Re: (Score:2, Insightful)
Shouldn't it be:
and in the darkness bind them : *ld*
Which ever tool provides the result (Score:5, Insightful)
Deceptive comfort? And here I thought the visual IDE to be just as valid a tool as anything else, that being the one that solves the need of the programmer. Silly me. I guess I need to overdevelop my zealousy in computing.
Re: (Score:2)
And, as someone else posted, you can get IDEs in Linux too, with plenty of pretty GUI stuff.
I'm just putting in this reply because I lack the mod points to give you the +1 insightful you deserve. (or at least +1 captain-obvious-that-everone-else-missed)
Mod parent up (Score:2)
Re: (Score:3, Insightful)
"Every tool is just as good as every other tool" is just as wrong as "my tool is always better than your tool". I suggest learning phrases like "I can do this faster with the tool I know than I can learn a new tool" and "Visual Studio is a better tool than vi when you're maintaining a form-heavy VB.NET program".
In the general case, I'd argue that Emacs in a *nix environm
Re:Which ever tool provides the result (Score:5, Insightful)
It has been my experience that a certain attitude, regarding the utility of more feature rich development tools, exists among Linux programmers which I find difficult to understand. They seem regard anything other than the most minimalist, zen-like, or spartan programming tools as either a complete waste of time or a highly suspect crutch for lesser (i.e. less worthy) programmers than themselves (not a flattering judgment in either case). It is my own opinion that such views are detrimental to the development of Linux as a platform since there are necessarily fewer professional programmers who take a whipping boy approach to their programming tools (i.e. *real* geeks use Emacs or VI and gcc and nothing else).
Visual Studio is less a "deceptive comfort", as the author chooses to put it, and more of a what a modern, productive, and efficient IDE *should* be (although it does fall short of that ideal sometimes). In my opinion, linux would be many times more successful if there were something more directly analogous to Visual Studio (Eclipse is getting there but it still has a ways to go) available for development. The "developer mindshare" among Linux geeks is comparatively low when weighed against, say the Windows platform and Visual Studio and whose fault is that? I leave that one as an exercise for the reader.
Re: (Score:2)
modern, productive, and efficient IDE *should* be ...
Don't confuse a complex IDE with productivity. They are often not the same.
So called "rich development tools" frequently integrate badly with the rest of the environment and lose any benefits they might have because of it. They also fair badly when the GUI designer doesn't anticipate all possible needs; almost always the case. I find my productivity in a non-integrated environment is much the same as an IDE and often superior due to flexibility, scr
kdevelop (Score:5, Informative)
Kdevelop is very close to VS in features, and much better than Eclipse for anything other than Java. I have done lots of development in C++, PHP, and Python using kdevelop.
It's hard to tell if it's kdevelop itself that's better, or if I'm comparing Qt with MFC, but for me at least, developing in kdevelop is several times more productive than in Visual Studio.
Besides, the fact that Qt is now very well integrated with Python brings even more productivity because we do not need to use C++ for GUI development. I don't know how well Visual Studio handles GUI development in Python, but I certainly do not miss the old days when I did develop for Windows using MFC and C++. Even better, there is PyQt for Windows, so you can do multiplatform development in kdevelop.
In my experience, the most productive platform for code development is a kubuntu machine with kdevelop creating Python code with Qt, using C libraries where needed. For integrating C libraries in Python I use swig.
Re: (Score:3, Insightful)
Or does the lack of an IDE just mean most people are turned away without even bothering to try?
My tools (Score:3, Informative)
Compiler - gcc
Debugger - gdb
Mem Checker - valgrind
Build - make and a custom build system written in Python
Image processing - ImageMagick
That's it. Spartan, yes, but it forces me to write good code instead of relying in fancy tools
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
all you need is bash-xterm-vi
and vim if you want your nails done.
cscope and ctags to track your code
get your hair highlights with Perl and Ruby
to look fab.
Sounds like a useful book, actually... (Score:2)
My tools for GUI building (Score:2)
* gcc is my compiler
* Xaw3D is my gui widget library (yeah, I know we know have FTLK, GTK, etc...)
A few tools... (Score:5, Informative)
If you want to move into the murky world of C/C++ development these are IMHO the basic tools:
There are many more tools but those are good start. It also helps to have a thick skin, getting to know which library does what, being persistent and making heavy use of search engines rather than posting every problem to mailing lists and newsgroups. Also remember that a lot of enterprise grade software can be had for free under various conditions. Just to name two examples... OS X actually ships with the Xcode development suite and Oracle offers various developer suites as well as many of it's products for download under a development license if you sign up for an Oracle account.
Re: (Score:2)
One small convenience git provides is "git grep", which does a recursive grep of your working directory, but just of paths that git is tracking. It's kind of surprising how often I find myself using that; it still doesn't quite replace cscope (plus vim keybindings) for me, but it's a heck of a lot better than the "find src/ -name '*.h' -o -name '*.c' | xarg
I have to say this doesn't sound like a good book. (Score:5, Interesting)
All in all, the book gives suggestions that will help you get a good grade at CS, and maybe Software Engineering, but probably not more formal courses (too little emphasis on the thinking part). It will help you write good programs, without a doubt, but not great programs and certainly not masterpieces. Nor will it help you with the history of programming (programmers predate text editors OR debuggers) or the future of programming (this book is only marginally useful on fourth- and fifth-generation languages, RAD, specification compilers, massively parallel programs, fuzzy logic, self-modifying code, and other such fun stuff).
All in all, there will be many people who will get great value from this text, but they will never be language-agnostic and they will never write the truly brilliant software that they are quite capable of. Yes, it's easy to criticise and harder to do, and it's most unlikely I would ever write a computer book. Mostly because nobody would be able to understand it - my writing style is hard enough to follow on Slashdot, I can guarantee you'd see people jumping off bridges if faced with 500+ pages of my degenerate writings. However, the fact is that there are many good books for novice programmers who want to be adequate, a few for adequate programmers to unlearn bad habits and become good programmers, far fewer that skip the middle step and go straight to good, and none at all that show someone how to go the extra mile that turns something good into something amazing.
That's the book I want to see someone write, and get reviewed on Slashdot.
Re:I have to say this doesn't sound like a good bo (Score:3, Insightful)
In a large crufty codebase, a good test harness may not be easily made. We had unit tests required for checkin at my last job. God I wish we had that where I am now...
As for printing state, depending on the system, printing may not be possible (embedded), or may throw off timing (or whatever) enough to make the problem go away...
A good debugger and skills in using it properly can be a huge advantage.
Re: (Score:3, Insightful)
To be fair, running a debugger on an embedded systems can cause just as many problems as state printing. In same cases more, since it can sssslllooooowwwww code execution. Depending on the embedded system, "printing state" can be a better choice - easier to get in to the system, and able to be targeted to a specific part of the system. Of course
Source control! (Score:5, Insightful)
Re:Source control! (Score:4, Informative)
The reviewer didn't seem to mention it but, yes, that aspect is covered. At least according to the Amazon blurb.
Need other things? Not really... (Score:2)
Not really. I've written many, many programs for various Unix and Unix-like systems over the past 20 years and only rarely have I needed a debugger or memory profiler.
Furthermore, understanding the "inner workings ...", while beneficial, only really matters when writing programs that interact with said "in
Re: (Score:2)
As for profilers, they should be used once you hit beta, if at all. And even then, chances are you're going to use them in a very superficial way, to find out which chunks of code are taking the most time so you can see which algorithms might need replacing. Very little code these days needs the kind o
Yeesh. (Score:2)
These can be a major bitch to figure out on your own, and are a pain in the ass even when you think you know what you're doing.
No coverage of source control?
No coverage of bug tracking?
And about this line: Linux doesn't have a comprehensive IDE on the lines of Microsoft Visual Studio to develop programs.
My Toolbox (Score:2)
When I have to go to the darkside I use Code::Blocks, SharpDevelop, and as absolute last resort VS.Net. I still use SVN, mingw, qt.
And the most important tool of course is a fast internet connection and a speedy browser. Firefox is the current favorite.
This simple setup gives me crossplatform support all the way from Desktop Apps, Through Server Apps, to Embedded Linux.
I've tried eclipse and I bet I could make it as usable, given enough time, but I'm not
Hmm... There are great IDEs for Linux! (Score:2, Insightful)
My toolkit's always the same... (Score:2)
IntelliJ IDEA
A bunch of JDKs
JProbe
Knowledge of the internals of the JVM is valuable, of the linux kernel - less so.
Oh give me a break... (Score:5, Insightful)
What a fantastic fantasy world to live in. Did I miss something, or is the software that millions of people run worldwide on Windows PCs somehow not 'real software'? Did the Windows developers who wrote large and/or mainstream applications such as Word, Photoshop, Quark, Winamp, Skype, etc somehow not actually know how to program?
I really would like to hear more about these 'hard facts' of programming...it makes it sound like it is harder to program for Linux - is this supposed to be a good thing? However, I don't believe this, and suspect it's the usual macho Linux bullshit that some F/OSS advocates seem to be afflicted with.
Luckily the rest of us can just get on with programming our software for whatever platform using the most appropriate tools, instead of banging nails in with our fists.
Re: (Score:2)
Well, some of those are okay, but I think it's safe to say that the people who wrote both Word and Quark are complete fucking idiots. Especially Quark.
Re: (Score:3, Funny)
So I typed out a longer reply, but it just boiled down to "No, it's still just macho bullshit."
So I'll leave it at that.
I certainly wouldn't trust someone who says:
For Microsoft's self-protective skin is really only a show, a lure to the determined engineer, a challenge to see if you're clever enough to rip the covers off. The more it resisted me, the more I knew I would enjoy the pleasure of deleting it.
Two hours later, I was stripping down the system. Layer by layer it fell away. Off came Windows NT 3.51; off came a wayward co-installation of Windows 95 where it overlaid DOS. I said goodbye to video and sound; goodbye wallpaper; goodbye fonts and colors and styles; goodbye windows and icons and menus and buttons and dialogs. All the lovely graphical skins turned to so much bitwise detritus.
Or, if you're not a muppet, you could just run fdisk, delete the partitions and prep the disk for a new OS. About 3 minutes work, I'd guess. Ooooh, I'm so clever - I defeated Microsoft!
Use Windows to Develop Linux Apps (Score:2)
Why restrict yourself to Linux tools just because you're developing a Linux app this week? I do all development (both Windows and Linux) from my Windows machine.
When coding for Windows, I have my editor open editing local files, and a console window open, for doing builds or whatever.
When coding for Linux, I have my editor open editing what looks like local files (but are actually a network share of the Linux development directory), and a Putty console window open, for doing builds or whatever.
It
Re: (Score:2)
Re: (Score:2)
I'll go a step further (Score:3, Interesting)
Re: (Score:2)
Re: (Score:3, Funny)
I've yet to try that one out?
Should I use
Written Interfaces Normalized Definitions On Wacky Systems instead?
or maybe
Freaky but Rational Enhanced Extensible Basic System Development?
how about
Machine Accessibly Control on Occult Systems eXtended?
Re: (Score:2)
Re: (Score:2)