Why Develop On Linux?

Kidbro asks: "I'm working as a programmer stuck in a Windows environment and know a really cool coworker here who's one of the best developers I've met. He is a Windows coder, though, and today he asked me why he should develop under Linux? What makes it easier? I pointed out the big flora of tools for manipulating files and text, I pointed out the stability of the system - things I as a normal user and hobby developer on the platform think are cool. 'Yeah, but still.. that has little to do with the actual code development, it's merely some fluff beside that eases up maintenance a bit' he replied. Now, since I practically also only have developed under the Windows platform I couldn't really counter this. So I'm asking this crew here, what are the real advantages with developing under Linux?"

After spending the last year developing under Windows in my previous job, I can say that I would highly prefer the freedom of developing with Open Source rather than depending on a closed environment. I have had numerous problems with the preponderance of binary files created by Developer's Studio (and ActiveX's dependence on the Registry) and the the behavior of just building my project. I prefer makefiles and source code, where everything is specified in text and there's an open syntax describing all aspects of the build process. Here's question I would like to ask of all the Developer's Studio users...how can you take an existing MFC SDI (single-window) project and convert it to an MDI (multi-window in a single pane) project? If it doesn't involve creating a new project from scratch, I'd be highly surprised.

So what are your thoughts on this subject? Do you prefer the slicker, highly integrated commercial environments, or do you prefer open ones?

integrated development

[MooseMunch]

where I spend my days we mostly program for windows, but we do our programming on a Unix (solaris) platform. Why? The multi user environment provided by Unix make file sharing a breeze. Code control systems (CVS,SCCS,etc) are more widly avliable (and I think more through). My answer, it's easier to share :)

Well, it's natural...

[Dungeon Dweller]

C and Unix as they stand fit hand in hand, they were born together. This makes programming on any unix-like platform MUCH easier. There are a ton of libraries to work with that have code that you can see and hammer bugs out of. There are a TON of languages, and more compilers and interpretters than you will ever find under windows. The command line is easier to understand. There is less garbage to mess around with. Pretty much, coding in Linux is coding just like you learned it in school. Coding in windows is, sort of like writing a biography about a person who won't tell you anything about themselves.

Don't use MFC as an example of anything

[Jon Erikson]

Ugh, if there's ever been an application "framework" nastier than MFC I've yet to see it. The sheer complexity involved in acheiving some of the simplest tasks is truly amazing - who wants to deal with a huge mess of DDX/DDV commands just to get the value of an edit box into a variable?

Personally I'm using Borland's VCL at the moment, and whilst it, like any other framework, does constrain the things you can do, it certainly feels a hell of a lot more "natural" than MFC ever did - things work the way you expect. As for chaning an SDI app into an MDI app? Well, it'd be some work, but I can see myself doing that without starting over.

No, using MFC as an example of why Windows is a poor environment for coding is wrong. Plain and simple, MFC sucks, and there are a lot better alternatives out there for coding apps in. And since Borland are porting Delphi and C++ Builder to Linux, I'd highly recommend them there as well.

---
Jon E. Erikson

Give MS Visual Studio a Chance!

[superid]

I've been using MS Visual Studio for a couple of years now, and I really like it. It's quite stable, I can't remember ever having the IDE crash, and it's very powerful.

By far, my favorite feature is the popup Intellisense, when you're working with an object or struct and type "." or "->" you get a window with the details of the object at that level. You will quickly get hooked on this feature.

Plus, you can now edit and recompile c on the fly while debugging. That's a big timesaver for me (for correcting "freshman" mistakes like incorrect loop bounds without having to start all over).

And finally, if it's good enough for John Carmack, it's good enough for me!

A sane environment

[pe1rxq]

I find the unix environment and philosophy more sane than the windows one. Like all devices have a similar (to some degree) interface to the user in /dev. In linux there also is less need to get something done real quick and ugly so new things tend to be more thought about.

Jeroen

Two things for me

[The Pim]

1. The libraries you use are open. You can read (and marvel at or laugh at) their source code, debug them, fix them, and participate in their development communities.
2. The API's you program against were mostly written by creative people with taste and community feedback; not by committees with deadlines, backwards compatibility requirements, an internal review only, and a narrow Microsoft mindset.

Really, development on a free platform is just more fun!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:integrated development

[Jon Erikson]

There are code control systems available for Windows as well - PVCS (nasty), SourceSafe (even nastier) and WinCVS, which is just a GUI wrapper around CVS. I wouldn't say that Windows suffers in this department.

---
Jon E. Erikson

Development can occur on any platform

[AndrewSchaefer]

Where I work our developers use windows boxes because that interface is simple for them. They write the code under cygwin and compile with GCC. They can take their code wherever they want since they use a standard compiler. It's not about forcing an OS on people, it's getting them to use tools that will port easily. If they used visual studio or some other propriatary tool it would make things a hell of a lot more complex. The software that they write actually runs on Sun boxes with solaris 7. If you want to push Linux, push GCC. Once they can port their code they will be a lot happier to hear about what else they can do in Linux. I have found that they are most interested in A) a good text editor (emacs or vi) B) Good windowing interface C) ability to display video output from their apps (remote X session or local execution) If that all works fairly simply, I don't think they care a whole lot about what they are actually using.

Your target audience?

[Psiren]

I don't know about anyone else, but the programs I develop are intended to run under Linux, so I develope under Linux. If I was intending to develop Windows apps, I'm sure I'd develop them under Windows. Yes, there are cross platform development environments, but to be frank I couldn't care less about Windows (95 has just trashed two motherboards for me so I'm in a very anti-Windows mood atm).

Anyway, what I'm saying is, if the programs are intended to be run only under Linux, Linux is a good choice for development, is it not? ;-)

Now weary traveller, rest your head. For just like me, you're utterly dead.

Do what you know.

[kwsNI]

It's always easiest to develope on what you know. If you're not familiar enough with Unix to know it's advantages, you probably won't have the experience with it to use it to program.

I'd still recommend checking it out or you'd never be familiar with it. I just don't recommend anyone wiping out their Windows partition, running down to the store and buying Linux and think that they can be a Unix programmer. Learn Unix first and when you know it well enough, you'll WANT to program with it.

kwsNI

More power

[heikkile]

I see the difference between Ms-DevStudio and all the Linux tools a bit like the difference between coding in VB and C++. If all you need is a quick way to put up a simple program, it is easier in DevStudio and all its wizards that create stuff for you. But once you need to maintain this code for a while, or wish to do something the wizards did not provide for, you start to run into problems. Under Linux the initial costs of starting up are a bit higher, but once you have a project going, there are (almost) no limits to what you can do, all files are in documented formats and plain ASCII, so you can just go and edit them. Distributed projects are easier to maintain, with a publicly available CVS repository where anyone can get the latest development version, and a standardized way to submit patches etc. And of course the scripting facilites under Unix make it so much easier to make (semi)automatic regression tests and other advanced stuff..

Let me count the ways

[FascDot Killed My Pr]

I spent several years developing on Windows (3.1 and 95, mostly). The last 7 months have been on Linux (exclusively). Here's my opinion: I will quit my job before I will spend as much as a week coding on Windows again.

1) Multi-tasking: Booting into Windows makes me feel claustrophobic now. I can start multiple programs but if one of them hangs (like Exchange) they ALL do. If you are like me you like to be doing several things at once (emacs here, netscape there, news reader the other place, etc). This is harder (or even impossible to the extent I do it) under Windows.

2) Determinacy: It used to be that when a program crashed I'd try running it again. Then I'd reboot and try again. Under Linux if it crashes I KNOW it was the program that did it (or course there may be environmental factors, like config files).

3) Source code: In the course of just 7 months, I've had to inspect the kernel code twice (and change it once).

4) And then there's all the little things: DLLs. Installers. Command line tools. Now that I've learned how to use the "find" command...well, there's no superlative strong enough to get across how much I prefer Linux.

Here's what you do: Go back to your friend and find out what he hates most about developing under Windows. Then show him how that isn't an issue under Linux. "Linux, it has something for everyone."
--
Less money, less admin, less machine--more power

Consistent API. Source Available.

[1010011010]

I find that Linux is more consistent that Windows. Unix has a philosophy -- everything is a file. It's not followed 100% (as in Plan9), but it's pretty widespread. Windows has no philosophy; it feels like a mash of unrelated ways of doing things.

Also, with Linux (any open-source, really), I can find out what the bugs are. I've been programming with imagemagick recently and ran across a situation where the headers didn't match the documentation. I just lookined in the .c file at the implementation of the function in question, and my questions were answered.

If he's good at Windows programming, though, good for him. It's not easy to be a *good* Windows programmer. And he probably makes good money at it.

Why develop for Linux?

[JCMay]

I'll tell you why I'd develop for Linux, but this comes from somebody that's not a professional software engineer-- at least not on a regular basis.

First, I write programs that fill needs that I see. The last desktop-based application I wrote, IntuDex, was a mailing list manager for the Amiga. It was much simpler to use than the relational database that my user group, Amiga Atlanta [amigaatlanta.org], had been using. Also, I could give it to anybody I wanted, an important fact. As the newsletter editor I depended on the secretary/treasurer for mailing labels. My program facilitated data sharing between us, and I didn't have to buy a $300 program to do it!

Second, I'm a big fan of simplicity. Even as an RF/Microwave engineer I find beauty in reducing complexity (try getting my program to believe that when they see this board I'm working on!). Win32 does not provide a "beautiful" environment, at least from my point of view. For example:

