"Steve Dossick" <steve@knownow.com> writes:
> But, there are other kinds of software people build on their
> workstations (i.e. non-web software), and many dev groups would
> prefer their engineers developing on the identical platform the
> software will eventually run on.
Sure --- I admitted it was probably a better Fortran development
station, didn't I? ;)
> -- I can call CheapBytes and pay $26 for a CD containing all the GNU sources
> (including Emacs). By Kragen's own admission to me verbally yesterday, just
> about all the GNU software builds with "./configure ; make", which is only
> slightly more time-consuming than "apt-get install <pkg>".
That's true, but ./configure && make install does a lot less than
apt-get install <pkg>. It doesn't configure the software
appropriately for your system, download and install the three other
libraries <pkg> depends on, install <pkg> as the new alternative for
vi, set <pkg>'s daemon up to be run when you boot, or start the daemon
itself. All of these are things you have to do if you ./configure &&
make install yourself, and figuring out how to do them often requires
spending an hour or two reading documentation.
Also, GNU software is something like 5% of Debian, and the other 95%
includes some pretty useful stuff --- Apache, Perl, Python, and
PostgreSQL, to name a few. Most of those packages have their own
slightly idiosyncratic installation methods.
To be fair, Debian isn't perfect; I'm going to have to build Apache on
my Debian machine to get mod_perl working.
What it adds up to is that I can install several hundred or thousand
Debian packages on a machine in an hour or two, while installing
J. Random Free Software Package on a Solaris box takes at least a
couple of minutes, even with pkgadd.
> -- 64-bitness is indeed an implementation detail. But if you're building
> native-code applications which need to eventually run on an E10k or some
> other 64-bit system, it's nice that your developers work in a 64bit
> environment too. This can potentially remove a porting step from the 32bit
> arch system.
Yes, and it's a good idea to regularly test on the same ISA your
software will eventually be deployed on, too, especially if your
software is written in C or C++.
> -- "The ultimate dev platform" really depends on who you are, what
> you're developing and what your budget is. For you Kragen, I
> imagine the ultimate dev platform is something which runs perl,
> python, and other languages you regularly use well.
If I were writing Fortran applications, it would need to be something
that ran Fortran well. If I were writing C, it would need to be
something that ran C well. It happens that, at the moment, strace,
mod_perl, and Perl are the server-side development tools I need most,
while on the client side, MSIE, Netscape, and Visual J++ are the tools
I need most.
> In addition, the platform includes Emacs and other tools you like to
> use. For me, the ultimate dev platform includes all these tools
> plus has great, optimized native-code compilers (C++) and has
> aftermarket tools available like Purify and Quantify. (Yes, we are
> beginning to see tools patterned after Purify available for Linux,
> but I like Purify -- it's part of MY ultimate dev platform).
Purify is *really* useful when you're writing programs in low-level
languages. I'm rather startled that Purify itself isn't available for
Linux. (It's true, though, according to Rational's web site.
Ironically, when I went to Rational's web site to check, it complained
that some Java source file wouldn't parse instead of showing me their
home page. Someone checked in source code that wouldn't parse and
published it on their web site.)
> The truly ironic thing here is that I'm the person who ordered the Dell
> machine on Kragen's desk :) :)
So how much did it cost?
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:13:28 PDT