Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Developer Tools for Linux?

By depsypher in Technology
Mon Dec 18, 2000 at 03:56:30 AM EST
Tags: Technology (all tags)

They say a good craftsman never blames his tools, but not all of us are Macguyver. Even the best craftsman wouldn't be able to cut down a 150 year old redwood with a butterknife, right? How does this analogy apply to development under linux? I've been programming for the last couple of years now and have grown quite accustomed to the MS way of doing things. I'm now thinking of setting up a linux box for development. My main interest in linux is the huge number of interesting open-source projects to work on.

As a someone just starting out programming, contributing to an open source project seems like a great way to learn. But I would like to know what I'd be giving up and possibly what I'd be gaining in moving from a windows to linux environment. Good IDEs, debuggers, resource editors etc are essential tools for making the life of a programmer easier. Is there anything out there for linux that's comparable to Microsoft's Visual Studio in its scope and ease of use?

I program mostly in c++ and use MSVC++ 6.0. The debugger kicks ass, imo. MFC and the resource editor takes care of the trivial tasks involved creating a window app, leaving you with the fun of fleshing out the actual program. Plus, I really like the way the editor automatically indents closing braces to the matching open brace. Don't make fun, it really is a time saver.

So my challenge to the k5 community is to suggest a set of tools that match those available for windows. What's available in the way of application frameworks for windowing? What about a full featured intuitive editor? Is there a debugger that kicks as much ass as the one for MSVC++? Is there anything I'm leaving out? Must-have tools a windows developer wouldn't know about?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Also by depsypher