if(IntuitionBase=OpenLibrary("intuition.library,NU LL))

{
if(win=OpenWindow(...))
{
/* do program stuff here */

CloseWindow(win);
}

CloseLibrary(IntuitionBase);
}

is pretty much all you need to do to open a window under the Amiga's operating system. Isn't it like a page and a half of code under Win32?

For me programming should be a joy, not a chore. It's realy as simple as that!

Linux/Unix is for curious perpetual coders.

[Karmageddon]

Coding under Windows is actually easier. If he's used to it, he will not easily make the switch. The reason it's easier is that the Integrated Development Environments are more comprehensive. There's more automatic code generation, there's plenty of code samples around, and plenty of people and books with deep expertise. Now, a lot of experience and smarts exists in the unix world too, deeper even, but your friend doesn't sound like he's in that world so it will be harder for him to tap into.

So, why do it? The reason to do it is that the code you end up with under windows is a big steaming pile of non-portability. In many instances, i.e. if it does anything whizzy, it won't even port to other versions of Windows. And there's tons of totally bogus crap you have to deal with in Windows, interfaces not working the way they are specced, weird... ok, one example: quick, allocate a string, and make it work cross platform. Do you want TCHAR, wstring, or any one of six others. Search MSDN, that will help you decide. ha ha ha.

Unix is for people who like to code everything they do. People who want to write a script to check in and out of source control. This morning, my cable modem was down at home. I whipped up a one line script so it would retry my the net every five minutes so I could make a service call from work and then later today I'll be able to log in from work and get to my home network. (The script: while [ 1 ] ; do /etc/rc.d/init.d/network start ; sleep 10 ; if ping -qc10 207.46.130.45 ; then exit ; else /etc/rc.d/init.d/network stop ; sleep 300 ; fi ; done )

you just can't do things like that under Windows. Oh, I know, there are tools you can find to do each thing, but it's not in Windows' blood. OK, then there's stuff like how regular the APIs are, how simple the inter-process control, and how network capable your apps will be (X Windows was designed for network use. When my home cable modem comes back up, I'll be able to log in from across the internet and use my several machines at home no different than if I were at home.

Finally (yes, there's more to say, but I gotta get to work :) you asked about Linux, and it's unix with all the source available. You can look up how things work, no secrets, no frustration with apps that don't quite do what you want. Apps that don't quite do what you want? That's almost the definition of Windows.

Unix isn't perfect, and Linux isn't perfect Unix, but if you love coding, you'll love coding them.

APIs

[The Iconoclast]

We are doing windows coding at work. Before all I ever did was do a little bit of *nix coding at home and school, and the biggest difference is that because Linux/GNU/BSD/etc is an Open platform, the APIs are actually followed. You can use code directly from an MSDN examle in your windows project and it won't work. Also under *nix you get all of the excellent POSIX calls. You can't use POSIX under Windows, it's not there. I had to write a string parser for a project we were working on without the use of POSIX regular expressions, and BOY was that a pain in the ass.

A wealthy eccentric who marches to the beat of a different drum. But you may call me "Noodle Noggin."

Re:System Calls

[cybrthng]

Well, you usually do. Your right, its not hidden, but for any programmer to come from Windows to Unix it is simply not documentated as much.

Sure you can find those rare Unix books that surfaced a few years back that really dug into the internals/libraries and posix standards but they're so damn expensive!

I'd say give it another year, and the choise will be a no brainer. You will either have A) Windows B) Linux.

With the likes of kdevelope, and the new Gnome and KDE hitting the streets, any gui developer will feel at home and in control of linux

OTH, i would love to see java take off more. OH well. It would be nice to follow IBM's Goal of Platform independance. Nothing like using an operating system which is designed for a specific task rather then vice versa.

IDE's are bad for code maintainance

[robra]

I think IDE's are bad for producing maintainable code. When, after 15 years, you find that you need
to alter a program that was once written using a command line C compiler and make, you can just recompile it using those same tools. If, however
the same program was written using some kind of IDE
with its own kind of project files and stuff you're going to have a hard time finding a copy of the same 15 year old IDE the program was developed with, not to mention a computer that can run the thing!

I think IDE's are only good for write-once programs.

Re:Give MS Visual Studio a Chance!

[numo]

Well, I am also using MSVC and I surely could imagine more stable system, although 6.0 is quite good.

The Intellisense absolutely rocks. However it is not only IDE what counts. I personally can live with vi, make, ddd etc. But it is plenty of mature tools available for M$ environment that makes a difference. Try to profile your code with gprof and then try to do the same using Rational Quantify. Try to make a coverage analysis without recompiling your code under Linux. Try to catch memory errors with ElectricFence - due to how it works it will eat all your memory in a few seconds in all but trivial programs.

Yes, the tools are expensive, but they save a huge amount of time.

The important thing is your comfort level

[substrate]

There are a lot of compelling reasons to develop under Linux in my opinion. It's important to note that disclaimer in that sentence however: In my opinion. My first experiences with programming were BASIC on a Commodore Pet. While in university I did a lot of programming under UNIX and became used to the pervasive way in which text and data could be handled and manipulated.

I also realize that if it weren't for this sudden immersion I wouldn't find these reasons all that compelling. I've coded in MetroWerk's IDE under MacOS as well as with the shell-like IDE MPW (Macintosh Programmers Workship). If I had first used an IDE to program I'm not sure I'd ever have really felt as comfortable without one. Most of the reasons that I feel so comfortable programming in a shell environment under UNIX are due to the ability to manipulate data with PERL, sed, awk, sort, cut, paste and so on. I'm not sure that most people get data in alien formats (if you produce the data, you've got some control over the format, if you produce a format that you can't use then you didn't produce a very good format).

I've toyed with IDE's under linux but haven't ever felt the need to change. Under MacOS I prefer an IDE. Under MacOS X I will probably prefer command line utilities.

I think the important thing with anything is to be comfortable with what you are using regardless of whether somebody else feels that there is a better opinion or not.

Better UI.

[korpiq]

For a software developer, the system environment is the UI.

How handily can you find stuff in your log files?
I use grep and perl for that.

How often do you have to reboot an unstable system?
I don't. (well, except for netscape)

Starting any services required in production in your sandbox without stability or resource exhaustion issues. Oracle, Apache...

Multiple desktops = almost unlimited number of windows, all neatly organized. This is /not/ the smallest reason. As well as the fact that you can configure your wm to respond in any way you want: kick windows behind each other, etc.

On the contrary

[FascDot Killed My Pr]

"Unix it is simply not documentated as much."

I agree that it's easy to find references to Windows API calls. But it is easier to find documentation on Unix system calls. Just take a system call and do a search on Google. You'll get back 5 tutorials, 4 online man pages (from 3 different implementations) and several mailing list discussions.

As for expensive books: *shrug* Which would you rather have? One expensive comprehensive book (like Stevens) or 15 "Windows Development Bibles" at $10 each?
--
Less money, less admin, less machine--more power

Everything's a file

[Stiletto]

When I moved from Windows and started coding for Linux (and unix in general), what really impressed me was how easy it was to do I/O. You open a file, read/write, and close it. There's none of that IDirectSound2->QueryDeviceAndPrayToGod() crap. It's SIMPLE.

Need information from about the system? Just read a few files from /proc. You don't have to go find the undocumented hidden Win32 call that only works on Service Pack 3.

Linux has another advantage in that it ships with vi, emacs, the standard development toolchain, bash, perl, etc., which once you get used to, totally blows Visual C++ out of the water as far as ease of use and customizability goes.

Re:Well, it's natural...

[vulgrin]

Great post... I think you hit it directly on the head. I'm trying to learn c++ now, and after years of misstarts by trying to do windows programming, with MFC and all its guckiness, I finally started doing some simple command line stuff under linux.

Man... so much easier and it actually makes sense! I'm also quite impressed that I can, with my rudimentary knowledge, can look at the Linux kernal code and actually follow it, where-as a calculator program written with MFC boggles my mind.

Simple is Better

Re:Give MS Visual Studio a Chance!

[V.]

FWIW, there is an elisp package that works pretty
much the same way as IntelliSense except that
the info shows up in the um....what is it called...the little area at the bottom in emacs.
I had it working at one time but never really
used it so I don't remember what it's called now.
I'm sure you could find reference to it on Deja
tho.

My three answers.

[tcdk]

I've read through the first twenty comments and non of them has really answered the question.

1. Open source libs. This is not a matter of OS.
2. MFC sucks. This is not a matter of OS.
3. It's stable. I've never lost a line of code due to a NT crash.
4. Nice editors/tools. This is not a matter of OS.

I can only see three answers to this question

a) You program in and for Linux when your customers ask you to do it and pay you for it.

b) You don't need more money and want to do your bit in the fight agains The Evil Empire.

c) You need to run something on hardware that whon't run Windows.

I know that some people dont like reason a) but this is the world that most of us live in.

TC - SFBook.com [sfbook.com]
--

Tip Sheet for those replying

[Anonymous Coward]

I use linux, and I can see where this is going....

People will post lots of replies saying something like "linux offers lots of languages and open source libraries, and heaps of tools that are cool and don't crash, unlike certain other companies' software". This will be marked "Insightful", and leave the original query unanswered.

1) Try to think of the person in question - someone who programs windows and *already knows* the above arguments about linux, but is not convinced. Try to imagine their mindset. What would your knee-jerk reaction be if someone told you that OS xyz is better than linux for dev?

2) There are already lots of libraries in windows, and lots more tools with lots more features than in linux. The IDE envs, testing suites, database tools and utilities, libraries and packages available for Windows make a formidable lineup. It's not for nothing that Windows has such a strongly hooked developer base (check out your local newsstand for evidence). This is why companies and individuals are impressed by a rich development environment with lots of options. Don't expect people to be convinced by Glade and Gimp and a far smaller lineup of software tools - explain why linux would still be better, or other things that compensate for the weaknesses.

3) Don't use ideology. If people wanted to program in linux because it's open source, they already would be doing so. Use a better approach. Not everyone finds ethics and the principles of open source a convincing reason (otherwise they would already be using linux, so you're preaching to the choir).

4) Compare point by point. If you say something is good about linux, think about whether Windows has an equal or better choice. If so, it's a redundant argument - not likely to convince.

5) Avoid zealotry. It turns off people. Really.

Money...

[fluxrad]

pure and simple.

When you talk about anything, it pretty much comes down to cold hard cash. Everyone wants to know "What's in it for me?" Well, i'll tell ya. Money! If you look at the market share linux has gained in the past few years you see what's going on in the computer world. More and more people are switching to linux. Linux's market share has gone from almost nil, including servers and (especially) home users, to brawling for second with MacOS - that is one hell of an accomplishment. What does it mean. People are going to keep switching to linux and there's a veritable gold mine waiting to be dug in the software market. The same people that are installing default RedHat with GNOME or KDE and trying to figure out why linux is so "cool" are the same people that want Apps for linux.

Well, it's not free....these people are coming from a closed source, pay-to-play environment. You give them good software, open-source or no, and they'll pay for it!! If your friend were to develop an audio app that rivaled something like Rebirth (i swear if someone mentions FreeBirth i'm going to flip my lid)....i would be willing to shell out the cash for that. And so would a LOT of other people that are looking for that type of software.

Why develop on linux? Because there are a lot of gaps out there as far as linux software vs. windows is concerned. And as more and more people switch to linux from windows, the value of closing those gaps is going to increase exponentially. Develop for linux and make a BUNDLE! look at Loki, RedHat, VALinux, and all kinds of others. The way I see it...you either lead, follow, or continue to develop for Windows.


FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network

Because...

[oren]

On Linux (or any UNIX, really), you get the benefits of tools written by programmers for programmers. With a choice between several high-quality competings tools. For free. And if the best one is just close to what you need, well, being a programmer and given the source, you can make it into exactly what you need.

Take for example Aegis [pcug.org.au]. Find me a tool like that for Windows which costs less then 1000$ per seat. Or compare the editing power of UNIX editors to the pitiful editor built into most IDEs - not to mention their brain dead build process (BTW, both Emacs and VI can and are commonly used as a UNIX "IDE" to great effect). It goes without saying that you can't replace your IDE's editor or build process, even if you are willing to pay.

Sure, UNIX developement tools are harder to learn (they are not harder to use). But one can hardly claim to be a serious professional and dismiss the UNIX tools as too hard to use. These tools simply assume a power user - one willing to invesrt the extra effort to get the (large) additional benefits. That's what being a professional programmer is all about.

Standards and Integration

[LondonFish]

I have seen the future, people, and in it there are a multitude of computing devices, not only PC's the way we see them now, but also PDA's, set tops, even computers in your goddamn fridge!

Sucessful development in the future will be by people who understand standardization, integration and adherence to open protocols. From my linux box I can, using protocols like X, http, nfs and things like CORBA and Java, share data and apps with other linux machines, solaris, BDS, hell even Windoze if I want, and using this stuff is kind of natural when developing on linux as most open source software and libraries out there are based on open standards, making portability and interoperability much easier

Contrast this with our poor friend who is stuck with such hideous and non stardard thinks like MFC (ugh) anc COM (double ugh!)

Now excuse me while I port gcc to the toaster

If you just want Windows code, develop on Windows

[jht]

The advantage of developing on Linux (or just about any Unix) is that it's a consistent, simple, and well-documented environment, with good portability to other platforms. If you develop on Windows as your primary platform, it's easy to get trapped into using hidden and undocumented API's that don't behave consistently from version to version, and it's real easy to wind up with Windows-only code.

Windows-only code isn't automatically a Bad Thing, but it does reduce your options going forward, and it links you inextricably to the Beast. Should there be a strategic need to change platforms a some point, it's going to be a more difficult task to go from Windows to Unix (or whatever) than the other way around.

That said, Visual Studio is a fairly slick IDE, though there are nice IDE's on Linux, as well. If you're developing for Windows, Visual Studio is really nice.

- -Josh Turiel

Re:Give MS Visual Studio a Chance!

[Keithel]

I'll agree with this. I don't particularly like the editor (I'm a vi person myself), except for the ultra-mondo-cool intellisense feature, but the plethora of good quality 3rd party tools like Rational Purify, Quantify and (esp.) Clear Case is quite nice. The tool integration is especially nice with clear case. Things hardly ever crash, which is *NOT* the case on linux or other unices (this is development tools I'm alking about). The debugger is quite a bit nicer and easier to get used to (and just as powerful) than ddd. Many times, on complex CORBA apps, gdb and/or ddd has crashed and burned.

I think part of the reason that dev studio doesn't crash much is that M$ actually uses it to develop code, so of course it is going to be clean -- they have a lot of beta testers and dev studio fixit people. :)

Keithel

You need the right tools for the job.

[EnglishTim]

If your friend the developer is developing software for Windows, then it surely makes sense for him to develop in Windows. For him, he needs to use the right tool for the job. MS Dev Studio isn't fantastic in all areas, but it's not bad, and most importantly, if he's developing Windows applications, it's probably going to be easier than cross compiling from a Linux platform. Also - Windows has all the other development tools you could want - CVS, RCS etc... and if you need to do lots of scripting stuff for maintainance, there are all the GNU tools - remember, they're avaliable for Windows as well. As Mr. Stallman would say - "It's GNU/Linux"...

Re:Your target audience?

[Psiren]

I bought a new KA7 board and moved my old disk across from my old system. I booted the machine up into Linux and it worked just great. I then proceeded to boot into Windows 95 in order to install the new motherboard drivers etc. Windows did its usual clucnking around and finding new hardware then asked me to reboot (no option to install drivers yet). I did this and bang, nothing. No POST, no Video.. sod all. I thought it was just a coincidence and that the board was faulty so I had it replaced (this time with a KA7-100). This had been running fine with Linux for a week until yesterday when I thought I'd give Windows a try again. And guess what... reboot... bang.. no board. Coincidence my arse. Windows is fucked ( and no, its not a virus as the windows partition has hardly been used in 2 years and is neither networked nor had any programs added for a long long while). I'm nuking Windows when I get my board back. Here endeth the lesson.


Now weary traveller, rest your head. For just like me, you're utterly dead.

A Stallman story

[Kaufmann]

A young programmer once asked Stallman: "How can I do Rapid Application Development for Linux?" To which Stallman replied: "If you want to develop applications rapidly, I suggest looking into Scheme."

Of course, what the novice really meant was "how can I cook up pretty-looking programs with the bare minimum of knowledge and effort and call myself a Linux programmer?" In this (poorly paraphrased) story, Stallman illustrates what I consider to be a fundamental difference between the school of thought that says "get it done the quick and easy way" and the school of thought that says "get it right".

Whether this dichotomy is related to the Windows/Linux development dichotomy remains unanswered... just take a look at the source code for a typical "Open Source" Linux project. Ah well.

I prefer Linux/UNIX

[Anonymous Coward]

I use Visual Basic at Work :-( but now I have access to a UNIX account I'm using Perl to autogenerate most of my code (all the fluff thats needed to support the business logic which is what I really ought to be writing).

My questions for Windows programmers: How many times have you been annoyed because VB's compiler gives up on the first thing it finds? Do you just shrug it off when the SourceSafe integration fails to integrate? What when VB saves your work in a completely different place to where the rest of the project is, and hides this detail from you (or have have you learned to work around that one)? "Wot No Layout Managers!?!". Would you like to be able to switch editors at will and still work?

I think the last question is probably the most important. Under Linux I can switch tools as I need. I can use different tools to the rest of my team and we can all get on together. There are development environments for Linux that have things like Intellisense if you want to use them. I use Vim or Emacs depending on the job in hand. Because so much in Linux is text based I have a wealth of really powerfull text manipulation tools to work with. The perl example above shows this.

A lot of work now is web based. If you want "Commerical Environments" then look at things like Enhydra, Java, JBuilder, ... A lot of web work uses the likes of Perl and PHP and Apache as the server. Linux is really strong for those languages. Also the ability to fully remotely administer a Linux (or any UNIX) Apache server really helps. People where I work are fighting NT at this moment because they can't remotely administer the IIS server.

In terms of environment. Linux, in comparison to Windows IMHO is a really well designed logical platform. When you look at how the file structure is organised and why it really seems to make sense. I've explained things like why /bin, /usr/bin and /usr/local/bin to people and though "That is good". Also why PINE has /etc/pine.conf.fixed, /etc/pine/conf and most importantly ~/.pinerc. The UNIX/Linux world has already had to solve the problems of dealing with a multi user environment, problems which the Windows is now starting to see as Microsoft bolt multi user capabilities onto Windows. It seems that system/user preference handling in WinFrame is particulary "interesting"

except

[kaisyain]

You can do all of those things under Windows.

Emacs, vim, gcc, python, perl, tcl, sed, awk, grep, tar. All available under windows. So you have all of that PLUS nice GUI IDEs.

I haven't found writing console apps any more difficult under Windows than it is under Linux. Writing GUI apps is as difficult or as easy as the underlying toolkit makes it. You don't have use MFC under windows, anymore than you have to use raw xlib calls under linux.

Develop on what your target customer base is...

[CormacJ]

I am a multi-platform developer. I write and maintain code on VMS, Windows, and Linux.

I've used nearly every type of tool there is to develop on, so heres my 2 cents:

General: All systems support whatever language you want to code in. C++, Pascal, Basic - these are all available. CVS is available on all systems. What differs is the user interface on the development tools on the systems, and the amount of learning time you have to spend before commencing coding.

Windows: Developing on windows is a good way to get to know the closed source system. Documentation is hard, and is often expensive to come by. Mostly people develop code using Microsoft tools. These tools look pretty and work ok. They allow you to edit, compile and run code. As a development environment is good. Whatever you want it there within easy reach. To start developing seriously for windows you are best off buying the Microsoft developer tools. You need to be prepared to continue to upgrade everytime Microsoft release a new OS. This is very costly, and not something a teenager can easily get into. There are free tools for developing under windows, but the windowing system calls make it a nightmare to be productive. Learning time is almost zero - mostly if you draw up your screen and hit run, it will. This can be a drawback in a large app if you need to maintain it on a daily basis - it can be hard to get to module you want quickly.

VMS: This is not something that is often done in someones bedroom. Alpha machines can be expensive, and follow the Apple style of making sure you use everything that Compaq can produce. The tools are good, and the documentation is excellent. The librarys are well documented, and do exactly what the docs say they will. Only in rare cases will these change radically enough to break your code. Developing under VMS is about the same as linux. You have good tools and good documentation, nothing too flash or pretty, but it's all very functional. Standards are so rigoursly enforced that as long as you obey the rules you'll never have to worry about your code crashing because of a conflict with some other piece of code. The drawback is that VMS developers are rare these days and good help is hard to get. Learning time is short, as the tools are basic enough to do exactly what everybody needs to do.

Linux: Developing under linux is nice. There are a lot of tools and a lot of people available to help when something happens. Newbies are very welcome. The range of linux distros and linux ports make it hard to write code once and forget about it. You need to figure out tools such as autoconfigure if you plan on being multi-vendor/multi-platform. Linux isn't as easy to code for as windows is, but if you are developing under open source you will get excellent peer review if your code is something everyone wants. Many of the tools are similar to other systems, but many have been scaled up to support world-wide development. Learning time can be long if you have to start a project from scratch, but is simple enough if you just want to contribute.

Depends on your project

[harmonica]

I think it's rare that you have to do a project that has to work under both Windows and Unix so that you'll have to make a choice on which of both to develop. If it's a pure Windows or Linux app, there's no reason to do it under the other OS. If complex tools are involved that must be used, again the choice has been made for you.

If cross-platform development is important, use the OS with the best tools available. Personally, I need a shell, a compiler and a good text editor for the stuff I write (not that I'm doing really big projects). They are available for Windows *and* Unix, so I just follow my personal taste and pick the one I like better.

Re:Give Emacs a Chance!

[tjwhaynes]

By far, my favorite feature is the popup Intellisense, when you're working with an object or struct and type "." or "->" you get a window with the details of the object at that level. You will quickly get hooked on this feature.

Hmm. If you like that sort of thing, I can see that might be useful. That's a pretty trivial hack to make something like Emacs do that for you if you wanted it. Maybe forty minutes of thinking and coding to add a reasonable working version which scans all the included files to pick up the struct definitions. Better still, if you use Tags support under Emacs, you don't have to go search either - you can just look up the details.

Plus, you can now edit and recompile c on the fly while debugging. That's a big timesaver for me (for correcting "freshman" mistakes like incorrect loop bounds without having to start all over).

Not to decry this feature - it's extremely useful - but I do this all the time. With Emacs. Now why use Emacs? Mainly because once you have got over the initial speedbump of actually learning how to drive Emacs, you realise that anything you ever find repetitive or clumsy can be automated, speeded up or helped along with either a quick reconfigure, a new library, or in the worst case scenario, a few minutes of thinking and a few more of coding a new Emacs function. It's this extensibility that makes me realise that I shall never really pick up another editor for anything complex. For all you VI users who are gnashing (sic!) your teeth over this, I use vi as well, but more often than not for simpler editing tasks.

Cheers,

Toby Haynes

Re:Well, it's natural...

[DeadSea]

I used to code only on windows. After I was introduced to linux, I found that the command line was amazing and that gcc and other gnu apps just rocked.

From the cygwin project, you can get bash and other gnu apps (including gcc) for windows. Now my windows interface and linux interface are very similar. I can comfortably develop from either. The OS should just get out of your way. I can make either do that.

However, each has tools that the other doesn't that I find indespensible at times. My suggestion is to develop on both. That way your programs may end up cross platform as well....

Re:He Should Develop on Linux if.....

[-brazil-]

.....he likes arcane command line tools.

... that can do whatever you need, when you need it, while the Windows user is lost when his narrow GUI doesn't offer a checkbox for what he needs.

.....doesn't care about productivity

What exactly is "productive" about rebooting because your beta app crashed the system or you're not sure whether the app might work after a reboot?

(intellisense, integrated debuggers,

emacs, emacs (if you need it), perhaps kdevelop

debugging a web page, its server side scripts, its client side scripts, and binary server side code simultaneously).

On Unix, you can do as many things simultaneously as your mind can handle, and that is the only barrier.

.....wants to manually create his own MAKE files

... which he then understands and which he can fix if they're broken or recompile too much. The little time spent there is well worth the gain of reliable project management.

....wants to be stuck in a world without a component architecture

What exactly have badly documented system calls to do with a "component architecture"?

what the Linux developer community doesn't get is that Microsoft goes out of its way to take the chore out of programming and allow you to concentrate on the problem you are trying to solve.

More like "allow you to concentrate on paying their license fees, their support contracts, suffering DLL hell and frequent reboots. In what way does Microsof "go out of their way" to do anything except squeeze more money out of their customers?

Re:Give MS Visual Studio a Chance!

[lordmage]

Heh, Since I am a Solaris/HPUX programmer we use Purify constantly and the purify product line from rational.

HOWEVER, I think that parasofts insure product line is sweet as well. If you talk about spending money, this is much better than electricfense or even most of the other windows products. The deal here is that parasoft is cross platform and support linux.

Yet another whish list

[bockman]

Important :

Multi-file editing (and opening each file only once)

Integrated editing/compiling/debugging

Availability on both development and target platform

Shall accept files written with other tools and shall generate files which can be modified with other tools

Useful:

Syntax highlighting

Search by variable/function/classes

Version control

MMI visual editor

Optional:

Graph generation

Project management

Conclusions : I'm quite happy with Emacs, but I might taste somenting different from time to time.

CORE DUMPS

[Anonymous Coward]

Nuff said.

Re:*rolls eyes*

[Junta]

Exactly what is intellisense? Personally, I hate
emacs, but love vi. (Which can be run under
windows too. I can't think of any features I'd like that vi doesn't have.

X is not that unstable, bloated, debateable, but still pretty solid, not as solid as the kernel, but solid. At least when X crashes, 97% of the time a reboot is not required. Even if X crashed as much as windows, at least time to recovery is short, as you can immediately restart X without reboot.

As to the blackbox model, that is plain bs. In the OSS world, most things could be treated as a black box, and work fine. You never *have* to look at source if you don't want. You certainly can't argue that it *hurts* you to be able to see how the calls you need are implemented.

And dependence on the registry is NOT akin to depending on the file system. That is the dumbest comparison I have ever heard. The registry is a centralized database of settings used by programs stored in a proprietary format in a singular spot on the disk, where if one thing corrupts it, many applications cease to function, a central spot for malicious programs to look for sensitive information. Sure something can corrupt the superblocks of a unix filesystem, but windows filesystem is also vulnerable, if not more so. The registry adds whole new dimensions of problems in security, reliability, and system administration. I have seen registries get so trashed before, and I have grown to hate having to be the administrator of such crap.

Re:Give MS Visual Studio a Chance!

[goodviking]

The issue here seems not to be "developing windows apps is better than developing Linux apps" but "there are better IDEs on windows than on Linux". These are separate issues. Granted there may be a larger and more established set of IDEs for Windows, but when you get down to the core of programming on the 2 platforms, it comes down to:

"given an equal set of tools, which contains easier and more logical standards to which to code"

I have found the Win API and the MFC to be cumbersome at best and the support base to be lacking. On the other hand, I have found *nix programming to be better documented, have better adherence to standards, and to have a better support base. Further, with Linux, if you can't figure it out, look at the source.

Tools will come as the number of developers working on Linux boxes increases. Look at JBuilder for example. Excellent Java IDE with a Linux port.

Fundamentally though, I would hesitant to invest my time and effort mastering interfaces and techniques that are owned by a company which has shown no hesitation to arbitrarily change them. Probably the best example of this is a colleague who tried to compile some simple examples from "Mastering Visual C++ 5" with Visual C++ 6. The source wouldn't compile and the reasons weren't readily apparent. That to me is not good developer support.

Substandard C++ compiler, libraries, etc...

[gtt]

The compiler in MSVC++ doesn't support the latest C++ standard, especially in the area of templates. In addition, it doesn't support the Standard C++ Library as described in the latest version of Stroustroup.

Also, having the full source for the system libraries and the operating system is important when debugging. I've been able to fix/extend things that I couldn't on Windows.

Thread support in Linux is robust and follows the POSIX standard. If you have to write portable code, this can be important. Also, most textbooks and references on threading address the POSIX standard pthreads library.

A rather big one: sockets and file descriptors are unified under Linux/Unix. This means that the system API's that apply to files also apply to sockets. Because TCP/IP was added to Windows later in the evolution of Windows, the socket descriptors are not interchangeable with other system objects, so WaitForMultipleObjects() in Windows cannot wait for a system object and a socket at the same time. This can complicate socket programming.

Windows takes a huge performance hit because its DLL's are not relocateable code, and the runtime loader in Windows must patch each call and jump instruction in the code when the DLL loads. In addition to taking a huge amount of time when a DLL is loaded, it pollutes the swapfile with multiple copies of the DLL because of the patched instructions. Under Linux, shared libraries are position-independent, so they do not have to be patched at load time and they may be paged directly from the shared object file, thus not polluting the swap file.

That's all I can think of off of the top of my head.

Fluff?!

[dkh2]

System stability is "fluff?"Coding and file manipulation tools are "fluff?"gcc is "fluff?"

I beg to differ.

What about the fact that you have access to a truly complete definition of the API? Does this guy realize that there things that MS does with their code that others can't because the API is less than fully documented in the public arena?

Additionally, if you want to compile on a MS platform you pretty much have to shell out several hundred dollars for your tools. On Linux your tools are included with the distribution that you can acquire completely free from many places.

Let's see here, Linux has:

• Stable systems
• Free OS
• Lots of FREE tools, Woohoo!
• Open API

Whereas, Microsoft has:

• Questionable stability
• $200+ for the OS
• Expensive tools
• Only a SEMI-open API

I think Linux wins 4-0!!

It's all about the tools!

[harshaw]

Hey people,

Read the subject. The whole point of using the Win32 platform at this stage in the game is the massive number of developer tools that Microsoft has been building for the last 15 years. Imaging the Microsoft environment as a pyramid: VB, ASP, ADO on top, COM, MTS, active directory, etc in the middle, and the Win32 API at the base. Of course this is grossly simplified but it exemplifies what is unique to the Windows development environment.

Case in Point:

1) The Win32 API is similar to Linux system calls; create files, threads, events, mutexes, etc. While you can argue that there are major architectural differences, they both provide the same level of support to the developer.

2) COM, MTS. Now the differences start to show. Linux does not have a component model that is widely integrated or used across multiple projects. Of course, newer works like GNOME are very component driven and may end up driving the defacto component model for Linux. However, on Win32 almost anything can be done with COM using a bit of VB script (can you say Melissa virus?). MIS people can tie together a bunch of different packages using COM. In Linux you have to resort to a wide array of command line tools that have different syntax, different configuration file formats, etc. MTS provides easy to write transaction support that is almost too easy to use.

3) VB, ASP. For anybody who has used these tools they are probably very familiar with their limitations. Is VB or ASP superior to other high level scripting languages? NO!! However, VB & ASP can access thousands of objects. You can create a fairly sophisticated UI in VB in a couple of hours. If you want a new control for your UI chances are someone has already written it.

The moral of the story: The application developer has a whole suite of tools they can use to rapidly develop high level apps. It may be a stinking pile of crap but for the most part it works :)