Display: Sort:
Developer Tools for Linux? | 46 comments (46 topical, editorial, 0 hidden)
*nix != IDE? (3.25 / 12) (#1)
by maketo on Sun Dec 17, 2000 at 10:35:16 PM EST

Hmmmm. I have posted the same question for years to different crowds - in general, the hard core unix crowd will tell you that IDEs suck and that they are totally anti-old-unix-hacker style. The newer Gnome/KDE crowd seems to be easier to convince, but in my opinion you have a problem with the following: people who know how to code and design and who are capable of producing what you want, do not see the need for it. The rest wants the tool but cannot produce it. Ofcourse, there are a zillion of small IDE projects outhere, but none of popularity/capability that say, Borland's IDEs had. I refuse to call MSVC++ tool an IDE, more like a graphical useless skeleton ;>. Anyways, I know Borland Delphi is on the way for Linux, that should be nice to see. I personally am working on a tool to block-diagram C code so that I can actually understand what is going on in a 150,000+ lines kernel ;). The first step would be the ability to show the code and browse through the block-diagrams, see all necessary information etc. The next phase eventually would be to program by making/rearranging the block-diagram elements (or C code) and to pick from your "code repository" where functions or modules could be stored. After this shameless plug, I also must say that C is far more preferred than C++ in developing for Linux....there are several web sites with arguments as to why this is. /me dont like C++ anyways.
agents, bugs, nanites....see the connection?
Oh yeah (2.60 / 5) (#2)
by maketo on Sun Dec 17, 2000 at 10:36:42 PM EST

You will also get a lot of "use Emacs, it rulez" or "vi is the best IDE you will need". It is up to you to see if you are ready to swallow the steep learning curve for any of these. In any case, IDE or not, you are in for a change ;>
agents, bugs, nanites....see the connection?
[ Parent ]
Well, I haven't used it in a while, but... (3.40 / 10) (#4)
by pb on Sun Dec 17, 2000 at 10:47:15 PM EST

My favorite IDE tool would have to be RHIDE. Unfortunately, it's somewhat buggy under Linux. (it was originally developed for DOS/DJGPP)

It's an IDE, but it isn't a GUI; in fact, it looks just like the old Borland IDEs (based on TurboVision). The best part is, it browses Info files with the same old Help file interface.

But I'm biased, of course; I programmed in Turbo Pascal 7 for years before I found Unix. I'm sure other people will suggest much more sensible things like Code Crusader or something. In fact, do a search on FreshMeat; I'm sure you'll find a bunch of stuff.
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
What I use at school (3.81 / 11) (#5)
by Scooby on Sun Dec 17, 2000 at 11:07:58 PM EST

At school, in the lab that I do my directed study in programming (I've progressed past what my school offers in programming), all the computers are running linux. When I'm only working on something quick, I generally use Gnome Edit, and compile via command line. However, when there's multiple files, I use an IDE, as I'm kinda a newbie to Linux and haven't taken the time to learn to compile multiple files via command line, or write a makefile.

Anyways, the IDE that we use at school is KDevelop, and it's pretty nice. The interface is very similar to VC++, which is why we use it, and the differences are quite easy to get used to. I'd give you a link, but I've lost the addy. =/ Just do a search for it though, it's bound to pop up, and I recommend it.

Various options (4.55 / 9) (#6)
by bgalehouse on Sun Dec 17, 2000 at 11:56:25 PM EST

Commercial systems have been available for Unix for a long time. They aren't allways priced well, but companies like Sun do sell compilers with integrated development environments.

But there is also some truth to a previous comment that all the open source guys with the firepower to do this well just use emacs or vi. This may be just as true in the windows open source world. Do you know a good non-commercial Win32 IDE?

Emacs comes across as a collection of routines which can be assembled quickly into an environment. It does not come across as a polished ready to go environment in and of itself. If you approach it this way, and maybe find experienced advice to help you set it up the way you want (say, in a newsgroup or in a user's group), you might find emacs very much to your liking. It depends on how easy it is to reach the control key on your keyboard :-) The problem with the C/C++ auto-indentation package for emacs is that it has so many parameters that a religous war would occur if it were applied blindly, so by default it is on request only. Similarly, font-lock-mode (syntax highlighting) works with more languages than you probably know, but by default you have to ask for it in all of them.

As far as additional tools are concerned, I'm sure that emacs supports integration with gdb. The various windowing toolkits probably also have some tools, but I'm not well acquainted with them.

Basically, the standards for unix development were originally set by people who enjoy tinkering. Not quite the same attitude as the dialog box heavy Visual C/C++ philosophy. If you understand that, you'll at least know what to expect to be available in the older projects.

options (4.00 / 2) (#7)
by depsypher on Mon Dec 18, 2000 at 01:32:57 AM EST

there is also some truth to a previous comment that all the open source guys with the firepower to do this well just use emacs or vi. This may be just as true in the windows open source world. Do you know a good non-commercial Win32 IDE?

This is an excellent point. The main reason I'm moving toward linux is the lack of open source software of any kind, including an open IDE. I've used the windows port of Vim (VI improved) and found it very powerful, but also very confusing. I was hoping to find something that had less of a learning curve (with the willingness to sacrifice some of the functionality). I haven't used emacs, but I imagine that is similar to vi in this regard (please don't take this as an invitation to start an emacs vs vi flame war-- I would enjoy seeing this as a seperate thread though ;)

Basically, the standards for unix development were originally set by people who enjoy tinkering

While I think this is wonderful, it's kind of a double edge sword... as I mentioned above, the learning curve for development is set higher along with added functionality. I'm sure I'll want the full blown, unadulterated tools at some point, but for now, as a newbie, I'm looking for a way to ease in.

My philosophy is, tools should help you get a job done and there's the right tool for every job. My old computer teacher used to say, "You don't need a jackhammer to kill an ant."

[ Parent ]

well (4.50 / 4) (#9)
by maketo on Mon Dec 18, 2000 at 01:46:03 AM EST

this is exactly the philosphy of Unix and its billion little, but powerful tools. Someone might tell you - emacs is good, so learn it. Thats an ide. Need to find something - you have find, locate, grep. Need to debug? there is DDD, there is gdb, xgdb. gcc has zillion of switches to do code expansions to zillion different levels. However, what you are looking at, coming from Windows, is a set of small tools which, applied properly allow for a lot of power. However, mastering them, and even becoming aware of the range is something that takes a different framework. In windows, you have large sets of interlinked options, usually in one tool. Your IDE is the debugger, the text searcher, the preprocessor, the compiler, the editor. It is also your project manager. And this works fine. To get on the point (if you thought I lost it - I didnt) - do NOT try to mimick the way you are used to treating your mental processes at work. Instead, learn the different (not necessarily better) way things are done in unix. This does not, however, mean abandoning your programming knowlegde cause we all know - programming is the same everywhere :)
agents, bugs, nanites....see the connection?
[ Parent ]
Why should people have to change? (4.00 / 2) (#19)
by pak21 on Mon Dec 18, 2000 at 05:40:47 AM EST

do NOT try to mimick the way you are used to treating your mental processes at work. Instead, learn the different (not necessarily better) way things are done in unix

I think the important question here is why people should have to change the way they work: if someone is comfortable developing using a IDE, why should they have to go an learn a different way of doing things if they want to develop for Un*x? As you say yourself, it's not a better way of doing things, just different. We should be making it easy for developers to switch to Un*x, not forcing them to change how they work if it doesn't help them produce better code.

[ Parent ]
Hmmm I agree but, (3.00 / 3) (#28)
by maketo on Mon Dec 18, 2000 at 01:49:00 PM EST

What is the impetus to encouridge people to go about Unix? To me it looks like KDE/Gnome and a bunch of other GUIs arose from the need to prove Linux as a user desktop, something that has not been eachieved yet. The basic problem is that Windows, MacOS, AmigaOS etc. are all integrated - the code for the GUI is the code for the OS. The GUI is the OS, for most practical uses. Now, on Unix - the GUI is a patch-on. Something put on top. There are numerous little tasks that you have to do everyday and that Unix makes possible - these tasks are now more easily done on the command line than in a window. This has partially to do with what people do with their Unix workstations and what they do with their Windows stations. I personally develop whatever pittiful code I develop on my FreeBSD machine - I have gcc, java, python, X terminals open, joe as an editor. As much as I would welcome a nice IDE, I would still feel like I am missing on something. Dont ask me why. As opposed to MS-DOS/Windows on which I spent a good deal of years - you could never make me use a command line tool, not even bpc.exe (Borland Pascal Compiler) - I used it from the IDE. Somehow it was natural to me. Ok - I guess new people are coming to the Unix scene - people who would like to _use_ their machine the windows way. To me it seems that one of those people should sit down and bring us a nice IDE for <plug-in-language> of choice. However, I assume there are numerous differences in the setup of many a *nix machine outhere. As opposed to Windows or MacOS where you always know what you will find, *nix mix is a bit different... I am not saying we should not have a nice IDE - I am just saying that there probably isnt enough interest in building a good, powerful one. First, by the time you decide to build one - you are comfortable with the way things are done. Two, see one (no users for the IDE).
agents, bugs, nanites....see the connection?
[ Parent ]
Use KDevelop (3.00 / 1) (#43)
by carb0n on Tue Dec 19, 2000 at 09:55:04 AM EST

If you feel so badly that you dont want to change, why dont you use KDevelop or Code Crusader? Actually, Sniff+ (www.takefive.com) is a very expensive C/C++ ide/navigation tool that normally costs mucho $$, but they have a free version out for linux. Worth a try... And of course Borland is gonna bring their tools to Linux quite soon...

[ Parent ]
XEmacs and gvim (1.80 / 5) (#14)
by pwhysall on Mon Dec 18, 2000 at 05:23:58 AM EST

I would mention Xemacs here, and gvim, both of which provide the full power of the Emacs and Vi editors, respectively, but also have a nice window/menu structure that means you don't have to remember that M-x font-lock-mode turns on syntax highlighting :)
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
[ Parent ]
For skeleton GUI apps- (4.20 / 5) (#8)
by ramses0 on Mon Dec 18, 2000 at 01:44:24 AM EST

-take a look at "Glade", which is located here ... I've used it a little bit, and it's like a mini version of Visual Basic for Gnome applications. In addition to C/C++ support, it will also build GUI's for Python and Perl, plus it uses XML to store the representation of the interface, making it fully buzzword compliant ;^)=

[ rate all comments , for great justice | sell.com ]

All you need to know (3.14 / 7) (#10)
by armag0n on Mon Dec 18, 2000 at 01:52:43 AM EST

There are many many great tools available for programmers under Linux.

1) vi is probably the only editor you'll ever need. Or, if you want somewhere to live while you code, use Emacs.

2) GDB kicks more ass than you can shake a stick at. Nothing that Microsoft could put out in a million years could out-do GDB.

3) GTK+ or QT are excellent application frameworks for GUI apps under KDE or Gnome and they are much more cleaner and coherent than Microsoft Foundation Molasses.

Did I mention that makefiles are much more easier to deal with that that nmake crap that MS Visual Studio gives you?

There will be no loss for you should you decide to switch over to Linux (unless you are making a ton of cash programming for Windows). The gains are too many to list, but you will experience a much cleaner coding experience and with a lot less pain.

If you want to check out a few books, I would recommend this for overall linux programming, and this for GTK+ development.

Be sure to check out freshmeat.net for many GUI programs and GTK development aids. There's a literal ton of stuff out there, you only just have to look.

Only if you're already a *nix programmer (4.50 / 2) (#27)
by leviathan on Mon Dec 18, 2000 at 01:23:18 PM EST

1) vi is probably the only editor you'll ever need. Or, if you want somewhere to live while you code, use Emacs.

I never got started with vi. I probably could have worked through the tutorial it presents on startup, but I already had emacs set up, and it had enough speed at editing for me. But I'd have never got emacs set up if I hadn't found someone to copy their .emacs file. On windows I can pick up J. Random Editor and provided it has the small set of features I need to conform with whatever coding standard I have to comply with, I can run through all the options in less than 5 minutes.

2) GDB kicks more ass than you can shake a stick at. Nothing that Microsoft could put out in a million years could out-do GDB.

GDB is the one program which put me off debugging. It was my first encounter with debuggers and it would have taken me ten times as long to learn to use it efficently enough to do what I was already doing with printf statements. It was only years later that I found out that all debuggers didn't have to have such a forbidding newbie interface. When I eventually got around to using a debugger where I could click to place a breakpoint, and have a window to show me my watch variables I found the advantages of debugging, but I'd been avoiding it for years because of GDB.

3) GTK+ or QT are excellent application frameworks for GUI apps under KDE or Gnome and they are much more cleaner and coherent than Microsoft Foundation Molasses.

OK, I agree with you on that one.

Did I mention that makefiles are much more easier to deal with that that nmake crap that MS Visual Studio gives you?

Sure, but at what point in developing in MS Visual Studio do you need to look at the nmake makefiles without the aid of a Visual Studio windows with cue text etc.

OK, I'll come clean. I do prefer the development environment under a *nix to the standard Windows ones (maybe excpeting GDB), and on the NT box I use I have installed cygwin and NTemacs. But from a newbie perspective, especially one who doesn't have the benefits of an academic community of hackers just down the corridor (it's closer than on the 'net, believe me), the initial hurdles the (mostly) GNU tools present is too daunting.

Maybe things are getting better; I've seen a few front ends for these tools around, although I've never bothered to try them out. Grumble over for today.

I wish everyone was peaceful. Then I could take over the planet with a butter knife.
- Dogbert
[ Parent ]

Why I Don't Like IDEs (3.75 / 4) (#11)
by gblues on Mon Dec 18, 2000 at 03:20:39 AM EST

.. it's so slow compared to SCSI ;)

Just kidding.

IDEs are a horrible way to learn how to program. They're great timesavers when you're already familiar with the basic concepts of coding and don't want to fuss with modifying makefiles by hand. But if you don't know how to do it by hand, you won't be able to fix it when the IDE breaks or when it can't do what you need it to do.

It's like a math class. When you first took math as a kid, you weren't allowed to use a calculator (well, I HOPE you weren't) so that you could learn the fundamentals. By the time you get to college-level math, a calculator becomes required. It's the same way with IDE environments.

Get a couple ORA books covering GNU Make and GDB, and dive in head-first. Do a couple small projects, or perhaps analyze the Linux kernel's makefile hierarchy to trace exactly what happens during 'make zImage'.

... although in retrospect, having sex to the news was probably doomed to fail from the get-go. --squinky
What I use. (3.66 / 3) (#12)
by antizeus on Mon Dec 18, 2000 at 03:54:54 AM EST

At work I develop under Solaris, but most of the tools are available under just about any OS: gnu compiler, vi for editing, xxgdb+gdb for debugging. Works for me. I don't do GUI stuff, so most of the charms of that Windows stuff is lost on me.

What I would really miss on Linux is Purify and, to a lesser extent, Quantify. I'm generally pretty good about freeing my allocated memory and not violating array bounds, but nobody's perfect, and I do make mistakes. I haven't really looked into any alternatives for Linux since most of my Linux programming is trivial, but they would still be nice to have.

Electric Fence (4.00 / 2) (#17)
by pak21 on Mon Dec 18, 2000 at 05:29:18 AM EST

What I would really miss on Linux is Purify

Bruce Peren's Electric Fence library certainly isn't bad for catching array overruns, but doesn't catch the memory leaks. And as the docs say, it's not as good as Purify.

[ Parent ]
Build your own set of tools... (3.00 / 3) (#16)
by pak21 on Mon Dec 18, 2000 at 05:26:07 AM EST

I don't think your going to find one nicely bundled suite of tools which gives you everything you want: try out different editors, debuggers, etc, etc, see which ones you prefer. You'll eventually end up with your own suite of stuff, probably with a couple of home-grown things in there as well. But to answer a couple of specific points:

Good IDEs, debuggers, resource editors etc are essential tools for making the life of a programmer easier.

A debugger: yes. But not necessarily a fancy GUI bells and whistles one - I find gdb a lot more useful than any of the Windows ones I tried... but then I have spent more time learning it. An IDE I'm really not so sure about - but again I've never used them that much anyway.

Plus, I really like the way the editor automatically indents closing braces to the matching open brace.

One word in that case: "Emacs".

Kylix (3.66 / 3) (#20)
by Peeteriz on Mon Dec 18, 2000 at 08:00:53 AM EST

I do most of my programming in borland's c++ builder and Delphi, and I am very satisfied with the IDE. I like it better than the M$ Studio, though your mileage may vary. But, the best thing is that Borland/Inprise has been busy porting these tools to linux for quite a while, and the first release should be Q1 2001 already. A lack nice RAD tool to speed up development when you know how to code has kept me from moving to linux for a long time, and the ability to develop apps for win9x offices under linux is also going to be really good.

Code Crusader/Code Medic (3.75 / 4) (#21)
by _Quinn on Mon Dec 18, 2000 at 08:39:56 AM EST

   Code Crusader, and its sister debugger, Code Medic, are clones of Metrowerk's CodeWarrior IDE, and they do a very good job; we teach everything but CS 100 using it. Code Medic wraps gdb, and Code Crusader can 'export' to/use Makefiles, so you're not losing any power, and it's relatively easy to move from the IDE to the command line when necessary. They probably don't have as many bells and whistles as VisualStudio (which I stopped using at rev1.0 :)), but I mostly program console apps, so it's not anything I miss.

Reality Maintenance Group, Silver City Construction Co., Ltd.
Learn the to live the Unix way! (4.60 / 10) (#22)
by joto on Mon Dec 18, 2000 at 08:59:55 AM EST

Actually, the traditional development tools on Unix are quite nice, when you get used to them. For a quick start, there's a book from O'Reilly called Programming with GNU software that should get you accustomed to the Unix way. While I haven't read it myself (I grew up the Unix way) I guess it should be excellent for someone used to some other way of doing it, learning to do it the Unix way. It covers make, which helps you automate dependencies between source files, and managing projects. gcc is the C compiler (also handles C++ (as well as Objective C, and possibly some other languages as well). emacs is a great text editor. You should take the time to learn to use it well. One of the greatest features of emacs is it's programmabillity, which means that there are editing modes for most programming languages which do syntax highlighting, indenting (I often use this as a syntax checker while typing), and some other features. There are also editing modes for gdb, the GNU debugger. If you use gdb inside emacs, it's actually very nice. On the command line by itself, it is a bit harder. You will also have to learn cvs which are traditionally used as version control software in most projects (the book unfortunately covers rcs, another version control software which cvs is (or at least used to) be built upon). The alternative is to hunt for the manuals to all of this online, which can be just as good (you may want to do so anyways after you have read the book), but I think the book would be a good way of getting started.

As you can understand from the previous paragraph, on Unix, the traditional way of doing software development is to be using a lot of tools. That is the Unix way of doing everything, we pick great tools that do one task well, and combine them to do whatever we want to do. There do exist monolithic IDE's as well, and maybe you prefer that way, but in my opinion. you should learn to do the Unix way first. Most Unix programmers actually prefer that way (including me).

But it all depends on what you want to do of course. If you want to develop for a GUI, I will mention three options, all with a relatively good probability of making you happy:

  1. I like to use glade and GTK. Glade is a GUI-builder, you drag widgets onto a window, and save the result as an XML file. You can either use the XML file directly, with libglade to parse and build your GUI at run time from this file (my preference) or you can let glade generate a code skeleton that you can modify yourself later. One of the nice things with the XML option is that you can use whatever language you prefer, C, C++, Ruby, Python, Perl, etc... to build your main program. And you don't need to recompile for simple modifications in the GUI. Read more on <a href="http://developer.gnome.org. Take especially note of the great articles written by George Lebl on IBM developerworks.
  2. If you prefer to use C++, there is the option of using Qt, which is also an excellent GUI-toolkit. Perhaps more so than GTK, but I prefer to avoid C++ as much as possible. Rest assured that Qt is one of the nicest things I have ever seen when it comes to programming GUI's. And it also comes with a very good tutorial.
  3. The last way, is to use <a href="http://dev.scriptics.comTcl/Tk. Tcl is a simple programming language that people have lot's of flame wars about whether it is good or evil (it shares this attribute with Perl). But the Tk toolkit (gui toolkit) really shines, and it is (unfortunately) most easily used from Tcl. But there exist bindings to most other scripting languages as well. Tcl/Tk may be old, but it is not dying just yet, and may be the best solution if you want to hack something together a'la Visual Basic.

If you want to use databases, my experience is also very limited but there are at least four free relatively ok databases available for most Unixes: MySQL, Postgres, InterBase and SAP DB. I am not really sure if anyone knows anything about which one you should prefer. There have been a lot of bad benchmarks and politics instead of useful information in the articles I've read. At least if you go with MySQL or Postgres you will have a sizeable community to support you, but it wouldn't surprise me if both lose on technical merits. As I said my experience is very limited here, so you will have to decide for yourself.

When it comes to alternative languages, most free software development on Unix is done in C. You can use C++, but it is for some reason just not that common as it is on Wintel-platforms. The other alternative is to use some scripting language. Here you can at least choose among Perl (please avoid it unless you already are in love with it, but every unix hacker should probably know a little bit of Perl), Python (very nice, and with a great future), Ruby (even nicer, but perhaps a bit too young to have captured mainstream use, except in Japan where it is very widely used) and Tcl (which is ok, I guess, but not exactly my fancy). Much application development could preferably be done in one of these languages instead of just reaching for the lowest common denominator: C. There are also the options of using some less common languages. If you like learning new languages, this is fine, but not essential. Most every language you have ever heard of has some free or open source implementation that you can use under Unix. If you (like me) want to learn something new, maybe you could look at some of these languages: ocaml, SML, Haskell, Scheme, Mercury, Erlang, Common Lisp, Pop11, Prolog, Eiffel, Smalltalk, which are all rather interesting languages I happen to like. They are all rather usable under most Unixes.

What I use (4.33 / 6) (#23)
by Garc on Mon Dec 18, 2000 at 10:54:58 AM EST

I've been doing a little development in GNU/Linux for a couple years, and I use a couple of things.

  1. emacs, if you don't want to deal with complexity, you should read this before deciding not to use it. This editor can do more than you can possibly imagine.
  2. gdb. I use it rarely, but when I do, I don't use any graphical front ends for it, just the command line. It's not too hard to understand after reading the man page, but some people perfer the xxgdb front end which can be gotten here.
  3. make
  4. cvs, a good open book that will help you use it is here. Most OSS projects use cvs, and for good reason too.
  5. gcc, is there another compiler?

It'll take you a little while to understand how to use emacs, and to get used to not using your mouse. After the learning curve, I belive that you will be more productive and happier with these tools, than any integrated win32 development environment.

best of luck,
Tomorrow is going to be wonderful because tonight I do not understand anything. -- Niels Bohr

sorry but PLEASE (3.50 / 2) (#40)
by SEAL on Tue Dec 19, 2000 at 02:21:08 AM EST

I usually don't jump in on these Unix vs Win32 threads but I've seen enough. This is a response to both you and joto - and don't take this personally.

[disclaimer: gcc, make, and cvs I have no problem with. They are more or less equivalent to doing Win32 project builds from the command line which isn't a big deal. I do this from work as a daily batch so I can have my build ready for me when I arrive each morning. ]

On to my point:

emacs and gdb are NOT a good alternative to a full fledged integrated development environment. Period.

Visual C++ has its share of quirks and annoyances, but for testing and debugging code, it is pretty damn good. Coding, debugging, and compiling in the same environment is nice. Yes you can set up emacs to do just about everything including wash your dog. But the point is that it is a pain in the ass to get it the way you want it, and a high learning curve for first time users. Xemacs is a little better for newbies but still doesn't quite fit the bill.

VC++ has some nice features that I find lacking elsewhere. There are mouseover tooltips for variable values in the debugger (DDD also does this). You can change variables while the program is running. You get statement completion / a popup window listing all members of a class as you type it. These little things speed up work quite a bit on a large project.

Debugging with command line gdb? Give me a break - that makes me want to vomit. It's much cleaner to set your breakpoints in your code window, and deal with them there (e.g. conditional breakpoints). I have neither the time, nor inclination to fight with gdb and some arcane manpage. If you rarely use a debugger, then you aren't working on a very big project :) More importantly, though, I find that stepping into code in a graphical debugger is an EXCELLENT way to learn how things work in a large codebase.

Luckily for me, DDD is a fairly nice frontend for gdb. When I work on Linux, I tend to use nedit + ddd. nedit isn't great but it's faster than xemacs on my slow machine, and does most of what I want, as does ddd. Overall, though, a Linux project will be more time consuming for me than an equivalent Win32 one due to the nature of the tools.

Best regards,


It's only after we've lost everything that we're free to do anything.
[ Parent ]
gdb & emacs vs. IDE (3.00 / 1) (#45)
by Garc on Tue Dec 19, 2000 at 10:40:07 AM EST

I understand how you feel that you are more productive working with a Visual Studio so you can set your break points and step through your code, with little highlights, etc. I, on the other hand, am not. I sit in front of a windoze box all day at work, coding in Visual Studio. At the end of the day, I can't wait to get home, and say hello to my emacs window and command line debugger. It's where I'm more comfortable, it's my home.

Most of the coding I do at home (using emacs & gdb) is multi-threaded and running gdb with a multithreaded program is a pain (although I will concede the programs aren't huge either). Is it easier in VS? I don't know, I've never tried it. If so, then that's a point I'll give you. I can do the equivalent of break point and watches with if statements and printfs. It may not be elegant, but it works well enough for me.

Emacs is a little rough to get used to, yes, but it is wonderful once you do get used to it. Run a tutorial, learn a couple of basic commands, and you're off to a good start. The only native win32 editor that even comes close is UltraEdit32.

Tomorrow is going to be wonderful because tonight I do not understand anything. -- Niels Bohr
[ Parent ]

Re: debugging (4.50 / 2) (#48)
by SEAL on Tue Dec 19, 2000 at 03:39:53 PM EST

I won't sit here and tell you that debugging a threaded app is easy under any environment. In VC++ you can break and open a window with the threads that are currently running and click to view the call stack for any of them. It's better than nothing, but threaded code (esp someone ELSE's threaded code) can always be confusing.

For what I do, there are two big time-savers in VC++. One, I touched on, is being able to see all members of a class when I type it. Not only that, but the tooltip shows the parameters of a method, including overloaded methods. This saves the time of finding the header file and going through it for that info. Seems trivial, but when there's a lot of code that other people wrote, and you need to use it, this is nice.

My second big time saver is edit and continue. I'm a full time game programmer, and I currently work on AI. This is one of those things that is very subjective when you are trying to figure out what's good or bad. In order to get the game to feel right, you end up doing a lot of trial and error. Being able to set a breakpoint, see what's going on with a few variables, make changes, and then hit a key to compile and continue running where you left off is really cool.

Now maybe there are Unix tools that can do this that I'm not aware of. I haven't looked at KDevelop yet but from what I've read here, I think I'll check it out. There are some good things on the Win32 platform that the Unix folks should take under consideration and vice-versa. Variety is a good thing.


It's only after we've lost everything that we're free to do anything.
[ Parent ]
Anti-visual studio. (3.66 / 6) (#24)
by Luke Scharf on Mon Dec 18, 2000 at 11:18:26 AM EST

IMHO, Visual Studio is evil. Even though I started programming on windows, I've spent hours searching through the "options" dialog looking for things that I can add to a makefile in seconds. Given all of this, Visual's integrated debugger is quite good.

Of course, everyone has their own preferences - I've installed kdevelop for my users. It looks a lot like Visual studio and will generate automake files for you. I've never used it long enough to see if it integrates with a debugger or a GUI builder. Brings back bad memories... [shudder]

KDevelop may make you feel more comfortable - until you need the flexibility that a real Makefile[0] gives you. If this is a tradeoff you're willing to make, by all means use KDevelop! :-)

Best of luck!

[0] As near as I can tell, make is a full-blown scripting language that just happens to have a syntax convenient for resolving dependencies among files. It's pretty cool!

Don't worry about losing Visual Studio (3.25 / 4) (#25)
by linklater on Mon Dec 18, 2000 at 12:15:34 PM EST

I've programmed for a lot of different platforms (mainly games consoles under DOS) and I found that moving from Brief to VisualStudio really p*ssed me off. Visual Studio just doesn't do the things I want it to do. eg

The incremental compilation sucks and gets things wrong too much.
Brief emulation sucks.
It can't deal with split windows at all well (not like Brief does).
I don't feel like I'm in control - I'm just along for the ride while VisualStudio does what it fancies.
It doesn't integrate with Version Control very robustly.

Get emacs running, learn how to write your own makefiles (a very rewarding skill), and get up to speed with Version Control. I've not programmed much on Linux, but I've done a LOT of programming without windows IDE's and I much prefer doing it from the command line. Your best friend is a quick customisable and programmable text editor - Visual Studio just doesn't cut it in this respect, Emacs does.

NB - Anyone know what happened to 'Brief' ? Now that was a good development tool !

---- 'Who dares not speak his free thought is a slave.' - Euripides

Huh? (3.00 / 1) (#36)
by kagaku_ninja on Mon Dec 18, 2000 at 09:57:49 PM EST

The incremental compilation sucks and gets things wrong too much.

Then turn it off.

Brief emulation sucks.

Not sure why this is an issue. You can make it use the editor of your choice.

It can't deal with split windows at all well (not like Brief does).

Works great for me. We are talking about VC++ version 5.0 or higher?

I don't feel like I'm in control - I'm just along for the ride while VisualStudio does what it fancies.

A valid opinion...

It doesn't integrate with Version Control very robustly.

Not sure what this means. In my last job, before we switched to Perforce, we used SourceSafe. The integration was seamless. Not sure how it worked with Perforce, because I quit before the switch...

[ Parent ]
VC's SourceSafe integration... (3.00 / 2) (#39)
by inpHilltr8r on Tue Dec 19, 2000 at 01:25:52 AM EST

...is pretty good until your project develops any form of complexity. At that point it will start breaking randomly, and inexplicably. Much like VC itself.

[ Parent ]
Re: VC's SourceSafe integration (3.00 / 1) (#46)
by kagaku_ninja on Tue Dec 19, 2000 at 02:39:54 PM EST

Ah, that explains it. Our code was not complex enough...

It is true that the SourceSafe database would occasionally become corrupted, hence the switch to Perforce. However the integration with VC was never an issue as far as I know.

And VC would occasionally get weird, too. But VC is way better than the POS Sun compiler I have to use now...

[ Parent ]
A quick recommendation (3.20 / 5) (#26)
by kjeldar on Mon Dec 18, 2000 at 12:32:59 PM EST

If for whatever reason you don't want to learn vi or emacs, and want a syntax-highlighting autoindenting editor for X, give NEdit a shot. NEdit + gcc + gdb is a pretty decent and fairly powerful combination, and if you're migrating from Windows, NEdit comes out of the box with the keybindings you're used to.

Kdevelop is great to start out with (3.60 / 5) (#29)
by Denor on Mon Dec 18, 2000 at 02:01:56 PM EST

I've seen a few mentions about it in the comments here, but nobody's devoted an entire post to it, so I will.

There are many recommendations for Vi/Emacs/NEdit + gdb + gcc here, and I find that's what I'm using nowadays for my Linux development -- however, I started with KDevelop.

KDevelop is very similar to VC++ (at least as far as I've used VC++ :) which makes it fairly easy to pick up. The version I used (1.2; 1.3 is out now) had an integrated debugger which was excellent. It also uses gcc and automake + autoconf behind the scenes, which is great if you decide to move in the direction the less IDE-friendly folks here are suggesting :) In short, it's a pretty good IDE and a learning tool if you decide you don't need it anymore.


further questions (3.60 / 5) (#30)
by depsypher on Mon Dec 18, 2000 at 04:15:42 PM EST

First of all, I'd like to thank everyone for their comments so far, every one of them has been helpful. I now feel like I have a better understanding of what I'll be getting into and what my options are.

The previous suggestions of dev tools (KDevelop, make, NEdit, emacs, gcc, Glade, etc) are food for thought. I'm familiar with CVS from work -- we use WinCVS, which is often a pain (it gets easily confused with local and remote copies. It thinks they're different when they're not and the same when they're different. Argh) Sound familiar to anyone?

One of the things that intrigues me is the idea that C is preferred over C++ for Linux development. How to manage encapsulation and code reusability without the benifits of OO programming? Does this preference toward C apply only to smaller projects? If not, what are some examples of larger projects done in C?

Also, there is the question of which distrobution to install. I don't mean to start a holy war over which distro is best, but does any one stand above the rest when it comes to software development? Does this question even apply? I'm starting from ground zero, so I'm trying to avoid making mistakes on the simple stuff too.

cvs issues and distro ramblings (3.00 / 2) (#31)
by Garc on Mon Dec 18, 2000 at 05:47:54 PM EST

I've been using cvs for a while now, and I haven't had any problems with it. IIRC, WinCVS is just a client, not a server, correct? Do you try to run a diff to find the changes it reports? Maybe the files are changed in a way that don't show up in your MS IDE? Just some guesses to try to rationalize your problems, as I've never had a problem with CVS.

I started with redhat, and haven't changed. I wouldn't recommend that you install rh 7.0 though, I don't plan on upgrading past 6.2 for a while. Perhaps you want slackware, I've never used it, but picked up the idea somewhere that it was a good development environment. Anyone here use it?

Tomorrow is going to be wonderful because tonight I do not understand anything. -- Niels Bohr
[ Parent ]

CVS woes (3.00 / 1) (#35)
by depsypher on Mon Dec 18, 2000 at 07:02:32 PM EST

As far as I know, WinCVS is just a CVS client/graphical frontend for windows. I'm not sure, but I think the server side is operating under RedHat Linux.

The most frequent problem I encounter with it is not being able to commit, 'cause it finds non-existant conflicts. I usually end up saving the offending file(s) out to the desktop, delete the whole local directory, do an update and then copy the 'suspect' files back from the desktop to the local directory. After all this, when I commit, CVS doesn't find any conflicts (if I'm lucky) and allows the commit to go through.

It's very possible that I misunderstand how CVS is supposed to work and many the problems I'm experiencing are actually a case of 'human error'. There are times, though, when it just really seems buggy... To give you an idea, every file has an icon next to it indicating it's status. An up-to-date file has a page of text icon, a file in the local directory that doesn't exist in the repository has a question mark icon etc. Sometimes I commit a modified file (red page icon) and the commit does through (no conflicts), yet the icon stays red. I'm left wondering what I should believe:

*****CVS exited normally with code 1*****

indicating that the commit went through, or the red page icon indicating the file needs to be commited.

Despite these problems, it really is a great tool to have around. More than likely the problems I'm experiencing are in the graphical frontend itself.

[ Parent ]
RE: CVS woes (4.50 / 2) (#44)
by Garc on Tue Dec 19, 2000 at 10:28:49 AM EST

It seems like the problems with the icons is from WinCVS. UNIX command line CVS gives you little letters when you run an update to make you aware of the status of your files, no icons at all in fact. I'm guessing that WinCVS is lazy about updating them, or something like that.

Conflicts often happen when there has been changes to the same section of text in the repository and in your working copy. CVS doesn't know which one it should keep when you run the update.

If there is a conflict CVS should add the conflicting text with markers to the file. You then can resolve the conflict by editing the file, then update & commit.

With your fix, you're basically removing your changes (and all the files), getting the code from the repository, then making your changes (over writing the conflict), then updating & submitting. It works, but it bypasses the checking of the conflict like CVS wants you to do.

If you're doing VB coding (I don't know about other MS stuff), the conflicts could be arrising in the hidden text that MS uses to store things like date, last user, etc.

Tomorrow is going to be wonderful because tonight I do not understand anything. -- Niels Bohr
[ Parent ]

wincvs (3.66 / 3) (#49)
by kubalaa on Tue Dec 19, 2000 at 04:24:05 PM EST

It's very possible that I misunderstand how CVS is supposed to work.

That's most likely. CVS is awfully complicated, and the documentation isn't that great. As with many powerful open-source tools, it takes a lot of use before you really grok what's going on. Especially dealing with conflicts and tracking revisions and things can be very confusing.

As for your problems. First, code 0 is the "success" message. If you got a code 1, something is wrong; scroll through the buffer and look for red errors telling you what the problem is. I very rarely get a case where an icon is marked as changed when it's already been committed. When I do, I just do an update and it fixes itself; it's never caused any confusion. Your "false conflicts" could be caused by a variety of things. I remember a while back I would get cases where a file was locked and I couldn't commit -- I don't think I ever figured out what was causing the locks -- but all you have to do is connect to the repository and manually delete the lock file and the commit should work.

The GUI is nice for seeing at a glance all the attributes of various files (status, tag, revision, etc.), but the fact is if you don't know how to use the command line the GUI won't help you very much.

[ Parent ]

this is a subject header (4.00 / 4) (#33)
by joto on Mon Dec 18, 2000 at 06:06:20 PM EST

[WinCVS] gets easily confused with local and remote copies

Doesn't sound familiar to me. But I have never used wincvs, and I'm used to a repository that is mounted under NFS. But like all version control software, CVS is too complicated.

One of the things that intrigues me is the idea that C is preferred over C++ for Linux development. How to manage encapsulation and code reusability without the benifits of OO programming?

Encapsulation: You don't need OO for encapsulation. You only need clean interfaces. Reusability: I don't know why anyone would need OO for reusability. Functional programming often creates much more reusable code than OO programming (not that it is so easy to do functional programming in C either). But you can do OO programming in C as well. It's just not that convenient, and probably requires a few typecasts, but it can be done. I do miss STL however, but I consider the price of using C++ too high compared to the benefits of STL, so I avoid that as well.

I have some reasons for why I stay away from C++. I don't claim this to be a universal truth (please, no flamewar), but since you appear interested, I should tell you my views:

  1. C++ is much more complicated than C. I prefer to know C really well and use a little trickery, rather than learn all of C++. Also, more parsing-tools and code-generators know C than C++.
  2. C++ has not been stable over the last few years, and gcc haven't exactly tracked the standard very closely. This has been greatly improved upon lately, and in a few years, when gcc 3.x installations become common at most Unix installations will probably be a non-issue.
  3. C++ mangles names in weird and undocumented ways. This can make it harder to reuse C++ code in other languages unless it has already been planned for.
  4. While I can agree to that C++ is in some respects better than C for some tasks, there usually exists another language that is even better for that task. So in some respects, the question "why not use C++?" is somewhat like "why not drive an audi?". It just happens that for this task I prefer my Rolls Royce, ok?

Does this preference toward C apply only to smaller projects? If not, what are some examples of larger projects done in C?

Almost all large free software projects are written in C. The linux-kernel, gcc, gdb, emacs (also written in emacs lisp of course), apache httpd, Gnome, Perl, Tcl/Tk, XFree86, bash, MySQL, Postgres, the list goes on. In fact, the only sizeable thing written in C++ I can come up with in a pinch is Qt, KDE and StarOffice (and note that two of them wasn't even intended to be free software from the start).

Also, there is the question of which distrobution to install.

Do you want to learn as much about Unix as possible, try Slackware, it's a nice traditional Unix installation that doesn't confuse you with anything too fancy. If you want fancyness, GUI configuration tools, packages, automatic upgrade, etc.. use something more mainstream. (i.e RedHat, Mandrake, Debian, Suse) .I happen to use Mandrake. It is a bit buggy, but generally OK. Wouldn't want it for a server, but good as a development box.

[ Parent ]

in favor of C++ (4.50 / 2) (#41)
by SEAL on Tue Dec 19, 2000 at 02:35:02 AM EST

One thing I'll say in favor of C++ is, properly used, it can be much cleaner than C. Maintainability increases as well. If you have a superior C++ programmer at your disposal, get him to lay out the groundwork for your project. With interfaces properly done, it is difficult for other programmers to abuse your code when they start adding on to the project. And yes the STL is nice ;)

With C, your "OO" code isn't always as clear and can be used improperly.

I think there's a lot of resistance to C++ in the Unix crowd just because "C is the way we've always done it" and they don't want to go to something new. I will be the first to admit - it takes awhile to wrap your brain around C++, even if you're a solid C programmer. But a well designed C++ project can really be a pleasure to work on. Working with Gnome / GTK makes me cringe after using KDE for awhile.

Really, though, the choice should depend on the background of the programmers involved in the project. If the project is time-critical, then go with whatever they are most comfortable with.


It's only after we've lost everything that we're free to do anything.
[ Parent ]
GDB is b*****it (1.87 / 8) (#32)
by (void *)0x00000000UL on Mon Dec 18, 2000 at 06:04:35 PM EST

GDB is crap, I wonder why nobody ever came up with a better debugger. I mean the debugger in VS is way more usable and works well. And those GDB frontend like DataDisplayDebugger are a joke. But want a better joke: try the GDB frontend inside XEmacs. Almost everything is unusable with Unix unless you have some years to learn it... And it should not take so long to use a f**king computer

GDB is b*****it is b*****it (3.00 / 2) (#34)
by joto on Mon Dec 18, 2000 at 06:19:53 PM EST

You need to learn:
  • h help
  • r run
  • n next
  • s step
  • c continue
  • bt backtrace
  • p print
  • b break
  • clear
  • up
  • down
How anyone can find that hard to learn is beyond me.

[ Parent ]
*NIX tools vs MS tools (2.80 / 5) (#37)
by kagaku_ninja on Mon Dec 18, 2000 at 10:52:42 PM EST

I started out learning UNIX 20 years ago. I loved it, learned vi; briefly toyed with EMACS (didn't work so hot over 2400 baud modems). However, my career took me away from my beloved UNIX. Years later, I ended up working on Windows. Mind you, I tried not to... After leaving that job, I am now full circle, working under UNIX (Solaris).

Rather than being filled with joy, I feel like one of my arms have been cut off. The VC++ browser is insanely useful. I have tried explaining this to my UNIX friends who have never experienced it. "It's like tags, but a lot more powerful." But this doesn't even come close... When you work on a code base too large to fit in your head, a good brower is essential.

Sure, the Sun Workshop does have a browser, but I wasn't too impressed. Yeah, they have a graphical debugger, that's a bit more intuitive than dbx. Does it measure up to the VC++ debugger? No way...

The browser... People here install VC++ onto their cheap WinTel boxes (used as VNC clients), just so they can use the browser.

I don't know the state of current GNU/Linux tools. I heard that CodeWarrior was being ported to Linux; that caught my eye, having used it on the Mac.

I just wish Linux gurus would move away from the mantra: vi and/or EMACS, make, gcc, CVS...

  • Editor: after learning the Nth cryptic command key based editor (vi, VAXTPU, WordStar, AmigaDOS editor, EMACS; I'm forgetting a few from machines that no longer exist), I deceided that was it. No more. The VC++ editor, while not to everyones taste, enables me to do most everything I want via the mouse and the occasional menu item. vi is pathetic in comparison (I'm sure EMACS lovers would agree :-)

  • CVS: I've never used any of the *NIX source control tools. However, our 100+ programmer organization recently moved to Perforce. Previously we were using Teamware, built on top of SCCS. It was an extreme pain in the ass when applied to large scale software development.

  • Make: I never had many problems with VC++ in this department. The occasional head scratcher, but I have similar issues at my new job using dmake. Lets face it, there has to be a better way...

  • I plan to join the open source movement someday; maybe I'll get off my ass and help improve the situation.

    Sadly, I must agree here... (3.50 / 2) (#38)
    by joto on Tue Dec 19, 2000 at 12:11:13 AM EST

    A good browser is essential when working on a large project.

    I really miss a good source-code browser that works well with emacs. I'm not sure how this could be done, though. I'd hate a half-baked solution only working for the most popular languages. It should be extensible, usable, intuitive, fast, and fit in well with emacs. Maybe it already exists? I haven't found it yet. Maybe I'll write it someday...

    [ Parent ]

    MSVC++ / gcc (2.00 / 3) (#42)
    by avatardd on Tue Dec 19, 2000 at 07:55:14 AM EST

    Anybody who has taken the time to learn to use MSVC++ will know that it is a great tool. It can save a programmer an enormous amount of time. The debugger is truly awesome, no need to get into writing makefiles, a nice editor, etc. What most people don't realize is that MSVC++ produces much faster binaries than gcc. Also, MSVC++ is much more standards compliant than gcc. IMO, gcc and Linux development tools have a long way to go to reach their counterparts.

    Danny Dorris

    Lamers rule Planet Earth (4.00 / 3) (#47)
    by exa on Tue Dec 19, 2000 at 03:25:07 PM EST

    I'm a developer who has worked with both on MS Visual C++ and GNU/g++ and I must confess that I've been very surprised with some of the comments I've read here.

    Let me put it bluntly: MS devel tools are not an improvement over GNU toolchain. It has never been so. The standard library implementations have been *worse*, read *slower* and *buggier*. What you may call 4GL or IDE plain *sucks*. The non-sense editor, the plain useless source code browser, stupid and restrictive resource editing, the undesigned and braindead MFC, and the buggiest compiler available. The moment you start using real C++, you'll bump into an internal compiler error.

    In MS VC++ 6.0 some of those things have been fixed but what I say mostly applies.

    The main disadvantages are IMHO,
    * Macro-polluted and very fragile MFC library. All devel grinds to a halt when you want a slightly different behavior than what MFC authors imagined
    * The worst configuration and build system available. In a big source tree, everything loses its meaning. Very inferior to autoconf/automake or autoconf/make.
    * Millions of editor/class wizard/help system/documentation bugs. My help system just vanished into thin air yesterday. It stopped working; I have to re-install. Click on a function in a large tree and it'll take many seconds to get there. If many windows open, editing will be slow. Click somewhere "wrong" and the whole devstudio app will crash.
    * The "visual" aspects are inferior compared to "Delphi", etc. Why? Because you can get from UI to code, but not vica versa. This makes development very unstable, and inconsistent...
    * The compiler compiles MFC style code well, but *ucks up standard C++ code with a lot of genericity, etc. Crashes badly on a large class of code. Error/warnings are not informative/helpful, and there are arbitrary limits in compiler/linker.

    For whom does this tool work well? Lamers. If you read C++ FAQ, you'll see a question concerning why most of the C++ users are simply newbies to programming. And if I show you a "programmer" using VC++6.0 chances are high that he's a pure newbie.And guess why there are so many horrible programs written in VC++ 6.0

    For those who criticize the gdb and cvs: I'm shocked. Where do you live people? The biggest projects are done with cvs, and in very effective ways. CVS has nice and stable frontends and has a superior working model compared to Source Safe. Gdb has a lot of frontends including DDD and Red Hat insight which are perfect IMO. If you'd like a source browsing IDE, you can get Red Hat's source navigator, or KDevelop. And best of all, these tools are free software.


    PS: I'm the debian maintainer of insight and sourcenav so feel free to ask more about them. You can find information on sources.redhat.com and install woody packages from the main archive now... (the sourcenav maintainer seems incorrect due to a mistake) thanks.

    exa a.k.a Eray Ozkural
    There is no perfect circle.

    The Root Of The Phrase (3.00 / 1) (#50)
    by garethwi on Wed Dec 20, 2000 at 05:11:45 AM EST

    "Only Bad Workmen Blame Their Tools" is a very old phrase, and is based on the old tradition of craftsmen making their own tools.

    Therefore, if you are blaming your tools, then you are blaming yourself because you didn't do a good job in making them.

    This doesn't really apply any more, unless you are Linus slagging of Linux, or RMS having a go at Emacs.

    Developer Tools for Linux? | 46 comments (46 topical, 0 editorial, 0 hidden)
    Display: Sort:


    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!