IMO, the java technologies are still the Windows killer for development internet apps. JSP and EJB sounds like it may be much better (and more fun to develop) than using VB and COM.

Bah! I second this!

[Anonymous Coward]

My friend, a Linux lover, and I argue periodiacally about the philosophical differences between Linux and Windows (NT; 98 is a bomb).

Many of the points brought up by TummyX are valid ones. Sure,they can be refuted, but he could then counter-refutre them.

The key is its a philosophical difference. Linux lovers might say "Linux's command line is superior!" Superior to what? NT's command line? OK, yeah. You know why? Becuase the NT command line is an unimportant accessory in NT while the GUI tools are central to it. It's a philosophical difference.

Like any philosophical difference, you will hardly be able to convince people to give up their current beliefs, morals and understandings to see your point-of-view. Why try?

Re:Why develop for Linux?

[gserre]

... is pretty much all you need to do to open a window under the Amiga's operating system. Isn't it like a page and a half of code under Win32?

With Visual Basic : Win.Show

Re:Well, it's natural...

[java_sucks]

Bingo!! I learned how to code on a VAX VMS back in the day. I had played around with little programs in Win 3.xx and Win 95 but hated it. It seemed confusing and I never really felt any passion for it. When I discovered Linux a few years ago it was like being in school again only better. (no exams to worry about :)

In the Windows environment it always felt like I was fighting everything, nothing seemed intuitive. With Linux it's just the oppisite. The *nix environment makes more sense to me, it simple and clean. The Windows environment goes to great lengths to hide things which just muddles it up. Also I'll take emacs over visual studio anyday. Now before anybody gets worked up over that let me state that it's a matter of preference for me, I'm not saying that it's better or easier for anybody else but it works for me. With Linux I feel like the only limitations are my abilty to think and be creative.

In conclusion I would have to say that for me it's just simply matter of personal preference, your milage may vary,

Why? (kind of long I guess)

[SillyWiz]

Well, I've done all sorts of stuff, I've done VB development, Access, Paradox and C++ for Windows. I've developed for the Mac, for embedded systems, for tons of flavours of UNIX, and the reason to use UNIX, for me, has to be the documentation. Mac has this advantage as well, with the proviso that you have to buy "Inside Mac". Once you've bought it, you've got a UNIX level of documentation.

When you want to know what something does on UNIX, the documentation is there. In /excruciating/ detail it describes the API, and everything it can do and everything that can go wrong.

Windows /has/ the documentation available, but it's somehow much less accessible. Firstly it carries a lot of layers about with it: there are multiple image formats, and multiple string types and layers of API and not all of what you can do in one layer is wrapped in another layer.

Secondly, the documentation is scattered around. It's a lot harder to grep for things: you have to know exactly the right trigger phrases to get the info out of the help systems. (To be fair, it's hard to grep dead trees, but Inside Mac comes with an index volume bigger than the Bible to help on that front.)

Thirdly, the documentation is often simply out of date. Windows chanegs API at a scary rate and it's hard to be sure what you're reading is applicable or useful.

The fourth problem I found is that the API levels are incomplete. They lack details. Obvious example; loading images in MFC in a format to display them. It's horrible and code that gets repeated over and over. It needs an image class to handle that, and several dozen are available but are 3rd party and hence buggy or licenced or shareware or unfinished or unsupported or...

There's no way to tell what will remain a supported interface: Will this DX5 call still work in DX8? Who knows. Macintosh has promises of support attached to the APIs.

I found projects annoying on VC++ as well as other people here, but I didn't on Codewarrior so that might just be the way they're done. I dislike MFCs dialog accessing stuff: Delphi does it much more elegantly.

On the final front, the whole concept of having stuff like running a window being so complicated that tools are needed to generate the boilerplate code to save people from the tedium, kind of indicates that that code is too complicated. On a personal front, I'd much rather have it take 3 lines of code to drive a window than have a tool to write the 300 lines for me.

Microsoft is running with two huge conflicting goals: the first is to drive stuff forward creating new APIs, but the second is not to outdate anything ever. Coupled with their financial issues ("ship it quickly") means that they layer things but layer them badly - some of the layers have thin bits which expose lower level nastynesses, others parts are too thick to expose useful functionality.

The solution to windows being complicated to develop for is to /make it simpler/, not to hide that complexity behind wizards. The problem there is that the minute you try and do something the wizard isn't expecting, you're dropped off into this ocean of complexity with little or no support. This leads to a development style where that which is "possible" is effectively determined by that which the wizards support - and that often there is one way of doing things, because any other way, no matter how obvious leads to complexities and incompatibilities and huge amounts of effort. The example given of switching an MDI to an SDI project is a perfect example of this: you aren't supposed to. You're supposed to make that decision on day 1 of the project and stick with it. Access never used to export new toolbars along with the database: toolbars have to be built on each user machine. Corrollary: Access is designed to be used in a fashion where the development machine is also the deployment machine... anything else requires a fight.

MFC uses macros instead of virtual function calls to dispatch window messages. Why? Because using vfunc calls was too slow in early versions, given the volume of window messages generated. So now it has this history of macros and general untidiness dealing with that sort of thing.
UNIX never had the problem in the first place. Why? Because X allows you to choose which messages are ever dispatched in the first place, rather than sending them all and letting the app sort out the wheat from the chaff. Manipulating the macros is complicated and error-prone, so now a wizard does it for you: a patch on the patch on the...

UNIX concentrates on being small, layers appear only slowly and are more complete. And at almost all layers, there are interchangeable options. Different shells, X servers, editors, window managers.

This smallness makes it easier for the layers to be complete, and uniform in shape and well understood.

The downside is that it does take it longer to evolve higher layers - media players and so on.

Re:Give MS Visual Studio a Chance!

[ddstreet]

By far, my favorite feature is the popup Intellisense, when you're working with an object or struct and type "." or "->" you get a window with the details of the object at that level.

Visual Slickedit [slickedit.com] has this and many more features and is availble for almost all UNIXes. Trial versions [slickedit.com] are available.

Slickedit is expensive ($299), and closed source, and most of its (and other editors) features can be reproduced in vi and emacs, but I like it. Especially the feature you mention.

Incidentally the latest issue of Linux Journal [linuxjournal.com] has a review of Visual Slickedit [linuxjournal.com].

Re:On the contrary (Slightly OT)

[Tim C]

On the subject of Stevens, I have "Advanced Programming in the Unix Environment", and would thoroughly recomend it to anyone wanting to get into "serious" Unix-based programming.

It is comprehensive, detailed and well written with clear examples; quite simply the best computer-related text I've ever read. It is pricey, but well worth the money.

Cheers,

Tim

Re:Let me count the ways

[dattaway]

To be fair, point #1 isn't valid for NT.

I work at a manufacturing plant that decided to use NT to control its production lines. When the server quits or refuses to stop taking connections, all the NT clients start bluescreening or hanging. Believe me, that gets your attention every time.

Re:Bah! POSIX does exist!

[Amphigory]

Oh it doessss? Where is it? Posix requires that you have a number of programs, for example a borne compatible shell. Where is it? Posix requires certain library interfaces? Where are they?

The answer for 3.51 was "buried on some cd somewhere, notincluded with the default NT install". The answer for 4.0 is, I assume, the same. I will challenge you, or any of the other MS apologists, to name one commercial program successfully using NT's POSIX module.

--

Re:Bah! Counter-example

[FascDot Killed My Pr]

3) "But what happens when you want to distribute your code and it relies on the 'fixed' code?"

Put a workaround in your own code but use a fixed kernel if it exists. Eventually you can remove the workaround. Are you saying it would be better if you COULDN'T fix (or even see) the kernel code?

4) "Hey, some of us prefer a point-click-drag to 47 keystrokes."

Please tell me how to use an IDE to do the following: "Mark all files currently tagged V31-BETA2 with V31, other mark the head of the tree V31, skip files in the ldap directory and anything that ends with .m". That's one (fairly simple) command under Linux (using RCS anyway).
--
Less money, less admin, less machine--more power

Re:Bah! Counter-example

[RedShodan]

>> 3) I too have had to fix the source code to Linux once -- for my own use. But what happens when you want to distribute your code and it relies on the 'fixed' code? Do you have to wait for your fix to be integrated into the mainstream? Furthermore, though, why should you even have to look into the source code? Ao good API should leave nothing questionable enough for the source code to be consulted.

And you wish to wait on Microsoft to integrate fixes to the proprietary source? All the open source setups that I have seen have responded much faster verging on infinitely faster than any company on a bug fix. And I say 'inifinitely' because many times they simply never respond at all and never fix the problem. The beuaty of open source is that if you are inclined, you can go fix the bug yourself, send the patch with the fix to the maintainers and that saves them the time of figuring out the bug themselves.

You miss the point of an API. An API is to abstract out everything that a person needs to know about how to use this 'black box'. Regardless of how well they did the abstraction, the black box may simply be functionaly broken. An API has nothing to do with that. Open source allows you to go fix that bug and continue on in your development.

Re:Let me count the ways

[tjwhaynes]

4) And then there's all the little things: DLLs. Installers. Command line tools. Now that I've learned how to use the "find" command...well, there's no superlative strong enough to get across how much I prefer Linux.

Several extra tips on that one. For those times when "find" just isn't quick enough, run "updatedb" as a cron task every night at 4am and use "locate" to near-instantly pull filenames out of the database that updatedb builds. Of course if you are doing things like "find . -cmin -60" then this doesn't help, but then you really do want find.

Of course, you can get fancy after that piping the argument into other commands or into other command arguments (using xargs). But that is the beauty of Unix - everything plugs together!

Cheers,

Toby Haynes

Re:Let me count the ways

[SurfsUp]

Here's my opinion: I will quit my job before I will spend as much as a week coding on Windows again.

I *did* quit after it became clear management wasn't going to let me develop on Linux. I'm much happier and productive now - also better paid :-)

4) And then there's all the little things: DLLs. Installers. Command line tools. Now that I've learned how to use the "find" command...well, there's no superlative strong enough to get across how much I prefer Linux.

Hooboy, you're gonna cream when you discover "locate"!
--

Converting MFC SDI etc.

[throx]

Generally the biggest problem with converting an MFC program from SDI to MDI is that you've made all sorts of assumptions about your document being the only one in the application, and similar assumptions about your view. If you've been true to the Doc/View architecture, and assuming your MFC code is clean it really isn't that hard to change from one to the other. The easist thing to do is create 2 projects from scratch which are identical except one is SDI and one MDI. Do a diff and see which code is different. It's not a lot - mostly the Application initialisation.

As for MSDev vs Emacs: I've seen both in use where I work and that's on Windows. When given the choice, I prefer to write my code using MSDev because I like the IDE. Even when coding for Linux, I prefer the layout and operation of the system. Then you switch windows and make (assuming you have Samba and share code dirs). Others use Emacs on NT for development.

I've never crashed NT with Dev Studio. Developing on 9x is suicide - you learn to regret it really quickly. Personally I don't mind Win32 development. YMMV of course, but Microsoft really does go out of their way to make things easier for developers. With tools like MSDN on DVD (over 6G of indexed help), Linux's man pages really pale in shame. The only redeeming grace is the "ultimate" documentation - the kernel itself.

I will say it again: YMMV.

(Brace for flames - this is Slashdot).

John Wiltshire

Why is the question "coding for Linux"

[mr]

The developer in question should be looking at making his/her code run across Unix, not Linux.

Portable code is the key. If they write PORTABLE code they can run on Solaris, AIX, HP/UX, BSD, Mac OS X, etc.

Now, why develop for OpenSource Unix *FIRST*? As another had said....you have FULL access to the source code. You can trace the flow from your code to theirs. And figure out if the error is in their code, the written docuemntation you used to produce the call, or the error is in your code.

The only thing to watch out for is GPLed code if you don't want your code under the GPL. Odds are your firm makes its profit from intellectual property expressed in the source you compile and sell. *IF* someone makes a charge that you have GPLed code in your product, you will have to defend this charge. Such defense could be as simple as a statement "No we don't" to hiring a lawyer to explain to a judge why the lawsuit over the GPL needs to be decided in your firms favor via the presentation of your source code to a judge, paid experts, etc. How do you avoid the GPL? Just read the licences. Some are as simple as public domain. The licence on PostgreSQL is an example of a simple one that is not PD and specific to one program. Some are more verbose and complicated.

If the code *HAS* to run on Windows, libraries exist for Unix to Windows portability. These cost $, and slow up operation, but somehow money and speed are not an issue with M$ software.

Soft mounts

[FascDot Killed My Pr]

man mount:

hard: The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. This is probably what you want.

soft This option allows the kernel to time out if the nfs server is not responding for some time. The time can be specified with timeo=time. This option might be useful if your nfs server sometimes doesn't respond or will be rebooted while some process tries to get a file from the server. Usually it just causes lots of trouble.
--
Less money, less admin, less machine--more power

Re:except

[Surazal]

My (less than thourough) experience suggests that the tools under Wondows you just mentioned aren't as feature-rich or as stable under Redmond's OS than they are in Linux. Yes it's nice they exist, but they aren't the panacea we Linux and Unix developers have been looking for under Win32.

Market, Market, Market...

[Slad]

As a developer of multi-platform applications for almost a decade now, I can say that there aren't any significant advantages in the actual development of apps across different platforms. SOme asre better for some things, and others are better at other things. The one advantage, and the best advantage, is that you can break into different markets and/or make yourself more marketable. Here's what I mean... The chances that Windows will be where it is 10 years from now looks pretty slim. By learning and porting applications to other OSs, you create a user base in a growing market. If Linux takes off and grabs real market share, and/or Apple ports OSX to Intel machines, how pretty will you be sitting when businesses and consumers realize that your apps are available across all three; and can share data transparently? Answer: pretty damn sweet. If you are a developer for a business (not developing "shrink wrapped" apps), it is also a good idea to get your feet wet in developing for other OSs. Again, MS probably won't be the juggernaught it is today; and you will be a lot more marketable if you can develop on other platforms.

Re:*rolls eyes*

[James Ojaste]

I see, I really love it how Unix has 10000 text editors. But I'd prefer one that works, and is easy to use. Does XEmacs support intellisense? No, I didn't think so

I'll assume that was sarcasm. While I prefer nvi, Emacs is highly extensible, and nedit is about the best combination of standard idiot-proof gui and configurability you can get, in my opinion. They're all "easy to use", once you've surpassed the learning curve that every editor has. I hate Intellisense, by the way - it slows me down and my keys stop working properly. After a year or two of 9-to-5 coding, you start to vaguely remember the odd property or method... Yes, that was sarcasm. If there's something I don't remember, I'll look it up, but I don't want the editor to slap me around like that.

Yes I have some friends who can't program that well who refuse to use anything WITHOUT the source code. When I ask them what they do with the source code, they say, they use it to build the binary.

True, the source is useless unless is used for something. I like having the source (if only to compile it) in order to put everything (binaries & configs etc) where I want them. When you install MS-App 98, you get the choice of where to put the base directory and that's it.
I also occasionally have to deal with bugs, and unlike your friends, have a clue about what I'm doing.

The thing about Windows development is it's blackbox. You shouldn't need to know anything about the components except thru the interfaces. Makes things much more stable....guesss what Unix is starting to do. That's right, copy Windows...so far - poorly.

This actually made me laugh. In the grand "OO theory of everything", you are correct in that no object should need to know the details of any other - just the interface between them. Well. I've done enough programming under Windows to notice the slight (sarcasm again) disparity between the documented interface and the real one. I've even had Microsoft ship me a new version of an API with older docs than the ones I already had! If Microsoft wrote to their own published interfaces, their apps wouldn't compile let alone run, let alone run crash-free. Not that they've achieved the last, of course...

Re:Well, it's natural...

[foistboinder]

Learning C++ in Microsoft's Visual Studio environment is, in my opinion, a bad thing. A novice programmer can crank out software (the quality of which is usually poor) using MFC and the IDE's Class Wizard and not actually understand anything about the language. When faced with a task that requires actual understanding of inheritance, polymorphism, overloading, or anything the IDE can't generate a framework for, such a programmer will always get stuck (making more work for me).

It is better to at least learn C++ in an environment that requires one to actually learn how the language works to get anything done. This understanding will be useful even when asked to work with something like Microsoft's Visual Studio.

I once worked on the project were the technical lead required UNIX (or similar OS) C++ experience even though the bulk of the work was on Windows NT. His reasoning was that almost all people claiming C++ experience but only had Windows experience didn't know the language well enough for a complex project.

Laziness

[slim]

I find that laziness drives me to code on UNIX, because the UNIX little-tools-in-a-pipe philosophy usually means that I only have to write a tiny program to do what I want, and in general it only needs to handle input from STDIN and output from STDOUT, so I don't have to worry about

In a Windows environment, it's likely I'd feel the need to write some sort of GUI. Windows would not provide me with the rich set of CLI tools I'd need to wrap around my quick and easy program to make it fully functional. It's possible I'd have to write that functionality into my own program instead. Sure, you *can* install GNU sort, cut, awk, sed, tr, etc. on Windows, but by the time you've done so you may as well have installed Linux or BSD.


--

Control

[Hard_Code]

Why?

Because since the code is open, as a coder, you are given entirely free reign to do what you want to do, how you want to do it, and are "empowered" to actually discover and remedy bugs.

Because you are not at the mercy of a large, faceless, corporation which dictates the APIs and specifications to you, forces you to use certain tools, locks you in, and makes you pay through the nose.

Because Linux, Unix, and open source *wants* and *needs* you. Microsoft couldn't care less. There are beanie weenies falling all over themselves to become l33t VB c0ders.

Because it is the Right Thing.

Re:except

[jguthrie]

kaisyain wrote:

I haven't found writing console apps any more difficult under Windows than it is under Linux. Writing GUI apps is as difficult or as easy as the underlying toolkit makes it. You don't have use MFC under windows, anymore than you have to use raw xlib calls under linux.

Except that MFC calls are supposed to hide all the complexity of the Windows equivalent of Xlib (and Xaw) calls from the programmer. There are class libraries that are available for X (Qt vs GTK flamewar, anyone?) and they are all better done than MFC. (Well, I hope they are, anyway. While I can imagine someone setting out to make a worse class library than MFC, I'd like to think that nobody would.)

Unfortunately, MFC is the standard for Windows programming. If you're doing Windows programming and you're not using MFC, then the suits complain. If you're strong enough to resist the suits, then you could already be running Linux.

Windows GUI programming is not nearly as nasty without MFC (which I found entirely unpleasant with its arbitrary and arcane rules concerning things like the messages that need be handled) but for most shops Windows programming means MFC programming just like it means using Microsoft C++ or Visual BASIC

As for the IDE's, well, back in the 1970's, an article titled "Real Programmers Don't Use Pascal" said that real programmers are happy with an 027 keypunch, a FORTRAN IV compiler, and a beer. The way I see it, XEmacs blows the heck out of a keypunch, C is at least as good ad FORTRAN IV, and I can afford plenty of beer. At least with makefiles and command-line compilers, I don't have to worry about my project files getting munged because somebody decided to update the IDE.

One opinion, worth what you paid for it.

Re:*rolls eyes*

[SurfsUp]

Nice troll.

I really love it how Unix has 10000 text editors. But I'd prefer one that works

Try Nedit if you want it to make an easy switch from Windows.

And stability isn't an issue for many windows developers who use NT/2000.

That's funny. I developed on NT 4 for a few weeks and I had processes lock up on at least a dozen occasions - other times, I had the system start doing strange things that only a reboot would fix, like displaying the mouse at a displacement from where the hits were actually occuring. ActiveX controls would crash constantly, and couldn't be restarted - also requiring a reboot. On a number of occasions the mouse cursor just froze, for periods up to 30 seconds. Maybe your experience was different, after all, as a Microsoft Troll perhaps you spend most of your time camping on a web browser and not actually developing?
--

I did..

[Tom7]

Visual Studio was a lot better than I expected from Microsoft, but it's not that good. It has a damn lot of features, but many of them narrow your thinking so much that you tend to produce the Same Old Windows App every time.

Here are some of the problems I've run into in Visual Studio:

Project management is so complicated and "behind-the-scenese" that projects can easily get corrupted and unbuildable.

BAD support for advanced features of C++, especially exceptions and templates (yes, worse than g++). One time we took a working, warning-free program from g++ to MSVC++ and it crashed the compiler. Another one couldn't compile because VC++ put a 255 character limit on the length of the names of instantiated templates.

AND IT ASKS YOU "Are you sure you want to recompile?" when you PRESS COMPILE!!

And of course, linux features unmached by windows:

Availability of library/kernel source

Awesome emacs features like smart syntax coloring, automatic indenting, regexp search/replace, keyboard macros

Elegant, scriptable project management

Not having to worry quite so much about compiler bugs.

Of course, the forms designer is the best way to make windows in Windows, and some other tools are invaluable. But as much as I'd like to be able to make apps for the OS I use as my desktop, I've just given up on dealing with MSVC. (And I have no patience to learn the twisted API and compile with cygwin or something ;))

The experience is not the same

[Dungeon Dweller]

I have written programs using these tools under windows. The experience is not the same. Windows just does not work like Linux/Unix does. Unix has been molded to fit the C language. Working with external programs, libraries, everything is a basic function call in C, whereas under windows, this is far from true.

Cross platform development

[Dungeon Dweller]

There are several libraries that have ports for both environments. I suggest using one of these if you are developing cross platform, less code to modify. The only time that I would suggest not using them is when you need fast, optimized code.

2 different arguments...

[justin_saunders]

Folks, there are two different arguments going on here.

1) Windows itself is a buggy and unstable platform with bad API's.
2) Programming tools on Linux are easy/harder/more productive than under Windows (with tools like Visual Studio)

I agree with #1, however as user of Visual Studio for several years I'd say that Windows wins #2.

I've never used a more helpful and intuitive coding environment. Once you use Intellisense its hard to remember how you worked without it. Just try coding without syntax highlighting and you kind of get the picture. "Edit and Continue" make it an absolute joy to debug.

If you are a little careful it's easy to write portable code under Visual Studio, and Win2k is suprisingly stable.

That said, there's something beautifully pure about using makefiles and debugging with GDB, and its good for your soul to take control on a low level now and then. For me, its kinda like camping in the woods for a few days. Some peope like camping a lot, others don't...

Try both out and see what feels "right".

Cheers,
Justin.

Re:*rolls eyes*

[frantzdb]

I see, I really love it how Unix has 10000 text editors. But I'd prefer one that works, and is easy to use. Does XEmacs support intellisense? No, I didn't think so. What's XEmac's goal? To demonstrate bad HCI by having the most deeply nested menus ever seen on the face of the earth.

There is easy to use and easy to learn. MSVC++ is easy to learn. Emacs is easy to use. Seriously. There is a bit of a learning curve but once you understand the basics it becomes much more clear.

Another poster in this discussion mentioned that yes, you can get ``intellisense'' in Emacs. Finally, if you are using the menus in Emacs then you clearly havn't tried to use it. IMHO you shouldn't have to use Emacs' menus. (M-x is your friend ;-)

Finally, the best reason to use Emacs (which I use in windows too, btw) is that when coding, hiting tab, instead of inserting the tab character at the cursor, properly indents the current line. It's great :-)

--Ben

Re:*rolls eyes*

[Old Wolf]

Windows gives me much more freedom (speaking as a programmer). I can actually achieve what I want to do quickly, than spending hours wading around in irrelevant details and reading source and trying to figure out if it is even possible to do whatever.

The question has not been clearly answered.

[Junks Jerzey]

Emacs in nice in some ways, but it's a dated dog in others. IDEs from Microsoft, Borland, and Metrowerks are annoying in different ways, but make so many things *sweet* (the Microsoft's being the worst of the three, because they insist that MDI programs are good). Similarly, Makefiles are nice sometimes, but once you've lived without them then you wonder why you went through all the trouble in the first place. Of course, you can use Makefiles with Windows compilers as well. The three big compiler companies all ship command line tools, so heck, you could even use Emacs under Windows if you want.

There's no clear answer yet.

Re:Give Emacs a Chance!

[still_nfi]

Emacs is truly awesome.....I can't stand any other editor anymore.
There are 2 features (out of the box) of emacs that I just can't live without.
1. Dynamic expansion - start typing a word press alt-/ and if that word exists in any file you have open, it will complete it for you, cycling through the possibilities. Greatly improves my code readability since now I can have informative variable names :)
2. Coding/indent styles - Once you set up your preferred indenting style, just have to hit tab to put that line in its rightful place. ctl-c ctl-q and the whole damn file is indented the way you want it!
There are a million other reasons emacs is cool and if you don't have one, you can easily make it do what you want. Emacs does take some time to coax it to behave the way you like, but once you are there.......you shall never return to the dark side.

Advantages

[jd]

*G* This seems an opportunity to plug all the different benefits Linux has to offer:

• Industry-Standard API (POSIX & UNIX98)
• Near-transparent portability (see above)
• Stable API (a MUST for developers)
• Plethora of development tools
  • Autobook, Docbook, web, et al - integrate docs and code
  • RCS, CVS - platform & vendor independent version tracking
  • Sourceforge (and, eventually, Server51) - platform & vendor independent project management
  • Slashdot - platform & vendor independent gossip tracking
  • automake, autoconf, configure - resource scanners
  • gdb, xxgdb, ddd - graphical debuggers
• Customise your environment to suit YOU, not vice versa
  • Many window managers & environments
  • KDE
  • Gnome
  • Open Look
  • Motif
  • Enlightenment
  • QVWM
  • and many more
• Many GUI systems - X, GGI, Berlin, etc
• Concentration Aids (eg: XRoach)
• Transparent Windows (eg: OClock -transparent)
• ANY resolution your monitor and card can display, not merely some random numbers someone thought up.
• Virtual desktops
• Focus control - no more pop-ups grabbing the mouse at random
• NO MORE PAPERCLIPS!!!
• NO MORE PAPERCLIPS!!! (Yes, I know I already said that, but it's so important, it's worth saying twice)

Read/Write almost any disk format in existance

Cross-platform testing, using WINE or IBCS, -without- rebooting or switching machines

The Penguin logo is cooler than the flying window

Ability to test out on multiple network configurations

• Not everyone uses IPv4. Linux also supports IPv6 (a protocol Microsoft is struggling to write any driver at all for)
• Then there's DecNet, Appletalk, Econet, IPX/SPX, PLIP, PPP/SLIP, wireless networks, Frame Relay, IR networks, etc

Linux is gaining mindshare & market share in the server arena. Microsoft isn't.

Linux is gaining mindshare & market share in the home network market. Microsoft isn't.

Linux has a guaranteed future. Right now, Microsoft doesn't.

Linux is future-proof, as it can migrate to a pure 64-bit OS. Microsoft 9x is DEAD, in 2032, and companies might not want another Y2K budget fiasco.

CBQ, RED, ECN, RSVP are all supported, making Linux a powerful network machine and DDoS-proof. Windows is not.

Linux supports a wider range of RAID configurations (so long as you don't use 2.3 or 2.4, just yet!)

Linux has better swap-handling, making development quicker. (Faster compile times, less disk thrashing, etc.)

Linux has -real- FS journalling. MS Windows does not.

Re:Why develop for Linux?

[Surak]

Here's a question - open to all - if you have an acquaintance who you are hideously attracted to, and want to see about exploring the relationship BUT you don't want to inadvertently queer the current, tenuous friendship, what's a good way to do it?

How the hell did that get in there?????

The advantage?

[stripes]

The big advantage is that your code will run under Linux (and other Unixish systems if you do your job right). That's a big deal, because you won't get bug reports about other programs crashing yours...and there are way fewer pain in the ass liberery bugs...and when there are it is far easyer to find them with the source to libc (or libcurses, or libfoo) and either fix them, or code around them. Way way way nicer. At least IMHO.

Preach On!

[T_Wit]

I'm totally sick of Universities' attitudes toward computer science. I majored in CS at two universities - ETBU, & UT Dallas. ETBU we had to do everything in Windows, at UT Dallas, everything is in Windows and you're "highly encouraged" to use Visual Studio. VS is good for turning out windows stuff. Other than that, like everybody says, It Sucks! There's too much crap between the actual code of the program that I write and the pretty buttons you see on the screen.

Now, for my personal rant - why are we learning this stuff backwards? At school they try to teach pretty interfaces and making your program user friendly... and then a year or so down the road learning assembly. Why don't we learn assembly first, then basic C, etc, and then by the time we're making those oh-so-spiffy interfaces we're turning out real-world aps that are actually useful. I can only code The Library Program so many times, ya know :) Doing The Library Program in first one language, then another, then another doesn't actually further my knowledge of programming. Give me a book of syntax and I can learn languages. I pay these people umpteen bux I don't have every semester to teach me programming, not pretty interfaces. Okay, end of my explosion about the status quo :)

MSVC Plugins

[Malc]

It is possible to write plugins. Take a look at the Visemacs page: http://www.atnetsend.net/computing/Vis Emacs/ [atnetsend.net]. Visemacs integrates Emacs into MSVC (well, as best it can considering the constraints placed on the task by Emacs ;)). I've been using it for several years, and really like it. The source is available, so I'm sure it wouldn't be hard to do a plugin for Vi, Lemmy, etc. Of course, Emacs integration uses the gnuserv package.

Re:except

[Black Parrot]

> Emacs, vim, gcc, python, perl, tcl, sed, awk, grep, tar. All available under windows.

If you're using "Linux" tools under Windows, the question changes from Why develop on Linux? to Why develop on Windows?

--

General Comments

[swamp boy]

Myths
1) NT == IDE (can use CLI makes on NT)
2) Linux == CLI (can use IDE on Linux/Unix)

Advantages of *any* unix flavor:
1) Client/Server nature of X (can sit at your workstation and work on any other unix box transparently. no need for pcAnywhere)
2) Industrial strength "kill" (i can issue kill -9 [pid] and *know* that the process will die)
3) More sophisticated shells (BASH, C shell, Korn shell, Bourne shell all leave cmd.exe in the dirt). Though one can get these equivalents on Windows, they're there on Unix.
4) lsof (view which processes have files open -- very handy on occasion)

Advantages of NT:
1) Tightly integrated toolset for MS development tools.

Tools/Utilities:
1) The tools/utilities such as vi, emacs, sed, awk, etc. can all be obtained for Windows. However, the Unix versions typically are more full-featured.
2) Editors are definitely a matter of personal preference. Personally, I'm no fan of emacs. There's a nice GUI editor called "CoolEdit" (http://cooledit.sourceforge.net/) [sourceforge.net] that only requires Xlib. See above advantage of the client/server nature of X. Commercial editors like Visual Slickedit (my favorite) is available on Windows, most flavors of Unix, and other platforms (OS/390 even).
3) I've come to the conclusion that it's often better to stick with scripting languages like Perl or Python (my favorite) instead of writing shell scripts or batch files. They're more powerful, usually more readable (at least in the case of Python), and definitely more portable.
4) Using *multiple* compilers on your source is often advantageous since one compiler may catch some things that another will not (as well as giving a check on compiler dependencies).

Re:Give Emacs a Chance!

[Azog]

No you could not add this to emacs as a "trivial hack". No way.

Why? Well, the compiler and the IDE talk to each other in DevStudio. The only way you could really get the same level of functionality in Emacs would be to build the first few stages of the C++ compiler pipeline into it.

If you type:

"pMyDoc->m_pWindo[tab]" it fills in the rest of the member variable. When you get the m_pWindowList you can type "->Head(" and the little tip window pops up and shows you what the arguments are for the Head method of pMyDoc->m_pWindowList.

Now, to do that in Emacs you would have to build code to:

1. Keep track of all temporary variables, their scope, and their type or class

2. Build tables of all classes and their methods and members, with the class or type of each.

The problem is, that's essentially the first stage of a compiler. It is NOT a trivial hack. You can't just do it by piping together a bunch of text parsing functions: you have to keep all this stuff in memory for decent performance - and even DevStudio 6 is pretty slow sometimes for this stuff.

On the other hand, under Windows you have to put up with MFC which has some good stuff but a lot of problems. You have to put up with all the different versions of Windows, which behave in different (undocumented!) ways and have different bugs. There are at least three occasions where I lost a night of sleep trying to fix things that worked perfectly under NT and blew up under Windows 95. (Microsoft fans who doubt me can get all the gory details by asking.) Without the source you often feel like you are working blindfolded.

My background: One month ago I started my cool new job using OpenBSD, Java, PHP, and Apache. I have used Linux at home for years, but haven't done serious development under it until now. I use Emacs because it's better than vi, but I don't think emacs is very good either. I want an editor that uses Alt- keys, not "Ctrl-X Ctrl-that Meta-x foo" for everything.

Simply put: I want Dev Studio 6 capabilities under a free operating system. That would be bliss. And if the IDE and compiler are all free software too.... ooohhh yeah baby.

The problem is, I believe that most free software developers just put in the huge effort to get good at vi or emacs (which are very powerful) but then don't have any incentive to create something better. And it could be better.


Torrey Hoffman (Azog)

Well...

[Greyfox]

1) Stability: Unless you're doing kernel or driver level work, you can pretty much count on Linux never crashing on you.

2) Development tools: GCC is one of the best implementations of ANSI C++ available. Possibly the best. With exceptions, namespaces, templates and STL, C++ now feels like a mature language. And you can get an assortment of ORBs and other goodies. And if you ever wonder, "How did they do that?" you can look at the source.

3) Intuitive: I've always found the X paradigm of using callback functions to be much more intuitive than the Windows event driven big case statement offering.

4) Stable APIs: OK, Microsoft hasn't really been playing the API of the week club game since they mercilessly slaughtered OS/2, but if the APIs ever do change, you don't have that nagging feeling that the people who made the change did it just to piss you off.

5) Choice: You have your choice of toolkits, and many of those toolkits are portable to other operating systems.

6) Total Cost of Ownership: All the necessary development tools in Linux are free. By the time you finish assembling everything you need on Windows, you could easily have shelled out more than your computer cost you. And you'll have to pay for updates on a regular basis.

Book Recommendation: The Unix Philosophy

[dsplat]

Get a copy of The Unix Philosophy by Mike Gancarz. You can read more about it or buy from fatbrain.com [fatbrain.com]. The first sentence of their description explains its relevance:

Unlike so many books that focus on how to use UNIX, The UNIX Philosophy concentrates on answering the question, "Why use UNIX in the first place?"

Re:except

[nehril]

Why code under Linux? Because you need to make a program that runs under Linux!! If you need to make a Windows program, develop it in Windows.

The fact that this question focusses exclusively on the "what to develop in" aspect ignores the fact that computers are just a tool, and you use the right one for solving whatever problem you need fixed.

So the question should really be, "For what kinds of problems is Linux a better solution that Windows?" Answer that, and you have also answered which system to develop under.

Both systems have their strengths and weaknesses for development, and a competent coder can do a good job on either platform.

Adding toolkits to make Linux more gooey or Windows more command-liney doesn't at all help you answer the "which is more appropriate for this task" question.

Re:Give Emacs a Chance!

[tjwhaynes]

No you could not add this to emacs as a "trivial hack". No way.

OOOooo! A CHALLENGE! :-)

Why? Well, the compiler and the IDE talk to each other in DevStudio. The only way you could really get the same level of functionality in Emacs would be to build the first few stages of the C++ compiler pipeline into it.

I disagree, but do continue. I'll explain why later.

If you type:

"pMyDoc->m_pWindo[tab]" it fills in the rest of the member variable. When you get the m_pWindowList you can type "->Head(" and the little tip window pops up and shows you what the arguments are for the Head method of pMyDoc->m_pWindowList.

Several options here for the budding Emacs hacker to get going on. For Emacs users already using Imenu and Speedbar, much of the functionality to chase those variables is in there. Spawning either inset windows or new frames in Emacs is not a difficult task. Dynamic or stati c abbreviation expansion can be used to fire up lisp functions as well as complete text, so having a hook run at buffer entry to set up the abbreviation tables is trivial.

Now, to do that in Emacs you would have to build code to:

1. Keep track of all temporary variables, their scope, and their type or class
2. Build tables of all classes and their methods and members, with the class or type of each.

That's why I noted that with TAGS support, most of the work to implement this hack is done. TAGS databases already include a complete list of structs, variables, functions and other such data. Therefore finding out what the definition contains is not difficult and neither is parsing it. Emacs is good with text :-)

Cheers,

Toby Haynes

Re:Why develop for Linux?

[mav[LAG]]

I dunno but in answer to the question: tread carefully. I was in the same situation a couple of years ago, decided a fork() or two would solve the problem and now I have two child processes to worry about...

Re:Preach On!

[dane23]

I'm not sure about ETBU but I'm not suprised about your unhappiness with UT Dallas. I wasn't impressed at all by UT Austin's Comp Sci program. My Comp Sci degree is from SWT in San Marcos, TX. It's a smaller school but the Comp Sci department actually taught the subject the right way. Assembly was a gateway class to the higher level courses, as was Data Structures and C. We didn't get into Human Factors, for GUI design, or Java until the senior level courses. The Linux Programming course alone was worth every late night study session.

Which bring me to my question: Why do people give small schools a bad time? I've been to UT Austin and UT San Antonio and I still prefer my experience at SWT in San Marcos over these two "better" schools.

Re:Preach On!

[Alan]

Agreed.

When I was in college my advanced pascal class (this was 94ish) introduced us to the concepts of pointers, memory allocation, constructors, destructors and object orientation.

I was fscking lost. When did you dereference again? Do I have to allocate memory? Huh?

The semester after I took assembler. Suddenly all these concepts came to life! Wow! I know what a string is now, I know what I'm actually doing when I allocate memory! Wow, suddenly I understand why I need a constructor and destructor! Null terminated string is not just a term but an idea I can visualize in my head!

That's my personal experience with this anyway. YMMV. However, I gotta agree with anyone who says that it is the Right Thing to teach from the ground up. If people had to take an assembler class *before* they got to take their "become a high paid programmer by cranking out crap in VB in 6 weeks" class, I think we'd have better programmers out there.

Now I don't begrudge people needing apps Now(tm). A friend of mine does VB programming and I admit that it has it's place. Being able to produce a program and worry about UI rather than worrying about HOW it's doing it is a good thing. But there *has* to be a nice melding of the two.

Advantages developing on Unix/Linux

[antv]

General advantages of Unix are:

• huge number of free (open-source) software floating around. You don't even need to borrow any code, you could just see how feature X is implemented (for example I remember looking at some Perl code and implementing smth similar in C)
• open standarts. Practically all kinds of Unix are compatible on source level because of that (POSIX, X libs and everything on top of them, i.e. GTK/QT, etc, is the same on every Unix). You don't have huge number of undocumented (or in most cases in Windows half-documented) APIs

• Practically all other advantages depends on language you use. Unix have incredibly good set of tools (gcc,make,cvs,gprof,etc). Most of them had been ported to windows as well, I don't have much experience with those ports. However, there are some advantages of Unix system itself:

  • For scripting languages one big advantage is that kernel automatically runs interpreter specified after magic '#!' . That could be a quite helpful if you have a system with many scripts running each other. For example if 25 programs call script X, and you decided to rewrite it, say, in Phyton istead of Perl, you don't need to modify those 25 programs to run Phyton interpreter - you just modify the script.
  • 
    For most shell scripts stuff like /proc filesystem is very useful too - you could extract a lot of information from it.
    Also, windows still lacks many shell utils. Last time I checked, pipes support was horriple - maybe it's changed in W2K, thought

For C/C++ programmer Unix have even more advantages:

Unix memory protection mechanisms - superior to anything I've seen. Most problems I have with C/C++ programs (especially raw C) are memory-related. Unix approach is very flexible: when program tries to access wrong address in memory it receives SIGSEGV or SIGBUS and could either intercept it and handle situation by itself or it could just create core dump (I usually trap SIGSEGV to output values of internal vars at the time of crash). Libraries like Electric Fence take advantage of this mechanism too.
Also, under Unix, application couldn't write in system memory. Under windows it's not supposed to - and as you could easily see none of microsoft's absolutely bug-free applications never ever crash windows, right ?

Support for debugging, like core dumps and ptrace(). Core dump allows you to save program state at any point, so that you could open it in debugger later. ptrace() allows you to trace process execution - in windows there are mechanisms to do this but all the debuggers I've seen (from SoftIce to TD) use their own functions, which means windows' default interface is almost useless. Also, you could attach your debugger to already running process, this is very usefull when debugging something like server process (in my case Squid proxy 2.3DEVEL3)

Much better development tools, like gdb and ddd. gdb, for example, is scriptable, you could easily program it to watch when variable changes to a specific value, when it does set temporary breakpoint in a specific function, trace that function until exit, and then if another variable has specific value set another breakpoint. I don't claim to be VC++ guru, but the only way to do it that I know is to press "next" and "step" buttons around 700 times. I tried. VC++ crashed somewhere at 500th.

DDD (Data Display Debugger) is really just a shell on top of gdb (or dbx or perl debugger). It's tread if you have complex data structures in your program and would like to examine them. DDD allows you to run gdb remotely, for example I ssh'ed to server (SunOS SPARC) from my workstation couple of times to debug a running cache proxy.

Some of these things could be implemented under windows, but things like watchpoints would require debugger to rewrite parts of OS.

Tools like gcc and emacs.
Emacs Is The Olny One True Editor, period !
Seriously, I never seen any other sools able to do everything emacs can, i.e.:

• Syntax hiliting, auto ident, parens balancing, and other basic features is of course a requirement, not an optional feature. Unfortunately, I haven't seen any editor yet that has it all in one place, i.e. expression auto-hiliting, identing, coloring, all the advanced search/replace, etc.
• code navigation, i.e. search any identifier in the whole source tree using tags table, speedbar (tree-like browser of functions, structures, etc) bookmark support, etc.
• Support for diffs, CVS/RCS, Makefile modes
  Please note that all the features above are supported at least for C/C++, Perl and Java, function navigation also works with List, etc
• Macros: emacs main advantage. To put it simply, emacs have macros system based on Lisp, powerfull enough to write mailer, news reader, web browser, games like tetris, AIM/ICQ/IRC support, telnet/FTP/ssh support, browsing thru compressed archives, etc

I've tried windows version of emacs, but they have very limited number of features compared to Unix versions

As for gcc, it's simply a C/C++/Objective C compiler with support for, if I remember correctly, at least 29 platforms, one of the best optimisers I've ever seen (egcs beats VC++ and Borland on every project I've seen), very powerfull error-detection mechanisms (I always use -Wall -pedantic options, it's way much more picky than either VC++ or Borland CppBuilder, but I never ever seen it bark on something that was not an error)
gcc is ported to windows, slow, but it's working

Last, but certainly not the least, user interfaces are better designed. For example, in Unix once you open socket you could use file IO functions like write() to write into it. When I tried to do it on NT I had 2 different results: General Protection Fault and BSOD. Unix system supports some very advanced functions, like for example, locking only certain parts of file (you could lock bytes 30 to 56 in a file, rest of the file is writable). X has very powerful API. One thing I really like is window being able to swallow (capture) another window. That, for instance, allows you to run any X application inside Netscape, provided you have plugin called xswallow. X does more than just windowing, it allows you to create atoms and properties - basically something like windows registry, only transparent thru network. Unix Netscape uses this mechanism to send "remote" commands to it's instance runnings, even if that instance is running on another machine. Similarly, XEmacs uses this interface to to connect to remote emacs process.
Unix has wide array of GUI toolkits, like Motif/GTK/QT/Tk. Some of them are much easier (for me) to use than MFC. For example GTK's event handling scheme is much better.
GUI development tools that Unix has look much more appealing to me than their windowsa counterparts. For example Glade - tool that creates GUI interfaces visually. There is a library called libglade that allows you to load Glage project on runtime. That way you could have "pluggable" user interfaces. I have yet to see anything like that for windows.
Component architecture upon which GNOME is build (CORBA) also seems to be better for me than COM. I'm not a COM expert, but parts of COM design I'm familiar with (for example the "proxy" components needed to marshall request over network) look like a kludge on top of badly designed protocol for me. CORBA is available for windows, but unlike GNOME, which is all based on CORBA, windows is based on COM, so practically you have CORBA and no components for it

Bottom line: learn every OS you can. Code for Unix - more fun ;-)

Re:Borland's VCL IS the way to go...

[RobertAG]

A few years ago I decided to try C++ as a programming language for Windows. Until that point, I had been using Visual Basic to develop in the windows environment (mostly database stuff). Because certain things in VB can only be done by accessing the WinAPI, I decided to investigate the possibility of using C++. Since VB and Visual C++ came from the same company, I thought, their IDEs were probably similiar. I had learned C++ in some college classes on a Solaris Box, so I wasn't too concerned with being overwhelmed.

Surprise. Surprise. The VC++ IDE was/is NOTHING like VB's. Windows development in VC++ was more primitive. You actually had to define the main window, create it and create the message loop for the program. In all, in order to bring up "Hello World" in a single window you needed several lines of code and about 30 minutes. Over the next few days, I learned a few other things, but was always astonished that it took so much to do so little. Needless to say, I looked to explore other options.

About this time, Borland released the trial version of C++ Builder. They said that it used the Delphi VCL and IDE. Since my current job at the university included a T3 connection to my computer, it took only a few minutes to download and install.>

For those of you who've never used C++ Builder, think Visual Basic IDE with C++ syntax. In was able to make that same "Hello World" app in 5 minutes, including compile time. This, I thought to myself, was what M$ should have done. Since that time, I've used C++ builder as much as I could. It's stable and does NOT MARRY ITSELF TO THE OPERATING SYSTEM like all other MS products. If Borland/Inprise ever developed a BASIC version of VCL, I would push my company to switch in a heartbeat.

Microsoft's products seem to exist to promote themselves, rather than to encourage the programmer. Their documentation in Visual Studio is almost total garbage. I find myself using 3rd party books and tools just so I won't have to deal with it. I've even used the HLP file on Visual Basic version 4 to look up syntax after a similiar MSDN query on Visual Studio kept giving me the wrong answer consistently.

Regarding programming tools and options for Linux, J++ Builder Foundation a very good tool to use to learn JAVA. Borland/Inprise has a very good history of designing IDEs/GUIs and that much is apparent. The only downside is the sheer size of the APP. You'll need 128MB RAM to run the thing without pounding your disk cache constantly. If you want a good, powerful text editor, use EMACS. If you want a good, simple text editor, use Pico. If you are doing web development and need a server side language, there is a Java plug-in for Apache called JServ. PHP is also a good language, I've recently discovered. Also check out shell scripting. Unlike DOS, The command interpreter in Linux is very sophisticated.

As a coding environment, Linux offers the best choices and widest variety. Once you start, the thought of going back to Windows will make you ill.

Re:Where did this myth come from???

[DunbarTheInept]

Unix just happened to have been written by an employee at Bell Labs who liked C enough to recode it in the language...

..Yeah, the same someone. The K&R of C fame are also the K&R of UNIX fame. C was designed specifically for the needs of systems development, where they wanted a language with some of the high-level syntax, but without the high-level masking of what's really happening. (the "icky" features of C that let you make all the same mistakes as in assembly language are actually intentional - It was meant to let people develop something as low-level as an OS in it.)

You are right that the first experimental versions of UNIX predate C, but those versions were not the versions the public saw later when UNIX finally escaped from Bell Labs and saw the light of day. The switch to C happened very early in the development of UNIX, and C was designed explicitly with the needs of the UNIX developers in mind, so it meshed very well.